From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 05:19:36 2010 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 EEFDD1065694; Sun, 22 Aug 2010 05:19:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4238FC08; Sun, 22 Aug 2010 05:19:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7M5JZhm077261; Sun, 22 Aug 2010 01:19:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7M5JZFQ077241; Sun, 22 Aug 2010 05:19:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 22 Aug 2010 05:19:35 GMT Message-Id: <201008220519.o7M5JZFQ077241@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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: Sun, 22 Aug 2010 05:19:37 -0000 TB --- 2010-08-22 03:13:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-22 03:13:44 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-08-22 03:13:44 - cleaning the object tree TB --- 2010-08-22 03:14:41 - cvsupping the source tree TB --- 2010-08-22 03:14:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-08-22 03:15:12 - building world TB --- 2010-08-22 03:15:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 03:15:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 03:15:12 - TARGET=amd64 TB --- 2010-08-22 03:15:12 - TARGET_ARCH=amd64 TB --- 2010-08-22 03:15:12 - TZ=UTC TB --- 2010-08-22 03:15:12 - __MAKE_CONF=/dev/null TB --- 2010-08-22 03:15:12 - cd /src TB --- 2010-08-22 03:15:12 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 03:15:13 UTC 2010 >>> 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 Sun Aug 22 04:53:45 UTC 2010 TB --- 2010-08-22 04:53:45 - generating LINT kernel config TB --- 2010-08-22 04:53:45 - cd /src/sys/amd64/conf TB --- 2010-08-22 04:53:45 - /usr/bin/make -B LINT TB --- 2010-08-22 04:53:45 - building LINT kernel TB --- 2010-08-22 04:53:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 04:53:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 04:53:45 - TARGET=amd64 TB --- 2010-08-22 04:53:45 - TARGET_ARCH=amd64 TB --- 2010-08-22 04:53:45 - TZ=UTC TB --- 2010-08-22 04:53:45 - __MAKE_CONF=/dev/null TB --- 2010-08-22 04:53:45 - cd /src TB --- 2010-08-22 04:53:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 04:53:45 UTC 2010 >>> 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 -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1! 999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1! 999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1! 999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1! 999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1! 999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3615: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3614: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 05:19:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 05:19:35 - ERROR: failed to build lint kernel TB --- 2010-08-22 05:19:35 - 5085.73 user 1451.85 system 7551.16 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 06:14:49 2010 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 6F2001065670; Sun, 22 Aug 2010 06:14:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB6E8FC08; Sun, 22 Aug 2010 06:14:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7M6EmoN000819; Sun, 22 Aug 2010 02:14:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7M6EmMb000817; Sun, 22 Aug 2010 06:14:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 22 Aug 2010 06:14:48 GMT Message-Id: <201008220614.o7M6EmMb000817@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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: Sun, 22 Aug 2010 06:14:49 -0000 TB --- 2010-08-22 04:37:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-22 04:37:21 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-08-22 04:37:21 - cleaning the object tree TB --- 2010-08-22 04:38:09 - cvsupping the source tree TB --- 2010-08-22 04:38:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-08-22 04:38:43 - building world TB --- 2010-08-22 04:38:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 04:38:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 04:38:43 - TARGET=i386 TB --- 2010-08-22 04:38:43 - TARGET_ARCH=i386 TB --- 2010-08-22 04:38:43 - TZ=UTC TB --- 2010-08-22 04:38:43 - __MAKE_CONF=/dev/null TB --- 2010-08-22 04:38:43 - cd /src TB --- 2010-08-22 04:38:43 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 04:38:43 UTC 2010 >>> 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 Aug 22 05:46:08 UTC 2010 TB --- 2010-08-22 05:46:08 - generating LINT kernel config TB --- 2010-08-22 05:46:08 - cd /src/sys/i386/conf TB --- 2010-08-22 05:46:08 - /usr/bin/make -B LINT TB --- 2010-08-22 05:46:08 - building LINT kernel TB --- 2010-08-22 05:46:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 05:46:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 05:46:08 - TARGET=i386 TB --- 2010-08-22 05:46:08 - TARGET_ARCH=i386 TB --- 2010-08-22 05:46:08 - TZ=UTC TB --- 2010-08-22 05:46:08 - __MAKE_CONF=/dev/null TB --- 2010-08-22 05:46:08 - cd /src TB --- 2010-08-22 05:46:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 05:46:08 UTC 2010 >>> 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 -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3615: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3614: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 06:14:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 06:14:48 - ERROR: failed to build lint kernel TB --- 2010-08-22 06:14:48 - 3987.97 user 1092.66 system 5847.34 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 06:15:53 2010 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 75238106566B; Sun, 22 Aug 2010 06:15:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 430988FC18; Sun, 22 Aug 2010 06:15:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7M6FqQq003822; Sun, 22 Aug 2010 02:15:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7M6Fqax003818; Sun, 22 Aug 2010 06:15:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 22 Aug 2010 06:15:52 GMT Message-Id: <201008220615.o7M6Fqax003818@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 22 Aug 2010 06:15:53 -0000 TB --- 2010-08-22 04:42:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-22 04:42:19 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-08-22 04:42:19 - cleaning the object tree TB --- 2010-08-22 04:43:06 - cvsupping the source tree TB --- 2010-08-22 04:43:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-08-22 04:43:39 - building world TB --- 2010-08-22 04:43:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 04:43:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 04:43:39 - TARGET=pc98 TB --- 2010-08-22 04:43:39 - TARGET_ARCH=i386 TB --- 2010-08-22 04:43:39 - TZ=UTC TB --- 2010-08-22 04:43:39 - __MAKE_CONF=/dev/null TB --- 2010-08-22 04:43:39 - cd /src TB --- 2010-08-22 04:43:39 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 04:43:39 UTC 2010 >>> 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 Aug 22 05:50:47 UTC 2010 TB --- 2010-08-22 05:50:47 - generating LINT kernel config TB --- 2010-08-22 05:50:47 - cd /src/sys/pc98/conf TB --- 2010-08-22 05:50:47 - /usr/bin/make -B LINT TB --- 2010-08-22 05:50:47 - building LINT kernel TB --- 2010-08-22 05:50:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 05:50:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 05:50:47 - TARGET=pc98 TB --- 2010-08-22 05:50:47 - TARGET_ARCH=i386 TB --- 2010-08-22 05:50:47 - TZ=UTC TB --- 2010-08-22 05:50:47 - __MAKE_CONF=/dev/null TB --- 2010-08-22 05:50:47 - cd /src TB --- 2010-08-22 05:50:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 05:50:48 UTC 2010 >>> 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 -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3615: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3614: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 06:15:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 06:15:52 - ERROR: failed to build lint kernel TB --- 2010-08-22 06:15:52 - 3788.41 user 1091.30 system 5613.30 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 07:10:46 2010 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 9E1951065670 for ; Sun, 22 Aug 2010 07:10:46 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 812FF8FC21 for ; Sun, 22 Aug 2010 07:10:46 +0000 (UTC) Received: from ns1.jnielsen.net (jn@ns1 [69.55.238.237]) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id o7M7Ajcr029040; Sun, 22 Aug 2010 03:10:46 -0400 (EDT) (envelope-from lists@jnielsen.net) Received: (from www@localhost) by ns1.jnielsen.net (8.12.9p2/8.12.9/Submit) id o7M7Aj6j029039; Sun, 22 Aug 2010 03:10:45 -0400 (EDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: ns1.jnielsen.net: www set sender to lists@jnielsen.net using -f Received: from stealth.jnielsen.net (stealth.jnielsen.net [74.218.226.254]) by newwebmail.jnielsen.net (Horde MIME library) with HTTP; Sun, 22 Aug 2010 03:10:45 -0400 Message-ID: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> Date: Sun, 22 Aug 2010 03:10:45 -0400 From: John Nielsen To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) / FreeBSD-4.9 X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: gshapiro@freebsd.org Subject: Apparent dnsbl bug in Sendmail or m4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 07:10:46 -0000 I'm migrating a sendmail server from FreeBSD 4.x to FreeBSD 8.x. After turning on the new server and feeding it some "live" e-mail, I noticed that the DNS blacklist lookups weren't actually rejecting e-mail like they did on the old server. (Actually the presence of blacklist information in the SpamAssassin report on an unwanted message that was delivered and a total lack of them in the sendmail logs (versus a steady stream on the old server).) I double-checked the syntax of my .mc file, re-ran "cd /etc/mail; make", and examined the resulting .cf file. While I saw lines referencing each dnsbl I included in the .mc, all of the error clauses were missing. My .mc file includes this line on both servers: FEATURE(dnsbl, `bl.spamcop.net', `"550 Mail from " $&{client_addr} " rejected, see http://spamcop.net/bl.shtml?" $&{client_addr}') On the FreeBSD 4.x server, this is the corresponding section in the .cf file: # DNS based IP address spam list bl.spamcop.net R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.bl.spamcop.net. $: OK $) ROK $: OKSOFAR R$+ $: TMPOK R$+ $#error $@ 5.7.1 $: "550 Mail from " $&{client_addr} " rejected, s ee http://spamcop.net/bl.shtml?" $&{client_addr} On the FreeBSD 8.x server, this is the corresponding section: # DNS based IP address spam list bl.spamcop.net R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.bl.spamcop.net. $: OK $) ROK $: OKSOFAR R$+ $: TMPOK Note that the last line (containing the "error" clause and custom 550 message) is absent from the new server's file. I know next to nothing about m4, but I compared the cf/feature/dnsbl.m4 files on the two machines and noticed that the newer version has an "ifelse" statement to handle 'quarantine' or 'discard' keywords that is not present in the older version. I counted the arguments and compared them to the documented behavior of "ifelse" and didn't see any glaring problems, but the correct output string from the statement simply does not appear in the .cf file. Apparently this is the only case that causes the ifelse statement to not produce any output. Omitting the custom error message, specifying 'discard' or specifying 'quarantine' all produce a suitable action line in the output (error with default message, discard or quarantine, respectively). So just specifying e.g. "FEATURE(dnsbl, `bl.spamcop.net')" is one workaround. Since I don't use the 'quarantine' or 'discard' keywords I doctored the dnsbl.m4 file to remove the final "ifelse" statement and always output the error clause. That allowed me to produce a .cf file which included the appropriate error clauses and customized 550 error messages. This is an issue on FreeBSD 7.2 and 8.1 (and probably -CURRENT, but I don't have a test machine handy), but not on 4.9 (I know, old). For kicks I tried substituting gm4 from ports for m4 in the base but got the same results. I also verified that a simple macro containing an "ifelse" statement with seven arguments works as expected, including printing the seventh argument if both comparisons (1&2 and 4&5) are false. So--I'm stumped. I do have the workarounds I mentioned but now that I've encountered this mystery I would like to see it solved. Can anyone help unravel it? Thanks, JN From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 07:36:42 2010 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 E87D110656A8; Sun, 22 Aug 2010 07:36:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 84BB48FC12; Sun, 22 Aug 2010 07:36:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7M7afuf058419; Sun, 22 Aug 2010 03:36:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7M7afTd058418; Sun, 22 Aug 2010 07:36:41 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 22 Aug 2010 07:36:41 GMT Message-Id: <201008220736.o7M7afTd058418@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 22 Aug 2010 07:36:43 -0000 TB --- 2010-08-22 06:15:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-22 06:15:46 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-08-22 06:15:46 - cleaning the object tree TB --- 2010-08-22 06:16:20 - cvsupping the source tree TB --- 2010-08-22 06:16:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-08-22 06:17:08 - building world TB --- 2010-08-22 06:17:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 06:17:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 06:17:08 - TARGET=sparc64 TB --- 2010-08-22 06:17:08 - TARGET_ARCH=sparc64 TB --- 2010-08-22 06:17:08 - TZ=UTC TB --- 2010-08-22 06:17:08 - __MAKE_CONF=/dev/null TB --- 2010-08-22 06:17:08 - cd /src TB --- 2010-08-22 06:17:08 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 06:17:08 UTC 2010 >>> 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 Aug 22 07:17:31 UTC 2010 TB --- 2010-08-22 07:17:31 - generating LINT kernel config TB --- 2010-08-22 07:17:31 - cd /src/sys/sparc64/conf TB --- 2010-08-22 07:17:31 - /usr/bin/make -B LINT TB --- 2010-08-22 07:17:31 - building LINT kernel TB --- 2010-08-22 07:17:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 07:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 07:17:31 - TARGET=sparc64 TB --- 2010-08-22 07:17:31 - TARGET_ARCH=sparc64 TB --- 2010-08-22 07:17:31 - TZ=UTC TB --- 2010-08-22 07:17:31 - __MAKE_CONF=/dev/null TB --- 2010-08-22 07:17:31 - cd /src TB --- 2010-08-22 07:17:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 07:17:31 UTC 2010 >>> 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 -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3615: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3614: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 07:36:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 07:36:41 - ERROR: failed to build lint kernel TB --- 2010-08-22 07:36:41 - 3627.22 user 920.63 system 4855.60 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 08:01:14 2010 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 2464C106566C for ; Sun, 22 Aug 2010 08:01:14 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id DBDCB8FC18 for ; Sun, 22 Aug 2010 08:01:13 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id E070E93A72; Sun, 22 Aug 2010 08:00:56 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> Date: Sun, 22 Aug 2010 10:00:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> To: John Nielsen X-Mailer: Apple Mail (2.1081) Cc: gshapiro@freebsd.org, FreeBSD Stable Subject: Re: Apparent dnsbl bug in Sendmail or m4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 08:01:14 -0000 Am 22.08.2010 um 09:10 schrieb John Nielsen: > FEATURE(dnsbl, `bl.spamcop.net', `"550 Mail from " $&{client_addr} " = rejected, see http://spamcop.net/bl.shtml?" $&{client_addr}') >=20 > On the FreeBSD 4.x server, this is the corresponding section in the = .cf file: >=20 > # DNS based IP address spam list bl.spamcop.net > R$* $: $&{client_addr} > R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.bl.spamcop.net. $: = OK $) > ROK $: OKSOFAR > R$+ $: TMPOK > R$+ $#error $@ 5.7.1 $: "550 Mail from " = $&{client_addr} " rejected, s > ee http://spamcop.net/bl.shtml?" $&{client_addr} >=20 > On the FreeBSD 8.x server, this is the corresponding section: >=20 > # DNS based IP address spam list bl.spamcop.net > R$* $: $&{client_addr} > R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.bl.spamcop.net. $: = OK $) > ROK $: OKSOFAR > R$+ $: TMPOK I've got: FEATURE(`dnsbl', `ix.dnsbl.manitu.net',`"550 Rejected - see = http://www.heise.de/ix/nixspam/nixspam.blackmatches"')dnl in my .mc, and get this in my .cf: # DNS based IP address spam list ix.dnsbl.manitu.net R$* $: $&{client_addr} R$-.$-.$-.$- $: $(dnsbl $4.$3.$2.$1.ix.dnsbl.manitu.net. = $: OK $) ROK $: OKSOFAR R$+ $: TMPOK R$+ $#error $@ 5.7.1 $: "550 Rejected - see = http://www.heise.de/ix/nixspam/nixspam.blackmatches" This is on 8.1 from July 15th. I just ran make all again, and it stays = the same. Fired up my VMware image with a three-day old -stable, and put both mine = and yours in, and yours is missing the error line. I experimented a bit, and it appears that the macro does not like having = the $&{client_addr} at the very end of the parameter. If I add "", it = starts working. No idea how or why, but there you go :-) FEATURE(`dnsbl', `bl.spamcop.net', `"550 " $&{client_addr} "foo" = $&{client_addr} ""')dnl Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 10:28:35 2010 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 765A710656A3 for ; Sun, 22 Aug 2010 10:28:35 +0000 (UTC) (envelope-from n.kalpazanov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD968FC17 for ; Sun, 22 Aug 2010 10:28:34 +0000 (UTC) Received: by vws7 with SMTP id 7so5169027vws.13 for ; Sun, 22 Aug 2010 03:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Uz8Lfm1bO7XS4W41dJgnMSkDnGCQZulPhnu5hHq/0gk=; b=kf52m7ghE/CCPTv/GBhksrWWC1x65LVZ+RPBUJ3FkW/M+TkgdKTkKkPDmFDLvmVK+0 /cbwnPT/LPHkDg/G9R4jR62UfKp6gIXChw+/e48blZtO6q4b2lVcpxhqPeiAm2Rl7BSQ 2b7b6NcZiCiLscVULTdqbmiFQ07OMAPpZEIKU= 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=JNguOkkFD2Cyk/6gsoCcD0eCxuND7URDiA3aIms7huIqf7RUfWjmf15+3tJXhTnZO3 JXemw8E1uIBu6tK7dX96tBEdZpDunNoU4bBNSKG0sUWV4AjBmbB96lYdXjVJOHtmoVP4 /SoknnGDt/2P6S0RPjs00gn9waaD+Xa4luXqs= MIME-Version: 1.0 Received: by 10.220.60.204 with SMTP id q12mr2346887vch.183.1282472914290; Sun, 22 Aug 2010 03:28:34 -0700 (PDT) Received: by 10.220.194.136 with HTTP; Sun, 22 Aug 2010 03:28:34 -0700 (PDT) In-Reply-To: <20100820174022.GA21062@michelle.cdnetworks.com> References: <20100820174022.GA21062@michelle.cdnetworks.com> Date: Sun, 22 Aug 2010 12:28:34 +0200 Message-ID: From: Nikola Kalpazanov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com Subject: Re: P811B Quad Port NIC problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 10:28:35 -0000 Hi, I applied the patch provided by Pyun YongHyeon to the rl driver. Then put hint.rl.0.prefer_iomap=3D"0" # for rl0 hint.rl.1.prefer_iomap=3D"0" # for rl1 hint.rl.3.prefer_iomap=3D"0" # for rl3 and all 3 adapters are now working fine. I absolutely agree that Realtek makes low-end adapters. But in my case scenario I am building a router with WiFi access point and this particular device allows me to do it on mini-ITX board ( single PCI slot ). Again ... I want to send my thanks and regards to Pyun for making this possible for me. Regards, Nikola On Fri, Aug 20, 2010 at 7:40 PM, Pyun YongHyeon wrote: > On Fri, Aug 20, 2010 at 01:44:20PM +0200, Nikola Kalpazanov wrote: >> Hi, >> >> First I want to start with the note that I know Realtek is no good, >> yet I will appreciate any assistance that you may provide. >> >> here are details of the problem: >> >> P811B is 4 port Ethernet card with built-in mini-PCI slot where I have >> attached Atheros 802.11a/b/g/n Wireless PCI Adapter (AR5416). >> That also requires to disable 4th port from the jumpers on the card. >> >> I have installed FreeBSD 8.1-RELEASE i386 >> >> pciconf -vlb >> >> pcib6@pci0:5:0:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x00000000 chip=3D= 0x814812d8 >> rev=3D0x00 hdr=3D0x01 >> =A0 =A0 vendor =A0 =A0 =3D 'Pericom Semiconductor' >> =A0 =A0 class =A0 =A0 =A0=3D bridge >> =A0 =A0 subclass =A0 =3D PCI-PCI >> rl0@pci0:6:8:0: class=3D0x020000 card=3D0x813910ec chip=3D0x813910ec rev= =3D0x10 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Realtek Semiconductor' >> =A0 =A0 device =A0 =A0 =3D 'Realtek RTL8139 Family PCI Fast Ethernet NIC >> (RTL-8139/8139C/8139D)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> =A0 =A0 bar =A0 [14] =3D type Memory, range 32, base 0xe0110200, size 25= 6, enabled >> rl1@pci0:6:9:0: class=3D0x020000 card=3D0x813910ec chip=3D0x813910ec rev= =3D0x10 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Realtek Semiconductor' >> =A0 =A0 device =A0 =A0 =3D 'Realtek RTL8139 Family PCI Fast Ethernet NIC >> (RTL-8139/8139C/8139D)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> =A0 =A0 bar =A0 [14] =3D type Memory, range 32, base 0xe0110100, size 25= 6, enabled >> rl2@pci0:6:10:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x813910ec chip= =3D0x813910ec >> rev=3D0x10 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Realtek Semiconductor' >> =A0 =A0 device =A0 =A0 =3D 'Realtek RTL8139 Family PCI Fast Ethernet NIC >> (RTL-8139/8139C/8139D)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> =A0 =A0 bar =A0 [10] =3D type I/O Port, range 32, base 0x1000, size 256,= enabled >> =A0 =A0 bar =A0 [14] =3D type Memory, range 32, base 0xe0110000, size 25= 6, enabled >> ath0@pci0:6:11:0: =A0 =A0 =A0 class=3D0x028000 card=3D0x2071168c chip=3D= 0x0023168c >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Atheros Communications Inc.' >> =A0 =A0 device =A0 =A0 =3D '802.11a/b/g/n Wireless PCI Adapter (AR5416)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 bar =A0 [10] =3D type Memory, range 32, base 0xe0100000, size 65= 536, enabled >> >> >> >> dmesg >> >> rl0: port 0x1200-0x12ff mem >> 0xe0110200-0xe01102ff irq 21 at device 8.0 on pci6 >> rl0: reset never completed! >> rl0: unknown device ID: ffff assuming 8139 >> rl0: MII without any phy! >> device_attach: rl0 attach returned 6 >> rl1: port 0x1100-0x11ff mem >> 0xe0110100-0xe01101ff irq 22 at device 9.0 on pci6 >> rl1: reset never completed! >> rl1: unknown device ID: ffff assuming 8139 >> rl1: MII without any phy! >> device_attach: rl1 attach returned 6 >> rl2: port 0x1000-0x10ff mem >> 0xe0110000-0xe01100ff irq 23 at device 10.0 on pci6 >> miibus1: on rl2 >> rlphy0: PHY 0 on miibus1 >> rlphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> rl2: Ethernet address: 00:06:4f:67:08:f5 >> rl2: [ITHREAD] >> rl2: link state changed to DOWN >> >> >> ath0 works fine >> rl2 works fine >> >> rl0 and rl1 don't and of course as you may suspect they are missing >> from ifconfig -a >> >> if I remove the miniPCI Atheros and enable 4th port it is the same >> picture but this time 4th port rl3 works fine and rl0, rl1, and rl2 >> don't in the same way. >> >> Any suggestions will be much appreciated. > > What makes me wonder is that both pci0:6:8:0 and pci0:6:9:0 has no > I/O BAR. I never saw these kind of thing on rl(4) controllers. > And I can't explain how rl(4) could successfully map the I/O with > non-existing I/O BAR. > Anyway would you try attached patch and let me know whether it > makes any difference? Also add the following line to > /boot/device.hints to have rl(4) use memory mapped mapping. > > hint.rl.0.prefer_iomap=3D"0" > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 10:40:32 2010 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 4305B1065696; Sun, 22 Aug 2010 10:40:32 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0694A8FC0A; Sun, 22 Aug 2010 10:40:31 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3C45B93E9B; Sun, 22 Aug 2010 10:40:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sun, 22 Aug 2010 12:40:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> To: John Nielsen X-Mailer: Apple Mail (2.1081) Cc: gshapiro@freebsd.org, FreeBSD Stable Subject: Re: Apparent dnsbl bug in Sendmail or m4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 10:40:32 -0000 Am 22.08.2010 um 10:00 schrieb Stefan Bethke: > FEATURE(`dnsbl', `bl.spamcop.net', `"550 " $&{client_addr} "foo" = $&{client_addr} ""')dnl The real culprit is the comma. I believe the problem stems from = unquoted use of the arguments in some of the ifelses, where the comma = turns the single argument into two. Tracing the ifelses with -d aceq I = see this for the last ifelse in cf/feature/dnsbl.m4: m4trace: -1- ifelse(`X"550 Mail from " $&{client_addr} " rejected', `see = http://spamcop.net/bl.shtml?" $&{client_addr}', `Xquarantine', `R$+ = $#error $@ quarantine $: _DNSBL_SRV_', `X"550 Mail from " = $&{client_addr} " rejected', ` see http://spamcop.net/bl.shtml?" $&{client_addr}', `Xdiscard', `R$+ = =20 $#discard $: _DNSBL_SRV_', `R$+ $#error $@ 5.7.1 $: = _DNSBL_MSG_' ) -> ??? m4trace: -1- ifelse(...) -> `' m4trace: -1- ifelse ... I've never managed to really wrap my head around m4 quoting, but the = easy fix is to use some other character that has no meaning to m4. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 11:22:47 2010 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 13E521065674; Sun, 22 Aug 2010 11:22:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A09C58FC1C; Sun, 22 Aug 2010 11:22:45 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o7MBMhG9058151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 07:22:43 -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.4/8.14.4) with ESMTP id o7MBMhC0044247; Sun, 22 Aug 2010 07:22:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id EC9521B5060; Sun, 22 Aug 2010 07:22:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100822112242.EC9521B5060@freebsd-stable.sentex.ca> Date: Sun, 22 Aug 2010 07:22:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 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: Sun, 22 Aug 2010 11:22:47 -0000 TB --- 2010-08-22 09:26:07 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-08-22 09:26:07 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-08-22 09:26:07 - cleaning the object tree TB --- 2010-08-22 09:26:46 - cvsupping the source tree TB --- 2010-08-22 09:26:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-08-22 09:26:56 - building world TB --- 2010-08-22 09:26:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 09:26:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 09:26:56 - TARGET=amd64 TB --- 2010-08-22 09:26:56 - TARGET_ARCH=amd64 TB --- 2010-08-22 09:26:56 - TZ=UTC TB --- 2010-08-22 09:26:56 - __MAKE_CONF=/dev/null TB --- 2010-08-22 09:26:56 - cd /src TB --- 2010-08-22 09:26:56 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 09:26:57 UTC 2010 >>> 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 Sun Aug 22 10:57:20 UTC 2010 TB --- 2010-08-22 10:57:20 - generating LINT kernel config TB --- 2010-08-22 10:57:20 - cd /src/sys/amd64/conf TB --- 2010-08-22 10:57:20 - /usr/bin/make -B LINT TB --- 2010-08-22 10:57:20 - building LINT kernel TB --- 2010-08-22 10:57:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 10:57:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 10:57:20 - TARGET=amd64 TB --- 2010-08-22 10:57:20 - TARGET_ARCH=amd64 TB --- 2010-08-22 10:57:20 - TZ=UTC TB --- 2010-08-22 10:57:20 - __MAKE_CONF=/dev/null TB --- 2010-08-22 10:57:20 - cd /src TB --- 2010-08-22 10:57:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 10:57:20 UTC 2010 >>> 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 -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnes ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3300: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3299: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 11:22:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 11:22:42 - ERROR: failed to build lint kernel TB --- 2010-08-22 11:22:42 - 5896.32 user 600.12 system 6994.84 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 12:16:10 2010 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 1DBFC10656A7; Sun, 22 Aug 2010 12:16:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DB6EE8FC14; Sun, 22 Aug 2010 12:16:09 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o7MCG7O9060590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 08:16:07 -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.4/8.14.4) with ESMTP id o7MCG7og000581; Sun, 22 Aug 2010 08:16:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 4A8551B5060; Sun, 22 Aug 2010 08:16:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100822121607.4A8551B5060@freebsd-stable.sentex.ca> Date: Sun, 22 Aug 2010 08:16:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 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: Sun, 22 Aug 2010 12:16:10 -0000 TB --- 2010-08-22 10:42:23 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-08-22 10:42:23 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-08-22 10:42:23 - cleaning the object tree TB --- 2010-08-22 10:42:50 - cvsupping the source tree TB --- 2010-08-22 10:42:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-08-22 10:43:03 - building world TB --- 2010-08-22 10:43:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 10:43:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 10:43:03 - TARGET=i386 TB --- 2010-08-22 10:43:03 - TARGET_ARCH=i386 TB --- 2010-08-22 10:43:03 - TZ=UTC TB --- 2010-08-22 10:43:03 - __MAKE_CONF=/dev/null TB --- 2010-08-22 10:43:03 - cd /src TB --- 2010-08-22 10:43:03 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 10:43:05 UTC 2010 >>> 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 Aug 22 11:47:32 UTC 2010 TB --- 2010-08-22 11:47:32 - generating LINT kernel config TB --- 2010-08-22 11:47:32 - cd /src/sys/i386/conf TB --- 2010-08-22 11:47:32 - /usr/bin/make -B LINT TB --- 2010-08-22 11:47:32 - building LINT kernel TB --- 2010-08-22 11:47:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 11:47:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 11:47:32 - TARGET=i386 TB --- 2010-08-22 11:47:32 - TARGET_ARCH=i386 TB --- 2010-08-22 11:47:32 - TZ=UTC TB --- 2010-08-22 11:47:32 - __MAKE_CONF=/dev/null TB --- 2010-08-22 11:47:32 - cd /src TB --- 2010-08-22 11:47:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 11:47:32 UTC 2010 >>> 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 -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3300: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3299: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 12:16:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 12:16:07 - ERROR: failed to build lint kernel TB --- 2010-08-22 12:16:07 - 4768.73 user 439.26 system 5623.50 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 12:51:26 2010 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 70315106564A; Sun, 22 Aug 2010 12:51: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 40A488FC14; Sun, 22 Aug 2010 12:51:25 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o7MCpNd2062428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Aug 2010 08:51:23 -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.4/8.14.4) with ESMTP id o7MCpNN6020182; Sun, 22 Aug 2010 08:51:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 9DF301B5060; Sun, 22 Aug 2010 08:51:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20100822125123.9DF301B5060@freebsd-stable.sentex.ca> Date: Sun, 22 Aug 2010 08:51:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 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: Sun, 22 Aug 2010 12:51:26 -0000 TB --- 2010-08-22 11:22:42 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-08-22 11:22:42 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2010-08-22 11:22:43 - cleaning the object tree TB --- 2010-08-22 11:23:07 - cvsupping the source tree TB --- 2010-08-22 11:23:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2010-08-22 11:23:17 - building world TB --- 2010-08-22 11:23:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 11:23:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 11:23:17 - TARGET=pc98 TB --- 2010-08-22 11:23:17 - TARGET_ARCH=i386 TB --- 2010-08-22 11:23:17 - TZ=UTC TB --- 2010-08-22 11:23:17 - __MAKE_CONF=/dev/null TB --- 2010-08-22 11:23:17 - cd /src TB --- 2010-08-22 11:23:17 - /usr/bin/make -B buildworld >>> World build started on Sun Aug 22 11:23:18 UTC 2010 >>> 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 Aug 22 12:27:22 UTC 2010 TB --- 2010-08-22 12:27:22 - generating LINT kernel config TB --- 2010-08-22 12:27:22 - cd /src/sys/pc98/conf TB --- 2010-08-22 12:27:22 - /usr/bin/make -B LINT TB --- 2010-08-22 12:27:22 - building LINT kernel TB --- 2010-08-22 12:27:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-22 12:27:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-22 12:27:22 - TARGET=pc98 TB --- 2010-08-22 12:27:22 - TARGET_ARCH=i386 TB --- 2010-08-22 12:27:22 - TZ=UTC TB --- 2010-08-22 12:27:22 - __MAKE_CONF=/dev/null TB --- 2010-08-22 12:27:22 - cd /src TB --- 2010-08-22 12:27:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 22 12:27:22 UTC 2010 >>> 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 -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pr ototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3300: error: redefinition of 'available_memory' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3299: error: previous definition of 'available_memory' was here *** Error code 1 Stop in /src/sys/modules/zfs. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-22 12:51:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-22 12:51:23 - ERROR: failed to build lint kernel TB --- 2010-08-22 12:51:23 - 4514.30 user 433.53 system 5320.52 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 12:55:31 2010 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 B02B1106566B for ; Sun, 22 Aug 2010 12:55:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5BB8FC19 for ; Sun, 22 Aug 2010 12:55:31 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32F045.dip.t-dialin.net [91.50.240.69]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id CC10D84400C; Sun, 22 Aug 2010 14:55:23 +0200 (CEST) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 2193D15EC; Sun, 22 Aug 2010 14:55:19 +0200 (CEST) Date: Sun, 22 Aug 2010 14:55:15 +0200 From: Alexander Leidinger To: jhell Message-ID: <20100822145515.00006bc6@unknown> In-Reply-To: <4C703737.3020007@DataIX.net> References: <4C6F5344.6040808@DataIX.net> <20100821215052.000030f1@unknown> <4C703737.3020007@DataIX.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: CC10D84400C.A47BA X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1283086529.28335@mjHpOwitc6ppiQMC/z59bw X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: daily run output 800.scrub-zfs fixups X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 12:55:31 -0000 On Sat, 21 Aug 2010 16:29:43 -0400 jhell wrote: > Also I just noticed another confusing message 'at least for me' that > said "starting first scrubbing (after reboot) of pool 'exports'". I > read that like it is going to scrub the pool after the next reboot. I > actually had to open up the script to double check that was not the > case. The new attached patch changes the message to "starting scrub of > pool 'pool'" so there is no confusion of when the scrub is actually > going to happen. Background info for this part: On every reboot the info from the last scrub is lost (except in the history output). What this part of the message was meant to do is, to tell that there was no scrub since the last boot (this is the first scrub since boot). Would it be less confusing for you if I change starting first scrubbing (after reboot) of pool X to starting first scrub (since last boot) of pool X ? Bye, Alexander. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 13:08:56 2010 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 22EB61065693 for ; Sun, 22 Aug 2010 13:08:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id D4BFA8FC19 for ; Sun, 22 Aug 2010 13:08:55 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32F045.dip.t-dialin.net [91.50.240.69]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E9E5484400C; Sun, 22 Aug 2010 15:08:50 +0200 (CEST) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 4E5BC15EE; Sun, 22 Aug 2010 15:08:45 +0200 (CEST) Date: Sun, 22 Aug 2010 15:08:42 +0200 From: Alexander Leidinger To: jhell Message-ID: <20100822150842.00005129@unknown> In-Reply-To: <4C6F5344.6040808@DataIX.net> References: <4C6F5344.6040808@DataIX.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E9E5484400C.A3354 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1283087334.11183@ls1taVt8Xacda7tWmurRCw X-EBL-Spam-Status: No Cc: FreeBSD Stable Subject: Re: daily run output 800.scrub-zfs fixups X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 13:08:56 -0000 On Sat, 21 Aug 2010 00:17:08 -0400 jhell wrote: > > Hi Alexander, > > Attached is a fix for one problem and one slight overlook for > 800.scrub-zfs. > > The first & second change was probably just an oversight but none the > less they both give a false impression of actions taken. > > Change1: > ${daily_scrub_zfs_default_threshold=30} is missng the ':' > which would ultimately reset the users supplied value in > periodic.conf to 30. Sorry, but it is not missing the ':'. There is one in front of it. A lot of start scripts in ports use this. You need to use a := instead of a = if you use var=${var:=default_val} but not if you use : ${var=default_val} I have the impression that the ':' in front of the variable is the way it is supposed to be in the start scripts in ports. I adopted this style (one variable name less to type... specially with expressive names this is some amount less to type). And I remember to have tested a lot of cases for the timeout value, overriding a pool specific value and overriding the default where some of them and all worked. If you have a case where it does not work, it would be nice if you could add a "set -x" in the beginning of the script and send me the output of a failing run. Bye, Alexander. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 13:45:39 2010 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 734231065673 for ; Sun, 22 Aug 2010 13:45:39 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 799918FC18 for ; Sun, 22 Aug 2010 13:45:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29437 for ; Sun, 22 Aug 2010 16:29:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnAc3-000ALA-SW for stable@freebsd.org; Sun, 22 Aug 2010 16:29:28 +0300 Message-ID: <4C712636.40802@freebsd.org> Date: Sun, 22 Aug 2010 16:29:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Thunderbird/3.1.2 MIME-Version: 1.0 To: stable@freebsd.org References: <20100822121607.4A8551B5060@freebsd-stable.sentex.ca> In-Reply-To: <20100822121607.4A8551B5060@freebsd-stable.sentex.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 13:45:39 -0000 on 22/08/2010 15:16 FreeBSD Tinderbox said the following: > [...] > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-str > ings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/trees.c > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-str > ings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod.c > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-str > ings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zmod_subr.c > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-str > ings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod/zutil.c > cc -O2 -fno-strict-aliasing -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-str > ings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe > r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c: In function 'arc_memory_throttle': > /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3300: error: redefinition of 'available_memory' > /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3299: error: previous definition of 'available_memory' was here > *** Error code 1 Sorry for the breakage. And in stable/8 too. Late night MFC and such a trivial mistake in such a trivial merge. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 14:01:20 2010 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 BFECE1065697 for ; Sun, 22 Aug 2010 14:01:20 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 855A58FC14 for ; Sun, 22 Aug 2010 14:01:20 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id A9ACE1DD607; Sun, 22 Aug 2010 16:01:18 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 9CD431721D; Sun, 22 Aug 2010 16:01:18 +0200 (CEST) Date: Sun, 22 Aug 2010 16:01:18 +0200 From: Jilles Tjoelker To: Alexander Leidinger Message-ID: <20100822140118.GA42636@stack.nl> References: <4C6F5344.6040808@DataIX.net> <20100822150842.00005129@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100822150842.00005129@unknown> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jhell , FreeBSD Stable Subject: Re: daily run output 800.scrub-zfs fixups X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 14:01:20 -0000 On Sun, Aug 22, 2010 at 03:08:42PM +0200, Alexander Leidinger wrote: > On Sat, 21 Aug 2010 00:17:08 -0400 jhell wrote: > > Hi Alexander, > > Attached is a fix for one problem and one slight overlook for > > 800.scrub-zfs. > > The first & second change was probably just an oversight but none the > > less they both give a false impression of actions taken. > > Change1: > > ${daily_scrub_zfs_default_threshold=30} is missng the ':' > > which would ultimately reset the users supplied value in > > periodic.conf to 30. > Sorry, but it is not missing the ':'. There is one in front of it. A > lot of start scripts in ports use this. You need to use a := instead of > a = if you use > var=${var:=default_val} > but not if you use > : ${var=default_val} > I have the impression that the ':' in front of the variable is the way > it is supposed to be in the start scripts in ports. I adopted this > style (one variable name less to type... specially with expressive > names this is some amount less to type). As described in sh(1) and POSIX, ${var=default_val} assigns the default if var was not set, while ${var:=default_val} assigns the default if var was not set or if it was set to the empty string. The double assignment in the construct var=${var:=default_val} is a workaround for bugs in very old Bourne shells (see Autoconf documentation for more). Our sh(1) has never had that bug, so simply : "${var:=default_val}" is better. The double-quotes prevent unnecessary pathname generation, which could be slow. However, even without the double-quotes, the correct value is assigned and no other side effects occur. > And I remember to have tested a lot of cases for the timeout value, > overriding a pool specific value and overriding the default where some > of them and all worked. > If you have a case where it does not work, it would be nice if you > could add a "set -x" in the beginning of the script and send me the > output of a failing run. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 18:19:29 2010 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 AD84210656A6 for ; Sun, 22 Aug 2010 18:19:29 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 700458FC1B for ; Sun, 22 Aug 2010 18:19:29 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 4BD988A2511 for ; Sun, 22 Aug 2010 19:50:59 +0200 (CEST) Message-ID: <4C716382.3040605@bsdforen.de> Date: Sun, 22 Aug 2010 19:50:58 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 18:19:29 -0000 wpa_supplicant doesn't create the pidfile if the target directory does not exist. Because /var/run is wiped with every boot I added the following line to my rc.local to workaround this issue: /bin/mkdir -p /var/run/wpa_supplicant I'm running RELENG_8. -- A: Because it fouls 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 19:48:27 2010 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 3F70F1065698; Sun, 22 Aug 2010 19:48:27 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 230FC8FC16; Sun, 22 Aug 2010 19:48:26 +0000 (UTC) Received: from [192.168.2.31] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id o7MJmNcr073199; Sun, 22 Aug 2010 15:48:25 -0400 (EDT) (envelope-from lists@jnielsen.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Nielsen In-Reply-To: Date: Sun, 22 Aug 2010 15:48:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> To: Stefan Bethke X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: gshapiro@freebsd.org, FreeBSD Stable Subject: Re: Apparent dnsbl bug in Sendmail or m4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 19:48:27 -0000 On Aug 22, 2010, at 6:40 AM, Stefan Bethke wrote: > Am 22.08.2010 um 10:00 schrieb Stefan Bethke: >=20 >> FEATURE(`dnsbl', `bl.spamcop.net', `"550 " $&{client_addr} "foo" = $&{client_addr} ""')dnl >=20 > The real culprit is the comma. I believe the problem stems from = unquoted use of the arguments in some of the ifelses, where the comma = turns the single argument into two. That makes a lot of sense, especially when combined with the off-list = suggestions I got to double-quote the error message. > Tracing the ifelses with -d aceq I see this for the last ifelse in = cf/feature/dnsbl.m4: >=20 > m4trace: -1- ifelse(`X"550 Mail from " $&{client_addr} " rejected', = `see http://spamcop.net/bl.shtml?" $&{client_addr}', `Xquarantine', = `R$+ $#error $@ quarantine $: _DNSBL_SRV_', `X"550 Mail from = " $&{client_addr} " rejected', ` > see http://spamcop.net/bl.shtml?" $&{client_addr}', `Xdiscard', = `R$+ =20 > $#discard $: _DNSBL_SRV_', `R$+ $#error $@ 5.7.1 $: = _DNSBL_MSG_' > ) -> ??? > m4trace: -1- ifelse(...) -> `' > m4trace: -1- ifelse ... >=20 >=20 > I've never managed to really wrap my head around m4 quoting, but the = easy fix is to use some other character that has no meaning to m4. The fact that you knew how to do a trace shows that you're way ahead of = me in grokking m4. :) I can confirm that replacing the comma with a = colon makes the problem go away. Does someone with some m4-fu want to take a stab at producing a fix? The = problem appears in the 7-arg "ifelse" in the last few lines of = /usr/share/sendmail/cf/feature/dnsbl.m4, though the source could of = course be missing quotes earlier in the file. I'd be happy to test any proposed patches and submit a bug report to = Sendmail if appropriate. At the very least perhaps the example in the = comment of /etc/mail/freebsd.mc should be modified to not use a comma. Thanks! JN From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 20:45:17 2010 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 693841065698 for ; Sun, 22 Aug 2010 20:45:17 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 285548FC24 for ; Sun, 22 Aug 2010 20:45:16 +0000 (UTC) Received: by iwn36 with SMTP id 36so5780914iwn.13 for ; Sun, 22 Aug 2010 13:45:16 -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:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=lmjvDWapsi3AZ7uKoy4BMIPFkbPmnKF8r//RJRMn44o=; b=ir3rBruVN33j3rw7vm5hyTXNGpAlANaoxze5Eik1SzenjbHfMEThCXqW8vdkx8Td/J 4eBcOVlRTeldyQteH77g7RzY/XFRSRykEpwdWsu/6oVY2CLsp55riWeTlAeSYljWZxKu JHBsRb30QGowKr4Asxm5gDw1/2zKy/26mzCd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=cAEYsIqVD9/pk/dGF9MUNqHrsHn2N3Ov6QXsRt1IoKlJgdn5xNJnvT8EX5CoslzbVZ VlxnTvNp7ibZye3hS3tA8s5LmyoRAod5Qmmm8eo4UrUTMgsxwBiJW2OqeWy2fRKtf46w BaLJHcX9W3aPuiW1EGwEkRrXhuYjnhhBc0UMA= Received: by 10.231.171.3 with SMTP id f3mr5465102ibz.145.1282509916531; Sun, 22 Aug 2010 13:45:16 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id g31sm5328930ibh.22.2010.08.22.13.45.14 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 13:45:15 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C718C59.4080302@DataIX.net> Date: Sun, 22 Aug 2010 16:45:13 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Alexander Leidinger References: <4C6F5344.6040808@DataIX.net> <20100821215052.000030f1@unknown> <4C703737.3020007@DataIX.net> <20100822145515.00006bc6@unknown> In-Reply-To: <20100822145515.00006bc6@unknown> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: daily run output 800.scrub-zfs fixups X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 20:45:17 -0000 On 08/22/2010 08:55, Alexander Leidinger wrote: > On Sat, 21 Aug 2010 16:29:43 -0400 jhell wrote: > >> Also I just noticed another confusing message 'at least for me' that >> said "starting first scrubbing (after reboot) of pool 'exports'". I >> read that like it is going to scrub the pool after the next reboot. I >> actually had to open up the script to double check that was not the >> case. The new attached patch changes the message to "starting scrub of >> pool 'pool'" so there is no confusion of when the scrub is actually >> going to happen. > > Background info for this part: > On every reboot the info from the last scrub is lost (except in the > history output). What this part of the message was > meant to do is, to tell that there was no scrub since the last boot > (this is the first scrub since boot). > > Would it be less confusing for you if I change > starting first scrubbing (after reboot) of pool X > to > starting first scrub (since last boot) of pool X > ? That would be wonderful!. -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 21:38:51 2010 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 1EB4A10656A8 for ; Sun, 22 Aug 2010 21:38:51 +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 964648FC20 for ; Sun, 22 Aug 2010 21:38:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2845D3F5B6 for ; Sun, 22 Aug 2010 21:23:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7MLNmVg079470 for ; Sun, 22 Aug 2010 21:23:48 GMT (envelope-from phk@critter.freebsd.dk) To: stable@freebsd.org From: Poul-Henning Kamp Date: Sun, 22 Aug 2010 21:23:48 +0000 Message-ID: <79469.1282512228@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Build option survey for stable/8 r210741 (for nanobsd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 21:38:51 -0000 I have run the build option survey scripts[1] on stable/8 r210741 and have put the results here: http://phk/misc/build_options_stable_8_210741/ This information is particularly useful if you are trying to shoehorn a NanoBSD image into a small-ish (ie: < 1G by the looks of it) media. But it also provides a audit of our rarely exercised build options, and as usual this run does exposes a handful of options that either do nothing or fail the build. Those options should probably be reviewed[2] Poul-Henning [1] src/tools/tools/build_option_survey It might be worth considering running these scripts on a regular basis for -trunk and the active -stable, but be aware that it takes half a week on a beefy machine. [2] Some of the options depend on each other. The scripts obviously are not able to do the full permutational test, but it would be nice if it were extended with a list of multiplets that should also be tested. -- 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 Sun Aug 22 21:45:15 2010 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 7D653106566B for ; Sun, 22 Aug 2010 21:45:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5638FC21 for ; Sun, 22 Aug 2010 21:45:15 +0000 (UTC) Received: by pxi17 with SMTP id 17so2277469pxi.13 for ; Sun, 22 Aug 2010 14:45:14 -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=2XcRujNiOCUg3yXCY2IlqBo66OzNapdmENjhU21BbVY=; b=HUIHsUUZw858GtL+G+MAFCpUAA4f1y5/F2Bg9sylJ7pAdYnoKRjP5AOHd5j99CU9ge R5jJer4RD+dLdBfXhz4vCFnoOh509KRhz2FWv5wHq+d9eeiCYBWTb/XFrtY6mABDrzx1 qRq+9pAd2fjW7Dj6vl2b4ejfSCDdXIebhTAcA= 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=VHT96y1UBDPSELwRd+JBtefZG3A8ifyXayXN0824feBvDbEjiPXgBmFkC+TW0bGNe4 FjKbUecyhDQpJG7B/dBoOYb83c4Q2dUs0ryRcr6dRaJHb2TUlKCU+rEKOzjF9iJGbq5p FW+dtfIo0zqYqoMyMLPj2Dl1Tbp7s+T8AI15c= Received: by 10.142.148.2 with SMTP id v2mr3539444wfd.205.1282513514745; Sun, 22 Aug 2010 14:45:14 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q27sm7496730wfc.6.2010.08.22.14.45.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 14:45:13 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 22 Aug 2010 14:45:11 -0700 From: Pyun YongHyeon Date: Sun, 22 Aug 2010 14:45:11 -0700 To: Nikola Kalpazanov Message-ID: <20100822214511.GA6013@michelle.cdnetworks.com> References: <20100820174022.GA21062@michelle.cdnetworks.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 Cc: freebsd-stable@freebsd.org Subject: Re: P811B Quad Port NIC problem. 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: Sun, 22 Aug 2010 21:45:15 -0000 On Sun, Aug 22, 2010 at 12:28:34PM +0200, Nikola Kalpazanov wrote: > Hi, > > I applied the patch provided by Pyun YongHyeon to the rl driver. > Then put > hint.rl.0.prefer_iomap="0" # for rl0 > hint.rl.1.prefer_iomap="0" # for rl1 > hint.rl.3.prefer_iomap="0" # for rl3 > > and all 3 adapters are now working fine. > > I absolutely agree that Realtek makes low-end adapters. > Even though the vendor may produce low-end ethernet controllers the controller would be sufficient enough to handle most traffics for personal/home usage. CPU is fast enough to saturate 100Mbps link with this controller and your bottle-neck would be PCI bus because you would use 4 ethernet controllers at the same time. > But in my case scenario I am building a router with WiFi access point > and this particular device allows me to do it on mini-ITX board ( > single PCI slot ). > > Again ... I want to send my thanks and regards to Pyun for making this > possible for me. > I just committed the patch to HEAD(r211648) and will MFC the change after 1 week. I made slight change to original patch so the tunable is now set in /boot/loader.conf instead of /boot/device.hints. You can get the same effect by adding the following line to /boot/loader.conf file. dev.rl.0.prefer_iomap="0" # for rl0 dev.rl.1.prefer_iomap="0" # for rl1 dev.rl.3.prefer_iomap="0" # for rl3 Thanks for testing and reporting! > Regards, > Nikola > > On Fri, Aug 20, 2010 at 7:40 PM, Pyun YongHyeon wrote: > > On Fri, Aug 20, 2010 at 01:44:20PM +0200, Nikola Kalpazanov wrote: > >> Hi, > >> > >> First I want to start with the note that I know Realtek is no good, > >> yet I will appreciate any assistance that you may provide. > >> > >> here are details of the problem: > >> > >> P811B is 4 port Ethernet card with built-in mini-PCI slot where I have > >> attached Atheros 802.11a/b/g/n Wireless PCI Adapter (AR5416). > >> That also requires to disable 4th port from the jumpers on the card. > >> > >> I have installed FreeBSD 8.1-RELEASE i386 > >> > >> pciconf -vlb > >> > >> pcib6@pci0:5:0:0: ? ? ? class=0x060400 card=0x00000000 chip=0x814812d8 > >> rev=0x00 hdr=0x01 > >> ? ? vendor ? ? = 'Pericom Semiconductor' > >> ? ? class ? ? ?= bridge > >> ? ? subclass ? = PCI-PCI > >> rl0@pci0:6:8:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 > >> ? ? vendor ? ? = 'Realtek Semiconductor' > >> ? ? device ? ? = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > >> (RTL-8139/8139C/8139D)' > >> ? ? class ? ? ?= network > >> ? ? subclass ? = ethernet > >> ? ? bar ? [14] = type Memory, range 32, base 0xe0110200, size 256, enabled > >> rl1@pci0:6:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 > >> ? ? vendor ? ? = 'Realtek Semiconductor' > >> ? ? device ? ? = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > >> (RTL-8139/8139C/8139D)' > >> ? ? class ? ? ?= network > >> ? ? subclass ? = ethernet > >> ? ? bar ? [14] = type Memory, range 32, base 0xe0110100, size 256, enabled > >> rl2@pci0:6:10:0: ? ? ? ?class=0x020000 card=0x813910ec chip=0x813910ec > >> rev=0x10 hdr=0x00 > >> ? ? vendor ? ? = 'Realtek Semiconductor' > >> ? ? device ? ? = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > >> (RTL-8139/8139C/8139D)' > >> ? ? class ? ? ?= network > >> ? ? subclass ? = ethernet > >> ? ? bar ? [10] = type I/O Port, range 32, base 0x1000, size 256, enabled > >> ? ? bar ? [14] = type Memory, range 32, base 0xe0110000, size 256, enabled > >> ath0@pci0:6:11:0: ? ? ? class=0x028000 card=0x2071168c chip=0x0023168c > >> rev=0x01 hdr=0x00 > >> ? ? vendor ? ? = 'Atheros Communications Inc.' > >> ? ? device ? ? = '802.11a/b/g/n Wireless PCI Adapter (AR5416)' > >> ? ? class ? ? ?= network > >> ? ? bar ? [10] = type Memory, range 32, base 0xe0100000, size 65536, enabled > >> > >> > >> > >> dmesg > >> > >> rl0: port 0x1200-0x12ff mem > >> 0xe0110200-0xe01102ff irq 21 at device 8.0 on pci6 > >> rl0: reset never completed! > >> rl0: unknown device ID: ffff assuming 8139 > >> rl0: MII without any phy! > >> device_attach: rl0 attach returned 6 > >> rl1: port 0x1100-0x11ff mem > >> 0xe0110100-0xe01101ff irq 22 at device 9.0 on pci6 > >> rl1: reset never completed! > >> rl1: unknown device ID: ffff assuming 8139 > >> rl1: MII without any phy! > >> device_attach: rl1 attach returned 6 > >> rl2: port 0x1000-0x10ff mem > >> 0xe0110000-0xe01100ff irq 23 at device 10.0 on pci6 > >> miibus1: on rl2 > >> rlphy0: PHY 0 on miibus1 > >> rlphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >> rl2: Ethernet address: 00:06:4f:67:08:f5 > >> rl2: [ITHREAD] > >> rl2: link state changed to DOWN > >> > >> > >> ath0 works fine > >> rl2 works fine > >> > >> rl0 and rl1 don't and of course as you may suspect they are missing > >> from ifconfig -a > >> > >> if I remove the miniPCI Atheros and enable 4th port it is the same > >> picture but this time 4th port rl3 works fine and rl0, rl1, and rl2 > >> don't in the same way. > >> > >> Any suggestions will be much appreciated. > > > > What makes me wonder is that both pci0:6:8:0 and pci0:6:9:0 has no > > I/O BAR. I never saw these kind of thing on rl(4) controllers. > > And I can't explain how rl(4) could successfully map the I/O with > > non-existing I/O BAR. > > Anyway would you try attached patch and let me know whether it > > makes any difference? Also add the following line to > > /boot/device.hints to have rl(4) use memory mapped mapping. > > > > hint.rl.0.prefer_iomap="0" > > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 22:06:38 2010 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 E8BA51065675 for ; Sun, 22 Aug 2010 22:06:38 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93DA08FC14 for ; Sun, 22 Aug 2010 22:06:38 +0000 (UTC) Received: by ywt2 with SMTP id 2so501909ywt.13 for ; Sun, 22 Aug 2010 15:06:37 -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:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ZiUWxRF/gsAcMiToZ02WUfuoMS5BZ6zsPi5jdboK5rM=; b=loC9heW9dGgf9w9U254yzlW6dTXpbuQyYSHIOpETnvzxhdu4ro8vdfTrpikaLr24wU HyF5L+V1SUqR0t0Bgy7Dah1PUrjFaMQulr6BUgmtyOVVoajPyindVVyskDv9gzvTgDCd S8DbuEUa56rlerYh0N5dbnby+BrqHvZd9Yb68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ml+nhJzS+Vs3ksZ6QUdyo9HqyaNhIb23Jt3uMpDm7jZ8Yimjr4jrbvaQHAoBYtP2cM 9oYnuLcpsYwraucd7zu4gb5XxV/M6ceYkhEWvchoR6zQPfwSXzw7+RF7vgHxkgpISGOn oKSQ3A9VU+J3Zmo/Ztuk38fbBgp2CpqD90nYg= Received: by 10.101.195.37 with SMTP id x37mr4509971anp.38.1282514797666; Sun, 22 Aug 2010 15:06:37 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id u14sm9468202ann.0.2010.08.22.15.06.36 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Aug 2010 15:06:36 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C719F6B.3030000@DataIX.net> Date: Sun, 22 Aug 2010 18:06:35 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Poul-Henning Kamp References: <79469.1282512228@critter.freebsd.dk> In-Reply-To: <79469.1282512228@critter.freebsd.dk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Build option survey for stable/8 r210741 (for nanobsd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 22:06:39 -0000 On 08/22/2010 17:23, Poul-Henning Kamp wrote: > I have run the build option survey scripts[1] on stable/8 r210741 > and have put the results here: > > http://phk/misc/build_options_stable_8_210741/ Where is this at again ? ;) -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Sun Aug 22 22:12:32 2010 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 6F6A41065675 for ; Sun, 22 Aug 2010 22:12:32 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB3F8FC1C for ; Sun, 22 Aug 2010 22:12:31 +0000 (UTC) Received: from unknown (client-86-31-88-103.midd.adsl.virginmedia.com [86.31.88.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 632AF5F11; Sun, 22 Aug 2010 21:59:41 +0000 (UTC) Date: Sun, 22 Aug 2010 22:59:40 +0100 From: Bruce Cran To: Poul-Henning Kamp Message-ID: <20100822225940.0000483e@unknown> In-Reply-To: <79469.1282512228@critter.freebsd.dk> References: <79469.1282512228@critter.freebsd.dk> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Build option survey for stable/8 r210741 (for nanobsd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2010 22:12:32 -0000 On Sun, 22 Aug 2010 21:23:48 +0000 Poul-Henning Kamp wrote: > http://phk/misc/build_options_stable_8_210741/ Did you mean http://phk.freebsd.dk/misc/build_options_stable_8_210741/ ? -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 01:18:32 2010 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 C4B2C1065675 for ; Mon, 23 Aug 2010 01:18:32 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 98E128FC12 for ; Mon, 23 Aug 2010 01:18:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id D830250BA4 for ; Mon, 23 Aug 2010 02:18:31 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqKBCYKAP0cU for ; Mon, 23 Aug 2010 02:18:31 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 3BF1A50B9A for ; Mon, 23 Aug 2010 02:18:31 +0100 (BST) Message-ID: <4C71CC62.6060803@langille.org> Date: Sun, 22 Aug 2010 21:18:26 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 01:18:32 -0000 What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 01:50:23 2010 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 B253C1065693; Mon, 23 Aug 2010 01:50:22 +0000 (UTC) (envelope-from john@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 786AC8FC17; Mon, 23 Aug 2010 01:50:22 +0000 (UTC) Received: from [192.168.2.40] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id o7N1Skcr036084; Sun, 22 Aug 2010 21:28:48 -0400 (EDT) (envelope-from john@jnielsen.net) References: <20100822031045.sl4d10544k0s80kw@newwebmail.jnielsen.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3E7350F2-5295-4D83-B807-C7F2246F9D2C@jnielsen.net> X-Mailer: iPhone Mail (8A306) From: John Nielsen Date: Sun, 22 Aug 2010 21:29:12 -0400 To: "gshapiro@freebsd.org" X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: FreeBSD Stable , Stefan Bethke Subject: Re: Apparent dnsbl bug in Sendmail or m4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 01:50:23 -0000 It was pointed out to me that the example in freebsd.mc has been double-quot= ed for some time. That's what I get for carrying old config files around for= too long I suppose. Sorry for the noise and thanks again all for the prompt= replies. On Aug 22, 2010, at 3:48 PM, John Nielsen wrote: > On Aug 22, 2010, at 6:40 AM, Stefan Bethke wrote: >=20 >> Am 22.08.2010 um 10:00 schrieb Stefan Bethke: >>=20 >>> FEATURE(`dnsbl', `bl.spamcop.net', `"550 " $&{client_addr} "foo" $&{clie= nt_addr} ""')dnl >>=20 >> The real culprit is the comma. I believe the problem stems from unquoted= use of the arguments in some of the ifelses, where the comma turns the sing= le argument into two. >=20 > That makes a lot of sense, especially when combined with the off-list sugg= estions I got to double-quote the error message. >=20 >> Tracing the ifelses with -d aceq I see this for the last ifelse in cf/fea= ture/dnsbl.m4: >>=20 >> m4trace: -1- ifelse(`X"550 Mail from " $&{client_addr} " rejected', `see h= ttp://spamcop.net/bl.shtml?" $&{client_addr}', `Xquarantine', `R$+ = $#error $@ quarantine $: _DNSBL_SRV_', `X"550 Mail from " $&{client_addr} "= rejected', ` >> see http://spamcop.net/bl.shtml?" $&{client_addr}', `Xdiscard', `R$+ = =20 >> $#discard $: _DNSBL_SRV_', `R$+ $#error $@ 5.7.1 $: _DNSB= L_MSG_' >> ) -> ??? >> m4trace: -1- ifelse(...) -> `' >> m4trace: -1- ifelse ... >>=20 >>=20 >> I've never managed to really wrap my head around m4 quoting, but the easy= fix is to use some other character that has no meaning to m4. >=20 > The fact that you knew how to do a trace shows that you're way ahead of me= in grokking m4. :) I can confirm that replacing the comma with a colon make= s the problem go away. >=20 > Does someone with some m4-fu want to take a stab at producing a fix? The p= roblem appears in the 7-arg "ifelse" in the last few lines of /usr/share/sen= dmail/cf/feature/dnsbl.m4, though the source could of course be missing quot= es earlier in the file. >=20 > I'd be happy to test any proposed patches and submit a bug report to Sendm= ail if appropriate. At the very least perhaps the example in the comment of /= etc/mail/freebsd.mc should be modified to not use a comma. >=20 > Thanks! >=20 > JN >=20 From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 01:53:54 2010 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 92CBB10656A7 for ; Mon, 23 Aug 2010 01:53:54 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E6F958FC1D for ; Mon, 23 Aug 2010 01:53:53 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o7N1ri3m037164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Aug 2010 11:23:50 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-56--721453012; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <4C71CC62.6060803@langille.org> Date: Mon, 23 Aug 2010 11:23:44 +0930 Message-Id: <114C4629-156B-486A-B9E4-42954E57F521@gsoft.com.au> References: <4C71CC62.6060803@langille.org> To: Dan Langille X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 01:53:54 -0000 --Apple-Mail-56--721453012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 23/08/2010, at 10:48, Dan Langille wrote: > What does this mean? > > kernel: MCA: Bank 4, Status 0x940c4001fe080813 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > kernel: MCA: Address 0x7ff6b0 > > FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 It's generated by machine check support, see.. /usr/src/sys/i386/i386/mca.c /usr/src/sys/amd64/amd64/mca.c Some info here.. http://en.wikipedia.org/wiki/Machine_check_architecture No man page for it though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail-56--721453012-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 02:05:16 2010 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 7DE0B10656A7 for ; Mon, 23 Aug 2010 02:05:16 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 51FBB8FC12 for ; Mon, 23 Aug 2010 02:05:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id AA89350BA4 for ; Mon, 23 Aug 2010 03:05:15 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngxGaC-wMeWx for ; Mon, 23 Aug 2010 03:05:15 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id D648A50B97 for ; Mon, 23 Aug 2010 03:05:14 +0100 (BST) Message-ID: <4C71D756.5080205@langille.org> Date: Sun, 22 Aug 2010 22:05:10 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable References: <4C71CC62.6060803@langille.org> In-Reply-To: <4C71CC62.6060803@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 02:05:16 -0000 On 8/22/2010 9:18 PM, Dan Langille wrote: > What does this mean? > > kernel: MCA: Bank 4, Status 0x940c4001fe080813 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > kernel: MCA: Address 0x7ff6b0 > > FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 06:21:49 2010 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 35CE91065670 for ; Mon, 23 Aug 2010 06:21:49 +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 EE27F8FC16 for ; Mon, 23 Aug 2010 06:21:48 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B4CDB3F61E; Mon, 23 Aug 2010 06:21:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7N6LlGe001956; Mon, 23 Aug 2010 06:21:48 GMT (envelope-from phk@critter.freebsd.dk) To: Bruce Cran From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 22 Aug 2010 22:59:40 +0100." <20100822225940.0000483e@unknown> Date: Mon, 23 Aug 2010 06:21:47 +0000 Message-ID: <1955.1282544507@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: stable@freebsd.org Subject: Re: Build option survey for stable/8 r210741 (for nanobsd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 06:21:49 -0000 In message <20100822225940.0000483e@unknown>, Bruce Cran writes: >On Sun, 22 Aug 2010 21:23:48 +0000 >Poul-Henning Kamp wrote: > >> http://phk/misc/build_options_stable_8_210741/ > >Did you mean http://phk.freebsd.dk/misc/build_options_stable_8_210741/ ? Yes, sorry, I was sleepy... -- 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 Mon Aug 23 06:45:18 2010 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 C0E10106566C for ; Mon, 23 Aug 2010 06:45:18 +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 179F18FC0C for ; Mon, 23 Aug 2010 06:45:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA11721; Mon, 23 Aug 2010 09:44:40 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnQlr-000DpO-Tc; Mon, 23 Aug 2010 09:44:39 +0300 Message-ID: <4C7218D6.6090408@icyb.net.ua> Date: Mon, 23 Aug 2010 09:44:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Dan Langille References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> In-Reply-To: <4C71D756.5080205@langille.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 06:45:18 -0000 on 23/08/2010 05:05 Dan Langille said the following: > On 8/22/2010 9:18 PM, Dan Langille wrote: >> What does this mean? >> >> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >> kernel: MCA: Address 0x7ff6b0 >> >> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > And another one: > > kernel: MCA: Bank 4, Status 0x9459c0014a080813 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > kernel: MCA: Address 0x7ff670 I believe that you get correctable RAM ECC errors, but not entirely sure. There is mcelog utility that decodes such messages into human-friendly descriptions. The utility is available on Linux-based systems. John Baldwin has a port of it to FreeBSD, but it seems to be WIP and is private so far. Wait and watch John posting decoded text in this thread :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 09:55:50 2010 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 DAC1F1065698 for ; Mon, 23 Aug 2010 09:55:50 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 90F7F8FC0A for ; Mon, 23 Aug 2010 09:55:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OnTkp-0002g1-Gk for freebsd-stable@freebsd.org; Mon, 23 Aug 2010 11:55:47 +0200 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, 23 Aug 2010 11:55:47 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Aug 2010 11:55:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 23 Aug 2010 11:55:40 +0200 Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: ZFS performance question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 09:55:51 -0000 On 08/20/10 12:30, Heinrich Rebehn wrote: > I am somewhat concerned about the numbers for per-char-output and per-char-input. In fact, i have never before seen that low numbers in a bonnie test. Using a single disk with UFS yields about 6 times as much. > > BTW: Running OpenSolaris on the same hardware yields 110306 for per-char-write and 94698 for per-char-read. "per-char" stats are different between different operating systems because of how they are implemented. Apparently, bonnie++ forces full disk writes (fsyncs) for each byte written on BSDs, but Linux (and apparently Solaris) somehow manage to write-cache this (or at least - cache it much more). It only matters if you have software which depends on this caching and performs slowly otherwise. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 10:34:15 2010 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 ED40210656A3 for ; Mon, 23 Aug 2010 10:34:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2B28FC1C for ; Mon, 23 Aug 2010 10:34:14 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id xmVK1e0031ap0As53maEHU; Mon, 23 Aug 2010 10:34:14 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id xmaD1e00A3LrwQ23imaEKl; Mon, 23 Aug 2010 10:34:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 67B379B425; Mon, 23 Aug 2010 03:34:12 -0700 (PDT) Date: Mon, 23 Aug 2010 03:34:12 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100823103412.GA21044@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: phk@freebsd.org Subject: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 10:34:15 -0000 It was brought to my attention that on FreeBSD with a hardware watchdog in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's quite possible for the watchdog to fire (reboot the system) once the panic has happened. This issue basically inhibits the ability for a system with a hardware watchdog in place to be able to successfully complete doadump(). There's confirmations of this problem dating all the way back to 2005: PR kern/82219, opened in 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82219 PR bin/145183, opened in 2010 (not sure if this is the same): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Confirmation that the problem still exists today (first paragraph): http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058350.html On Linux, it appears that they've worked around this problem by using what's called a "pretimeout" (basically a way to get the watchdog to become delayed, thus not firing during important tasks): http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt According to watchdog(4), it looks like the kernel setting WD_PASSIVE immediately upon entering panic would solve the problem, but the BUGS section indicates WD_PASSIVE hasn't been implemented (returns ENOSYS). Thoughts on solving this dilemma? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 11:08:50 2010 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 D766F10656A9 for ; Mon, 23 Aug 2010 11:08:50 +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 853A28FC28 for ; Mon, 23 Aug 2010 11:08:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5AB953F5B6; Mon, 23 Aug 2010 10:53:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7NArkdr085638; Mon, 23 Aug 2010 10:53:47 GMT (envelope-from phk@critter.freebsd.dk) To: Jeremy Chadwick From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 23 Aug 2010 03:34:12 MST." <20100823103412.GA21044@icarus.home.lan> Date: Mon, 23 Aug 2010 10:53:46 +0000 Message-ID: <85637.1282560826@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-stable@freebsd.org Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 11:08:50 -0000 In message <20100823103412.GA21044@icarus.home.lan>, Jeremy Chadwick writes: >It was brought to my attention that on FreeBSD with a hardware watchdog >in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's >quite possible for the watchdog to fire (reboot the system) once the >panic has happened. This issue basically inhibits the ability for a >system with a hardware watchdog in place to be able to successfully >complete doadump(). The good news is that the watchdog hopefully gets your system back on the air, even if the dumping hangs. If it is decided to reset/disarm the watchdog before a dump, please make that a sysctl tunable. -- 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 Mon Aug 23 11:37:12 2010 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 F3D0410656A8; Mon, 23 Aug 2010 11:37:11 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1A88FC0C; Mon, 23 Aug 2010 11:37:11 +0000 (UTC) Received: by ywt2 with SMTP id 2so661726ywt.13 for ; Mon, 23 Aug 2010 04:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2stJMf7U++BEQ+AJvyAlqdCx3Pr/hrqLgw4GN9pfNzI=; b=uhXT45H3HnArzjsoEKjxlpLfw6+0cz33YzJrVlLhN3PHDTs+cTlBLwH7zpNXbP2gE7 xhfBRgg9UVIJk73xH+5ujHfsE9KVEikxhyX50eTdm7AdbM47CYLlMugakk/05rcGrJj9 BEU+v+1PFqqkjNz1GkuH6klBKW46Fy1UpubI4= 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=bs3NKhZUjGNq3QCpmgGDMdGYD8sJYxPY2gkScfOEM8bQtU1rz66qCYlAbt8/d596fg 4jMplMYvYtXHpHHVLzmEF9Lf6znkjrhWgJounMwHnu11qZcIxJu12lmqvi9VmOnp0t5e aNQNq2LnTBuJe+/0N7NTh9goqV4+OBQjpXBQE= MIME-Version: 1.0 Received: by 10.90.84.1 with SMTP id h1mr3225192agb.138.1282561667382; Mon, 23 Aug 2010 04:07:47 -0700 (PDT) Received: by 10.231.146.10 with HTTP; Mon, 23 Aug 2010 04:07:47 -0700 (PDT) In-Reply-To: <20100823103412.GA21044@icarus.home.lan> References: <20100823103412.GA21044@icarus.home.lan> Date: Mon, 23 Aug 2010 04:07:47 -0700 Message-ID: From: Xin LI To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, phk@freebsd.org Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 11:37:12 -0000 On Mon, Aug 23, 2010 at 3:34 AM, Jeremy Chadwick wrote: > PR bin/145183, opened in 2010 (not sure if this is the same): > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Speaking for this I think we can do it by issuing an explicit watchdog(8) command on shutdown (like, set the timeout to several minutes) in /etc/rc.d/watchdog's shutdown section. This would be trivial to implement. Additionally, I'd personally think init(8) should be taught about watchdog facility. For panics, I think we should have the disk driver to "pat" watchdog rather than disabling it in their write success callback? Another thing is that ddb should be able to disable watchdog when it's waiting for keyboard input (or received first user input) I think. Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 11:39:49 2010 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 1ECF21065673 for ; Mon, 23 Aug 2010 11:39:49 +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 67C0D8FC1B for ; Mon, 23 Aug 2010 11:39:47 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15744; Mon, 23 Aug 2010 14:39:41 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C725DFC.8000205@icyb.net.ua> Date: Mon, 23 Aug 2010 14:39:40 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Poul-Henning Kamp , Jeremy Chadwick References: <20100823103412.GA21044@icarus.home.lan> <85637.1282560826@critter.freebsd.dk> In-Reply-To: <85637.1282560826@critter.freebsd.dk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 11:39:49 -0000 on 23/08/2010 13:53 Poul-Henning Kamp said the following: > In message <20100823103412.GA21044@icarus.home.lan>, Jeremy Chadwick writes: > >> It was brought to my attention that on FreeBSD with a hardware watchdog >> in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's >> quite possible for the watchdog to fire (reboot the system) once the >> panic has happened. This issue basically inhibits the ability for a >> system with a hardware watchdog in place to be able to successfully >> complete doadump(). > > The good news is that the watchdog hopefully gets your system back > on the air, even if the dumping hangs. > > If it is decided to reset/disarm the watchdog before a dump, please > make that a sysctl tunable. I'd rather add code to take over watchdog from watchdogd and to pat the dog while dumping, perhaps some other crucial places (like right before calling reset). This way we could ensure that system doesn't hang while dumping or in reset routine or etc. Another workaround is to set watchdog timeout large enough for dumping to complete, but that increases time that system is unavailable during a 'hard' hang (e.g. caused by hardware). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 11:55:13 2010 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 0332B10656A6 for ; Mon, 23 Aug 2010 11:55:13 +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 BC9FC8FC14 for ; Mon, 23 Aug 2010 11:55:12 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0A8263F649; Mon, 23 Aug 2010 11:55:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7NBtBsV086083; Mon, 23 Aug 2010 11:55:11 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 23 Aug 2010 14:39:40 +0300." <4C725DFC.8000205@icyb.net.ua> Date: Mon, 23 Aug 2010 11:55:11 +0000 Message-ID: <86082.1282564511@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 11:55:13 -0000 In message <4C725DFC.8000205@icyb.net.ua>, Andriy Gapon writes: >on 23/08/2010 13:53 Poul-Henning Kamp said the following: >> In message <20100823103412.GA21044@icarus.home.lan>, Jeremy Chadwick writes: >Another workaround is to set watchdog timeout large enough for dumping to >complete, but that increases time that system is unavailable during a 'hard' >hang (e.g. caused by hardware). You cannot trust the hardware to support such long timeouts. -- 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 Mon Aug 23 12:40:30 2010 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 DCD871065693 for ; Mon, 23 Aug 2010 12:40:30 +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 AD28C8FC1B for ; Mon, 23 Aug 2010 12:40:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5649146B03; Mon, 23 Aug 2010 08:40:30 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 773BE8A050; Mon, 23 Aug 2010 08:40:29 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 23 Aug 2010 08:17:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C6E790C.6060909@aldan.algebra.com> In-Reply-To: <4C6E790C.6060909@aldan.algebra.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008230817.12411.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "Mikhail T." Subject: Re: Strange buildworld error (uuid_*) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 12:40:30 -0000 On Friday, August 20, 2010 8:46:04 am Mikhail T. wrote: > Hello! > > With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, > NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now > boots nicely. > > I'd like to make another round of buildworld/buildkernel -- using the > existing tools... That, however, breaks in the most unexpected place: Your libstand is too stale. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 12:40:32 2010 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 5A66910656A5 for ; Mon, 23 Aug 2010 12:40:32 +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 2970B8FC08 for ; Mon, 23 Aug 2010 12:40:32 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C634D46B17; Mon, 23 Aug 2010 08:40:31 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCCAB8A04E; Mon, 23 Aug 2010 08:40:30 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 23 Aug 2010 08:20:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> In-Reply-To: <4C7218D6.6090408@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008230820.35260.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andriy Gapon , Dan Langille Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 12:40:32 -0000 On Monday, August 23, 2010 2:44:38 am Andriy Gapon wrote: > on 23/08/2010 05:05 Dan Langille said the following: > > On 8/22/2010 9:18 PM, Dan Langille wrote: > >> What does this mean? > >> > >> kernel: MCA: Bank 4, Status 0x940c4001fe080813 > >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > >> kernel: MCA: CPU 0 COR BUSLG Source RD Memory > >> kernel: MCA: Address 0x7ff6b0 > >> > >> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > > > And another one: > > > > kernel: MCA: Bank 4, Status 0x9459c0014a080813 > > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > > kernel: MCA: Address 0x7ff670 > > I believe that you get correctable RAM ECC errors, but not entirely sure. > There is mcelog utility that decodes such messages into human-friendly descriptions. > The utility is available on Linux-based systems. > John Baldwin has a port of it to FreeBSD, but it seems to be WIP and is private > so far. Wait and watch John posting decoded text in this thread :-) It is not private, it is in //depot/projects/mcelog/... in p4. It is not a complete port yet though (doesn't support the daemon and client modes for example). Details for these errors: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 7ff6b0 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = fe18 bit32 = err cpu0 bit46 = corrected ecc error bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS 940c4001fe080813 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 7ff670 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = 4ab3 bit32 = err cpu0 bit46 = corrected ecc error bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS 9459c0014a080813 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 As Andriy guessed, I believe both of these are corrected ECC errors. You can likely ignore them as a low rate of corrected ECC errors is not unexpected. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 14:15:04 2010 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 27E60106566C for ; Mon, 23 Aug 2010 14:15:04 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id D6A418FC16 for ; Mon, 23 Aug 2010 14:15:03 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:50503 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1OnXYM-000349-Ci for freebsd-stable@freebsd.org; Mon, 23 Aug 2010 15:59:13 +0200 Received: (qmail 42105 invoked from network); 23 Aug 2010 15:59:08 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 23 Aug 2010 15:59:08 +0200 Received: (qmail 5834 invoked by uid 1001); 23 Aug 2010 15:59:08 +0200 Date: Mon, 23 Aug 2010 15:59:08 +0200 From: Erik Trulsson To: Xin LI Message-ID: <20100823135908.GA5538@owl.midgard.homeip.net> References: <20100823103412.GA21044@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1OnXYM-000349-Ci. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1OnXYM-000349-Ci ab9100a4502a87ee407473d247eeaf99 Cc: freebsd-stable@freebsd.org, phk@freebsd.org, Jeremy Chadwick Subject: Re: Watchdog not being disabled while dumping core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 14:15:04 -0000 On Mon, Aug 23, 2010 at 04:07:47AM -0700, Xin LI wrote: > On Mon, Aug 23, 2010 at 3:34 AM, Jeremy Chadwick > wrote: > > PR bin/145183, opened in 2010 (not sure if this is the same): > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 > > Speaking for this I think we can do it by issuing an explicit > watchdog(8) command on shutdown (like, set the timeout to several > minutes) in /etc/rc.d/watchdog's shutdown section. This would be > trivial to implement. No, it would not be trivial to implement (at least not if you want it to actually work correctly.) The reason for that is that at least some (perhaps even most) hardware watchdog devices do not support so long timeouts. I know for example that the watchdog in the ixp425 CPU has a maximum timeout of 65 seconds. Reading the manpage for ichwd(4) it seems that it has maximum timeout of about 37 seconds. I suspect that other hardware watchdogs have similar limits, which leads to the conclusion that one should not assume watchdog timeouts longer than maybe 30 seconds to be supported. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 19:46:50 2010 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 7F34B10656A4 for ; Mon, 23 Aug 2010 19:46:50 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (timeinc9-ld25.websys.aol.com [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9948FC1A for ; Mon, 23 Aug 2010 19:46:49 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o7NJkmbp010785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 15:46:48 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o7NJkl6J030117; Mon, 23 Aug 2010 15:46:48 -0400 Message-ID: <4C72D027.4050406@aldan.algebra.com> Date: Mon, 23 Aug 2010 15:46:47 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: John Baldwin References: <4C6E790C.6060909@aldan.algebra.com> <201008230817.12411.jhb@freebsd.org> In-Reply-To: <201008230817.12411.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 23 Aug 2010 19:52:55 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Strange buildworld error (uuid_*) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 19:46:50 -0000 23.08.2010 08:17, John Baldwin написав(ла): >> With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, >> > NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now >> > boots nicely. >> > >> > I'd like to make another round of buildworld/buildkernel -- using the >> > existing tools... That, however, breaks in the most unexpected place: > Your libstand is too stale. The only libstand found on the computer (/usr/lib/libstand.a) is from August 19th -- the version built by FreeBSD-6's gcc-3 from FreeBSD-8.1's sources. According to nm, the library does define both uuid_equal and uuid_is_nil: mi@vaio:~ (106) nm /usr/lib/libstand.a | grep uuid uuid_equal.o: 00000000 T uuid_equal U uuid_is_nil uuid_is_nil.o: 00000000 T uuid_is_nil Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 20:49:43 2010 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 215C210656A6 for ; Mon, 23 Aug 2010 20:49:43 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id A94278FC14 for ; Mon, 23 Aug 2010 20:49:42 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7NKnPPF007050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2010 06:49:27 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o7NKnOxS007208; Tue, 24 Aug 2010 06:49:24 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o7NKnN5D007207; Tue, 24 Aug 2010 06:49:23 +1000 (EST) (envelope-from peter) Date: Tue, 24 Aug 2010 06:49:23 +1000 From: Peter Jeremy To: Tim Bishop Message-ID: <20100823204923.GA7142@server.vk2pj.dyndns.org> References: <20100821220435.GA6208@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20100821220435.GA6208@carrick-users.bishnet.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1R ZFS almost locking up system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 20:49:43 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Aug-21 23:04:35 +0100, Tim Bishop wrote: >I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems >that ZFS gets in to an almost unresponsive state. Last time it did it >(two weeks ago) I couldn't even log in, although the system was up, this >time I could manage a reboot but couldn't stop any applications (they >were likely hanging on I/O). Unless you have a ZFS-only system, it's possible you are running out of free memory (see the "free" entry in top(1) or 'systat -v') - in which case r211581 (and r211599 which fixes a mismerge) should help. Your very high kstat.zfs.misc.arcstats.memory_throttle_count suggests this is your problem. I have a more extensive patch in http://www.freebsd.org/cgi/query-pr.cgi?pr=3D146410 --=20 Peter Jeremy --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxy3tMACgkQ/opHv/APuIcWagCfVlqFfTfv13KSa+DRUrnvfkIn bnIAmQGQ7FslGYhY+YppLS362fHDTecY =fYwd -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 21:52:18 2010 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 4A15C106566B; Mon, 23 Aug 2010 21:52:18 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB4D8FC20; Mon, 23 Aug 2010 21:52:17 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id CED0737B48A; Mon, 23 Aug 2010 16:35:40 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3F8DA61C5A; Mon, 23 Aug 2010 16:35:40 -0500 (CDT) Date: Mon, 23 Aug 2010 16:35:40 -0500 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20100823213540.GD49588@over-yonder.net> References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008230820.35260.jhb@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 21:52:18 -0000 On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: > > It is not private, it is in //depot/projects/mcelog/... in p4. Which may as well be Siberia for us lowly non-developers. Any chance you could stick a tarball or a patch against upstream mcelog somewhere? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 23:37:20 2010 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 676971065672 for ; Mon, 23 Aug 2010 23:37:20 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 285518FC13 for ; Mon, 23 Aug 2010 23:37:20 +0000 (UTC) Received: from [2a01:348:132:51::10] (helo=carrick-users) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OngZr-000ENq-Pg; Tue, 24 Aug 2010 00:37:19 +0100 Received: (from tdb@localhost) by carrick-users (8.14.4/8.14.4/Submit) id o7NNbJUe055293; Tue, 24 Aug 2010 00:37:19 +0100 (BST) (envelope-from tdb) Date: Tue, 24 Aug 2010 00:37:19 +0100 From: Tim Bishop To: Dan Nelson Message-ID: <20100823233719.GB5352@carrick-users.bishnet.net> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100821222429.GB73221@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100821222429.GB73221@dan.emsphone.com> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 23:37:20 -0000 On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > In the last episode (Aug 21), Tim Bishop said: > > I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems > > that ZFS gets in to an almost unresponsive state. Last time it did it > > (two weeks ago) I couldn't even log in, although the system was up, this > > time I could manage a reboot but couldn't stop any applications (they > > were likely hanging on I/O). > > Could your pool be very close to full? Zfs will throttle itself when it's > almost out of disk space. I know it's "saved" me from filling up my > filesystems a couple times :) It's not close to full, so I don't think that's the issue. > > A few items from top, including zfskern: > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern > > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres > > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt > > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs > > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs > > > > At some point during this process my zfs snapshots have been failing to > > complete: > > > > root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] > > root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d > > root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d > > root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d > > root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d > > root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d > > procstat -k on some of these processes might help to pinpoint what part of > the zfs code they're all waiting in. I'll do that. Thanks for the pointer :-) Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 23:43:39 2010 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 9232B1065739 for ; Mon, 23 Aug 2010 23:43:39 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 653368FC0A for ; Mon, 23 Aug 2010 23:43:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A773750B97 for ; Tue, 24 Aug 2010 00:43:38 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8I4+ZjLDgPu for ; Tue, 24 Aug 2010 00:43:37 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id CA75850BA4 for ; Tue, 24 Aug 2010 00:43:37 +0100 (BST) Message-ID: <4C73079F.60601@langille.org> Date: Mon, 23 Aug 2010 19:43:27 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> In-Reply-To: <4C71D756.5080205@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 23:43:39 -0000 On 8/22/2010 10:05 PM, Dan Langille wrote: > On 8/22/2010 9:18 PM, Dan Langille wrote: >> What does this mean? >> >> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >> kernel: MCA: Address 0x7ff6b0 >> >> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > And another one: > > kernel: MCA: Bank 4, Status 0x9459c0014a080813 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > kernel: MCA: Address 0x7ff670 kernel: MCA: Bank 4, Status 0x947ec000d8080a13 kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Responder RD Memory kernel: MCA: Address 0xbfa9930 Another one. These errors started appearing after upgrading to 8.1-STABLE from 7.2.. something. I suspect the functionality was added about then -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 23:43:51 2010 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 D9FBB10656D4 for ; Mon, 23 Aug 2010 23:43:51 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3BD8FC1B for ; Mon, 23 Aug 2010 23:43:51 +0000 (UTC) Received: from [2a01:348:132:51::10] (helo=carrick-users) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnggB-000EQt-Rm; Tue, 24 Aug 2010 00:43:51 +0100 Received: (from tdb@localhost) by carrick-users (8.14.4/8.14.4/Submit) id o7NNhpPF055482; Tue, 24 Aug 2010 00:43:51 +0100 (BST) (envelope-from tdb) Date: Tue, 24 Aug 2010 00:43:51 +0100 From: Tim Bishop To: Peter Jeremy Message-ID: <20100823234351.GC5352@carrick-users.bishnet.net> References: <20100821220435.GA6208@carrick-users.bishnet.net> <20100823204923.GA7142@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100823204923.GA7142@server.vk2pj.dyndns.org> X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1R ZFS almost locking up system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 23:43:51 -0000 On Tue, Aug 24, 2010 at 06:49:23AM +1000, Peter Jeremy wrote: > On 2010-Aug-21 23:04:35 +0100, Tim Bishop wrote: > >I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems > >that ZFS gets in to an almost unresponsive state. Last time it did it > >(two weeks ago) I couldn't even log in, although the system was up, this > >time I could manage a reboot but couldn't stop any applications (they > >were likely hanging on I/O). > > Unless you have a ZFS-only system, it's possible you are running out > of free memory (see the "free" entry in top(1) or 'systat -v') - in > which case r211581 (and r211599 which fixes a mismerge) should help. > Your very high kstat.zfs.misc.arcstats.memory_throttle_count suggests > this is your problem. Thanks. At the time I had a reasonable amount free (~450MB from 3GB), but it had dropped lower than that at some points previously. I'll take a closer look at that next time, and look at that patch (or upgrade to 8-STABLE). And the system has a UFS root, but all the apps/data are stored in ZFS. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 23:47:38 2010 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 8F25A106567A for ; Mon, 23 Aug 2010 23:47:38 +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 D2DD18FC14 for ; Mon, 23 Aug 2010 23:47:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id CAA26911; Tue, 24 Aug 2010 02:47:32 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ongjj-000F07-UB; Tue, 24 Aug 2010 02:47:32 +0300 Message-ID: <4C730892.5010409@icyb.net.ua> Date: Tue, 24 Aug 2010 02:47:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Dan Langille References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C73079F.60601@langille.org> In-Reply-To: <4C73079F.60601@langille.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 23:47:38 -0000 on 24/08/2010 02:43 Dan Langille said the following: > On 8/22/2010 10:05 PM, Dan Langille wrote: >> On 8/22/2010 9:18 PM, Dan Langille wrote: >>> What does this mean? >>> >>> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >>> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>> kernel: MCA: Address 0x7ff6b0 >>> >>> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >> >> And another one: >> >> kernel: MCA: Bank 4, Status 0x9459c0014a080813 >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >> kernel: MCA: Address 0x7ff670 > > kernel: MCA: Bank 4, Status 0x947ec000d8080a13 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Responder RD Memory > kernel: MCA: Address 0xbfa9930 > > Another one. > > These errors started appearing after upgrading to 8.1-STABLE from 7.2.. > something. I suspect the functionality was added about then Please strop the flood :-) Depending on hardware there could be hundreds of such errors per day. Either replace memory modules or learn to live with these messages. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Aug 23 23:53:47 2010 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 34B00106566C for ; Mon, 23 Aug 2010 23:53:47 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 07E1B8FC25 for ; Mon, 23 Aug 2010 23:53:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 5FEDA50BA4; Tue, 24 Aug 2010 00:53:46 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge1Jv3JgjcU2; Tue, 24 Aug 2010 00:53:45 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5218B50B9A ; Tue, 24 Aug 2010 00:53:45 +0100 (BST) Message-ID: <4C7309FE.3070205@langille.org> Date: Mon, 23 Aug 2010 19:53:34 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C73079F.60601@langille.org> <4C730892.5010409@icyb.net.ua> In-Reply-To: <4C730892.5010409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2010 23:53:47 -0000 On 8/23/2010 7:47 PM, Andriy Gapon wrote: > on 24/08/2010 02:43 Dan Langille said the following: >> On 8/22/2010 10:05 PM, Dan Langille wrote: >>> On 8/22/2010 9:18 PM, Dan Langille wrote: >>>> What does this mean? >>>> >>>> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >>>> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >>>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>>> kernel: MCA: Address 0x7ff6b0 >>>> >>>> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >>> >>> And another one: >>> >>> kernel: MCA: Bank 4, Status 0x9459c0014a080813 >>> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>> kernel: MCA: Address 0x7ff670 >> >> kernel: MCA: Bank 4, Status 0x947ec000d8080a13 >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> kernel: MCA: CPU 0 COR BUSLG Responder RD Memory >> kernel: MCA: Address 0xbfa9930 >> >> Another one. >> >> These errors started appearing after upgrading to 8.1-STABLE from 7.2.. >> something. I suspect the functionality was added about then > > Please strop the flood :-) Sure. Three emails is hardly a flood. :) > Depending on hardware there could be hundreds of such errors per day. > Either replace memory modules or learn to live with these messages. I was posting a remark anyone. Thought I'd include one more that I noticed. Surely you can cope. :) -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 06:10:59 2010 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 57EC81065673; Tue, 24 Aug 2010 06:10:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EE9848FC15; Tue, 24 Aug 2010 06:10:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O6AwQO021175; Tue, 24 Aug 2010 02:10:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O6Av3S021144; Tue, 24 Aug 2010 06:10:57 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 06:10:57 GMT Message-Id: <201008240610.o7O6Av3S021144@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 06:10:59 -0000 TB --- 2010-08-24 05:33:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 05:33:59 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-08-24 05:33:59 - cleaning the object tree TB --- 2010-08-24 05:34:52 - cvsupping the source tree TB --- 2010-08-24 05:34:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-08-24 05:35:46 - building world TB --- 2010-08-24 05:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 05:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 05:35:46 - TARGET=amd64 TB --- 2010-08-24 05:35:46 - TARGET_ARCH=amd64 TB --- 2010-08-24 05:35:46 - TZ=UTC TB --- 2010-08-24 05:35:46 - __MAKE_CONF=/dev/null TB --- 2010-08-24 05:35:46 - cd /src TB --- 2010-08-24 05:35:46 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 05:35:47 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 06:10:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 06:10:57 - ERROR: failed to build world TB --- 2010-08-24 06:10:57 - 1380.59 user 488.81 system 2217.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 06:28:25 2010 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 4024F106566C for ; Tue, 24 Aug 2010 06:28:25 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id C8AE78FC0C for ; Tue, 24 Aug 2010 06:28:24 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1OnmmG-0006rI-6Z for freebsd-stable@freebsd.org; Tue, 24 Aug 2010 08:14:32 +0200 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id C60606FC4 for ; Tue, 24 Aug 2010 08:14:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> Date: Tue, 24 Aug 2010 08:14:29 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <201008230820.35260.jhb@freebsd.org> User-Agent: Opera Mail/10.61 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 06:28:25 -0000 On Mon, 23 Aug 2010 14:20:35 +0200, John Baldwin wrote: > On Monday, August 23, 2010 2:44:38 am Andriy Gapon wrote: >> on 23/08/2010 05:05 Dan Langille said the following: >> > On 8/22/2010 9:18 PM, Dan Langille wrote: >> >> What does this mean? >> >> >> >> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >> >> kernel: MCA: Global Cap 0x0000000000000105, Status 0x00000000000000= 00 >> >> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> >> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >> >> kernel: MCA: Address 0x7ff6b0 >> >> >> >> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >> > >> > And another one: >> > >> > kernel: MCA: Bank 4, Status 0x9459c0014a080813 >> > kernel: MCA: Global Cap 0x0000000000000105, Status 0x000000000000000= 0 >> > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >> > kernel: MCA: CPU 0 COR BUSLG Source RD Memory >> > kernel: MCA: Address 0x7ff670 >> >> I believe that you get correctable RAM ECC errors, but not entirely =20 >> sure. >> There is mcelog utility that decodes such messages into human-friendly= =20 >> descriptions. >> The utility is available on Linux-based systems. >> John Baldwin has a port of it to FreeBSD, but it seems to be WIP and i= s =20 >> private >> so far. Wait and watch John posting decoded text in this thread :-) > > It is not private, it is in //depot/projects/mcelog/... in p4. It is =20 > not a > complete port yet though (doesn't support the daemon and client modes f= or > example). > > Details for these errors: > > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 4 northbridge > ADDR 7ff6b0 > Northbridge RAM Chipkill ECC error > Chipkill ECC syndrome =3D fe18 > bit32 =3D err cpu0 > bit46 =3D corrected ecc error > bus error 'local node origin, request didn't time out > generic read mem transaction > memory access, level generic' > STATUS 940c4001fe080813 MCGSTATUS 0 > MCGCAP 105 APICID 0 SOCKETID 0 > CPUID Vendor AMD Family 15 Model 5 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 4 northbridge > ADDR 7ff670 > Northbridge RAM Chipkill ECC error > Chipkill ECC syndrome =3D 4ab3 > bit32 =3D err cpu0 > bit46 =3D corrected ecc error > bus error 'local node origin, request didn't time out > generic read mem transaction > memory access, level generic' > STATUS 9459c0014a080813 MCGSTATUS 0 > MCGCAP 105 APICID 0 SOCKETID 0 > CPUID Vendor AMD Family 15 Model 5 > > As Andriy guessed, I believe both of these are corrected ECC errors. Y= ou > can likely ignore them as a low rate of corrected ECC errors is not > unexpected. > Hi, A little off topic, but what is 'a low rate of corrected ECC errors'? At = =20 work one machine has them like ones per day, but runs ok. Is ones per day= =20 much? Ronald. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 06:30:42 2010 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 6468010656AB; Tue, 24 Aug 2010 06:30:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 075538FC17; Tue, 24 Aug 2010 06:30:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O6UfMh063973; Tue, 24 Aug 2010 02:30:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O6UfOq063971; Tue, 24 Aug 2010 06:30:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 06:30:41 GMT Message-Id: <201008240630.o7O6UfOq063971@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on arm/arm 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, 24 Aug 2010 06:30:42 -0000 TB --- 2010-08-24 05:59:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 05:59:45 - starting RELENG_8 tinderbox run for arm/arm TB --- 2010-08-24 05:59:45 - cleaning the object tree TB --- 2010-08-24 06:00:09 - cvsupping the source tree TB --- 2010-08-24 06:00:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2010-08-24 06:01:05 - building world TB --- 2010-08-24 06:01:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 06:01:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 06:01:05 - TARGET=arm TB --- 2010-08-24 06:01:05 - TARGET_ARCH=arm TB --- 2010-08-24 06:01:05 - TZ=UTC TB --- 2010-08-24 06:01:05 - __MAKE_CONF=/dev/null TB --- 2010-08-24 06:01:05 - cd /src TB --- 2010-08-24 06:01:05 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 06:01:06 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/arm/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/arm/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 06:30:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 06:30:41 - ERROR: failed to build world TB --- 2010-08-24 06:30:41 - 1137.09 user 457.10 system 1855.89 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 06:46:33 2010 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 513051065679; Tue, 24 Aug 2010 06:46:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ECCBD8FC3C; Tue, 24 Aug 2010 06:46:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O6kQ1Y064252; Tue, 24 Aug 2010 02:46:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O6kQLP064239; Tue, 24 Aug 2010 06:46:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 06:46:26 GMT Message-Id: <201008240646.o7O6kQLP064239@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 06:46:33 -0000 TB --- 2010-08-24 06:10:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 06:10:58 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-08-24 06:10:58 - cleaning the object tree TB --- 2010-08-24 06:11:43 - cvsupping the source tree TB --- 2010-08-24 06:11:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-08-24 06:12:41 - building world TB --- 2010-08-24 06:12:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 06:12:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 06:12:41 - TARGET=i386 TB --- 2010-08-24 06:12:41 - TARGET_ARCH=i386 TB --- 2010-08-24 06:12:41 - TZ=UTC TB --- 2010-08-24 06:12:41 - __MAKE_CONF=/dev/null TB --- 2010-08-24 06:12:41 - cd /src TB --- 2010-08-24 06:12:41 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 06:12:42 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/i386/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/i386/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 06:46:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 06:46:26 - ERROR: failed to build world TB --- 2010-08-24 06:46:26 - 1350.16 user 463.01 system 2127.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 07:09:25 2010 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 B35431065673; Tue, 24 Aug 2010 07:09:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 528948FC12; Tue, 24 Aug 2010 07:09:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O79Oiw006116; Tue, 24 Aug 2010 03:09:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O79OMu006115; Tue, 24 Aug 2010 07:09:24 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 07:09:24 GMT Message-Id: <201008240709.o7O79OMu006115@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 07:09:25 -0000 TB --- 2010-08-24 06:30:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 06:30:41 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-08-24 06:30:41 - cleaning the object tree TB --- 2010-08-24 06:31:20 - cvsupping the source tree TB --- 2010-08-24 06:31:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-08-24 06:32:47 - building world TB --- 2010-08-24 06:32:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 06:32:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 06:32:47 - TARGET=pc98 TB --- 2010-08-24 06:32:47 - TARGET_ARCH=i386 TB --- 2010-08-24 06:32:47 - TZ=UTC TB --- 2010-08-24 06:32:47 - __MAKE_CONF=/dev/null TB --- 2010-08-24 06:32:47 - cd /src TB --- 2010-08-24 06:32:47 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 06:32:47 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/pc98/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/pc98/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 07:09:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 07:09:24 - ERROR: failed to build world TB --- 2010-08-24 07:09:24 - 1355.84 user 511.73 system 2322.88 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 07:28:35 2010 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 40B0210656A9; Tue, 24 Aug 2010 07:28:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D792D8FC16; Tue, 24 Aug 2010 07:28:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O7SXWo017390; Tue, 24 Aug 2010 03:28:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O7SXYY017389; Tue, 24 Aug 2010 07:28:33 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 07:28:33 GMT Message-Id: <201008240728.o7O7SXYY017389@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 07:28:35 -0000 TB --- 2010-08-24 06:46:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 06:46:26 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-08-24 06:46:26 - cleaning the object tree TB --- 2010-08-24 06:47:12 - cvsupping the source tree TB --- 2010-08-24 06:47:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-08-24 06:47:43 - building world TB --- 2010-08-24 06:47:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 06:47:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 06:47:43 - TARGET=ia64 TB --- 2010-08-24 06:47:43 - TARGET_ARCH=ia64 TB --- 2010-08-24 06:47:43 - TZ=UTC TB --- 2010-08-24 06:47:43 - __MAKE_CONF=/dev/null TB --- 2010-08-24 06:47:43 - cd /src TB --- 2010-08-24 06:47:43 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 06:47:44 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/ia64/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/ia64/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 07:28:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 07:28:33 - ERROR: failed to build world TB --- 2010-08-24 07:28:33 - 1610.20 user 533.32 system 2527.49 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 07:34:06 2010 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 2B4A110656A8; Tue, 24 Aug 2010 07:34:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C2B808FC0A; Tue, 24 Aug 2010 07:34:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O7Y47K059198; Tue, 24 Aug 2010 03:34:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O7Y4BN059192; Tue, 24 Aug 2010 07:34:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 07:34:04 GMT Message-Id: <201008240734.o7O7Y4BN059192@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 07:34:06 -0000 TB --- 2010-08-24 07:01:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 07:01:13 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-08-24 07:01:13 - cleaning the object tree TB --- 2010-08-24 07:01:39 - cvsupping the source tree TB --- 2010-08-24 07:01:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-08-24 07:02:20 - building world TB --- 2010-08-24 07:02:20 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 07:02:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 07:02:20 - TARGET=mips TB --- 2010-08-24 07:02:20 - TARGET_ARCH=mips TB --- 2010-08-24 07:02:20 - TZ=UTC TB --- 2010-08-24 07:02:20 - __MAKE_CONF=/dev/null TB --- 2010-08-24 07:02:20 - cd /src TB --- 2010-08-24 07:02:20 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 07:02:21 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/mips/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/mips/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 07:34:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 07:34:04 - ERROR: failed to build world TB --- 2010-08-24 07:34:04 - 1150.28 user 488.13 system 1971.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 07:48:22 2010 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 2DB831065697; Tue, 24 Aug 2010 07:48:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C50768FC1C; Tue, 24 Aug 2010 07:48:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O7mLnT018711; Tue, 24 Aug 2010 03:48:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O7mLYv018710; Tue, 24 Aug 2010 07:48:21 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 07:48:21 GMT Message-Id: <201008240748.o7O7mLYv018710@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 07:48:22 -0000 TB --- 2010-08-24 07:09:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 07:09:24 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-08-24 07:09:24 - cleaning the object tree TB --- 2010-08-24 07:10:39 - cvsupping the source tree TB --- 2010-08-24 07:10:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-08-24 07:16:45 - building world TB --- 2010-08-24 07:16:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 07:16:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 07:16:45 - TARGET=powerpc TB --- 2010-08-24 07:16:45 - TARGET_ARCH=powerpc TB --- 2010-08-24 07:16:45 - TZ=UTC TB --- 2010-08-24 07:16:45 - __MAKE_CONF=/dev/null TB --- 2010-08-24 07:16:45 - cd /src TB --- 2010-08-24 07:16:45 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 07:16:46 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/powerpc/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/powerpc/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 07:48:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 07:48:20 - ERROR: failed to build world TB --- 2010-08-24 07:48:20 - 1342.73 user 465.74 system 2336.35 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 07:52:19 2010 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 4F0E91065698; Tue, 24 Aug 2010 07:52:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EB8578FC1C; Tue, 24 Aug 2010 07:52:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7O7qI5q029291; Tue, 24 Aug 2010 03:52:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7O7qIcO029290; Tue, 24 Aug 2010 07:52:18 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 24 Aug 2010 07:52:18 GMT Message-Id: <201008240752.o7O7qIcO029290@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 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, 24 Aug 2010 07:52:19 -0000 TB --- 2010-08-24 07:18:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-24 07:18:29 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-08-24 07:18:29 - cleaning the object tree TB --- 2010-08-24 07:19:19 - cvsupping the source tree TB --- 2010-08-24 07:19:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-08-24 07:23:45 - building world TB --- 2010-08-24 07:23:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-24 07:23:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-24 07:23:45 - TARGET=sparc64 TB --- 2010-08-24 07:23:45 - TARGET_ARCH=sparc64 TB --- 2010-08-24 07:23:45 - TZ=UTC TB --- 2010-08-24 07:23:45 - __MAKE_CONF=/dev/null TB --- 2010-08-24 07:23:45 - cd /src TB --- 2010-08-24 07:23:45 - /usr/bin/make -B buildworld >>> World build started on Tue Aug 24 07:23:46 UTC 2010 >>> 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 [...] mkdep -f .depend -a /src/usr.bin/c89/c89.c echo c89: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/c99 (depend) rm -f .depend mkdep -f .depend -a /src/usr.bin/c99/c99.c echo c99: /obj/sparc64/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/calendar (depend) make: don't know how to make locale.c. Stop *** Error code 2 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-24 07:52:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-24 07:52:18 - ERROR: failed to build world TB --- 2010-08-24 07:52:18 - 1259.74 user 406.71 system 2028.26 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 08:15:07 2010 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 936221065698 for ; Tue, 24 Aug 2010 08:15:07 +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 DBAE68FC15 for ; Tue, 24 Aug 2010 08:15:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA02438; Tue, 24 Aug 2010 11:15:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Onoes-000HQE-Mo; Tue, 24 Aug 2010 11:15:02 +0300 Message-ID: <4C737F85.5010804@icyb.net.ua> Date: Tue, 24 Aug 2010 11:15:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ronald Klop References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 08:15:07 -0000 on 24/08/2010 09:14 Ronald Klop said the following: > > A little off topic, but what is 'a low rate of corrected ECC errors'? At work > one machine has them like ones per day, but runs ok. Is ones per day much? That's up to your judgment. It's like after how many remapped sectors do you replace HDD. You may find this interesting: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 14:17:19 2010 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 1BA161065694 for ; Tue, 24 Aug 2010 14:17:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id D1E378FC19 for ; Tue, 24 Aug 2010 14:17:17 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7OEHCx5051927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2010 10:17:12 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7OEHCwa042809 for ; Tue, 24 Aug 2010 10:17:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008241417.o7OEHCwa042809@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 10:17:16 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <201008202104.o7KL4xi8012899@lava.sentex.ca> References: <201008202104.o7KL4xi8012899@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Subject: Re: RELENG_8 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: Tue, 24 Aug 2010 14:17:19 -0000 At 05:04 PM 8/20/2010, Mike Tancsa wrote: >The box is a moderately busy LNS running mpd5. I have another box >running the same load that has not crashed so I am wondering if its >hardware or this box is just "lucky" ? its crashed a couple of times >now, but the watchdog rebooted it prior to the dump being written out. I had disabled the watchdog and was able to get a full crash dump this time. Seems to be about 3 days between crashes Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x20:0xc5d11e15 stack pointer = 0x28:0xc4e70704 frame pointer = 0x28:0xc4e70718 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 = 0 (em1 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 3d20h45m41s Physical memory: 2036 MB Dumping 228 MB: 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/if_disc.ko...Reading symbols from /boot/kernel/if_disc.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_disc.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/libalias.ko...Reading symbols from /boot/kernel/libalias.ko.symbols...done. done. Loaded symbols for /boot/kernel/libalias.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_mppc.ko Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done. done. Loaded symbols for /boot/kernel/rc4.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko Reading symbols from /boot/kernel/ng_l2tp.ko...Reading symbols from /boot/kernel/ng_l2tp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2tp.ko Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from /boot/kernel/ng_ksocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ksocket.ko Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tee.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06b0ac3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc06b0d29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc092239c in trap_fatal (frame=0xc4e706c4, eva=36) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0922620 in trap_pfault (frame=0xc4e706c4, usermode=0, eva=36) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0922f0c in trap (frame=0xc4e706c4) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0904a9c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5d11e15 in ng_address_hook (here=0x0, item=0xc5da0540, hook=0xc65ce400, retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3504 #8 0xc5dddbcb in ng_tee_rcvdata (hook=0xca997580, item=0xc5da0540) at /usr/src/sys/modules/netgraph/tee/../../../netgraph/ng_tee.c:326 #9 0xc5d137c4 in ng_apply_item (node=0xc6499b80, item=0xc5da0540, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #10 0xc5d1279f in ng_snd_item (item=0xc5da0540, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #11 0xc5eca84a in ng_ppp_link_xmit (node=Variable "node" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1350 #12 0xc5ecb605 in ng_ppp_mp_xmit (node=0xcaad1a00, item=0xc5da0540, proto=Variable "proto" is not available. ) at /usr/src/sys/modules/netgraph/ppp/../../../netgraph/ng_ppp.c:1998 #13 0xc5d137c4 in ng_apply_item (node=0xcaad1a00, item=0xc5da0540, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #14 0xc5d1279f in ng_snd_item (item=0xc5da0540, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #15 0xc5d137c4 in ng_apply_item (node=0xc5eeae80, item=0xc5da0540, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #16 0xc5d1279f in ng_snd_item (item=0xc5da0540, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2253 #17 0xc5ec57e1 in ng_iface_send (ifp=0xc527d400, m=0xcb478200, sa=Variable "sa" is not available. ) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:475 #18 0xc5ec5c08 in ng_iface_output (ifp=0xc527d400, m=0xcb478200, dst=0xc4e70bdc, ro=0xc4e70bd4) at /usr/src/sys/modules/netgraph/iface/../../../netgraph/ng_iface.c:410 #19 0xc077cde2 in ip_fastforward (m=0xcb478200) at /usr/src/sys/netinet/ip_fastfwd.c:552 #20 0xc0759015 in ether_demux (ifp=0xc523c800, m=0xcb478200) at /usr/src/sys/net/if_ethersubr.c:837 #21 0xc0759593 in ether_input (ifp=0xc523c800, m=0xcb478200) at /usr/src/sys/net/if_ethersubr.c:760 #22 0xc0536d2a in lem_handle_rxtx (context=0xc5277000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3626 #23 0xc06ea2c2 in taskqueue_run (queue=0xc5266280) at /usr/src/sys/kern/subr_taskqueue.c:239 #24 0xc06ea4cd in taskqueue_thread_loop (arg=0xc527b5e8) at /usr/src/sys/kern/subr_taskqueue.c:360 #25 0xc0686561 in fork_exit (callout=0xc06ea410 , arg=0xc527b5e8, frame=0xc4e70d38) at /usr/src/sys/kern/kern_fork.c:844 #26 0xc0904b14 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:273 (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - DLs ?? 13090934:27.00 [kernel] 0 1 0 0 44 0 2912 0 wait DLs ?? 5028681:45.00 [init] 0 2 0 0 -8 0 0 0 - RL ?? -14489947:-26.55 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? -30170063:-16.55 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 20877214:22.00 [g_down] 0 5 0 0 -16 0 0 0 - DL ?? 19420261:44.00 [fdc0] 0 6 0 0 -60 0 0 0 waitin DL ?? 1587:45.00 [sctp_itera 0 7 0 0 -60 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 8 0 0 -16 0 0 0 psleep DL ?? 7421017:48.00 [pagedaemon 0 9 0 0 -16 0 0 0 psleep DL ?? 51:45.00 [vmdaemon] 0 10 0 0 171 0 0 0 - RL ?? 25156623:14.00 [idle] 0 11 0 0 -48 0 0 0 - WL ?? -29218365:-21.55 [intr] 0 12 0 0 44 0 0 0 - RL ?? 24812477:16.00 [yarrow] 0 13 0 0 76 0 0 0 pgzero DL ?? 103176:00.00 [pagezero] 0 14 0 0 44 0 0 0 psleep DL ?? 31116207:18.00 [bufdaemon] 0 15 0 0 -16 0 0 0 vlruwt DL ?? 31653040:03.00 [vnlru] 0 16 0 0 44 0 0 0 - RL ?? 7034379:11.00 [syncer] 0 17 0 0 44 0 0 0 - RL ?? -9165157:-23.55 [softdepflu 0 113 1 0 76 0 1540 0 pause Ds ?? 8264:42.00 [adjkerntz] 101 574 1 0 44 0 2948 0 select Ds ?? -22918381:-22.55 [zebra] 101 580 1 0 44 0 3456 0 select Ds ?? 7761146:41.00 [ospfd] 0 955 1 0 1 0 3348 0 - Rs ?? 3529521:14.00 [syslogd] 0 1153 0 0 45 0 0 0 - RL ?? 27744613:25.00 [ng_queue] 0 1160 1 0 44 0 3352 0 select Ds ?? 269548:12.00 [ntpd] 123 1161 1160 0 44 0 3352 0 select D ?? 8588592:09.00 [ntpd] 123 1163 1161 0 76 0 3352 0 select D ?? 21072:54.00 [ntpd] 0 1307 1 0 44 0 6704 0 select Ds ?? 17624560:39.00 [sshd] 0 1315 1 0 44 0 6080 0 - Rs ?? 34559384:02.00 [sendmail] 25 1321 1 0 44 0 6080 0 pause Ds ?? 1682274:36.00 [sendmail] 0 1328 1 0 44 0 3376 0 nanslp Ds ?? 17758332:54.00 [cron] 0 1418 1 0 76 0 3348 0 ttyin Ds+ ?? 55567:03.00 [getty] 0 1419 1 0 76 0 3348 0 ttyin Ds+ ?? 43887:36.00 [getty] 0 1420 1 0 76 0 3348 0 ttyin Ds+ ?? 50276:15.00 [getty] 0 1421 1 0 76 0 3348 0 ttyin Ds+ ?? 45877:21.00 [getty] 0 1422 1 0 76 0 3348 0 ttyin Ds+ ?? 46096:30.00 [getty] 0 1423 1 0 76 0 3348 0 ttyin Ds+ ?? 45587:15.00 [getty] 0 1424 1 0 76 0 3348 0 ttyin Ds+ ?? 44476:30.00 [getty] 0 1425 1 0 76 0 3348 0 ttyin Ds+ ?? 50589:36.00 [getty] 0 1426 1 0 44 0 3812 0 wait Ds ?? 395870:24.00 [login] 0 4087 1426 0 44 0 5652 0 pause D ?? 723658:48.00 [csh] 0 4090 4087 0 44 0 3288 0 kqread D+ ?? 64711:30.00 [tail] 0 4333 1 0 44 0 28440 0 select Ds ?? -32284891:-49.55 [mpd5] 0 12120 1307 0 48 0 11372 0 sbwait Ds ?? 796169:42.00 [sshd] 1001 12122 12120 0 44 0 11372 0 select D ?? 1822270:12.00 [sshd] 1001 12123 12122 0 44 0 5652 0 pause Ds ?? 376237:48.00 [csh] 0 12134 12123 0 44 0 3808 0 wait D ?? 166535:15.00 [su] 0 12135 12134 0 44 0 5652 0 ttyin D+ ?? 1204515:36.00 [csh] 0 12139 1 0 45 0 34744 0 - Rs ?? -20815152:-14.55 [argus] 0 17075 1307 0 47 0 11372 0 sbwait Ds ?? 795308:24.00 [sshd] 1001 17077 17075 0 44 0 11372 0 select D ?? 369119:51.00 [sshd] 1001 17078 17077 0 44 0 5652 0 ttyin Ds+ ?? 769947:27.00 [csh] ------------------------------------------------------------------------ vmstat -s 3478376649 cpu context switches 2032445813 device interrupts 48096996 software interrupts 15353777 traps 1467200553 system calls 18 kernel threads created 14876 fork() calls 2517 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 1040 vnode pager pageins 8157 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 237 pages reactivated 580900 copy-on-write faults 354 copy-on-write optimized faults 1024989 zero fill pages zeroed 34096 zero fill pages prezeroed 192 intransit blocking page faults 2153200 total VM faults taken 0 pages affected by kernel thread creation 2820899 pages affected by fork() 489397 pages affected by vfork() 0 pages affected by rfork() 335 pages cached 2003757 pages freed 0 pages freed by daemon 1367292 pages freed by exiting processes 10919 pages active 159341 pages inactive 65 pages in VM cache 45709 pages wired down 295745 pages free 4096 bytes per page 4892890 total name lookups cache hits (59% pos + 7% neg) system 2% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) filedesc 57 17K - 17428 16,32,256,512,1024,2048 kenv 114 8K - 117 16,32,64,128,4096 kqueue 2 2K - 10932 128,1024 CAM SIM 1 1K - 1 128 proc-args 33 2K - 87399 16,32,64,128,256 ithread 89 9K - 89 16,64,128 UART 3 2K - 3 16,256,1024 KTRACE 100 13K - 100 128 acpidev 59 2K - 59 32 linker 188 446K - 375 16,32,256,1024,2048,4096 lockf 23 2K - 857 32,64 ata_generic 1 1K - 9 16,512,1024 ip6ndp 795 75K - 47295 64,128 ip6opt 0 0K - 2 128 temp 821 247K - 20925999 16,32,64,128,256,512,1024,2048,4096 devbuf 364 1483K - 401 16,32,64,128,256,512,1024,2048,4096 module 320 21K - 320 64,128 mtx_pool 2 8K - 2 4096 ad_driver 1 1K - 1 32 ar_driver 0 0K - 6 512,2048 subproc 154 230K - 17612 256,4096 proc 2 8K - 2 4096 session 25 2K - 3169 64 pgrp 29 2K - 3386 64 cred 70 7K - 1187398 64,128 uidinfo 6 2K - 2880 64,1024 plimit 18 5K - 25406 256 sysctltmp 0 0K - 49868 16,32,64,128,4096 sysctloid 3021 94K - 3093 16,32,64,128 sysctl 0 0K - 20643 16,32,64 callout 1 256K - 1 umtx 204 13K - 204 64 p1003.1b 1 1K - 1 16 SWAP 2 413K - 2 64 bus-sc 56 90K - 1829 16,32,64,128,256,512,1024,2048,4096 bus 886 43K - 35234 16,32,64,128,1024 devstat 6 13K - 6 16,4096 eventhandler 81 4K - 81 32,64,128 kobj 214 428K - 250 2048 Per-cpu 1 1K - 1 16 rman 157 10K - 563 32,64 sbuf 0 0K - 940 16,32,64,128,256,512,1024,2048,4096 CAM periph 2 1K - 12 16,32,64,128 stack 0 0K - 2 128 taskqueue 19 1K - 19 16,64 Unitno 11 1K - 125295 16,64 iov 0 0K - 4457191 16,64,128,256 select 146 10K - 146 64 ioctlops 0 0K - 484247 16,32,64,128,256,512,1024,2048 msg 4 25K - 4 1024,4096 sem 4 6K - 4 256,512,1024,4096 shm 1 12K - 1 tty 22 11K - 34 512,2048 pts 2 1K - 12 128 mbuf_tag 1 1K - 998739350 32,64 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 pci_link 16 2K - 16 32,128 pcb 186 84K - 161996 16,32,64,512,1024,2048,4096 soname 8 1K - 34723809 16,32,128 acl 0 0K - 32 4096 biobuf 1 2K - 45 2048 vfscache 1 512K - 1 cl_savebuf 0 0K - 3937 32,64 vfs_hash 1 256K - 1 vnodes 2 1K - 2 128 vnodemarker 0 0K - 86176 512 mount 69 3K - 132 16,32,64,128,256 BPF 403 90K - 17250 16,64,256 ether_multi 4019 121K - 157478 16,32,64 ifaddr 3233 748K - 126468 16,32,64,128,256,512,2048 ifnet 400 401K - 15820 64,128,256,512,1024,2048 clone 6 24K - 8 16,128,4096 arpcom 5 1K - 5 16 lltable 1202 300K - 47535 128,256 acpi_perf 2 1K - 2 64 acpica 1804 91K - 60858 16,32,64,128,256,512 DEVFS1 73 19K - 91 256 DEVFS3 90 12K - 109 128 routetbl 2761 247K - 117560 16,32,64,128,256,512 igmp 399 50K - 15814 128 DEVFS 10 1K - 11 16,64 DEVFSP 1 1K - 359 32 ip_moptions 2 1K - 2 32,128 in_multi 397 50K - 15741 128 in_mfilter 1 1K - 1 512 sctp_iter 0 0K - 9 256 sctp_ifn 6 1K - 6 128 sctp_ifa 11 2K - 11 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 9 16 hostcache 1 16K - 1 syncache 1 72K - 1 ip6_moptions 2 1K - 2 32,128 in6_multi 3180 422K - 125932 16,256 in6_mfilter 1 1K - 1 512 pfs_nodes 21 3K - 21 128 mld 399 50K - 15814 128 NFS FHA 1 1K - 1 1024 rpc 2 5K - 2 128,4096 savedino 0 0K - 729 256 newdirblk 0 0K - 1 32 dirrem 0 0K - 5260 32 mkdir 0 0K - 90 32 diradd 0 0K - 5442 64 freefile 0 0K - 1094 32 freeblks 0 0K - 1122 256 freefrag 0 0K - 17250 32 allocindir 1 1K - 49037 64 indirdep 2 1K - 16134 32 allocdirect 0 0K - 4060 128 bmsafemap 1 1K - 9184 64 newblk 1 1K - 53098 64,256 inodedep 1 256K - 6340 128 pagedep 1 64K - 789 64 ufs_dirhash 1146 211K - 1146 16,32,64,128,256,512 ufs_mount 12 49K - 12 256,2048,4096 UMAHash 1 2K - 4 256,512,1024,2048 GEOM 63 15K - 447 16,32,64,128,512,1024 vm_pgdata 2 65K - 2 64 acpitask 1 1K - 1 1024 atkbddev 2 1K - 2 32 kbdmux 6 10K - 6 16,256,1024,2048,4096 LED 4 1K - 4 64 apmdev 1 1K - 1 64 CAM XPT 12 2K - 26 16,32,64,1024 acpisem 15 2K - 15 64,128 isadev 21 2K - 21 64 io_apic 2 2K - 2 1024 memdesc 1 4K - 1 4096 msi 1 1K - 1 64 nexusdev 4 1K - 4 16 CAM dev queue 1 1K - 1 128 entropy 1024 64K - 1024 64 cdev 9 2K - 9 128 CAM queue 3 1K - 7 16 sigio 1 1K - 1 32 disc 1 1K - 1 16 IpFw/IpAcct 13 2K - 24 16,32,64,128 netgraph_msg 0 0K - 19647245 64,128,256,512,1024 netgraph_node 1800 225K - 188552 128 netgraph_hook 4248 531K - 401764 128 netgraph 1176 147K - 63692 64,256 netgraph_sock 80 5K - 70376 64 netgraph_path 0 0K - 10195923 16,32 netgraph_mppc 0 0K - 2 1024 netgraph_l2tp 468 101K - 35378 64,1024 netgraph_ksock 76 5K - 19333 64 netgraph_iface 392 25K - 15807 64 netgraph_ppp 392 3136K - 15807 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 87, 3, 87, 0 UMA Zones: 888, 0, 87, 1, 87, 0 UMA Slabs: 284, 0, 1496, 16, 24018, 0 UMA RCntSlabs: 544, 0, 1267, 0, 1267, 0 UMA Hash: 128, 0, 2, 28, 3, 0 16 Bucket: 76, 0, 60, 40, 82, 0 32 Bucket: 140, 0, 92, 20, 114, 0 64 Bucket: 268, 0, 114, 12, 160, 14 128 Bucket: 524, 0, 244, 1, 1077, 112 VM OBJECT: 136, 0, 56609, 318, 418318, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 57505, 25, 399, 85251, 0 MAP ENTRY: 72, 0, 930, 395, 783736, 0 DP fakepg: 72, 0, 0, 0, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 249, 238, 249, 0 16: 16, 0, 6475, 630, 45472233, 0 32: 32, 0, 6482, 524, 999601063, 0 64: 64, 0, 7957, 3548, 10862360, 0 128: 128, 0, 9460, 560, 15223676, 0 256: 256, 0, 4810, 200, 376877, 0 512: 512, 0, 1238, 266, 787258, 0 1024: 1024, 0, 497, 87, 8592861, 0 2048: 2048, 0, 247, 85, 11756451, 0 4096: 4096, 0, 105, 68, 73770, 0 Files: 56, 0, 273, 330, 1297543, 0 TURNSTILE: 72, 0, 205, 35, 205, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 680, 0, 50, 52, 17411, 0 THREAD: 636, 0, 128, 76, 47327, 0 SLEEPQUEUE: 44, 0, 205, 90, 205, 0 VMSPACE: 232, 0, 33, 103, 17395, 0 cpuset: 40, 0, 2, 182, 2, 0 mbuf_packet: 256, 0, 2252, 189, 1770562500, 0 mbuf: 256, 0, 30660, 328, 2623840453, 0 mbuf_cluster: 2048, 25600, 2432, 14, 2432, 0 mbuf_jumbo_page: 4096, 12800, 0, 44, 266, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 ttyinq: 152, 0, 165, 69, 480, 0 ttyoutq: 256, 0, 88, 32, 256, 0 g_bio: 140, 0, 0, 3808, 1251337, 0 ata_request: 204, 0, 1, 1044, 301616, 0 ata_composite: 180, 0, 0, 0, 0, 0 VNODE: 268, 0, 80955, 105, 1591300, 0 VNODEPOLL: 60, 0, 1, 125, 1, 0 S VFS Cache: 72, 0, 87335, 804, 1613030, 0 L VFS Cache: 292, 0, 226, 632, 12424, 0 NAMEI: 1024, 0, 0, 48, 3452761, 0 NFSMOUNT: 524, 0, 0, 0, 0, 0 NFSNODE: 468, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 1373, 19, 1373, 0 pipe: 392, 0, 6, 44, 7635, 0 ksiginfo: 80, 0, 91, 965, 11791, 0 itimer: 220, 0, 0, 72, 97, 0 KNOTE: 72, 0, 2, 210, 10960, 0 socket: 412, 25605, 280, 89, 540850, 0 unpcb: 172, 25622, 23, 92, 12892, 0 ipq: 32, 904, 0, 0, 0, 0 udp_inpcb: 220, 25614, 84, 96, 417278, 0 udpcb: 8, 25781, 84, 322, 417278, 0 tcp_inpcb: 220, 25614, 11, 61, 1510, 0 tcpcb: 632, 25602, 11, 25, 1510, 0 tcptw: 52, 5184, 0, 216, 59, 0 syncache: 112, 15365, 0, 105, 1241, 0 hostcache: 76, 15400, 1, 149, 21, 0 tcpreass: 20, 1690, 0, 0, 0, 0 sackhole: 20, 0, 0, 169, 9, 0 sctp_ep: 860, 25600, 0, 0, 0, 0 sctp_asoc: 1484, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 290, 10, 0 sctp_raddr: 432, 80001, 0, 0, 0, 0 sctp_chunk: 92, 400008, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 220, 25614, 2, 52, 32, 0 rtentry: 108, 0, 2194, 254, 79838, 0 selfd: 28, 0, 414, 475, 2819104093, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0 Mountpoints: 644, 0, 5, 13, 5, 0 FFS inode: 116, 0, 80922, 159, 1591194, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 80922, 138, 1591194, 0 IPFW dynamic rule: 108, 0, 0, 0, 0, 0 NetGraph items: 36, 4130, 31, 205, 766085117, 0 NetGraph data items: 36, 531, 1, 412, 1762181728, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 6 0 irq4: uart0 2642 14 irq19: atapci1 298104 1665 irq30: em0 1055249819 5895250 irq31: em1 976895242 5457515 cpu0: timer 667882096 3731184 cpu1: timer 667868364 3731108 Total 3368196273 18816738 ------------------------------------------------------------------------ pstat -T 273/12328 files 0M/3071M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad4s1b 6291200 0 6291200 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics ad4 KB/t tps MB/s 13.27 1662 21.53 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 33554432 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 8192 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 10 (# of semaphore identifiers) semmns: 60 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 136 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ netstat -m 32912/517/33429 mbufs in use (current/cache/total) 2243/203/2446/25600 mbuf clusters in use (current/cache/total/max) 2252/189 mbuf+clusters out of packet secondary zone in use (current/cache) 0/44/44/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 12714K/711K/13425K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines >Fatal trap 12: page fault while in kernel mode >cpuid = 1; apic id = 01 >fault virtual address = 0x1378af >fault code = supervisor read, page not present >instruction pointer = 0x20:0xc5ba1190 >stack pointer = 0x28:0xe79b784c >frame pointer = 0x28:0xe79b7864 >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 = 33060 (mpd5) >trap number = 12 >panic: page fault >cpuid = 1 >Uptime: 2d4h49m17s >Physical memory: 2036 MB >Dumping 228 MB:panic: bufwrite: buffer is not busy??? >cpuid = 1 > 213 197 181 165 149 133 117 101 85 69 53 37 21 5 > > >(kgdb) #0 doadump () at pcpu.h:231 >#1 0xc06b0ac3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 >#2 0xc06b0d29 in panic (fmt=Variable "fmt" is not available. >) at /usr/src/sys/kern/kern_shutdown.c:590 >#3 0xc092239c in trap_fatal (frame=0xe79b780c, eva=1276079) > at /usr/src/sys/i386/i386/trap.c:938 >#4 0xc0922620 in trap_pfault (frame=0xe79b780c, usermode=0, eva=1276079) > at /usr/src/sys/i386/i386/trap.c:851 >#5 0xc0922f0c in trap (frame=0xe79b780c) at /usr/src/sys/i386/i386/trap.c:533 >#6 0xc0904a9c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >#7 0xc5ba1190 in ng_ID2noderef (ID=64998) > at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:811 >#8 0xc5ba192b in ng_path2noderef (here=0xc5f3f180, > address=0xcac2a800 "[fde6]:", destp=0xe79b7ac0, lasthook=0xe79b7abc) > at > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1679 >#9 0xc5ba1d40 in ng_address_path (here=0xc5f3f180, item=0xc5c597c0, > address=0xcac2a800 "[fde6]:", retaddr=0) > at > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3536 >#10 0xc5b9c662 in ngc_send (so=0xc56e380c, flags=0, m=0xcaee6800, > addr=0xca8baca0, control=0x0, td=0xc6298780) > at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:296 >#11 0xc07111aa in sosend_generic (so=0xc56e380c, addr=0xca8baca0, > uio=0xe79b7be8, top=0xcaee6800, control=0x0, flags=0, td=0xc6298780) > at /usr/src/sys/kern/uipc_socket.c:1260 >#12 0xc070d40f in sosend (so=0xc56e380c, addr=0xca8baca0, uio=0xe79b7be8, > top=0x0, control=0x0, flags=0, td=0xc6298780) > at /usr/src/sys/kern/uipc_socket.c:1304 >#13 0xc0714a47 in kern_sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0, > control=0x0, segflg=UIO_USERSPACE) > at /usr/src/sys/kern/uipc_syscalls.c:788 >#14 0xc0714c81 in sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0) > at /usr/src/sys/kern/uipc_syscalls.c:724 >#15 0xc0714d98 in sendto (td=0xc6298780, uap=0xe79b7cf8) > at /usr/src/sys/kern/uipc_syscalls.c:840 >#16 0xc09228fa in syscall (frame=0xe79b7d38) > at /usr/src/sys/i386/i386/trap.c:1111 >#17 0xc0904b01 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:264 >#18 0x00000033 in ?? () >Previous frame inner to this frame (corrupt stack?) >(kgdb) > > > > ---Mike > >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 15:37:23 2010 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 F22661065670 for ; Tue, 24 Aug 2010 15:37:23 +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 C03698FC14 for ; Tue, 24 Aug 2010 15:37:23 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 67F5C46B85; Tue, 24 Aug 2010 11:37:23 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 887188A04E; Tue, 24 Aug 2010 11:37:22 -0400 (EDT) From: John Baldwin To: "Matthew D. Fuller" Date: Tue, 24 Aug 2010 11:06:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71CC62.6060803@langille.org> <201008230820.35260.jhb@freebsd.org> <20100823213540.GD49588@over-yonder.net> In-Reply-To: <20100823213540.GD49588@over-yonder.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008241106.43878.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 24 Aug 2010 11:37:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 15:37:24 -0000 On Monday, August 23, 2010 5:35:40 pm Matthew D. Fuller wrote: > On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of > John Baldwin, and lo! it spake thus: > > > > It is not private, it is in //depot/projects/mcelog/... in p4. > > Which may as well be Siberia for us lowly non-developers. Any chance > you could stick a tarball or a patch against upstream mcelog > somewhere? It is actually public at perforce.freebsd.org. :) However, it is tedious to download the files. It really should be a port perhaps, though Someone (tm) should try to get the patches integrated upstream. You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also need to download the memstream.c file from there as well and put that in the extracted mcelog tarball. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 19:51:54 2010 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 2F97E1065679 for ; Tue, 24 Aug 2010 19:51:54 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4EFE8FC15 for ; Tue, 24 Aug 2010 19:51:53 +0000 (UTC) Received: by qwg5 with SMTP id 5so7220886qwg.13 for ; Tue, 24 Aug 2010 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4iuStYGtR/63Eh3eHk6Kz4H0BtaQHnd4yv8ktT8Ug1c=; b=R7Oz6SdIUx7c5i4wUlCEw0l0ToO4vK8zC00To4UBQkEE31SK4vFqnfH/WMfGKnrdrl 22yZIJQS6ZPWBTxfCRC0JU30w+Qj/leGKuYAEqIMxfLS7+Fzd9WRyuU6BaDMkanBMlfD 4Gm8LlQHURteEwiHovWXLRC3NCF3//+NTPfKw= 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=q6czjGWJ4XADufXv2ugHQWrebChEHT5v4Ov/SXIt2SSEqD+DAVYfJWFJTwj0xDNZeJ b41kEvpBIJyqR95DQfArphpWJtCp6ysR4y1ik52BlYrfG9UbQ15JuaOGeNaoMzKHv5AO KB3FBgynu8EJTERqHU2w5wFg/aAk44yduU4YU= MIME-Version: 1.0 Received: by 10.220.179.7 with SMTP id bo7mr2223684vcb.2.1282679476138; Tue, 24 Aug 2010 12:51:16 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.49.70 with HTTP; Tue, 24 Aug 2010 12:51:15 -0700 (PDT) In-Reply-To: <4C737F85.5010804@icyb.net.ua> References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> <4C737F85.5010804@icyb.net.ua> Date: Tue, 24 Aug 2010 12:51:15 -0700 X-Google-Sender-Auth: vd3EuMZ9CF6sjntF5fOY9Ek9V7k Message-ID: From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ronald Klop , freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 19:51:54 -0000 IMHO the key here is whether hardware is broken or not. The only case where correctable ECC errors are OK is when a bit gets flipped by a high-energy particle. That's a normal but fairly rare event. If you get bit flips often enough that you can recall details of more then one of them on the same hardware, my guess would be that you're dealing with something else -- bad/marginal memory, signal integrity issues, power issues, overheating... The list continues.. In all those cases hardware does *not* work correctly. Whether you can (or want to) keep running stuff on the hardware that is broken is another question. --Artem On Tue, Aug 24, 2010 at 1:15 AM, Andriy Gapon wrote: > on 24/08/2010 09:14 Ronald Klop said the following: >> >> A little off topic, but what is 'a low rate of corrected ECC errors'? At= work >> one machine has them like ones per day, but runs ok. Is ones per day muc= h? > > That's up to your judgment. =A0It's like after how many remapped sectors = do you > replace HDD. > You may find this interesting: > http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf > > -- > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 20:03:33 2010 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 63BD61065695 for ; Tue, 24 Aug 2010 20:03:33 +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 A20258FC12 for ; Tue, 24 Aug 2010 20:03:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA13396; Tue, 24 Aug 2010 23:03:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnziR-000Huw-JH; Tue, 24 Aug 2010 23:03:27 +0300 Message-ID: <4C74258E.2060403@icyb.net.ua> Date: Tue, 24 Aug 2010 23:03:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Artem Belevich References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> <4C737F85.5010804@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ronald Klop , freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 20:03:33 -0000 on 24/08/2010 22:51 Artem Belevich said the following: > IMHO the key here is whether hardware is broken or not. The only case > where correctable ECC errors are OK is when a bit gets flipped by a > high-energy particle. That's a normal but fairly rare event. If you > get bit flips often enough that you can recall details of more then > one of them on the same hardware, my guess would be that you're > dealing with something else -- bad/marginal memory, signal integrity > issues, power issues, overheating... The list continues.. In all those > cases hardware does *not* work correctly. Whether you can (or want to) > keep running stuff on the hardware that is broken is another question. Have you read the article? :) If not, read at least the summary. > On Tue, Aug 24, 2010 at 1:15 AM, Andriy Gapon wrote: >> on 24/08/2010 09:14 Ronald Klop said the following: >>> >>> A little off topic, but what is 'a low rate of corrected ECC errors'? At work >>> one machine has them like ones per day, but runs ok. Is ones per day much? >> >> That's up to your judgment. It's like after how many remapped sectors do you >> replace HDD. >> You may find this interesting: >> http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf >> >> -- >> Andriy Gapon -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 20:05:49 2010 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 0CA5C106566C for ; Tue, 24 Aug 2010 20:05:49 +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 4904C8FC08 for ; Tue, 24 Aug 2010 20:05:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA13446 for ; Tue, 24 Aug 2010 23:05:47 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Onzkg-000Hv9-IJ for freebsd-stable@FreeBSD.org; Tue, 24 Aug 2010 23:05:46 +0300 Message-ID: <4C74261A.4000401@icyb.net.ua> Date: Tue, 24 Aug 2010 23:05:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------070209070705070300020109" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Attn Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 20:05:49 -0000 This is a multi-part message in MIME format. --------------070209070705070300020109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ronald, your email address bounces, that's inconvenient. -------- Original Message -------- Subject: Returned mail: Service unavailable Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) From: Mail Delivery Subsystem To: The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 (EEST) from porto-e.starpoint.kiev.ua [212.40.38.100] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to thuis.klop.ws.: >>> RCPT To: <<< 554 5.7.1 : Relay access denied 554 ... Service unavailable --------------070209070705070300020109 Content-Type: message/rfc822; name="ForwardedMessage.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ForwardedMessage.eml" Return-Path: avg@icyb.net.ua Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA13396; Tue, 24 Aug 2010 23:03:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OnziR-000Huw-JH; Tue, 24 Aug 2010 23:03:27 +0300 Message-ID: <4C74258E.2060403@icyb.net.ua> Date: Tue, 24 Aug 2010 23:03:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Artem Belevich CC: Ronald Klop , freebsd-stable@freebsd.org Subject: Re: kernel MCA messages References: <4C71CC62.6060803@langille.org> <4C71D756.5080205@langille.org> <4C7218D6.6090408@icyb.net.ua> <201008230820.35260.jhb@freebsd.org> <4C737F85.5010804@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 24/08/2010 22:51 Artem Belevich said the following: > IMHO the key here is whether hardware is broken or not. The only case > where correctable ECC errors are OK is when a bit gets flipped by a > high-energy particle. That's a normal but fairly rare event. If you > get bit flips often enough that you can recall details of more then > one of them on the same hardware, my guess would be that you're > dealing with something else -- bad/marginal memory, signal integrity > issues, power issues, overheating... The list continues.. In all those > cases hardware does *not* work correctly. Whether you can (or want to) > keep running stuff on the hardware that is broken is another question. Have you read the article? :) If not, read at least the summary. > On Tue, Aug 24, 2010 at 1:15 AM, Andriy Gapon wrote: >> on 24/08/2010 09:14 Ronald Klop said the following: >>> >>> A little off topic, but what is 'a low rate of corrected ECC errors'? At work >>> one machine has them like ones per day, but runs ok. Is ones per day much? >> >> That's up to your judgment. It's like after how many remapped sectors do you >> replace HDD. >> You may find this interesting: >> http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf >> >> -- >> Andriy Gapon -- Andriy Gapon --------------070209070705070300020109-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 23:13:33 2010 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 26AAD1065679 for ; Tue, 24 Aug 2010 23:13:33 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id F079B8FC14 for ; Tue, 24 Aug 2010 23:13:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 628E450BAB for ; Wed, 25 Aug 2010 00:13:32 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJJqJ+Z0yaNK for ; Wed, 25 Aug 2010 00:13:28 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 6DABF50BA4 for ; Wed, 25 Aug 2010 00:13:28 +0100 (BST) Message-ID: <4C745213.3050004@langille.org> Date: Tue, 24 Aug 2010 19:13:23 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable References: <4C71CC62.6060803@langille.org> In-Reply-To: <4C71CC62.6060803@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 23:13:33 -0000 On 8/22/2010 9:18 PM, Dan Langille wrote: > What does this mean? > > kernel: MCA: Bank 4, Status 0x940c4001fe080813 > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > kernel: MCA: Address 0x7ff6b0 > > FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 FYI, these are occurring every hour, almost to the second. e.g. xx:56:yy, where yy is 09, 10, or 11. Checking logs, I don't see anything that correlates with this point in the hour (i.e 56 minutes past) that doesn't also occur at other times. It seems very odd to occur so regularly. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 23:21:44 2010 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 3B8ED1065697 for ; Tue, 24 Aug 2010 23:21:44 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFC68FC0C for ; Tue, 24 Aug 2010 23:21:43 +0000 (UTC) Received: (qmail 53731 invoked from network); 24 Aug 2010 22:55:01 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 24 Aug 2010 22:55:01 -0000 Message-ID: <4C744DC4.3070100@h3q.com> Date: Wed, 25 Aug 2010 00:55:00 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 23:21:44 -0000 Hi, I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes about once a day. I haven't found a way to trigger this yet. The system has a bunch of VLANs on em1, it does routing between them. Currently its running 8-STABLE but it happend with 8.1-RELEASE too. greetings, Philipp # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8061f5a8 stack pointer = 0x28:0xffffff80000e64d0 frame pointer = 0x28:0xffffff80000e64e0 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 = 0 (em1 taskq) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 13h24m39s Physical memory: 4079 MB Dumping 1349 MB: 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174 1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934 918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:224 224 __asm("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff8061f5a8 0xffffffff8061f5a8 is in m_tag_locate (/usr/src/sys/kern/uipc_mbuf2.c:389). 384 if (t == NULL) 385 p = SLIST_FIRST(&m->m_pkthdr.tags); 386 else 387 p = SLIST_NEXT(t, m_tag_link); 388 while (p != NULL) { 389 if (p->m_tag_cookie == cookie && p->m_tag_id == type) 390 return p; 391 p = SLIST_NEXT(p, m_tag_link); 392 } 393 return NULL; (kgdb) backtrace #0 doadump () at pcpu.h:224 #1 0xffffffff805c25ce in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805c29dc in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xffffffff808d40bd in trap_fatal (frame=0xffffffff80c8af60, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:777 #4 0xffffffff808d4a8b in trap (frame=0xffffff80000e6420) at /usr/src/sys/amd64/amd64/trap.c:588 #5 0xffffffff808b9d64 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xffffffff8061f5a8 in m_tag_locate (m=0xffffff010bb45c00, cookie=0, type=6, t=Variable "t" is not available. ) at /usr/src/sys/kern/uipc_mbuf2.c:388 #7 0xffffffff806d7c56 in ip_ipsec_output (m=0xffffff80000e6598, inp=0xffffff010be43150, flags=0xffffff80000e6594, error=0xffffff80000e65a8, ifp=Variable "ifp" is not available. ) at mbuf.h:1006 #8 0xffffffff806d97ef in ip_output (m=0xffffff010bb45c00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:483 #9 0xffffffff8073ef13 in tcp_output (tp=0xffffff000a9eb370) at /usr/src/sys/netinet/tcp_output.c:1190 #10 0xffffffff8073a42d in tcp_do_segment (m=0xffffff000a4cd800, th=0xffffff000a4df824, so=0xffffff000a9037f8, tp=0xffffff000a9eb370, drop_hdrlen=52, tlen=0, iptos=0 '\0', ti_locked=2) at /usr/src/sys/netinet/tcp_input.c:1484 #11 0xffffffff8073cf7b in tcp_input (m=0xffffff000a4cd800, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:1029 #12 0xffffffff806d7660 in ip_input (m=0xffffff000a4cd800) at /usr/src/sys/netinet/ip_input.c:793 #13 0xffffffff8067bd3e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:917 #14 0xffffffff806720fd in ether_demux (ifp=0xffffff0004fd4000, m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:901 #15 0xffffffff806724c7 in ether_input (ifp=0xffffff0004fd4000, m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:760 #16 0xffffffff8067201f in ether_demux (ifp=0xffffff0002686800, m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:810 #17 0xffffffff806724c7 in ether_input (ifp=0xffffff0002686800, m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:760 #18 0xffffffff8033a00b in em_rxeof (rxr=0xffffff00026f7400, count=100, done=0x0) at /usr/src/sys/dev/e1000/if_em.c:4196 #19 0xffffffff8033aab8 in em_handle_que (context=Variable "context" is not available. ) at /usr/src/sys/dev/e1000/if_em.c:1451 #20 0xffffffff805ff704 in taskqueue_run (queue=0xffffff0002727b80) at /usr/src/sys/kern/subr_taskqueue.c:239 #21 0xffffffff805ff976 in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/subr_taskqueue.c:360 #22 0xffffffff805985a8 in fork_exit ( callout=0xffffffff805ff930 , arg=0xffffff80003c1740, frame=0xffffff80000e6c80) at /usr/src/sys/kern/kern_fork.c:844 #23 0xffffffff808ba23e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:566 #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x00000000010d1000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0xffffffff80cb0fa0 in sleepq_chains () #52 0xffffff00025087c0 in ?? () #53 0xffffff80000e6b20 in ?? () #54 0xffffff80000e6ad8 in ?? () #55 0xffffff00026877c0 in ?? () #56 0xffffffff805e64fa in sched_switch (td=0xffffff80003c1740, newtd=0xffffffff805ff930, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1844 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 24 23:38:53 2010 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 D6B7D1065693 for ; Tue, 24 Aug 2010 23:38:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) 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 83D618FC17 for ; Tue, 24 Aug 2010 23:38:52 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id yPMn1e0040cZkys56PetFF; Tue, 24 Aug 2010 23:38:53 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta10.westchester.pa.mail.comcast.net with comcast id yPeq1e00N3LrwQ23WPerB4; Tue, 24 Aug 2010 23:38:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 10E8E9B425; Tue, 24 Aug 2010 16:38:49 -0700 (PDT) Date: Tue, 24 Aug 2010 16:38:49 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20100824233849.GA35100@icarus.home.lan> References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C745213.3050004@langille.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2010 23:38:53 -0000 On Tue, Aug 24, 2010 at 07:13:23PM -0400, Dan Langille wrote: > On 8/22/2010 9:18 PM, Dan Langille wrote: > >What does this mean? > > > >kernel: MCA: Bank 4, Status 0x940c4001fe080813 > >kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > >kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > >kernel: MCA: CPU 0 COR BUSLG Source RD Memory > >kernel: MCA: Address 0x7ff6b0 > > > >FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > FYI, these are occurring every hour, almost to the second. e.g. > xx:56:yy, where yy is 09, 10, or 11. > > Checking logs, I don't see anything that correlates with this point > in the hour (i.e 56 minutes past) that doesn't also occur at other > times. > > It seems very odd to occur so regularly. 1) Why haven't you replaced the DIMM in Bank 4 -- or better yet, all the DIMMs just to be sure? Do this and see if the problem goes away. If not, no harm done, and you've narrowed it down. 2) What exact manufacturer and model of motherboard is this? If you can provide a link to a User Manual that would be great. 3) Please go into your system BIOS and find where "ECC ChipKill" options are available (likely under a Memory, Chipset, or Northbridge section). Please write down and provide here all of the options and what their currently selected values are. 4) Please make sure you're running the latest system BIOS. I've seen on certain Rackable AMD-based systems where Northbridge-related features don't work quite right (at least with Solaris), resulting in atrocious memory performance on the system. A BIOS upgrade solved the problem. There's a ChipKill feature called "ECC BG Scrubbing" that's vague in definition, given that it's a "background memory scrub" that happens at intervals which are unknown to me. Maybe 60 minutes? I don't know. This is why I ask question #3. For John and other devs: I assume the decoded MCA messages indicate with absolute certainty that the ECC error is coming from external DRAM and not, say, bad L1 or L2 cache? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 00:42:00 2010 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 5FF5D1065673 for ; Wed, 25 Aug 2010 00:42:00 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 225DE8FC16 for ; Wed, 25 Aug 2010 00:41:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6A86150BAB; Wed, 25 Aug 2010 01:41:59 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJEThQZD-8ac; Wed, 25 Aug 2010 01:41:57 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id C2B7A50BA4 ; Wed, 25 Aug 2010 01:41:57 +0100 (BST) Message-ID: <4C7466D0.7080200@langille.org> Date: Tue, 24 Aug 2010 20:41:52 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <20100824233849.GA35100@icarus.home.lan> In-Reply-To: <20100824233849.GA35100@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 00:42:00 -0000 On 8/24/2010 7:38 PM, Jeremy Chadwick wrote: > On Tue, Aug 24, 2010 at 07:13:23PM -0400, Dan Langille wrote: >> On 8/22/2010 9:18 PM, Dan Langille wrote: >>> What does this mean? >>> >>> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >>> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>> kernel: MCA: Address 0x7ff6b0 >>> >>> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >> >> FYI, these are occurring every hour, almost to the second. e.g. >> xx:56:yy, where yy is 09, 10, or 11. >> >> Checking logs, I don't see anything that correlates with this point >> in the hour (i.e 56 minutes past) that doesn't also occur at other >> times. >> >> It seems very odd to occur so regularly. > > 1) Why haven't you replaced the DIMM in Bank 4 -- or better yet, all > the DIMMs just to be sure? Do this and see if the problem goes > away. If not, no harm done, and you've narrowed it down. For good reason: time and distance. I've not hand the time or opportunity to buy new RAM. Today is Tuesday. The problem appeared about 48 hours ago after upgrading to 8.1 stable from 7.x. The box is in Austin. I'm in Philadelphia. You know the math. ;) When I can get the time to fly to Austin, I will if required. I'm sorry, I'm not meaning to be flippant. I'm just glad I documented as such as I could 4 years ago. > 2) What exact manufacturer and model of motherboard is this? If > you can provide a link to a User Manual that would be great. This is a box from iXsystems that I obtained back when 6.1-RELEASE was the latest. I know it has four sticks of 2GB. http://www.freebsddiary.org/dual-opteron.php Sadly, many of the links are now invalid. The board is a AccelerTech ATO2161-DC, also known as a RioWorks HDAMA-G. See also: http://www.freebsddiary.org/dual-opteron-dmidecode.txt And we have a close up of the RAM and the m/b: http://www.freebsddiary.org/showpicture.php?id=85 http://www.freebsddiary.org/showpicture.php?id=84 I am quite sure it's very close to this: http://www.accelertech.com/2007/amd_mb/opteron/ato2161i-dc_pic.php With the manual here: http://www.accelertech.com/2007/amd_mb/opteron/ato2161i-dc_manual.php > 3) Please go into your system BIOS and find where "ECC ChipKill" > options are available (likely under a Memory, Chipset, or > Northbridge section). Please write down and provide here all > of the options and what their currently selected values are. > > 4) Please make sure you're running the latest system BIOS. I've seen > on certain Rackable AMD-based systems where Northbridge-related > features don't work quite right (at least with Solaris), resulting > in atrocious memory performance on the system. A BIOS upgrade > solved the problem. 3 & 4 are just as hard as #1 at the moment. > There's a ChipKill feature called "ECC BG Scrubbing" that's vague in > definition, given that it's a "background memory scrub" that happens at > intervals which are unknown to me. Maybe 60 minutes? I don't know. > This is why I ask question #3. > > For John and other devs: I assume the decoded MCA messages indicate with > absolute certainty that the ECC error is coming from external DRAM and > not, say, bad L1 or L2 cache? Nice question. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 01:10:01 2010 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 5E9D81065698 for ; Wed, 25 Aug 2010 01:10:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2-6.sentex.ca [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id D13B98FC0C for ; Wed, 25 Aug 2010 01:10:00 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7P19v1a006001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2010 21:09:57 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7P19uEp046002; Tue, 24 Aug 2010 21:09:56 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008250109.o7P19uEp046002@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 21:10:02 -0400 To: Philipp Wuensche , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4C744DC4.3070100@h3q.com> References: <4C744DC4.3070100@h3q.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 01:10:01 -0000 At 06:55 PM 8/24/2010, Philipp Wuensche wrote: >Hi, > >I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes >about once a day. I haven't found a way to trigger this yet. > >The system has a bunch of VLANs on em1, it does routing between them. > >Currently its running 8-STABLE but it happend with 8.1-RELEASE too. I dont think its the same problem you are seeing, but the patch in http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058296.html might be worth a try. ---Mike >greetings, >Philipp > ># kgdb kernel.debug /var/crash/vmcore.0 >GNU gdb 6.1.1 [FreeBSD] >Copyright 2004 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain >conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "amd64-marcel-freebsd"... > >Unread portion of the kernel message buffer: > > >Fatal trap 9: general protection fault while in kernel mode >cpuid = 0; apic id = 00 >instruction pointer = 0x20:0xffffffff8061f5a8 >stack pointer = 0x28:0xffffff80000e64d0 >frame pointer = 0x28:0xffffff80000e64e0 >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 = 0 (em1 taskq) >trap number = 9 >panic: general protection fault >cpuid = 0 >Uptime: 13h24m39s >Physical memory: 4079 MB >Dumping 1349 MB: 1334 1318 1302 1286 1270 1254 1238 1222 1206 1190 1174 >1158 1142 1126 1110 1094 1078 1062 1046 1030 1014 998 982 966 950 934 >918 902 886 870 854 838 822 806 790 774 758 742 726 710 694 678 662 646 >630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 >342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 >38 22 6 > >Reading symbols from /boot/kernel/zfs.ko...Reading symbols from >/boot/kernel/zfs.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/zfs.ko >Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from >/boot/kernel/opensolaris.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/opensolaris.ko >Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from >/boot/kernel/coretemp.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/coretemp.ko >Reading symbols from /boot/kernel/ahci.ko...Reading symbols from >/boot/kernel/ahci.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/ahci.ko >Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from >/boot/kernel/ipmi.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/ipmi.ko >Reading symbols from /boot/kernel/smbus.ko...Reading symbols from >/boot/kernel/smbus.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/smbus.ko >Reading symbols from /boot/kernel/pflog.ko...Reading symbols from >/boot/kernel/pflog.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/pflog.ko >Reading symbols from /boot/kernel/pf.ko...Reading symbols from >/boot/kernel/pf.ko.symbols...done. >done. >Loaded symbols for /boot/kernel/pf.ko >#0 doadump () at pcpu.h:224 >224 __asm("movq %%gs:0,%0" : "=r" (td)); >(kgdb) list *0xffffffff8061f5a8 >0xffffffff8061f5a8 is in m_tag_locate (/usr/src/sys/kern/uipc_mbuf2.c:389). >384 if (t == NULL) >385 p = SLIST_FIRST(&m->m_pkthdr.tags); >386 else >387 p = SLIST_NEXT(t, m_tag_link); >388 while (p != NULL) { >389 if (p->m_tag_cookie == cookie && p->m_tag_id == type) >390 return p; >391 p = SLIST_NEXT(p, m_tag_link); >392 } >393 return NULL; >(kgdb) backtrace >#0 doadump () at pcpu.h:224 >#1 0xffffffff805c25ce in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 >#2 0xffffffff805c29dc in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:590 >#3 0xffffffff808d40bd in trap_fatal (frame=0xffffffff80c8af60, >eva=Variable "eva" is not available. >) > at /usr/src/sys/amd64/amd64/trap.c:777 >#4 0xffffffff808d4a8b in trap (frame=0xffffff80000e6420) > at /usr/src/sys/amd64/amd64/trap.c:588 >#5 0xffffffff808b9d64 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 >#6 0xffffffff8061f5a8 in m_tag_locate (m=0xffffff010bb45c00, cookie=0, > type=6, t=Variable "t" is not available. >) at /usr/src/sys/kern/uipc_mbuf2.c:388 >#7 0xffffffff806d7c56 in ip_ipsec_output (m=0xffffff80000e6598, > inp=0xffffff010be43150, flags=0xffffff80000e6594, > error=0xffffff80000e65a8, ifp=Variable "ifp" is not available. >) at mbuf.h:1006 >#8 0xffffffff806d97ef in ip_output (m=0xffffff010bb45c00, opt=Variable >"opt" is not available. >) > at /usr/src/sys/netinet/ip_output.c:483 >#9 0xffffffff8073ef13 in tcp_output (tp=0xffffff000a9eb370) > at /usr/src/sys/netinet/tcp_output.c:1190 >#10 0xffffffff8073a42d in tcp_do_segment (m=0xffffff000a4cd800, > th=0xffffff000a4df824, so=0xffffff000a9037f8, tp=0xffffff000a9eb370, > drop_hdrlen=52, tlen=0, iptos=0 '\0', ti_locked=2) > at /usr/src/sys/netinet/tcp_input.c:1484 >#11 0xffffffff8073cf7b in tcp_input (m=0xffffff000a4cd800, off0=Variable >"off0" is not available. >) > at /usr/src/sys/netinet/tcp_input.c:1029 >#12 0xffffffff806d7660 in ip_input (m=0xffffff000a4cd800) > at /usr/src/sys/netinet/ip_input.c:793 >#13 0xffffffff8067bd3e in netisr_dispatch_src (proto=1, source=Variable >"source" is not available. >) > at /usr/src/sys/net/netisr.c:917 >#14 0xffffffff806720fd in ether_demux (ifp=0xffffff0004fd4000, > m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:901 >#15 0xffffffff806724c7 in ether_input (ifp=0xffffff0004fd4000, > m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:760 >#16 0xffffffff8067201f in ether_demux (ifp=0xffffff0002686800, > m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:810 >#17 0xffffffff806724c7 in ether_input (ifp=0xffffff0002686800, > m=0xffffff000a4cd800) at /usr/src/sys/net/if_ethersubr.c:760 >#18 0xffffffff8033a00b in em_rxeof (rxr=0xffffff00026f7400, count=100, > done=0x0) at /usr/src/sys/dev/e1000/if_em.c:4196 >#19 0xffffffff8033aab8 in em_handle_que (context=Variable "context" is >not available. >) > at /usr/src/sys/dev/e1000/if_em.c:1451 >#20 0xffffffff805ff704 in taskqueue_run (queue=0xffffff0002727b80) > at /usr/src/sys/kern/subr_taskqueue.c:239 >#21 0xffffffff805ff976 in taskqueue_thread_loop (arg=Variable "arg" is >not available. >) > at /usr/src/sys/kern/subr_taskqueue.c:360 >#22 0xffffffff805985a8 in fork_exit ( > callout=0xffffffff805ff930 , > arg=0xffffff80003c1740, frame=0xffffff80000e6c80) > at /usr/src/sys/kern/kern_fork.c:844 >#23 0xffffffff808ba23e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:566 >#24 0x0000000000000000 in ?? () >#25 0x0000000000000000 in ?? () >#26 0x0000000000000000 in ?? () >#27 0x0000000000000000 in ?? () >#28 0x0000000000000000 in ?? () >#29 0x0000000000000000 in ?? () >#30 0x0000000000000000 in ?? () >#31 0x0000000000000000 in ?? () >#32 0x0000000000000000 in ?? () >#33 0x0000000000000000 in ?? () >#34 0x0000000000000000 in ?? () >#35 0x0000000000000000 in ?? () >#36 0x0000000000000000 in ?? () >#37 0x0000000000000000 in ?? () >#38 0x0000000000000000 in ?? () >#39 0x0000000000000000 in ?? () >#40 0x0000000000000000 in ?? () >#41 0x0000000000000000 in ?? () >#42 0x0000000000000000 in ?? () >#43 0x0000000000000000 in ?? () >#44 0x0000000000000000 in ?? () >#45 0x0000000000000000 in ?? () >#46 0x0000000000000000 in ?? () >#47 0x0000000000000000 in ?? () >#48 0x00000000010d1000 in ?? () >#49 0x0000000000000000 in ?? () >#50 0x0000000000000000 in ?? () >#51 0xffffffff80cb0fa0 in sleepq_chains () >#52 0xffffff00025087c0 in ?? () >#53 0xffffff80000e6b20 in ?? () >#54 0xffffff80000e6ad8 in ?? () >#55 0xffffff00026877c0 in ?? () >#56 0xffffffff805e64fa in sched_switch (td=0xffffff80003c1740, > newtd=0xffffffff805ff930, flags=Variable "flags" is not available. >) at /usr/src/sys/kern/sched_ule.c:1844 >Previous frame inner to this frame (corrupt stack?) >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 04:05:13 2010 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 4229D10656A4; Wed, 25 Aug 2010 04:05:13 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 17D3E8FC17; Wed, 25 Aug 2010 04:05:12 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 90ACA37B462; Tue, 24 Aug 2010 23:05:10 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id C277A61C57; Tue, 24 Aug 2010 23:05:09 -0500 (CDT) Date: Tue, 24 Aug 2010 23:05:09 -0500 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20100825040509.GJ49588@over-yonder.net> References: <4C71CC62.6060803@langille.org> <201008230820.35260.jhb@freebsd.org> <20100823213540.GD49588@over-yonder.net> <201008241106.43878.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008241106.43878.jhb@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 04:05:13 -0000 On Tue, Aug 24, 2010 at 11:06:43AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: > > It is actually public at perforce.freebsd.org. :) However, it is > tedious to download the files. Oh, I'd apparently blocked out of my mind that you could clicky-clicky files one at a time from there. Probably for the best; I'd be real annoyed by the end of that ;) > You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also > need to download the memstream.c file from there as well and put > that in the extracted mcelog tarball. Thanks! For anyone following along at home, I needed to make a few changes to get it compiling here: - I'm on a nice recent -CURRENT, so I had to #if 0 out the getline() definition. - Add a FREEBSD definition to the Makefile (or remember it manually). - Comment out the kread_symbol() of X_SNAPDATE in mcelog.c. I don't see X_SNAPDATE defined anywhere in my /usr/include, and the var doesn't seem to ever actually be read for anything anyway (unless I'm supposed to -DLOCAL_HACK...). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 07:00:20 2010 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 0B5491065674; Wed, 25 Aug 2010 07:00:20 +0000 (UTC) (envelope-from stark@mapper.nl) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD2B8FC1F; Wed, 25 Aug 2010 07:00:14 +0000 (UTC) Received: from [82.170.17.27] (helo=mapper.nl) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1Oo9hJ-0000fv-0x; Wed, 25 Aug 2010 08:42:57 +0200 Received: from yoshi ([10.58.235.3] helo=[0.0.0.0]) by mapper.nl with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oo9hF-000Ney-DN; Wed, 25 Aug 2010 08:42:53 +0200 Message-ID: <4C74BB68.4020003@mapper.nl> Date: Wed, 25 Aug 2010 08:42:48 +0200 From: Mark Stapper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C587A523C9ADCF34BD91D76" Cc: Subject: cone segmentation fault on 8.0-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: Wed, 25 Aug 2010 07:00:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C587A523C9ADCF34BD91D76 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I'm running cone on 8.0-STABLE. When I run the program for the first time it works like a charm! Cone then creates a configuration directory and conerc. When I run cone the second time it crashed with a segmentation fault. Then after removing the "OPTIONS" node from the config file cone starts again. When I go to the setup menu and hit "save" also crashes with segfault. Any ideas? Cheers, Mark conerc:
xxxx@xxxx
 --------------enig6C587A523C9ADCF34BD91D76 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx0u24ACgkQN9xNqOOVnWBncwCfWSei7D+9yQVTZO1vdTaMqv/o h00An09gBjsEBTWaZv1S4lin0TCknrD/ =W9Ao -----END PGP SIGNATURE----- --------------enig6C587A523C9ADCF34BD91D76-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 07:11:39 2010 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 C69731065697 for ; Wed, 25 Aug 2010 07:11:39 +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 18EB58FC1B for ; Wed, 25 Aug 2010 07:11:38 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA23611; Wed, 25 Aug 2010 10:11:31 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OoA8w-000KUU-P0; Wed, 25 Aug 2010 10:11:30 +0300 Message-ID: <4C74C221.5020702@icyb.net.ua> Date: Wed, 25 Aug 2010 10:11:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <20100824233849.GA35100@icarus.home.lan> In-Reply-To: <20100824233849.GA35100@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Dan Langille Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 07:11:39 -0000 on 25/08/2010 02:38 Jeremy Chadwick said the following: > On Tue, Aug 24, 2010 at 07:13:23PM -0400, Dan Langille wrote: >> On 8/22/2010 9:18 PM, Dan Langille wrote: >>> What does this mean? >>> >>> kernel: MCA: Bank 4, Status 0x940c4001fe080813 >>> kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 >>> kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 >>> kernel: MCA: CPU 0 COR BUSLG Source RD Memory >>> kernel: MCA: Address 0x7ff6b0 >>> >>> FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 >> >> FYI, these are occurring every hour, almost to the second. e.g. >> xx:56:yy, where yy is 09, 10, or 11. >> >> Checking logs, I don't see anything that correlates with this point >> in the hour (i.e 56 minutes past) that doesn't also occur at other >> times. >> >> It seems very odd to occur so regularly. I still think that everything of essence has already been said in this thread. > 1) Why haven't you replaced the DIMM in Bank 4 -- or better yet, all Bank 4 here is MCA reporting bank, it has nothing to do with RAM slots. Currently on FreeBSD we don't have a standard tool to map physical address to DRAM module, but I am sure that there could be some ways to do it. > the DIMMs just to be sure? Do this and see if the problem goes > away. If not, no harm done, and you've narrowed it down. > > 2) What exact manufacturer and model of motherboard is this? If > you can provide a link to a User Manual that would be great. > > 3) Please go into your system BIOS and find where "ECC ChipKill" > options are available (likely under a Memory, Chipset, or > Northbridge section). Please write down and provide here all > of the options and what their currently selected values are. > > 4) Please make sure you're running the latest system BIOS. I've seen > on certain Rackable AMD-based systems where Northbridge-related > features don't work quite right (at least with Solaris), resulting > in atrocious memory performance on the system. A BIOS upgrade > solved the problem. > > There's a ChipKill feature called "ECC BG Scrubbing" that's vague in > definition, given that it's a "background memory scrub" that happens at > intervals which are unknown to me. Maybe 60 minutes? I don't know. > This is why I ask question #3. > > For John and other devs: I assume the decoded MCA messages indicate with > absolute certainty that the ECC error is coming from external DRAM and > not, say, bad L1 or L2 cache? Have you read the decoded message? Please re-read it. I still recommend reading at least the summary of the RAM ECC research article to make your own judgment about need to replace DRAM. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 07:47:16 2010 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 1B04F10656A3 for ; Wed, 25 Aug 2010 07:47:16 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id D23DB8FC0A for ; Wed, 25 Aug 2010 07:47:15 +0000 (UTC) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OoAaK-0001jr-S2; Wed, 25 Aug 2010 09:39:48 +0200 From: Heinrich Rebehn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Aug 2010 09:47:13 +0200 To: freebsd-stable@freebsd.org Message-Id: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: zfs sharenfs with multiple hosts/networks and options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 07:47:16 -0000 Hi list, with traditional /etc/exports i can do /export/linux/root -ro xxx.xxx.xxx.0/24 /export/linux/root -maproot=3D0 xxx.xxx.xxx.1 How can i do this using zfs's sharenfs option? When i try=20 zfs set sharenfs=3D"-ro -network xxx.xxx.xxx.0/24,-maproot=3D0 = xxx.xxx.xxx.1" data/linux/root /var/log/messages shows "network/host conflict" and "bad exports list = line. The general problem seems to be that with each "zfs set sharenfs" = command, the corresponding in /etc/zfs/exports gets overwritten. Is there a workaround for this besides ignoring sharenfs and using hand = edited /etc/exports? Thanks for any help, Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax : -3341 From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 08:03:38 2010 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 99A161065670 for ; Wed, 25 Aug 2010 08:03:38 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id 353898FC1A for ; Wed, 25 Aug 2010 08:03:37 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.4/8.14.4) with ESMTP id o7P83YoD025407 for ; Wed, 25 Aug 2010 08:03:34 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.4/8.14.4/Submit) id o7P83Y2m025406 for freebsd-stable@freebsd.org; Wed, 25 Aug 2010 08:03:34 GMT (envelope-from marco) Date: Wed, 25 Aug 2010 08:03:34 +0000 From: Marco van Tol To: freebsd-stable@freebsd.org Message-ID: <20100825080334.GA24997@tolstoy.tols.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on tolstoy.tols.org Subject: Re: zfs sharenfs with multiple hosts/networks and options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 08:03:38 -0000 On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: > Hi list, > > with traditional /etc/exports i can do > > /export/linux/root -ro xxx.xxx.xxx.0/24 > /export/linux/root -maproot=0 xxx.xxx.xxx.1 > > How can i do this using zfs's sharenfs option? > > When i try > > zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" data/linux/root > > /var/log/messages shows "network/host conflict" and "bad exports list line. > > The general problem seems to be that with each "zfs set sharenfs" command, the corresponding in /etc/zfs/exports gets overwritten. > > Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? > > Thanks for any help, In december '09 I started a thread about it in freebsd-fs@. Subject: zfs sharenfs to multiple subnets - found a dirty looking hack I found a dirty hack to do what you need there. Not sure there is a more elegant way to do it already, would be nice. Marco -- Now watch me snatch defeat from the jaws of victory - "Rigoletto" during a game on www.dailygammon.com From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 08:22:52 2010 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 D5B3310656A4 for ; Wed, 25 Aug 2010 08:22:52 +0000 (UTC) (envelope-from quintessence@bobi.gateit.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6DD8FC19 for ; Wed, 25 Aug 2010 08:22:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7D1A55C71B for ; Wed, 25 Aug 2010 11:03:44 +0300 (EEST) X-Virus-Scanned: amavisd-new at bulinfo.net Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0sanzh07W5f for ; Wed, 25 Aug 2010 11:03:44 +0300 (EEST) Received: from [192.168.1.247] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 377285C711 for ; Wed, 25 Aug 2010 11:03:44 +0300 (EEST) Message-ID: <4C74CEC2.7090700@bobi.gateit.net> Date: Wed, 25 Aug 2010 11:05:22 +0300 From: Bojidara Marinchovska User-Agent: Thunderbird 2.0.0.24 (X11/20100617) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: typo error in /etc/defaults/rc.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, 25 Aug 2010 08:22:53 -0000 Hello , Refers to rc.conf(5) the alternative way for cloning interfaces is by using create_args_ variable In rc.conf there is a typo error in variable name --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.000000000 +0300 +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.000000000 +0300 @@ -212,7 +212,7 @@ #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. #vlans_fxp0="101 vlan0" # vlan(4) interfaces for fxp0 device -#create_arg_vlan0="vlan 102" # vlan tag for vlan0 device +#create_args_vlan0="vlan 102" # vlan tag for vlan0 device #wlans_ath0="wlan0" # wlan(4) interfaces for ath0 device #wlandebug_wlan0="scan+auth+assoc" # Set debug flags with wlanddebug(8) #ipv4_addrs_fxp0="192.168.0.1/24 192.168.1.1-5/28" # example IPv4 address entry. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 08:24:18 2010 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 6045A1065695 for ; Wed, 25 Aug 2010 08:24:18 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id 218278FC1F for ; Wed, 25 Aug 2010 08:24:17 +0000 (UTC) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OoBAB-0001tg-Cn; Wed, 25 Aug 2010 10:16:51 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Heinrich Rebehn In-Reply-To: <20100825080334.GA24997@tolstoy.tols.org> Date: Wed, 25 Aug 2010 10:24:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> <20100825080334.GA24997@tolstoy.tols.org> To: Marco van Tol X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: zfs sharenfs with multiple hosts/networks and options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 08:24:18 -0000 On 25.08.2010, at 10:03, Marco van Tol wrote: > On Wed, Aug 25, 2010 at 09:47:13AM +0200, Heinrich Rebehn wrote: >> Hi list, >>=20 >> with traditional /etc/exports i can do >>=20 >> /export/linux/root -ro xxx.xxx.xxx.0/24 >> /export/linux/root -maproot=3D0 xxx.xxx.xxx.1 >>=20 >> How can i do this using zfs's sharenfs option? >>=20 >> When i try=20 >>=20 >> zfs set sharenfs=3D"-ro -network xxx.xxx.xxx.0/24,-maproot=3D0 = xxx.xxx.xxx.1" data/linux/root >>=20 >> /var/log/messages shows "network/host conflict" and "bad exports list = line. >>=20 >> The general problem seems to be that with each "zfs set sharenfs" = command, the corresponding in /etc/zfs/exports gets overwritten. >>=20 >> Is there a workaround for this besides ignoring sharenfs and using = hand edited /etc/exports? >>=20 >> Thanks for any help, >=20 > In december '09 I started a thread about it in freebsd-fs@.=20 > Subject: zfs sharenfs to multiple subnets - found a dirty looking hack >=20 > I found a dirty hack to do what you need there. Not sure there is a > more elegant way to do it already, would be nice. >=20 > Marco I already found your hack (after starting this thread) and it does work. = However, when i then use zfs to create a descendant filesystem, things = go wrong because when inheriting the sharenfs property from the parent, = zfs does not adjust the mountpoint that i used in the hack. Similar = problems will probably arise if one choses to change the mountpoint of = the filesystem afterwards. Thanks anyway for the hint! -Heinrich >=20 > --=20 > Now watch me snatch defeat from the jaws of victory > - "Rigoletto" during a game on www.dailygammon.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20 Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax : -3341 From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 08:37:47 2010 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 EDAA310656C7 for ; Wed, 25 Aug 2010 08:37:47 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 755938FC0A for ; Wed, 25 Aug 2010 08:37:47 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by mp2.macomnet.net (8.14.3/8.14.3) with ESMTP id o7P8bZSv018311; Wed, 25 Aug 2010 12:37:35 +0400 (MSD) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 25 Aug 2010 12:37:34 +0400 (MSD) From: Maxim Konovalov To: Bojidara Marinchovska In-Reply-To: <4C74CEC2.7090700@bobi.gateit.net> Message-ID: References: <4C74CEC2.7090700@bobi.gateit.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: typo error in /etc/defaults/rc.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, 25 Aug 2010 08:37:48 -0000 Fixed. Thanks for the patch. On Wed, 25 Aug 2010, 11:05+0300, Bojidara Marinchovska wrote: > Hello , > > Refers to rc.conf(5) the alternative way for cloning interfaces is by using > create_args_ variable > In rc.conf there is a typo error in variable name > > > --- /etc/defaults/rc.conf.orig 2010-08-25 11:01:12.000000000 +0300 > +++ /etc/defaults/rc.conf 2010-08-25 11:01:29.000000000 +0300 > @@ -212,7 +212,7 @@ > #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. > #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. > #vlans_fxp0="101 vlan0" # vlan(4) interfaces for fxp0 device > -#create_arg_vlan0="vlan 102" # vlan tag for vlan0 device > +#create_args_vlan0="vlan 102" # vlan tag for vlan0 device > #wlans_ath0="wlan0" # wlan(4) interfaces for ath0 device > #wlandebug_wlan0="scan+auth+assoc" # Set debug flags with wlanddebug(8) > #ipv4_addrs_fxp0="192.168.0.1/24 192.168.1.1-5/28" # example IPv4 > address entry. > > > _______________________________________________ > 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" > -- Maxim Konovalov From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 09:56:20 2010 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 E227A106566B for ; Wed, 25 Aug 2010 09:56:20 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CCCB8FC16 for ; Wed, 25 Aug 2010 09:56:20 +0000 (UTC) Received: by qyk4 with SMTP id 4so372573qyk.13 for ; Wed, 25 Aug 2010 02:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1zsWQ0JI8A+IjDgiMdZgdfU62kaJ9e3GLACxlh8ynm8=; b=hkJ1btIKzIcjlBPnlxsAsawifXgW0L5RjJdC5D7Y+pN/NgIL8PDT+KG77Q8FWIOQHR LetR82uypTwoy9r6H6uW3CKus4reJ6CokBSvB5+UYHFWstlbkON8W9+ceTHWh6J+5OTw Q78l/UzdUugYJs/r3l8QOeYs7swpAKzBLX42Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mTQN5FHvIGAzzt3dldj1wdIeovexhnqjVi+nTGW6nPymirSnqnb7XHAfRFJuoRfEeC WAnyhY46BzBDxrpom33Hs3O3D1QyYVBh5Md3sXJs+UKX5uWHe2iTQT87jK2QvpZU5NH/ 9pSFb2sJ73gFpUIKNTvqbytVfxxTKjsDode9g= MIME-Version: 1.0 Received: by 10.224.75.211 with SMTP id z19mr5356730qaj.185.1282730178984; Wed, 25 Aug 2010 02:56:18 -0700 (PDT) Received: by 10.229.248.202 with HTTP; Wed, 25 Aug 2010 02:56:18 -0700 (PDT) In-Reply-To: <201008241106.43878.jhb@freebsd.org> References: <4C71CC62.6060803@langille.org> <201008230820.35260.jhb@freebsd.org> <20100823213540.GD49588@over-yonder.net> <201008241106.43878.jhb@freebsd.org> Date: Wed, 25 Aug 2010 10:56:18 +0100 Message-ID: From: Tom Evans To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, "Matthew D. Fuller" Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 09:56:21 -0000 On Tue, Aug 24, 2010 at 4:06 PM, John Baldwin wrote: > On Monday, August 23, 2010 5:35:40 pm Matthew D. Fuller wrote: >> On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of >> John Baldwin, and lo! it spake thus: >> > >> > It is not private, it is in //depot/projects/mcelog/... in p4. >> >> Which may as well be Siberia for us lowly non-developers. =C2=A0Any chan= ce >> you could stick a tarball or a patch against upstream mcelog >> somewhere? > > It is actually public at perforce.freebsd.org. :) =C2=A0However, it is te= dious to > download the files. =C2=A0It really should be a port perhaps, though Some= one (tm) > should try to get the patches integrated upstream. > > You can find a patch at www.freebsd.org/~jhb/mcelog/. =C2=A0You will also= need to > download the memstream.c file from there as well and put that in the extr= acted > mcelog tarball. > I wrote a small script a while back to extract a tree from perforce using the web interface, might be handy: http://www.clearchain.com/~benjsc/downloads/FreeBSD/P4fetch.rb Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 10:41:55 2010 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 8F5B41065672 for ; Wed, 25 Aug 2010 10:41:55 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 643218FC08 for ; Wed, 25 Aug 2010 10:41:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6B7EE50BAB; Wed, 25 Aug 2010 11:41:54 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXw-gmwr-lmx; Wed, 25 Aug 2010 11:41:52 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id AE04950B97 ; Wed, 25 Aug 2010 11:41:52 +0100 (BST) Message-ID: <4C74F36B.2060200@langille.org> Date: Wed, 25 Aug 2010 06:41:47 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <20100824233849.GA35100@icarus.home.lan> <4C74C221.5020702@icyb.net.ua> In-Reply-To: <4C74C221.5020702@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Jeremy Chadwick Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 10:41:55 -0000 On 8/25/2010 3:11 AM, Andriy Gapon wrote: > Have you read the decoded message? > Please re-read it. > > I still recommend reading at least the summary of the RAM ECC research article > to make your own judgment about need to replace DRAM. Andriy: What is your interpretation of the decoded message? What is your view on replacing DRAM? What do you conclude from the summary? -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 11:01:26 2010 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 8549F10656A6 for ; Wed, 25 Aug 2010 11:01:26 +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 C8ED28FC13 for ; Wed, 25 Aug 2010 11:01:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29560; Wed, 25 Aug 2010 14:01:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C74F7FF.8000704@icyb.net.ua> Date: Wed, 25 Aug 2010 14:01:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Dan Langille References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <20100824233849.GA35100@icarus.home.lan> <4C74C221.5020702@icyb.net.ua> <4C74F36B.2060200@langille.org> In-Reply-To: <4C74F36B.2060200@langille.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Jeremy Chadwick Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 11:01:26 -0000 on 25/08/2010 13:41 Dan Langille said the following: > On 8/25/2010 3:11 AM, Andriy Gapon wrote: > >> Have you read the decoded message? >> Please re-read it. >> >> I still recommend reading at least the summary of the RAM ECC research article >> to make your own judgment about need to replace DRAM. > > Andriy: What is your interpretation of the decoded message? What is your view on > replacing DRAM? What do you conclude from the summary? Most likely you have a small defect in one of your memory modules, perhaps a "stuck" bit. You will be getting correctable ECC errors for that module. Eventually you might get uncorrectable error. That may happen soon or it may never happen during lifetime of that modules. As that study has demonstrated a significant percentage of systems and modules report at least one correctable ECC error. ECC correctable errors at present correlate with correctable ECC errors in the future. They also correlate with uncorrectable errors in the future. But percentage of systems developing uncorrectable errors is significantly smaller, so chances of false positives are substantial. You should decide whether you want to replace the module (if you can pinpoint it) or all modules depending on your resources (money, etc), importance of service that the server in question provides (allowable downtime and cost of it and fault-tolerance of a larger system, of which the server may be a part (e.g. it may have a standby server for failover). I think that most of what I've just said was kind of obvious from the start. The important bit from that study is that ECC errors are not as random and as rare as was previously thought, and they can be attributed to a number of factors like manufacturing defects, layout of memory lanes on motherboard, etc. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 04:40:27 2010 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 69DE61065693 for ; Wed, 25 Aug 2010 04:40:27 +0000 (UTC) (envelope-from mi+thunw@aldan.algebra.com) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE018FC08 for ; Wed, 25 Aug 2010 04:40:26 +0000 (UTC) Received: from [192.168.1.9] ([unknown] [173.70.194.135]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7O00ALXYAPINP5@vms173005.mailsrvcs.net>; Tue, 24 Aug 2010 23:40:05 -0500 (CDT) Message-id: <4C749E8C.1020506@aldan.algebra.com> Date: Wed, 25 Aug 2010 00:39:40 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-version: 1.0 To: sam@FreeBSD.org X-Mailman-Approved-At: Wed, 25 Aug 2010 11:03:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@FreeBSD.org Subject: Can't compile ath(4) into kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 04:40:27 -0000 My laptop's kernel config file reads: device wlan # 802.11 support device ath device ath_ar5212 device ath_rate_onoe Config raises no objections and the compilation succeeds, but linking the kernel breaks: ... linking kernel.debug ah.o(.text+0x218): In function `ath_hal_rfprobe': /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__start_set_ah_rfs' ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to `__stop_set_ah_rfs' *** Error code 1 What could this be? All modules (including ath_hal) build correctly... Thank you! -mi From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 11:47:57 2010 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 5704310656AC for ; Wed, 25 Aug 2010 11:47:57 +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 263028FC16 for ; Wed, 25 Aug 2010 11:47:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ABBDE46B03; Wed, 25 Aug 2010 07:47:56 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C4218A04E; Wed, 25 Aug 2010 07:47:54 -0400 (EDT) From: John Baldwin To: "Matthew D. Fuller" Date: Wed, 25 Aug 2010 07:40:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71CC62.6060803@langille.org> <201008241106.43878.jhb@freebsd.org> <20100825040509.GJ49588@over-yonder.net> In-Reply-To: <20100825040509.GJ49588@over-yonder.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008250740.46733.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 25 Aug 2010 07:47:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 11:47:57 -0000 On Wednesday, August 25, 2010 12:05:09 am Matthew D. Fuller wrote: > On Tue, Aug 24, 2010 at 11:06:43AM -0400 I heard the voice of > John Baldwin, and lo! it spake thus: > > > > It is actually public at perforce.freebsd.org. :) However, it is > > tedious to download the files. > > Oh, I'd apparently blocked out of my mind that you could clicky-clicky > files one at a time from there. Probably for the best; I'd be real > annoyed by the end of that ;) > > > > You can find a patch at www.freebsd.org/~jhb/mcelog/. You will also > > need to download the memstream.c file from there as well and put > > that in the extracted mcelog tarball. > > Thanks! For anyone following along at home, I needed to make a few > changes to get it compiling here: > > - I'm on a nice recent -CURRENT, so I had to #if 0 out the getline() > definition. Yeah, that needs a __FreeBSD_version wrapper. > - Add a FREEBSD definition to the Makefile (or remember it manually). I just do 'gmake FREEBSD=yes'. > - Comment out the kread_symbol() of X_SNAPDATE in mcelog.c. I don't > see X_SNAPDATE defined anywhere in my /usr/include, and the var > doesn't seem to ever actually be read for anything anyway (unless > I'm supposed to -DLOCAL_HACK...). Bah, I must have missed that. You certainly don't want LOCAL_HACK. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 12:27:44 2010 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 156CB106566C for ; Wed, 25 Aug 2010 12:27:44 +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 D9D808FC1A for ; Wed, 25 Aug 2010 12:27:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7D1AF46B86; Wed, 25 Aug 2010 08:27:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75FB48A03C; Wed, 25 Aug 2010 08:27:42 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 25 Aug 2010 08:23:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> In-Reply-To: <4C745213.3050004@langille.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008250823.11954.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 25 Aug 2010 08:27:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dan Langille Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 12:27:44 -0000 On Tuesday, August 24, 2010 7:13:23 pm Dan Langille wrote: > On 8/22/2010 9:18 PM, Dan Langille wrote: > > What does this mean? > > > > kernel: MCA: Bank 4, Status 0x940c4001fe080813 > > kernel: MCA: Global Cap 0x0000000000000105, Status 0x0000000000000000 > > kernel: MCA: Vendor "AuthenticAMD", ID 0xf5a, APIC ID 0 > > kernel: MCA: CPU 0 COR BUSLG Source RD Memory > > kernel: MCA: Address 0x7ff6b0 > > > > FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 > > FYI, these are occurring every hour, almost to the second. e.g. > xx:56:yy, where yy is 09, 10, or 11. > > Checking logs, I don't see anything that correlates with this point in > the hour (i.e 56 minutes past) that doesn't also occur at other times. > > It seems very odd to occur so regularly. That is because machine checks for corrected errors have to be polled and the kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a separate interrupt (CMCI) that can fire for corrected errors. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 12:27:45 2010 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 BBDF9106564A for ; Wed, 25 Aug 2010 12:27:45 +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 8A77A8FC1C for ; Wed, 25 Aug 2010 12:27:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 318EB46B89; Wed, 25 Aug 2010 08:27:45 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CF4E78A04E; Wed, 25 Aug 2010 08:27:43 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 25 Aug 2010 08:25:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C71CC62.6060803@langille.org> <4C74F36B.2060200@langille.org> <4C74F7FF.8000704@icyb.net.ua> In-Reply-To: <4C74F7FF.8000704@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008250825.34903.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 25 Aug 2010 08:27:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andriy Gapon , Jeremy Chadwick , Dan Langille Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 12:27:45 -0000 On Wednesday, August 25, 2010 7:01:19 am Andriy Gapon wrote: > on 25/08/2010 13:41 Dan Langille said the following: > > On 8/25/2010 3:11 AM, Andriy Gapon wrote: > > > >> Have you read the decoded message? > >> Please re-read it. > >> > >> I still recommend reading at least the summary of the RAM ECC research article > >> to make your own judgment about need to replace DRAM. > > > > Andriy: What is your interpretation of the decoded message? What is your view on > > replacing DRAM? What do you conclude from the summary? > > Most likely you have a small defect in one of your memory modules, perhaps a > "stuck" bit. You will be getting correctable ECC errors for that module. > Eventually you might get uncorrectable error. That may happen soon or it may > never happen during lifetime of that modules. > > As that study has demonstrated a significant percentage of systems and modules > report at least one correctable ECC error. ECC correctable errors at present > correlate with correctable ECC errors in the future. They also correlate with > uncorrectable errors in the future. But percentage of systems developing > uncorrectable errors is significantly smaller, so chances of false positives are > substantial. > > You should decide whether you want to replace the module (if you can pinpoint it) > or all modules depending on your resources (money, etc), importance of service > that the server in question provides (allowable downtime and cost of it and > fault-tolerance of a larger system, of which the server may be a part (e.g. it may > have a standby server for failover). > > I think that most of what I've just said was kind of obvious from the start. > The important bit from that study is that ECC errors are not as random and as rare > as was previously thought, and they can be attributed to a number of factors like > manufacturing defects, layout of memory lanes on motherboard, etc. A while back I found a slide deck from some Intel presentation that claimed that a modern 4GB DIMM should average 18 corrected errors a month. Your rate is a bit higher than that, but corrected ECC errors are not that unexpected. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 12:27:47 2010 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 DB480106566C; Wed, 25 Aug 2010 12:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB4A98FC22; Wed, 25 Aug 2010 12:27:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5299D46B81; Wed, 25 Aug 2010 08:27:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CE4C8A04F; Wed, 25 Aug 2010 08:27:45 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 25 Aug 2010 08:27:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C749E8C.1020506@aldan.algebra.com> In-Reply-To: <4C749E8C.1020506@aldan.algebra.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008250827.13482.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 25 Aug 2010 08:27:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: stable@freebsd.org, sam@freebsd.org, "Mikhail T." Subject: Re: Can't compile ath(4) into kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:27:47 -0000 On Wednesday, August 25, 2010 12:39:40 am Mikhail T. wrote: > My laptop's kernel config file reads: > > device wlan # 802.11 support > device ath > device ath_ar5212 > device ath_rate_onoe > > Config raises no objections and the compilation succeeds, but linking > the kernel breaks: > > ... > linking kernel.debug > ah.o(.text+0x218): In function `ath_hal_rfprobe': > /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to > `__start_set_ah_rfs' > ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > *** Error code 1 > > What could this be? All modules (including ath_hal) build correctly... > Thank you! You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 12:27:47 2010 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 DB480106566C; Wed, 25 Aug 2010 12:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB4A98FC22; Wed, 25 Aug 2010 12:27:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5299D46B81; Wed, 25 Aug 2010 08:27:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CE4C8A04F; Wed, 25 Aug 2010 08:27:45 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 25 Aug 2010 08:27:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C749E8C.1020506@aldan.algebra.com> In-Reply-To: <4C749E8C.1020506@aldan.algebra.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008250827.13482.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 25 Aug 2010 08:27:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: stable@freebsd.org, sam@freebsd.org, "Mikhail T." Subject: Re: Can't compile ath(4) into kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:27:47 -0000 On Wednesday, August 25, 2010 12:39:40 am Mikhail T. wrote: > My laptop's kernel config file reads: > > device wlan # 802.11 support > device ath > device ath_ar5212 > device ath_rate_onoe > > Config raises no objections and the compilation succeeds, but linking > the kernel breaks: > > ... > linking kernel.debug > ah.o(.text+0x218): In function `ath_hal_rfprobe': > /home/mi/src/sys/dev/ath/ath_hal/ah.c:142: undefined reference to > `__start_set_ah_rfs' > ah.o(.text+0x21d):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > ah.o(.text+0x236):/home/mi/src/sys/dev/ath/ath_hal/ah.c:142: > undefined reference to `__stop_set_ah_rfs' > *** Error code 1 > > What could this be? All modules (including ath_hal) build correctly... > Thank you! You are missing: options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the changes to GENERIC across your upgrade. It would save you several e-mails to the mailing list. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 15:02:42 2010 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 EBE4610656A3; Wed, 25 Aug 2010 15:02:42 +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 E69FF8FC1C; Wed, 25 Aug 2010 15:02:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05325; Wed, 25 Aug 2010 18:02:40 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C75308F.3080504@icyb.net.ua> Date: Wed, 25 Aug 2010 18:02:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Baldwin References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <201008250823.11954.jhb@freebsd.org> In-Reply-To: <201008250823.11954.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 15:02:43 -0000 on 25/08/2010 15:23 John Baldwin said the following: > That is because machine checks for corrected errors have to be polled and the > kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a > separate interrupt (CMCI) that can fire for corrected errors. I think that on AMD it's possible to configure an interrupt for Bank 4 events as well (perhaps other banks too), but I need to refresh my memory of BKDG. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 16:03:54 2010 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 80EA51065698; Wed, 25 Aug 2010 16:03:54 +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 9177C8FC14; Wed, 25 Aug 2010 16:03:53 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06538; Wed, 25 Aug 2010 19:03:51 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C753EE7.3010805@icyb.net.ua> Date: Wed, 25 Aug 2010 19:03:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Baldwin References: <4C71CC62.6060803@langille.org> <4C745213.3050004@langille.org> <201008250823.11954.jhb@freebsd.org> <4C75308F.3080504@icyb.net.ua> In-Reply-To: <4C75308F.3080504@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kernel MCA messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2010 16:03:54 -0000 on 25/08/2010 18:02 Andriy Gapon said the following: > on 25/08/2010 15:23 John Baldwin said the following: >> That is because machine checks for corrected errors have to be polled and the >> kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a >> separate interrupt (CMCI) that can fire for corrected errors. > > I think that on AMD it's possible to configure an interrupt for Bank 4 events as > well (perhaps other banks too), but I need to refresh my memory of BKDG. Yeah, for Bank 4 only, configurable via MSR0000_0413 and MSRC000_04[0A:08] Machine Check Misc 4 (Thresholding) Registers. Also, see section 2.12.1.6 Error Thresholding in Fam10h BKDG. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 14:04:16 2010 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 45BE6106564A; Wed, 25 Aug 2010 14:04:16 +0000 (UTC) (envelope-from mi+thunw@aldan.algebra.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 180D78FC19; Wed, 25 Aug 2010 14:04:15 +0000 (UTC) Received: from [192.168.1.9] ([unknown] [173.70.194.135]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7P006ZVOE8NBB1@vms173003.mailsrvcs.net>; Wed, 25 Aug 2010 09:03:50 -0500 (CDT) Message-id: <4C7522AA.90004@aldan.algebra.com> Date: Wed, 25 Aug 2010 10:03:22 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-version: 1.0 To: John Baldwin References: <4C749E8C.1020506@aldan.algebra.com> <201008250827.13482.jhb@freebsd.org> In-reply-to: <201008250827.13482.jhb@freebsd.org> X-Mailman-Approved-At: Wed, 25 Aug 2010 16:09:25 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, sam@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't compile ath(4) into kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:04:16 -0000 On 8/25/2010 8:27 AM, John Baldwin wrote: > You are missing: > > options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors > But I don't have the ar5416 chipset... Mine is AR2312... And it is an option, so should not it be optional? Anyway, I tried adding that option and the error is the same (did cleandepend && depend, saw ah.c recompiled anew). > For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the > changes to GENERIC across your upgrade. It would save you several e-mails to > the mailing list Thanks, I did that. After several attempts to fiddle with options/devices, the wireless section now looks like: # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath device ath_rate_sample # SampleRate tx rate control for ath device ath_ar5212 #device ath_rate_onoe #options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that picking out a single driver should work... -mi From owner-freebsd-stable@FreeBSD.ORG Wed Aug 25 15:04:28 2010 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 BFCA2106567A; Wed, 25 Aug 2010 15:04:28 +0000 (UTC) (envelope-from mi+thunw@aldan.algebra.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5F48FC20; Wed, 25 Aug 2010 15:04:28 +0000 (UTC) Received: from [192.168.1.9] ([unknown] [173.70.194.135]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7P006ZVOE8NBB1@vms173003.mailsrvcs.net>; Wed, 25 Aug 2010 09:03:50 -0500 (CDT) Message-id: <4C7522AA.90004@aldan.algebra.com> Date: Wed, 25 Aug 2010 10:03:22 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-version: 1.0 To: John Baldwin References: <4C749E8C.1020506@aldan.algebra.com> <201008250827.13482.jhb@freebsd.org> In-reply-to: <201008250827.13482.jhb@freebsd.org> X-Mailman-Approved-At: Wed, 25 Aug 2010 16:15:38 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, sam@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't compile ath(4) into kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:04:28 -0000 On 8/25/2010 8:27 AM, John Baldwin wrote: > You are missing: > > options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors > But I don't have the ar5416 chipset... Mine is AR2312... And it is an option, so should not it be optional? Anyway, I tried adding that option and the error is the same (did cleandepend && depend, saw ah.c recompiled anew). > For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the > changes to GENERIC across your upgrade. It would save you several e-mails to > the mailing list Thanks, I did that. After several attempts to fiddle with options/devices, the wireless section now looks like: # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath device ath_rate_sample # SampleRate tx rate control for ath device ath_ar5212 #device ath_rate_onoe #options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors Generic simply uses the entire ath_hal, but ath_hal(4) suggests, that picking out a single driver should work... -mi From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 17:19:37 2010 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 8F3A31065673 for ; Thu, 26 Aug 2010 17:19:37 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id D808C8FC08 for ; Thu, 26 Aug 2010 17:19:36 +0000 (UTC) Received: (qmail 45551 invoked from network); 26 Aug 2010 17:19:35 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Aug 2010 17:19:35 -0000 Message-ID: <4C76A226.5070302@h3q.com> Date: Thu, 26 Aug 2010 19:19:34 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Mike Tancsa References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> In-Reply-To: <201008250109.o7P19uEp046002@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 17:19:37 -0000 Mike Tancsa wrote: > At 06:55 PM 8/24/2010, Philipp Wuensche wrote: >> Hi, >> >> I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes >> about once a day. I haven't found a way to trigger this yet. >> >> The system has a bunch of VLANs on em1, it does routing between them. >> >> Currently its running 8-STABLE but it happend with 8.1-RELEASE too. > > I dont think its the same problem you are seeing, but the patch in > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058296.html > > might be worth a try. Didn't help, crashed again but differently. I'm getting a lot of "discard frame w/o packet header" on the em devices too. I now disabled TSO, RX- and TXCSUM on the device to see if the problems comes from this direction. Greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 19:06:16 2010 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 6B9081065694 for ; Thu, 26 Aug 2010 19:06:16 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ECED18FC18 for ; Thu, 26 Aug 2010 19:06:15 +0000 (UTC) Received: by wwb34 with SMTP id 34so374226wwb.31 for ; Thu, 26 Aug 2010 12:06:15 -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:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=73jbsZpdNkAGEo4a3OZEgvcmJcAl81ZVHsEVSH4N5F8=; b=jhUfReTSmWMKM9UoTk+U+psKimlbPwOsolvHelyhav5/v3f6SHk7YcLy7u4rZi32P1 BLIY8WGoA2ItBi7vVAIULBcyT8puj0eX+pGwc//BtowZgHzAg7szyfBCjHaCRNO3zQaA 8Zszr7gfoyNImPtlu8FQPfAHvymSh1Netl4FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=E2Xg517bWVQ01PakrO7/ANg475EP9H/nEpuJb09XobfQJ7Na1dllJGv17024HpfSre TR8NPSUWhaR9/0XHDe7/nlSH05Vwbs8L/D5GzShXfYpXS+6WWBMqJkv18MvTdKVKN43X VIgAmxPmxmAIIc8tlzEW/JKPyaPr5X5Z0MJsQ= Received: by 10.227.158.15 with SMTP id d15mr9431896wbx.46.1282849574981; Thu, 26 Aug 2010 12:06:14 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-33.dsl.klmzmi.sbcglobal.net [99.181.132.33]) by mx.google.com with ESMTPS id b23sm2544713wbb.10.2010.08.26.12.06.13 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 12:06:13 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C76BB23.50606@DataIX.net> Date: Thu, 26 Aug 2010 15:06:11 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Heinrich Rebehn References: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> In-Reply-To: <3D57D985-4B4D-4657-86E0-C93EFB3549CC@ant.uni-bremen.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: zfs sharenfs with multiple hosts/networks and options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 19:06:16 -0000 On 08/25/2010 03:47, Heinrich Rebehn wrote: > Hi list, > > with traditional /etc/exports i can do > > /export/linux/root -ro xxx.xxx.xxx.0/24 > /export/linux/root -maproot=0 xxx.xxx.xxx.1 > > How can i do this using zfs's sharenfs option? > > When i try > > zfs set sharenfs="-ro -network xxx.xxx.xxx.0/24,-maproot=0 xxx.xxx.xxx.1" data/linux/root > > /var/log/messages shows "network/host conflict" and "bad exports list line. > > The general problem seems to be that with each "zfs set sharenfs" command, the corresponding in /etc/zfs/exports gets overwritten. > > Is there a workaround for this besides ignoring sharenfs and using hand edited /etc/exports? > > Thanks for any help, > Hi Heinrich, All the sharenfs property is actually doing and maybe not exactly in this order is modifying /etc/zfs/exports with the interpreted contents of the sharenfs property and using a syntax that the native mountd(8) understands or at least tries to in a very simple way. After this is all done, mountd(8) recieves a HUP signal to inform if to reread /etc/exports & /etc/zfs/exports. So traditionally everything is happening the way it always has been except for the fact your now using the zfs(1M) Sun command with our own patch on top of that to make it look like its doing what you see in *Solaris or at least the interpreted version. Currently we do not have a/the share(1M) command implemented. My suggestion would be to write a script either in Python or Perl or maybe even in C to parse your own command line arguments and adjust /etc/exports or /etc/zfs/exports accordingly depending on the type of filesystem your arguments point to and then send signal HUP to mountd(8). This will at least be a little more under your control without having to modify sources and deal with conflicts later. I would recommend that you disable using the sharenfs property at all if you choose to go this route as you may start to find inconsistencies among your shares. The reference code where this is all happening is: cddl/compat/opensolaris/misc/fsshare.c Disable handling of the sharenfs property (ZFS_PROP_SHARENFS): cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c Personally I would love to see our version of the sharenfs version translated into something that is local to FreeBSD only like the org.freebsd:swap local property that we use to enable swap on zvol's. My theorized version of this would look a little like the following. zfs set \ org.freebsd:nfs='ro=@192.168.1.0/24,root=0; rw=@192.168.2.1,root=514' org.freebsd:nfs4='V4: ......' Where options are separated by commas and shares to different hosts or networks are separated by semicolons. But if you don't want to go through all this then you could always designate /etc/zfs/exports as a permanent share for users that are allowed to write and administered by the sharenfs property. And use /etc/exports as your extraneous read-only shares. Just a thought. Anyway! enough said. Good luck on your mission. Regards, -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 21:28:00 2010 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 BA81B1065693 for ; Thu, 26 Aug 2010 21:28:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6623C8FC15 for ; Thu, 26 Aug 2010 21:27:59 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta14.westchester.pa.mail.comcast.net with comcast id z0TR1e0050mv7h05E9U0zl; Thu, 26 Aug 2010 21:28:00 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.westchester.pa.mail.comcast.net with comcast id z9Tz1e0023LrwQ23X9Tzno; Thu, 26 Aug 2010 21:28:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B9A0B9B425; Thu, 26 Aug 2010 14:27:57 -0700 (PDT) Date: Thu, 26 Aug 2010 14:27:57 -0700 From: Jeremy Chadwick To: Philipp Wuensche Message-ID: <20100826212757.GA3391@icarus.home.lan> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C76A226.5070302@h3q.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 21:28:00 -0000 On Thu, Aug 26, 2010 at 07:19:34PM +0200, Philipp Wuensche wrote: > Mike Tancsa wrote: > > At 06:55 PM 8/24/2010, Philipp Wuensche wrote: > >> Hi, > >> > >> I'm having trouble with a system on a Supermicro X7SPE-HF, it crashes > >> about once a day. I haven't found a way to trigger this yet. > >> > >> The system has a bunch of VLANs on em1, it does routing between them. > >> > >> Currently its running 8-STABLE but it happend with 8.1-RELEASE too. > > > > I dont think its the same problem you are seeing, but the patch in > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058296.html > > > > might be worth a try. > > Didn't help, crashed again but differently. > > I'm getting a lot of "discard frame w/o packet header" on the em devices > too. > > I now disabled TSO, RX- and TXCSUM on the device to see if the problems > comes from this direction. CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some ideas. OP's backtrace is here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html Philipp, can you please provide the following output? * dmesg | egrep 'em[0-9]' * uname -a (you can XXX out the machine name if need be) * pciconf -lvc (only include the em(4) items please) * vmstat -i Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 21:56:52 2010 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 69858106566C for ; Thu, 26 Aug 2010 21:56:52 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id B8ACA8FC1A for ; Thu, 26 Aug 2010 21:56:51 +0000 (UTC) Received: (qmail 14959 invoked from network); 26 Aug 2010 21:56:49 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Aug 2010 21:56:49 -0000 Message-ID: <4C76E320.9090008@h3q.com> Date: Thu, 26 Aug 2010 23:56:48 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jeremy Chadwick References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> In-Reply-To: <20100826212757.GA3391@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 21:56:52 -0000 Jeremy Chadwick wrote: > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > ideas. OP's backtrace is here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > Philipp, can you please provide the following output? > > * dmesg | egrep 'em[0-9]' em0: port 0xdc00-0xdc1f mem 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:25:90:04:6e:fa em1: port 0xec00-0xec1f mem 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:25:90:04:6e:fb > * uname -a (you can XXX out the machine name if need be) FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE too, I can go back to RELEASE or any SVN revision you would like, if it is helping in any way. Kernel-config: include GENERIC ident XXX options IPSEC options DEVICE_POLLING options ACCEPT_FILTER_HTTP options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ device crypto device enc > * pciconf -lvc (only include the em(4) items please) em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c > * vmstat -i interrupt total rate irq1: atkbd0 9 0 cpu0: timer 36544552 1994 irq256: em0 3801 0 irq257: em1 32963909 1799 irq258: ahci0 175662 9 cpu1: timer 36543525 1994 cpu2: timer 36543525 1994 cpu3: timer 36543525 1994 Total 179318508 9786 There is an shared IPMI interface on em0, but the interface is not used by FreeBSD. em1 is used by four VLANs. Polling is only in the Kernelconfig, not activated on the devices. Greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:02:15 2010 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 7BC061065672 for ; Thu, 26 Aug 2010 22:02:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0712F8FC0C for ; Thu, 26 Aug 2010 22:02:14 +0000 (UTC) Received: by wyb33 with SMTP id 33so3108790wyb.13 for ; Thu, 26 Aug 2010 15:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4SAMCWni/VDbA3dDpzVMh2TkzJ0lmJwHe/4T0qnHmpQ=; b=alGL8jrLR4UivjEM6Vdrtplr+HTv0Zz7CXB9LUVg6T3klUcPOFfjFLHk4d6pnmhv1b Q5EGYgdU3mkP3Gb9GxXO5IpPKvVHVe4rIqSTShWaciE/XzI5lkXXnNhju5B7e7lkUqKN Lkm5oQ1IC+LDAOKZCXwKFs3jBdwOwtrIXQIFA= 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=h2K2IfBsNondNOEfBkKeT6/4oJNK3nbuRWSpvpfoebc//wRIsQa4LASxBrHrG3F7tc RnFsO4qDXiCAWRt8bpCmizqqBpyu8ZyfIZo0Uf26w00lKZJXdLkk+1HvLqi1fkhWvxqA VKFcDmQEDYN0iOOBaXT+q6u5lE1Izr+hS7aSY= MIME-Version: 1.0 Received: by 10.216.236.146 with SMTP id w18mr95165weq.19.1282860103121; Thu, 26 Aug 2010 15:01:43 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 26 Aug 2010 15:01:42 -0700 (PDT) In-Reply-To: <4C76E320.9090008@h3q.com> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> Date: Thu, 26 Aug 2010 15:01:43 -0700 Message-ID: From: Jack Vogel To: Philipp Wuensche Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 22:02:15 -0000 Hmmm, can you remove ALTQ from the mix and see if that eliminates it? Jack On Thu, Aug 26, 2010 at 2:56 PM, Philipp Wuensche wrote: > Jeremy Chadwick wrote: > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > ideas. OP's backtrace is here: > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > Philipp, can you please provide the following output? > > > > * dmesg | egrep 'em[0-9]' > > em0: port 0xdc00-0xdc1f mem > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:25:90:04:6e:fa > em1: port 0xec00-0xec1f mem > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:25:90:04:6e:fb > > > * uname -a (you can XXX out the machine name if need be) > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE > too, I can go back to RELEASE or any SVN revision you would like, if it > is helping in any way. > > Kernel-config: > > include GENERIC > > ident XXX > > options IPSEC > > options DEVICE_POLLING > options ACCEPT_FILTER_HTTP > > options ALTQ > > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > > device crypto > device enc > > > > * pciconf -lvc (only include the em(4) items please) > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > * vmstat -i > > interrupt total rate > irq1: atkbd0 9 0 > cpu0: timer 36544552 1994 > irq256: em0 3801 0 > irq257: em1 32963909 1799 > irq258: ahci0 175662 9 > cpu1: timer 36543525 1994 > cpu2: timer 36543525 1994 > cpu3: timer 36543525 1994 > Total 179318508 9786 > > There is an shared IPMI interface on em0, but the interface is not used > by FreeBSD. em1 is used by four VLANs. Polling is only in the > Kernelconfig, not activated on the devices. > > Greetings, > philipp > > From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:11:53 2010 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 19E3110656A5 for ; Thu, 26 Aug 2010 22:11:53 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8E38FC14 for ; Thu, 26 Aug 2010 22:11:51 +0000 (UTC) Received: (qmail 19241 invoked from network); 26 Aug 2010 22:11:51 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Aug 2010 22:11:51 -0000 Message-ID: <4C76E6A6.4070507@h3q.com> Date: Fri, 27 Aug 2010 00:11:50 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jack Vogel References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 22:11:53 -0000 Jack Vogel wrote: > Hmmm, can you remove ALTQ from the mix and see if that eliminates it? Sure, but its not used in the pf-rules anyway. Greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:15:29 2010 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 A80251065695 for ; Thu, 26 Aug 2010 22:15:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 52FEF8FC1D for ; Thu, 26 Aug 2010 22:15:28 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id z0Bg1e0051ZXKqc52AFUH9; Thu, 26 Aug 2010 22:15:28 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.westchester.pa.mail.comcast.net with comcast id zAFT1e0093LrwQ23hAFToi; Thu, 26 Aug 2010 22:15:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DB819B425; Thu, 26 Aug 2010 15:15:26 -0700 (PDT) Date: Thu, 26 Aug 2010 15:15:26 -0700 From: Jeremy Chadwick To: Philipp Wuensche Message-ID: <20100826221526.GA4760@icarus.home.lan> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C76E320.9090008@h3q.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 22:15:29 -0000 On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > Jeremy Chadwick wrote: > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > ideas. OP's backtrace is here: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > Philipp, can you please provide the following output? > > > > * dmesg | egrep 'em[0-9]' > > em0: port 0xdc00-0xdc1f mem > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:25:90:04:6e:fa > em1: port 0xec00-0xec1f mem > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:25:90:04:6e:fb > > > * uname -a (you can XXX out the machine name if need be) > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE > too, I can go back to RELEASE or any SVN revision you would like, if it > is helping in any way. > > Kernel-config: > > include GENERIC > > ident XXX > > options IPSEC > > options DEVICE_POLLING > options ACCEPT_FILTER_HTTP > > options ALTQ > > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > > device crypto > device enc > > > > * pciconf -lvc (only include the em(4) items please) > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > * vmstat -i > > interrupt total rate > irq1: atkbd0 9 0 > cpu0: timer 36544552 1994 > irq256: em0 3801 0 > irq257: em1 32963909 1799 > irq258: ahci0 175662 9 > cpu1: timer 36543525 1994 > cpu2: timer 36543525 1994 > cpu3: timer 36543525 1994 > Total 179318508 9786 > > There is an shared IPMI interface on em0, but the interface is not used > by FreeBSD. em1 is used by four VLANs. Polling is only in the > Kernelconfig, not activated on the devices. So much complexity here. Tracking this down might be difficult. One thing that does concern me is the interrupt rate for em1. Jack et al, is this normal? I don't see this behaviour on my 8.x systems with em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't have MSI-X support. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:28:17 2010 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 40E141065694 for ; Thu, 26 Aug 2010 22:28:17 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id B7ED18FC1A for ; Thu, 26 Aug 2010 22:28:16 +0000 (UTC) Received: (qmail 22479 invoked from network); 26 Aug 2010 22:28:15 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 26 Aug 2010 22:28:15 -0000 Message-ID: <4C76EA7E.4050205@h3q.com> Date: Fri, 27 Aug 2010 00:28:14 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jeremy Chadwick References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> In-Reply-To: <20100826221526.GA4760@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 22:28:17 -0000 Jeremy Chadwick wrote: > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: >> Jeremy Chadwick wrote: >>> CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some >>> ideas. OP's backtrace is here: >>> >>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html >>> >>> Philipp, can you please provide the following output? >>> >>> * dmesg | egrep 'em[0-9]' >> em0: port 0xdc00-0xdc1f mem >> 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:25:90:04:6e:fa >> em1: port 0xec00-0xec1f mem >> 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 >> em1: Using MSI interrupt >> em1: [FILTER] >> em1: Ethernet address: 00:25:90:04:6e:fb >> >>> * uname -a (you can XXX out the machine name if need be) >> FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST >> 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 >> >> Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE >> too, I can go back to RELEASE or any SVN revision you would like, if it >> is helping in any way. >> >> Kernel-config: >> >> include GENERIC >> >> ident XXX >> >> options IPSEC >> >> options DEVICE_POLLING >> options ACCEPT_FILTER_HTTP >> >> options ALTQ >> >> options ALTQ_CBQ >> options ALTQ_RED >> options ALTQ_RIO >> options ALTQ_HFSC >> options ALTQ_PRIQ >> >> device crypto >> device enc >> >> >>> * pciconf -lvc (only include the em(4) items please) >> em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> cap 11[a0] = MSI-X supports 5 messages in map 0x1c >> em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> cap 11[a0] = MSI-X supports 5 messages in map 0x1c >> >>> * vmstat -i >> interrupt total rate >> irq1: atkbd0 9 0 >> cpu0: timer 36544552 1994 >> irq256: em0 3801 0 >> irq257: em1 32963909 1799 >> irq258: ahci0 175662 9 >> cpu1: timer 36543525 1994 >> cpu2: timer 36543525 1994 >> cpu3: timer 36543525 1994 >> Total 179318508 9786 >> >> There is an shared IPMI interface on em0, but the interface is not used >> by FreeBSD. em1 is used by four VLANs. Polling is only in the >> Kernelconfig, not activated on the devices. > > So much complexity here. Tracking this down might be difficult. > > One thing that does concern me is the interrupt rate for em1. Jack et > al, is this normal? I don't see this behaviour on my 8.x systems with > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't > have MSI-X support. This is with the current settings, RXCSUM,TXCSUM and TSO disabled. Uptime is now only 5h:44m. It crashes about 2 to 3 times a day. I haven't found a way to trigger this, so I can only wait for it happen again. Greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:47:16 2010 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 EB12B1065679 for ; Thu, 26 Aug 2010 22:47:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B73788FC12 for ; Thu, 26 Aug 2010 22:47:16 +0000 (UTC) Received: by pwi8 with SMTP id 8so1059851pwi.13 for ; Thu, 26 Aug 2010 15:47:16 -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=ZNhrC5HVOHU8ZqI2474OS3ILFwAE7r28YqjUcHtbzxk=; b=BV5BjzI+8ButQ+SU2LPPy1ohrjLLlOZcjQNiRZJ+4MEvJUP8y73/NJcdP1ZyUdAKhv nHJMpVpMgddd8C2TcVU2j8Cs3RXfoui3erV5VOZ+b2g6rBcOZOCVJYQ8/qGKQQZ7+cj4 xQcM3EghrFyILnX2W6yqTCRwcXQi4sL0Iy13E= 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=YqXcy7Ho2pe/SNoZ+EX2g2ziP18TjokTSbVWVLRQCR0SuLjIBIXf8vll3AQyWwMYiN MSwUg7ulLSSHdSZTmLXWJ4nB8rPR7g4kcutc4nhy2C1y5BGSP89swYjF3RyumenbZa0p FV70YcfBxO2y/xMvytk3GWqsrTEp20p8z2ny4= Received: by 10.142.173.13 with SMTP id v13mr550707wfe.43.1282862835965; Thu, 26 Aug 2010 15:47:15 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z1sm3522560wfd.15.2010.08.26.15.47.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Aug 2010 15:47:14 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 26 Aug 2010 15:47:13 -0700 From: Pyun YongHyeon Date: Thu, 26 Aug 2010 15:47:13 -0700 To: Philipp Wuensche Message-ID: <20100826224713.GG16395@michelle.cdnetworks.com> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> <4C76EA7E.4050205@h3q.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C76EA7E.4050205@h3q.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em 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: Thu, 26 Aug 2010 22:47:17 -0000 On Fri, Aug 27, 2010 at 12:28:14AM +0200, Philipp Wuensche wrote: > Jeremy Chadwick wrote: > > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > >> Jeremy Chadwick wrote: > >>> CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > >>> ideas. OP's backtrace is here: > >>> > >>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > >>> > >>> Philipp, can you please provide the following output? > >>> > >>> * dmesg | egrep 'em[0-9]' > >> em0: port 0xdc00-0xdc1f mem > >> 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 > >> em0: Using MSI interrupt > >> em0: [FILTER] > >> em0: Ethernet address: 00:25:90:04:6e:fa > >> em1: port 0xec00-0xec1f mem > >> 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 > >> em1: Using MSI interrupt > >> em1: [FILTER] > >> em1: Ethernet address: 00:25:90:04:6e:fb > >> > >>> * uname -a (you can XXX out the machine name if need be) > >> FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST > >> 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > >> > >> Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE > >> too, I can go back to RELEASE or any SVN revision you would like, if it > >> is helping in any way. > >> > >> Kernel-config: > >> > >> include GENERIC > >> > >> ident XXX > >> > >> options IPSEC > >> > >> options DEVICE_POLLING > >> options ACCEPT_FILTER_HTTP > >> > >> options ALTQ > >> > >> options ALTQ_CBQ > >> options ALTQ_RED > >> options ALTQ_RIO > >> options ALTQ_HFSC > >> options ALTQ_PRIQ > >> > >> device crypto > >> device enc > >> > >> > >>> * pciconf -lvc (only include the em(4) items please) > >> em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > >> hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > >> class = network > >> subclass = ethernet > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > >> cap 11[a0] = MSI-X supports 5 messages in map 0x1c > >> em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 rev=0x00 > >> hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > >> class = network > >> subclass = ethernet > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > >> cap 11[a0] = MSI-X supports 5 messages in map 0x1c > >> > >>> * vmstat -i > >> interrupt total rate > >> irq1: atkbd0 9 0 > >> cpu0: timer 36544552 1994 > >> irq256: em0 3801 0 > >> irq257: em1 32963909 1799 > >> irq258: ahci0 175662 9 > >> cpu1: timer 36543525 1994 > >> cpu2: timer 36543525 1994 > >> cpu3: timer 36543525 1994 > >> Total 179318508 9786 > >> > >> There is an shared IPMI interface on em0, but the interface is not used > >> by FreeBSD. em1 is used by four VLANs. Polling is only in the > >> Kernelconfig, not activated on the devices. > > > > So much complexity here. Tracking this down might be difficult. > > > > One thing that does concern me is the interrupt rate for em1. Jack et > > al, is this normal? I don't see this behaviour on my 8.x systems with > > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't > > have MSI-X support. > > This is with the current settings, RXCSUM,TXCSUM and TSO disabled. > Uptime is now only 5h:44m. It crashes about 2 to 3 times a day. I > haven't found a way to trigger this, so I can only wait for it happen again. > I'm not sure but it does not look like em(4) issue. Of course em(4) could free/poke mbuf which was already passed to upper stack but this may happen only when it has severe bug and I didn't see such code yet. It seems you're using ipsec, is it doable for you to disable ipsec to narrow down the issue? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 26 22:50:13 2010 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 C151C1065693 for ; Thu, 26 Aug 2010 22:50:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 492CC8FC0C for ; Thu, 26 Aug 2010 22:50:12 +0000 (UTC) Received: by eyx24 with SMTP id 24so1990163eyx.13 for ; Thu, 26 Aug 2010 15:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=l75idNCbsVk5Fwpa+9uMmg7s0S/XRKDbETzvCD0eKso=; b=KmKOBUXpxOpD1TF1Xrqz/wRCxdEwdzTzPFggWCIpG7i3fRDUM0ikkmrxuY9ovMKsVD 85zlQ7Ojj8jSiBTC7PvWOqmmvcP+WX3aF0bZJ+XaJarJHJTmaPkN8V5AdHKqbW5a7Ho6 FRhY8kvAwJtS5Y3uDRFkgD0ToqRYi+aQgkG5Q= 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=fTrZS1p9IS5AH97zMWmqUXbxHKTHRmUARPcub9ooOuibwFWsXVZfju0B8F8DyuwxmU i8tsZpoYjSvWu7odMKtPpNTRl3qVRcDyNbhxBOlrOgjCG5K6qwE4EwefXFMluZV74PRO riorX51b4e0hS63pdM8mjZoWy9jClUv78Hp68= MIME-Version: 1.0 Received: by 10.216.186.70 with SMTP id v48mr106866wem.64.1282863011078; Thu, 26 Aug 2010 15:50:11 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Thu, 26 Aug 2010 15:50:10 -0700 (PDT) In-Reply-To: <20100826221526.GA4760@icarus.home.lan> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> Date: Thu, 26 Aug 2010 15:50:10 -0700 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: PYUN YongHyeon , Philipp Wuensche , freebsd-stable@freebsd.org Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Aug 2010 22:50:13 -0000 On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick wrote: > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > > Jeremy Chadwick wrote: > > > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > > ideas. OP's backtrace is here: > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > > > Philipp, can you please provide the following output? > > > > > > * dmesg | egrep 'em[0-9]' > > > > em0: port 0xdc00-0xdc1f mem > > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci2 > > em0: Using MSI interrupt > > em0: [FILTER] > > em0: Ethernet address: 00:25:90:04:6e:fa > > em1: port 0xec00-0xec1f mem > > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 on pci3 > > em1: Using MSI interrupt > > em1: [FILTER] > > em1: Ethernet address: 00:25:90:04:6e:fb > > > > > * uname -a (you can XXX out the machine name if need be) > > > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST > > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > > > Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE > > too, I can go back to RELEASE or any SVN revision you would like, if it > > is helping in any way. > > > > Kernel-config: > > > > include GENERIC > > > > ident XXX > > > > options IPSEC > > > > options DEVICE_POLLING > > options ACCEPT_FILTER_HTTP > > > > options ALTQ > > > > options ALTQ_CBQ > > options ALTQ_RED > > options ALTQ_RIO > > options ALTQ_HFSC > > options ALTQ_PRIQ > > > > device crypto > > device enc > > > > > > > * pciconf -lvc (only include the em(4) items please) > > > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 > rev=0x00 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 chip=0x10d38086 > rev=0x00 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > * vmstat -i > > > > interrupt total rate > > irq1: atkbd0 9 0 > > cpu0: timer 36544552 1994 > > irq256: em0 3801 0 > > irq257: em1 32963909 1799 > > irq258: ahci0 175662 9 > > cpu1: timer 36543525 1994 > > cpu2: timer 36543525 1994 > > cpu3: timer 36543525 1994 > > Total 179318508 9786 > > > > There is an shared IPMI interface on em0, but the interface is not used > > by FreeBSD. em1 is used by four VLANs. Polling is only in the > > Kernelconfig, not activated on the devices. > > So much complexity here. Tracking this down might be difficult. > > One thing that does concern me is the interrupt rate for em1. Jack et > al, is this normal? I don't see this behaviour on my 8.x systems with > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't > have MSI-X support. > > He is only using one vector anyway it seems, so MSIX isnt making things much more complex than your 573. The interrupt rate seems high but I'm not sure if its abnormal for a busy interface. I tend to agree with Yongari, let's eliminate all the complicating factors like IPSEC and ALTQ and see if it still occurs. >From the crash data I do not see a clear cause either. Jack From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 01:56:34 2010 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 ED0E310656A9; Fri, 27 Aug 2010 01:56:34 +0000 (UTC) (envelope-from ivoras@freebsd.org) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5B18FC16; Fri, 27 Aug 2010 01:56:34 +0000 (UTC) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id o7QEcwp6009299; Thu, 26 Aug 2010 14:38:59 GMT Message-ID: <4C7678A8.9000201@freebsd.org> Date: Thu, 26 Aug 2010 16:22:32 +0200 From: Ivan Voras User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org, rmacklem@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: NFS uid/gid mapping X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 01:56:35 -0000 hi, I can't seem to find how to manually remap uid & gid information while using NFS, e.g. something similar to this: http://www.kernelcrash.com/blog/nfs-uidgid-mapping/2007/09/10/ Is such mapping really unimplemented? From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 07:36:22 2010 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 CA09E10656A4 for ; Fri, 27 Aug 2010 07:36:22 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2DB8FC18 for ; Fri, 27 Aug 2010 07:36:22 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [92.117.63.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 5882A8A255B; Fri, 27 Aug 2010 09:36:19 +0200 (CEST) Message-ID: <4C776AEE.7070309@bsdforen.de> Date: Fri, 27 Aug 2010 09:36:14 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 MIME-Version: 1.0 To: Bernhard Schmidt References: <4C716382.3040605@bsdforen.de> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 07:36:22 -0000 On 27/08/2010 09:28, Bernhard Schmidt wrote: > On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey wrote: >> wpa_supplicant doesn't create the pidfile if the target directory >> does not exist. Because /var/run is wiped with every boot I added >> the following line to my rc.local to workaround this issue: >> >> /bin/mkdir -p /var/run/wpa_supplicant >> >> I'm running RELENG_8. > > How about this? > > Index: etc/mtree/BSD.var.dist > =================================================================== > --- etc/mtree/BSD.var.dist>.....(revision 211568) > +++ etc/mtree/BSD.var.dist>.....(working copy) > @@ -64,6 +64,8 @@ > .. > ppp gname=network mode=0770 > .. > + wpa_supplicant > + .. > .. > rwho gname=daemon mode=0775 > .. Is the mtree built every time the system boots? Because my /var/run is a tmpfs. And even if it wasn't, I think it's wiped every boot any way. Regards -- A: Because it fouls 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 07:42:31 2010 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 3F020106566B for ; Fri, 27 Aug 2010 07:42:31 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id F125E8FC14 for ; Fri, 27 Aug 2010 07:42:30 +0000 (UTC) Received: by qwg5 with SMTP id 5so2742483qwg.13 for ; Fri, 27 Aug 2010 00:42:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.233.68 with SMTP id jx4mr258676qcb.7.1282894950111; Fri, 27 Aug 2010 00:42:30 -0700 (PDT) Received: by 10.229.7.131 with HTTP; Fri, 27 Aug 2010 00:42:30 -0700 (PDT) X-Originating-IP: [91.14.62.192] In-Reply-To: <4C776AEE.7070309@bsdforen.de> References: <4C716382.3040605@bsdforen.de> <4C776AEE.7070309@bsdforen.de> Date: Fri, 27 Aug 2010 09:42:30 +0200 Message-ID: From: Bernhard Schmidt To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 07:42:31 -0000 On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey wrote= : > On 27/08/2010 09:28, Bernhard Schmidt wrote: >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey wr= ote: >>> wpa_supplicant doesn't create the pidfile if the target directory >>> does not exist. Because /var/run is wiped with every boot I added >>> the following line to my rc.local to workaround this issue: >>> >>> /bin/mkdir -p /var/run/wpa_supplicant >>> >>> I'm running RELENG_8. >> >> How about this? >> >> Index: etc/mtree/BSD.var.dist >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- etc/mtree/BSD.var.dist>.....(revision 211568) >> +++ etc/mtree/BSD.var.dist>.....(working copy) >> @@ -64,6 +64,8 @@ >> =A0 =A0 =A0 =A0 =A0.. >> =A0 =A0 =A0 =A0 =A0ppp =A0 =A0 =A0 =A0 =A0 =A0 gname=3Dnetwork mode=3D07= 70 >> =A0 =A0 =A0 =A0 =A0.. >> + =A0 =A0 =A0 =A0wpa_supplicant >> + =A0 =A0 =A0 =A0.. >> =A0 =A0 =A0.. >> =A0 =A0 =A0rwho =A0 =A0 =A0 =A0 =A0 =A0gname=3Ddaemon mode=3D0775 >> =A0 =A0 =A0.. > > Is the mtree built every time the system boots? Because my /var/run > is a tmpfs. And even if it wasn't, I think it's wiped every boot > any way. Not build but, according to /etc/rc.d/var mtree is run on every boot. I actually tried that and it works just fine. --=20 Bernhard From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 08:00:04 2010 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 09F6C1065697 for ; Fri, 27 Aug 2010 08:00:03 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA6F08FC14 for ; Fri, 27 Aug 2010 08:00:01 +0000 (UTC) Received: by qyk4 with SMTP id 4so2917882qyk.13 for ; Fri, 27 Aug 2010 01:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.26.87 with SMTP id d23mr132741qac.124.1282894134708; Fri, 27 Aug 2010 00:28:54 -0700 (PDT) Received: by 10.229.7.131 with HTTP; Fri, 27 Aug 2010 00:28:54 -0700 (PDT) X-Originating-IP: [91.14.62.192] In-Reply-To: <4C716382.3040605@bsdforen.de> References: <4C716382.3040605@bsdforen.de> Date: Fri, 27 Aug 2010 09:28:54 +0200 Message-ID: From: Bernhard Schmidt To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: wpa_supplicant does not create pidfile X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 08:00:04 -0000 On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey wrote: > wpa_supplicant doesn't create the pidfile if the target directory > does not exist. Because /var/run is wiped with every boot I added > the following line to my rc.local to workaround this issue: > > /bin/mkdir -p /var/run/wpa_supplicant > > I'm running RELENG_8. How about this? Index: etc/mtree/BSD.var.dist =================================================================== --- etc/mtree/BSD.var.dist>.....(revision 211568) +++ etc/mtree/BSD.var.dist>.....(working copy) @@ -64,6 +64,8 @@ .. ppp gname=network mode=0770 .. + wpa_supplicant + .. .. rwho gname=daemon mode=0775 .. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 08:03:57 2010 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 0976410656A7 for ; Fri, 27 Aug 2010 08:03:57 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id BE5538FC0C for ; Fri, 27 Aug 2010 08:03:56 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1Ootul-0003Xd-MP; Fri, 27 Aug 2010 10:03:55 +0200 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id F3C6A19134; Fri, 27 Aug 2010 10:03:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "Andriy Gapon" References: <4C74261A.4000401@icyb.net.ua> Date: Fri, 27 Aug 2010 10:03:52 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <4C74261A.4000401@icyb.net.ua> User-Agent: Opera Mail/10.61 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: Subject: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 08:03:57 -0000 offtopic, but why do some mailers replace a CNAME in a mail-address? root@sheeva2:/var/vmail# host klop.yi.org klop.yi.org CNAME thuis.klop.ws thuis.klop.ws A 212.123.145.58 It is not the first time that I'm bitten by this, but I never understood = =20 it. Ronald. On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon wrote: > > Ronald, > > your email address bounces, that's inconvenient. > > > -------- Original Message -------- > Subject: Returned mail: Service unavailable > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) > From: Mail Delivery Subsystem > To: > > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 =20 > (EEST) > from porto-e.starpoint.kiev.ua [212.40.38.100] > > ----- The following addresses had permanent fatal errors ----- > > > ----- Transcript of session follows ----- > ... while talking to thuis.klop.ws.: >>>> RCPT To: > <<< 554 5.7.1 : Relay access denied > 554 ... Service unavailable From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 08:21:50 2010 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 C1E10106566C for ; Fri, 27 Aug 2010 08:21:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by mx1.freebsd.org (Postfix) with ESMTP id 5970A8FC17 for ; Fri, 27 Aug 2010 08:21:50 +0000 (UTC) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 07B435F985D; Fri, 27 Aug 2010 08:21:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 0FB22E604A; Fri, 27 Aug 2010 08:21:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 07538364425; Fri, 27 Aug 2010 18:21:28 +1000 (EST) To: "Ronald Klop" From: Mark Andrews References: <4C74261A.4000401@icyb.net.ua> In-reply-to: Your message of "Fri, 27 Aug 2010 10:03:52 +0200." Date: Fri, 27 Aug 2010 18:21:27 +1000 Message-Id: <20100827082128.07538364425@drugs.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 08:21:50 -0000 In message , "Ronald Klop" writ es: > offtopic, but why do some mailers replace a CNAME in a mail-address? Because it used to be manditory to do so. If you don't want it to be done use a MX record. klop.yi.org MX 0 thuis.klop.ws If you need klop.yi.org to have a address record then give it one. klop.yi.org A 212.123.145.58 Mark > root@sheeva2:/var/vmail# host klop.yi.org > klop.yi.org CNAME thuis.klop.ws > thuis.klop.ws A 212.123.145.58 > > It is not the first time that I'm bitten by this, but I never understood = > =20 > it. > > Ronald. > > On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon wrote: > > > > > Ronald, > > > > your email address bounces, that's inconvenient. > > > > > > -------- Original Message -------- > > Subject: Returned mail: Service unavailable > > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) > > From: Mail Delivery Subsystem > > To: > > > > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 =20 > > (EEST) > > from porto-e.starpoint.kiev.ua [212.40.38.100] > > > > ----- The following addresses had permanent fatal errors ----- > > > > > > ----- Transcript of session follows ----- > > ... while talking to thuis.klop.ws.: > >>>> RCPT To: > > <<< 554 5.7.1 : Relay access denied > > 554 ... Service unavailable > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 09:22:12 2010 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 BDE5A1065696 for ; Fri, 27 Aug 2010 09:22:12 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.freebsd.org (Postfix) with ESMTP id 50EBE8FC27 for ; Fri, 27 Aug 2010 09:22:12 +0000 (UTC) Received: from [212.123.145.58] (helo=sjakie.klop.ws) by smtp-out1.tiscali.nl with esmtp (Exim) (envelope-from ) id 1Oov8V-0001CR-8C; Fri, 27 Aug 2010 11:22:11 +0200 Received: from 212-123-145-58.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id F0921194EB; Fri, 27 Aug 2010 11:22:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Mark Andrews" References: <4C74261A.4000401@icyb.net.ua> <20100827082128.07538364425@drugs.dv.isc.org> Date: Fri, 27 Aug 2010 11:22:05 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <20100827082128.07538364425@drugs.dv.isc.org> User-Agent: Opera Mail/10.61 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 09:22:12 -0000 Mandatory? I'm googling, but can't find a document that declares it =20 mandatory and only sendmail seems to do it. I think it is lame to use DNS info to rewrite e-mail addresses, but the =20 person who made it 'mandatory' will have good reasons for it. Does somebody have a pointer to the specs about this? Ronald. On Fri, 27 Aug 2010 10:21:27 +0200, Mark Andrews wrote: > > In message , "Ronald =20 > Klop" writ > es: >> offtopic, but why do some mailers replace a CNAME in a mail-address? > > Because it used to be manditory to do so. If you don't want it to > be done use a MX record. > > klop.yi.org MX 0 thuis.klop.ws > > If you need klop.yi.org to have a address record then give it one. > > klop.yi.org A 212.123.145.58 > > Mark > >> root@sheeva2:/var/vmail# host klop.yi.org >> klop.yi.org CNAME thuis.klop.ws >> thuis.klop.ws A 212.123.145.58 >> >> It is not the first time that I'm bitten by this, but I never =20 >> understood =3D >> =3D20 >> it. >> >> Ronald. >> >> On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon =20 >> wrote: >> >> > >> > Ronald, >> > >> > your email address bounces, that's inconvenient. >> > >> > >> > -------- Original Message -------- >> > Subject: Returned mail: Service unavailable >> > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) >> > From: Mail Delivery Subsystem >> > To: >> > >> > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300= =20 >> =3D20 >> > (EEST) >> > from porto-e.starpoint.kiev.ua [212.40.38.100] >> > >> > ----- The following addresses had permanent fatal errors ----- >> > >> > >> > ----- Transcript of session follows ----- >> > ... while talking to thuis.klop.ws.: >> >>>> RCPT To: >> > <<< 554 5.7.1 : Relay access denied >> > 554 ... Service unavailable >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to =20 >> "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 09:28:32 2010 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 D23E7106564A for ; Fri, 27 Aug 2010 09:28:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id B57708FC08 for ; Fri, 27 Aug 2010 09:28:32 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta07.emeryville.ca.mail.comcast.net with comcast id zMUY1e0031Y3wxoA7MUYTX; Fri, 27 Aug 2010 09:28:32 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id zMUW1e0013LrwQ28bMUWHG; Fri, 27 Aug 2010 09:28:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1C8AE9B425; Fri, 27 Aug 2010 02:28:30 -0700 (PDT) Date: Fri, 27 Aug 2010 02:28:30 -0700 From: Jeremy Chadwick To: Ronald Klop Message-ID: <20100827092830.GA21076@icarus.home.lan> References: <4C74261A.4000401@icyb.net.ua> <20100827082128.07538364425@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 09:28:32 -0000 On Fri, Aug 27, 2010 at 11:22:05AM +0200, Ronald Klop wrote: > Mandatory? I'm googling, but can't find a document that declares it > mandatory and only sendmail seems to do it. > I think it is lame to use DNS info to rewrite e-mail addresses, but > the person who made it 'mandatory' will have good reasons for it. > > Does somebody have a pointer to the specs about this? First hit on Google: http://www.ferris.com/2008/09/08/why-you-shouldnt-mix-cname-and-mx/ Bottom line: don't use CNAMEs, ever, unless you know ***exactly*** what you're doing. It's been like this for a very long time. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 09:46:17 2010 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 D81BA106566C for ; Fri, 27 Aug 2010 09:46:17 +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 9B09A8FC0A for ; Fri, 27 Aug 2010 09:46:17 +0000 (UTC) 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 1OovVg-0005Bp-9K; Fri, 27 Aug 2010 10:46:08 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OovVg-0009O0-8F; Fri, 27 Aug 2010 10:46:08 +0100 Date: Fri, 27 Aug 2010 10:46:08 +0100 Message-Id: To: marka@isc.org, ronald-freebsd8@klop.yi.org In-Reply-To: From: Pete French Cc: freebsd-stable@freebsd.org, avg@icyb.net.ua Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 09:46:17 -0000 > Mandatory? I'm googling, but can't find a document that declares it > mandatory and only sendmail seems to do it. > I think it is lame to use DNS info to rewrite e-mail addresses, but the > person who made it 'mandatory' will have good reasons for it. Rewiting may not be mandatory, but it is certainly true that a domain needs to have either an A record or an MX record to recieve email according to the spec. Your has neither, and given the presence of a CNAME then rewriting the address to use that CNAME doesnt seem like an unreasonable thing to do. You should add an MX record to that domain - but mixing MX and CNAME is a fairly bad idea too (and that should be easily found in google). -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 11:50:22 2010 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 BD15B1065672 for ; Fri, 27 Aug 2010 11:50:22 +0000 (UTC) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.HRZ.Uni-Dortmund.DE [129.217.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 537298FC0C for ; Fri, 27 Aug 2010 11:50:21 +0000 (UTC) Received: from [131.234.21.116] (baloo.cs.uni-paderborn.de [131.234.21.116]) (authenticated bits=0) by unimail.uni-dortmund.de (8.14.4/8.14.4) with ESMTP id o7RBSDOl029427 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 27 Aug 2010 13:28:13 +0200 (CEST) Message-ID: <4C77A14C.3030703@dt.e-technik.uni-dortmund.de> Date: Fri, 27 Aug 2010 13:28:12 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C74261A.4000401@icyb.net.ua> <20100827082128.07538364425@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 11:50:22 -0000 Am 27.08.2010 11:22, schrieb Ronald Klop: > Mandatory? I'm googling, but can't find a document that declares it > mandatory and only sendmail seems to do it. > I think it is lame to use DNS info to rewrite e-mail addresses, but the > person who made it 'mandatory' will have good reasons for it. May have been RFC0974, perhaps in connection with others - January 1986... -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 13:04:30 2010 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 BD4AC10656A7 for ; Fri, 27 Aug 2010 13:04:30 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9148FC13 for ; Fri, 27 Aug 2010 13:04:30 +0000 (UTC) Received: (qmail 53517 invoked from network); 27 Aug 2010 13:04:27 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 27 Aug 2010 13:04:27 -0000 Message-ID: <4C77B7DA.3040801@h3q.com> Date: Fri, 27 Aug 2010 15:04:26 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jack Vogel References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 13:04:30 -0000 Jack Vogel wrote: > > > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick > > wrote: > > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > > Jeremy Chadwick wrote: > > > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > > ideas. OP's backtrace is here: > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > > > Philipp, can you please provide the following output? > > > > > > * dmesg | egrep 'em[0-9]' > > > > em0: port > 0xdc00-0xdc1f mem > > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 > on pci2 > > em0: Using MSI interrupt > > em0: [FILTER] > > em0: Ethernet address: 00:25:90:04:6e:fa > > em1: port > 0xec00-0xec1f mem > > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 > on pci3 > > em1: Using MSI interrupt > > em1: [FILTER] > > em1: Ethernet address: 00:25:90:04:6e:fb > > > > > * uname -a (you can XXX out the machine name if need be) > > > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 CEST > > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > > > Date of source is Aug 17 14:09 CEST 2010. It happend with 8.1-RELEASE > > too, I can go back to RELEASE or any SVN revision you would like, > if it > > is helping in any way. > > > > Kernel-config: > > > > include GENERIC > > > > ident XXX > > > > options IPSEC > > > > options DEVICE_POLLING > > options ACCEPT_FILTER_HTTP > > > > options ALTQ > > > > options ALTQ_CBQ > > options ALTQ_RED > > options ALTQ_RIO > > options ALTQ_HFSC > > options ALTQ_PRIQ > > > > device crypto > > device enc > > > > > > > * pciconf -lvc (only include the em(4) items please) > > > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 > chip=0x10d38086 rev=0x00 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 > chip=0x10d38086 rev=0x00 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > * vmstat -i > > > > interrupt total rate > > irq1: atkbd0 9 0 > > cpu0: timer 36544552 1994 > > irq256: em0 3801 0 > > irq257: em1 32963909 1799 > > irq258: ahci0 175662 9 > > cpu1: timer 36543525 1994 > > cpu2: timer 36543525 1994 > > cpu3: timer 36543525 1994 > > Total 179318508 9786 > > > > There is an shared IPMI interface on em0, but the interface is not > used > > by FreeBSD. em1 is used by four VLANs. Polling is only in the > > Kernelconfig, not activated on the devices. > > So much complexity here. Tracking this down might be difficult. > > One thing that does concern me is the interrupt rate for em1. Jack et > al, is this normal? I don't see this behaviour on my 8.x systems with > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and don't > have MSI-X support. > > > He is only using one vector anyway it seems, so MSIX isnt making things > much more complex than your 573. > > The interrupt rate seems high but I'm not sure if its abnormal for a busy > interface. > > I tend to agree with Yongari, let's eliminate all the complicating factors > like IPSEC and ALTQ and see if it still occurs. Crashed couply of minutes ago, the kernel without ALTQ and IPSEC is now running. greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 14:44:10 2010 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 B11D810656A3 for ; Fri, 27 Aug 2010 14:44:10 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 770368FC1F for ; Fri, 27 Aug 2010 14:44:10 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id 6EF4E2BB35E; Fri, 27 Aug 2010 10:15:05 -0400 (EDT) Date: Fri, 27 Aug 2010 10:15:03 -0400 From: "Peter C. Lai" To: Ronald Klop Message-ID: <20100827141503.GA57669@cesium.hyperfine.info> References: <4C74261A.4000401@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 14:44:10 -0000 Does the recipient MTA actually receive for both klop.yi.org *and* thuis.klop.ws? The recipient MTA will dereference the CNAME and rewrite the envelope for the reason that it can only relay to an RR that points to a real host. You might be able to fix it if you configure the mta on thuis.klop.ws to accept mail for the thuis.klop.ws domain in addition to klop.yi.org (which I assume is how you have it setup). In a situation like this if you have domain CNAME originaldomain then you better make sure that someone can send to either @domain AND @originaldomain otherwise it doesn't make sense. On 2010-08-27 10:03:52AM +0200, Ronald Klop wrote: > offtopic, but why do some mailers replace a CNAME in a mail-address? > > root@sheeva2:/var/vmail# host klop.yi.org > klop.yi.org CNAME thuis.klop.ws > thuis.klop.ws A 212.123.145.58 > > It is not the first time that I'm bitten by this, but I never understood > it. > > Ronald. > > On Tue, 24 Aug 2010 22:05:46 +0200, Andriy Gapon wrote: > > > > > Ronald, > > > > your email address bounces, that's inconvenient. > > > > > > -------- Original Message -------- > > Subject: Returned mail: Service unavailable > > Date: Tue, 24 Aug 2010 23:03:33 +0300 (EEST) > > From: Mail Delivery Subsystem > > To: > > > > The original message was received at Tue, 24 Aug 2010 23:03:27 +0300 > > (EEST) > > from porto-e.starpoint.kiev.ua [212.40.38.100] > > > > ----- The following addresses had permanent fatal errors ----- > > > > > > ----- Transcript of session follows ----- > > ... while talking to thuis.klop.ws.: > >>>> RCPT To: > > <<< 554 5.7.1 : Relay access denied > > 554 ... Service unavailable > _______________________________________________ > 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" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 15:10:41 2010 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 22A3A1065695; Fri, 27 Aug 2010 15:10:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C426F8FC1E; Fri, 27 Aug 2010 15:10:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB5rd0yDaFvO/2dsb2JhbACDF54zqVWSF4EigyJzBIoJ X-IronPort-AV: E=Sophos;i="4.56,278,1280721600"; d="scan'208";a="91970457" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Aug 2010 10:41:19 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 21D69B3E96; Fri, 27 Aug 2010 10:41:22 -0400 (EDT) Date: Fri, 27 Aug 2010 10:41:22 -0400 (EDT) From: Rick Macklem To: Ivan Voras Message-ID: <1635793326.204904.1282920082122.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4C7678A8.9000201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: rmacklem@freebsd.org, stable@freebsd.org Subject: Re: NFS uid/gid mapping X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 15:10:41 -0000 > hi, > > I can't seem to find how to manually remap uid & gid information while > using NFS, e.g. something similar to this: > > http://www.kernelcrash.com/blog/nfs-uidgid-mapping/2007/09/10/ > > Is such mapping really unimplemented? > Except for root or all uids, no. There is no generic mapping facility. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 16:59:51 2010 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 492A510656AD for ; Fri, 27 Aug 2010 16:59:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8E8F8FC0C for ; Fri, 27 Aug 2010 16:59:49 +0000 (UTC) Received: by wyb33 with SMTP id 33so4338144wyb.13 for ; Fri, 27 Aug 2010 09:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=C2qb7vTDbGSWsqFjafi6uzPqO0jTOVymyrwtP448+Ag=; b=Wq4LxKkGkHMdSvxJKVAQncsJaD9neaK/7/6KFWo3BR5DqyQTZgTT7us9PcKsK2NOQz xjPfemjtE9MgaPa+S2iACS3X3Jw8iUeq1ww5vpygIdddUr9UKVsYY8vmQL+X0N7eptXR qNVRU3xKNwTMQLtUGCLCJkwyXEZXtFm12p634= 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=Es2GVVPcrkMI3vYqnf5KKcWJS2mhbW+O0JJwKqHEPnhphIl/bxpd5kp9OEKZE1iG5e JWNcLh+TnOkj9LW/JrOSYlgYf7gsOnKt+htkbWaYk9Q5xHwDuSmzgVdKUmzN2mcA71z/ cGyYbzL3PKMIypksMNTi89fxt24swHMt0ucPQ= MIME-Version: 1.0 Received: by 10.216.47.80 with SMTP id s58mr1207176web.15.1282928389011; Fri, 27 Aug 2010 09:59:49 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Fri, 27 Aug 2010 09:59:48 -0700 (PDT) In-Reply-To: <4C77B7DA.3040801@h3q.com> References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> <4C77B7DA.3040801@h3q.com> Date: Fri, 27 Aug 2010 09:59:48 -0700 Message-ID: From: Jack Vogel To: Philipp Wuensche Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 16:59:51 -0000 On Fri, Aug 27, 2010 at 6:04 AM, Philipp Wuensche wrote: > Jack Vogel wrote: > > > > > > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick > > > wrote: > > > > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > > > Jeremy Chadwick wrote: > > > > > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have > some > > > > ideas. OP's backtrace is here: > > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > > > > > Philipp, can you please provide the following output? > > > > > > > > * dmesg | egrep 'em[0-9]' > > > > > > em0: port > > 0xdc00-0xdc1f mem > > > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 > > on pci2 > > > em0: Using MSI interrupt > > > em0: [FILTER] > > > em0: Ethernet address: 00:25:90:04:6e:fa > > > em1: port > > 0xec00-0xec1f mem > > > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 > > on pci3 > > > em1: Using MSI interrupt > > > em1: [FILTER] > > > em1: Ethernet address: 00:25:90:04:6e:fb > > > > > > > * uname -a (you can XXX out the machine name if need be) > > > > > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 10:38:50 > CEST > > > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > > > > > Date of source is Aug 17 14:09 CEST 2010. It happend with > 8.1-RELEASE > > > too, I can go back to RELEASE or any SVN revision you would like, > > if it > > > is helping in any way. > > > > > > Kernel-config: > > > > > > include GENERIC > > > > > > ident XXX > > > > > > options IPSEC > > > > > > options DEVICE_POLLING > > > options ACCEPT_FILTER_HTTP > > > > > > options ALTQ > > > > > > options ALTQ_CBQ > > > options ALTQ_RED > > > options ALTQ_RIO > > > options ALTQ_HFSC > > > options ALTQ_PRIQ > > > > > > device crypto > > > device enc > > > > > > > > > > * pciconf -lvc (only include the em(4) items please) > > > > > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 > > chip=0x10d38086 rev=0x00 > > > hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller > (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link > x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 > > chip=0x10d38086 rev=0x00 > > > hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller > (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link > x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > > * vmstat -i > > > > > > interrupt total rate > > > irq1: atkbd0 9 0 > > > cpu0: timer 36544552 1994 > > > irq256: em0 3801 0 > > > irq257: em1 32963909 1799 > > > irq258: ahci0 175662 9 > > > cpu1: timer 36543525 1994 > > > cpu2: timer 36543525 1994 > > > cpu3: timer 36543525 1994 > > > Total 179318508 9786 > > > > > > There is an shared IPMI interface on em0, but the interface is not > > used > > > by FreeBSD. em1 is used by four VLANs. Polling is only in the > > > Kernelconfig, not activated on the devices. > > > > So much complexity here. Tracking this down might be difficult. > > > > One thing that does concern me is the interrupt rate for em1. Jack > et > > al, is this normal? I don't see this behaviour on my 8.x systems > with > > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, and > don't > > have MSI-X support. > > > > > > He is only using one vector anyway it seems, so MSIX isnt making things > > much more complex than your 573. > > > > The interrupt rate seems high but I'm not sure if its abnormal for a busy > > interface. > > > > I tend to agree with Yongari, let's eliminate all the complicating > factors > > like IPSEC and ALTQ and see if it still occurs. > > Crashed couply of minutes ago, the kernel without ALTQ and IPSEC is now > running. > Does this mean the crash happened without IPSEC and ALTQ or it just now started running that kernel?? Jack From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 17:24:46 2010 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 73C88106567A for ; Fri, 27 Aug 2010 17:24:46 +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 1A1908FC17 for ; Fri, 27 Aug 2010 17:24:45 +0000 (UTC) Received: (qmail 16413 invoked by uid 399); 27 Aug 2010 17:24:45 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 27 Aug 2010 17:24:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C77F4DC.9070807@FreeBSD.org> Date: Fri, 27 Aug 2010 10:24:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ronald Klop References: <4C74261A.4000401@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 17:24:46 -0000 On 08/27/2010 01:03 AM, Ronald Klop wrote: > offtopic, but why do some mailers replace a CNAME in a mail-address? > > root@sheeva2:/var/vmail# host klop.yi.org > klop.yi.org CNAME thuis.klop.ws > thuis.klop.ws A 212.123.145.58 > > It is not the first time that I'm bitten by this, but I never understood > it. You've already received all the right answers but I figured I'd respond too since this is my area. Given that klop.yi.org is a CNAME, and that the target hostname (thuis.klop.ws) has no MX record, the fact that you receive any mail at all is a tribute to the robustness principle. :) If you're going to receive mail at thuis.klop.ws then you should really have an MX record for it. See http://dougbarton.us/DNS/MX.html for more information if you need more information or references to the standards. The simplest way to solve your mail delivery problem is to have the @hostname refer to a canonical host (I.e., with an A and/or AAAA record) which also has an MX record. If you insist on using klop.yi.org the _best_ way to do that would be to duplicate those 2 records from thuis.klop.ws. By adding an MX to thuis you are more likely to get mail if klop.yi.org is a CNAME to it, even though it's still not "right." hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 17:33:16 2010 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 16ADD10656AD; Fri, 27 Aug 2010 17:33:16 +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 AED138FC0C; Fri, 27 Aug 2010 17:33:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA22662; Fri, 27 Aug 2010 20:33:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C77F6D6.9020402@icyb.net.ua> Date: Fri, 27 Aug 2010 20:33:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100823 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C6D5E31.9000701@icyb.net.ua> <201008191326.09822.jkim@FreeBSD.org> In-Reply-To: <201008191326.09822.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 17:33:16 -0000 on 19/08/2010 20:26 Jung-uk Kim said the following: > One thing I am not sure is whether those CPUID instructions are > executed on *real* CPUs or translated in HVM. On top of that, I am > not even sure they will be executed on *correct* cores. I bet they > won't. Hmm, I have an impression that we try to detect the topology by doing stuff only on BSP and that's why we handle properly only uniform topologies. So that would make your point about correct cores moot. Am I mistaken? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 19:36:18 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 1B9741065675; Fri, 27 Aug 2010 19:36:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 15:36:03 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008191326.09822.jkim@FreeBSD.org> <4C77F6D6.9020402@icyb.net.ua> In-Reply-To: <4C77F6D6.9020402@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271536.08773.jkim@FreeBSD.org> Cc: jeff@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 19:36:18 -0000 On Friday 27 August 2010 01:33 pm, Andriy Gapon wrote: > on 19/08/2010 20:26 Jung-uk Kim said the following: > > One thing I am not sure is whether those CPUID instructions are > > executed on *real* CPUs or translated in HVM. On top of that, I > > am not even sure they will be executed on *correct* cores. I bet > > they won't. > > Hmm, I have an impression that we try to detect the topology by > doing stuff only on BSP and that's why we handle properly only > uniform topologies. So that would make your point about correct > cores moot. > Am I mistaken? No, you're correct. Here goes little background information. Originally, Jeff tried to implement Intel's algorithm[1] as described here, if my understanding is correct: http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ Unfortunately, this algorithm needed to execute CPUID instruction on every core and aggregate them later. Thus, he had to compromise and made it simpler, I believe[2]. However, this compromise had some side effects and my patch was an attempt to correct them (sorry, I forgot the details). It was never committed because Jeff said "I will look it over in more detail soon" at the time. Then, I had to return the CPU, which was an engineering sample[3] and now in production. That's how my patch has been neglected for long time and just re-discovered from trashcan of rejected patches, thanks to this thread. ;-) Now, back to my original question. My point was, we should never trust any CPUIDs on emulated CPU if they are translated. What should happen if you have four physical cores and you "assign" just one for VirtualBox, for example? What should we "announce" if you are emulating two cores on UP host? How do we know whether it is "the" real BSP or not? Is it really bound to a CPU? Is "CPUID leaf 11" emulated properly? If not, is it an emulator bug or a guest OS bug? Do we really care about "physical topology" in these cases? IMHO, the answer is no, we don't, and we should say "all cores are independent". If anyone really cares and wants prettier printing, we may say "N virtual cores", though. I hope it makes sense. Jung-uk Kim [1] I believe he referenced an older revision, though. [2] It was committed as r191648: http://svn.freebsd.org/viewvc/base?view=revision&revision=191648 Also, this commit is related to kern/145385: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and my patch won't work on them. If anyone has a Bulldozer sample, please look into it. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 19:47:16 2010 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 8022210656A4; Fri, 27 Aug 2010 19:47:16 +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 975578FC16; Fri, 27 Aug 2010 19:47:15 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA23941; Fri, 27 Aug 2010 22:47:13 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op4tN-0003LV-E7; Fri, 27 Aug 2010 22:47:13 +0300 Message-ID: <4C781640.8010909@icyb.net.ua> Date: Fri, 27 Aug 2010 22:47:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008191326.09822.jkim@FreeBSD.org> <4C77F6D6.9020402@icyb.net.ua> <201008271536.08773.jkim@FreeBSD.org> In-Reply-To: <201008271536.08773.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 19:47:16 -0000 on 27/08/2010 22:36 Jung-uk Kim said the following: > Now, back to my original question. My point was, we should never > trust any CPUIDs on emulated CPU if they are translated. What should > happen if you have four physical cores and you "assign" just one for > VirtualBox, for example? What should we "announce" if you are > emulating two cores on UP host? How do we know whether it is "the" > real BSP or not? Is it really bound to a CPU? Is "CPUID leaf 11" > emulated properly? If not, is it an emulator bug or a guest OS bug? > Do we really care about "physical topology" in these cases? IMHO, > the answer is no, we don't, and we should say "all cores are > independent". If anyone really cares and wants prettier printing, we > may say "N virtual cores", though. Thanks a lot for the rest of the info that I snipped, very interesting and useful! To this issue - I'd say let the developers of virtual machines worry that their machines look like real hardware, not us. More specifically, in this thread we saw that current FreeBSD code (without the patch) and Intel's code detect the same topology and that topology looks reasonable for the person who started the thread. With the patch though, detected topology looks different. So I'd rather not worry about the general case of virtual machines right now. Let's first see more evidence of whether we should trust them or not. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 19:50:36 2010 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 493C21065672 for ; Fri, 27 Aug 2010 19:50:36 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 7303F8FC08 for ; Fri, 27 Aug 2010 19:50:35 +0000 (UTC) Received: (qmail 54003 invoked from network); 27 Aug 2010 19:50:33 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 27 Aug 2010 19:50:33 -0000 Message-ID: <4C781707.9020201@h3q.com> Date: Fri, 27 Aug 2010 21:50:31 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jack Vogel References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> <4C77B7DA.3040801@h3q.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 19:50:36 -0000 Jack Vogel wrote: > > > On Fri, Aug 27, 2010 at 6:04 AM, Philipp Wuensche > wrote: > > Jack Vogel wrote: > > > > > > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick > > > >> > wrote: > > > > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > > > Jeremy Chadwick wrote: > > > > > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might > have some > > > > ideas. OP's backtrace is here: > > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058425.html > > > > > > > > Philipp, can you please provide the following output? > > > > > > > > * dmesg | egrep 'em[0-9]' > > > > > > em0: port > > 0xdc00-0xdc1f mem > > > 0xfe9e0000-0xfe9fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 > > on pci2 > > > em0: Using MSI interrupt > > > em0: [FILTER] > > > em0: Ethernet address: 00:25:90:04:6e:fa > > > em1: port > > 0xec00-0xec1f mem > > > 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 17 at device 0.0 > > on pci3 > > > em1: Using MSI interrupt > > > em1: [FILTER] > > > em1: Ethernet address: 00:25:90:04:6e:fb > > > > > > > * uname -a (you can XXX out the machine name if > need be) > > > > > > FreeBSD XXX 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Aug 25 > 10:38:50 CEST > > > 2010 root@XXX:/usr/obj/usr/src/sys/XXX amd64 > > > > > > Date of source is Aug 17 14:09 CEST 2010. It happend with > 8.1-RELEASE > > > too, I can go back to RELEASE or any SVN revision you would > like, > > if it > > > is helping in any way. > > > > > > Kernel-config: > > > > > > include GENERIC > > > > > > ident XXX > > > > > > options IPSEC > > > > > > options DEVICE_POLLING > > > options ACCEPT_FILTER_HTTP > > > > > > options ALTQ > > > > > > options ALTQ_CBQ > > > options ALTQ_RED > > > options ALTQ_RIO > > > options ALTQ_HFSC > > > options ALTQ_PRIQ > > > > > > device crypto > > > device enc > > > > > > > > > > * pciconf -lvc (only include the em(4) items please) > > > > > > em0@pci0:2:0:0: class=0x020000 card=0x060a15d9 > > chip=0x10d38086 rev=0x00 > > > hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller > (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with > 1 message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) > link x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > em1@pci0:3:0:0: class=0x020000 card=0x060a15d9 > > chip=0x10d38086 rev=0x00 > > > hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller > (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with > 1 message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) > link x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > > * vmstat -i > > > > > > interrupt total rate > > > irq1: atkbd0 9 0 > > > cpu0: timer 36544552 1994 > > > irq256: em0 3801 0 > > > irq257: em1 32963909 1799 > > > irq258: ahci0 175662 9 > > > cpu1: timer 36543525 1994 > > > cpu2: timer 36543525 1994 > > > cpu3: timer 36543525 1994 > > > Total 179318508 9786 > > > > > > There is an shared IPMI interface on em0, but the interface > is not > > used > > > by FreeBSD. em1 is used by four VLANs. Polling is only in the > > > Kernelconfig, not activated on the devices. > > > > So much complexity here. Tracking this down might be difficult. > > > > One thing that does concern me is the interrupt rate for em1. > Jack et > > al, is this normal? I don't see this behaviour on my 8.x > systems with > > em(4) driver 7.0.5, but my systems all use 82573E and 82573L, > and don't > > have MSI-X support. > > > > > > He is only using one vector anyway it seems, so MSIX isnt making > things > > much more complex than your 573. > > > > The interrupt rate seems high but I'm not sure if its abnormal for > a busy > > interface. > > > > I tend to agree with Yongari, let's eliminate all the complicating > factors > > like IPSEC and ALTQ and see if it still occurs. > > Crashed couply of minutes ago, the kernel without ALTQ and IPSEC is now > running. > > > Does this mean the crash happened without IPSEC and ALTQ or it just now > started running that kernel?? It just now started running the kernel without IPSEC and ALTQ. greetings, philipp From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 20:16:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3261D1065674; Fri, 27 Aug 2010 20:16:14 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 16:15:55 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271536.08773.jkim@FreeBSD.org> <4C781640.8010909@icyb.net.ua> In-Reply-To: <4C781640.8010909@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271615.58056.jkim@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 20:16:15 -0000 On Friday 27 August 2010 03:47 pm, Andriy Gapon wrote: > on 27/08/2010 22:36 Jung-uk Kim said the following: > > Now, back to my original question. My point was, we should never > > trust any CPUIDs on emulated CPU if they are translated. What > > should happen if you have four physical cores and you "assign" > > just one for VirtualBox, for example? What should we "announce" > > if you are emulating two cores on UP host? How do we know > > whether it is "the" real BSP or not? Is it really bound to a > > CPU? Is "CPUID leaf 11" emulated properly? If not, is it an > > emulator bug or a guest OS bug? Do we really care about "physical > > topology" in these cases? IMHO, the answer is no, we don't, and > > we should say "all cores are independent". If anyone really > > cares and wants prettier printing, we may say "N virtual cores", > > though. > > Thanks a lot for the rest of the info that I snipped, very > interesting and useful! > > To this issue - I'd say let the developers of virtual machines > worry that their machines look like real hardware, not us. > More specifically, in this thread we saw that current FreeBSD code > (without the patch) and Intel's code detect the same topology and > that topology looks reasonable for the person who started the > thread. With the patch though, detected topology looks different. > So I'd rather not worry about the general case of virtual machines > right now. Let's first see more evidence of whether we should trust > them or not. I quickly looked over Xen sources. It seems the CPUID instruction is translated by this code: http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c For HVM case, this is how the CPUID_HTT_CORES is set: 185 case 0x00000001: 186 /* 187 * EBX[23:16] is Maximum Logical Processors Per Package. 188 * Update to reflect vLAPIC_ID = vCPU_ID * 2. 189 */ 190 regs[1] = (regs[1] & 0x0000ffffu) | ((regs[1] & 0x007f0000u) << 1); But CPUID 0x0b is not handled and falls here: 265 default: 266 regs[0] = regs[1] = regs[2] = regs[3] = 0; 267 break; I am not a Xen developer, so please don't shoot me. ;-) Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 20:18:06 2010 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 0C3711065693; Fri, 27 Aug 2010 20:18:06 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8628FC20; Fri, 27 Aug 2010 20:18:05 +0000 (UTC) Received: by qwg5 with SMTP id 5so3477281qwg.13 for ; Fri, 27 Aug 2010 13:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HTPIZ4SSVFAmYcuf/Ry688ilr9dyPguc0WHpXVLdg9c=; b=lzj0Gv4l9YnvauWzEBNgI6fURBb5WyxZCfz5jplKOcezLhu4YPnDA0w8Q6aZQZ+P4b f+Ha4v4mKJu2GROG2hL0p3VvfQN1f1J1kloofEEW8DZL65PdGesSsn2eZA0BkfWZZS5z ScewuDNXFDXafDnnfjxQhDSobd3J48H+GGcq4= 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=Ei0DHhWazSZV3exUMxQiaTexNUyWb5djwlEVwLqb2pZH6PuPH848GvhxH+smnMFwVm ywyhaSSWI+QfrcxJ9Z1bq/8S0Gri9PD3T/DJUE1BTypMjSKpyXcSbofveRw9EZ0ShPMU L7ilSwb0MM2vIAtnAZFLU20XmwbV5o+MHJTCE= MIME-Version: 1.0 Received: by 10.229.182.141 with SMTP id cc13mr920581qcb.56.1282940284782; Fri, 27 Aug 2010 13:18:04 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Fri, 27 Aug 2010 13:18:04 -0700 (PDT) In-Reply-To: References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> Date: Sat, 28 Aug 2010 00:18:04 +0400 Message-ID: From: pluknet To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jung-uk Kim Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 20:18:06 -0000 On 19 August 2010 20:56, pluknet wrote: > On 19 August 2010 20:39, Andriy Gapon wrote: >> on 10/08/2010 19:55 pluknet said the following: >>> On 16 July 2010 19:47, Jung-uk Kim wrote: >>>> The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and >>>> sys/i386/i386/mp_machdep.c. >>>> >>>> http://people.freebsd.org/~jkim/mp_machdep2.diff >>>> >>> >>> >>> Hi. >>> >>> Just checked on Xen HVM with 3 cores. >>> 1) 8.1 unmodified: >>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >>> FreeBSD/SMP: 1 package(s) x 3 core(s) >>> >>> 2) 8.1 + patch >>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >>> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >>> WARNING: Non-uniform processors. >>> WARNING: Using suboptimal topology. >> >> Can you debug, e.g. with printfs, what exactly goes wrong? >> I wonder if in this case code follows some unusual/unexpected path. > > Sorry, I'm a bit busy right now. > I hope to debug this somewhere in the next week. First, sorry for late replay, and thanks Andriy for kicking me ;) Something really weird there . topo_probe_0xb() falls early on 1st iteration back to topo_probe_0x4(). topo_probe_0x4() returns incorrect data as well. topo_probe: cpu_high =3D b topo_probe: cpu_vendor_id =3D 8086 topo_probe_0xb: i =3D 0, p[1] =3D 0 topo_probe_0x4: cpu_procinfo =3D 200800 topo_probe_0x4: cpu_logical =3D 32 topo_probe_0x4: i =3D 0, type =3D 1 topo_probe_0x4: i =3D 0, level =3D 1 topo_probe_0x4: i =3D 0, logical =3D 1 topo_probe_0x4: i =3D 0, cores =3D 16 topo_probe_0x4: i =3D 1, type =3D 2 topo_probe_0x4: i =3D 1, level =3D 1 topo_probe_0x4: i =3D 1, logical =3D 1 topo_probe_0x4: i =3D 1, cores =3D 16 topo_probe_0x4: i =3D 2, type =3D 3 topo_probe_0x4: i =3D 2, level =3D 2 topo_probe_0x4: i =3D 2, logical =3D 1 topo_probe_0x4: i =3D 2, cores =3D 16 topo_probe#1: mp_ncpus =3D 3 topo_probe#1: cpu_cores =3D 1 topo_probe#1: cpu_logical =3D 32 topo_probe#1: hyperthreading_cpus =3D 32 topo_probe#2: mp_ncpus =3D 3 topo_probe#2: cpu_cores =3D 1 topo_probe#2: cpu_logical =3D 32 topo_probe#2: hyperthreading_cpus =3D 32 %%% static void topo_probe_0x4(void) { u_int p[4]; int cores; int i; int level; int logical; int type; cpu_logical =3D (cpu_feature & CPUID_HTT) !=3D 0 ? (cpu_procinfo & CPUID_HTT_CORES) >> 16 : 1; printf("topo_probe_0x4: cpu_procinfo =3D %x\n", cpu_procinfo); printf("topo_probe_0x4: cpu_logical =3D %d\n", cpu_logical); if (cpu_logical =3D=3D 1) { cpu_cores =3D 1; return; } /* We only support three levels for now. */ for (i =3D 0; i < 3; i++) { cpuid_count(0x04, i, p); type =3D p[0] & 0x1f; printf("topo_probe_0x4: i =3D %d, type =3D %d\n", i, type); level =3D (p[0] >> 5) & 0x7; printf("topo_probe_0x4: i =3D %d, level =3D %d\n", i, level= ); logical =3D ((p[0] >> 14) & 0xfff) + 1; printf("topo_probe_0x4: i =3D %d, logical =3D %d\n", i, log= ical); cores =3D ((p[0] >> 26) & 0x3f) + 1; printf("topo_probe_0x4: i =3D %d, cores =3D %d\n", i, cores= ); if (type =3D=3D 0) break; if (level =3D=3D 1 && cpu_logical =3D=3D logical * cores) { cpu_cores =3D cores; cpu_logical =3D logical; break; } } if (cpu_cores =3D=3D 0) cpu_cores =3D 1; if (cpu_logical > 1) hyperthreading_cpus =3D logical_cpus =3D cpu_logical; } static void topo_probe_0xb(void) { u_int p[4]; int bits; int cnt; int i; int logical; int type; int x; /* We only support three levels for now. */ for (i =3D 0; i < 3; i++) { cpuid_count(0x0b, i, p); /* * Fall back if it is not really supported. */ if (i =3D=3D 0 && p[1] =3D=3D 0) { printf("topo_probe_0xb: i =3D %d, p[1] =3D %d\n", i= , p[1]); topo_probe_0x4(); return; } [...] } static void topo_probe(void) { static int cpu_topo_probed =3D 0; if (cpu_topo_probed) return; printf("topo_probe: cpu_high =3D %x\n", cpu_high); printf("topo_probe: cpu_vendor_id =3D %x\n", cpu_vendor_id); logical_cpus =3D logical_cpus_mask =3D 0; if (cpu_vendor_id =3D=3D CPU_VENDOR_AMD) topo_probe_amd(); else if (cpu_vendor_id =3D=3D CPU_VENDOR_INTEL) { if (cpu_high >=3D 0xb) topo_probe_0xb(); else if (cpu_high >=3D 0x4) topo_probe_0x4(); } printf("topo_probe#1: mp_ncpus =3D %d\n", mp_ncpus); printf("topo_probe#1: cpu_cores =3D %d\n", cpu_cores); printf("topo_probe#1: cpu_logical =3D %d\n", cpu_logical); printf("topo_probe#1: hyperthreading_cpus =3D %d\n", hyperthreading= _cpus); if (cpu_cores =3D=3D 0) cpu_cores =3D mp_ncpus > 0 ? mp_ncpus : 1; if (cpu_logical =3D=3D 0) cpu_logical =3D 1; cpu_topo_probed =3D 1; printf("topo_probe#2: mp_ncpus =3D %d\n", mp_ncpus); printf("topo_probe#2: cpu_cores =3D %d\n", cpu_cores); printf("topo_probe#2: cpu_logical =3D %d\n", cpu_logical); printf("topo_probe#2: hyperthreading_cpus =3D %d\n", hyperthreading= _cpus); } > >> BTW, could you please also provide CPU name/model/features as detected b= y the kernel? > > Sure. > CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 E5520 =A0@ 2.27GHz (2763.12= -MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106a5 =A0Family =3D 6 =A0Model = =3D 1a =A0Stepping =3D 5 > =A0Features=3D0x1781fbbf > =A0Features2=3D0x80982201> > =A0TSC: P-state invariant > real memory =A0=3D 4194304000 (4000 MB) > avail memory =3D 3932786688 (3750 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP/HT): APIC ID: =A02 > =A0cpu2 (AP/HT): APIC ID: =A04 --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 20:19:42 2010 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 E2FA710656D2; Fri, 27 Aug 2010 20:19:42 +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 060B18FC18; Fri, 27 Aug 2010 20:19:41 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA24241; Fri, 27 Aug 2010 23:19:40 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op5Ol-0003Ny-NR; Fri, 27 Aug 2010 23:19:39 +0300 Message-ID: <4C781DDB.1080903@icyb.net.ua> Date: Fri, 27 Aug 2010 23:19:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271536.08773.jkim@FreeBSD.org> <4C781640.8010909@icyb.net.ua> <201008271615.58056.jkim@FreeBSD.org> In-Reply-To: <201008271615.58056.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 20:19:43 -0000 on 27/08/2010 23:15 Jung-uk Kim said the following: > I quickly looked over Xen sources. It seems the CPUID instruction is > translated by this code: > > http://lxr.xensource.com/lxr/source/tools/libxc/xc_cpuid_x86.c > > For HVM case, this is how the CPUID_HTT_CORES is set: > > 185 case 0x00000001: > 186 /* > 187 * EBX[23:16] is Maximum Logical Processors Per Package. > 188 * Update to reflect vLAPIC_ID = vCPU_ID * 2. > 189 */ > 190 regs[1] = (regs[1] & 0x0000ffffu) | ((regs[1] & 0x007f0000u) << 1); > > But CPUID 0x0b is not handled and falls here: Does it have to be handled? 0x4 should still work. > 265 default: > 266 regs[0] = regs[1] = regs[2] = regs[3] = 0; > 267 break; > > I am not a Xen developer, so please don't shoot me. ;-) I still don't get your point. My point is that if the Intel's code gets the topology right, then the hardware is emulated properly and the problem is with the patch. What is your point? :) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 21:25:20 2010 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 9DE16106566C; Fri, 27 Aug 2010 21:25:20 +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 AEC308FC1E; Fri, 27 Aug 2010 21:25:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA24908; Sat, 28 Aug 2010 00:25:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op6QG-0003Sl-Mf; Sat, 28 Aug 2010 00:25:16 +0300 Message-ID: <4C782D3B.6020407@icyb.net.ua> Date: Sat, 28 Aug 2010 00:25:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: pluknet References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jung-uk Kim Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 21:25:20 -0000 on 27/08/2010 23:18 pluknet said the following: > First, sorry for late replay, and thanks Andriy for kicking me ;) > > Something really weird there . > topo_probe_0xb() falls early on 1st iteration back to topo_probe_0x4(). > topo_probe_0x4() returns incorrect data as well. > > topo_probe: cpu_high = b > topo_probe: cpu_vendor_id = 8086 > topo_probe_0xb: i = 0, p[1] = 0 > topo_probe_0x4: cpu_procinfo = 200800 > topo_probe_0x4: cpu_logical = 32 > topo_probe_0x4: i = 0, type = 1 > topo_probe_0x4: i = 0, level = 1 > topo_probe_0x4: i = 0, logical = 1 > topo_probe_0x4: i = 0, cores = 16 > topo_probe_0x4: i = 1, type = 2 > topo_probe_0x4: i = 1, level = 1 > topo_probe_0x4: i = 1, logical = 1 > topo_probe_0x4: i = 1, cores = 16 > topo_probe_0x4: i = 2, type = 3 > topo_probe_0x4: i = 2, level = 2 > topo_probe_0x4: i = 2, logical = 1 > topo_probe_0x4: i = 2, cores = 16 > topo_probe#1: mp_ncpus = 3 > topo_probe#1: cpu_cores = 1 > topo_probe#1: cpu_logical = 32 > topo_probe#1: hyperthreading_cpus = 32 > topo_probe#2: mp_ncpus = 3 > topo_probe#2: cpu_cores = 1 > topo_probe#2: cpu_logical = 32 > topo_probe#2: hyperthreading_cpus = 32 My interpretation: 1. Current (unpatched) code reports correct results either by a chance or because Jeff knows some magic patterns. cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb, but CPUID.(EAX=11, ECX=0):EBX == 0, which means that we should fallback to 0x4 method. But the code doesn't do that and instead simply sets cpu_logical to 1 and cpu_cores stays zero, which is later translated to mp_ncpus, which happens to match the reality. 2. Intel reports correct results, because it properly probes the topology. It binds to each of the logical processors available and checks their APIC IDs against masks and builds topology info. 3. Patched code works incorrectly, because essentially it only calculates masks for CPU (and cache, for some reason) topology building. Instead of checking IDs against those masks, the code assumes numbers of cores and threads are at their maximum values allowed by the masks[*]. But that is not true and the numbers do not add up and we get that strange incorrect result. Things like that probably do not happen with real hardware much, but they could. The only way to deal with this is by following the correct procedure instead of making assumptions based on BSP. But that may be hard. [*] E.g. that page says: CPUID.1:EBX[23:16] represents the maximum number of addressable IDs (initial APIC ID) that can be assigned to logical processors in a physical package. The value may not be the same as the number of logical processors that are present in the hardware of a physical package. The value of (1 + (CPUID.(EAX=4, ECX=0):EAX[31:26] )) represents the maximum number of addressable IDs (Core_ID) that can be used to enumerate different processor cores in a physical package. The value also can be different than the actual number of processor cores that are present in the hardware of a physical package. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 21:43:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8AA521065696; Fri, 27 Aug 2010 21:43:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 17:43:26 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> In-Reply-To: <4C782D3B.6020407@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271743.29393.jkim@FreeBSD.org> Cc: pluknet , freebsd-stable@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 21:43:37 -0000 On Friday 27 August 2010 05:25 pm, Andriy Gapon wrote: > on 27/08/2010 23:18 pluknet said the following: > > First, sorry for late replay, and thanks Andriy for kicking me ;) > > > > Something really weird there . > > topo_probe_0xb() falls early on 1st iteration back to > > topo_probe_0x4(). topo_probe_0x4() returns incorrect data as > > well. > > > > topo_probe: cpu_high = b > > topo_probe: cpu_vendor_id = 8086 > > topo_probe_0xb: i = 0, p[1] = 0 > > topo_probe_0x4: cpu_procinfo = 200800 > > topo_probe_0x4: cpu_logical = 32 > > topo_probe_0x4: i = 0, type = 1 > > topo_probe_0x4: i = 0, level = 1 > > topo_probe_0x4: i = 0, logical = 1 > > topo_probe_0x4: i = 0, cores = 16 > > topo_probe_0x4: i = 1, type = 2 > > topo_probe_0x4: i = 1, level = 1 > > topo_probe_0x4: i = 1, logical = 1 > > topo_probe_0x4: i = 1, cores = 16 > > topo_probe_0x4: i = 2, type = 3 > > topo_probe_0x4: i = 2, level = 2 > > topo_probe_0x4: i = 2, logical = 1 > > topo_probe_0x4: i = 2, cores = 16 > > topo_probe#1: mp_ncpus = 3 > > topo_probe#1: cpu_cores = 1 > > topo_probe#1: cpu_logical = 32 > > topo_probe#1: hyperthreading_cpus = 32 > > topo_probe#2: mp_ncpus = 3 > > topo_probe#2: cpu_cores = 1 > > topo_probe#2: cpu_logical = 32 > > topo_probe#2: hyperthreading_cpus = 32 > > My interpretation: > > 1. Current (unpatched) code reports correct results either by a > chance or because Jeff knows some magic patterns. > cpu_high (CPUID_Leaf_Max in Intel's lingo) is 0xb, > but CPUID.(EAX=11, ECX=0):EBX == 0, > which means that we should fallback to 0x4 method. > But the code doesn't do that and instead simply sets cpu_logical to > 1 and cpu_cores stays zero, which is later translated to mp_ncpus, > which happens to match the reality. > > 2. Intel reports correct results, because it properly probes the > topology. It binds to each of the logical processors available and > checks their APIC IDs against masks and builds topology info. > > 3. Patched code works incorrectly, because essentially it only > calculates masks for CPU (and cache, for some reason) topology > building. Instead of checking IDs against those masks, the code > assumes numbers of cores and threads are at their maximum values > allowed by the masks[*]. But that is not true and the numbers do > not add up and we get that strange incorrect result. Yes, your interpretation is correct, I believe. > Things like that probably do not happen with real hardware much, > but they could. AFAIK, it never happened on a real hardware. > The only way to deal with this is by following the correct procedure > instead of making assumptions based on BSP. But that may be hard. Feel free to rewrite the patch. I never intended to commit the patch, any way. If I ever did, it was a year ago. :-) > [*] E.g. that page says: > CPUID.1:EBX[23:16] represents the maximum number of addressable IDs > (initial APIC ID) that can be assigned to logical processors in a > physical package. The value may not be the same as the number of > logical processors that are present in the hardware of a physical > package. The value of (1 + (CPUID.(EAX=4, ECX=0):EAX[31:26] )) > represents the maximum number of addressable IDs (Core_ID) that can > be used to enumerate different processor cores in a physical > package. The value also can be different than the actual number of > processor cores that are present in the hardware of a physical > package. Yes, I already know that. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:02:18 2010 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 A9BF51065693; Fri, 27 Aug 2010 22:02:18 +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 B5B168FC0C; Fri, 27 Aug 2010 22:02:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA25311; Sat, 28 Aug 2010 01:02:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op703-0003WI-Mg; Sat, 28 Aug 2010 01:02:15 +0300 Message-ID: <4C7835E6.6070309@icyb.net.ua> Date: Sat, 28 Aug 2010 01:02:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> In-Reply-To: <201008271743.29393.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pluknet , freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 22:02:18 -0000 on 28/08/2010 00:43 Jung-uk Kim said the following: >> Things like that probably do not happen with real hardware much, >> but they could. > > AFAIK, it never happened on a real hardware. > >> The only way to deal with this is by following the correct procedure >> instead of making assumptions based on BSP. But that may be hard. > > Feel free to rewrite the patch. I never intended to commit the patch, > any way. If I ever did, it was a year ago. :-) :-) BTW, it may be not that hard. It seems that 0x4 topology building involves knowing the masks and we already have that data (just interpreted differently), and APIC IDs of the CPUs and it seems that we also have that. We don't need to bind to CPUs to learn their IDs, we can just iterate over cpu_apic_ids[]. The only problem is that currently topo_probe() is called before assign_cpu_ids() which populates cpu_apic_ids. assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value. So, either cpu_apic_ids could be split out or alternatively we could use cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present and cpu_disabled entries). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:03:35 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 105C81065673; Fri, 27 Aug 2010 22:03:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 18:03:24 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271615.58056.jkim@FreeBSD.org> <4C781DDB.1080903@icyb.net.ua> In-Reply-To: <4C781DDB.1080903@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271803.27295.jkim@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 22:03:35 -0000 On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote: > I still don't get your point. > My point is that if the Intel's code gets the topology right, then > the hardware is emulated properly and the problem is with the > patch. > What is your point? :) My point is "right" topology means nothing in this context if CPU affinity of guest OS does not reflect hypervisor's point of view. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:05:07 2010 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 8B0AD1065696; Fri, 27 Aug 2010 22:05:07 +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 97F248FC20; Fri, 27 Aug 2010 22:05:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA25379; Sat, 28 Aug 2010 01:05:04 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op72m-0003Wd-Mc; Sat, 28 Aug 2010 01:05:04 +0300 Message-ID: <4C783690.2020101@icyb.net.ua> Date: Sat, 28 Aug 2010 01:05:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271615.58056.jkim@FreeBSD.org> <4C781DDB.1080903@icyb.net.ua> <201008271803.27295.jkim@FreeBSD.org> In-Reply-To: <201008271803.27295.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 22:05:07 -0000 on 28/08/2010 01:03 Jung-uk Kim said the following: > On Friday 27 August 2010 04:19 pm, Andriy Gapon wrote: >> I still don't get your point. >> My point is that if the Intel's code gets the topology right, then >> the hardware is emulated properly and the problem is with the >> patch. >> What is your point? :) > > My point is "right" topology means nothing in this context if CPU > affinity of guest OS does not reflect hypervisor's point of view. I see. And I just cared about the pretty message in dmesg, nothing more :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:33:52 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id CDCE510656AD; Fri, 27 Aug 2010 22:33:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 27 Aug 2010 18:33:37 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> In-Reply-To: <4C7835E6.6070309@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271833.42133.jkim@FreeBSD.org> Cc: pluknet , Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 22:33:52 -0000 On Friday 27 August 2010 06:02 pm, Andriy Gapon wrote: > on 28/08/2010 00:43 Jung-uk Kim said the following: > >> Things like that probably do not happen with real hardware much, > >> but they could. > > > > AFAIK, it never happened on a real hardware. > > > >> The only way to deal with this is by following the correct > >> procedure instead of making assumptions based on BSP. But that > >> may be hard. > > > > Feel free to rewrite the patch. I never intended to commit the > > patch, any way. If I ever did, it was a year ago. :-) > > > :-) > > BTW, it may be not that hard. > It seems that 0x4 topology building involves knowing the masks and > we already have that data (just interpreted differently), and APIC > IDs of the CPUs and it seems that we also have that. We don't need > to bind to CPUs to learn their IDs, we can just iterate over > cpu_apic_ids[]. > > The only problem is that currently topo_probe() is called before > assign_cpu_ids() which populates cpu_apic_ids. > assign_cpu_ids depends on topo_probe to know hyperthreading_cpus > value. So, either cpu_apic_ids could be split out or alternatively > we could use cpu_info[] similarly to how it's done in > topo_probe_0xb (skipping !cpu_present and cpu_disabled entries). If you are really up to this, it has to be a two-pass process. Even then, the dmesg won't be pretty because the topology can only be "announced" after all APs have been started. I mean, nobody's going to like to see a message like this from dmesg output: ... ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 --- >8 --- Snip several hundred lines! --- >8 --- SMP: AP CPU #1 Launched! FreeBSD/SMP: 1 package(s) x 2 core(s) Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 ... In fact, I implemented something like that while I was writing the patch but I discarded it for an obvious reason. ;-) Also, don't forget jhb's work based on ACPI affinity tables. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 22:46:20 2010 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 6659D10656A7; Fri, 27 Aug 2010 22:46:20 +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 7EBF38FC16; Fri, 27 Aug 2010 22:46:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA25731; Sat, 28 Aug 2010 01:46:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Op7gf-0003ZW-7S; Sat, 28 Aug 2010 01:46:17 +0300 Message-ID: <4C784038.4070305@icyb.net.ua> Date: Sat, 28 Aug 2010 01:46:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <201008271833.42133.jkim@FreeBSD.org> In-Reply-To: <201008271833.42133.jkim@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 22:46:20 -0000 on 28/08/2010 01:33 Jung-uk Kim said the following: > If you are really up to this, it has to be a two-pass process. Even > then, the dmesg won't be pretty because the topology can only be > "announced" after all APs have been started. I mean, nobody's going > to like to see a message like this from dmesg output: > > ... > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > > --- >8 --- Snip several hundred lines! --- >8 --- > > SMP: AP CPU #1 Launched! > FreeBSD/SMP: 1 package(s) x 2 core(s) > Root mount waiting for: usbus5 usbus2 > Root mount waiting for: usbus5 usbus2 > ... > > In fact, I implemented something like that while I was writing the > patch but I discarded it for an obvious reason. ;-) Well, I was just going to write that I would still keep the assumption that physical packages are identical :-) Not nice, but messing with APs I don't want :) > Also, don't forget jhb's work based on ACPI affinity tables. Not sure how they are applicable here. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 23:03:43 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6886B1065675; Fri, 27 Aug 2010 23:03:43 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Fri, 27 Aug 2010 19:03:32 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008271833.42133.jkim@FreeBSD.org> <4C784038.4070305@icyb.net.ua> In-Reply-To: <4C784038.4070305@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008271903.34011.jkim@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 23:03:44 -0000 On Friday 27 August 2010 06:46 pm, Andriy Gapon wrote: > on 28/08/2010 01:33 Jung-uk Kim said the following: > > Also, don't forget jhb's work based on ACPI affinity tables. > > Not sure how they are applicable here. Only SRAT is implemented ATM but SLIT should provide CPU affinity information without messing with CPUID. In fact, I'd prefer that over messing with Intel's CPUID hacks, which gets messier whenever they release a new core. ;-) Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 27 23:13:34 2010 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 62B93106566B for ; Fri, 27 Aug 2010 23:13:34 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 341D88FC12 for ; Fri, 27 Aug 2010 23:13:33 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id o7RN1ihT015533; Fri, 27 Aug 2010 16:01:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201008272301.o7RN1ihT015533@gw.catspoiler.org> Date: Fri, 27 Aug 2010 16:01:44 -0700 (PDT) From: Don Lewis To: ronald-freebsd8@thuis.klop.ws In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, avg@icyb.net.ua Subject: Re: cname replace in mail address? [off-topic] (Re: Attn Ronald Klop) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Aug 2010 23:13:34 -0000 On 27 Aug, Ronald Klop wrote: > Mandatory? I'm googling, but can't find a document that declares it > mandatory and only sendmail seems to do it. > I think it is lame to use DNS info to rewrite e-mail addresses, but the > person who made it 'mandatory' will have good reasons for it. > > Does somebody have a pointer to the specs about this? 5.2.2 Canonicalization: RFC-821 Section 3.1 The domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been "canonicalized," i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations. A canonicalized name either identifies a host directly or is an MX name; it cannot be a CNAME. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 28 14:19:10 2010 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 5561610656A8 for ; Sat, 28 Aug 2010 14:19:10 +0000 (UTC) (envelope-from cryx-freebsd@h3q.com) Received: from mail.h3q.com (mail.h3q.com [213.73.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 860698FC17 for ; Sat, 28 Aug 2010 14:19:09 +0000 (UTC) Received: (qmail 40474 invoked from network); 28 Aug 2010 14:19:08 -0000 Received: from mail.h3q.com (HELO mail.h3q.com) (cryx) by mail.h3q.com with AES256-SHA encrypted SMTP; 28 Aug 2010 14:19:08 -0000 Message-ID: <4C791ADB.9040505@h3q.com> Date: Sat, 28 Aug 2010 16:19:07 +0200 From: Philipp Wuensche User-Agent: Postbox 1.1.5 (Macintosh/20100613) MIME-Version: 1.0 To: Jack Vogel References: <4C744DC4.3070100@h3q.com> <201008250109.o7P19uEp046002@lava.sentex.ca> <4C76A226.5070302@h3q.com> <20100826212757.GA3391@icarus.home.lan> <4C76E320.9090008@h3q.com> <20100826221526.GA4760@icarus.home.lan> <4C77B7DA.3040801@h3q.com> <4C781707.9020201@h3q.com> In-Reply-To: <4C781707.9020201@h3q.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: PYUN YongHyeon , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Crashes on X7SPE-HF with em X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Aug 2010 14:19:10 -0000 Philipp Wuensche wrote: > > It just now started running the kernel without IPSEC and ALTQ. Here we go again, this time it crashed with IPSEC and ALTQ disabled, crashdump looks different this time though. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffff80400bc58038 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a41ae stack pointer = 0x28:0xffffff80000e69a0 frame pointer = 0x28:0xffffff80000e69b0 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 = 0 (em1 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 23h30m3s Physical memory: 4079 MB Dumping 1907 MB: 1892 1876em1: Watchdog timeout -- resetting 1860 1844 1828 1812 1796 1780 1764 1748 1732 1716 1700 1684 1668 1652 1636 1620 1604 1588 1572 1556 1540 1524 1508 1492 1476 1460 1444 1428 1412 1396 1380 1364 1348 1332 1316 1300 1284 1268 1252 1236 1220 1204 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/kernel/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:224 224 __asm("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff808a41ae 0xffffffff808a41ae is in pmap_kextract (/usr/src/sys/amd64/amd64/pmap.c:1172). 1167 vm_paddr_t pa; 1168 1169 if (va >= DMAP_MIN_ADDRESS && va < DMAP_MAX_ADDRESS) { 1170 pa = DMAP_TO_PHYS(va); 1171 } else { 1172 pde = *vtopde(va); 1173 if (pde & PG_PS) { 1174 pa = (pde & PG_PS_FRAME) | (va & PDRMASK); 1175 } else { 1176 /* (kgdb) backtrace #0 doadump () at pcpu.h:224 #1 0xffffffff805b2b5e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805b2f6c in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xffffffff808ac70d in trap_fatal (frame=0xffffffff80c5cc60, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:777 #4 0xffffffff808acacf in trap_pfault (frame=0xffffff80000e68f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:693 #5 0xffffffff808ad2e2 in trap (frame=0xffffff80000e68f0) at /usr/src/sys/amd64/amd64/trap.c:451 #6 0xffffffff808923b4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #7 0xffffffff808a41ae in pmap_kextract (va=51771551252551) at /usr/src/sys/amd64/amd64/pmap.c:1172 #8 0xffffffff80890f83 in bus_dmamap_load_mbuf_sg (dmat=0xffffff0002727c00, map=0xffffffff80c99d40, m0=Variable "m0" is not available. ) at /usr/src/sys/amd64/amd64/busdma_machdep.c:659 #9 0xffffffff8032f8fc in em_refresh_mbufs (rxr=0xffffff0002712600, limit=975) at /usr/src/sys/dev/e1000/if_em.c:3691 #10 0xffffffff8032ff3c in em_rxeof (rxr=0xffffff0002712600, count=100, done=0x0) at /usr/src/sys/dev/e1000/if_em.c:4210 #11 0xffffffff80330788 in em_handle_que (context=Variable "context" is not available. ) at /usr/src/sys/dev/e1000/if_em.c:1451 #12 0xffffffff805efc94 in taskqueue_run (queue=0xffffff0002727b80) at /usr/src/sys/kern/subr_taskqueue.c:239 #13 0xffffffff805eff06 in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/subr_taskqueue.c:360 #14 0xffffffff80589998 in fork_exit ( callout=0xffffffff805efec0 , arg=0xffffff80003c2740, frame=0xffffff80000e6c80) at /usr/src/sys/kern/kern_fork.c:844 #15 0xffffffff8089288e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:566 #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x000000000109b000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0xffffffff80c823e0 in sleepq_chains () #44 0xffffff00025087c0 in ?? () #45 0xffffff80000e6b20 in ?? () #46 0xffffff80000e6ad8 in ?? () #47 0xffffff000267f7c0 in ?? () #48 0xffffffff805d6a8a in sched_switch (td=0xffffff80003c2740, newtd=0xffffffff805efec0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1844 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-stable@FreeBSD.ORG Sat Aug 28 20:35:59 2010 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 10F6110656A6; Sat, 28 Aug 2010 20:35:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1D63F8FC15; Sat, 28 Aug 2010 20:35:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA09840; Sat, 28 Aug 2010 23:28:49 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OpS1B-0007yq-Cw; Sat, 28 Aug 2010 23:28:49 +0300 Message-ID: <4C797180.5000905@freebsd.org> Date: Sat, 28 Aug 2010 23:28:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim , freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> <4C797023.8020206@freebsd.org> In-Reply-To: <4C797023.8020206@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pluknet Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Aug 2010 20:35:59 -0000 Oops, the patch had a small mistake. I've put it here now, just in case I'll want to fix/cleanup anything else: http://people.freebsd.org/~avg/intel-cpu-topo.diff on 28/08/2010 23:22 Andriy Gapon said the following: > So, here is my take on the problem. > The attached patch is against sources in FreeBSD tree, it should be applied > either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending > on the desired architecture. > > The patch is substantially based on the Junk-uk's patch, but with some changes > and additions: > - topo_probo_0x4() is rewritten so that it does APIC ID matching against masks > as described in the Intel article. The code still heavily depends on the > assumption of the uniform topology, it discovers number of cores in BSP package > and number of threads in BSP core and extrapolates that to global topology. > The difference with current code and Junk-uk's patch is that actual APIC ID > matching is done as opposed to deriving counts purely from max. values. > > - added a few comments that describe uniformity assumption, plus couple other > useful things. > > - changed "final fallback" code, so that each logical CPU is considered to be in > its own physical package as opposed to current code placing all logical CPUs as > cores of a single package. > > The rest is Junk-uk's work. > > Concerns: > - about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a > better name or re-arranging/writing that code, so that the function is not needed. > - about current code: logical_cpus variable (don't confuse with cpu_logical) > doesn't seem to be consistently used; e.g. it is not set at all by > topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask > doesn't seem to be reliable - BSP may be missed. > > Reviews, comments and test reports are very welcome! > Please test the patch if you have any problems with how CPU topology is reported > by the current code. Please test even if everything is OK, to avoid regressions. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Aug 28 20:36:00 2010 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 D7FE41065698; Sat, 28 Aug 2010 20:36:00 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DC1298FC17; Sat, 28 Aug 2010 20:35:59 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA09802; Sat, 28 Aug 2010 23:23:00 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OpRvY-0007yY-A3; Sat, 28 Aug 2010 23:23:00 +0300 Message-ID: <4C797023.8020206@freebsd.org> Date: Sat, 28 Aug 2010 23:22:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jung-uk Kim , freebsd-stable@freebsd.org References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C782D3B.6020407@icyb.net.ua> <201008271743.29393.jkim@FreeBSD.org> <4C7835E6.6070309@icyb.net.ua> In-Reply-To: <4C7835E6.6070309@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------000301090401000705080907" Cc: pluknet Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Aug 2010 20:36:01 -0000 This is a multi-part message in MIME format. --------------000301090401000705080907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 28/08/2010 01:02 Andriy Gapon said the following: > BTW, it may be not that hard. > It seems that 0x4 topology building involves knowing the masks and we already > have that data (just interpreted differently), and APIC IDs of the CPUs and it > seems that we also have that. We don't need to bind to CPUs to learn their IDs, > we can just iterate over cpu_apic_ids[]. > > The only problem is that currently topo_probe() is called before > assign_cpu_ids() which populates cpu_apic_ids. > assign_cpu_ids depends on topo_probe to know hyperthreading_cpus value. > So, either cpu_apic_ids could be split out or alternatively we could use > cpu_info[] similarly to how it's done in topo_probe_0xb (skipping !cpu_present > and cpu_disabled entries). So, here is my take on the problem. The attached patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture. The patch is substantially based on the Junk-uk's patch, but with some changes and additions: - topo_probo_0x4() is rewritten so that it does APIC ID matching against masks as described in the Intel article. The code still heavily depends on the assumption of the uniform topology, it discovers number of cores in BSP package and number of threads in BSP core and extrapolates that to global topology. The difference with current code and Junk-uk's patch is that actual APIC ID matching is done as opposed to deriving counts purely from max. values. - added a few comments that describe uniformity assumption, plus couple other useful things. - changed "final fallback" code, so that each logical CPU is considered to be in its own physical package as opposed to current code placing all logical CPUs as cores of a single package. The rest is Junk-uk's work. Concerns: - about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a better name or re-arranging/writing that code, so that the function is not needed. - about current code: logical_cpus variable (don't confuse with cpu_logical) doesn't seem to be consistently used; e.g. it is not set at all by topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask doesn't seem to be reliable - BSP may be missed. Reviews, comments and test reports are very welcome! Please test the patch if you have any problems with how CPU topology is reported by the current code. Please test even if everything is OK, to avoid regressions. Thanks! -- Andriy Gapon --------------000301090401000705080907 Content-Type: text/plain; name="intel-cpu-topo.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intel-cpu-topo.diff" diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index e2f82ec..47a5c0b 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -177,24 +177,101 @@ mem_range_AP_init(void) } static void +topo_probe_amd(void) +{ + + /* AMD processors do not support HTT. */ + cpu_cores = (amd_feature2 & AMDID2_CMP) != 0 ? + (cpu_procinfo2 & AMDID_CMP_CORES) + 1 : 1; + cpu_logical = 1; +} + +/* + * Round up to the next power of two, if necessary, and then + * take log2. + */ +static __inline int +ilog2_round_pow2(u_int x) +{ + + return fls(x << (1 - powerof2(x))); +} + +static void +topo_probe_0x4(void) +{ + u_int p[4]; + int core_id_bits; + int smt_id_bits; + int max_cores; + int max_logical; + int id; + + max_logical = (cpu_feature & CPUID_HTT) != 0 ? + (cpu_procinfo & CPUID_HTT_CORES) >> 16 : 1; + if (max_logical == 1) + return; + + /* + * Because of uniformity assumption we examine only + * those logical processors that belong to the same + * package as BSP. Further, we count number of + * logical processors that belong to the same core + * as BSP thus deducing number of threads per core. + */ + cpuid_count(0x04, 0, p); + max_cores = ((p[0] >> 26) & 0x3f) + 1; + smt_id_bits = ilog2_round_pow2(max_logical/max_cores) - 1; + if (smt_id_bits < 0) + return; + core_id_bits = smt_id_bits + fls(max_cores) - 1; + + for (id = 0; id <= MAX_APIC_ID; id++) { + if (!cpu_info[id].cpu_present || cpu_info[id].cpu_disabled) + continue; + if ((id >> core_id_bits) != (boot_cpu_id >> core_id_bits)) + continue; + cpu_cores++; + if ((id >> smt_id_bits) == (boot_cpu_id >> smt_id_bits)) + cpu_logical++; + } + + cpu_cores /= cpu_logical; + if (cpu_logical > 1) + hyperthreading_cpus = logical_cpus = cpu_logical; +} + +static void topo_probe_0xb(void) { - int logical; - int p[4]; + u_int p[4]; int bits; - int type; int cnt; int i; + int logical; + int type; int x; - /* We only support two levels for now. */ + /* We only support three levels for now. */ for (i = 0; i < 3; i++) { - cpuid_count(0x0B, i, p); + cpuid_count(0x0b, i, p); + + /* Fall back if CPU leaf 11 doesn't really exist. */ + if (i == 0 && p[1] == 0) { + topo_probe_0x4(); + return; + } + bits = p[0] & 0x1f; logical = p[1] &= 0xffff; type = (p[2] >> 8) & 0xff; if (type == 0 || logical == 0) break; + /* + * Because of uniformity assumption we examine only + * those logical processors that belong to the same + * package as BSP. + */ for (cnt = 0, x = 0; x <= MAX_APIC_ID; x++) { if (!cpu_info[x].cpu_present || cpu_info[x].cpu_disabled) @@ -212,76 +289,16 @@ topo_probe_0xb(void) cpu_cores /= cpu_logical; } -static void -topo_probe_0x4(void) -{ - u_int threads_per_cache, p[4]; - u_int htt, cmp; - int i; - - htt = cmp = 1; - /* - * If this CPU supports HTT or CMP then mention the - * number of physical/logical cores it contains. - */ - if (cpu_feature & CPUID_HTT) - htt = (cpu_procinfo & CPUID_HTT_CORES) >> 16; - if (cpu_vendor_id == CPU_VENDOR_AMD && (amd_feature2 & AMDID2_CMP)) - cmp = (cpu_procinfo2 & AMDID_CMP_CORES) + 1; - else if (cpu_vendor_id == CPU_VENDOR_INTEL && (cpu_high >= 4)) { - cpuid_count(4, 0, p); - if ((p[0] & 0x1f) != 0) - cmp = ((p[0] >> 26) & 0x3f) + 1; - } - cpu_cores = cmp; - cpu_logical = htt / cmp; - - /* Setup the initial logical CPUs info. */ - if (cpu_feature & CPUID_HTT) - logical_cpus = (cpu_procinfo & CPUID_HTT_CORES) >> 16; - - /* - * Work out if hyperthreading is *really* enabled. This - * is made really ugly by the fact that processors lie: Dual - * core processors claim to be hyperthreaded even when they're - * not, presumably because they want to be treated the same - * way as HTT with respect to per-cpu software licensing. - * At the time of writing (May 12, 2005) the only hyperthreaded - * cpus are from Intel, and Intel's dual-core processors can be - * identified via the "deterministic cache parameters" cpuid - * calls. - */ - /* - * First determine if this is an Intel processor which claims - * to have hyperthreading support. - */ - if ((cpu_feature & CPUID_HTT) && cpu_vendor_id == CPU_VENDOR_INTEL) { - /* - * If the "deterministic cache parameters" cpuid calls - * are available, use them. - */ - if (cpu_high >= 4) { - /* Ask the processor about the L1 cache. */ - for (i = 0; i < 1; i++) { - cpuid_count(4, i, p); - threads_per_cache = ((p[0] & 0x3ffc000) >> 14) + 1; - if (hyperthreading_cpus < threads_per_cache) - hyperthreading_cpus = threads_per_cache; - if ((p[0] & 0x1f) == 0) - break; - } - } - - /* - * If the deterministic cache parameters are not - * available, or if no caches were reported to exist, - * just accept what the HTT flag indicated. - */ - if (hyperthreading_cpus == 0) - hyperthreading_cpus = logical_cpus; - } -} - +/* + * Both topology discovery code and code that consumes topology + * information assume top-down uniformity of the topology. + * That is, all physical packages must be identical and each + * core in a package must have the same number of threads. + * Topology information is queried only on BSP, on which this + * code runs and for which it can query CPUID information. + * Then topology is extrapolated on all packages using the + * uniformity assumption. + */ static void topo_probe(void) { @@ -291,12 +308,26 @@ topo_probe(void) return; logical_cpus = logical_cpus_mask = 0; - if (cpu_high >= 0xb) - topo_probe_0xb(); - else if (cpu_high) - topo_probe_0x4(); + if (cpu_vendor_id == CPU_VENDOR_AMD) + topo_probe_amd(); + else if (cpu_vendor_id == CPU_VENDOR_INTEL) { + /* + * See Intel(R) 64 Architecture Processor + * Topology Enumeration article for details. + */ + if (cpu_high >= 0xb) + topo_probe_0xb(); + else if (cpu_high >= 0x4) + topo_probe_0x4(); + } + + /* + * Fallback: assume each logical CPU is in separate + * physical package. That is, no multi-core, + * no SMT. + */ if (cpu_cores == 0) - cpu_cores = mp_ncpus > 0 ? mp_ncpus : 1; + cpu_cores = 1; if (cpu_logical == 0) cpu_logical = 1; cpu_topo_probed = 1; --------------000301090401000705080907-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 28 20:36:03 2010 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 DFA061065695 for ; Sat, 28 Aug 2010 20:36:03 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id B76728FC18 for ; Sat, 28 Aug 2010 20:36:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 0EBF350BA0 for ; Sat, 28 Aug 2010 21:36:03 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPyeWIm4X9Io for ; Sat, 28 Aug 2010 21:36:02 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 436F050B9A for ; Sat, 28 Aug 2010 21:36:02 +0100 (BST) Message-ID: <4C79732E.2010606@langille.org> Date: Sat, 28 Aug 2010 16:35:58 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ACPI Warning: Optional field Pm2ControlBlock has zero address X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Aug 2010 20:36:04 -0000 This this something to be concerned about: ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20100331/tbfadt-655) -- Dan Langille - http://langille.org/