From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 00:18:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31739106564A for ; Sun, 5 Feb 2012 00:18:20 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id DEE2A8FC15 for ; Sun, 5 Feb 2012 00:18:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q150IIJE062585; Sat, 4 Feb 2012 17:18:18 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q150IIw7062582; Sat, 4 Feb 2012 17:18:18 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 4 Feb 2012 17:18:18 -0700 (MST) From: Warren Block To: Jason Hellenthal In-Reply-To: <20120204230332.GA582@DataIX.net> Message-ID: References: <20120204184816.GA52504@icarus.home.lan> <20120204190702.GC37724@DataIX.net> <20120204230332.GA582@DataIX.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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 04 Feb 2012 17:18:18 -0700 (MST) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ld: kernel.debug: Not enough room for program headers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 00:18:20 -0000 On Sat, 4 Feb 2012, Jason Hellenthal wrote: > On Sat, Feb 04, 2012 at 12:54:58PM -0700, Warren Block wrote: >> But it still does (did) not build here with NOCCACHE set, so it's not >> a ccache problem. > > I have seen ccache before run anyway even though .if statements are > within make.conf to prevent it. It was something to do with make and > friends built from world with ccache and after it would continue to use > ccache regardless. This can be verified by watching the cache hits and > misses during a compile with NOCCACHE set. Its tough to revert from > this but involves removing ccache/distcc from the system. Interesting. Just for fun, I tried that, and the ccache stats didn't change. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 01:55:13 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B02191065676; Sun, 5 Feb 2012 01:55:13 +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 544D98FC13; Sun, 5 Feb 2012 01:55:13 +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 q151tCGt014951; Sun, 5 Feb 2012 01:55:12 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q151tCs8014908; Sun, 5 Feb 2012 01:55:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Feb 2012 01:55:12 GMT Message-Id: <201202050155.q151tCs8014908@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 , , Precedence: bulk Cc: Subject: [releng_8_2 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 01:55:13 -0000 TB --- 2012-02-05 01:16:09 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 01:16:09 - starting RELENG_8_2 tinderbox run for mips/mips TB --- 2012-02-05 01:16:09 - cleaning the object tree TB --- 2012-02-05 01:16:17 - cvsupping the source tree TB --- 2012-02-05 01:16:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/mips/mips/supfile TB --- 2012-02-05 01:16:33 - building world TB --- 2012-02-05 01:16:33 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 01:16:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 01:16:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 01:16:33 - SRCCONF=/dev/null TB --- 2012-02-05 01:16:33 - TARGET=mips TB --- 2012-02-05 01:16:33 - TARGET_ARCH=mips TB --- 2012-02-05 01:16:33 - TZ=UTC TB --- 2012-02-05 01:16:33 - __MAKE_CONF=/dev/null TB --- 2012-02-05 01:16:33 - cd /src TB --- 2012-02-05 01:16:33 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 01:16:33 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 Sun Feb 5 01:52:51 UTC 2012 TB --- 2012-02-05 01:52:51 - cd /src/sys/mips/conf TB --- 2012-02-05 01:52:51 - /usr/sbin/config -m ADM5120 TB --- 2012-02-05 01:52:51 - building ADM5120 kernel TB --- 2012-02-05 01:52:51 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 01:52:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 01:52:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 01:52:51 - SRCCONF=/dev/null TB --- 2012-02-05 01:52:51 - TARGET=mips TB --- 2012-02-05 01:52:51 - TARGET_ARCH=mips TB --- 2012-02-05 01:52:51 - TZ=UTC TB --- 2012-02-05 01:52:51 - __MAKE_CONF=/dev/null TB --- 2012-02-05 01:52:51 - cd /src TB --- 2012-02-05 01:52:51 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Sun Feb 5 01:52:51 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 Sun Feb 5 01:54:04 UTC 2012 TB --- 2012-02-05 01:54:04 - cd /src/sys/mips/conf TB --- 2012-02-05 01:54:04 - /usr/sbin/config -m ALCHEMY TB --- 2012-02-05 01:54:04 - building ALCHEMY kernel TB --- 2012-02-05 01:54:04 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 01:54:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 01:54:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 01:54:04 - SRCCONF=/dev/null TB --- 2012-02-05 01:54:04 - TARGET=mips TB --- 2012-02-05 01:54:04 - TARGET_ARCH=mips TB --- 2012-02-05 01:54:04 - TZ=UTC TB --- 2012-02-05 01:54:04 - __MAKE_CONF=/dev/null TB --- 2012-02-05 01:54:04 - cd /src TB --- 2012-02-05 01:54:04 - /usr/bin/make -B buildkernel KERNCONF=ALCHEMY >>> Kernel build for ALCHEMY started on Sun Feb 5 01:54: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 -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=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/kern/link_elf_obj.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/alchemy/alchemy_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/alchemy/obio.c cc1: warnings being treated as errors /src/sys/mips/alchemy/obio.c:513: warning: pointer type mismatch in conditional expression *** Error code 1 Stop in /obj/mips/src/sys/ALCHEMY. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-05 01:55:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-05 01:55:12 - ERROR: failed to build ALCHEMY kernel TB --- 2012-02-05 01:55:12 - 1754.86 user 366.40 system 2343.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_2-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 02:49:48 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F1601065673; Sun, 5 Feb 2012 02:49:48 +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 CE0BF8FC0C; Sun, 5 Feb 2012 02:49:47 +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 q152nlNk068312; Sun, 5 Feb 2012 02:49:47 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q152nlD9068304; Sun, 5 Feb 2012 02:49:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Feb 2012 02:49:47 GMT Message-Id: <201202050249.q152nlD9068304@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 , , Precedence: bulk Cc: Subject: [releng_8_2 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 02:49:48 -0000 TB --- 2012-02-05 01:34:50 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 01:34:50 - starting RELENG_8_2 tinderbox run for powerpc/powerpc TB --- 2012-02-05 01:34:50 - cleaning the object tree TB --- 2012-02-05 01:35:22 - cvsupping the source tree TB --- 2012-02-05 01:35:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/powerpc/powerpc/supfile TB --- 2012-02-05 01:35:33 - building world TB --- 2012-02-05 01:35:33 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 01:35:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 01:35:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 01:35:33 - SRCCONF=/dev/null TB --- 2012-02-05 01:35:33 - TARGET=powerpc TB --- 2012-02-05 01:35:33 - TARGET_ARCH=powerpc TB --- 2012-02-05 01:35:33 - TZ=UTC TB --- 2012-02-05 01:35:33 - __MAKE_CONF=/dev/null TB --- 2012-02-05 01:35:33 - cd /src TB --- 2012-02-05 01:35:33 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 01:35:33 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 Sun Feb 5 02:21:50 UTC 2012 TB --- 2012-02-05 02:21:50 - generating LINT kernel config TB --- 2012-02-05 02:21:50 - cd /src/sys/powerpc/conf TB --- 2012-02-05 02:21:50 - /usr/bin/make -B LINT TB --- 2012-02-05 02:21:50 - cd /src/sys/powerpc/conf TB --- 2012-02-05 02:21:50 - /usr/sbin/config -m LINT TB --- 2012-02-05 02:21:50 - building LINT kernel TB --- 2012-02-05 02:21:50 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 02:21:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 02:21:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 02:21:50 - SRCCONF=/dev/null TB --- 2012-02-05 02:21:50 - TARGET=powerpc TB --- 2012-02-05 02:21:50 - TARGET_ARCH=powerpc TB --- 2012-02-05 02:21:50 - TZ=UTC TB --- 2012-02-05 02:21:50 - __MAKE_CONF=/dev/null TB --- 2012-02-05 02:21:50 - cd /src TB --- 2012-02-05 02:21:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 5 02:21:50 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 LINT completed on Sun Feb 5 02:37:21 UTC 2012 TB --- 2012-02-05 02:37:21 - cd /src/sys/powerpc/conf TB --- 2012-02-05 02:37:21 - /usr/sbin/config -m GENERIC TB --- 2012-02-05 02:37:21 - building GENERIC kernel TB --- 2012-02-05 02:37:21 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 02:37:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 02:37:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 02:37:21 - SRCCONF=/dev/null TB --- 2012-02-05 02:37:21 - TARGET=powerpc TB --- 2012-02-05 02:37:21 - TARGET_ARCH=powerpc TB --- 2012-02-05 02:37:21 - TZ=UTC TB --- 2012-02-05 02:37:21 - __MAKE_CONF=/dev/null TB --- 2012-02-05 02:37:21 - cd /src TB --- 2012-02-05 02:37:21 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 5 02:37:21 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 GENERIC completed on Sun Feb 5 02:47:44 UTC 2012 TB --- 2012-02-05 02:47:44 - cd /src/sys/powerpc/conf TB --- 2012-02-05 02:47:44 - /usr/sbin/config -m MPC85XX TB --- 2012-02-05 02:47:44 - building MPC85XX kernel TB --- 2012-02-05 02:47:44 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 02:47:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 02:47:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 02:47:44 - SRCCONF=/dev/null TB --- 2012-02-05 02:47:44 - TARGET=powerpc TB --- 2012-02-05 02:47:44 - TARGET_ARCH=powerpc TB --- 2012-02-05 02:47:44 - TZ=UTC TB --- 2012-02-05 02:47:44 - __MAKE_CONF=/dev/null TB --- 2012-02-05 02:47:44 - cd /src TB --- 2012-02-05 02:47:44 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Sun Feb 5 02:47:44 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 -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/clock.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/copyinout.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/interrupt.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/machdep.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/mp_cpudep.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/platform_bare.c /src/sys/powerpc/booke/platform_bare.c:82: error: expected '}' before ';' token *** Error code 1 Stop in /obj/powerpc/src/sys/MPC85XX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-05 02:49:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-05 02:49:47 - ERROR: failed to build MPC85XX kernel TB --- 2012-02-05 02:49:47 - 3555.51 user 572.76 system 4496.86 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_2-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 04:21:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48EE5106564A for ; Sun, 5 Feb 2012 04:21:43 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07FE88FC13 for ; Sun, 5 Feb 2012 04:21:42 +0000 (UTC) Received: by iaeo4 with SMTP id o4so10416415iae.13 for ; Sat, 04 Feb 2012 20:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=F5X2LlkIqvTuTXg5ytwsN22xluvHmGYw+cbs6KH/JLs=; b=rWpMJPlIL6dzMKpv2cM+7ao5cuPzSB2JK9EEseJtVuXFf6aQ+DsgxYyYualhBSMxse aABfkwUoYniZ2mCG+sTEKtn0cq6sWfsCtH+GOeBfbN85BV7hTxZ82eJQBDl/cUQz+0ua eDoC4xKLMvNywIIGaHnxVNFTlltH1G+Z0g6KA= Received: by 10.42.144.2 with SMTP id z2mr12151280icu.18.1328415702671; Sat, 04 Feb 2012 20:21:42 -0800 (PST) Received: from DataIX.net (adsl-99-181-135-57.dsl.klmzmi.sbcglobal.net. [99.181.135.57]) by mx.google.com with ESMTPS id l28sm19512862ibc.3.2012.02.04.20.21.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 20:21:41 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q154Lcf5010441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 23:21:38 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q154Lbld009663; Sat, 4 Feb 2012 23:21:37 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sat, 4 Feb 2012 23:21:37 -0500 From: Jason Hellenthal To: Warren Block Message-ID: <20120205042137.GB582@DataIX.net> References: <20120204184816.GA52504@icarus.home.lan> <20120204190702.GC37724@DataIX.net> <20120204230332.GA582@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ld: kernel.debug: Not enough room for program headers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 04:21:43 -0000 On Sat, Feb 04, 2012 at 05:18:18PM -0700, Warren Block wrote: > On Sat, 4 Feb 2012, Jason Hellenthal wrote: > > > On Sat, Feb 04, 2012 at 12:54:58PM -0700, Warren Block wrote: > >> But it still does (did) not build here with NOCCACHE set, so it's not > >> a ccache problem. > > > > I have seen ccache before run anyway even though .if statements are > > within make.conf to prevent it. It was something to do with make and > > friends built from world with ccache and after it would continue to use > > ccache regardless. This can be verified by watching the cache hits and > > misses during a compile with NOCCACHE set. Its tough to revert from > > this but involves removing ccache/distcc from the system. > > Interesting. Just for fun, I tried that, and the ccache stats didn't > change. Wierd. I dont know what to say to that and out of ideas at this point. Can say though that FreeBSD 8.2-STABLE #1 r230983M: Sat Feb 4 11:05:52 EST 2012 this one did compile cleanly here. usr/obj was clean when built and have build logs for every batch of 10 revisions for the past 6 months with no errors shown. -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 05:24:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BBBC106566C for ; Sun, 5 Feb 2012 05:24:07 +0000 (UTC) (envelope-from morgan.s.reed@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE5198FC08 for ; Sun, 5 Feb 2012 05:24:06 +0000 (UTC) Received: by pbdv10 with SMTP id v10so5132378pbd.13 for ; Sat, 04 Feb 2012 21:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=yZooNNViVMnsi+rqD8CfLtohi6ezE0fQFQ5q6MXiqKA=; b=tAdmuYHf7ZnDdz5bvET4uuueTARpaCuOAor2DuvkaXOF1lXuTTMZygSs6KWGIkWKP7 nSbM4E1kiIhoD905Vhxyh0bJfvIEB7KnMdhGuzZ+SCoBaLYp0Gws8QOaSD2IpwdPrdKw e+BORA2XBiFAGEYCGxT2E8TRsjZ2FCbUzc2v4= Received: by 10.68.232.103 with SMTP id tn7mr33801524pbc.74.1328417846260; Sat, 04 Feb 2012 20:57:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.65.226 with HTTP; Sat, 4 Feb 2012 20:57:06 -0800 (PST) From: Morgan Reed Date: Sun, 5 Feb 2012 15:57:06 +1100 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS panics on pool moved from OpenSolaris X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 05:24:07 -0000 Hi all, I'm experiencing an issue in migrating my NAS from OpenSolaris over to FreeBSD, I've tried both releng_8_2 and releng_9 I have similar issues in both cases. The pool is a RAID-Z pool comprising 4 1TB drives, it was originally created on OpenSolaris (not sure what version, 2010.09 maybe, it was one of the last ones prior to the Oracle acquisition), pool was a V14 pool, initially I built a FreeBSD-8.2 system to migrate the pool to, migrated it over OK, upgraded it from V14 to V15, but later testing revealed something wasn't happy, when listing certain directories (and even doing an ls -la at the root of the pool) resulted in a kernel panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other than that stock); panic: avl_find() succeeded inside avl_add() cpuid = 0 KDB: stack backtrace: #0 0x808e0d07 at kdb_backtrace+0x47 #1 0x808b1dc7 at panic+0x117 #2 0x862e6602 at avl_add+0x52 #3 0x8635c136 at zfs_fuid_table_load+0x1f6 #4 0x8635c3ee at zfs_fuid_init+0x14e #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 #6 0x8635c52d at zfs_fuid_map_id+0x2d #7 0x8635d56f at zfs_groupmember+0x2f #8 0x8636df0b at zfs_zaccess_aces_check+0x1db #9 0x8636377 at zfs_zaccess+0x57 #10 0x8636d6fb at zfs_zaccess_rwx+0x3b #11 0x86385f61 at zfs_freebsd_access+0xf1 #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 #13 0x809457cf at change_dir+0x5f #14 0x809467b1 at kern_chdir+0x81 #15 0x80946a22 at chdir+0x22 #16 0x808eca39 at syscallenter+0x329 #17 0x80be4e14 at syscall+0x34 Looks like something in the permissions structure was causing grief, tried running a scrub across the pool, didn't resolve the issue. After spending some time fighting with it I decided that it wasn't worth the effort, and I upgraded to FreeBSD-9.0 to see if that would assist (I normally avoid x.0 releases), once again pool imported fine, however I was still seeing similar panics, ran a scrub across the pool, still not happy, also upgraded the pool to v28 tried again, when that failed I scrubbed again but still no joy. As a matter of interest I booted an OpenIndiana live CD and tried copying the directories contents to another location, I am now able to list the directories. However there are still issues. The issue seems to have shifted slightly, stack trace from a recent panic is below (GENERIC kernel on 9.0-RELEASE); panic: avl_find() succeeded inside avl_add() cpuid = 0 KDB: stack backtrace: #0 0xc0a4b157 at kdb_backtrace+0x47 #1 0xc0a186b7 at panic+0x117 #2 0xc5a2d7b2 at avl_add+0x52 #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 #4 0xc5ac479e at zfs_fuid_init+0x14e #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 #6 0xc5ac48ed at zfs_fuid_map_id+0x2d #7 0xc5ac492f at zfs_groupmember+0x2f #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db #9 0xc5adc257 at zfs_zaccess+0xb7 #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 #11 0xc0d69322 at VOP_GETATTR_APV+0x42 #12 0xc0ab81c9 at vn_stat+0x79 #13 0xc0aaefdd at kern_statat_vnhook+0xfd #14 0xc0aaf1cc at kern_statat+0x3c #15 0xc0aaf156 at kern_lstat+0x36 #16 0xc0aaf1ff at sys_lstat+0x2f #17 0xc0d49315 at syscall+0x355 This time it appears to be related to some extended attribute(s), I can do an ls on one of the directories in question but an ls -la causes a panic, so it would seem that it's some attribute which is only shown in the long form of the ls output that is causing the issue. I've done some digging around via the magic of google and this seems to be a fairly common issue, but I've not found a solution for it (barring copying the data off, recreating the pool and restoring the data, I'd like to avoid this if at all possible. If I could determine what the problematic attribute was and a means to strip it (be that from FreeBSD or from an OpenIndiana liveCD) I think that will get me back up and running. If anybody can provide some suggestions as to what I may be able to do to resolve this issue in situ I would be very grateful. Thanks, Morgan From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 08:28:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A663D106566C for ; Sun, 5 Feb 2012 08:28:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7698FC0A for ; Sun, 5 Feb 2012 08:28:36 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q157vQFN032850 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 23:57:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2E36B5.3010308@freebsd.org> Date: Sat, 04 Feb 2012 23:58:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable References: <4F2CE485.5020909@freebsd.org> In-Reply-To: <4F2CE485.5020909@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: problem with kgdb and modules. (k)gdb expert needed. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 08:28:36 -0000 In 9.x ( can't check -current, but teh mailing list has a better readership) I'm still seeing this and have still not found any solution: possible reasons for the change may be: 1/ change to kgdb? 2/ change to the compiling toolset? 3/ change to the .mk files for compiling modules? any guidance would be appreciated.. The reason I can get away with using FreeBSD ar work is because I can debug modules well as in Linux this is generally a problem.. Now I see similar breakage in freebsd. (sigh)). I really don't know where to start looking for this.. Julian On 2/3/12 11:55 PM, Julian Elischer wrote: > so We upgraded our development machines from 8 stable to 9 stable. > and now kgdb can't debug inside modules. > > instead of getting anything useful, we just get: > > (kgdb) bt > #0 0xffffffff81814600 in ?? () from /boot/kernel/netgraph.ko > #1 0xffffffff81812d80 in ?? () from /boot/kernel/ng_socket.ko > #2 0x0000000000000037 in ?? () > #3 0x0000000000000002 in ?? () > #4 0xfffffe0007176aa0 in ?? () > #5 0xfffffe0007176aa0 in ?? () > #6 0xffffffff818134a0 in ?? () from /boot/kernel/ng_socket.ko > #7 0xffffffff81813960 in ?? () from /boot/kernel/ng_socket.ko > #8 0xffffff860fa3cad0 in ?? () > #9 0xffffffff808cc76e in socreate (dom=Variable "dom" is not > available. > ) at ../../../kern/uipc_socket.c:411 > > > > but stopping in the kernel itself, we DO see stuff.. > > (kgdb) break socreate > Breakpoint 1 at 0xffffffff808cc628: file > ../../../kern/uipc_socket.c, line 372. > (kgdb) c > Continuing. > > > > [New Thread 100198] > [Switching to Thread 100198] > > Breakpoint 1, socreate (dom=32, aso=0xffffff860fa3caf0, type=2, > proto=1, cred=0xfffffe000c63f600, td=0xfffffe011501a000) at > ../../../kern/uipc_socket.c:372 > 372 if (proto) > (kgdb) bt > #0 socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, > cred=0xfffffe000c63f600, td=0xfffffe011501a000) at > ../../../kern/uipc_socket.c:372 > #1 0xffffffff808cf710 in sys_socket (td=0xfffffe011501a000, > uap=0xffffff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 > #2 0xffffffff80b5599a in amd64_syscall (td=0xfffffe011501a000, > traced=0) at subr_syscall.c:131 > #3 0xffffffff80b40b57 in Xfast_syscall () at > ../../../amd64/amd64/exception.S:387 > #4 0x00000008011c82ac in ?? () > > > > etc. > > it looks as if modules no longer have stack frames compiled in. > does anyone know the culprit? > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 09:47:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DA5106566B for ; Sun, 5 Feb 2012 09:47:34 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 893CF8FC08 for ; Sun, 5 Feb 2012 09:47:34 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 2D2C661C; Sun, 5 Feb 2012 10:29:08 +0100 (CET) Date: Sun, 5 Feb 2012 10:27:54 +0100 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20120205092753.GA30033@garage.freebsd.pl> References: <86ipjvbglk.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <86ipjvbglk.fsf@kopusha.home.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Artem Kajalainen , freebsd-stable@freebsd.org Subject: Re: problems with hast X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 09:47:34 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2012 at 12:35:35AM +0200, Mikolaj Golub wrote: > Investigating, it looks after r226859, when 'async' mode was added, we ha= ve 2 > issues with synchronization from secondary to master (rather very rear ca= se > normally): >=20 > 1) When the synchronization from secondary to master is running and prima= ry > gets READ request, the request should be sent to the secondary but actual= ly it > is lost. As a result READ operation gets stuck. After the syncronization = is > complete the following READ requests, which now can be served by primary,= work > ok. >=20 > 2) In async mode, for syncronization requests, write_complete() function, > which sends G_GATE_CMD_DONE command to ggate, is called twice and the sec= ond > call fails. >=20 > Artem, did you run async mode? If you did then I suppose you observed the > second issue. Could you please try the attached patch? The analysis and fixes look good to me, please go ahead and commit (small nits below). > Index: sbin/hastd/primary.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 > --- sbin/hastd/primary.c (revision 230661) > +++ sbin/hastd/primary.c (working copy) > @@ -1255,7 +1255,7 @@ ggate_recv_thread(void *arg) > pjdlog_debug(2, > "ggate_recv: (%p) Moving request to the send queues.", hio); > refcount_init(&hio->hio_countdown, ncomps); > - for (ii =3D ncomp; ii < ncomps; ii++) > + for (ii =3D ncomp; ncomps !=3D 0; ncomps--, ii++) I'd prefer not to modify ncomps in the loop, maybe something like this: for (ii =3D ncomp; ii < ncomp + ncomps; ii++) > QUEUE_INSERT1(hio, send, ii); > } > /* NOTREACHED */ > @@ -1326,7 +1326,7 @@ local_send_thread(void *arg) > } else { > hio->hio_errors[ncomp] =3D 0; > if (hio->hio_replication =3D=3D > - HAST_REPLICATION_ASYNC) { > + HAST_REPLICATION_ASYNC && !ISSYNCREQ(hio)) { Could you move this additional check to separate line? Thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8uS5gACgkQForvXbEpPzRQPwCfXj+FSNO47V13eoRL1DJwuHWK zlcAoNBPW26Lz+CvQcs48kYXlFFVBarV =07jR -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 09:54:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF2A9106566B for ; Sun, 5 Feb 2012 09:54:34 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC818FC18 for ; Sun, 5 Feb 2012 09:54:33 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so5588569bkb.13 for ; Sun, 05 Feb 2012 01:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=yN2m2sxWZgFf5ybNv1MvNnWE9Z/q65GK423SY017EG4=; b=nGuYWizMrWA/ClQi28u7TkxhAzWOo2BPHQywzVeBmbpZxBvxtPnAPDjSVY7awkT5mU ljjGLbhGhGsCuyn8EZlLsfLzO2CCD0L1uEa+GcNFQ0ZoDKlKa9Dq1Tq7DZSB0C5R1BV6 KM5B+IEwFd4WPmMg7GJn54m6J2R9MpgywIzNg= Received: by 10.205.127.141 with SMTP id ha13mr6700403bkc.28.1328435672997; Sun, 05 Feb 2012 01:54:32 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id ew13sm34098385bkb.1.2012.02.05.01.54.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 01:54:31 -0800 (PST) From: Mikolaj Golub To: "Dewayne" References: X-Comment-To: Dewayne Sender: Mikolaj Golub Date: Sun, 05 Feb 2012 11:54:29 +0200 In-Reply-To: (Dewayne's message of "Sun, 5 Feb 2012 20:09:08 +1100") Message-ID: <861uq9a9m2.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: andrey@zonov.org, freebsd-stable@freebsd.org Subject: Re: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 09:54:34 -0000 On Sun, 5 Feb 2012 20:09:08 +1100 Dewayne wrote: D> Unfortunately 9.0 Stable fails to compile due to missing declaration of D> KERN_PROC_ENV in /usr/src/lib/libkvm/kvm_proc.c. csup'ed from today. D> Please refer to the following changes on 30-Jan-2012: D> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libkvm/kvm_proc.c.diff?r1=1.106.2.1;r2=1.106.2.2;f=h D> Compile error reads: D> cc -O2 -pipe -pipe -O2 -g0 -DSTRIP_FBSDID -UDEBUGGING -march=prescott -mtune=prescott -DLIBC_SCCS -I/usr/src/lib/libkvm D> -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes D> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libkvm/kvm_proc.c D> /usr/src/lib/libkvm/kvm_proc.c: In function 'kvm_argv': D> /usr/src/lib/libkvm/kvm_proc.c:663: error: 'KERN_PROC_ENV' undeclared (first use in this function) D> /usr/src/lib/libkvm/kvm_proc.c:663: error: (Each undeclared identifier is reported only once D> /usr/src/lib/libkvm/kvm_proc.c:663: error: for each function it appears in.) D> Am I the last person using i386 architecture? ;) I'm half joking. The D> buildworld completes successfully for architecture=amd64. And there should not be problems with i386 too. The error does not look like architecture specific. Could you please recheck your sources and building procedure and give more details if the error still exists. KERN_PROC_ENV is declared in sys/sys/sysctl.h, and this was MFCed in r230754, before the MFC lib/libkvm (r230780) you are referring to. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 10:18:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270591065672; Sun, 5 Feb 2012 10:18:05 +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 AB1718FC12; Sun, 5 Feb 2012 10:18:04 +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 q15AI3Xu074848; Sun, 5 Feb 2012 10:18:03 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q15AI33A074770; Sun, 5 Feb 2012 10:18:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Feb 2012 10:18:03 GMT Message-Id: <201202051018.q15AI33A074770@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 , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 10:18:05 -0000 TB --- 2012-02-05 09:29:08 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 09:29:08 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2012-02-05 09:29:08 - cleaning the object tree TB --- 2012-02-05 09:29:16 - cvsupping the source tree TB --- 2012-02-05 09:29:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2012-02-05 09:34:41 - building world TB --- 2012-02-05 09:34:41 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 09:34:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 09:34:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 09:34:41 - SRCCONF=/dev/null TB --- 2012-02-05 09:34:41 - TARGET=mips TB --- 2012-02-05 09:34:41 - TARGET_ARCH=mips TB --- 2012-02-05 09:34:41 - TZ=UTC TB --- 2012-02-05 09:34:41 - __MAKE_CONF=/dev/null TB --- 2012-02-05 09:34:41 - cd /src TB --- 2012-02-05 09:34:41 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 09:34:42 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 Sun Feb 5 10:11:13 UTC 2012 TB --- 2012-02-05 10:11:13 - cd /src/sys/mips/conf TB --- 2012-02-05 10:11:13 - /usr/sbin/config -m ADM5120 TB --- 2012-02-05 10:11:13 - building ADM5120 kernel TB --- 2012-02-05 10:11:13 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:11:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:11:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:11:13 - SRCCONF=/dev/null TB --- 2012-02-05 10:11:13 - TARGET=mips TB --- 2012-02-05 10:11:13 - TARGET_ARCH=mips TB --- 2012-02-05 10:11:13 - TZ=UTC TB --- 2012-02-05 10:11:13 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:11:13 - cd /src TB --- 2012-02-05 10:11:13 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Sun Feb 5 10:11: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 ADM5120 completed on Sun Feb 5 10:12:25 UTC 2012 TB --- 2012-02-05 10:12:25 - cd /src/sys/mips/conf TB --- 2012-02-05 10:12:25 - /usr/sbin/config -m IDT TB --- 2012-02-05 10:12:25 - building IDT kernel TB --- 2012-02-05 10:12:25 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:12:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:12:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:12:25 - SRCCONF=/dev/null TB --- 2012-02-05 10:12:25 - TARGET=mips TB --- 2012-02-05 10:12:25 - TARGET_ARCH=mips TB --- 2012-02-05 10:12:25 - TZ=UTC TB --- 2012-02-05 10:12:25 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:12:25 - cd /src TB --- 2012-02-05 10:12:25 - /usr/bin/make -B buildkernel KERNCONF=IDT >>> Kernel build for IDT started on Sun Feb 5 10:12: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 IDT completed on Sun Feb 5 10:14:01 UTC 2012 TB --- 2012-02-05 10:14:01 - cd /src/sys/mips/conf TB --- 2012-02-05 10:14:01 - /usr/sbin/config -m MALTA TB --- 2012-02-05 10:14:01 - building MALTA kernel TB --- 2012-02-05 10:14:01 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:14:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:14:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:14:01 - SRCCONF=/dev/null TB --- 2012-02-05 10:14:01 - TARGET=mips TB --- 2012-02-05 10:14:01 - TARGET_ARCH=mips TB --- 2012-02-05 10:14:01 - TZ=UTC TB --- 2012-02-05 10:14:01 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:14:01 - cd /src TB --- 2012-02-05 10:14:01 - /usr/bin/make -B buildkernel KERNCONF=MALTA >>> Kernel build for MALTA started on Sun Feb 5 10:14:01 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 MALTA completed on Sun Feb 5 10:15:29 UTC 2012 TB --- 2012-02-05 10:15:29 - cd /src/sys/mips/conf TB --- 2012-02-05 10:15:29 - /usr/sbin/config -m QEMU TB --- 2012-02-05 10:15:29 - building QEMU kernel TB --- 2012-02-05 10:15:29 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:15:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:15:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:15:29 - SRCCONF=/dev/null TB --- 2012-02-05 10:15:29 - TARGET=mips TB --- 2012-02-05 10:15:29 - TARGET_ARCH=mips TB --- 2012-02-05 10:15:29 - TZ=UTC TB --- 2012-02-05 10:15:29 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:15:29 - cd /src TB --- 2012-02-05 10:15:29 - /usr/bin/make -B buildkernel KERNCONF=QEMU >>> Kernel build for QEMU started on Sun Feb 5 10:15:29 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 QEMU completed on Sun Feb 5 10:16:42 UTC 2012 TB --- 2012-02-05 10:16:42 - cd /src/sys/mips/conf TB --- 2012-02-05 10:16:42 - /usr/sbin/config -m SENTRY5 TB --- 2012-02-05 10:16:42 - building SENTRY5 kernel TB --- 2012-02-05 10:16:42 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 10:16:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 10:16:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 10:16:42 - SRCCONF=/dev/null TB --- 2012-02-05 10:16:42 - TARGET=mips TB --- 2012-02-05 10:16:42 - TARGET_ARCH=mips TB --- 2012-02-05 10:16:42 - TZ=UTC TB --- 2012-02-05 10:16:42 - __MAKE_CONF=/dev/null TB --- 2012-02-05 10:16:42 - cd /src TB --- 2012-02-05 10:16:42 - /usr/bin/make -B buildkernel KERNCONF=SENTRY5 >>> Kernel build for SENTRY5 started on Sun Feb 5 10:16:43 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 -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 -EL -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/dev/cfe/cfe_console.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -EL -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/sentry5/s5_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -EL -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/dev/siba/siba.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -EL -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/dev/siba/siba_pcib.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -EL -fno-pic -mno-abicalls -G0 -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/sentry5/siba_cc.c In file included from /src/sys/mips/sentry5/siba_cc.c:58: /src/sys/dev/siba/sibavar.h:487: error: field 'sd_id' has incomplete type /src/sys/dev/siba/sibavar.h:526: error: 'SIBA_MAX_CORES' undeclared here (not in a function) *** Error code 1 Stop in /obj/mips/src/sys/SENTRY5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-05 10:18:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-05 10:18:03 - ERROR: failed to build SENTRY5 kernel TB --- 2012-02-05 10:18:03 - 1979.25 user 429.01 system 2934.67 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 11:05:54 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB6E106566C; Sun, 5 Feb 2012 11:05:54 +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 4C4908FC0A; Sun, 5 Feb 2012 11:05:52 +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 NAA12118; Sun, 05 Feb 2012 13:05:51 +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 1Rtzup-000HYn-6x; Sun, 05 Feb 2012 13:05:51 +0200 Message-ID: <4F2E628D.8050101@FreeBSD.org> Date: Sun, 05 Feb 2012 13:05:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer References: <4F2CE485.5020909@freebsd.org> <4F2E36B5.3010308@freebsd.org> In-Reply-To: <4F2E36B5.3010308@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , FreeBSD Current Subject: Re: problem with kgdb and modules. (k)gdb expert needed. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 11:05:54 -0000 on 05/02/2012 09:58 Julian Elischer said the following: > In 9.x ( can't check -current, but teh mailing list has a better readership) > > I'm still seeing this and have still not found any solution: > possible reasons for the change may be: > 1/ change to kgdb? > 2/ change to the compiling toolset? > 3/ change to the .mk files for compiling modules? > > any guidance would be appreciated.. > The reason I can get away with using FreeBSD ar work is because I can debug > modules well > as in Linux this is generally a problem.. Now I see similar breakage in > freebsd. (sigh)). > > I really don't know where to start looking for this.. Julian, just in case, how about some basic stuff like checking that the modules are indeed built with debugging support, that .symbols are installed and are accessible, that kgdb produces those messages: "Reading symbols", "Loaded symbols". > On 2/3/12 11:55 PM, Julian Elischer wrote: >> so We upgraded our development machines from 8 stable to 9 stable. and now >> kgdb can't debug inside modules. >> >> instead of getting anything useful, we just get: >> >> (kgdb) bt >> #0 0xffffffff81814600 in ?? () from /boot/kernel/netgraph.ko >> #1 0xffffffff81812d80 in ?? () from /boot/kernel/ng_socket.ko >> #2 0x0000000000000037 in ?? () >> #3 0x0000000000000002 in ?? () >> #4 0xfffffe0007176aa0 in ?? () >> #5 0xfffffe0007176aa0 in ?? () >> #6 0xffffffff818134a0 in ?? () from /boot/kernel/ng_socket.ko >> #7 0xffffffff81813960 in ?? () from /boot/kernel/ng_socket.ko >> #8 0xffffff860fa3cad0 in ?? () >> #9 0xffffffff808cc76e in socreate (dom=Variable "dom" is not available. >> ) at ../../../kern/uipc_socket.c:411 >> >> >> >> but stopping in the kernel itself, we DO see stuff.. >> >> (kgdb) break socreate >> Breakpoint 1 at 0xffffffff808cc628: file ../../../kern/uipc_socket.c, line 372. >> (kgdb) c >> Continuing. >> >> >> >> [New Thread 100198] >> [Switching to Thread 100198] >> >> Breakpoint 1, socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, >> cred=0xfffffe000c63f600, td=0xfffffe011501a000) at >> ../../../kern/uipc_socket.c:372 >> 372 if (proto) >> (kgdb) bt >> #0 socreate (dom=32, aso=0xffffff860fa3caf0, type=2, proto=1, >> cred=0xfffffe000c63f600, td=0xfffffe011501a000) at >> ../../../kern/uipc_socket.c:372 >> #1 0xffffffff808cf710 in sys_socket (td=0xfffffe011501a000, >> uap=0xffffff860fa3cbc0) at ../../../kern/uipc_syscalls.c:199 >> #2 0xffffffff80b5599a in amd64_syscall (td=0xfffffe011501a000, traced=0) at >> subr_syscall.c:131 >> #3 0xffffffff80b40b57 in Xfast_syscall () at >> ../../../amd64/amd64/exception.S:387 >> #4 0x00000008011c82ac in ?? () >> >> >> >> etc. >> >> it looks as if modules no longer have stack frames compiled in. >> does anyone know the culprit? >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 11:20:17 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 573D1106564A for ; Sun, 5 Feb 2012 11:20:17 +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 B0CA68FC13 for ; Sun, 5 Feb 2012 11:20:16 +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 NAA12221; Sun, 05 Feb 2012 13:20:13 +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 1Ru08j-000HZL-75; Sun, 05 Feb 2012 13:20:13 +0200 Message-ID: <4F2E65EC.60107@FreeBSD.org> Date: Sun, 05 Feb 2012 13:20:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Morgan Reed References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ZFS panics on pool moved from OpenSolaris X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 11:20:17 -0000 Please see this thread: http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html It looks like the same issue. The patch has been committed in head, not sure if it's MFCed. on 05/02/2012 06:57 Morgan Reed said the following: > Hi all, > > I'm experiencing an issue in migrating my NAS from OpenSolaris > over to FreeBSD, I've tried both releng_8_2 and releng_9 I have > similar issues in both cases. > > The pool is a RAID-Z pool comprising 4 1TB drives, it was originally > created on OpenSolaris (not sure what version, 2010.09 maybe, it was > one of the last ones prior to the Oracle acquisition), pool was a V14 > pool, initially I built a FreeBSD-8.2 system to migrate the pool to, > migrated it over OK, upgraded it from V14 to V15, but later testing > revealed something wasn't happy, when listing certain directories (and > even doing an ls -la at the root of the pool) resulted in a kernel > panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other > than that stock); > > panic: avl_find() succeeded inside avl_add() > cpuid = 0 > KDB: stack backtrace: > #0 0x808e0d07 at kdb_backtrace+0x47 > #1 0x808b1dc7 at panic+0x117 > #2 0x862e6602 at avl_add+0x52 > #3 0x8635c136 at zfs_fuid_table_load+0x1f6 > #4 0x8635c3ee at zfs_fuid_init+0x14e > #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 > #6 0x8635c52d at zfs_fuid_map_id+0x2d > #7 0x8635d56f at zfs_groupmember+0x2f > #8 0x8636df0b at zfs_zaccess_aces_check+0x1db > #9 0x8636377 at zfs_zaccess+0x57 > #10 0x8636d6fb at zfs_zaccess_rwx+0x3b > #11 0x86385f61 at zfs_freebsd_access+0xf1 > #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 > #13 0x809457cf at change_dir+0x5f > #14 0x809467b1 at kern_chdir+0x81 > #15 0x80946a22 at chdir+0x22 > #16 0x808eca39 at syscallenter+0x329 > #17 0x80be4e14 at syscall+0x34 > > Looks like something in the permissions structure was causing grief, > tried running a scrub across the pool, didn't resolve the issue. > > After spending some time fighting with it I decided that it wasn't > worth the effort, and I upgraded to FreeBSD-9.0 to see if that would > assist (I normally avoid x.0 releases), once again pool imported fine, > however I was still seeing similar panics, ran a scrub across the > pool, still not happy, also upgraded the pool to v28 tried again, when > that failed I scrubbed again but still no joy. > > As a matter of interest I booted an OpenIndiana live CD and tried > copying the directories contents to another location, I am now able to > list the directories. However there are still issues. > > The issue seems to have shifted slightly, stack trace from a recent > panic is below (GENERIC kernel on 9.0-RELEASE); > > panic: avl_find() succeeded inside avl_add() > cpuid = 0 > KDB: stack backtrace: > #0 0xc0a4b157 at kdb_backtrace+0x47 > #1 0xc0a186b7 at panic+0x117 > #2 0xc5a2d7b2 at avl_add+0x52 > #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 > #4 0xc5ac479e at zfs_fuid_init+0x14e > #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 > #6 0xc5ac48ed at zfs_fuid_map_id+0x2d > #7 0xc5ac492f at zfs_groupmember+0x2f > #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db > #9 0xc5adc257 at zfs_zaccess+0xb7 > #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 > #11 0xc0d69322 at VOP_GETATTR_APV+0x42 > #12 0xc0ab81c9 at vn_stat+0x79 > #13 0xc0aaefdd at kern_statat_vnhook+0xfd > #14 0xc0aaf1cc at kern_statat+0x3c > #15 0xc0aaf156 at kern_lstat+0x36 > #16 0xc0aaf1ff at sys_lstat+0x2f > #17 0xc0d49315 at syscall+0x355 > > This time it appears to be related to some extended attribute(s), I > can do an ls on one of the directories in question but an ls -la > causes a panic, so it would seem that it's some attribute which is > only shown in the long form of the ls output that is causing the > issue. > > I've done some digging around via the magic of google and this seems > to be a fairly common issue, but I've not found a solution for it > (barring copying the data off, recreating the pool and restoring the > data, I'd like to avoid this if at all possible. > > If I could determine what the problematic attribute was and a means to > strip it (be that from FreeBSD or from an OpenIndiana liveCD) I think > that will get me back up and running. > > If anybody can provide some suggestions as to what I may be able to do > to resolve this issue in situ I would be very grateful. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 11:50:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192801065672 for ; Sun, 5 Feb 2012 11:50:15 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD6918FC1B for ; Sun, 5 Feb 2012 11:50:14 +0000 (UTC) Received: by eekb47 with SMTP id b47so2146504eek.13 for ; Sun, 05 Feb 2012 03:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=rLXGCWsTbBggwcoBlvbLuwmQfF58nmB1Xab+Wq0OluI=; b=QN/3Jwvo17hHcoguV3c+kd9yXDxVEdcky1Lp4GeDfacvG6evY1wuQ4d0LyqRTymPox nFtu8fNm+IzLNm0qjqA9aO3nmwNoL9yZo9VWc8NqhzQ5Rbe7HlQfedJiDUGGPw5AgCdm SAZmzsB0VutwMG0cpRoX7jyvxtORYQ4+sSw/Q= MIME-Version: 1.0 Received: by 10.213.98.71 with SMTP id p7mr730348ebn.101.1328441007392; Sun, 05 Feb 2012 03:23:27 -0800 (PST) Received: by 10.213.5.8 with HTTP; Sun, 5 Feb 2012 03:23:27 -0800 (PST) Date: Sun, 5 Feb 2012 12:23:27 +0100 Message-ID: From: Olav Gjerde To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Why do I get 32767 id mapping when using NSFv4 with LDAP? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 11:50:15 -0000 I've configured a server with 9-STABLE compiled late january. I've played a bit with NFSv4 and it works great. Except that I can't get it to play nice with OpenLDAP. If I mirror the passwd and group files between the client and server the mapping is correct. If I add pam_ldap to the /etc/pam.d/system file it works fine on both systems when I browse local files, however NFSv4 map both the uid and gid as 32767. The files should belong to user olav with uid and gid 1001. Do anyone how I can get this to work properly? At least what I should look into? Do I need kerberos? From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 12:26:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE011065673; Sun, 5 Feb 2012 12:26:06 +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 C9CBC8FC0C; Sun, 5 Feb 2012 12:26:05 +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 q15CQ5WV042903; Sun, 5 Feb 2012 12:26:05 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q15CQ5kc042886; Sun, 5 Feb 2012 12:26:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Feb 2012 12:26:05 GMT Message-Id: <201202051226.q15CQ5kc042886@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 , , Precedence: bulk Cc: Subject: [releng_8_2 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 12:26:06 -0000 TB --- 2012-02-05 11:47:04 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 11:47:04 - starting RELENG_8_2 tinderbox run for mips/mips TB --- 2012-02-05 11:47:04 - cleaning the object tree TB --- 2012-02-05 11:47:12 - cvsupping the source tree TB --- 2012-02-05 11:47:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/mips/mips/supfile TB --- 2012-02-05 11:47:27 - building world TB --- 2012-02-05 11:47:27 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 11:47:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 11:47:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 11:47:27 - SRCCONF=/dev/null TB --- 2012-02-05 11:47:27 - TARGET=mips TB --- 2012-02-05 11:47:27 - TARGET_ARCH=mips TB --- 2012-02-05 11:47:27 - TZ=UTC TB --- 2012-02-05 11:47:27 - __MAKE_CONF=/dev/null TB --- 2012-02-05 11:47:27 - cd /src TB --- 2012-02-05 11:47:27 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 11:47:27 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 Sun Feb 5 12:23:42 UTC 2012 TB --- 2012-02-05 12:23:42 - cd /src/sys/mips/conf TB --- 2012-02-05 12:23:42 - /usr/sbin/config -m ADM5120 TB --- 2012-02-05 12:23:42 - building ADM5120 kernel TB --- 2012-02-05 12:23:42 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:23:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:23:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:23:42 - SRCCONF=/dev/null TB --- 2012-02-05 12:23:42 - TARGET=mips TB --- 2012-02-05 12:23:42 - TARGET_ARCH=mips TB --- 2012-02-05 12:23:42 - TZ=UTC TB --- 2012-02-05 12:23:42 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:23:42 - cd /src TB --- 2012-02-05 12:23:42 - /usr/bin/make -B buildkernel KERNCONF=ADM5120 >>> Kernel build for ADM5120 started on Sun Feb 5 12:23: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 ADM5120 completed on Sun Feb 5 12:24:55 UTC 2012 TB --- 2012-02-05 12:24:55 - cd /src/sys/mips/conf TB --- 2012-02-05 12:24:55 - /usr/sbin/config -m ALCHEMY TB --- 2012-02-05 12:24:55 - building ALCHEMY kernel TB --- 2012-02-05 12:24:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:24:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:24:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:24:55 - SRCCONF=/dev/null TB --- 2012-02-05 12:24:55 - TARGET=mips TB --- 2012-02-05 12:24:55 - TARGET_ARCH=mips TB --- 2012-02-05 12:24:55 - TZ=UTC TB --- 2012-02-05 12:24:55 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:24:55 - cd /src TB --- 2012-02-05 12:24:55 - /usr/bin/make -B buildkernel KERNCONF=ALCHEMY >>> Kernel build for ALCHEMY started on Sun Feb 5 12:24:56 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 -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=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/kern/link_elf_obj.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/alchemy/alchemy_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1000 --param large-function-growth=100000 -EL -fno-pic -mno-abicalls -G0 -EL -march=mips32 -msoft-float -mno-dsp -ffreestanding -Werror /src/sys/mips/alchemy/obio.c cc1: warnings being treated as errors /src/sys/mips/alchemy/obio.c:513: warning: pointer type mismatch in conditional expression *** Error code 1 Stop in /obj/mips/src/sys/ALCHEMY. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-05 12:26:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-05 12:26:05 - ERROR: failed to build ALCHEMY kernel TB --- 2012-02-05 12:26:05 - 1749.08 user 370.71 system 2340.56 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_2-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 13:28:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6F69106566C; Sun, 5 Feb 2012 13:28: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 90B318FC0C; Sun, 5 Feb 2012 13:28: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 q15DSLTc097034; Sun, 5 Feb 2012 13:28:21 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q15DSKgo096855; Sun, 5 Feb 2012 13:28:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 5 Feb 2012 13:28:20 GMT Message-Id: <201202051328.q15DSKgo096855@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 , , Precedence: bulk Cc: Subject: [releng_8_2 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 13:28:22 -0000 TB --- 2012-02-05 12:12:26 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-05 12:12:26 - starting RELENG_8_2 tinderbox run for powerpc/powerpc TB --- 2012-02-05 12:12:26 - cleaning the object tree TB --- 2012-02-05 12:12:57 - cvsupping the source tree TB --- 2012-02-05 12:12:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_2/powerpc/powerpc/supfile TB --- 2012-02-05 12:14:04 - building world TB --- 2012-02-05 12:14:04 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 12:14:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 12:14:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 12:14:04 - SRCCONF=/dev/null TB --- 2012-02-05 12:14:04 - TARGET=powerpc TB --- 2012-02-05 12:14:04 - TARGET_ARCH=powerpc TB --- 2012-02-05 12:14:04 - TZ=UTC TB --- 2012-02-05 12:14:04 - __MAKE_CONF=/dev/null TB --- 2012-02-05 12:14:04 - cd /src TB --- 2012-02-05 12:14:04 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 5 12:14:04 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 Sun Feb 5 13:00:19 UTC 2012 TB --- 2012-02-05 13:00:19 - generating LINT kernel config TB --- 2012-02-05 13:00:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:00:19 - /usr/bin/make -B LINT TB --- 2012-02-05 13:00:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:00:19 - /usr/sbin/config -m LINT TB --- 2012-02-05 13:00:19 - building LINT kernel TB --- 2012-02-05 13:00:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:00:19 - SRCCONF=/dev/null TB --- 2012-02-05 13:00:19 - TARGET=powerpc TB --- 2012-02-05 13:00:19 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:00:19 - TZ=UTC TB --- 2012-02-05 13:00:19 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:00:19 - cd /src TB --- 2012-02-05 13:00:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 5 13:00:19 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 LINT completed on Sun Feb 5 13:15:46 UTC 2012 TB --- 2012-02-05 13:15:46 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:15:46 - /usr/sbin/config -m GENERIC TB --- 2012-02-05 13:15:46 - building GENERIC kernel TB --- 2012-02-05 13:15:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:15:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:15:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:15:46 - SRCCONF=/dev/null TB --- 2012-02-05 13:15:46 - TARGET=powerpc TB --- 2012-02-05 13:15:46 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:15:46 - TZ=UTC TB --- 2012-02-05 13:15:46 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:15:46 - cd /src TB --- 2012-02-05 13:15:46 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Feb 5 13:15: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 GENERIC completed on Sun Feb 5 13:26:19 UTC 2012 TB --- 2012-02-05 13:26:19 - cd /src/sys/powerpc/conf TB --- 2012-02-05 13:26:19 - /usr/sbin/config -m MPC85XX TB --- 2012-02-05 13:26:19 - building MPC85XX kernel TB --- 2012-02-05 13:26:19 - CROSS_BUILD_TESTING=YES TB --- 2012-02-05 13:26:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-05 13:26:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-05 13:26:19 - SRCCONF=/dev/null TB --- 2012-02-05 13:26:19 - TARGET=powerpc TB --- 2012-02-05 13:26:19 - TARGET_ARCH=powerpc TB --- 2012-02-05 13:26:19 - TZ=UTC TB --- 2012-02-05 13:26:19 - __MAKE_CONF=/dev/null TB --- 2012-02-05 13:26:19 - cd /src TB --- 2012-02-05 13:26:19 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Sun Feb 5 13:26:19 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 -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/clock.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/copyinout.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/interrupt.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/machdep.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/mp_cpudep.c cc -c -O -pipe -std=c99 -Wa,-me500 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/booke/platform_bare.c /src/sys/powerpc/booke/platform_bare.c:82: error: expected '}' before ';' token *** Error code 1 Stop in /obj/powerpc/src/sys/MPC85XX. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-05 13:28:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-05 13:28:20 - ERROR: failed to build MPC85XX kernel TB --- 2012-02-05 13:28:20 - 3555.28 user 577.31 system 4553.87 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_2-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 13:43:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B5C1065670; Sun, 5 Feb 2012 13:43:23 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFE98FC12; Sun, 5 Feb 2012 13:43:22 +0000 (UTC) Received: from nskntcmgw07p ([61.9.169.167]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20120205134321.WQSQ25972.nskntmtas01p.mx.bigpond.com@nskntcmgw07p>; Sun, 5 Feb 2012 13:43:21 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.204]) by nskntcmgw07p with BigPond Outbound id WDjL1i0054QfL3601DjL8b; Sun, 05 Feb 2012 13:43:21 +0000 X-Authority-Analysis: v=2.0 cv=A4LuztqG c=1 sm=1 a=3gUU17yAEl4T7pnfkUDLuw==:17 a=OJ00FmT28VQA:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=VlaoTGg91ZV2_1jiuZ8A:9 a=620n_tYgBPI_RJWyBSYA:7 a=CjuIK1q_8ugA:10 a=3gUU17yAEl4T7pnfkUDLuw==:117 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q15Dfhg0071931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Feb 2012 00:41:44 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Mikolaj Golub'" References: <861uq9a9m2.fsf@kopusha.home.net> Date: Mon, 6 Feb 2012 00:41:41 +1100 Message-ID: <948CB7705C4A40AF8694F78A4923CECC@white> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <861uq9a9m2.fsf@kopusha.home.net> Thread-Index: Aczj7C/Dqn7eJa0mQ1KxXCKn45VEmAAFrIvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: andrey@zonov.org, freebsd-stable@freebsd.org Subject: RE: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 13:43:23 -0000 Hi Mikolaj, As part of the process, I delete all logs, audit trails of the build, /usr/obj/* and the various DESTDIR's that have been set. The build process is from a single /usr/src but I do modify MAKEOBJDIRPREFIX, DESTDIR and various WITHOUT_ statements through variable switches in {make,src}.conf. And you're right, in the sources, KERN_PROC_ENV is defined. # ls -lrth /usr/src/sys/sys/sysctl.h -rw-r--r-- 1 root wheel 30k Jan 30 19:56 /usr/src/sys/sys/sysctl.h # grep KERN_PROC_ENV /usr/src/sys/sys/sysctl.h #define KERN_PROC_ENV 35 /* get environment */ The clue seems to be in here # ls -lrth /usr/src/sys/sys/ |tail -n 12 -rw-r--r-- 1 root wheel 4.2k Jan 16 19:10 mchain.h -rw-r--r-- 1 root wheel 8.2k Jan 16 19:10 iconv.h -rw-r--r-- 1 root wheel 6.2k Jan 23 22:24 umtx.h -rw-r--r-- 1 root wheel 31k Jan 23 22:24 pmc.h -rw-r--r-- 1 root wheel 11k Jan 23 22:24 param.h # The following aren't copied into /usr/include -rw-r--r-- 1 root wheel 30k Jan 30 06:24 mount.h -rw-r--r-- 1 root wheel 30k Jan 30 19:56 sysctl.h -rw-r--r-- 1 root wheel 5.6k Jan 30 19:56 resourcevar.h -rw-r--r-- 1 root wheel 39k Jan 30 19:56 proc.h -rw-r--r-- 1 root wheel 15k Feb 4 15:19 mutex.h -rw-r--r-- 1 root wheel 40k Feb 4 15:19 elf_common.h -rw-r--r-- 1 root wheel 11k Feb 4 15:19 sx.h # ls -lrth /usr/include/sys/ | tail -n 12 -r--r--r-- 1 root wheel 11k Jan 9 00:05 syscallsubr.h -r--r--r-- 1 root wheel 11k Jan 9 00:05 syscall.h -r--r--r-- 1 root wheel 5.0k Jan 9 00:05 resource.h -r--r--r-- 1 root wheel 10k Jan 9 00:05 file.h -r--r--r-- 1 root wheel 10k Jan 9 00:05 fcntl.h -r--r--r-- 1 root wheel 6.4k Jan 13 10:32 taskqueue.h -r--r--r-- 1 root wheel 28k Jan 14 17:54 vnode.h -r--r--r-- 1 root wheel 8.2k Jan 16 19:38 iconv.h -r--r--r-- 1 root wheel 4.2k Jan 16 19:38 mchain.h -r--r--r-- 1 root wheel 6.2k Jan 23 23:09 umtx.h -r--r--r-- 1 root wheel 31k Jan 23 23:09 pmc.h -r--r--r-- 1 root wheel 11k Jan 23 23:09 param.h # I'm looking into why this is the last file copied. I'm reviewing my build logs to ascertain why files after param.h aren't being copied from /usr/src/sys into /usr/include Its after midnight so I'll continue investigating tomorrow, clearly its going to take some time. The buildworld succeeding only for amd64/K8-sse is the really confusing part. So far, I note that log files each contain: ... if [ -L /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys ]; then rm -f /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys; fi ... cd /usr/src/include/../sys/sys; for h in *.h; do ln -fs ../../../sys/sys/$h /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys; done ... Which seems normal. And yes, grep KERN_PROC_ENV /usr/obj/prod/900/P/PRESCOTT/usr/src/tmp/usr/include/sys/sysctl.h is defined Kind regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 13:48:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4559C106566C for ; Sun, 5 Feb 2012 13:48:10 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwqsrv03p.mx.bigpond.com (nschwqsrv03p.mx.bigpond.com [61.9.189.237]) by mx1.freebsd.org (Postfix) with ESMTP id D47658FC0C for ; Sun, 5 Feb 2012 13:48:09 +0000 (UTC) Received: from nschwotgx04p.mx.bigpond.com ([58.172.112.204]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20120205091020.JNDH22122.nschwmtas02p.mx.bigpond.com@nschwotgx04p.mx.bigpond.com>; Sun, 5 Feb 2012 09:10:20 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.204]) by nschwotgx04p.mx.bigpond.com with ESMTP id <20120205091019.LMPP1687.nschwotgx04p.mx.bigpond.com@hermes.heuristicsystems.com.au>; Sun, 5 Feb 2012 09:10:19 +0000 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q1599AWF060541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 5 Feb 2012 20:09:10 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne" To: , Date: Sun, 5 Feb 2012 20:09:08 +1100 Organization: Heuristic Systems Pty Ltd Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczj5dFONJFaj02ISn6n5kqrgvQ7cg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-SIH-MSG-ID: rRw0EtzuXAD+xDFw3jbvZAR+xA/uo3c75JcMWtRmtxsZTljBucXOII/9Y9UUk5720S5MPxCEPmsiY7zmXY7TiA== Cc: freebsd-stable@freebsd.org Subject: 9.0 Stable unable to buildworld, missing KERN_PROC_ENV in kvm_proc.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 13:48:10 -0000 Unfortunately 9.0 Stable fails to compile due to missing declaration of KERN_PROC_ENV in /usr/src/lib/libkvm/kvm_proc.c. csup'ed from today. Please refer to the following changes on 30-Jan-2012: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libkvm/kvm_proc.c.diff?r1=1.106.2.1;r2=1.106.2.2;f=h Compile error reads: cc -O2 -pipe -pipe -O2 -g0 -DSTRIP_FBSDID -UDEBUGGING -march=prescott -mtune=prescott -DLIBC_SCCS -I/usr/src/lib/libkvm -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libkvm/kvm_proc.c /usr/src/lib/libkvm/kvm_proc.c: In function 'kvm_argv': /usr/src/lib/libkvm/kvm_proc.c:663: error: 'KERN_PROC_ENV' undeclared (first use in this function) /usr/src/lib/libkvm/kvm_proc.c:663: error: (Each undeclared identifier is reported only once /usr/src/lib/libkvm/kvm_proc.c:663: error: for each function it appears in.) Am I the last person using i386 architecture? ;) I'm half joking. The buildworld completes successfully for architecture=amd64. Regards, Dewayne From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 15:32:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE541065672; Sun, 5 Feb 2012 15:32:29 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E83468FC12; Sun, 5 Feb 2012 15:32:28 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so5721442bkb.13 for ; Sun, 05 Feb 2012 07:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=zqeVPJGbOdHymGJj8oVUUw3Q60//lsM/94lN24LPqeU=; b=xOjbSzYvccVDkjAAy+zIDpI0AQ+6e+A8p+tx3rIQJVC1NuI2S3uM8QynVGqn2pJafp w7OwJvrYNKoDfrkW1xW07xc0eiIs2jcdYfXiDMIu5wDFqaM/GEiMa9BFXKBLBUp9s5o3 gmfFD1pJcl9YsO5GRDFLlfAUsNB9niMxBrizE= Received: by 10.204.152.75 with SMTP id f11mr6720477bkw.127.1328455948037; Sun, 05 Feb 2012 07:32:28 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id o26sm36199939bko.14.2012.02.05.07.32.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 07:32:26 -0800 (PST) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <86ipjvbglk.fsf@kopusha.home.net> <20120205092753.GA30033@garage.freebsd.pl> X-Comment-To: Pawel Jakub Dawidek Sender: Mikolaj Golub Date: Sun, 05 Feb 2012 17:32:23 +0200 In-Reply-To: <20120205092753.GA30033@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Sun, 5 Feb 2012 10:27:54 +0100") Message-ID: <86pqdt8feg.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Artem Kajalainen , freebsd-stable@freebsd.org Subject: Re: problems with hast X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 15:32:29 -0000 On Sun, 5 Feb 2012 10:27:54 +0100 Pawel Jakub Dawidek wrote: PJD> The analysis and fixes look good to me, please go ahead and commit PJD> (small nits below). Thanks. Committed. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 15:49:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B046106566B for ; Sun, 5 Feb 2012 15:49:02 +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 BCD8E8FC12 for ; Sun, 5 Feb 2012 15:49:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABukLk+DaFvO/2dsb2JhbABEhQurKoFyAQEFI1YbGAICDRkCWQavTJB2gS+KNQEFAgIdAwQBDgEIBQMDCQ0SgnECBgUCBAwGDQMJAgJzGQIEgiOBFgSIRIxkknk X-IronPort-AV: E=Sophos;i="4.73,365,1325480400"; d="scan'208";a="155128212" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2012 10:49:00 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9AC20B3F37; Sun, 5 Feb 2012 10:49:00 -0500 (EST) Date: Sun, 5 Feb 2012 10:49:00 -0500 (EST) From: Rick Macklem To: Olav Gjerde Message-ID: <1623006267.784457.1328456940617.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org Subject: Re: Why do I get 32767 id mapping when using NSFv4 with LDAP? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 15:49:02 -0000 Olav Gjerde wrote: > I've configured a server with 9-STABLE compiled late january. I've > played a bit with NFSv4 and it works great. Except that I can't get it > to play nice with OpenLDAP. If I mirror the passwd and group files > between the client and server the mapping is correct. If I add > pam_ldap to the /etc/pam.d/system file it works fine on both systems > when I browse local files, however NFSv4 map both the uid and gid as > 32767. The files should belong to user olav with uid and gid 1001. Do > anyone how I can get this to work properly? At least what I should > look into? Do I need kerberos? Nope, you shouldn't need Kerberos. The 32767 is what you get when it can't find a mapping. All nfsuserd does is call the library functions like getpwuid()/getpwname() to get a mapping for a uid when it gets an upcall from the kernel asking for a mapping for that uid/user. I've never used ldap, so I can't help with that except to suggest that, for some reason, the libc calls aren't working. You can run nfsuserd with "-verbose" and it will log all mapping attempts. (Maybe what it logs in /var/log/messages will give you a hint.) You can also "tcpdump -s 0 -w xxx host " and then look at "xxx" in wireshark. Then, look in the Getattr reply and see what the Owner and Owner_group replies look like. This will tell you if it is the server that isn't doing the mappings or the client after it receives the name. (For Getattr, the server should translate uid/gid to @ and then the client should turn that back into the same uid/gid.) Good luck with it, rick From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 18:59:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16F1106566C for ; Sun, 5 Feb 2012 18:59:16 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from orlith.tzim.net (orlith.tzim.net [IPv6:2001:41d0:2:1d32::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF808FC08 for ; Sun, 5 Feb 2012 18:59:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tzim.net; s=A; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=7YGsRdbTB1nmNeHeRfHwtgtpBpZRtsysOvxIexAWhpw=; b=wpEOQHMan0nB+K1xgC4pdpXZ0SF7KusYJF75JVmSsWDuqMG1lL3hkhSx92WI0oQ07VS0ndiu7eEBkP39j6BuzhbkFPoZkACMAApGfjXXiKk187o7cSR+iulJs22TUtRd; Received: from 12rf.tzim.net ([82.232.60.244] helo=[10.1.0.10]) by orlith.tzim.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ru7Iv-0000FK-6W for freebsd-stable@freebsd.org; Sun, 05 Feb 2012 19:59:13 +0100 Message-ID: <4F2ED17E.6010105@tzim.net> Date: Sun, 05 Feb 2012 19:59:10 +0100 From: Arnaud Houdelette User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: tzim@tzim.net Subject: Re: DNSSec on FreeBSD 9.0-RELEASE causes CPU 100% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 18:59:16 -0000 Hi Just FYI, I just encountered the same issue with bind and DNSSEC. Bind was using 100% CPU, even after a restart. Turns out that were a key in the managed-keys folder which was unreadable by bind (permission issue). Hope It can help. Arnaud Houdelette. On 05/01/2012 01:24, George Kontostanos wrote: > Greetings everyone, > > I was testing DNSSec resolution on BIND 9.8.1-P1 by adding the > following options: > > options { > ... > dnssec-enable yes; > dnssec-validation auto; > ... > }; > > Unfortunately immediately after named is restarted one CPU reaches > 100% utilization. > > CPU: 30.1% user, 0.0% nice, 23.6% system, 0.0% interrupt, 46.3% idle > Mem: 111M Active, 14M Inact, 255M Wired, 852K Cache, 3558M Free > Swap: 2048M Total, 2048M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 2178 bind 5 20 0 51364K 13828K kqread 0 0:17 84.18% named > > The system is running GENERIC kernel, and it not an authoritative DNS. > Mainly used for testing purposes. My logs don't show anything strange: > > Jan 5 02:03:55 hp named[2178]: starting BIND 9.8.1-P1 -t /var/named -u bind > Jan 5 02:03:55 hp named[2178]: built with '--prefix=/usr' > '--infodir=/usr/share/info' '--mandir=/usr/share/man' > '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' > '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' > '--without-libxml2' > Jan 5 02:03:55 hp named[2178]: using built-in root key for view _default > Jan 5 02:03:55 hp named[2178]: command channel listening on 127.0.0.1#953 > Jan 5 02:03:55 hp named[2178]: command channel listening on ::1#953 > an 5 02:03:55 hp named[2178]: running > > Anybody has come across a similar behavior ? > > Cheers, > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 5 23:23:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E30C106566B; Sun, 5 Feb 2012 23:23:26 +0000 (UTC) (envelope-from morgan.s.reed@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0CC8FC15; Sun, 5 Feb 2012 23:23:25 +0000 (UTC) Received: by pbdv10 with SMTP id v10so5698220pbd.13 for ; Sun, 05 Feb 2012 15:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=X1nX0Pyu6nRVvzl5VkC+gvSxKSR9lgNxlTEBgVyywHY=; b=Dukq5R4vUC8Uhvb6dNMfBJna3befs3YYF7OUmPSrsnmOHNHT2bCT7RgHgJB/eOW98p JusEdGGGCmEbrTJiGBCrjRIYuOwXMxmBQMTNZttfNRuYAM8knSPes9kQvRyx2amda6+7 S4jSn5p7tV8ZH5o0vEqWeYL19xS0i0B9ejmQk= Received: by 10.68.135.137 with SMTP id ps9mr41821503pbb.40.1328484205452; Sun, 05 Feb 2012 15:23:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.65.226 with HTTP; Sun, 5 Feb 2012 15:23:05 -0800 (PST) In-Reply-To: <4F2E65EC.60107@FreeBSD.org> References: <4F2E65EC.60107@FreeBSD.org> From: Morgan Reed Date: Mon, 6 Feb 2012 10:23:05 +1100 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS panics on pool moved from OpenSolaris X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 23:23:26 -0000 Hi Andriy, Thanks for that, the patch has significantly improved matters, I'm now able to run a find across part of the drive without issue, however I'm still seeing the panics on some directories, stack trace below; panic: avl_find() succeeded inside avl_add() cpuid =3D 0 KDB: stack backtrace: #0 0xc0a4b157 at kdb_backtrace+0x47 #1 0xc0a186b7 at panic+0x117 #2 0xc5a2d7b2 at avl_add+0x52 #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 #4 0xc5ac479e at zfs_fuid_init+0x14e #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 #6 0xc5ac48ed at zfs_fuid_map_id+0x2d #7 0xc5ac492f at zfs_groupmember+0x2f #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db #9 0xc5adc257 at zfs_zaccess+0xb7 #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 #11 0xc0d69322 at VOP_GETATTR_APV+0x42 #12 0xc0ab81c9 at vn_stat+0x79 #13 0xc0aaefdd at kern_statat_vnhook+0xfd #14 0xc0aaf1cc at kern_statat+0x3c #15 0xc0aaf156 at kern_lstat+0x36 #16 0xc0aaf1ff at sys_lstat+0x2f #17 0xc0d49315 at syscall+0x355 Same trace as previously on 9.0. I'm following your advice to Karli and throwing some printfs into zfs_fuid_table_load, I'll advise if I find anything enlightening. Thanks, Morgan On Sun, Feb 5, 2012 at 22:20, Andriy Gapon wrote: > > Please see this thread: > http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html > It looks like the same issue. > The patch has been committed in head, not sure if it's MFCed. > > on 05/02/2012 06:57 Morgan Reed said the following: >> Hi all, >> >> =A0 =A0 =A0I'm experiencing an issue in migrating my NAS from OpenSolari= s >> over to FreeBSD, I've tried both releng_8_2 and releng_9 I have >> similar issues in both cases. >> >> The pool is a RAID-Z pool comprising 4 1TB drives, it was originally >> created on OpenSolaris (not sure what version, 2010.09 maybe, it was >> one of the last ones prior to the Oracle acquisition), pool was a V14 >> pool, initially I built a FreeBSD-8.2 system to migrate the pool to, >> migrated it over OK, upgraded it from V14 to V15, but later testing >> revealed something wasn't happy, when listing certain directories (and >> even doing an ls -la at the root of the pool) resulted in a kernel >> panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other >> than that stock); >> >> panic: avl_find() =A0succeeded inside avl_add() >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0x808e0d07 at kdb_backtrace+0x47 >> #1 0x808b1dc7 at panic+0x117 >> #2 0x862e6602 at avl_add+0x52 >> #3 0x8635c136 at zfs_fuid_table_load+0x1f6 >> #4 0x8635c3ee at zfs_fuid_init+0x14e >> #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 >> #6 0x8635c52d at zfs_fuid_map_id+0x2d >> #7 0x8635d56f at zfs_groupmember+0x2f >> #8 0x8636df0b at zfs_zaccess_aces_check+0x1db >> #9 0x8636377 at zfs_zaccess+0x57 >> #10 0x8636d6fb at zfs_zaccess_rwx+0x3b >> #11 0x86385f61 at zfs_freebsd_access+0xf1 >> #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 >> #13 0x809457cf at change_dir+0x5f >> #14 0x809467b1 at kern_chdir+0x81 >> #15 0x80946a22 at chdir+0x22 >> #16 0x808eca39 at syscallenter+0x329 >> #17 0x80be4e14 at syscall+0x34 >> >> Looks like something in the permissions structure was causing grief, >> tried running a scrub across the pool, didn't resolve the issue. >> >> After spending some time fighting with it I decided that it wasn't >> worth the effort, and I upgraded to FreeBSD-9.0 to see if that would >> assist (I normally avoid x.0 releases), once again pool imported fine, >> however I was still seeing similar panics, ran a scrub across the >> pool, still not happy, also upgraded the pool to v28 tried again, when >> that failed I scrubbed again but still no joy. >> >> As a matter of interest I booted an OpenIndiana live CD and tried >> copying the directories contents to another location, I am now able to >> list the directories. However there are still issues. >> >> The issue seems to have shifted slightly, stack trace from a recent >> panic is below (GENERIC kernel on 9.0-RELEASE); >> >> panic: avl_find() =A0succeeded inside avl_add() >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xc0a4b157 at kdb_backtrace+0x47 >> #1 0xc0a186b7 at panic+0x117 >> #2 0xc5a2d7b2 at avl_add+0x52 >> #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 >> #4 0xc5ac479e at zfs_fuid_init+0x14e >> #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 >> #6 0xc5ac48ed at zfs_fuid_map_id+0x2d >> #7 0xc5ac492f at zfs_groupmember+0x2f >> #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db >> #9 0xc5adc257 at zfs_zaccess+0xb7 >> #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 >> #11 0xc0d69322 at VOP_GETATTR_APV+0x42 >> #12 0xc0ab81c9 at vn_stat+0x79 >> #13 0xc0aaefdd at kern_statat_vnhook+0xfd >> #14 0xc0aaf1cc at kern_statat+0x3c >> #15 0xc0aaf156 at kern_lstat+0x36 >> #16 0xc0aaf1ff at sys_lstat+0x2f >> #17 0xc0d49315 at syscall+0x355 >> >> This time it appears to be related to some extended attribute(s), I >> can do an ls on one of the directories in question but an ls -la >> causes a panic, so it would seem that it's some attribute which is >> only shown in the long form of the ls output that is causing the >> issue. >> >> I've done some digging around via the magic of google and this seems >> to be a fairly common issue, but I've not found a solution for it >> (barring copying the data off, recreating the pool and restoring the >> data, I'd like to avoid this if at all possible. >> >> If I could determine what the problematic attribute was and a means to >> strip it (be that from FreeBSD or from an OpenIndiana liveCD) I think >> that will get me back up and running. >> >> If anybody can provide some suggestions as to what I may be able to do >> to resolve this issue in situ I would be very grateful. > > > > -- > Andriy Gapon --=20 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 00:16:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4011A106566B; Mon, 6 Feb 2012 00:16:56 +0000 (UTC) (envelope-from morgan.s.reed@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4CE8FC08; Mon, 6 Feb 2012 00:16:55 +0000 (UTC) Received: by pbdv10 with SMTP id v10so5725018pbd.13 for ; Sun, 05 Feb 2012 16:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Po+MBtXk4dVMUq9DzmX158Xu0o27CCjs2xt7zz5i3jQ=; b=k9iix4M0B9xkK5+q+ogOflTUIz50IwpX+XTdNJR2pQiVAWjlsH9M9tV0MUBTu9IzBm 2RxnhWxkN/Gly72eOkHYSM2EKtR3B1C/DILp7cPP6Ewk40UdWT4UT/IMgaDMmu4N5FMD UuCaVHQez8IyqQkQWhoL02geOUSrT7Olb/4eg= Received: by 10.68.208.196 with SMTP id mg4mr42045392pbc.108.1328487415473; Sun, 05 Feb 2012 16:16:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.65.226 with HTTP; Sun, 5 Feb 2012 16:16:34 -0800 (PST) In-Reply-To: References: <4F2E65EC.60107@FreeBSD.org> From: Morgan Reed Date: Mon, 6 Feb 2012 11:16:34 +1100 Message-ID: To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS panics on pool moved from OpenSolaris X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 00:16:56 -0000 Hi Andriy, Scratch that, it would appear to be a PEBKAC issue, looks like I omitted to actually save sid.h when I made the mods. Patch is good, I now have access to my whole pool again. Thanks, Morgan On Mon, Feb 6, 2012 at 10:23, Morgan Reed wrote: > Hi Andriy, > > =A0 =A0 =A0 =A0 =A0Thanks for that, the patch has significantly improved > matters, I'm now able to run a find across part of the drive without > issue, however I'm still seeing the panics on some directories, stack > trace below; > > panic: avl_find() =A0succeeded inside avl_add() > cpuid =3D 0 > KDB: stack backtrace: > #0 0xc0a4b157 at kdb_backtrace+0x47 > #1 0xc0a186b7 at panic+0x117 > #2 0xc5a2d7b2 at avl_add+0x52 > #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 > #4 0xc5ac479e at zfs_fuid_init+0x14e > #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 > #6 0xc5ac48ed at zfs_fuid_map_id+0x2d > #7 0xc5ac492f at zfs_groupmember+0x2f > #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db > #9 0xc5adc257 at zfs_zaccess+0xb7 > #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 > #11 0xc0d69322 at VOP_GETATTR_APV+0x42 > #12 0xc0ab81c9 at vn_stat+0x79 > #13 0xc0aaefdd at kern_statat_vnhook+0xfd > #14 0xc0aaf1cc at kern_statat+0x3c > #15 0xc0aaf156 at kern_lstat+0x36 > #16 0xc0aaf1ff at sys_lstat+0x2f > #17 0xc0d49315 at syscall+0x355 > > Same trace as previously on 9.0. > > I'm following your advice to Karli and throwing some printfs into > zfs_fuid_table_load, =A0I'll advise if I find anything enlightening. > > Thanks, > > Morgan > > On Sun, Feb 5, 2012 at 22:20, Andriy Gapon wrote: >> >> Please see this thread: >> http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013215.html >> It looks like the same issue. >> The patch has been committed in head, not sure if it's MFCed. >> >> on 05/02/2012 06:57 Morgan Reed said the following: >>> Hi all, >>> >>> =A0 =A0 =A0I'm experiencing an issue in migrating my NAS from OpenSolar= is >>> over to FreeBSD, I've tried both releng_8_2 and releng_9 I have >>> similar issues in both cases. >>> >>> The pool is a RAID-Z pool comprising 4 1TB drives, it was originally >>> created on OpenSolaris (not sure what version, 2010.09 maybe, it was >>> one of the last ones prior to the Oracle acquisition), pool was a V14 >>> pool, initially I built a FreeBSD-8.2 system to migrate the pool to, >>> migrated it over OK, upgraded it from V14 to V15, but later testing >>> revealed something wasn't happy, when listing certain directories (and >>> even doing an ls -la at the root of the pool) resulted in a kernel >>> panic (Mostly GENERIC kernel, rebuilt with KVA_PAGES 512 but other >>> than that stock); >>> >>> panic: avl_find() =A0succeeded inside avl_add() >>> cpuid =3D 0 >>> KDB: stack backtrace: >>> #0 0x808e0d07 at kdb_backtrace+0x47 >>> #1 0x808b1dc7 at panic+0x117 >>> #2 0x862e6602 at avl_add+0x52 >>> #3 0x8635c136 at zfs_fuid_table_load+0x1f6 >>> #4 0x8635c3ee at zfs_fuid_init+0x14e >>> #5 0x8635c4d7 at zfs_fuid_find_by_idx+0xb7 >>> #6 0x8635c52d at zfs_fuid_map_id+0x2d >>> #7 0x8635d56f at zfs_groupmember+0x2f >>> #8 0x8636df0b at zfs_zaccess_aces_check+0x1db >>> #9 0x8636377 at zfs_zaccess+0x57 >>> #10 0x8636d6fb at zfs_zaccess_rwx+0x3b >>> #11 0x86385f61 at zfs_freebsd_access+0xf1 >>> #12 0x80c02ea2 at VOP_ACCESS_APV+0x42 >>> #13 0x809457cf at change_dir+0x5f >>> #14 0x809467b1 at kern_chdir+0x81 >>> #15 0x80946a22 at chdir+0x22 >>> #16 0x808eca39 at syscallenter+0x329 >>> #17 0x80be4e14 at syscall+0x34 >>> >>> Looks like something in the permissions structure was causing grief, >>> tried running a scrub across the pool, didn't resolve the issue. >>> >>> After spending some time fighting with it I decided that it wasn't >>> worth the effort, and I upgraded to FreeBSD-9.0 to see if that would >>> assist (I normally avoid x.0 releases), once again pool imported fine, >>> however I was still seeing similar panics, ran a scrub across the >>> pool, still not happy, also upgraded the pool to v28 tried again, when >>> that failed I scrubbed again but still no joy. >>> >>> As a matter of interest I booted an OpenIndiana live CD and tried >>> copying the directories contents to another location, I am now able to >>> list the directories. However there are still issues. >>> >>> The issue seems to have shifted slightly, stack trace from a recent >>> panic is below (GENERIC kernel on 9.0-RELEASE); >>> >>> panic: avl_find() =A0succeeded inside avl_add() >>> cpuid =3D 0 >>> KDB: stack backtrace: >>> #0 0xc0a4b157 at kdb_backtrace+0x47 >>> #1 0xc0a186b7 at panic+0x117 >>> #2 0xc5a2d7b2 at avl_add+0x52 >>> #3 0xc5ac44e6 at zfs_fuid_table_load+0x1f6 >>> #4 0xc5ac479e at zfs_fuid_init+0x14e >>> #5 0xc5ac4893 at zfs_fuid_find_by_idx+0xc3 >>> #6 0xc5ac48ed at zfs_fuid_map_id+0x2d >>> #7 0xc5ac492f at zfs_groupmember+0x2f >>> #8 0xc5adbdcb at zfs_zaccess_aces_check+0x1db >>> #9 0xc5adc257 at zfs_zaccess+0xb7 >>> #10 0xc5afa7d4 at zfs_freebsd_getattr+0x1f4 >>> #11 0xc0d69322 at VOP_GETATTR_APV+0x42 >>> #12 0xc0ab81c9 at vn_stat+0x79 >>> #13 0xc0aaefdd at kern_statat_vnhook+0xfd >>> #14 0xc0aaf1cc at kern_statat+0x3c >>> #15 0xc0aaf156 at kern_lstat+0x36 >>> #16 0xc0aaf1ff at sys_lstat+0x2f >>> #17 0xc0d49315 at syscall+0x355 >>> >>> This time it appears to be related to some extended attribute(s), I >>> can do an ls on one of the directories in question but an ls -la >>> causes a panic, so it would seem that it's some attribute which is >>> only shown in the long form of the ls output that is causing the >>> issue. >>> >>> I've done some digging around via the magic of google and this seems >>> to be a fairly common issue, but I've not found a solution for it >>> (barring copying the data off, recreating the pool and restoring the >>> data, I'd like to avoid this if at all possible. >>> >>> If I could determine what the problematic attribute was and a means to >>> strip it (be that from FreeBSD or from an OpenIndiana liveCD) I think >>> that will get me back up and running. >>> >>> If anybody can provide some suggestions as to what I may be able to do >>> to resolve this issue in situ I would be very grateful. >> >> >> >> -- >> Andriy Gapon > > > > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -- Benjamin Franklin, 1759 --=20 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 00:43:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E548106566B; Mon, 6 Feb 2012 00:43:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id EFBDB8FC13; Mon, 6 Feb 2012 00:43:48 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q160hk0S036515 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 5 Feb 2012 16:43:48 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2F2292.4000909@freebsd.org> Date: Sun, 05 Feb 2012 16:45:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Andriy Gapon References: <4F2CE485.5020909@freebsd.org> <4F2E36B5.3010308@freebsd.org> <4F2E628D.8050101@FreeBSD.org> In-Reply-To: <4F2E628D.8050101@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , FreeBSD Current Subject: Re: problem with kgdb and modules. (k)gdb expert needed. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 00:43:49 -0000 On 2/5/12 3:05 AM, Andriy Gapon wrote: > on 05/02/2012 09:58 Julian Elischer said the following: >> In 9.x ( can't check -current, but teh mailing list has a better readership) >> >> I'm still seeing this and have still not found any solution: >> possible reasons for the change may be: >> 1/ change to kgdb? >> 2/ change to the compiling toolset? >> 3/ change to the .mk files for compiling modules? >> >> any guidance would be appreciated.. >> The reason I can get away with using FreeBSD ar work is because I can debug >> modules well >> as in Linux this is generally a problem.. Now I see similar breakage in >> freebsd. (sigh)). >> >> I really don't know where to start looking for this.. > Julian, > > just in case, how about some basic stuff like checking that the modules are > indeed built with debugging support, that .symbols are installed and are > accessible, that kgdb produces those messages: "Reading symbols", "Loaded symbols". > it seems to have been some timing issue. the scripts that ran in 8.x fail to load the symbols in 9.x but if I do the commands again by hand, it does load them.. so it seems to be a false alarm From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 05:51:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 334DD106566C; Mon, 6 Feb 2012 05:51:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 03B488FC17; Mon, 6 Feb 2012 05:51:43 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q165pcTq037281 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 5 Feb 2012 21:51:43 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2F6ABA.2020809@freebsd.org> Date: Sun, 05 Feb 2012 21:52:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: FreeBSD Stable , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kernel debugging and ULE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 05:51:44 -0000 so if I'm sitting still in the debugger for too long, a hardclock event happens that goes into ULE, which then hits the following KASSERT. KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, ("sched_priority: invalid priority %d: nice %d, " "ticks %d ftick %d ltick %d tick pri %d", pri, td->td_proc->p_nice, td->td_sched->ts_ticks, td->td_sched->ts_ftick, td->td_sched->ts_ltick, SCHED_PRI_TICKS(td->td_sched))); The reason seems to be that I've been sitting still for too long and things have become pear shaped. how is it that being in the debugger doesn't stop hardclock events? is there something I can do to make them not happen.. It means I have to ge tmy debugging done in less than about 60 seconds. suggesions welcome. Julian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 07:08:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B461065672 for ; Mon, 6 Feb 2012 07:08:58 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 57F108FC16 for ; Mon, 6 Feb 2012 07:08:58 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1678t3M073213; Mon, 6 Feb 2012 00:08:55 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1678tCI073210; Mon, 6 Feb 2012 00:08:55 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 6 Feb 2012 00:08:55 -0700 (MST) From: Warren Block To: Torfinn Ingolfsen In-Reply-To: <20120204230409.338a597b.torfinn.ingolfsen@broadpark.no> Message-ID: References: <20120202212222.e940f64c.torfinn.ingolfsen@broadpark.no> <20120203204110.cc933dc5.torfinn.ingolfsen@broadpark.no> <20120204043756.GA67863@DataIX.net> <20120204164423.ba815842.torfinn.ingolfsen@broadpark.no> <20120204165214.6f14f4a5.torfinn.ingolfsen@broadpark.no> <20120204230409.338a597b.torfinn.ingolfsen@broadpark.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 06 Feb 2012 00:08:56 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2-stable: devd fails to restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 07:08:58 -0000 On Sat, 4 Feb 2012, Torfinn Ingolfsen wrote: > On Sat, 04 Feb 2012 10:34:19 -0700 (MST) > Warren Block wrote: > >> >> Possibly relevant: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=140462&cat= >> >> (Using DHCP from /etc/rc.conf leaves a lock on devd.pid. SYNCDHCP does >> not.) >> >> And the thread: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012749.html > > Yes, it seems to be that problem. Tested on my other machine, which hasn't changed since the problem was discovered: > root@kg-v7# service devd status > devd is not running. > root@kg-v7# ll /var/run/devd.pid > -rw------- 1 root wheel 3 Jan 12 20:40 /var/run/devd.pid > root@kg-v7# lsof /var/run/devd.pid > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > dhclient 1075 root 5w VREG 0,70 3 918547 /var/run/devd.pid > dhclient 1091 _dhcp 5w VREG 0,70 3 918547 /var/run/devd.pid > root@kg-v7# > > So, if this was worked on back in 2009, why isn't fixed yet? I switched to using SYNCDHCP which avoids the problem, didn't enter a PR, and quickly forgot about it. It would be nice to have it fixed. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 11:11:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 164561065675 for ; Mon, 6 Feb 2012 11:11:45 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 986CB8FC08 for ; Mon, 6 Feb 2012 11:11:44 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id q16Av5X4072972 for ; Mon, 6 Feb 2012 11:57:05 +0100 (CET) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.158] (may be forged)) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id q16Av553013213 for ; Mon, 6 Feb 2012 11:57:05 +0100 (CET) (envelope-from hausen@punkt.de) From: "Patrick M. Hausen" Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Feb 2012 11:57:05 +0100 Message-Id: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: Swap on zvol - recommendable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 11:11:45 -0000 Hi, all, is it possible to make a definite statement about swap on zvols? I found some older discussions about a resource starvation scenario when ZFS arc would be the cause of the system running out of memory, trying to swap, yet the ZFS would not be accessible until some memory was freed - leading to a deadlock. Is this still the case with RELENG_8? The various Root on ZFS guides mention both choices (decicated or gmirror partition vs. zvol), yet don't say anything about the respective merits or risks. I am aware of the fact that I cannot dump to a raidz2 zvol ... Thanks for any hints, Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 12:52:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BF351065670; Mon, 6 Feb 2012 12:52:46 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailB.acsu.buffalo.edu (localmailb.acsu.buffalo.edu [128.205.5.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFB78FC18; Mon, 6 Feb 2012 12:52:45 +0000 (UTC) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F6ED187B; Mon, 6 Feb 2012 07:52:45 -0500 (EST) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id 613C85436; Mon, 6 Feb 2012 07:52:44 -0500 (EST) Received: from smtp2.acsu.buffalo.edu (smtp2.acsu.buffalo.edu [128.205.5.254]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 2EC26187B; Mon, 6 Feb 2012 07:52:44 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp2.acsu.buffalo.edu (Postfix) with ESMTPSA id D90D54A988; Mon, 6 Feb 2012 07:52:43 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-lyYfnGmGwMeRXmde/WLO" Date: Mon, 06 Feb 2012 07:52:43 -0500 Message-ID: <1328532763.4550.35.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: re Subject: Schedule for 8.3-RELEASE... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 12:52:46 -0000 --=-lyYfnGmGwMeRXmde/WLO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick note to say the target schedule for 8.3-RELEASE has been set and is available here: http://www.freebsd.org/releases/8.3R/schedule.html The summary of the target dates is: Code Freeze: Feb 15, 2012=20 BETA1 builds: Feb 17, 2012=20 RC1 builds: Mar 2, 2012=20 RC2 builds: Mar 16, 2012=20 REL builds: Mar 23, 2012=20 The Security Officer has pushed back the estimated End of Life for 8.2-RELEASE to July 31, 2012. That will give three months between the release of 8.3-RELEASE and the EoL for 8.2-RELEASE. It is expected that 8.3-RELEASE will be an Extended Support release. See: http://www.freebsd.org/security/#sup for the full details of the currently supported releases. Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-lyYfnGmGwMeRXmde/WLO 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) iEYEABECAAYFAk8vzRIACgkQ/G14VSmup/bWJACeO9nqaW8LciWeNbukaUO4sxX6 UOQAnjVYJlvDJZSbXHsgW+av9qDHHYxH =v0Fo -----END PGP SIGNATURE----- --=-lyYfnGmGwMeRXmde/WLO-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 17:23:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB211106566C for ; Mon, 6 Feb 2012 17:23:50 +0000 (UTC) (envelope-from mikes@siralan.org) Received: from mail.suso.org (mail.suso.org [66.244.94.5]) by mx1.freebsd.org (Postfix) with ESMTP id 9928D8FC0A for ; Mon, 6 Feb 2012 17:23:50 +0000 (UTC) Received: from c-98-223-201-170.hsd1.in.comcast.net (c-98-223-201-170.hsd1.in.comcast.net [98.223.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suso.org (Postfix) with ESMTP id 70565138214 for ; Mon, 6 Feb 2012 17:23:49 +0000 (GMT) Date: Mon, 6 Feb 2012 12:23:48 -0500 (EST) From: "Michael L. Squires" X-X-Sender: mikes@familysquires.net To: freebsd-stable@freebsd.org In-Reply-To: <1328532763.4550.35.camel@bauer.cse.buffalo.edu> Message-ID: References: <1328532763.4550.35.camel@bauer.cse.buffalo.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: make buildworld fails with 8.2-RELEASE amd64 building STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 17:23:50 -0000 "make buildworld" fails when trying to "make buildworld" (no options) with 8.2-RELEASE with 8.2-STABLE sources as of 2/6/2012 updated at 9:15 AM from ftp.freebsd.org. The compile fails in the same spot every time; this is not a random failure. I have seen some evidence, however, that there may be hardware problems. The other hardware problem was a Broadcom GigE watchdog timeout and reset. Hardware is a Tyan S2885 (dual dual-core Opteron) which has been running Windows XP SP3 for some time without problems, for what that's worth. A Google search turns up nothing obviously related. Mike Squires mikes at siralan.org UN*X at home since 1986 uname -a: FreeBSD s2885.familysquires.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@Amason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Error messages at failure: ===> gnu/usr.bin/gperf/doc (depend) c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc: In destructor 'Bool_Array::~Bool_Array()': /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc:39: internal compiler error: Illegal instruction: 4 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. s2885# From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 18:47:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4614C106566B; Mon, 6 Feb 2012 18:47:58 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E18328FC16; Mon, 6 Feb 2012 18:47:56 +0000 (UTC) Received: by iaeo4 with SMTP id o4so13313778iae.13 for ; Mon, 06 Feb 2012 10:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tSSOsBtWYcU219aHPr+R+oO4pO4djJErW/3pMDCAbC8=; b=T1ypp7wRhUde4nBQ+TsZmTpRLV+TzWXLeKndyegMH5BbVTYyMnTY/jeYDTcNQ1Gqle G4VX1xuzwjrjidaWd6WhzLKe/bbiPj+AG/mEjwyriPqgy+AuDlsw6gbM67HCtfuoa0pr gNJnA5kOC7iU22tbSxUPsEOf0JZHEDJW+ywao= Received: by 10.50.89.232 with SMTP id br8mr11524574igb.30.1328552241201; Mon, 06 Feb 2012 10:17:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.243.4 with HTTP; Mon, 6 Feb 2012 10:16:40 -0800 (PST) In-Reply-To: References: <2740DA0E7C0F495BA00E6D4BC0FE8F37@multiplay.co.uk> <040F9FF759DA441392432EDBD5C4D2CF@multiplay.co.uk> <4EB29A84.6070104@FreeBSD.org> From: Vlad Galu Date: Mon, 6 Feb 2012 18:16:40 +0000 Message-ID: To: "Li, Qing" X-Gm-Message-State: ALoCoQk6aWqOO6scbGMD9wqYvF7YYcMD+ubKLVzvVFjXkXa5dooeD3qwzwJh7gd9ZI9yNJmyMckr Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Steven Hartland , "liv3d@multiplay.co.uk" , "Alexander V. Chernikov" , "freebsd-stable@FreeBSD.org" , "qingli@freebsd.org" Subject: Re: serious packet routing issue causing ntpd high load? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 18:47:58 -0000 Hi Qing, Any luck with this? Thanks Vlad On Thu, Nov 3, 2011 at 2:05 PM, Li, Qing wrote: > This endless route lookup miss message problem is reproducible without > FLOWTABLE. > The problem is with the multiple FIBs. I cannot reproduce this problem in > my home network > but the problem is easily seen at work. > > The route lookup miss itself in multi-FIBs configuration may be normal > depending on > the actual system configuration. It's the flooding of RTM_MISS messages > that is abnormal. > For example, if the route to the DNS servers is not configured in all > FIBs, then the RTM_MISS > message will be generated when an userland application sends to an > explicit IP address > in a specific FIB. > > In any case, I can reproduce the issue consistently and just trying to get > a few uninterrupted > hours to get it done. > > --Qing > > ________________________________________ > From: Alexander V. Chernikov [melifaro@FreeBSD.org] > Sent: Thursday, November 03, 2011 6:43 AM > To: Steven Hartland > Cc: Li, Qing; freebsd-stable@FreeBSD.org; liv3d@multiplay.co.uk > Subject: Re: serious packet routing issue causing ntpd high load? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10.10.2011 13:50, Steven Hartland wrote: > > ----- Original Message ----- From: "Li, Qing" > > > >>> RTM_MISS: Lookup failed on this address: len 184, pid: 0, seq 0, errno > >>> 0, flags: > >>> locks: inits: > >>> sockaddrs: > >>> ::A.B.C.D > >>> > I'm unable to reproduce an issue on (nearly) GENERIC 8-S, but I see > nearly the same situation on 8.1-S box with FLOWTABLE enabled. > > Do you have FLOWTABLE option in your kernel config ? > >> > >> Would it be possible for you to email me what exactly does "::A.B.C.D" > >> map into WRT your system or infrastructure ? > > > > Sorry for the slow reply been out of the country. > > > > All the hosts are local machines same /24 connecting to the server for > > mysql. It seems to be that every packet either to or from for the mysql > > server is generating an RTM_MISS. > > > >> And are you able to share your "ifconfig -a" and "netstat -rn" output > >> with me privately ? > > > > On its way. > > > > 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. > > > > _______________________________________________ > > 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 > " > > > > > - -- > WBR, Alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6ymoMACgkQwcJ4iSZ1q2meiACeKq4lhzw6scqCKzEyTNEeycxo > 31QAn2q5KIRBwJpcF7yOpTe3wOcP3Aak > =jfKN > -----END PGP SIGNATURE----- > _______________________________________________ > 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" > -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 19:01:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AC0E1065674 for ; Mon, 6 Feb 2012 19:01:06 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 119918FC14 for ; Mon, 6 Feb 2012 19:01:05 +0000 (UTC) Received: from [192.168.248.34] ([192.168.248.34]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q16IlBKu029925 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 6 Feb 2012 23:47:11 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F30202C.5040304@norma.perm.ru> Date: Tue, 07 Feb 2012 00:47:08 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 06 Feb 2012 23:47:11 +0500 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: VOP_WRITE is not exclusive locked but should be X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 19:01:06 -0000 Hi. I have a server with an 8.2-RELEASE/amd64. It's primary use for routing/ipsec+gre tunneling. It's also running zfs. Sometimes it's locking up: it stops to respond to the network, but the console is still alive, though it doesn't log me in - the 'password:' prompt never comes up (I only can type my username or enter key). I've built a kernel with DEBUG_LOCKS/DEBUG_VFS_LOCKS, KDB/DDB, INVARIANTS, WITNESS and stuff. The only problem is that when booting such a new kernel and DEBUG_LOCKS/DEBUG_VFS_LOCKS are present, I get VOP_PUTPAGES: is not exclusive locked but should be and the kernel immidiately enters ddb. This happens on a daemons startup after the kernel is boot up and filesystems are mounted. Is this something that is safe to ignore (then how do I ignore that ? 'continue' only makes a new VOP_PUTPAGES message appear) ? Is it something that can lock up my server later on and should I report that ? I saw similar message (only it was about VOP_WRITE) in this maillist about 7-STABLE, someone said to try a memtest. I did one pass of a memtest (I know this isn't enough, but I cannot run it there for a day, and, furthermore, I got this message in subject immidiately on multiuser boot sequence so my guess is - the errors should appear immidiately too) and it didn't find any errors. Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 6 19:46:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01470106564A for ; Mon, 6 Feb 2012 19:46:20 +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 DBB3B8FC0A for ; Mon, 6 Feb 2012 19:46:19 +0000 (UTC) Received: from [192.168.15.220] (unknown [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 7D9B5B9022; Mon, 6 Feb 2012 12:17:13 -0500 (EST) Message-ID: <4F300B1D.9080809@ateamsystems.com> Date: Tue, 07 Feb 2012 00:17:17 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4F2BD37E.70209@ateamsystems.com> <20120203144848.GX3283@deviant.kiev.zoral.com.ua> In-Reply-To: <20120203144848.GX3283@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , FreeBSD-Stable ML Subject: Re: FreeBSD 9: Group quotas increase but don't decrease automatically X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Feb 2012 19:46:20 -0000 On 2/3/2012 21:48, Konstantin Belousov wrote: > This is a bug in +J code (even if you do not use +J). Do you have > softupdates enabled on the volume ? If yes, try the following patch. > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index 5b4b6b9..ed2db79 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -43,6 +43,7 @@ > __FBSDID("$FreeBSD$"); > > #include "opt_ffs.h" > +#include "opt_quota.h" > #include "opt_ddb.h" > > /* > @@ -6428,7 +6429,7 @@ softdep_setup_freeblocks(ip, length, flags) > } > #ifdef QUOTA > /* Reference the quotas in case the block count is wrong in the end. */ > - quotaref(vp, freeblks->fb_quota); > + quotaref(ITOV(ip), freeblks->fb_quota); > (void) chkdq(ip, -datablocks, NOCRED, 0); > #endif > freeblks->fb_chkcnt = -datablocks; Bingo, this fixes the issue for me! Testing it out on one machine now and will push it out to the others gradually ... thanks! From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 08:22:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F5CF106566C for ; Tue, 7 Feb 2012 08:22:54 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8A698FC17 for ; Tue, 7 Feb 2012 08:22:53 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so11312268obc.13 for ; Tue, 07 Feb 2012 00:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=USmvZ4WYRCEmmhUimaJKNvYnzBzN35baAXt5LZ4fiCQ=; b=Zfsv9qYPSo0I4jSEB/+hJGvFrzwb10SNsUfR9GmSHujyc5deVU3wouSq0f4xescZE9 uIZQd0DkeUNclEqNx4fKaJH5NFnFaIgul1sAxxnlZNV0U3x+0Ft1jDEJuR0j/IDWWXjM qEHP7hiqvbN/r+UwcruigcD6ltLf4wXHW/vPE= MIME-Version: 1.0 Received: by 10.182.16.103 with SMTP id f7mr20000029obd.51.1328602973237; Tue, 07 Feb 2012 00:22:53 -0800 (PST) Received: by 10.60.28.200 with HTTP; Tue, 7 Feb 2012 00:22:53 -0800 (PST) In-Reply-To: References: <1328532763.4550.35.camel@bauer.cse.buffalo.edu> Date: Tue, 7 Feb 2012 11:22:53 +0300 Message-ID: From: Sergey Kandaurov To: "Michael L. Squires" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: make buildworld fails with 8.2-RELEASE amd64 building STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 08:22:54 -0000 On 6 February 2012 21:23, Michael L. Squires wrote: > "make buildworld" fails when trying to "make buildworld" (no options) wit= h > 8.2-RELEASE with 8.2-STABLE sources as of 2/6/2012 updated at 9:15 AM fro= m > ftp.freebsd.org. > > The compile fails in the same spot every time; this is not a random failu= re. > =A0I have seen some evidence, however, that there may be hardware problem= s. > > The other hardware problem was a Broadcom GigE watchdog timeout and reset= . > > Hardware is a Tyan S2885 (dual dual-core Opteron) which has been running > Windows XP SP3 for some time without problems, for what that's worth. > > A Google search turns up nothing obviously related. > > Mike Squires > mikes at siralan.org > UN*X at home since 1986 > > uname -a: > > FreeBSD s2885.familysquires.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu F= eb > 17 02:41:51 UTC 2011 > root@Amason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =A0amd64 > > Error messages at failure: > > =3D=3D=3D> gnu/usr.bin/gperf/doc (depend) c++ -O2 -pipe > -I/usr/obj/usr/src/tmp/legacy/usr/include > -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/usr/src/gnu/usr.bin/gperf -c > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc: In > destructor 'Bool_Array::~Bool_Array()': > /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc:39: > internal compiler error: Illegal instruction: 4 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/gperf. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > s2885# You probably has bad RAM / overheat. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 08:36:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B70921065672 for ; Tue, 7 Feb 2012 08:36:38 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 266678FC13 for ; Tue, 7 Feb 2012 08:36:37 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q178aKmX085303 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 13:36:20 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F30E284.8080905@norma.perm.ru> Date: Tue, 07 Feb 2012 14:36:20 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Tue, 07 Feb 2012 13:36:20 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 08:36:38 -0000 Hi. I have a server with 9.0/amd64 and 4 Gigs of RAM. Today's questions are about the amount of memory in 'wired' state and the ARC size. If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says: ===Cut=== ARC Size: 12.50% 363.14 MiB Target Size: (Adaptive) 12.50% 363.18 MiB Min Size (Hard Limit): 12.50% 363.18 MiB Max Size (High Water): 8:1 2.84 GiB ===Cut=== At the same time I have 3500 megs in wired state: ===Cut=== Mem: 237M Active, 36M Inact, 3502M Wired, 78M Cache, 432K Buf, 37M Free ===Cut=== First question - what is the actual size of ARC, and how can it be determined ? Solaris version of the script is more comprehensive (ran on Solaris): ===Cut=== ARC Size: Current Size: 6457 MB (arcsize) Target Size (Adaptive): 6457 MB (c) Min Size (Hard Limit): 2941 MB (zfs_arc_min) Max Size (Hard Limit): 23534 MB (zfs_arc_max) ===Cut=== The arcstat script makes me think that the ARC size is about 380 megs indeed: ===Cut=== Time read miss miss% dmis dm% pmis pm% mmis mm% size tsize 14:33:35 170M 7466K 4 7466K 4 192 78 793K 3 380M 380M ===Cut=== Second question: if the size is 363 Megs, why do I have 3500 Megs in wired state? From my experience this is directly related to the zfs, but 380 megs its like about ten times smaller than 3600 megs. At the same time I have like 700 Megs in swap, so my guess - zfs isn't freeing memory for current needs that easily. Yeah, I can tune it down, but I just would like to know what is happening on an untuned machine. Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 09:50:16 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B5210656A4; Tue, 7 Feb 2012 09:50:16 +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 A25658FC1A; Tue, 7 Feb 2012 09:50:15 +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 LAA15619; Tue, 07 Feb 2012 11:50:12 +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 1Ruhgi-000OC2-8A; Tue, 07 Feb 2012 11:50:12 +0200 Message-ID: <4F30F3D1.4060600@FreeBSD.org> Date: Tue, 07 Feb 2012 11:50:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer References: <4F2F6ABA.2020809@freebsd.org> In-Reply-To: <4F2F6ABA.2020809@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , FreeBSD Current Subject: Re: kernel debugging and ULE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 09:50:16 -0000 on 06/02/2012 07:52 Julian Elischer said the following: > so if I'm sitting still in the debugger for too long, a hardclock > event happens that goes into ULE, which then hits the following KASSERT. > > > KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, > ("sched_priority: invalid priority %d: nice %d, " > "ticks %d ftick %d ltick %d tick pri %d", > pri, td->td_proc->p_nice, td->td_sched->ts_ticks, > td->td_sched->ts_ftick, td->td_sched->ts_ltick, > SCHED_PRI_TICKS(td->td_sched))); > > > The reason seems to be that I've been sitting still for too long and things have > become pear shaped. > > > how is it that being in the debugger doesn't stop hardclock events? > is there something I can do to make them not happen.. > It means I have to ge tmy debugging done in less than about 60 seconds. > > suggesions welcome. Does this really happen when you just sit in the debugger? Or does it happen when you let the kernel run? Like stepping through the code, etc.... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 10:46:51 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8983F106564A for ; Tue, 7 Feb 2012 10:46:51 +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 D50518FC1A for ; Tue, 7 Feb 2012 10:46:50 +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 MAA17192; Tue, 07 Feb 2012 12:46:47 +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 1RuiZS-000OEJ-Mb; Tue, 07 Feb 2012 12:46:46 +0200 Message-ID: <4F310115.3070507@FreeBSD.org> Date: Tue, 07 Feb 2012 12:46:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> In-Reply-To: <4F30E284.8080905@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 10:46:51 -0000 on 07/02/2012 10:36 Eugene M. Zheganin said the following: > Hi. > > I have a server with 9.0/amd64 and 4 Gigs of RAM. > Today's questions are about the amount of memory in 'wired' state and the ARC size. > > If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says: > > ===Cut=== > ARC Size: 12.50% 363.14 MiB > Target Size: (Adaptive) 12.50% 363.18 MiB > Min Size (Hard Limit): 12.50% 363.18 MiB > Max Size (High Water): 8:1 2.84 GiB > ===Cut=== > > At the same time I have 3500 megs in wired state: > > ===Cut=== > Mem: 237M Active, 36M Inact, 3502M Wired, 78M Cache, 432K Buf, 37M Free > ===Cut=== > > First question - what is the actual size of ARC, and how can it be determined ? > Solaris version of the script is more comprehensive (ran on Solaris): > > ===Cut=== > ARC Size: > Current Size: 6457 MB (arcsize) > Target Size (Adaptive): 6457 MB (c) > Min Size (Hard Limit): 2941 MB (zfs_arc_min) > Max Size (Hard Limit): 23534 MB (zfs_arc_max) > ===Cut=== Please try sysutils/zfs-stats; zfs-stats -a output should provide a good overview of the state and configuration of the system. > The arcstat script makes me think that the ARC size is about 380 megs indeed: > > ===Cut=== > Time read miss miss% dmis dm% pmis pm% mmis mm% size tsize > 14:33:35 170M 7466K 4 7466K 4 192 78 793K 3 380M 380M > ===Cut=== > > Second question: if the size is 363 Megs, why do I have 3500 Megs in wired > state? From my experience this is directly related to the zfs, but 380 megs its > like about ten times smaller than 3600 megs. At the same time I have like 700 > Megs in swap, so my guess - zfs isn't freeing memory for current needs that easily. > > Yeah, I can tune it down, but I just would like to know what is happening on an > untuned machine. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 11:35:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 471F31065691 for ; Tue, 7 Feb 2012 11:35:07 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id A12E88FC1F for ; Tue, 7 Feb 2012 11:35:05 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q17BYok6000658 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 16:34:50 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F310C5A.6070400@norma.perm.ru> Date: Tue, 07 Feb 2012 17:34:50 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> In-Reply-To: <4F310115.3070507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Tue, 07 Feb 2012 16:34:50 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,TO_NO_BRKTS_NORDNS=0.001,TO_NO_BRKTS_PCNT=0.001, USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 11:35:07 -0000 Hi. On 07.02.2012 16:46, Andriy Gapon wrote: > on 07/02/2012 10:36 Eugene M. Zheganin said the following: >> If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says: >> >> ===Cut=== >> ARC Size: 12.50% 363.14 MiB >> Target Size: (Adaptive) 12.50% 363.18 MiB >> Min Size (Hard Limit): 12.50% 363.18 MiB >> Max Size (High Water): 8:1 2.84 GiB >> ===Cut=== >> >> At the same time I have 3500 megs in wired state: >> >> >> Please try sysutils/zfs-stats; zfs-stats -a output should provide a good >> overview of the state and configuration of the system. >> Thanks. But it seems to be the same script. Anyway, it reports the same amount of memory: [emz@taiga:~]# zfs-stats -A ------------------------------------------------------------------------ ZFS Subsystem Report Tue Feb 7 17:32:34 2012 ------------------------------------------------------------------------ ARC Summary: (THROTTLED) Memory Throttle Count: 2.62k ARC Misc: Deleted: 10.17m Recycle Misses: 1.47m Mutex Misses: 7.69k Evict Skips: 7.69k ARC Size: 12.50% 363.24 MiB Target Size: (Adaptive) 12.50% 363.18 MiB Min Size (Hard Limit): 12.50% 363.18 MiB Max Size (High Water): 8:1 2.84 GiB ARC Size Breakdown: Recently Used Cache Size: 57.54% 209.01 MiB Frequently Used Cache Size: 42.46% 154.22 MiB ARC Hash Breakdown: Elements Max: 191.41k Elements Current: 33.76% 64.63k Collisions: 27.09m Chain Max: 17 Chains: 13.56k ------------------------------------------------------------------------ I still don't get why I have 3/5 Gigs in wired state. Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 11:43:56 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 521D71065676 for ; Tue, 7 Feb 2012 11:43:56 +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 9D58F8FC12 for ; Tue, 7 Feb 2012 11:43:55 +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 NAA18505; Tue, 07 Feb 2012 13:43:51 +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 1RujSh-000OHN-8Q; Tue, 07 Feb 2012 13:43:51 +0200 Message-ID: <4F310E75.7090301@FreeBSD.org> Date: Tue, 07 Feb 2012 13:43:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> In-Reply-To: <4F310C5A.6070400@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 11:43:56 -0000 on 07/02/2012 13:34 Eugene M. Zheganin said the following: > Hi. > > On 07.02.2012 16:46, Andriy Gapon wrote: >> on 07/02/2012 10:36 Eugene M. Zheganin said the following: >>> If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says: >>> >>> ===Cut=== >>> ARC Size: 12.50% 363.14 MiB >>> Target Size: (Adaptive) 12.50% 363.18 MiB >>> Min Size (Hard Limit): 12.50% 363.18 MiB >>> Max Size (High Water): 8:1 2.84 GiB >>> ===Cut=== >>> >>> At the same time I have 3500 megs in wired state: >>> >>> >>> Please try sysutils/zfs-stats; zfs-stats -a output should provide a good >>> overview of the state and configuration of the system. >>> > Thanks. But it seems to be the same script. Anyway, it reports the same amount > of memory: > > [emz@taiga:~]# zfs-stats -A zfs-stats -A is not the same as zfs-stats -a > ------------------------------------------------------------------------ > ZFS Subsystem Report Tue Feb 7 17:32:34 2012 > ------------------------------------------------------------------------ > > ARC Summary: (THROTTLED) > Memory Throttle Count: 2.62k > > ARC Misc: > Deleted: 10.17m > Recycle Misses: 1.47m > Mutex Misses: 7.69k > Evict Skips: 7.69k > > ARC Size: 12.50% 363.24 MiB > Target Size: (Adaptive) 12.50% 363.18 MiB > Min Size (Hard Limit): 12.50% 363.18 MiB > Max Size (High Water): 8:1 2.84 GiB > > ARC Size Breakdown: > Recently Used Cache Size: 57.54% 209.01 MiB > Frequently Used Cache Size: 42.46% 154.22 MiB > > ARC Hash Breakdown: > Elements Max: 191.41k > Elements Current: 33.76% 64.63k > Collisions: 27.09m > Chain Max: 17 > Chains: 13.56k > > ------------------------------------------------------------------------ > > I still don't get why I have 3/5 Gigs in wired state. > > Thanks. > > Eugene. > _______________________________________________ > 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" > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 15:35:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64641065672; Tue, 7 Feb 2012 15:35:29 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2A99F8FC14; Tue, 7 Feb 2012 15:35:27 +0000 (UTC) Received: from [192.168.248.33] ([192.168.248.33]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q17FZAvR013519 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 20:35:11 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F3144A9.2000505@norma.perm.ru> Date: Tue, 07 Feb 2012 21:35:05 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> In-Reply-To: <4F310E75.7090301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Tue, 07 Feb 2012 20:35:12 +0500 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: freebsd-stable@FreeBSD.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 15:35:29 -0000 Hi. On 07.02.2012 17:43, Andriy Gapon wrote: > on 07/02/2012 13:34 Eugene M. Zheganin said the following: >> Hi. >> >> On 07.02.2012 16:46, Andriy Gapon wrote: >>> on 07/02/2012 10:36 Eugene M. Zheganin said the following: >>>> If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says: >>>> >>>> ===Cut=== >>>> ARC Size: 12.50% 363.14 MiB >>>> Target Size: (Adaptive) 12.50% 363.18 MiB >>>> Min Size (Hard Limit): 12.50% 363.18 MiB >>>> Max Size (High Water): 8:1 2.84 GiB >>>> ===Cut=== >>>> >>>> At the same time I have 3500 megs in wired state: >>>> >>>> >>>> Please try sysutils/zfs-stats; zfs-stats -a output should provide a good >>>> overview of the state and configuration of the system. >>>> >> Thanks. But it seems to be the same script. Anyway, it reports the same amount >> of memory: >> >> [emz@taiga:~]# zfs-stats -A > zfs-stats -A is not the same as zfs-stats -a > Okay, thank you once again, it made me more clear what is happening to the memory: System Memory: 4.39% 172.47 MiB Active, 0.29% 11.53 MiB Inact 90.68% 3.48 GiB Wired, 3.54% 138.98 MiB Cache 0.10% 4.12 MiB Free, 0.99% 39.07 MiB Gap Real Installed: 4.00 GiB Real Available: 99.61% 3.98 GiB Real Managed: 96.31% 3.84 GiB Logical Total: 4.00 GiB Logical Used: 96.22% 3.85 GiB Logical Free: 3.78% 154.63 MiB Kernel Memory: 393.82 MiB Data: 96.14% 378.63 MiB Text: 3.86% 15.20 MiB Kernel Memory Map: 2.68 GiB Size: 9.82% 269.77 MiB Free: 90.18% 2.42 GiB Looks like most of the 'wired' space is makred in kernel as free, though still 'wired', and thus for me it doesn't look that free as 'free' or 'inactive', and, as the paged out amount continues to grow, I want to ask if there's a way to make this address space availabe to a userland processes ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 15:51:51 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52DA91065670 for ; Tue, 7 Feb 2012 15:51:51 +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 9F99E8FC19 for ; Tue, 7 Feb 2012 15:51:50 +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 RAA22676; Tue, 07 Feb 2012 17:51:46 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F314892.50806@FreeBSD.org> Date: Tue, 07 Feb 2012 17:51:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> In-Reply-To: <4F3144A9.2000505@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 15:51:51 -0000 on 07/02/2012 17:35 Eugene M. Zheganin said the following: > Okay, thank you once again, it made me more clear what is happening to the memory: > > > System Memory: > > 4.39% 172.47 MiB Active, 0.29% 11.53 MiB Inact > 90.68% 3.48 GiB Wired, 3.54% 138.98 MiB Cache > 0.10% 4.12 MiB Free, 0.99% 39.07 MiB Gap > > Real Installed: 4.00 GiB > Real Available: 99.61% 3.98 GiB > Real Managed: 96.31% 3.84 GiB > > Logical Total: 4.00 GiB > Logical Used: 96.22% 3.85 GiB > Logical Free: 3.78% 154.63 MiB > > Kernel Memory: 393.82 MiB > Data: 96.14% 378.63 MiB > Text: 3.86% 15.20 MiB > > Kernel Memory Map: 2.68 GiB > Size: 9.82% 269.77 MiB > Free: 90.18% 2.42 GiB > > Looks like most of the 'wired' space is makred in kernel as free, though still > 'wired', and thus for me it doesn't look that free as 'free' or 'inactive', and, > as the paged out amount continues to grow, I want to ask if there's a way to make > this address space availabe to a userland processes ? I am not sure that these conclusions are correct. Wired is wired, it's not free. BTW, are you reluctant to share the full zfs-stats -a output? You don't have to place it inline, you can upload it somewhere and provide a link. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 16:04:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33ABA106566B for ; Tue, 7 Feb 2012 16:04:03 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5C09C8FC13 for ; Tue, 7 Feb 2012 16:04:01 +0000 (UTC) Received: from [192.168.248.33] ([192.168.248.33]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q17G3iwP014711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 7 Feb 2012 21:03:44 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F314B5B.100@norma.perm.ru> Date: Tue, 07 Feb 2012 22:03:39 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> In-Reply-To: <4F314892.50806@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Tue, 07 Feb 2012 21:03:45 +0500 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 16:04:03 -0000 Hi. On 07.02.2012 21:51, Andriy Gapon wrote: > > I am not sure that these conclusions are correct. Wired is wired, it's not free. > BTW, are you reluctant to share the full zfs-stats -a output? You don't have to > place it inline, you can upload it somewhere and provide a link. > Well... nothing secret in it (in case someone will be interested too and so it stays in maillist archive): ===Cut=== [emz@taiga:~]> zfs-stats -a ------------------------------------------------------------------------ ZFS Subsystem Report Tue Feb 7 22:01:09 2012 ------------------------------------------------------------------------ System Information: Kernel Version: 900044 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 28 ZFS Filesystem Version: 5 FreeBSD 9.0-RELEASE #1: Mon Jan 23 13:36:16 YEKT 2012 emz 22:01 up 11 days, 2:44, 4 users, load averages: 0,30 0,26 0,32 ------------------------------------------------------------------------ System Memory: 4.30% 169.09 MiB Active, 1.04% 40.95 MiB Inact 90.80% 3.48 GiB Wired, 2.17% 85.25 MiB Cache 0.69% 27.30 MiB Free, 0.99% 39.08 MiB Gap Real Installed: 4.00 GiB Real Available: 99.61% 3.98 GiB Real Managed: 96.31% 3.84 GiB Logical Total: 4.00 GiB Logical Used: 96.25% 3.85 GiB Logical Free: 3.75% 153.50 MiB Kernel Memory: 397.53 MiB Data: 96.18% 382.33 MiB Text: 3.82% 15.20 MiB Kernel Memory Map: 2.69 GiB Size: 9.93% 273.20 MiB Free: 90.07% 2.42 GiB ------------------------------------------------------------------------ ARC Summary: (THROTTLED) Memory Throttle Count: 3.20k ARC Misc: Deleted: 10.83m Recycle Misses: 1.55m Mutex Misses: 7.80k Evict Skips: 7.80k ARC Size: 12.50% 363.20 MiB Target Size: (Adaptive) 12.50% 363.18 MiB Min Size (Hard Limit): 12.50% 363.18 MiB Max Size (High Water): 8:1 2.84 GiB ARC Size Breakdown: Recently Used Cache Size: 56.17% 204.02 MiB Frequently Used Cache Size: 43.83% 159.18 MiB ARC Hash Breakdown: Elements Max: 191.41k Elements Current: 32.79% 62.76k Collisions: 28.06m Chain Max: 17 Chains: 12.77k ------------------------------------------------------------------------ ARC Efficiency: 179.54m Cache Hit Ratio: 95.07% 170.68m Cache Miss Ratio: 4.93% 8.86m Actual Hit Ratio: 95.07% 170.68m Data Demand Efficiency: 94.72% 152.53m Data Prefetch Efficiency: 0.00% 20 CACHE HITS BY CACHE LIST: Most Recently Used: 30.50% 52.05m Most Frequently Used: 69.50% 118.63m Most Recently Used Ghost: 0.30% 517.41k Most Frequently Used Ghost: 1.02% 1.74m CACHE HITS BY DATA TYPE: Demand Data: 84.65% 144.48m Prefetch Data: 0.00% 0 Demand Metadata: 15.35% 26.20m Prefetch Metadata: 0.00% 52 CACHE MISSES BY DATA TYPE: Demand Data: 90.88% 8.05m Prefetch Data: 0.00% 20 Demand Metadata: 9.12% 807.98k Prefetch Metadata: 0.00% 172 ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 384 vm.kmem_size 4120326144 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 329853485875 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 114792960 vfs.zfs.mfu_ghost_metadata_lsize 69912064 vfs.zfs.mfu_ghost_size 184705024 vfs.zfs.mfu_data_lsize 26686464 vfs.zfs.mfu_metadata_lsize 13492736 vfs.zfs.mfu_size 45798912 vfs.zfs.mru_ghost_data_lsize 22662656 vfs.zfs.mru_ghost_metadata_lsize 142631424 vfs.zfs.mru_ghost_size 165294080 vfs.zfs.mru_data_lsize 149837312 vfs.zfs.mru_metadata_lsize 6439424 vfs.zfs.mru_size 215066624 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 1421824 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.arc_meta_limit 761646080 vfs.zfs.arc_meta_used 202913864 vfs.zfs.arc_min 380823040 vfs.zfs.arc_max 3046584320 vfs.zfs.dedup.prefetch 1 vfs.zfs.mdcomp_disable 0 vfs.zfs.write_limit_override 0 vfs.zfs.write_limit_inflated 12834803712 vfs.zfs.write_limit_max 534783488 vfs.zfs.write_limit_min 33554432 vfs.zfs.write_limit_shift 3 vfs.zfs.no_write_throttle 0 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 1 vfs.zfs.mg_alloc_failures 8 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.txg.synctime_ms 1000 vfs.zfs.txg.timeout 5 vfs.zfs.scrub_limit 10 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 0 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.ramp_rate 2 vfs.zfs.vdev.time_shift 6 vfs.zfs.vdev.min_pending 4 vfs.zfs.vdev.max_pending 10 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_replay_disable 0 vfs.zfs.zio.use_uma 0 vfs.zfs.version.zpl 5 vfs.zfs.version.spa 28 vfs.zfs.version.acl 1 vfs.zfs.debug 0 vfs.zfs.super_owner 0 ------------------------------------------------------------------------ [emz@taiga:~]> ===Cut=== Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 18:56:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB32106564A for ; Tue, 7 Feb 2012 18:56:10 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id DD4E88FC17 for ; Tue, 7 Feb 2012 18:56:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LZ100H3WDXK9AB0@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Tue, 07 Feb 2012 19:56:08 +0100 (CET) Received: from kg-v2.kg4.no ([84.215.134.159]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTPA id <0LZ100KRIDXJ5B10@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Tue, 07 Feb 2012 19:56:08 +0100 (CET) Date: Tue, 07 Feb 2012 19:56:07 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120207195607.919234a7.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <20120202212222.e940f64c.torfinn.ingolfsen@broadpark.no> <20120203204110.cc933dc5.torfinn.ingolfsen@broadpark.no> <20120204043756.GA67863@DataIX.net> <20120204164423.ba815842.torfinn.ingolfsen@broadpark.no> <20120204165214.6f14f4a5.torfinn.ingolfsen@broadpark.no> <20120204230409.338a597b.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD 8.2-stable: devd fails to restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 18:56:10 -0000 On Mon, 06 Feb 2012 00:08:55 -0700 (MST) Warren Block wrote: > On Sat, 4 Feb 2012, Torfinn Ingolfsen wrote: > > > On Sat, 04 Feb 2012 10:34:19 -0700 (MST) > > Warren Block wrote: > > > >> > >> Possibly relevant: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=140462&cat= > >> > >> (Using DHCP from /etc/rc.conf leaves a lock on devd.pid. SYNCDHCP does > >> not.) > >> > >> And the thread: > >> http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012749.html > > > > Yes, it seems to be that problem. Tested on my other machine, which hasn't changed since the problem was discovered: > > root@kg-v7# service devd status > > devd is not running. > > root@kg-v7# ll /var/run/devd.pid > > -rw------- 1 root wheel 3 Jan 12 20:40 /var/run/devd.pid > > root@kg-v7# lsof /var/run/devd.pid > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > > dhclient 1075 root 5w VREG 0,70 3 918547 /var/run/devd.pid > > dhclient 1091 _dhcp 5w VREG 0,70 3 918547 /var/run/devd.pid > > root@kg-v7# > > > > So, if this was worked on back in 2009, why isn't fixed yet? > > I switched to using SYNCDHCP which avoids the problem, didn't enter a > PR, and quickly forgot about it. It would be nice to have it fixed. I'm all for getting it fixed, even if I don't know how yet. Should a PR be against devd, dhclient, or ... something else? -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 19:03:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81AE6106566B; Tue, 7 Feb 2012 19:03:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 58A2A8FC15; Tue, 7 Feb 2012 19:03:46 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 10B6846B3B; Tue, 7 Feb 2012 14:03:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6B6D1B95C; Tue, 7 Feb 2012 14:03:45 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 7 Feb 2012 13:43:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F2F6ABA.2020809@freebsd.org> In-Reply-To: <4F2F6ABA.2020809@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202071343.45787.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 Feb 2012 14:03:45 -0500 (EST) Cc: FreeBSD Stable , Julian Elischer , FreeBSD Current Subject: Re: kernel debugging and ULE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 19:03:46 -0000 On Monday, February 06, 2012 12:52:58 am Julian Elischer wrote: > so if I'm sitting still in the debugger for too long, a hardclock > event happens that goes into ULE, which then hits the following KASSERT. > > > KASSERT(pri >= PRI_MIN_BATCH && pri <= PRI_MAX_BATCH, > ("sched_priority: invalid priority %d: nice %d, " > "ticks %d ftick %d ltick %d tick pri %d", > pri, td->td_proc->p_nice, td->td_sched->ts_ticks, > td->td_sched->ts_ftick, td->td_sched->ts_ltick, > SCHED_PRI_TICKS(td->td_sched))); > > > The reason seems to be that I've been sitting still for too long and > things have become pear shaped. > > > how is it that being in the debugger doesn't stop hardclock events? > is there something I can do to make them not happen.. > It means I have to ge tmy debugging done in less than about 60 seconds. > > suggesions welcome. I committed a workaround to HEAD for this recently (r228960). Just make sure that is merged into whatever tree you are using. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 19:16:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76FA6106566B for ; Tue, 7 Feb 2012 19:16:19 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 148D08FC14 for ; Tue, 7 Feb 2012 19:16:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q17JGFlI089635; Tue, 7 Feb 2012 12:16:15 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q17JGFLF089632; Tue, 7 Feb 2012 12:16:15 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 7 Feb 2012 12:16:15 -0700 (MST) From: Warren Block To: Torfinn Ingolfsen In-Reply-To: <20120207195607.919234a7.torfinn.ingolfsen@broadpark.no> Message-ID: References: <20120202212222.e940f64c.torfinn.ingolfsen@broadpark.no> <20120203204110.cc933dc5.torfinn.ingolfsen@broadpark.no> <20120204043756.GA67863@DataIX.net> <20120204164423.ba815842.torfinn.ingolfsen@broadpark.no> <20120204165214.6f14f4a5.torfinn.ingolfsen@broadpark.no> <20120204230409.338a597b.torfinn.ingolfsen@broadpark.no> <20120207195607.919234a7.torfinn.ingolfsen@broadpark.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 07 Feb 2012 12:16:15 -0700 (MST) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2-stable: devd fails to restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 19:16:19 -0000 On Tue, 7 Feb 2012, Torfinn Ingolfsen wrote: > On Mon, 06 Feb 2012 00:08:55 -0700 (MST) > Warren Block wrote: > >> On Sat, 4 Feb 2012, Torfinn Ingolfsen wrote: >> >>> On Sat, 04 Feb 2012 10:34:19 -0700 (MST) >>> Warren Block wrote: >>> >>>> >>>> Possibly relevant: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=140462&cat= >>>> >>>> (Using DHCP from /etc/rc.conf leaves a lock on devd.pid. SYNCDHCP does >>>> not.) >>>> >>>> And the thread: >>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012749.html >>> >>> Yes, it seems to be that problem. Tested on my other machine, which hasn't changed since the problem was discovered: >>> root@kg-v7# service devd status >>> devd is not running. >>> root@kg-v7# ll /var/run/devd.pid >>> -rw------- 1 root wheel 3 Jan 12 20:40 /var/run/devd.pid >>> root@kg-v7# lsof /var/run/devd.pid >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> dhclient 1075 root 5w VREG 0,70 3 918547 /var/run/devd.pid >>> dhclient 1091 _dhcp 5w VREG 0,70 3 918547 /var/run/devd.pid >>> root@kg-v7# >>> >>> So, if this was worked on back in 2009, why isn't fixed yet? >> >> I switched to using SYNCDHCP which avoids the problem, didn't enter a >> PR, and quickly forgot about it. It would be nice to have it fixed. > > I'm all for getting it fixed, even if I don't know how yet. > Should a PR be against devd, dhclient, or ... something else? It's devd, IMO. Hey, come to think of it, I did enter a PR, the one above. If this is still a problem in 9 (which I can test in a bit), posting to -current might get some needed attention on it. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 19:21:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6301065676 for ; Tue, 7 Feb 2012 19:21:52 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 52C748FC14 for ; Tue, 7 Feb 2012 19:21:52 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q17JLotr089687; Tue, 7 Feb 2012 12:21:50 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q17JLoP8089684; Tue, 7 Feb 2012 12:21:50 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 7 Feb 2012 12:21:50 -0700 (MST) From: Warren Block To: Jason Hellenthal In-Reply-To: Message-ID: References: <20120204184816.GA52504@icarus.home.lan> <20120204190702.GC37724@DataIX.net> <20120204230332.GA582@DataIX.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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 07 Feb 2012 12:21:50 -0700 (MST) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: ld: kernel.debug: Not enough room for program headers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 19:21:52 -0000 8-stable i386 is building again. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 19:53:14 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE801065674 for ; Tue, 7 Feb 2012 19:53:14 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BA2F68FC0A for ; Tue, 7 Feb 2012 19:53:13 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 630346A2BF for ; Tue, 7 Feb 2012 20:53:11 +0100 (CET) Received: from [172.20.10.4] (c-5eeaaa37-74736162.cust.telenor.se [94.234.170.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 981C56A2B8; Tue, 7 Feb 2012 20:53:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> Date: Tue, 7 Feb 2012 20:53:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> To: Patrick M. Hausen X-Mailer: Apple Mail (2.1251.1) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Feb 7 20:53:11 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4f31812726811036549374 X-DSPAM-Factors: 27, Received*cipher+AES128, 0.40000, just, 0.40000, system+>, 0.40000, a+HUGE, 0.40000, AM, 0.40000, Mime-Version*Message, 0.40000, all+>, 0.40000, ZFS+guides, 0.40000, swap+is, 0.40000, "freebsd, 0.40000, or, 0.40000, or, 0.40000, Received*Tue, 0.40000, http+//lists, 0.40000, any+hints, 0.40000, org, 0.40000, from, 0.40000, be+the, 0.40000, of, 0.40000, of, 0.40000, M+Hausen, 0.40000, running+out, 0.40000, when+the, 0.40000, Received*2012, 0.40000, zvol+>, 0.40000, cause, 0.40000, swap+on, 0.40000 Cc: stable@freebsd.org Subject: Re: Swap on zvol - recommendable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 19:53:14 -0000 I can just tell you I had this problem still in 8.1 and it was a HUGE = problem.=20 System stalled every two weeks or so. Now when the swap is moved away = from zfs it works fine. On Feb 6, 2012, at 11:57 AM, Patrick M. Hausen wrote: > Hi, all, >=20 > is it possible to make a definite statement about swap on zvols? >=20 > I found some older discussions about a resource starvation > scenario when ZFS arc would be the cause of the system > running out of memory, trying to swap, yet the ZFS would > not be accessible until some memory was freed - leading to > a deadlock. >=20 > Is this still the case with RELENG_8? The various Root on > ZFS guides mention both choices (decicated or gmirror > partition vs. zvol), yet don't say anything about the respective > merits or risks. I am aware of the fact that I cannot dump to > a raidz2 zvol ... >=20 > Thanks for any hints, > Patrick > --=20 > punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe > Tel. 0721 9109 0 * Fax 0721 9109 100 > info@punkt.de http://www.punkt.de > Gf: J=FCrgen Egeling AG Mannheim 108285 >=20 >=20 >=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" >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 20:17:16 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89AC1065686 for ; Tue, 7 Feb 2012 20:17:16 +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 2F3008FC1E for ; Tue, 7 Feb 2012 20:17:15 +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 WAA25869; Tue, 07 Feb 2012 22:17:11 +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 1RurTT-000Odk-8S; Tue, 07 Feb 2012 22:17:11 +0200 Message-ID: <4F3186C6.8000904@FreeBSD.org> Date: Tue, 07 Feb 2012 22:17:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> In-Reply-To: <4F314B5B.100@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 20:17:16 -0000 on 07/02/2012 18:03 Eugene M. Zheganin said the following: > Hi. > > On 07.02.2012 21:51, Andriy Gapon wrote: >> >> I am not sure that these conclusions are correct. Wired is wired, it's not free. >> BTW, are you reluctant to share the full zfs-stats -a output? You don't have to >> place it inline, you can upload it somewhere and provide a link. >> > Well... nothing secret in it (in case someone will be interested too and so it > stays in maillist archive): [output snipped] Thank you. I don't see anything suspicious/unusual there. Just case, do you have ZFS dedup enabled by a chance? I think that examination of vmstat -m and vmstat -z outputs may provide some clues as to what got all that memory wired. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 7 22:36:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF8F41065676 for ; Tue, 7 Feb 2012 22:36:05 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 780098FC0A for ; Tue, 7 Feb 2012 22:36:05 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so8425047wib.13 for ; Tue, 07 Feb 2012 14:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zxmNj2ZeXMTTSvXXrLewf/2Dr1czd/UnxkQAqqQoLfI=; b=oCPIkqfXb62usQulOdSydych0hL1dVPSScTTXOtI6USPc/TF/rKTPkdXeEOXZUGOCY pghKPx3ieLpF5bfl6IiiQaTGo1keDksCOcZBlyQ5Gm28HITkpiBALvYythjdyLod+Lns FqypnIfdst5k10ay/5xIxQ4f5H04/rZvRD7NY= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr22706015wif.10.1328654164506; Tue, 07 Feb 2012 14:36:04 -0800 (PST) Received: by 10.223.157.198 with HTTP; Tue, 7 Feb 2012 14:36:04 -0800 (PST) Date: Tue, 7 Feb 2012 16:36:04 -0600 Message-ID: From: Adam Vande More To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: sndstat verbosity X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Feb 2012 22:36:06 -0000 The Handbook page on setting up sound says to find out which driver bound to the system after doing a "kldload snd_driver" to run"cat /dev/sndstat". In my versions of 8/9-STABLE, there is no way to determine what that driver is from sndstat without increasing the verbosity of "hw.snd.verbose". IMO, either a bug should be filed against docs to include a mention of increasing the verbosity, or sndstat should list the bound module in it's default output. Does anyone have feedback on this and if the bug should be a doc or sndstat related one? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 09:52:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923DD1065670; Wed, 8 Feb 2012 09:52:04 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 52A8F8FC0C; Wed, 8 Feb 2012 09:52:04 +0000 (UTC) Received: from carrick-users.bishnet.net ([2a01:348:132:51::10]) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Rv4CT-000DCu-MW; Wed, 08 Feb 2012 09:52:29 +0000 Received: (from tdb@localhost) by carrick-users.bishnet.net (8.14.4/8.14.4/Submit) id q189qTGJ050771; Wed, 8 Feb 2012 09:52:29 GMT (envelope-from tdb) Date: Wed, 8 Feb 2012 09:52:29 +0000 From: Tim Bishop To: freebsd-stable@freebsd.org Message-ID: <20120208095229.GJ54493@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: markm@freebsd.org Subject: MFC misc/124164 (Add SHA-256/512 hash algorithm to crypt(3)) to stable/8? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 09:52:04 -0000 Are there any committers willing to merge PR misc/124164 to stable/8 before the 8.3 release freeze? It's already in HEAD and stable/9 so it's had some testing. misc/124164 adds support for SHA256/512 to crypt(3). This is something we make use of on Linux and FreeBSD 9, and it'd be great to have the same support on FreeBSD 8. http://www.freebsd.org/cgi/query-pr.cgi?pr=124164 SVN Revs: 220496 220497 I've tried markm@ already and had no response. Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 10:28:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2063106564A; Wed, 8 Feb 2012 10:28:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id AE0BC8FC08; Wed, 8 Feb 2012 10:28:21 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q18ASHr1052113 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 Feb 2012 02:28:20 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F324E93.50303@freebsd.org> Date: Wed, 08 Feb 2012 02:29:39 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Andriy Gapon References: <4F2F6ABA.2020809@freebsd.org> <4F30F3D1.4060600@FreeBSD.org> In-Reply-To: <4F30F3D1.4060600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , FreeBSD Current Subject: Re: kernel debugging and ULE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 10:28:22 -0000 On 2/7/12 1:50 AM, Andriy Gapon wrote: > on 06/02/2012 07:52 Julian Elischer said the following: >> so if I'm sitting still in the debugger for too long, a hardclock >> event happens that goes into ULE, which then hits the following KASSERT. >> >> >> KASSERT(pri>= PRI_MIN_BATCH&& pri<= PRI_MAX_BATCH, >> ("sched_priority: invalid priority %d: nice %d, " >> "ticks %d ftick %d ltick %d tick pri %d", >> pri, td->td_proc->p_nice, td->td_sched->ts_ticks, >> td->td_sched->ts_ftick, td->td_sched->ts_ltick, >> SCHED_PRI_TICKS(td->td_sched))); >> >> >> The reason seems to be that I've been sitting still for too long and things have >> become pear shaped. >> >> >> how is it that being in the debugger doesn't stop hardclock events? >> is there something I can do to make them not happen.. >> It means I have to ge tmy debugging done in less than about 60 seconds. >> >> suggesions welcome. > Does this really happen when you just sit in the debugger? > Or does it happen when you let the kernel run? Like stepping through the code, > etc.... > good point.. I was doing some single stepping.. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 10:32:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D01A106564A for ; Wed, 8 Feb 2012 10:32:03 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 097ED8FC1C for ; Wed, 8 Feb 2012 10:32:01 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q18AViGE074164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 Feb 2012 15:31:44 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F324F10.2060508@norma.perm.ru> Date: Wed, 08 Feb 2012 16:31:44 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> In-Reply-To: <4F3186C6.8000904@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Wed, 08 Feb 2012 15:31:44 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 10:32:03 -0000 Hi. On 08.02.2012 02:17, Andriy Gapon wrote: > [output snipped] > > Thank you. I don't see anything suspicious/unusual there. > Just case, do you have ZFS dedup enabled by a chance? > > I think that examination of vmstat -m and vmstat -z outputs may provide some > clues as to what got all that memory wired. > Nope, I don't have deduplication feature enabled. By the way, today, after eating another 100M of wired memory this server hanged out with multiple non-stopping messages swap_pager: indefinite wait buffer Since it's swapping on zvol, it looks to me like it could be the mentioned in another thread here ("Swap on zvol - recommendable?") resource starvation issue; may be it happens faster when the ARC isn't limited. So I want to ask - how to report it and what should I include in such pr ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 11:45:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F470106566B for ; Wed, 8 Feb 2012 11:45:08 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) by mx1.freebsd.org (Postfix) with ESMTP id A939B8FC14 for ; Wed, 8 Feb 2012 11:45:07 +0000 (UTC) Received: from uucp by gromit.grondar.org with local-rmail (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Rv5xS-0002V4-UD for freebsd-stable@freebsd.org; Wed, 08 Feb 2012 11:45:06 +0000 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rv5vu-000CCt-It; Wed, 08 Feb 2012 11:43:30 +0000 To: Tim Bishop In-reply-to: <20120208095229.GJ54493@carrick-users.bishnet.net> References: <20120208095229.GJ54493@carrick-users.bishnet.net> From: Mark Murray Date: Wed, 08 Feb 2012 11:43:30 +0000 Message-Id: Cc: freebsd-stable@freebsd.org Subject: Re: MFC misc/124164 (Add SHA-256/512 hash algorithm to crypt(3)) to stable/8? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 11:45:08 -0000 Tim Bishop writes: > Are there any committers willing to merge PR misc/124164 to stable/8 > before the 8.3 release freeze? It's already in HEAD and stable/9 so it's > had some testing. > > misc/124164 adds support for SHA256/512 to crypt(3). This is something > we make use of on Linux and FreeBSD 9, and it'd be great to have the > same support on FreeBSD 8. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124164 > > SVN Revs: 220496 220497 > > I've tried markm@ already and had no response. Apologies - I'll get to it ASAP. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 12:15:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C95106566B for ; Wed, 8 Feb 2012 12:15:57 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id BD51B8FC0A for ; Wed, 8 Feb 2012 12:15:56 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D68A.dip.t-dialin.net [87.150.214.138]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 7B85C84400C; Wed, 8 Feb 2012 13:15:41 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id BB69C2AA3; Wed, 8 Feb 2012 13:15:38 +0100 (CET) Date: Wed, 8 Feb 2012 13:15:37 +0100 From: Alexander Leidinger To: "Eugene M. Zheganin" Message-ID: <20120208131537.00004c01@unknown> In-Reply-To: <4F324F10.2060508@norma.perm.ru> References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 7B85C84400C.A04F5 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.971, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.04, TW_ZF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329308144.06559@BQxXemMODmNt/B59UwXU8Q X-EBL-Spam-Status: No Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 12:15:57 -0000 On Wed, 08 Feb 2012 16:31:44 +0600 "Eugene M. Zheganin" wrote: > swap_pager: indefinite wait buffer > > Since it's swapping on zvol, it looks to me like it could be the > mentioned in another thread here ("Swap on zvol - recommendable?") > resource starvation issue; may be it happens faster when the ARC > isn't limited. > > So I want to ask - how to report it and what should I include in such > pr ? I can't remember to have seen any mention of SWAP on ZFS being safe now. So if nobody can provide a reference to a place which tells that the problems with SWAP on ZFS are fixed: 1. do not use SWAP on ZFS 2. see 1. 3. check if you see the same problem without SWAP on ZFS (btw. see 1.) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 12:29:17 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B4B106564A for ; Wed, 8 Feb 2012 12:29:17 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 33AAD8FC14 for ; Wed, 8 Feb 2012 12:29:16 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 774DE39844; Wed, 8 Feb 2012 13:11:18 +0100 (CET) Date: Wed, 8 Feb 2012 13:11:18 +0100 From: Victor Balada Diaz To: stable@freebsd.org Message-ID: <20120208121118.GH2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: i18n not working during startup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 12:29:17 -0000 Hello, I tried freebsd-i18n but no one answered, so i will try better luck here. Sorry for the people who are subscribed to both lists. ----- Forwarded message from Victor Balada Diaz ----- Date: Thu, 2 Feb 2012 19:17:21 +0100 From: Victor Balada Diaz To: freebsd-i18n@freebsd.org Subject: i18n not working during startup User-Agent: Mutt/1.5.21 (2010-09-15) Hello, I've setup login classes by handbook recommendation but seems that daemons started by rc at system bootup don't use it. What i'm actually trying to do is configure tomcat to use UTF-8 by default. I've configured it's user class on /etc/login.conf adding: :setenv=LC_ALL=en_US.UTF-8:\ :lang=en_US.UTF-8:\ rebuilt login.conf db and tried rebooting. It doesn't seem to have lang or lc_all set in their environment. As a workaround i thought about adding export lines at start of /etc/rc.conf, but that's an ugly hack. Is there any other way of setting up lang settings for system startup daemons? FreeBSD version: 7.4 Arch: amd64 Thanks a lot. Regards -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ----- End forwarded message ----- -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 13:04:02 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91761106566C for ; Wed, 8 Feb 2012 13:04:02 +0000 (UTC) (envelope-from it@galasoluciones.com) Received: from mail.galasoluciones.com (maduixa.galasoluciones.com [178.22.68.108]) by mx1.freebsd.org (Postfix) with ESMTP id 4B87D8FC13 for ; Wed, 8 Feb 2012 13:04:02 +0000 (UTC) Received: from maduixa.galasoluciones.com (localhost [127.0.0.1]) by mail.galasoluciones.com (Postfix) with ESMTP id C8B7DD4C5D; Wed, 8 Feb 2012 13:46:59 +0100 (CET) X-Virus-Scanned: amavisd-new at galasoluciones.com Received: from mail.galasoluciones.com ([127.0.0.1]) by maduixa.galasoluciones.com (maduixa.galasoluciones.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P69Lm0+6Zrt; Wed, 8 Feb 2012 13:46:58 +0100 (CET) Received: from host129-0-168-192.siriusdemo.com (20.21.23.95.dynamic.jazztel.es [95.23.21.20]) by mail.galasoluciones.com (Postfix) with ESMTPA id 024F3D4C5B; Wed, 8 Feb 2012 13:46:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Gala IT In-Reply-To: <20120208121118.GH2010@equilibrium.bsdes.net> Date: Wed, 8 Feb 2012 13:46:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F843E45-7222-40B6-BF46-5B3DD5291229@galasoluciones.com> References: <20120208121118.GH2010@equilibrium.bsdes.net> To: Victor Balada Diaz X-Mailer: Apple Mail (2.1257) Cc: stable@freebsd.org Subject: Re: i18n not working during startup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 13:04:02 -0000 Hi Victor, Try setting tomcat7_java_opts=3D"-Dfile.encoding=3DUTF-8" in = /etc/rc.conf. It works for us under 8.2. Kind regards, David. El 08/02/2012, a les 13:11, Victor Balada Diaz va escriure: > Hello, >=20 > I tried freebsd-i18n but no one answered, so i will try better luck = here. Sorry > for the people who are subscribed to both lists. >=20 > ----- Forwarded message from Victor Balada Diaz = ----- >=20 > Date: Thu, 2 Feb 2012 19:17:21 +0100 > From: Victor Balada Diaz > To: freebsd-i18n@freebsd.org > Subject: i18n not working during startup > User-Agent: Mutt/1.5.21 (2010-09-15) >=20 > Hello, >=20 > I've setup login classes by handbook recommendation but seems that = daemons started by rc > at system bootup don't use it. What i'm actually trying to do is = configure tomcat to > use UTF-8 by default. I've configured it's user class on = /etc/login.conf adding: >=20 > :setenv=3DLC_ALL=3Den_US.UTF-8:\ > :lang=3Den_US.UTF-8:\ >=20 > rebuilt login.conf db and tried rebooting. It doesn't seem to have = lang or lc_all set > in their environment. As a workaround i thought about adding export = lines at start of > /etc/rc.conf, but that's an ugly hack.=20 >=20 > Is there any other way of setting up lang settings for system startup = daemons? >=20 > FreeBSD version: 7.4 > Arch: amd64 >=20 > Thanks a lot. > Regards > --=20 > La prueba m=E1s fehaciente de que existe vida inteligente en otros > planetas, es que no han intentado contactar con nosotros.=20 >=20 > ----- End forwarded message ----- >=20 > --=20 > La prueba m=E1s fehaciente de que existe vida inteligente en otros > planetas, es que no han intentado contactar con nosotros.=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 Wed Feb 8 18:01:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 263911065674 for ; Wed, 8 Feb 2012 18:01:04 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id CB5548FC19 for ; Wed, 8 Feb 2012 18:01:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LZ300L6461QJNB0@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Wed, 08 Feb 2012 19:01:03 +0100 (CET) Received: from kg-v2.kg4.no ([84.215.134.159]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTPA id <0LZ30087A61QVU20@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Wed, 08 Feb 2012 19:01:02 +0100 (CET) Date: Wed, 08 Feb 2012 19:01:02 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20120208190102.a01fe9c6.torfinn.ingolfsen@broadpark.no> In-reply-to: References: <20120202212222.e940f64c.torfinn.ingolfsen@broadpark.no> <20120203204110.cc933dc5.torfinn.ingolfsen@broadpark.no> <20120204043756.GA67863@DataIX.net> <20120204164423.ba815842.torfinn.ingolfsen@broadpark.no> <20120204165214.6f14f4a5.torfinn.ingolfsen@broadpark.no> <20120204230409.338a597b.torfinn.ingolfsen@broadpark.no> <20120207195607.919234a7.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD 8.2-stable: devd fails to restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 18:01:04 -0000 On Tue, 07 Feb 2012 12:16:15 -0700 (MST) Warren Block wrote: > > It's devd, IMO. Hey, come to think of it, I did enter a PR, the one > above. If this is still a problem in 9 (which I can test in a bit), > posting to -current might get some needed attention on it. PR updated. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 18:25:40 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C33FD106564A for ; Wed, 8 Feb 2012 18:25:40 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 195538FC15 for ; Wed, 8 Feb 2012 18:25:38 +0000 (UTC) Received: from [192.168.248.33] ([192.168.248.33]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q18IPMWk000304 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 Feb 2012 23:25:22 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F32BE0B.7000703@norma.perm.ru> Date: Thu, 09 Feb 2012 00:25:15 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <20120208131537.00004c01@unknown> In-Reply-To: <20120208131537.00004c01@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 08 Feb 2012 23:25:23 +0500 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 18:25:40 -0000 Hi. On 08.02.2012 18:15, Alexander Leidinger wrote: > I can't remember to have seen any mention of SWAP on ZFS being safe > now. So if nobody can provide a reference to a place which tells that > the problems with SWAP on ZFS are fixed: > 1. do not use SWAP on ZFS > 2. see 1. > 3. check if you see the same problem without SWAP on ZFS (btw. see 1.) > So, if a swap have to be used, and, it has to be backed up with something like gmirror so it won't come down with one of the disks, there's no need to use zfs for system. This makes zfs only useful in cases where you need to store something on a couple+ of terabytes, still having OS on ufs. Occam's razor and so on. Thanks for explanation. Eugene. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 18:40:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F971065672 for ; Wed, 8 Feb 2012 18:40:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19BAC8FC0C for ; Wed, 8 Feb 2012 18:40:13 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so810432vbb.13 for ; Wed, 08 Feb 2012 10:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=205JHB3aSxsKcgalM5oVqWuCz4QsEYAen5vzE6lEbzg=; b=mtmQk0ctwRUOJg9cK7uq6Oxm0Epr/3pYSofMxw3B++ThdV1zVBE39j/j658sbxsu1D 7Yqd6VlPM4XC40svQzA9jLViQcm0CbAMDXSFMC9lQwsZaXy/2h+6kJIbDMrm4js7oyNW UqkinDRPhNGjgLDH1SVXryp2WUTsHVnj5IH/c= MIME-Version: 1.0 Received: by 10.52.33.239 with SMTP id u15mr12713060vdi.49.1328726413183; Wed, 08 Feb 2012 10:40:13 -0800 (PST) Received: by 10.220.181.4 with HTTP; Wed, 8 Feb 2012 10:40:12 -0800 (PST) In-Reply-To: <4F32BE0B.7000703@norma.perm.ru> References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <20120208131537.00004c01@unknown> <4F32BE0B.7000703@norma.perm.ru> Date: Wed, 8 Feb 2012 10:40:12 -0800 Message-ID: From: Freddie Cash To: "Eugene M. Zheganin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 18:40:14 -0000 On Wed, Feb 8, 2012 at 10:25 AM, Eugene M. Zheganin wro= te: > On 08.02.2012 18:15, Alexander Leidinger wrote: >> I can't remember to have seen any mention of SWAP on ZFS being safe >> now. So if nobody can provide a reference to a place which tells that >> the problems with SWAP on ZFS are fixed: >> =C2=A01. do not use SWAP on ZFS >> =C2=A02. see 1. >> =C2=A03. check if you see the same problem without SWAP on ZFS (btw. see= 1.) >> > So, if a swap have to be used, and, it has to be backed up with something > like gmirror so it won't come down with one of the disks, there's no need= to > use zfs for system. > > This makes zfs only useful in cases where you need to store something on = a > couple+ of terabytes, still having OS on ufs. Occam's razor and so on. Or, you plug a USB stick into the back (or even inside the case as a lot of mobos have internal USB connectors now) and use that for swap. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 18:40:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1891065672 for ; Wed, 8 Feb 2012 18:40:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1337F8FC14 for ; Wed, 8 Feb 2012 18:40:45 +0000 (UTC) Received: by vcmm1 with SMTP id m1so817441vcm.13 for ; Wed, 08 Feb 2012 10:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=abZF8ULYPDB3Sg1emaka80UjTj6DJiQaAft9o5r4reg=; b=cEe5CFnP5N6g8kY6J4+abUpbOxa03RtMmxvuNDL4zb4IK8lktOoFCmbCFxAMbRU4Ep GJN5SI5+0yD0GNCKsnza8a7JYu3dUag9MZ3o8qVi6Ni6N2bdQMZXeZju8Jc5+2pL1kCq 01snZq8dTm44UAKTmhTG89Y+3nxw7RbsVPB4M= MIME-Version: 1.0 Received: by 10.52.33.239 with SMTP id u15mr12713684vdi.49.1328726445282; Wed, 08 Feb 2012 10:40:45 -0800 (PST) Received: by 10.220.181.4 with HTTP; Wed, 8 Feb 2012 10:40:45 -0800 (PST) In-Reply-To: References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <20120208131537.00004c01@unknown> <4F32BE0B.7000703@norma.perm.ru> Date: Wed, 8 Feb 2012 10:40:45 -0800 Message-ID: From: Freddie Cash To: "Eugene M. Zheganin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 18:40:46 -0000 On Wed, Feb 8, 2012 at 10:40 AM, Freddie Cash wrote: > On Wed, Feb 8, 2012 at 10:25 AM, Eugene M. Zheganin w= rote: >> On 08.02.2012 18:15, Alexander Leidinger wrote: >>> I can't remember to have seen any mention of SWAP on ZFS being safe >>> now. So if nobody can provide a reference to a place which tells that >>> the problems with SWAP on ZFS are fixed: >>> =C2=A01. do not use SWAP on ZFS >>> =C2=A02. see 1. >>> =C2=A03. check if you see the same problem without SWAP on ZFS (btw. se= e 1.) >>> >> So, if a swap have to be used, and, it has to be backed up with somethin= g >> like gmirror so it won't come down with one of the disks, there's no nee= d to >> use zfs for system. >> >> This makes zfs only useful in cases where you need to store something on= a >> couple+ of terabytes, still having OS on ufs. Occam's razor and so on. > > Or, you plug a USB stick into the back (or even inside the case as a > lot of mobos have internal USB connectors now) and use that for swap. That also works well for adding L2ARC (cache) to the ZFS pool as well. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 20:29:48 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97595106564A for ; Wed, 8 Feb 2012 20:29:48 +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 DE31B8FC14 for ; Wed, 8 Feb 2012 20:29:47 +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 WAA17155; Wed, 08 Feb 2012 22:29:38 +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 1RvE94-0001yu-GI; Wed, 08 Feb 2012 22:29:38 +0200 Message-ID: <4F32DB30.6020600@FreeBSD.org> Date: Wed, 08 Feb 2012 22:29:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> In-Reply-To: <4F324F10.2060508@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 20:29:48 -0000 on 08/02/2012 12:31 Eugene M. Zheganin said the following: > Hi. > > On 08.02.2012 02:17, Andriy Gapon wrote: >> [output snipped] >> >> Thank you. I don't see anything suspicious/unusual there. >> Just case, do you have ZFS dedup enabled by a chance? >> >> I think that examination of vmstat -m and vmstat -z outputs may provide some >> clues as to what got all that memory wired. >> > Nope, I don't have deduplication feature enabled. OK. So, did you have a chance to inspect vmstat -m and vmstat -z? > By the way, today, after eating another 100M of wired memory this server hanged > out with multiple non-stopping messages > > swap_pager: indefinite wait buffer > > Since it's swapping on zvol, it looks to me like it could be the mentioned in > another thread here ("Swap on zvol - recommendable?") resource starvation issue; > may be it happens faster when the ARC isn't limited. It could be very well possible that swap on zvol doesn't work well when the kernel itself is starved on memory. > So I want to ask - how to report it and what should I include in such pr ? I am leaving swap-on-zvol issue aside. Your original problem doesn't seem to be ZFS-related. I suspect that you might be running into some kernel memory leak. If you manage to reproduce the high wired value again, then vmstat -m and vmstat -z may provide some useful information. In this vein, do you use any out-of-tree kernel modules? Also, can you try to monitor your system to see when wired count grows? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 20:50:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61E6106564A for ; Wed, 8 Feb 2012 20:50:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id C30FB8FC15 for ; Wed, 8 Feb 2012 20:50:02 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta11.emeryville.ca.mail.comcast.net with comcast id XYH71i0091wfjNsABYq2XB; Wed, 08 Feb 2012 20:50:02 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.emeryville.ca.mail.comcast.net with comcast id XYq01i00q1t3BNj8jYq1K7; Wed, 08 Feb 2012 20:50:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C32BA102C1E; Wed, 8 Feb 2012 12:50:00 -0800 (PST) Date: Wed, 8 Feb 2012 12:50:00 -0800 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20120208205000.GA25700@icarus.home.lan> References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F32DB30.6020600@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Eugene M. Zheganin" , freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 20:50:03 -0000 On Wed, Feb 08, 2012 at 10:29:36PM +0200, Andriy Gapon wrote: > on 08/02/2012 12:31 Eugene M. Zheganin said the following: > > Hi. > > > > On 08.02.2012 02:17, Andriy Gapon wrote: > >> [output snipped] > >> > >> Thank you. I don't see anything suspicious/unusual there. > >> Just case, do you have ZFS dedup enabled by a chance? > >> > >> I think that examination of vmstat -m and vmstat -z outputs may provide some > >> clues as to what got all that memory wired. > >> > > Nope, I don't have deduplication feature enabled. > > OK. So, did you have a chance to inspect vmstat -m and vmstat -z? Andriy, Politely -- recommending this to a user is a good choice of action, but the problem is that no user, even an experienced user, is going to know what all of the "Types" (vmstat -m) or "ITEMs" (vmstat -z) correlate with on the system. For example, for vmstat -m, the ITEM name is "solaris". For vmstat -z, the Types are named zio_* but I have a feeling there are more than just that which pertain to ZFS. I'm having to make *assumptions*. The FreeBSD VM is highly complex and is not "easy to understand" even remotely. It becomes more complex when you consider that we use terms like "wired", "active", "inactive", "cache", and "free" -- and none of them, in simple English terms, actually represent the words chosen for what they do. Furthermore, the only definition I've been able to find over the years for how any of these work, what they do/mean, etc. is here: http://www.freebsd.org/doc/en/books/arch-handbook/vm.html And this piece of documentation is only useful for people who understand VMs (note: it was written by Matt Dillon, for example). It is not useful for end-users trying to track down what within the kernel is actually eating up memory. "vmstat -m" is as best as it's going to get, and like I said, with the ITEM names being borderline ambiguous (depending on what you're looking for -- with VFS and so on it's spread all over the place), this becomes a very tedious task, where the user or admin have to continually ask developers on the mailing lists what it is they're looking at. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 21:00:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7971065670 for ; Wed, 8 Feb 2012 21:00:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id CEEF28FC0A for ; Wed, 8 Feb 2012 21:00:58 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q18L0u6q005099 for ; Wed, 8 Feb 2012 16:00:56 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F32E289.4080806@sentex.net> Date: Wed, 08 Feb 2012 16:00:57 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Subject: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 21:00:59 -0000 I have a 4 port eSata PCIe card with 3 external port multipliers attached on an AMD64 box (8G of RAM), RELENG8 from Feb1st. siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI-X to Serial ATA Controller (SiI 3124)' class = mass storage subclass = RAID bar [10] = type Memory, range 64, base 0xb4408000, size 128, enabled bar [18] = type Memory, range 64, base 0xb4400000, size 32768, enabled bar [20] = type I/O Port, range 32, base 0x3000, size 16, enabled cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message siis0: port 0x3000-0x300f mem 0xb4408000-0xb440807f,0xb4400000-0xb4407fff irq 19 at device 0.0 on pci5 siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [ITHREAD] # camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus0 target 1 lun 0 (pass1,ada1) at scbus0 target 2 lun 0 (pass2,ada2) at scbus0 target 3 lun 0 (pass3,ada3) at scbus0 target 15 lun 0 (pass4,pmp1) at scbus1 target 0 lun 0 (pass5,ada4) at scbus1 target 1 lun 0 (pass6,ada5) at scbus1 target 2 lun 0 (pass7,ada6) at scbus1 target 3 lun 0 (pass8,ada7) at scbus1 target 4 lun 0 (pass9,ada8) at scbus1 target 15 lun 0 (pass10,pmp0) at scbus4 target 0 lun 0 (pass11,da0) at scbus4 target 0 lun 1 (pass12,da1) at scbus4 target 16 lun 0 (pass13) at scbus5 target 0 lun 0 (pass14,da2) at scbus6 target 0 lun 0 (pass15,ada9) at scbus7 target 0 lun 0 (pass16,ada10) at scbus8 target 0 lun 0 (pass17,ada11) at scbus11 target 0 lun 0 (pass18,ada12) Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 47000000 Feb 7 23:49:32 backup3 kernel: siisch1: Timeout on slot 26 Feb 7 23:49:32 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 43000000 Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 30 Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 03000000 Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 25 Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 01000000 Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 24 Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 Feb 7 23:57:59 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 00:13:36 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 00:21:53 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 00:22:16 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 00:39:13 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 01:24:25 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 01:33:52 backup3 last message repeated 2 times Feb 8 01:43:45 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 01:50:31 backup3 last message repeated 2 times Feb 8 01:55:20 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 02:26:26 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 02:27:24 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 03:16:28 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 03:36:20 backup3 kernel: siisch1: Error while READ LOG EXT Feb 8 04:04:05 backup3 kernel: siisch1: Error while READ LOG EXT smartctl doesnt show any issues on the drives other than one that has some historical errors from a while ago. What are these errors and do I need to worry about them ? The "READ LOG EXT" ones are new. This is the only drive with anything in its logs so not sure if this is causing the driver to complain smartctl -a /dev/ada9 smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 Device Model: ST31000333AS Serial Number: 9TE14SRV LU WWN Device Id: 5 000c50 010a39664 Firmware Version: SD35 User Capacity: 1,000,204,886,016 bytes [1.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Wed Feb 8 15:49:12 2012 EST ==> WARNING: There are known problems with these drives, see the following Seagate web pages: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207957 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 617) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 203) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 111 099 006 Pre-fail Always - 41201023 3 Spin_Up_Time 0x0003 093 092 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 68 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 2 7 Seek_Error_Rate 0x000f 088 060 030 Pre-fail Always - 791743293 9 Power_On_Hours 0x0032 075 075 000 Old_age Always - 22755 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 2 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 68 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 095 095 000 Old_age Always - 5 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 001 001 000 Old_age Always - 961 190 Airflow_Temperature_Cel 0x0022 065 056 045 Old_age Always - 35 (Min/Max 33/37) 194 Temperature_Celsius 0x0022 035 044 000 Old_age Always - 35 (0 25 0 0) 195 Hardware_ECC_Recovered 0x001a 049 030 000 Old_age Always - 41201023 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 5 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 5 occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 1a ff ff ff 4f 00 11d+02:29:18.542 READ FPDMA QUEUED 60 00 1a ff ff ff 4f 00 11d+02:29:18.542 READ FPDMA QUEUED 60 00 1b ff ff ff 4f 00 11d+02:29:18.541 READ FPDMA QUEUED 60 00 19 ff ff ff 4f 00 11d+02:29:18.541 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:18.541 READ FPDMA QUEUED Error 4 occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 1a ff ff ff 4f 00 11d+02:29:15.783 READ FPDMA QUEUED 60 00 1a ff ff ff 4f 00 11d+02:29:15.780 READ FPDMA QUEUED 60 00 1b ff ff ff 4f 00 11d+02:29:15.732 READ FPDMA QUEUED 60 00 19 ff ff ff 4f 00 11d+02:29:15.732 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:15.731 READ FPDMA QUEUED Error 3 occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 1b ff ff ff 4f 00 11d+02:29:12.889 READ FPDMA QUEUED 60 00 19 ff ff ff 4f 00 11d+02:29:12.889 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:12.888 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:12.888 READ FPDMA QUEUED 60 00 1a ff ff ff 4f 00 11d+02:29:12.888 READ FPDMA QUEUED Error 2 occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 1b ff ff ff 4f 00 11d+02:29:10.011 READ FPDMA QUEUED 60 00 19 ff ff ff 4f 00 11d+02:29:10.011 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:10.010 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:10.010 READ FPDMA QUEUED 60 00 1a ff ff ff 4f 00 11d+02:29:10.010 READ FPDMA QUEUED Error 1 occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 1b ff ff ff 4f 00 11d+02:29:07.148 READ FPDMA QUEUED 60 00 19 ff ff ff 4f 00 11d+02:29:07.140 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:07.131 READ FPDMA QUEUED 60 00 1c ff ff ff 4f 00 11d+02:29:07.117 READ FPDMA QUEUED 60 00 35 ff ff ff 4f 00 11d+02:29:07.111 READ FPDMA QUEUED SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 21:18:14 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D021065676 for ; Wed, 8 Feb 2012 21:18:14 +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 35FD78FC18 for ; Wed, 8 Feb 2012 21:18:13 +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 XAA17609; Wed, 08 Feb 2012 23:18:03 +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 1RvEtu-00020Q-U6; Wed, 08 Feb 2012 23:18:02 +0200 Message-ID: <4F32E68A.5060607@FreeBSD.org> Date: Wed, 08 Feb 2012 23:18:02 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <20120208205000.GA25700@icarus.home.lan> In-Reply-To: <20120208205000.GA25700@icarus.home.lan> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Eugene M. Zheganin" , freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 21:18:15 -0000 on 08/02/2012 22:50 Jeremy Chadwick said the following: > Politely -- recommending this to a user is a good choice of action, but > the problem is that no user, even an experienced user, is going to know > what all of the "Types" (vmstat -m) or "ITEMs" (vmstat -z) correlate > with on the system. I see no problem with users sharing the output and asking for help interpreting it. I do not know of any easier way to analyze problems like this one. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 21:27:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91AB8106564A for ; Wed, 8 Feb 2012 21:27:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3E98C8FC08 for ; Wed, 8 Feb 2012 21:27:24 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id XY9D1i0391c6gX857ZTRPl; Wed, 08 Feb 2012 21:27:25 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.westchester.pa.mail.comcast.net with comcast id XZTQ1i00j1t3BNj3jZTQ6G; Wed, 08 Feb 2012 21:27:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 12883102C1E; Wed, 8 Feb 2012 13:27:23 -0800 (PST) Date: Wed, 8 Feb 2012 13:27:23 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120208212723.GA26263@icarus.home.lan> References: <4F32E289.4080806@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F32E289.4080806@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-STABLE Mailing List Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 21:27:25 -0000 On Wed, Feb 08, 2012 at 04:00:57PM -0500, Mike Tancsa wrote: > I have a 4 port eSata PCIe card with 3 external port multipliers attached on an AMD64 box (8G of RAM), RELENG8 from Feb1st. > > siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'PCI-X to Serial ATA Controller (SiI 3124)' > class = mass storage > subclass = RAID > bar [10] = type Memory, range 64, base 0xb4408000, size 128, enabled > bar [18] = type Memory, range 64, base 0xb4400000, size 32768, enabled > bar [20] = type I/O Port, range 32, base 0x3000, size 16, enabled > cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions > cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message > > siis0: port 0x3000-0x300f mem 0xb4408000-0xb440807f,0xb4400000-0xb4407fff irq 19 at device 0.0 on pci5 > siis0: [ITHREAD] > siisch0: at channel 0 on siis0 > siisch0: [ITHREAD] > siisch1: at channel 1 on siis0 > siisch1: [ITHREAD] > siisch2: at channel 2 on siis0 > siisch2: [ITHREAD] > siisch3: at channel 3 on siis0 > siisch3: [ITHREAD] > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) > at scbus0 target 1 lun 0 (pass1,ada1) > at scbus0 target 2 lun 0 (pass2,ada2) > at scbus0 target 3 lun 0 (pass3,ada3) > at scbus0 target 15 lun 0 (pass4,pmp1) > at scbus1 target 0 lun 0 (pass5,ada4) > at scbus1 target 1 lun 0 (pass6,ada5) > at scbus1 target 2 lun 0 (pass7,ada6) > at scbus1 target 3 lun 0 (pass8,ada7) > at scbus1 target 4 lun 0 (pass9,ada8) > at scbus1 target 15 lun 0 (pass10,pmp0) > at scbus4 target 0 lun 0 (pass11,da0) > at scbus4 target 0 lun 1 (pass12,da1) > at scbus4 target 16 lun 0 (pass13) > at scbus5 target 0 lun 0 (pass14,da2) > at scbus6 target 0 lun 0 (pass15,ada9) > at scbus7 target 0 lun 0 (pass16,ada10) > at scbus8 target 0 lun 0 (pass17,ada11) > at scbus11 target 0 lun 0 (pass18,ada12) > > > Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. > > > Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 47000000 > Feb 7 23:49:32 backup3 kernel: siisch1: Timeout on slot 26 > Feb 7 23:49:32 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 43000000 > Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 30 > Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 03000000 > Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 25 > Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 01000000 > Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 24 > Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 This indicates the controller on channel 1 (siisch1) is "stalled" waiting for underlying communication with the device attached to it. > Feb 7 23:57:59 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 00:13:36 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 00:21:53 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 00:22:16 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 00:39:13 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 01:24:25 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 01:33:52 backup3 last message repeated 2 times > Feb 8 01:43:45 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 01:50:31 backup3 last message repeated 2 times > Feb 8 01:55:20 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 02:26:26 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 02:27:24 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 03:16:28 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 03:36:20 backup3 kernel: siisch1: Error while READ LOG EXT > Feb 8 04:04:05 backup3 kernel: siisch1: Error while READ LOG EXT This indicates the underlying device was handed a READ LOG EXT ATA command (command 0x2f) and the device did not respond promptly (resulting in the timeout messages you see). > smartctl doesnt show any issues on the drives other than one that has some historical errors from a while ago. What are these errors and do I need to worry about them ? The "READ LOG EXT" ones are new. > > {snipping SMART stats} You're focused heavily on the READ LOG EXT command. READ LOG EXT is intended for accessing the GP Log section of a drive. EXT stands for "Extended". "GP Log" means "General Purpose Log", and is where all sorts of logging information regarding drive performance is stored. It's usually stored within a reserved section of the platters, or in the HPA area. It's not within a "standard" user-accessible LBA/sector region. This is a completely separate log from that of SMART logs. You can review the different types of "logs" on a device by reviewing the ATA8-ACS specification here. See Annex A, section A.1, page 362: http://www.t13.org/documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf This is almost certainly a lower level problem with the disk that cannot be addressed/solved via normal means. Thus, my recommendation is to replace the disk. If you would rather not replace the disk, I can try to step you through looking at the GPLog sections of the disk to see if you can trigger the problem -- and I have a feeling you'll be able to, but I won't necessarily be able to tell you where the actual problem lies hardware-wise, nor will I be able to solve the problem. Regarding the repeated errors at semi-regular (but not entirely) intervals: are you using smartd? Do you have a cronjob that issues smartctl -a or smartctl -x commands at intervals? I imagine any of these could be tickling something lower level. Also, please upgrade your smartmontools to 5.42. It does provide some further enhancements that are useful. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 21:32:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B8F106572B for ; Wed, 8 Feb 2012 21:32:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id EC7DE8FC14 for ; Wed, 8 Feb 2012 21:32:48 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta06.emeryville.ca.mail.comcast.net with comcast id XZRS1i00816AWCUA6ZYoaY; Wed, 08 Feb 2012 21:32:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id XZYn1i00E1t3BNj8SZYnvH; Wed, 08 Feb 2012 21:32:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6ACBD102C1E; Wed, 8 Feb 2012 13:32:47 -0800 (PST) Date: Wed, 8 Feb 2012 13:32:47 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120208213247.GA26554@icarus.home.lan> References: <4F32E289.4080806@sentex.net> <20120208212723.GA26263@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120208212723.GA26263@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-STABLE Mailing List Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 21:32:49 -0000 On Wed, Feb 08, 2012 at 01:27:23PM -0800, Jeremy Chadwick wrote: > On Wed, Feb 08, 2012 at 04:00:57PM -0500, Mike Tancsa wrote: > > Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. BTW, something I forgot to cover in my reply: the slot number shown in the output (e.g. "Timeout on slot NN") has nothing to do with "port number", "connector", or anything like that. It's an internal controller feature; AHCI offers the same thing. I performed rudimentary analysis on this back in April 2011 by reviewing the code and a small write-up on it (semi-technical): http://lists.freebsd.org/pipermail/freebsd-fs/2011-April/011197.html Taken from my post at that time, which is what I'm wanting to relay here: "Timeout on slot N" != SATA port N. Two unrelated things. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 22:22:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC02A10656D0 for ; Wed, 8 Feb 2012 22:22:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 33C3A8FC16 for ; Wed, 8 Feb 2012 22:22:52 +0000 (UTC) Received: by eekb47 with SMTP id b47so395266eek.13 for ; Wed, 08 Feb 2012 14:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jGgLq1ocNW/GO/IFLBKIDYKVjkOyZLkymMvR+WNKBfI=; b=AqeN0a54lIp1RRVnvP6LsXqnCODcfRKD7z/Qea6crE+XdaJq/UmI151jkVzZ3m4y+W 98PjfMs79uJ6wldsFwgq24kZs8mfCDzI1k+IPdFlDtlkYAJp0IxgswYxAR/1hgLkLxVd +zoVVFSgHKX27C9OBKZBl39YMefhD8Iral6bU= Received: by 10.14.40.14 with SMTP id e14mr9140711eeb.18.1328739771187; Wed, 08 Feb 2012 14:22:51 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id c16sm2182152eei.1.2012.02.08.14.22.49 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 14:22:50 -0800 (PST) Sender: Alexander Motin Message-ID: <4F32F5B0.2060203@FreeBSD.org> Date: Thu, 09 Feb 2012 00:22:40 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 22:22:53 -0000 On 08.02.2012 23:27, Jeremy Chadwick wrote: > On Wed, Feb 08, 2012 at 04:00:57PM -0500, Mike Tancsa wrote: >> I have a 4 port eSata PCIe card with 3 external port multipliers attached on an AMD64 box (8G of RAM), RELENG8 from Feb1st. >> >> siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 >> vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' >> device = 'PCI-X to Serial ATA Controller (SiI 3124)' >> class = mass storage >> subclass = RAID >> bar [10] = type Memory, range 64, base 0xb4408000, size 128, enabled >> bar [18] = type Memory, range 64, base 0xb4400000, size 32768, enabled >> bar [20] = type I/O Port, range 32, base 0x3000, size 16, enabled >> cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 >> cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions >> cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message >> >> siis0: port 0x3000-0x300f mem 0xb4408000-0xb440807f,0xb4400000-0xb4407fff irq 19 at device 0.0 on pci5 >> siis0: [ITHREAD] >> siisch0: at channel 0 on siis0 >> siisch0: [ITHREAD] >> siisch1: at channel 1 on siis0 >> siisch1: [ITHREAD] >> siisch2: at channel 2 on siis0 >> siisch2: [ITHREAD] >> siisch3: at channel 3 on siis0 >> siisch3: [ITHREAD] >> >> # camcontrol devlist >> at scbus0 target 0 lun 0 (pass0,ada0) >> at scbus0 target 1 lun 0 (pass1,ada1) >> at scbus0 target 2 lun 0 (pass2,ada2) >> at scbus0 target 3 lun 0 (pass3,ada3) >> at scbus0 target 15 lun 0 (pass4,pmp1) >> at scbus1 target 0 lun 0 (pass5,ada4) >> at scbus1 target 1 lun 0 (pass6,ada5) >> at scbus1 target 2 lun 0 (pass7,ada6) >> at scbus1 target 3 lun 0 (pass8,ada7) >> at scbus1 target 4 lun 0 (pass9,ada8) >> at scbus1 target 15 lun 0 (pass10,pmp0) >> at scbus4 target 0 lun 0 (pass11,da0) >> at scbus4 target 0 lun 1 (pass12,da1) >> at scbus4 target 16 lun 0 (pass13) >> at scbus5 target 0 lun 0 (pass14,da2) >> at scbus6 target 0 lun 0 (pass15,ada9) >> at scbus7 target 0 lun 0 (pass16,ada10) >> at scbus8 target 0 lun 0 (pass17,ada11) >> at scbus11 target 0 lun 0 (pass18,ada12) >> >> >> Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. >> >> >> Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 47000000 >> Feb 7 23:49:32 backup3 kernel: siisch1: Timeout on slot 26 >> Feb 7 23:49:32 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >> Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 43000000 >> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 30 >> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >> Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 03000000 >> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 25 >> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >> Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 01000000 >> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 24 >> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > > This indicates the controller on channel 1 (siisch1) is "stalled" > waiting for underlying communication with the device attached to it. > >> Feb 7 23:57:59 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 00:13:36 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 00:21:53 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 00:22:16 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 00:39:13 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 01:24:25 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 01:33:52 backup3 last message repeated 2 times >> Feb 8 01:43:45 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 01:50:31 backup3 last message repeated 2 times >> Feb 8 01:55:20 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 02:26:26 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 02:27:24 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 03:16:28 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 03:36:20 backup3 kernel: siisch1: Error while READ LOG EXT >> Feb 8 04:04:05 backup3 kernel: siisch1: Error while READ LOG EXT > > This indicates the underlying device was handed a READ LOG EXT ATA > command (command 0x2f) and the device did not respond promptly > (resulting in the timeout messages you see). There are hours between timeouts and READ LOG EXT errors. they are not directly related, but may have the same reason. >> smartctl doesnt show any issues on the drives other than one that has some historical errors from a while ago. What are these errors and do I need to worry about them ? The "READ LOG EXT" ones are new. >> >> {snipping SMART stats} > > You're focused heavily on the READ LOG EXT command. READ LOG EXT is > intended for accessing the GP Log section of a drive. EXT stands for > "Extended". "GP Log" means "General Purpose Log", and is where all > sorts of logging information regarding drive performance is stored. > It's usually stored within a reserved section of the platters, or in the > HPA area. It's not within a "standard" user-accessible LBA/sector > region. This is a completely separate log from that of SMART logs. READ LOG EXT commands here used to fetch status of some failed NCQ commands. It is normal (the only) way to get detailed error status in that case. Error of the READ LOG EXT commands may mean that it is not regular media error, but may be problem with communication, firmware or something else. > You can review the different types of "logs" on a device by reviewing > the ATA8-ACS specification here. See Annex A, section A.1, page 362: > > http://www.t13.org/documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf > > This is almost certainly a lower level problem with the disk that cannot > be addressed/solved via normal means. Thus, my recommendation is to > replace the disk. > > If you would rather not replace the disk, I can try to step you through > looking at the GPLog sections of the disk to see if you can trigger the > problem -- and I have a feeling you'll be able to, but I won't > necessarily be able to tell you where the actual problem lies > hardware-wise, nor will I be able to solve the problem. > > Regarding the repeated errors at semi-regular (but not entirely) > intervals: are you using smartd? Do you have a cronjob that issues > smartctl -a or smartctl -x commands at intervals? I imagine any of > these could be tickling something lower level. > > Also, please upgrade your smartmontools to 5.42. It does provide some > further enhancements that are useful. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 22:38:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 266A21065674 for ; Wed, 8 Feb 2012 22:38:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7048FC16 for ; Wed, 8 Feb 2012 22:38:20 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta09.emeryville.ca.mail.comcast.net with comcast id XaYS1i0090EPchoA9aeLV7; Wed, 08 Feb 2012 22:38:20 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id XaeK1i00b1t3BNj8MaeKuQ; Wed, 08 Feb 2012 22:38:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3F578102C1E; Wed, 8 Feb 2012 14:38:19 -0800 (PST) Date: Wed, 8 Feb 2012 14:38:19 -0800 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20120208223819.GA27488@icarus.home.lan> References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F32F5B0.2060203@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 22:38:21 -0000 On Thu, Feb 09, 2012 at 12:22:40AM +0200, Alexander Motin wrote: > On 08.02.2012 23:27, Jeremy Chadwick wrote: > >On Wed, Feb 08, 2012 at 04:00:57PM -0500, Mike Tancsa wrote: > >>I have a 4 port eSata PCIe card with 3 external port multipliers attached on an AMD64 box (8G of RAM), RELENG8 from Feb1st. > >> > >>siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 > >> vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > >> device = 'PCI-X to Serial ATA Controller (SiI 3124)' > >> class = mass storage > >> subclass = RAID > >> bar [10] = type Memory, range 64, base 0xb4408000, size 128, enabled > >> bar [18] = type Memory, range 64, base 0xb4400000, size 32768, enabled > >> bar [20] = type I/O Port, range 32, base 0x3000, size 16, enabled > >> cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions > >> cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message > >> > >>siis0: port 0x3000-0x300f mem 0xb4408000-0xb440807f,0xb4400000-0xb4407fff irq 19 at device 0.0 on pci5 > >>siis0: [ITHREAD] > >>siisch0: at channel 0 on siis0 > >>siisch0: [ITHREAD] > >>siisch1: at channel 1 on siis0 > >>siisch1: [ITHREAD] > >>siisch2: at channel 2 on siis0 > >>siisch2: [ITHREAD] > >>siisch3: at channel 3 on siis0 > >>siisch3: [ITHREAD] > >> > >># camcontrol devlist > >> at scbus0 target 0 lun 0 (pass0,ada0) > >> at scbus0 target 1 lun 0 (pass1,ada1) > >> at scbus0 target 2 lun 0 (pass2,ada2) > >> at scbus0 target 3 lun 0 (pass3,ada3) > >> at scbus0 target 15 lun 0 (pass4,pmp1) > >> at scbus1 target 0 lun 0 (pass5,ada4) > >> at scbus1 target 1 lun 0 (pass6,ada5) > >> at scbus1 target 2 lun 0 (pass7,ada6) > >> at scbus1 target 3 lun 0 (pass8,ada7) > >> at scbus1 target 4 lun 0 (pass9,ada8) > >> at scbus1 target 15 lun 0 (pass10,pmp0) > >> at scbus4 target 0 lun 0 (pass11,da0) > >> at scbus4 target 0 lun 1 (pass12,da1) > >> at scbus4 target 16 lun 0 (pass13) > >> at scbus5 target 0 lun 0 (pass14,da2) > >> at scbus6 target 0 lun 0 (pass15,ada9) > >> at scbus7 target 0 lun 0 (pass16,ada10) > >> at scbus8 target 0 lun 0 (pass17,ada11) > >> at scbus11 target 0 lun 0 (pass18,ada12) > >> > >> > >>Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. > >> > >> > >>Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 47000000 > >>Feb 7 23:49:32 backup3 kernel: siisch1: Timeout on slot 26 > >>Feb 7 23:49:32 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > >>Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 43000000 > >>Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 30 > >>Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > >>Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 03000000 > >>Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 25 > >>Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > >>Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 01000000 > >>Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 24 > >>Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 > > > >This indicates the controller on channel 1 (siisch1) is "stalled" > >waiting for underlying communication with the device attached to it. > > > >>Feb 7 23:57:59 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 00:13:36 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 00:21:53 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 00:22:16 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 00:39:13 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 01:24:25 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 01:33:52 backup3 last message repeated 2 times > >>Feb 8 01:43:45 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 01:50:31 backup3 last message repeated 2 times > >>Feb 8 01:55:20 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 02:26:26 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 02:27:24 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 03:16:28 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 03:36:20 backup3 kernel: siisch1: Error while READ LOG EXT > >>Feb 8 04:04:05 backup3 kernel: siisch1: Error while READ LOG EXT > > > >This indicates the underlying device was handed a READ LOG EXT ATA > >command (command 0x2f) and the device did not respond promptly > >(resulting in the timeout messages you see). > > There are hours between timeouts and READ LOG EXT errors. they are > not directly related, but may have the same reason. > > >>smartctl doesnt show any issues on the drives other than one that has some historical errors from a while ago. What are these errors and do I need to worry about them ? The "READ LOG EXT" ones are new. > >> > >>{snipping SMART stats} > > > >You're focused heavily on the READ LOG EXT command. READ LOG EXT is > >intended for accessing the GP Log section of a drive. EXT stands for > >"Extended". "GP Log" means "General Purpose Log", and is where all > >sorts of logging information regarding drive performance is stored. > >It's usually stored within a reserved section of the platters, or in the > >HPA area. It's not within a "standard" user-accessible LBA/sector > >region. This is a completely separate log from that of SMART logs. > > READ LOG EXT commands here used to fetch status of some failed NCQ > commands. It is normal (the only) way to get detailed error status > in that case. Error of the READ LOG EXT commands may mean that it is > not regular media error, but may be problem with communication, > firmware or something else. As usual -- thanks for your fantastic insights, Alexander. I wasn't aware that to get NCQ error conditions you had to read from the GPLog region, I was under the impression this was somehow returned via extended SATA status codes (since I with NCQ the internal ordering CDBs changes). Interesting. NCQ is still something (on an ATA and OS level, for lack of better terminology) I am not fully familiar with, though functionally I understand what it provides/gains. Where in the ata-cam code is this done? I'd like to look at it for educational reasons. Firmware problems are a possibility in this case, but I'm reluctant to believe problems with communication between controller and drive. His CRC error count on the drive itself is zero. So the only communication failure I can think of would be between the controller and the port multiplier (e.g. before anything actually reaches the drive), or some kind of firmware-level problem with the port multiplier device (I believe they do have some sort of ASIC on them? I've never used one). Mike, can you please provide output from the following commands? * smartctl -x /dev/ada9 * smartctl -l sataphy /dev/ada9 * smartctl -l devstat /dev/ada9 * smartctl -l gplog,0x10 /dev/ada9 Note that some of these may fail with some error equivalent to "GPLog 0xXX not supported", and that's perfectly okay. Thank you. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 8 22:47:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76262106564A for ; Wed, 8 Feb 2012 22:47:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F10D08FC14 for ; Wed, 8 Feb 2012 22:47:06 +0000 (UTC) Received: by eaan10 with SMTP id n10so387894eaa.13 for ; Wed, 08 Feb 2012 14:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=793NuQO0e6CxhkF6mFiq7N3dVlMFm1K4v4mSCfIXM2Q=; b=CXRg16HiBfZTIQrkbzIiNpRPx38QaPGYmsDqoGS66NPREi5QRPQm5DXy1EY2FQeSLl 9gfT5cVHEgR8GYdYe7BQ56ePuYxPF6hAzB3Y2IKweEdeJ47g74ZXub2yvQU0QE7mNDgI ukdg8oUqvc+hivU13TDQ5MAzGPeADJMd956pc= Received: by 10.14.95.135 with SMTP id p7mr9003263eef.62.1328741225821; Wed, 08 Feb 2012 14:47:05 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id x4sm2368329eeb.4.2012.02.08.14.47.03 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 14:47:04 -0800 (PST) Sender: Alexander Motin Message-ID: <4F32FB5E.7050102@FreeBSD.org> Date: Thu, 09 Feb 2012 00:46:54 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> In-Reply-To: <20120208223819.GA27488@icarus.home.lan> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2012 22:47:07 -0000 On 09.02.2012 00:38, Jeremy Chadwick wrote: > On Thu, Feb 09, 2012 at 12:22:40AM +0200, Alexander Motin wrote: >> On 08.02.2012 23:27, Jeremy Chadwick wrote: >>> On Wed, Feb 08, 2012 at 04:00:57PM -0500, Mike Tancsa wrote: >>>> I have a 4 port eSata PCIe card with 3 external port multipliers attached on an AMD64 box (8G of RAM), RELENG8 from Feb1st. >>>> >>>> siis0@pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 >>>> vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' >>>> device = 'PCI-X to Serial ATA Controller (SiI 3124)' >>>> class = mass storage >>>> subclass = RAID >>>> bar [10] = type Memory, range 64, base 0xb4408000, size 128, enabled >>>> bar [18] = type Memory, range 64, base 0xb4400000, size 32768, enabled >>>> bar [20] = type I/O Port, range 32, base 0x3000, size 16, enabled >>>> cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions >>>> cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message >>>> >>>> siis0: port 0x3000-0x300f mem 0xb4408000-0xb440807f,0xb4400000-0xb4407fff irq 19 at device 0.0 on pci5 >>>> siis0: [ITHREAD] >>>> siisch0: at channel 0 on siis0 >>>> siisch0: [ITHREAD] >>>> siisch1: at channel 1 on siis0 >>>> siisch1: [ITHREAD] >>>> siisch2: at channel 2 on siis0 >>>> siisch2: [ITHREAD] >>>> siisch3: at channel 3 on siis0 >>>> siisch3: [ITHREAD] >>>> >>>> # camcontrol devlist >>>> at scbus0 target 0 lun 0 (pass0,ada0) >>>> at scbus0 target 1 lun 0 (pass1,ada1) >>>> at scbus0 target 2 lun 0 (pass2,ada2) >>>> at scbus0 target 3 lun 0 (pass3,ada3) >>>> at scbus0 target 15 lun 0 (pass4,pmp1) >>>> at scbus1 target 0 lun 0 (pass5,ada4) >>>> at scbus1 target 1 lun 0 (pass6,ada5) >>>> at scbus1 target 2 lun 0 (pass7,ada6) >>>> at scbus1 target 3 lun 0 (pass8,ada7) >>>> at scbus1 target 4 lun 0 (pass9,ada8) >>>> at scbus1 target 15 lun 0 (pass10,pmp0) >>>> at scbus4 target 0 lun 0 (pass11,da0) >>>> at scbus4 target 0 lun 1 (pass12,da1) >>>> at scbus4 target 16 lun 0 (pass13) >>>> at scbus5 target 0 lun 0 (pass14,da2) >>>> at scbus6 target 0 lun 0 (pass15,ada9) >>>> at scbus7 target 0 lun 0 (pass16,ada10) >>>> at scbus8 target 0 lun 0 (pass17,ada11) >>>> at scbus11 target 0 lun 0 (pass18,ada12) >>>> >>>> >>>> Ever since I added a new PM, I have been seeing a new error (READ LOG EXT) along with a the odd slot timeout error. >>>> >>>> >>>> Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 47000000 >>>> Feb 7 23:49:32 backup3 kernel: siisch1: Timeout on slot 26 >>>> Feb 7 23:49:32 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >>>> Feb 7 23:49:32 backup3 kernel: siisch1: ... waiting for slots 43000000 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 30 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 03000000 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 25 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: ... waiting for slots 01000000 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: Timeout on slot 24 >>>> Feb 7 23:49:34 backup3 kernel: siisch1: siis_timeout is 07040000 ss 7f17e8b9 rs 7f17e8b9 es 00000000 sts 801d2000 serr 00680000 >>> >>> This indicates the controller on channel 1 (siisch1) is "stalled" >>> waiting for underlying communication with the device attached to it. >>> >>>> Feb 7 23:57:59 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 00:13:36 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 00:21:53 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 00:22:16 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 00:39:13 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 01:24:25 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 01:33:52 backup3 last message repeated 2 times >>>> Feb 8 01:43:45 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 01:50:31 backup3 last message repeated 2 times >>>> Feb 8 01:55:20 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 02:26:26 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 02:27:24 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 03:16:28 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 03:36:20 backup3 kernel: siisch1: Error while READ LOG EXT >>>> Feb 8 04:04:05 backup3 kernel: siisch1: Error while READ LOG EXT >>> >>> This indicates the underlying device was handed a READ LOG EXT ATA >>> command (command 0x2f) and the device did not respond promptly >>> (resulting in the timeout messages you see). >> >> There are hours between timeouts and READ LOG EXT errors. they are >> not directly related, but may have the same reason. >> >>>> smartctl doesnt show any issues on the drives other than one that has some historical errors from a while ago. What are these errors and do I need to worry about them ? The "READ LOG EXT" ones are new. >>>> >>>> {snipping SMART stats} >>> >>> You're focused heavily on the READ LOG EXT command. READ LOG EXT is >>> intended for accessing the GP Log section of a drive. EXT stands for >>> "Extended". "GP Log" means "General Purpose Log", and is where all >>> sorts of logging information regarding drive performance is stored. >>> It's usually stored within a reserved section of the platters, or in the >>> HPA area. It's not within a "standard" user-accessible LBA/sector >>> region. This is a completely separate log from that of SMART logs. >> >> READ LOG EXT commands here used to fetch status of some failed NCQ >> commands. It is normal (the only) way to get detailed error status >> in that case. Error of the READ LOG EXT commands may mean that it is >> not regular media error, but may be problem with communication, >> firmware or something else. > > As usual -- thanks for your fantastic insights, Alexander. > > I wasn't aware that to get NCQ error conditions you had to read from the > GPLog region, I was under the impression this was somehow returned via > extended SATA status codes (since I with NCQ the internal ordering CDBs > changes). Interesting. NCQ is still something (on an ATA and OS level, > for lack of better terminology) I am not fully familiar with, though > functionally I understand what it provides/gains. Where in the ata-cam > code is this done? I'd like to look at it for educational reasons. READ LOG EXT for NCQ, same as REQUEST SENSE for ATAPI sent by every specific controller driver. In this case by siis_issue_recovery() function in dev/siis/siis.c. In case of proper READ LOG EXT completion, fetched status returned to CAM together with original command. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 00:11:41 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E17B510656D0 for ; Thu, 9 Feb 2012 00:11:40 +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 638538FC15 for ; Thu, 9 Feb 2012 00:11:40 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B125628432; Thu, 9 Feb 2012 01:11:38 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2CE6F2842E; Thu, 9 Feb 2012 01:11:37 +0100 (CET) Message-ID: <4F330F38.3010806@quip.cz> Date: Thu, 09 Feb 2012 01:11:36 +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: Andriy Gapon References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> In-Reply-To: <4F32DB30.6020600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eugene M. Zheganin" , freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 00:11:41 -0000 Andriy Gapon wrote: > on 08/02/2012 12:31 Eugene M. Zheganin said the following: >> Hi. >> >> On 08.02.2012 02:17, Andriy Gapon wrote: >>> [output snipped] >>> >>> Thank you. I don't see anything suspicious/unusual there. >>> Just case, do you have ZFS dedup enabled by a chance? >>> >>> I think that examination of vmstat -m and vmstat -z outputs may provide some >>> clues as to what got all that memory wired. >>> >> Nope, I don't have deduplication feature enabled. > > OK. So, did you have a chance to inspect vmstat -m and vmstat -z? > >> By the way, today, after eating another 100M of wired memory this server hanged >> out with multiple non-stopping messages >> >> swap_pager: indefinite wait buffer >> >> Since it's swapping on zvol, it looks to me like it could be the mentioned in >> another thread here ("Swap on zvol - recommendable?") resource starvation issue; >> may be it happens faster when the ARC isn't limited. > > It could be very well possible that swap on zvol doesn't work well when the > kernel itself is starved on memory. > >> So I want to ask - how to report it and what should I include in such pr ? > > I am leaving swap-on-zvol issue aside. Your original problem doesn't seem to be > ZFS-related. I suspect that you might be running into some kernel memory leak. > If you manage to reproduce the high wired value again, then vmstat -m and > vmstat -z may provide some useful information. > > In this vein, do you use any out-of-tree kernel modules? > Also, can you try to monitor your system to see when wired count grows? I am seeing something similar on one of our machine. This is old 7.3 with ZFS v13, that's why I did not reported it. The machine is used as storage for backups made by rsync. All is running fine for about 107 days. Then backups are slower and slower because of some strange memory situation. Mem: 15M Active, 17M Inact, 3620M Wired, 420K Cache, 48M Buf, 1166M Free ARC Size: Current Size: 1769 MB (arcsize) Target Size (Adaptive): 512 MB (c) Min Size (Hard Limit): 512 MB (zfs_arc_min) Max Size (Hard Limit): 3584 MB (zfs_arc_max) The target size is going down to the min size and after few more days, the system is so slow, that I must reboot the machine. Then it is running fine for about 107 days and then it all repeat again. You can see more on MRTG graphs http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ You can see links to other useful informations on top of the page (arc_summary, top, dmesg, fs usage, loader.conf) There you can see nightly backups (higher CPU load started at 01:13), otherwise the machine is idle. It coresponds with ARC target size lowering in last 5 days http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arcstats_size.html And with ARC metadata cache overflowing the limit in last 5 days http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs_meta.html I don't know what's going on and I don't know if it is something know / fixed in newer releases. We are running a few more ZFS systems on 8.2 without this issue. But those systems are in different roles. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 00:28:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082F31065670 for ; Thu, 9 Feb 2012 00:28:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id B7F1C8FC0A for ; Thu, 9 Feb 2012 00:28:38 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id XcNg1i0020ldTLk5EcUfky; Thu, 09 Feb 2012 00:28:39 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta04.westchester.pa.mail.comcast.net with comcast id XcUd1i0081t3BNj3QcUdYl; Thu, 09 Feb 2012 00:28:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F3621102C1E; Wed, 8 Feb 2012 16:28:35 -0800 (PST) Date: Wed, 8 Feb 2012 16:28:35 -0800 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20120209002835.GA29400@icarus.home.lan> References: <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F330F38.3010806@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F330F38.3010806@quip.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Eugene M. Zheganin" , freebsd-stable , mm@freebsd.org, Andriy Gapon Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 00:28:39 -0000 On Thu, Feb 09, 2012 at 01:11:36AM +0100, Miroslav Lachman wrote: > Andriy Gapon wrote: > >on 08/02/2012 12:31 Eugene M. Zheganin said the following: > >>Hi. > >> > >>On 08.02.2012 02:17, Andriy Gapon wrote: > >>>[output snipped] > >>> > >>>Thank you. I don't see anything suspicious/unusual there. > >>>Just case, do you have ZFS dedup enabled by a chance? > >>> > >>>I think that examination of vmstat -m and vmstat -z outputs may provide some > >>>clues as to what got all that memory wired. > >>> > >>Nope, I don't have deduplication feature enabled. > > > >OK. So, did you have a chance to inspect vmstat -m and vmstat -z? > > > >>By the way, today, after eating another 100M of wired memory this server hanged > >>out with multiple non-stopping messages > >> > >>swap_pager: indefinite wait buffer > >> > >>Since it's swapping on zvol, it looks to me like it could be the mentioned in > >>another thread here ("Swap on zvol - recommendable?") resource starvation issue; > >>may be it happens faster when the ARC isn't limited. > > > >It could be very well possible that swap on zvol doesn't work well when the > >kernel itself is starved on memory. > > > >>So I want to ask - how to report it and what should I include in such pr ? > > > >I am leaving swap-on-zvol issue aside. Your original problem doesn't seem to be > >ZFS-related. I suspect that you might be running into some kernel memory leak. > > If you manage to reproduce the high wired value again, then vmstat -m and > >vmstat -z may provide some useful information. > > > >In this vein, do you use any out-of-tree kernel modules? > >Also, can you try to monitor your system to see when wired count grows? > > I am seeing something similar on one of our machine. This is old 7.3 > with ZFS v13, that's why I did not reported it. > > The machine is used as storage for backups made by rsync. All is > running fine for about 107 days. Then backups are slower and slower > because of some strange memory situation. > > Mem: 15M Active, 17M Inact, 3620M Wired, 420K Cache, 48M Buf, 1166M Free > > ARC Size: > Current Size: 1769 MB (arcsize) > Target Size (Adaptive): 512 MB (c) > Min Size (Hard Limit): 512 MB (zfs_arc_min) > Max Size (Hard Limit): 3584 MB (zfs_arc_max) > > The target size is going down to the min size and after few more > days, the system is so slow, that I must reboot the machine. Then it > is running fine for about 107 days and then it all repeat again. > > You can see more on MRTG graphs > http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ > You can see links to other useful informations on top of the page > (arc_summary, top, dmesg, fs usage, loader.conf) > > There you can see nightly backups (higher CPU load started at > 01:13), otherwise the machine is idle. > > It coresponds with ARC target size lowering in last 5 days > http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arcstats_size.html > > And with ARC metadata cache overflowing the limit in last 5 days > http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs_meta.html > > I don't know what's going on and I don't know if it is something > know / fixed in newer releases. We are running a few more ZFS > systems on 8.2 without this issue. But those systems are in > different roles. This sounds like the... damn, what is it called... some kind of internal "counter" or "ticks" thing within the ZFS code that was discovered to only begin happening after a certain period of time (which correlated to some number of days, possibly 107). I'm sorry that I can't be more specific, but it's been discussed heavily on the lists in the past, and fixes for all of that were committed to RELENG_8. I wish I could remember the name of the function or macro or variable name it pertained to, something like LTHAW or TLOCK or something like that. I would say "I don't know why I can't remember", but I do know why I can't remember: because I gave up trying to track all of these problems. Does someone else remember this issue? CC'ing Martin who might remember for certain. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 01:08:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E79541065676; Thu, 9 Feb 2012 01:08:04 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78B0D8FC0A; Thu, 9 Feb 2012 01:08:04 +0000 (UTC) Received: by yenl12 with SMTP id l12so801568yen.13 for ; Wed, 08 Feb 2012 17:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DfpgNDsVDEzbhl16rAXBHnvr67Oaq/0VXzHc1LCuBNA=; b=tW0bR35IoNRSwokosa/pKdXmDf1xBFomoZDaRcm7JKldQqU00UzwqcS9XCefjHJSn2 gY0YYOCuSlB3M7vs/noe6uBBXLIt/xoaf3kfuom16JbQIiqhgM6zqxAXgs7zCuh2vC0X mFEpH0LS3pF53l9FZOSRwBMsALpf+NT9VoPmY= MIME-Version: 1.0 Received: by 10.101.51.12 with SMTP id d12mr11929277ank.69.1328748229003; Wed, 08 Feb 2012 16:43:49 -0800 (PST) Sender: artemb@gmail.com Received: by 10.147.47.6 with HTTP; Wed, 8 Feb 2012 16:43:48 -0800 (PST) In-Reply-To: <20120209002835.GA29400@icarus.home.lan> References: <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F330F38.3010806@quip.cz> <20120209002835.GA29400@icarus.home.lan> Date: Wed, 8 Feb 2012 16:43:48 -0800 X-Google-Sender-Auth: 1490Z5Xe4WXY6GhkC6HY0dvkPm0 Message-ID: From: Artem Belevich To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Eugene M. Zheganin" , freebsd-stable , Miroslav Lachman <000.fbsd@quip.cz>, Andriy Gapon , mm@freebsd.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 01:08:05 -0000 On Wed, Feb 8, 2012 at 4:28 PM, Jeremy Chadwick wrote: > On Thu, Feb 09, 2012 at 01:11:36AM +0100, Miroslav Lachman wrote: ... >> ARC Size: >> =A0 =A0 =A0 =A0 =A0Current Size: =A0 =A0 =A0 =A0 =A0 =A0 1769 MB (arcsiz= e) >> =A0 =A0 =A0 =A0 =A0Target Size (Adaptive): =A0 512 MB (c) >> =A0 =A0 =A0 =A0 =A0Min Size (Hard Limit): =A0 =A0512 MB (zfs_arc_min) >> =A0 =A0 =A0 =A0 =A0Max Size (Hard Limit): =A0 =A03584 MB (zfs_arc_max) >> >> The target size is going down to the min size and after few more >> days, the system is so slow, that I must reboot the machine. Then it >> is running fine for about 107 days and then it all repeat again. >> >> You can see more on MRTG graphs >> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ >> You can see links to other useful informations on top of the page >> (arc_summary, top, dmesg, fs usage, loader.conf) >> >> There you can see nightly backups (higher CPU load started at >> 01:13), otherwise the machine is idle. >> >> It coresponds with ARC target size lowering in last 5 days >> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arc= stats_size.html >> >> And with ARC metadata cache overflowing the limit in last 5 days >> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs= _meta.html >> >> I don't know what's going on and I don't know if it is something >> know / fixed in newer releases. We are running a few more ZFS >> systems on 8.2 without this issue. But those systems are in >> different roles. > > This sounds like the... damn, what is it called... some kind of internal > "counter" or "ticks" thing within the ZFS code that was discovered to > only begin happening after a certain period of time (which correlated to > some number of days, possibly 107). =A0I'm sorry that I can't be more > specific, but it's been discussed heavily on the lists in the past, and > fixes for all of that were committed to RELENG_8. =A0I wish I could > remember the name of the function or macro or variable name it pertained > to, something like LTHAW or TLOCK or something like that. =A0I would say > "I don't know why I can't remember", but I do know why I can't remember: > because I gave up trying to track all of these problems. > > Does someone else remember this issue? =A0CC'ing Martin who might remembe= r > for certain. It's LBOLT. :-) And there was more than one related integer overflow. One of them manifested itself as L2ARC feeding thread hogging CPU time after about a month of uptime. Another one caused issue with ARC reclaim after 107 days. See more details in this thread: http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011584.html --Artem From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 01:08:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3FB8106564A for ; Thu, 9 Feb 2012 01:08:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E728E8FC1E for ; Thu, 9 Feb 2012 01:08:37 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q1918YPR025003; Wed, 8 Feb 2012 20:08:34 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F331C93.8080300@sentex.net> Date: Wed, 08 Feb 2012 20:08:35 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> <20120208212723.GA26263@icarus.home.lan> In-Reply-To: <20120208212723.GA26263@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: FreeBSD-STABLE Mailing List Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 01:08:38 -0000 On 2/8/2012 4:27 PM, Jeremy Chadwick wrote: > > This indicates the controller on channel 1 (siisch1) is "stalled" > waiting for underlying communication with the device attached to it. Hi, But which device ? the PM itself, or the disks behind it ? And which disk ? > > > This is almost certainly a lower level problem with the disk that cannot > be addressed/solved via normal means. Thus, my recommendation is to > replace the disk. I would gladly replace it if I knew which one :) > > Regarding the repeated errors at semi-regular (but not entirely) > intervals: are you using smartd? Do you have a cronjob that issues > smartctl -a or smartctl -x commands at intervals? I imagine any of > these could be tickling something lower level. Dont have smartd running. The box takes a lot of backups as well as a constant stream of netflow data, so a lot of writes to it. > > Also, please upgrade your smartmontools to 5.42. It does provide some > further enhancements that are useful. > Done. # smartctl -x /dev/ada9 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 Device Model: ST31000333AS Serial Number: 9TE14SRV LU WWN Device Id: 5 000c50 010a39664 Firmware Version: SD35 User Capacity: 1,000,204,886,016 bytes [1.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Wed Feb 8 20:00:47 2012 EST ==> WARNING: There are known problems with these drives, see the following Seagate web pages: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207957 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 617) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 203) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-- 112 099 006 - 44490692 3 Spin_Up_Time PO---- 093 092 000 - 0 4 Start_Stop_Count -O--CK 100 100 020 - 68 5 Reallocated_Sector_Ct PO--CK 100 100 036 - 2 7 Seek_Error_Rate POSR-- 088 060 030 - 791764702 9 Power_On_Hours -O--CK 075 075 000 - 22759 10 Spin_Retry_Count PO--C- 100 100 097 - 2 12 Power_Cycle_Count -O--CK 100 100 020 - 68 184 End-to-End_Error -O--CK 100 100 099 - 0 187 Reported_Uncorrect -O--CK 095 095 000 - 5 188 Command_Timeout -O--CK 100 100 000 - 0 189 High_Fly_Writes -O-RCK 001 001 000 - 961 190 Airflow_Temperature_Cel -O---K 066 056 045 - 34 (Min/Max 33/37) 194 Temperature_Celsius -O---K 034 044 000 - 34 (0 25 0 0 0) 195 Hardware_ECC_Recovered -O-RC- 050 030 000 - 44490692 197 Current_Pending_Sector -O--C- 100 100 000 - 0 198 Offline_Uncorrectable ----C- 100 100 000 - 0 199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning General Purpose Log Directory Version 1 SMART Log Directory Version 1 [multi-sector log support] GP/S Log at address 0x00 has 1 sectors [Log Directory] GP/S Log at address 0x01 has 1 sectors [Summary SMART error log] GP/S Log at address 0x02 has 5 sectors [Comprehensive SMART error log] GP/S Log at address 0x03 has 5 sectors [Ext. Comprehensive SMART error log] GP/S Log at address 0x06 has 1 sectors [SMART self-test log] GP/S Log at address 0x07 has 1 sectors [Extended self-test log] GP/S Log at address 0x09 has 1 sectors [Selective self-test log] GP/S Log at address 0x10 has 1 sectors [NCQ Command Error log] GP/S Log at address 0x11 has 1 sectors [SATA Phy Event Counters] GP/S Log at address 0x21 has 1 sectors [Write stream error log] GP/S Log at address 0x22 has 1 sectors [Read stream error log] GP/S Log at address 0x80 has 16 sectors [Host vendor specific log] GP/S Log at address 0x81 has 16 sectors [Host vendor specific log] GP/S Log at address 0x82 has 16 sectors [Host vendor specific log] GP/S Log at address 0x83 has 16 sectors [Host vendor specific log] GP/S Log at address 0x84 has 16 sectors [Host vendor specific log] GP/S Log at address 0x85 has 16 sectors [Host vendor specific log] GP/S Log at address 0x86 has 16 sectors [Host vendor specific log] GP/S Log at address 0x87 has 16 sectors [Host vendor specific log] GP/S Log at address 0x88 has 16 sectors [Host vendor specific log] GP/S Log at address 0x89 has 16 sectors [Host vendor specific log] GP/S Log at address 0x8a has 16 sectors [Host vendor specific log] GP/S Log at address 0x8b has 16 sectors [Host vendor specific log] GP/S Log at address 0x8c has 16 sectors [Host vendor specific log] GP/S Log at address 0x8d has 16 sectors [Host vendor specific log] GP/S Log at address 0x8e has 16 sectors [Host vendor specific log] GP/S Log at address 0x8f has 16 sectors [Host vendor specific log] GP/S Log at address 0x90 has 16 sectors [Host vendor specific log] GP/S Log at address 0x91 has 16 sectors [Host vendor specific log] GP/S Log at address 0x92 has 16 sectors [Host vendor specific log] GP/S Log at address 0x93 has 16 sectors [Host vendor specific log] GP/S Log at address 0x94 has 16 sectors [Host vendor specific log] GP/S Log at address 0x95 has 16 sectors [Host vendor specific log] GP/S Log at address 0x96 has 16 sectors [Host vendor specific log] GP/S Log at address 0x97 has 16 sectors [Host vendor specific log] GP/S Log at address 0x98 has 16 sectors [Host vendor specific log] GP/S Log at address 0x99 has 16 sectors [Host vendor specific log] GP/S Log at address 0x9a has 16 sectors [Host vendor specific log] GP/S Log at address 0x9b has 16 sectors [Host vendor specific log] GP/S Log at address 0x9c has 16 sectors [Host vendor specific log] GP/S Log at address 0x9d has 16 sectors [Host vendor specific log] GP/S Log at address 0x9e has 16 sectors [Host vendor specific log] GP/S Log at address 0x9f has 16 sectors [Host vendor specific log] GP/S Log at address 0xa1 has 20 sectors [Device vendor specific log] GP Log at address 0xa2 has 2248 sectors [Device vendor specific log] GP/S Log at address 0xa8 has 20 sectors [Device vendor specific log] GP/S Log at address 0xa9 has 1 sectors [Device vendor specific log] GP Log at address 0xb0 has 2819 sectors [Device vendor specific log] GP Log at address 0xbe has 65535 sectors [Device vendor specific log] GP Log at address 0xbf has 65535 sectors [Device vendor specific log] GP/S Log at address 0xe0 has 1 sectors [SCT Command/Status] GP/S Log at address 0xe1 has 1 sectors [SCT Data Transfer] SMART Extended Comprehensive Error Log Version: 1 (5 sectors) Device Error Count: 5 CR = Command Register FEATR = Features Register COUNT = Count (was: Sector Count) Register LBA_48 = Upper bytes of LBA High/Mid/Low Registers ] ATA-8 LH = LBA High (was: Cylinder High) Register ] LBA LM = LBA Mid (was: Cylinder Low) Register ] Register LL = LBA Low (was: Sector Number) Register ] DV = Device (was: Device/Head) Register DC = Device Control Register ER = Error register ST = Status register Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 5 [4] occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- == -- == == == -- -- -- -- -- 40 -- 51 00 00 00 4d 08 00 db 10 00 00 Error: UNC at LBA = 0x4d0800db10 = 330846755600 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 00 00 1a 00 19 72 00 2f a2 40 00 11d+02:29:18.542 READ FPDMA QUEUED 60 00 00 00 1a 00 19 3e 00 2d 83 40 00 11d+02:29:18.542 READ FPDMA QUEUED 60 00 00 00 1b 00 19 38 00 2a 07 40 00 11d+02:29:18.541 READ FPDMA QUEUED 60 00 00 00 19 00 19 35 00 2a 2b 40 00 11d+02:29:18.541 READ FPDMA QUEUED 60 00 00 00 1c 00 19 b4 00 28 ec 40 00 11d+02:29:18.541 READ FPDMA QUEUED Error 4 [3] occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- == -- == == == -- -- -- -- -- 40 -- 51 00 00 00 4d 08 00 db 10 00 00 Error: UNC at LBA = 0x4d0800db10 = 330846755600 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 00 00 1a 00 19 72 00 2f a2 40 00 11d+02:29:15.783 READ FPDMA QUEUED 60 00 00 00 1a 00 19 3e 00 2d 83 40 00 11d+02:29:15.780 READ FPDMA QUEUED 60 00 00 00 1b 00 19 38 00 2a 07 40 00 11d+02:29:15.732 READ FPDMA QUEUED 60 00 00 00 19 00 19 35 00 2a 2b 40 00 11d+02:29:15.732 READ FPDMA QUEUED 60 00 00 00 1c 00 19 b4 00 28 ec 40 00 11d+02:29:15.731 READ FPDMA QUEUED Error 3 [2] occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- == -- == == == -- -- -- -- -- 40 -- 51 00 00 00 4d 08 00 db 10 00 00 Error: UNC at LBA = 0x4d0800db10 = 330846755600 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 00 00 1b 00 19 38 00 2a 07 40 00 11d+02:29:12.889 READ FPDMA QUEUED 60 00 00 00 19 00 19 35 00 2a 2b 40 00 11d+02:29:12.889 READ FPDMA QUEUED 60 00 00 00 1c 00 19 b4 00 28 ec 40 00 11d+02:29:12.888 READ FPDMA QUEUED 60 00 00 00 1c 00 4d 4f 00 e3 b5 40 00 11d+02:29:12.888 READ FPDMA QUEUED 60 00 00 00 1a 00 4d 07 00 db fc 40 00 11d+02:29:12.888 READ FPDMA QUEUED Error 2 [1] occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- == -- == == == -- -- -- -- -- 40 -- 51 00 00 00 4d 08 00 db 10 00 00 Error: UNC at LBA = 0x4d0800db10 = 330846755600 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 00 00 1b 00 19 38 00 2a 07 40 00 11d+02:29:10.011 READ FPDMA QUEUED 60 00 00 00 19 00 19 35 00 2a 2b 40 00 11d+02:29:10.011 READ FPDMA QUEUED 60 00 00 00 1c 00 19 b4 00 28 ec 40 00 11d+02:29:10.010 READ FPDMA QUEUED 60 00 00 00 1c 00 4d 4f 00 e3 b5 40 00 11d+02:29:10.010 READ FPDMA QUEUED 60 00 00 00 1a 00 4d 07 00 db fc 40 00 11d+02:29:10.010 READ FPDMA QUEUED Error 1 [0] occurred at disk power-on lifetime: 18292 hours (762 days + 4 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- == -- == == == -- -- -- -- -- 40 -- 51 00 00 00 4d 08 00 db 10 00 00 Error: UNC at LBA = 0x4d0800db10 = 330846755600 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- 60 00 00 00 1b 00 19 38 00 2a 07 40 00 11d+02:29:07.148 READ FPDMA QUEUED 60 00 00 00 19 00 19 35 00 2a 2b 40 00 11d+02:29:07.140 READ FPDMA QUEUED 60 00 00 00 1c 00 19 b4 00 28 ec 40 00 11d+02:29:07.131 READ FPDMA QUEUED 60 00 00 00 1c 00 4d 4f 00 e3 b5 40 00 11d+02:29:07.117 READ FPDMA QUEUED 60 00 00 00 35 00 4d c0 00 e0 09 40 00 11d+02:29:07.111 READ FPDMA QUEUED SMART Extended Self-test Log Version: 1 (1 sectors) No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. SCT Status Version: 3 SCT Version (vendor specific): 522 (0x020a) SCT Support Level: 1 Device State: Active (0) Current Temperature: 34 Celsius Power Cycle Min/Max Temperature: 33/37 Celsius Lifetime Min/Max Temperature: 25/44 Celsius Under/Over Temperature Limit Count: 0/10423 SCT Temperature History Version: 2 Temperature Sampling Period: 1 minute Temperature Logging Interval: 1 minute Min/Max recommended Temperature: 0/ 0 Celsius Min/Max Temperature Limit: 0/ 0 Celsius Temperature History Size (Index): 128 (24) Index Estimated Time Temperature Celsius 25 2012-02-08 17:53 35 **************** ... ..( 53 skipped). .. **************** 79 2012-02-08 18:47 35 **************** 80 2012-02-08 18:48 34 *************** ... ..( 71 skipped). .. *************** 24 2012-02-08 20:00 34 *************** SCT Error Recovery Control: Read: Disabled Write: Disabled SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 12 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS smartctl -l gplog,0x10 /dev/ada9 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net General Purpose Log 0x10 [NCQ Command Error log], Page 0-0 (of 1) 0000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0(backup3)# smartctl -l sataphy /dev/ada9 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 12 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0(backup3)# smartctl -l sataphy /dev/ada10 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 11 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0(backup3)# smartctl -l sataphy /dev/ada11 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 12 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0(backup3)# smartctl -l sataphy /dev/ada12 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x000a 2 5 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS 0x8000 4 625971 Vendor specific 0(backup3)# ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 01:20:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9D321065672; Thu, 9 Feb 2012 01:20:40 +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 1E85F8FC0C; Thu, 9 Feb 2012 01:20:40 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 32F842842E; Thu, 9 Feb 2012 02:20:38 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7931128424; Thu, 9 Feb 2012 02:20:36 +0100 (CET) Message-ID: <4F331F63.60707@quip.cz> Date: Thu, 09 Feb 2012 02:20:35 +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: Artem Belevich References: <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F330F38.3010806@quip.cz> <20120209002835.GA29400@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andriy Gapon , "Eugene M. Zheganin" , freebsd-stable , mm@freebsd.org, Jeremy Chadwick Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 01:20:40 -0000 Artem Belevich wrote: > On Wed, Feb 8, 2012 at 4:28 PM, Jeremy Chadwick > wrote: >> On Thu, Feb 09, 2012 at 01:11:36AM +0100, Miroslav Lachman wrote: > ... >>> ARC Size: >>> Current Size: 1769 MB (arcsize) >>> Target Size (Adaptive): 512 MB (c) >>> Min Size (Hard Limit): 512 MB (zfs_arc_min) >>> Max Size (Hard Limit): 3584 MB (zfs_arc_max) >>> >>> The target size is going down to the min size and after few more >>> days, the system is so slow, that I must reboot the machine. Then it >>> is running fine for about 107 days and then it all repeat again. >>> >>> You can see more on MRTG graphs >>> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ >>> You can see links to other useful informations on top of the page >>> (arc_summary, top, dmesg, fs usage, loader.conf) >>> >>> There you can see nightly backups (higher CPU load started at >>> 01:13), otherwise the machine is idle. >>> >>> It coresponds with ARC target size lowering in last 5 days >>> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arcstats_size.html >>> >>> And with ARC metadata cache overflowing the limit in last 5 days >>> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs_meta.html >>> >>> I don't know what's going on and I don't know if it is something >>> know / fixed in newer releases. We are running a few more ZFS >>> systems on 8.2 without this issue. But those systems are in >>> different roles. >> >> This sounds like the... damn, what is it called... some kind of internal >> "counter" or "ticks" thing within the ZFS code that was discovered to >> only begin happening after a certain period of time (which correlated to >> some number of days, possibly 107). I'm sorry that I can't be more >> specific, but it's been discussed heavily on the lists in the past, and >> fixes for all of that were committed to RELENG_8. Thank you for your quick response. I am glad that it is fixed in 8.x. So I will upgrade this last old machine in few weeks. :) >> I wish I could >> remember the name of the function or macro or variable name it pertained >> to, something like LTHAW or TLOCK or something like that. I would say >> "I don't know why I can't remember", but I do know why I can't remember: >> because I gave up trying to track all of these problems. >> >> Does someone else remember this issue? CC'ing Martin who might remember >> for certain. > > It's LBOLT. :-) > > And there was more than one related integer overflow. One of them > manifested itself as L2ARC feeding thread hogging CPU time after about > a month of uptime. Another one caused issue with ARC reclaim after 107 > days. See more details in this thread: > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011584.html Yes, it is exactly this problem. Thank you for the link to this thread. I am subscribed to freebsd-fs@ and I am reading it almost daily, but I missed this one! Thanks to both of you! Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 01:32:07 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA237106566B for ; Thu, 9 Feb 2012 01:32:07 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 59AD28FC12 for ; Thu, 9 Feb 2012 01:32:07 +0000 (UTC) Received: (qmail 12500 invoked by uid 0); 9 Feb 2012 01:05:25 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2012 01:05:25 -0000 Received: (qmail 12484 invoked by uid 90); 9 Feb 2012 01:05:25 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 9 Feb 2012 01:05:25 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Charles Sprickman In-Reply-To: <4F330F38.3010806@quip.cz> Date: Wed, 8 Feb 2012 20:05:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F330F38.3010806@quip.cz> To: Miroslav Lachman <000.fbsd@quip.cz> X-Mailer: Apple Mail (2.1084) Cc: "Eugene M. Zheganin" , freebsd-stable , Andriy Gapon Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 01:32:07 -0000 On Feb 8, 2012, at 7:11 PM, Miroslav Lachman wrote: > Andriy Gapon wrote: >> on 08/02/2012 12:31 Eugene M. Zheganin said the following: >>> Hi. >>>=20 >>> On 08.02.2012 02:17, Andriy Gapon wrote: >>>> [output snipped] >>>>=20 >>>> Thank you. I don't see anything suspicious/unusual there. >>>> Just case, do you have ZFS dedup enabled by a chance? >>>>=20 >>>> I think that examination of vmstat -m and vmstat -z outputs may = provide some >>>> clues as to what got all that memory wired. >>>>=20 >>> Nope, I don't have deduplication feature enabled. >>=20 >> OK. So, did you have a chance to inspect vmstat -m and vmstat -z? >>=20 >>> By the way, today, after eating another 100M of wired memory this = server hanged >>> out with multiple non-stopping messages >>>=20 >>> swap_pager: indefinite wait buffer >>>=20 >>> Since it's swapping on zvol, it looks to me like it could be the = mentioned in >>> another thread here ("Swap on zvol - recommendable?") resource = starvation issue; >>> may be it happens faster when the ARC isn't limited. >>=20 >> It could be very well possible that swap on zvol doesn't work well = when the >> kernel itself is starved on memory. >>=20 >>> So I want to ask - how to report it and what should I include in = such pr ? >>=20 >> I am leaving swap-on-zvol issue aside. Your original problem doesn't = seem to be >> ZFS-related. I suspect that you might be running into some kernel = memory leak. >> If you manage to reproduce the high wired value again, then vmstat = -m and >> vmstat -z may provide some useful information. >>=20 >> In this vein, do you use any out-of-tree kernel modules? >> Also, can you try to monitor your system to see when wired count = grows? >=20 > I am seeing something similar on one of our machine. This is old 7.3 = with ZFS v13, that's why I did not reported it. >=20 > The machine is used as storage for backups made by rsync. All is = running fine for about 107 days. Then backups are slower and slower = because of some strange memory situation. >=20 > Mem: 15M Active, 17M Inact, 3620M Wired, 420K Cache, 48M Buf, 1166M = Free >=20 > ARC Size: > Current Size: 1769 MB (arcsize) > Target Size (Adaptive): 512 MB (c) > Min Size (Hard Limit): 512 MB (zfs_arc_min) > Max Size (Hard Limit): 3584 MB (zfs_arc_max) >=20 > The target size is going down to the min size and after few more days, = the system is so slow, that I must reboot the machine. Then it is = running fine for about 107 days and then it all repeat again. >=20 > You can see more on MRTG graphs > http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ > You can see links to other useful informations on top of the page = (arc_summary, top, dmesg, fs usage, loader.conf) >=20 > There you can see nightly backups (higher CPU load started at 01:13), = otherwise the machine is idle. >=20 > It coresponds with ARC target size lowering in last 5 days > = http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arcst= ats_size.html >=20 > And with ARC metadata cache overflowing the limit in last 5 days > = http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs_m= eta.html I'm not having luck finding it, but there's some known issue that exists = even in 8.2 where some 32-bit counter overflows or something. I don't = truly remember the logic in it, but when you hit it, it's around 110 = days or so. Before it gets really bad (to the point where you either = reboot or get some memory exhaustion panic), you can see zfs "evict = skips" incrementing rapidly. Looking at that graph, that would be my = guess as to what's happening to you. It's easy to check - run one of = the arc stats scripts, look for "evict_skips", note the number and then = run it a few minutes later. If it increases by more than a few hundred, = you've hit the bug. You'll find at that point the kernel is no longer = "evicting" ARC from the kernel and it will just continue to grow until = bad things happen. Charles >=20 > I don't know what's going on and I don't know if it is something know = / fixed in newer releases. We are running a few more ZFS systems on 8.2 = without this issue. But those systems are in different roles. >=20 > Miroslav Lachman > _______________________________________________ > 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 Thu Feb 9 01:45:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21667106566C for ; Thu, 9 Feb 2012 01:45:14 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id D582B8FC15 for ; Thu, 9 Feb 2012 01:45:13 +0000 (UTC) Received: (qmail 44020 invoked by uid 0); 9 Feb 2012 01:45:13 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2012 01:45:13 -0000 Received: (qmail 44001 invoked by uid 90); 9 Feb 2012 01:45:12 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 9 Feb 2012 01:45:12 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Charles Sprickman In-Reply-To: Date: Wed, 8 Feb 2012 20:45:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CCD642A-BE63-4AD8-BD80-1F55425CA537@bway.net> References: <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F330F38.3010806@quip.cz> <20120209002835.GA29400@icarus.home.lan> To: Artem Belevich X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable , mm@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, Andriy Gapon , "Eugene M. Zheganin" , Jeremy Chadwick Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 01:45:14 -0000 On Feb 8, 2012, at 7:43 PM, Artem Belevich wrote: > On Wed, Feb 8, 2012 at 4:28 PM, Jeremy Chadwick > wrote: >> On Thu, Feb 09, 2012 at 01:11:36AM +0100, Miroslav Lachman wrote: > ... >>> ARC Size: >>> Current Size: 1769 MB (arcsize) >>> Target Size (Adaptive): 512 MB (c) >>> Min Size (Hard Limit): 512 MB (zfs_arc_min) >>> Max Size (Hard Limit): 3584 MB (zfs_arc_max) >>>=20 >>> The target size is going down to the min size and after few more >>> days, the system is so slow, that I must reboot the machine. Then it >>> is running fine for about 107 days and then it all repeat again. >>>=20 >>> You can see more on MRTG graphs >>> http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/ >>> You can see links to other useful informations on top of the page >>> (arc_summary, top, dmesg, fs usage, loader.conf) >>>=20 >>> There you can see nightly backups (higher CPU load started at >>> 01:13), otherwise the machine is idle. >>>=20 >>> It coresponds with ARC target size lowering in last 5 days >>> = http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_arcst= ats_size.html >>>=20 >>> And with ARC metadata cache overflowing the limit in last 5 days >>> = http://freebsd.quip.cz/ext/2012/2012-02-08-kiwi-mrtg-12-15/local_zfs_vfs_m= eta.html >>>=20 >>> I don't know what's going on and I don't know if it is something >>> know / fixed in newer releases. We are running a few more ZFS >>> systems on 8.2 without this issue. But those systems are in >>> different roles. >>=20 >> This sounds like the... damn, what is it called... some kind of = internal >> "counter" or "ticks" thing within the ZFS code that was discovered to >> only begin happening after a certain period of time (which correlated = to >> some number of days, possibly 107). I'm sorry that I can't be more >> specific, but it's been discussed heavily on the lists in the past, = and >> fixes for all of that were committed to RELENG_8. I wish I could >> remember the name of the function or macro or variable name it = pertained >> to, something like LTHAW or TLOCK or something like that. I would = say >> "I don't know why I can't remember", but I do know why I can't = remember: >> because I gave up trying to track all of these problems. >>=20 >> Does someone else remember this issue? CC'ing Martin who might = remember >> for certain. >=20 > It's LBOLT. :-) >=20 > And there was more than one related integer overflow. One of them > manifested itself as L2ARC feeding thread hogging CPU time after about > a month of uptime. Another one caused issue with ARC reclaim after 107 > days. See more details in this thread: >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011584.html This would be an excellent piece of information to have on one of the = ZFS wiki pages. The 107 day issue exists post-8.2, correct? Anyone on this=20= cc: list have permissions to edit those pages? Thanks, Charles >=20 > --Artem > _______________________________________________ > 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 Thu Feb 9 02:46:00 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632C6106566C; Thu, 9 Feb 2012 02:46:00 +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 2DDDB8FC14; Thu, 9 Feb 2012 02:46:00 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvK11-000Gab-Kg; Wed, 08 Feb 2012 21:45:43 -0500 Date: Wed, 8 Feb 2012 21:45:43 -0500 From: Gary Palmer To: Andriy Gapon , Jeremy Chadwick Message-ID: <20120209024543.GD10082@in-addr.com> References: <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <20120208205000.GA25700@icarus.home.lan> <4F32E68A.5060607@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F32E68A.5060607@FreeBSD.org> 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: "Eugene M. Zheganin" , freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 02:46:00 -0000 On Wed, Feb 08, 2012 at 11:18:02PM +0200, Andriy Gapon wrote: > on 08/02/2012 22:50 Jeremy Chadwick said the following: > > Politely -- recommending this to a user is a good choice of action, but > > the problem is that no user, even an experienced user, is going to know > > what all of the "Types" (vmstat -m) or "ITEMs" (vmstat -z) correlate > > with on the system. > > I see no problem with users sharing the output and asking for help interpreting > it. I do not know of any easier way to analyze problems like this one. Also, since we are looking for gigs of memory it should be relatively easy to look down the 'Size' or 'MemUse' columns and identify likely candidates for "eating gobs of memory". The user doesn't need to know what the rest of the data means, and can ask what that line means and how to fix it Gary From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 04:28:02 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BC411065672 for ; Thu, 9 Feb 2012 04:28:02 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 578D38FC0C for ; Thu, 9 Feb 2012 04:28:00 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q194RXUM031298 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 9 Feb 2012 09:27:33 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F334B35.5040708@norma.perm.ru> Date: Thu, 09 Feb 2012 10:27:33 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> In-Reply-To: <4F32DB30.6020600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 09 Feb 2012 09:27:33 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 04:28:02 -0000 Hi. On 09.02.2012 02:29, Andriy Gapon wrote: > on 08/02/2012 12:31 Eugene M. Zheganin said the following: >> Hi. >> >> On 08.02.2012 02:17, Andriy Gapon wrote: >>> [output snipped] >>> >>> Thank you. I don't see anything suspicious/unusual there. >>> Just case, do you have ZFS dedup enabled by a chance? >>> >>> I think that examination of vmstat -m and vmstat -z outputs may provide some >>> clues as to what got all that memory wired. >>> >> Nope, I don't have deduplication feature enabled. > OK. So, did you have a chance to inspect vmstat -m and vmstat -z? I did. I didn't understand it, but kinda 'felt the atmosphere'. It was pretty much similar to the output I supplied below. Most of the sizes were used by 'solaris' and numerous 'zio' caches. > > It could be very well possible that swap on zvol doesn't work well when the > kernel itself is starved on memory. > >> So I want to ask - how to report it and what should I include in such pr ? > I am leaving swap-on-zvol issue aside. Your original problem doesn't seem to be > ZFS-related. I suspect that you might be running into some kernel memory leak. > If you manage to reproduce the high wired value again, then vmstat -m and > vmstat -z may provide some useful information. > > In this vein, do you use any out-of-tree kernel modules? > Also, can you try to monitor your system to see when wired count grows? > Nope, I don't have any 3rd party kernel modules. Yes, I can monitor it, but I have no idea what should I exactly monitor. This system is running squid with a dozens of authentication helpers, freeradius + postgresql, sendmail and a perl squid log parser, which uses postgresql too. net/isc-dhcp, quagga, net/mpd5, a bunch of sendmail milters, net/samba35, bind. So it's some kind of a corporate production zoo. As I write this letter, the wired amount of memory increases by 70 megs. Excuse me, 80 megs now. The output I promised (if it's MORE acceptable in the form of a link to a paste site, just say it): [emz@taiga:etc/snmp]# vmstat -m Type InUse MemUse HighUse Requests Size(s) hhook 2 1K - 2 128 ithread 85 14K - 85 32,128,256 KTRACE 100 13K - 100 128 linker 280 226K - 384 16,32,64,128,256,512,1024,2048,4096 lockf 94 10K - 20264872 64,128 loginclass 3 1K - 367 64 pci_link 13 2K - 13 16,128 ip6ndp 55 5K - 78 64,128 ip6opt 23 6K - 142134 32,256 temp 146 20K - 114199 16,32,64,128,256,512,1024,2048,4096 devbuf 28285 56235K - 29225 16,32,64,128,256,512,1024,2048,4096 module 291 37K - 291 128 USBdev 39 10K - 39 64,128,512,1024 mtx_pool 2 16K - 2 USB 55 166K - 58 16,32,64,128,256,512,2048,4096 osd 22 1K - 10870 16,64 ddb_capture 1 48K - 1 subproc 831 1312K - 56233 512,4096 proc 2 16K - 2 session 66 9K - 16431 128 pgrp 73 10K - 16581 128 cred 650 102K - 818736 64,256 uidinfo 15 4K - 5420 128,2048 plimit 25 7K - 4948 256 kbdmux 8 18K - 8 16,512,1024,2048 sysctltmp 0 0K - 9741241 16,32,64,128,4096 sysctloid 4837 243K - 4950 16,32,64,128 sysctl 0 0K - 50230 16,32,64 tidhash 1 16K - 1 callout 3 1536K - 3 umtx 2712 339K - 2766 128 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 bus-sc 84 686K - 2193 16,32,64,128,256,512,1024,2048,4096 bus 861 78K - 4641 16,32,64,128,256,512,1024 devstat 4 9K - 4 32,4096 eventhandler 83 7K - 83 64,128 kobj 194 776K - 231 4096 Per-cpu 1 1K - 1 32 aacbuf 241 72K - 273 64,128,512 rman 219 23K - 449 16,32,128 acpiintr 1 1K - 1 64 sbuf 1 1K - 967 16,32,64,128,256,512,1024,2048,4096 acpica 1641 174K - 50289 16,32,64,128,256,512,1024,2048,4096 DEVFS1 106 53K - 111 512 DEVFS3 261 66K - 269 256 stack 0 0K - 2 256 taskqueue 85 8K - 121 16,32,64,128,1024 Unitno 21 1K - 208557 32,64 DEVFS2 106 2K - 108 16 DEVFS_RULE 54 26K - 54 64,512 DEVFS 39 1K - 40 16,128 Witness 1 128K - 1 iov 0 0K - 12708587 16,32,64,128,256,512 select 1081 136K - 1108 128 ioctlops 0 0K - 5846280 16,32,64,128,256,512,1024,2048,4096 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 11 40K - 13055 2048 tty 23 23K - 29 1024,2048 pts 5 2K - 9 256 mbuf_tag 133 13K - 425972406 32,64,128 shmfd 1 8K - 1 DEVFSP 8 1K - 8 64 pcb 618 176K - 1042950 16,32,64,128,1024,2048,4096 soname 221 27K - 70492663 16,32,128 acl 0 0K - 1575 4096 vfscache 1 2048K - 1 vfs_hash 1 1024K - 1 vnodes 6 1K - 17 64,256 vnodemarker 0 0K - 72943 512 mount 256 16K - 1498 16,32,64,128,256,512 BPF 65 74K - 66 128,512,4096 ether_multi 564 32K - 786 16,32,64 ifaddr 330 93K - 339 16,32,64,128,256,512,2048,4096 ifnet 34 67K - 37 128,256,512,2048 clone 8 32K - 8 4096 arpcom 23 1K - 23 16 gif 1 1K - 1 256 lltable 767 209K - 15188 256,512 vlan 103 8K - 465 64,128 routetbl 840 45K - 13455 32,64,128,256,512 igmp 33 9K - 34 256 CARP 32 13K - 32 64,256,1024 ipid 2 24K - 2 ip_moptions 2 1K - 2 64,256 in_multi 23 6K - 24 256 in_mfilter 1 1K - 1 1024 encap_export_host 1 1K - 1 1024 sctp_iter 0 0K - 29 256 sctp_ifn 16 2K - 16 128 sctp_ifa 44 6K - 44 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 29 16 hostcache 1 28K - 1 syncache 1 96K - 1 fragment 0 0K - 18 64,128 ip6_moptions 10 2K - 10 32,256 in6_multi 188 28K - 196 32,256 in6_mfilter 5 5K - 5 1024 mld 33 5K - 34 128 NLM 0 0K - 1 32 rpc 64 8K - 398 16,32,64,128,256,512,1024,2048 audit_evclass 179 6K - 218 32 freework 1 1K - 1 64 newblk 1 128K - 1 bmsafemap 1 8K - 1 inodedep 1 1024K - 1 pagedep 1 128K - 1 vm_pgdata 2 129K - 2 128 UMAHash 2 5K - 6 512,1024,2048,4096 NFSD srvcache 0 0K - 91 128 pfs_nodes 21 6K - 21 256 acpitask 1 2K - 1 2048 memdesc 1 4K - 1 4096 GEOM 61 12K - 297 16,32,64,128,256,512,1024,2048 atkbddev 2 1K - 2 64 ata_pci 1 1K - 1 64 CAM dev queue 3 1K - 3 128 CAM queue 11 1K - 56 16,32 acpisem 16 2K - 16 128 CAM SIM 3 1K - 3 256 scsi_cd 0 0K - 4 16 CAM periph 4 1K - 18 16,32,64,128,256 isadev 7 1K - 7 128 entropy 1024 64K - 1024 64 apmdev 1 1K - 1 128 CAM XPT 29 14K - 80 32,64,128,1024,2048 UART 3 2K - 3 16,512,1024 cdev 8 2K - 8 256 io_apic 1 2K - 1 2048 sigio 1 1K - 3 64 filedesc 544 566K - 60333 16,32,64,128,256,512,1024,2048,4096 msi 2 1K - 2 128 nexusdev 3 1K - 3 16 kenv 104 12K - 108 16,32,64,128 kqueue 24 39K - 405980 256,2048,4096 acpidev 27 2K - 27 64 proc-args 219 24K - 449753 16,32,64,128,256 solaris 427482 2357264K - 228638905 16,32,64,128,256,512,1024,2048,4096 kstat_data 4 1K - 4 64 netgraph_msg 0 0K - 17743 64,128,256,512,1024 netgraph_node 11 3K - 26 256 netgraph_hook 14 2K - 46 128 netgraph 3 1K - 9 64,256,512,1024 netgraph_sock 5 1K - 10 128 netgraph_path 0 0K - 8912 16,32 netgraph_mppc 0 0K - 3 1024 netgraph_l2tp 2 3K - 2 128,2048 netgraph_ksock 1 1K - 2 128 netgraph_iface 1 1K - 2 128 netgraph_ppp 1 12K - 2 [emz@taiga:etc/snmp]# vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 199, 5, 199, 0, 0 UMA Zones: 896, 0, 199, 1, 199, 0, 0 UMA Slabs: 568, 0, 38730, 827, 2045963, 0, 0 UMA RCntSlabs: 568, 0, 2417, 152, 10161, 0, 0 UMA Hash: 256, 0, 79, 11, 81, 0, 0 16 Bucket: 152, 0, 18, 132, 156, 0, 0 32 Bucket: 280, 0, 35, 119, 299, 0, 0 64 Bucket: 536, 0, 54, 72, 644, 57, 0 128 Bucket: 1048, 0, 467, 262, 112841,14481, 0 VM OBJECT: 216, 0, 39763, 2267, 1794570, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 150412, 3666, 2131, 4810417, 0, 0 MAP ENTRY: 120, 0, 16746, 8457, 4147673, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 283, 77, 283, 0, 0 16: 16, 0, 65795, 565,103575464, 0, 0 32: 32, 0, 14388, 964,32512329, 0, 0 64: 64, 0, 164377, 14879,486891319, 0, 0 128: 128, 0, 17439, 2571,112770466, 0, 0 256: 256, 0, 12848, 15832,32654808, 0, 0 512: 512, 0, 149161, 4727, 6242680, 0, 0 1024: 1024, 0, 1970, 314, 151802, 0, 0 2048: 2048, 0, 1717, 349, 465184, 0, 0 4096: 4096, 0, 7621, 669, 375642, 0, 0 Files: 80, 0, 2210, 805,47573314, 0, 0 TURNSTILE: 136, 0, 1357, 83, 1384, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 259, 314, 55680, 0, 0 THREAD: 1112, 0, 864, 492, 53330, 0, 0 SLEEPQUEUE: 88, 0, 1357, 122, 1384, 0, 0 VMSPACE: 392, 0, 239, 681, 55662, 0, 0 cpuset: 72, 0, 2, 98, 2, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 2107, 709,137988001, 0, 0 mbuf: 256, 0, 58204, 1065,523117709, 0, 0 mbuf_cluster: 2048, 25600, 2816, 914, 7273137, 0, 0 mbuf_jumbo_page: 4096, 12800, 9, 543, 7683953, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 672, 29126, 0, 0 g_bio: 232, 0, 0, 752, 5733840, 0, 0 ttyinq: 160, 0, 240, 120, 555, 0, 0 ttyoutq: 256, 0, 127, 83, 293, 0, 0 ata_request: 328, 0, 0, 36, 14, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 792, 69760, 0, 0 VNODE: 480, 0, 37315, 2269, 429291, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 S VFS Cache: 108, 0, 16761, 28350, 349225, 0, 0 L VFS Cache: 328, 0, 18, 1086, 13342, 0, 0 NAMEI: 1024, 0, 0, 384,29340521, 0, 0 NCLNODE: 560, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 zio_cache: 880, 0, 1, 1135,40366913, 0, 0 zio_link_cache: 48, 0, 0, 1440,11333105, 0, 0 zio_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_data_buf_512: 512, 0, 0, 0, 0, 0, 0 zio_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_data_buf_1024: 1024, 0, 0, 0, 0, 0, 0 zio_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_data_buf_1536: 1536, 0, 0, 0, 0, 0, 0 zio_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_data_buf_2048: 2048, 0, 0, 0, 0, 0, 0 zio_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_data_buf_2560: 2560, 0, 0, 0, 0, 0, 0 zio_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_data_buf_3072: 3072, 0, 0, 0, 0, 0, 0 zio_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_data_buf_3584: 3584, 0, 0, 0, 0, 0, 0 zio_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_data_buf_4096: 4096, 0, 0, 0, 0, 0, 0 zio_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_data_buf_5120: 5120, 0, 0, 0, 0, 0, 0 zio_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_data_buf_6144: 6144, 0, 0, 0, 0, 0, 0 zio_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_data_buf_7168: 7168, 0, 0, 0, 0, 0, 0 zio_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_data_buf_8192: 8192, 0, 0, 0, 0, 0, 0 zio_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_data_buf_10240: 10240, 0, 0, 0, 0, 0, 0 zio_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_data_buf_12288: 12288, 0, 0, 0, 0, 0, 0 zio_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_data_buf_14336: 14336, 0, 0, 0, 0, 0, 0 zio_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_data_buf_16384: 16384, 0, 0, 0, 0, 0, 0 zio_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_data_buf_20480: 20480, 0, 0, 0, 0, 0, 0 zio_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_data_buf_24576: 24576, 0, 0, 0, 0, 0, 0 zio_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_data_buf_28672: 28672, 0, 0, 0, 0, 0, 0 zio_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_data_buf_32768: 32768, 0, 0, 0, 0, 0, 0 zio_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_data_buf_36864: 36864, 0, 0, 0, 0, 0, 0 zio_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_data_buf_40960: 40960, 0, 0, 0, 0, 0, 0 zio_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_data_buf_45056: 45056, 0, 0, 0, 0, 0, 0 zio_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_data_buf_49152: 49152, 0, 0, 0, 0, 0, 0 zio_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_data_buf_53248: 53248, 0, 0, 0, 0, 0, 0 zio_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_data_buf_57344: 57344, 0, 0, 0, 0, 0, 0 zio_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_data_buf_61440: 61440, 0, 0, 0, 0, 0, 0 zio_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_data_buf_65536: 65536, 0, 0, 0, 0, 0, 0 zio_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_data_buf_69632: 69632, 0, 0, 0, 0, 0, 0 zio_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_data_buf_73728: 73728, 0, 0, 0, 0, 0, 0 zio_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_data_buf_77824: 77824, 0, 0, 0, 0, 0, 0 zio_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_data_buf_81920: 81920, 0, 0, 0, 0, 0, 0 zio_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_data_buf_86016: 86016, 0, 0, 0, 0, 0, 0 zio_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_data_buf_90112: 90112, 0, 0, 0, 0, 0, 0 zio_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_data_buf_94208: 94208, 0, 0, 0, 0, 0, 0 zio_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_data_buf_98304: 98304, 0, 0, 0, 0, 0, 0 zio_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_data_buf_102400: 102400, 0, 0, 0, 0, 0, 0 zio_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_data_buf_106496: 106496, 0, 0, 0, 0, 0, 0 zio_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_data_buf_110592: 110592, 0, 0, 0, 0, 0, 0 zio_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_data_buf_114688: 114688, 0, 0, 0, 0, 0, 0 zio_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_data_buf_118784: 118784, 0, 0, 0, 0, 0, 0 zio_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_data_buf_122880: 122880, 0, 0, 0, 0, 0, 0 zio_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_data_buf_126976: 126976, 0, 0, 0, 0, 0, 0 zio_buf_131072: 131072, 0, 0, 0, 0, 0, 0 zio_data_buf_131072: 131072, 0, 0, 0, 0, 0, 0 sa_cache: 80, 0, 37248, 2262, 429178, 0, 0 dnode_t: 856, 0, 151801, 1919, 249658, 0, 0 dmu_buf_impl_t: 224, 0, 177337, 2404, 600337, 0, 0 arc_buf_hdr_t: 216, 0, 105487, 1253, 519289, 0, 0 arc_buf_t: 104, 0, 38391, 5205, 559830, 0, 0 zil_lwb_cache: 192, 0, 9, 611, 80899, 0, 0 zfs_znode_cache: 400, 0, 37248, 2325, 429178, 0, 0 pipe: 728, 0, 42, 328, 39330, 0, 0 Mountpoints: 768, 0, 20, 20, 20, 0, 0 ksiginfo: 112, 0, 564, 657, 29202, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 877, 776,90925709, 0, 0 pfsrctrpl: 152, 10000, 0, 0, 0, 0, 0 pfrulepl: 936, 0, 325, 11, 325, 0, 0 pfstatepl: 288, 10010, 3360, 2568, 1170450, 0, 0 pfstatekeypl: 288, 0, 3983, 2621, 1916481, 0, 0 pfstateitempl: 288, 0, 3983, 2439, 1439637, 0, 0 pfaltqpl: 240, 0, 0, 0, 0, 0, 0 pfpooladdrpl: 88, 0, 71, 55, 71, 0, 0 pfrktable: 1296, 1002, 6, 9, 11, 0, 0 pfrkentry: 160, 200016, 21, 27, 21, 0, 0 pffrent: 32, 5050, 0, 0, 0, 0, 0 pffrag: 80, 0, 0, 0, 0, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0, 0 pfstatescrub: 40, 0, 0, 0, 0, 0, 0 pfiaddrpl: 120, 0, 0, 0, 0, 0, 0 pfospfen: 112, 0, 700, 26, 700, 0, 0 pfosfp: 40, 0, 410, 94, 410, 0, 0 pfsync: 88, 0, 0, 0, 0, 0, 0 socket: 680, 25602, 1726, 596,25837811, 0, 0 ipq: 56, 819, 0, 126, 396, 0, 0 udp_inpcb: 392, 25600, 152, 728,20355207, 0, 0 udpcb: 16, 25704, 152, 856,20355207, 0, 0 tcp_inpcb: 392, 25600, 1782, 4968, 5284799, 0, 0 tcpcb: 976, 25600, 982, 762, 5284799, 0, 0 tcptw: 72, 5150, 800, 4350, 306578,97901, 0 syncache: 152, 15375, 0, 325, 5052872, 0, 0 hostcache: 136, 15372, 2053, 467, 7364, 0, 0 tcpreass: 40, 1680, 3, 585, 216370, 0, 0 sackhole: 32, 0, 0, 909, 55622, 0, 0 sctp_ep: 1368, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2280, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 288, 43, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 6, 34, 8, 0, 0 unpcb: 240, 25600, 570, 550, 197771, 0, 0 rtentry: 200, 0, 756, 137, 1395, 0, 0 selfd: 56, 0, 1504, 701,705385407, 0, 0 SWAPMETA: 288, 116519, 4, 113, 866, 0, 0 NetGraph items: 72, 4118, 0, 812, 115049, 0, 0 NetGraph data items: 72, 522, 0, 493, 189271, 0, 0 P.S. after I pasted this, the wired memory gone down by 70 megs, the final output (I guess enough is enough can be seen here: http://dpaste.org/iA5mP/ ). Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 08:34:06 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99DF1065670 for ; Thu, 9 Feb 2012 08:34:06 +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 075768FC12 for ; Thu, 9 Feb 2012 08:34:05 +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 KAA24832; Thu, 09 Feb 2012 10:33:59 +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 1RvPS3-0004qz-1W; Thu, 09 Feb 2012 10:33:59 +0200 Message-ID: <4F3384F6.9070406@FreeBSD.org> Date: Thu, 09 Feb 2012 10:33:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F334B35.5040708@norma.perm.ru> In-Reply-To: <4F334B35.5040708@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 08:34:06 -0000 on 09/02/2012 06:27 Eugene M. Zheganin said the following: > The output I promised (if it's MORE acceptable in the form of a link to a paste > site, just say it): I prefer links, but both ways are acceptable to me. Just one more hint on the reporting. The most useful reports are coherent reports. That is, I now have your older reports from top and zfs-stat and I have newer vmstat reports. But I do not have all the reports taken at about the same time, so I don't have a coherent picture of a system state. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 08:35:49 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67848106564A for ; Thu, 9 Feb 2012 08:35:49 +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 ACD028FC12 for ; Thu, 9 Feb 2012 08:35:48 +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 KAA24855; Thu, 09 Feb 2012 10:35:45 +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 1RvPTl-0004r9-2J; Thu, 09 Feb 2012 10:35:45 +0200 Message-ID: <4F338560.1040501@FreeBSD.org> Date: Thu, 09 Feb 2012 10:35:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F334B35.5040708@norma.perm.ru> <4F3384F6.9070406@FreeBSD.org> In-Reply-To: <4F3384F6.9070406@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 08:35:49 -0000 on 09/02/2012 10:33 Andriy Gapon said the following: > on 09/02/2012 06:27 Eugene M. Zheganin said the following: >> The output I promised (if it's MORE acceptable in the form of a link to a paste >> site, just say it): > > I prefer links, but both ways are acceptable to me. > Just one more hint on the reporting. The most useful reports are coherent > reports. That is, I now have your older reports from top and zfs-stat and I > have newer vmstat reports. But I do not have all the reports taken at about the > same time, so I don't have a coherent picture of a system state. > And please take the reports after discrepancy between ARC size an wired size is large enough, like e.g. 1GB. That's when they are useful. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 10:41:38 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9189106566B for ; Thu, 9 Feb 2012 10:41:38 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 248D88FC13 for ; Thu, 9 Feb 2012 10:41:36 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q19AfKIB059373 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 9 Feb 2012 15:41:20 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F33A2D0.10300@norma.perm.ru> Date: Thu, 09 Feb 2012 16:41:20 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F334B35.5040708@norma.perm.ru> <4F3384F6.9070406@FreeBSD.org> <4F338560.1040501@FreeBSD.org> In-Reply-To: <4F338560.1040501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 09 Feb 2012 15:41:21 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 10:41:38 -0000 Hi. On 09.02.2012 14:35, Andriy Gapon wrote: > And please take the reports after discrepancy between ARC size an wired size is > large enough, like e.g. 1GB. That's when they are useful. > Okay, I wrote a short script capturing sequence of top -b/zfs-stats -a/vmstat -m/vmstat -z in a timestamped file and put it in a crontab every hour. I will provide the files it creates (or a subset of files, if there will be too many) after the system will enter a deadlock again. This time varies from one week to two. Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 11:10:19 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6EB8106566B for ; Thu, 9 Feb 2012 11:10:19 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 49F9B8FC1C for ; Thu, 9 Feb 2012 11:10:18 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q19BA36b062560 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 9 Feb 2012 16:10:04 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F33A98B.4080508@norma.perm.ru> Date: Thu, 09 Feb 2012 17:10:03 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable References: <4F30E284.8080905@norma.perm.ru> <4F310115.3070507@FreeBSD.org> <4F310C5A.6070400@norma.perm.ru> <4F310E75.7090301@FreeBSD.org> <4F3144A9.2000505@norma.perm.ru> <4F314892.50806@FreeBSD.org> <4F314B5B.100@norma.perm.ru> <4F3186C6.8000904@FreeBSD.org> <4F324F10.2060508@norma.perm.ru> <4F32DB30.6020600@FreeBSD.org> <4F334B35.5040708@norma.perm.ru> <4F3384F6.9070406@FreeBSD.org> <4F338560.1040501@FreeBSD.org> In-Reply-To: <4F338560.1040501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 09 Feb 2012 16:10:04 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Cc: Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 11:10:19 -0000 Hi. On 09.02.2012 14:35, Andriy Gapon wrote: > And please take the reports after discrepancy between ARC size an wired size is > large enough, like e.g. 1GB. That's when they are useful. > One more thing - this machine is running a debug/ddb kernel, so just in order to save two weeks - when/if it will enter a deadlock, do you (or anyone else) need crashdump or anything else I can provide using ddb in a deadlock ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 13:41:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C026106564A for ; Thu, 9 Feb 2012 13:41:30 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id D3F778FC0A for ; Thu, 9 Feb 2012 13:41:29 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC42244.dip.t-dialin.net [79.196.34.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6F449844464; Thu, 9 Feb 2012 14:41:14 +0100 (CET) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id CB32B2B84; Thu, 9 Feb 2012 14:41:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1328794871; bh=NvfPkLnEZufy7FHRGhlS0Jj8D+EQh3CaImPeafiWfTs=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=DKw0O7KicVP+QGDG+haH8mZmSk+5/hbA2ACE7CnGO39XhiWzqQNkw+QnwHAXlwvSZ CC1gLnSm3H9zdACz4h43NMig+ysjng2JtFiDyaJDLK+3ohrMafRHtQrP/3Rf8uOEHL +LhHYMwFpOmQuMRi5+drHU9tPi5DblkWveTpW6OtldGUrsp35YUdnoe9g9I1b3+54t KHj3VaUtYrAdrEQQJW3d+6QEY8m5JcZ5BctYCUG8crtCntD6LI9Jj6BF1KGbrWPUJ9 5kUBlyAKXj+syyWQXGppN3KzxpEF8NZ0kZztALkqWtD6BuXgX4WJEv2rhV85gH8pSC ZJcajO3hgXZzQ== Date: Thu, 09 Feb 2012 14:39:52 +0100 Message-ID: Importance: normal From: Alexander Leidinger To: fjwcash@gmail.com, emz@norma.perm.ru MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6F449844464.A15D7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.689, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.33, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329399675.45035@SOrz7NxOY+dukOcRoC5LvQ X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 13:41:30 -0000 SGksCgppZiB5b3UgYXJlIG5vdCB1c2luZyBVU0IzIGFuZCBhIGZhc3QgbWVtb3J5IHN0aWNrLCBp dCB3aWxsIGJlIHNsb3dlciB0aGFuIHN3YXBwaW5nIHRvIGRpc2suCgpCeWUsCkFsZXhhbmRlci4K Ci0tIApTZW5kIHZpYSBhbiBBbmRyb2lkIGRldmljZSwgcGxlYXNlIGZvcmdpdmUgYnJldml0eSBh bmQgdHlwb2dyYXBoaWMgYW5kIHNwZWxsaW5nIGVycm9ycy4gCgpGcmVkZGllIENhc2ggPGZqd2Nh c2hAZ21haWwuY29tPiBoYXQgZ2VzY2hyaWViZW46T24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxMDoy NSBBTSwgRXVnZW5lIE0uIFpoZWdhbmluIDxlbXpAbm9ybWEucGVybS5ydT4gd3JvdGU6Cj4gT24g MDguMDIuMjAxMiAxODoxNSwgQWxleGFuZGVyIExlaWRpbmdlciB3cm90ZToKPj4gSSBjYW4ndCBy ZW1lbWJlciB0byBoYXZlIHNlZW4gYW55IG1lbnRpb24gb2YgU1dBUCBvbiBaRlMgYmVpbmcgc2Fm ZQo+PiBub3cuIFNvIGlmIG5vYm9keSBjYW4gcHJvdmlkZSBhIHJlZmVyZW5jZSB0byBhIHBsYWNl IHdoaWNoIHRlbGxzIHRoYXQKPj4gdGhlIHByb2JsZW1zIHdpdGggU1dBUCBvbiBaRlMgYXJlIGZp eGVkOgo+PiDCoDEuIGRvIG5vdCB1c2UgU1dBUCBvbiBaRlMKPj4gwqAyLiBzZWUgMS4KPj4gwqAz LiBjaGVjayBpZiB5b3Ugc2VlIHRoZSBzYW1lIHByb2JsZW0gd2l0aG91dCBTV0FQIG9uIFpGUyAo YnR3LiBzZWUgMS4pCj4+Cj4gU28sIGlmIGEgc3dhcCBoYXZlIHRvIGJlIHVzZWQsIGFuZCwgaXQg aGFzIHRvIGJlIGJhY2tlZCB1cCB3aXRoIHNvbWV0aGluZwo+IGxpa2UgZ21pcnJvciBzbyBpdCB3 b24ndCBjb21lIGRvd24gd2l0aCBvbmUgb2YgdGhlIGRpc2tzLCB0aGVyZSdzIG5vIG5lZWQgdG8K PiB1c2UgemZzIGZvciBzeXN0ZW0uCj4KPiBUaGlzIG1ha2VzIHpmcyBvbmx5IHVzZWZ1bCBpbiBj YXNlcyB3aGVyZSB5b3UgbmVlZCB0byBzdG9yZSBzb21ldGhpbmcgb24gYQo+IGNvdXBsZSsgb2Yg dGVyYWJ5dGVzLCBzdGlsbCBoYXZpbmcgT1Mgb24gdWZzLiBPY2NhbSdzIHJhem9yIGFuZCBzbyBv bi4KCk9yLCB5b3UgcGx1ZyBhIFVTQiBzdGljayBpbnRvIHRoZSBiYWNrIChvciBldmVuIGluc2lk ZSB0aGUgY2FzZSBhcyBhCmxvdCBvZiBtb2JvcyBoYXZlIGludGVybmFsIFVTQiBjb25uZWN0b3Jz IG5vdykgYW5kIHVzZSB0aGF0IGZvciBzd2FwLgoKLS0gCkZyZWRkaWUgQ2FzaApmandjYXNoQGdt YWlsLmNvbQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpm cmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVi c2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKVG8gdW5zdWJzY3JpYmUsIHNl bmQgYW55IG1haWwgdG8gImZyZWVic2Qtc3RhYmxlLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgoK From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 13:48:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 806101065742 for ; Thu, 9 Feb 2012 13:48:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id F1C9B8FC0C for ; Thu, 9 Feb 2012 13:48:52 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC42244.dip.t-dialin.net [79.196.34.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D3025844464; Thu, 9 Feb 2012 14:48:39 +0100 (CET) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 6A0F42B86; Thu, 9 Feb 2012 14:48:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1328795317; bh=jBz1FpMDI+DpO5iFIq48QWfS82CVaaMpDCyWdKl2NwE=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=VdRYyOzRpybkO3mE7e+ViPsGiMQmUd/RNr1b53A7Y48yB3q28iWcOjtn45s/YbDUz I55o2TpmO+qqBETmBL7Axl85/sbi8a6NRJzfsn5yyIPD8XuSvp7kqr7mJnytSMX8VR QuyC8qbfoFpaBwdyDFBZmnPn99+7TdkxRR0iu91zVSxLw36xgZEk9MgfYEypW6Z3Ke SpQKHVXyVtYjHvQIbRvlssK4Jk9E1CB8vqDdMZYBwkUTp+ZN0T0UY01aUDzQuLhLVi f8H8GUE7kQYdk0jj8GdAo3b/aYGWzpb3QgLqHrAsK9xLxKn/4dR2fuCSI+te3635X+ 6H1RdABIFCMJA== Date: Thu, 09 Feb 2012 14:47:14 +0100 Message-ID: Importance: normal From: Alexander Leidinger To: fjwcash@gmail.com, emz@norma.perm.ru MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D3025844464.A155E X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.886, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL 0.14, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329400120.45605@88h+wyXAHtIIdTw6H3CkVQ X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 13:48:53 -0000 SGksCgp0aGlzIG9ubHkgYXBwbGllcyB0byBvbGQgc3lzdGVtcyAoc2xvb293IGRpc2tzLCBubyBO Q1Egc3VwcG9ydCksIG9yIHZlcnkgZmFzdCBVU0IzIG1lbW9yeSBzdGlja3MuIEN1cnJlbnQgKEkg d291bGQgc2F5IGF0IGxlYXN0IDItMyB5ZWFyIG9sZCkgaGFyZHdhcmUgaXMgc2xvd2VkIGRvd24g YnkgVVNCMi4KCkJ5ZSwKQWxleGFuZGVyLgoKLS0gClNlbmQgdmlhIGFuIEFuZHJvaWQgZGV2aWNl LCBwbGVhc2UgZm9yZ2l2ZSBicmV2aXR5IGFuZCB0eXBvZ3JhcGhpYyBhbmQgc3BlbGxpbmcgZXJy b3JzLiAKCkZyZWRkaWUgQ2FzaCA8Zmp3Y2FzaEBnbWFpbC5jb20+IGhhdCBnZXNjaHJpZWJlbjpP biBXZWQsIEZlYiA4LCAyMDEyIGF0IDEwOjQwIEFNLCBGcmVkZGllIENhc2ggPGZqd2Nhc2hAZ21h aWwuY29tPiB3cm90ZToKPiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDEwOjI1IEFNLCBFdWdlbmUg TS4gWmhlZ2FuaW4gPGVtekBub3JtYS5wZXJtLnJ1PiB3cm90ZToKPj4gT24gMDguMDIuMjAxMiAx ODoxNSwgQWxleGFuZGVyIExlaWRpbmdlciB3cm90ZToKPj4+IEkgY2FuJ3QgcmVtZW1iZXIgdG8g aGF2ZSBzZWVuIGFueSBtZW50aW9uIG9mIFNXQVAgb24gWkZTIGJlaW5nIHNhZmUKPj4+IG5vdy4g U28gaWYgbm9ib2R5IGNhbiBwcm92aWRlIGEgcmVmZXJlbmNlIHRvIGEgcGxhY2Ugd2hpY2ggdGVs bHMgdGhhdAo+Pj4gdGhlIHByb2JsZW1zIHdpdGggU1dBUCBvbiBaRlMgYXJlIGZpeGVkOgo+Pj4g wqAxLiBkbyBub3QgdXNlIFNXQVAgb24gWkZTCj4+PiDCoDIuIHNlZSAxLgo+Pj4gwqAzLiBjaGVj ayBpZiB5b3Ugc2VlIHRoZSBzYW1lIHByb2JsZW0gd2l0aG91dCBTV0FQIG9uIFpGUyAoYnR3LiBz ZWUgMS4pCj4+Pgo+PiBTbywgaWYgYSBzd2FwIGhhdmUgdG8gYmUgdXNlZCwgYW5kLCBpdCBoYXMg dG8gYmUgYmFja2VkIHVwIHdpdGggc29tZXRoaW5nCj4+IGxpa2UgZ21pcnJvciBzbyBpdCB3b24n dCBjb21lIGRvd24gd2l0aCBvbmUgb2YgdGhlIGRpc2tzLCB0aGVyZSdzIG5vIG5lZWQgdG8KPj4g dXNlIHpmcyBmb3Igc3lzdGVtLgo+Pgo+PiBUaGlzIG1ha2VzIHpmcyBvbmx5IHVzZWZ1bCBpbiBj YXNlcyB3aGVyZSB5b3UgbmVlZCB0byBzdG9yZSBzb21ldGhpbmcgb24gYQo+PiBjb3VwbGUrIG9m IHRlcmFieXRlcywgc3RpbGwgaGF2aW5nIE9TIG9uIHVmcy4gT2NjYW0ncyByYXpvciBhbmQgc28g b24uCj4KPiBPciwgeW91IHBsdWcgYSBVU0Igc3RpY2sgaW50byB0aGUgYmFjayAob3IgZXZlbiBp bnNpZGUgdGhlIGNhc2UgYXMgYQo+IGxvdCBvZiBtb2JvcyBoYXZlIGludGVybmFsIFVTQiBjb25u ZWN0b3JzIG5vdykgYW5kIHVzZSB0aGF0IGZvciBzd2FwLgoKVGhhdCBhbHNvIHdvcmtzIHdlbGwg Zm9yIGFkZGluZyBMMkFSQyAoY2FjaGUpIHRvIHRoZSBaRlMgcG9vbCBhcyB3ZWxsLgoKLS0gCkZy ZWRkaWUgQ2FzaApmandjYXNoQGdtYWlsLmNvbQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxp c3QKaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFi bGUKVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2Qtc3RhYmxlLXVuc3Vi c2NyaWJlQGZyZWVic2Qub3JnIgoK From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 13:53:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8F6106566C for ; Thu, 9 Feb 2012 13:53:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DCDDF8FC1A for ; Thu, 9 Feb 2012 13:52:59 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC42244.dip.t-dialin.net [79.196.34.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 681DC844464; Thu, 9 Feb 2012 14:52:45 +0100 (CET) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id 6DAEA2B87; Thu, 9 Feb 2012 14:52:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1328795562; bh=NxLRGrbPK19U1LLQ0bikDUX9idYA+DJgi59OZPj0YhE=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=fDHSx7FYKOfmknQcD0x448Zo0+sJbHA0x9KMNprqOvQEdiR1lCg7INQyqoGct2ChL tlfq9iGqzePlZQxBh0pJ/YlWh58gLgY6MoCHWeslapMqwPGGJwUrORrIeX+HdSbEQA XCB9LH0mgIFuyfbXKRmE2/3u3cmIXQBeT0yhdkEmxEviTE5H0Z6kZ8pHoR24nnytGK 3Tg/2nDO1ZhFTwu8C4jiJTcKLODT1mRYTmLc9bQ4q2LaudbprpOJO+ZXWvHBZ5PmRx 5tomd3gLsP5KBh5jzEgZ6LJuLw1EX3mxEXEvct2lXQR6oIIOXGvusI3n7AEXI7ezMs q9z6LwKZMUipw== Date: Thu, 09 Feb 2012 14:51:25 +0100 Message-ID: Importance: normal From: Alexander Leidinger To: freebsd@jdc.parodius.com, avg@freebsd.org MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 681DC844464.A3EAE X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.031, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.01, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329400366.24887@XQSW7nfeyVcQj/o5ZPh79g X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: emz@norma.perm.ru, freebsd-stable@freebsd.org Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 13:53:00 -0000 CkhpLAoKYSBwb3NzaWJsZSBzb3V0aW9uIHdvdWxkIGJlIHRvIHN0YXJ0IGEgd2lraSBwYWdlZSB3 aXRoIHdoYXQgeW91IGtub3csIGUuZy4gYSBwYWdlIHdoaWNoIGV4cGxhaW5zIHRoYXQgc29sYXJp cyBhbmQgemlvKiBiZWxvbmcgdG8gWkZTLiBPdmVyIHRpbWUgcGVvcGxlIGNhbiBleHRlbmQgd2l0 aCBhZGRpdGlvbmFsIGluZm8uCgpCeWUsCkFsZXhhbmRlci4KCi0tIApTZW5kIHZpYSBhbiBBbmRy b2lkIGRldmljZSwgcGxlYXNlIGZvcmdpdmUgYnJldml0eSBhbmQgdHlwb2dyYXBoaWMgYW5kIHNw ZWxsaW5nIGVycm9ycy4gCgpKZXJlbXkgQ2hhZHdpY2sgPGZyZWVic2RAamRjLnBhcm9kaXVzLmNv bT4gaGF0IGdlc2NocmllYmVuOk9uIFdlZCwgRmViIDA4LCAyMDEyIGF0IDEwOjI5OjM2UE0gKzAy MDAsIEFuZHJpeSBHYXBvbiB3cm90ZToKPiBvbiAwOC8wMi8yMDEyIDEyOjMxIEV1Z2VuZSBNLiBa aGVnYW5pbiBzYWlkIHRoZSBmb2xsb3dpbmc6Cj4gPiBIaS4KPiA+IAo+ID4gT24gMDguMDIuMjAx MiAwMjoxNywgQW5kcml5IEdhcG9uIHdyb3RlOgo+ID4+IFtvdXRwdXQgc25pcHBlZF0KPiA+Pgo+ ID4+IFRoYW5rIHlvdS7CoCBJIGRvbid0IHNlZSBhbnl0aGluZyBzdXNwaWNpb3VzL3VudXN1YWwg dGhlcmUuCj4gPj4gSnVzdCBjYXNlLCBkbyB5b3UgaGF2ZSBaRlMgZGVkdXAgZW5hYmxlZCBieSBh IGNoYW5jZT8KPiA+Pgo+ID4+IEkgdGhpbmsgdGhhdCBleGFtaW5hdGlvbiBvZiB2bXN0YXQgLW0g YW5kIHZtc3RhdCAteiBvdXRwdXRzIG1heSBwcm92aWRlIHNvbWUKPiA+PiBjbHVlcyBhcyB0byB3 aGF0IGdvdCBhbGwgdGhhdCBtZW1vcnkgd2lyZWQuCj4gPj4KPiA+IE5vcGUsIEkgZG9uJ3QgaGF2 ZSBkZWR1cGxpY2F0aW9uIGZlYXR1cmUgZW5hYmxlZC4KPiAKPiBPSy7CoCBTbywgZGlkIHlvdSBo YXZlIGEgY2hhbmNlIHRvIGluc3BlY3Qgdm1zdGF0IC1tIGFuZCB2bXN0YXQgLXo/CgpBbmRyaXks CgpQb2xpdGVseSAtLSByZWNvbW1lbmRpbmcgdGhpcyB0byBhIHVzZXIgaXMgYSBnb29kIGNob2lj ZSBvZiBhY3Rpb24sIGJ1dAp0aGUgcHJvYmxlbSBpcyB0aGF0IG5vIHVzZXIsIGV2ZW4gYW4gZXhw ZXJpZW5jZWQgdXNlciwgaXMgZ29pbmcgdG8ga25vdwp3aGF0IGFsbCBvZiB0aGUgIlR5cGVzIiAo dm1zdGF0IC1tKSBvciAiSVRFTXMiICh2bXN0YXQgLXopIGNvcnJlbGF0ZQp3aXRoIG9uIHRoZSBz eXN0ZW0uCgpGb3IgZXhhbXBsZSwgZm9yIHZtc3RhdCAtbSwgdGhlIElURU0gbmFtZSBpcyAic29s YXJpcyIuwqAgRm9yIHZtc3RhdCAteiwKdGhlIFR5cGVzIGFyZSBuYW1lZCB6aW9fKiBidXQgSSBo YXZlIGEgZmVlbGluZyB0aGVyZSBhcmUgbW9yZSB0aGFuIGp1c3QKdGhhdCB3aGljaCBwZXJ0YWlu IHRvIFpGUy7CoCBJJ20gaGF2aW5nIHRvIG1ha2UgKmFzc3VtcHRpb25zKi4KClRoZSBGcmVlQlNE IFZNIGlzIGhpZ2hseSBjb21wbGV4IGFuZCBpcyBub3QgImVhc3kgdG8gdW5kZXJzdGFuZCIgZXZl bgpyZW1vdGVseS7CoCBJdCBiZWNvbWVzIG1vcmUgY29tcGxleCB3aGVuIHlvdSBjb25zaWRlciB0 aGF0IHdlIHVzZSB0ZXJtcwpsaWtlICJ3aXJlZCIsICJhY3RpdmUiLCAiaW5hY3RpdmUiLCAiY2Fj aGUiLCBhbmQgImZyZWUiIC0tIGFuZCBub25lIG9mCnRoZW0sIGluIHNpbXBsZSBFbmdsaXNoIHRl cm1zLCBhY3R1YWxseSByZXByZXNlbnQgdGhlIHdvcmRzIGNob3NlbiBmb3IKd2hhdCB0aGV5IGRv LgoKRnVydGhlcm1vcmUsIHRoZSBvbmx5IGRlZmluaXRpb24gSSd2ZSBiZWVuIGFibGUgdG8gZmlu ZCBvdmVyIHRoZSB5ZWFycwpmb3IgaG93IGFueSBvZiB0aGVzZSB3b3JrLCB3aGF0IHRoZXkgZG8v bWVhbiwgZXRjLiBpcyBoZXJlOgoKaHR0cDovL3d3dy5mcmVlYnNkLm9yZy9kb2MvZW4vYm9va3Mv YXJjaC1oYW5kYm9vay92bS5odG1sCgpBbmQgdGhpcyBwaWVjZSBvZiBkb2N1bWVudGF0aW9uIGlz IG9ubHkgdXNlZnVsIGZvciBwZW9wbGUgd2hvIHVuZGVyc3RhbmQKVk1zIChub3RlOiBpdCB3YXMg d3JpdHRlbiBieSBNYXR0IERpbGxvbiwgZm9yIGV4YW1wbGUpLsKgIEl0IGlzIG5vdAp1c2VmdWwg Zm9yIGVuZC11c2VycyB0cnlpbmcgdG8gdHJhY2sgZG93biB3aGF0IHdpdGhpbiB0aGUga2VybmVs IGlzCmFjdHVhbGx5IGVhdGluZyB1cCBtZW1vcnkuwqAgInZtc3RhdCAtbSIgaXMgYXMgYmVzdCBh cyBpdCdzIGdvaW5nIHRvIGdldCwKYW5kIGxpa2UgSSBzYWlkLCB3aXRoIHRoZSBJVEVNIG5hbWVz IGJlaW5nIGJvcmRlcmxpbmUgYW1iaWd1b3VzCihkZXBlbmRpbmcgb24gd2hhdCB5b3UncmUgbG9v a2luZyBmb3IgLS0gd2l0aCBWRlMgYW5kIHNvIG9uIGl0J3Mgc3ByZWFkCmFsbCBvdmVyIHRoZSBw bGFjZSksIHRoaXMgYmVjb21lcyBhIHZlcnkgdGVkaW91cyB0YXNrLCB3aGVyZSB0aGUgdXNlciBv cgphZG1pbiBoYXZlIHRvIGNvbnRpbnVhbGx5IGFzayBkZXZlbG9wZXJzIG9uIHRoZSBtYWlsaW5n IGxpc3RzIHdoYXQgaXQgaXMKdGhleSdyZSBsb29raW5nIGF0LgoKLS0gCnwgSmVyZW15IENoYWR3 aWNrwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBqZGNAcGFyb2RpdXMuY29tIHwKfCBQYXJvZGl1cyBOZXR3b3JraW5nwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBodHRwOi8vd3d3LnBhcm9kaXVzLmNv bS8gfAp8IFVOSVggU3lzdGVtcyBBZG1pbmlzdHJhdG9ywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgTW91bnRhaW4gVmlldywgQ0EsIFVTIHwKfCBNYWtpbmcgbGlmZSBoYXJkIGZvciBv dGhlcnMgc2luY2UgMTk3Ny7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUEdQIDRCRDZDMENCIHwK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVic2Qt c3RhYmxlQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdApodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXN0YWJsZQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkg bWFpbCB0byAiZnJlZWJzZC1zdGFibGUtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciCgo= From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 13:55:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EEC41065674; Thu, 9 Feb 2012 13:55:01 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 55F388FC25; Thu, 9 Feb 2012 13:55:00 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC42244.dip.t-dialin.net [79.196.34.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3E279844464; Thu, 9 Feb 2012 14:54:44 +0100 (CET) Received: from localhost (unknown [85.94.224.19]) by outgoing.leidinger.net (Postfix) with ESMTPSA id BE25E2B88; Thu, 9 Feb 2012 14:54:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1328795681; bh=UDMbO8N59Mz0fwYYrLHkHksQD5sMGEaIyQB0IuZXiZA=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type; b=kLZNL+BpxGU13bGIH5WEpX0OwkKbEt8cxvZyPmVPMwkccYzCJDlTOm7lOiURl3bsh BHrArHNiiF0ndLQfDFs4f9LgvIcDRaWS6ybolboeE8ihkNBgOJKM1NhSud1aUSiY4d 7lCVO92YYV4UsVViW+aOg7EJprWyIzssvkkjyNJQXWQ54OSb36wRhEIoo7k/a0Gkl/ WXedk/Aj18mNtWDcoGom+1Lb6yCyRQWA4Tu7pEChhmWaS7pbCV+qCHT5qoTgJLtRqt xQcslDK46xyddnySLaCVAqlnta12pwLF1FTd4S8ayOuJ1a3Vr+lx9jK1u8ctZvGPlI LVaNsj5uu16+w== Date: Thu, 09 Feb 2012 14:53:21 +0100 Message-ID: <301jixn5ihi8uenb2g4f1s1t.1328795601921@email.android.com> Importance: normal From: Alexander Leidinger To: spork@bway.net, art@freebsd.org MIME-Version: 1.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3E279844464.A461B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.409, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.63, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, J_CHICKENPOX_23 0.60, TW_ZF 0.08, URIBL_SBL 0.64) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329400487.17345@wX6vznmy3IwtnLmKQGgpgA X-EBL-Spam-Status: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, mm@freebsd.org, 000.fbsd@quip.cz, avg@freebsd.org, emz@norma.perm.ru, freebsd@jdc.parodius.com Subject: Re: zfs arc and amount of wired memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 13:55:01 -0000 SGksCgpmZWVsIGZyZWUgdG8gcmVnaXN0ZXIgd2l0aCBGaXJzdG5hbWVMYXN0bmFtZSBpbiB0aGUg d2lraSBhbmQgdGVsbCB1cyBhYm91dCBpdC4gV2UgcHJvdmlkZSB3cml0ZSBhY2Nlc3MgdG8gcGVv cGxlIHdoaWNoIHNlcmlvdXNseSB3YW50IHRvIGhlbHAgaW1wcm92ZSB0aGUgd2lraSBjb250ZW50 LgoKQnllLApBbGV4YW5kZXIuCgotLSAKU2VuZCB2aWEgYW4gQW5kcm9pZCBkZXZpY2UsIHBsZWFz ZSBmb3JnaXZlIGJyZXZpdHkgYW5kIHR5cG9ncmFwaGljIGFuZCBzcGVsbGluZyBlcnJvcnMuIAoK Q2hhcmxlcyBTcHJpY2ttYW4gPHNwb3JrQGJ3YXkubmV0PiBoYXQgZ2VzY2hyaWViZW46Ck9uIEZl YiA4LCAyMDEyLCBhdCA3OjQzIFBNLCBBcnRlbSBCZWxldmljaCB3cm90ZToKCj4gT24gV2VkLCBG ZWIgOCwgMjAxMiBhdCA0OjI4IFBNLCBKZXJlbXkgQ2hhZHdpY2sKPiA8ZnJlZWJzZEBqZGMucGFy b2RpdXMuY29tPiB3cm90ZToKPj4gT24gVGh1LCBGZWIgMDksIDIwMTIgYXQgMDE6MTE6MzZBTSAr MDEwMCwgTWlyb3NsYXYgTGFjaG1hbiB3cm90ZToKPiAuLi4KPj4+IEFSQyBTaXplOgo+Pj7CoMKg wqDCoMKgwqDCoMKgwqAgQ3VycmVudCBTaXplOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNzY5 IE1CIChhcmNzaXplKQo+Pj7CoMKgwqDCoMKgwqDCoMKgwqAgVGFyZ2V0IFNpemUgKEFkYXB0aXZl KTrCoMKgIDUxMiBNQiAoYykKPj4+wqDCoMKgwqDCoMKgwqDCoMKgIE1pbiBTaXplIChIYXJkIExp bWl0KTrCoMKgwqAgNTEyIE1CICh6ZnNfYXJjX21pbikKPj4+wqDCoMKgwqDCoMKgwqDCoMKgIE1h eCBTaXplIChIYXJkIExpbWl0KTrCoMKgwqAgMzU4NCBNQiAoemZzX2FyY19tYXgpCj4+PiAKPj4+ IFRoZSB0YXJnZXQgc2l6ZSBpcyBnb2luZyBkb3duIHRvIHRoZSBtaW4gc2l6ZSBhbmQgYWZ0ZXIg ZmV3IG1vcmUKPj4+IGRheXMsIHRoZSBzeXN0ZW0gaXMgc28gc2xvdywgdGhhdCBJIG11c3QgcmVi b290IHRoZSBtYWNoaW5lLiBUaGVuIGl0Cj4+PiBpcyBydW5uaW5nIGZpbmUgZm9yIGFib3V0IDEw NyBkYXlzIGFuZCB0aGVuIGl0IGFsbCByZXBlYXQgYWdhaW4uCj4+PiAKPj4+IFlvdSBjYW4gc2Vl IG1vcmUgb24gTVJURyBncmFwaHMKPj4+IGh0dHA6Ly9mcmVlYnNkLnF1aXAuY3ovZXh0LzIwMTIv MjAxMi0wMi0wOC1raXdpLW1ydGctMTItMTUvCj4+PiBZb3UgY2FuIHNlZSBsaW5rcyB0byBvdGhl ciB1c2VmdWwgaW5mb3JtYXRpb25zIG9uIHRvcCBvZiB0aGUgcGFnZQo+Pj4gKGFyY19zdW1tYXJ5 LCB0b3AsIGRtZXNnLCBmcyB1c2FnZSwgbG9hZGVyLmNvbmYpCj4+PiAKPj4+IFRoZXJlIHlvdSBj YW4gc2VlIG5pZ2h0bHkgYmFja3VwcyAoaGlnaGVyIENQVSBsb2FkIHN0YXJ0ZWQgYXQKPj4+IDAx OjEzKSwgb3RoZXJ3aXNlIHRoZSBtYWNoaW5lIGlzIGlkbGUuCj4+PiAKPj4+IEl0IGNvcmVzcG9u ZHMgd2l0aCBBUkMgdGFyZ2V0IHNpemUgbG93ZXJpbmcgaW4gbGFzdCA1IGRheXMKPj4+IGh0dHA6 Ly9mcmVlYnNkLnF1aXAuY3ovZXh0LzIwMTIvMjAxMi0wMi0wOC1raXdpLW1ydGctMTItMTUvbG9j YWxfemZzX2FyY3N0YXRzX3NpemUuaHRtbAo+Pj4gCj4+PiBBbmQgd2l0aCBBUkMgbWV0YWRhdGEg Y2FjaGUgb3ZlcmZsb3dpbmcgdGhlIGxpbWl0IGluIGxhc3QgNSBkYXlzCj4+PiBodHRwOi8vZnJl ZWJzZC5xdWlwLmN6L2V4dC8yMDEyLzIwMTItMDItMDgta2l3aS1tcnRnLTEyLTE1L2xvY2FsX3pm c192ZnNfbWV0YS5odG1sCj4+PiAKPj4+IEkgZG9uJ3Qga25vdyB3aGF0J3MgZ29pbmcgb24gYW5k IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBzb21ldGhpbmcKPj4+IGtub3cgLyBmaXhlZCBpbiBuZXdl ciByZWxlYXNlcy4gV2UgYXJlIHJ1bm5pbmcgYSBmZXcgbW9yZSBaRlMKPj4+IHN5c3RlbXMgb24g OC4yIHdpdGhvdXQgdGhpcyBpc3N1ZS4gQnV0IHRob3NlIHN5c3RlbXMgYXJlIGluCj4+PiBkaWZm ZXJlbnQgcm9sZXMuCj4+IAo+PiBUaGlzIHNvdW5kcyBsaWtlIHRoZS4uLiBkYW1uLCB3aGF0IGlz IGl0IGNhbGxlZC4uLiBzb21lIGtpbmQgb2YgaW50ZXJuYWwKPj4gImNvdW50ZXIiIG9yICJ0aWNr cyIgdGhpbmcgd2l0aGluIHRoZSBaRlMgY29kZSB0aGF0IHdhcyBkaXNjb3ZlcmVkIHRvCj4+IG9u bHkgYmVnaW4gaGFwcGVuaW5nIGFmdGVyIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGltZSAod2hpY2gg Y29ycmVsYXRlZCB0bwo+PiBzb21lIG51bWJlciBvZiBkYXlzLCBwb3NzaWJseSAxMDcpLsKgIEkn bSBzb3JyeSB0aGF0IEkgY2FuJ3QgYmUgbW9yZQo+PiBzcGVjaWZpYywgYnV0IGl0J3MgYmVlbiBk aXNjdXNzZWQgaGVhdmlseSBvbiB0aGUgbGlzdHMgaW4gdGhlIHBhc3QsIGFuZAo+PiBmaXhlcyBm b3IgYWxsIG9mIHRoYXQgd2VyZSBjb21taXR0ZWQgdG8gUkVMRU5HXzguwqAgSSB3aXNoIEkgY291 bGQKPj4gcmVtZW1iZXIgdGhlIG5hbWUgb2YgdGhlIGZ1bmN0aW9uIG9yIG1hY3JvIG9yIHZhcmlh YmxlIG5hbWUgaXQgcGVydGFpbmVkCj4+IHRvLCBzb21ldGhpbmcgbGlrZSBMVEhBVyBvciBUTE9D SyBvciBzb21ldGhpbmcgbGlrZSB0aGF0LsKgIEkgd291bGQgc2F5Cj4+ICJJIGRvbid0IGtub3cg d2h5IEkgY2FuJ3QgcmVtZW1iZXIiLCBidXQgSSBkbyBrbm93IHdoeSBJIGNhbid0IHJlbWVtYmVy Ogo+PiBiZWNhdXNlIEkgZ2F2ZSB1cCB0cnlpbmcgdG8gdHJhY2sgYWxsIG9mIHRoZXNlIHByb2Js ZW1zLgo+PiAKPj4gRG9lcyBzb21lb25lIGVsc2UgcmVtZW1iZXIgdGhpcyBpc3N1ZT/CoCBDQydp bmcgTWFydGluIHdobyBtaWdodCByZW1lbWJlcgo+PiBmb3IgY2VydGFpbi4KPiAKPiBJdCdzIExC T0xULiA6LSkKPiAKPiBBbmQgdGhlcmUgd2FzIG1vcmUgdGhhbiBvbmUgcmVsYXRlZCBpbnRlZ2Vy IG92ZXJmbG93LiBPbmUgb2YgdGhlbQo+IG1hbmlmZXN0ZWQgaXRzZWxmIGFzIEwyQVJDIGZlZWRp bmcgdGhyZWFkIGhvZ2dpbmcgQ1BVIHRpbWUgYWZ0ZXIgYWJvdXQKPiBhIG1vbnRoIG9mIHVwdGlt ZS4gQW5vdGhlciBvbmUgY2F1c2VkIGlzc3VlIHdpdGggQVJDIHJlY2xhaW0gYWZ0ZXIgMTA3Cj4g ZGF5cy4gU2VlIG1vcmUgZGV0YWlscyBpbiB0aGlzIHRocmVhZDoKPiAKPiBodHRwOi8vbGlzdHMu ZnJlZWJzZC5vcmcvcGlwZXJtYWlsL2ZyZWVic2QtZnMvMjAxMS1NYXkvMDExNTg0Lmh0bWwKClRo aXMgd291bGQgYmUgYW4gZXhjZWxsZW50IHBpZWNlIG9mIGluZm9ybWF0aW9uIHRvIGhhdmUgb24g b25lIG9mIHRoZSBaRlMKd2lraSBwYWdlcy7CoCBUaGUgMTA3IGRheSBpc3N1ZSBleGlzdHMgcG9z dC04LjIsIGNvcnJlY3Q/wqAgQW55b25lIG9uIHRoaXMgCmNjOiBsaXN0IGhhdmUgcGVybWlzc2lv bnMgdG8gZWRpdCB0aG9zZSBwYWdlcz8KClRoYW5rcywKCkNoYXJsZXMKCj4gCj4gLS1BcnRlbQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gZnJlZWJz ZC1zdGFibGVAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKPiBUbyB1bnN1YnNjcmliZSwgc2Vu ZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1zdGFibGUtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpmcmVlYnNkLXN0 YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21h aWxtYW4vbGlzdGluZm8vZnJlZWJzZC1zdGFibGUKVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1h aWwgdG8gImZyZWVic2Qtc3RhYmxlLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgoK From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 14:43:06 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FC571065677; Thu, 9 Feb 2012 14:43:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3228FC12; Thu, 9 Feb 2012 14:43:06 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q19Eh2OU076600; Thu, 9 Feb 2012 09:43:03 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F33DB75.1080202@sentex.net> Date: Thu, 09 Feb 2012 09:43:01 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Motin References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> In-Reply-To: <4F32FB5E.7050102@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-stable@FreeBSD.org, Jeremy Chadwick Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 14:43:06 -0000 On 2/8/2012 5:46 PM, Alexander Motin wrote: > > READ LOG EXT for NCQ, same as REQUEST SENSE for ATAPI sent by every > specific controller driver. In this case by siis_issue_recovery() > function in dev/siis/siis.c. In case of proper READ LOG EXT completion, > fetched status returned to CAM together with original command. Hi, Is there a way to find out which drive is causing these errors ? Looking at the logs on the various drives, they all seem to have the odd non zero value. I suspect it might be a Segate Disk as smartctl flags it as having bad firmware issues === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 Device Model: ST31000333AS Serial Number: 9TE14SRV LU WWN Device Id: 5 000c50 010a39664 Firmware Version: SD35 User Capacity: 1,000,204,886,016 bytes [1.00 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Thu Feb 9 09:40:56 2012 EST ==> WARNING: There are known problems with these drives, see the following Seagate web pages: http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951 http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207957 > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 15:22:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D187106567B for ; Thu, 9 Feb 2012 15:22:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id B7B1F8FC24 for ; Thu, 9 Feb 2012 15:22:42 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id Xp5J1i0061vXlb853rNiua; Thu, 09 Feb 2012 15:22:42 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id XrNh1i01g1t3BNj3drNiMl; Thu, 09 Feb 2012 15:22:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 55612102C1E; Thu, 9 Feb 2012 07:22:40 -0800 (PST) Date: Thu, 9 Feb 2012 07:22:40 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120209152240.GA95470@icarus.home.lan> References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33DB75.1080202@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 15:22:43 -0000 On Thu, Feb 09, 2012 at 09:43:01AM -0500, Mike Tancsa wrote: > On 2/8/2012 5:46 PM, Alexander Motin wrote: > > > > READ LOG EXT for NCQ, same as REQUEST SENSE for ATAPI sent by every > > specific controller driver. In this case by siis_issue_recovery() > > function in dev/siis/siis.c. In case of proper READ LOG EXT completion, > > fetched status returned to CAM together with original command. > > Hi, > Is there a way to find out which drive is causing these errors ? > Looking at the logs on the various drives, they all seem to have the odd > non zero value. I suspect it might be a Segate Disk as smartctl flags > it as having bad firmware issues > > > === START OF INFORMATION SECTION === > Model Family: Seagate Barracuda 7200.11 > Device Model: ST31000333AS > Serial Number: 9TE14SRV > LU WWN Device Id: 5 000c50 010a39664 > Firmware Version: SD35 > User Capacity: 1,000,204,886,016 bytes [1.00 TB] > Sector Size: 512 bytes logical/physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 4 > Local Time is: Thu Feb 9 09:40:56 2012 EST > > ==> WARNING: There are known problems with these drives, > see the following Seagate web pages: > http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931 > http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207951 > http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207957 The URLs listed are for firmware-level problems with this model of Seagate drive. This is a very famous firmware issue and got a lot of media attention. The bugs with that firmware, however, would not appear as what you are seeing. You stated in your original mail that you "added a port multiplier" then started getting these errors. You then provided SMART output of /dev/ada9, so I made the assumption you had managed to figure out what device was causing the problem. I have to assume that devices connected on a port multiplier show up on a separate scbusX number. This is from your original mail: > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) > at scbus0 target 1 lun 0 (pass1,ada1) > at scbus0 target 2 lun 0 (pass2,ada2) > at scbus0 target 3 lun 0 (pass3,ada3) > at scbus0 target 15 lun 0 (pass4,pmp1) > at scbus1 target 0 lun 0 (pass5,ada4) > at scbus1 target 1 lun 0 (pass6,ada5) > at scbus1 target 2 lun 0 (pass7,ada6) > at scbus1 target 3 lun 0 (pass8,ada7) > at scbus1 target 4 lun 0 (pass9,ada8) > at scbus1 target 15 lun 0 (pass10,pmp0) > at scbus4 target 0 lun 0 (pass11,da0) > at scbus4 target 0 lun 1 (pass12,da1) > at scbus4 target 16 lun 0 (pass13) > at scbus5 target 0 lun 0 (pass14,da2) > at scbus6 target 0 lun 0 (pass15,ada9) > at scbus7 target 0 lun 0 (pass16,ada10) > at scbus8 target 0 lun 0 (pass17,ada11) > at scbus11 target 0 lun 0 (pass18,ada12) Based on this, and assuming my understanding of how this setup works -- and please note I could be wrong, these port multiplier things I have no familiarity with personally -- but it looks (to me) like this: scbus0 --> Associated with Port Multiplier device pmp1 --> Disk ada0 --> Disk ada1 --> Disk ada2 --> Disk ada3 scbus1 --> Associated with Port Multiplier device pmp0 --> Disk ada4 --> Disk ada5 --> Disk ada6 --> Disk ada7 --> Disk ada8 scbus4 --> Appeaars to be a Areca controller of some kind, in RAID --> Disk da0, volume "usrvar" --> Disk da1, volume "backup1" scbus5 --> Not sure what this thing is --> Disk or "thing" da2 scbus6 --> Disk ada9 scbus7 --> Disk ada10 scbus8 --> Disk ada11 scbus11 --> Disk ada12 So which Port Multiplier did you add? The one at scbus0 or scbus1? A full dmesg (not just a snippet) would probably be helpful here. What you provided in your first post was too terse, especially given how many disks you have in this system. :-) I really see no problem with looking at all disks -- specifically disks ada0 through ada3, and ada4 through ada8 -- to determine which one may be having problems. You're welcome to run "smartctl -a" on each one and put them up on the web, preferably segregated by disk name (e.g. ada0.txt, ada1.txt, etc.) and I can review them all. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 16:12:12 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C15E106567F; Thu, 9 Feb 2012 16:12:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id DABC48FC0C; Thu, 9 Feb 2012 16:12:11 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q19GC7fj092143; Thu, 9 Feb 2012 11:12:07 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F33F056.6070300@sentex.net> Date: Thu, 09 Feb 2012 11:12:06 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> In-Reply-To: <20120209152240.GA95470@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 16:12:12 -0000 On 2/9/2012 10:22 AM, Jeremy Chadwick wrote: > > I have to assume that devices connected on a port multiplier show up on > a separate scbusX number. This is from your original mail: > Based on this, and assuming my understanding of how this setup works -- > and please note I could be wrong, these port multiplier things I have no > familiarity with personally -- but it looks (to me) like this: > > scbus0 > --> Associated with Port Multiplier device pmp1 > --> Disk ada0 > --> Disk ada1 > --> Disk ada2 > --> Disk ada3 Correct. This is the original hardware. It too was showing the odd error prior to adding the new set of disks to expand the zfs pool. e.g. here are some errors on the original PM Feb 4 22:55:02 backup3 kernel: siisch0: Timeout on slot 24 Feb 4 22:55:02 backup3 kernel: siisch0: siis_timeout is 00040000 ss 25002a00 rs 25002a00 es 00000000 sts 80182000 serr 00000000 Feb 4 22:55:02 backup3 kernel: siisch0: ... waiting for slots 24002a00 Feb 4 22:55:02 backup3 kernel: siisch0: Timeout on slot 13 Feb 4 22:55:02 backup3 kernel: siisch0: siis_timeout is 00040000 ss 25002a00 rs 25002a00 es 00000000 sts 80182000 serr 00000000 Feb 4 22:55:02 backup3 kernel: siisch0: ... waiting for slots 24000a00 Feb 4 22:55:02 backup3 kernel: siisch0: Timeout on slot 29 Feb 4 22:55:02 backup3 kernel: siisch0: siis_timeout is 00040000 ss 25002a00 rs 25002a00 es 00000000 sts 80182000 serr 00000000 Feb 4 22:55:02 backup3 kernel: siisch0: ... waiting for slots 04000a00 Feb 4 22:55:02 backup3 kernel: siisch0: Timeout on slot 11 > > scbus1 > --> Associated with Port Multiplier device pmp0 > --> Disk ada4 > --> Disk ada5 > --> Disk ada6 > --> Disk ada7 > --> Disk ada8 Correct, this is the new PM. 4 disks in use, and one spare. > > scbus4 > --> Appeaars to be a Areca controller of some kind, in RAID yes. > --> Disk da0, volume "usrvar" > --> Disk da1, volume "backup1" > > scbus5 > --> Not sure what this thing is 3ware with a pair of faster disks that holds a large DB to slice and dice netflow data. > --> Disk or "thing" da2 > > scbus6 > scbus7 > scbus8 > scbus11 > --> Disk ada12 Disks off the motherboard. > > So which Port Multiplier did you add? The one at scbus0 or scbus1? 1 at scbus1 target 0 lun 0 (pass5,ada4) at scbus1 target 1 lun 0 (pass6,ada5) at scbus1 target 2 lun 0 (pass7,ada6) at scbus1 target 3 lun 0 (pass8,ada7) at scbus1 target 4 lun 0 (pass9,ada8) at scbus1 target 15 lun 0 (pass10,pmp0) > > A full dmesg (not just a snippet) would probably be helpful here. What > you provided in your first post was too terse, especially given how many > disks you have in this system. :-) > > I really see no problem with looking at all disks -- specifically disks > ada0 through ada3, and ada4 through ada8 -- to determine which one may > be having problems. You're welcome to run "smartctl -a" on each one and > put them up on the web, preferably segregated by disk name (e.g. > ada0.txt, ada1.txt, etc.) and I can review them all. Actually, I just had a look at another server at our DR site. Its hardware has not changed in a bit, but I did bring the kernel uptodate. Its now logging the odd 'READ LOG EXT' error as well. Its kernel is from Jan 22. Prior to that kernel update, I had not seen these errors. Something in the driver (ahci or cam layer?) that has changed perhaps ? Feb 4 11:12:36 offsite kernel: siisch1: Error while READ LOG EXT The output is in one giant txt file. But each section has the heading of the disk (for i in `jot 10 0`;do echo "==================== ada$i ==================" >> d.rep; smartctl -x /dev/ada$i >>d.rep;smartctl -l gplog,0x10 /dev/ada$i >> d.rep;done;) http://www.tancsa.com/ahci.txt ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 16:22:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64E0106566B; Thu, 9 Feb 2012 16:22:46 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB348FC0C; Thu, 9 Feb 2012 16:22:42 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2000396wgb.31 for ; Thu, 09 Feb 2012 08:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VbuyqKBR5JT7vHT6ODyffIv/vGPCKGtGarQPqucEPf0=; b=m0DMZenSKHSFUBG6epBt/iigaYRiqWwyVqkA0NYVs03ZyWbL9bwVs5zTGUoq6XDxCR uF86YeQXto3yEthjc/pfZe+kKGWStCBd41tApGwsTx6np1xxsnc9wWmJhgrlt7NYGMpG tgvw6y09EfXf/f2DkaT/2qKpjeSlsbD+Xq2Oo= MIME-Version: 1.0 Received: by 10.216.133.91 with SMTP id p69mr915566wei.30.1328802784182; Thu, 09 Feb 2012 07:53:04 -0800 (PST) Sender: tomelite82@gmail.com Received: by 10.223.95.204 with HTTP; Thu, 9 Feb 2012 07:53:04 -0800 (PST) In-Reply-To: References: <2740DA0E7C0F495BA00E6D4BC0FE8F37@multiplay.co.uk> <040F9FF759DA441392432EDBD5C4D2CF@multiplay.co.uk> <4EB29A84.6070104@FreeBSD.org> Date: Thu, 9 Feb 2012 07:53:04 -0800 X-Google-Sender-Auth: yMQQyFfNAgrNMiB2UtMLGFjvsJM Message-ID: From: Qing Li To: Vlad Galu , Qing Li Content-Type: text/plain; charset=ISO-8859-1 Cc: Steven Hartland , "liv3d@multiplay.co.uk" , "Alexander V. Chernikov" , "freebsd-stable@FreeBSD.org" Subject: Re: serious packet routing issue causing ntpd high load? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 16:22:46 -0000 Hi Vlad, Sorry about the delayed response. No, this one just fell through the cracks. Has anyone responded ? Does it still exist in 9.x ? --Qing On Mon, Feb 6, 2012 at 10:16 AM, Vlad Galu wrote: > Hi Qing, > > Any luck with this? > > Thanks > Vlad > > > On Thu, Nov 3, 2011 at 2:05 PM, Li, Qing wrote: >> >> This endless route lookup miss message problem is reproducible without >> FLOWTABLE. The problem is with the multiple FIBs. I cannot reproduce >> this problem in my home network but the problem is easily seen at work. >> >> The route lookup miss itself in multi-FIBs configuration may be normal >> depending on the actual system configuration. It's the flooding of >> RTM_MISS messages that is abnormal. For example, if the route to the >> DNS servers is not configured in all FIBs, then the RTM_MISS >> message will be generated when an userland application sends to an >> explicit IP address in a specific FIB. >> >> In any case, I can reproduce the issue consistently and just trying to get >> a few uninterrupted >> hours to get it done. >> >> --Qing >> From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 16:28:59 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE85106564A; Thu, 9 Feb 2012 16:28:59 +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 6465A8FC17; Thu, 9 Feb 2012 16:28:59 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvWrT-000IMb-6K; Thu, 09 Feb 2012 11:28:43 -0500 Date: Thu, 9 Feb 2012 11:28:43 -0500 From: Gary Palmer To: Jeremy Chadwick Message-ID: <20120209162843.GE10082@in-addr.com> References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120209152240.GA95470@icarus.home.lan> 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: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 16:28:59 -0000 On Thu, Feb 09, 2012 at 07:22:40AM -0800, Jeremy Chadwick wrote: > I have to assume that devices connected on a port multiplier show up on > a separate scbusX number. This is from your original mail: > > > # camcontrol devlist > > at scbus0 target 0 lun 0 (pass0,ada0) > > at scbus0 target 1 lun 0 (pass1,ada1) > > at scbus0 target 2 lun 0 (pass2,ada2) > > at scbus0 target 3 lun 0 (pass3,ada3) > > at scbus0 target 15 lun 0 (pass4,pmp1) > > at scbus1 target 0 lun 0 (pass5,ada4) > > at scbus1 target 1 lun 0 (pass6,ada5) > > at scbus1 target 2 lun 0 (pass7,ada6) > > at scbus1 target 3 lun 0 (pass8,ada7) > > at scbus1 target 4 lun 0 (pass9,ada8) > > at scbus1 target 15 lun 0 (pass10,pmp0) > > at scbus4 target 0 lun 0 (pass11,da0) > > at scbus4 target 0 lun 1 (pass12,da1) > > at scbus4 target 16 lun 0 (pass13) > > at scbus5 target 0 lun 0 (pass14,da2) > > at scbus6 target 0 lun 0 (pass15,ada9) > > at scbus7 target 0 lun 0 (pass16,ada10) > > at scbus8 target 0 lun 0 (pass17,ada11) > > at scbus11 target 0 lun 0 (pass18,ada12) > > Based on this, and assuming my understanding of how this setup works -- > and please note I could be wrong, these port multiplier things I have no > familiarity with personally -- but it looks (to me) like this: > > scbus5 > --> Not sure what this thing is > --> Disk or "thing" da2 3ware 9650SE controller (twa driver I beleive) Gary From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 16:34:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 408A3106564A for ; Thu, 9 Feb 2012 16:34:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF438FC14 for ; Thu, 9 Feb 2012 16:34:16 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta05.emeryville.ca.mail.comcast.net with comcast id XrqN1i0011u4NiLA5saGme; Thu, 09 Feb 2012 16:34:16 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id XsaF1i0081t3BNj8hsaFhc; Thu, 09 Feb 2012 16:34:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 73789102C1E; Thu, 9 Feb 2012 08:34:15 -0800 (PST) Date: Thu, 9 Feb 2012 08:34:15 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120209163415.GA96451@icarus.home.lan> References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F33F056.6070300@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 16:34:17 -0000 On Thu, Feb 09, 2012 at 11:12:06AM -0500, Mike Tancsa wrote: > {snipping} > > > So which Port Multiplier did you add? The one at scbus0 or scbus1? > > 1 > at scbus1 target 0 lun 0 (pass5,ada4) > at scbus1 target 1 lun 0 (pass6,ada5) > at scbus1 target 2 lun 0 (pass7,ada6) > at scbus1 target 3 lun 0 (pass8,ada7) > at scbus1 target 4 lun 0 (pass9,ada8) > at scbus1 target 15 lun 0 (pass10,pmp0) I'll provide analysis for all 5 of these disks below. > > A full dmesg (not just a snippet) would probably be helpful here. What > > you provided in your first post was too terse, especially given how many > > disks you have in this system. :-) > > > > I really see no problem with looking at all disks -- specifically disks > > ada0 through ada3, and ada4 through ada8 -- to determine which one may > > be having problems. You're welcome to run "smartctl -a" on each one and > > put them up on the web, preferably segregated by disk name (e.g. > > ada0.txt, ada1.txt, etc.) and I can review them all. > > Actually, I just had a look at another server at our DR site. Its > hardware has not changed in a bit, but I did bring the kernel uptodate. > Its now logging the odd 'READ LOG EXT' error as well. Its kernel is > from Jan 22. Prior to that kernel update, I had not seen these errors. > Something in the driver (ahci or cam layer?) that has changed perhaps ? > > Feb 4 11:12:36 offsite kernel: siisch1: Error while READ LOG EXT Perhaps, but mav@ would be the authority on that. > http://www.tancsa.com/ahci.txt So here are the results of analysis for disks ada4 through ada8: ada4 --> When the below errors happened are 100% unknown. Just noting that here. --> SMART attribute 199 shows 13 CRC errors. These would be caused by issues between the disk and the device its attached to (port multiplier I guess). Causes could be bad SATA cables, bad ports, dirty/dusty ports, or flaky PCB (on the disk itself). --> SATA PHY log/counters confirms above problem: ID Size Value Description 0x0001 2 13 Command failed due to ICRC error 0x0002 2 13 R_ERR response for data FIS 0x0003 2 13 R_ERR response for device-to-host data FIS --> Given this behaviour, possibly the ATA commands submit which experienced errors were NCQ-related. --> The NCQ command error log does have non-zero values in it. The format of the output is proprietary, sadly, and smartmontools does not know how to decode it. But, compare it to your other drives and you'll see there is non-zero data there. --> This is a likely candidate for the behaviour seen on this PM. ada5 --> When the below errors happened are 100% unknown. Just noting that here. --> SMART attribute 199 shows 11 CRC errors. These would be caused by issues between the disk and the device its attached to (port multiplier I guess). Causes could be bad SATA cables, bad ports, dirty/dusty ports, or flaky PCB (on the disk itself). --> SATA PHY log/counters confirms above problem: ID Size Value Description 0x0001 2 11 Command failed due to ICRC error 0x0002 2 11 R_ERR response for data FIS 0x0003 2 11 R_ERR response for device-to-host data FIS --> Given this behaviour, possibly the ATA commands submit which experienced errors were NCQ-related. --> The NCQ command error log does have non-zero values in it. The format of the output is proprietary, sadly, and smartmontools does not know how to decode it. But, compare it to your other drives and you'll see there is non-zero data there. --> This is a likely candidate for the behaviour seen on this PM. ada6 --> When the below errors happened are 100% unknown. Just noting that here. --> SMART attribute 199 shows 8 CRC errors. These would be caused by issues between the disk and the device its attached to (port multiplier I guess). Causes could be bad SATA cables, bad ports, dirty/dusty ports, or flaky PCB (on the disk itself). --> SATA PHY log/counters confirms above problem: ID Size Value Description 0x0001 2 8 Command failed due to ICRC error 0x0002 2 8 R_ERR response for data FIS 0x0003 2 8 R_ERR response for device-to-host data FIS --> Given this behaviour, possibly the ATA commands submit which experienced errors were NCQ-related. --> The NCQ command error log does have non-zero values in it. The format of the output is proprietary, sadly, and smartmontools does not know how to decode it. But, compare it to your other drives and you'll see there is non-zero data there. --> This is a likely candidate for the behaviour seen on this PM. ada7 --> When the below errors happened are 100% unknown. Just noting that here. --> SMART attribute 199 shows 13 CRC errors. These would be caused by issues between the disk and the device its attached to (port multiplier I guess). Causes could be bad SATA cables, bad ports, dirty/dusty ports, or flaky PCB (on the disk itself). --> SATA PHY log/counters confirms above problem: ID Size Value Description 0x0001 2 13 Command failed due to ICRC error 0x0002 2 13 R_ERR response for data FIS 0x0003 2 13 R_ERR response for device-to-host data FIS --> There are an additional two anomalies shown for this drive in the SATA PHY log as well: 0x0005 2 1 R_ERR response for non-data FIS 0x0006 2 1 R_ERR response for device-to-host non-data FIS --> Given this behaviour, possibly the ATA commands submit which experienced errors were NCQ-related. --> The NCQ command error log does have non-zero values in it. The format of the output is proprietary, sadly, and smartmontools does not know how to decode it. But, compare it to your other drives and you'll see there is non-zero data there. --> This is a likely candidate for the behaviour seen on this PM. ada8 --> Looks great, no issues. Now, here is an important fact: I can see all of these drives are brand new or at least unused until recently. Attribute 9 confirms that. So you have 5 drives, 4 of which are seeing CRC errors, but all were roughly put into use at the same time (188 to 234 power-on hours). So, for drives ada4 through ada7: You will probably need to "track these drives" on a regular basis. That is to say, set up some cronjob or similar that logs the above output to a file (appends data to it), specifically output from smartctl -A (not -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can track SMART attribute changes, but does not track GPLog changes. Make sure to put timestamps in your logs. The next time you see READ LOG EXT errors, you should review your logs and see if any of the counters I focused on above have increased. If so, you've found your likely candidate. CRC errors of this nature are considered "communication errors", which is what mav@ eluded to in his previous post. As for fixing the problem: I have no idea how you would go about this. Use of port multipliers involves additional cables, possibly of shoddy quality, or other components which may not be decent/reliable. CRC errors can also be caused by electrical interference, and I HAVE seen this be the root cause on a few systems, but those systems had SATA cables that had been accidentally cut on internals of the case, thus had bare copper exposed. I do not know if cable length could explain the CRC errors when a PM is in place. E.g. controller <--> cable <--> PM <--> cable <--> disk. I do not think that the limits of SATA cable lengths applies to the TOTAL length between controller and disk in the above topology, but I do not know. Someone more familiar with PMs would need to comment here. You could simply just have a bad break-out cable, or a bad PM. Overall, this is just one of the many reasons why I avoid PMs, as well as avoid eSATA (especially eSATA). CRC errors are one of the most difficult and annoying things to track down because there are so many possibilities for root causes, and many are "hardware-level" to the point where practically EE people need to be involved. Good luck. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 18:37:07 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A149A106564A; Thu, 9 Feb 2012 18:37:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 5EFC08FC13; Thu, 9 Feb 2012 18:37:07 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q19Ib4cw067513; Thu, 9 Feb 2012 13:37:04 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F34124F.9090808@sentex.net> Date: Thu, 09 Feb 2012 13:37:03 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> In-Reply-To: <20120209163415.GA96451@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 18:37:07 -0000 On 2/9/2012 11:34 AM, Jeremy Chadwick wrote: > > You will probably need to "track these drives" on a regular basis. That > is to say, set up some cronjob or similar that logs the above output to > a file (appends data to it), specifically output from smartctl -A (not > -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can > track SMART attribute changes, but does not track GPLog changes. Make > sure to put timestamps in your logs. Thanks very much for having a look, and the suggestions. It think this is the way to go to see which drive my have errors incrementing. Alexander, is there a better way you can suggest ? > > As for fixing the problem: I have no idea how you would go about this. > Use of port multipliers involves additional cables, possibly of shoddy > quality, or other components which may not be decent/reliable. Possibly. Cables are one of those things I am happy to "pay extra for better quality" but how does one assess quality of such parts. > > Overall, this is just one of the many reasons why I avoid PMs, as well > as avoid eSATA (especially eSATA). Yeah, at some point it doesnt really work with too many PMs, especially if you cant query the thing to find out where things are "bad". I think for the next version of this box I will use the newer generation 3ware SAS/SATA controller ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 21:47:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FC36106566C for ; Thu, 9 Feb 2012 21:47:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id CF1498FC08 for ; Thu, 9 Feb 2012 21:47:17 +0000 (UTC) Received: from julian-mac.elischer.org (64.1.209.194.ptr.us.xo.net [64.1.209.194]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q19Ll58T063461 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 9 Feb 2012 13:47:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F343F2D.4040307@freebsd.org> Date: Thu, 09 Feb 2012 13:48:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 21:47:18 -0000 does anyone know of problems with freebsd and this system? the kernel We tried to boot seems to stop somewhere in the ahci probing. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 9 21:56:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B52A1065670 for ; Thu, 9 Feb 2012 21:56:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 632438FC19 for ; Thu, 9 Feb 2012 21:56:02 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta10.emeryville.ca.mail.comcast.net with comcast id Xw5g1i0061zF43QAAxw2sW; Thu, 09 Feb 2012 21:56:02 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id Xxw11i0041t3BNj8kxw159; Thu, 09 Feb 2012 21:56:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0C007102C1E; Thu, 9 Feb 2012 13:56:01 -0800 (PST) Date: Thu, 9 Feb 2012 13:56:01 -0800 From: Jeremy Chadwick To: Julian Elischer Message-ID: <20120209215600.GA1793@icarus.home.lan> References: <4F343F2D.4040307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F343F2D.4040307@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Feb 2012 21:56:02 -0000 On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: > does anyone know of problems with freebsd and this system? > > the kernel We tried to boot seems to stop somewhere in the ahci probing. Few things: 1) Possible to get full console output (e.g. serial, etc.) from a verbose boot? 2) Can you also provide the exact release/tag/kernel/thing you're trying to install or upgrade to ("8.x" is a little vague; there are all sorts of changes that happen between tags). For example 8.1 is not going to behave the same necessarily as 8.2. 3) When you say "ahci probing", are you booting a standard installation CD/DVD/memstick of, say, 8.2? If so, those won't make use of the AHCI-to-CAM translation layer (and that AHCI code is also different than the native-ATA-AHCI code), so you might try, when booting the system, dropping to the loader prompt and issuing "load ahci.ko" before typing "boot". See if that helps. If it does, great, use it (ahci_load="yes" in /boot/loader.conf) permanently (and benefit from things like NCQ too). 4) If it's an Intel ESB2 controller, I believe there were some fixes or identification shims put in place for this in recent RELENG_8, which wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be remembering the wrong controller though. Hmm... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 00:48:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A1A106566B; Fri, 10 Feb 2012 00:48:29 +0000 (UTC) (envelope-from prvs=1387bf0264=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 4C8128FC16; Fri, 10 Feb 2012 00:48:27 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 10 Feb 2012 00:37:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 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 md50017980343.msg; Fri, 10 Feb 2012 00:37:30 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1387bf0264=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Qing Li" , "Vlad Galu" References: <2740DA0E7C0F495BA00E6D4BC0FE8F37@multiplay.co.uk><040F9FF759DA441392432EDBD5C4D2CF@multiplay.co.uk><4EB29A84.6070104@FreeBSD.org> Date: Fri, 10 Feb 2012 00:36:40 -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-stable@FreeBSD.org" , liv3d@multiplay.co.uk, "Alexander V. Chernikov" Subject: Re: serious packet routing issue causing ntpd high load? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 00:48:29 -0000 ----- Original Message ----- From: "Qing Li" > Sorry about the delayed response. No, this one just fell through the cracks. > > Has anyone responded ? Does it still exist in 9.x ? We discovered yesterday that adding the following routes, which are present in: /etc/rc.d/network_ipv6, but not active unless ipv6_enable="YES" is set fixed the issue:- route add -inet6 ::ffff:0.0.0.0 -prefixlen 96 ::1 -reject route add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject I haven't confirmed but this is reported to be set by default on 9.x due to the changes in rc.d scripts. 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 Feb 10 06:24:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2312F106564A for ; Fri, 10 Feb 2012 06:24:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0911A8FC13 for ; Fri, 10 Feb 2012 06:24:12 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta10.emeryville.ca.mail.comcast.net with comcast id Y6Pl1i0020b6N64AA6QC7k; Fri, 10 Feb 2012 06:24:12 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id Y6QB1i00s1t3BNj8P6QC1L; Fri, 10 Feb 2012 06:24:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A8566102C1E; Thu, 9 Feb 2012 22:24:11 -0800 (PST) Date: Thu, 9 Feb 2012 22:24:11 -0800 From: Jeremy Chadwick To: Julian Elischer Message-ID: <20120210062411.GA9664@icarus.home.lan> References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F345E84.8080307@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 06:24:13 -0000 On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: > On 2/9/12 1:56 PM, Jeremy Chadwick wrote: > >On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: > >>does anyone know of problems with freebsd and this system? > >> > >>the kernel We tried to boot seems to stop somewhere in the ahci probing. > >Few things: > > > >1) Possible to get full console output (e.g. serial, etc.) from a verbose > >boot? > > it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems > at the > moment.. but I wasnhoping someone could save us some time by saying > "Oh yeah, merge in change number xxxxxx" > > >2) Can you also provide the exact release/tag/kernel/thing you're trying > >to install or upgrade to ("8.x" is a little vague; there are all sorts > >of changes that happen between tags). For example 8.1 is not going to > >behave the same necessarily as 8.2. > > > >3) When you say "ahci probing", are you booting a standard installation > >CD/DVD/memstick of, say, 8.2? If so, those won't make use of the > >AHCI-to-CAM translation layer (and that AHCI code is also different than > >the native-ATA-AHCI code), so you might try, when booting the system, > >dropping to the loader prompt and issuing "load ahci.ko" before typing > >"boot". See if that helps. If it does, great, use it (ahci_load="yes" > >in /boot/loader.conf) permanently (and benefit from things like NCQ > >too). > let me forward you an image... > >4) If it's an Intel ESB2 controller, I believe there were some fixes or > >identification shims put in place for this in recent RELENG_8, which > >wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be > >remembering the wrong controller though. Hmm... > > > > that may be what we are looking for. > > I'll try get more info. For others: the last few lines in the kernel log are: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi: wakeup code va 0xffffff848311d000 pa 0x4000 ahc_isa_probe 0: ioport 0xc00 alloc failed I don't see any indication of AHCI problems here (or AHCI at all). ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. A verbose boot might be more helpful. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 11:40:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8308D106566C for ; Fri, 10 Feb 2012 11:40:37 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA448FC21 for ; Fri, 10 Feb 2012 11:40:36 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2803004wgb.31 for ; Fri, 10 Feb 2012 03:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ybGK/cl6hNK6PrrjXyo1n5mT81LutEWUqMuHkgInkvU=; b=TYoXgNJLbZLKUT6xK8EOQcnkzPC99NITrpDO9LEjwlhyBDbhVR6v6ePNUEABkKC4Rh /PGXzCIjybuEULfqFRwMv02bT639Xi8aoJ7Npqr2zDWTuUgVVt3z1AZ89pE+4qan28F9 wYKo6+S4yTQUlz1gi4Wl9tzSaSBpvRGOJ+XSE= MIME-Version: 1.0 Received: by 10.180.83.97 with SMTP id p1mr8517637wiy.19.1328872230639; Fri, 10 Feb 2012 03:10:30 -0800 (PST) Received: by 10.216.21.85 with HTTP; Fri, 10 Feb 2012 03:10:30 -0800 (PST) Received: by 10.216.21.85 with HTTP; Fri, 10 Feb 2012 03:10:30 -0800 (PST) In-Reply-To: <4F34124F.9090808@sentex.net> References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> Date: Fri, 10 Feb 2012 03:10:30 -0800 Message-ID: From: "Jack L." To: Mike Tancsa Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 11:40:37 -0000 the drive has reallocated some sectors and normally drives should never reallocate sectors unless it has trouble reading/writing to them. also, that drive has known firmware problems so it sounds like the drive needs replacing On Feb 9, 2012 10:38 AM, "Mike Tancsa" wrote: > On 2/9/2012 11:34 AM, Jeremy Chadwick wrote: > > > > You will probably need to "track these drives" on a regular basis. That > > is to say, set up some cronjob or similar that logs the above output to > > a file (appends data to it), specifically output from smartctl -A (not > > -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can > > track SMART attribute changes, but does not track GPLog changes. Make > > sure to put timestamps in your logs. > > Thanks very much for having a look, and the suggestions. It think this > is the way to go to see which drive my have errors incrementing. > Alexander, is there a better way you can suggest ? > > > > > As for fixing the problem: I have no idea how you would go about this. > > Use of port multipliers involves additional cables, possibly of shoddy > > quality, or other components which may not be decent/reliable. > > > Possibly. Cables are one of those things I am happy to "pay extra for > better quality" but how does one assess quality of such parts. > > > > > Overall, this is just one of the many reasons why I avoid PMs, as well > > as avoid eSATA (especially eSATA). > > Yeah, at some point it doesnt really work with too many PMs, especially > if you cant query the thing to find out where things are "bad". I think > for the next version of this box I will use the newer generation 3ware > SAS/SATA controller > > ---Mike > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.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 Fri Feb 10 13:49:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15255106566B for ; Fri, 10 Feb 2012 13:49:49 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF6058FC17 for ; Fri, 10 Feb 2012 13:49:48 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1RvqRT-00037o-DK for freebsd-stable@freebsd.org; Fri, 10 Feb 2012 17:23:11 +0400 Date: Fri, 10 Feb 2012 17:23:11 +0400 From: Slawa Olhovchenkov To: freebsd-stable@freebsd.org Message-ID: <20120210132311.GA97848@zxy.spb.ru> References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> <20120210062411.GA9664@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120210062411.GA9664@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 13:49:49 -0000 On Thu, Feb 09, 2012 at 10:24:11PM -0800, Jeremy Chadwick wrote: > On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: > > On 2/9/12 1:56 PM, Jeremy Chadwick wrote: > > >On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: > > >>does anyone know of problems with freebsd and this system? > > >> > > >>the kernel We tried to boot seems to stop somewhere in the ahci probing. > > >Few things: > > > > > >1) Possible to get full console output (e.g. serial, etc.) from a verbose > > >boot? > > > > it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems > > at the > > moment.. but I wasnhoping someone could save us some time by saying > > "Oh yeah, merge in change number xxxxxx" > > > > >2) Can you also provide the exact release/tag/kernel/thing you're trying > > >to install or upgrade to ("8.x" is a little vague; there are all sorts > > >of changes that happen between tags). For example 8.1 is not going to > > >behave the same necessarily as 8.2. > > > > > >3) When you say "ahci probing", are you booting a standard installation > > >CD/DVD/memstick of, say, 8.2? If so, those won't make use of the > > >AHCI-to-CAM translation layer (and that AHCI code is also different than > > >the native-ATA-AHCI code), so you might try, when booting the system, > > >dropping to the loader prompt and issuing "load ahci.ko" before typing > > >"boot". See if that helps. If it does, great, use it (ahci_load="yes" > > >in /boot/loader.conf) permanently (and benefit from things like NCQ > > >too). > > let me forward you an image... > > >4) If it's an Intel ESB2 controller, I believe there were some fixes or > > >identification shims put in place for this in recent RELENG_8, which > > >wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be > > >remembering the wrong controller though. Hmm... > > > > > > > that may be what we are looking for. > > > > I'll try get more info. > > For others: the last few lines in the kernel log are: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi: wakeup code va 0xffffff848311d000 pa 0x4000 > ahc_isa_probe 0: ioport 0xc00 alloc failed > > I don't see any indication of AHCI problems here (or AHCI at all). > ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. > > A verbose boot might be more helpful. Can you tru hint.ahc.0.disabled="1" ? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 14:11:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7CC6106566B for ; Fri, 10 Feb 2012 14:11:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7518FC15 for ; Fri, 10 Feb 2012 14:11:27 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC41EEA.dip.t-dialin.net [79.196.30.234]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DD3E5844722 for ; Fri, 10 Feb 2012 14:56:09 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 245CB2C66 for ; Fri, 10 Feb 2012 14:56:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1328882167; bh=c4vGkchq0+2FK1PizHEAyTdp4GxIMaVpEEnvyP+jrPs=; h=Date:Message-ID:From:To:Subject:Content-Type:MIME-Version; b=Lyd5SgrzDetXVYIbwC9S6uO7Wq6eHAoRFLs7BINIy72VYoRE3OArg4IzlQghOgBpM HBq/hAi9OGb3s4hCqaVvCNXR+QNRi6bwi9PfE+srZxBeZqHQd6EFww/y1y3IpTwv1E dG2xL0Umm6T/9xpCHyLxIO16NWNCaxB+Y3YQK7Ub2cD9s+h7AfSfcceYdT+PjXPl6Y TtldAKxIQRdJ+cP7NTIjlO7XbVCTelgPNSWHqjsfk/hpyRjRWZxomgG6+S65OUltz6 waCBzpgKLe6K2z8tVAKghF7TTXZicNt3Pcc/UBk45D4VlpCMw9t3A5lUft8nlQDLx6 RgQrYoAMvLrpg== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1ADu62B098720 for stable@FreeBSD.org; Fri, 10 Feb 2012 14:56:06 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 10 Feb 2012 14:56:06 +0100 Date: Fri, 10 Feb 2012 14:56:04 +0100 Message-ID: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> From: Alexander Leidinger To: stable@FreeBSD.org User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DD3E5844722.A2FF5 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.72, required 6, autolearn=disabled, AWL -0.61, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329486970.59465@OUn0/xCazLTUuudUVvjD3Q X-EBL-Spam-Status: No Cc: Subject: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 14:11:28 -0000 Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Bye, Alexander. -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 14:19:52 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D361065672 for ; Fri, 10 Feb 2012 14:19:52 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id B7F4D8FC08 for ; Fri, 10 Feb 2012 14:19:51 +0000 (UTC) Received: (qmail 56388 invoked by uid 0); 10 Feb 2012 09:19:50 -0500 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 10 Feb 2012 09:19:50 -0500 Date: Fri, 10 Feb 2012 09:19:45 -0500 From: Glen Barber To: Alexander Leidinger Message-ID: <20120210141945.GA1848@glenbarber.us> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 14:19:52 -0000 On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? > For me, the two big ones are IPSEC (which, as I understand it, we cannot ship with GENERIC due to export laws), and KDB_UNATTENDED. The latter may be a sysctl tunable, I never bothered to look. Regards, Glen From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 14:36:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC741065760 for ; Fri, 10 Feb 2012 14:36:08 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (dev.null.cz [IPv6:2a01:430:34:0:2:0:dead:babe]) by mx1.freebsd.org (Postfix) with ESMTP id 44E618FC13 for ; Fri, 10 Feb 2012 14:36:08 +0000 (UTC) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.14.4/8.14.4) with ESMTP id q1AEa10Q019892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Feb 2012 15:36:06 +0100 (CET) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.14.4/8.14.4/Submit) id q1AEa1wc019891 for freebsd-stable@freebsd.org; Fri, 10 Feb 2012 15:36:01 +0100 (CET) (envelope-from buki) Date: Fri, 10 Feb 2012 15:36:01 +0100 From: "Marek 'Buki' =?utf-8?Q?Kozlovsk=C3=BD?=" To: freebsd-stable@freebsd.org Message-ID: <20120210143601.GB42565@dev.null.cz> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQAi4ZBraoACHIeu" Content-Disposition: inline In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 14:36:08 -0000 --rQAi4ZBraoACHIeu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > Hi, >=20 > during some big discussions in the last monts on various lists, one > of the problems was that some people would like to use > freebsd-update but can't as they are using a custom kernel. With all > the kernel modules we provide, the need for a custom kernel should > be small, but on the other hand, we do not provide a small > kernel-skeleton where you can load just the modules you need. >=20 > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that > the module is build like with the current generic kernel). I also > removed some storage drivers which are not available as a module. > The rationale is, that I can not remove CAM from the kernel config > if I let those drivers inside (if those drivers are important > enough, someone will probably fix the problem and add the missing > pieces to generate a module). >=20 > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). >=20 > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you? I need (not on every machine, granted) IPSEC and MROUTING > Bye, > Alexander. >=20 > --=20 > Cheit's Lament: > If you help a friend in need, he is sure to remember you-- > the next time he's in need. >=20 > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 Buki --rQAi4ZBraoACHIeu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk81K1EACgkQPzhIkpLLm09yJwCgyi5xAYIer0TAijygi2B1D4fC ss4AnA09mFyrmCBKV+hj2lmjnHqrky3k =07eo -----END PGP SIGNATURE----- --rQAi4ZBraoACHIeu-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 14:52:32 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D57441065672 for ; Fri, 10 Feb 2012 14:52:32 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 6454B8FC0A for ; Fri, 10 Feb 2012 14:52:32 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 331E910D; Fri, 10 Feb 2012 15:52:31 +0100 (CET) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 92282BD46; Fri, 10 Feb 2012 15:52:30 +0100 (CET) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 65D4EBEA9; Fri, 10 Feb 2012 15:52:30 +0100 (CET) Date: Fri, 10 Feb 2012 15:52:30 +0100 From: Kristof Provost To: Alexander Leidinger Message-ID: <20120210145230.GC10865@thebe.jupiter.sigsegv.be> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 14:52:32 -0000 On 2012-02-10 14:56:04 (+0100), Alexander Leidinger wrote: > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you? > VIMAGE and IPSEC I currently "require" both of them. The VIMAGE is sort of optional. I could run everything unjailed, but I prefer this. IPSEC is required, unless I add a separate device. That's for a little home gateway (HP Microserver thingy), doing file serving (NFS/ZFS), mail, web, backup, ... Regards, Kristof From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:05:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91998106566B for ; Fri, 10 Feb 2012 15:05:08 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12A098FC16 for ; Fri, 10 Feb 2012 15:05:07 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so2473081bkc.13 for ; Fri, 10 Feb 2012 07:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Ogx8lOf7KIAt5eUy2kSnFXZl3o3QFw6oYFzRVT4r7Q=; b=L0HAEIRic96b5tetcIRi7hIoK1RM0wefNyuQavlIqlWx9SxWUCsK7ai+345MNed9mO Rr8/F4wh5bKRid5dnlcw6brHqohnQu6Ex7NQLIHh0OTb6wJIcY7EY0MKBC7m+zjUvCDE 4KW0L8sZOOslX/5UFoPujDpsY3uUYbBRLEz+U= MIME-Version: 1.0 Received: by 10.204.129.198 with SMTP id p6mr2606628bks.96.1328886306824; Fri, 10 Feb 2012 07:05:06 -0800 (PST) Received: by 10.204.187.17 with HTTP; Fri, 10 Feb 2012 07:05:06 -0800 (PST) In-Reply-To: <20120210143601.GB42565@dev.null.cz> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210143601.GB42565@dev.null.cz> Date: Fri, 10 Feb 2012 16:05:06 +0100 Message-ID: From: Andreas Nilsson To: =?ISO-8859-1?Q?Marek_=27Buki=27_Kozlovsk=FD?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 15:05:08 -0000 2012/2/10 Marek 'Buki' Kozlovsk=FD > On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > > Hi, > > > > during some big discussions in the last monts on various lists, one > > of the problems was that some people would like to use > > freebsd-update but can't as they are using a custom kernel. With all > > the kernel modules we provide, the need for a custom kernel should > > be small, but on the other hand, we do not provide a small > > kernel-skeleton where you can load just the modules you need. > > > > This should be easy to change. As a first step I took the generic > > kernel and removed all devices which are available as modules, e.g. > > the USB section consists now only of the USB_DEBUG option (so that > > the module is build like with the current generic kernel). I also > > removed some storage drivers which are not available as a module. > > The rationale is, that I can not remove CAM from the kernel config > > if I let those drivers inside (if those drivers are important > > enough, someone will probably fix the problem and add the missing > > pieces to generate a module). > > > > Such a kernel would cover situations where people compile their own > > kernel because they want to get rid of some unused kernel code (and > > maybe even need the memory this frees up). > > > > The question is, is this enough? Or asked differently, why are you > > compiling a custom kernel in a production environment (so I rule out > > debug options zhich are not enabled in GENERIC)? Are there options > > which you add which you can not add as a module (SW_WATCHDOG comes > > to my mind)? If yes, which ones and how important are they for you? > > I need (not on every machine, granted) IPSEC and MROUTING > > > Bye, > > Alexander. > > > > -- > > Cheit's Lament: > > If you help a friend in need, he is sure to remember you-- > > the next time he's in need. > > > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063= FE7 > > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077= 137 > > Buki > IPFIREWALL_DEFAULT_TO_ACCEPT, DEVICE_POLLING and HZ=3D1000. /Andreas From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:14:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC724106564A for ; Fri, 10 Feb 2012 15:14:05 +0000 (UTC) (envelope-from endzed@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 656688FC1A for ; Fri, 10 Feb 2012 15:14:05 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3083797wib.13 for ; Fri, 10 Feb 2012 07:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=6tctIqwSYfJv+UCFqHY01D19SXKDErlB6P22EG0tPBE=; b=xzLBI41vkljsKBssGkp1M1XQcTNSrr8Ni56HVVw3vErxijZbRSnbxOkHfA/NRzwCEY J/LD1++z94IZZuI+IVDtYhkCxjxOlwbZFkduINZV4cHh+8Yz3WBWNlR74DDWYU+hJoPi JfmJYcwQoIY1w1Sg7s1E2uLX9nvb2ijCsa80E= Received: by 10.181.12.106 with SMTP id ep10mr3608847wid.8.1328884996037; Fri, 10 Feb 2012 06:43:16 -0800 (PST) Received: from [10.0.1.2] (178-211-252-211.dhcp.sevj.net. [178.211.252.211]) by mx.google.com with ESMTPS id eq5sm18592318wib.2.2012.02.10.06.43.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 06:43:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: endzed@gmail.com In-Reply-To: <20120210143601.GB42565@dev.null.cz> Date: Fri, 10 Feb 2012 15:43:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210143601.GB42565@dev.null.cz> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1257) Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 15:14:05 -0000 Le 10 f=E9vr. 2012 =E0 15:36, Marek 'Buki' Kozlovsk=FD a =E9crit : > On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: >>=20 >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options zhich are not enabled in GENERIC)? Are there options >> which you add which you can not add as a module (SW_WATCHDOG comes >> to my mind)? If yes, which ones and how important are they for you? >=20 quota support for me, but I heard that they will be soon added in = GENERIC maybe it is done for latest versions btw ?=20 All my boxes sticking to 7.x and 8.x box for the moment thus I didn't = checked already. Regards= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:18:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB71106566B; Fri, 10 Feb 2012 15:18:17 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id EB4DC8FC12; Fri, 10 Feb 2012 15:18:16 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id q1AEio77002852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2012 15:44:55 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id q1AEioC5002851; Fri, 10 Feb 2012 15:44:50 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Fri, 10 Feb 2012 15:44:50 +0100 From: Paul Schenkeveld To: freebsd-stable@freebsd.org, stable@freebsd.org Message-ID: <20120210144449.GA2358@psconsult.nl> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 15:18:17 -0000 On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules > we provide, the need for a custom kernel should be small, but on the > other hand, we do not provide a small kernel-skeleton where you can > load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that the > module is build like with the current generic kernel). I also removed > some storage drivers which are not available as a module. The > rationale is, that I can not remove CAM from the kernel config if I > let those drivers inside (if those drivers are important enough, > someone will probably fix the problem and add the missing pieces to > generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? - INET without INET6 - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) - Björn may add INET6 without INET - SCHED_ULE vs. SCHED_4BSD - No vga console/atkbd/psm for embedded devices - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls - probably more I also always specify exactly one CPU type (on i386), know it made a difference in the 386/486/586 era but am not sure how much difference it makes nowadays. HTH Paul Schenkeveld From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:18:17 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB71106566B; Fri, 10 Feb 2012 15:18:17 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id EB4DC8FC12; Fri, 10 Feb 2012 15:18:16 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id q1AEio77002852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2012 15:44:55 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id q1AEioC5002851; Fri, 10 Feb 2012 15:44:50 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Fri, 10 Feb 2012 15:44:50 +0100 From: Paul Schenkeveld To: freebsd-stable@freebsd.org, stable@freebsd.org Message-ID: <20120210144449.GA2358@psconsult.nl> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 15:18:17 -0000 On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules > we provide, the need for a custom kernel should be small, but on the > other hand, we do not provide a small kernel-skeleton where you can > load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that the > module is build like with the current generic kernel). I also removed > some storage drivers which are not available as a module. The > rationale is, that I can not remove CAM from the kernel config if I > let those drivers inside (if those drivers are important enough, > someone will probably fix the problem and add the missing pieces to > generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? - INET without INET6 - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) - Björn may add INET6 without INET - SCHED_ULE vs. SCHED_4BSD - No vga console/atkbd/psm for embedded devices - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls - probably more I also always specify exactly one CPU type (on i386), know it made a difference in the 386/486/586 era but am not sure how much difference it makes nowadays. HTH Paul Schenkeveld From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:56:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A56A6106566B for ; Fri, 10 Feb 2012 15:56:58 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by mx1.freebsd.org (Postfix) with ESMTP id 208228FC17 for ; Fri, 10 Feb 2012 15:56:57 +0000 (UTC) Received: from [147.102.224.69] (ovpn-69.noc.ntua.gr [147.102.224.69]) (authenticated bits=0) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id q1AFutQ4009248 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 10 Feb 2012 17:56:55 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Message-ID: <4F353E4A.6030903@noc.ntua.gr> Date: Fri, 10 Feb 2012 17:56:58 +0200 From: Panagiotis Christias Organization: NTUA NOC User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Alexander Leidinger References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [147.102.222.230]); Fri, 10 Feb 2012 17:56:55 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.3 at ulysses.noc.ntua.gr X-Virus-Status: Clean Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 15:56:58 -0000 On 10/2/2012 15:56, Alexander Leidinger wrote: > Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules we > provide, the need for a custom kernel should be small, but on the other > hand, we do not provide a small kernel-skeleton where you can load just > the modules you need. > > This should be easy to change. As a first step I took the generic kernel > and removed all devices which are available as modules, e.g. the USB > section consists now only of the USB_DEBUG option (so that the module is > build like with the current generic kernel). I also removed some storage > drivers which are not available as a module. The rationale is, that I > can not remove CAM from the kernel config if I let those drivers inside > (if those drivers are important enough, someone will probably fix the > problem and add the missing pieces to generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options which are not enabled in GENERIC)? Are there options which > you add which you can not add as a module (SW_WATCHDOG comes to my > mind)? If yes, which ones and how important are they for you? Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT IPFIREWALL_FORWARD ROUTETABLES=n Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc Finally, once we upgrade our jail setup VIMAGE will be also a must. Regards, Panagiotis -- Panagiotis J. Christias Network Management Center p.christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 16:01:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12C6106566B for ; Fri, 10 Feb 2012 16:01:45 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD0A8FC13 for ; Fri, 10 Feb 2012 16:01:41 +0000 (UTC) Received: by eaan10 with SMTP id n10so1129061eaa.13 for ; Fri, 10 Feb 2012 08:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8fVAuF04gKxjF8RfYLoz6Q+Hnr2KG+/EmZISbW4gQEY=; b=odTXHBgGqw5KO+V5DmKY3DVBOpSl6SRoJFuNdseeFbEKT0B7lqgFdGnp9uHRSUIht9 Ddfk3Phmwsy5K0Oi95/ZHhD3385p5ppNUlgbhZIiMsiwsQkZK2lOOo+84M1w8M9Rp5A/ bv9WeqK3c98ZwdZoK3iCowXB1u3JrjOQrOwVc= Received: by 10.14.47.68 with SMTP id s44mr2158330eeb.11.1328887967705; Fri, 10 Feb 2012 07:32:47 -0800 (PST) Received: from green.tandem.local (97-217-132-95.pool.ukrtel.net. [95.132.217.97]) by mx.google.com with ESMTPS id e12sm23262366eea.5.2012.02.10.07.32.45 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 07:32:46 -0800 (PST) Message-ID: <4F35389C.5080007@gmail.com> Date: Fri, 10 Feb 2012 17:32:44 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120208 Firefox/10.0 SeaMonkey/2.7 MIME-Version: 1.0 To: Alexander Leidinger References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 16:01:45 -0000 Alexander Leidinger wrote: > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules we > provide, the need for a custom kernel should be small, but on the other > hand, we do not provide a small kernel-skeleton where you can load just > the modules you need. > > This should be easy to change. As a first step I took the generic kernel > and removed all devices which are available as modules, e.g. the USB > section consists now only of the USB_DEBUG option (so that the module is > build like with the current generic kernel). I also removed some storage > drivers which are not available as a module. The rationale is, that I > can not remove CAM from the kernel config if I let those drivers inside > (if those drivers are important enough, someone will probably fix the > problem and add the missing pieces to generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options which > you add which you can not add as a module (SW_WATCHDOG comes to my > mind)? If yes, which ones and how important are they for you? The list would be too long for me, that's a sample what I add to my MINIMAL after stripping GENERIC: option DEVICE_POLLING option BPF_JITTER option DIRECTIO option SC_ALT_MOUSE_IMAGE option SC_MOUSE_CHAR=0x3 option ZERO_COPY_SOCKETS option SW_WATCHDOG option ALTQ option ALTQ_CBQ option ALTQ_RED option ALTQ_RIO option ALTQ_HFSC option ALTQ_CDNR option ALTQ_PRIQ option ALTQ_NOPCC device atpic device mptable I even don't use them on most machines however I prefer to build all machines from one kernel config however even this is impossible because for example I can't select scheduler by modules. Some point can be superseded in future for example current work on ULE seems promising. For example, why there are no modules for atpic and mptable? I don't need them on most machines but I can't load them at boot time. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 16:06:22 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA792106566B for ; Fri, 10 Feb 2012 16:06:22 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 612D98FC0C for ; Fri, 10 Feb 2012 16:06:22 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 8D2421CC6F; Fri, 10 Feb 2012 12:48:36 -0300 (BRT) Received: from 187.115.182.229 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Fri, 10 Feb 2012 13:48:36 -0200 Message-ID: <83648209d86469fa1da8ab36ad067f08.squirrel@eternamente.info> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Date: Fri, 10 Feb 2012 13:48:36 -0200 From: "Nenhum_de_Nos" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 16:06:22 -0000 On Fri, February 10, 2012 11:56, Alexander Leidinger wrote: > Hi, > > during some big discussions in the last monts on various lists, one of > the problems was that some people would like to use freebsd-update but > can't as they are using a custom kernel. With all the kernel modules > we provide, the need for a custom kernel should be small, but on the > other hand, we do not provide a small kernel-skeleton where you can > load just the modules you need. > > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that the > module is build like with the current generic kernel). I also removed > some storage drivers which are not available as a module. The > rationale is, that I can not remove CAM from the kernel config if I > let those drivers inside (if those drivers are important enough, > someone will probably fix the problem and add the missing pieces to > generate a module). > > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? Its a great thing this Alexander, but for me mainly I need PF+ALTQ and soekris stuff (apart from things other said before). matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 16:12:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC14F106564A for ; Fri, 10 Feb 2012 16:12:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 5370E8FC12 for ; Fri, 10 Feb 2012 16:12:06 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 47C1B25D3AB3; Fri, 10 Feb 2012 16:12:05 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 290C4BDB10D; Fri, 10 Feb 2012 16:12:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id SzzFTdcWf56u; Fri, 10 Feb 2012 16:12:02 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A0AC9BDB10B; Fri, 10 Feb 2012 16:12:02 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F353E4A.6030903@noc.ntua.gr> Date: Fri, 10 Feb 2012 16:12:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <4F353E4A.6030903@noc.ntua.gr> To: Panagiotis Christias X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 16:12:07 -0000 On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: > On 10/2/2012 15:56, Alexander Leidinger wrote: >> Hi, >>=20 >> during some big discussions in the last monts on various lists, one = of >> the problems was that some people would like to use freebsd-update = but >> can't as they are using a custom kernel. With all the kernel modules = we >> provide, the need for a custom kernel should be small, but on the = other >> hand, we do not provide a small kernel-skeleton where you can load = just >> the modules you need. >>=20 >> This should be easy to change. As a first step I took the generic = kernel >> and removed all devices which are available as modules, e.g. the USB >> section consists now only of the USB_DEBUG option (so that the module = is >> build like with the current generic kernel). I also removed some = storage >> drivers which are not available as a module. The rationale is, that I >> can not remove CAM from the kernel config if I let those drivers = inside >> (if those drivers are important enough, someone will probably fix the >> problem and add the missing pieces to generate a module). >>=20 >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >>=20 >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options which are not enabled in GENERIC)? Are there options = which >> you add which you can not add as a module (SW_WATCHDOG comes to my >> mind)? If yes, which ones and how important are they for you? >=20 > Hello, >=20 > we are currently using on every server (in order to maintain a single = custom kernel) the following options: >=20 > IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT loadable, tunable there for this > IPFIREWALL_FORWARD > ROUTETABLES=3Dn melifaro and I are working on this; he'll fix the netgraph netflow part = and I'll fix the #ifdefs and the tunable will be enough. > Soon, we will also add: >=20 > IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc IPSEC_FILTERTUNNEL has long been obsolete. > Finally, once we upgrade our jail setup VIMAGE will be also a must. I have read that multiple times already and I'd love to but that's a = looong way. The plan might be to one day provide a 2nd kernel to install from and = that freebsd-update can handle but we'll see. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 16:15:05 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F301065670 for ; Fri, 10 Feb 2012 16:15:04 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4568FC0A for ; Fri, 10 Feb 2012 16:15:04 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A10E025D3AB3; Fri, 10 Feb 2012 16:15:03 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B2DA4BDB10E; Fri, 10 Feb 2012 16:15:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 48lWKlpRl1Cw; Fri, 10 Feb 2012 16:15:01 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 34540BDB10D; Fri, 10 Feb 2012 16:15:01 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Date: Fri, 10 Feb 2012 16:15:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1084) Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 16:15:05 -0000 On 10. Feb 2012, at 13:56 , Alexander Leidinger wrote: > Hi, >=20 > during some big discussions in the last monts on various lists, one of = the problems was that some people would like to use freebsd-update but = can't as they are using a custom kernel. With all the kernel modules we = provide, the need for a custom kernel should be small, but on the other = hand, we do not provide a small kernel-skeleton where you can load just = the modules you need. >=20 > This should be easy to change. As a first step I took the generic = kernel and removed all devices which are available as modules, e.g. the = USB section consists now only of the USB_DEBUG option (so that the = module is build like with the current generic kernel). I also removed = some storage drivers which are not available as a module. The rationale = is, that I can not remove CAM from the kernel config if I let those = drivers inside (if those drivers are important enough, someone will = probably fix the problem and add the missing pieces to generate a = module). And you completely seem to have missed the discussion about a device ID = DB and loader being able to probe and load them for you? With that sound, firewire, but also NICs and storage drivers can mostly = go away... But it needs infrastructure... lots of ... feel free to = resume that thread but stable@ is obviously the wrong place. > Such a kernel would cover situations where people compile their own = kernel because they want to get rid of some unused kernel code (and = maybe even need the memory this frees up). >=20 > The question is, is this enough? Or asked differently, why are you = compiling a custom kernel in a production environment (so I rule out = debug options zhich are not enabled in GENERIC)? Are there options which = you add which you can not add as a module (SW_WATCHDOG comes to my = mind)? If yes, which ones and how important are they for you? As a lot of the results will show... various parts of the network stack = being loadable, which is not as easy as it sounds, especially making = them unloadable again currently ... /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 16:23:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 247F91065670 for ; Fri, 10 Feb 2012 16:23:07 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF6FE8FC17 for ; Fri, 10 Feb 2012 16:23:06 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so1766131pbc.13 for ; Fri, 10 Feb 2012 08:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qIcj0rpRDn78JpY3HJML2VtNdPee1jEkNgp5o/ZT/80=; b=fLt7jjrPPLr1Z8GAvLUeJI/WxHkdvXYKeih4BYf3KF91ye2LTcpTqIDfVeIPHiaF4a wNbaMriOwWD//ZoP3CrWcMhvXvnqFC5h0bCZLI/hHKkAT9F9SH8BENKIpc3+J9DTBygD e/wmBt7aNKjEe1TjH2DZKFGUcVJbuHZThhA+4= MIME-Version: 1.0 Received: by 10.68.242.39 with SMTP id wn7mr1823600pbc.89.1328890986528; Fri, 10 Feb 2012 08:23:06 -0800 (PST) Received: by 10.142.174.3 with HTTP; Fri, 10 Feb 2012 08:23:06 -0800 (PST) In-Reply-To: References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210143601.GB42565@dev.null.cz> Date: Fri, 10 Feb 2012 08:23:06 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 16:23:07 -0000 2012/2/10 Andreas Nilsson : > IPFIREWALL_DEFAULT_TO_ACCEPT, DEVICE_POLLING and HZ=1000. HZ can be set via /boot/loader.conf, and I think via sysctl as well. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 17:27:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EEEF1065672 for ; Fri, 10 Feb 2012 17:27:43 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 94D5B8FC08 for ; Fri, 10 Feb 2012 17:27:42 +0000 (UTC) Received: by lagz14 with SMTP id z14so3840162lag.13 for ; Fri, 10 Feb 2012 09:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.37 with SMTP id d5mr388530lbk.5.1328894861197; Fri, 10 Feb 2012 09:27:41 -0800 (PST) Received: by 10.112.83.227 with HTTP; Fri, 10 Feb 2012 09:27:41 -0800 (PST) X-Originating-IP: [209.66.78.50] In-Reply-To: <20120210132311.GA97848@zxy.spb.ru> References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> <20120210062411.GA9664@icarus.home.lan> <20120210132311.GA97848@zxy.spb.ru> Date: Fri, 10 Feb 2012 12:27:41 -0500 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnndHNYvFxOLNaAjWXVkqoZ1m8EanotGFOv7VB1wUWE4PODG6U50USQExOjjP17zpDbY41O Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 17:27:43 -0000 On Fri, Feb 10, 2012 at 8:23 AM, Slawa Olhovchenkov wrote: > On Thu, Feb 09, 2012 at 10:24:11PM -0800, Jeremy Chadwick wrote: > >> On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: >> > On 2/9/12 1:56 PM, Jeremy Chadwick wrote: >> > >On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: >> > >>does anyone know of problems with freebsd and this system? >> > >> >> > >>the kernel We tried to boot seems to stop somewhere in the ahci prob= ing. >> > >Few things: >> > > >> > >1) Possible to get full console output (e.g. serial, etc.) from a ver= bose >> > >boot? >> > >> > it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems >> > at the >> > moment.. but I wasnhoping someone could save us some time by saying >> > "Oh yeah, merge in change number xxxxxx" >> > >> > >2) Can you also provide the exact release/tag/kernel/thing you're try= ing >> > >to install or upgrade to ("8.x" is a little vague; there are all sort= s >> > >of changes that happen between tags). =C2=A0For example 8.1 is not go= ing to >> > >behave the same necessarily as 8.2. >> > > >> > >3) When you say "ahci probing", are you booting a standard installati= on >> > >CD/DVD/memstick of, say, 8.2? =C2=A0If so, those won't make use of th= e >> > >AHCI-to-CAM translation layer (and that AHCI code is also different t= han >> > >the native-ATA-AHCI code), so you might try, when booting the system, >> > >dropping to the loader prompt and issuing "load ahci.ko" before typin= g >> > >"boot". =C2=A0See if that helps. =C2=A0If it does, great, use it (ahc= i_load=3D"yes" >> > >in /boot/loader.conf) permanently (and benefit from things like NCQ >> > >too). >> > let me forward you an image... >> > >4) If it's an Intel ESB2 controller, I believe there were some fixes = or >> > >identification shims put in place for this in recent RELENG_8, which >> > >wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. =C2=A0I c= ould be >> > >remembering the wrong controller though. =C2=A0Hmm... >> > > >> > >> > that may be what we are looking for. >> > >> > I'll try get more info. >> >> For others: the last few lines in the kernel log are: >> >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route= 64-bit >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> acpi: wakeup code va 0xffffff848311d000 pa 0x4000 >> ahc_isa_probe 0: ioport 0xc00 alloc failed >> >> I don't see any indication of AHCI problems here (or AHCI at all). >> ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. >> >> A verbose boot might be more helpful. > > Can you tru hint.ahc.0.disabled=3D"1" ? > _______________________________________________ > 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" Is this a Dl165 G5 or a G5p . Also have you tried to change the sata settings in the bios from AHCI to RAID or compat ? I am currently using the G5 , G5p and G7 with 7.3 , 7.4 and 8.3 and , I have seen this issue once or twice but I could not remember what the fix was. I think playing with the bios options for AHCI and reseatting the cables and backplane resolved this for me the last time. --=20 mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 17:56:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D912106566B for ; Fri, 10 Feb 2012 17:56:45 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (unknown [IPv6:2001:b70:201:2::20]) by mx1.freebsd.org (Postfix) with ESMTP id BE86F8FC08 for ; Fri, 10 Feb 2012 17:56:44 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 27BD52284C for ; Fri, 10 Feb 2012 17:56:44 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id C513B106934C2 for ; Fri, 10 Feb 2012 17:56:21 +0000 (GMT) Message-ID: <4F355A5B.9080007@rewt.org.uk> Date: Fri, 10 Feb 2012 17:56:43 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 17:56:45 -0000 Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Few things: - On my installs at least, if there is an unknown ftp connection problem the installer will just bail and say it has been aborted - this consistently happens when ftp.de is selected - there is no method of stepping back through the install - If a dhcp lease request times out manual configuration isn't offered I realise that a lot of work has gone into it and it's nice and new, but really unless it's finished it shouldn't be the default. Thanks, J From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 18:23:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF3611065672 for ; Fri, 10 Feb 2012 18:23:36 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (unknown [IPv6:2001:b70:201:2::20]) by mx1.freebsd.org (Postfix) with ESMTP id 9D16A8FC14 for ; Fri, 10 Feb 2012 18:23:36 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 027CE2284C for ; Fri, 10 Feb 2012 18:23:36 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id C3D10106934C2 for ; Fri, 10 Feb 2012 18:23:13 +0000 (GMT) Message-ID: <4F3560A7.90505@rewt.org.uk> Date: Fri, 10 Feb 2012 18:23:35 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: FreeBSD Stable Mailing List References: <4F355A5B.9080007@rewt.org.uk> In-Reply-To: <4F355A5B.9080007@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 18:23:36 -0000 Joe Holden wrote: > Guys, > > This should really be reverted to sysinstall until the new installer is > at least in a state where it consistently works... the most important > part of a new users experience is the installer and the few new installs > I have done lately I've just installed 8.2 and upgraded from there as > the new installer is terribly buggy. > > Few things: > > - On my installs at least, if there is an unknown ftp connection problem > the installer will just bail and say it has been aborted - this > consistently happens when ftp.de is selected > > - there is no method of stepping back through the install > > - If a dhcp lease request times out manual configuration isn't offered Another one I've just encountered several times: For some reason the output for setting root password has new lines and lots of space between the various bits of text and isn't taking any input (see http://i.imgur.com/lTP5b.png) The lack of installation progress or emergency shell on another terminal is also something that I think should be considered - being able to see whats going on and getting error output from the commands the installer is running is invaluable. > > I realise that a lot of work has gone into it and it's nice and new, but > really unless it's finished it shouldn't be the default. > > Thanks, > J > _______________________________________________ > 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 Feb 10 19:47:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C155D106566C for ; Fri, 10 Feb 2012 19:47:14 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [IPv6:2a01:d0:81f8::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4FD8FC0A for ; Fri, 10 Feb 2012 19:47:14 +0000 (UTC) Received: from [2001:470:6f:26:226:b9ff:fedd:5cf1] by s1.sdv.com.ua with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvwR2-000JGU-92; Fri, 10 Feb 2012 21:47:10 +0200 Message-ID: <4F35743B.4020302@os2.kiev.ua> Date: Fri, 10 Feb 2012 20:47:07 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Joe Holden References: <4F355A5B.9080007@rewt.org.uk> In-Reply-To: <4F355A5B.9080007@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 Cc: FreeBSD Stable Mailing List Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 19:47:14 -0000 On 02/10/2012 06:56 PM, Joe Holden wrote: > Guys, > > This should really be reverted to sysinstall until the new installer > is at least in a state where it consistently works... the most > important part of a new users experience is the installer and the few > new installs I have done lately I've just installed 8.2 and upgraded > from there as the new installer is terribly buggy. > Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. P.S. i personally had no problems with a new installer, used it from DVD. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 19:55:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA851065670 for ; Fri, 10 Feb 2012 19:55:27 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (unknown [IPv6:2001:b70:201:2::20]) by mx1.freebsd.org (Postfix) with ESMTP id 143CD8FC1B for ; Fri, 10 Feb 2012 19:55:27 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 750F22284C for ; Fri, 10 Feb 2012 19:55:26 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id 35178106934C2; Fri, 10 Feb 2012 19:55:04 +0000 (GMT) Message-ID: <4F35762D.60908@rewt.org.uk> Date: Fri, 10 Feb 2012 19:55:25 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alex Samorukov References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> In-Reply-To: <4F35743B.4020302@os2.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 19:55:27 -0000 Alex Samorukov wrote: > On 02/10/2012 06:56 PM, Joe Holden wrote: >> Guys, >> >> This should really be reverted to sysinstall until the new installer >> is at least in a state where it consistently works... the most >> important part of a new users experience is the installer and the few >> new installs I have done lately I've just installed 8.2 and upgraded >> from there as the new installer is terribly buggy. >> > Hi, > > I am highly against reverting. Old installer is not GPT aware and in > fact is unmaintained for a very long time. > True, there is that. > About ftp - its probably needs to be handled better, but most of the > user i think using cd/dvd image, so it is not an issue. And new > installer is written on shell, so i think its better to fix broken parts > then to revert it to outdated and unmaintained code. > True also perhaps, could be more user friendly though especially for people just installing it - I have been using my own install scripts and such since 5 but am giving the new installer a go at the moment... > P.S. i personally had no problems with a new installer, used it from DVD. > _______________________________________________ > 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 Feb 10 20:02:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4005B106566B for ; Fri, 10 Feb 2012 20:02:19 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (unknown [IPv6:2001:b70:201:2::20]) by mx1.freebsd.org (Postfix) with ESMTP id EF4588FC12 for ; Fri, 10 Feb 2012 20:02:18 +0000 (UTC) Received: from jasmine.internethq (unknown [91.208.177.192]) by abby.lhr1.as41113.net (Postfix) with ESMTP id 50B7122853 for ; Fri, 10 Feb 2012 20:02:18 +0000 (UTC) Received: from [172.16.11.44] (jwh-laptop.internethq [172.16.11.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jasmine.internethq (Postfix) with ESMTPS id 32E36106934C2; Fri, 10 Feb 2012 20:01:56 +0000 (GMT) Message-ID: <4F3577C9.6050401@rewt.org.uk> Date: Fri, 10 Feb 2012 20:02:17 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alex Samorukov References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F35762D.60908@rewt.org.uk> In-Reply-To: <4F35762D.60908@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 20:02:19 -0000 Joe Holden wrote: > Alex Samorukov wrote: >> On 02/10/2012 06:56 PM, Joe Holden wrote: >>> Guys, >>> >>> This should really be reverted to sysinstall until the new installer >>> is at least in a state where it consistently works... the most >>> important part of a new users experience is the installer and the few >>> new installs I have done lately I've just installed 8.2 and upgraded >>> from there as the new installer is terribly buggy. >>> >> Hi, >> >> I am highly against reverting. Old installer is not GPT aware and in >> fact is unmaintained for a very long time. >> > True, there is that. > >> About ftp - its probably needs to be handled better, but most of the >> user i think using cd/dvd image, so it is not an issue. And new >> installer is written on shell, so i think its better to fix broken >> parts then to revert it to outdated and unmaintained code. >> > True also perhaps, could be more user friendly though especially for > people just installing it - I have been using my own install scripts and > such since 5 but am giving the new installer a go at the moment... > >> P.S. i personally had no problems with a new installer, used it from DVD. On a related note - does the new installer have any kind of config file for unattended installs a la sysinstall? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 20:37:08 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9817F106564A for ; Fri, 10 Feb 2012 20:37:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 287408FC08 for ; Fri, 10 Feb 2012 20:37:07 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3295356wgb.31 for ; Fri, 10 Feb 2012 12:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cSrTMf5jatntdyWdyfUN1xBCpPEZW/nFrLEWGfzZ1GY=; b=SzLRo0oLP8GfyxLpBmM+Tr1p4lDXQ8i2eVr2YX986E9vObetzF7GZL81CNczO7Lf/H c5J5fS4n8sLkeFblfe8szvMqXQWZTzSjoKIqQlQSp4tbmqSoOj/u8hcqWnZ3Z89EDQIO fq1sGxK/HTZyRnPGu6oSR8TjE1Tkb3GvcOn/Q= MIME-Version: 1.0 Received: by 10.180.95.105 with SMTP id dj9mr11318175wib.18.1328904833446; Fri, 10 Feb 2012 12:13:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Fri, 10 Feb 2012 12:13:53 -0800 (PST) In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Date: Fri, 10 Feb 2012 12:13:53 -0800 X-Google-Sender-Auth: 2wD4RZEFMI-ue2NeQRGtGbNu6k0 Message-ID: From: Adrian Chadd To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 20:37:08 -0000 I've done this a few times. The /boot/loader takes a _long_ time to suck in the 25 odd modules my eeepc requires to load a completely modular kernel. It takes a _very long_ time to suck these in over USB. It's a great idea and I think we should start down this path in the 10-CURRENT trajectory but those load times need to be tweaked if possible. Adrian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 21:35:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF08106566C; Fri, 10 Feb 2012 21:35:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD3F8FC14; Fri, 10 Feb 2012 21:35:56 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q1ALZrPk085564; Fri, 10 Feb 2012 16:35:54 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F358DB6.4030203@sentex.net> Date: Fri, 10 Feb 2012 16:35:50 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32E289.4080806@sentex.net> <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> In-Reply-To: <4F34124F.9090808@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 21:35:56 -0000 On 2/9/2012 1:37 PM, Mike Tancsa wrote: > On 2/9/2012 11:34 AM, Jeremy Chadwick wrote: >> >> You will probably need to "track these drives" on a regular basis. That >> is to say, set up some cronjob or similar that logs the above output to >> a file (appends data to it), specifically output from smartctl -A (not >> -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can >> track SMART attribute changes, but does not track GPLog changes. Make >> sure to put timestamps in your logs. > > Thanks very much for having a look, and the suggestions. It think this > is the way to go to see which drive my have errors incrementing. > Alexander, is there a better way you can suggest ? Got a few more of the READ LOG EXT errors and I did a snapshot of all the disks post error to compare with the snapshots from cron this AM. Unfortunately some of the deltas were on the one new port multiplier and some were on the motherboard sata. Feb 9 04:34:55 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:05:53 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:06:53 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:07:06 backup3 last message repeated 3 times Feb 10 16:18:24 backup3 last message repeated 16 times Feb 10 16:18:24 backup3 kernel: Feb 10 16:18:39 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:19:10 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:20:27 backup3 last message repeated 4 times Feb 10 16:20:27 backup3 kernel: Feb 10 16:20:30 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:21:33 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:23:23 backup3 last message repeated 8 times On ada4, -199 UDMA_CRC_Error_Count -O--CK 200 199 000 - 13 +199 UDMA_CRC_Error_Count -O--CK 200 199 000 - 32 SATA Phy Event Counters (GP Log 0x11) ID Size Value Description -0x0001 2 13 Command failed due to ICRC error -0x0002 2 13 R_ERR response for data FIS -0x0003 2 13 R_ERR response for device-to-host data FIS +0x0001 2 32 Command failed due to ICRC error +0x0002 2 32 R_ERR response for data FIS +0x0003 2 32 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS -0x0005 2 0 R_ERR response for non-data FIS -0x0006 2 0 R_ERR response for device-to-host non-data FIS +0x0005 2 1 R_ERR response for non-data FIS +0x0006 2 1 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x000a 2 0 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS -0x8000 4 744462 Vendor specific +0x8000 4 785195 Vendor specific General Purpose Log 0x10 [NCQ Command Error log], Page 0-0 (of 1) -0000000: 05 00 41 84 04 9a 53 40 00 00 00 00 00 00 00 00 |..A...S@........| +0000000: 06 00 41 84 f2 39 6d 40 2d 00 00 00 00 00 00 00 |..A..9m@-.......| -00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa |................| +00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 |...............%| ada5 -199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 11 +199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 22 -0x0001 2 11 Command failed due to ICRC error -0x0002 2 11 R_ERR response for data FIS -0x0003 2 11 R_ERR response for device-to-host data FIS +0x0001 2 22 Command failed due to ICRC error +0x0002 2 22 R_ERR response for data FIS +0x0003 2 22 R_ERR response for device-to-host data FIS ada6 -199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 8 +199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 25 SATA Phy Event Counters (GP Log 0x11) ID Size Value Description -0x0001 2 8 Command failed due to ICRC error -0x0002 2 8 R_ERR response for data FIS -0x0003 2 8 R_ERR response for device-to-host data FIS +0x0001 2 25 Command failed due to ICRC error +0x0002 2 25 R_ERR response for data FIS +0x0003 2 25 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x000a 2 0 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS -0x8000 4 744462 Vendor specific +0x8000 4 785195 Vendor specific ada7 -199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 13 +199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 30 SATA Phy Event Counters (GP Log 0x11) ID Size Value Description -0x0001 2 13 Command failed due to ICRC error -0x0002 2 13 R_ERR response for data FIS -0x0003 2 13 R_ERR response for device-to-host data FIS +0x0001 2 30 Command failed due to ICRC error +0x0002 2 31 R_ERR response for data FIS +0x0003 2 31 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 1 R_ERR response for non-data FIS 0x0006 2 1 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x000a 2 0 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS -0x8000 4 744460 Vendor specific +0x8000 4 785193 Vendor specific General Purpose Log 0x10 [NCQ Command Error log], Page 0-0 (of 1) -0000000: 19 00 41 84 74 3d 4a 40 29 00 00 00 00 00 00 00 |..A.t=J@).......| +0000000: 15 00 41 84 d7 03 1f 40 2d 00 00 00 00 00 00 00 |..A....@-.......| 0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| @@ -238,5 +244,5 @@ 00001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| -00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b3 |................| +00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b5 |................| ada9 ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE - 1 Raw_Read_Error_Rate POSR-- 115 099 006 - 91821743 + 1 Raw_Read_Error_Rate POSR-- 117 099 006 - 155365055 3 Spin_Up_Time PO---- 093 092 000 - 0 4 Start_Stop_Count -O--CK 100 100 020 - 68 5 Reallocated_Sector_Ct PO--CK 100 100 036 - 2 - 7 Seek_Error_Rate POSR-- 088 060 030 - 792342525 - 9 Power_On_Hours -O--CK 074 074 000 - 22792 + 7 Seek_Error_Rate POSR-- 088 060 030 - 792482445 + 9 Power_On_Hours -O--CK 074 074 000 - 22803 10 Spin_Retry_Count PO--C- 100 100 097 - 2 12 Power_Cycle_Count -O--CK 100 100 020 - 68 184 End-to-End_Error -O--CK 100 100 099 - 0 187 Reported_Uncorrect -O--CK 095 095 000 - 5 188 Command_Timeout -O--CK 100 100 000 - 0 189 High_Fly_Writes -O-RCK 001 001 000 - 961 -190 Airflow_Temperature_Cel -O---K 064 056 045 - 36 (Min/Max 33/37) -194 Temperature_Celsius -O---K 036 044 000 - 36 (0 25 0 0 0) -195 Hardware_ECC_Recovered -O-RC- 050 030 000 - 91821743 +190 Airflow_Temperature_Cel -O---K 066 056 045 - 34 (Min/Max 33/37) +194 Temperature_Celsius -O---K 034 044 000 - 34 (0 25 0 0 0) +195 Hardware_ECC_Recovered -O-RC- 050 030 000 - 155365055 197 Current_Pending_Sector -O--C- 100 100 000 - 0 198 Offline_Uncorrectable ----C- 100 100 000 - 0 199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0 ada10 SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE - 1 Raw_Read_Error_Rate POSR-- 118 099 006 - 196445860 + 1 Raw_Read_Error_Rate POSR-- 107 099 006 - 13128068 3 Spin_Up_Time PO---- 095 095 000 - 0 4 Start_Stop_Count -O--CK 100 100 020 - 216 5 Reallocated_Sector_Ct PO--CK 100 100 036 - 0 - 7 Seek_Error_Rate POSR-- 087 060 030 - 586360650 - 9 Power_On_Hours -O--CK 077 077 000 - 20319 + 7 Seek_Error_Rate POSR-- 087 060 030 - 586495516 + 9 Power_On_Hours -O--CK 077 077 000 - 20330 10 Spin_Retry_Count PO--C- 100 100 097 - 0 12 Power_Cycle_Count -O--CK 100 100 020 - 113 183 Runtime_Bad_Block -O--CK 100 100 000 - 0 @@ -69,15 +69,15 @@ 187 Reported_Uncorrect -O--CK 100 100 000 - 0 188 Command_Timeout -O--CK 100 100 000 - 0 189 High_Fly_Writes -O-RCK 099 099 000 - 1 -190 Airflow_Temperature_Cel -O---K 067 062 045 - 33 (Min/Max 31/34) -194 Temperature_Celsius -O---K 033 040 000 - 33 (0 22 0 0 0) -195 Hardware_ECC_Recovered -O-RC- 040 018 000 - 196445860 +190 Airflow_Temperature_Cel -O---K 068 062 045 - 32 (Min/Max 31/34) +194 Temperature_Celsius -O---K 032 040 000 - 32 (0 22 0 0 0) +195 Hardware_ECC_Recovered -O-RC- 028 018 000 - 13128068 197 Current_Pending_Sector -O--C- 100 100 000 - 0 198 Offline_Uncorrectable ----C- 100 100 000 - 0 199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0 -240 Head_Flying_Hours ------ 100 253 000 - 205935091929084 -241 Total_LBAs_Written ------ 100 253 000 - 1286405353 -242 Total_LBAs_Read ------ 100 253 000 - 708601879 +240 Head_Flying_Hours ------ 100 253 000 - 221530118180872 +241 Total_LBAs_Written ------ 100 253 000 - 3323838357 +242 Total_LBAs_Read ------ 100 253 000 - 1778396343 ada11 ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE - 1 Raw_Read_Error_Rate POSR-- 120 097 006 - 242285977 + 1 Raw_Read_Error_Rate POSR-- 113 097 006 - 58229866 3 Spin_Up_Time PO---- 092 091 000 - 0 4 Start_Stop_Count -O--CK 100 100 020 - 69 5 Reallocated_Sector_Ct PO--CK 100 100 036 - 0 - 7 Seek_Error_Rate POSR-- 073 060 030 - 133894632808 - 9 Power_On_Hours -O--CK 072 072 000 - 25283 + 7 Seek_Error_Rate POSR-- 073 060 030 - 133894764364 + 9 Power_On_Hours -O--CK 072 072 000 - 25294 10 Spin_Retry_Count PO--C- 100 100 097 - 3 12 Power_Cycle_Count -O--CK 100 100 020 - 82 184 End-to-End_Error -O--CK 100 100 099 - 0 187 Reported_Uncorrect -O--CK 100 100 000 - 0 188 Command_Timeout -O--CK 100 089 000 - 124555952157 189 High_Fly_Writes -O-RCK 080 080 000 - 20 -190 Airflow_Temperature_Cel -O---K 059 050 045 - 41 (Min/Max 38/42) -194 Temperature_Celsius -O---K 041 050 000 - 41 (0 22 0 0 0) -195 Hardware_ECC_Recovered -O-RC- 051 032 000 - 242285977 +190 Airflow_Temperature_Cel -O---K 061 050 045 - 39 (Min/Max 38/42) +194 Temperature_Celsius -O---K 039 050 000 - 39 (0 22 0 0 0) +195 Hardware_ECC_Recovered -O-RC- 050 032 000 - 58229866 197 Current_Pending_Sector -O--C- 100 100 000 - 0 198 Offline_Uncorrectable ----C- 100 100 000 - 0 199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 23:00:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3350C106566B for ; Fri, 10 Feb 2012 23:00:59 +0000 (UTC) (envelope-from carlj@peak.org) Received: from redcondor2.peak.org (redcondor2.peak.org [69.59.192.56]) by mx1.freebsd.org (Postfix) with ESMTP id 077068FC08 for ; Fri, 10 Feb 2012 23:00:58 +0000 (UTC) Received: from zmail-mta01.peak.org ([207.55.16.111]) by redcondor2.peak.org ({6c724cae-de34-4c5f-b615-3072b86419fa}) via TCP (outbound) with ESMTP id 20120210225058075 for ; Fri, 10 Feb 2012 22:50:58 +0000 X-RC-FROM: X-RC-RCPT: Received: from birch.localnet (unknown [207.55.106.132]) by zmail-mta01.peak.org (Postfix) with ESMTPSA id 9A4A449168B for ; Fri, 10 Feb 2012 14:50:57 -0800 (PST) Received: from oak.localnet (oak.localnet [192.168.193.34]) by birch.localnet (Postfix) with ESMTP id 107C6556E8 for ; Fri, 10 Feb 2012 14:50:54 -0800 (PST) Received: from oak.localnet (localhost.localnet [127.0.0.1]) by oak.localnet (Postfix) with ESMTP id A153FD1A7 for ; Fri, 10 Feb 2012 14:50:54 -0800 (PST) Received: (from carlj@localhost) by oak.localnet (8.14.4/8.14.4/Submit) id q1AMosF0055903; Fri, 10 Feb 2012 14:50:54 -0800 (PST) (envelope-from carlj@peak.org) X-Authentication-Warning: oak.localnet: carlj set sender to carlj@peak.org using -f From: Carl Johnson To: freebsd-stable@freebsd.org References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> Mail-Followup-To: freebsd-stable@freebsd.org Date: Fri, 10 Feb 2012 14:50:54 -0800 In-Reply-To: <4F35743B.4020302@os2.kiev.ua> (Alex Samorukov's message of "Fri, 10 Feb 2012 20:47:07 +0100") Message-ID: <87d39m2tgx.fsf@oak.localnet> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 23:00:59 -0000 Alex Samorukov writes: > On 02/10/2012 06:56 PM, Joe Holden wrote: >> Guys, >> >> This should really be reverted to sysinstall until the new installer >> is at least in a state where it consistently works... the most >> important part of a new users experience is the installer and the >> few new installs I have done lately I've just installed 8.2 and >> upgraded from there as the new installer is terribly buggy. >> > Hi, > > I am highly against reverting. Old installer is not GPT aware and in > fact is unmaintained for a very long time. > > About ftp - its probably needs to be handled better, but most of the > user i think using cd/dvd image, so it is not an issue. And new > installer is written on shell, so i think its better to fix broken > parts then to revert it to outdated and unmaintained code. The major problem I saw is that I couldn't find any mention of the packages on the CD/DVD in any of the menus. Is there really no way of installing them, or did I manage to overlook it? I ran through it twice and ended up using sysinstall both times to install the packages. -- Carl Johnson carlj@peak.org From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 23:11:02 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 549A4106564A for ; Fri, 10 Feb 2012 23:11:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE928FC1E for ; Fri, 10 Feb 2012 23:11:01 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta06.emeryville.ca.mail.comcast.net with comcast id YP5E1i0041HpZEsA6PB1D2; Fri, 10 Feb 2012 23:11:01 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id YPAz1i0241t3BNj8aPB0gH; Fri, 10 Feb 2012 23:11:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7233B102C1E; Fri, 10 Feb 2012 15:10:59 -0800 (PST) Date: Fri, 10 Feb 2012 15:10:59 -0800 From: Jeremy Chadwick To: Alexander Leidinger Message-ID: <20120210231059.GA25777@icarus.home.lan> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 23:11:02 -0000 On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: > during some big discussions in the last monts on various lists, one > of the problems was that some people would like to use > freebsd-update but can't as they are using a custom kernel. With all > the kernel modules we provide, the need for a custom kernel should > be small, but on the other hand, we do not provide a small > kernel-skeleton where you can load just the modules you need. My below comments apply to RELENG_8, amd64. Just noting that here. I have no plans to upgrade to RELENG_9 or newer. > This should be easy to change. As a first step I took the generic > kernel and removed all devices which are available as modules, e.g. > the USB section consists now only of the USB_DEBUG option (so that > the module is build like with the current generic kernel). I also > removed some storage drivers which are not available as a module. > The rationale is, that I can not remove CAM from the kernel config > if I let those drivers inside (if those drivers are important > enough, someone will probably fix the problem and add the missing > pieces to generate a module). This is a core (meaning "key") problem as I see it. There is no definitive list of what drivers can/will work as modules vs. being compiled in to the kernel statically. Furthermore, there is evidence on the mailing lists where users experience different behaviour in drivers when built as modules than if statically included: em(4) is one such example (I can dig up the post if needed). Jack often asks me why we include em(4) statically. :-) > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you? Excellent question, and I would love to share with folks the list of things we tweak in our kernel config vs. GENERIC: * Removal: option INET6 * Removal: option SCTP * Removal: option COMPAT_FREEBSD32 * Removal: option COMPAT_FREEBSD4 * Removal: option COMPAT_FREEBSD5 * Removal: option COMPAT_FREEBSD6 * Removal: option COMPAT_FREEBSD7 * Setting: option PRINTF_BUFR_SIZE=256 * Addition: option KDTRACE_HOOKS * Addition: option FLOWTABLE - Note: Despite this, we disable use of flowtable via sysctl due to severe bugs as we have no indication this has been fixed: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060289.html * Addition: option BREAK_TO_DEBUGGER * Addition: option ALT_BREAK_TO_DEBUGGER * Addition: option KDB * Addition: option KDB_TRACE * Addition: option DDB * Addition: option DDB_NUMSYM * Addition: option GDB * Addition: option KTR * Addition: option KTR_ENTRIES=262144 * Addition: option KTR_COMPILE=(KTR_SCHED) * Addition: option KTR_MASK=(KTR_SCHED) * Removal: device ata - Note: Our config has the following comment: # NOTE: "device ata" is missing because we use the Modular ATA core # to only include the ATA-related drivers we need (e.g. AHCI). * Removal: device atapifd * Removal: device atapist * Removal: All device/options relating to SCSI controllers * Addition: device atacore * Addition: device ataisa * Addition: device atapci * Addition: device ataahci * Addition: device ataintel * Removal: device ch * Removal: device sa * Removal: All device/options pertaining to RAID controllers * Removal: All device/options pertaining to PCMCIA/CardBus * Removal: All device/options pertaining to parallel ports * Removal: device puc * Removal: All PCI Ethernet NICs (with and without miibus), with the exception being em * Removal: All ISA Ethernet NICs * Removal: All Wireless NICs * Removal: device vlan * Removal: device tun * Removal: device gif * Removal: device faith * Removal: option USB_DEBUG * Removal: device ulpt * Removal: All device/options pertaining to USB serial devices * Removal: All device/options pertaining to USB Ethernet devices * Removal: All device/options pertaining to USB Wireless devices * Removal: All device/options pertaining to FireWire * Addition: device coretemp * Addition: device smbus * Addition: device smb * Addition: device ichsmb * Addition: device ichwd - Note: We do not use features of this driver given known problems with the watchdog firing during ddb> and similar environments. I have no idea if this has been fixed, but I do remember it being confirmed as a problem. * Addition: options ALTQ * Addition: options ALTQ_CBQ * Addition: options ALTQ_RED * Addition: options ALTQ_RIO * Addition: options ALTQ_HFSC * Addition: options ALTQ_CDNR * Addition: options ALTQ_PRIQ * Addition: options ALTQ_NOPCC I want to note here: the pf ALTQ options are a pain in the butt, quite honestly. I've found in the past that removing the ones you don't use won't result in a successful build, thus one must include them all. We do need ALTQ support though, for rate-limiting capability. The NOPCC option is needed for SMP builds, which makes me wonder what the state of SMP is in this regard -- meaning, on non-SMP builds, is it still safe to include ALTQ_NOPCC? Now, most of the device-related ones -- ASSUMING they can be used reliably as kernel modules -- can probably be ignored (meaning if you strip them out, per your proposal, that's fine). However, the list of options above still stands. Also, there are obviously kernel modules which we're using dynamically, such as ahci.ko (/boot/loader.conf ahci_load="yes") and some others: # kldstat Id Refs Address Size Name 1 20 0xffffffff80100000 1d34f30 kernel 2 1 0xffffffff81e36000 11e48 ahci.ko 3 1 0xffffffff82012000 1313a8 zfs.ko 4 1 0xffffffff82144000 1ff1 opensolaris.ko 5 1 0xffffffff82146000 28c93 pf.ko 6 1 0xffffffff8216f000 7f8 accf_http.ko 7 1 0xffffffff82170000 1f0 accf_data.ko So in this case, ZFS is loaded dynamically via zfs_enable="yes" in rc.conf, as is pf. The accf_* combo is pulled in in real-time when one uses Apache with apache22_http_accept_enable="yes". All the other options you see that we adjust we have legitimate need for. I cannot stress (to you and others) how important it is to have many of the debugging options in there; in the case of a kernel panic, in almost every case on the mailing lists, the first response from developers is "can you drop to ddb and..." I realise for folks running remote/embedded environments these probably aren't what they want, but for the majority I see them as being needed more and more I watch the responses from developers. Finally, just throwing this out there: does anyone know if you can include ALT_BREAK_TO_DEBUGGER by itself, without BREAK_TO_DEBUGGER? E.g. we only want ~ inducing a break to ddb, not serial break. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 23:18:51 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 93454106566C; Fri, 10 Feb 2012 23:18:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D3B7D14D897; Fri, 10 Feb 2012 23:18:50 +0000 (UTC) Message-ID: <4F35A5DA.7070602@FreeBSD.org> Date: Fri, 10 Feb 2012 15:18:50 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Adrian Chadd References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 23:18:51 -0000 On 02/10/2012 12:13, Adrian Chadd wrote: > I've done this a few times. > > The /boot/loader takes a _long_ time to suck in the 25 odd modules my > eeepc requires to load a completely modular kernel. For those modules not directly related to booting you're better off putting them in kld_list in rc.conf. It's available already in 9, and in [78]-stable. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 23:30:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C5E106566B for ; Fri, 10 Feb 2012 23:30:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0418FC0A for ; Fri, 10 Feb 2012 23:30:25 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id YPWP1i0061smiN4A5PWRJu; Fri, 10 Feb 2012 23:30:25 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id YPWQ1i01R1t3BNj8gPWQNo; Fri, 10 Feb 2012 23:30:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 60EC5102C1E; Fri, 10 Feb 2012 15:30:24 -0800 (PST) Date: Fri, 10 Feb 2012 15:30:24 -0800 From: Jeremy Chadwick To: Ian Lepore Message-ID: <20120210233024.GA26774@icarus.home.lan> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> <1328916321.6341.5.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1328916321.6341.5.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 23:30:25 -0000 On Fri, Feb 10, 2012 at 04:25:21PM -0700, Ian Lepore wrote: > On Fri, 2012-02-10 at 15:10 -0800, Jeremy Chadwick wrote: > > * Addition: device ichwd > > - Note: We do not use features of this driver given known problems > > with the watchdog firing during ddb> and similar environments. I > > have no idea if this has been fixed, but I do remember it being > > confirmed as a problem. > > It used to be that "watchdog 0" in ddb disabled the watchdog, then when > we upgraded to 8.2 that stopped working. One day I discovered (via > typo) that now just "watchdog" without a numeric parm disables it. I'm > not positive that applies to the ichwd but it works that way for the > hardware watchdog on our arm platforms. This won't work for us. This requires manual intervention. When we have a machine that panic's, we want it sitting at a ddb> prompt indefinitely until an admin gets to it to find out what happened. There may be some way to automatically run ddb commands when ddb is induced, but I haven't dug into it yet. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 23:38:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 592AF106564A for ; Fri, 10 Feb 2012 23:38:34 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 406D28FC13 for ; Fri, 10 Feb 2012 23:38:34 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta12.emeryville.ca.mail.comcast.net with comcast id YPRE1i0080vp7WLACPRQJH; Fri, 10 Feb 2012 23:25:24 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id YPRN1i00p4NgCEG8RPRP5k; Fri, 10 Feb 2012 23:25:23 +0000 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 q1ANPLrf034019; Fri, 10 Feb 2012 16:25:21 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Jeremy Chadwick In-Reply-To: <20120210231059.GA25777@icarus.home.lan> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> Content-Type: text/plain Date: Fri, 10 Feb 2012 16:25:21 -0700 Message-Id: <1328916321.6341.5.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Feb 2012 23:38:34 -0000 On Fri, 2012-02-10 at 15:10 -0800, Jeremy Chadwick wrote: > * Addition: device ichwd > - Note: We do not use features of this driver given known problems > with the watchdog firing during ddb> and similar environments. I > have no idea if this has been fixed, but I do remember it being > confirmed as a problem. It used to be that "watchdog 0" in ddb disabled the watchdog, then when we upgraded to 8.2 that stopped working. One day I discovered (via typo) that now just "watchdog" without a numeric parm disables it. I'm not positive that applies to the ichwd but it works that way for the hardware watchdog on our arm platforms. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 01:27:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B9A4106566B for ; Sat, 11 Feb 2012 01:27:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 3E65B8FC18 for ; Sat, 11 Feb 2012 01:27:54 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta09.emeryville.ca.mail.comcast.net with comcast id YR8V1i00A1GXsucA9RTuk1; Sat, 11 Feb 2012 01:27:54 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id YRTt1i01C1t3BNj8URTuQS; Sat, 11 Feb 2012 01:27:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A8C1A102C1E; Fri, 10 Feb 2012 17:27:53 -0800 (PST) Date: Fri, 10 Feb 2012 17:27:53 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120211012753.GA29375@icarus.home.lan> References: <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> <4F358DB6.4030203@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F358DB6.4030203@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 01:27:55 -0000 Mike, I wanted to make you aware of this commit that just came through: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c I would recommend trying this out first to see if it improves your situation with disks on the PM. mav@ might be able to state with more certainty if that commit could address the problems you're seeing, and I know that you're seeing these errors on non-PM-attached devices too, which I'll look at in a bit. But I wanted to make you aware of the above. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 01:44:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 864D41065675; Sat, 11 Feb 2012 01:44:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 444368FC14; Sat, 11 Feb 2012 01:44:04 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q1B1hu0K002186; Fri, 10 Feb 2012 20:43:56 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F35C7D8.5050707@sentex.net> Date: Fri, 10 Feb 2012 20:43:52 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> <4F358DB6.4030203@sentex.net> <20120211012753.GA29375@icarus.home.lan> In-Reply-To: <20120211012753.GA29375@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 01:44:04 -0000 On 2/10/2012 8:27 PM, Jeremy Chadwick wrote: > Mike, > > I wanted to make you aware of this commit that just came through: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c Thanks, I did see that. I was going to wait until Monday to csup up once all the weekend level zeros are done. The prior kernels from Nov 28th never saw these READ LOG EXT errors on either of these 2 big zfs boxes ---Mike > > I would recommend trying this out first to see if it improves your > situation with disks on the PM. mav@ might be able to state with more > certainty if that commit could address the problems you're seeing, and I > know that you're seeing these errors on non-PM-attached devices too, > which I'll look at in a bit. But I wanted to make you aware of the > above. > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 03:01:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C553C1065670 for ; Sat, 11 Feb 2012 03:01:08 +0000 (UTC) (envelope-from jholland@fastsoft.com) Received: from fs-mail-relay.fastsoft.com (fs-mail-relay.fastsoft.com [38.102.243.14]) by mx1.freebsd.org (Postfix) with ESMTP id A22CD8FC1A for ; Sat, 11 Feb 2012 03:01:08 +0000 (UTC) Received: from hq-es.fastsoft.com (hq-es.fastsoft.com [38.102.243.86]) by fs-mail-relay.fastsoft.com (8.14.4/8.14.4) with ESMTP id q1B2oE2V042260 for ; Fri, 10 Feb 2012 18:50:30 -0800 (PST) (envelope-from jholland@fastsoft.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Feb 2012 18:50:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: hang during dump (reproducible) Thread-Index: AczoZ+Fn+NvkyIiISSKG8TQogz+obA== From: "Jake Holland" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: hang during dump (reproducible) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 03:01:08 -0000 Hi, I was reliably seeing a hang during panic in stable/8 -r231144 (and 8.2 = release) with an active ssh session. The SCHEDULER_STOPPED patch fixed = it, once I found it: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030127.h= tml http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063824.h= tml Many thanks to Attilio Rao, Kostik Belousov, and Andriy Gapon. And = anybody else involved. However, when I looked at the commit I noticed this: > $ svn log -r228424 svn://svn.freebsd.org/base ... > MFC after: 3 months (or never) I'm not sure whether "never" is still considered an option, but it would = be useful for me if 8.3 release, when it comes, does not hang this way = during panic. But thanks for the patch, regardless. Problem details: If I did a "sysctl debug.kdb.panic=3D1" from the console while the = machine was idle, the dump would complete and the machine would reboot = and come up with a good core. If I did the same command remotely via ssh, it would hang every time. I also usually would see a hang if I had an active ssh session printing = things while I caused a panic from the console. Occasionally in that = case it would continue and make a good core if I killed the ssh session = from the client side. An open but idle ssh session did not seem to = induce a hang. If anybody wants other details, I'd be happy to provide them. Jake Holland From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 04:56:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F3ED106566C for ; Sat, 11 Feb 2012 04:56:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3464D8FC08 for ; Sat, 11 Feb 2012 04:56:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw50u-000BSf-Eg for freebsd-stable@freebsd.org; Sat, 11 Feb 2012 04:56:44 +0000 Date: Fri, 10 Feb 2012 20:56:43 -0800 Message-ID: From: Randy Bush To: FreeBSD Stable User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 04:56:45 -0000 is there a recipe for moving from i386 to amd64? on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, all 32-bit. it was done with repeated make buildworld make kernel.new [0] nextboot -k kernel.new reboot make installworld etc [0] - well, there were some mv(1)s in there :) so after it was happy with 9.0 i386, i went to move to amd64 with make buildworld TARGET=amd64 make kernel TARGET=amd64 DESTDIR=kernel.new [0] nextboot -k kernel.new reboot it did not come back from the reboot, and required a manual reset. i have no console access to the machine, not my choice. clue bat please. randy From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 05:48:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 055C8106564A for ; Sat, 11 Feb 2012 05:48:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F3B52152BB1; Sat, 11 Feb 2012 05:48:19 +0000 (UTC) Message-ID: <4F360123.2050708@FreeBSD.org> Date: Fri, 10 Feb 2012 21:48:19 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 05:48:21 -0000 On 02/10/2012 20:56, Randy Bush wrote: > is there a recipe for moving from i386 to amd64? Other than backup and reinstall, no. As you already discovered the old world won't run on the new kernel. Installing the new world before reboot isn't safe either, as at some point in the process it'll blow up. Sorry, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:07:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22B1E106566C for ; Sat, 11 Feb 2012 06:07:13 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id DF7BB8FC08 for ; Sat, 11 Feb 2012 06:07:12 +0000 (UTC) Received: (qmail 61533 invoked by uid 0); 11 Feb 2012 06:07:12 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Feb 2012 06:07:12 -0000 Received: (qmail 61525 invoked by uid 90); 11 Feb 2012 06:07:11 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 11 Feb 2012 06:07:11 -0000 References: <4F360123.2050708@FreeBSD.org> In-Reply-To: <4F360123.2050708@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: Charles Sprickman Date: Sat, 11 Feb 2012 01:07:11 -0500 To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: Randy Bush , FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:07:13 -0000 On Feb 11, 2012, at 12:48 AM, Doug Barton wrote: > On 02/10/2012 20:56, Randy Bush wrote: >> is there a recipe for moving from i386 to amd64? > > Other than backup and reinstall, no. As you already discovered the old > world won't run on the new kernel. Installing the new world before > reboot isn't safe either, as at some point in the process it'll blow up. I recall doing it and then going on to do other bad things (like putting a 4.9/i386 jail on the 7.2 amd64 host). I'm pretty sure I had some back and forth about it on this list, but I'm having no luck finding it. I was local to the box though, so errors were a bit easier to work around. A few vague snippets I remember: -grabbing lib32 from somewhere and installing it -ensuring COMPAT_FREEBSD32 was in the kernel -possibly something complicated with /libexec/ld-elf.so.1 and its 32-bit friend I wish I could remember more. It was one of those "you cannot/should not do this" challenges that often suck down many hours. Maybe I misremembered the whole thing and gave in and reinstalled even. I do recall finding a few encouraging hacks in the archives though. Thanks, Charles > > Sorry, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.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" -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net spork@bway.net - 212.655.9344 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:10:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D12106566C for ; Sat, 11 Feb 2012 06:10:36 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 059318FC08 for ; Sat, 11 Feb 2012 06:10:35 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8B5B625D3857; Sat, 11 Feb 2012 06:10:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A69DBBDB1B5; Sat, 11 Feb 2012 06:10:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id sx7CWrhbBZLD; Sat, 11 Feb 2012 06:10:32 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6F2DDBDB1B4; Sat, 11 Feb 2012 06:10:31 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F360123.2050708@FreeBSD.org> Date: Sat, 11 Feb 2012 06:10:31 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <4F360123.2050708@FreeBSD.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:10:36 -0000 On 11. Feb 2012, at 05:48 , Doug Barton wrote: > On 02/10/2012 20:56, Randy Bush wrote: >> is there a recipe for moving from i386 to amd64? > > Other than backup and reinstall, no. As you already discovered the old > world won't run on the new kernel. Installing the new world before > reboot isn't safe either, as at some point in the process it'll blow up. heh? An i386 world should run (almost) fine on an amd64 kernel. I know people who have done that update (but I know of no one done it headless). One trick is to install to a swap partition boot that and then update the normal installation but you need to know what you are doing in that case as well. If you are very careful, that can be done headless - did a re-paritioning in a similar way lately. But in general it's all a gamble if not a streamlined process and no console. /bz PS: do you happen to know why the amd64 kernel did hang on boot? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:13:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51F941065674 for ; Sat, 11 Feb 2012 06:13:06 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id F20908FC17 for ; Sat, 11 Feb 2012 06:13:05 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id q1B628di067497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2012 00:02:08 -0600 (CST) (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 q1B6282Z090762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2012 00:02:08 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id q1B627Lp090751; Sat, 11 Feb 2012 00:02:07 -0600 (CST) (envelope-from dan) Date: Sat, 11 Feb 2012 00:02:07 -0600 From: Dan Nelson To: Randy Bush Message-ID: <20120211060207.GK5775@dan.emsphone.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Sat, 11 Feb 2012 00:02:08 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:13:06 -0000 In the last episode (Feb 10), Randy Bush said: > is there a recipe for moving from i386 to amd64? > > on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, all > 32-bit. it was done with repeated > > make buildworld > make kernel.new [0] > nextboot -k kernel.new > reboot > make installworld > etc > > [0] - well, there were some mv(1)s in there :) > > so after it was happy with 9.0 i386, i went to move to amd64 with > > make buildworld TARGET=amd64 > make kernel TARGET=amd64 DESTDIR=kernel.new [0] > nextboot -k kernel.new > reboot > > it did not come back from the reboot, and required a manual reset. i have > no console access to the machine, not my choice. > > clue bat please. You probably got bit by a mismatched /libexec/ld-elf.so. The kernel expects that to be the "native" version, and on a 64-bit kernel it also expects a ld-elf32.so to be the "compat" 32-bit version. When you rebooted onto the 64-bit kernel, it couldn't find /libexec/ld-elf32.so to run any of the 32-bit binaries on the system. My guess is that your reboot attempt died in /sbin/init, prompting for a path to /bin/sh. If you compiled with a static /bin/sh for performance, it probably died very early in /etc/rc. I think copying ld-elf.so over to ld-elf32.so might have been all you needed to boot, but that would end up with a 64-bit kernel running a true 32-bit userland with all the libraries in the "wrong" place, and your "installworld" step would replace them with their 64-bit equivalents and your install would die halfway through, leaving you with a large mess to clean up. The cleanest upgrade path is to prepare your 32-bit root to be bootable by both 32- and 64-bit kernels: copy the ld-elf32.so that was built during your buildworld over to /libexec/ld-elf32.so, and also make copies of /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when you reboot to a 64-bit kernel, your 32-bit executables will be running "correctly" out of compat32 paths and your installworld should succeed. When I did all this on a local system, I made judicious use of ZFS snapshots and clones, preserving a bootable clone of my original system plus intermediate versions all the way until I was happy with the result. I've never done it completely remotely, but if you do a trial run or two on a local machine or VM, you should be able to it confidently remotely. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:16:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A1701065672 for ; Sat, 11 Feb 2012 06:16:47 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 026E68FC0A for ; Sat, 11 Feb 2012 06:16:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw6GM-000BcL-0Z; Sat, 11 Feb 2012 06:16:46 +0000 Date: Fri, 10 Feb 2012 22:16:45 -0800 Message-ID: From: Randy Bush To: "Bjoern A. Zeeb" In-Reply-To: References: <4F360123.2050708@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:16:47 -0000 > heh? An i386 world should run (almost) fine on an amd64 kernel. I > know people who have done that update (but I know of no one done it > headless). i am not sure i want to be the first :) > PS: do you happen to know why the amd64 kernel did hang on boot? nope. dmesg -a did not help on reset randy From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:18:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0E62E106566C for ; Sat, 11 Feb 2012 06:18:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3CAD5156739; Sat, 11 Feb 2012 06:17:44 +0000 (UTC) Message-ID: <4F360807.1060400@FreeBSD.org> Date: Fri, 10 Feb 2012 22:17:43 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4F360123.2050708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randy Bush , FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:18:35 -0000 Sorry, I wasn't clear. There are various hacky solutions that you can use if you're safely within shouting distance of the system. But Randy specified "very remote," thus the answer to his question is "no." Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 06:28:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38858106566C for ; Sat, 11 Feb 2012 06:28:02 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1C58FC0A for ; Sat, 11 Feb 2012 06:28:02 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw6RF-000Bdt-Qf; Sat, 11 Feb 2012 06:28:01 +0000 Date: Fri, 10 Feb 2012 22:28:01 -0800 Message-ID: From: Randy Bush To: Dan Nelson In-Reply-To: <20120211060207.GK5775@dan.emsphone.com> References: <20120211060207.GK5775@dan.emsphone.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 06:28:02 -0000 > The cleanest upgrade path is to prepare your 32-bit root to be bootable by > both 32- and 64-bit kernels: copy the ld-elf32.so that was built during your > buildworld over to /libexec/ld-elf32.so, and also make copies of > /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when you > reboot to a 64-bit kernel, your 32-bit executables will be running > "correctly" out of compat32 paths and your installworld should succeed. > > When I did all this on a local system, I made judicious use of ZFS snapshots > and clones, preserving a bootable clone of my original system plus > intermediate versions all the way until I was happy with the result. I've > never done it completely remotely, but if you do a trial run or two on a > local machine or VM, you should be able to it confidently remotely. if i get some time next week, i will try under fusion here on my mba. worse comes to worst, i'll learn something. thanks! randy From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 07:20:50 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE9F1065670; Sat, 11 Feb 2012 07:20:50 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 658668FC0C; Sat, 11 Feb 2012 07:20:50 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1777386iae.13 for ; Fri, 10 Feb 2012 23:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition; bh=DvR2GADDEujrXiD+8uxMrMwiLsds0Sp1JDFVTNMXHfI=; b=RVGwUtmJYU5sIDYo9DlGq5MGS+lokfj+c98luZcfxVRRKH3CzwwGM9XMSbvANUbrcR Alb4/jPuHNsPp1TZ6NocfwX/wHvWnYxMjmM7rjIIf33EJ4bzd9xWVGWRj44JBkSJSYRB SHooW2NPK6c4GpIxxVIqX1upU1brJa/25rXVk= Received: by 10.42.155.70 with SMTP id t6mr13115130icw.11.1328943542444; Fri, 10 Feb 2012 22:59:02 -0800 (PST) Received: from DataIX.net (adsl-99-19-42-38.dsl.klmzmi.sbcglobal.net. [99.19.42.38]) by mx.google.com with ESMTPS id 5sm16176457ibe.8.2012.02.10.22.59.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 22:59:01 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1B6wwZZ085411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2012 01:58:58 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1B6wvS6084811; Sat, 11 Feb 2012 01:58:57 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sat, 11 Feb 2012 01:58:57 -0500 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120211065857.GA66606@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline Cc: bapt@freebsd.org, dougb@freebsd.org Subject: dhclient script adjustments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 07:20:50 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After recent merges to stable/8 I am now seeing errors on bootup of the following for three interfaces that will never see the light of DHCP. ? /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface Can someone please revert these changes or some other action. ? --=20 ;s =3D; --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPNhGxAAoJEJBXh4mJ2FR+PEcH/jbeyqoxRWTYG8nzHLpYwOaf kjtYKEL+dIsNRXcCtt0dMT/1fW3j9VXr8O6MRtL0ay0yl6rJKQ6YhaQVfxe/79wU i68N1C3Xlw8ySoFITFoV6WSh0GIIdBV4f9PCvtZRKLXXW7J6OixezFA96YHfDvuJ UtGUGiQb5ngpPRrSzoxmFeLDBFBFC+SlLG5kyjHSuJkd5e2SJFwN0PKk46EB31Jg H3LhHfdkMP7H4f2NJiJdtDpLm24Wv3vtYx5i88SEeDvif+exYBhQ7+ZKV2/aoioU 7pvU0RNZwMVZrCFNQUp3sp2Mxslm4LEIR5IDNmt9s+GczPFB57M8oqKNUki6laU= =hjXV -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 07:35:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B19C106564A for ; Sat, 11 Feb 2012 07:35:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D2B7C8FC08 for ; Sat, 11 Feb 2012 07:35:43 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1B7ZR8A084355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Feb 2012 09:35:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1B7ZR11055249; Sat, 11 Feb 2012 09:35:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1B7ZRch055248; Sat, 11 Feb 2012 09:35:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 11 Feb 2012 09:35:27 +0200 From: Konstantin Belousov To: Dan Nelson Message-ID: <20120211073527.GQ3283@deviant.kiev.zoral.com.ua> References: <20120211060207.GK5775@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ohhUr6qMC+8zx6A6" Content-Disposition: inline In-Reply-To: <20120211060207.GK5775@dan.emsphone.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Randy Bush , FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 07:35:44 -0000 --ohhUr6qMC+8zx6A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 11, 2012 at 12:02:07AM -0600, Dan Nelson wrote: > In the last episode (Feb 10), Randy Bush said: > > is there a recipe for moving from i386 to amd64? > >=20 > > on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, a= ll > > 32-bit. it was done with repeated > >=20 > > make buildworld > > make kernel.new [0] > > nextboot -k kernel.new > > reboot > > make installworld > > etc > >=20 > > [0] - well, there were some mv(1)s in there :) > >=20 > > so after it was happy with 9.0 i386, i went to move to amd64 with > >=20 > > make buildworld TARGET=3Damd64 > > make kernel TARGET=3Damd64 DESTDIR=3Dkernel.new [0] > > nextboot -k kernel.new > > reboot > >=20 > > it did not come back from the reboot, and required a manual reset. i h= ave > > no console access to the machine, not my choice. > >=20 > > clue bat please. >=20 > You probably got bit by a mismatched /libexec/ld-elf.so. The kernel expec= ts > that to be the "native" version, and on a 64-bit kernel it also expects a > ld-elf32.so to be the "compat" 32-bit version. When you rebooted onto the > 64-bit kernel, it couldn't find /libexec/ld-elf32.so to run any of the > 32-bit binaries on the system. My guess is that your reboot attempt died= in > /sbin/init, prompting for a path to /bin/sh. If you compiled with a stat= ic > /bin/sh for performance, it probably died very early in /etc/rc. These statements are false, esp. worrying is that they are interwinned with some facts that get tilted to support false presumption. Kernel do not care about which interpreter is /libexec/ld-elf.so. The path to the interpreter is specified in the binary itself. So if you have 32bit binary that put '/libexec/ld-elf.so.1' into PH_INTERP, and /libexec/ld-elf.so.1 is 32bit, then amd64 kernel properly executes that combination. Kernel has a hack that falls back to try to use /libexec/ld-elf32.so.1 for some 'brands' of ELF images, in particular, for 32bit binaries. This is done to help in situation when 32bit binaries also specified the same path for interpreter. If you have 32bit world installed and booted 64bit kernel, it will boot.=20 It is the same as running 32bit world in the jail. The management functions, like configuring network interfaces, ZFS and many other system setup functionality does not work, indeed. >=20 > I think copying ld-elf.so over to ld-elf32.so might have been all you nee= ded > to boot, but that would end up with a 64-bit kernel running a true 32-bit > userland with all the libraries in the "wrong" place, and your > "installworld" step would replace them with their 64-bit equivalents and > your install would die halfway through, leaving you with a large mess to > clean up. Absolute false. >=20 > The cleanest upgrade path is to prepare your 32-bit root to be bootable by > both 32- and 64-bit kernels: copy the ld-elf32.so that was built during y= our > buildworld over to /libexec/ld-elf32.so, and also make copies of > /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when y= ou > reboot to a 64-bit kernel, your 32-bit executables will be running > "correctly" out of compat32 paths and your installworld should succeed. >=20 > When I did all this on a local system, I made judicious use of ZFS snapsh= ots > and clones, preserving a bootable clone of my original system plus > intermediate versions all the way until I was happy with the result. I've > never done it completely remotely, but if you do a trial run or two on a > local machine or VM, you should be able to it confidently remotely. >=20 > --=20 > 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" --ohhUr6qMC+8zx6A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk82Gj4ACgkQC3+MBN1Mb4iFFQCguAgqXjt0mc4sIbIGDj+T5Z/8 2mkAoKa1QV29kTDyi0cN3kCl/b1M2Qfh =Gl/D -----END PGP SIGNATURE----- --ohhUr6qMC+8zx6A6-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 08:29:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4534106566C for ; Sat, 11 Feb 2012 08:29:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD978FC12 for ; Sat, 11 Feb 2012 08:29:30 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1B8TS6F071982 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 11 Feb 2012 00:29:29 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F36273E.9010805@freebsd.org> Date: Sat, 11 Feb 2012 00:30:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> <20120210062411.GA9664@icarus.home.lan> In-Reply-To: <20120210062411.GA9664@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , jpaetzel@ixsystems.com Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 08:29:31 -0000 On 2/9/12 10:24 PM, Jeremy Chadwick wrote: > On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: >> On 2/9/12 1:56 PM, Jeremy Chadwick wrote: >>> On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: >>>> does anyone know of problems with freebsd and this system? >>>> >>>> the kernel We tried to boot seems to stop somewhere in the ahci probing. >>> Few things: >>> >>> 1) Possible to get full console output (e.g. serial, etc.) from a verbose >>> boot? >> it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems >> at the >> moment.. but I wasnhoping someone could save us some time by saying >> "Oh yeah, merge in change number xxxxxx" >> >>> 2) Can you also provide the exact release/tag/kernel/thing you're trying >>> to install or upgrade to ("8.x" is a little vague; there are all sorts >>> of changes that happen between tags). For example 8.1 is not going to >>> behave the same necessarily as 8.2. >>> >>> 3) When you say "ahci probing", are you booting a standard installation >>> CD/DVD/memstick of, say, 8.2? If so, those won't make use of the >>> AHCI-to-CAM translation layer (and that AHCI code is also different than >>> the native-ATA-AHCI code), so you might try, when booting the system, >>> dropping to the loader prompt and issuing "load ahci.ko" before typing >>> "boot". See if that helps. If it does, great, use it (ahci_load="yes" >>> in /boot/loader.conf) permanently (and benefit from things like NCQ >>> too). >> let me forward you an image... >>> 4) If it's an Intel ESB2 controller, I believe there were some fixes or >>> identification shims put in place for this in recent RELENG_8, which >>> wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be >>> remembering the wrong controller though. Hmm... >>> >> that may be what we are looking for. >> >> I'll try get more info. > For others: the last few lines in the kernel log are: > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi: wakeup code va 0xffffff848311d000 pa 0x4000 > ahc_isa_probe 0: ioport 0xc00 alloc failed > > I don't see any indication of AHCI problems here (or AHCI at all). > ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. > > A verbose boot might be more helpful. turns out that the HP machine has an HP branded (and with different firmware) raid controller that is not quite the same as the standard one. FreeBSD can't handle it and dies. Josh Paetzel may remember the exact type.. I forget.. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 08:41:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 760E2106564A for ; Sat, 11 Feb 2012 08:41:06 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 5304C8FC13 for ; Sat, 11 Feb 2012 08:41:06 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1B8f5fM056262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Feb 2012 00:41:05 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1B8f5Ve056261; Sat, 11 Feb 2012 00:41:05 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08891; Sat, 11 Feb 12 00:34:09 PST Date: Sat, 11 Feb 2012 07:33:08 -0800 From: perryh@pluto.rain.com To: bzeeb-lists@lists.zabbadoz.net Message-Id: <4f368a34.rIGc5BVL5Vu8OIjl%perryh@pluto.rain.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> In-Reply-To: <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alexander@Leidinger.net, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 08:41:06 -0000 "Bjoern A. Zeeb" wrote: > various parts of the network stack being loadable, which is not > as easy as it sounds, especially making them unloadable again > currently ... Seems to me unloadability does not matter to the case under discussion, which is modularizing the kernel to reduce the number of cases in which a custom kernel is needed. How much real functional difference is there between "built in" and "loaded permanently at boot"? From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 09:58:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 536381065672 for ; Sat, 11 Feb 2012 09:58:31 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3554C8FC0C for ; Sat, 11 Feb 2012 09:58:31 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw9iw-000C01-9N; Sat, 11 Feb 2012 09:58:30 +0000 Date: Sat, 11 Feb 2012 01:58:30 -0800 Message-ID: From: Randy Bush To: Konstantin Belousov In-Reply-To: <20120211073527.GQ3283@deviant.kiev.zoral.com.ua> References: <20120211060207.GK5775@dan.emsphone.com> <20120211073527.GQ3283@deviant.kiev.zoral.com.ua> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 09:58:31 -0000 > These statements are false, esp. worrying is that they are > interwinned with some facts that get tilted to support false presumption. > > Kernel do not care about which interpreter is /libexec/ld-elf.so. > The path to the interpreter is specified in the binary itself. So if you > have 32bit binary that put '/libexec/ld-elf.so.1' into PH_INTERP, > and /libexec/ld-elf.so.1 is 32bit, then amd64 kernel properly executes > that combination. > > Kernel has a hack that falls back to try to use /libexec/ld-elf32.so.1 > for some 'brands' of ELF images, in particular, for 32bit binaries. This > is done to help in situation when 32bit binaries also specified the > same path for interpreter. > > If you have 32bit world installed and booted 64bit kernel, it will boot. > It is the same as running 32bit world in the jail. > The management functions, like configuring network interfaces, ZFS > and many other system setup functionality does not work, indeed. as the system in this case is half the planet away and without console access, it might be helpful to have network interfaces working. so do you have direct suggestion(s) on how to hack the system (while the 32-bit kernel is running) so that i can boot the 64-bit kernel and get the 64-bit world up? randy From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 11:25:15 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7A0106566C for ; Sat, 11 Feb 2012 11:25:15 +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 D476E8FC1A for ; Sat, 11 Feb 2012 11:25:14 +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 NAA28894; Sat, 11 Feb 2012 13:11:05 +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 1RwArB-000DCk-83; Sat, 11 Feb 2012 13:11:05 +0200 Message-ID: <4F364CC8.2030000@FreeBSD.org> Date: Sat, 11 Feb 2012 13:11:04 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> <1328916321.6341.5.camel@revolution.hippie.lan> <20120210233024.GA26774@icarus.home.lan> In-Reply-To: <20120210233024.GA26774@icarus.home.lan> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 11:25:15 -0000 on 11/02/2012 01:30 Jeremy Chadwick said the following: > This won't work for us. This requires manual intervention. When we > have a machine that panic's, we want it sitting at a ddb> prompt > indefinitely until an admin gets to it to find out what happened. There > may be some way to automatically run ddb commands when ddb is induced, > but I haven't dug into it yet. Yep. See ddb(8). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 11:55:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33925106566C for ; Sat, 11 Feb 2012 11:55:15 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id C182A8FC12 for ; Sat, 11 Feb 2012 11:55:14 +0000 (UTC) Received: from neon.fritz.box (helium.xs4all.nl [83.163.52.241]) (authenticated bits=0) by erg.verweg.com (8.14.5/8.14.4) with ESMTP id q1BBt7u0030323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 11 Feb 2012 11:55:13 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [83.163.52.241] claimed to be neon.fritz.box Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ruben van Staveren In-Reply-To: Date: Sat, 11 Feb 2012 12:55:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58313F27-D0B4-4896-B12B-232237E3A308@verweg.com> References: <20120211060207.GK5775@dan.emsphone.com> <20120211073527.GQ3283@deviant.kiev.zoral.com.ua> To: Randy Bush X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (erg.verweg.com [94.142.245.8]); Sat, 11 Feb 2012 11:55:13 +0000 (UTC) Cc: Konstantin Belousov , FreeBSD Stable Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 11:55:15 -0000 Hi Randy, On 11 Feb 2012, at 10:58, Randy Bush wrote: > so do you have direct suggestion(s) on how to hack the system (while = the > 32-bit kernel is running) so that i can boot the 64-bit kernel and get > the 64-bit world up? >=20 > randy trying something nanobsd'ish in where you get a 64bit kernel to run with = a mfsroot image which brings up networking so you can get in from remote = and kick of from there ? mfsroot should hold enough stuff to buildworld = etc. Just an idea. Cheers, Ruben From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 13:00:57 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C740106564A for ; Sat, 11 Feb 2012 13:00:57 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mx1a.lautre.net (mx1a.lautre.net [80.67.160.71]) by mx1.freebsd.org (Postfix) with ESMTP id 37CD18FC0A for ; Sat, 11 Feb 2012 13:00:56 +0000 (UTC) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry@pompo.net) by mx1a.lautre.net (Postfix) with ESMTPSA id 5BFF740EB4 for ; Sat, 11 Feb 2012 13:40:56 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id BC4321146B; Sat, 11 Feb 2012 13:40:41 +0100 (CET) Date: Sat, 11 Feb 2012 13:40:41 +0100 From: Thierry Thomas To: stable@FreeBSD.org Message-ID: <20120211124041.GF32360@graf.pompo.net> Mail-Followup-To: stable@FreeBSD.org References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 9.0-STABLE i386 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xC71405A2 Cc: Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 13:00:57 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le ven 10 f=E9v 12 =E0 14:56:04 +0100, Alexander Leidinger =E9crivait=A0: > Hi, Hello, > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes to > my mind)? If yes, which ones and how important are they for you? Not very important, but since you are asking, is there another place to put options to atkbd and sc, like these ones: options ATKBD_DFLT_KEYMAP # specify the built-in keymap makeoptions ATKBD_DFLT_KEYMAP=3Dfr.iso.acc options SC_KERNEL_CONS_ATTR=3D(FG_LIGHTGREEN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=3D(FG_WHITE|BG_GREEN) options SC_NORM_REV_ATTR=3D(FG_WHITE|BG_BLUE) Regards, --=20 Th. Thomas. --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk82YckACgkQc95pjMcUBaK23QCgyugS83G44AQKM+5eWN9TTw5G VAMAn2c31WkiB8P2HSWyiFQJwD2uMslI =4yER -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 13:22:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F21121065673 for ; Sat, 11 Feb 2012 13:22:20 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 95D528FC08 for ; Sat, 11 Feb 2012 13:22:19 +0000 (UTC) Received: (qmail 71938 invoked by uid 907); 11 Feb 2012 12:55:37 -0000 Received: from b13FC.static.pacific.net.au (HELO [192.168.1.154]) (202.7.88.252) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 11 Feb 2012 23:55:37 +1100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jan Mikkelsen In-Reply-To: <4F36273E.9010805@freebsd.org> Date: Sat, 11 Feb 2012 23:55:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <80227576-89AE-4831-8565-BED2323D2FFD@transactionware.com> References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> <20120210062411.GA9664@icarus.home.lan> <4F36273E.9010805@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1257) Cc: FreeBSD Stable , jpaetzel@ixsystems.com, Jeremy Chadwick Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 13:22:21 -0000 On 11/02/2012, at 7:30 PM, Julian Elischer wrote: >=20 > turns out that the HP machine has an HP branded (and with different = firmware) raid controller > that is not quite the same as the standard one. FreeBSD can't handle = it and dies. >=20 > Josh Paetzel may remember the exact type.. I forget.. >=20 I have some memory of HP DL160 servers with an embedded ciss(4) = controller taking a long time to boot. I recall a delay of multiple = minutes. I don't remember what I did to work around it. Does it really stop, or is it just being slow? Regards, Jan. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 15:21:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1103106564A for ; Sat, 11 Feb 2012 15:21:25 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 70FB98FC16 for ; Sat, 11 Feb 2012 15:21:25 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 34CFC20C77 for ; Sat, 11 Feb 2012 10:02:37 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 11 Feb 2012 10:02:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from :subject:date:to; s=smtpout; bh=u4Ri7fvxqczMzp7sIBON5TfOong=; b= ZilsI1fc3bwca7h2fjBUQwLMK+jxtEGqleCo9lihQ6csRJyGY45Bnfrb29ehj+3y TPO+RYvU+CybtQuxZwguPHQpEqBGhCA/AxcD/EWGYM72iSYQFhBocqd4rp3hIGe9 EwA+mzBbZFRPkmQXhwmnRTT1UnqXAdSU/bA7OciqaG8= X-Sasl-enc: h72L+7e/U6ZAc/ytmTo0q6SbGRcPpX1XpxRZohUnLjfw 1328972556 Received: from [10.10.1.128] (unknown [216.139.7.151]) by mail.messagingengine.com (Postfix) with ESMTPSA id AF0138E00D9; Sat, 11 Feb 2012 10:02:36 -0500 (EST) References: <4F343F2D.4040307@freebsd.org> <20120209215600.GA1793@icarus.home.lan> <4F345E84.8080307@freebsd.org> <20120210062411.GA9664@icarus.home.lan> <4F36273E.9010805@freebsd.org> <80227576-89AE-4831-8565-BED2323D2FFD@transactionware.com> In-Reply-To: <80227576-89AE-4831-8565-BED2323D2FFD@transactionware.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8957A163-6A31-4666-AA7F-C05ED6487808@tcbug.org> X-Mailer: iPhone Mail (9A405) From: Josh Paetzel Date: Sat, 11 Feb 2012 07:02:33 -0800 To: Jan Mikkelsen Cc: FreeBSD Stable , Julian Elischer , "jpaetzel@ixsystems.com" , Jeremy Chadwick Subject: Re: known problems with 8.x and HP DL16 G5 server? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 15:21:25 -0000 On Feb 11, 2012, at 4:55 AM, Jan Mikkelsen wrote:= >=20 > On 11/02/2012, at 7:30 PM, Julian Elischer wrote: >>=20 >> turns out that the HP machine has an HP branded (and with different firmw= are) raid controller >> that is not quite the same as the standard one. FreeBSD can't handle it a= nd dies. >>=20 >> Josh Paetzel may remember the exact type.. I forget.. >>=20 >=20 >=20 > I have some memory of HP DL160 servers with an embedded ciss(4) controller= taking a long time to boot. I recall a delay of multiple minutes. I don't r= emember what I did to work around it. >=20 > Does it really stop, or is it just being slow? >=20 > Regards, >=20 > Jan. >=20 It really does stop. It was left overnight once. It has an old mpt (rebrande= d lsi 1068) with HP firmware on it. The controller takes way too long to pro= be but eventually it passes that and then hangs where Julian describes.=20 If you poke around on the web, there's posts where this machine hangs on boo= t on 6.2, 7.0 and 8.0. Removing the HBA allows it to boot normally.=20 My next troubleshooting step would be replacing the HBA with one with stock L= SI firmware.=20 Thanks, Josh Paetzel= From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 16:12:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9D64106566B; Sat, 11 Feb 2012 16:12:32 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id ACADC8FC0A; Sat, 11 Feb 2012 16:12:30 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1BFtaqe031450 ; Sat, 11 Feb 2012 16:55:49 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1BFrBHV047752; Sat, 11 Feb 2012 16:53:11 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1BFrBiw047749; Sat, 11 Feb 2012 16:53:11 +0100 (CET) (envelope-from arno) To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" Date: Sat, 11 Feb 2012 16:53:10 +0100 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F368F78.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F368F78.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org Subject: 9-stable : geli + one-disk ZFS fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 16:12:32 -0000 Hello, I finally decided to 'play' a bit with ZFS on a notebook, some years old, but I installed a brand new disk and memtest passes OK. I installed base+ports on partition 2, using 'classical' UFS. I crypted partition 3 and created a single zpool on it containing 4 Z-"file-systems" : [root@cc ~]# zfs list NAME USED AVAIL REFER MOUNTPOINT zfiles 10.7G 377G 152K /zfiles zfiles/home 10.6G 377G 119M /zfiles/home zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito I export the ZFS's via nfs and rsynced on the other machine some backup of my current note-book (geli + UFS, (almost) same 9-stable version, no problem) to the ZFS's. Quite fast, I see on the notebook : [root@cc /usr/temp]# zpool status -v pool: zfiles 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 repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 11 ada0s3.eli ONLINE 0 0 23 errors: Permanent errors have been detected in the following files: /zfiles/home/arno/.scito/contrib/XNAT.tar [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error [root@cc /usr/temp]# As said, memtest is OK, nothing is logged to the console, UFS on the same disk works OK (I did some tests copying and comparing random data) and smartctl as well seems to trust the disk : SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) # 1 Extended offline Completed without error 00% 388 # 2 Short offline Completed without error 00% 387 Am I doing something wrong and/or let me know what I could provide as extra info to try to solve this (dmesg.boot at the end of this mail). Thanx a lot in advance, best, Arno ################### demsg.boot ####### Table 'FACP' at 0xbdd90200 Table 'APIC' at 0xbdd90390 APIC: Found table at 0xbdd90390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 130 ACPI ID 3: disabled MADT: Found CPU APIC ID 131 ACPI ID 4: disabled Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #0: Fri Feb 3 22:48:57 CET 2012 toor@cc:/usr/obj/raid1/bsd/9/src/sys/VR603 amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bba000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80bba200. Calibrating TSC clock ... TSC clock: 2161296371 Hz CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz (2161.30-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000095fff, 610304 bytes (149 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000be9000 - 0x00000000b8402fff, 3078725632 bytes (751642 pages) avail memory = 3057152000 (2915 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000210000 x86bios: EBDA 0x099000-0x09ffff at 0xfffffe0000099000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf9420 00014 (v00 ACPIAM) ACPI: RSDT 0xbdd90000 00048 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: FACP 0xbdd90200 00084 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: DSDT 0xbdd905c0 072D3 (v01 1ADTS 1ADTS012 00000012 INTL 20051117) ACPI: FACS 0xbdd9e000 00040 ACPI: APIC 0xbdd90390 0006C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: MCFG 0xbdd90400 0003C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: SLIC 0xbdd90440 00176 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: OEMB 0xbdd9e040 00072 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) ACPI: HPET 0xbdd9a5c0 00038 (v01 MSI_NB OEMHPET 20091013 MSFT 00000097) ACPI: ASF! 0xbdd9a600 00099 (v32 LEGEND I865PASF 00000001 INTL 20051117) ACPI: GSCI 0xbdd9e0c0 02024 (v01 MSI_NB GMCHSCI 20091013 MSFT 00000097) ACPI: SSDT 0xbdda0a50 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> random: kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device io: null: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bdd00000 (3) failed ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI: SSDT 0xbdda04b0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) cpu1: on acpi0 ACPI: SSDT 0xbdda0420 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xdffff pcib0: decoding 3 range 0xbde00000-0xdfffffff pcib0: decoding 3 range 0xf0000000-0xfed8ffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2a40, revid=0x07 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2a42, revid=0x07 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xfd800000, size 22, enabled pcib0: allocated type 3 (0xfd800000-0xfdbfffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0xb400, size 3, enabled pcib0: allocated type 4 (0xb400-0xb407) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2a43, revid=0x07 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfdd00000, size 20, enabled pcib0: allocated type 3 (0xfdd00000-0xfddfffff) for rid 10 of pci0:0:2:1 found-> vendor=0x8086, dev=0x2937, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2938, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:26:1 pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x293c, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdefec00, size 10, enabled pcib0: allocated type 3 (0xfdefec00-0xfdefefff) for rid 10 of pci0:0:26:7 pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293e, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdef8000, size 14, enabled pcib0: allocated type 3 (0xfdef8000-0xfdefbfff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2940, revid=0x03 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2942, revid=0x03 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2946, revid=0x03 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2934, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled pcib0: allocated type 4 (0xc000-0xc01f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2935, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2936, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x293a, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdeff000, size 10, enabled pcib0: allocated type 3 (0xfdeff000-0xfdeff3ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0x93 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2919, revid=0x03 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2929, revid=0x03 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xcc00, size 3, enabled pcib0: allocated type 4 (0xcc00-0xcc07) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0xc880, size 2, enabled pcib0: allocated type 4 (0xc880-0xc883) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0xc800, size 3, enabled pcib0: allocated type 4 (0xc800-0xc807) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0xc480, size 2, enabled pcib0: allocated type 4 (0xc480-0xc483) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled pcib0: allocated type 4 (0xc400-0xc41f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xfdeff800, size 11, enabled pcib0: allocated type 3 (0xfdeff800-0xfdefffff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x2930, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfdeff400, size 8, enabled pcib0: allocated type 3 (0xfdeff400-0xfdeff4ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xb400-0xb407 mem 0xfd800000-0xfdbfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory vgapci1: mem 0xfdd00000-0xfddfffff at device 2.1 on pci0 pci0: at device 26.0 (no driver attached) pci0: at device 26.1 (no driver attached) pci0: at device 26.7 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 pcib0: allocated type 3 (0xfdf00000-0xfdffffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xf9f00000-0xf9ffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xfdf00000-0xfdffffff pcib1: prefetched decode 0xf9f00000-0xf9ffffff pci2: on pcib1 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib1: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 map[18]: type Memory, range 64, base 0xfdfff000, size 12, enabled pcib1: allocated memory range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 map[20]: type Prefetchable Memory, range 64, base 0xf9ff0000, size 16, enabled pcib1: allocated prefetch range (0xf9ff0000-0xf9ffffff) for rid 20 of pci0:2:0:0 pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 pcib0: allocated type 3 (0xfe000000-0xfeafffff) for rid 20 of pcib2 pcib0: allocated type 3 (0xfa000000-0xfcffffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 3 pcib2: subordinate bus 4 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfe000000-0xfeafffff pcib2: prefetched decode 0xfa000000-0xfcffffff pci3: on pcib2 pci3: domain=0, physical bus=3 pcib3: irq 19 at device 28.3 on pci0 pcib0: allocated type 3 (0xfeb00000-0xfebfffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 5 pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pci5: on pcib3 pci5: domain=0, physical bus=5 found-> vendor=0x168c, dev=0x001c, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfebf0000, size 16, enabled pcib3: allocated memory range (0xfebf0000-0xfebfffff) for rid 10 of pci0:5:0:0 pcib3: matched entry for 5.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 pci5: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 1 pcib4: subordinate bus 1 pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib4 pci1: domain=0, physical bus=1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfdeff800-0xfdefffff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 ahci0: using IRQ 256 for MSI ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 4ports ahci0: Caps2: ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: at channel 4 on ahci0 ahcich4: Caps: ahcich5: at channel 5 on ahci0 ahcich5: Caps: pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_tz0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 51 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 52 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 53 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) hpet0: t3: irqs 0x00f01000 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi0: wakeup code va 0xffffff80d4544000 pa 0x4000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000123 ahcich0: AHCI reset: device found ahcich1: AHCI reset... ahcich1: SATA offline status=00000004 ahcich1: AHCI reset: device not found ahcich4: AHCI reset... ahcich4: SATA offline status=00000004 ahcich4: AHCI reset: device not found ahcich5: AHCI reset... ahcich5: SATA connect time=900us status=00000113 ahcich5: AHCI reset: device found ahcich5: AHCI reset: device ready after 0ms (aprobe1:ahcich5:0:0:0): SIGNATURE: eb14 acpi_acad0: acline initialization start battery0: battery initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ahcich5: SNTF 0x0001 ahcich0: AHCI reset: device ready after 100ms (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 SATA 2.x device GEOM: new disk cd0 pass0: Serial Number 5YX0J5YD (cd0:ahcich5:0:0:0): SCSI status error (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error (cd0:ahcich5:0:0:0): SCSI status: Check Condition (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) (cd0:ahcich5:0:0:0): Error 6, Unretryable error cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number 30651780 1165921Q111 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 - tray open pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich5 bus 0 scbus3 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number 30651780 1165921Q111 pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 (cd0:ahcich5:0:0:0): SCSI status error (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error (cd0:ahcich5:0:0:0): SCSI status: Check Condition (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) (cd0:ahcich5:0:0:0): Error 6, Unretryable error ada0: ATA-8 SATA 2.x device ada0: Serial Number 5YX0J5YD ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 TSC timecounter disabled: C3 enabled. Timecounter "TSC" frequency 2161296371 Hz quality -1000 (cd0:ahcich5:0:0:0): SCSI status error (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error (cd0:ahcich5:0:0:0): SCSI status: Check Condition (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) (cd0:ahcich5:0:battery0: battery initialization done, tried 1 times 0:0): Error 6, Unretryable error (cd0:ahcich5:0:0:0): SCSI status error (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error (cd0:ahcich5:0:0:0): SCSI status: Check Condition (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) (cd0:ahcich5:0:0:0): Error 6, Unretryable error GEOM: new disk ada0 GEOM: ada0s3: media size does not match label. Trying to mount root from ufs:/dev/ada0s2a [rw,noatime]... start_init: trying /sbin/init ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 (cd0:ahcich5:0:0:0): SCSI status error (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error (cd0:ahcich5:0:0:0): SCSI status: Check Condition (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) (cd0:ahcich5:0:0:0): Error 6, Unretryable error tap0: bpf attached tap0: Ethernet address: 00:bd:0b:07:00:00 pci0: driver added found-> vendor=0x8086, dev=0x2937, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 pci0:0:26:0: reprobing on driver added found-> vendor=0x8086, dev=0x2938, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=21 pci0:0:26:1: reprobing on driver added found-> vendor=0x8086, dev=0x293c, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 2 supports D0 D3 current D0 pci0:0:26:7: reprobing on driver added found-> vendor=0x8086, dev=0x293e, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=22 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:27:0: reprobing on driver added found-> vendor=0x8086, dev=0x2934, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 pci0:0:29:0: reprobing on driver added found-> vendor=0x8086, dev=0x2935, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=19 pci0:0:29:1: reprobing on driver added found-> vendor=0x8086, dev=0x2936, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:29:2: reprobing on driver added found-> vendor=0x8086, dev=0x293a, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 powerspec 2 supports D0 D3 current D0 pci0:0:29:7: reprobing on driver added found-> vendor=0x8086, dev=0x2930, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added pci1: driver added pci2: driver added found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 pci0:2:0:0: reprobing on driver added re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xf9ff0000-0xf9ffffff irq 16 at device 0.0 on pci2 re0: MSI count : 1 re0: MSI-X count : 2 re0: attempting to allocate 1 MSI-X vectors (2 supported) msi: routing MSI-X IRQ 257 to local APIC 0 vector 55 re0: using IRQ 257 for MSI-X re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: bpf attached re0: Ethernet address: 00:24:21:61:e0:20 pci3: driver added pci5: driver added found-> vendor=0x168c, dev=0x001c, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 pci0:5:0:0: reprobing on driver added pci0: driver added found-> vendor=0x8086, dev=0x2937, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 pci0:0:26:0: reprobing on driver added found-> vendor=0x8086, dev=0x2938, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=21 pci0:0:26:1: reprobing on driver added found-> vendor=0x8086, dev=0x293c, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 2 supports D0 D3 current D0 pci0:0:26:7: reprobing on driver added found-> vendor=0x8086, dev=0x293e, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=22 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:27:0: reprobing on driver added found-> vendor=0x8086, dev=0x2934, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 pci0:0:29:0: reprobing on driver added found-> vendor=0x8086, dev=0x2935, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=19 pci0:0:29:1: reprobing on driver added found-> vendor=0x8086, dev=0x2936, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:29:2: reprobing on driver added found-> vendor=0x8086, dev=0x293a, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 powerspec 2 supports D0 D3 current D0 pci0:0:29:7: reprobing on driver added found-> vendor=0x8086, dev=0x2930, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added pci1: driver added pci2: driver added pci3: driver added pci5: driver added found-> vendor=0x168c, dev=0x001c, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 pci0:5:0:0: reprobing on driver added ath0: mem 0xfebf0000-0xfebfffff irq 19 at device 0.0 on pci5 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 56 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: AR2425 mac 14.2 RF5424 phy 7.0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search crypto: cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 GEOM_ELI: Device ada0s3.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software pci0: driver added found-> vendor=0x8086, dev=0x2937, revid=0x03 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 pci0:0:26:0: reprobing on driver added found-> vendor=0x8086, dev=0x2938, revid=0x03 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=21 pci0:0:26:1: reprobing on driver added found-> vendor=0x8086, dev=0x293c, revid=0x03 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 2 supports D0 D3 current D0 pci0:0:26:7: reprobing on driver added found-> vendor=0x8086, dev=0x293e, revid=0x03 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=22 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:27:0: reprobing on driver added found-> vendor=0x8086, dev=0x2934, revid=0x03 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 pci0:0:29:0: reprobing on driver added found-> vendor=0x8086, dev=0x2935, revid=0x03 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=19 pci0:0:29:1: reprobing on driver added found-> vendor=0x8086, dev=0x2936, revid=0x03 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:29:2: reprobing on driver added found-> vendor=0x8086, dev=0x293a, revid=0x03 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=23 powerspec 2 supports D0 D3 current D0 pci0:0:29:7: reprobing on driver added found-> vendor=0x8086, dev=0x2930, revid=0x03 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added pci1: driver added pci2: driver added pci3: driver added pci5: driver added est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 p4tcc1: on cpu1 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 coretemp0: on cpu0 coretemp0: Setting TjMax=100 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est0 attach returned 6 coretemp1: on cpu1 coretemp1: Setting TjMax=100 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b device_attach: est1 attach returned 6 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 17:19:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0FC6106567A for ; Sat, 11 Feb 2012 17:19:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 94CA78FC22 for ; Sat, 11 Feb 2012 17:19:54 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CAB9.dip.t-dialin.net [87.150.202.185]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 71427844007; Sat, 11 Feb 2012 18:19:38 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id BFA682D6A; Sat, 11 Feb 2012 18:19:35 +0100 (CET) Date: Sat, 11 Feb 2012 18:19:35 +0100 From: Alexander Leidinger To: "Bjoern A. Zeeb" Message-ID: <20120211181935.00003fac@unknown> In-Reply-To: <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 71427844007.A0B4C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.118, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.11, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329585581.05418@+MQ3euYWPtZBLs7ueUGORQ X-EBL-Spam-Status: No Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 17:19:56 -0000 On Fri, 10 Feb 2012 16:15:00 +0000 "Bjoern A. Zeeb" wrote: > > On 10. Feb 2012, at 13:56 , Alexander Leidinger wrote: > > > Hi, > > > > during some big discussions in the last monts on various lists, one > > of the problems was that some people would like to use > > freebsd-update but can't as they are using a custom kernel. With > > all the kernel modules we provide, the need for a custom kernel > > should be small, but on the other hand, we do not provide a small > > kernel-skeleton where you can load just the modules you need. > > > > This should be easy to change. As a first step I took the generic > > kernel and removed all devices which are available as modules, e.g. > > the USB section consists now only of the USB_DEBUG option (so that > > the module is build like with the current generic kernel). I also > > removed some storage drivers which are not available as a module. > > The rationale is, that I can not remove CAM from the kernel config > > if I let those drivers inside (if those drivers are important > > enough, someone will probably fix the problem and add the missing > > pieces to generate a module). > > And you completely seem to have missed the discussion about a device > ID DB and loader being able to probe and load them for you? This is how I would like FreeBSD to behave, but this is not what I try to do here. Something like this is not around the corner, a barebones config file can be done in minutes (if the requirements are known). And a config file is also much more easy to MFC (and as such addresses the immediate needs of those which will not change the major version for some years from now) than a device ID DB and the corresponding changes in the kernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 17:26:54 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE0F1065670; Sat, 11 Feb 2012 17:26:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 71A6C8FC14; Sat, 11 Feb 2012 17:26:54 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CAB9.dip.t-dialin.net [87.150.202.185]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id BF49D844007; Sat, 11 Feb 2012 18:26:41 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id F419E2D6C; Sat, 11 Feb 2012 18:26:38 +0100 (CET) Date: Sat, 11 Feb 2012 18:26:38 +0100 From: Alexander Leidinger To: Adrian Chadd Message-ID: <20120211182638.00000abb@unknown> In-Reply-To: References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: BF49D844007.A0508 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.223, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.21, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329586002.17619@XoeNij12Cb6uTCKeu+9dRA X-EBL-Spam-Status: No Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 17:26:54 -0000 On Fri, 10 Feb 2012 12:13:53 -0800 Adrian Chadd wrote: > I've done this a few times. Me too, and others probably too, so let's end the waste of time and provide one officially. > The /boot/loader takes a _long_ time to suck in the 25 odd modules my > eeepc requires to load a completely modular kernel. It takes a _very > long_ time to suck these in over USB. I suggest to compile a monolithic kernel for your eeepc (or update to a FreeBSD which is able to load klds from rc.conf). > It's a great idea and I think we should start down this path in the > 10-CURRENT trajectory but those load times need to be tweaked if > possible. The result will be committed to -current first, it's just that the audience for this change is more likely to read this list than current@, hackers@ or arch@. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 17:33:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AF2B1065670 for ; Sat, 11 Feb 2012 17:33:25 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id D06528FC0C for ; Sat, 11 Feb 2012 17:33:24 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CAB9.dip.t-dialin.net [87.150.202.185]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 40BE7844007; Sat, 11 Feb 2012 18:33:12 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id 84D3F2D6E; Sat, 11 Feb 2012 18:33:09 +0100 (CET) Date: Sat, 11 Feb 2012 18:33:08 +0100 From: Alexander Leidinger To: Thierry Thomas Message-ID: <20120211183308.00007579@unknown> In-Reply-To: <20120211124041.GF32360@graf.pompo.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 40BE7844007.A0807 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.229, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.37, TW_KB 0.08, TW_TK 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329586392.51393@fWGcq1epnLMB7UOZoAbnFA X-EBL-Spam-Status: No Cc: stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 17:33:25 -0000 On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas wrote: > Le ven 10 f=E9v 12 =E0 14:56:04 +0100, Alexander Leidinger > =E9crivait=A0: > > Hi, >=20 > Hello, >=20 > > The question is, is this enough? Or asked differently, why are you > > compiling a custom kernel in a production environment (so I rule out > > debug options zhich are not enabled in GENERIC)? Are there options > > which you add which you can not add as a module (SW_WATCHDOG comes > > to my mind)? If yes, which ones and how important are they for you? >=20 > Not very important, but since you are asking, is there another place > to put options to atkbd and sc, like these ones: >=20 > options ATKBD_DFLT_KEYMAP # specify the built-in keymap > makeoptions ATKBD_DFLT_KEYMAP=3Dfr.iso.acc >=20 > options SC_KERNEL_CONS_ATTR=3D(FG_LIGHTGREEN|BG_BLACK) > options SC_KERNEL_CONS_REV_ATTR=3D(FG_WHITE|BG_GREEN) > options SC_NORM_REV_ATTR=3D(FG_WHITE|BG_BLUE) No, there is no other way to add the keymap to the kernel directly (if you want to have it working correctly in single-user mode) instead of loading it with rc.conf. I do not know if you can change the colors with vidcontrol, but if you can, I do not expect this to be a problem for single-user mode. Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 17:36:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8FCE106564A for ; Sat, 11 Feb 2012 17:36:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF718FC16 for ; Sat, 11 Feb 2012 17:36:34 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CAB9.dip.t-dialin.net [87.150.202.185]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1EC13844007; Sat, 11 Feb 2012 18:36:18 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id 60E732D6F; Sat, 11 Feb 2012 18:36:15 +0100 (CET) Date: Sat, 11 Feb 2012 18:36:14 +0100 From: Alexander Leidinger To: perryh@pluto.rain.com Message-ID: <20120211183614.00006079@unknown> In-Reply-To: <4f368a34.rIGc5BVL5Vu8OIjl%perryh@pluto.rain.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <5B8B698D-6DC0-4334-8617-4EDEC7973D9D@lists.zabbadoz.net> <4f368a34.rIGc5BVL5Vu8OIjl%perryh@pluto.rain.com> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1EC13844007.A2857 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.366, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.36, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329586582.07739@FO29OIoAMK6PMRaWxZj7gA X-EBL-Spam-Status: No Cc: bzeeb-lists@lists.zabbadoz.net, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 17:36:34 -0000 On Sat, 11 Feb 2012 07:33:08 -0800 perryh@pluto.rain.com wrote: > "Bjoern A. Zeeb" wrote: > > > various parts of the network stack being loadable, which is not > > as easy as it sounds, especially making them unloadable again > > currently ... > > Seems to me unloadability does not matter to the case under > discussion, which is modularizing the kernel to reduce the Correct. > number of cases in which a custom kernel is needed. How much > real functional difference is there between "built in" and > "loaded permanently at boot"? For what I want to achieve: nearly zero compared to GENERIC (there will be differences, more when I present the result for discussion). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 18:43:29 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34288106564A for ; Sat, 11 Feb 2012 18:43:29 +0000 (UTC) (envelope-from PETER@PEAN.ORG) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) by mx1.freebsd.org (Postfix) with ESMTP id E14DC8FC14 for ; Sat, 11 Feb 2012 18:43:28 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 57A0ED416 for ; Sat, 11 Feb 2012 19:15:51 +0100 (CET) X-SENDER-IP: [85.225.6.148] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcdAP+vNk9V4QaUPGdsb2JhbAAMOLAIAQEBATeEJg4WLQnAHItpIAcEBwICGwEDCAEjAQIBgxcFBoEWJoI6YwSNDogkkmU X-IronPort-AV: E=Sophos;i="4.73,403,1325458800"; d="scan'208";a="267421735" Received: from c-9406e155.166-7-64736c14.cust.bredbandsbolaget.se (HELO [172.25.0.25]) ([85.225.6.148]) by ipb1.telenor.se with ESMTP; 11 Feb 2012 19:15:51 +0100 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Feb 2012 19:15:50 +0100 Message-Id: To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: Subject: Disable DMA. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 18:43:29 -0000 Hi, In FreeBSD 8 i used the loader-variable hw.ata.ata_dma=3D0 to get my = computer boot on a CF card. But in FreeBSD 9.0 it doesn't seem to work. Could it be another variable or = is it something else that doesn't work in 9? The machine boots up the installer when the CF-card is not present = but when it is present it stops right=20 after the "Timecounter" stuff. -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 11 20:34:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 915541065672 for ; Sat, 11 Feb 2012 20:34:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF3E8FC12 for ; Sat, 11 Feb 2012 20:34:37 +0000 (UTC) Received: by eaan10 with SMTP id n10so1497965eaa.13 for ; Sat, 11 Feb 2012 12:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pwI+9MR5piHJ1IsZ67r/KpDuqWT4JOTvlsNS1kzvDTM=; b=j+113RLb15y0kv7HcBpL56Eu1NIvabDvYcB13SlUA0PAW6ZPrrGY/JKEqwU/HbyVYc Mq6+51Jpuk3OFC0SJhD+bmSaAlKVT7U0CzI5nMhQTXwBZ/mzTQZRO1N9J4cUi1voO1Pn e4BSYPAxp9qM1oNbmnFKYlWhHIfdcrVSbZQWE= Received: by 10.14.135.140 with SMTP id u12mr3427469eei.73.1328992477010; Sat, 11 Feb 2012 12:34:37 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a58sm39601202eeb.8.2012.02.11.12.34.35 (version=SSLv3 cipher=OTHER); Sat, 11 Feb 2012 12:34:36 -0800 (PST) Sender: Alexander Motin Message-ID: <4F36D0DA.4050208@FreeBSD.org> Date: Sat, 11 Feb 2012 22:34:34 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Disable DMA. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Feb 2012 20:34:38 -0000 On 02/11/12 20:15, Peter Ankerstål wrote: > In FreeBSD 8 i used the loader-variable hw.ata.ata_dma=0 to get my computer boot on a CF card. But > in FreeBSD 9.0 it doesn't seem to work. Could it be another variable or is it something else that doesn't work > in 9? The machine boots up the installer when the CF-card is not present but when it is present it stops right > after the "Timecounter" stuff. On 9.0 you can to it with hint.ata.X.mode=PIO4 , where X is a bus number. In recent 8/9-STABLE I've also resurrected hw.ata.ata_dma=0. -- Alexander Motin