From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 09:54:01 2009 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 54B441065673 for ; Sun, 7 Jun 2009 09:54:01 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com (web.hostmailing.com [200.110.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 922148FC12 for ; Sun, 7 Jun 2009 09:54:00 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by web.hostmailing.com with esmtpa (Exim 4.63) (envelope-from ) id 1MDF3h-0001cz-E9 for freebsd-stable@freebsd.org; Sun, 07 Jun 2009 06:52:57 -0300 Date: Sun, 7 Jun 2009 06:52:57 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: <111abbfc08141ad9348f67a4523f8272@www.hostmailing.com> X-Priority: 3 X-Mailer: wh4535 [version 3.1] MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Modbus I/O Module - Cost Effective X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 09:54:01 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 12:48:00 2009 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 2FEA1106566C; Sun, 7 Jun 2009 12:48:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id EFEC48FC17; Sun, 7 Jun 2009 12:47:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n57ClvwK029160; Sun, 7 Jun 2009 08:47:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n57ClvM6099224; Sun, 7 Jun 2009 08:47:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id DB3BE1B5060; Sun, 7 Jun 2009 08:47:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090607124756.DB3BE1B5060@freebsd-stable.sentex.ca> Date: Sun, 7 Jun 2009 08:47:56 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 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, 07 Jun 2009 12:48:01 -0000 TB --- 2009-06-07 11:26:01 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 11:26:01 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-07 11:26:01 - cleaning the object tree TB --- 2009-06-07 11:26:26 - cvsupping the source tree TB --- 2009-06-07 11:26:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-07 11:26:37 - building world TB --- 2009-06-07 11:26:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 11:26:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 11:26:37 - TARGET=pc98 TB --- 2009-06-07 11:26:37 - TARGET_ARCH=i386 TB --- 2009-06-07 11:26:37 - TZ=UTC TB --- 2009-06-07 11:26:37 - __MAKE_CONF=/dev/null TB --- 2009-06-07 11:26:37 - cd /src TB --- 2009-06-07 11:26:37 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 11:26:39 UTC 2009 >>> 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 Jun 7 12:33:51 UTC 2009 TB --- 2009-06-07 12:33:51 - generating LINT kernel config TB --- 2009-06-07 12:33:51 - cd /src/sys/pc98/conf TB --- 2009-06-07 12:33:51 - /usr/bin/make -B LINT TB --- 2009-06-07 12:33:51 - building LINT kernel TB --- 2009-06-07 12:33:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:33:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:33:51 - TARGET=pc98 TB --- 2009-06-07 12:33:51 - TARGET_ARCH=i386 TB --- 2009-06-07 12:33:51 - TZ=UTC TB --- 2009-06-07 12:33:51 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:33:51 - cd /src TB --- 2009-06-07 12:33:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 12:33:51 UTC 2009 >>> 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 [...] rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel hwpmc_intel.o(.text+0x1c6): In function `pmc_intel_initialize': : undefined reference to `pmc_core_initialize' hwpmc_intel.o(.text+0x49): In function `pmc_intel_finalize': : undefined reference to `pmc_core_finalize' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 12:47:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 12:47:56 - ERROR: failed to build lint kernel TB --- 2009-06-07 12:47:56 - 3963.74 user 410.00 system 4914.68 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 13:44:01 2009 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 75A501065673; Sun, 7 Jun 2009 13:44:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 360178FC12; Sun, 7 Jun 2009 13:44:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n57DhxnQ035178; Sun, 7 Jun 2009 09:43:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n57DhxVM027760; Sun, 7 Jun 2009 09:43:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 63FCE1B5060; Sun, 7 Jun 2009 09:43:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090607134359.63FCE1B5060@freebsd-stable.sentex.ca> Date: Sun, 7 Jun 2009 09:43:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 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, 07 Jun 2009 13:44:02 -0000 TB --- 2009-06-07 12:08:02 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 12:08:02 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-07 12:08:02 - cleaning the object tree TB --- 2009-06-07 12:08:22 - cvsupping the source tree TB --- 2009-06-07 12:08:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-07 12:08:35 - building world TB --- 2009-06-07 12:08:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:08:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:08:35 - TARGET=ia64 TB --- 2009-06-07 12:08:35 - TARGET_ARCH=ia64 TB --- 2009-06-07 12:08:35 - TZ=UTC TB --- 2009-06-07 12:08:35 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:08:35 - cd /src TB --- 2009-06-07 12:08:35 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 12:08:36 UTC 2009 >>> 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 Jun 7 13:37:38 UTC 2009 TB --- 2009-06-07 13:37:38 - generating LINT kernel config TB --- 2009-06-07 13:37:38 - cd /src/sys/ia64/conf TB --- 2009-06-07 13:37:38 - /usr/bin/make -B LINT TB --- 2009-06-07 13:37:38 - building LINT kernel TB --- 2009-06-07 13:37:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:37:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:37:38 - TARGET=ia64 TB --- 2009-06-07 13:37:38 - TARGET_ARCH=ia64 TB --- 2009-06-07 13:37:38 - TZ=UTC TB --- 2009-06-07 13:37:38 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:37:38 - cd /src TB --- 2009-06-07 13:37:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 13:37:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hme/if_hme.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 13:43:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 13:43:58 - ERROR: failed to build lint kernel TB --- 2009-06-07 13:43:58 - 4851.80 user 386.43 system 5756.63 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 14:01:43 2009 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 681A5106564A; Sun, 7 Jun 2009 14:01:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 297048FC15; Sun, 7 Jun 2009 14:01:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n57E1eW3054616; Sun, 7 Jun 2009 10:01:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n57E1e6T013946; Sun, 7 Jun 2009 10:01:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 6D2C81B5060; Sun, 7 Jun 2009 10:01:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090607140140.6D2C81B5060@freebsd-stable.sentex.ca> Date: Sun, 7 Jun 2009 10:01:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 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, 07 Jun 2009 14:01:44 -0000 TB --- 2009-06-07 12:47:57 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 12:47:57 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-06-07 12:47:57 - cleaning the object tree TB --- 2009-06-07 12:48:24 - cvsupping the source tree TB --- 2009-06-07 12:48:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-06-07 12:48:35 - building world TB --- 2009-06-07 12:48:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 12:48:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 12:48:35 - TARGET=powerpc TB --- 2009-06-07 12:48:35 - TARGET_ARCH=powerpc TB --- 2009-06-07 12:48:35 - TZ=UTC TB --- 2009-06-07 12:48:35 - __MAKE_CONF=/dev/null TB --- 2009-06-07 12:48:35 - cd /src TB --- 2009-06-07 12:48:35 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 12:48:36 UTC 2009 >>> 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 Jun 7 13:57:26 UTC 2009 TB --- 2009-06-07 13:57:26 - generating LINT kernel config TB --- 2009-06-07 13:57:26 - cd /src/sys/powerpc/conf TB --- 2009-06-07 13:57:26 - /usr/bin/make -B LINT TB --- 2009-06-07 13:57:26 - building LINT kernel TB --- 2009-06-07 13:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:57:26 - TARGET=powerpc TB --- 2009-06-07 13:57:26 - TARGET_ARCH=powerpc TB --- 2009-06-07 13:57:26 - TZ=UTC TB --- 2009-06-07 13:57:26 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:57:26 - cd /src TB --- 2009-06-07 13:57:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 13:57:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hme/if_hme.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 14:01:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 14:01:40 - ERROR: failed to build lint kernel TB --- 2009-06-07 14:01:40 - 3591.21 user 361.16 system 4423.28 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 14:49:30 2009 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 D91CD106566B; Sun, 7 Jun 2009 14:49:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3D88FC17; Sun, 7 Jun 2009 14:49:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n57EnSR0044862; Sun, 7 Jun 2009 10:49:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n57EnSEI061240; Sun, 7 Jun 2009 10:49:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 8656A1B5060; Sun, 7 Jun 2009 10:49:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090607144928.8656A1B5060@freebsd-stable.sentex.ca> Date: Sun, 7 Jun 2009 10:49:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on sparc64/sparc64 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, 07 Jun 2009 14:49:31 -0000 TB --- 2009-06-07 13:43:59 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-07 13:43:59 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-06-07 13:43:59 - cleaning the object tree TB --- 2009-06-07 13:44:22 - cvsupping the source tree TB --- 2009-06-07 13:44:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-06-07 13:44:33 - building world TB --- 2009-06-07 13:44:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 13:44:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 13:44:33 - TARGET=sparc64 TB --- 2009-06-07 13:44:33 - TARGET_ARCH=sparc64 TB --- 2009-06-07 13:44:33 - TZ=UTC TB --- 2009-06-07 13:44:33 - __MAKE_CONF=/dev/null TB --- 2009-06-07 13:44:33 - cd /src TB --- 2009-06-07 13:44:33 - /usr/bin/make -B buildworld >>> World build started on Sun Jun 7 13:44:34 UTC 2009 >>> 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 Jun 7 14:45:00 UTC 2009 TB --- 2009-06-07 14:45:00 - generating LINT kernel config TB --- 2009-06-07 14:45:00 - cd /src/sys/sparc64/conf TB --- 2009-06-07 14:45:00 - /usr/bin/make -B LINT TB --- 2009-06-07 14:45:00 - building LINT kernel TB --- 2009-06-07 14:45:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-07 14:45:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-07 14:45:00 - TARGET=sparc64 TB --- 2009-06-07 14:45:00 - TARGET_ARCH=sparc64 TB --- 2009-06-07 14:45:00 - TZ=UTC TB --- 2009-06-07 14:45:00 - __MAKE_CONF=/dev/null TB --- 2009-06-07 14:45:00 - cd /src TB --- 2009-06-07 14:45:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 7 14:45:00 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hme/if_hme_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hme/if_hme_sbus.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_logging.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/dev/hwpmc/hwpmc_mod.c cc1: warnings being treated as errors /src/sys/dev/hwpmc/hwpmc_mod.c: In function 'pmc_process_interrupt': /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: implicit declaration of function 'PMC_TRAPFRAME_TO_PC' /src/sys/dev/hwpmc/hwpmc_mod.c:3895: warning: nested extern declaration of 'PMC_TRAPFRAME_TO_PC' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-07 14:49:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-07 14:49:28 - ERROR: failed to build lint kernel TB --- 2009-06-07 14:49:28 - 3361.62 user 355.89 system 3928.90 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 17:04:44 2009 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 790EF106566C for ; Sun, 7 Jun 2009 17:04:44 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id 387238FC20 for ; Sun, 7 Jun 2009 17:04:44 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 07E23153467; Sun, 7 Jun 2009 18:48:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bom5ZGVfBZu7; Sun, 7 Jun 2009 18:48:57 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id B7797153433; Sun, 7 Jun 2009 18:48:56 +0200 (CEST) Message-ID: <4A2BEF7D.5070808@withagen.nl> Date: Sun, 07 Jun 2009 18:49:01 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS isntall requirements 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, 07 Jun 2009 17:04:44 -0000 Dmitry Morozovsky wrote: > On Fri, 5 Jun 2009, Kirk Strauser wrote: > > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > KS> > Hi, > KS> > > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib > KS> > ===> sys/boot/i386/libi386 (install) > KS> > ===> sys/boot/i386/libfirewire (install) > KS> > ===> sys/boot/i386/loader (install) > KS> > make: don't know how to make > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop > KS> > KS> ISTR that the build was temporarily broken several days ago. > > > Well, according to http://tinderbox.freebsd.org/ it does not ;) I'm not at all familiar with the intrinsics of the tinderbox setup. But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? Because that is required to have the trouble surface. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 17:29:59 2009 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 155D71065686 for ; Sun, 7 Jun 2009 17:29:59 +0000 (UTC) (envelope-from allnetgroup@yahoo.com) Received: from web34307.mail.mud.yahoo.com (web34307.mail.mud.yahoo.com [66.163.178.139]) by mx1.freebsd.org (Postfix) with SMTP id C472A8FC23 for ; Sun, 7 Jun 2009 17:29:58 +0000 (UTC) (envelope-from allnetgroup@yahoo.com) Received: (qmail 44191 invoked by uid 60001); 7 Jun 2009 17:29:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244395798; bh=MmorXEAH2iVzZrwZoqHLw3ENJufR5z9o4yzsP/vS+Sw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=juGX/dUBjEraGqBaN3Ck9KVdHma9n1SwaiZcBoszfDsKmARdQEIB036p0VrSIi9IPadTqafTj4qBaYpD47JkRrgL55Qpli87uTBQMvixkrtGrTGfhKW6vhmPyr5VTxlzGALoyBdVtn365QMvLkAGMeV1QVqrTAtJfVHgsBYVkD8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SBo9fHMGGlrGOcmg2sWLYVWIwMZRPPoyZCwfL3zBJy8p0JHCenSOo81xLc3RUTOg5dZ4wo5JuntcNiXaK5LSzNwvQbQnczoREev8zuhHth5CZFNlW1GoDh9Y4dr4tIQyOy317keAfnfHnsmY3rvWSEbF7k9WaHKGOsVQM4IhPQg=; Message-ID: <143776.42704.qm@web34307.mail.mud.yahoo.com> X-YMail-OSG: LJFz8B4VM1m2JDaLywhSvBC2KZO9dsQWfwLo1HQW9Q99tWeFMfO5m4oC.Y2GUxsYl__awoHL_HSJu8xEKpaHwt92NbgBv9cUdNJ_e1FAy1l8Dul1kZFZELdFLRC_qQbf8zsB7CoAbqeKrujHoqVQlSByQ.26rhfORGCAkQF.nP3CHK5k35zHk5m46KBK5JTG0_qE6Uox7XVeB_Rxi90fu6lSH6Xr9PqxJJiWO40QdswTEYtr1UKTFsZthMP5EKZ6rGP6nrTMLvwzMLNYzEVeWjfOi.QrtURrPgO9r.5lNrbSN_JblKLjxLIjeyyxMR583w-- Received: from [81.2.197.55] by web34307.mail.mud.yahoo.com via HTTP; Sun, 07 Jun 2009 10:29:57 PDT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Sun, 7 Jun 2009 10:29:57 -0700 (PDT) From: AES To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: I need to add commands that starts every time at system boot. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: allnetgroup@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 17:30:02 -0000 I need to add commands that starts every time=A0at system boot. =A0 which script is the one that starts first and where can I find it?=0A=0A=0A= From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 18:13:18 2009 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 8DFCC106564A for ; Sun, 7 Jun 2009 18:13:18 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF188FC0C for ; Sun, 7 Jun 2009 18:13:11 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by gxk3 with SMTP id 3so3825914gxk.19 for ; Sun, 07 Jun 2009 11:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LbohaoFQXOoTE+BY8v2iPB3ekvyN3zRHMVTLoSD1MPU=; b=r50HNL4Uy6/UmNiDJ377U67C6nG+QQ7KzZYSRQoPPMEHd/4ma7h0CsC0WLpXG75G2x bIi7L3UfmR3HsxcSqZpIYGonBNvmPsSxikDnKTFnofBBTESQBAOUtvnPNLxILna7W4KX n8t6g+dRc/22OfI8VZ18dMNvE4XVyTU5x5ihQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pfVWl05tPc4S+UqeY0M/aUaPNuccrZjEigNpSUwlW62qz0/AmLg3avSvFu3EpqsI/h mQThMpNMz5hwDKf8K2ZRRI2Pw1JsdZoia47FhVLhazb8GwNHVH0eH1kRr+h57s+Sz2qD mt775Vce0xYzyC9elWNfseaIv4pWjshBwfdrI= MIME-Version: 1.0 Received: by 10.150.49.4 with SMTP id w4mr10808318ybw.71.1244397073517; Sun, 07 Jun 2009 10:51:13 -0700 (PDT) In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> Date: Sun, 7 Jun 2009 19:51:13 +0200 Message-ID: From: Claus Guttesen To: allnetgroup@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: I need to add commands that starts every time at system boot. 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, 07 Jun 2009 18:13:18 -0000 > I need to add commands that starts every time=A0at system boot. > which script is the one that starts first and where can I find it? You can also try to add something like this to root's crontab: @reboot /sbin/mount -a --=20 regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 18:30:38 2009 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 A80EA10656A5 for ; Sun, 7 Jun 2009 18:30:38 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1848FC14 for ; Sun, 7 Jun 2009 18:30:38 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 72DB5170B3D; Sun, 7 Jun 2009 08:30:37 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 1CA9F153882; Sun, 7 Jun 2009 08:30:37 -1000 (HST) Date: Sun, 7 Jun 2009 08:30:36 -1000 From: Clifton Royston To: AES Message-ID: <20090607183035.GA22240@lava.net> Mail-Followup-To: AES , freebsd-stable@freebsd.org References: <143776.42704.qm@web34307.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: I need to add commands that starts every time at system boot. 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, 07 Jun 2009 18:30:39 -0000 On Sun, Jun 07, 2009 at 10:29:57AM -0700, AES wrote: > I need to add commands that starts every time at system boot. >   > which script is the one that starts first and where can I find it? You should add a script of your own to the directory /usr/local/etc/rc.d, and have it check the first parameter to see under what circumstances it is being invoked. If the first parameter is "start", then the system is being started, or at least you are requesting that your script be run as if it were starting. I strongly recommend against adding anything to the /etc/rc script itself. If you feel you just *can't* do it via a script in /usr/local/etc/rc.d, which is the better way, add a script called /etc/rc.local and that will be run after all the other start-up steps. "man rc" for more information, man "rcorder" if you need to control the order in which your script runs relative to other startup scripts. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 18:54:00 2009 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 1FE411065677 for ; Sun, 7 Jun 2009 18:54:00 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 908238FC17 for ; Sun, 7 Jun 2009 18:53:59 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by ewy8 with SMTP id 8so3534779ewy.43 for ; Sun, 07 Jun 2009 11:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KTwJpSj4SO8P75Gs/jkaEE1ozuvX+9CFXwjfJ/V9EWA=; b=mcrxO9KLuZtQiBiXMR+V8F9MiWd7zT5UQg7IrTRDWMEO0aEm7t3kHy/mIXqdAReKoZ Xf9kgrSKSjyDyqQqj4ho89EvkVrZheJ/0p2HFB+P3bAgs3Zi3Wx5hsQ6dL23NTIy2adS VHpr44p2LKpp1CWXIn58UXflxHJYSWkmWhPpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rSBA+JuDbyoRxcQZsG/0xS/IzdMaDrJASQt9aoy0zwRY4RVrMNaJWpthFOEp8zMevC o00mnxHNJEp1DLJswT+WSKsUKkoqOOcVpPefogEJWcqWntHTNGbGtACQaRKkpJjAZXZz qAMmqMGsovW2iqhNGRy6aWwNRsYTwzxsPVROQ= MIME-Version: 1.0 Received: by 10.216.28.209 with SMTP id g59mr1967131wea.96.1244399427071; Sun, 07 Jun 2009 11:30:27 -0700 (PDT) Date: Sun, 7 Jun 2009 20:30:26 +0200 Message-ID: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> From: claudiu vasadi To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: IBM TSM 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: Sun, 07 Jun 2009 18:54:00 -0000 Hello again. About a week ago I cryed on your shoulders but since no one is answering I am crying again. This time with more accurate data. My sistem is a P4 2.66 Mhz (sk 478) Intel P4 processor with 1 GB DDR1 ram, mobo Asus p4p800-x with 2 HDD's. One of them (ad2 ) is a Samsing SpinPoint of 80GB ATA and is the one used by the actual OS. The second one (ad6) is a WD 250 GB S-ATA2 and has some data on it. The server acts as a web server, ftp server, NAS, samba svr, a p2p server (verlihub) and just about every normal app a mental deranged person can have running :P (those kind that dnt have money to buy the ultra ultimate bullshit in hardware or more than two 2 pc's. Leaving this asside here is my situation. Ups, almost forgot. I have a FreeBSD-7.0-STABLE. I have a Windows machine with vmware and solaris on it. In solaris there is a IBM TSM (Tape Storage Management) Server. The server can use disks over tapes to build pools. So I added the local windows disks, and have some 30 G of free space on freebsd, so I thought, I would add them to the storage pool. There's my mistake ... thinking :P Every time I try to add that space to the storage pool the system crashes with a kernel panic. Here is the /var/log/messages file Jun 7 21:03:45 da1 fsck: /dev/ad6s1d: INCORRECT BLOCK COUNT I=5652481 (0 should be 4) (CORRECTED) Jun 7 21:03:45 da1 fsck: /dev/ad6s1d: 16137 files, 45577224 used, 15357050 free (2210 frags, 1919355 blocks, 0.0% fragmentation) Jun 7 21:10:47 da1 syslogd: kernel boot file is /boot/kernel/kernel Jun 7 21:10:47 da1 kernel: ad6: FAILURE - device detached Jun 7 21:10:47 da1 kernel: subdisk6: detached Jun 7 21:10:47 da1 kernel: ad6: detached Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, length=16384)]error = 6 [...] [...] [...] Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=46438858752, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=46252277760, length=16384)]error = 6 Jun 7 21:10:47 da1 kernel: panic: vinvalbuf: dirty bufs Jun 7 21:10:47 da1 kernel: cpuid = 0 Jun 7 21:10:47 da1 kernel: Uptime: 21m50s Jun 7 21:10:47 da1 kernel: Physical memory: 1011 MB So I'm guesing the script that adds the space to the pool is doing some crap. I tryed using both HDD's but the result is the same -> sistem crash. I have no kernel dump file defined yet (dnt ask why, I've setted up long ago but for some reason this time it didn't write to it) . REPRODUCE: The only way to reproduce the problem is by telling tsm server to add the available 30G off free space. What the tsm server doesm, is it creates a file of a given size, in this case 25G out of the total of 30G, and then populates the file with whatever data it is given as backup data. I really have no ideea if this is the right mailing list for this matter. If it is not, please advise in this matter. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 19:38:15 2009 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 50D0C106564A; Sun, 7 Jun 2009 19:38:15 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5208FC12; Sun, 7 Jun 2009 19:38:13 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n57Jc7PI000369; Sun, 7 Jun 2009 21:38:07 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n57Jc4Cb000366; Sun, 7 Jun 2009 21:38:07 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 7 Jun 2009 21:38:04 +0200 (CEST) From: Wojciech Puchar To: claudiu vasadi In-Reply-To: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> Message-ID: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IBM TSM 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: Sun, 07 Jun 2009 19:38:15 -0000 > Jun 7 21:10:47 da1 kernel: ad6: detached > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, > length=16384)]error = 6 > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, > length=16384)]error = 6 > Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, > length=16384)]error = 6 isn;t it trying to read past the end of disk? From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 20:06:19 2009 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 CB887106566C; Sun, 7 Jun 2009 20:06:19 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 28FDC8FC0A; Sun, 7 Jun 2009 20:06:18 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by ewy8 with SMTP id 8so3568006ewy.43 for ; Sun, 07 Jun 2009 13:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p4d6Mt/awBHGNfNWo8+ffmQIaB9g4/2IxNlbuocH5yI=; b=lQUPk5UdePYoSM4dXYjAiNBXsY/rgTh+A7LR89Einrk8sQLLN+H0ZTMvSp1wl6T04Z zgjqtKh+nRWI3WxOoxCFHSOL+5gE3A/pb66HAvunEHQ+IfCyJQIx7JQNvp9EEW80wZZm p8m95JgNfBfRQjM5TJSY8vsLA2sjCbU8G2N4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pHTXVt9kKdbtCL/URAwb8rZGGQBVJe+TQZnmE+yrms0JO/kWQlGX19l2fa5fEoA/g5 DuEsglgA2CMbzTWAq3uc6xKt2Uv4cuBhj0kyVr54/Xh98pV13cPcn55XeQEvGYCO4lFb 7hKhshtgGKYC6Z3p4+VjrcxlxZ2sit2h+sjus= MIME-Version: 1.0 Received: by 10.216.11.213 with SMTP id 63mr2007364wex.176.1244405178084; Sun, 07 Jun 2009 13:06:18 -0700 (PDT) In-Reply-To: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> Date: Sun, 7 Jun 2009 22:06:18 +0200 Message-ID: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> From: claudiu vasadi To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IBM TSM 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: Sun, 07 Jun 2009 20:06:20 -0000 On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > Jun 7 21:10:47 da1 kernel: ad6: detached >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >> length=16384)]error = 6 >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >> length=16384)]error = 6 >> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >> length=16384)]error = 6 >> > > > isn;t it trying to read past the end of disk? > Hmm.. I guess you are correct. The question is why is it doing this ? And on both drives ? Feels to me a problem for the developers. HDD's didn't give me one problem since the day the got installed. I'm not saing that they are very good HDD's (in fact they are quite cheap ones) but fail all of a sudden ? And leaving this asside, they dnt give one error on masive transfers and still have very good transfer speed. What I'm saing is that hdd failure could be a posibility of course, but a unlikely one at this point. My problem is that I do not know what tehnik TSM server uses for creating those files because at some point it fails. Strainge thing is that it goes over 1G. First it creates the file and then it populates the file up until the given limit (25G in this case). I will try something tomorow. I will again start the tsm server to add the space (the 25G free space) to the pool and will monitor the file size up until the OS crashes. I'm very curious what's the size of the file when the OS crashes. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 20:06:37 2009 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 EFE4E1065841 for ; Sun, 7 Jun 2009 20:06:37 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1448FC1D for ; Sun, 7 Jun 2009 20:06:37 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by mail-ew0-f212.google.com with SMTP id 8so3568006ewy.43 for ; Sun, 07 Jun 2009 13:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=50B/uetsFnXHEpm+jn1qpgpoA6uLKsMLtr/LDAxGa2s=; b=IqVjU2srUpzH5AgkXwN6Taml8vE9IkSKUMhCjaPXtQzVr8HV0n4usobCWkP/r+ll1l NT8A5B6bosKRLQs9CYDY4663zzJO9WRinLn7Y5kV/6To41x0tnUS3VKND1PX8E/gF0eJ gm98KJ5M9lD8t40jbEUVr+H/m9EC/SX0VDAmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; b=BXDTt750l62TXnfep/fY+W9RwNbt4Rpegj4bVisM64MF1VCQKuh1T5CBs2PCnqtdrX 6+Zsv0V4pNomQXhGLMagK9YJA5DbAid+DCTjgGj7qjBLUsEy5pobiBIf0I+U+cQOVwOO 97FQ4yHobOG1+G4GUmZZBBI2bu1wGkYSu/Pzg= MIME-Version: 1.0 Received: by 10.216.7.141 with SMTP id 13mr2024530wep.24.1244403437117; Sun, 07 Jun 2009 12:37:17 -0700 (PDT) In-Reply-To: <20090607183035.GA22240@lava.net> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> From: Chris Rees Date: Sun, 7 Jun 2009 20:36:57 +0100 Message-ID: To: AES , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: I need to add commands that starts every time at system boot. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 20:06:38 -0000 2009/6/7 Clifton Royston : >=A0If you feel you just *can't* do it via a script in > /usr/local/etc/rc.d, which is the better way, add a script called > /etc/rc.local and that will be run after all the other start-up steps. What's wrong with rc.local? Chris --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 20:44:43 2009 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 7EE391065687 for ; Sun, 7 Jun 2009 20:44:43 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 10D188FC1F for ; Sun, 7 Jun 2009 20:44:42 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by ewy8 with SMTP id 8so3585814ewy.43 for ; Sun, 07 Jun 2009 13:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=EzCQT5C3iSn2757rj3qcAwlj3K68C9M+oIT9X7k7Weo=; b=P4prvVT6UgnlwkyK9x7A4E0S8ph1l4Wy4Zfc+lodSt47cqutCAQLGqgbtsHjcz+qqc j31lKf2KP34AQIlALv1erXdkSIzKTqwyAV2wHHlgUkpNv1llR7MIq0TIFfm92ESzdfpM hKZnD3P08/pvmhOYJoPc3PcLk8Kf318in3t3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cXpnr+jPX2GC+0y7LW2EnSVpNNqCeC4w0jHPeP8Bj4SNZbpV5X3GtjJyIxT6+cFrFp rae2B8ZBG3GNGpKK4Tq0eQLdO5cFQv9tecESehpDBuEUHoh6EFP9nwomnfey8EgkeQN4 Krm5ykqiVKdcWeLW6+Sr+ffxT4Xok3/MKr+2A= MIME-Version: 1.0 Received: by 10.210.42.20 with SMTP id p20mr5611944ebp.92.1244405581128; Sun, 07 Jun 2009 13:13:01 -0700 (PDT) In-Reply-To: References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> From: Scott Ullrich Date: Sun, 7 Jun 2009 16:12:41 -0400 Message-ID: To: utisoft@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: AES , freebsd-stable@freebsd.org Subject: Re: I need to add commands that starts every time at system boot. 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, 07 Jun 2009 20:44:43 -0000 On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: > 2009/6/7 Clifton Royston : > >>=A0If you feel you just *can't* do it via a script in >> /usr/local/etc/rc.d, which is the better way, add a script called >> /etc/rc.local and that will be run after all the other start-up steps. > > What's wrong with rc.local? Probably stems from this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html Cheers Scott From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 21:26:17 2009 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 272E21065670 for ; Sun, 7 Jun 2009 21:26:17 +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 D8BED8FC15 for ; Sun, 7 Jun 2009 21:26:16 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4276919E023; Sun, 7 Jun 2009 23:26:13 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D4D4919E019; Sun, 7 Jun 2009 23:26:10 +0200 (CEST) Message-ID: <4A2C3073.3020700@quip.cz> Date: Sun, 07 Jun 2009 23:26:11 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: claudiu vasadi References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> In-Reply-To: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IBM TSM 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: Sun, 07 Jun 2009 21:26:17 -0000 claudiu vasadi wrote: > On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: > > >>Jun 7 21:10:47 da1 kernel: ad6: detached >> >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >>>length=16384)]error = 6 >>> >> >> >>isn;t it trying to read past the end of disk? >> > > > Hmm.. I guess you are correct. The question is why is it doing this ? It can be caused by wrong disk label (partitioning). Some partition made bigger then real media [disk]. You can see the label by command disklabel ad6s1 and then compare size & offset values with `diskinfo -v ad6` > And on both drives ? > > > Feels to me a problem for the developers. HDD's didn't give me one problem > since the day the got installed. I'm not saing that they are very good HDD's > (in fact they are quite cheap ones) but fail all of a sudden ? And leaving > this asside, they dnt give one error on masive transfers and still have very > good transfer speed. What I'm saing is that hdd failure could be a > posibility of course, but a unlikely one at this point. > > My problem is that I do not know what tehnik TSM server uses for creating > those files because at some point it fails. Strainge thing is that it goes > over 1G. First it creates the file and then it populates the file up until > the given limit (25G in this case). > > I will try something tomorow. I will again start the tsm server to add the > space (the 25G free space) to the pool and will monitor the file size up > until the OS crashes. I'm very curious what's the size of the file when the > OS crashes. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 22:21:13 2009 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 2E3F9106564A for ; Sun, 7 Jun 2009 22:21:13 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id A210D8FC19 for ; Sun, 7 Jun 2009 22:21:12 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 9ED7FD0061; Sun, 7 Jun 2009 12:21:11 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 22748153882; Sun, 7 Jun 2009 12:21:11 -1000 (HST) Date: Sun, 7 Jun 2009 12:21:11 -1000 From: Clifton Royston To: Scott Ullrich Message-ID: <20090607222110.GA18662@lava.net> Mail-Followup-To: Scott Ullrich , utisoft@gmail.com, AES , freebsd-stable@freebsd.org References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: AES , freebsd-stable@freebsd.org, utisoft@gmail.com Subject: Re: I need to add commands that starts every time at system boot. 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, 07 Jun 2009 22:21:13 -0000 On Sun, Jun 07, 2009 at 04:12:41PM -0400, Scott Ullrich wrote: > On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote: > > 2009/6/7 Clifton Royston : > > > >> If you feel you just *can't* do it via a script in > >> /usr/local/etc/rc.d, which is the better way, add a script called > >> /etc/rc.local and that will be run after all the other start-up steps. > > > > What's wrong with rc.local? > > Probably stems from this discussion: > http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html No, I hadn't actually seen that discussion before. I used to work on BSD/OS, which had only the rc.local mechanism, and when I first switched over to FreeBSD it was what I used. Eventually I got my head around the /etc/rc.d and /usr/local/etc/rc.d mechanism and found it distinctly superior, so now I use it almost exclusively. Major highlights as to why are: * You can readily implement whatever additional operations your service should support, such as restart/shutdown/whatever; * you can add or remove different services as discrete entities, without having to merge their change or removal into a single text file; * the startup/shutdown script can therefore readily be packaged for removal/installation together with any other software for the service in question; * you can get your service or operation run in a specific order relative to other services; * you can use the same script to start, shutdown, or restart the service at another time if appropriate or necessary It used to be a little harder to write them than a few lines in rc.local, but now sourcing rc_subr provides shell functions which make it trivial. These days I only use rc.local if I need to do some kind of non-critical quick hack, e.g. for troubleshooting a problem. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 22:34:50 2009 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 458B31065673 for ; Sun, 7 Jun 2009 22:34:50 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id BB7428FC20 for ; Sun, 7 Jun 2009 22:34:49 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n57MYlWE028975; Mon, 8 Jun 2009 02:34:47 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Mon, 8 Jun 2009 02:34:47 +0400 (MSD) From: Dmitry Morozovsky To: Willem Jan Withagen In-Reply-To: <4A2BEF7D.5070808@withagen.nl> Message-ID: References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Mon, 08 Jun 2009 02:34:47 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS isntall requirements 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, 07 Jun 2009 22:34:50 -0000 On Sun, 7 Jun 2009, Willem Jan Withagen wrote: WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: WJW> > KS> > Hi, WJW> > KS> > WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib WJW> > KS> > ===> sys/boot/i386/libi386 (install) WJW> > KS> > ===> sys/boot/i386/libfirewire (install) WJW> > KS> > ===> sys/boot/i386/loader (install) WJW> > KS> > make: don't know how to make WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop WJW> > KS> KS> ISTR that the build was temporarily broken several days ago. WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/ it does not ;) WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox setup. WJW> But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? WJW> WJW> Because that is required to have the trouble surface. Ah well, you're possibly right. In the interim, you can safely comment this line out, as there's nothing (except small amount of disk space) you lose when you compile ZFS but do not use it. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 00:27:02 2009 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 EBE0F106566C for ; Mon, 8 Jun 2009 00:27:02 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id A01D88FC12 for ; Mon, 8 Jun 2009 00:27:02 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qyk3 with SMTP id 3so3768204qyk.3 for ; Sun, 07 Jun 2009 17:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=vhAD6Zg6H3/bOFj0QfSS54JmwTPnIXS81kbIZLSjWjc=; b=JGmQHV1M9gMOIpgypmgY5oFyGWpG7iBGfP4i+FHVMlIOb3KzSA3eqI9KYozXMOt+uR erhnDWH1Wdngqci/zX3fQSPFbStDRtrrVFeeMbf9pi94ugd9z/oPfNsNVLae11u8rwgJ z9JDRBdsZzxRU67G0SN1TzpNkbTzd9yujbrI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=UzcUvjGKp8wU+DPnPko6gqMXUZkY42um0zT4Qxi9ahOFfexqHRNFm6bCVFjOHJNJfw RnyZUY/PN6wrrS4s55I0XD4/84KZ8nUCo24EvpMq5TRfw58e940ssS2sWILAkVKnJNmw X89cxwtL8MTgSNzzh1hEf9j13aBFCHNzM8vgA= Received: by 10.224.74.81 with SMTP id t17mr6078329qaj.59.1244418896067; Sun, 07 Jun 2009 16:54:56 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-1-160.nwrk.east.verizon.net [70.111.1.160]) by mx.google.com with ESMTPS id 7sm3315549qwf.9.2009.06.07.16.54.54 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Jun 2009 16:54:55 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Angelo Turetta In-Reply-To: <4A281250.5050306@commit.it> References: <4A281250.5050306@commit.it> Content-Type: text/plain; charset="UTF-8" Date: Sun, 07 Jun 2009 19:54:26 -0400 Message-Id: <1244418866.1276.6.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: kmem map too small panic after updating to STABLE-7 r192996 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, 08 Jun 2009 00:27:03 -0000 On Thu, 2009-06-04 at 20:28 +0200, Angelo Turetta wrote: > Tim Chase wrote: > > Hello, > > > > I decided to give the new zfs code a try and upgraded my stable-7 system > > and discovered a panic that I can reproduce at will. > > I just had the same problem, and it turned out I was not diligent when I > first set my zfs pool up :) > > To use vm.kmem_size="512M" you need to put > > options KVA_PAGES=512 Are you sure this is the case? RabbitsDen# uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Jun 7 12:25:08 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 RabbitsDen# grep KVA_PAGES /sys/i386/conf/TPX60 options KVA_PAGES=256 <========= RabbitsDen# grep kmem /boot/loader.conf vm.kmem_size_max="512M" vm.kmem_size="512M" RabbitsDen# sysctl vm.kmem_size_max vm.kmem_size_max: 536870912 <========= RabbitsDen# sysctl vm.kmem_size vm.kmem_size: 536870912 RabbitsDen# grep arc /boot/loader.conf vfs.zfs.arc_min="128M" vfs.zfs.arc_max="256M" -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 05:59:09 2009 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 82FBB106564A; Mon, 8 Jun 2009 05:59:09 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id CF8A38FC08; Mon, 8 Jun 2009 05:59:08 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by ewy8 with SMTP id 8so3799485ewy.43 for ; Sun, 07 Jun 2009 22:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Uh9RJm5G+foRibOjCFevjD8E6i6lUAOHhGEcg7G2t6E=; b=K5tDWwL7rUmiPQ6v8gjuujyOhjH/GmBRWNqW1jbS87An0Ldw9RayQ14uMPXRWWUYWC NqvYGzB5Viim12KjhzplIa8XnyC5IGZJbl0IGggHlFcq72J/8Zig6bcxlcnrMKKlqUjA Ju9O7X72N+17d6Pk8guz/2UHO0ouuUbAFU04Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vv7RxKqScdNilgihNEFVESOXT9slnc+ijDE/WzOVgKNgk+ETg+2i96H7VlKvbi/Xed GHqz96dEEP4GNJJvErR9H+whnYeaZfDf6flQg8x7h7QDDZ4J5m4dygBsj14DWN77/l9b k+NH/RTTfDg6BYKPQB2vMwmK4oW7/3xsSH4S4= MIME-Version: 1.0 Received: by 10.216.11.213 with SMTP id 63mr2135435wex.176.1244440747867; Sun, 07 Jun 2009 22:59:07 -0700 (PDT) In-Reply-To: <4A2C3073.3020700@quip.cz> References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> <4A2C3073.3020700@quip.cz> Date: Mon, 8 Jun 2009 07:59:07 +0200 Message-ID: <4f760c6a0906072259j6d2d2c6ese55769f58e58e11a@mail.gmail.com> From: claudiu vasadi To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IBM TSM 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: Mon, 08 Jun 2009 05:59:10 -0000 On Sun, Jun 7, 2009 at 11:26 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > claudiu vasadi wrote: > >> On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < >> wojtek@wojtek.tensor.gdynia.pl> wrote: >> >> >> Jun 7 21:10:47 da1 kernel: ad6: detached >>> >>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >>>> length=16384)]error = 6 >>>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >>>> length=16384)]error = 6 >>>> Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >>>> length=16384)]error = 6 >>>> >>>> >>> >>> isn;t it trying to read past the end of disk? >>> >>> >> >> Hmm.. I guess you are correct. The question is why is it doing this ? >> > > It can be caused by wrong disk label (partitioning). Some partition made > bigger then real media [disk]. > You can see the label by command disklabel ad6s1 and then compare size & > offset values with `diskinfo -v ad6` Here is the ad2: [da1@da1.ro /home/da1]# disklabel ad2s1 # /dev/ad2s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 0 4.2BSD 2048 16384 8 b: 4125328 1048576 swap c: 41929587 0 unused 0 0 # "raw" part, don't edit d: 4159488 5173904 4.2BSD 2048 16384 28552 e: 1048576 9333392 4.2BSD 2048 16384 8 f: 31547619 10381968 4.2BSD 2048 16384 28552 [da1@da1.ro /home/da1]# diskinfo -v ad2 ad2 512 # sectorsize 80060424192 # mediasize in bytes (75G) 156368016 # mediasize in sectors 155127 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:S00JJ30X533937 # Disk ident. And the ad6: [da1@da1.ro /home/da1]# disklabel ad6s1 # /dev/ad6s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 490223412 0 unused 0 0 # "raw" part, don't edit d: 251658240 0 4.2BSD 0 0 0 e: 167772160 251658240 4.2BSD 0 0 0 f: 70793012 419430400 4.2BSD 0 0 0 [da1@da1.ro /home/da1]# diskinfo -v ad6 ad6 512 # sectorsize 251000193024 # mediasize in bytes (234G) 490234752 # mediasize in sectors 486344 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:WD-WCANY2281832 # Disk ident. [da1@da1.ro /home/da1]# From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 07:13:47 2009 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 57CCD106566B; Mon, 8 Jun 2009 07:13:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB688FC17; Mon, 8 Jun 2009 07:13:46 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [IPv6:::1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n587DeZt003578; Mon, 8 Jun 2009 09:13:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n587DeaY003570; Mon, 8 Jun 2009 09:13:40 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 8 Jun 2009 09:13:40 +0200 (CEST) From: Wojciech Puchar To: claudiu vasadi In-Reply-To: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> Message-ID: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IBM TSM 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: Mon, 08 Jun 2009 07:13:47 -0000 > > isn;t it trying to read past the end of disk? > > > Hmm.. I guess you are correct. The question is why is it doing this ? because partition/slice table is wrong? From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 07:55:52 2009 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 80D551065670; Mon, 8 Jun 2009 07:55:52 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id DC8728FC0A; Mon, 8 Jun 2009 07:55:51 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by ewy8 with SMTP id 8so3853097ewy.43 for ; Mon, 08 Jun 2009 00:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UfEDSvbss7U7nEyYezJU9WIqwk7BEeOOrAemmP0cy8E=; b=XhU9ZA2/8OiyrhdnwO2zji7QkdUwnacT3o2PCzj3rVV/Aq+ma9bO2efFTnEFwcODjd zum830RzZBChJrtQwcZw9hMXJbO/+aNwhQG6FKKLdZChi7LtT12uGULln/KgFwHfa6zH M2hDybm8+v525VrKXg1FviYZP8CPOlG3UlqNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x90g/dO++R3cir8PcMv05z/gYxBkdg/vE0WTGT0x1VwZSHVFV+Q6KfAwFSID3HmPH+ X/eVYZ6rub11WCigLkgt+X8cNgN5BoVtxezzZCT3I5uH5it041tvbhJsVMFzvtBKfIfz 7DJjoRFAa3J04kgq+zsxUtgnSokoKKb8GhZFA= MIME-Version: 1.0 Received: by 10.216.3.195 with SMTP id 45mr2243539weh.8.1244447750997; Mon, 08 Jun 2009 00:55:50 -0700 (PDT) In-Reply-To: References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> <4A2C3073.3020700@quip.cz> <4f760c6a0906072259j6d2d2c6ese55769f58e58e11a@mail.gmail.com> Date: Mon, 8 Jun 2009 09:55:50 +0200 Message-ID: <4f760c6a0906080055p481cb61dm94c7a6ca9e267e0a@mail.gmail.com> From: claudiu vasadi To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: IBM TSM 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: Mon, 08 Jun 2009 07:55:53 -0000 On Mon, Jun 8, 2009 at 9:16 AM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > > the type fdisk /dev/da1 and then compare the sectors values with what dmesg > says > > fdisk /dev/ad2 : ******* Working on device /dev/ad2 ******* parameters extracted from in-core disklabel are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155127 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41929587 (20473 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 41929650, size 114430995 (55874 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 dmesg doesn't say anything usefull. only: ad2: 76351MB at ata1-master UDMA100 I'm not pretty good at this but it seams ok. the disk has been 99% full before and no problems. The slices were created a long time ago and ran some random test that all came out ok. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 08:50:04 2009 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 428CA106567B for ; Mon, 8 Jun 2009 08:50:04 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id B22F28FC12 for ; Mon, 8 Jun 2009 08:50:03 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by ewy8 with SMTP id 8so3884536ewy.43 for ; Mon, 08 Jun 2009 01:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=2WJVj7LkEf84EZTyUxFM4rOHGBtjwwkYeRJBBRo2t5o=; b=kyazRnE2Wj01GldYO5MoS2FDzYbTbfkhuM/9EPbTI2ArC+Pu3zYxS3Oa59fnYtv+OB OMWQOCFyjryZ5Ujb99ACnzDsLOVMFdUF8KShgN2cFwLvvvoHAsbdX880SXTcEBK5MLfu ae2YHoHX94u4UhIEuxwtPxxV3tWI/WWKnZDPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; b=LuG4TnHC19AfFvJf+gEOfrho1UsyjDklHK7NXNFvwgo8yyI+xU7paVrXYF1KNcPtYB 5GneOLNifyzxlpuqC+RYbQnEn3IVb/D+pzIzJ396MToZOCvYsLs+fmBa2eDW/eqrxLeN Vu0pN9Od26RvcokmYZv8jzuZ3MEGd5EsUdeRE= MIME-Version: 1.0 Received: by 10.216.28.198 with SMTP id g48mr2210714wea.109.1244451002289; Mon, 08 Jun 2009 01:50:02 -0700 (PDT) In-Reply-To: <20090607222110.GA18662@lava.net> References: <143776.42704.qm@web34307.mail.mud.yahoo.com> <20090607183035.GA22240@lava.net> <20090607222110.GA18662@lava.net> From: Chris Rees Date: Mon, 8 Jun 2009 09:49:42 +0100 Message-ID: To: Scott Ullrich , utisoft@gmail.com, AES , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: I need to add commands that starts every time at system boot. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 08:50:05 -0000 2009/6/7 Clifton Royston : > On Sun, Jun 07, 2009 at 04:12:41PM -0400, Scott Ullrich wrote: >> On Sun, Jun 7, 2009 at 3:36 PM, Chris Rees wrote= : >> > 2009/6/7 Clifton Royston : >> > >> >>=A0If you feel you just *can't* do it via a script in >> >> /usr/local/etc/rc.d, which is the better way, add a script called >> >> /etc/rc.local and that will be run after all the other start-up steps= . >> > >> > What's wrong with rc.local? >> >> Probably stems from this discussion: >> http://lists.freebsd.org/pipermail/freebsd-stable/2007-July/035996.html > > =A0No, I hadn't actually seen that discussion before. > > =A0I used to work on BSD/OS, which had only the rc.local mechanism, and > when I first switched over to FreeBSD it was what I used. =A0Eventually I > got my head around the /etc/rc.d and /usr/local/etc/rc.d mechanism and > found it distinctly superior, so now I use it almost exclusively. > > =A0Major highlights as to why are: > > =A0* You can readily implement whatever additional operations your servic= e > =A0 should support, such as restart/shutdown/whatever; > =A0* you can add or remove different services as discrete entities, > =A0 without having to merge their change or removal into a single text > =A0 file; > =A0* the startup/shutdown script can therefore readily be packaged for > =A0 removal/installation together with any other software for the > =A0 service in question; > =A0* you can get your service or operation run in a specific order > =A0 relative to other services; > =A0* you can use the same script to start, shutdown, or restart the > =A0 service at another time if appropriate or necessary > > =A0It used to be a little harder to write them than a few lines in > rc.local, but now sourcing rc_subr provides shell functions which make > it trivial. > > =A0These days I only use rc.local if I need to do some kind of > non-critical quick hack, e.g. for troubleshooting a problem. > =A0-- Clifton > > -- > =A0 =A0Clifton Royston =A0-- =A0cliftonr@iandicomputing.com / cliftonr@la= va.net > =A0 =A0 =A0 President =A0- I and I Computing * http://www.iandicomputing.= com/ > =A0Custom programming, network design, systems and network consulting ser= vices > Nice, thanks a lot, didn't know about rc_subr. Thanks Scott too. Chris --=20 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 10:59:44 2009 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 5F9D31065673 for ; Mon, 8 Jun 2009 10:59:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1D11C8FC0C for ; Mon, 8 Jun 2009 10:59:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 0E7E415346B; Mon, 8 Jun 2009 12:40:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1oXlasgKiz4; Mon, 8 Jun 2009 12:40:07 +0200 (CEST) Received: from [192.168.254.10] (unknown [192.168.254.10]) by mail.digiware.nl (Postfix) with ESMTP id 968DA153467; Mon, 8 Jun 2009 12:40:06 +0200 (CEST) Message-ID: <4A2CEA86.9040509@digiware.nl> Date: Mon, 08 Jun 2009 12:40:06 +0200 From: Willem Jan Withagen Organization: Digiware Management User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS isntall requirements 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, 08 Jun 2009 10:59:44 -0000 Dmitry Morozovsky wrote: > On Sun, 7 Jun 2009, Willem Jan Withagen wrote: > > WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: > WJW> > KS> > Hi, > WJW> > KS> > > WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run into: > WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib > WJW> > KS> > ===> sys/boot/i386/libi386 (install) > WJW> > KS> > ===> sys/boot/i386/libfirewire (install) > WJW> > KS> > ===> sys/boot/i386/loader (install) > WJW> > KS> > make: don't know how to make > WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop > WJW> > KS> KS> ISTR that the build was temporarily broken several days ago. > WJW> > > WJW> > > WJW> > Well, according to http://tinderbox.freebsd.org/ it does not ;) > WJW> > WJW> I'm not at all familiar with the intrinsics of the tinderbox setup. > WJW> But am I free to assume that it is not tested with 'WITHOUT_ZFS=yes'??? > WJW> > WJW> Because that is required to have the trouble surface. > > Ah well, you're possibly right. In the interim, you can safely comment this > line out, as there's nothing (except small amount of disk space) you lose when > you compile ZFS but do not use it. I was trying to figure out if it was pilot error, or a bug. But now I conclude it is a bug. Should I log a PR? --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 11:28:32 2009 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 790C1106564A for ; Mon, 8 Jun 2009 11:28:32 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp27.orange.fr (smtp27.orange.fr [80.12.242.94]) by mx1.freebsd.org (Postfix) with ESMTP id 12FFD8FC1A for ; Mon, 8 Jun 2009 11:28:31 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2702.orange.fr (SMTP Server) with ESMTP id E7A741C000AD; Mon, 8 Jun 2009 13:28:30 +0200 (CEST) Received: from localhost (AToulouse-156-1-56-115.w90-16.abo.wanadoo.fr [90.16.87.115]) by mwinf2702.orange.fr (SMTP Server) with ESMTP id 039701C000A4; Mon, 8 Jun 2009 13:28:29 +0200 (CEST) X-ME-UUID: 20090608112830148.039701C000A4@mwinf2702.orange.fr Message-ID: <4A2CF5DC.8020102@orange.fr> Date: Mon, 08 Jun 2009 13:28:28 +0200 From: Claude Buisson User-Agent: Thunderbird 2.0.0.21 (X11/20090420) MIME-Version: 1.0 To: Willem Jan Withagen References: <4A29011B.9040803@withagen.nl> <200906050946.59547.kirk@strauser.com> <4A2BEF7D.5070808@withagen.nl> <4A2CEA86.9040509@digiware.nl> In-Reply-To: <4A2CEA86.9040509@digiware.nl> Content-Type: multipart/mixed; boundary="------------030609080002000609020706" Cc: freebsd-stable@freebsd.org, Dmitry Morozovsky Subject: Re: ZFS isntall requirements 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, 08 Jun 2009 11:28:32 -0000 This is a multi-part message in MIME format. --------------030609080002000609020706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Willem Jan Withagen wrote: > > Dmitry Morozovsky wrote: >> On Sun, 7 Jun 2009, Willem Jan Withagen wrote: >> >> WJW> > KS> On Friday 05 June 2009 06:27:23 am Willem Jan Withagen wrote: >> WJW> > KS> > Hi, >> WJW> > KS> > >> WJW> > KS> > I'm trying to get my world to 7.2-stable(amd64),but run >> into: >> WJW> > KS> > install -o root -g wheel -m 444 kgzldr.o /usr/lib >> WJW> > KS> > ===> sys/boot/i386/libi386 (install) >> WJW> > KS> > ===> sys/boot/i386/libfirewire (install) >> WJW> > KS> > ===> sys/boot/i386/loader (install) >> WJW> > KS> > make: don't know how to make >> WJW> > KS> > /usr/obj/mnt4/usr/src7/src/tmp/usr/lib/libzfs.a. Stop >> WJW> > KS> KS> ISTR that the build was temporarily broken several days >> ago. >> WJW> > WJW> > WJW> > Well, according to http://tinderbox.freebsd.org/ >> it does not ;) >> WJW> WJW> I'm not at all familiar with the intrinsics of the tinderbox >> setup. >> WJW> But am I free to assume that it is not tested with >> 'WITHOUT_ZFS=yes'??? >> WJW> WJW> Because that is required to have the trouble surface. >> >> Ah well, you're possibly right. In the interim, you can safely >> comment this line out, as there's nothing (except small amount of disk >> space) you lose when you compile ZFS but do not use it. > > I was trying to figure out if it was pilot error, or a bug. > But now I conclude it is a bug. > > Should I log a PR? > > --WjW > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freeb, which is invalisd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > This bug exists from some time and has already be discussed on this list. The bug stems from the use of the LIBZFS variable in sys/boot/i386/loader/Makefile: it is not defined in this Makefile if LOADER_ZFS_SUPPORT is not defined, so its value is taken from share/mk/bsd.libnames.mk which is invalid in the WITHOUT_CDDL/WITHOUT_ZFS case. Kip Macy said he would try to fix it by (last) Wednesday. He made a patch, then reverted it (see the svn history). You may use the attached simple patch. Hope it helps, Claude Buisson --------------030609080002000609020706 Content-Type: text/plain; name="patch-boot_i386_loader_Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-boot_i386_loader_Makefile" --- sys/boot/i386/loader/Makefile.orig 2009-05-24 18:32:41.000000000 +0200 +++ sys/boot/i386/loader/Makefile 2009-06-01 15:18:57.000000000 +0200 @@ -18,7 +18,7 @@ # Put LOADER_ZFS_SUPPORT=yes in /etc/make.conf for ZFS support .if defined(LOADER_ZFS_SUPPORT) CFLAGS+= -DLOADER_ZFS_SUPPORT -LIBZFS= ${.OBJDIR}/../../zfs/libzfsboot.a +LIBZFSBOOT= ${.OBJDIR}/../../zfs/libzfsboot.a .endif # Enable PXE TFTP or NFS support, not both. @@ -105,8 +105,8 @@ # XXX crt0.o needs to be first for pxeboot(8) to work OBJS= ${BTXCRT} -DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} ${LIBSTAND} -LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFS} ${LIBI386} -lstand +DPADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} ${LIBSTAND} +LDADD= ${LIBFICL} ${LIBFIREWIRE} ${LIBZFSBOOT} ${LIBI386} -lstand .include --------------030609080002000609020706-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 12:56:57 2009 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 CBEAE10656C2 for ; Mon, 8 Jun 2009 12:56:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 862BA8FC1C for ; Mon, 8 Jun 2009 12:56:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MDePF-0005ck-FL for freebsd-stable@freebsd.org; Mon, 08 Jun 2009 12:56:53 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jun 2009 12:56:53 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jun 2009 12:56:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 08 Jun 2009 14:57:18 +0200 Lines: 33 Message-ID: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090409) In-Reply-To: <200906020842.42330.jhb@freebsd.org> Sender: news Subject: Re: Unnamed POSIX shared semaphores 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, 08 Jun 2009 12:56:58 -0000 John Baldwin wrote: > On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: >> Jilles Tjoelker wrote: >>> If process-shared semaphores really work, then the above structure is >>> not a pathological case. Effectively, sem_t is carved in stone. So >>> process-private semaphores should continue to have most of their stuff >>> in a separately allocated structure, to preserve flexibility. >>> >> There was an inadvertent race in FreeBSD's POSIX semaphores which I >> fixed in HEAD and STABLE about 6 weeks before 7.2 was released. >> >> I believe process-shared POSIX semaphores now work -- the Python >> 'multiprocessing' regression test now runs to completion with no errors >> on both HEAD and STABLE. > > The semaphores in recent 7 and 8 are definitely not process-shared (at least > not intentionally). They may work across a fork accidentally, but you can't > store it in an mmap() region and share it with an arbitrary process. > On a completely unrelated subject I was reading about PHP APC cache where they have the same need - cross-process locking with locks embedded in data structures and they have adopted userland spinlock code from PostgreSQL: http://www.scribd.com/doc/3288293/brian-shireapc-facebook (spin)locks are not the same as sempahores but maybe it will help the OP or anyone else trying to implement this feature: http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 13:01:14 2009 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 610DD106573D for ; Mon, 8 Jun 2009 13:01:14 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 204C48FC0A for ; Mon, 8 Jun 2009 13:01:13 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.2.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id ACA4E46E89; Mon, 8 Jun 2009 14:32:53 +0200 (CEST) Message-Id: From: Fabien Thomas To: FreeBSD Stable List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 14:32:53 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Joseph Koshy Subject: Announcement: PmcTools merged to RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabient@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 13:01:15 -0000 Hello, The PmcTools is merged to RELENG_7. You can now enjoy the same level of features / hw supported as in head: - Callchain in capture - Core 2 support - Core i7 support - pmcannotate: source code annotation using pmc capture - bug fixes ... Tell me if you find any problems with it. Fabien From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 13:23:00 2009 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 566401065672; Mon, 8 Jun 2009 13:23:00 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2278FC1E; Mon, 8 Jun 2009 13:23:00 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 2EACB455BB; Mon, 8 Jun 2009 14:22:59 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id L5IAb7rc-vZH; Mon, 8 Jun 2009 13:22:58 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id E0C664550D; Mon, 8 Jun 2009 14:22:57 +0100 (BST) Message-ID: <4A2D10AB.3040007@thekeelecentre.com> Date: Mon, 08 Jun 2009 14:22:51 +0100 From: Richard Tector User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Kip Macy References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> In-Reply-To: <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Claude Buisson , freebsd-stable@freebsd.org, Pavel Greenberg Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf 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, 08 Jun 2009 13:23:00 -0000 Kip Macy wrote: >> The second bug is the use of LOADER_ZFS_SUPPORT without any >> consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) > I'll try get it fixed by Wednesday. Kip, I noticed a fix went in with revision 193494 but was then backed out straight away with no reason. Will this be fixed soon? It is still not possible to build RELENG_7 sources WITHOUT_CDDL. Regards, Richard From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 14:32:16 2009 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 067AB1065670 for ; Mon, 8 Jun 2009 14:32:16 +0000 (UTC) (envelope-from adamk@voicenet.com) 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 E49B28FC24 for ; Mon, 8 Jun 2009 14:32:12 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 1QSr1c0060cQ2SLAASK2PB; Mon, 08 Jun 2009 14:19:02 +0000 Received: from localhost ([67.103.204.242]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id 1SJs1c00M5EJinX8WSJv6E; Mon, 08 Jun 2009 14:18:59 +0000 Date: Mon, 8 Jun 2009 10:18:37 -0400 From: Adam K Kirchhoff To: freebsd-stable@freebsd.org Message-ID: <20090608101837.79c3b7d7@voicenet.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Problems with PATA disk 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, 08 Jun 2009 14:32:16 -0000 My old workstation finally died and replaced by a Dell Vostro 420. Since the hard drives on the old machine were fine, I decided to throw them into the new machine. The new machine only had SATA onboard, so I added a Promise controller to the mix: atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage It has two SATA connectors and a single PATA connector. I had two PATA drives, so that worked out fine, and I hooked them up. The master was the master in the old machine and the slave was the slave in the old machine. No need to change anything around. At first everything was fine. I booted up (using GENERIC, as I nearly always do) and ran for a while. The machine locked up and I decided to bring the machine up in single user mode and run an fsck. It ran just fine on / /tmp /var and /usr (all on the master drive, ad14). I then ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout' messages (along with various other SETFEATURES messages). They were proceeded by both ad14 and ad15 (though, as I said, ad14 fsck'ed fine). This continued for 30 minutes before I gave up and rebooted. When the machine came back up, ad15 had no partition table or disklabel. And fdisk refused to create a partition. Assuming that the drive had gone bad, I swapped it out with another drive. Created a new partition, and labelled it. Restored /home from backups. It ran for about a week, but locked up on me today (as before, when doing something 3D, so I do not believe the backups are related to disk activity), and I decided to manually run a fsck on the system. Unfortunately, I received the same SETFEATURES messages as before when fsck'ing /home. Instead of letting it run for 30 minutes, I stopped after the messages flashed by the screen. I rebooted. The partition table is hosed and there is no disklabel. When I go to create a new partition (per the directions in /usr/share/doc/handbook/disks-adding.html, which is what I used without any problems when I threw the new drive into the system), this is what I happens: [ root@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) [ root@memory - ~ ]: fdisk -BI ad15 ******* Working on device /dev/ad15 ******* fdisk: invalid fdisk partition table found fdisk: Geom not found: "ad15" [ root@memory - ~ ]: bsdlabel -B -w ad15s1 auto bsdlabel: /dev/ad15s1: No such file or directory And, indeed, there is still only /dev/ad15. So I have a few questions... Why do I keep losing my data? How can I partition and label either one of these drives? Some system information: [ root@memory - ~ ]: uname -a FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 14:02:01 EDT 2009 root@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC i386 [ root@memory - ~ ]: pciconf -vl hostb0@pci0:0:0:0: class=0x060000 card=0x02821028 chip=0x2e208086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uhci0@pci0:0:26:0: class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci1@pci0:0:26:1: class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci2@pci0:0:26:2: class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci0@pci0:0:26:7: class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib2@pci0:0:28:0: class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI uhci3@pci0:0:29:0: class=0x0c0300 card=0x02821028 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci4@pci0:0:29:1: class=0x0c0300 card=0x02821028 chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB uhci5@pci0:0:29:2: class=0x0c0300 card=0x02821028 chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x02821028 chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib5@pci0:0:30:0: class=0x060401 card=0x02821028 chip=0x244e8086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x02821028 chip=0x3a168086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA atapci2@pci0:0:31:2: class=0x010601 card=0x02821028 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = mass storage subclass = SATA none0@pci0:0:31:3: class=0x0c0500 card=0x02821028 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x030000 card=0x30001002 chip=0x5b631002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X550 Series' class = display subclass = VGA vgapci1@pci0:1:0:1: class=0x038000 card=0x30011002 chip=0x5b731002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X550 Series - Secondary' class = display atapci0@pci0:3:0:0: class=0x010185 card=0x02821028 chip=0x2363197b rev=0x03 hdr=0x00 vendor = 'JMicron Technology Corp' device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' class = mass storage subclass = ATA re0@pci0:4:0:0: class=0x020000 card=0x02821028 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet fxp0@pci0:5:0:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet emu10kx0@pci0:5:1:0: class=0x040100 card=0x80641102 chip=0x00021102 rev=0x0a hdr=0x00 vendor = 'Creative Technology LTD.' device = 't4780010004541 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL - CT4780' class = multimedia subclass = audio none1@pci0:5:1:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x0a hdr=0x00 vendor = 'Creative Technology LTD.' device = 'EMU10000 Game Port' class = input device atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' class = mass storage [ root@memory - ~ ]: vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad14 ad15 in sy cs us sy id 0 0 0 194M 2916M 110 0 1 0 91 0 0 0 119 2024 952 0 0 100 Thanks :-) Adam From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 14:45:26 2009 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 856131065670 for ; Mon, 8 Jun 2009 14:45:26 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 40B388FC1B for ; Mon, 8 Jun 2009 14:45:25 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1855380ana.13 for ; Mon, 08 Jun 2009 07:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ndPSokwDdzBHxPWpO8tKub+nxumlpCOugERX+0hnQPI=; b=VmQANcJ9OIhRiQETfeqMRijarFJ65vePLmaI7D34WeFzSt5NDqT/eeHZrww+xlPXlU sB0MtZz8SJFpzdDk7lY8LrxfEgAPALLjUaz7SlgFGjwHmpE+L6H4BMBxpwq30A13olAO IEoGyrSn4vxP2etgsXGRRJgy8lH61r5MsJyfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IhR2d14ndW2TTEU3YDQQLe75HxPeRwkhQcSbPF0fw0N2QcZy3UpkDc+5Vzal/b497A J5rlwSvx23vqJ1T+jc9zVNaP66m3Qpna/+g0E2hndKlHSQ1pqAoo0+UBykicxGPKC3bK w4X7jtnWfmlXNqFlm7ANWqKQIIic+hCDNo62I= MIME-Version: 1.0 Received: by 10.100.13.14 with SMTP id 14mr149362anm.51.1244472325398; Mon, 08 Jun 2009 07:45:25 -0700 (PDT) Date: Mon, 8 Jun 2009 17:45:25 +0300 Message-ID: From: Dan Naumov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: gptzfsboot and RELENG_7 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, 08 Jun 2009 14:45:27 -0000 Hello list Any ideas if gptzfsboot is going to be MFC'ed into RELENG_7 anytime soon? I am going to be building a NAS soon and I would like to have a "full ZFS" system without having to resort to running 8-CURRENT :) Sincerely, - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 14:57:15 2009 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 CEAD7106564A for ; Mon, 8 Jun 2009 14:57:15 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7238FC18 for ; Mon, 8 Jun 2009 14:57:15 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 1NmM1c0040EZKEL56Sk0Zl; Mon, 08 Jun 2009 14:44:00 +0000 Received: from localhost ([67.103.204.242]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 1Sjd1c00C5EJinX3MSjfqL; Mon, 08 Jun 2009 14:43:43 +0000 Date: Mon, 8 Jun 2009 10:43:34 -0400 From: Adam K Kirchhoff To: freebsd-stable@freebsd.org Message-ID: <20090608104334.59a4718c@voicenet.com> In-Reply-To: <20090608101837.79c3b7d7@voicenet.com> References: <20090608101837.79c3b7d7@voicenet.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Problems with PATA disk 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, 08 Jun 2009 14:57:16 -0000 On Mon, 8 Jun 2009 10:18:37 -0400 Adam K Kirchhoff wrote: > > My old workstation finally died and replaced by a Dell Vostro 420. > Since the hard drives on the old machine were fine, I decided to throw > them into the new machine. The new machine only had SATA onboard, so I added a Promise controller to the mix: > > atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 > vendor = 'Promise Technology Inc' > device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' > class = mass storage > > It has two SATA connectors and a single PATA connector. I had two PATA > drives, so that worked out fine, and I hooked them up. The master was > the master in the old machine and the slave was the slave in the old > machine. No need to change anything around. > > At first everything was fine. I booted up (using GENERIC, as I nearly > always do) and ran for a while. The machine locked up and I decided to > bring the machine up in single user mode and run an fsck. It ran just > fine on / /tmp /var and /usr (all on the master drive, ad14). I then > ran the fsck on ad15s1a (/home). Unfortunately, I almost immediately > started receiving 'WARNING - SETFEATURES SET TRANSFER MODE taskqueue > timeout' messages (along with various other SETFEATURES messages). > They were proceeded by both ad14 and ad15 (though, as I said, ad14 > fsck'ed fine). > > This continued for 30 minutes before I gave up and rebooted. When the > machine came back up, ad15 had no partition table or disklabel. And > fdisk refused to create a partition. > > Assuming that the drive had gone bad, I swapped it out with another > drive. Created a new partition, and labelled it. Restored /home from > backups. It ran for about a week, but locked up on me today (as > before, when doing something 3D, so I do not believe the backups are > related to disk activity), and I decided to manually run a fsck on the > system. Unfortunately, I received the same SETFEATURES messages as > before when fsck'ing /home. Instead of letting it run for 30 minutes, I > stopped after the messages flashed by the screen. I rebooted. The > partition table is hosed and there is no disklabel. > > When I go to create a new partition (per the directions > in /usr/share/doc/handbook/disks-adding.html, which is what I used > without any problems when I threw the new drive into the system), this > is what I happens: > > [ root@memory - ~ ]: dd if=/dev/zero of=/dev/ad15 bs=1k count=1 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000118 secs (8676702 bytes/sec) > [ root@memory - ~ ]: fdisk -BI ad15 > ******* Working on device /dev/ad15 ******* > fdisk: invalid fdisk partition table found > fdisk: Geom not found: "ad15" > [ root@memory - ~ ]: bsdlabel -B -w ad15s1 auto > bsdlabel: /dev/ad15s1: No such file or directory > > And, indeed, there is still only /dev/ad15. > > So I have a few questions... > > Why do I keep losing my data? > How can I partition and label either one of these drives? > > Some system information: > > [ root@memory - ~ ]: uname -a > FreeBSD memory.visualtech.com 7.2-STABLE FreeBSD 7.2-STABLE #5: Fri May 8 14:02:01 EDT 2009 root@memory.visualtech.com:/usr/obj/usr/src/sys/GENERIC i386 > [ root@memory - ~ ]: pciconf -vl > hostb0@pci0:0:0:0: class=0x060000 card=0x02821028 chip=0x2e208086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x02821028 chip=0x2e218086 rev=0x03 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:26:0: class=0x0c0300 card=0x02821028 chip=0x3a378086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci1@pci0:0:26:1: class=0x0c0300 card=0x02821028 chip=0x3a388086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci2@pci0:0:26:2: class=0x0c0300 card=0x02821028 chip=0x3a398086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci0@pci0:0:26:7: class=0x0c0320 card=0x02821028 chip=0x3a3c8086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pcib2@pci0:0:28:0: class=0x060400 card=0x02821028 chip=0x3a408086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:1: class=0x060400 card=0x02821028 chip=0x3a428086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > pcib4@pci0:0:28:2: class=0x060400 card=0x02821028 chip=0x3a448086 rev=0x00 hdr=0x01 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-PCI > uhci3@pci0:0:29:0: class=0x0c0300 card=0x02821028 chip=0x3a348086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci4@pci0:0:29:1: class=0x0c0300 card=0x02821028 chip=0x3a358086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > uhci5@pci0:0:29:2: class=0x0c0300 card=0x02821028 chip=0x3a368086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > ehci1@pci0:0:29:7: class=0x0c0320 card=0x02821028 chip=0x3a3a8086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = USB > pcib5@pci0:0:30:0: class=0x060401 card=0x02821028 chip=0x244e8086 rev=0x90 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x02821028 chip=0x3a168086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = PCI-ISA > atapci2@pci0:0:31:2: class=0x010601 card=0x02821028 chip=0x3a228086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = mass storage > subclass = SATA > none0@pci0:0:31:3: class=0x0c0500 card=0x02821028 chip=0x3a308086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > class = serial bus > subclass = SMBus > vgapci0@pci0:1:0:0: class=0x030000 card=0x30001002 chip=0x5b631002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X550 Series' > class = display > subclass = VGA > vgapci1@pci0:1:0:1: class=0x038000 card=0x30011002 chip=0x5b731002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X550 Series - Secondary' > class = display > atapci0@pci0:3:0:0: class=0x010185 card=0x02821028 chip=0x2363197b rev=0x03 hdr=0x00 > vendor = 'JMicron Technology Corp' > device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' > class = mass storage > subclass = ATA > re0@pci0:4:0:0: class=0x020000 card=0x02821028 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > fxp0@pci0:5:0:0: class=0x020000 card=0x000c8086 chip=0x12298086 rev=0x08 hdr=0x00 > vendor = 'Intel Corporation' > device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' > class = network > subclass = ethernet > emu10kx0@pci0:5:1:0: class=0x040100 card=0x80641102 chip=0x00021102 rev=0x0a hdr=0x00 > vendor = 'Creative Technology LTD.' > device = 't4780010004541 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL - CT4780' > class = multimedia > subclass = audio > none1@pci0:5:1:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x0a hdr=0x00 > vendor = 'Creative Technology LTD.' > device = 'EMU10000 Game Port' > class = input device > atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x02 hdr=0x00 > vendor = 'Promise Technology Inc' > device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' > class = mass storage > [ root@memory - ~ ]: vmstat > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad14 ad15 in sy cs us sy id > 0 0 0 194M 2916M 110 0 1 0 91 0 0 0 119 2024 952 0 0 100 > My apologies for replying to my first e-mail. I'm not sure why this didn't occur to me the first time this happened, but I completely powered off my machine, and then powered it back on. It could see the partition table and disklabel on ad15 again. I attempted an fsck, and I received the same errors as before, but this time I hit a kernel panic, too: GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed. Jun 8 14:35:42 memory last message repeated 7 times ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07d4d94 stack pointer = 0x28:0xc62f9c00 frame pointer = 0x28:0xc62f9c18 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m56s Physical memory: 3058 MB Dumping 113 MB: 98 82 66 50 34 18 2 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs Unfortunately, nothing showed up in /var/crash, which I think is odd. I'll update my -STABLE, rebuild my kernel with debugging, and hope to catch something next time. In the mean time, I'd appreciate any help I could get on resolving this problem. Adam From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 15:33:51 2009 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 B49E6106564A for ; Mon, 8 Jun 2009 15:33:51 +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 877528FC24 for ; Mon, 8 Jun 2009 15:33:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3A20F46B58; Mon, 8 Jun 2009 11:33:51 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3E7DE8A06C; Mon, 8 Jun 2009 11:33:50 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 8 Jun 2009 10:45:39 -0400 User-Agent: KMail/1.9.7 References: <20090606071431.092609ce@vaio> In-Reply-To: <20090606071431.092609ce@vaio> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906081045.39497.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Jun 2009 11:33:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Robert Subject: Re: Panic resource_list_alloc 7.2 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, 08 Jun 2009 15:33:52 -0000 On Saturday 06 June 2009 10:14:31 am Robert wrote: > Greetings > > This problem seems the same as this one from May of this year > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > This happens on an older HP laptop. It was running on 7.1 prerelease > fine and then I updated to 7.2 Stable yesterday. > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri Jun 5 > 11:47:29 PDT 2009 > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > The bits from pciconf > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 > rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > class = mass storage > subclass = ATA > > The date of ata-chipset.c > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > The chipset is found in the above file > > ata_intel_ident(device_t dev) > { > struct ata_pci_controller *ctlr = device_get_softc(dev); > static struct ata_chip_id ids[] = > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > ^^^^^^^ > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > I can include the dump if needed but I am not at this time to shorten > the email. But here is the panic. > > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 68939776B (65 MB) > Blocksize: 512 > Dumptime: Sat Jun 6 05:40:52 2009 > Hostname: hp.shasta204.local > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT 2009 > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > Panic String: resource_list_alloc: resource entry is busy > Dump Parity: 3285399556 > Bounds: 1 > Dump Status: good > > > Any help would be greatly appreciated. The last screen of the dmesg output would be helpful. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 15:44:41 2009 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 2C46E1065675 for ; Mon, 8 Jun 2009 15:44:41 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id D91F58FC17 for ; Mon, 8 Jun 2009 15:44:40 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by gxk3 with SMTP id 3so4894260gxk.19 for ; Mon, 08 Jun 2009 08:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YDZ7OOpwcjpYrxbFMhodCjmLempbTtxzBUyho6iJH00=; b=LamIon8TVSh63QfwMm2RUctq1djN98aQyHLOnWsRiV2TVXHweM3Xw1Fxitl5EJ723b O+S0fc85HYUjUbZBDbnfU7j8ur/ov7zwVCX0/OYlt3AdVNqbsH5eUHo6ITN8NkXMjpZG iQz2X8ZMttv/qk7VmCb1TXekdslm4w0vtdRCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HpZ9wlOhs00jfRbfe0Zyi78BcfxrFi2Kuqw2DIVYvUQuWbxKI83MLx9O6+/IBxEpmd z1tEIvr/ovSPQ8UU+i39DL3JUBcuwQGxRiGTwocr+r42CsXBsOwfm3SxZpwG1TLir0WV M/eJ+5Xsjaft3D9ltMOfDaweSGdG9uucwNyAM= MIME-Version: 1.0 Received: by 10.100.152.12 with SMTP id z12mr213704and.96.1244475880126; Mon, 08 Jun 2009 08:44:40 -0700 (PDT) In-Reply-To: <4A2D26D8.8030008@egr.msu.edu> References: <4A2D26D8.8030008@egr.msu.edu> Date: Mon, 8 Jun 2009 18:44:40 +0300 Message-ID: From: Dan Naumov To: Adam McDougall , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: gptzfsboot and RELENG_7 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, 08 Jun 2009 15:44:41 -0000 Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 indicated that even after that MFC, you still needed gptzfsboot from 8-CURRENT to be able to boot from a full ZFS system. Is this not the case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot in my /boot, only gptboot. I didn't make any changes to the stock Makefiles and used GENERIC kernel config. Do I need to adjust some options for gptzfsboot to get built? - Dan Naumov >> > > 5/25/09 - last month > From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 16:49:49 2009 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 D852B106564A for ; Mon, 8 Jun 2009 16:49:49 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCB18FC23 for ; Mon, 8 Jun 2009 16:49:49 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: by fg-out-1718.google.com with SMTP id 22so1091533fge.12 for ; Mon, 08 Jun 2009 09:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=6SDmUxaqNLBQ1RAXcUQT0vUvjhGW8LLxLPWi7ZpWTxk=; b=XdOC2ryIkT+TYFOo8uMWrl2hQmOMhWVaMUDA/M0Q2KWkvMB7lEdRWUJr75NOPExvx9 Cz9EBwRCs+okkPs1Pv6AVYNKcMgUjqhpFffAzImY4Byjfc3E98VD7P8t3Kv0P3rqQoi+ ldkpd8VV9kGkqNPz+NZ30+zzWmG4Ga4NAa5Kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=e85TCg3dr0CTQYcywjCHVY54N1atdp1JkOaWnkOBo/K8EVwF2CrH4xUUCJZ0/9AMoX 7ZbqT0iWKHZIvByJ7Ch+WTzYi64HFWsfz8rlclL3MashMHB1wLpAF5B9tDz6wvArZHku Aj8mW6c4D0odw6BrIh9hALExW1qaZqwjnBlBU= Received: by 10.86.23.20 with SMTP id 20mr7518729fgw.17.1244479788205; Mon, 08 Jun 2009 09:49:48 -0700 (PDT) Received: from echo.hoth (host246-137-dynamic.56-82-r.retail.telecomitalia.it [82.56.137.246]) by mx.google.com with ESMTPS id d6sm172270fga.17.2009.06.08.09.49.47 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 09:49:47 -0700 (PDT) From: Alberto Villa To: freebsd-stable@freebsd.org Date: Mon, 8 Jun 2009 18:49:45 +0200 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <4A2D26D8.8030008@egr.msu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906081849.45373.villa.alberto@gmail.com> Subject: Re: gptzfsboot and RELENG_7 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, 08 Jun 2009 16:49:50 -0000 On Monday 08 June 2009 17:44:40 Dan Naumov wrote: > Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 > indicated that even after that MFC, you still needed gptzfsboot from > 8-CURRENT to be able to boot from a full ZFS system. Is this not the > case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot > in my /boot, only gptboot. I didn't make any changes to the stock > Makefiles and used GENERIC kernel config. Do I need to adjust some > options for gptzfsboot to get built? no, it's /boot/loader from 8-current which is needed (the one shared on this list works perfectly for me) to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes to /etc/make.conf -- Alberto Villa From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 17:05:30 2009 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 8682E1065675 for ; Mon, 8 Jun 2009 17:05:30 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 445FF8FC22 for ; Mon, 8 Jun 2009 17:05:30 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by gxk3 with SMTP id 3so4977287gxk.19 for ; Mon, 08 Jun 2009 10:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jFfLb+jf+L0QNX+3P/GYJkhIpRd+UGyxx6hqs0aQ83c=; b=HSuiqi4ZAnlgqi5AmRTNMkgc+qBGe0hgyNOqlvPb0QoFSYaWPysrrWhoBy5Q8Cp2Ih Le71+EFujsxOBpo2hgMPjgc4lrh2gE9LxYCcQPsr9gyJcONZlUjYVKzGROwLaZLbUg9u badoksh+h5w2tD4CZ/xvfs/VE43VGbR5YS2BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ezDRHdflv3foKx2C5XUOxpKs3YiO2dMgX7rXoSOLGqdQd932k1MruuyIh1QzFS55jv iv4D5xRRZ9eOp7/JfPuOx9PCdsRrx2PEeE4iWBf5i3Y9IBnRS/Jtlw671SNodu1O5Imh 3uUjkktyhmepcrmJE5XmMOIFnrdc02Uaa/USs= MIME-Version: 1.0 Received: by 10.100.213.7 with SMTP id l7mr345057ang.78.1244480729587; Mon, 08 Jun 2009 10:05:29 -0700 (PDT) Date: Mon, 8 Jun 2009 20:05:29 +0300 Message-ID: From: Dan Naumov To: Alberto Villa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7) 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, 08 Jun 2009 17:05:31 -0000 Ah, so there is still a (small) piece of 8-CURRENT needed to have a working 7-STABLE zfs boot configuration? I am getting really confused now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the RELENG_7 system will be built with zfs boot support, but I still need the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into into RELENG_7 anytime soon? Where are all make.conf options documented by the way? Neither /usr/share/examples/etc/make.conf nor "man make.conf" make any reference to the LOADER_ZFS_SUPPORT option. - Dan Naumov On Mon, Jun 8, 2009 at 7:49 PM, Alberto Villa wrote: > On Monday 08 June 2009 17:44:40 Dan Naumov wrote: >> Several posts made to this list AFTER the zfs v13 MFC to RELENG_7 >> indicated that even after that MFC, you still needed gptzfsboot from >> 8-CURRENT to be able to boot from a full ZFS system. Is this not the >> case? I have a 7.2-STABLE built on May 30 and I do not have gptzfsboot >> in my /boot, only gptboot. I didn't make any changes to the stock >> Makefiles and used GENERIC kernel config. Do I need to adjust some >> options for gptzfsboot to get built? > > no, it's /boot/loader from 8-current which is needed (the one shared on this > list works perfectly for me) > to build your system with zfs boot support just add LOADER_ZFS_SUPPORT=yes > to /etc/make.conf > -- > Alberto Villa From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 17:50:20 2009 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 B1DB510656C7 for ; Mon, 8 Jun 2009 17:50:20 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3588FC1C for ; Mon, 8 Jun 2009 17:50:16 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so813313fga.12 for ; Mon, 08 Jun 2009 10:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=a7UUEREApxW150i3A+wt5B+KfpfJr9JIKL4HSLm/5mM=; b=hybafJ/LfJPmzddi/XO9jmGGAuOex26By+BytOcxgGVRLawZWKU6LnLGvOnEqbzE9h OGJ0xPbrbmYQH7jI5+DObwJEWhmepL4+jru+++gj9/tjTx7Oovs649139a7rijN0oz4k 2u3cbjSUbTXjsnhG2K8KLpGddVLuuJa471I/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=ljI/F9+eN3uiBpLbUQJXgZTGD528JXjgbXv1fydoCK9QMz71nve0gIu6qBZlra/XOC 3mBO+iAnYfo6vGVkjzPeh+eGV3lAzNuMPqyxcLbdv4Hqls1HBJxjcStsZUA4vuqdTwt7 2cBoPVpxeY98iT7T5PlqVoYtFMbvb1Vq/pR0Q= Received: by 10.86.96.1 with SMTP id t1mr7498490fgb.68.1244481954991; Mon, 08 Jun 2009 10:25:54 -0700 (PDT) Received: from localhost ([95.69.174.216]) by mx.google.com with ESMTPS id e20sm300449fga.15.2009.06.08.10.25.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 10:25:52 -0700 (PDT) To: freebsd-stable@freebsd.org Organization: TOA Ukraine From: Mikolaj Golub Date: Mon, 08 Jun 2009 20:25:50 +0300 Message-ID: <86d49eocwx.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 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, 08 Jun 2009 17:50:20 -0000 --=-=-= After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled, the previous build was Apr 26), I have been experienced panics when starting some our home made application: Architecture: i386 Architecture Version: 2 Dump Length: 73797632B (70 MB) Blocksize: 512 Dumptime: Mon Jun 8 15:29:14 2009 Hostname: zhuzha.ua1 Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009 root@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG Panic String: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 Dump Parity: 1277108796 Bounds: 18 Narrowing down the problem I have written a simple test program (in attaches) that models in simplified way the behaviour or our application and reproduces the crash. There are two threads. One of the threads is doing vfork/exec to start child process while the other is monitoring the status of the child calling wait4(). At the moment of the crash the parent vfork thread is sleeping on wchan=0xc4d17ae0 (td->td_proc) with lock=0xc4d178b8 waiting for the child to exec. The parent wait4 thread with lock=0xc4d17b70 and the same wchan calls sleepq_lookup(wchan) to check if the wait channel already have a sleep queue associated with it, finds the queue of the vfork thread, tries to insert the current thread into this sleep queue and fails on assertion lock==sq->sq_lock. wait4 treead: (kgdb) thr 128 [Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196 196 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0496509 in db_fncall (dummy1=-1061924641, dummy2=0, dummy3=-1, dummy4=0xe69a089c "") at /usr/src/sys/ddb/db_command.c:516 #2 0xc0496abf in db_command (last_cmdp=0xc0c9ab54, cmd_table=0x0, dopager=0) at /usr/src/sys/ddb/db_command.c:413 #3 0xc0496b34 in db_command_script (command=0xc0c9baa4 "call doadump") at /usr/src/sys/ddb/db_command.c:484 #4 0xc049a3a0 in db_script_exec (scriptname=0xe69a09a8 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available. ) at /usr/src/sys/ddb/db_script.c:302 #5 0xc049a47d in db_script_kdbenter (eventname=0xc0b8fa85 "panic") at /usr/src/sys/ddb/db_script.c:324 #6 0xc0498388 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:227 #7 0xc0810d36 in kdb_trap (type=3, code=0, tf=0xe69a0ae0) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xc0add6ab in trap (frame=0xe69a0ae0) at /usr/src/sys/i386/i386/trap.c:688 #9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #10 0xc0810eba in kdb_enter_why (why=0xc0b8fa85 "panic", msg=0xc0b8fa85 "panic") at cpufunc.h:60 #11 0xc07e4216 in panic (fmt=0xc0b5ecd3 "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:557 #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 #13 0xc07ec94b in _sleep (ident=0xc4d17ae0, lock=Variable "lock" is not available. ) at /usr/src/sys/kern/kern_synch.c:203 #14 0xc07bd8e6 in kern_wait (td=0xc41e8480, pid=-1, status=0xe69a0c2c, options=Variable "options" is not available. ) at /usr/src/sys/kern/kern_exit.c:902 #15 0xc07bd95b in wait4 (td=0xc41e8480, uap=0xe69a0cfc) at /usr/src/sys/kern/kern_exit.c:688 #16 0xc0adce23 in syscall (frame=0xe69a0d38) at /usr/src/sys/i386/i386/trap.c:1090 #17 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 12 #12 0xc08194dc in sleepq_add (wchan=0xc4d17ae0, lock=0xc4d17b70, wmesg=0xc0b959c1 "wait", flags=256, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:327 327 MPASS(lock == sq->sq_lock); (kgdb) p lock $1 = (struct lock_object *) 0xc4d17b70 (kgdb) p sq->sq_lock $2 = (struct lock_object *) 0xc4d178b8 (kgdb) p *lock $3 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} (kgdb) p *sq->sq_lock $4 = {lo_name = 0xc0b8e532 "process lock", lo_type = 0xc0b8e532 "process lock", lo_flags = 21168128, lo_witness_data = {lod_list = {stqe_next = 0xc0ce4840}, lod_witness = 0xc0ce4840}} vfork thread of the parent process: (kgdb) thr 127 [Switching to thread 127 (Thread 100162)]#0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc41e86c0, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc0818bd2 in sleepq_switch (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc0819800 in sleepq_wait (wchan=0xc4d17ae0) at /usr/src/sys/kern/subr_sleepqueue.c:580 #4 0xc07eca69 in _sleep (ident=0xc4d17ae0, lock=0xc4d178b8, priority=92, wmesg=0xc0b8bacb "ppwait", timo=0) at /usr/src/sys/kern/kern_synch.c:230 #5 0xc07c0631 in fork1 (td=0xc41e86c0, flags=-2147483596, pages=0, procp=0xe699ac78) at /usr/src/sys/kern/kern_fork.c:747 #6 0xc07c07c9 in vfork (td=0xc41e86c0, uap=0xe699acfc) at /usr/src/sys/kern/kern_fork.c:124 #7 0xc0adce23 in syscall (frame=0xe699ad38) at /usr/src/sys/i386/i386/trap.c:1090 #8 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #9 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) And here is the child process: (kgdb) thr 129 [Switching to thread 129 (Thread 100163)]#0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xc4d1d900, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 #1 0xc07ec4c3 in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc0818bd2 in sleepq_switch (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:497 #3 0xc0818e6f in sleepq_catch_signals (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:417 #4 0xc0819647 in sleepq_timedwait_sig (wchan=0xc0ccdac4) at /usr/src/sys/kern/subr_sleepqueue.c:631 #5 0xc07eca31 in _sleep (ident=0xc0ccdac4, lock=0x0, priority=348, wmesg=0xc0b90bcd "nanslp", timo=2) at /usr/src/sys/kern/kern_synch.c:224 #6 0xc07f3f51 in kern_nanosleep (td=0xc4d1d900, rqt=0xe699dc64, rmt=0xe699dc6c) at /usr/src/sys/kern/kern_time.c:373 #7 0xc07f594f in nanosleep (td=0xc4d1d900, uap=0xe699dcfc) at /usr/src/sys/kern/kern_time.c:415 #8 0xc0adce23 in syscall (frame=0xe699dd38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p &td->td_proc.p_mtx $5 = (struct mtx *) 0xc4d178b8 Actually, I am not sure that the problem is observed only on the recent STABLE. It might have not been triggered by our application before the upgrade. Currently I don't have the system with some old STABLE to check this running the test program. -- Mikolaj Golub --=-=-=-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 18:12:21 2009 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 1C97C106566C for ; Mon, 8 Jun 2009 18:12:21 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id E5D5F8FC1C for ; Mon, 8 Jun 2009 18:12:20 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id B3E3571F4B7; Mon, 8 Jun 2009 14:12:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvs47PmLiLPE; Mon, 8 Jun 2009 14:12:19 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 9109971F433; Mon, 8 Jun 2009 14:12:19 -0400 (EDT) Message-ID: <4A2D5483.2080004@egr.msu.edu> Date: Mon, 08 Jun 2009 14:12:19 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Alberto Villa Subject: Re: /boot/loader and RELENG_7 (WAS: gptzfsboot and RELENG_7) 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, 08 Jun 2009 18:12:21 -0000 Dan Naumov wrote: > Ah, so there is still a (small) piece of 8-CURRENT needed to have a > working 7-STABLE zfs boot configuration? I am getting really confused > now, if I add LOADER_ZFS_SUPPORT=yes to my /etc/make.conf, the > RELENG_7 system will be built with zfs boot support, but I still need > the actual /boot/loader from 8-CURRENT? Is that getting MFC'ed into > into RELENG_7 anytime soon? > > Where are all make.conf options documented by the way? Neither > /usr/share/examples/etc/make.conf nor "man make.conf" make any > reference to the LOADER_ZFS_SUPPORT option. > > - Dan Naumov > > > ZFS booting without partitions > See the last emails in the thread "ZFS booting without partitions", it has a patch which makes the -stable loader work (some changes that didn't get merged to -stable). I think only the change from 8 to 64 is all thats needed but I applied the whole patch when I tested it. Also, yes LOADER_ZFS_SUPPORT causes gptzfsboot to be compiled as well as add ZFS support to loader (and other stuff). It may not have been documented (I didn't check). From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 18:17:40 2009 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 8E353106566C for ; Mon, 8 Jun 2009 18:17:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 24C0D8FC13 for ; Mon, 8 Jun 2009 18:17:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MDjPc-000OUB-BA; Mon, 08 Jun 2009 21:17:36 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n58IHTvU008727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 21:17:29 +0300 (EEST) (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.3/8.14.3) with ESMTP id n58IHSuF074237; Mon, 8 Jun 2009 21:17:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n58IHSmY074236; Mon, 8 Jun 2009 21:17:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Jun 2009 21:17:28 +0300 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20090608181728.GU1927@deviant.kiev.zoral.com.ua> References: <86d49eocwx.fsf@kopusha.onet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mx4ocXf5NbpB7gU8" Content-Disposition: inline In-Reply-To: <86d49eocwx.fsf@kopusha.onet> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MDjPc-000OUB-BA 82822130c04edd5771eb70daf723cf82 X-Terabit: YES Cc: freebsd-stable@freebsd.org Subject: Re: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 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, 08 Jun 2009 18:17:40 -0000 --mx4ocXf5NbpB7gU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 08, 2009 at 08:25:50PM +0300, Mikolaj Golub wrote: > After recent upgrade (on June 3) of my 7-stable host (WITNESS is enabled,= the > previous build was Apr 26), I have been experienced panics when starting = some > our home made application: >=20 > Architecture: i386=20 > Architecture Version: 2=20 > Dump Length: 73797632B (70 MB)=20 > Blocksize: 512=20 > Dumptime: Mon Jun 8 15:29:14 2009=20 > Hostname: zhuzha.ua1=20 > Magic: FreeBSD Kernel Dump=20 > Version String: FreeBSD 7.2-STABLE #18: Wed Jun 3 14:28:49 EEST 2009= =20 > root@zhuzha.ua1:/usr/obj/usr/src/sys/DEBUG=20 > Panic String: Assertion lock =3D=3D sq->sq_lock failed at /usr/src/sys/= kern/subr_sleepqueue.c:327=20 > Dump Parity: 1277108796=20 > Bounds: 18=20 > =20 > Narrowing down the problem I have written a simple test program (in attac= hes) > that models in simplified way the behaviour or our application and reprod= uces > the crash. There are two threads. One of the threads is doing vfork/exec = to > start child process while the other is monitoring the status of the child > calling wait4(). >=20 > At the moment of the crash the parent vfork thread is sleeping on > wchan=3D0xc4d17ae0 (td->td_proc) with lock=3D0xc4d178b8 waiting for the c= hild to > exec. The parent wait4 thread with lock=3D0xc4d17b70 and the same wchan c= alls > sleepq_lookup(wchan) to check if the wait channel already have a sleep qu= eue > associated with it, finds the queue of the vfork thread, tries to insert = the > current thread into this sleep queue and fails on assertion lock=3D=3Dsq-= >sq_lock. >=20 > wait4 treead: >=20 > (kgdb) thr 128 > [Switching to thread 128 (Thread 100164)]#0 doadump () at pcpu.h:196 > 196 in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc0496509 in db_fncall (dummy1=3D-1061924641, dummy2=3D0, dummy3=3D-= 1, dummy4=3D0xe69a089c "") > at /usr/src/sys/ddb/db_command.c:516 > #2 0xc0496abf in db_command (last_cmdp=3D0xc0c9ab54, cmd_table=3D0x0, do= pager=3D0) > at /usr/src/sys/ddb/db_command.c:413 > #3 0xc0496b34 in db_command_script (command=3D0xc0c9baa4 "call doadump") > at /usr/src/sys/ddb/db_command.c:484 > #4 0xc049a3a0 in db_script_exec (scriptname=3D0xe69a09a8 "kdb.enter.pani= c", warnifnotfound=3DVariable "warnifnotfound" is not available. > ) > at /usr/src/sys/ddb/db_script.c:302 > #5 0xc049a47d in db_script_kdbenter (eventname=3D0xc0b8fa85 "panic") at = /usr/src/sys/ddb/db_script.c:324 > #6 0xc0498388 in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_mai= n.c:227 > #7 0xc0810d36 in kdb_trap (type=3D3, code=3D0, tf=3D0xe69a0ae0) at /usr/= src/sys/kern/subr_kdb.c:524 > #8 0xc0add6ab in trap (frame=3D0xe69a0ae0) at /usr/src/sys/i386/i386/tra= p.c:688 > #9 0xc0ac159b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #10 0xc0810eba in kdb_enter_why (why=3D0xc0b8fa85 "panic", msg=3D0xc0b8fa= 85 "panic") at cpufunc.h:60 > #11 0xc07e4216 in panic (fmt=3D0xc0b5ecd3 "Assertion %s failed at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:557 > #12 0xc08194dc in sleepq_add (wchan=3D0xc4d17ae0, lock=3D0xc4d17b70, wmes= g=3D0xc0b959c1 "wait", flags=3D256,=20 > queue=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:327 > #13 0xc07ec94b in _sleep (ident=3D0xc4d17ae0, lock=3DVariable "lock" is n= ot available. > ) at /usr/src/sys/kern/kern_synch.c:203 > #14 0xc07bd8e6 in kern_wait (td=3D0xc41e8480, pid=3D-1, status=3D0xe69a0c= 2c, options=3DVariable "options" is not available. > ) > at /usr/src/sys/kern/kern_exit.c:902 > #15 0xc07bd95b in wait4 (td=3D0xc41e8480, uap=3D0xe69a0cfc) at /usr/src/s= ys/kern/kern_exit.c:688 > #16 0xc0adce23 in syscall (frame=3D0xe69a0d38) at /usr/src/sys/i386/i386/= trap.c:1090 > #17 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:255 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 12 > #12 0xc08194dc in sleepq_add (wchan=3D0xc4d17ae0, lock=3D0xc4d17b70, wmes= g=3D0xc0b959c1 "wait", flags=3D256,=20 > queue=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:327 > 327 MPASS(lock =3D=3D sq->sq_lock); > (kgdb) p lock > $1 =3D (struct lock_object *) 0xc4d17b70 > (kgdb) p sq->sq_lock > $2 =3D (struct lock_object *) 0xc4d178b8 > (kgdb) p *lock > $3 =3D {lo_name =3D 0xc0b8e532 "process lock", lo_type =3D 0xc0b8e532 "pr= ocess lock", lo_flags =3D 21168128,=20 > lo_witness_data =3D {lod_list =3D {stqe_next =3D 0xc0ce4840}, lod_witne= ss =3D 0xc0ce4840}} > (kgdb) p *sq->sq_lock > $4 =3D {lo_name =3D 0xc0b8e532 "process lock", lo_type =3D 0xc0b8e532 "pr= ocess lock", lo_flags =3D 21168128,=20 > lo_witness_data =3D {lod_list =3D {stqe_next =3D 0xc0ce4840}, lod_witne= ss =3D 0xc0ce4840}} >=20 > vfork thread of the parent process: >=20 > (kgdb) thr 127 > [Switching to thread 127 (Thread 100162)]#0 sched_switch (td=3D0xc41e86c= 0, newtd=3DVariable "newtd" is not available. > ) > at /usr/src/sys/kern/sched_ule.c:1944 > 1944 cpuid =3D PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=3D0xc41e86c0, newtd=3DVariable "newtd" is not availa= ble. > ) at /usr/src/sys/kern/sched_ule.c:1944 > #1 0xc07ec4c3 in mi_switch (flags=3DVariable "flags" is not available. > ) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc0818bd2 in sleepq_switch (wchan=3D0xc4d17ae0) at /usr/src/sys/kern= /subr_sleepqueue.c:497 > #3 0xc0819800 in sleepq_wait (wchan=3D0xc4d17ae0) at /usr/src/sys/kern/s= ubr_sleepqueue.c:580 > #4 0xc07eca69 in _sleep (ident=3D0xc4d17ae0, lock=3D0xc4d178b8, priority= =3D92, wmesg=3D0xc0b8bacb "ppwait",=20 > timo=3D0) at /usr/src/sys/kern/kern_synch.c:230 > #5 0xc07c0631 in fork1 (td=3D0xc41e86c0, flags=3D-2147483596, pages=3D0,= procp=3D0xe699ac78) > at /usr/src/sys/kern/kern_fork.c:747 > #6 0xc07c07c9 in vfork (td=3D0xc41e86c0, uap=3D0xe699acfc) at /usr/src/s= ys/kern/kern_fork.c:124 > #7 0xc0adce23 in syscall (frame=3D0xe699ad38) at /usr/src/sys/i386/i386/= trap.c:1090 > #8 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:255 > #9 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > And here is the child process: >=20 > (kgdb) thr 129 > [Switching to thread 129 (Thread 100163)]#0 sched_switch (td=3D0xc4d1d90= 0, newtd=3DVariable "newtd" is not available. > ) > at /usr/src/sys/kern/sched_ule.c:1944 > 1944 cpuid =3D PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=3D0xc4d1d900, newtd=3DVariable "newtd" is not availa= ble. > ) at /usr/src/sys/kern/sched_ule.c:1944 > #1 0xc07ec4c3 in mi_switch (flags=3DVariable "flags" is not available. > ) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc0818bd2 in sleepq_switch (wchan=3D0xc0ccdac4) at /usr/src/sys/kern= /subr_sleepqueue.c:497 > #3 0xc0818e6f in sleepq_catch_signals (wchan=3D0xc0ccdac4) at /usr/src/s= ys/kern/subr_sleepqueue.c:417 > #4 0xc0819647 in sleepq_timedwait_sig (wchan=3D0xc0ccdac4) at /usr/src/s= ys/kern/subr_sleepqueue.c:631 > #5 0xc07eca31 in _sleep (ident=3D0xc0ccdac4, lock=3D0x0, priority=3D348,= wmesg=3D0xc0b90bcd "nanslp", timo=3D2) > at /usr/src/sys/kern/kern_synch.c:224 > #6 0xc07f3f51 in kern_nanosleep (td=3D0xc4d1d900, rqt=3D0xe699dc64, rmt= =3D0xe699dc6c) > at /usr/src/sys/kern/kern_time.c:373 > #7 0xc07f594f in nanosleep (td=3D0xc4d1d900, uap=3D0xe699dcfc) at /usr/s= rc/sys/kern/kern_time.c:415 > #8 0xc0adce23 in syscall (frame=3D0xe699dd38) at /usr/src/sys/i386/i386/= trap.c:1090 > #9 0xc0ac1600 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:255 > #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p &td->td_proc.p_mtx > $5 =3D (struct mtx *) 0xc4d178b8 >=20 > Actually, I am not sure that the problem is observed only on the recent > STABLE. It might have not been triggered by our application before the > upgrade. Currently I don't have the system with some old STABLE to check = this > running the test program. This is fixed in HEAD by r185647. I did not merged it to 7, because I do not believe that somebody runs stable with INVARIANTS on :). --mx4ocXf5NbpB7gU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkotVbgACgkQC3+MBN1Mb4gTIACgmGEHHMIx/s7s/Qg31guguDrZ YO0An1zFxwnW3/PZCCbE7Vva7Frf+wiF =+RwY -----END PGP SIGNATURE----- --mx4ocXf5NbpB7gU8-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 19:42:02 2009 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 099621065670 for ; Mon, 8 Jun 2009 19:42:02 +0000 (UTC) (envelope-from bjb@darco.dk) Received: from pasmtpA.tele.dk (pasmtpa.tele.dk [80.160.77.114]) by mx1.freebsd.org (Postfix) with ESMTP id 534E58FC15 for ; Mon, 8 Jun 2009 19:42:01 +0000 (UTC) (envelope-from bjb@darco.dk) Received: from v8.blichsoft.dk (0x503e00ba.cpe.ge-0-2-0-1101.banqu1.customer.tele.dk [80.62.0.186]) by pasmtpA.tele.dk (Postfix) with ESMTP id 032B2800577 for ; Mon, 8 Jun 2009 21:22:19 +0200 (CEST) Received: by v8.blichsoft.dk (Postfix, from userid 110) id B43E54391; Mon, 8 Jun 2009 21:22:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on v8.blichsoft.dk X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=ham version=3.2.5 Received: from [192.168.1.200] (sussi [192.168.1.200]) by v8.blichsoft.dk (Postfix) with ESMTP id 99D2B438E for ; Mon, 8 Jun 2009 21:21:55 +0200 (CEST) Message-ID: <4A2D64D4.9060106@darco.dk> Date: Mon, 08 Jun 2009 21:21:56 +0200 From: Bjarne User-Agent: Thunderbird 2.0.0.21 (X11/20090310) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan / ClamAV 0.95.1/9436/Mon Jun 8 02:21:18 2009 Subject: flooded with "ath0: stuck beacon; resetting (bmiss count 4)" after upgrade to 7.2-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, 08 Jun 2009 19:42:02 -0000 After upgrading from FreeBSD 7.1-RELEASE to FreeBSD 7.2-STABLE I Get a gazillion of these : kernel: ath0: stuck beacon; resetting (bmiss count 4) in /var/log/messages Mostly when all workstations are turned off. The messagestorm slows down after the first workstation has connected, but there are still a LOT of messages The Hardware is exactly the same as before the upgrade. No change whatsoever. I am uing the atheros card as a host AP and I have tried different settings with ifconfig like -bgscan to no avail. So please : how to stop these emssages ? v8 # ifconfig ath0 ath0: flags=8943 metric 0 mtu 2290 ether 00:18:4d:ec:7d:07 inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid XXXXXX channel 1 (2412 Mhz 11g) bssid 00:18:4d:ec:7d:07 authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 1000 protmode CTS burst hidessid dtimperiod 1 Current dmesg from 7.2 stable : ================================================= Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #2: Sun Jun 7 17:14:11 CEST 2009 toor@v8.YYYYY.dk:/usr/obj/usr/src/sys/V8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1600+ (1401.72-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 773959680 (738 MB) kbd1 at kbdmux0 acpi0: <761686 AWRDACPI> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc800-0xc81f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) vgapci0: mem 0xf0000000-0xf0003fff,0xf1000000-0xf17fffff irq 5 at device 11.0 on pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xd000-0xd03f irq 12 at device 15.0 on pci0 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:57:5a:bf xl0: [ITHREAD] ath0: mem 0xf3000000-0xf300ffff irq 10 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:ec:7d:07 ath0: mac 7.9 phy 4.5 radio 5.6 atapci1: port 0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe4ff irq 11 at device 19.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1401715949 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA66 ad4: 152627MB at ata2-master UDMA100 ad6: 152627MB at ata3-master UDMA100 GEOM_MIRROR: Device mirror/gm0s1 launched (1/1). GEOM_MIRROR: Device gm0s1: provider ad6s1 marked as inactive, skipping. GEOM_LABEL: Label for provider ad4s1a is ufsid/43764dd0e4c68fd0. GEOM_LABEL: Label for provider ad4s1d is ufsid/43764dd570a98422. GEOM_LABEL: Label for provider ad4s1e is ufsid/43764dd8ec27faff. GEOM_LABEL: Label for provider ad4s1f is ufsid/43764ddc8f945f3f. Trying to mount root from ufs:/dev/mirror/gm0s1a bridge0: Ethernet address: 42:87:0c:b1:1e:f6 ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ============================== dmesg from 7.1-release : (same hardware - with no problems) ============================== Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE-p4 #0: Sun Apr 5 20:22:16 CEST 2009 toor@v8.YYYYY.dk:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1600+ (1401.72-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383f9ff AMD Features=0xc0480800 real memory = 805240832 (767 MB) avail memory = 773980160 (738 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: <761686 AWRDACPI> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc400-0xc40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc800-0xc81f irq 5 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 5 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) vgapci0: mem 0xf0000000-0xf0003fff,0xf1000000-0xf17fffff irq 5 at device 11.0 on pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xd000-0xd03f irq 12 at device 15.0 on pci0 miibus0: on xl0 nsphy0: PHY 24 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:57:5a:bf xl0: [ITHREAD] ath0: mem 0xf3000000-0xf300ffff irq 10 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:ec:7d:07 ath0: mac 7.9 phy 4.5 radio 5.6 atapci1: port 0xd400-0xd407,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe4ff irq 11 at device 19.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1401715696 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA66 ad4: 152627MB at ata2-master UDMA100 ad6: 152627MB at ata3-master UDMA100 GEOM_MIRROR: Device gm0s1: provider ad4s1 marked as inactive, skipping. Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device gm0s1 start due to timeout. GEOM_MIRROR: Device mirror/gm0s1 launched (2/3). Trying to mount root from ufs:/dev/mirror/gm0s1a bridge0: Ethernet address: 9e:0e:a9:07:08:01 ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 22:42:26 2009 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 CAEAB1065677; Mon, 8 Jun 2009 22:42:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A0FD78FC19; Mon, 8 Jun 2009 22:42:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n58MgLBS097304; Mon, 8 Jun 2009 18:42:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n58MgLZI013851; Mon, 8 Jun 2009 18:42:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 42C7C1B5060; Mon, 8 Jun 2009 18:42:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090608224221.42C7C1B5060@freebsd-stable.sentex.ca> Date: Mon, 8 Jun 2009 18:42:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 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: Mon, 08 Jun 2009 22:42:27 -0000 TB --- 2009-06-08 21:28:33 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 21:28:33 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-08 21:28:33 - cleaning the object tree TB --- 2009-06-08 21:28:56 - cvsupping the source tree TB --- 2009-06-08 21:28:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-08 21:29:10 - building world TB --- 2009-06-08 21:29:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 21:29:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 21:29:10 - TARGET=i386 TB --- 2009-06-08 21:29:10 - TARGET_ARCH=i386 TB --- 2009-06-08 21:29:10 - TZ=UTC TB --- 2009-06-08 21:29:10 - __MAKE_CONF=/dev/null TB --- 2009-06-08 21:29:10 - cd /src TB --- 2009-06-08 21:29:10 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 21:29:11 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 8 22:36:06 UTC 2009 TB --- 2009-06-08 22:36:06 - generating LINT kernel config TB --- 2009-06-08 22:36:06 - cd /src/sys/i386/conf TB --- 2009-06-08 22:36:06 - /usr/bin/make -B LINT TB --- 2009-06-08 22:36:06 - building LINT kernel TB --- 2009-06-08 22:36:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:36:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:36:06 - TARGET=i386 TB --- 2009-06-08 22:36:06 - TARGET_ARCH=i386 TB --- 2009-06-08 22:36:06 - TZ=UTC TB --- 2009-06-08 22:36:06 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:36:06 - cd /src TB --- 2009-06-08 22:36:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 22:36:06 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 22:42:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 22:42:21 - ERROR: failed to build lint kernel TB --- 2009-06-08 22:42:21 - 3545.02 user 387.44 system 4427.29 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 22:50:30 2009 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 1FC85106566B; Mon, 8 Jun 2009 22:50:30 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id D9A1B8FC18; Mon, 8 Jun 2009 22:50:29 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n58MoG99004928; Tue, 9 Jun 2009 07:50:17 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: Attilio Rao References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Date: Tue, 09 Jun 2009 07:50:15 +0900 In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") Message-ID: <863aaagx20.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-5.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,NO_RELAYS,QENCPTR1 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Big problem still remains with 7.2-STABLE locking up 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, 08 Jun 2009 22:50:30 -0000 I got a lockup at 3 a.m. JST, but because I'm not ready for dcons I cannot show you guys the whole ddb session. I put a 'bt' output of kgdb. http://www.heimat.gr.jp/localhost/kgdbbtvmcore.0 Kernel config: include GENERIC ident HEIMAT options MSGBUF_SIZE=81920 makeoptions DEBUG=-g options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options BREAK_TO_DEBUGGER options QUOTA options DEVICE_POLLING options HZ=1000 options SW_WATCHDOG options DEBUG_VFS_LOCKS options INVARIANTS options INVARIANT_SUPPORT options WITNESS Thanks. P.S. "allthreads" was not a usable command in my RELENG_7's ddb. >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> >>>>> Attilio Rao wrote: > Anyways, the only one way we have to debug this is getting some help > by the user. > 1) Drop the option WITNESS_SPIKSPIN (as we would like to debug > spinlocks too) and LOCK_PROFILING (in order to create higher > contention and kill some barriers) > 2) Once you get the deadlock break in the DDB debugger > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) > Let me know. > Attilio -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 23:55:35 2009 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 63419106566C; Mon, 8 Jun 2009 23:55:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 386A98FC12; Mon, 8 Jun 2009 23:55:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n58NtUJv003633; Mon, 8 Jun 2009 19:55:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n58NtUGw066066; Mon, 8 Jun 2009 19:55:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 6B3561B5060; Mon, 8 Jun 2009 19:55:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090608235530.6B3561B5060@freebsd-stable.sentex.ca> Date: Mon, 8 Jun 2009 19:55:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 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: Mon, 08 Jun 2009 23:55:36 -0000 TB --- 2009-06-08 22:42:21 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:21 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-08 22:42:21 - cleaning the object tree TB --- 2009-06-08 22:42:52 - cvsupping the source tree TB --- 2009-06-08 22:42:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-08 22:43:04 - building world TB --- 2009-06-08 22:43:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:04 - TARGET=pc98 TB --- 2009-06-08 22:43:04 - TARGET_ARCH=i386 TB --- 2009-06-08 22:43:04 - TZ=UTC TB --- 2009-06-08 22:43:04 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:04 - cd /src TB --- 2009-06-08 22:43:04 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jun 8 23:50:39 UTC 2009 TB --- 2009-06-08 23:50:39 - generating LINT kernel config TB --- 2009-06-08 23:50:39 - cd /src/sys/pc98/conf TB --- 2009-06-08 23:50:39 - /usr/bin/make -B LINT TB --- 2009-06-08 23:50:39 - building LINT kernel TB --- 2009-06-08 23:50:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:50:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:50:39 - TARGET=pc98 TB --- 2009-06-08 23:50:39 - TARGET_ARCH=i386 TB --- 2009-06-08 23:50:39 - TZ=UTC TB --- 2009-06-08 23:50:39 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:50:39 - cd /src TB --- 2009-06-08 23:50:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 8 23:50:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-08 23:55:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-08 23:55:30 - ERROR: failed to build lint kernel TB --- 2009-06-08 23:55:30 - 3445.74 user 392.66 system 4388.88 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 00:18:44 2009 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 5FE871065672; Tue, 9 Jun 2009 00:18:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 367588FC14; Tue, 9 Jun 2009 00:18:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n590Idaw054961; Mon, 8 Jun 2009 20:18:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n590Idbe023383; Mon, 8 Jun 2009 20:18:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id AB5B41B5060; Mon, 8 Jun 2009 20:18:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609001839.AB5B41B5060@freebsd-stable.sentex.ca> Date: Mon, 8 Jun 2009 20:18:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 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: Tue, 09 Jun 2009 00:18:45 -0000 TB --- 2009-06-08 22:42:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 22:42:38 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-08 22:42:39 - cleaning the object tree TB --- 2009-06-08 22:43:09 - cvsupping the source tree TB --- 2009-06-08 22:43:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-08 22:43:20 - building world TB --- 2009-06-08 22:43:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 22:43:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 22:43:20 - TARGET=ia64 TB --- 2009-06-08 22:43:20 - TARGET_ARCH=ia64 TB --- 2009-06-08 22:43:20 - TZ=UTC TB --- 2009-06-08 22:43:20 - __MAKE_CONF=/dev/null TB --- 2009-06-08 22:43:20 - cd /src TB --- 2009-06-08 22:43:20 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 22:43:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 00:12:39 UTC 2009 TB --- 2009-06-09 00:12:39 - generating LINT kernel config TB --- 2009-06-09 00:12:39 - cd /src/sys/ia64/conf TB --- 2009-06-09 00:12:39 - /usr/bin/make -B LINT TB --- 2009-06-09 00:12:39 - building LINT kernel TB --- 2009-06-09 00:12:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:12:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:12:39 - TARGET=ia64 TB --- 2009-06-09 00:12:39 - TARGET_ARCH=ia64 TB --- 2009-06-09 00:12:39 - TZ=UTC TB --- 2009-06-09 00:12:39 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:12:39 - cd /src TB --- 2009-06-09 00:12:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 00:12:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 00:18:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 00:18:39 - ERROR: failed to build lint kernel TB --- 2009-06-09 00:18:39 - 4806.28 user 390.27 system 5760.57 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 01:08:50 2009 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 072391065675; Tue, 9 Jun 2009 01:08:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D0BD08FC0A; Tue, 9 Jun 2009 01:08:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5918jvm009689; Mon, 8 Jun 2009 21:08:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5918jwC047261; Mon, 8 Jun 2009 21:08:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 48F961B5060; Mon, 8 Jun 2009 21:08:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609010845.48F961B5060@freebsd-stable.sentex.ca> Date: Mon, 8 Jun 2009 21:08:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 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: Tue, 09 Jun 2009 01:08:50 -0000 TB --- 2009-06-08 23:55:30 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-08 23:55:30 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-06-08 23:55:30 - cleaning the object tree TB --- 2009-06-08 23:55:50 - cvsupping the source tree TB --- 2009-06-08 23:55:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-06-08 23:56:02 - building world TB --- 2009-06-08 23:56:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-08 23:56:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-08 23:56:02 - TARGET=powerpc TB --- 2009-06-08 23:56:02 - TARGET_ARCH=powerpc TB --- 2009-06-08 23:56:02 - TZ=UTC TB --- 2009-06-08 23:56:02 - __MAKE_CONF=/dev/null TB --- 2009-06-08 23:56:02 - cd /src TB --- 2009-06-08 23:56:02 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 8 23:56:03 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 01:04:55 UTC 2009 TB --- 2009-06-09 01:04:55 - generating LINT kernel config TB --- 2009-06-09 01:04:55 - cd /src/sys/powerpc/conf TB --- 2009-06-09 01:04:55 - /usr/bin/make -B LINT TB --- 2009-06-09 01:04:55 - building LINT kernel TB --- 2009-06-09 01:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:04:55 - TARGET=powerpc TB --- 2009-06-09 01:04:55 - TARGET_ARCH=powerpc TB --- 2009-06-09 01:04:55 - TZ=UTC TB --- 2009-06-09 01:04:55 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:04:55 - cd /src TB --- 2009-06-09 01:04:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:04:55 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:08:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:08:45 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:08:45 - 3564.34 user 363.25 system 4394.38 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 01:27:21 2009 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 4B743106566B; Tue, 9 Jun 2009 01:27:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE7C8FC13; Tue, 9 Jun 2009 01:27:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n591RIdv011321; Mon, 8 Jun 2009 21:27:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n591RIFG056176; Mon, 8 Jun 2009 21:27:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id BAEB01B5060; Mon, 8 Jun 2009 21:27:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609012718.BAEB01B5060@freebsd-stable.sentex.ca> Date: Mon, 8 Jun 2009 21:27:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on sparc64/sparc64 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: Tue, 09 Jun 2009 01:27:22 -0000 TB --- 2009-06-09 00:18:40 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 00:18:40 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2009-06-09 00:18:40 - cleaning the object tree TB --- 2009-06-09 00:19:03 - cvsupping the source tree TB --- 2009-06-09 00:19:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2009-06-09 00:19:15 - building world TB --- 2009-06-09 00:19:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 00:19:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 00:19:15 - TARGET=sparc64 TB --- 2009-06-09 00:19:15 - TARGET_ARCH=sparc64 TB --- 2009-06-09 00:19:15 - TZ=UTC TB --- 2009-06-09 00:19:15 - __MAKE_CONF=/dev/null TB --- 2009-06-09 00:19:15 - cd /src TB --- 2009-06-09 00:19:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 00:19:17 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 01:23:22 UTC 2009 TB --- 2009-06-09 01:23:22 - generating LINT kernel config TB --- 2009-06-09 01:23:22 - cd /src/sys/sparc64/conf TB --- 2009-06-09 01:23:22 - /usr/bin/make -B LINT TB --- 2009-06-09 01:23:22 - building LINT kernel TB --- 2009-06-09 01:23:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 01:23:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 01:23:22 - TARGET=sparc64 TB --- 2009-06-09 01:23:22 - TARGET_ARCH=sparc64 TB --- 2009-06-09 01:23:22 - TZ=UTC TB --- 2009-06-09 01:23:22 - __MAKE_CONF=/dev/null TB --- 2009-06-09 01:23:22 - cd /src TB --- 2009-06-09 01:23:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 01:23:22 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 01:27:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 01:27:18 - ERROR: failed to build lint kernel TB --- 2009-06-09 01:27:18 - 3339.84 user 359.49 system 4118.37 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 02:16:04 2009 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 A1BDC106566C for ; Tue, 9 Jun 2009 02:16:04 +0000 (UTC) (envelope-from pete@altadena.net) Received: from puffin.altadena.net (puffin.altadena.net [173.10.157.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6938FC1F for ; Tue, 9 Jun 2009 02:16:04 +0000 (UTC) (envelope-from pete@altadena.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=2.puffin; d=altadena.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=qX6Kkz4Ws71Wiedk4CIz/wH27AcX2DluGrib3riv8M9mj0ouu1xxYlKM4dCzfVYoMUALxcLCGwrI9yGQ44D5Nr7H3/xS6yejvdSNdUE+Fp0ZsTGOGKRBdn/zcYxgENQh8WHS9PujHccWDVxFx03HcZ0f+7pKU7tz+QJRLcbGjr8=; Received: from gate.east.altadena.net ([173.10.157.233] helo=port4l.altadena.net) by puffin.altadena.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MDqVj-000K8t-LG for stable@freebsd.org; Mon, 08 Jun 2009 21:52:23 -0400 Message-ID: <4A2DC056.8090500@altadena.net> Date: Mon, 08 Jun 2009 21:52:22 -0400 From: Pete Carah User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Bug between DRM, MSI, or somewhere, re7-stable 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: Tue, 09 Jun 2009 02:16:04 -0000 I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I had been running 7-stable i386 with few problems) and have acquired an apparent irq problem. Fortunately in debugging a linux shared-interrupt problem about a month ago I learned that the X server will happily accept mouse motion as if it was a display interrupt, so at least with some inconvenience I can read the screen... (the keyboard isn't so obliging) Ours does this too... /usr/src was picked up via svn on last Saturday morning EDT, ports via csup about the same time. I have no idea if this bug is in the intel driver, drm, or the core msi code... There are 2 peripherals that dmesg says uses msi - re0 (which doesn't get a kernel thread indicated in ps for either the stated irq (257) or re0) and drm0/vgapci0 (which indicates irq256 in systat and ps). As I said, this worked properly with earlier source (about a week) in i386 mode. I've used both G45 and re controllers in (f10) linux msi mode with no problems in both 32 and 64-bit. Fortunately this laptop now has enough disk to triple-boot so at least something works... I am using svn instead of csup because I am trying (haven't gotten time yet either :-) to port Sam's ath 92xx code to -stable and handling code porting is much easier that way. -- Pete From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 06:37:03 2009 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 CA487106566C; Tue, 9 Jun 2009 06:37:03 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3E78C8FC19; Tue, 9 Jun 2009 06:37:02 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm10 with SMTP id 10so863661fxm.43 for ; Mon, 08 Jun 2009 23:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.114.135 with SMTP id e7mr4863286faq.89.1244529422082; Mon, 08 Jun 2009 23:37:02 -0700 (PDT) In-Reply-To: References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> From: Vlad Galu Date: Tue, 9 Jun 2009 09:36:42 +0300 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores 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, 09 Jun 2009 06:37:04 -0000 On Mon, Jun 8, 2009 at 3:57 PM, Ivan Voras wrote: > On a completely unrelated subject I was reading about PHP APC cache > where they have the same need - cross-process locking with locks > embedded in data structures and they have adopted userland spinlock code > from PostgreSQL: > > http://www.scribd.com/doc/3288293/brian-shireapc-facebook > > (spin)locks are not the same as sempahores but maybe it will help the OP > or anyone else trying to implement this feature: > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup > > http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup Thanks, Ivan. I'll take a better look at this after our first release, which is due in a couple of weeks. Right now the team efforts aren't focused on portability, so it's a low priority issue, but something we'd definitely like to have in the future. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 07:26:26 2009 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 3D292106566B for ; Tue, 9 Jun 2009 07:26:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0A86A8FC18 for ; Tue, 9 Jun 2009 07:26:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8B64235F3A1; Tue, 9 Jun 2009 03:26:25 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 09 Jun 2009 03:26:25 -0400 X-Sasl-enc: fw97mea7S460TXgCbyVJbQwMViwPZl/T+p9oWeB1nJpr 1244532385 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id DF7D25AC9C; Tue, 9 Jun 2009 03:26:24 -0400 (EDT) Message-ID: <4A2E0E9F.8050708@incunabulum.net> Date: Tue, 09 Jun 2009 08:26:23 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vlad Galu References: <20090601161903.GA40377@stack.nl> <4A24457C.6060100@FreeBSD.org> <200906020842.42330.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Unnamed POSIX shared semaphores 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, 09 Jun 2009 07:26:26 -0000 Vlad Galu wrote: > ... > Thanks, Ivan. I'll take a better look at this after our first release, > which is due in a couple of weeks. Right now the team efforts aren't > focused on portability, so it's a low priority issue, but something > we'd definitely like to have in the future. > I stand corrected. Having read around this, I don't see how process-shared sems could work at all, although I haven't actually tried running process-shared sem code. POSIX semaphores were however horribly broken in kernel prior to 7.2. The fix was essentially one liner. We got a very good test case from a chap in a GNATS PR. cheers BMS From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 08:34:59 2009 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 1ADB71065691 for ; Tue, 9 Jun 2009 08:34:59 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id A448E8FC1F for ; Tue, 9 Jun 2009 08:34:58 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDwFO-000JE8-4V; Tue, 09 Jun 2009 09:59:57 +0200 Message-ID: <4A2E167A.3000902@kkip.pl> Date: Tue, 09 Jun 2009 09:59:54 +0200 From: Bartosz Stec User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adam K Kirchhoff References: <20090608101837.79c3b7d7@voicenet.com> <20090608104334.59a4718c@voicenet.com> In-Reply-To: <20090608104334.59a4718c@voicenet.com> X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.8 X-Spam-Score-Int: -87 X-Exim-Version: 4.69 (build at 04-Jun-2009 16:07:02) X-Date: 2009-06-09 09:59:57 X-Connected-IP: 10.66.3.254:1705 X-Message-Linecount: 191 X-Body-Linecount: 177 X-Message-Size: 8039 X-Body-Size: 7460 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Problems with PATA disk 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, 09 Jun 2009 08:35:00 -0000 Adam K Kirchhoff wrote: >> atapci1@pci0:5:3:0: class=0x018000 card=0x3375105a chip=0x3375105a rev=0x020 >> vendor = 'Promise Technology Inc' >> device = 'PDC20375(??) FastTrak SATA150 TX2plus Controller' >> class = mass storage >> This happens frequently with Promise TX2/TX4 (less frequently in RELENG-7 than RELENG-6) and issue is probably related to controller driver. > > GEOM_LABEL: Label ufsid/4a296b573007b5f2 removed. > Jun 8 14:35:42 memory last message repeated 7 times > ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad14: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request directly > ad14: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad15: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > ad15: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad15: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=470440143 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x188 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07d4d94 > stack pointer = 0x28:0xc62f9c00 > frame pointer = 0x28:0xc62f9c18 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 23 (swi6: task queue) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m56s > Physical memory: 3058 MB > Dumping 113 MB: 98 82 66 50 34 18 2 > Dump complete > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Stopping other CPUs > > Unfortunately, nothing showed up in /var/crash, which I think is odd. > I'll update my -STABLE, rebuild my kernel with debugging, and hope to > catch something next time. > > In this case controller probably loose whole drive (disconnected and dissapear from 'atacontrol list'), that's why you see no core dropped, and powering machine off and on let it recognize the drive again. I have this issue from time to time with TX4, but fortunately i have 2 disks in gmirror, so when one drive disconnect I force rebuilding mirro by just powering machine off and on. You're using 7.2-stable, so it seems that OS upgrade won't help you (after upgrade from FreeBSD 6 to 7 issue has been seen 80% less frequently for me), so my one and only suggestion for you is using different PATA controller if you can. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 11:20:04 2009 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 2A733106566B for ; Tue, 9 Jun 2009 11:20:04 +0000 (UTC) (envelope-from jkoshy.freebsd@gmail.com) Received: from mail-px0-f199.google.com (mail-px0-f199.google.com [209.85.216.199]) by mx1.freebsd.org (Postfix) with ESMTP id EC16B8FC13 for ; Tue, 9 Jun 2009 11:20:03 +0000 (UTC) (envelope-from jkoshy.freebsd@gmail.com) Received: by pxi37 with SMTP id 37so3334247pxi.3 for ; Tue, 09 Jun 2009 04:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:to:cc :subject:in-reply-to:references:user-agent:mime-version:content-type :from:date; bh=kJMCogx7MkQf5DAfmKFBVWWKib49crtydhW3XlQ1GZk=; b=RK8Ew6/5Ri+dELLmBTriLNdYCmsCXgQpv72YtXTxKBsprZxjU4STCIOF/ZkxFmFbcz PtMKJ8Q9zayDnczIWJmeP7LGBAjoxBTYFCqHU+a4AILdzkdcAGXI9WKwMCk3i8TqdG7q AznnSJczoz+ojrk8M3B+v6rdMxBXmaTgpQY04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:to:cc:subject:in-reply-to:references:user-agent :mime-version:content-type:from:date; b=UP5hq0i3SxfN82L7xaPeDMbEB3v7oS62uIECV2dkfD1gXNNIGT1Zt3+X/Dv1yhxUjS MW4hh0GHoiCG5SRKKAEcexF9GuHdif0lKfsIuJ6nietFEzSlh83CKp17+ODYkTe1fDLA cKMwn6NqU8l0I4BezoSIMHOYZcuII1Dov0xng= Received: by 10.142.135.13 with SMTP id i13mr2625560wfd.133.1244544698068; Tue, 09 Jun 2009 03:51:38 -0700 (PDT) Received: from moria.unixconsulting.co.in ([117.195.166.36]) by mx.google.com with ESMTPS id 29sm2662205wfg.8.2009.06.09.03.51.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 03:51:36 -0700 (PDT) Sender: Joseph Koshy Message-ID: <86prdd65xb.wl%koshy@unixconsulting.co.in> To: fabient@freebsd.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd6.3) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII From: Joseph Koshy Date: Tue, 09 Jun 2009 10:46:29 -0000 Cc: Joseph Koshy , FreeBSD Stable List Subject: Re: Announcement: PmcTools merged to RELENG_7 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, 09 Jun 2009 11:20:04 -0000 > Hello, > > The PmcTools is merged to RELENG_7. > > You can now enjoy the same level of features / hw supported as in head: > - Callchain in capture > - Core 2 support > - Core i7 support > - pmcannotate: source code annotation using pmc capture > - bug fixes > ... > > Tell me if you find any problems with it. Thank you, Fabien. Great job! Koshy From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 12:12:04 2009 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 B016C106578F for ; Tue, 9 Jun 2009 12:12:04 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2D50A8FC1C for ; Tue, 9 Jun 2009 12:12:03 +0000 (UTC) (envelope-from bra@fsn.hu) Message-ID: <4A2E4D2D.7040007@fsn.hu> Date: Tue, 09 Jun 2009 13:53:17 +0200 From: Attila Nagy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Kip Macy References: <20090526.192217.94910518.nyan@jp.FreeBSD.org> <4A1C3DA8.5050300@bit0.com> <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> In-Reply-To: <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> X-Stationery: 0.4.8.14 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (people.fsn.hu [0.0.0.0]); Tue, 09 Jun 2009 13:53:19 +0200 (CEST) Cc: Takahashi Yoshihiro , pjd@freebsd.org, stable@freebsd.org, Mike Andrews Subject: Re: NFS on ZFS 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, 09 Jun 2009 12:12:04 -0000 Hello, I've also ran into it, it's a pretty "killer" feature. :-O Any chance for us on the fix? Thanks, Kip Macy wrote: > The flags checks are too strict. File a PR. I'll fix it when I get to > it. Sorrry. > > > -Kip > > On Wed, May 27, 2009 at 7:24 PM, Mike Andrews wrote: > >> On Tue, 26 May 2009, Mike Andrews wrote: >> >> >>> Takahashi Yoshihiro wrote: >>> >>>> Today's stable has a problem creating a new file via NFS on ZFS. >>>> >>>> On the NFS server, there is no problem. >>>> >>>> % cd /ZFS >>>> % mktemp hoge >>>> hoge >>>> % ls -l hoge >>>> -rw------- 1 nyan nyan 0 5 26 19:09 hoge >>>> >>>> >>>> But it's a problem on the NFS client. >>>> >>>> # mount server:/ZFS /ZFS >>>> % cd /ZFS >>>> % mktemp hoge >>>> mktemp: mkstemp failed on hoge: Input/output error >>>> % ls -l hoge >>>> ---------- 1 nyan wheel 0 5 26 19:09 hoge >>>> >>>> The file has a wrong permission. >>>> >>>> This problem is only on stable, current has no problem. >>>> >>> I'm seeing this too. It seems so far to be limited to mkstemp() -- just >>> copying files normally works. For example /usr/bin/install -S fails, >>> without -S works, if the target is an NFS+ZFS volume. >>> >> Anyone? >> >> I've verified that if the NFS server uses UFS2, mkstemp() from an NFS >> client to the server works fine, but if the NFS server uses ZFS, the NFS >> server returns EIO after creating a file with 000 permissions. >> >> In addition to breaking /usr/bin/install -S, it also breaks rsync over NFS. >> >> I don't yet know if it matters whether the on-disk format is ZFS v6 vs v13. >> >> >> > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 13:51:42 2009 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 132A810656D6 for ; Tue, 9 Jun 2009 13:51:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8F78D8FC0A for ; Tue, 9 Jun 2009 13:51:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-157-59-252.bna.bellsouth.net [70.157.59.252]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n59DOKMI033281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 09:24:20 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Pete Carah In-Reply-To: <4A2DC056.8090500@altadena.net> References: <4A2DC056.8090500@altadena.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CY0UDfTW5oVKZqYQu+ES" Organization: FreeBSD Date: Tue, 09 Jun 2009 08:24:14 -0500 Message-Id: <1244553854.60347.1487.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RCVD_IN_PBL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: stable@freebsd.org Subject: Re: Bug between DRM, MSI, or somewhere, re7-stable 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: Tue, 09 Jun 2009 13:51:43 -0000 --=-CY0UDfTW5oVKZqYQu+ES Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-06-08 at 21:52 -0400, Pete Carah wrote: > I updated my recently acquired core-2 duo laptop to 7-stable amd64 (I=20 > had been running 7-stable i386 with few problems) and have acquired an=20 > apparent irq problem. >=20 > Fortunately in debugging a linux shared-interrupt problem about a month=20 > ago I learned that the X server will happily accept mouse motion as if=20 > it was a display interrupt, so at least with some inconvenience I can=20 > read the screen... (the keyboard isn't so obliging) > Ours does this too... >=20 > /usr/src was picked up via svn on last Saturday morning EDT, ports via=20 > csup about the same time. I have no idea if this bug is in the intel=20 > driver, drm, or the core msi code... There are 2 peripherals that dmesg=20 > says uses msi - re0 (which doesn't get a kernel thread indicated in ps=20 > for either the stated irq (257) or re0) and drm0/vgapci0 (which=20 > indicates irq256 in systat and ps). As I said, this worked properly=20 > with earlier source (about a week) in i386 mode. I've used both G45 and=20 > re controllers in (f10) linux msi mode with no problems in both 32 and=20 > 64-bit. Fortunately this laptop now has enough disk to triple-boot so=20 > at least something works... Yes, Intel still has issues. I do have a patch that reworks the interrupt handling and gets Intel chips working. It isn't safe to commit yet though. It works correctly on my G45, but I have had reports that GM45 is still broken somehow. As a workaround you can disable MSI for just drm using loader tuneable hw.drm.msi=3D0. robert. > I am using svn instead of csup because I am trying (haven't gotten time=20 > yet either :-) to port Sam's ath 92xx code to -stable and handling code=20 > porting is much easier that way. >=20 > -- Pete >=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 Robert Noland FreeBSD --=-CY0UDfTW5oVKZqYQu+ES Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkouYn4ACgkQM4TrQ4qfROO5oQCfbjWu204vdJ4/vbqbrGi3hr2b jB4AnRNBcUwvX9vSBexljQmqjw+1pUJz =3Olx -----END PGP SIGNATURE----- --=-CY0UDfTW5oVKZqYQu+ES-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 13:54:20 2009 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 3358010656C9 for ; Tue, 9 Jun 2009 13:54:20 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id A4E4F8FC13 for ; Tue, 9 Jun 2009 13:54:19 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from furia.intranet ([93.104.44.223]) (AUTH: LOGIN lopez.on.the.lists@yellowspace.net) by mail.yellowspace.net with esmtp; Tue, 09 Jun 2009 15:54:17 +0200 id 0048F5AF.000000004A2E6989.0000827B Message-Id: From: Lorenzo Perone To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 9 Jun 2009 15:54:17 +0200 X-Mailer: Apple Mail (2.935.3) Subject: ZFS list -t snapshot USAGE column 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, 09 Jun 2009 13:54:20 -0000 Hi there, just wondering, since the ZFS v13 update (to be precise, 7.2-STABLE FreeBSD 7.2-STABLE #11: Wed Jun 3 23:11:29 CEST 2009) why the USAGE column in a zfs list -t snapshot is not showing anymore the space used by the snapshot? I made those snapshots with zfs snapshot -r. They're almost all showing a USAGE of 0K, albeit there have been changes to the dataset since that snapshot. Regards, Lorenzo From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 14:24:38 2009 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 37BA8106567F; Tue, 9 Jun 2009 14:24:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD168FC1C; Tue, 9 Jun 2009 14:24:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59EOZIT087110; Tue, 9 Jun 2009 10:24:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59EOZJG010044; Tue, 9 Jun 2009 10:24:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 7E1EC1B5060; Tue, 9 Jun 2009 10:24:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609142435.7E1EC1B5060@freebsd-stable.sentex.ca> Date: Tue, 9 Jun 2009 10:24:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 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: Tue, 09 Jun 2009 14:24:38 -0000 TB --- 2009-06-09 12:44:20 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 12:44:20 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-06-09 12:44:20 - cleaning the object tree TB --- 2009-06-09 12:44:55 - cvsupping the source tree TB --- 2009-06-09 12:44:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-06-09 12:45:05 - building world TB --- 2009-06-09 12:45:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 12:45:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 12:45:05 - TARGET=amd64 TB --- 2009-06-09 12:45:05 - TARGET_ARCH=amd64 TB --- 2009-06-09 12:45:05 - TZ=UTC TB --- 2009-06-09 12:45:05 - __MAKE_CONF=/dev/null TB --- 2009-06-09 12:45:05 - cd /src TB --- 2009-06-09 12:45:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 12:45:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jun 9 14:18:53 UTC 2009 TB --- 2009-06-09 14:18:53 - generating LINT kernel config TB --- 2009-06-09 14:18:53 - cd /src/sys/amd64/conf TB --- 2009-06-09 14:18:53 - /usr/bin/make -B LINT TB --- 2009-06-09 14:18:53 - building LINT kernel TB --- 2009-06-09 14:18:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 14:18:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 14:18:53 - TARGET=amd64 TB --- 2009-06-09 14:18:53 - TARGET_ARCH=amd64 TB --- 2009-06-09 14:18:53 - TZ=UTC TB --- 2009-06-09 14:18:53 - __MAKE_CONF=/dev/null TB --- 2009-06-09 14:18:53 - cd /src TB --- 2009-06-09 14:18:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 14:18:53 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 14:24:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 14:24:35 - ERROR: failed to build lint kernel TB --- 2009-06-09 14:24:35 - 4792.32 user 553.73 system 6015.15 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 15:06:54 2009 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 4BBF31065670; Tue, 9 Jun 2009 15:06:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 211348FC1D; Tue, 9 Jun 2009 15:06:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59F6pTe096619; Tue, 9 Jun 2009 11:06:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n59F6pNl090501; Tue, 9 Jun 2009 11:06:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id B25C21B5060; Tue, 9 Jun 2009 11:06:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609150651.B25C21B5060@freebsd-stable.sentex.ca> Date: Tue, 9 Jun 2009 11:06:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 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: Tue, 09 Jun 2009 15:06:55 -0000 TB --- 2009-06-09 13:52:38 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 13:52:38 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-09 13:52:38 - cleaning the object tree TB --- 2009-06-09 13:52:50 - cvsupping the source tree TB --- 2009-06-09 13:52:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-09 13:52:59 - building world TB --- 2009-06-09 13:52:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 13:52:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 13:52:59 - TARGET=i386 TB --- 2009-06-09 13:52:59 - TARGET_ARCH=i386 TB --- 2009-06-09 13:52:59 - TZ=UTC TB --- 2009-06-09 13:52:59 - __MAKE_CONF=/dev/null TB --- 2009-06-09 13:52:59 - cd /src TB --- 2009-06-09 13:52:59 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 13:53:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 15:00:46 UTC 2009 TB --- 2009-06-09 15:00:46 - generating LINT kernel config TB --- 2009-06-09 15:00:46 - cd /src/sys/i386/conf TB --- 2009-06-09 15:00:46 - /usr/bin/make -B LINT TB --- 2009-06-09 15:00:46 - building LINT kernel TB --- 2009-06-09 15:00:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:00:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:00:46 - TARGET=i386 TB --- 2009-06-09 15:00:46 - TARGET_ARCH=i386 TB --- 2009-06-09 15:00:46 - TZ=UTC TB --- 2009-06-09 15:00:46 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:00:46 - cd /src TB --- 2009-06-09 15:00:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 15:00:46 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 15:06:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 15:06:51 - ERROR: failed to build lint kernel TB --- 2009-06-09 15:06:51 - 3549.24 user 389.72 system 4453.23 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 15:37:04 2009 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 643A41065670; Tue, 9 Jun 2009 15:37:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1018FC14; Tue, 9 Jun 2009 15:37:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n59Fawqu091310; Tue, 9 Jun 2009 11:36:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59FawDd080941; Tue, 9 Jun 2009 11:36:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 99C201B5060; Tue, 9 Jun 2009 11:36:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609153658.99C201B5060@freebsd-stable.sentex.ca> Date: Tue, 9 Jun 2009 11:36:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 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: Tue, 09 Jun 2009 15:37:05 -0000 TB --- 2009-06-09 14:24:35 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 14:24:35 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-06-09 14:24:35 - cleaning the object tree TB --- 2009-06-09 14:24:56 - cvsupping the source tree TB --- 2009-06-09 14:24:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-06-09 14:25:05 - building world TB --- 2009-06-09 14:25:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 14:25:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 14:25:05 - TARGET=pc98 TB --- 2009-06-09 14:25:05 - TARGET_ARCH=i386 TB --- 2009-06-09 14:25:05 - TZ=UTC TB --- 2009-06-09 14:25:05 - __MAKE_CONF=/dev/null TB --- 2009-06-09 14:25:05 - cd /src TB --- 2009-06-09 14:25:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 14:25:08 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 15:32:12 UTC 2009 TB --- 2009-06-09 15:32:12 - generating LINT kernel config TB --- 2009-06-09 15:32:12 - cd /src/sys/pc98/conf TB --- 2009-06-09 15:32:12 - /usr/bin/make -B LINT TB --- 2009-06-09 15:32:12 - building LINT kernel TB --- 2009-06-09 15:32:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:32:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:32:12 - TARGET=pc98 TB --- 2009-06-09 15:32:12 - TARGET_ARCH=i386 TB --- 2009-06-09 15:32:12 - TZ=UTC TB --- 2009-06-09 15:32:12 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:32:12 - cd /src TB --- 2009-06-09 15:32:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 15:32:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 15:36:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 15:36:58 - ERROR: failed to build lint kernel TB --- 2009-06-09 15:36:58 - 3452.06 user 388.35 system 4342.84 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 16:42:20 2009 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 A08E61065677; Tue, 9 Jun 2009 16:42:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7664F8FC23; Tue, 9 Jun 2009 16:42:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59GgIth015711; Tue, 9 Jun 2009 12:42:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n59GgIOv042345; Tue, 9 Jun 2009 12:42:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 0A74B1B5060; Tue, 9 Jun 2009 12:42:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090609164218.0A74B1B5060@freebsd-stable.sentex.ca> Date: Tue, 9 Jun 2009 12:42:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on ia64/ia64 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: Tue, 09 Jun 2009 16:42:21 -0000 TB --- 2009-06-09 15:06:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-09 15:06:51 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2009-06-09 15:06:51 - cleaning the object tree TB --- 2009-06-09 15:07:07 - cvsupping the source tree TB --- 2009-06-09 15:07:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2009-06-09 15:07:17 - building world TB --- 2009-06-09 15:07:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 15:07:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 15:07:17 - TARGET=ia64 TB --- 2009-06-09 15:07:17 - TARGET_ARCH=ia64 TB --- 2009-06-09 15:07:17 - TZ=UTC TB --- 2009-06-09 15:07:17 - __MAKE_CONF=/dev/null TB --- 2009-06-09 15:07:17 - cd /src TB --- 2009-06-09 15:07:17 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 9 15:07:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 9 16:36:37 UTC 2009 TB --- 2009-06-09 16:36:37 - generating LINT kernel config TB --- 2009-06-09 16:36:37 - cd /src/sys/ia64/conf TB --- 2009-06-09 16:36:37 - /usr/bin/make -B LINT TB --- 2009-06-09 16:36:37 - building LINT kernel TB --- 2009-06-09 16:36:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-09 16:36:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-09 16:36:37 - TARGET=ia64 TB --- 2009-06-09 16:36:37 - TARGET_ARCH=ia64 TB --- 2009-06-09 16:36:37 - TZ=UTC TB --- 2009-06-09 16:36:37 - __MAKE_CONF=/dev/null TB --- 2009-06-09 16:36:37 - cd /src TB --- 2009-06-09 16:36:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 9 16:36:37 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'data' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: error: dereferencing pointer to incomplete type /src/sys/dev/cxgb/cxgb_main.c:3033: error: request for member 'bufsize' in something not a structure or union /src/sys/dev/cxgb/cxgb_main.c:3033: warning: passing argument 3 of 'copyout' makes integer from pointer without a cast /src/sys/dev/cxgb/cxgb_main.c: At top level: /src/sys/dev/cxgb/cxgb_main.c:3050: error: conflicting types for 'reg_block_dump' /src/sys/dev/cxgb/cxgb_main.c:111: error: previous declaration of 'reg_block_dump' was here /src/sys/dev/cxgb/cxgb_main.c:3065: error: expected ')' before '*' token *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-09 16:42:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-09 16:42:17 - ERROR: failed to build lint kernel TB --- 2009-06-09 16:42:17 - 4804.94 user 387.17 system 5725.96 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 18:08:57 2009 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 18DB7106564A for ; Tue, 9 Jun 2009 18:08:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A4E088FC0C for ; Tue, 9 Jun 2009 18:08:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13487 invoked by uid 399); 9 Jun 2009 18:08:52 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jun 2009 18:08:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A2EA533.1040405@FreeBSD.org> Date: Tue, 09 Jun 2009 11:08:51 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Kostik Belousov References: <86d49eocwx.fsf@kopusha.onet> <20090608181728.GU1927@deviant.kiev.zoral.com.ua> In-Reply-To: <20090608181728.GU1927@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 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, 09 Jun 2009 18:08:57 -0000 Kostik Belousov wrote: > This is fixed in HEAD by r185647. I did not merged it to 7, because I > do not believe that somebody runs stable with INVARIANTS on :). I would imagine that people doing kernel module development for use in -stable systems do that with regularity. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 18:55:34 2009 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 01C9210656D4; Tue, 9 Jun 2009 18:55:34 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 201F48FC15; Tue, 9 Jun 2009 18:55:32 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n59IHNGB059887; Wed, 10 Jun 2009 02:17:23 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n59IHNiP059886; Wed, 10 Jun 2009 02:17:23 +0800 (KRAST) (envelope-from eugen) Date: Wed, 10 Jun 2009 02:17:23 +0800 From: Eugene Grosbein To: Doug Barton Message-ID: <20090609181723.GA59598@svzserv.kemerovo.su> References: <86d49eocwx.fsf@kopusha.onet> <20090608181728.GU1927@deviant.kiev.zoral.com.ua> <4A2EA533.1040405@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2EA533.1040405@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Kostik Belousov , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: Assertion lock == sq->sq_lock failed at /usr/src/sys/kern/subr_sleepqueue.c:327 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, 09 Jun 2009 18:55:34 -0000 On Tue, Jun 09, 2009 at 11:08:51AM -0700, Doug Barton wrote: > Kostik Belousov wrote: > > This is fixed in HEAD by r185647. I did not merged it to 7, because I > > do not believe that somebody runs stable with INVARIANTS on :). > > I would imagine that people doing kernel module development for use in > -stable systems do that with regularity. I generally run STABLE with INVARIANTS and lots of other debug options while trying to debug a panic or hang in STABLE. And I expect it won't add another panic. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 18:58:26 2009 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 31066106566B for ; Tue, 9 Jun 2009 18:58:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B4D128FC23 for ; Tue, 9 Jun 2009 18:58:24 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23560 invoked by uid 399); 9 Jun 2009 18:58:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jun 2009 18:58:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A2EB0C6.6040705@FreeBSD.org> Date: Tue, 09 Jun 2009 11:58:14 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: allnetgroup@yahoo.com References: <143776.42704.qm@web34307.mail.mud.yahoo.com> In-Reply-To: <143776.42704.qm@web34307.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: I need to add commands that starts every time at system boot. 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, 09 Jun 2009 18:58:26 -0000 AES wrote: > I need to add commands that starts every time at system boot. > > which script is the one that starts first and where can I find it? If you're Ok with running your commands late in the boot process then /etc/rc.local is your best bet. If what you're doing needs to happen in a certain order relative to the rest of the boot system then you'll want to write your own rc.d-style script and put it in /usr/local/etc/rc.d/. There are several articles in the Handbook that will help you in writing your own script. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 21:02:34 2009 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 991CD1065672 for ; Tue, 9 Jun 2009 21:02:34 +0000 (UTC) (envelope-from mark@lomag.net) Received: from web.lomag.net (web.lomag.net [208.185.81.14]) by mx1.freebsd.org (Postfix) with SMTP id 44C608FC13 for ; Tue, 9 Jun 2009 21:02:34 +0000 (UTC) (envelope-from mark@lomag.net) Received: (qmail 99742 invoked by uid 89); 9 Jun 2009 20:35:53 -0000 Received: from mark@lomag.net by web.lomag.net by uid 89 with qmail-scanner-1.20st (clamav: 0.92. spamassassin: 3.2.4. Clear:RC:1(68.197.94.3):. Processed in 0.019779 secs); 09 Jun 2009 20:35:53 -0000 Received: from ws01.lomag.net (HELO ws01) (68.197.94.3) by 0 with SMTP; 9 Jun 2009 20:35:53 -0000 Message-ID: <7F95EEF369A54B4E924DE08FCA4600CD@ws01> From: "Mark Skurzynski" To: Date: Tue, 9 Jun 2009 16:36:13 -0400 Organization: Lomag Internet Services, LLC 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Buildworld Failure with MODULES_WITH_WORLD=true 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, 09 Jun 2009 21:02:34 -0000 Hello, Our recent buildworlds on both i386 and amd64, as of a couple days ago, are failing with the below error. We use MODULES_WITH_WORLD=true. ===> sys/modules/dtrace/dtmalloc (depend) @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/dtrace/dtmalloc/../../.. -I. -I@ -I@/contrib/altq/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/dev/dtmalloc/dtmalloc.c===> sys/modules/dtrace/dtrace (depend)@ -> /usr/src/sysmachine -> /usr/src/sys/amd64/includeawk -f @/tools/makeobjops.awk @/kern/bus_if.m -hawk -f @/tools/makeobjops.awk @/kern/device_if.m -hawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -pawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -qawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h:> opt_compat.h:> opt_kstack_pages.h:> opt_nfs.hcc -c -O2 -fno-strict-aliasing -pipe -DDIS_MEM -DSMP -DDEBUG -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64 -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensol aris/uts/common -I/usr/src/sys/modules/dtrace/dtrace/../../.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --paramlarge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas@/amd64/amd64/genassym.c@/amd64/amd64/genassym.c:39:29: error: opt_hwpmc_hooks.h: No suchfile or directory*** Error code 1Stop in /usr/src/sys/modules/dtrace/dtrace.*** Error code 1Stop in /usr/src/sys/modules/dtrace.*** Error code 1Stop in /usr/src/sys/modules.*** Error code 1Stop in /usr/src/sys.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.Any ideas on how to resolve this?Thank you,Mark--******************* ********************************* Mark Skurzynski * Lomag Internet Services, LLC mark@lomag.net * http://www.lomag.net Edison, NJ USA * 908-754-0221**************************************************** From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 21:05:30 2009 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 4A0A9106566B for ; Tue, 9 Jun 2009 21:05:30 +0000 (UTC) (envelope-from mark@lomag.net) Received: from web.lomag.net (web.lomag.net [208.185.81.14]) by mx1.freebsd.org (Postfix) with SMTP id EA7318FC17 for ; Tue, 9 Jun 2009 21:05:29 +0000 (UTC) (envelope-from mark@lomag.net) Received: (qmail 439 invoked by uid 89); 9 Jun 2009 20:38:48 -0000 Received: from mark@lomag.net by web.lomag.net by uid 89 with qmail-scanner-1.20st (clamav: 0.92. spamassassin: 3.2.4. Clear:RC:1(68.197.94.3):. Processed in 0.018983 secs); 09 Jun 2009 20:38:48 -0000 Received: from ws01.lomag.net (HELO ws01) (68.197.94.3) by 0 with SMTP; 9 Jun 2009 20:38:48 -0000 Message-ID: From: "Mark Skurzynski" To: Date: Tue, 9 Jun 2009 16:39:08 -0400 Organization: Lomag Internet Services, LLC 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Cc: Subject: Buildworld Failure with MODULES_WITH_WORLD=true 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, 09 Jun 2009 21:05:30 -0000 Hello, Our recent buildworlds on both i386 and amd64, as of a couple days ago, are failing with the below error. We use MODULES_WITH_WORLD=true. ===> sys/modules/dtrace/dtmalloc (depend) @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/dtrace/dtmalloc/../../.. -I. -I@ -I@/contrib/altq/usr/src/sys/modules/dtrace/dtmalloc/../../../cddl/dev/dtmalloc/dtmalloc.c===> sys/modules/dtrace/dtrace (depend)@ -> /usr/src/sysmachine -> /usr/src/sys/amd64/includeawk -f @/tools/makeobjops.awk @/kern/bus_if.m -hawk -f @/tools/makeobjops.awk @/kern/device_if.m -hawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -pawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -qawk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h:> opt_compat.h:> opt_kstack_pages.h:> opt_nfs.hcc -c -O2 -fno-strict-aliasing -pipe -DDIS_MEM -DSMP -DDEBUG -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/compat/opensolaris -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/amd64 -I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensol aris/uts/common -I/usr/src/sys/modules/dtrace/dtrace/../../.. -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --paramlarge-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas@/amd64/amd64/genassym.c@/amd64/amd64/genassym.c:39:29: error: opt_hwpmc_hooks.h: No suchfile or directory*** Error code 1Stop in /usr/src/sys/modules/dtrace/dtrace.*** Error code 1Stop in /usr/src/sys/modules/dtrace.*** Error code 1Stop in /usr/src/sys/modules.*** Error code 1Stop in /usr/src/sys.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.*** Error code 1Stop in /usr/src.Any ideas on how to resolve this?Thank you,Mark--******************* ********************************* Mark Skurzynski * Lomag Internet Services, LLC mark@lomag.net * http://www.lomag.net Edison, NJ USA * 908-754-0221**************************************************** From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 21:50:36 2009 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 91C39106566B; Tue, 9 Jun 2009 21:50:36 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id 62DA88FC16; Tue, 9 Jun 2009 21:50:36 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from localhost (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id 08A147C98; Tue, 9 Jun 2009 17:50:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at bit0.com Received: from magnum.bit0.com ([127.0.0.1]) by localhost (magnum.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfmrBa+ErBF6; Tue, 9 Jun 2009 17:50:34 -0400 (EDT) Received: from beast.int.bit0.com (beast.int.bit0.com [172.27.0.2]) by magnum.bit0.com (Postfix) with ESMTP; Tue, 9 Jun 2009 17:50:34 -0400 (EDT) Date: Tue, 9 Jun 2009 17:50:34 -0400 (EDT) From: Mike Andrews X-X-Sender: mandrews@beast.int.bit0.com To: Attila Nagy In-Reply-To: <4A2E4D2D.7040007@fsn.hu> Message-ID: References: <20090526.192217.94910518.nyan@jp.FreeBSD.org> <4A1C3DA8.5050300@bit0.com> <3c1674c90905280025i17039257l573838d33d8493fd@mail.gmail.com> <4A2E4D2D.7040007@fsn.hu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Takahashi Yoshihiro , stable@freebsd.org, pjd@freebsd.org, Kip Macy Subject: Re: NFS on ZFS 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, 09 Jun 2009 21:50:36 -0000 On Tue, 9 Jun 2009, Attila Nagy wrote: > Hello, > > I've also ran into it, it's a pretty "killer" feature. :-O > > Any chance for us on the fix? It's kern/135039, fyi. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 22:28:55 2009 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 E1E4110656A6 for ; Tue, 9 Jun 2009 22:28:55 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 990E58FC16 for ; Tue, 9 Jun 2009 22:28:55 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by qyk3 with SMTP id 3so522115qyk.3 for ; Tue, 09 Jun 2009 15:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Oo0TQq70Q8awpLG3FZkAIiHkHo7tbyFvmPznHV9xKM8=; b=psVHOiNKhQPu48bvbDomUqE5yl0MFJ8p8GKWBYBx2yvo517SP2aGiOoMdItUHm3NCN UjjicGDk/51ZAdJ1HpZ+JrNqzUZU5TzG00xia+L4czodN/k+cEqZLV82IyDrYKIxKli9 CyNxFikIyekkjh7uWGrghezLlKN2eVl2iDzHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=essOi+r5LO2r3gGgxD0ndowC7UKFXbfI6BPIyi7q0Dr3pMSUuSr6mv+PXjoqHq3Z0T mNKZJch4REAWLs4OSRWw9wMdtVXDwZNuIGMGeEoSGy77tj9oqwzOkqd5qUmmKzqfRuTs 1h7KxpIg79Jhjl2/NAFn929yngzBIHXImfrbo= MIME-Version: 1.0 Received: by 10.224.73.134 with SMTP id q6mr810012qaj.120.1244586534995; Tue, 09 Jun 2009 15:28:54 -0700 (PDT) Date: Wed, 10 Jun 2009 01:28:54 +0300 Message-ID: From: Dan Naumov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: trouble building a "make release" snapshot of 7.2-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, 09 Jun 2009 22:28:56 -0000 So first I cvsupped the entire cvs repository (sans ports) using the following supfile: =========================================== *default host=ftp13.FreeBSD.org *default base=/var/db *default prefix=/backup/ncvs *default release=cvs *default delete use-rel-suffix compress src-all doc-all cvsroot-all =========================================== Then I cd /usr/src/release and do: =========================================== make release RELEASETAG=RELENG_7 TARGET_ARCH=amd64 TARGET=amd64 BUILDNAME=7.2-STABLE CHROOTDIR=/backup/releng CVSROOT=/backup/ncvs NODOC=yes NOPORTS=yes NOPORTREADMES=yes MAKE_ISOS=yes NO_FLOPPIES=yes LOCAL_PATCHES=/root/zfs-libstand-loader-patch =========================================== However, the process bombs out on me within 5 seconds with the following: =========================================== -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) install -o root -g wheel -m 444 dir-tmpl /backup/releng/usr/share/info/dir install:No such file or directory *** Error code 1 Stop in /usr/src/share/info. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. =========================================== And... =========================================== agathon# which install /usr/bin/install =========================================== Any ideas? - Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 00:29:18 2009 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 E994F106564A; Wed, 10 Jun 2009 00:29:18 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) Received: from www.heimat.gr.jp (unknown [IPv6:2001:3e0:a84::1]) by mx1.freebsd.org (Postfix) with ESMTP id 73B0F8FC08; Wed, 10 Jun 2009 00:29:18 +0000 (UTC) (envelope-from nakaji@kankyo-u.ac.jp) X-Virus-Scanned: amavisd-new at heimat.gr.jp Received: from ra333.heimat.gr.jp.kankyo-u.ac.jp (ra333.heimat.gr.jp [IPv6:2001:3e0:a84:0:200:4cff:fe17:573c]) by www.heimat.gr.jp (8.14.3/8.14.3) with ESMTP id n5A0T2UA016717; Wed, 10 Jun 2009 09:29:03 +0900 (JST) (envelope-from nakaji@kankyo-u.ac.jp) From: NAKAJI Hiroyuki To: Attilio Rao References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> Date: Wed, 10 Jun 2009 09:29:02 +0900 In-Reply-To: <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> (Attilio Rao's message of "Sat, 6 Jun 2009 16:49:54 +0200") Message-ID: <86hbyprkxd.fsf@ra333.heimat.gr.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-5.7 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ZERO,NO_RELAYS,QENCPTR1 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on www.heimat.gr.jp Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Big problem still remains with 7.2-STABLE locking up 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, 10 Jun 2009 00:29:19 -0000 Thanks Attilio, I set up dcons target/host pair. Target is 7.2-STABLE and host is 6.4-STABLE. Dcons session was recorded with script. http://www.heimat.gr.jp/localhost/dcons.log >>>>> In <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> >>>>> Attilio Rao wrote: > 2) Once you get the deadlock break in the DDB debugger KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a vfs_badlock() at vfs_badlock+0x95 assert_vop_elocked() at assert_vop_elocked+0x64 VOP_WRITE_APV() at VOP_WRITE_APV+0x155 vn_write() at vn_write+0x1ce dofilewrite() at dofilewrite+0x85 kern_pwritev() at kern_pwritev+0x66 pwrite() at pwrite+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (476, FreeBSD ELF64, pwrite), rip = 0x80074d17c, rsp = 0x7fffffffda98, rbp = 0xb4000 --- VOP_WRITE: 0xffffff004a26c000 is not exclusive locked but should be KDB: enter: lock violation [thread pid 29756 tid 100177 ] Stopped at kdb_enter_why+0x3d: movq $0,0x626418(%rip) > 3) Once you are in DDB informations which could be very useful are: db> show allpcpu db> show alllocks db> show lockedvnods db> ps db> allthreads > Note that this is a lot of printout so you won't be able of collecting > all these informations if not with a serial connection. db> show allpcpu Current CPU: 0 cpuid = 0 curthread = 0xffffff0114476ab0: pid 29756 "expireover" curpcb = 0xffffff80a3f7ed40 fpcurthread = none idlethread = 0xffffff0001589720: pid 11 "idle: cpu0" spin locks held: db> show alllocks Process 29784 (spamc) thread 0xffffff004afac720 (100170) exclusive sx so_rcv_sx r = 0 (0xffffff0065383c40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29413 (perl) thread 0xffffff004afb0720 (100162) exclusive sx so_rcv_sx r = 0 (0xffffff00656163d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29409 (perl) thread 0xffffff01144ea390 (100175) exclusive sx so_rcv_sx r = 0 (0xffffff004a210970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 29406 (perl) thread 0xffffff0065899000 (100196) exclusive sx so_rcv_sx r = 0 (0xffffff00655cbc40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1497 (perl5.8.9) thread 0xffffff0013dedab0 (100113) exclusive sx so_rcv_sx r = 0 (0xffffff004a0b9970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1496 (ninpaths) thread 0xffffff001333a720 (100082) exclusive sx so_rcv_sx r = 0 (0xffffff004a33d100) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1494 (perl5.8.9) thread 0xffffff0013dcf720 (100107) exclusive sx so_rcv_sx r = 0 (0xffffff004a33d6a0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 1397 (python2.5) thread 0xffffff0013dd1ab0 (100098) exclusive sx so_rcv_sx r = 0 (0xffffff00655cc3d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db> show lockedvnods Locked vnodes 0xffffff004a26c000: tag ufs, type VREG usecount 5, writecount 2, refcount 587 mountedhere 0 flags (VI_OBJDIRTY) v_object 0xffffff004a1fad80 ref 3 pages 4604 lock type ufs: SHARED (count 1) ino 3157042, on dev ad4s1f db> ps pid ppid pgrp uid state wmesg wchan cmd 29803 1443 1406 8 S nanslp 0xffffffff80b58688 sleep 29797 1534 1534 0 S connec 0xffffff00654815fe sendmail 29785 1499 1499 110 S lockf 0xffffff0065a19000 perl [snip] db> allthreads No such command db> panic panic: from debugger cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 db_panic() at db_panic+0x17 db_command() at db_command+0x1ef db_command_loop() at db_command_loop+0x50 db_trap() at db_trap+0x89 kdb_trap() at kdb_trap+0x95 trap() at trap+0x295 calltrap() at calltrap+0x8 --- trap 0x3, rip = 0xffffffff8054694d, rsp = 0xffffff80a3f7e850, rbp = 0xffffff80a3f7e870 --- kdb_enter_why() at kdb_enter_why+0x3d assert_vop_elocked() at assert_vop_elocked+0x64 VOP_WRITE_APV() at VOP_WRITE_APV+0x155 vn_write() at vn_write+0x1ce dofilewrite() at dofilewrite+0x85 kern_pwritev() at kern_pwritev+0x66 pwrite() at pwrite+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (476, FreeBSD ELF64, pwrite), rip = 0x80074d17c, rsp = 0x7fffffffda98, rbp = 0xb4000 --- Uptime: 3h20m7s Physical memory: 6121 MB Dumping 1730 MB: (CTRL-C to abort) ... Dump complete Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... And, here is a backtrace. (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff80517e73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xffffffff805182fc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xffffffff801c6817 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:446 #4 0xffffffff801c710f in db_command (last_cmdp=0xffffffff80b21088, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xffffffff801c7320 in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xffffffff801c8c59 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:228 #7 0xffffffff80546775 in kdb_trap (type=3, code=0, tf=0xffffff80a3f7e7a0) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xffffffff807d6925 in trap (frame=0xffffff80a3f7e7a0) at /usr/src/sys/amd64/amd64/trap.c:531 #9 0xffffffff807ba53e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #10 0xffffffff8054694d in kdb_enter_why (why=0xffffffff808caa99 "vfslock", msg=0xa
) at cpufunc.h:63 #11 0xffffffff8059d804 in assert_vop_elocked (vp=0xffffff004a26c000, str=0xffffffff80907391 "VOP_WRITE") at /usr/src/sys/kern/vfs_subr.c:3679 #12 0xffffffff8081da55 in VOP_WRITE_APV (vop=Variable "vop" is not available. ) at vnode_if.c:702 #13 0xffffffff805aad6e in vn_write (fp=0xffffff0003a13d80, uio=0xffffff80a3f7eb00, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:373 ---Type to continue, or q to quit--- #14 0xffffffff80559215 in dofilewrite (td=0xffffff0114476ab0, fd=15, fp=0xffffff0003a13d80, auio=0xffffff80a3f7eb00, offset=Variable "offset" is not available. ) at file.h:257 #15 0xffffffff80559386 in kern_pwritev (td=0xffffff0114476ab0, fd=15, auio=0xffffff80a3f7eb00, offset=770655) at /usr/src/sys/kern/sys_generic.c:450 #16 0xffffffff80559418 in pwrite (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:351 #17 0xffffffff807d61de in syscall (frame=0xffffff80a3f7ec80) at /usr/src/sys/amd64/amd64/trap.c:900 #18 0xffffffff807ba74b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x000000080074d17c in ?? () Previous frame inner to this frame (corrupt stack?) > 4) Dump the content so that we can further look at locks structure > states once we identify something useful (ideally, keeping the machine > up in DDB for that would be very useful, but often not viable) The target machine is my SMTP server and it's hard to keep it in DDB. > Let me know. I hope this helps debugging. Thanks. -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 00:57:17 2009 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 EBA71106566C for ; Wed, 10 Jun 2009 00:57:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 70C5D8FC12 for ; Wed, 10 Jun 2009 00:57:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz4 with SMTP id 4so404830bwz.43 for ; Tue, 09 Jun 2009 17:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3/Lq7Jz4F36VQ4UzvRoeNSC3k/acMS6owSCn0rxl6KU=; b=NFsFZqQcRTTOu23PGnYzNFv32DudYmd2sGS9HpHxUIB3dcMy60fjXqZ9vgm3oDfmZ1 QeeOvTzVLvxSjg3eyPdRMG7hW+PqaNlQcPwo640arOMTyziOe06FACHEWkf8gGuOsq/3 PDFiFMFR8d58Bln/k6MddZBcq9E41sC7WU6P4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ianAWMvBkZ3QWGVW87489U7tOiXptJF7dYHsWmh0dsZoZwVyFzbEdJfgpsmdI/Fn5N eB8qn9h6f+u4VKF6v7XxcOHACJAEwKJ6rQUvC36+qv+f7wYr0tZv8NNb8Xm1qoB53a1i Jpe4V2XszVNGcL6Hh7011+f1W9iXqQ5DCIz7c= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.124.147 with SMTP id u19mr720883far.28.1244595435493; Tue, 09 Jun 2009 17:57:15 -0700 (PDT) In-Reply-To: <86hbyprkxd.fsf@ra333.heimat.gr.jp> References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <86hbyprkxd.fsf@ra333.heimat.gr.jp> Date: Wed, 10 Jun 2009 02:57:14 +0200 X-Google-Sender-Auth: fe3217d6afdf78cc Message-ID: <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> From: Attilio Rao To: NAKAJI Hiroyuki Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Big problem still remains with 7.2-STABLE locking up 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, 10 Jun 2009 00:57:18 -0000 2009/6/10 NAKAJI Hiroyuki : > Thanks Attilio, > > I set up dcons target/host pair. Target is 7.2-STABLE and host is > 6.4-STABLE. > > Dcons session was recorded with script. > http://www.heimat.gr.jp/localhost/dcons.log I'm following up privately with the user, news to come hopefully. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 01:27:19 2009 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 6CAB91065670 for ; Wed, 10 Jun 2009 01:27:19 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6528FC0A for ; Wed, 10 Jun 2009 01:27:18 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so219230ywe.13 for ; Tue, 09 Jun 2009 18:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uCz20E14zLSqNYYfvDbXAAXsD0eQ+MnEY+Yz11+tXVo=; b=GlkZuEQAYHBLff6X97QeWOo6couHoP3uytlkLPyYp3fDHr1YcgZMD/H+RMQptv84ZB ZpOSIxh0vHiTpE7VUk1arbCvWZy4oFOwNOjk+AV1QC9eOzxKjIEH5WoARoeWTwV+E0r7 L5dTlszNmRj+NnoaXov1+dlP0tRxNKNeBEjNA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=OORZzGI3qMNkrw69vUAGXYYR3KcK5GH9bYG3oVNRV+jEucEFCtV2vi3C0bv8YvIv/a qJHLuqF3OD6vm72m4te0tiQMhqrCrulXV//MBHAPUnUIQ7UMFO5bW+i8lK11Vy1M/R/G xT9zR9XWowAiCHIGDCsjEW193KzC6/UQ7chN4= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.227.18 with SMTP id z18mr786355ang.67.1244597238479; Tue, 09 Jun 2009 18:27:18 -0700 (PDT) In-Reply-To: <4A2D10AB.3040007@thekeelecentre.com> References: <20090531191456.M33035@onet.com.ua> <200906010940.26300.doconnor@gsoft.com.au> <4A2404E5.7010104@orange.fr> <3c1674c90906011518k6d680125hf4b4d7608c92de44@mail.gmail.com> <4A2D10AB.3040007@thekeelecentre.com> Date: Tue, 9 Jun 2009 18:27:18 -0700 X-Google-Sender-Auth: 828752d28f1b7cab Message-ID: <3c1674c90906091827u8de6f1eq438db01aaa4b3090@mail.gmail.com> From: Kip Macy To: Richard Tector Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Claude Buisson , freebsd-stable@freebsd.org, Pavel Greenberg Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf 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, 10 Jun 2009 01:27:19 -0000 On Mon, Jun 8, 2009 at 6:22 AM, Richard Tector wrote: > Kip Macy wrote: >>> >>> The second bug is the use of LOADER_ZFS_SUPPORT without any >>> consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) > >> I'll try get it fixed by Wednesday. > > > Kip, I noticed a fix went in with revision 193494 but was then backed out > straight away with no reason. > > Will this be fixed soon? It is still not possible to build RELENG_7 sources > WITHOUT_CDDL. This should be fixed now. Sorry for the delay. Thanks, Kip From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 01:28:51 2009 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 8CC071065689 for ; Wed, 10 Jun 2009 01:28:51 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 46F0C8FC24 for ; Wed, 10 Jun 2009 01:28:50 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so216578ana.13 for ; Tue, 09 Jun 2009 18:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mOyCbaqVXZq58BgCrabl0OwlAOqCYdOwHL0lxj6xeqQ=; b=lFQdPpsa0MOWLNa5PKf94XkBZ2HZYYwDn0dMbG3EwAFUc4/cVvbZHn1Ha6lznkjHON pDYhd5Om5eAALp9Bqf5NdHiBrAFPHfUwZpHq8XkGAaXDInsWUl91cDdZUUVjT/ZlF2Vv lEJD3eVrUgbD17el5do8JHW9NNj+8nB3A68F0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=phDsDEH6HWR3DoV3VtIKEw5/9JbaR7AKsootpH9mgJJtU32r1+rMvpN6L3ot2m47Xd 9S4C9gig3PqWa2iRRZBNvFhxRVe0VomKPOMSdIUcbKMESzUEOlPk5/H2KGtchSwm5Ijq LsA436tdHBAJmzlG2elNVNgIGYCboQKNiWyV4= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.153.12 with SMTP id a12mr739704ane.191.1244597330640; Tue, 09 Jun 2009 18:28:50 -0700 (PDT) In-Reply-To: <20090526120510.GA1785@fbsd.hasee.cpu> References: <20090526120510.GA1785@fbsd.hasee.cpu> Date: Tue, 9 Jun 2009 18:28:50 -0700 X-Google-Sender-Auth: 978da7215b51f074 Message-ID: <3c1674c90906091828h43cc8a34vaeafbcacd95ebd88@mail.gmail.com> From: Kip Macy To: "Wu, Yue" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: WITHOUT_ZFS makes build world and kernel error 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, 10 Jun 2009 01:28:52 -0000 fixed. On Tue, May 26, 2009 at 5:05 AM, Wu, Yue wrote: > Hi, list, > > I have a FreeBSD 7-stable box, which has been cvsed up yesterday, even with my > src.conf which has the line of WITHOUT_ZFS=yes, FreeBSD always wants to > install libzfs relative stuffs when installing kernel and world, so error > comes, I have to comment out this line to make the installing stage goes > correctly. Is it a bug? > > -- > Hi, > Wu, Yue > _______________________________________________ > 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" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 01:32:25 2009 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 92683106566B; Wed, 10 Jun 2009 01:32:25 +0000 (UTC) (envelope-from nakaji@jp.freebsd.org) Received: from d4407.kankyo-u.ac.jp (unknown [IPv6:2001:3e0:a84:2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25BFA8FC14; Wed, 10 Jun 2009 01:32:24 +0000 (UTC) (envelope-from nakaji@jp.freebsd.org) Received: from roddy.4407.kankyo-u.ac.jp.kankyo-u.ac.jp (localhost [IPv6:::1]) by d4407.kankyo-u.ac.jp (8.14.3/8.14.3) with ESMTP id n5A1NVle073239; Wed, 10 Jun 2009 10:23:31 +0900 (JST) (envelope-from nakaji@jp.freebsd.org) From: NAKAJI Hiroyuki To: Attilio Rao Organization: Japan FreeBSD User's Group References: <86d49h300c.fsf@ra333.heimat.gr.jp> <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com> <86hbyprkxd.fsf@ra333.heimat.gr.jp> <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> Date: Wed, 10 Jun 2009 10:23:31 +0900 In-Reply-To: <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> (Attilio Rao's message of "Wed, 10 Jun 2009 02:57:14 +0200") Message-ID: <87fxe8g9v0.fsf@roddy.4407.kankyo-u.ac.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: freebsd-stable@freebsd.org Subject: Re: Big problem still remains with 7.2-STABLE locking up 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, 10 Jun 2009 01:32:25 -0000 >>>>> In <3bbf2fe10906091757w35ffd5cfr6f091fc718bc80c7@mail.gmail.com> >>>>> Attilio Rao wrote: > > Dcons session was recorded with script. > > http://www.heimat.gr.jp/localhost/dcons.log Just fix my typo. http://www.heimat.gr.jp/~nakaji/localhost/dcons.log ^^^^^^^ > I'm following up privately with the user, news to come hopefully. Thanks. I'll try. -- NAKAJI Hiroyuki From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 06:35:39 2009 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 EAD1A1065672; Wed, 10 Jun 2009 06:35:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id ABF868FC15; Wed, 10 Jun 2009 06:35:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5A6Zbh7036860; Wed, 10 Jun 2009 02:35:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5A6ZbB1096956; Wed, 10 Jun 2009 02:35:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 85FE61B5060; Wed, 10 Jun 2009 02:35:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090610063537.85FE61B5060@freebsd-stable.sentex.ca> Date: Wed, 10 Jun 2009 02:35:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 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: Wed, 10 Jun 2009 06:35:40 -0000 TB --- 2009-06-10 05:36:19 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-10 05:36:19 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-06-10 05:36:19 - cleaning the object tree TB --- 2009-06-10 05:36:41 - cvsupping the source tree TB --- 2009-06-10 05:36:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-06-10 05:36:53 - building world TB --- 2009-06-10 05:36:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-10 05:36:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-10 05:36:53 - TARGET=amd64 TB --- 2009-06-10 05:36:53 - TARGET_ARCH=amd64 TB --- 2009-06-10 05:36:53 - TZ=UTC TB --- 2009-06-10 05:36:53 - __MAKE_CONF=/dev/null TB --- 2009-06-10 05:36:53 - cd /src TB --- 2009-06-10 05:36:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 10 05:36:54 UTC 2009 >>> 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 [...] cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/load_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/load_elf64_obj.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/reloc_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/bcache.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/isapnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/pnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -c /src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /obj/amd64/src/sys/boot/i386/loader/../../zfs/libzfsboot.a. Stop *** Error code 2 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-10 06:35:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-10 06:35:37 - ERROR: failed to build world TB --- 2009-06-10 06:35:37 - 2875.98 user 317.82 system 3558.16 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 07:20:42 2009 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 43493106566B for ; Wed, 10 Jun 2009 07:20:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 02E308FC1F for ; Wed, 10 Jun 2009 07:20:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MEHYA-000075-KB for stable@freebsd.org; Wed, 10 Jun 2009 09:44:42 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jun 2009 09:44:42 +0300 From: Danny Braniss Message-ID: Cc: Subject: unionfs & unlocking unheld lock 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, 10 Jun 2009 07:20:42 -0000 hi, sporadically, I see this: lockmgr: thread 0xffffff0004a8b390 unlocking unheld lock KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _lockmgr() at _lockmgr+0x6ae VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 unionfs_unlock() at unionfs_unlock+0x22f VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 vn_read() at vn_read+0x264 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x4c read() at read+0x54 syscall() at syscall+0x256 Xfast_syscall() at Xfast_syscall+0xab --- syscall (3, FreeBSD ELF64, read), rip = 0x8017545bc, rsp = 0x7fffffffaf98, rbp = 0x7fffffffb025 --- sf-02> zgrep 'unlocking unheld lock' /var/log/messages* /var/log/messages:May 25 03:03:37 sf-02 kernel: lockmgr: thread 0xffffff0004ed0720 unlocking unheld lock /var/log/messages:May 31 03:03:10 sf-02 kernel: lockmgr: thread 0xffffff0004ed6ab0 unlocking unheld lock /var/log/messages:Jun 10 03:03:19 sf-02 kernel: lockmgr: thread 0xffffff0004a8b390 unlocking unheld lock it happens around 3 am, so I guess it must be some daily script that trips this. danny From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 07:40:08 2009 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 0E2A4106564A; Wed, 10 Jun 2009 07:40:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C244B8FC17; Wed, 10 Jun 2009 07:40:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5A7e5em021565; Wed, 10 Jun 2009 03:40:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5A7e5j7086039; Wed, 10 Jun 2009 03:40:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id EABC81B5060; Wed, 10 Jun 2009 03:40:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090610074004.EABC81B5060@freebsd-stable.sentex.ca> Date: Wed, 10 Jun 2009 03:40:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 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: Wed, 10 Jun 2009 07:40:08 -0000 TB --- 2009-06-10 06:35:37 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-06-10 06:35:37 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-06-10 06:35:37 - cleaning the object tree TB --- 2009-06-10 06:35:52 - cvsupping the source tree TB --- 2009-06-10 06:35:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-06-10 06:36:03 - building world TB --- 2009-06-10 06:36:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-10 06:36:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-10 06:36:03 - TARGET=i386 TB --- 2009-06-10 06:36:03 - TARGET_ARCH=i386 TB --- 2009-06-10 06:36:03 - TZ=UTC TB --- 2009-06-10 06:36:03 - __MAKE_CONF=/dev/null TB --- 2009-06-10 06:36:03 - cd /src TB --- 2009-06-10 06:36:03 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 10 06:36:04 UTC 2009 >>> 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 [...] cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/load_elf64_obj.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/reloc_elf64.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/bcache.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/isapnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/pnp.c cc -O2 -fno-strict-aliasing -pipe -DLOADER_ZFS_SUPPORT -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/i386/loader/../../ficl -I/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT -I/src/sys/boot/i386/loader/../../common -I. -Wall -I/src/sys/boot/i386/loader/.. -I/src/sys/boot/i386/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/i386/loader/../../common/interp_forth.c make: don't know how to make /obj/src/sys/boot/i386/loader/../../zfs/libzfsboot.a. Stop *** Error code 2 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-10 07:40:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-10 07:40:04 - ERROR: failed to build world TB --- 2009-06-10 07:40:04 - 2861.66 user 306.05 system 3866.99 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 12:46:37 2009 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 4FC9010656C0 for ; Wed, 10 Jun 2009 12:46:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B61CF8FC1D for ; Wed, 10 Jun 2009 12:46:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 91696 invoked from network); 10 Jun 2009 12:09:44 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jun 2009 12:09:44 -0000 Message-ID: <4A2FA4EF.5060603@freebsd.org> Date: Wed, 10 Jun 2009 14:19:59 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org Subject: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 12:46:37 -0000 Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config From here on it hangs and repeats the last message with some sort of exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock does. Hard reset is required to reboot. Booting the old 6.4 kernel works and the system comes up again with full access to the RAID array. Any help appreciated. -- Andre From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 13:19:29 2009 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 CCE901065672 for ; Wed, 10 Jun 2009 13:19:29 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by mx1.freebsd.org (Postfix) with ESMTP id A42668FC1C for ; Wed, 10 Jun 2009 13:19:29 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090610131917.HDDU2915.fed1rmmtao103.cox.net@fed1rmimpo02.cox.net>; Wed, 10 Jun 2009 09:19:17 -0400 Received: from vaio ([98.176.33.70]) by fed1rmimpo02.cox.net with bizsmtp id 2DKK1c0011WnGw204DKKKS; Wed, 10 Jun 2009 09:19:19 -0400 X-VR-Score: -240.00 X-Authority-Analysis: v=1.0 c=1 a=5F8ODknaBjMA:10 a=6I5d2MoRAAAA:8 a=b7s8li24_wH_wsZEL4gA:9 a=pCu8uaVQJGviNkyoHuwA:7 a=IthWybH-7WQ5_TJUjsWptyHtRcYA:4 a=SV7veod9ZcQA:10 a=1MdDLB7a_Z57_WnOw68A:9 a=t5_40jiVBb8M0ydsTmAA:7 a=Zx6Hkdf1YxTdp9glxw_czQk69fEA:4 X-CM-Score: 0.00 Date: Wed, 10 Jun 2009 06:19:13 -0700 From: Robert To: John Baldwin Message-ID: <20090610061913.04a97b6c@vaio> In-Reply-To: <200906081045.39497.jhb@freebsd.org> References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/y=ZNjVkUxLPDc26Dk.xyxMt" Cc: freebsd-stable@freebsd.org Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 13:19:30 -0000 --MP_/y=ZNjVkUxLPDc26Dk.xyxMt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 8 Jun 2009 10:45:39 -0400 John Baldwin wrote: > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > Greetings > > > > This problem seems the same as this one from May of this year > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > This happens on an older HP laptop. It was running on 7.1 prerelease > > fine and then I updated to 7.2 Stable yesterday. > > > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri > > Jun 5 11:47:29 PDT 2009 > > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > > > The bits from pciconf > > > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 > > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > > class = mass storage > > subclass = ATA > > > > The date of ata-chipset.c > > > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > > > The chipset is found in the above file > > > > ata_intel_ident(device_t dev) > > { > > struct ata_pci_controller *ctlr = device_get_softc(dev); > > static struct ata_chip_id ids[] = > > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > ^^^^^^^ > > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > > I can include the dump if needed but I am not at this time to > > shorten the email. But here is the panic. > > > > Dump header from device /dev/ad0s1b > > Architecture: i386 > > Architecture Version: 2 > > Dump Length: 68939776B (65 MB) > > Blocksize: 512 > > Dumptime: Sat Jun 6 05:40:52 2009 > > Hostname: hp.shasta204.local > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT > > 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > > Panic String: resource_list_alloc: resource entry is busy > > Dump Parity: 3285399556 > > Bounds: 1 > > Dump Status: good > > > > > > Any help would be greatly appreciated. > > The last screen of the dmesg output would be helpful. > I have installed 7.2 on the laptop because it would panic whenever going into multiuser. I would prefer to be on stable. Here is dmesg.boot. I hope that is what you wanted. Thank you Robert --MP_/y=ZNjVkUxLPDc26Dk.xyxMt Content-Type: application/octet-stream; name=dmesg.boot Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmesg.boot V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0 b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1 ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1h aW5pbmcuLi4xIDEgMSAwIDAgMCBkb25lCkFsbCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAzOW0y N3MKUmVib290aW5nLi4uCkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgNy4yLVJFTEVBU0UgIzA6 IFNhdCBKdW4gIDYgMTQ6MTE6MTUgUERUIDIwMDkKICAgIHJvb3RAcDQuc2hhc3RhMjA0LmxvY2Fs Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL1ZFU0EKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kg MTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbCBDZWxlcm9uICg3NDYuNzYtTUh6IDY4Ni1j bGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ODYgIFN0ZXBwaW5n ID0gNgogIEZlYXR1cmVzPTB4MzgzZjlmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NFPgpyZWFsIG1l bW9yeSAgPSAyNjgzNjk5MjAgKDI1NSBNQikKYXZhaWwgbWVtb3J5ID0gMjQ4NTEyNTEyICgyMzcg TUIpCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPFBUTFREICAgUlNEVD4gb24gbW90aGVyYm9hcmQK YWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIg IkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA4NTAKYWNwaV90aW1lcjA6 IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3Bp MAphY3BpX2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDk+IHBvcnQgMHg2MiwweDY2 IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQw OiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9idXR0b24xOiA8U2xl ZXAgQnV0dG9uPiBvbiBhY3BpMApiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVy eT4gb24gYWNwaTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCnBjaWIwOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYsMHgxMDAwLTB4MTAxNSBvbiBhY3Bp MApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAphZ3AwOiA8SW50ZWwgODI0NDNCWCAoNDQw IEJYKSBob3N0IHRvIFBDSSBicmlkZ2U+IG9uIGhvc3RiMApwY2liMTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MQpzM3BjaTA6IDxTMyBncmFwaGljIGNhcmQ+IHBvcnQgMHgzYzAtMHgzZGYsMHg0YWU4IG1lbSAw eGYwMDAwMDAwLTB4ZjdmZmZmZmYgaXJxIDExIGF0IGRldmljZSAxLjAgb24gcGNpMQpjYmIwOiA8 VEkxNDIwIFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4ODAwMDAwMDAtMHg4MDAwMGZmZiBhdCBk ZXZpY2UgNC4wIG9uIHBjaTAKY2FyZGJ1czA6IDxDYXJkQnVzIGJ1cz4gb24gY2JiMApwY2NhcmQw OiA8MTYtYml0IFBDQ2FyZCBidXM+IG9uIGNiYjAKY2JiMDogW0lUSFJFQURdCmNiYjE6IDxUSTE0 MjAgUENJLUNhcmRCdXMgQnJpZGdlPiBtZW0gMHg4MDAwMTAwMC0weDgwMDAxZmZmIGF0IGRldmlj ZSA0LjEgb24gcGNpMApjYXJkYnVzMTogPENhcmRCdXMgYnVzPiBvbiBjYmIxCnBjY2FyZDE6IDwx Ni1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMQpjYmIxOiBbSVRIUkVBRF0KaXNhYjA6IDxQQ0ktSVNB IGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAph dGFwY2kwOiA8SW50ZWwgUElJWDQgVURNQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcs MHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgxMDUwLTB4MTA1ZiBhdCBkZXZpY2UgNy4xIG9uIHBj aTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMDogW0lUSFJFQURdCmF0YTE6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTE6IFtJVEhSRUFEXQp1aGNpMDogPEludGVs IDgyMzcxQUIvRUIgKFBJSVg0KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDEwNjAtMHgxMDdmIGly cSA1IGF0IGRldmljZSA3LjIgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdWhjaTA6IFtJ VEhSRUFEXQp1c2IwOiA8SW50ZWwgODIzNzFBQi9FQiAoUElJWDQpIFVTQiBjb250cm9sbGVyPiBv biB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiA8SW50ZWwgVUhDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmludHNtYjA6IDxJbnRlbCBQSUlYNCBT TUJVUyBJbnRlcmZhY2U+IHBvcnQgMHgxMDQwLTB4MTA0ZiBhdCBkZXZpY2UgNy4zIG9uIHBjaTAK aW50c21iMDogaW50ciBJUlEgOSBlbmFibGVkIHJldmlzaW9uIDAKaW50c21iMDogW0dJQU5ULUxP Q0tFRF0KaW50c21iMDogW0lUSFJFQURdCmludHNtYjA6IFBNIEkvTyBtYXBwZWQgMTAwMApzbWJ1 czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGludHNtYjAKc21iMDogPFNNQnVzIGdlbmVy aWMgSS9PPiBvbiBzbWJ1czAKcGNtMDogPEVTUyBUZWNobm9sb2d5IEFsbGVncm8tMT4gcG9ydCAw eDE0MDAtMHgxNGZmIGlycSA1IGF0IGRldmljZSA4LjAgb24gcGNpMApwY20wOiBmYWlsZWQgdG8g ZW5hYmxlIG1lbW9yeSBtYXBwaW5nIQpwY20wOiBbSVRIUkVBRF0KcGNtMDogPEVTUyBUZWNobm9s b2d5IEVTMTk4OCBBQzk3IENvZGVjPgpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgOC4x IChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAph dGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEg MSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0 IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IDxQ Uy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBb SVRIUkVBRF0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNlLCBkZXZpY2UgSUQgMApzaW8w OiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxh Z3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQpzaW8wOiBbRklMVEVSXQpmZGMwOiA8 ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJx IDIgb24gYWNwaTAKZmRjMDogW0ZJTFRFUl0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBm ZGMwIGRyaXZlIDAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3Rocm90dGxlMDogPEFD UEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTAKc21pc3QwOiA8U3BlZWRTdGVwIFNNST4gb24gY3B1 MApkZXZpY2VfYXR0YWNoOiBzbWlzdDAgYXR0YWNoIHJldHVybmVkIDYKcG10aW1lcjAgb24gaXNh MApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2JmZmYsMHhkYzAw MC0weGRmZmZmIHBucGlkIE9STTAwMDAgb24gaXNhMApwcGMwOiA8UGFyYWxsZWwgcG9ydD4gYXQg cG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBpc2EwCnBwYzA6IFNNQy1saWtlIGNoaXBzZXQgKEVD UC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYzA6IEZJRk8gd2l0aCAxNi8x Ni83IGJ5dGVzIHRocmVzaG9sZApwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMApw cGJ1czA6IFtJVEhSRUFEXQpwbGlwMDogPFBMSVAgbmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVz MApwbGlwMDogV0FSTklORzogdXNpbmcgb2Jzb2xldGVkIElGRl9ORUVEU0dJQU5UIGZsYWcKbHB0 MDogPFByaW50ZXI+IG9uIHBwYnVzMApscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQKcHBpMDog PFBhcmFsbGVsIEkvTz4gb24gcHBidXMwCnBwYzA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IFtJVEhS RUFEXQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZH QSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzE6IGNvbmZpZ3VyZWQgaXJx IDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBl bmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0g MHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKdWtiZDA6IDxEZXZpY2UgV2lyZWxlc3MgTm90ZWJvb2sg S2V5cGFkL0NhbGN1bGF0b3IgYW5kIE1vdXNlIFNldCwgY2xhc3MgMC8wLCByZXYgMS4xMC8xLjAx LCBhZGRyIDI+IG9uIHVodWIwCmtiZDIgYXQgdWtiZDAKdW1zMDogPERldmljZSBXaXJlbGVzcyBO b3RlYm9vayBLZXlwYWQvQ2FsY3VsYXRvciBhbmQgTW91c2UgU2V0LCBjbGFzcyAwLzAsIHJldiAx LjEwLzEuMDEsIGFkZHIgMj4gb24gdWh1YjAKdW1zMDogNCBidXR0b25zIGFuZCBaIGRpci4KVGlt ZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDc0Njc1NzQ4NyBIeiBxdWFsaXR5IDgwMApUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmFkMDogOTU5ME1CIDxJQk0gREpTQS0yMTAgSlMy T0FCOEE+IGF0IGF0YTAtbWFzdGVyIFVETUEzMwpuZGlzMDogPFJlYWx0ZWsgUlRMODE4MCBXaXJl bGVzcyBMQU4gKE1pbmktKVBDSSBOSUM+IHBvcnQgMHgxMTAwLTB4MTFmZiBtZW0gMHg4ODAwMDAw MC0weDg4MDAwMWZmIGlycSAxMSBhdCBkZXZpY2UgMC4wIG9uIGNhcmRidXMxCm5kaXMwOiBbSVRI UkVBRF0KbmRpczA6IE5ESVMgQVBJIHZlcnNpb246IDUuMQphY2QwOiBEVkRST00gPE1BVFNISVRB RFZELVJPTSBTUi04MTc1L0cwMzU+IGF0IGF0YTEtbWFzdGVyIFVETUEzMwpuZGlzMDogV0FSTklO RzogdXNpbmcgb2Jzb2xldGVkIGlmX3dhdGNoZG9nIGludGVyZmFjZQpuZGlzMDogRXRoZXJuZXQg YWRkcmVzczogMDA6NTA6ZmM6ZjI6MmI6N2MKR0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVy IGZkMCBpcyB1ZnNpZC80M2QwNTQ4ZWIxZmEzNTBjLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJv dmlkZXIgYWQwczFhIGlzIHVmc2lkLzQ3YjViOGY1NDQ5MTVkNWUuCkdFT01fTEFCRUw6IExhYmVs IGZvciBwcm92aWRlciBhZDBzMWQgaXMgdWZzaWQvNDdiNWI4ZjY4YTk0YWVlMC4KR0VPTV9MQUJF TDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxZSBpcyB1ZnNpZC80N2I1YjhmN2RmZjE0NGIzLgpH RU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFmIGlzIHVmc2lkLzQ3YjViOGY1NGY0 MDAwMWEuCkdFT01fTEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzMWcgaXMgdWZzaWQvNDdi NWI4ZjY1MDZjODQyMS4KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEK R0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDdiNWI4ZjU0NDkxNWQ1ZSByZW1vdmVkLgpHRU9NX0xB QkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFhIGlzIHVmc2lkLzQ3YjViOGY1NDQ5MTVkNWUu CkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ3YjViOGY1NGY0MDAwMWEgcmVtb3ZlZC4KR0VPTV9M QUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxZiBpcyB1ZnNpZC80N2I1YjhmNTRmNDAwMDFh LgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80N2I1YjhmNjhhOTRhZWUwIHJlbW92ZWQuCkdFT01f TEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBhZDBzMWQgaXMgdWZzaWQvNDdiNWI4ZjY4YTk0YWVl MC4KR0VPTV9MQUJFTDogTGFiZWwgdWZzaWQvNDdiNWI4ZjY1MDZjODQyMSByZW1vdmVkLgpHRU9N X0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQwczFnIGlzIHVmc2lkLzQ3YjViOGY2NTA2Yzg0 MjEuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lkLzQ3YjViOGY3ZGZmMTQ0YjMgcmVtb3ZlZC4KR0VP TV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGFkMHMxZSBpcyB1ZnNpZC80N2I1YjhmN2RmZjE0 NGIzLgpHRU9NX0xBQkVMOiBMYWJlbCB1ZnNpZC80N2I1YjhmNTQ0OTE1ZDVlIHJlbW92ZWQuCkdF T01fTEFCRUw6IExhYmVsIHVmc2lkLzQ3YjViOGY1NGY0MDAwMWEgcmVtb3ZlZC4KR0VPTV9MQUJF TDogTGFiZWwgdWZzaWQvNDdiNWI4ZjY4YTk0YWVlMCByZW1vdmVkLgpHRU9NX0xBQkVMOiBMYWJl bCB1ZnNpZC80N2I1YjhmNjUwNmM4NDIxIHJlbW92ZWQuCkdFT01fTEFCRUw6IExhYmVsIHVmc2lk LzQ3YjViOGY3ZGZmMTQ0YjMgcmVtb3ZlZC4K --MP_/y=ZNjVkUxLPDc26Dk.xyxMt-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 13:23:31 2009 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 1A1C2106564A for ; Wed, 10 Jun 2009 13:23:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id DA8048FC14 for ; Wed, 10 Jun 2009 13:23:25 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n5ADLbds031697; Wed, 10 Jun 2009 09:21:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200906101321.n5ADLbds031697@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Jun 2009 09:23:30 -0400 To: Andre Oppermann , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4A2FA4EF.5060603@freebsd.org> References: <4A2FA4EF.5060603@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: scottl@freebsd.org Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 13:23:31 -0000 At 08:19 AM 6/10/2009, Andre Oppermann wrote: >Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big >nasty surprise with the Areca RAID controller: > >arcmsr0: > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >arcmsr0: [ITHREAD] >... >(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config Not sure if its a firmware issue or not, but I am running an AMD64 RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems "normal" in that I get it as well. I dont boot off the controller, so not sure if thats part of the issue or not. arcmsr0: mem 0xea600000-0xea600fff irq 18 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 arcmsr0: [ITHREAD] (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da1 at arcmsr0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: Command Queueing Enabled da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) da2 at arcmsr0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: Command Queueing Enabled da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 14:40:33 2009 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 3FC691065673 for ; Wed, 10 Jun 2009 14:40:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A3AD28FC22 for ; Wed, 10 Jun 2009 14:40:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 97886 invoked from network); 10 Jun 2009 14:30:20 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jun 2009 14:30:20 -0000 Message-ID: <4A2FC5E4.3000909@freebsd.org> Date: Wed, 10 Jun 2009 16:40:36 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mike Tancsa References: <4A2FA4EF.5060603@freebsd.org> <200906101321.n5ADLbds031697@lava.sentex.ca> In-Reply-To: <200906101321.n5ADLbds031697@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org, freebsd-stable@freebsd.org Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 14:40:33 -0000 Mike Tancsa wrote: > At 08:19 AM 6/10/2009, Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > > Not sure if its a firmware issue or not, but I am running an AMD64 > RELENG_7 kernel from Apr 23 and its works fine. The DV1 error seems > "normal" in that I get it as well. I dont boot off the controller, so > not sure if thats part of the issue or not. I did an firmware update after I encountered the issue the first time. Before it was V1.43. Exactly the same behavior. And yes, I do have to boot off the RAID. After the run_interrupt_driven_hooks everything hangs and no daX drives are ever detected. You don't seem to get this particular error. -- Andre > arcmsr0: > mem 0xea600000-0xea600fff irq 18 at device 14.0 on pci3 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.44 2008-2-1 > arcmsr0: [ITHREAD] > > (probe48:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > da1 at arcmsr0 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: Command Queueing Enabled > da1: 76293MB (156249600 512 byte sectors: 255H 63S/T 9726C) > da0 at twa0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 100.000MB/s transfers > da0: 66747MB (136697856 512 byte sectors: 255H 63S/T 8509C) > da2 at arcmsr0 bus 0 target 0 lun 1 > da2: Fixed Direct Access SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: Command Queueing Enabled > da2: 2784728MB (5703123456 512 byte sectors: 255H 63S/T 355003C) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 14:41:46 2009 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 205E11065674 for ; Wed, 10 Jun 2009 14:41:46 +0000 (UTC) (envelope-from dan@dburkland.com) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by mx1.freebsd.org (Postfix) with SMTP id C654E8FC26 for ; Wed, 10 Jun 2009 14:41:44 +0000 (UTC) (envelope-from dan@dburkland.com) Received: from source ([173.8.114.137]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKSi/GKOMtFaLIr60QpWRRAjcn0F4zsy23@postini.com; Wed, 10 Jun 2009 07:41:45 PDT Received: from mail.dburk.local ([10.0.0.4]) by mail ([10.0.0.4]) with mapi; Wed, 10 Jun 2009 09:30:46 -0500 From: Daniel Burkland To: "freebsd-stable@freebsd.org" Date: Wed, 10 Jun 2009 09:30:22 -0500 Thread-Topic: buildworld fails with "WITHOUT_CDDL=yes" in src.conf Thread-Index: AQHJ6dgKjJxrpJeRvEa+hiC8iP0w4g== Message-ID: <9BF0E9EFFF8AD245AAB6AAB1542D95967CF97561@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: buildworld fails with "WITHOUT_CDDL=yes" in src.conf 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, 10 Jun 2009 14:41:46 -0000 Thanks Kip I greatly appreciate the fix!= From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 14:58:05 2009 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 DB56A106564A; Wed, 10 Jun 2009 14:58:05 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [IPv6:2001:470:1f09:16f:2::3]) by mx1.freebsd.org (Postfix) with ESMTP id 92C3E8FC13; Wed, 10 Jun 2009 14:58:05 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id B0CFC454EC; Wed, 10 Jun 2009 15:58:04 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (filter.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id h+hjo1Yf7cVo; Wed, 10 Jun 2009 14:58:04 +0000 (UTC) Received: from [10.0.2.50] (daffy.tector.org.uk [82.71.32.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 9323F454B8; Wed, 10 Jun 2009 15:58:01 +0100 (BST) Message-ID: <4A2FC9F0.3060804@thekeelecentre.com> Date: Wed, 10 Jun 2009 15:57:52 +0100 From: Richard Tector User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mike Tancsa References: <4A2FA4EF.5060603@freebsd.org> <200906101321.n5ADLbds031697@lava.sentex.ca> In-Reply-To: <200906101321.n5ADLbds031697@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, scottl@freebsd.org, Andre Oppermann Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 14:58:06 -0000 Mike Tancsa wrote: > At 08:19 AM 6/10/2009, Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config As a further datapoint, I see no problems with amd64 RELENG_7 from May 20th, though I am running an older firmware version. I also don't appear to receive the probe error the two of you are seeing. arcmsr0: mem 0xf4500000-0xf4500fff,0xf4000000-0xf43fffff irq 18 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: Command Queueing Enabled da0: 1831054MB (3749999616 512 byte sectors: 255H 63S/T 233426C) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 15:04:51 2009 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 C6528106564A for ; Wed, 10 Jun 2009 15:04:51 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id 909118FC15 for ; Wed, 10 Jun 2009 15:04:51 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from localhost (maia-1.hub.org [200.46.208.211]) by hub.org (Postfix) with ESMTP id 94B7B345590C for ; Wed, 10 Jun 2009 12:04:48 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 25143-07 for ; Wed, 10 Jun 2009 12:04:48 -0300 (ADT) Received: by hub.org (Postfix, from userid 1002) id 57DBB34558D5; Wed, 10 Jun 2009 12:04:48 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by hub.org (Postfix) with ESMTP id 5786434558C9 for ; Wed, 10 Jun 2009 12:04:48 -0300 (ADT) Date: Wed, 10 Jun 2009 12:04:48 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20090610115351.V56412@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Server lock up: kern.maxswzone relate ... 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, 10 Jun 2009 15:04:52 -0000 I'm running a couple of brand new servers ... 32G of RAM, very little load on it right now, and this morning it locked up with that 'kern.maxswzone' error on the console ... The server is running a reasonably current 7.2-STABLE: FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 ADT And top right now, with everything running, shows no swappping, 19G of Free memory, 9G of Inact memory ... no reason to do any serious amount of swapping. last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 11:53:39 573 processes: 1 running, 571 sleeping, 1 zombie CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free Swap: 32G Total, 32G Free In fact, my other server (same config), has been up 9 days (they were put online 9 days ago), and tops shows it doing a little bit of swapping, but, again, huge amounts of Inact memory: last pid: 26307; load averages: 0.36, 0.35, 0.36 up 9+17:03:48 11:57:54 680 processes: 2 running, 657 sleeping, 21 zombie CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free Swap: 32G Total, 1044K Used, 32G Free So these servers right now are definitely not feeling any pain ... And, based on experiences with another server, I have my /boot/loader.conf set to: kern.maxswzone=67108864 So, the question is ... what am I missing? Is there some magical formula for calculating maxswzone that 7.2 is missing? Some nagios plug-in I shuld be using to monitor ... what? Help? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 15:09:26 2009 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 A3160106564A; Wed, 10 Jun 2009 15:09:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 57DDD8FC08; Wed, 10 Jun 2009 15:09:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5AEp4bU007905; Wed, 10 Jun 2009 08:51:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A2FC858.5050800@samsco.org> Date: Wed, 10 Jun 2009 08:51:04 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Andre Oppermann References: <4A2FA4EF.5060603@freebsd.org> In-Reply-To: <4A2FA4EF.5060603@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 15:09:26 -0000 Andre Oppermann wrote: > Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big > nasty surprise with the Areca RAID controller: > > arcmsr0: > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 > arcmsr0: [ITHREAD] > ... > (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > From here on it hangs and repeats the last message with some sort of > exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock > does. Hard reset is required to reboot. > > Booting the old 6.4 kernel works and the system comes up again with full > access to the RAID array. > > Any help appreciated. > I'll try to reproduce this locally. There have been sporadic reports of the "fails comparison" problem, but none as fatal as this. Is it possible to compile your kernel with CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? Scott From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 13:51:11 2009 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 14DE31065672 for ; Wed, 10 Jun 2009 13:51:11 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220]) by mx1.freebsd.org (Postfix) with ESMTP id 4981E8FC1F for ; Wed, 10 Jun 2009 13:51:03 +0000 (UTC) (envelope-from nkalev@gmail.com) Received: by fxm20 with SMTP id 20so728979fxm.43 for ; Wed, 10 Jun 2009 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MQZ53KZBuTDQeJxrkJ3nWS5Xbom9er9k045UCrkI61w=; b=Uh0a2YDfCE6VpJ+8AlrBMs7cW/LAqe14pFc9Uo6KsG5Gjnp47xcfCsgdJVwfSi48Wk siktw5ABM2GSzeriN1gjrasucaOoWBWzvp7j7Am5/U7LNxklK61oKso0/4yYxYo8XY/z Ot2Ge6KZGcgvZgJX2hXxynV3AmIZ4RKxlBk+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V9hMGg5nHiAoDfBMu/1tpf2d0qZ+YAem6PdFn0nPLBzcanrkcXfepNA86aBWlMTYwp zDrTIsWQCW8Cd8yKNE3jJzn4wWx7FAOtZBh3lsLBzhxNk9RqP78XyxYNaOQ7zVCBCeiy iwboMQQwvETbBEOlnsQl/ywjHGkZ7VJQyYhf0= MIME-Version: 1.0 Received: by 10.223.126.145 with SMTP id c17mr1215031fas.102.1244640064311; Wed, 10 Jun 2009 06:21:04 -0700 (PDT) Date: Wed, 10 Jun 2009 16:21:04 +0300 Message-ID: <136a340a0906100621n48400e57r1fc6fbedc3e3178d@mail.gmail.com> From: Nikolay Kalev To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=001636c5a736e814a8046bfe584d X-Mailman-Approved-At: Wed, 10 Jun 2009 15:24:00 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dell R710 4GB PERC 6/i crashing on high I/O 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, 10 Jun 2009 13:51:11 -0000 --001636c5a736e814a8046bfe584d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all, I wanted to ask if anyone had issues with Dell R710 4GB with PERC 6/i on heavy I/O. I cannot for sure determine that the issue is indeed with the PERC 6/i controller or hardware problem. I got the following output after some hammering with creating localy files 1-10GB with dd and doing rsync via the network interface. I've attached the pictures from the KVM. First one is with the box before upgrade to BIOS 1.1.4 and firmware of PERC 6/i to 6.2.0.0.13 Second one is after the upgrade. Any ideas ? --001636c5a736e814a8046bfe584d-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 15:37:02 2009 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 A55811065673 for ; Wed, 10 Jun 2009 15:37:02 +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 26B6C8FC16 for ; Wed, 10 Jun 2009 15:37:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CF6E646B1A; Wed, 10 Jun 2009 11:37:01 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C74258A06A; Wed, 10 Jun 2009 11:37:00 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 10 Jun 2009 10:38:36 -0400 User-Agent: KMail/1.9.7 References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> <20090610061913.04a97b6c@vaio> In-Reply-To: <20090610061913.04a97b6c@vaio> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101038.37028.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 11:37:00 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Robert Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 15:37:03 -0000 On Wednesday 10 June 2009 9:19:13 am Robert wrote: > On Mon, 8 Jun 2009 10:45:39 -0400 > John Baldwin wrote: > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > Greetings > > > > > > This problem seems the same as this one from May of this year > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > This happens on an older HP laptop. It was running on 7.1 prerelease > > > fine and then I updated to 7.2 Stable yesterday. > > > > > > FreeBSD hp.shasta204.local 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri > > > Jun 5 11:47:29 PDT 2009 > > > root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA i386 > > > > > > The bits from pciconf > > > > > > atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 > > > chip=0x71118086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' > > > device = '82371AB/EB/MB PIIX4/4E/4M IDE Controller' > > > class = mass storage > > > subclass = ATA > > > > > > The date of ata-chipset.c > > > > > > -rw-r--r-- 1 root wheel 188823 May 22 02:21 ata-chipset.c > > > > > > The chipset is found in the above file > > > > > > ata_intel_ident(device_t dev) > > > { > > > struct ata_pci_controller *ctlr = device_get_softc(dev); > > > static struct ata_chip_id ids[] = > > > {{ ATA_I82371FB, 0, 0, 2, ATA_WDMA2, "PIIX" }, > > > { ATA_I82371SB, 0, 0, 2, ATA_WDMA2, "PIIX3" }, > > > { ATA_I82371AB, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > ^^^^^^^ > > > { ATA_I82443MX, 0, 0, 2, ATA_UDMA2, "PIIX4" }, > > > > > > I can include the dump if needed but I am not at this time to > > > shorten the email. But here is the panic. > > > > > > Dump header from device /dev/ad0s1b > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 68939776B (65 MB) > > > Blocksize: 512 > > > Dumptime: Sat Jun 6 05:40:52 2009 > > > Hostname: hp.shasta204.local > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 7.2-STABLE #0: Fri Jun 5 11:47:29 PDT > > > 2009 root@vaio.shasta204.local:/usr/obj/usr/src/sys/VESA > > > Panic String: resource_list_alloc: resource entry is busy > > > Dump Parity: 3285399556 > > > Bounds: 1 > > > Dump Status: good > > > > > > > > > Any help would be greatly appreciated. > > > > The last screen of the dmesg output would be helpful. > > > I have installed 7.2 on the laptop because it would panic whenever > going into multiuser. I would prefer to be on stable. > > Here is dmesg.boot. I hope that is what you wanted. Hmm, can you get the stack trace from the dump that you have? I'm curious which device driver is triggering the panic. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 15:37:43 2009 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 3B07A1065673 for ; Wed, 10 Jun 2009 15:37:43 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE7E8FC1D for ; Wed, 10 Jun 2009 15:37:40 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from giskard.altus-escon.com (giskard.altus-escon.com [193.78.231.1]) by altus-escon.com (8.14.3/8.14.3) with ESMTP id n5AF2eAH097741 for ; Wed, 10 Jun 2009 17:02:45 +0200 (CEST) (envelope-from ben@altesco.nl) Message-Id: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> From: Ben Stuyts To: stable@freebsd.org Content-Type: multipart/mixed; boundary=Apple-Mail-19-50987061 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 17:02:39 +0200 X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [193.78.231.142]); Wed, 10 Jun 2009 17:02:45 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9450/Wed Jun 10 15:41:08 2009 on mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-3.2 required=3.5 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Subject: Xorg keyboard and mouse hung 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, 10 Jun 2009 15:37:43 -0000 --Apple-Mail-19-50987061 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ world of today, and now the mouse and keyboard don't react anymore in the Xorg / KDE login window. Mouse doesn't move, keyboard characters don't appear in the login prompt. I can still switch back with ctl-alt- F1 to a console login, and there both the keyboard and mouse still work. I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf as the default settings used to work fine. Any ideas? Thanks, Ben --Apple-Mail-19-50987061 Content-Disposition: attachment; filename=dmesg.boot Content-Type: application/octet-stream; x-unix-mode=0644; name="dmesg.boot" Content-Transfer-Encoding: 7bit Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #3: Wed Jun 10 16:06:06 CEST 2009 root@jirad.altus-escon.com:/usr/obj/.amd_mnt/mars/host/usr/src7/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) D CPU 3.06GHz (3060.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf65 Stepping = 5 Features=0xbfebfbff Features2=0xe41d AMD Features=0x20000000 AMD Features2=0x1 real memory = 737083392 (702 MB) avail memory = 707244032 (674 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2bdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf4000000-0xf7ffffff,0xfb000000-0xfbffffff irq 16 at device 0.0 on pci1 atapci0: port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe000-0xe01f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd400-0xd41f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfdfff000-0xfdfff0ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: waiting for BIOS to give up control usb4: timed out waiting for BIOS usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) vr0: port 0xcc00-0xccff mem 0xfdffe000-0xfdffe0ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x78 miibus0: on vr0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:16:17:8c:c5:9d vr0: [ITHREAD] acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xd4000-0xd5fff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 umass0: on uhub2 Timecounter "TSC" frequency 3060714190 Hz quality 800 Timecounters tick every 1.000 msec ad0: 78533MB at ata0-master UDMA133 acd0: DVDROM at ata1-slave UDMA33 GEOM_LABEL: Label for provider ad0s1a is ufsid/4644cd2ba5c9ff8c. (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:1): Medium not present (probe0:umass-sim0:0:0:1): Unretryable error (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI Status: Check Condition (probe0:umass-sim0:0:0:2): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:2): Medium not present (probe0:umass-sim0:0:0:2): Unretryable error (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI Status: Check Condition (probe0:umass-sim0:0:0:3): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:3): Medium not present (probe0:umass-sim0:0:0:3): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ufsid/4644cd2ba5c9ff8c removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/4644cd2ba5c9ff8c. GEOM_LABEL: Label ufsid/4644cd2ba5c9ff8c removed. --Apple-Mail-19-50987061 Content-Disposition: attachment; filename=Xorg.0.log Content-Type: application/octet-stream; x-unix-mode=0644; name="Xorg.0.log" Content-Transfer-Encoding: quoted-printable =0AX.Org=20X=20Server=201.6.1=0ARelease=20Date:=202009-4-14=0AX=20= Protocol=20Version=2011,=20Revision=200=0ABuild=20Operating=20System:=20= FreeBSD=207.2-STABLE=20i386=20=0ACurrent=20Operating=20System:=20FreeBSD=20= jirad.altus-escon.com=207.2-STABLE=20FreeBSD=207.2-STABLE=20#3:=20Wed=20= Jun=2010=2016:06:06=20CEST=202009=20=20=20=20=20= root@jirad.altus-escon.com:/usr/obj/.amd_mnt/mars/host/usr/src7/sys/GENERI= C=20i386=0ABuild=20Date:=2026=20May=202009=20=2009:34:49PM=0A=20=0A=09= Before=20reporting=20problems,=20check=20http://wiki.x.org=0A=09to=20= make=20sure=20that=20you=20have=20the=20latest=20version.=0AMarkers:=20= (--)=20probed,=20(**)=20from=20config=20file,=20(=3D=3D)=20default=20= setting,=0A=09(++)=20from=20command=20line,=20(!!)=20notice,=20(II)=20= informational,=0A=09(WW)=20warning,=20(EE)=20error,=20(NI)=20not=20= implemented,=20(??)=20unknown.=0A(=3D=3D)=20Log=20file:=20= "/var/log/Xorg.0.log",=20Time:=20Wed=20Jun=2010=2016:33:49=202009=0A(II)=20= Loader=20magic:=200x6a0=0A(II)=20Module=20ABI=20versions:=0A=09X.Org=20= ANSI=20C=20Emulation:=200.4=0A=09X.Org=20Video=20Driver:=205.0=0A=09= X.Org=20XInput=20driver=20:=204.0=0A=09X.Org=20Server=20Extension=20:=20= 2.0=0A(II)=20Loader=20running=20on=20freebsd=0A(--)=20Using=20syscons=20= driver=20with=20X=20support=20(version=202.0)=0A(--)=20using=20VT=20= number=209=0A=0A(--)=20PCI:*(0@1:0:0)=20VIA=20Technologies,=20Inc.=20= CN700/P4M800=20Pro/P4M800=20CE/VN800=20[S3=20UniChrome=20Pro]=20rev=201,=20= Mem=20@=200xf4000000/67108864,=200xfb000000/16777216,=20BIOS=20@=20= 0x????????/65536=0A(=3D=3D)=20Using=20default=20built-in=20configuration=20= (30=20lines)=0A(=3D=3D)=20---=20Start=20of=20built-in=20configuration=20= ---=0A=09Section=20"Device"=0A=09=09Identifier=09"Builtin=20Default=20= openchrome=20Device=200"=0A=09=09Driver=09"openchrome"=0A=09EndSection=0A= =09Section=20"Screen"=0A=09=09Identifier=09"Builtin=20Default=20= openchrome=20Screen=200"=0A=09=09Device=09"Builtin=20Default=20= openchrome=20Device=200"=0A=09EndSection=0A=09Section=20"Device"=0A=09=09= Identifier=09"Builtin=20Default=20vesa=20Device=200"=0A=09=09Driver=09= "vesa"=0A=09EndSection=0A=09Section=20"Screen"=0A=09=09Identifier=09= "Builtin=20Default=20vesa=20Screen=200"=0A=09=09Device=09"Builtin=20= Default=20vesa=20Device=200"=0A=09EndSection=0A=09Section=20"Device"=0A=09= =09Identifier=09"Builtin=20Default=20fbdev=20Device=200"=0A=09=09Driver=09= "fbdev"=0A=09EndSection=0A=09Section=20"Screen"=0A=09=09Identifier=09= "Builtin=20Default=20fbdev=20Screen=200"=0A=09=09Device=09"Builtin=20= Default=20fbdev=20Device=200"=0A=09EndSection=0A=09Section=20= "ServerLayout"=0A=09=09Identifier=09"Builtin=20Default=20Layout"=0A=09=09= Screen=09"Builtin=20Default=20openchrome=20Screen=200"=0A=09=09Screen=09= "Builtin=20Default=20vesa=20Screen=200"=0A=09=09Screen=09"Builtin=20= Default=20fbdev=20Screen=200"=0A=09EndSection=0A(=3D=3D)=20---=20End=20= of=20built-in=20configuration=20---=0A(=3D=3D)=20ServerLayout=20"Builtin=20= Default=20Layout"=0A(**)=20|-->Screen=20"Builtin=20Default=20openchrome=20= Screen=200"=20(0)=0A(**)=20|=20=20=20|-->Monitor=20""=0A= (**)=20|=20=20=20|-->Device=20"Builtin=20Default=20openchrome=20Device=20= 0"=0A(=3D=3D)=20No=20monitor=20specified=20for=20screen=20"Builtin=20= Default=20openchrome=20Screen=200".=0A=09Using=20a=20default=20monitor=20= configuration.=0A(**)=20|-->Screen=20"Builtin=20Default=20vesa=20Screen=20= 0"=20(1)=0A(**)=20|=20=20=20|-->Monitor=20""=0A(**)=20= |=20=20=20|-->Device=20"Builtin=20Default=20vesa=20Device=200"=0A(=3D=3D)=20= No=20monitor=20specified=20for=20screen=20"Builtin=20Default=20vesa=20= Screen=200".=0A=09Using=20a=20default=20monitor=20configuration.=0A(**)=20= |-->Screen=20"Builtin=20Default=20fbdev=20Screen=200"=20(2)=0A(**)=20|=20= =20=20|-->Monitor=20""=0A(**)=20|=20=20=20|-->Device=20= "Builtin=20Default=20fbdev=20Device=200"=0A(=3D=3D)=20No=20monitor=20= specified=20for=20screen=20"Builtin=20Default=20fbdev=20Screen=200".=0A=09= Using=20a=20default=20monitor=20configuration.=0A(=3D=3D)=20= Automatically=20adding=20devices=0A(=3D=3D)=20Automatically=20enabling=20= devices=0A(=3D=3D)=20FontPath=20set=20to:=0A=09= /usr/local/lib/X11/fonts/misc/,=0A=09/usr/local/lib/X11/fonts/TTF/,=0A=09= /usr/local/lib/X11/fonts/OTF,=0A=09/usr/local/lib/X11/fonts/Type1/,=0A=09= /usr/local/lib/X11/fonts/100dpi/,=0A=09/usr/local/lib/X11/fonts/75dpi/,=0A= =09built-ins=0A(=3D=3D)=20ModulePath=20set=20to=20= "/usr/local/lib/xorg/modules"=0A(II)=20Cannot=20locate=20a=20core=20= pointer=20device.=0A(II)=20Cannot=20locate=20a=20core=20keyboard=20= device.=0A(II)=20The=20server=20relies=20on=20HAL=20to=20provide=20the=20= list=20of=20input=20devices.=0A=09If=20no=20devices=20become=20= available,=20reconfigure=20HAL=20or=20disable=20AllowEmptyInput.=0A(II)=20= System=20resource=20ranges:=0A=09[0]=20-1=090=090x000f0000=20-=20= 0x000fffff=20(0x10000)=20MX[B]=0A=09[1]=20-1=090=090x000c0000=20-=20= 0x000effff=20(0x30000)=20MX[B]=0A=09[2]=20-1=090=090x00000000=20-=20= 0x0009ffff=20(0xa0000)=20MX[B]=0A=09[3]=20-1=090=090x0000ffff=20-=20= 0x0000ffff=20(0x1)=20IX[B]=0A=09[4]=20-1=090=090x00000000=20-=20= 0x000000ff=20(0x100)=20IX[B]=0A(II)=20LoadModule:=20"extmod"=0A(II)=20= Loading=20/usr/local/lib/xorg/modules/extensions//libextmod.so=0A(II)=20= Module=20extmod:=20vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=20= 1.6.1,=20module=20version=20=3D=201.0.0=0A=09Module=20class:=20X.Org=20= Server=20Extension=0A=09ABI=20class:=20X.Org=20Server=20Extension,=20= version=202.0=0A(II)=20Loading=20extension=20MIT-SCREEN-SAVER=0A(II)=20= Loading=20extension=20XFree86-VidModeExtension=0A(II)=20Loading=20= extension=20XFree86-DGA=0A(II)=20Loading=20extension=20DPMS=0A(II)=20= Loading=20extension=20XVideo=0A(II)=20Loading=20extension=20= XVideo-MotionCompensation=0A(II)=20Loading=20extension=20X-Resource=0A= (II)=20LoadModule:=20"dbe"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules/extensions//libdbe.so=0A(II)=20Module=20dbe:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.0.0=0A=09Module=20class:=20X.Org=20Server=20Extension=0A= =09ABI=20class:=20X.Org=20Server=20Extension,=20version=202.0=0A(II)=20= Loading=20extension=20DOUBLE-BUFFER=0A(II)=20LoadModule:=20"glx"=0A(II)=20= Loading=20/usr/local/lib/xorg/modules/extensions//libglx.so=0A(II)=20= Module=20glx:=20vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=20= 1.6.1,=20module=20version=20=3D=201.0.0=0A=09ABI=20class:=20X.Org=20= Server=20Extension,=20version=202.0=0A(=3D=3D)=20AIGLX=20disabled=0A(II)=20= Loading=20extension=20GLX=0A(II)=20LoadModule:=20"record"=0A(II)=20= Loading=20/usr/local/lib/xorg/modules/extensions//librecord.so=0A(II)=20= Module=20record:=20vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=20= 1.6.1,=20module=20version=20=3D=201.13.0=0A=09Module=20class:=20X.Org=20= Server=20Extension=0A=09ABI=20class:=20X.Org=20Server=20Extension,=20= version=202.0=0A(II)=20Loading=20extension=20RECORD=0A(II)=20LoadModule:=20= "dri"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules/extensions//libdri.so=0A(II)=20Module=20dri:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.0.0=0A=09ABI=20class:=20X.Org=20Server=20Extension,=20= version=202.0=0A(II)=20Loading=20extension=20XFree86-DRI=0A(II)=20= LoadModule:=20"dri2"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules/extensions//libdri2.so=0A(II)=20Module=20= dri2:=20vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20= module=20version=20=3D=201.0.0=0A=09ABI=20class:=20X.Org=20Server=20= Extension,=20version=202.0=0A(II)=20Loading=20extension=20DRI2=0A(II)=20= LoadModule:=20"openchrome"=0A(WW)=20Warning,=20couldn't=20open=20module=20= openchrome=0A(II)=20UnloadModule:=20"openchrome"=0A(EE)=20Failed=20to=20= load=20module=20"openchrome"=20(module=20does=20not=20exist,=200)=0A(II)=20= LoadModule:=20"vesa"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules/drivers//vesa_drv.so=0A(II)=20Module=20vesa:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=202.1.0=0A=09Module=20class:=20X.Org=20Video=20Driver=0A=09= ABI=20class:=20X.Org=20Video=20Driver,=20version=205.0=0A(II)=20= LoadModule:=20"fbdev"=0A(WW)=20Warning,=20couldn't=20open=20module=20= fbdev=0A(II)=20UnloadModule:=20"fbdev"=0A(EE)=20Failed=20to=20load=20= module=20"fbdev"=20(module=20does=20not=20exist,=200)=0A(II)=20VESA:=20= driver=20for=20VESA=20chipsets:=20vesa=0A(II)=20Primary=20Device=20is:=20= PCI=2001@00:00:0=0A(II)=20resource=20ranges=20after=20probing:=0A=09[0]=20= -1=090=090x000f0000=20-=200x000fffff=20(0x10000)=20MX[B]=0A=09[1]=20-1=09= 0=090x000c0000=20-=200x000effff=20(0x30000)=20MX[B]=0A=09[2]=20-1=090=09= 0x00000000=20-=200x0009ffff=20(0xa0000)=20MX[B]=0A=09[3]=20-1=090=09= 0x0000ffff=20-=200x0000ffff=20(0x1)=20IX[B]=0A=09[4]=20-1=090=09= 0x00000000=20-=200x000000ff=20(0x100)=20IX[B]=0A(II)=20Loading=20sub=20= module=20"vbe"=0A(II)=20LoadModule:=20"vbe"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules//libvbe.so=0A(II)=20Module=20vbe:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.1.0=0A=09ABI=20class:=20X.Org=20Video=20Driver,=20= version=205.0=0A(II)=20Loading=20sub=20module=20"int10"=0A(II)=20= LoadModule:=20"int10"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules//libint10.so=0A(II)=20Module=20int10:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.0.0=0A=09ABI=20class:=20X.Org=20Video=20Driver,=20= version=205.0=0A(II)=20VESA(0):=20initializing=20int10=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0xa0000,0x20000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0xc0000,0x40000)=20was=20already=20clear=0A(II)=20VESA(0):=20Primary=20= V_BIOS=20segment=20is:=200xc000=0A(=3D=3D)=20VESA(0):=20Write-combining=20= range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(II)=20VESA(0):=20VESA=20BIOS=20detected=0A(II)=20VESA(0):=20= VESA=20VBE=20Version=203.0=0A(II)=20VESA(0):=20VESA=20VBE=20Total=20Mem:=20= 65536=20kB=0A(II)=20VESA(0):=20VESA=20VBE=20OEM:=20VIA=20P4M800=20PRO=0D=0A= =0A(II)=20VESA(0):=20VESA=20VBE=20OEM=20Software=20Rev:=201.0=0A(II)=20= VESA(0):=20VESA=20VBE=20OEM=20Vendor:=20=0A(II)=20VESA(0):=20VESA=20VBE=20= OEM=20Product:=20=0A(II)=20VESA(0):=20VESA=20VBE=20OEM=20Product=20Rev:=20= =0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20= already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(II)=20VESA(0):=20Creating=20= default=20Display=20subsection=20in=20Screen=20section=0A=09"Builtin=20= Default=20vesa=20Screen=200"=20for=20depth/fbbpp=2024/32=0A(=3D=3D)=20= VESA(0):=20Depth=2024,=20(--)=20framebuffer=20bpp=2032=0A(=3D=3D)=20= VESA(0):=20RGB=20weight=20888=0A(=3D=3D)=20VESA(0):=20Default=20visual=20= is=20TrueColor=0A(=3D=3D)=20VESA(0):=20Using=20gamma=20correction=20= (1.0,=201.0,=201.0)=0A(II)=20Loading=20sub=20module=20"ddc"=0A(II)=20= LoadModule:=20"ddc"=0A(II)=20Module=20"ddc"=20already=20built-in=0A(=3D=3D= )=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(II)=20VESA(0):=20VESA=20VBE=20DDC=20supported=0A= (II)=20VESA(0):=20VESA=20VBE=20DDC=20Level=202=0A(II)=20VESA(0):=20VESA=20= VBE=20DDC=20transfer=20in=20appr.=201=20sec.=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(II)=20VESA(0):=20VESA=20VBE=20DDC=20read=20successfully=0A(II)=20= VESA(0):=20Manufacturer:=20BNQ=20=20Model:=2076bd=20=20Serial#:=2010032=0A= (II)=20VESA(0):=20Year:=202007=20=20Week:=2011=0A(II)=20VESA(0):=20EDID=20= Version:=201.3=0A(II)=20VESA(0):=20Analog=20Display=20Input,=20=20Input=20= Voltage=20Level:=200.700/0.700=20V=0A(II)=20VESA(0):=20Sync:=20=20= Separate=20=20Composite=0A(II)=20VESA(0):=20Max=20Image=20Size=20[cm]:=20= horiz.:=2038=20=20vert.:=2030=0A(II)=20VESA(0):=20Gamma:=202.20=0A(II)=20= VESA(0):=20DPMS=20capabilities:=20StandBy=20Suspend=20Off;=20RGB/Color=20= Display=0A(II)=20VESA(0):=20First=20detailed=20timing=20is=20preferred=20= mode=0A(II)=20VESA(0):=20redX:=200.634=20redY:=200.354=20=20=20greenX:=20= 0.300=20greenY:=200.614=0A(II)=20VESA(0):=20blueX:=200.138=20blueY:=20= 0.076=20=20=20whiteX:=200.310=20whiteY:=200.330=0A(II)=20VESA(0):=20= Supported=20VESA=20Video=20Modes:=0A(II)=20VESA(0):=20720x400@70Hz=0A= (II)=20VESA(0):=20640x480@60Hz=0A(II)=20VESA(0):=20640x480@67Hz=0A(II)=20= VESA(0):=20640x480@72Hz=0A(II)=20VESA(0):=20640x480@75Hz=0A(II)=20= VESA(0):=20800x600@60Hz=0A(II)=20VESA(0):=20800x600@72Hz=0A(II)=20= VESA(0):=20800x600@75Hz=0A(II)=20VESA(0):=20832x624@75Hz=0A(II)=20= VESA(0):=201024x768@60Hz=0A(II)=20VESA(0):=201024x768@70Hz=0A(II)=20= VESA(0):=201024x768@75Hz=0A(II)=20VESA(0):=201280x1024@75Hz=0A(II)=20= VESA(0):=201152x870@75Hz=0A(II)=20VESA(0):=20Manufacturer's=20mask:=200=0A= (II)=20VESA(0):=20Supported=20Future=20Video=20Modes:=0A(II)=20VESA(0):=20= #0:=20hsize:=201152=20=20vsize=20864=20=20refresh:=2075=20=20vid:=20= 20337=0A(II)=20VESA(0):=20#1:=20hsize:=201280=20=20vsize=201024=20=20= refresh:=2076=20=20vid:=2036993=0A(II)=20VESA(0):=20#2:=20hsize:=201280=20= =20vsize=201024=20=20refresh:=2060=20=20vid:=2032897=0A(II)=20VESA(0):=20= #3:=20hsize:=201280=20=20vsize=201024=20=20refresh:=2072=20=20vid:=20= 35969=0A(II)=20VESA(0):=20Supported=20additional=20Video=20Mode:=0A(II)=20= VESA(0):=20clock:=20108.0=20MHz=20=20=20Image=20Size:=20=20376=20x=20301=20= mm=0A(II)=20VESA(0):=20h_active:=201280=20=20h_sync:=201328=20=20= h_sync_end=201440=20h_blank_end=201688=20h_border:=200=0A(II)=20VESA(0):=20= v_active:=201024=20=20v_sync:=201025=20=20v_sync_end=201028=20= v_blanking:=201066=20v_border:=200=0A(II)=20VESA(0):=20Supported=20= additional=20Video=20Mode:=0A(II)=20VESA(0):=20clock:=2025.2=20MHz=20=20=20= Image=20Size:=20=20376=20x=20301=20mm=0A(II)=20VESA(0):=20h_active:=20= 640=20=20h_sync:=20656=20=20h_sync_end=20752=20h_blank_end=20800=20= h_border:=200=0A(II)=20VESA(0):=20v_active:=20350=20=20v_sync:=20387=20=20= v_sync_end=20389=20v_blanking:=20449=20v_border:=200=0A(II)=20VESA(0):=20= Ranges:=20V=20min:=2056=20V=20max:=2076=20Hz,=20H=20min:=2031=20H=20max:=20= 83=20kHz,=20PixClock=20max=20140=20MHz=0A(II)=20VESA(0):=20Monitor=20= name:=20BenQ=20FP91GX=0A(II)=20VESA(0):=20EDID=20(in=20hex):=0A(II)=20= VESA(0):=20=0900ffffffffffff0009d1bd7630270000=0A(II)=20VESA(0):=20=09= 0b1101036c261e78ea6d66a25a4c9d23=0A(II)=20VESA(0):=20=09= 134f54bdef80714f81908180818c0101=0A(II)=20VESA(0):=20=09= 010101010101302a009851002a403070=0A(II)=20VESA(0):=20=09= 1300782d1100001ed50980a0205e6310=0A(II)=20VESA(0):=20=09= 10605208782d1100001a000000fd0038=0A(II)=20VESA(0):=20=09= 4c1f530e000a202020202020000000fc=0A(II)=20VESA(0):=20=09= 0042656e51204650393147580a2000f9=0A(II)=20VESA(0):=20EDID=20vendor=20= "BNQ",=20prod=20id=2030397=0A(II)=20VESA(0):=20Using=20EDID=20range=20= info=20for=20horizontal=20sync=0A(II)=20VESA(0):=20Using=20EDID=20range=20= info=20for=20vertical=20refresh=0A(II)=20VESA(0):=20Printing=20DDC=20= gathered=20Modelines:=0A(II)=20VESA(0):=20Modeline=20"1280x1024"x0.0=20=20= 108.00=20=201280=201328=201440=201688=20=201024=201025=201028=201066=20= +hsync=20+vsync=20(64.0=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "640x350"x0.0=20=20=2025.17=20=20640=20656=20752=20800=20=20350=20387=20= 389=20449=20+hsync=20-vsync=20(31.5=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "800x600"x0.0=20=20=2040.00=20=20800=20840=20968=201056=20=20600=20601=20= 605=20628=20+hsync=20+vsync=20(37.9=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "640x480"x0.0=20=20=2031.50=20=20640=20656=20720=20840=20=20480=20481=20= 484=20500=20-hsync=20-vsync=20(37.5=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "640x480"x0.0=20=20=2031.50=20=20640=20664=20704=20832=20=20480=20489=20= 492=20520=20-hsync=20-vsync=20(37.9=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "640x480"x0.0=20=20=2030.24=20=20640=20704=20768=20864=20=20480=20483=20= 486=20525=20-hsync=20-vsync=20(35.0=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "640x480"x0.0=20=20=2025.18=20=20640=20656=20752=20800=20=20480=20490=20= 492=20525=20-hsync=20-vsync=20(31.5=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "720x400"x0.0=20=20=2028.32=20=20720=20738=20846=20900=20=20400=20412=20= 414=20449=20-hsync=20+vsync=20(31.5=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "1280x1024"x0.0=20=20135.00=20=201280=201296=201440=201688=20=201024=20= 1025=201028=201066=20+hsync=20+vsync=20(80.0=20kHz)=0A(II)=20VESA(0):=20= Modeline=20"1024x768"x0.0=20=20=2078.75=20=201024=201040=201136=201312=20= =20768=20769=20772=20800=20+hsync=20+vsync=20(60.0=20kHz)=0A(II)=20= VESA(0):=20Modeline=20"1024x768"x0.0=20=20=2075.00=20=201024=201048=20= 1184=201328=20=20768=20771=20777=20806=20-hsync=20-vsync=20(56.5=20kHz)=0A= (II)=20VESA(0):=20Modeline=20"1024x768"x0.0=20=20=2065.00=20=201024=20= 1048=201184=201344=20=20768=20771=20777=20806=20-hsync=20-vsync=20(48.4=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"832x624"x0.0=20=20=2057.28=20=20832=20= 864=20928=201152=20=20624=20625=20628=20667=20-hsync=20-vsync=20(49.7=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"800x600"x0.0=20=20=2049.50=20=20800=20= 816=20896=201056=20=20600=20601=20604=20625=20+hsync=20+vsync=20(46.9=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"800x600"x0.0=20=20=2050.00=20=20800=20= 856=20976=201040=20=20600=20637=20643=20666=20+hsync=20+vsync=20(48.1=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"1152x864"x0.0=20=20108.00=20=201152=20= 1216=201344=201600=20=20864=20865=20868=20900=20+hsync=20+vsync=20(67.5=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"1152x864"x0.0=20=20108.00=20=201152=20= 1216=201344=201600=20=20864=20865=20868=20900=20+hsync=20+vsync=20(67.5=20= kHz)=0A(II)=20VESA(0):=20Modeline=20"1280x1024"x76.0=20=20141.82=20=20= 1280=201376=201512=201744=20=201024=201025=201028=201070=20-hsync=20= +vsync=20(81.3=20kHz)=0A(II)=20VESA(0):=20Modeline=20"1280x1024"x0.0=20=20= 108.00=20=201280=201328=201440=201688=20=201024=201025=201028=201066=20= +hsync=20+vsync=20(64.0=20kHz)=0A(II)=20VESA(0):=20Modeline=20= "1280x1024"x72.0=20=20132.75=20=201280=201368=201504=201728=20=201024=20= 1025=201028=201067=20-hsync=20+vsync=20(76.8=20kHz)=0A(II)=20VESA(0):=20= Searching=20for=20matching=20VESA=20mode(s):=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20101=20(640x480)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=20640=0A=09= XResolution:=20640=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=20203=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A= =09GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=20= 0=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=20640=0A=09BnkNumberOfImagePages:=20= 203=0A=09LinNumberOfImagePages:=20203=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20111=20(640x480)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201280=0A=09= XResolution:=20640=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=20101=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=201280=0A=09BnkNumberOfImagePages:=20= 101=0A=09LinNumberOfImagePages:=20101=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=20112=20(640x480)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=202560=0A=09= XResolution:=20640=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2050=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=202560=0A=09BnkNumberOfImagePages:=20= 50=0A=09LinNumberOfImagePages:=2050=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20103=20(800x600)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=20800=0A=09= XResolution:=20800=0A=09YResolution:=20600=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=20127=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A= =09GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=20= 0=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=20800=0A=09BnkNumberOfImagePages:=20= 127=0A=09LinNumberOfImagePages:=20127=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20114=20(800x600)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201600=0A=09= XResolution:=20800=0A=09YResolution:=20600=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2063=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=201600=0A=09BnkNumberOfImagePages:=20= 63=0A=09LinNumberOfImagePages:=2063=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=20115=20(800x600)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=203200=0A=09= XResolution:=20800=0A=09YResolution:=20600=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2031=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=203200=0A=09BnkNumberOfImagePages:=20= 31=0A=09LinNumberOfImagePages:=2031=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20105=20(1024x768)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201024=0A=09= XResolution:=201024=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=2084=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=201024=0A=09BnkNumberOfImagePages:=2084=0A=09= LinNumberOfImagePages:=2084=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20117=20(1024x768)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=202048=0A=09= XResolution:=201024=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2041=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=202048=0A=09BnkNumberOfImagePages:=20= 41=0A=09LinNumberOfImagePages:=2041=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=20118=20(1024x768)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=204096=0A=09= XResolution:=201024=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2020=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=204096=0A=09BnkNumberOfImagePages:=20= 20=0A=09LinNumberOfImagePages:=2020=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20179=20(1280x768)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201280=0A=09= XResolution:=201280=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=2067=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=201280=0A=09BnkNumberOfImagePages:=2067=0A=09= LinNumberOfImagePages:=2067=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=2017a=20(1280x768)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=202560=0A=09= XResolution:=201280=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2033=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=202560=0A=09BnkNumberOfImagePages:=20= 33=0A=09LinNumberOfImagePages:=2033=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=2017b=20(1280x768)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=205120=0A=09= XResolution:=201280=0A=09YResolution:=20768=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2016=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=205120=0A=09BnkNumberOfImagePages:=20= 16=0A=09LinNumberOfImagePages:=2016=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20107=20(1280x1024)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201280=0A=09= XResolution:=201280=0A=09YResolution:=201024=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=2050=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=201280=0A=09BnkNumberOfImagePages:=2050=0A=09= LinNumberOfImagePages:=2050=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=2011a=20(1280x1024)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=202560=0A=09= XResolution:=201280=0A=09YResolution:=201024=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2024=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=202560=0A=09BnkNumberOfImagePages:=20= 24=0A=09LinNumberOfImagePages:=2024=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=2011b=20(1280x1024)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=205120=0A=09= XResolution:=201280=0A=09YResolution:=201024=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2011=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=205120=0A=09BnkNumberOfImagePages:=20= 11=0A=09LinNumberOfImagePages:=2011=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20120=20(1600x1200)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201600=0A=09= XResolution:=201600=0A=09YResolution:=201200=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=2033=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=201600=0A=09BnkNumberOfImagePages:=2033=0A=09= LinNumberOfImagePages:=2033=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20122=20(1600x1200)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=203200=0A=09= XResolution:=201600=0A=09YResolution:=201200=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2016=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=203200=0A=09BnkNumberOfImagePages:=20= 16=0A=09LinNumberOfImagePages:=2016=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=20124=20(1600x1200)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=206400=0A=09= XResolution:=201600=0A=09YResolution:=201200=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=207=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A=09= GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=208=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=206400=0A=09BnkNumberOfImagePages:=207=0A=09= LinNumberOfImagePages:=207=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20199=20(1920x1440)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201920=0A=09= XResolution:=201920=0A=09YResolution:=201440=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=2022=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=201920=0A=09BnkNumberOfImagePages:=2022=0A=09= LinNumberOfImagePages:=2022=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=2019a=20(1920x1440)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=203840=0A=09= XResolution:=201920=0A=09YResolution:=201440=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2011=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=203840=0A=09BnkNumberOfImagePages:=20= 11=0A=09LinNumberOfImagePages:=2011=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=2019b=20(1920x1440)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=207680=0A=09= XResolution:=201920=0A=09YResolution:=201440=0A=09XCharSize:=208=0A=09= YCharSize:=2016=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=205=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A=09= GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=208=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200xf4000000=0A=09= LinBytesPerScanLine:=207680=0A=09BnkNumberOfImagePages:=205=0A=09= LinNumberOfImagePages:=205=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=2022e=20(800x480)=0A=09ModeAttributes:=200x9f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=20800=0A=09= XResolution:=20800=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=208=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=204=0A=09BankSize:=200=0A=09= NumberOfImages:=20127=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A= =09GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=20= 0=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=20800=0A=09BnkNumberOfImagePages:=20= 127=0A=09LinNumberOfImagePages:=20127=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=2022f=20(800x480)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=201600=0A=09= XResolution:=20800=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2016=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2063=0A=09RedMaskSize:=205=0A=09RedFieldPosition:=2011=0A= =09GreenMaskSize:=206=0A=09GreenFieldPosition:=205=0A=09BlueMaskSize:=20= 5=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=201600=0A=09BnkNumberOfImagePages:=20= 63=0A=09LinNumberOfImagePages:=2063=0A=09LinRedMaskSize:=205=0A=09= LinRedFieldPosition:=2011=0A=09LinGreenMaskSize:=206=0A=09= LinGreenFieldPosition:=205=0A=09LinBlueMaskSize:=205=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A*Mode:=20230=20(800x480)=0A=09ModeAttributes:=200x9b=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=203200=0A=09= XResolution:=20800=0A=09YResolution:=20480=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=2032=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=206=0A=09BankSize:=200=0A=09= NumberOfImages:=2031=0A=09RedMaskSize:=208=0A=09RedFieldPosition:=2016=0A= =09GreenMaskSize:=208=0A=09GreenFieldPosition:=208=0A=09BlueMaskSize:=20= 8=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0xf4000000=0A=09LinBytesPerScanLine:=203200=0A=09BnkNumberOfImagePages:=20= 31=0A=09LinNumberOfImagePages:=2031=0A=09LinRedMaskSize:=208=0A=09= LinRedFieldPosition:=2016=0A=09LinGreenMaskSize:=208=0A=09= LinGreenFieldPosition:=208=0A=09LinBlueMaskSize:=208=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20108=20(80x60)=0A=09ModeAttributes:=200xf=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=20160=0A=09= XResolution:=2080=0A=09YResolution:=2060=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=201=0A=09BitsPerPixel:=204=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=200=0A=09BankSize:=200=0A=09= NumberOfImages:=20254=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A= =09GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=20= 0=0A=09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09= RsvdFieldPosition:=200=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=20= 0x0=0A=09LinBytesPerScanLine:=20160=0A=09BnkNumberOfImagePages:=20254=0A=09= LinNumberOfImagePages:=20254=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0AMode:=20102=20(800x600)=0A=09ModeAttributes:=200x1f=0A=09= WinAAttributes:=200x7=0A=09WinBAttributes:=200x0=0A=09WinGranularity:=20= 64=0A=09WinSize:=2064=0A=09WinASegment:=200xa000=0A=09WinBSegment:=20= 0xa000=0A=09WinFuncPtr:=200xc00069ee=0A=09BytesPerScanline:=20100=0A=09= XResolution:=20800=0A=09YResolution:=20600=0A=09XCharSize:=208=0A=09= YCharSize:=208=0A=09NumberOfPlanes:=204=0A=09BitsPerPixel:=204=0A=09= NumberOfBanks:=201=0A=09MemoryModel:=203=0A=09BankSize:=200=0A=09= NumberOfImages:=2031=0A=09RedMaskSize:=200=0A=09RedFieldPosition:=200=0A=09= GreenMaskSize:=200=0A=09GreenFieldPosition:=200=0A=09BlueMaskSize:=200=0A= =09BlueFieldPosition:=200=0A=09RsvdMaskSize:=200=0A=09RsvdFieldPosition:=20= 0=0A=09DirectColorModeInfo:=202=0A=09PhysBasePtr:=200x0=0A=09= LinBytesPerScanLine:=20100=0A=09BnkNumberOfImagePages:=2031=0A=09= LinNumberOfImagePages:=2031=0A=09LinRedMaskSize:=200=0A=09= LinRedFieldPosition:=200=0A=09LinGreenMaskSize:=200=0A=09= LinGreenFieldPosition:=200=0A=09LinBlueMaskSize:=200=0A=09= LinBlueFieldPosition:=200=0A=09LinRsvdMaskSize:=200=0A=09= LinRsvdFieldPosition:=200=0A=09MaxPixelClock:=200=0A=0A(II)=20VESA(0):=20= Total=20Memory:=201024=2064KB=20banks=20(65536kB)=0A(II)=20VESA(0):=20= :=20Using=20hsync=20range=20of=2031.00-83.00=20kHz=0A= (II)=20VESA(0):=20:=20Using=20vrefresh=20range=20of=20= 56.00-76.00=20Hz=0A(II)=20VESA(0):=20:=20Using=20= maximum=20pixel=20clock=20of=20140.00=20MHz=0A(WW)=20VESA(0):=20Unable=20= to=20estimate=20virtual=20size=0A(II)=20VESA(0):=20Not=20using=20= built-in=20mode=20"1920x1440"=20(no=20mode=20of=20this=20name)=0A(II)=20= VESA(0):=20Not=20using=20built-in=20mode=20"1600x1200"=20(no=20mode=20of=20= this=20name)=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(II)=20= VESA(0):=20Not=20using=20built-in=20mode=20"1280x768"=20(no=20mode=20of=20= this=20name)=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(II)=20VESA(0):=20Not=20using=20built-in=20mode=20= "800x480"=20(no=20mode=20of=20this=20name)=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(--)=20VESA(0):=20Virtual=20size=20is=201280x1024=20(pitch=20= 1280)=0A(**)=20VESA(0):=20*Built-in=20mode=20"1280x1024"=0A(**)=20= VESA(0):=20*Built-in=20mode=20"1024x768"=0A(**)=20VESA(0):=20*Built-in=20= mode=20"800x600"=0A(**)=20VESA(0):=20*Built-in=20mode=20"640x480"=0A(**)=20= VESA(0):=20Display=20dimensions:=20(380,=20300)=20mm=0A(**)=20VESA(0):=20= DPI=20set=20to=20(85,=2086)=0A(**)=20VESA(0):=20Using=20"Shadow=20= Framebuffer"=0A(II)=20Loading=20sub=20module=20"shadow"=0A(II)=20= LoadModule:=20"shadow"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules//libshadow.so=0A(II)=20Module=20shadow:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.1.0=0A=09ABI=20class:=20X.Org=20ANSI=20C=20Emulation,=20= version=200.4=0A(II)=20Loading=20sub=20module=20"fb"=0A(II)=20= LoadModule:=20"fb"=0A(II)=20Loading=20= /usr/local/lib/xorg/modules//libfb.so=0A(II)=20Module=20fb:=20= vendor=3D"X.Org=20Foundation"=0A=09compiled=20for=201.6.1,=20module=20= version=20=3D=201.0.0=0A=09ABI=20class:=20X.Org=20ANSI=20C=20Emulation,=20= version=200.4=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20Depth=2024=20pixmap=20= format=20is=2032=20bpp=0A(II)=20do=20I=20need=20RAC?=20=20No,=20I=20= don't.=0A(II)=20resource=20ranges=20after=20preInit:=0A=09[0]=20-1=090=09= 0x000f0000=20-=200x000fffff=20(0x10000)=20MX[B]=0A=09[1]=20-1=090=09= 0x000c0000=20-=200x000effff=20(0x30000)=20MX[B]=0A=09[2]=20-1=090=09= 0x00000000=20-=200x0009ffff=20(0xa0000)=20MX[B]=0A=09[3]=20-1=090=09= 0x0000ffff=20-=200x0000ffff=20(0x1)=20IX[B]=0A=09[4]=20-1=090=09= 0x00000000=20-=200x000000ff=20(0x100)=20IX[B]=0A(II)=20Loading=20sub=20= module=20"int10"=0A(II)=20LoadModule:=20"int10"=0A(II)=20Reloading=20= /usr/local/lib/xorg/modules//libint10.so=0A(II)=20VESA(0):=20= initializing=20int10=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0xa0000,0x20000)=20was=20already=20clear=0A(II)=20VESA(0):=20Primary=20= V_BIOS=20segment=20is:=200xc000=0A(=3D=3D)=20VESA(0):=20Write-combining=20= range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(II)=20VESA(0):=20VESA=20BIOS=20detected=0A(II)=20VESA(0):=20= VESA=20VBE=20Version=203.0=0A(II)=20VESA(0):=20VESA=20VBE=20Total=20Mem:=20= 65536=20kB=0A(II)=20VESA(0):=20VESA=20VBE=20OEM:=20VIA=20P4M800=20PRO=0D=0A= =0A(II)=20VESA(0):=20VESA=20VBE=20OEM=20Software=20Rev:=201.0=0A(II)=20= VESA(0):=20VESA=20VBE=20OEM=20Vendor:=20=0A(II)=20VESA(0):=20VESA=20VBE=20= OEM=20Product:=20=0A(II)=20VESA(0):=20VESA=20VBE=20OEM=20Product=20Rev:=20= =0A(II)=20VESA(0):=20virtual=20address=20=3D=200x28c00000,=0A=09physical=20= address=20=3D=200xf4000000,=20size=20=3D=2067108864=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(II)=20VESA(0):=20Setting=20up=20VESA=20Mode=20= 0x11B=20(1280x1024)=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(II)=20= VESA(0):=20VBESetVBEMode=20failed(=3D=3D)=20VESA(0):=20Write-combining=20= range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A= ...Tried=20again=20without=20customized=20values.=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Default=20visual=20is=20TrueColor=0A(=3D=3D)= =20VESA(0):=20Backing=20store=20disabled=0A(II)=20VESA(0):=20DPMS=20= enabled=0A(=3D=3D)=20RandR=20enabled=0A(II)=20Initializing=20built-in=20= extension=20Generic=20Event=20Extension=0A(II)=20Initializing=20built-in=20= extension=20SHAPE=0A(II)=20Initializing=20built-in=20extension=20MIT-SHM=0A= (II)=20Initializing=20built-in=20extension=20XInputExtension=0A(II)=20= Initializing=20built-in=20extension=20XTEST=0A(II)=20Initializing=20= built-in=20extension=20BIG-REQUESTS=0A(II)=20Initializing=20built-in=20= extension=20SYNC=0A(II)=20Initializing=20built-in=20extension=20= XKEYBOARD=0A(II)=20Initializing=20built-in=20extension=20XC-MISC=0A(II)=20= Initializing=20built-in=20extension=20XINERAMA=0A(II)=20Initializing=20= built-in=20extension=20XFIXES=0A(II)=20Initializing=20built-in=20= extension=20RENDER=0A(II)=20Initializing=20built-in=20extension=20RANDR=0A= (II)=20Initializing=20built-in=20extension=20COMPOSITE=0A(II)=20= Initializing=20built-in=20extension=20DAMAGE=0A(II)=20AIGLX:=20Loaded=20= and=20initialized=20/usr/local/lib/dri/swrast_dri.so=0A(II)=20GLX:=20= Initialized=20DRISWRAST=20GL=20provider=20for=20screen=200=0A(=3D=3D)=20= VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20was=20already=20= clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20(0x0,0x1000)=20= was=20already=20clear=0A(=3D=3D)=20VESA(0):=20Write-combining=20range=20= (0x0,0x1000)=20was=20already=20clear=0A(=3D=3D)=20VESA(0):=20= Write-combining=20range=20(0x0,0x1000)=20was=20already=20clear=0A= --Apple-Mail-19-50987061-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 16:45:09 2009 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 30DBF106566B; Wed, 10 Jun 2009 16:45:09 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by mx1.freebsd.org (Postfix) with ESMTP id 071998FC13; Wed, 10 Jun 2009 16:45:08 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090610164508.BPNI17135.fed1rmmtao104.cox.net@fed1rmimpo02.cox.net>; Wed, 10 Jun 2009 12:45:08 -0400 Received: from vaio ([98.176.33.70]) by fed1rmimpo02.cox.net with bizsmtp id 2Gl81c0071WnGw204Gl8ol; Wed, 10 Jun 2009 12:45:08 -0400 X-VR-Score: -80.00 X-Authority-Analysis: v=1.0 c=1 a=5F8ODknaBjMA:10 a=6I5d2MoRAAAA:8 a=GDr_Of5erPDDIF-kg2wA:9 a=76jvYwkvTyHEaCv-gtQA:7 a=TGnxo_hZoGqPpaFRziD_96pIF2AA:4 a=SV7veod9ZcQA:10 X-CM-Score: 0.00 Date: Wed, 10 Jun 2009 09:45:03 -0700 From: Robert To: John Baldwin Message-ID: <20090610094503.104ffbb7@vaio> In-Reply-To: <200906101038.37028.jhb@freebsd.org> References: <20090606071431.092609ce@vaio> <200906081045.39497.jhb@freebsd.org> <20090610061913.04a97b6c@vaio> <200906101038.37028.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 16:45:09 -0000 On Wed, 10 Jun 2009 10:38:36 -0400 John Baldwin wrote: > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > On Mon, 8 Jun 2009 10:45:39 -0400 > > John Baldwin wrote: > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > Greetings > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > going into multiuser. I would prefer to be on stable. > > > > Here is dmesg.boot. I hope that is what you wanted. > > Hmm, can you get the stack trace from the dump that you have? I'm > curious which device driver is triggering the panic. > (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e4b47 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, callbacks=0xd528a9e4, argp=0xc2a65000) at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 #9 0xc0affad2 in VOP_OPEN_APV (vop=0xc0c4f840, a=0xd528aa88) at vnode_if.c:371 #10 0xc0873329 in vn_open_cred (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, cred=0xc2ab3d00, fp=0xc2a4be40) at vnode_if.h:199 #11 0xc0873473 in vn_open (ndp=0xd528ab7c, flagp=0xd528ac78, cmode=1, fp=0xc2a4be40) at /usr/src/sys/kern/vfs_vnops.c:94 #12 0xc0870b7d in kern_open (td=0xc2a91d80, path=0xbfbfef32
, pathseg=UIO_USERSPACE, flags=1, mode=1) at /usr/src/sys/kern/vfs_syscalls.c:1042 #13 0xc08710f0 in open (td=0xc2a91d80, uap=0xd528acfc) at /usr/src/sys/kern/vfs_syscalls.c:1009 #14 0xc0ae9405 in syscall (frame=0xd528ad38) at /usr/src/sys/i386/i386/trap.c:1090 #15 0xc0ace1e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Thanks again Robert From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:03:29 2009 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 91E0F106566B for ; Wed, 10 Jun 2009 17:03:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 044EC8FC12 for ; Wed, 10 Jun 2009 17:03:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 3030 invoked from network); 10 Jun 2009 16:53:15 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jun 2009 16:53:15 -0000 Message-ID: <4A2FE765.9000803@freebsd.org> Date: Wed, 10 Jun 2009 19:03:33 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Scott Long References: <4A2FA4EF.5060603@freebsd.org> <4A2FC858.5050800@samsco.org> In-Reply-To: <4A2FC858.5050800@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 10 Jun 2009 17:03:29 -0000 Scott Long wrote: > Andre Oppermann wrote: >> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >> a big >> nasty surprise with the Areca RAID controller: >> >> arcmsr0: > > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >> arcmsr0: [ITHREAD] >> ... >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >> >> From here on it hangs and repeats the last message with some sort of >> exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock >> does. Hard reset is required to reboot. >> >> Booting the old 6.4 kernel works and the system comes up again with full >> access to the RAID array. >> >> Any help appreciated. >> > > I'll try to reproduce this locally. There have been sporadic reports of > the "fails comparison" problem, but none as fatal as this. Is it > possible to compile your kernel with CAMDEBUG and > CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? CAMDEBUG doesn't give any output. As it turns out the hang seems to be related to an interrupt routing problem somehow. I did an BIOS upgrade and BIOS settings factory reset. The mainboard is an ASUS M2N32 WS Professional with an Athlon64 X2 4800+. Enabling all on-board devices including ATA and various SATA controllers together with "PnP OS" set to yes fixed the hand and allowed FreeBSD 7 to boot sucessfully. Why 6.4 doesn't stumble I don't know. The "(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step" line is still there. Fortunately the boot process simply continues from there without further trouble. If there are any other CAM debug options or patches you want me to try I can do that. The system is only in partial production and I'm allowed to reboot it during workhours. -- Andre From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:09:06 2009 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 9E477106564A for ; Wed, 10 Jun 2009 17:09:06 +0000 (UTC) (envelope-from prvs=40585e3a7=pschmehl_lists@tx.rr.com) Received: from ip-relay-001.utdallas.edu (ip-relay-001.utdallas.edu [129.110.20.111]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6BF8FC15 for ; Wed, 10 Jun 2009 17:09:01 +0000 (UTC) (envelope-from prvs=40585e3a7=pschmehl_lists@tx.rr.com) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.41,342,1241413200"; d="scan'208";a="13243280" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-001.utdallas.edu with ESMTP; 10 Jun 2009 11:58:41 -0500 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id C89CF4EF37; Wed, 10 Jun 2009 11:58:21 -0500 (CDT) Date: Wed, 10 Jun 2009 16:58:21 +0000 From: Paul Schmehl To: Ben Stuyts , stable@freebsd.org Message-ID: In-Reply-To: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> References: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> X-Mailer: Mulberry/4.0.6 (Linux/x86) X-Munged-Reply-To: Figure it out MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: Xorg keyboard and mouse hung X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Schmehl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 17:09:06 -0000 --On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts wrote: > > Hi, > > I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ > world of today, and now the mouse and keyboard don't react anymore in > the Xorg / KDE login window. Mouse doesn't move, keyboard characters > don't appear in the login prompt. I can still switch back with ctl-alt- > F1 to a console login, and there both the keyboard and mouse still work. > > I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf > as the default settings used to work fine. > > Any ideas? > Sure. In your Xorg.0.log file: "(==) ModulePath set to "/usr/local/lib/xorg/modules" (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput" add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then start them both manually (/usr/local/etc/rc.d/hald start and /usr/local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. ******************************************* Check the headers before clicking on Reply. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:09:14 2009 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 9FA1A10656A6; Wed, 10 Jun 2009 17:09:14 +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 70CAD8FC1B; Wed, 10 Jun 2009 17:09:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 14F7546B2A; Wed, 10 Jun 2009 13:09:14 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C184C8A06C; Wed, 10 Jun 2009 13:09:12 -0400 (EDT) From: John Baldwin To: Robert Date: Wed, 10 Jun 2009 13:07:36 -0400 User-Agent: KMail/1.9.7 References: <20090606071431.092609ce@vaio> <200906101038.37028.jhb@freebsd.org> <20090610094503.104ffbb7@vaio> In-Reply-To: <20090610094503.104ffbb7@vaio> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101307.37181.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 13:09:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Warner Losh , freebsd-stable@freebsd.org Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 17:09:15 -0000 On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > On Wed, 10 Jun 2009 10:38:36 -0400 > John Baldwin wrote: > > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > > > On Mon, 8 Jun 2009 10:45:39 -0400 > > > John Baldwin wrote: > > > > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > > > > > Greetings > > > > > > > > > > This problem seems the same as this one from May of this year > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > > > > > > > > > > > > > > > I have installed 7.2 on the laptop because it would panic whenever > > > going into multiuser. I would prefer to be on stable. > > > > > > Here is dmesg.boot. I hope that is what you wanted. > > > > Hmm, can you get the stack trace from the dump that you have? I'm > > curious which device driver is triggering the panic. > > > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07e4b47 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > (fmt=Variable "fmt" is not available. ) > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > callbacks=0xd528a9e4, argp=0xc2a65000) > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 Hmmm, ok. So the problem appears to be that the cardbus code that parses the CIS wants to allocate a resource belonging to a cardbus card device that has already been allocated by that device's driver. Warner, what is the best way to handle this do you think? Does the bus_alloc_resource() method for a cardbus bus need to proxy resource requests to the CIS resource perhaps? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:16:33 2009 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 EA306106568B; Wed, 10 Jun 2009 17:16:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6838FC30; Wed, 10 Jun 2009 17:16:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n5AHEuJM066050; Wed, 10 Jun 2009 11:14:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 10 Jun 2009 11:15:16 -0600 (MDT) Message-Id: <20090610.111516.1756928424.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200906101307.37181.jhb@freebsd.org> References: <200906101038.37028.jhb@freebsd.org> <20090610094503.104ffbb7@vaio> <200906101307.37181.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, traveling08@cox.net Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 17:16:34 -0000 In message: <200906101307.37181.jhb@freebsd.org> John Baldwin writes: : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: : > On Wed, 10 Jun 2009 10:38:36 -0400 : > John Baldwin wrote: : > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: : > > > On Mon, 8 Jun 2009 10:45:39 -0400 : > > > John Baldwin wrote: : > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: : > > > > > Greetings : > > > > > : > > > > > This problem seems the same as this one from May of this year : > > > > > : > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html : > > > > > : > : > : > : > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever : > > > going into multiuser. I would prefer to be on stable. : > > > : > > > Here is dmesg.boot. I hope that is what you wanted. : > > : > > Hmm, can you get the stack trace from the dump that you have? I'm : > > curious which device driver is triggering the panic. : > > : > : > (kgdb) bt : > #0 doadump () at pcpu.h:196 : > #1 0xc07e4b47 in boot (howto=260) : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic : > (fmt=Variable "fmt" is not available. ) : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, : > callbacks=0xd528a9e4, argp=0xc2a65000) : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 : : Hmmm, ok. So the problem appears to be that the cardbus code that parses the : CIS wants to allocate a resource belonging to a cardbus card device that has : already been allocated by that device's driver. Warner, what is the best way : to handle this do you think? Does the bus_alloc_resource() method for a : cardbus bus need to proxy resource requests to the CIS resource perhaps? I thought I already fixed this. We snag the cardbus CIS now on attach rather than at open time. We just need to MFC it. The problem isn't that we're allocating a resource that the device owns, so much, as that there are technical hurdles to accessing the CIS after the initial parsing.... Warner From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:24:32 2009 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 45AB1106566C for ; Wed, 10 Jun 2009 17:24:32 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id C76798FC0C for ; Wed, 10 Jun 2009 17:24:31 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from giskard.altus-escon.com (giskard.altus-escon.com [193.78.231.1]) by altus-escon.com (8.14.3/8.14.3) with ESMTP id n5AHONDR074500; Wed, 10 Jun 2009 19:24:28 +0200 (CEST) (envelope-from ben@altesco.nl) Message-Id: <56C52C1B-1CC1-407B-BB51-4EF1EF75F484@altesco.nl> From: Ben Stuyts To: Paul Schmehl In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 19:24:22 +0200 References: <660A86EE-A365-42C3-A1DF-15AC7B03C813@altesco.nl> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [193.78.231.142]); Wed, 10 Jun 2009 19:24:29 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9450/Wed Jun 10 15:41:08 2009 on mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: stable@freebsd.org Subject: Re: Xorg keyboard and mouse hung 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, 10 Jun 2009 17:24:32 -0000 On 10 jun 2009, at 18:58, Paul Schmehl wrote: > --On Wednesday, June 10, 2009 10:02:39 -0500 Ben Stuyts > wrote: > >> I've upgrade two FreeBSD 7-stable workstations to the latest kernel/ >> world of today, and now the mouse and keyboard don't react anymore in >> the Xorg / KDE login window. Mouse doesn't move, keyboard characters >> don't appear in the login prompt. I can still switch back with ctl- >> alt- >> F1 to a console login, and there both the keyboard and mouse still >> work. >> >> I have attached dmesg.boot and Xorg.0.log. I'm not using a xorg.conf >> as the default settings used to work fine. >> >> Any ideas? > > Sure. In your Xorg.0.log file: > > "(==) ModulePath set to "/usr/local/lib/xorg/modules" > (II) Cannot locate a core pointer device. > (II) Cannot locate a core keyboard device. > (II) The server relies on HAL to provide the list of input devices. > If no devices become available, reconfigure HAL or disable > AllowEmptyInput" > > add dbus_enable="YES" and hald_enable="YES" to /etc/rc.conf. Then > start them both manually (/usr/local/etc/rc.d/hald start and /usr/ > local/etc/rc.d/dbus start). Then restart X (Ctrl-Alt-Bkspc) I missed that somehow in UPDATING. Thanks! Kind regards, Ben From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 17:45:15 2009 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 30E9710656A5 for ; Wed, 10 Jun 2009 17:45:15 +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 E12E38FC22 for ; Wed, 10 Jun 2009 17:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6E24046B35; Wed, 10 Jun 2009 13:45:14 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 57EFE8A06E; Wed, 10 Jun 2009 13:45:13 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Date: Wed, 10 Jun 2009 13:44:04 -0400 User-Agent: KMail/1.9.7 References: <200906101038.37028.jhb@freebsd.org> <200906101307.37181.jhb@freebsd.org> <20090610.111516.1756928424.imp@bsdimp.com> In-Reply-To: <20090610.111516.1756928424.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101344.04754.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 13:45:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org, traveling08@cox.net Subject: Re: Panic resource_list_alloc 7.2 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: Wed, 10 Jun 2009 17:45:15 -0000 On Wednesday 10 June 2009 1:15:16 pm M. Warner Losh wrote: > In message: <200906101307.37181.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 10 June 2009 12:45:03 pm Robert wrote: > : > On Wed, 10 Jun 2009 10:38:36 -0400 > : > John Baldwin wrote: > : > > : > > On Wednesday 10 June 2009 9:19:13 am Robert wrote: > : > > > On Mon, 8 Jun 2009 10:45:39 -0400 > : > > > John Baldwin wrote: > : > > > > : > > > > On Saturday 06 June 2009 10:14:31 am Robert wrote: > : > > > > > Greetings > : > > > > > > : > > > > > This problem seems the same as this one from May of this year > : > > > > > > : > > > > > > : http://lists.freebsd.org/pipermail/freebsd-stable/2009-May/050088.html > : > > > > > > : > > : > > : > > : > > > > > : > > > I have installed 7.2 on the laptop because it would panic whenever > : > > > going into multiuser. I would prefer to be on stable. > : > > > > : > > > Here is dmesg.boot. I hope that is what you wanted. > : > > > : > > Hmm, can you get the stack trace from the dump that you have? I'm > : > > curious which device driver is triggering the panic. > : > > > : > > : > (kgdb) bt > : > #0 doadump () at pcpu.h:196 > : > #1 0xc07e4b47 in boot (howto=260) > : > at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e4e19 in panic > : > (fmt=Variable "fmt" is not available. ) > : > at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc080d6f6 in > : > resource_list_alloc (rl=0xc2630904, bus=0xc25bed80, child=0xc2494180, > : > type=3, rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/kern/subr_bus.c:2739 #4 0xc06a2057 in > : > pci_alloc_resource (dev=0xc25bed80, child=0xc2494180, type=3, > : > rid=0xd528a5b8, start=0, end=4294967295, count=1, flags=12290) > : > at /usr/src/sys/dev/pci/pci.c:3586 #5 0xc080d57c in bus_alloc_resource > : > (dev=0xc2494180, type=3, rid=0xd528a5b8, start=0, end=4294967295, > : > count=1, flags=12290) at bus_if.h:263 #6 0xc058ef4c in > : > cardbus_parse_cis (cbdev=0xc25bed80, child=0xc2494180, > : > callbacks=0xd528a9e4, argp=0xc2a65000) > : > at /usr/src/sys/dev/cardbus/cardbus_cis.c:481 #7 0xc058f91c in > : > cardbus_open (dev=0xc25ab400, oflags=1, devtype=8192, td=0xc2a91d80) > : > at /usr/src/sys/dev/cardbus/cardbus_device.c:140 #8 0xc076f26a in > : > devfs_open (ap=0xd528aa88) at /usr/src/sys/fs/devfs/devfs_vnops.c:903 > : > : Hmmm, ok. So the problem appears to be that the cardbus code that parses the > : CIS wants to allocate a resource belonging to a cardbus card device that has > : already been allocated by that device's driver. Warner, what is the best way > : to handle this do you think? Does the bus_alloc_resource() method for a > : cardbus bus need to proxy resource requests to the CIS resource perhaps? > > I thought I already fixed this. We snag the cardbus CIS now on attach > rather than at open time. We just need to MFC it. Oh, ok, that would make sense. Is it easy to merge to 7? > The problem isn't that we're allocating a resource that the device > owns, so much, as that there are technical hurdles to accessing the > CIS after the initial parsing.... *nod* -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 18:14:42 2009 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 B82DE106566B for ; Wed, 10 Jun 2009 18:14:42 +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 8B07D8FC18 for ; Wed, 10 Jun 2009 18:14:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1E32B46B17; Wed, 10 Jun 2009 14:14:42 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AE4068A06E; Wed, 10 Jun 2009 14:14:40 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 10 Jun 2009 14:12:35 -0400 User-Agent: KMail/1.9.7 References: <20090610115351.V56412@hub.org> In-Reply-To: <20090610115351.V56412@hub.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101412.35353.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 14:14:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "Marc G. Fournier" Subject: Re: Server lock up: kern.maxswzone relate ... 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, 10 Jun 2009 18:14:43 -0000 On Wednesday 10 June 2009 11:04:48 am Marc G. Fournier wrote: > > I'm running a couple of brand new servers ... 32G of RAM, very little load > on it right now, and this morning it locked up with that 'kern.maxswzone' > error on the console ... > > The server is running a reasonably current 7.2-STABLE: > > FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 > 14:48:04 ADT > > And top right now, with everything running, shows no swappping, 19G of > Free memory, 9G of Inact memory ... no reason to do any serious amount of > swapping. > > last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 11:53:39 > 573 processes: 1 running, 571 sleeping, 1 zombie > CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle > Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free > Swap: 32G Total, 32G Free > > In fact, my other server (same config), has been up 9 days (they were put > online 9 days ago), and tops shows it doing a little bit of swapping, but, > again, huge amounts of Inact memory: > > last pid: 26307; load averages: 0.36, 0.35, 0.36 up 9+17:03:48 > 11:57:54 > 680 processes: 2 running, 657 sleeping, 21 zombie > CPU: 0.7% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.9% idle > Mem: 2915M Active, 25G Inact, 778M Wired, 13M Cache, 399M Buf, 1771M Free > Swap: 32G Total, 1044K Used, 32G Free > > So these servers right now are definitely not feeling any pain ... > > And, based on experiences with another server, I have my /boot/loader.conf > set to: > > kern.maxswzone=67108864 > > So, the question is ... what am I missing? Is there some magical formula > for calculating maxswzone that 7.2 is missing? Some nagios plug-in I > shuld be using to monitor ... what? > > Help? There are changes in 8 that you can ask kib@ to MFC perhaps that help some. They make the kernel kill a process when maxswzone is empty similar to what happens when you run out of swap space. If you break into the debugger and get a crashdump, you can verify 1) that you were swapping, and 2) you can calculate a better value for maxswzone. The problem with making maxswzone really big is that it uses up wired memory that can't be reused for anything else, so you don't just want to blindly use the maximum amount for the swap you have. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 20:23:29 2009 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 C05DA106564A for ; Wed, 10 Jun 2009 20:23:29 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 458048FC1A for ; Wed, 10 Jun 2009 20:23:29 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n5AKNRiU024642; Thu, 11 Jun 2009 00:23:27 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 11 Jun 2009 00:23:27 +0400 (MSD) From: Dmitry Morozovsky To: "Marc G. Fournier" In-Reply-To: <20090610115351.V56412@hub.org> Message-ID: References: <20090610115351.V56412@hub.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Thu, 11 Jun 2009 00:23:27 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: Server lock up: kern.maxswzone relate ... 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, 10 Jun 2009 20:23:30 -0000 On Wed, 10 Jun 2009, Marc G. Fournier wrote: MGF> MGF> I'm running a couple of brand new servers ... 32G of RAM, very little load MGF> on it right now, and this morning it locked up with that 'kern.maxswzone' MGF> error on the console ... MGF> MGF> The server is running a reasonably current 7.2-STABLE: MGF> MGF> FreeBSD pluto.hub.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 31 14:48:04 MGF> ADT MGF> MGF> And top right now, with everything running, shows no swappping, 19G of Free MGF> memory, 9G of Inact memory ... no reason to do any serious amount of MGF> swapping. MGF> MGF> last pid: 32159; load averages: 0.12, 0.21, 0.47 up 0+10:57:56 MGF> 11:53:39 MGF> 573 processes: 1 running, 571 sleeping, 1 zombie MGF> CPU: 2.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 96.8% idle MGF> Mem: 1331M Active, 9446M Inact, 659M Wired, 35M Cache, 399M Buf, 19G Free MGF> Swap: 32G Total, 32G Free As a workaround, if your machine is usually not going to swap, you can decrease swap space significally, and use otherwise unused partition for crashdumps. For RELENG_7/amd64 with 8G RAM and 16G of swap, on stress tests with tmpfs to avoid such locks I had to tune kern.maxswzone up to 192M, which seems to be kinda overkill... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 02:56:41 2009 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 421461065672 for ; Thu, 11 Jun 2009 02:56:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id DA1558FC17; Thu, 11 Jun 2009 02:56:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk3 with SMTP id 3so1741565gxk.19 for ; Wed, 10 Jun 2009 19:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fHoZS5S66sjny+q9T7cGeU71COsJYoDzMqMAim/+LfQ=; b=lqeWqcj3JbX1U0+2UIS4Nk+BTxyUx5n0ap6iiQ6WIiga+UORXL1YrfblVH8E/TWeRT wYPFB0I1vftJ2IWUM0F/K+PRaI1iU/NaYDznjjW0OJTwr63XUZmWWm7jjRqUrHLlj/w6 OzGg9gluN/p4jyABNXoZnHKoNkt750Kqx/PYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qz7ZZbtV6nVklSnBUZcwgAGfUCoA3OEthKRr8D8oJbLBL+eq9IdNWGUoO9Z7pJp2+n 0qJCBnjUgMAQ3ljbpftEw701bYrwch8pIL+3v/+O/JUOEZDQHsMTwtFsuteV3OV4snKu KZMtYA71ze43ONpBXU36Dy/CXVtjkJR3MTphY= MIME-Version: 1.0 Received: by 10.151.132.4 with SMTP id j4mr4070790ybn.120.1244688618242; Wed, 10 Jun 2009 19:50:18 -0700 (PDT) In-Reply-To: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> Date: Wed, 10 Jun 2009 19:50:18 -0700 Message-ID: <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> From: Garrett Cooper To: pjd@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ata@freebsd.org, FreeBSD-STABLE Mailing List Subject: Re: Issues with gjournal (heaaaaaaaaaaalp!) 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, 11 Jun 2009 02:56:41 -0000 On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote: > Hi Pawel, ATA, and Stable folks, > > =A0 =A0This time when I did a reinstall I took the bullet and tried to > use gjournaling instead of softupdates. The unfortunate thing is that > I can't seem to get it to work. > > Here's the procedure that I'm trying to follow (based off of [1]): > - sysinstall from scratch with a minimal distribution. This creates > /usr // /dev/ad6s1d as UFS2 with softupdates disabled. > - Pull latest stable sources. Rebuild kernel (with `options > GEOM_JOURNAL'), world, install kernel, then world after reboot. > - gjournal label -f ad6s1d ad6s2d > - mount /dev/ad6s1d /usr # That works (I think...), but prints out the > error message below: > > GEOM_JOURNAL: [flush] Error while writing data (error=3D1) > ad6s2d[WRITE(offset=3D512, length=3D6656)] > > gjournal status says: > =A0 =A0 =A0 =A0 =A0 =A0Name =A0 Status =A0 Components > ad6s1d.journal =A0 =A0 =A0 N/A =A0 ad6s1d > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a= d6s2d > > Some issues I noticed: > > - GJOURNAL ROOT (something) loops infinitely if the device can't be > found; this should probably time out and panic / exit if a device > becomes unavailable (depends on fstab values in the final 2 fields no > doubt). I did this by accident when I forgot to add iir statically to > the kernel. > - The LiveCD doesn't fully support gjournal (userland's there, kernel > support isn't). Kind of annoying and counterproductive... > - Existing journal partitions disappeared when I upgraded by accident > from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from > my server with label=3D.). That was weird... > - When I use gjournal label with an existing filesystem I _must_ use -f. > > Any help with this endeavor would be more than appreciated, as I want > to enable this functionality before I move on to installing X11, as > nvidia-driver frequently hardlocks the desktop (or has in the past). > > Thanks, > -Garrett > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/= article.html And to answer another potential question, I've tried mounting both with -o rw,async and with -o rw. Thanks! -Garrett From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 03:04:55 2009 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 E1FF11065673 for ; Thu, 11 Jun 2009 03:04:55 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com [209.85.210.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDC98FC0A; Thu, 11 Jun 2009 03:04:55 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yxe38 with SMTP id 38so341459yxe.3 for ; Wed, 10 Jun 2009 20:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6qCcWim6DYrLh0aln6U8WfzhSK65kMXcSOSpxKXWwJA=; b=EFnnmCkLbrgWIMeR2/7tnwDVm6jLFnu0e1dPaIH9nMX/fy673iZkwB76iyt5iUE3g0 2aFoK04KlyNa+Se4yzy7/Iutt2brggLGyEtLKqEF9jgfvoqBtGGpuFSpUB7eAJzhrAkp GMfYlOal/2yalcYDuf1W6xPraG8mYvUaKYaEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hX6vNULC/doGvbrjIhn2Lpu5xLv3bBe/zC4cC4RrsCkaEoG8DareaLVjxf5EsbiVqm 8yAgGcVHoZk4r0GCTHG+ernLHrLdCQebW8YdUuh3irE91+XLrG/UE6BaXo0aKC/YOPuT cbl5IbOxgs3JKBMjiVKB/wT798UQpQcUGmUsk= MIME-Version: 1.0 Received: by 10.151.132.7 with SMTP id j7mr4041051ybn.192.1244688267556; Wed, 10 Jun 2009 19:44:27 -0700 (PDT) Date: Wed, 10 Jun 2009 19:44:27 -0700 Message-ID: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> From: Garrett Cooper To: pjd@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ata@freebsd.org, FreeBSD-STABLE Mailing List Subject: Issues with gjournal (heaaaaaaaaaaalp!) 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, 11 Jun 2009 03:04:56 -0000 Hi Pawel, ATA, and Stable folks, This time when I did a reinstall I took the bullet and tried to use gjournaling instead of softupdates. The unfortunate thing is that I can't seem to get it to work. Here's the procedure that I'm trying to follow (based off of [1]): - sysinstall from scratch with a minimal distribution. This creates /usr // /dev/ad6s1d as UFS2 with softupdates disabled. - Pull latest stable sources. Rebuild kernel (with `options GEOM_JOURNAL'), world, install kernel, then world after reboot. - gjournal label -f ad6s1d ad6s2d - mount /dev/ad6s1d /usr # That works (I think...), but prints out the error message below: GEOM_JOURNAL: [flush] Error while writing data (error=1) ad6s2d[WRITE(offset=512, length=6656)] gjournal status says: Name Status Components ad6s1d.journal N/A ad6s1d ad6s2d Some issues I noticed: - GJOURNAL ROOT (something) loops infinitely if the device can't be found; this should probably time out and panic / exit if a device becomes unavailable (depends on fstab values in the final 2 fields no doubt). I did this by accident when I forgot to add iir statically to the kernel. - The LiveCD doesn't fully support gjournal (userland's there, kernel support isn't). Kind of annoying and counterproductive... - Existing journal partitions disappeared when I upgraded by accident from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from my server with label=.). That was weird... - When I use gjournal label with an existing filesystem I _must_ use -f. Any help with this endeavor would be more than appreciated, as I want to enable this functionality before I move on to installing X11, as nvidia-driver frequently hardlocks the desktop (or has in the past). Thanks, -Garrett [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop/article.html From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 05:58:41 2009 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 20CA6106564A; Thu, 11 Jun 2009 05:58:41 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id A08D08FC18; Thu, 11 Jun 2009 05:58:40 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so716971ana.13 for ; Wed, 10 Jun 2009 22:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NpTGFlRz9GO5+2gGMpg1jShsyc49/lc6RFU3ivP1dYw=; b=sw28NGIGqVrxhjet4A7yZFdk7zOFQ6/ePJRfGmM1aYyXQZeCRE2mvBowfcYIaovAcC hgS39InNBwf88ZP9EfmIY5PLJQkIq5gj0lKc/eGmtwZi5/ferPgox7altq3wDcv0PH4C y59pIbCb4XvNrgoy18qhgTcZEPC4ndb2knNpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L/zrBTPvgPUynknFxziTaBgiUc9LfhnzlaBvYvzeE520mNKMimYm/ed6y7POy4Ujc0 pj43ebrrReRu9QihmrnCKirKkWTCUOcgBE67I/IB6ql5mBgHaxptLpruwPsw18GNtzkm JRwkUtcmLpwuDLtXsH2J2zTl/AQ3IvNytqgmQ= MIME-Version: 1.0 Received: by 10.100.8.4 with SMTP id 4mr2273068anh.146.1244699919866; Wed, 10 Jun 2009 22:58:39 -0700 (PDT) In-Reply-To: <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> Date: Thu, 11 Jun 2009 08:58:39 +0300 Message-ID: From: Dan Naumov To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , ata@freebsd.org, pjd@freebsd.org Subject: Re: Issues with gjournal (heaaaaaaaaaaalp!) 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, 11 Jun 2009 05:58:41 -0000 You need to mount your /dev/ad6s1d.journal as /usr and not /dev/ad6s1d, because this is the new device provided to you by GEOM. - Dan Naumov On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote: > On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrote= : >> Hi Pawel, ATA, and Stable folks, >> >> =A0 =A0This time when I did a reinstall I took the bullet and tried to >> use gjournaling instead of softupdates. The unfortunate thing is that >> I can't seem to get it to work. >> >> Here's the procedure that I'm trying to follow (based off of [1]): >> - sysinstall from scratch with a minimal distribution. This creates >> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >> - Pull latest stable sources. Rebuild kernel (with `options >> GEOM_JOURNAL'), world, install kernel, then world after reboot. >> - gjournal label -f ad6s1d ad6s2d >> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >> error message below: >> >> GEOM_JOURNAL: [flush] Error while writing data (error=3D1) >> ad6s2d[WRITE(offset=3D512, length=3D6656)] >> >> gjournal status says: >> =A0 =A0 =A0 =A0 =A0 =A0Name =A0 Status =A0 Components >> ad6s1d.journal =A0 =A0 =A0 N/A =A0 ad6s1d >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = ad6s2d >> >> Some issues I noticed: >> >> - GJOURNAL ROOT (something) loops infinitely if the device can't be >> found; this should probably time out and panic / exit if a device >> becomes unavailable (depends on fstab values in the final 2 fields no >> doubt). I did this by accident when I forgot to add iir statically to >> the kernel. >> - The LiveCD doesn't fully support gjournal (userland's there, kernel >> support isn't). Kind of annoying and counterproductive... >> - Existing journal partitions disappeared when I upgraded by accident >> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >> my server with label=3D.). That was weird... >> - When I use gjournal label with an existing filesystem I _must_ use -f. >> >> Any help with this endeavor would be more than appreciated, as I want >> to enable this functionality before I move on to installing X11, as >> nvidia-driver frequently hardlocks the desktop (or has in the past). >> >> Thanks, >> -Garrett >> >> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop= /article.html > > And to answer another potential question, I've tried mounting both > with -o rw,async and with -o rw. > Thanks! > -Garrett > _______________________________________________ > 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 Jun 11 06:24:51 2009 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 DDDF2106566C; Thu, 11 Jun 2009 06:24:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 68AE28FC23; Thu, 11 Jun 2009 06:24:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so731002ywe.13 for ; Wed, 10 Jun 2009 23:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zeAIHuyJO75NmTQdmb0Wh13XbdAQtLY7Zo/1FQcMKtA=; b=SQ+AbTplf+9Rn/XUuFyBtD4ElmkeFbryLM8CVM7IUD9gW8+/aF1oMSdv0D4ajcXMgT HdipY0q5hXjeIjSrEoGb6NoM3hYVkqEdQaG9oLuRPgGI7Aoz5jP0wIxHun0AjkV3yWE0 mFhEFeBFTeyZINcRA/vLBLLnCmrSNrGYm+BXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ec0GQy/bvzkzvjspD10pUfDYKH0vy7ZVPtLym960beeefgLQYazI7z66NtraSVddt8 g9RVOsh9hWMRkXd54FLdODkpEyTNlHCOq9111ERLzUcYgHd7/HWc7fnUAnx0x9zKk1i+ EtKSREVgGyv4+PfAs9tABL3wsnXujJAWHoe+E= MIME-Version: 1.0 Received: by 10.150.229.7 with SMTP id b7mr4376168ybh.255.1244701489699; Wed, 10 Jun 2009 23:24:49 -0700 (PDT) In-Reply-To: References: <7d6fde3d0906101944t7a04ff7ejdd415938d3e1483c@mail.gmail.com> <7d6fde3d0906101950r7640dbf5va8181fd80e2e07ba@mail.gmail.com> Date: Wed, 10 Jun 2009 23:24:49 -0700 Message-ID: <7d6fde3d0906102324i7c296d40pdf5a5e853c359bc3@mail.gmail.com> From: Garrett Cooper To: Dan Naumov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List , ata@freebsd.org, pjd@freebsd.org Subject: Re: Issues with gjournal (heaaaaaaaaaaalp!) 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, 11 Jun 2009 06:24:51 -0000 On Wed, Jun 10, 2009 at 10:58 PM, Dan Naumov wrote: > You need to mount your /dev/ad6s1d.journal as /usr and not > /dev/ad6s1d, because this is the new device provided to you by GEOM. > > - Dan Naumov > > > > On Thu, Jun 11, 2009 at 5:50 AM, Garrett Cooper wrote= : >> On Wed, Jun 10, 2009 at 7:44 PM, Garrett Cooper wrot= e: >>> Hi Pawel, ATA, and Stable folks, >>> >>> =A0 =A0This time when I did a reinstall I took the bullet and tried to >>> use gjournaling instead of softupdates. The unfortunate thing is that >>> I can't seem to get it to work. >>> >>> Here's the procedure that I'm trying to follow (based off of [1]): >>> - sysinstall from scratch with a minimal distribution. This creates >>> /usr // /dev/ad6s1d as UFS2 with softupdates disabled. >>> - Pull latest stable sources. Rebuild kernel (with `options >>> GEOM_JOURNAL'), world, install kernel, then world after reboot. >>> - gjournal label -f ad6s1d ad6s2d >>> - mount /dev/ad6s1d /usr # That works (I think...), but prints out the >>> error message below: >>> >>> GEOM_JOURNAL: [flush] Error while writing data (error=3D1) >>> ad6s2d[WRITE(offset=3D512, length=3D6656)] >>> >>> gjournal status says: >>> =A0 =A0 =A0 =A0 =A0 =A0Name =A0 Status =A0 Components >>> ad6s1d.journal =A0 =A0 =A0 N/A =A0 ad6s1d >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= ad6s2d >>> >>> Some issues I noticed: >>> >>> - GJOURNAL ROOT (something) loops infinitely if the device can't be >>> found; this should probably time out and panic / exit if a device >>> becomes unavailable (depends on fstab values in the final 2 fields no >>> doubt). I did this by accident when I forgot to add iir statically to >>> the kernel. >>> - The LiveCD doesn't fully support gjournal (userland's there, kernel >>> support isn't). Kind of annoying and counterproductive... >>> - Existing journal partitions disappeared when I upgraded by accident >>> from 7.2-RELEASE to 8-CURRENT (silly me copied my srcs.sup file from >>> my server with label=3D.). That was weird... >>> - When I use gjournal label with an existing filesystem I _must_ use -f= . >>> >>> Any help with this endeavor would be more than appreciated, as I want >>> to enable this functionality before I move on to installing X11, as >>> nvidia-driver frequently hardlocks the desktop (or has in the past). >>> >>> Thanks, >>> -Garrett >>> >>> [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-deskto= p/article.html >> >> And to answer another potential question, I've tried mounting both >> with -o rw,async and with -o rw. >> Thanks! >> -Garrett Hi Dan, I'm doing that right now =3D\... orangebox# mount /dev/ad6s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad6s1d.journal on /usr (ufs, asynchronous, local) /dev/ad6s1e on /usr/home (ufs, local) /dev/ad6s1f on /var (ufs, local) Thanks! -Garrett From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 08:41:17 2009 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 D48571065673 for ; Thu, 11 Jun 2009 08:41:17 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220]) by mx1.freebsd.org (Postfix) with ESMTP id 4471A8FC13 for ; Thu, 11 Jun 2009 08:41:16 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm20 with SMTP id 20so1255225fxm.43 for ; Thu, 11 Jun 2009 01:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.125.144 with SMTP id y16mr2016355far.93.1244709676136; Thu, 11 Jun 2009 01:41:16 -0700 (PDT) In-Reply-To: <20090604030724.V1181@besplex.bde.org> References: <20090603123208.GK1927@deviant.kiev.zoral.com.ua> <20090603143051.GM1927@deviant.kiev.zoral.com.ua> <20090603150710.GN1927@deviant.kiev.zoral.com.ua> <20090604030724.V1181@besplex.bde.org> From: Vlad Galu Date: Thu, 11 Jun 2009 11:40:56 +0300 Message-ID: To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-stable@freebsd.org, Oliver Fromme Subject: Re: poll()-ing a pipe descriptor, watching for POLLHUP 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, 11 Jun 2009 08:41:18 -0000 On Wed, Jun 3, 2009 at 9:42 PM, Bruce Evans wrote: [...] Hello Bruce, Kostik, Oliver. Was any consensus reached on how to tackle this issue? The RELENG_7 code looks slightly different so I haven't (yet) tried adapting the provided patches. As for the interface behavior, I think the nicest way would be to signal EOF by POLLHUP alone, without POLLIN. Regards, Vlad From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 12:13:28 2009 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 E2B52106564A for ; Thu, 11 Jun 2009 12:13:28 +0000 (UTC) (envelope-from vilmos.gyorgy@gmail.com) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by mx1.freebsd.org (Postfix) with ESMTP id 57CC28FC1D for ; Thu, 11 Jun 2009 12:13:27 +0000 (UTC) (envelope-from vilmos.gyorgy@gmail.com) Received: by bwz17 with SMTP id 17so156789bwz.43 for ; Thu, 11 Jun 2009 05:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ZiZgGKi/h50uJFZBSSsW2qgzJi1pbeflunVqekEKaRc=; b=rwuIicQeiupH2pO8QBIQGgVAmhWCiKpKcE8mlTcCvfJfszhjFqGeXVKI65Ox85aTSt r6YzWab9pnUeF8DITA+j/NaNksR9VfaYyJsoz7wGPPwK2c5rSaPksQ7hdTfVI2stNxR5 gALIiSZbYrrq+j9yzPzcVdvNqnMqlwGOECl8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bxrDY36C0Gfr/QmVy2iPpnoKkE8cQW5O9BJKAajStVcS1FC6r12CWwjZBEr38uCD1g tYLGPztC65C3QnoTOHLcxge1MNwjhpnbeUHk4gyLijDfoTMK74rkCu5BJRaeLivH3z31 TuN5QZC0rvGYLlY+oArIh3SvO7r79331S5yFM= MIME-Version: 1.0 Received: by 10.204.69.133 with SMTP id z5mr2360799bki.163.1244720410140; Thu, 11 Jun 2009 04:40:10 -0700 (PDT) Date: Thu, 11 Jun 2009 13:40:10 +0200 Message-ID: From: =?ISO-8859-1?Q?Gy=F6rgy_Vilmos?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: .zfs snapshot dir disappears and a crash later on, while umounting 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, 11 Jun 2009 12:13:29 -0000 Hi All! (please keep me on cc) FreeBSD 7/amd64 stable compiled with GENERIC on May 23 22:22:00 CEST 2009 (csuped sources around that time) on an IBM xSomething. I have a single disk zfs pool for backup purposes, the fs is compressed and the stuff goes onto it every night and then snapshotted once. I have a nullfs mount from that to a UFS partition, like this: bkp on /bkp (zfs, local) bkp@20090607 on /bkp/.zfs/snapshot/20090607 (zfs, local, noatime, read- only) bkp@20090610 on /bkp/.zfs/snapshot/20090610 (zfs, local, noatime, read- only) bkp@20090609 on /bkp/.zfs/snapshot/20090609 (zfs, local, noatime, read- only) bkp@20090608 on /bkp/.zfs/snapshot/20090608 (zfs, local, noatime, read- only) /bkp/hosting on /data/jail/hosting/bkp (nullfs, local) The strange thing is that while did the above, I lost .zfs, so an ls wrote this: ls /bkp/.zfs/snapshot ls: /bkp/.zfs/snapshot: Bad file descriptor df also didn't show the snapshot dirs after it, but I could do snapshots and zfs list -t snapshot showed them, I just couldn't access them. Today, I've tried to umount the nullfs mount and the zfs pool to see whether it helps the situation, but it didn't, I was awarded with a crashdump. What I did is: umount /data/jail/hosting/bkp (went fine, I haven't got back the .zfs snapshot dir) then: zfs export bkp (crash) The crashdump says: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff80517925 stack pointer = 0x10:0xffffff80780249d0 frame pointer = 0x10:0xffffff8078024a50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 35021 (zpool) trap number = 12 panic: page fault cpuid = 1 Uptime: 14d22h20m56s Physical memory: 4082 MB bt says: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff8050ff29 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #3 0xffffffff80510332 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff807d5a33 in trap_fatal (frame=0xffffff0020214390, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0xffffffff807d5e05 in trap_pfault (frame=0xffffff8078024920, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0xffffffff807d6744 in trap (frame=0xffffff8078024920) at /usr/src/ sys/amd64/amd64/trap.c:444 #7 0xffffffff807ba96e in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:209 #8 0xffffffff80517925 in _sx_xlock (sx=0xa0, opts=0, file=0xffffffff80f045e8 "/usr/src/sys/modules/zfs/../../cddl/contrib/ opensolaris/uts/common/fs/zfs/zfs_ctldir.c", line=1288) at atomic.h:143 #9 0xffffffff80e97e55 in zfsctl_umount_snapshots (vfsp=Variable "vfsp" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ common/fs/zfs/zfs_ctldir.c:1288 #10 0xffffffff80ea3560 in zfs_umount (vfsp=0xffffff00048b7380, fflag=0, td=Variable "td" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ common/fs/zfs/zfs_vfsops.c:1003 #11 0xffffffff8058e1a7 in dounmount (mp=0xffffff00048b7380, flags=0, td=0xffffff0020214390) at /usr/src/sys/kern/vfs_mount.c:1290 #12 0xffffffff8058e975 in unmount (td=0xffffff0020214390, uap=0xffffff8078024bf0) at /usr/src/sys/kern/vfs_mount.c:1186 #13 0xffffffff807d6087 in syscall (frame=0xffffff8078024c80) at /usr/ src/sys/amd64/amd64/trap.c:900 #14 0xffffffff807bab7b in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:330 #15 0x000000080102e5cc in ?? () Previous frame inner to this frame (corrupt stack?) I have the dump, if any further info could help. Thank you in advance. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 13:47:31 2009 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 AA884106567C for ; Thu, 11 Jun 2009 13:47:31 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from smtp1.servage.net (smtp1.servage.net [77.232.76.11]) by mx1.freebsd.org (Postfix) with ESMTP id 703C48FC1B for ; Thu, 11 Jun 2009 13:47:31 +0000 (UTC) (envelope-from lists@reiteration.net) Received: from [127.0.0.1] (roobarb.growveg.org [62.49.247.174]) by smtp1.servage.net (Postfix) with ESMTP id E8DD5F98232 for ; Thu, 11 Jun 2009 12:25:28 +0000 (GMT) Message-ID: <4A30F7A1.1080301@reiteration.net> Date: Thu, 11 Jun 2009 13:25:05 +0100 From: John User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090610-0, 10/06/2009), Outbound message X-Antivirus-Status: Clean Subject: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) 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, 11 Jun 2009 13:47:32 -0000 Hello list, uname -prs FreeBSD 7.2-RELEASE-p1 amd64 Question as subject, really. Is the malo driver capable of WPA2 under FreeBSD? ? If so, how would it be set? I've tried various wireless options via ifconfig, can't seem to get it to work, so am wondering if it is capable of it. I know support for it appeared in HEAD on OpenBSD around the middle of April, and this driver is derived from that. thanks -- John From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 15:35:40 2009 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 60FE81065670; Thu, 11 Jun 2009 15:35:40 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EC8188FC22; Thu, 11 Jun 2009 15:35:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5BFZalW021679; Thu, 11 Jun 2009 09:35:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A312448.1060009@samsco.org> Date: Thu, 11 Jun 2009 09:35:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Andre Oppermann References: <4A2FA4EF.5060603@freebsd.org> <4A2FC858.5050800@samsco.org> <4A2FE765.9000803@freebsd.org> In-Reply-To: <4A2FE765.9000803@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step 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, 11 Jun 2009 15:35:40 -0000 Andre Oppermann wrote: > Scott Long wrote: >> Andre Oppermann wrote: >>> Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got >>> a big >>> nasty surprise with the Areca RAID controller: >>> >>> arcmsr0: >> > mem 0xfdbff000-0xfdb400000 irq16 at device 14.0 on pci18 >>> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >>> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 >>> arcmsr0: [ITHREAD] >>> ... >>> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >>> run_interrupt_driven_hooks: still waiting after 60 seconds for >>> xpt_config >>> >>> From here on it hangs and repeats the last message with some sort of >>> exponential backoff. Ctrl-Alt-Del to reboot doesn't work but ScrollLock >>> does. Hard reset is required to reboot. >>> >>> Booting the old 6.4 kernel works and the system comes up again with full >>> access to the RAID array. >>> >>> Any help appreciated. >>> >> >> I'll try to reproduce this locally. There have been sporadic reports of >> the "fails comparison" problem, but none as fatal as this. Is it >> possible to compile your kernel with CAMDEBUG and >> CAM_DEBUG_FLAGS=CAM_DEBUG_INFO? > > CAMDEBUG doesn't give any output. > > As it turns out the hang seems to be related to an interrupt routing > problem somehow. I did an BIOS upgrade and BIOS settings factory reset. > The mainboard is an ASUS M2N32 WS Professional with an Athlon64 X2 4800+. > Enabling all on-board devices including ATA and various SATA controllers > together with "PnP OS" set to yes fixed the hand and allowed FreeBSD 7 to > boot sucessfully. Why 6.4 doesn't stumble I don't know. > > The "(probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step" > line is still there. Fortunately the boot process simply continues from > there without further trouble. > > If there are any other CAM debug options or patches you want me to try I > can do that. The system is only in partial production and I'm allowed to > reboot it during workhours. > You enabled both CAMDEBUG and CAM_DEBUG_FLAGS=CAM_DEBUG_INFO in your kernel? Scott From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 15:47:24 2009 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 B0855106564A for ; Thu, 11 Jun 2009 15:47:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8A05E8FC16 for ; Thu, 11 Jun 2009 15:47:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5BFHp1t034560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 08:17:51 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A31201F.8060300@freebsd.org> Date: Thu, 11 Jun 2009 08:17:51 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: John References: <4A30F7A1.1080301@reiteration.net> In-Reply-To: <4A30F7A1.1080301@reiteration.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: FreeBSD Stable Subject: Re: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) 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, 11 Jun 2009 15:47:24 -0000 John wrote: > Hello list, > > uname -prs > FreeBSD 7.2-RELEASE-p1 amd64 > > Question as subject, really. Is the malo driver capable of WPA2 under > FreeBSD? ? If so, how would it be set? I've tried various wireless > options via ifconfig, can't seem to get it to work, so am wondering if > it is capable of it. I know support for it appeared in HEAD on OpenBSD > around the middle of April, and this driver is derived from that. > > thanks > malo is derived from the mwl driver. it supports wpa. Sam From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 16:32:06 2009 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 03DFD106566C for ; Thu, 11 Jun 2009 16:32:06 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 829C38FC12 for ; Thu, 11 Jun 2009 16:32:05 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz27 with SMTP id 27so25765bwz.43 for ; Thu, 11 Jun 2009 09:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pB53Zc6vWiR7CTTyhgkNQIxusHDH0xGVY188XPXHdOA=; b=v4tBlzcy1PtdzL0qWpSAWVwMHeuP4arv2Fy8VqFxbRFKLpCvn/6eqmEOskQeuKvMRk MFHoD4UhHjTz/W77ASNHY1Wq2QNvipjkOdcmFf+B+CcaYYnRSNb3eLGzNieJKjTpLvNI ud4k85XQ/xqDx14gs1GYUWNrZwLlmA8KfIAkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PsGTHTjqFI8/BlXc75dVOAPoJy6j+ct9p8LyRIK+0s4Fj0zCNBQqbVb/ohMFD8SYDV lOuLiGyh76FSpJVsfvidRgW+tfURq8EmIL6wKBK+8fzeZO1nYqEXnGWu07+f+5e59Xmj tRGo+6bV2Z+xBPtXF78t7F+8TM07byYUvUUek= MIME-Version: 1.0 Received: by 10.204.54.4 with SMTP id o4mr2691844bkg.10.1244737923999; Thu, 11 Jun 2009 09:32:03 -0700 (PDT) In-Reply-To: <4A30F7A1.1080301@reiteration.net> References: <4A30F7A1.1080301@reiteration.net> Date: Thu, 11 Jun 2009 16:32:03 +0000 Message-ID: <3a142e750906110932naca99bam8d0e0735ddec2797@mail.gmail.com> From: "Paul B. Mahol" To: John Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: malo wireless driver - is this capable of wpa2-personal (WPA2-PSK) 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, 11 Jun 2009 16:32:06 -0000 On 6/11/09, John wrote: > Hello list, > > uname -prs > FreeBSD 7.2-RELEASE-p1 amd64 > > Question as subject, really. Is the malo driver capable of WPA2 under > FreeBSD? ? If so, how would it be set? I've tried various wireless via wpa_supplicant(8) > options via ifconfig, can't seem to get it to work, so am wondering if > it is capable of it. I know support for it appeared in HEAD on OpenBSD > around the middle of April, and this driver is derived from that. > > thanks > -- > John > _______________________________________________ > 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" > -- Paul From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 21:25:32 2009 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 D7DA2106564A for ; Thu, 11 Jun 2009 21:25:32 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id B603E8FC15 for ; Thu, 11 Jun 2009 21:25:32 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 18323 invoked by uid 89); 11 Jun 2009 19:47:41 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 11 Jun 2009 19:47:41 -0000 Message-Id: From: Dan Allen To: FreeBSD-STABLE Mailing List Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 14:58:49 -0600 X-Mailer: Apple Mail (2.935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Something since June 8th clobbers my disk... 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, 11 Jun 2009 21:25:33 -0000 I sync with 7-STABLE almost every day. I build everything on a Toshiba U205 Satellite. Things are fine for months on end. I did this on June 8th. Everything was fine. I did this on June 10th. The machine no longer booted. The entire root partition got clobbered. I reinstalled a snapshot of 7-STABLE from May 28th that I had put on a DVD. Everything was once again fine. I then sync'd again this morning June 11th with 7-STABLE, did a full build, and reproducibly, BOOM - the entire root partition got clobbered. Gone. Again. After the reboot it just comes up with: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 and stops. Nothing else is printed. There is no choice of how to boot. There is no files for me to send, no log files to inspect, no remnants. I unfortunately did not see where in the build this happened. My build does the canonical steps exactly as outlined in / usr/src/Makefile and then does a reboot. It builds userland and the kernel. When I inspect it from the bootable DVD the partition that my root filesystem was in has no association with it having the root any more. The partition is listed, but it looks like it had been freshly partitioned. Something is very, very wrong. Ideas? Dan Allen From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 21:40:39 2009 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 5AD90106566C for ; Thu, 11 Jun 2009 21:40:39 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220]) by mx1.freebsd.org (Postfix) with ESMTP id DFF178FC0A for ; Thu, 11 Jun 2009 21:40:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm20 with SMTP id 20so1687203fxm.43 for ; Thu, 11 Jun 2009 14:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gy/SKaU3kCKIWMb92ky4jCpAxwq58ewFgX8ss+94Suo=; b=usqRS/HCGyy/SjTFhx+OxCHSogZajZsdLbTp1U4WC34hehVadVsfALz7iXSuI7JnQ3 1fKDMeWr5luF8q3lPklHSxynO27v6ReS3ywWMMvCFDUifP6DsR59LnupUYsmUSANJUTN xRK0PhGvZy+WdVRBd5GvtsSqc6NnLCKJpBkeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GKSrlImpT03eElxRB5OEldx/S/PPsxKakj0TlvDVsLCV1yvDMYi6B/XDX23CPw61Rv piYE7K0LV280yY/bqPR/juRst4V3uvF3fVbmpGY4SAR9IsfMughZLFwg2ob+s6ULgv4M 3CYalBpQJVsvs5BoLEeCASRv+jSw9U6zDYeLg= MIME-Version: 1.0 Received: by 10.204.123.83 with SMTP id o19mr2942022bkr.12.1244756437460; Thu, 11 Jun 2009 14:40:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jun 2009 21:40:37 +0000 Message-ID: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> From: "Paul B. Mahol" To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 11 Jun 2009 21:40:39 -0000 On 6/11/09, Dan Allen wrote: > I sync with 7-STABLE almost every day. I build everything on a > Toshiba U205 Satellite. Things are fine for months on end. > > I did this on June 8th. Everything was fine. > > I did this on June 10th. The machine no longer booted. The entire > root partition got clobbered. I reinstalled a snapshot of 7-STABLE > from May 28th that I had put on a DVD. Everything was once again fine. > > I then sync'd again this morning June 11th with 7-STABLE, did a full > build, and reproducibly, BOOM - the entire root partition got > clobbered. Gone. Again. After the reboot it just comes up with: > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive A: is disk0 > BIOS drive C: is disk1 > > and stops. Nothing else is printed. There is no choice of how to > boot. There is no files for me to send, no log files to inspect, no > remnants. I unfortunately did not see where in the build this > happened. My build does the canonical steps exactly as outlined in / > usr/src/Makefile and then does a reboot. It builds userland and the > kernel. > > When I inspect it from the bootable DVD the partition that my root > filesystem was in has no association with it having the root any > more. The partition is listed, but it looks like it had been freshly > partitioned. > > Something is very, very wrong. > > Ideas? Are you using ZFS on root partition? -- Paul From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 21:44:25 2009 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 2BC61106566C for ; Thu, 11 Jun 2009 21:44:25 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id E32778FC17 for ; Thu, 11 Jun 2009 21:44:24 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 8363 invoked by uid 89); 11 Jun 2009 20:33:13 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 11 Jun 2009 20:33:13 -0000 Message-Id: <7747D41F-0F3E-4D4A-AA20-552F308D8D2E@airwired.net> From: Dan Allen To: "Paul B. Mahol" In-Reply-To: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 15:44:23 -0600 References: <3a142e750906111440s26405c53v82fa82917145b930@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 11 Jun 2009 21:44:25 -0000 On 11 Jun 2009, at 3:40 PM, Paul B. Mahol wrote: > Are you using ZFS on root partition? No. The disk is the default (UFS2 I believe). So I just reinstalled BSD again and this time I did not reinitialize the file system and after a brief disk integrity check it reinstalled and files I had added were still there! So apparently the file system did not get munged as much as the main disk partition map got nailed. So, what has changed recently that could mess with the disk partition map? I have Windows on the first disk partition and it has not been harmed with these problems. Dan From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 22:40:58 2009 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 C6AA71065672 for ; Thu, 11 Jun 2009 22:40:58 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7F78FC0C for ; Thu, 11 Jun 2009 22:40:58 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 1727 invoked by uid 89); 11 Jun 2009 21:29:47 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 11 Jun 2009 21:29:47 -0000 Message-Id: <68F716C4-212C-449E-AEB7-AA14720C0D69@airwired.net> From: Dan Allen To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 16:40:56 -0600 X-Mailer: Apple Mail (2.935.3) Subject: Re: Something since June 8th clobbers my disk... 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, 11 Jun 2009 22:40:59 -0000 In trying to figure this out, I rebuilt a GENERIC kernel after sync'ing to today's RELENG_7 sources. I then installed it, held my breath, and rebooted. It works! So I am now looking at userland (make buildworld && make installworld) to see if it is the culprit. Another possibility is my custom kernel build. Stay tuned... Dan From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 23:36:48 2009 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 0C67C106566B for ; Thu, 11 Jun 2009 23:36:48 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id C6D8C8FC0C for ; Thu, 11 Jun 2009 23:36:47 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 26743 invoked by uid 89); 11 Jun 2009 22:25:35 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 11 Jun 2009 22:25:35 -0000 Message-Id: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> From: Dan Allen To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 17:36:46 -0600 X-Mailer: Apple Mail (2.935.3) Subject: Re: Something since June 8th clobbers my disk... 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, 11 Jun 2009 23:36:48 -0000 Okay. I did a make buildkernel && installkernel and rebooted, no problems. I then did a make buildworld and rebooted, no problems. I then did a make installworld which completed normally, rebooted, and BINGO - my disk partition table has been zapped. The problem appears to be something that runs during this 'make installworld'! There are no problems with the build itself that I can tell, but some program is munging the disk partition table. In a zany sort of way this is progress. Of course now I have to reinstall the OS, again... Dan Allen From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 23:41:29 2009 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 7CD32106566B for ; Thu, 11 Jun 2009 23:41:29 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by mx1.freebsd.org (Postfix) with ESMTP id 0241B8FC08 for ; Thu, 11 Jun 2009 23:41:28 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz17 with SMTP id 17so7592bwz.43 for ; Thu, 11 Jun 2009 16:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d17/Rm9toIHKVzwiDys672zV0M4WVW4b2N2lwRBd7UU=; b=MnZeetbV06Z41hJW3ZHKCty7VisHVOgHF7syNlJJBQUmiWz01TxAcm0dzH0Cf+cNsM M7Vfzf2WLert2Sh47Z5AZXrN1B6/h5YG/MsatAxKGFNqagMNoxnXvufkng8GyNOphFPl uaRKL3usZVlZth6inml3LmeYpGSf6e3hzRzpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sKvt+jRCDjhVsMVSjKExg8kRoIJALYYyqDoi01re62P+OZcGNEcf/jO7CNSBOCOMfR TP9iHABScznBeqgWwWIjr/F1DAwR2AClzRwj8g15nh/YKMwTYfgN9N5SyfS5guicvZee FbDwfwNwtG5f8ot3yE+idZxGKBIGRduhmv/IE= MIME-Version: 1.0 Received: by 10.204.116.208 with SMTP id n16mr3034013bkq.96.1244763686481; Thu, 11 Jun 2009 16:41:26 -0700 (PDT) In-Reply-To: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> Date: Thu, 11 Jun 2009 23:41:26 +0000 Message-ID: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> From: "Paul B. Mahol" To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 11 Jun 2009 23:41:29 -0000 On 6/11/09, Dan Allen wrote: > Okay. I did a > > make buildkernel && installkernel > > and rebooted, no problems. > > I then did a > > make buildworld > > and rebooted, no problems. > > I then did a > > make installworld > > which completed normally, rebooted, and > > BINGO - my disk partition table has been zapped. > > The problem appears to be something that runs during this 'make > installworld'! > > There are no problems with the build itself that I can tell, but some > program is munging the disk partition table. > > In a zany sort of way this is progress. Of course now I have to > reinstall the OS, again... Looks like boot(8) is problematic. Anything in /etc/src.conf or /etc/make.conf? -- Paul From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 01:10:21 2009 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 C21CF106566B for ; Fri, 12 Jun 2009 01:10:21 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7721A8FC08 for ; Fri, 12 Jun 2009 01:10:21 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.1.73] (ppp-71-139-19-63.dsl.snfc21.pacbell.net [71.139.19.63]) (authenticated bits=0) by ape.monkeybrains.net (8.14.3/8.14.1) with ESMTP id n5C0l70K001001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 17:47:08 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <4A31A596.6090707@monkeybrains.net> Date: Thu, 11 Jun 2009 17:47:18 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at pita.monkeybrains.net X-Virus-Status: Clean Subject: ZFS jumps from slice to partition on upgrade (???) 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, 12 Jun 2009 01:10:22 -0000 I just bumped from: FreeBSD 7.2-PRERELEASE #1: Wed Mar 18 00:55:27 PDT 2009 to: FreeBSD 7.2-STABLE #2: Wed Jun 10 18:27:30 PDT 2009 I rebooted and my zpool was WHACK'd. I was getting these errors in /var/log/messages: Jun 11 16:54:55 crepe3 root: ZFS: vdev I/O failure, zpool=tank path=/dev/ad6s2c offset=481721292800 size=1024 error=5 Jun 11 16:54:55 crepe3 root: ZFS: vdev I/O failure, zpool=tank path=/dev/ad6s2c offset=481721293824 size=1024 error=5 I had ad0s2 and ad6s2 in my zpool mirror, but after the upgrade zfs read the devices as: ad0s2 and ad6s2c. So I dropped the 'c' parition and reattached the slice: # zpool detach tank ad6s2c # zpool attach tank ad0s2 ad6s2 and now my 'zpool status' shows it resilvering... pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h22m, 21.91% done, 1h21m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad0s2 ONLINE 0 0 0 82.2M resilvered ad6s2 ONLINE 0 0 0 19.0G resilvered QUESTION: Why the heck would ZFS latch onto ad6s2c partition instead of the ad6s2 slice? I've rebooted many times before without issue... it seems the upgrade bonk'd things. Hopefully when this is all done, I can run zfs upgrade... anyone have trouble with "zfs upgrade"? Rudy From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 01:30:09 2009 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 0949E106564A for ; Fri, 12 Jun 2009 01:30:09 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id E6FE58FC1C for ; Fri, 12 Jun 2009 01:30:08 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from [192.168.1.73] (ppp-71-139-19-63.dsl.snfc21.pacbell.net [71.139.19.63]) (authenticated bits=0) by ape.monkeybrains.net (8.14.3/8.14.1) with ESMTP id n5C1Twgk007857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 18:29:58 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <4A31AFA1.304@monkeybrains.net> Date: Thu, 11 Jun 2009 18:30:09 -0700 From: Rudy User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4A31A596.6090707@monkeybrains.net> In-Reply-To: <4A31A596.6090707@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at pita.monkeybrains.net X-Virus-Status: Clean Subject: Re: ZFS jumps from slice to partition on upgrade (???) 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, 12 Jun 2009 01:30:09 -0000 History for 'tank': 2008-01-17.23:07:08 zpool create tank mirror ad0s2 ad8s2 2008-01-17.23:40:35 zfs create -o quota=100g tank/test.monkeybrains.net ... many more creates/deletes ... then the zfs freakout ... 2009-06-11.16:43:33 zpool clear tank 2009-06-11.16:43:59 zpool scrub tank 2009-06-11.16:48:58 zpool scrub -s tank 2009-06-11.16:54:56 zpool detach tank ad6s2c 2009-06-11.16:55:57 zpool attach tank ad0s2 ad6s2 Maybe having the device jump from ad8s2 to ad6s2 freaked out zfs? Any thoughts, or will the Internet tube swallow this post silently? Rudy From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 01:33:28 2009 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 A885D1065674 for ; Fri, 12 Jun 2009 01:33:28 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0AC8FC08 for ; Fri, 12 Jun 2009 01:33:28 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 10341 invoked by uid 89); 12 Jun 2009 00:22:11 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 12 Jun 2009 00:22:11 -0000 Message-Id: From: Dan Allen To: "Paul B. Mahol" In-Reply-To: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 19:33:24 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 12 Jun 2009 01:33:28 -0000 On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > Looks like boot(8) is problematic. > Anything in /etc/src.conf or /etc/make.conf? I have never touched or created a src.conf. If there was one there, it has been unmodified by me. I HAVE modified make.conf. Here is its contents: --- /etc/make.conf --- BATCH=yes NO_PROFILE=yes KERNCONF=DKA USE_FORTRAN=yes WITH_JADETEX=no PERL_VERSION=5.8.9 --- My custom kernel named DKA has only three modifications from GENERIC: I commented out the following three lines: #cpu I486_CPU #cpu I586_CPU #makeoptions DEBUG="-g" I have run with such a kernel on many machines for many years now. However, my experiments have shown that the kernel build is not to blame. Isn't boot part of the kernel build? Why would installing the kernel not cause this problem? It is by installing the world via make installworld that my drive gets munged. I obviously am missing something, but boot(8) sounds like it is in the neighborhood of where the problem is. There were changes to /usr/src/sys/boot/i386/libi386/biosdisk.c and biospnp.c that really look suspect to me. Dan From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 05:03:51 2009 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 89CA8106564A; Fri, 12 Jun 2009 05:03:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 508308FC13; Fri, 12 Jun 2009 05:03:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5C53mQY095212; Fri, 12 Jun 2009 01:03:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5C53m2m043759; Fri, 12 Jun 2009 01:03:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id EA98D241BA; Fri, 12 Jun 2009 01:03:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090612050347.EA98D241BA@freebsd-legacy.sentex.ca> Date: Fri, 12 Jun 2009 01:03:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_6 tinderbox] failure on amd64/amd64 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: Fri, 12 Jun 2009 05:03:52 -0000 TB --- 2009-06-12 05:03:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-06-12 05:03:27 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-06-12 05:03:27 - cleaning the object tree TB --- 2009-06-12 05:03:47 - WARNING: /obj/amd64/src/sys/LINT/modules/src/sys/modules/sound/driver/spicds: Directory not empty TB --- 2009-06-12 05:03:47 - ERROR: unable to remove old object directory TB --- 2009-06-12 05:03:47 - 0.55 user 2.09 system 20.02 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 07:57:43 2009 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 E5D30106564A for ; Fri, 12 Jun 2009 07:57:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A49098FC13 for ; Fri, 12 Jun 2009 07:57:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MF1du-0005tm-HL; Fri, 12 Jun 2009 10:57:42 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jun 2009 10:57:42 +0300 From: Danny Braniss Message-ID: Cc: Pyun YongHyeon Subject: (no subject) 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, 12 Jun 2009 07:57:44 -0000 latest -stable (June 11) is causing problems: MB is intel SE7320VP21, msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering msk0: watchdog timeout (missed Tx interrupts) -- recovering ... cheers, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 08:42:38 2009 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 643DD1065673 for ; Fri, 12 Jun 2009 08:42:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0A08FC14 for ; Fri, 12 Jun 2009 08:42:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so693908rvb.43 for ; Fri, 12 Jun 2009 01:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=+ANkmWM4Up84ACD6Z8oMHBqqqRyf2G/Of7p9FIOSiQw=; b=tXKvdpU5ypCOVo3oulxA8zL4DpVJKGQr8DYnaqUrrpJriuOVLk3o+WPh8UF9aXJ0qB 5KsvAgIgWxlS2772YFT8fVQhPSfTxhXnTJNjAM+5UF6X8aqxnQw5BLcgAsBW4v0B4Cg7 SJp1dW2/sNrRZQtmLfE7i1H9gFbFoLIFgZL9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=UscHmZ/1UxLhsoktUwSIem6sCq5kL0Fsg0CDN4g8iiMunouv43tIsRHvfJ/to/aBLh UYIJg1DeXS6xKTXBRFqnlRxUvzf7RgOkrkqcQlC211/LfKnCNu5ZF6xNrvrmlt2Rt+Bt j14LLGEp8MxsggE+EfeeJe4qDloNCXyyeFcC8= Received: by 10.141.18.1 with SMTP id v1mr2718869rvi.221.1244794767498; Fri, 12 Jun 2009 01:19:27 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id f42sm3281920rvb.41.2009.06.12.01.19.25 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 01:19:26 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 12 Jun 2009 17:22:12 +0900 From: Pyun YongHyeon Date: Fri, 12 Jun 2009 17:22:12 +0900 To: Danny Braniss Message-ID: <20090612082212.GE72855@michelle.cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: your mail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 08:42:38 -0000 On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > latest -stable (June 11) is causing problems: > MB is intel SE7320VP21, > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > msk0: watchdog timeout (missed Tx interrupts) -- recovering > ... > I think there was not much msk(4) changes in stable. msk(4) in CURRENT has a lot changes to support newer controllers. Does msk(4) in CURRENT make any difference? Also please show me dmesg output(msk(4) related one) to know which controller you have. Btw, are you using MSI? > cheers, > danny > > From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 08:59:29 2009 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 E2218106564A for ; Fri, 12 Jun 2009 08:59:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2898FC13 for ; Fri, 12 Jun 2009 08:59:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MF2bf-0006Q1-OQ; Fri, 12 Jun 2009 11:59:27 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: pyunyh@gmail.com In-reply-to: <20090612082212.GE72855@michelle.cdnetworks.co.kr> References: <20090612082212.GE72855@michelle.cdnetworks.co.kr> Comments: In-reply-to Pyun YongHyeon message dated "Fri, 12 Jun 2009 17:22:12 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jun 2009 11:59:27 +0300 From: Danny Braniss Message-ID: Cc: stable@freebsd.org Subject: Re: msk/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: Fri, 12 Jun 2009 08:59:30 -0000 > On Fri, Jun 12, 2009 at 10:57:42AM +0300, Danny Braniss wrote: > > latest -stable (June 11) is causing problems: > > MB is intel SE7320VP21, > > > > msk0: Ethernet address: 00:0e:0c:6a:85:a8 > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > msk0: watchdog timeout (missed Tx interrupts) -- recovering > > ... > > > > I think there was not much msk(4) changes in stable. msk(4) in > CURRENT has a lot changes to support newer controllers. Does msk(4) > in CURRENT make any difference? > Also please show me dmesg output(msk(4) related one) to know which > controller you have. hrumph, missed some lines: mskc0: port 0xb800-0xb8ff mem 0xdeefc000-0xdeefffff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:0e:0c:6a:85:a8 miibus0: on msk0 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] > > Btw, are you using MSI? yes, but it was (so it seemed) working ok. i'll try again soon without msi. in the meantime, Im running an older kernel, trying to finish a very long process (svn/svk), which when done, I will be able to compile current. thanks, danny From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 12:59:22 2009 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 3928F106566B for ; Fri, 12 Jun 2009 12:59:22 +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 0A9E58FC0A for ; Fri, 12 Jun 2009 12:59:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 74AE846B29; Fri, 12 Jun 2009 08:59:21 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 047098A06A; Fri, 12 Jun 2009 08:59:20 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 12 Jun 2009 08:32:50 -0400 User-Agent: KMail/1.9.7 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906120832.51098.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 12 Jun 2009 08:59:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dan Allen , "Paul B. Mahol" Subject: Re: Something since June 8th clobbers my disk... 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, 12 Jun 2009 12:59:22 -0000 On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? No, sys/boot is built during world. Likely some change in /boot/loader is causing your problem. Can you narrow it down to a specific change under sys/boot? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 13:56:50 2009 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 CA14C1065689; Fri, 12 Jun 2009 13:56:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DFA3F8FC1E; Fri, 12 Jun 2009 13:56:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 QAA09983; Fri, 12 Jun 2009 16:56:48 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A325E9F.2080802@icyb.net.ua> Date: Fri, 12 Jun 2009 16:56:47 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: zfs related panic 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, 12 Jun 2009 13:56:51 -0000 This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the latest version. I did zfs rollback xxx@yyy And then did ls on a directory in the rolled-back fs. I have the core file if it can be of any help. Sleeping thread (tid 100263, pid 2432) owns a non-sleepable lock sched_switch() at 0xffffffff8031d0ef = sched_switch+0x47d mi_switch() at 0xffffffff80302a59 = mi_switch+0x1bf sleepq_switch() at 0xffffffff8032f645 = sleepq_switch+0xd8 sleepq_catch_signals() at 0xffffffff8032f925 = sleepq_catch_signals+0x2db sleepq_wait_sig() at 0xffffffff80330219 = sleepq_wait_sig+0xc _sleep() at 0xffffffff80302eba = _sleep+0x2b5 kern_sigsuspend() at 0xffffffff802fc567 = kern_sigsuspend+0xeb sigsuspend() at 0xffffffff802fc5e9 = sigsuspend+0x34 syscall() at 0xffffffff80491d2d = syscall+0x347 Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = 0x7fffffffdee8, rbp = 0x8011e5a60 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80192dd5 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff80327ea7 = kdb_backtrace+0x32 panic() at 0xffffffff802fb70c = panic+0x1b0 propagate_priority() at 0xffffffff80332e92 = propagate_priority+0x122 turnstile_wait() at 0xffffffff80333e29 = turnstile_wait+0x358 _mtx_lock_sleep() at 0xffffffff802ed64a = _mtx_lock_sleep+0x117 cache_lookup() at 0xffffffff8036a52a = cache_lookup+0x632 vfs_cache_lookup() at 0xffffffff8036a69f = vfs_cache_lookup+0xab VOP_LOOKUP_APV() at 0xffffffff804c86f3 = VOP_LOOKUP_APV+0x51 lookup() at 0xffffffff80370a71 = lookup+0x5d8 namei() at 0xffffffff8037168f = namei+0x320 kern_lstat() at 0xffffffff8037f6ca = kern_lstat+0x5e lstat() at 0xffffffff8037f8c9 = lstat+0x25 syscall() at 0xffffffff80491d2d = syscall+0x347 Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffffffdde8, rbp = 0x800b50270 --- -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 17:03:38 2009 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 BEAA61065673; Fri, 12 Jun 2009 17:03:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id 832078FC13; Fri, 12 Jun 2009 17:03:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by pxi30 with SMTP id 30so1685700pxi.3 for ; Fri, 12 Jun 2009 10:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=v62ImNvzWEnAsqcxjTMIDivQeNw5F32uf6hynx8DVR4=; b=YneKAbqBh5lBZBxxkIUA32hUg14IExeH/ElCLqXcTOLoAZsTO4kHXEqsUN1kA67XfJ /zXnp8mslDkUqbJBNUohLxq6cpXN9NXV27RWfhyIXqkDNxKUqwk54USXPjJpvE+gQyJo Nt6X0+Wa2HF+1vc+z2WGKZPTotWUrpAsfYJpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sY+Gr9U8RC1HTsVHk6RbzhkM1+4ICy15+3jT73M2NCmIYsUvdT0lNgPPyNL9NQwOyF +Aifi3IWEJVL+e9IJGYRSeJVB1lj9fVZIfwnWWykNcjfcKlhp7j5+Q6b6UftfmA9A/Ug ND3tClJ8jSXVgQVA5Hd9qpBQKpZ4f0YY2tN+E= MIME-Version: 1.0 Received: by 10.142.225.20 with SMTP id x20mr1522352wfg.127.1244826218220; Fri, 12 Jun 2009 10:03:38 -0700 (PDT) Date: Fri, 12 Jun 2009 10:03:38 -0700 Message-ID: <2a41acea0906121003n4e2c8a54k6ac41cc934c6d7d0@mail.gmail.com> From: Jack Vogel To: FreeBSD Net , FreeBSD Current , FreeBSD stable Content-Type: multipart/mixed; boundary=000e0cd28cf08b4e89046c29b00f X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Intel ESB2 problems and their solution 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, 12 Jun 2009 17:03:39 -0000 --000e0cd28cf08b4e89046c29b00f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I wanted to circulate a document from our technical marketing group that details a problem with the family of adapters called ES2LAN. These are most commonly seen as LOMs (on motherboard) in SuperMicro and other servers, the most common device ID is 0x1096 but also may be 0x1098, 0x10BA, or 0x10BB. They are a device driven by the 'em' driver. This document has some Windows symptoms that will be of no value here, but the problem does occur on FreeBSD, most often it is seen as a failure to load, due to a "Shared Code Initialization" failure. There is driver changes in 7.2 that address this problem, however the driver alone is only part of the complete solution, you MUST have firmware updates to resolve the problem, and this document provides pointers for particular systems. If you have a system that has seen this issue please obtain and apply the relevant firmware. I hope this helps resolve any of these issues customers are still seeing. Cheers everyone, Jack Vogel Intel Lan Access Division freebsd@intel.com --000e0cd28cf08b4e89046c29b00f Content-Type: application/pdf; name="ESB2_problems.pdf" Content-Disposition: attachment; filename="ESB2_problems.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fvv5ah0y0 JVBERi0xLjQNJeLjz9MNCjMwIDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDI5NTQwL08gMzIvRSA2 MzQ5L04gNC9UIDI4ODkzL0ggWyA1OTYgMjYxXT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQozMCAxNQ0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwODU3IDAwMDAwIG4NCjAw MDAwMDA5MzggMDAwMDAgbg0KMDAwMDAwMTA2OCAwMDAwMCBuDQowMDAwMDAxMTg2IDAwMDAwIG4N CjAwMDAwMDE3NjQgMDAwMDAgbg0KMDAwMDAwMjE2NSAwMDAwMCBuDQowMDAwMDAyNDA4IDAwMDAw IG4NCjAwMDAwMDI0ODUgMDAwMDAgbg0KMDAwMDAwMjcxMyAwMDAwMCBuDQowMDAwMDA0OTc3IDAw MDAwIG4NCjAwMDAwMDUzNTggMDAwMDAgbg0KMDAwMDAwNTU5NyAwMDAwMCBuDQowMDAwMDA2MTI3 IDAwMDAwIG4NCjAwMDAwMDA1OTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0NS9QcmV2IDI4 ODgyL1Jvb3QgMzEgMCBSL0luZm8gMjkgMCBSL0lEWzwyRkQ2NDBBMkU0MEI1RDkzRjlDQTQxQzE2 QThBODMzQT48MDQ2MUE2QTZBMjdDQjE0MjhGRUJEMjE3NzI2OUQ0RjQ+XT4+DQpzdGFydHhyZWYN CjANCiUlRU9GDQogICAgICAgICAgICAgDQo0NCAwIG9iag08PC9MZW5ndGggMTczL0ZpbHRlci9G bGF0ZURlY29kZS9JIDE4Ny9MIDE3MS9TIDExMT4+c3RyZWFtDQp42mJgYGBmYGBaysDCwMBxnIGX AQF4gWKsQMwxlSHpyQs+MQaG2f/BEowsU0TfRc24xHG4+NQUrw1L0hwlMl20Ii55hxwAmmbiAFSi pAwkmFRC0xpAGgSNLaAmAAE/A4PPCSDNA8QQEWUGHtYPwYof83gZtHgktoouOCP3YTfrgyrexGm8 Fx4xcCUJOGZAnCTJwBD/HWQyENsCsSwDQ959kIuA+B1AgAEAnecotg0KZW5kc3RyZWFtDWVuZG9i ag0zMSAwIG9iag08PC9NZXRhZGF0YSAyOCAwIFIvUGFnZXMgMjcgMCBSL1R5cGUvQ2F0YWxvZy9Q YWdlTGFiZWxzIDI1IDAgUj4+DWVuZG9iag0zMiAwIG9iag08PC9Dcm9wQm94WzAgMCA2MTIgNzky XS9QYXJlbnQgMjcgMCBSL0NvbnRlbnRzIDM5IDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEy IDc5Ml0vUmVzb3VyY2VzIDMzIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMzMgMCBvYmoNPDwvRm9u dDw8L1RUMiAzNCAwIFIvVFQ0IDM1IDAgUi9UVDYgNDAgMCBSL1RUOCA0MiAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAgUj4+Pj4NZW5kb2JqDTM0IDAgb2JqDTw8 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMzYgMCBSL0xhc3RDaGFyIDE3NC9XaWR0 aHNbMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDAgMjUwIDI3OCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDAgMCA1NjQgMCAwIDAgNzIyIDY2NyA2 NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMCA3MjIgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2 NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiAwIDAgMCAwIDAgMCAwIDAgNDQ0IDUwMCA0NDQgNTAw IDQ0NCAzMzMgNTAwIDUwMCAyNzggMCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4 OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAzMzMgNDQ0IDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDc2MF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmly c3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzUg MCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAzOCAwIFIvTGFzdENoYXIg MTIxL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDMzMyAwIDAgMCAwIDAgMCAwIDcyMiA3MjIgNzIyIDY2NyA2MTEgMCAwIDI3OCAw IDAgMCA4MzMgMCA3NzggNjY3IDAgNzIyIDY2NyA2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NTU2IDAgNTU2IDYxMSA1NTYgMzMzIDYxMSAwIDI3OCAwIDAgMjc4IDg4OSA2MTEgNjExIDYxMSAw IDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9G aXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0z NiAwIG9iag08PC9TdGVtViA4Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFNNVC9Gb250U3RyZXRj aC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy01 NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCA4OTEvRm9udEZhbWlseShUaW1lcyBOZXcgUm9tYW4p L0NhcEhlaWdodCA2NTYvWEhlaWdodCAtNTQ2L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5n bGUgMD4+DWVuZG9iag0zNyAwIG9iag08PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4 dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTM4IDAgb2JqDTw8L1N0ZW1WIDEzOC9G b250TmFtZS9BcmlhbC1Cb2xkTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0Zs YWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJveFstNjI4IC0zNzYgMjAwMCAxMDEwXS9Bc2NlbnQg OTA1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTM5IDAgb2JqDTw8L0xlbmd0aCAyMTkz L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpo3qxYy27jyBXd+ytqSQYjmm9SS3e3M+lgeiaw BSRAdxY0VZKYlkmFpCTrO5LvyDfm3EdRasVxsjAEUKyqW/f95O3Pj5FZDzcfFje3i0VsIrNY3URh EMYmxE/e5qEp8FbGZvF8E5r1zSwIw6g0i/oGL0liFsebr97944fYn6VB6d3+3GzX8lptzYOfB5nX yVr/Rj/IPfOx2sty8GdRMPes8XPvkx3qvtkpXNO18mYqfVma3g6KZrv/DzD/r4s/gkfgi9J5YRaf hNnMMSu8fmbwzBvt1vxy96u5W8q62rn9nnlpDrJufLA3KJXMo7Nv3i93n775PxBMJoJxTgSZ9FxI fql6ujz3ahF2488yUkIcyks41w1GCGOkaox8MkauxsizMsjyMCJzEImwIGIh0fHuX2y9H5uDNY/7 5+eqPxl/8be3bZuncTB3uKLcaSoSvhdHVjYYa4ZhbweSfSM7lZ8FkXeQhfVnkIpOn3TDtmbV7WXR +lGQekvFBKDebqvRuo2xM6MiZSdYsRKiIkjSIgGvzoyJMheXwhxjT7xW/qBZIHDOkIA/Wm+b8WQ6 2Vn5MdggCkIuAbn76RXipF7f2tF8uftomtacgXDjs2KFz/gF5P6XP4vVWjPH6YUXTF4XCqt54pPr RPx8IR/IKGT8hAIGz7mX85GAxQLwwot7KC/3FNZ8vvXngP7NfOR1xyDtyCh6iBBTkNHlLW/J00Lw 2GOn/sOebzyJE98/IjxLT3DH3/wAu8YsICGbmfDYwZqGsQxsxQGHKaleDs2zH8GBPAFZb4QTU1d7 ARTSplZGW1sLRMNiHASNXJaDEwMi4JciaSdSvRLa5PuRukSUip53tl91PXgitJUPqdraml3fPW2t 7g7m2IwbWJeNb8XXQLPMy7OvITYUcSGI2TEavwQr8IQEf8gSq6q2A9grPNOtgLHRxdIemtoGzj0U +QXr4TlkOULDK985k9eUtdhIZDT9MFIowmwRGSGGhHzSDEaDyozgMic3oENTAxRa9InldrQtBQjH qR2Pls8spTdyd1kK13EYJFGRXmgkdSxpSiN1kooRgNWaribeM9CT5cyuOm19eGe1RCA5RRFVVhMp HqcbS0r1XdqeOZLX2fs6JyE8A7PQhAG5aykOklk0XdX1nt2dTH0+1HQ0+BLWYMZO58j55yTUKMZR 3WMehAXkDl1oly6/u5JCTpqRZ0RQc7UFAbjsB/yRimLyOvvkpxqwpe71S16YL/grdK+tYL3MW5O3 ksksORtHOKP8yCgFie4J6U5IC2V5WiEikc5AwpCQE0woYZ0gMEJYRXCuq4Jf1bcrX/DsC2zcotp/ +ALTmEuXft3fF7+btFc7hTo3Hyy5bAqJYrAJZyJ3p9q4J1WQ3WBz2dnpTt2smpr9nnTDe+bB1haF kFGZx2bp3upq27Rr8817eHxEwjOvlPD/Ep0XLlk4l4wd3+QvBXmjn0tBKsQVC1QkMFe5ulRQJUUi yUk2BbDtUt4oeDujuGD5yNvuTL0fRkX1jIyIgx4I3I12InJS/8WmGU6XF3YKQz4STrvcdpXeT0aP ex+14zAhJuqm75wQPnFeS8uGu/YnErRS6kuzVLh6/wOnhKS9xMDKdtafkneuQYTWDmkD1mNTR1zM ObPy5sanQsP1iHsRuEDpOQO+2TKlZRHEP/ZL9KKJ7POSsiL093h63o3d88Ap7KHrRvSoPjVte9B0 VHKlglpVChV+IypozPJ0IhNflH/G7M9yKc8kGqg4jK43U6aF4xRFXxpuYBE3fKV5S+N5kOdT93bd IC2mDmY4IZ+EoLvTNkZbIt2FLxQUNL3V8w61Hi6hPRpORu56FF81cm61vT0Xne7cL6mFpI6g5IYX mdPZPNSCbSl/AzfSmVQlfvZTroy87zoetLwyyykDRt6RjqgB5BPqIjSBSTORKRhSClM42B6peU7J blUJ9Jafe7nTC5i0NLi8tEPAeca4CiXCvJHYoLV5nl51KWyWr14UAH2GlOsMX6rhg7BMtPe4MPfZ M4IiwkRxrsTXcfMAf+24u4GhkN2+m203SLl1ZR0ycK0FxJEaA0jXfz/X5qlVmdgv0ji7ZF8dOX4v GQpXQZPyPJQlnA17dkok03G0bpPd0SCCPFhuu5dduN/SvSKnyxtPdAT4p7/cm6dONjuHpsDzNWHL 14RN3knY6/nz8TSgsZhR5/3MPa6k/IxHFgTCWlZsQatDZ93tp6m1t8vzJHrUu83WGvui72PjkBio ISC4O+NamSLJswvm4skSyt5A7LENYlF5b3moizkr6BQfs00UgJvPv+9lv1H2cIZWHAd1d5A1DYlo SE7BRTgl8fwNC6TvYIHX2ulf0fxyAHCr3EqrrLFgNhX3we2aDQC1s95AMpvP35gQuMPQfmtjq8OJ uiEuXdSjccxVK7QCk/uBZpYnbwRb9j7Si/t9hQfIbCUj2eV8qCPjkSd684+nSuccgl7/08hyt7OV E4a+2hgZ4Vq5S1L/mXy68Nw+3V7KqUx/R/5IIHOh+WQZ2UGgoXZqS1PugmPpgmN0wf3/DlYM1++k J9fVhjpoiMJkho1YVaU+WWE5KcypK2KBU6euyKkrYnXNJZg7BmnlMlxjDlQbWdlJgSUrsFR8SzmW m1TvWH9ckBMdJLD1/WlSHgiaS4aWXBcdOvPJz1Seg+yr5hO93MrdtVXeySMCSAC/uCNpB1HJIOQt l8qSGocn9EvyiULwKpuvf5EL3efD2M1PnD7onqQPRoSeYtXwt4gX2bnlTyFoExWWk5R8fAJ/rWx2 8rFDz1DwZyz4Su8oVM13pCsXRdKavhb937WweNdaSMrQaeL3VOJ6e56X6atML/MM5GhrsO2S0vmz RejyUSZYMI/Rt6/jxrbmgSv/I6yJJw0g1g0gsPvTVlbLSXIYHbJf9Tmuxblf3PxbgAEApP0zXgoN CmVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3Jp cHRvciA0MSAwIFIvTGFzdENoYXIgMTIxL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDcyMiA3MjIg NjY3IDAgMCAwIDI3OCAwIDAgMCAwIDAgMCA2NjcgMCA3MjIgNjY3IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgNTU2IDAgMCAwIDU1NiAzMzMgMCAwIDAgMCAwIDI3OCA4ODkgNjExIDYxMSA2MTEg MCAzODkgNTU2IDMzMyA2MTEgMCAwIDAgNTU2XS9CYXNlRm9udC9BcmlhbC1Cb2xkSXRhbGljTVQv Rmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoN NDEgMCBvYmoNPDwvU3RlbVYgMTM1Ljg0L0ZvbnROYW1lL0FyaWFsLUJvbGRJdGFsaWNNVC9Gb250 U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgOTYvRGVzY2VudCAtMjExL0ZvbnRC Qm94Wy01NjAgLTM3NiAxMTU3IDEwMDBdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2Fw SGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0x NT4+DWVuZG9iag00MiAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDQz IDAgUi9MYXN0Q2hhciAxNzQvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAg MzMzIDI3OCAyNzggMCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgMjc4IDAgMCAw IDAgMCAwIDAgNjY3IDAgMCA2NjcgMCA3NzggNzIyIDI3OCAwIDY2NyAwIDAgMCAwIDY2NyAwIDcy MiA2NjcgMCA3MjIgNjY3IDAgMCA2NjcgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2 IDI3OCA1NTYgNTU2IDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2IDU1NiAwIDMzMyA1MDAgMjc4IDAg NTAwIDcyMiAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNzM3XS9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNp RW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTQzIDAgb2JqDTw8L1N0ZW1WIDg4L0ZvbnROYW1l L0FyaWFsTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMyL0Rlc2Nl bnQgLTIxMS9Gb250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1L0ZvbnRGYW1p bHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9J dGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBvYmoNPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vUGFy ZW50IDI3IDAgUi9Db250ZW50cyAzIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0v UmVzb3VyY2VzIDIgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqDTw8L0ZvbnQ8PC9UVDIg MzQgMCBSL1RUNiA0MCAwIFIvVFQ4IDQyIDAgUi9UVDEwIDE4IDAgUi9UVDExIDE1IDAgUi9UVDEz IDE2IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMzcgMCBSPj4+Pg1l bmRvYmoNMyAwIG9iag08PC9MZW5ndGggMjIyNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K aN60WNtu3MgRfddX9CMZaGjeL4sggCR7gwQQbEjzECDOA8XpmWF2TM6SHEn+jf3iPXVpziWyvUAS CBiS3dXd1XWqTlXp3V8fI7MZr26XV++Wy9xEZrm+ipKgKk2IP3mrQpNXaVDFZvnlKjSbqyAMw8os G37B6MuVZx76fjJ39WG040/GX/6b9ot1v1g2i3mnogjKUnbCDqGspgVRGIQqyW8knGdBlYYRieOs KDk79J/ecmuNn3tD76dB4vWTnwSFZ5raLz0ogt/Rj4LYM2s/83p/EWF2MJNf4bmVT2vGr7z4ix/F +N7LsOykS3RK99oP9rnlLXT6wOtldsfrZEezsmMDHYaWB59In5Uh3QYs9Fhz+7qXJbUIdSKEmXpU rWkrkdmdKvUy/iS39f+1/DvMiMEorQqzfP8fhgUSUShQiFwesdyCTJqpSROx6M+1v0iDzGt3h4E1 vPcXSVDi1AijuJGJFjKSGzn6iLNsnkRvKnGmIR2ckwCpQPDS0Y/2GbfHbYd656eeafEzjgc7+gWO Jl1e7CASZsWTDX/0bpk82HqDpS1qP8bAhDfLbytD72TS3DNbfsjHi7/AjXiW/YIW8Dl8wxjumGcV HFNVd16YieLrdmAXSb2XGkoUhMpn78MHvEXeJx/7PHy8B1iVd+1ndJVb+br77F/DH0i+8xext6Jb j9DIW5OPnm8HPQtIQGxoefLZDjz22SeNna4Lp+yJtdnILnSiUpSum8aOo8EBOTbbtONkh9G0HYxQ Qu0tgZzAST883sIlY/lkh7i5C86cLvljeKuxli1sRRZufbJYtzGtgIxI9xS6erKAqjcTwruGfoUn ytIQtGOQoNsowW+d8g2L9oJZFFRFPkN2pKtc1Djs2E8aIixjW5wEQ+ccmdifOSLBMQSTNQ7ghBGh df1AvyMOpNBYxLDYWtawhLzqBElu64732rghwUqUPLEiQ1WorrGy3OoAkDy5fSHURZFv2wExot7D HAKpJ3ltd+30lVYozNP2wlYAujZTS8HO3BfShn7o7b4af5G7kVpsmQTkNuGsYOp8qRIFu84O12qW pifTNgRbQiTMqLAtEhh2GA77qRWI4AVVFkdHjCLHCKmC1Jl+zepM2x47qfZs9IEMGXtjYFhADZog SxXY5ztkuPwTn1U6fyjULXuxz6g+xLvvngXKmExOAzptnc/SB7zj1TJFjTNHMWHp89dDy1sMduUn zDLs2CLjPCuePYuI49MDVkTeR3JGYmDm+ZpXdKKIbPUOvzEZ/VZkQCg+kbdhbyuZ7061p/1Xg6jz rGNDgMhDZJs/ENOUSCLN6UFR5SkJxzFR+furP8OW5V9EqhShIM0jxde7rAmCJMmSI/azS2ky+Lkn dkOk7MEGa37tffYgpo+SjA3cD2Pb8fCGmaGUq+aOt2CTWAZ+G9kN4feTlZ07mah3RgTJhIl3B0YG KrzXK+NZj+IZv/I5B1nVMrgREzIlE9VCgZWYv9UdFWRSmkAOzDFxoqC5sOYbbtv750bNqrL8llGj mfQWakxhktxZlQI+QhH04dPje7OXr51P+aMmckm8dT9w8KOiMTsKt5UIGeBAb0QTC8KBc8VWJlu2 kUrqGQ38CgB9sZ18T9en4uuWT3vVzdXQMqgLmn7Y90N91KB1O7GUHjNvahEFd2848RuM5cHWSDO2 HgkN59mKxeL/BYZLQUl6CkYFS6KsajedfLElD/pO6b6F42aezm4Q2sa+ygd5Ml5iNwlXZreDD69l ovWxVKUtsQkY07wI6Vsh4fKc2yNnqVi5Hawkdk8BiDwBi75o3qF07YQmnaNc5W3lHdFInJZDi4/3 hgqA0Ks3OjdeK3mrKheFy2WBCi/peqlR6ViqFSgN0t6dDKtHZORmKxVtDvL8Au5jUyAYVXzyMfJW UJ45QvI/dITYmVhzz91B0BrFdrFkX+Lm0bgpqfEoPhTuGL5AHEdsE8vAb6OiEJNr6BvxG8UFAmzb yx2jIsC9opOE7rJhrEbeSolfc1H2LB9kNI3UoZ0m28kw1yS5W0E1CdUBL52yXkjVNaW2cdsfRGa3 0pUKu2rzo4K16bupbqaL+hTn7foGl/wbiH0nTL0fuJxEFsCKqX22wRFbTV8L5LwSDe1J/jpi+19l sqiY+xot3252vrAs0xXFOpkl8jbdyKYzB67jqYFEYnG5ieDe8AS1JXLjiCty3JGATwE7T3OTRl3M DRBCEUBdBPdCKdcefNZAhTSNdK5ZAMnspaeQIi+qLpxibrZjBYDCDdXDM9V69WlySDwXhi4jJKcZ Qak64YyQzhkBjVng6uAkyLK8+lHp8VYPO9f2pHLmmLWW9vW+56J7ZU2BDurhESwRe48+fj7732he i+81MycJxWXWKL/4T0Q/SfGbc/FLsbCGUWAOlIy4f+lxFERcQ3Kfb7YKQBLkVXpsWebkHeqthhX7 gTaFiB/6f4D8hyBiV0Fi5ZHGPB1kkOu/TFynogyfaCdN/Ygs45nxXNCaBy5n/qEOxuqBrNPke/7x /p7d+Ua4RpOMQm0eHh/pwu67fpLnbvYgWoQ2zKzqqXZuUQogF41kPMOt/Em3zsWziVWoX+CRrYxY s68bqFZ5v+iATJsnnwjyIINUY1b4pcM8LhEpK3BvcUPVCq14JawKSdKYeLKWv+aT1U5ZGZ52S7mz U+TULST70JbHIsecjWuzVwrR5RL2cJFMDkF9Rt5+PGQ2SqoUTqGKiI+FvimZsBmolvgFnTfIfWP5 FghaabGsXACVbxXH38FZOIDaGIfmSMHmIr+eXDOG2qAo0x+2t3Qyq0b4cGM70WWfDus1cQqcRrvR PVral63tZmfy87n1fYInUS2XIxLb0f0LIM+QY79dgWk/9KwFEprXWkspI630Sd1k1r1WZZ0fSeXv BFu3SEzA8WNHre52umqSOq4/3cOMtkE3fLl8tqC7wXkASGYM9X9P3KoW3m7Xv4zKpx+WV78LMACF CyJ3Cg0KZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8L0xlbmd0aCAzNjcwL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGgxIDU4ODQ+PnN0cmVhbQ0KaN7kOH90VNWZ3733vXkvP0gmIYSQAHnjI4nJ 5DcI+dVkkswkwEAImYAzgDqTyYQEA4lJiGYBm8JS6SDpWD3gaqvUUhWo+hLAnXQtRKvVc1Z3PWWb 3VXaFUHkuEU5FnFVkrfffRkiuJ52z+k/e86+O9/9ft/vu9+99/0YIAAQA4PAoHCVq6D4b/90sQcl LyGs9ff3KTmvfrUbgCQBiEJb98bNnxW+eg+AKQX5+I2dA21Hdj/3MkACtx9pD/haX3tuQwAg+VXk F7ejID6PfQ8D3Ir8gvbNfffd27isEvkVAPRaZ5ffl1KRUgGQ2I0xdm723ddNmfgM+h9Ce2WLb3OA tfluA5h5Be2f7+4JdN8f/zKOH7cUgN0DRHiLhEDEXB4TF+IIGVOYHYQ2mhjLRJFQIpmoKME3rpVd W7rAdlm5rIsPTtaRhXIMeWVwWiveAUXiCkhHmMsegTQA/WwEzk969Evi3aBObtLPZMWj8fEITF0+ yIA7IRuWwytwGU6SHGiEMf1t8IOb3gt5KP8h/D2MwR/ADq1AIZVsB0X/MTwImbALDkKpkKqfgBVw UY6HZFgAZaQLTDALNsIT5AwsAyeOUQ718APowX41yj8nJaghEA13YPRH4HE4Cf8E/wFzcMR8GCcS +Vz/B6gFF+awDUbhD2KNuBdmwkPwDByGl+EDkk8OkY/Yx/oJ/U39P9ErG4pgMayHFmw/gp+i3TPw j1RlP9NT9W36s/obMBezP4qzfhlew1hXiULWEj99mg1Mfqlv0Y9iHWIxZ8weWzXOpgH64OdoOQ5f kShsO6lCq6h/MkGfDRKkgwJWzG8NbIb7YQ/sw1k8Bk/CC3CRVJF28hb5mM6gg/SU2Cg1SA1RpyZ+ p9frVzFGLFgw29vhbrgPPX8ED8N+9PwpxnoV22WYIItJOakky0gT+SH5Pvk5+S9qpe/Sr1gci2e5 zMO8bDt7n30hixOrJg9Mvq036vdhLQnWPBpXshbn2QwboBt64V7YjqdkDwxhC2H1jmLTsJ6nsP0a fg/nsF2Ai/BH3HMizjGa5GArxFZObGQ5WUPuIhtJLzlAXiRhcpK8Rj4iV+giupiW0lW0iW6k3bSP hqhGh+kpep7+CbMsYw7Wy77LjrJX2Bvst+wdAYTlgk/oELYKjwia8DvhsnBFmBRBVLHliz7x4MRT k87J9XqmXq636Pv0ELaLWOP5OJtMyML5NOKq+qENd043tnuwDWDtduOM9sMTWDtevRchjHeAMdzD r8Fv4G14B+f3e3gfPocvsDh8frOIheSRIqzvd0g9tnW4Tv1kOxkkQ+QxrPMwOYFtjJzBWU7iDNdS D72T9tPtdB89QB+no3SMjuNK6MyEK5HC6pmT3c7WsztZH9vPHmV/x55gT7IwG2O/EahQJjQKPcIu ISQ8JbwgvC6cFs6IhWK5GMSmiSfEX4kXTImmNNMik8sUlkzygPyhPAnH4HUYhhPfPPtkDzGTYXiO fMgENkjfpG4aQ8fJTuGfSRauQAUBcQi2wKeY4TzyW7qE3M78ZB3WbydpI+vhJ2wue4othzfFLcTF GkkruIQDcE38NfjEIB1hVAyyCfIFPQrtMETvnjise0gcuMgh+jTumB1QAdlCKozTUmGUZNBsekp6 noShUjKxUlYmxyN3iJ3DNF1yPPkIfOx9PD9n8Ww10afxnnCBnJFWYXYT7AW02QGV5NBkAhwWPdRL 5tJDZMXErol/Y4/rT5I59H2AiYSJalqLO26NfoSehE/gwOQXwntwkr4La/Cu4TdOzqd49u7FO81a uEZn4Hly4X2k21ZVVfmdivKy0pIlty1aWFxUWJCfl2vNyb41KzNjgXqLRUmfP29uWuqclNnJs5Jm JiaY4+NmxMZER8mSSRQYJZDrUOu8ipbp1YRMdenSPM6rPhT4bhB4NQVFdTfbaIrXMFNutrShZds3 LG1TlrZpS2JWKqAiL1dxqIr2ll1VwmTdajfS++yqR9EuGfRKgxYyDWYGMhYLeiiOlHa7ohGv4tDq +tuDDq8dxxuOia5VawPRebkwHB2DZAxS2my1e5jMriQGQWc7yoYpyDMwKy1VtTu0Oaqdp6CxDIev VWtc7XbY0ywWT16uRmr9aosGao0WbzVMoNYIo5lqNckIo3Tw6cBeZTh3LPhg2AwtXmtsq9rq2+DW mM/DYyRYMa5dm/0351O+ZnHwxFr3Azdq01jQkdKhcDYYfEDRDq5236i18N7jwTHQl2bUeYN1GPpB rKLTpWA0utvj1shuDKnwmfBZTc0voDq4xLtJ0aLUGrU9uMmLa5Ma1KBpwDKSmmob1d+DVIcSbHar Fq0qTfX47HOHkyDYNHBsjk2Zc7MmL3fYnDBV2OG4+AgRO+NGIjCtMyjDnFPOpunKEp6Rugx3hKb4 FczEreKcSngXKIGgvwTN8PIQ9NJacUU6tKhab9BcxuXcXxMzzKoS/AxwB6iX/nizxBeRmDLMnwEn +T6Z3muov05rVquWk8O3iFSLa4o5Vhr8bXm5/WFarXabFURYPmjE2vo8ZQVYfouFL/DesA1akNEG V7uneAVa0kbAVmD1aNTLNWPXNbPWcM3gdc20u1fFnXwc+DvdLE3OnP7Fm5NnOtrLNJL8Z9SBKb3T pTpXr3MrjqA3Ultn803clL5kWhehtJm1bpZGIxRNY4YWN+WGaWPOuGM1IQN/JmNTt4YlGXelISFK nWb2Lp3qPdEWy//SKaxf5l4G+totkqZWZr2ZL7+Jvym92CDDhIVM6mxeFwxG36gDXjQ5ZhLfXeW1 k0ev5ct9RhlvvE4Kb+FTlV9f4tsqInoEzovHwScAZAitsNp0BOpNpbCU7YIy1DUj5KHuIdRloP2W CH6Iluo6ypcjXEbIRXAhKAgtCB6EFQjbEVbTUvgFwl70reD+HLN94Oa0+DokiWvhFsSJwgeQKpyD LFMaLBVOg4qyTIy/UIyFBqQzxB2QJM3jPvpF5FeYMtDmY8yhFzKFl6AEfcvF3ZCMudejrkTMhhrT Box3DpJxnGdMH5JNiJeLdpSB/okA7B0cuxnzGECoY1fAgb7LBCvUs+U4v9OQR5+CWsQO1M9CKBJ+ jHOywq1I8/yXIO1B3IE2DehrRX091rMac21kn8J6xAU47nr2r3CaPAaHEI+j/SLhKswkXxpxKwiu FvosxlqByQSjJhMpRPw5wlV5LWRLH4ATx7/jOmYLoY3XDp/wHZGaDqB/G8apZs/DpkiNOSzgsWSA C8JpWiqDvg/nrpj245rvgDyszZ3SB2Qn1qrBgP3gQ7ySA45XgrAEoTwCZeJxEo0Qg3oX8stNTeDn IKVDMfrmY6xmvjdQV4h5GhDJf0UkfwNjngVY1+rr/qblkIM+VpYIrhsApuEKvm9cwe8cA5ND6LMV /StpEX4H7aBPTwHUskT9YZZI75jCoCL9PQOjLzkEc6tnQSLNwpZJM6GLJOPpuMvoVxl9ldEX8J4W jBSkp4dp/shBjnJH5mUjWmCLOZuaXpSVmF6RxfnZtvLO7PT3jsxJP4twNKs4fU9FcfouhAKEfuS5 XdaR7PSurK7NXd/vekBYAsnJuMqJCbItTM69uCYpKilqSShMTtlKpdCvpNAxKbRRCrVKodulUJ0U WiyF8qWQVQplSKEFUpKcKJvlODlWjpZl2SQLMpVBTgrr79ms/PAnmcwcmQTeCwZtprznBx3vBJTI FL/utJnMSZ2uGq3E6gxLepO2xOrUpMb17mFChjwo1eieMIFmd5joXLQ7jT+1R4EQffe+tAj2eIhT G/ODs0XRrrrUMInGG5Wo1hAt0QnO5poUSO6vSqlKrEworbN/S+eN9NavrxTrjZezceAlSCdb+ccX 6TsmpT8scakLpSFDGuLSkCFNmaftd7rc2pF5Hq2YE/o8DzlWfcK2jb8HeFVHAMGr7e1vT9EGWxRl 2HYi8oKQ6W3xt3PsC2gn1IBds6l2Zbh627eot3F1tWofhm2OZvfwNlvAPlJtq3aoPrtnFBpIy3DO 0E3hfnA93CjkkJb/OWKYtPAhc3jEhqFviTjE1Q084hCPOMQjNtgajIiODlcNcTa6h2Wo8eDDx8DH aEw0LpU3zeKpSTZ3VxrrVm5JuT/tlwKQZyEGn8Wx+F43A4Gr8qrzqrkKNwxXxfFXvogq5f5yS9ov ybMRlRnFCWoNWLdav3H18gtSHB12DpjJqD5GB0cS04utHv6cofwRJPI/QBguWrltvknyo0wU/Ayi TaKfMZoaJQl+AnPk7JIUa4P5SsXKiYoG89WKleaJCqiqmKjgUFRoSbAkZGCHexuuKWzsmk2Er/CJ M2Y85U7Td/HeFwOWUWDkuC0uSoLUGaY5sTM+sfBhrQ3nzRegauWlokKSZFJvybxt0eKFxcn03fED j46PP3pgnFZP4XHj6Vj8/6x5/o81fkXjN//195fvTt3BgO+ieOSmaAHpoQhtQvonqAUhCrlJ+EWE JjCfHInQFOLIGxGaoXw8QgtIX4nQJphPE5sHugNtPn9AOaw0twcU/ldcH4qU2q6e7q4eX19H1xal u9Ofr9h9fb6/YFTAB1NcXZ1buaRXWbYF/YpKSwvzsCvOV6o7O5Wmjo3tfb1KU6A30NMfaK13LG20 L7O6Bja3dHWubP7zLDTDAHRDANrwm9iPWIHDCM34bc/pldCF3+Jd0BexUqAWuR6kee9DeYdhoaCk E/3zkbIbct9fOVLBdGYKfq93oWzrtE0vypYhnopXBKXYCiEvQhUb0mr06ETchD4bMYc+w6sJx+tF 6IF+7FuhHhywFBox52XGP3QDsBlajGgrMT633ohxOzG/nr9g+9dop3bnGMYSjd1IwYzztyF1SYyf +kuHSwfh37elSnfFV3wmz5MN8c+WvlTO8ciKfzmr65OV8odyjPFvd2Tn/7cAAwBSGX1vCg0KZW5k c3RyZWFtDWVuZG9iag01IDAgb2JqDTw8L1N0ZW1WIDAvRm9udE5hbWUvR0VIUERJK1N5bWJvbE1U L0ZvbnRTdHJldGNoL05vcm1hbC9Gb250RmlsZTIgNCAwIFIvRm9udFdlaWdodCA0MDAvRmxhZ3Mg NC9EZXNjZW50IC0yMTkvRm9udEJCb3hbMCAtMjIwIDExMTMgMTAwNV0vQXNjZW50IDEwMDUvRm9u dEZhbWlseShTeW1ib2wpL0NhcEhlaWdodCAwL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5n bGUgMD4+DWVuZG9iag02IDAgb2JqDTw8L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlw dG9yIDUgMCBSL0Jhc2VGb250L0dFSFBESStTeW1ib2xNVC9XWzEyMFs0NjBdXS9DSURUb0dJRE1h cC9JZGVudGl0eS9DSURTeXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5 KS9SZWdpc3RyeShBZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag03IDAgb2JqDTw8 L0xlbmd0aCAyMTgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCmjeVFCxTsQwDN3zFR45MSSN kGCouhxLBw5EC3sucUsk6kRuOvTvSUp7iMG2/Oyn92x5bp9b8gnkGwfbYYLBk2Ocw8IW4YqjJ6g0 OG/T3m3ZTiaCzORunRNOLQ0B6lrI9zycE69w1/dVda9OIF/ZIXsaM/SgPz4z0i0xfuOElEBB04DD Qcjzi4kXMyHIX+Yf2q8RQW99tasHh3M0FtnQiFAr9fjUHAXJ/Z8frOtgvwyLY1srrRuRt3e88MpV NyN2Yc4et9M3I8WCJ7x9J4ZY1EqIHwEGAIAKauoKDQplbmRzdHJlYW0NZW5kb2JqDTggMCBvYmoN PDwvU3RlbVYgNDIvRm9udE5hbWUvQ291cmllck5ld1BTTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0Zv bnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTMwMC9Gb250QkJveFstMjEgLTY4MCA2Mzgg MTAyMV0vQXNjZW50IDgzMi9Gb250RmFtaWx5KENvdXJpZXIgTmV3KS9DYXBIZWlnaHQgNTc4L1hI ZWlnaHQgLTU3OC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNOSAw IG9iag08PC9Dcm9wQm94WzAgMCA2MTIgNzkyXS9QYXJlbnQgMjcgMCBSL0NvbnRlbnRzIDExIDAg Ui9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDEwIDAgUi9UeXBlL1Bh Z2U+Pg1lbmRvYmoNMTAgMCBvYmoNPDwvQ29sb3JTcGFjZTw8L0NzNiAyMSAwIFI+Pi9Gb250PDwv VFQyIDM0IDAgUi9UVDQgMzUgMCBSL1RUNiA0MCAwIFIvVFQxMCAxOCAwIFIvVFQxNSAyNCAwIFIv VFQxNyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAgUj4+ Pj4NZW5kb2JqDTExIDAgb2JqDTw8L0xlbmd0aCAzNjgxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpo3tRa3W/bOBJ/z1/BR+lQKxI/9LHAPrRpurd3bTdIssUCxT0otpz41rF8kpy0//3NBylR tpTsAXvAHQzIooYzJIe/meGMdP7TTSLu27N3t2fnt7daJOJ2fZakUSxFDD++K2KRFiqKU3H7eBaL +7NFFMexEbdLaN0+nwXXVVtvD92m3onw9p8oSVpJcS8pdpKyLNIsCPgDYojFIokSrTJx+/4MZCcZ 0mgUiQN8Da5DHVShjHQAI4U6SoJDCDwq6KixoWsN1yzYCW7tqPVE15o7M+cTN6o2zKI0ECvbA6/P 4QIlbEOYLsgrwxxGXPny7plZlGJJRCv5MUwU9Lnjls9QjmYICkqDeh0aYBW7ikQ847NVQ882oxk2 7ZswjWQg1vy8scM8lw2zvhElj7I69zTQwCpgYZewvjy4DBO4Xl3DkoJfPgEdKCzNCivvqzYSQoT/ uP2b24mCdiIedpi26fYvuDmxcpujc96c24dKrOvttg4VzPp5s6N/0JSEyYiuvNtWIlykwZ6ew+xk wF2fuMtmVYVZ0Ia40pJ6NtUaHzV42dHEEhMpWShAkoXIAL+vwbISJe4m6LQDwQXviglQsc8PJT+j DZOOBIuX8HDPLdSbgZGoUe2YwUrcVRUxrqzMLizGI9wRM6IT5n+gxn5lB7Ws2G3NgzSipGdiz/8N d9zQdUlCDltqlI1dzXeWybIEi1nDHucBb9rCKefIilBDX4P9tuxwbEIPWlA0t9WBs94kZvOlLjJV BrvQjpNMuDEpa/4qXGgwK+gGSA8XGeCpg5lpnF/K5pERcMXt9z2iIDEp6v1XJBtUv4ZlrAZWZEJV pqhvpIl3ny64M0+7iGJlCn+p5CeyAasfNs0jWgitRkaJAncyvVQTFSZPBOi8UNpqjf0aqw9X+Ot+ BZaZ4+okTKIDSOIuXF6CSaEV/QLLTYJPuMM/P5awX4aRD4iwNmVnejRjqe04quCBbr7wgv8O8zGw ywv0Bw2MAd7mp6Yq+UGHnTJQEam8cUOoKEVzHO0/+msaIS78pRS8FM1LUQDOj5vdgQjfcBXvm81T 1bBcGCqTxp/6sU+4vD3LQQ1SpBArABWg0aIoYCLguZvqbO1RUyky8GbYJ40dOUnjSOUDd4qKH7iT FByhduw5zCMfsUsNypofXGoV6dyxwxqiWI/4VZ6O+Iky8Ks88/lVEekxv5FpVMzze2Tgt2Sfn7Vj col/dvpK4yi+dno6acej2+XP8tvl+fzSp9v5zdL5WDAfzE2WID9EczJC63Eur27en3+6uAJMyeD9 hLdB+KcuimTW0O4g3BYUH1JEJXkRcWg3ITpmAw7hfiRpsKTEOSVpnRIEoAWaZlc19q7cohuxthJH ucqVZ/Vkjso7zhCyPZd64jhAhikk21txNBGMK4m0ofHztbjmYXtDMYjiCTsxUZwzMRUZOHTukh4B gXmnrcQyOysZuHuYTI5sjcRy90YysPco6gefsBHH7mxkYO9BNslulaLBQjwAm/GyLdXB34yXNc3r Zj3wSo/qJjVNBdxPoV2lfHSlzVYOdXarfyasqR51qkfdwsSJRFQtEoigBRjFDd4rABj0OsGHNpHJ ZwEC1FQ7gJz40Z55BiHMPetH58Z2EGH2eT/qDz+FEcs/60fn+K1mlPbcXJJE+sg6HJ0XP9Dd6ub4 3ew9funT3ezm6DNwkcpzjqBwG+8V4+XyG8d7h5e8xwuc0OFBLmP0gAiaLI7B/10LQk2MYk9Ro9QL XgWJ6TxoLO8MZph5HjPTIzvIMPcLkBkGn0KMZZ9HzDS7VYpMEG/zgHH0OcDM8bu5e/yTgJmjzwAG ewwO5jisfa6tO8mkzOg8jNAwmA286E8AR6mchQZS8/mA45hnsMHc8xFnZmwHDmZ/IeR4w0+hw/LP x5wZfquZGA72w6kRDrtHi3d0XvxAd6ub43ez9/ilT3ezm6NPw0MX4D1TB4+T/OFa/Ciuq38dOE/Y NNWK76bPX1hY4TRH9SeVH9H1fK47yDPBBYEsyGYkFlokOCcQCAezAg9mss88T89ifeXGhcUbSuh/ FH/lk9gmxCLKA2cx2+9EbA/39zatabtq9UbccevAfx2yiF1tW2Jn+y6rti0bTEC/h1STOcJ9DD5V z+IeqIXQOuE+p37FcU8iR6cFAsSdOUxv2COyBpj0nXzhPTsfO8yx3xjTfQF8IE/tgRwCQc4YoTvE iIaDB0LEz2RjciBwQOmqrcDDubiimkDz2P7wesFOg1dxpb+TetBkZPtQczzbbuvnze7e5vHltq3F phWl2G7aTtRr0T0wqaLkeefCoZ2jrQ1sQwAjVTCo2TxCkgCQwcqXqxB0AMw06IVtbddl2W3s7Y6G G3dbWdqzHdixlU7slvpPCLN0quk03irehVim+ARgTIKLCbP7iqUJNgNexTM2JObjyGJJFbe89WFS zj0bZ0Q4syc7rn2IRbwPtW1QmbGf2Ug+7EF7sIQW+43HBWRUvWLrSQ23tGFH+8NC3C75q4S98vtW JfMvx+rsSM6yE9/rg5tpafn2je27B916WqCRK+FDZ8YtOWcprbNkDehgv6/5BmQq8jUw7LLe8UNs wZRswSyxhkFWoSDmST1lFV79bMKaVJpHWe/DZe8t3aEQkI9jg/8FG0UHLgPCPt40jzyRFGMfSqWb xORRnguVgbM+mk9ic9XRJJKUkv1+IrZAtMQ6VaZtvV1cNfWKas8H2JIwSTLcyc/lI9XMK9iGNHDV LS1N8lLZOAd/q45z5dg5DbdyV7U7f99saJAn3BGEt8BCgkIrwfby9/K+mtKDysCXy0k9yCk9qMwM SvCLWSoFGnhfnWPYt3/Ou1uihiOLzEdEA4eyxGPVU6xwWoMjiiVIOvbwiSOLMfoPdJ8I+p0numE9 ydqnv1bCUdr0EYM9OcRsE6I9xTH/XYVYnL35OGNcXMpBrhhxmgLfb3ATfPmM1wk/uOjfIiAP9EbR BJRUglLHhZnYHYMTewy+6cpGfCzJI/1eCb7ZITgSLLSfTLHP1e3Lgi/gMA29nFFBvcO6exaUzJe5 eEo30uCbKqWzSBKgzi/aVCxbVp9olzuvyP7Qdfsfzs+fn5+jDYbZaIk1a0WvCWJ+PwRn1OAcXVZ7 AK/TdOfYo0BKQu8TbB1XJ8oMbzkyFt89VM1dXTar9rytmqeqOW9BcWAWJoj37fbcnXzclOm1XQLn RQMoVMPhBsAwXqM2Mir8ReLrPa/QNVgE4Et7uM8K4PaRDesreoPwKjgW2D3Zr99YXE/RHKw9sfrV Ao1CXUsHZtp0GWV9Me4mo00nWMPfhwsKT5pL6b9eUwtCKFG/Lfn/ianVCwBJpI0E8wCx0PsTUEKH bwjshBaIgoU5RcsJVjKHlfVSH5pjtIBkdBkxJdJqdNY8AgukRcZb7xFWFhIOspDDkvHB+RlndYwi WJ+Zcp6WHCd4NreEJIfQMkZRT/eJDkaTRIcjT7L26dNAkgWGNQsk2TtFg9gx7BBV8PbjdGrFXtQ5 uedTf0rX395+pPez7s2rdX7jJM17x/52u6y3B1LnFArBZUJCjmj7rzsqC0FwoxaERZbpAYQ2Gky6 Kw3uqtyeb3ar6lv00PHQj2M8ygLOJ/Ancyq2vei9IJeDPNtf+wkm88jkqXkJk1hcm3dsMsvo1c5c yB7oEyF7mmgx6Us+DtlTmExhzTGvsscGJMJx5gKj0XF8Qy8rP4ibh3q93vHLygZ9mEvZJ8ED+WYu XwPPn+7E5hBkphDEq/swwo4+wU6KZkTYSV/xZXk6WvYEblKdpi/gBrcvzuedmYRzeZrOO7OBPuHM pokOOJ7kP+LMdNG/oSNfBsdoKRMHGnj6BVGTBG9xYyAE3pT7CnL3F/Bi4qj438HLKx7nqS171Bzj RRdRxnjBw7NK59HCWzqsewowhf3SYAYwsG3JC0coqQrc+nnA9PQpwEwSHWA8yX8EMCqOksHTcDxT 1lTm4tkX+ujogr6J+BjivglulCF+DIGfXkl75ScP5e4FhCkJk/m/QdjytZgGGs2lF9NeCWje6v/z gIa7LX3HNAKZjKnmPAuynj4FskmiA5kn+RhkWBMxnIKOk3ZEW2IgiPFig+S1eqTGMSTsmrQsQzJp oYqI+HRx9V7sbZET9zgJWtE9lJ04tBXcVOLy5p0Un95eiE2Y07d6C/wgDUn8wH4AA2tKjMkYCZPp 6KpqN/c7KqThN0dU5SzX62rZVZSZrjgzpQ/FvqP8lp+L5YNNXe/5QRvxmz8cdlZfOpMU4DydHZdb FqaAk0RKny5kaW4GhAxqpSNrlmU5EaWYqo+wqpM8t5lhn1KhGoxV9EfOn3cHTprOqfWhqap3lE3d vBerZgO3WZ9INT8cr7DgfD+eqh0NU4acw0913DagBdhvEPk4veP/56rt6GMs/rhyQ/c0B/woL+Ma JRYTaeOeSu6wpWtJn0zecYNqlfWOXJloa/72tFmyjDW3G/KA91Z6RF+r7Co7/pqINRO5p2DSg2Wg LzVlcBOCL3kHFB1IEvtG8CgJ94vpobtaVpgc+KIWdWzcIHay9ttA3Ex9VBCRfYqS2RQljiinMfyX 858UdRPyp3eLFJRjyHnj1Du6r+i+4c5/4ANS3PSMt9N+S2pzq891x2+XTsABuWZmPE/sXlu51AqC DM7hQIGlafjbzZR3dUcPV7ADiMUDn4KZbhv4gSlGqpb593yF+MC1gDX1rW1fwU8fuDnsGvKAM+lx RjuCzYewr+7nAXmIu6riSYnHARU59KdprOyADdXb6scBK96o3DUhKRSA4c/OzEo74uAVVpbD8tmn DBGr4zFE3JfXK7ZwsqYsaLh1d+Amt7hSsiM922+tM1oErNM5COpyYNK3yO2yte08yk2spj3AENZk zC/VpsIavgJW/Sk8TyZo9m3cacXW59U97yTR5/63AAMAoZRHQQoNCmVuZHN0cmVhbQ1lbmRvYmoN MTIgMCBvYmoNPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vUGFyZW50IDI3IDAgUi9Db250ZW50cyAx NCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAxMyAwIFIvVHlw ZS9QYWdlPj4NZW5kb2JqDTEzIDAgb2JqDTw8L0NvbG9yU3BhY2U8PC9DczYgMjEgMCBSPj4vRm9u dDw8L1RUMiAzNCAwIFIvVFQ0IDM1IDAgUi9UVDYgNDAgMCBSL1RUOCA0MiAwIFIvVFQxNSAyNCAw IFIvVFQxNyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM3IDAg Uj4+Pj4NZW5kb2JqDTE0IDAgb2JqDTw8L0xlbmd0aCAxODc4L0ZpbHRlci9GbGF0ZURlY29kZT4+ c3RyZWFtDQpo3oxX227jyBF991fUYxOIKN4vfrSt2TgTZwZrZYDFbB5oqSUxkUiFTdmzP7KfkW/M qaqmrPHA2IVh9rWqTtdd858eY9q6q5vl1Xy5zCim5eYqTsO6ogh/OqsjKqMirBNaHq4i2l6FURRl tFzxJKfly5X5tHigz/tm3PTDwQXLfzO3QrmVYVxFKZgt70AMokgoyN96lRklk0zMILMo67DMWOaM BcZMa+6G9tkO7noiTzx5dCaPJvIiCytFzIRCENEsDuOsLhkMmMYpnzH7vGJUX83f2yANS9OdgixM zbe5rD4M1t4EdViYx6DA9y5gNobWQ4vd0jzzujR2uA7+tfwbw4pzxVWHSYU3vPd4jz5MchBE34Hi JyeKaRmUwLLzQigoTGdfbFAZNwo8WgvYAReMwp8A4Y7sUoOZ32z0yl6+TZCYJ50K474TVuR6GU+v jFd2E+SmH/DZ2jDIw8p0XopHIedKQLq1e4VBi0fVYKJ7fyHejeV6FOkgCJ4FtFOQyq4jUeusDvO0 qt+YMKkmE5apqisKRV+5DpUOCQF6EeZQ/azA4/MwweNTbIwytzIf9LLK886Slu8YLy7Vem+dis22 Ao5/9KOFyNr84BVJmJR59mrweDJ4pi+gW6DJRPuxGQbbjYKO1dN0srmGtqEOXIHs2ui5XwwWj4DG ndIf9dsPo1CAkO/2/i7p7k6XlhagjeHmTHOTsER2cqZA2PFyJ0eN3ne882StgqIDhnJi/aww1jR6 gXIF93V9lmhjOYn0G3nwaxXqFJ6H8HRS2vaCYxfSpN73U0leQ+UFJ4Nz6mKPKbzHLBaff/4UZOaB 7g/N1rozx/ezS17CURLPMZ6SIScpZnh/COIEzxBmjNYHS2GIM0hpviBWPoq7J3hFZsJcBmrWMuoX cccack6dUvk4d7Ki9sHuZQMhDDWMMrcyX4tRKzUERDo7wZHj406494MlpWrl9gHAKuPBbqkRIS9e iH45jYCBC2LG45l6KeCG3IBTv34SISddOBUk/iMezE+Uk71HoCrig63koY3wogdJAJxvzf2tppnL 2NSYY1MiGNUEqU+a4wBBM/ZH16zGtp8WLLYyIS13utE6EvM/sNiT7h3lgWtdsKub0VLb0arXrYNk /SfPwHNuXoWI5tpxJ1CTRNPWFO3RFO3xFO0jtCoBkUhAMA6n2XhDTUen47oZ7drHIofhqhFbdaJP uz/SStYn5eCUXw/7xBhtMOMEN/BhYrxvzyZUFymOIeXnNPcVINgstZgFSZ8TNhh8YwXm4m+1+Buz ZgGdHjR7OWFoN2LVB7HqrTovFAtnJ+KSVmgOAEIJigpBwf7+US3/LFITvRGCW65TUYMCcwpCinDt k0Nt9KwX8o5Vxag7TVQy50KFoVd+J70o37UXcfluUuR3guqemlGEXftH/uCLF80G8kfluwDJHbXk jRQa47Qxv3UFrRyFeRTXBY79xK067XdqrSK7cTxez+fBjF3uBWqr8WX3xDeDDkM9adnKGTBLOUDU yhKHKWCv+sN8tZ7btXX+3lYdtZvv2yd4BnNthNQvfuPYzowXq0fu0M/0tGvm1rv6dp5mOqtKHeNc x3A3HkQ/i+WVPDwK0WQleRUWBeEfoUqDvdpw7zkpKM3k9KwkbjYvNDpLKu4IWd15mrK637aR3hZT byC5wNz1q9MBRZTu765n31sGbpemvjmdnbuJqa39agAI/QLUXCI03haamae+wMMxVF3E0LId9zZg O10H7FqziUU1dQJlUpSv8uM3Wey+gy3/R1WSF+niZl6xaitEBeewXBdFtmCrpOaGfmq3zVM70mLc WRgSGcKO9Pmvv9Dv9M+x3bejJiSk1FeJUe5FJqWK/A2xiCB57DcjwqFgP8ulcqTqHLlEfSodXUKP zeHIzjZtfmlk1Qbc5CFvsb+hq6SPgPWrefzy8ddgykAlSinefqG92WUzlEpxNr/Tz/Y5JKSrP275 M/xiyF97/ot27YfG/23F/tBr9UIq5RL3fd3qfanDDw9fMnd63vi6Nlih+u9JC5my0mJ8ZshZ8A0/ qTxS1T5xkdFiR+1l87C2UxFJIkkTU47x2ZqxI6grjunOQW6N1hq57ri3DYrISroNpDp00SPqID20 /7FqAGitLKvs/br0iBKqpWTES8SKYIxfeKTlx7nWjU23ktKoNkXc1lV1WVRm54bYF2nmvBosPANN BvxUqlTCNeG9bPpnfy9mMZJHcv69eP5p5y1883BLH9rhIF3jSzPY6z/R5mVR6nleBOeUHG5PblRT ZuIaLxLo6K5M742YsR2mG0hAeG87EGqT0bsdbbh4odXzlxgX6pO20Rm35ztuiKe2J0Hcp9Vl9E6/ FWP/+1WCkp/qdv1pL6635iKQGvEFQFM/GOVop0cMCqaVZMO+zPeOg3X8w6OSbh8bI1qPKXQ9jDd2 Pocut9oMhn2l7TbSNcXyxgjSuFHSnU4HiNxzh+NXo7S7/bTa6aSVfnTTftNlyO1M4dWCCvN/AQYA 5SrYdwoNCmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNPDwvU3VidHlwZS9UeXBlMC9EZXNjZW5k YW50Rm9udHNbNiAwIFJdL0Jhc2VGb250L0dFSFBESStTeW1ib2xNVC9Ub1VuaWNvZGUgNyAwIFIv RW5jb2RpbmcvSWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTYgMCBvYmoNPDwvU3VidHlw ZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA4IDAgUi9MYXN0Q2hhciAxMTEvV2lkdGhzWzYwMF0v QmFzZUZvbnQvQ291cmllck5ld1BTTVQvRmlyc3RDaGFyIDExMS9FbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTE3IDAgb2JqDTw8L1N0ZW1WIDEzNi9Gb250TmFtZS9U aW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9G bGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50 IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01 NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTE4IDAgb2JqDTw8 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTcgMCBSL0xhc3RDaGFyIDEyMS9XaWR0 aHNbMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMgMjUwIDI3OCAwIDUwMCA1MDAg MCAwIDUwMCA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDcyMiA3MjIgNjY3IDYxMSA3 NzggMCAzODkgMCA3NzggNjY3IDk0NCA3MjIgNzc4IDYxMSAwIDcyMiA1NTYgNjY3IDcyMiA3MjIg MCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCA0NDQgNTU2IDQ0NCAzMzMgNTAwIDAgMjc4IDAgNTU2 IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwXS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5B bnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTE5IDAgb2JqDTw8L1N0ZW1WIDcxLjc0Mi9G b250TmFtZS9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRX ZWlnaHQgNDAwL0ZsYWdzIDk4L0Rlc2NlbnQgLTIxNi9Gb250QkJveFstNDk4IC0zMDcgMTEyMCAx MDIzXS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2 L1hIZWlnaHQgLTU0Ni9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9i ag0yMCAwIG9iag08PC9TdGVtViAxMTYuODY3L0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QUy1Cb2xk SXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDk4L0Rlc2Nl bnQgLTIxNi9Gb250QkJveFstNTQ3IC0zMDcgMTIwNiAxMDMyXS9Bc2NlbnQgODkxL0ZvbnRGYW1p bHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTUzMS9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9iag0yMSAwIG9iag1bL0lDQ0Jhc2VkIDIy IDAgUl0NZW5kb2JqDTIyIDAgb2JqDTw8L0xlbmd0aCAyNTk4L0ZpbHRlci9GbGF0ZURlY29kZS9O IDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQpo3pyWd1RU1xaHz713eqHNMNIZepMuMID0 LiAdBFEYZgYYygDDDE1siKhARBERAUWQoIABo6FIrIhiISioYA9IEFBiMIqoqGRG1kp8eXnv5eX3 x73f2mfvc/fZe5+1LgAkTx8uLwWWAiCZJ+AHejjTV4VH0LH9AAZ4gAGmADBZ6am+Qe7BQCQvNxd6 usgJ/IveDAFI/L5l6OlPp4P/T9KsVL4AAMhfxOZsTjpLxPkiTsoUpIrtMyKmxiSKGUaJmS9KUMRy Yo5b5KWffRbZUczsZB5bxOKcU9nJbDH3iHh7hpAjYsRHxAUZXE6miG+LWDNJmMwV8VtxbDKHmQ4A iiS2CziseBGbiJjEDw50EfFyAHCkuC845gsWcLIE4kO5pKRm87lx8QK6LkuPbmptzaB7cjKTOAKB oT+Tlcjks+kuKcmpTF42AItn/iwZcW3poiJbmlpbWhqaGZl+Uaj/uvg3Je7tIr0K+NwziNb3h+2v /FLqAGDMimqz6w9bzH4AOrYCIHf/D5vmIQAkRX1rv/HFeWjieYkXCFJtjI0zMzONuByWkbigv+t/ OvwNffE9I/F2v5eH7sqJZQqTBHRx3VgpSSlCPj09lcni0A3/PMT/OPCv81gayInl8Dk8UUSoaMq4 vDhRu3lsroCbwqNzef+pif8w7E9anGuRKPWfADXKCEjdoALk5z6AohABEnlQ3PXf++aDDwXimxem OrE4958F/fuucIn4kc6N+xznEhhMZwn5GYtr4msJ0IAAJAEVyAMVoAF0gSEwA1bAFjgCN7AC+IFg EA7WAhaIB8mADzJBLtgMCkAR2AX2gkpQA+pBI2gBJ0AHOA0ugMvgOrgJ7oAHYASMg+dgBrwB8xAE YSEyRIHkIVVICzKAzCAGZA+5QT5QIBQORUNxEA8SQrnQFqgIKoUqoVqoEfoWOgVdgK5CA9A9aBSa gn6F3sMITIKpsDKsDRvDDNgJ9oaD4TVwHJwG58D58E64Aq6Dj8Ht8AX4OnwHHoGfw7MIQIgIDVFD DBEG4oL4IRFILMJHNiCFSDlSh7QgXUgvcgsZQaaRdygMioKiowxRtihPVAiKhUpDbUAVoypRR1Ht qB7ULdQoagb1CU1GK6EN0DZoL/QqdBw6E12ALkc3oNvQl9B30OPoNxgMhobRwVhhPDHhmATMOkwx 5gCmFXMeM4AZw8xisVh5rAHWDuuHZWIF2ALsfuwx7DnsIHYc+xZHxKnizHDuuAgcD5eHK8c14c7i BnETuHm8FF4Lb4P3w7Px2fgSfD2+C38DP46fJ0gTdAh2hGBCAmEzoYLQQrhEeEh4RSQS1YnWxAAi l7iJWEE8TrxCHCW+I8mQ9EkupEiSkLSTdIR0nnSP9IpMJmuTHckRZAF5J7mRfJH8mPxWgiJhJOEl wZbYKFEl0S4xKPFCEi+pJekkuVYyR7Jc8qTkDclpKbyUtpSLFFNqg1SV1CmpYalZaYq0qbSfdLJ0 sXST9FXpSRmsjLaMmwxbJl/msMxFmTEKQtGguFBYlC2UesolyjgVQ9WhelETqEXUb6j91BlZGdll sqGyWbJVsmdkR2gITZvmRUuildBO0IZo75coL3FawlmyY0nLksElc3KKco5yHLlCuVa5O3Lv5eny bvKJ8rvlO+QfKaAU9BUCFDIVDipcUphWpCraKrIUCxVPKN5XgpX0lQKV1ikdVupTmlVWUfZQTlXe r3xReVqFpuKokqBSpnJWZUqVomqvylUtUz2n+owuS3eiJ9Er6D30GTUlNU81oVqtWr/avLqOeoh6 nnqr+iMNggZDI1ajTKNbY0ZTVdNXM1ezWfO+Fl6LoRWvtU+rV2tOW0c7THubdof2pI6cjpdOjk6z zkNdsq6Dbppune5tPYweQy9R74DeTX1Y30I/Xr9K/4YBbGBpwDU4YDCwFL3Ueilvad3SYUOSoZNh hmGz4agRzcjHKM+ow+iFsaZxhPFu417jTyYWJkkm9SYPTGVMV5jmmXaZ/mqmb8YyqzK7bU42dzff aN5p/nKZwTLOsoPL7lpQLHwttll0W3y0tLLkW7ZYTllpWkVbVVsNM6gMf0Yx44o12trZeqP1aet3 NpY2ApsTNr/YGtom2jbZTi7XWc5ZXr98zE7djmlXazdiT7ePtj9kP+Kg5sB0qHN44qjhyHZscJxw 0nNKcDrm9MLZxJnv3OY852Ljst7lvCvi6uFa6NrvJuMW4lbp9thd3T3Ovdl9xsPCY53HeU+0p7fn bs9hL2Uvllej18wKqxXrV/R4k7yDvCu9n/jo+/B9unxh3xW+e3wfrtRayVvZ4Qf8vPz2+D3y1/FP 8/8+ABPgH1AV8DTQNDA3sDeIEhQV1BT0Jtg5uCT4QYhuiDCkO1QyNDK0MXQuzDWsNGxklfGq9auu hyuEc8M7I7ARoRENEbOr3VbvXT0eaRFZEDm0RmdN1pqraxXWJq09EyUZxYw6GY2ODotuiv7A9GPW MWdjvGKqY2ZYLqx9rOdsR3YZe4pjxynlTMTaxZbGTsbZxe2Jm4p3iC+Pn+a6cCu5LxM8E2oS5hL9 Eo8kLiSFJbUm45Kjk0/xZHiJvJ4UlZSslIFUg9SC1JE0m7S9aTN8b35DOpS+Jr1TQBX9TPUJdYVb haMZ9hlVGW8zQzNPZkln8bL6svWzd2RP5LjnfL0OtY61rjtXLXdz7uh6p/W1G6ANMRu6N2pszN84 vslj09HNhM2Jm3/IM8krzXu9JWxLV75y/qb8sa0eW5sLJAr4BcPbbLfVbEdt527v32G+Y/+OT4Xs wmtFJkXlRR+KWcXXvjL9quKrhZ2xO/tLLEsO7sLs4u0a2u2w+2ipdGlO6dge3z3tZfSywrLXe6P2 Xi1fVl6zj7BPuG+kwqeic7/m/l37P1TGV96pcq5qrVaq3lE9d4B9YPCg48GWGuWaopr3h7iH7tZ6 1LbXadeVH8Yczjj8tD60vvdrxteNDQoNRQ0fj/COjBwNPNrTaNXY2KTUVNIMNwubp45FHrv5jes3 nS2GLbWttNai4+C48Pizb6O/HTrhfaL7JONky3da31W3UdoK26H27PaZjviOkc7wzoFTK051d9l2 tX1v9P2R02qnq87Inik5Szibf3bhXM652fOp56cvxF0Y647qfnBx1cXbPQE9/Ze8L1257H75Yq9T 77krdldOX7W5euoa41rHdcvr7X0WfW0/WPzQ1m/Z337D6kbnTeubXQPLB84OOgxeuOV66/Jtr9vX 76y8MzAUMnR3OHJ45C777uS9pHsv72fcn3+w6SH6YeEjqUflj5Ue1/2o92PriOXImVHX0b4nQU8e jLHGnv+U/tOH8fyn5KflE6oTjZNmk6en3KduPlv9bPx56vP56YKfpX+ufqH74rtfHH/pm1k1M/6S /3Lh1+JX8q+OvF72unvWf/bxm+Q383OFb+XfHn3HeNf7Puz9xHzmB+yHio96H7s+eX96uJC8sPCb AAMA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNPDwvU3VidHlwZS9UcnVlVHlwZS9G b250RGVzY3JpcHRvciAyMCAwIFIvTGFzdENoYXIgMTE2L1dpZHRoc1szMzMgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgMCAwIDAgMjc4XS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZEl0YWxpY01UL0ZpcnN0Q2hhciA1OC9FbmNvZGlu Zy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTI0IDAgb2JqDTw8L1N1YnR5cGUv VHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTkgMCBSL0xhc3RDaGFyIDEyMC9XaWR0aHNbMjUwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjUwIDAgNTAwIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgNjExIDY2NyAwIDYxMSAwIDAgMCAwIDAgMCA1NTYgMCAwIDAgMCAwIDAg NTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDUwMCAwIDUwMCA0NDQgMjc4IDAgNTAw IDI3OCAwIDAgMCA3MjIgNTAwIDUwMCA1MDAgMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDAgNDQ0XS9C YXNlRm9udC9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjUgMCBvYmoNPDwvTnVtc1swIDI2IDAg Ul0+Pg1lbmRvYmoNMjYgMCBvYmoNPDwvUy9EPj4NZW5kb2JqDTI3IDAgb2JqDTw8L0NvdW50IDQv VHlwZS9QYWdlcy9LaWRzWzMyIDAgUiAxIDAgUiA5IDAgUiAxMiAwIFJdPj4NZW5kb2JqDTI4IDAg b2JqDTw8L1N1YnR5cGUvWE1ML0xlbmd0aCAzNjA1L1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNC4w LWMzMTYgNDQuMjUzOTIxLCBTdW4gT2N0IDAxIDIwMDYgMTc6MTQ6MzkiPgogICA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNyZWF0b3JUb29s PlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4 YXA6TW9kaWZ5RGF0ZT4yMDA5LTA2LTA5VDEyOjUwOjE5LTA3OjAwPC94YXA6TW9kaWZ5RGF0ZT4K ICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDktMDYtMDlUMTI6NTA6MTktMDc6MDA8L3hhcDpD cmVhdGVEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZv cm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAg ICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3NvZnQgV29yZCAtIEVTQjJf QlNEX1N0YXRlbWVudC5kb2M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAg ICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+ CiAgICAgICAgICAgICAgIDxyZGY6bGk+bWZzdHJhdHQ8L3JkZjpsaT4KICAgICAgICAgICAgPC9y ZGY6U2VxPgogICAgICAgICA8L2RjOmNyZWF0b3I+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgog ICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPkFj cm9iYXQgRGlzdGlsbGVyIDguMC4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3Jk ZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAg ICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAg ICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjJmMzM1OTY5LWViZDEtNDMyYy1iY2JmLTFjZjk0 YjZhZDY5YTwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVp ZDpiMzc4MmY5My03Y2MxLTQxZmEtOTk0OS03MTJjMmZhNDA3MzQ8L3hhcE1NOkluc3RhbmNlSUQ+ CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tl dCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmoNPDwvQ3JlYXRpb25EYXRlKEQ6 MjAwOTA2MDkxMjUwMTktMDcnMDAnKS9BdXRob3IobWZzdHJhdHQpL0NyZWF0b3IoUFNjcmlwdDUu ZGxsIFZlcnNpb24gNS4yLjIpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDguMC4wIFwoV2lu ZG93c1wpKS9Nb2REYXRlKEQ6MjAwOTA2MDkxMjUwMTktMDcnMDAnKS9UaXRsZShNaWNyb3NvZnQg V29yZCAtIEVTQjJfQlNEX1N0YXRlbWVudC5kb2MpPj4NZW5kb2JqDXhyZWYNCjAgMzANCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwNjM0OSAwMDAwMCBuDQowMDAwMDA2NDc2IDAwMDAwIG4NCjAw MDAwMDY2MTggMDAwMDAgbg0KMDAwMDAwODkxNSAwMDAwMCBuDQowMDAwMDEyNjY4IDAwMDAwIG4N CjAwMDAwMTI4OTYgMDAwMDAgbg0KMDAwMDAxMzEwMCAwMDAwMCBuDQowMDAwMDEzMzg3IDAwMDAw IG4NCjAwMDAwMTM2MjAgMDAwMDAgbg0KMDAwMDAxMzc0OSAwMDAwMCBuDQowMDAwMDEzOTE4IDAw MDAwIG4NCjAwMDAwMTc2NzAgMDAwMDAgbg0KMDAwMDAxNzgwMCAwMDAwMCBuDQowMDAwMDE3OTY4 IDAwMDAwIG4NCjAwMDAwMTk5MTcgMDAwMDAgbg0KMDAwMDAyMDA0NiAwMDAwMCBuDQowMDAwMDIw MjAzIDAwMDAwIG4NCjAwMDAwMjA0NTIgMDAwMDAgbg0KMDAwMDAyMDg5MyAwMDAwMCBuDQowMDAw MDIxMTQ5IDAwMDAwIG4NCjAwMDAwMjE0MTAgMDAwMDAgbg0KMDAwMDAyMTQ0NSAwMDAwMCBuDQow MDAwMDI0MTM4IDAwMDAwIG4NCjAwMDAwMjQ0MzMgMDAwMDAgbg0KMDAwMDAyNDgyOCAwMDAwMCBu DQowMDAwMDI0ODY0IDAwMDAwIG4NCjAwMDAwMjQ4ODkgMDAwMDAgbg0KMDAwMDAyNDk2MSAwMDAw MCBuDQowMDAwMDI4NjQ0IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMzA+Pg0Kc3RhcnR4cmVm DQoxMTYNCiUlRU9GDQo= --000e0cd28cf08b4e89046c29b00f-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 17:41:24 2009 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 E1AF6106566C for ; Fri, 12 Jun 2009 17:41:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A9A308FC16 for ; Fri, 12 Jun 2009 17:41:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B29BF6995B for ; Fri, 12 Jun 2009 17:22:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n5CHMKSm048091 for ; Fri, 12 Jun 2009 17:22:20 GMT (envelope-from phk@critter.freebsd.dk) To: stable@freebsd.org From: Poul-Henning Kamp Date: Fri, 12 Jun 2009 17:22:20 +0000 Message-ID: <48090.1244827340@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Stable7 buildoption effects: updated table 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, 12 Jun 2009 17:41:25 -0000 I have just completed a run of /src/tools/tools/build_option_survey and have uploaded the result here: http://phk.freebsd.dk/misc/stable7_build_options/ Those of you building embedded systems on FreeBSD 7.x may find this useful. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 20:54:43 2009 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 34F4E106566C; Fri, 12 Jun 2009 20:54:43 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id CF48D8FC0A; Fri, 12 Jun 2009 20:54:42 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1349595ana.13 for ; Fri, 12 Jun 2009 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=DSKWok/uA4O/Z5myXRPNIpaF2PiL7FqahsfxPblvy1U=; b=jnqcDcn7AxvYwi9ynbQXMPcYknHFjsc7utHYI3oXmXHaIxggmYg4VviV9RNMQ67nP2 Y+ME/D6pYNMti8InC2tGKtmzxy7YdfcHnSauskTRKbz2SpPAm6tJTDfDsCtr+TI3F6DA O1ZaaMwhEFKoiDiuV6HN0IC/ZT4YSkqLIDjBo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=uOlOLjwA/A6gwxQwgERYJKdCR44Sr98YKrvNOdwAWo1Z8Wr0eWkAyQeLnImIMil+vw qhm2S+5eLyHyg8qFobmrRoQoT5tFs0ow9wBmyDuAvrYAgQPKlUsnYwikO6gQZWcC8jUH anIlRaPd8u5KRD9kDD+kKZbYDSU+pdp3kd/OI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.3.13 with SMTP id 13mr5484858anc.75.1244840081163; Fri, 12 Jun 2009 13:54:41 -0700 (PDT) In-Reply-To: <4A325E9F.2080802@icyb.net.ua> References: <4A325E9F.2080802@icyb.net.ua> Date: Fri, 12 Jun 2009 13:54:40 -0700 X-Google-Sender-Auth: 2e44c479cd2b2ba1 Message-ID: <3c1674c90906121354s6d6ae7ben5082708b1586e94f@mail.gmail.com> From: Kip Macy To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: zfs related panic 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, 12 Jun 2009 20:54:43 -0000 show sleepchain show thread 100263 On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapon wrote: > > This is on a recent stable/7 amd64, with zpool and filesystems upgraded to the > latest version. > I did zfs rollback xxx@yyy > And then did ls on a directory in the rolled-back fs. > > I have the core file if it can be of any help. > > Sleeping thread (tid 100263, pid 2432) owns a non-sleepable lock > sched_switch() at 0xffffffff8031d0ef = sched_switch+0x47d > mi_switch() at 0xffffffff80302a59 = mi_switch+0x1bf > sleepq_switch() at 0xffffffff8032f645 = sleepq_switch+0xd8 > sleepq_catch_signals() at 0xffffffff8032f925 = sleepq_catch_signals+0x2db > sleepq_wait_sig() at 0xffffffff80330219 = sleepq_wait_sig+0xc > _sleep() at 0xffffffff80302eba = _sleep+0x2b5 > kern_sigsuspend() at 0xffffffff802fc567 = kern_sigsuspend+0xeb > sigsuspend() at 0xffffffff802fc5e9 = sigsuspend+0x34 > syscall() at 0xffffffff80491d2d = syscall+0x347 > Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab > --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x80092ce3c, rsp = > 0x7fffffffdee8, rbp = 0x8011e5a60 --- > panic: sleeping thread > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff80192dd5 = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff80327ea7 = kdb_backtrace+0x32 > panic() at 0xffffffff802fb70c = panic+0x1b0 > propagate_priority() at 0xffffffff80332e92 = propagate_priority+0x122 > turnstile_wait() at 0xffffffff80333e29 = turnstile_wait+0x358 > _mtx_lock_sleep() at 0xffffffff802ed64a = _mtx_lock_sleep+0x117 > cache_lookup() at 0xffffffff8036a52a = cache_lookup+0x632 > vfs_cache_lookup() at 0xffffffff8036a69f = vfs_cache_lookup+0xab > VOP_LOOKUP_APV() at 0xffffffff804c86f3 = VOP_LOOKUP_APV+0x51 > lookup() at 0xffffffff80370a71 = lookup+0x5d8 > namei() at 0xffffffff8037168f = namei+0x320 > kern_lstat() at 0xffffffff8037f6ca = kern_lstat+0x5e > lstat() at 0xffffffff8037f8c9 = lstat+0x25 > syscall() at 0xffffffff80491d2d = syscall+0x347 > Xfast_syscall() at 0xffffffff8047d00b = Xfast_syscall+0xab > --- syscall (190, FreeBSD ELF64, lstat), rip = 0x80095afbc, rsp = 0x7fffffffdde8, > rbp = 0x800b50270 --- > > -- > Andriy Gapon > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 02:30:53 2009 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 68BE4106566C for ; Sat, 13 Jun 2009 02:30:53 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from smtp.owt.com (smtp.owt.com [64.146.239.50]) by mx1.freebsd.org (Postfix) with ESMTP id 89D4F8FC13 for ; Sat, 13 Jun 2009 02:30:52 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from kstewart2.owt.com (kstewart2.owt.com [64.146.237.228]) (authenticated bits=0) by smtp.owt.com (8.13.8/8.13.8) with ESMTP id n5D2GlKQ017668; Fri, 12 Jun 2009 19:16:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=owt.com; s=default; t=1244859407; bh=MJ1T1BlolYPwH5mfDnV+C5qBBx+nTQGePCNoMtcpCLk=; h=From:To:Subject:Date:Cc:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=iaGJm1sV5JicG Gs/FmDf6/ThYb9AOYatCp3PMkzE19NcXy7PvRBemImWMsjPXwi8Rgfl8vhucKBZ+Jf0 QqbkDjZyDEjUgzRxusEIedUWUPjRelIadaM1A3jkZRqPV0q8snCLlVNIjP5IGZyCCin d1EySCvUaCZ7Yz30Xq61uPCo= From: Kent Stewart To: freebsd-stable@freebsd.org Date: Fri, 12 Jun 2009 19:16:46 -0700 User-Agent: KMail/1.9.10 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906121916.46729.kstewart@owt.com> Cc: Dan Allen , "Paul B. Mahol" Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 02:30:54 -0000 On Thursday 11 June 2009 06:33:24 pm Dan Allen wrote: > On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > > Looks like boot(8) is problematic. > > Anything in /etc/src.conf or /etc/make.conf? > > I have never touched or created a src.conf. If there was one there, > it has been unmodified by me. > > I HAVE modified make.conf. Here is its contents: > > --- /etc/make.conf --- > > BATCH=yes > NO_PROFILE=yes > KERNCONF=DKA > USE_FORTRAN=yes > WITH_JADETEX=no > PERL_VERSION=5.8.9 > > --- > > My custom kernel named DKA has only three modifications from GENERIC: > > I commented out the following three lines: > > #cpu I486_CPU > #cpu I586_CPU > #makeoptions DEBUG="-g" > > I have run with such a kernel on many machines for many years now. > > However, my experiments have shown that the kernel build is not to > blame. > > Isn't boot part of the kernel build? Why would installing the kernel > not cause this problem? > > It is by installing the world via make installworld that my drive gets > munged. > > I obviously am missing something, but boot(8) sounds like it is in the > neighborhood of where the problem is. > > There were changes to /usr/src/sys/boot/i386/libi386/biosdisk.c and > biospnp.c that really look suspect to me. The order of your builds in previous messages had the kernel built on an old world. You are supposed to do the buildworld first and then, build and install the kernel. The classic way at this point is to boot into single user mode and do the installworld. Kent > > Dan > > _______________________________________________ > 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" -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 02:45:11 2009 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 D8FE11065670 for ; Sat, 13 Jun 2009 02:45:11 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id B458C8FC13 for ; Sat, 13 Jun 2009 02:45:11 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 12687 invoked by uid 89); 13 Jun 2009 01:33:31 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 01:33:31 -0000 Message-Id: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> From: Dan Allen To: John Baldwin , Yuri Pankov In-Reply-To: <200906120832.51098.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 20:45:01 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> X-Mailer: Apple Mail (2.935.3) Cc: "Paul B. Mahol" , freebsd-stable@freebsd.org Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 02:45:12 -0000 On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: >> Isn't boot part of the kernel build? Why would installing the kernel >> not cause this problem? > > No, sys/boot is built during world. Likely some change in /boot/ > loader is > causing your problem. Can you narrow it down to a specific change > under > sys/boot? Ok. I updated just the one file since it appeared like one of the few changed files /usr/src/sys/boot/i386/libi386/biosdisk.c and rebuilt things with cd /usr/src/sys/boot; make cleandir obj depend all install and it was okay. No problems. Then I did sync'd all of the changed files for /usr/src/sys/boot and my machine is hung again at boot, so we have narrowed it down to somewhere in /usr/src/sys/boot/. Time to reinstall from a DVD and try it with finer granularity. This will take some time. There appears to be only four files that have changed in /usr/src/sys/ boot from June 8th (all working fine) to June 11th (dead in the water). They are: /usr/src/sys/boot/Makefile /usr/src/sys/boot/i386/Makefile /usr/src/sys/boot/i386/libi386/biosdisk.c /usr/src/sys/boot/i386/loader/Makefile I have ruled out bisodisk.c, as stated above. That means that the Makefiles are building new stuff that previously was not built, namely zfsboot gptzfsboot I believe it has to do with that. More help is needed! I am tired of reinstalling the OS, but I am much more paranoid about updating my other machine in any way now, as it could erase that whole machine. I can't believe I am the only one seeing this... Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 03:38:23 2009 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 08823106564A; Sat, 13 Jun 2009 03:38:23 +0000 (UTC) (envelope-from kline@thought.org) Received: from aristotle.thought.org (ns1.thought.org [209.180.213.210]) by mx1.freebsd.org (Postfix) with ESMTP id 97C7B8FC0C; Sat, 13 Jun 2009 03:38:22 +0000 (UTC) (envelope-from kline@thought.org) Received: from thought.org (tao.thought.org [10.47.0.250]) (authenticated bits=0) by aristotle.thought.org (8.14.2/8.14.2) with ESMTP id n5D3PwvW043392; Fri, 12 Jun 2009 20:25:58 -0700 (PDT) (envelope-from kline@thought.org) Received: by thought.org (nbSMTP-1.00) for uid 1002 kline@thought.org; Fri, 12 Jun 2009 20:24:43 -0700 (PDT) Date: Fri, 12 Jun 2009 20:24:42 -0700 From: Gary Kline To: Dan Allen Message-ID: <20090613032442.GA24933@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> User-Agent: Mutt/1.4.2.3i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 22++ years of service to the Unix community. X-Spam-Status: No, score=-4.4 required=3.6 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on aristotle.thought.org Cc: Yuri Pankov , "Paul B. Mahol" , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 03:38:23 -0000 On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > >>Isn't boot part of the kernel build? Why would installing the kernel > >>not cause this problem? > > > >No, sys/boot is built during world. Likely some change in /boot/ > >loader is > >causing your problem. Can you narrow it down to a specific change > >under > >sys/boot? > > Ok. I updated just the one file since it appeared like one of the few > changed files > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > and rebuilt things with > > cd /usr/src/sys/boot; make cleandir obj depend all install > > and it was okay. No problems. > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > my machine is hung again at boot, so we have narrowed it down to > somewhere in /usr/src/sys/boot/. > > Time to reinstall from a DVD and try it with finer granularity. This > will take some time. > > There appears to be only four files that have changed in /usr/src/sys/ > boot from June 8th (all working fine) to June 11th (dead in the > water). They are: > > /usr/src/sys/boot/Makefile > /usr/src/sys/boot/i386/Makefile > /usr/src/sys/boot/i386/libi386/biosdisk.c > /usr/src/sys/boot/i386/loader/Makefile > > I have ruled out bisodisk.c, as stated above. > > That means that the Makefiles are building new stuff that previously > was not built, namely > > zfsboot gptzfsboot > > I believe it has to do with that. More help is needed! I am tired of > reinstalling the OS, but I am much more paranoid about updating my > other machine in any way now, as it could erase that whole machine. I > can't believe I am the only one seeing this... > > Dan > Whew!! i'm giving thanks to every saint, god and daemon known. i rebuilt my kernel in very recent days (7.2) on my ancient 500MHz kayak, but did not go further. So still runing on the 7.0 kernel. Will someone send up a flare when it's *safe*? gary -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 04:18:37 2009 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 C00601065670 for ; Sat, 13 Jun 2009 04:18:37 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.149]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF078FC13 for ; Sat, 13 Jun 2009 04:18:37 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: by ey-out-1920.google.com with SMTP id 3so322033eyh.18 for ; Fri, 12 Jun 2009 21:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=o3WvPNSnobqg47RLt+3OCaSWQ6C12FiV6qXzaTAJIf4=; b=CVYtP8nz0NjzhO37ok4HS46pA/IjZWpKxEqng9MMGMsaB/3je/R3hlet9IYHgsDSJp EiKELsoHgypdRur67571XYKM+pnQb1TZb1G+T51H1NlYl4dt8RXn/eWdfOkcVvcYeyVT yVPj2PvwG447nXAQHvoQFZiZFz1/se/ZRz7wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=rgDvTGrRvZmrDP7gLwVdO+lotoqMOYl62l+FCgoB5zYnoQhufP6QCdvn+NkLQLdUwL +4oK4v6xZztHbyOr1bwYBcfPunBShjXt7QtjtXLNuzUmebmslp2M0FLV9zQZtghfUBHa C7eXYIwT6BTAQq+V7bvWx5hrJTyfEcdU2Pxj8= Received: by 10.210.56.2 with SMTP id e2mr1585617eba.42.1244865028305; Fri, 12 Jun 2009 20:50:28 -0700 (PDT) Received: from darklight.homeunix.org ([85.175.158.234]) by mx.google.com with ESMTPS id 23sm808841eya.49.2009.06.12.20.50.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 20:50:27 -0700 (PDT) Received: from darklight.homeunix.org (darklight.homeunix.org [127.0.0.1]) by darklight.homeunix.org (8.14.3/8.14.3) with ESMTP id n5D3oNSZ016462; Sat, 13 Jun 2009 07:50:24 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.homeunix.org (8.14.3/8.14.3/Submit) id n5D3oNVG016461; Sat, 13 Jun 2009 07:50:23 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.homeunix.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 13 Jun 2009 07:50:23 +0400 From: Yuri Pankov To: Gary Kline Message-ID: <20090613035023.GB1227@darklight.homeunix.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090613032442.GA24933@thought.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Dan Allen , "Paul B. Mahol" , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 04:18:38 -0000 On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > >>Isn't boot part of the kernel build? Why would installing the kernel > > >>not cause this problem? > > > > > >No, sys/boot is built during world. Likely some change in /boot/ > > >loader is > > >causing your problem. Can you narrow it down to a specific change > > >under > > >sys/boot? > > > > Ok. I updated just the one file since it appeared like one of the few > > changed files > > > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > > > and rebuilt things with > > > > cd /usr/src/sys/boot; make cleandir obj depend all install > > > > and it was okay. No problems. > > > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > > my machine is hung again at boot, so we have narrowed it down to > > somewhere in /usr/src/sys/boot/. > > > > Time to reinstall from a DVD and try it with finer granularity. This > > will take some time. > > > > There appears to be only four files that have changed in /usr/src/sys/ > > boot from June 8th (all working fine) to June 11th (dead in the > > water). They are: > > > > /usr/src/sys/boot/Makefile > > /usr/src/sys/boot/i386/Makefile > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > /usr/src/sys/boot/i386/loader/Makefile > > > > I have ruled out bisodisk.c, as stated above. > > > > That means that the Makefiles are building new stuff that previously > > was not built, namely > > > > zfsboot gptzfsboot > > > > I believe it has to do with that. More help is needed! I am tired of > > reinstalling the OS, but I am much more paranoid about updating my > > other machine in any way now, as it could erase that whole machine. I > > can't believe I am the only one seeing this... > > > > Dan > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary > > > > -- > Gary Kline kline@thought.org http://www.thought.org Public Service Unix > http://jottings.thought.org http://transfinite.thought.org > For FBSD list: http://transfinite.thought.org/slicejourney.php > The 4.98a release of Jottings: http://jottings.thought.org/index.php How do you know it isn't safe? Noone hasn't provided any useful info (debug, revisions where it works and where it doesn't). Yuri From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 06:24:12 2009 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 C07C41065689 for ; Sat, 13 Jun 2009 06:24:12 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from smtp.owt.com (smtp.owt.com [64.146.239.50]) by mx1.freebsd.org (Postfix) with ESMTP id 94D728FC14 for ; Sat, 13 Jun 2009 06:24:12 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from kstewart2.owt.com (kstewart2.owt.com [64.146.237.228]) (authenticated bits=0) by smtp.owt.com (8.13.8/8.13.8) with ESMTP id n5D6O9rn022384; Fri, 12 Jun 2009 23:24:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=owt.com; s=default; t=1244874252; bh=WksCll+YzwjYbsL4C1Ut/WOTEv6ZEQFOkJXT6No9IlM=; h=From:To:Subject:Date:Cc:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=X+uCV7bLYEIRZ P5ldyIUW888rM4Py77FvuKQJcDe9EwCuaGmwKhhN7q4w82efFm/K5eK2mh/6jjOr/UI 0oA3oGRTrk5R7dCMM4FagyfTHi/GXYbQXCXyN2jM561oIpusKUS1jweupmmQtirbaPY RZKHB0P7AtnzvZH/4jRcuWQI= From: Kent Stewart To: freebsd-stable@freebsd.org Date: Fri, 12 Jun 2009 23:24:07 -0700 User-Agent: KMail/1.9.10 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> In-Reply-To: <20090613032442.GA24933@thought.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906122324.08061.kstewart@owt.com> Cc: Gary Kline Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 06:24:13 -0000 On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > Whew!! i'm giving thanks to every saint, god and daemon known. i > rebuilt my kernel in very recent days (7.2) on my ancient > 500MHz kayak, but did not go further. So still runing on the 7.0 > kernel. > > Will someone send up a flare when it's *safe*? > > gary Gary, it isn't affecting everyone. FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 14:07:14 PDT 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 i386 FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 15:03:03 PDT 2009 root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 i386 Ruby is an Intel core duo and the other has dual Xeon's. They were all installed the canonical way. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 07:08:22 2009 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 CFE89106564A for ; Sat, 13 Jun 2009 07:08:22 +0000 (UTC) (envelope-from kline@thought.org) Received: from aristotle.thought.org (aristotle.thought.org [209.180.213.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7FD8FC19 for ; Sat, 13 Jun 2009 07:08:22 +0000 (UTC) (envelope-from kline@thought.org) Received: from thought.org (tao.thought.org [10.47.0.250]) (authenticated bits=0) by aristotle.thought.org (8.14.2/8.14.2) with ESMTP id n5D79Xs2044963; Sat, 13 Jun 2009 00:09:33 -0700 (PDT) (envelope-from kline@thought.org) Received: by thought.org (nbSMTP-1.00) for uid 1002 kline@thought.org; Sat, 13 Jun 2009 00:08:17 -0700 (PDT) Date: Sat, 13 Jun 2009 00:08:17 -0700 From: Gary Kline To: Kent Stewart Message-ID: <20090613070817.GA25592@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> <200906122324.08061.kstewart@owt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906122324.08061.kstewart@owt.com> User-Agent: Mutt/1.4.2.3i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 22++ years of service to the Unix community. X-Spam-Status: No, score=-4.4 required=3.6 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on aristotle.thought.org Cc: freebsd-stable@freebsd.org Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 07:08:23 -0000 On Fri, Jun 12, 2009 at 11:24:07PM -0700, Kent Stewart wrote: > On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > > rebuilt my kernel in very recent days (7.2) on my ancient > > 500MHz kayak, but did not go further. So still runing on the 7.0 > > kernel. > > > > Will someone send up a flare when it's *safe*? > > > > gary > > Gary, it isn't affecting everyone. > > FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 14:07:14 PDT > 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 i386 > > FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 > 15:03:03 PDT 2009 root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 > i386 > > Ruby is an Intel core duo and the other has dual Xeon's. They were all > installed the canonical way. > Thanks for the insight, Kent. I'll go ahead and install 7.2 on the P3, then. Should be done this weekend. gary > Kent > -- > Kent Stewart > Richland, WA > > http://users.owt.com/kstewart/index.html > -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 08:08:35 2009 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 24DEA106566B for ; Sat, 13 Jun 2009 08:08:35 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from smtp.owt.com (smtp.owt.com [64.146.239.50]) by mx1.freebsd.org (Postfix) with ESMTP id EDD1B8FC08 for ; Sat, 13 Jun 2009 08:08:34 +0000 (UTC) (envelope-from kstewart@owt.com) Received: from kstewart2.owt.com (kstewart2.owt.com [64.146.237.228]) (authenticated bits=0) by smtp.owt.com (8.13.8/8.13.8) with ESMTP id n5D88XNM024894; Sat, 13 Jun 2009 01:08:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=owt.com; s=default; t=1244880514; bh=Nxb3A0rI7IUjQrYnVbZJpFSk0DNCdyvRB16PEOguDQQ=; h=From:To:Subject:Date:Cc:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=DFlu7l9QfdH3p DB4UXrsGu5irrU92qRnGpu8puSu8EDFsCivFw/HqtztMgtRFzCMr7LNxAtQwazAhkIX VGZWwgPBmcrYBGW34HBa1RL5ewKs6tNaUUgGzY9Hc9rqCHmpOiQO/5aynAD3aR4uj4/ bVhZ+mY5fzg1myOUf61hXMHI= From: Kent Stewart To: Gary Kline Date: Sat, 13 Jun 2009 01:08:32 -0700 User-Agent: KMail/1.9.10 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <200906122324.08061.kstewart@owt.com> <20090613070817.GA25592@thought.org> In-Reply-To: <20090613070817.GA25592@thought.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906130108.33076.kstewart@owt.com> Cc: freebsd-stable@freebsd.org Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 08:08:35 -0000 On Saturday 13 June 2009 12:08:17 am Gary Kline wrote: > On Fri, Jun 12, 2009 at 11:24:07PM -0700, Kent Stewart wrote: > > On Friday 12 June 2009 08:24:42 pm Gary Kline wrote: > > > On Fri, Jun 12, 2009 at 08:45:01PM -0600, Dan Allen wrote: > > > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > > > > >On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: > > > > > > Whew!! i'm giving thanks to every saint, god and daemon known. i > > > rebuilt my kernel in very recent days (7.2) on my ancient > > > 500MHz kayak, but did not go further. So still runing on the 7.0 > > > kernel. > > > > > > Will someone send up a flare when it's *safe*? > > > > > > gary > > > > Gary, it isn't affecting everyone. > > > > FreeBSD ruby.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #4: Wed Jun 10 > > 14:07:14 PDT 2009 root@ruby.owt.com:/usr/obj/usr/src/sys/FREEBSD2 > > i386 > > > > FreeBSD kstewart2.owt.com 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 > > 15:03:03 PDT 2009 > > root@kstewart2.owt.com:/usr/obj/usr/src/sys/FREEBSD1 i386 > > > > Ruby is an Intel core duo and the other has dual Xeon's. They were all > > installed the canonical way. > > Thanks for the insight, Kent. I'll go ahead and install 7.2 on the > P3, then. Should be done this weekend. > Coming from the diagnostic side in the days of our Cray, I believe that one broken machine means more than 100 without problems. There just seems to be more to this than is normal. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 14:00:44 2009 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 3E1DA106566B for ; Sat, 13 Jun 2009 14:00:44 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com (web.hostmailing.com [200.110.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 910568FC2C for ; Sat, 13 Jun 2009 14:00:43 +0000 (UTC) (envelope-from rebotados@exemys.com) Received: from web.hostmailing.com ([200.110.145.34] helo=www.hostmailing.com) by web.hostmailing.com with esmtpa (Exim 4.63) (envelope-from ) id 1MFTlb-000714-Sh for freebsd-stable@freebsd.org; Sat, 13 Jun 2009 10:59:31 -0300 Date: Sat, 13 Jun 2009 10:59:31 -0300 To: freebsd-stable@freebsd.org From: Exemys Message-ID: <4ee8822e7b83696737a9daf622ec6f95@www.hostmailing.com> X-Priority: 3 X-Mailer: wh4535 [version 3.1] MIME-Version: 1.0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: I/O Serial Tunnel over Ethernet - Cellular - WiFi X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: exemys@exemys.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 14:00:45 -0000 This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 16:45:53 2009 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 9B2721065672 for ; Sat, 13 Jun 2009 16:45:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 617C58FC16 for ; Sat, 13 Jun 2009 16:45:53 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFWMZ-00026z-2t for freebsd-stable@freebsd.org; Sat, 13 Jun 2009 17:45:51 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFWMX-000NUw-GV for freebsd-stable@freebsd.org; Sat, 13 Jun 2009 17:45:49 +0100 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Sat, 13 Jun 2009 17:45:49 +0100 Subject: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 16:45:53 -0000 I am looking to deploy a couple of hundered system, which are supposed to attach to a network and be plug-in-and-go. I am thinking of doing this with a FreeBSD installation, duplicated onto flash cards, and dumped into some off-the-sheelt hardware. The questions I, what hardware ? I've done some research, and come up with boxes like this: http://www.icp-epia.co.uk/index.php?act=viewProd&productId=434 But I was wondering if anyone knew of any alternatives, preferably featuring a processor which can run amd64. The rest of thats pec is fine, and I dont need wifi. Any suggestions, or words of wisdom from anyone who has done someething similar themselevs in the past ? cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 16:57:00 2009 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 8BCC3106564A for ; Sat, 13 Jun 2009 16:57:00 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 03B928FC18 for ; Sat, 13 Jun 2009 16:56:59 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 5811 invoked by uid 89); 13 Jun 2009 15:45:12 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 15:45:12 -0000 Message-Id: From: Dan Allen To: Yuri Pankov In-Reply-To: <20090613035023.GB1227@darklight.homeunix.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 10:56:57 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <20090613032442.GA24933@thought.org> <20090613035023.GB1227@darklight.homeunix.org> X-Mailer: Apple Mail (2.935.3) Cc: Gary Kline , freebsd-stable@freebsd.org, John Baldwin , "Paul B. Mahol" Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 16:57:00 -0000 On 12 Jun 2009, at 9:50 PM, Yuri Pankov wrote: > On Fri, Jun 12, 2009 at 08:24:42PM -0700, Gary Kline wrote: >> Whew!! i'm giving thanks to every saint, god and daemon known. i >> rebuilt my kernel in very recent days (7.2) on my ancient >> 500MHz kayak, but did not go further. So still runing on the 7.0 >> kernel. >> >> Will someone send up a flare when it's *safe*? >> > > How do you know it isn't safe? Noone hasn't provided any useful info > (debug, revisions where it works and where it doesn't). Well, I do not think it is safe at all either. I must have some strange configuration that others do not have or there would be plenty of people with their drives getting wiped out. I tried removing the zfsboot and gptzfsboot items from /usr/src/sys/ boot/i386/Makefile and then rebuild the boot area but it once again killed things. My hunch is that the boot loader is getting stuck on something strange about my system. Here is my drive config, and perhaps this will cause a light bulb to go on for someone: Toshiba U205, Intel 1.83GHz Core Duo, 1GB RAM, 1 120GB hard drive with two partitions. The first partition is 92161 MB for Windows XP Pro. I rarely use it. The second partition is 22309 MB for FreeBSD. It has 3 slices: The first slice /dev/ad0s2a is the main 22 GB file system. It has the / root mount point and has soft updates turned on. The second slice /dev/ad0s2b is a 1GB SWAP partition. The third slice /dev/ad0s2c is unused. I will continue to test. I am TRYING to narrow it down, it just takes forever. Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 18:41:56 2009 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 E1C52106566C for ; Sat, 13 Jun 2009 18:41:56 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id A51658FC16 for ; Sat, 13 Jun 2009 18:41:56 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 16982 invoked by uid 89); 13 Jun 2009 17:30:07 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 17:30:07 -0000 Message-Id: From: Dan Allen To: Paul B. Mahol In-Reply-To: <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 12:41:55 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 18:41:57 -0000 On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > Looks like boot(8) is problematic. Okay, here is the June 13th noon update to this problem. I once again installed a May 28th build. Rebuilt world and kernel from source. Everything works great. No custom kernel, just GENERIC. I then merged in just /usr/src/sys/boot/i386/libi386 changes to June 10th. Rebuilt in /usr/src/sys/boot and installed it, no problem. Then I merged in the latest from /usr/src/sys/boot/i386/loader, rebuilt, installed, and BOOM. DEATH TO DRIVE. Disk label GONE again. Hangs after "BIOS drive C: is disk1" at boot. Does not get to memory check, let alone to the "Welcome to FreeBSD and choose a boot option" screen. CULPRIT REVEALED: So, there is only one file change in /usr/src/sys/boot/i386/loader from June 8th to June 10th, which kills my machine very repeatably, and that is the Makefile. Something in /usr/src/sys/boot/i386/loader/Makefile is killing my drive. What do I try next? Thanks for the help. Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 18:50:33 2009 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 4CA98106566B; Sat, 13 Jun 2009 18:50:33 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id A7D4E8FC0A; Sat, 13 Jun 2009 18:50:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm28 with SMTP id 28so301344fxm.43 for ; Sat, 13 Jun 2009 11:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Enz37Bwz9T2ULJkm4aHM3fhQlAPUO4/eh47TzUeGbnk=; b=alx/OPbLK5KIzl5w0wUHT3Bah6CdPBXILtJKwRz3/nSNeyHDa6WBqhD3Qbb6WUy2hZ vwSMRobIFwv4Q9WVEKzZ/av17cHtX0O5Yf+jfmeqXggAWf5yXJyxfK3lMEXe4L2KwiqD QVNvtlKZ/iYQOq3/S9jCl93c3B3drVVhoDh2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a9SqJaeLA6BO17H7tZQ2oWKW0uR81zTtx49YYPVqoVzFashvnWcKreZgeoLwbmNtXP rOkvuGQFylfE7Plw4sxQ7+WSF915SwAiJQZNolLb8iCUsrbZ3aGd3i15SpKD2+pt/YTb 3/OxSq7pzq0kmnsNB2zlemgKzsdy+eXAXpfhg= MIME-Version: 1.0 Received: by 10.204.53.10 with SMTP id k10mr5013931bkg.169.1244919031689; Sat, 13 Jun 2009 11:50:31 -0700 (PDT) In-Reply-To: <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> Date: Sat, 13 Jun 2009 20:50:31 +0200 Message-ID: <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> From: "Paul B. Mahol" To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yuri Pankov , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 18:50:33 -0000 On 6/13/09, Dan Allen wrote: > > On 12 Jun 2009, at 6:32 AM, John Baldwin wrote: > >> On Thursday 11 June 2009 9:33:24 pm Dan Allen wrote: >>> Isn't boot part of the kernel build? Why would installing the kernel >>> not cause this problem? >> >> No, sys/boot is built during world. Likely some change in /boot/ >> loader is >> causing your problem. Can you narrow it down to a specific change >> under >> sys/boot? > > Ok. I updated just the one file since it appeared like one of the few > changed files > > /usr/src/sys/boot/i386/libi386/biosdisk.c > > and rebuilt things with > > cd /usr/src/sys/boot; make cleandir obj depend all install > > and it was okay. No problems. > > Then I did sync'd all of the changed files for /usr/src/sys/boot and > my machine is hung again at boot, so we have narrowed it down to > somewhere in /usr/src/sys/boot/. > > Time to reinstall from a DVD and try it with finer granularity. This > will take some time. > > There appears to be only four files that have changed in /usr/src/sys/ > boot from June 8th (all working fine) to June 11th (dead in the > water). They are: > > /usr/src/sys/boot/Makefile > /usr/src/sys/boot/i386/Makefile > /usr/src/sys/boot/i386/libi386/biosdisk.c I doubt it is loader fault, from your description it appears that loader is never started. Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? > /usr/src/sys/boot/i386/loader/Makefile > > I have ruled out bisodisk.c, as stated above. > > That means that the Makefiles are building new stuff that previously > was not built, namely > > zfsboot gptzfsboot > > I believe it has to do with that. More help is needed! I am tired of > reinstalling the OS, but I am much more paranoid about updating my > other machine in any way now, as it could erase that whole machine. I > can't believe I am the only one seeing this... > > Dan > > -- Paul From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 19:54:54 2009 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 491721065677 for ; Sat, 13 Jun 2009 19:54:54 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by mx1.freebsd.org (Postfix) with ESMTP id ED8258FC14 for ; Sat, 13 Jun 2009 19:54:53 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id 2AA16172C80; Sat, 13 Jun 2009 09:54:52 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 57686153882; Sat, 13 Jun 2009 09:54:52 -1000 (HST) Date: Sat, 13 Jun 2009 09:54:52 -1000 From: Clifton Royston To: Pete French Message-ID: <20090613195451.GA15509@lava.net> Mail-Followup-To: Pete French , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 19:54:54 -0000 On Sat, Jun 13, 2009 at 05:45:49PM +0100, Pete French wrote: > I am looking to deploy a couple of hundered system, which are supposed > to attach to a network and be plug-in-and-go. I am thinking of doing > this with a FreeBSD installation, duplicated onto flash cards, and > dumped into some off-the-sheelt hardware. The questions I, what hardware ? > > I've done some research, and come up with boxes like this: > > http://www.icp-epia.co.uk/index.php?act=viewProd&productId=434 > > But I was wondering if anyone knew of any alternatives, preferably > featuring a processor which can run amd64. The rest of thats pec > is fine, and I dont need wifi. I'm not 100% sure, but fairly sure that you'll have a hard time finding something that combines the low-power standalone type spec with a 64-bit capable processor. Once you get the higher-end processor, that draws higher power, and so demands active cooling, a motherboard chipset which also draws higher power, a bigger power supply which becomes a more likely failure point, and so on. Can you elaborate a bit more on which parts of that system spec you really need - do you need the GigE? Two ethernets? The external SATA? > Any suggestions, or words of wisdom from anyone who has done someething > similar themselevs in the past ? Not specifically this, though I've done other embedded work in the past. Several years ago I did research some appliance type setups for a possible spam-filtering appliance based on the VIA Nehemiah CPU; I won't bother you with that info because nowadays the Atom or AMD Geode seem to win in that niche. Besides the frequently mentioned Soekris these guys seem to make some pretty nice low-power systems: http://www.compulab.co.il/all-products/html/products.htm I bought one of these from them last year: http://www.fit-pc.com/new/fit-pc-1-0-specifications.html due to the two Ethernet ports and low power consumption, and put the pfSense package on it (FreeBSD 7.1-based) for a firewall; it runs a packet filtering bridge with DHCP service, Squid, etc. This particular model is out of production now, but the site implies they could do a new run of them for 100 or more units, and there's a newer upgraded model here: http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Note these are both passively cooled and draw around 5w; I think they also come in at about half the price of what you were looking at, if they'll do. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 19:59:24 2009 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 4D7411065674 for ; Sat, 13 Jun 2009 19:59:24 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing02.lava.net (pie.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b8c]) by mx1.freebsd.org (Postfix) with ESMTP id 2645C8FC0C for ; Sat, 13 Jun 2009 19:59:24 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing02.lava.net (Postfix) with ESMTP id C48C5172C82; Sat, 13 Jun 2009 09:59:23 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id C8B5B153882; Sat, 13 Jun 2009 09:59:22 -1000 (HST) Date: Sat, 13 Jun 2009 09:59:22 -1000 From: Clifton Royston To: Pete French , freebsd-stable@freebsd.org Message-ID: <20090613195922.GB15509@lava.net> Mail-Followup-To: Pete French , freebsd-stable@freebsd.org References: <20090613195451.GA15509@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090613195451.GA15509@lava.net> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 19:59:24 -0000 Sorry for the self-followup; correcting an incorrect URL. On Sat, Jun 13, 2009 at 09:54:52AM -1000, Clifton Royston wrote: ... > due to the two Ethernet ports and low power consumption, and put the > pfSense package on it (FreeBSD 7.1-based) for a firewall; it runs a > packet filtering bridge with DHCP service, Squid, etc. This particular > model is out of production now, but the site implies they could do a > new run of them for 100 or more units, and there's a newer upgraded > model here: > > http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Should have gone here: http://www.fit-pc.com/new/whats-new.html No business relationship with them, just had a good experience with the (earlier) hardware. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 20:13:37 2009 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 97832106570D for ; Sat, 13 Jun 2009 20:13:37 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC178FC24 for ; Sat, 13 Jun 2009 20:13:37 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFZba-0004OX-II; Sat, 13 Jun 2009 21:13:34 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFZba-000OCF-H8; Sat, 13 Jun 2009 21:13:34 +0100 To: cliftonr@lava.net In-Reply-To: <20090613195451.GA15509@lava.net> Message-Id: From: Pete French Date: Sat, 13 Jun 2009 21:13:34 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 20:13:38 -0000 > I'm not 100% sure, but fairly sure that you'll have a hard time > finding something that combines the low-power standalone type spec with > a 64-bit capable processor. Once you get the higher-end processor, That was my experiense when shopping around yes - annoying as I don't need anything particularly low power (it ain't going to be my leccy bill :-). > becomes a more likely failure point, and so on. Can you elaborate a > bit more on which parts of that system spec you really need - do you > need the GigE? Two ethernets? The external SATA? It needs to be: 1) Complete as purchased - I dont want to build a machine 2) Capable of having a simple boot device (e.g. CF card) dropped in 3) At least one ether port. 100 meg will do. 4) Small enough to be posted to the end user 5) Cheap - under 400 euros, preferably 300 I do not really care about processor speed, or memory, or power consumption. It needs to run FreeBSD, and I would prefer amd64 as we havent written or used any of our code on 32 bit in a long time, and I would feel uneasy that there might be laten bugs in it if we simply recompiled it for 32 bit. > I bought one of these from them last year: > http://www.fit-pc.com/new/fit-pc-1-0-specifications.html Thanks for the links - thats pretty interesting! I notice the newer ones are also Atom based, so similarly spec'd to what I was looking at, but they may be more suitable. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 20:41:35 2009 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 20A221065670 for ; Sat, 13 Jun 2009 20:41:35 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id D4CA28FC0A for ; Sat, 13 Jun 2009 20:41:34 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 29730 invoked by uid 89); 13 Jun 2009 19:29:43 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 19:29:43 -0000 Message-Id: From: Dan Allen To: Paul B. Mahol In-Reply-To: <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 14:41:31 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Yuri Pankov , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 20:41:35 -0000 On 13 Jun 2009, at 12:50 PM, Paul B. Mahol wrote: > I doubt it is loader fault, from your description it appears that > loader is never started. > > Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? > >> /usr/src/sys/boot/i386/loader/Makefile BINGO! LOADER_ZFS_SUPPORT is the culprit. I rebuilt the good world, and brought in the loader changes which have caused previously caused death to my drive, then deleted the ZFS_SUPPORT path in /usr/src/sys/boot/i386/loader/Makefile as you recommended, and rebuilt things and everything works fine. Now what do we do? Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 20:53:44 2009 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 CE1131065673 for ; Sat, 13 Jun 2009 20:53:44 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 957C28FC08 for ; Sat, 13 Jun 2009 20:53:44 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 1475 invoked by uid 89); 13 Jun 2009 19:41:53 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 19:41:53 -0000 Message-Id: From: Dan Allen To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 14:53:42 -0600 X-Mailer: Apple Mail (2.935.3) Subject: Let's back out LOADER_ZFS_SUPPORT from 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: Sat, 13 Jun 2009 20:53:45 -0000 I have now proven that the recent post June 8th version of /usr/src/sys/boot/i386/loader/Makefile causes catastrophic data loss. Why on earth would this change not be immediately rolled back out of the STABLE branch? For those on the bleeding edge with CURRENT they expect to lose their entire drives, but not STABLE users. We need to remove -DLOADER_ZFS_SUPPORT from /usr/src/sys/boot/i386/ loader/Makefile immediately. Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 21:03:09 2009 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 4822510657E3 for ; Sat, 13 Jun 2009 21:03:09 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 04CEB8FC15 for ; Sat, 13 Jun 2009 21:03:08 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 5563 invoked by uid 89); 13 Jun 2009 19:51:16 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 19:51:16 -0000 Message-Id: <4F4C9D30-9B89-469B-A62E-184AA3361813@airwired.net> From: Dan Allen To: "Paul B. Mahol" , John Baldwin , Yuri Pankov , FreeBSD-STABLE Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 15:03:02 -0600 References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> <200906120832.51098.jhb@freebsd.org> <22FB500C-9655-4702-99B8-F6498DD27E2F@airwired.net> <3a142e750906131150p6e960400o8a42ab4973aa26e@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 21:03:10 -0000 On 13 Jun 2009, at 2:41 PM, Dan Allen wrote: > > On 13 Jun 2009, at 12:50 PM, Paul B. Mahol wrote: > >> I doubt it is loader fault, from your description it appears that >> loader is never started. >> >> Could you try to remove -DLOADER_ZFS_SUPPORT from Makefile? >> >>> /usr/src/sys/boot/i386/loader/Makefile > > BINGO! LOADER_ZFS_SUPPORT is the culprit. > > I rebuilt the good world, and brought in the loader changes which > have caused previously caused death to my drive, then deleted the > ZFS_SUPPORT path in /usr/src/sys/boot/i386/loader/Makefile as you > recommended, and rebuilt things and everything works fine. My wording may not have been clear: I simply replaced the errant June 10th version of /usr/src/sys/boot/i386/loader/Makefile with the June 8th version of the same file which simply defaults to no LOADER_ZFS_SUPPORT. Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 21:50:27 2009 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 0CA61106566B for ; Sat, 13 Jun 2009 21:50:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C63578FC0C for ; Sat, 13 Jun 2009 21:50:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1F77873098; Sat, 13 Jun 2009 23:38:06 +0200 (CEST) Date: Sat, 13 Jun 2009 23:38:06 +0200 From: Luigi Rizzo To: Pete French Message-ID: <20090613213806.GA98400@onelab2.iet.unipi.it> References: <20090613195451.GA15509@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, cliftonr@lava.net Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 21:50:27 -0000 On Sat, Jun 13, 2009 at 09:13:34PM +0100, Pete French wrote: > > I'm not 100% sure, but fairly sure that you'll have a hard time > > finding something that combines the low-power standalone type spec with > > a 64-bit capable processor. Once you get the higher-end processor, > > That was my experiense when shopping around yes - annoying as I > don't need anything particularly low power (it ain't going to > be my leccy bill :-). > > > becomes a more likely failure point, and so on. Can you elaborate a > > bit more on which parts of that system spec you really need - do you > > need the GigE? Two ethernets? The external SATA? > > It needs to be: > > 1) Complete as purchased - I dont want to build a machine > 2) Capable of having a simple boot device (e.g. CF card) dropped in > 3) At least one ether port. 100 meg will do. > 4) Small enough to be posted to the end user > 5) Cheap - under 400 euros, preferably 300 the Asus EEEBox might fit the description. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 21:50:53 2009 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 3C288106567E for ; Sat, 13 Jun 2009 21:50:53 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id E87348FC08 for ; Sat, 13 Jun 2009 21:50:52 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so1612395ana.13 for ; Sat, 13 Jun 2009 14:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=v6bTa7XonJaKeY5XCC4s70evvH6Sj+DaflvVOSUvvi8=; b=StAvrgk9293Vzo084Q0K5U/jWqSUKtuyyMgI6CB5u/2JmTVstsDFeCh7W7rWuSFB+N h5xFDSu0aT+atYZL59pyDLzfcAS5Tmfo2ILjhUfW0ejO5me9GwAIfjiIEwbFwWpV0s60 bBUKIvfKvH7YKUvdsa4rTX4Ka1Z6ppgLRftlk= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=dh2zhIyAb3Jo04QLAvXYv21Cz5S5DV3TuhV9dewN4oZpaU7mbM54iHTuLqRYOR8g9+ X+X0sXQR2vrHj1HyOQ1Dpb3gG66JjDnIXl6eVv0z2f7Y0gorPwUz/K6WO8ko6hBqZlRh Zlt8I/LMAXdacLNgUhYVtHwWe+Avx7l0kanV4= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.229.14 with SMTP id b14mr6764848anh.156.1244929852141; Sat, 13 Jun 2009 14:50:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Jun 2009 14:50:52 -0700 X-Google-Sender-Auth: 7061a3bfcea98e01 Message-ID: <3c1674c90906131450o572cef72tae8e891cf56268ec@mail.gmail.com> From: Kip Macy To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List Subject: Re: Let's back out LOADER_ZFS_SUPPORT from 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: Sat, 13 Jun 2009 21:50:53 -0000 On Sat, Jun 13, 2009 at 1:53 PM, Dan Allen wrote: > I have now proven that the recent post June 8th version of > > =A0 =A0 =A0 =A0/usr/src/sys/boot/i386/loader/Makefile > > causes catastrophic data loss. Then it should be disabled by default until the problem is fixed. > Why on earth would this change not be immediately rolled back out of the > STABLE branch? =A0For those on the bleeding edge with CURRENT they expect= to > lose their entire drives, but not STABLE users. > Your word choice indicates that someone has asserted otherwise, when in fact I see no indication that this is the case. -Kip From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 22:11:14 2009 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 0BDE51065670 for ; Sat, 13 Jun 2009 22:11:14 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9D72D8FC12 for ; Sat, 13 Jun 2009 22:11:13 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.245.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id EAEC93A6A4; Sat, 13 Jun 2009 23:55:51 +0200 (SAST) Message-ID: <4A342067.1000603@phat.za.net> Date: Sat, 13 Jun 2009 23:55:51 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 22:11:14 -0000 Hi, Pete French wrote: >> I'm not 100% sure, but fairly sure that you'll have a hard time >> finding something that combines the low-power standalone type spec with >> a 64-bit capable processor. Once you get the higher-end processor, > > That was my experiense when shopping around yes - annoying as I > don't need anything particularly low power (it ain't going to > be my leccy bill :-). The Atom 230 and 330 are supposed to be 64-bit capable: http://ark.intel.com/Compare.aspx?ids=36331,35635,35641, but I have not personally tested either with an AMD64 FreeBSD install. > It needs to be: > > 1) Complete as purchased - I dont want to build a machine > 2) Capable of having a simple boot device (e.g. CF card) dropped in > 3) At least one ether port. 100 meg will do. > 4) Small enough to be posted to the end user > 5) Cheap - under 400 euros, preferably 300 You might consider something like this: http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html Or this which is rack mountable: http://www.tranquilpc-shop.co.uk/acatalog/T2e_300atom_nocd.html Both Atom 330 based and prebuilt. No affiliation with them, but I almost ordered one and found their support to be responsive and helpful. :) Regards, Aragon From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 22:34:26 2009 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 714981065672 for ; Sat, 13 Jun 2009 22:34:26 +0000 (UTC) (envelope-from kline@thought.org) Received: from aristotle.thought.org (ns1.thought.org [209.180.213.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0D77C8FC12 for ; Sat, 13 Jun 2009 22:34:25 +0000 (UTC) (envelope-from kline@thought.org) Received: from thought.org (tao.thought.org [10.47.0.250]) (authenticated bits=0) by aristotle.thought.org (8.14.2/8.14.2) with ESMTP id n5DMZUON052897; Sat, 13 Jun 2009 15:35:30 -0700 (PDT) (envelope-from kline@thought.org) Received: by thought.org (nbSMTP-1.00) for uid 1002 kline@thought.org; Sat, 13 Jun 2009 15:34:14 -0700 (PDT) Date: Sat, 13 Jun 2009 15:34:14 -0700 From: Gary Kline To: Dan Allen Message-ID: <20090613223414.GA28195@thought.org> References: <212AA509-6A5D-4D43-8B02-A31E636A8D40@airwired.net> <3a142e750906111641w73d991a7ld22ff9a9150404e0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: With 22++ years of service to the Unix community. X-Spam-Status: No, score=-4.4 required=3.6 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on aristotle.thought.org Cc: "Paul B. Mahol" , FreeBSD-STABLE Mailing List Subject: Re: Something since June 8th clobbers my disk... 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, 13 Jun 2009 22:34:26 -0000 On Sat, Jun 13, 2009 at 12:41:55PM -0600, Dan Allen wrote: > > On 11 Jun 2009, at 5:41 PM, Paul B. Mahol wrote: > > >Looks like boot(8) is problematic. > > Okay, here is the June 13th noon update to this problem. > > I once again installed a May 28th build. Rebuilt world and kernel > from source. Everything works great. No custom kernel, just GENERIC. > > I then merged in just /usr/src/sys/boot/i386/libi386 changes to June > 10th. Rebuilt in /usr/src/sys/boot and installed it, no problem. > > Then I merged in the latest from /usr/src/sys/boot/i386/loader, > rebuilt, installed, and BOOM. DEATH TO DRIVE. Disk label GONE > again. Hangs after "BIOS drive C: is disk1" at boot. Does not get to > memory check, let alone to the "Welcome to FreeBSD and choose a boot > option" screen. > > CULPRIT REVEALED: > So, there is only one file change in /usr/src/sys/boot/i386/loader > from June 8th to June 10th, which kills my machine very repeatably, > and that is the Makefile. > > Something in /usr/src/sys/boot/i386/loader/Makefile is killing my drive. > > What do I try next? > > Thanks for the help. > > Dan I just checked the timestamped on my ....i386/loader/Makefile. The CVS/RCS v that may show you something is from 07jun09: 1.85.2.4 and if you find what changed between your working build on 28may and failing build, that might isolate it. just my dime's worth :-) gary > > _______________________________________________ > 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" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org For FBSD list: http://transfinite.thought.org/slicejourney.php The 4.98a release of Jottings: http://jottings.thought.org/index.php From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 22:34:50 2009 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 282041065746 for ; Sat, 13 Jun 2009 22:34:50 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id E2E178FC13 for ; Sat, 13 Jun 2009 22:34:49 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFboG-0005gY-Gf; Sat, 13 Jun 2009 23:34:48 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFboG-0004SE-FS; Sat, 13 Jun 2009 23:34:48 +0100 To: aragon@phat.za.net In-Reply-To: <4A342067.1000603@phat.za.net> Message-Id: From: Pete French Date: Sat, 13 Jun 2009 23:34:48 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 22:34:50 -0000 > http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html Now *that* is very much what I am thinking of - OK, I will need to drop in a CF->SATA along with the card, but thats not much hassle. 64 bit and I can add in more RAM than on the other. Thanks, I hadn't realised the new ATonms did 64 bit. -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 22:45:01 2009 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 D1BE81065689 for ; Sat, 13 Jun 2009 22:45:01 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF468FC18 for ; Sat, 13 Jun 2009 22:45:01 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.245.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id EF53F3982F; Sun, 14 Jun 2009 00:44:59 +0200 (SAST) Message-ID: <4A342BEB.1030300@phat.za.net> Date: Sun, 14 Jun 2009 00:44:59 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 22:45:02 -0000 Pete French wrote: >> http://www.tranquilpc-shop.co.uk/acatalog/T7-330_Barebones.html > > Now *that* is very much what I am thinking of - OK, I will need to drop > in a CF->SATA along with the card, but thats not much hassle. 64 bit > and I can add in more RAM than on the other. Thanks, I hadn't realised > the new ATonms did 64 bit. No, I don't think you will need a CF->SATA adapter. A simple CF->ATA adapter should do. Those systems just have an Intel GCLF2 board in them, which has both SATA and ATA: http://www.intel.com/products/desktop/motherboards/D945GCLF2-D945GCLF2D/D945GCLF2-D945GCLF2D-overview.htm Best you mail them to confirm though... They're also fanless. :) Regards, Aragon From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 23:42:19 2009 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 E9550106566C for ; Sat, 13 Jun 2009 23:42:19 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 744028FC17 for ; Sat, 13 Jun 2009 23:42:19 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz7 with SMTP id 7so3014392bwz.19 for ; Sat, 13 Jun 2009 16:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=90JYXuB6/uhuFUGBYxOizuD7f5f2scUkpMsSo0t2Hxo=; b=Ck2AkYuA5whYB6ao3fqvEQQP6WTyvKxOShZX84qZyXt2+frENtjRCB/JTiYpQ/OxG7 k7dI2lU0NsM6OwC+jKJhCA3oKlCnywkJ5dXDN8cpKTb0anUrEnEjGHNbDeSfnIsRl31Y T4+bF5TvMZAWCDDiqJ4MufAPr4jio5tUokTaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oCzTqzK8Hx6NhhPQMocx9zbZByno/Ufx5RxEgDZoOpT19pVeFMQR96nBWibKx2AiJs jNEY+oAD65DeHP4epnDqYGqEOXkFfoy0LZYQdAWxgVpuu5MKrYFpwH52a/Qf3N/z0twr YgqKQfvOyWqWUkrAUDciHbzGRAX1Su+s0UG84= MIME-Version: 1.0 Received: by 10.204.51.210 with SMTP id e18mr5289131bkg.38.1244936538404; Sat, 13 Jun 2009 16:42:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Jun 2009 01:42:18 +0200 Message-ID: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> From: "Paul B. Mahol" To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: Let's back out LOADER_ZFS_SUPPORT from 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: Sat, 13 Jun 2009 23:42:20 -0000 On 6/13/09, Dan Allen wrote: > I have now proven that the recent post June 8th version of > > /usr/src/sys/boot/i386/loader/Makefile > > causes catastrophic data loss. > > Why on earth would this change not be immediately rolled back out of > the STABLE branch? For those on the bleeding edge with CURRENT they > expect to lose their entire drives, but not STABLE users. I hardly doubt that such change cause loss of data on entire drive. There is always old loader to pick up. > We need to remove -DLOADER_ZFS_SUPPORT from /usr/src/sys/boot/i386/ > loader/Makefile immediately. I don't understand why LOADER_ZFS_SUPPORT is not defined by default on CURRENT. -- Paul From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 23:56:50 2009 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 9E6FE1065676 for ; Sat, 13 Jun 2009 23:56:50 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 611058FC21 for ; Sat, 13 Jun 2009 23:56:50 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 1157 invoked by uid 89); 13 Jun 2009 22:44:56 -0000 Received: from unknown (HELO ?192.168.0.18?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 13 Jun 2009 22:44:56 -0000 Message-Id: From: Dan Allen To: "Paul B. Mahol" In-Reply-To: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 13 Jun 2009 17:56:49 -0600 References: <3a142e750906131642n4d00469dh779e54da231bf6d3@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD-STABLE Mailing List Subject: Re: Let's back out LOADER_ZFS_SUPPORT from 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: Sat, 13 Jun 2009 23:56:51 -0000 On 13 Jun 2009, at 5:42 PM, Paul B. Mahol wrote: > On 6/13/09, Dan Allen wrote: >> I have now proven that the recent post June 8th version of >> >> /usr/src/sys/boot/i386/loader/Makefile >> >> causes catastrophic data loss. >> > > I hardly doubt that such change cause loss of data on entire drive. > There is always old loader to pick up. How do I get to the old loader when the machine boots and immediately stops? There is no ability at this point in the boot process to try and get to the old loader that I know of. Is there a hidden magic key combination that allows this? You are correct that the bulk of the file system is not touched, but the key file partitioning headers get cleared and when you boot off of a DVD -- the only way to get to the system that I know of -- and inspect the file partitioning via whatever means you try, it shows that the root partition is gone. What was your main file system is gone. I learned after many installs that I could NOT do a newfs(8) and the setup program would re-mark things and and files ended up re- appearing. My machine was well backed up so no great loss of data in the end, but it has cost me lots of time to get this figured out. For me the real questions are these: * Why is my system the only one that this happens on? * What makes my machine setup different? * What is the bug in the bootable ZFS loader that munges the partition map? Dan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 13 23:57:54 2009 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 B7E8B10656AE for ; Sat, 13 Jun 2009 23:57:54 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [207.246.88.226]) by mx1.freebsd.org (Postfix) with ESMTP id 813078FC15 for ; Sat, 13 Jun 2009 23:57:54 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from localhost (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id E664A9E95; Sat, 13 Jun 2009 19:41:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at bit0.com Received: from magnum.bit0.com ([127.0.0.1]) by localhost (magnum.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHrvCTjctYos; Sat, 13 Jun 2009 19:41:22 -0400 (EDT) Received: from beast.int.bit0.com (beast.int.bit0.com [172.27.0.2]) by magnum.bit0.com (Postfix) with ESMTP; Sat, 13 Jun 2009 19:41:21 -0400 (EDT) Date: Sat, 13 Jun 2009 19:41:21 -0400 (EDT) From: Mike Andrews X-X-Sender: mandrews@beast.int.bit0.com To: Aragon Gouveia In-Reply-To: <4A342067.1000603@phat.za.net> Message-ID: References: <4A342067.1000603@phat.za.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Pete French Subject: Re: reecommendations for an 'appliance" platform ? 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, 13 Jun 2009 23:57:55 -0000 On Sat, 13 Jun 2009, Aragon Gouveia wrote: > Hi, > > Pete French wrote: >>> I'm not 100% sure, but fairly sure that you'll have a hard time >>> finding something that combines the low-power standalone type spec with >>> a 64-bit capable processor. Once you get the higher-end processor, >> >> That was my experiense when shopping around yes - annoying as I >> don't need anything particularly low power (it ain't going to >> be my leccy bill :-). > > The Atom 230 and 330 are supposed to be 64-bit capable: > > http://ark.intel.com/Compare.aspx?ids=36331,35635,35641, > > but I have not personally tested either with an AMD64 FreeBSD install. I have a Supermicro 5015A-H on the way, which is a 1U rackmount Atom 330 box, and am planning to run 7.2-STABLE amd64 on it. We'll see how it goes. No flash card slots, so you'd need adapters -- I was just going to use a pair of leftover 2.5" disks I had on the shelf.