From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 15:37:38 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE738BF0; Sun, 24 Nov 2013 15:37:37 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A3A62618; Sun, 24 Nov 2013 15:37:35 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id rAOF9OQB007833; Sun, 24 Nov 2013 17:09:24 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id rAOF9ODC007741; Sun, 24 Nov 2013 15:09:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Nov 2013 15:09:24 GMT Message-Id: <201311241509.rAOF9ODC007741@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 15:37:38 -0000 TB --- 2013-11-24 10:20:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-24 10:20:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-24 10:20:42 - starting RELENG_10 tinderbox run for arm/arm TB --- 2013-11-24 10:20:42 - cleaning the object tree TB --- 2013-11-24 10:20:42 - /usr/local/bin/svn stat /src TB --- 2013-11-24 10:21:31 - At svn revision 258523 TB --- 2013-11-24 10:21:32 - building world TB --- 2013-11-24 10:21:32 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 10:21:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 10:21:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 10:21:32 - SRCCONF=/dev/null TB --- 2013-11-24 10:21:32 - TARGET=arm TB --- 2013-11-24 10:21:32 - TARGET_ARCH=arm TB --- 2013-11-24 10:21:32 - TZ=UTC TB --- 2013-11-24 10:21:32 - __MAKE_CONF=/dev/null TB --- 2013-11-24 10:21:32 - cd /src TB --- 2013-11-24 10:21:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Nov 24 10:21:42 UTC 2013 >>> 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 Nov 24 13:49:55 UTC 2013 TB --- 2013-11-24 13:49:55 - generating LINT kernel config TB --- 2013-11-24 13:49:55 - cd /src/sys/arm/conf TB --- 2013-11-24 13:49:55 - /usr/bin/make -B LINT TB --- 2013-11-24 13:49:55 - cd /src/sys/arm/conf TB --- 2013-11-24 13:49:55 - /usr/sbin/config -m LINT TB --- 2013-11-24 13:49:55 - building LINT kernel TB --- 2013-11-24 13:49:55 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 13:49:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 13:49:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 13:49:55 - SRCCONF=/dev/null TB --- 2013-11-24 13:49:55 - TARGET=arm TB --- 2013-11-24 13:49:55 - TARGET_ARCH=arm TB --- 2013-11-24 13:49:55 - TZ=UTC TB --- 2013-11-24 13:49:55 - __MAKE_CONF=/dev/null TB --- 2013-11-24 13:49:55 - cd /src TB --- 2013-11-24 13:49:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Nov 24 13:49:55 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Nov 24 14:15:43 UTC 2013 TB --- 2013-11-24 14:15:43 - cd /src/sys/arm/conf TB --- 2013-11-24 14:15:43 - /usr/sbin/config -m AC100 TB --- 2013-11-24 14:15:43 - skipping AC100 kernel TB --- 2013-11-24 14:15:43 - cd /src/sys/arm/conf TB --- 2013-11-24 14:15:43 - /usr/sbin/config -m ARMADAXP TB --- 2013-11-24 14:15:43 - skipping ARMADAXP kernel TB --- 2013-11-24 14:15:43 - cd /src/sys/arm/conf TB --- 2013-11-24 14:15:43 - /usr/sbin/config -m ARNDALE TB --- 2013-11-24 14:15:43 - skipping ARNDALE kernel TB --- 2013-11-24 14:15:43 - cd /src/sys/arm/conf TB --- 2013-11-24 14:15:43 - /usr/sbin/config -m ATMEL TB --- 2013-11-24 14:15:43 - building ATMEL kernel TB --- 2013-11-24 14:15:43 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:15:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:15:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:15:43 - SRCCONF=/dev/null TB --- 2013-11-24 14:15:43 - TARGET=arm TB --- 2013-11-24 14:15:43 - TARGET_ARCH=arm TB --- 2013-11-24 14:15:43 - TZ=UTC TB --- 2013-11-24 14:15:43 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:15:43 - cd /src TB --- 2013-11-24 14:15:43 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sun Nov 24 14:15:43 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sun Nov 24 14:19:49 UTC 2013 TB --- 2013-11-24 14:19:49 - cd /src/sys/arm/conf TB --- 2013-11-24 14:19:49 - /usr/sbin/config -m AVILA TB --- 2013-11-24 14:19:49 - skipping AVILA kernel TB --- 2013-11-24 14:19:49 - cd /src/sys/arm/conf TB --- 2013-11-24 14:19:49 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-11-24 14:19:49 - skipping BEAGLEBONE kernel TB --- 2013-11-24 14:19:49 - cd /src/sys/arm/conf TB --- 2013-11-24 14:19:49 - /usr/sbin/config -m BWCT TB --- 2013-11-24 14:19:49 - building BWCT kernel TB --- 2013-11-24 14:19:49 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:19:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:19:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:19:49 - SRCCONF=/dev/null TB --- 2013-11-24 14:19:49 - TARGET=arm TB --- 2013-11-24 14:19:49 - TARGET_ARCH=arm TB --- 2013-11-24 14:19:49 - TZ=UTC TB --- 2013-11-24 14:19:49 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:19:49 - cd /src TB --- 2013-11-24 14:19:49 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sun Nov 24 14:19:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Sun Nov 24 14:22:34 UTC 2013 TB --- 2013-11-24 14:22:34 - cd /src/sys/arm/conf TB --- 2013-11-24 14:22:34 - /usr/sbin/config -m CAMBRIA TB --- 2013-11-24 14:22:34 - skipping CAMBRIA kernel TB --- 2013-11-24 14:22:34 - cd /src/sys/arm/conf TB --- 2013-11-24 14:22:34 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-11-24 14:22:34 - building CNS11XXNAS kernel TB --- 2013-11-24 14:22:34 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:22:34 - SRCCONF=/dev/null TB --- 2013-11-24 14:22:34 - TARGET=arm TB --- 2013-11-24 14:22:34 - TARGET_ARCH=arm TB --- 2013-11-24 14:22:34 - TZ=UTC TB --- 2013-11-24 14:22:34 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:22:34 - cd /src TB --- 2013-11-24 14:22:34 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sun Nov 24 14:22:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Sun Nov 24 14:26:30 UTC 2013 TB --- 2013-11-24 14:26:30 - cd /src/sys/arm/conf TB --- 2013-11-24 14:26:30 - /usr/sbin/config -m CRB TB --- 2013-11-24 14:26:30 - skipping CRB kernel TB --- 2013-11-24 14:26:30 - cd /src/sys/arm/conf TB --- 2013-11-24 14:26:30 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-11-24 14:26:30 - skipping CUBIEBOARD kernel TB --- 2013-11-24 14:26:30 - cd /src/sys/arm/conf TB --- 2013-11-24 14:26:30 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-11-24 14:26:30 - skipping CUBIEBOARD2 kernel TB --- 2013-11-24 14:26:30 - cd /src/sys/arm/conf TB --- 2013-11-24 14:26:30 - /usr/sbin/config -m DB-78XXX TB --- 2013-11-24 14:26:30 - building DB-78XXX kernel TB --- 2013-11-24 14:26:30 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:26:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:26:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:26:30 - SRCCONF=/dev/null TB --- 2013-11-24 14:26:30 - TARGET=arm TB --- 2013-11-24 14:26:30 - TARGET_ARCH=arm TB --- 2013-11-24 14:26:30 - TZ=UTC TB --- 2013-11-24 14:26:30 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:26:30 - cd /src TB --- 2013-11-24 14:26:30 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sun Nov 24 14:26:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Sun Nov 24 14:30:00 UTC 2013 TB --- 2013-11-24 14:30:00 - cd /src/sys/arm/conf TB --- 2013-11-24 14:30:00 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-11-24 14:30:00 - building DB-88F5XXX kernel TB --- 2013-11-24 14:30:00 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:30:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:30:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:30:00 - SRCCONF=/dev/null TB --- 2013-11-24 14:30:00 - TARGET=arm TB --- 2013-11-24 14:30:00 - TARGET_ARCH=arm TB --- 2013-11-24 14:30:00 - TZ=UTC TB --- 2013-11-24 14:30:00 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:30:00 - cd /src TB --- 2013-11-24 14:30:00 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sun Nov 24 14:30:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Sun Nov 24 14:33:20 UTC 2013 TB --- 2013-11-24 14:33:20 - cd /src/sys/arm/conf TB --- 2013-11-24 14:33:20 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-11-24 14:33:20 - building DB-88F6XXX kernel TB --- 2013-11-24 14:33:20 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:33:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:33:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:33:20 - SRCCONF=/dev/null TB --- 2013-11-24 14:33:20 - TARGET=arm TB --- 2013-11-24 14:33:20 - TARGET_ARCH=arm TB --- 2013-11-24 14:33:20 - TZ=UTC TB --- 2013-11-24 14:33:20 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:33:20 - cd /src TB --- 2013-11-24 14:33:20 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sun Nov 24 14:33:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Sun Nov 24 14:36:52 UTC 2013 TB --- 2013-11-24 14:36:52 - cd /src/sys/arm/conf TB --- 2013-11-24 14:36:52 - /usr/sbin/config -m DIGI-CCWMX53 TB --- 2013-11-24 14:36:52 - skipping DIGI-CCWMX53 kernel TB --- 2013-11-24 14:36:52 - cd /src/sys/arm/conf TB --- 2013-11-24 14:36:52 - /usr/sbin/config -m DOCKSTAR TB --- 2013-11-24 14:36:52 - building DOCKSTAR kernel TB --- 2013-11-24 14:36:52 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:36:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:36:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:36:52 - SRCCONF=/dev/null TB --- 2013-11-24 14:36:52 - TARGET=arm TB --- 2013-11-24 14:36:52 - TARGET_ARCH=arm TB --- 2013-11-24 14:36:52 - TZ=UTC TB --- 2013-11-24 14:36:52 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:36:52 - cd /src TB --- 2013-11-24 14:36:52 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sun Nov 24 14:36:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Sun Nov 24 14:40:02 UTC 2013 TB --- 2013-11-24 14:40:02 - cd /src/sys/arm/conf TB --- 2013-11-24 14:40:02 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-11-24 14:40:02 - building DREAMPLUG-1001 kernel TB --- 2013-11-24 14:40:02 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:40:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:40:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:40:02 - SRCCONF=/dev/null TB --- 2013-11-24 14:40:02 - TARGET=arm TB --- 2013-11-24 14:40:02 - TARGET_ARCH=arm TB --- 2013-11-24 14:40:02 - TZ=UTC TB --- 2013-11-24 14:40:02 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:40:02 - cd /src TB --- 2013-11-24 14:40:02 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sun Nov 24 14:40:02 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DREAMPLUG-1001 completed on Sun Nov 24 14:46:09 UTC 2013 TB --- 2013-11-24 14:46:09 - cd /src/sys/arm/conf TB --- 2013-11-24 14:46:09 - /usr/sbin/config -m EA3250 TB --- 2013-11-24 14:46:09 - building EA3250 kernel TB --- 2013-11-24 14:46:09 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:46:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:46:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:46:09 - SRCCONF=/dev/null TB --- 2013-11-24 14:46:09 - TARGET=arm TB --- 2013-11-24 14:46:09 - TARGET_ARCH=arm TB --- 2013-11-24 14:46:09 - TZ=UTC TB --- 2013-11-24 14:46:09 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:46:09 - cd /src TB --- 2013-11-24 14:46:09 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sun Nov 24 14:46:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Sun Nov 24 14:49:45 UTC 2013 TB --- 2013-11-24 14:49:45 - cd /src/sys/arm/conf TB --- 2013-11-24 14:49:45 - /usr/sbin/config -m EB9200 TB --- 2013-11-24 14:49:45 - building EB9200 kernel TB --- 2013-11-24 14:49:45 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:49:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:49:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:49:45 - SRCCONF=/dev/null TB --- 2013-11-24 14:49:45 - TARGET=arm TB --- 2013-11-24 14:49:45 - TARGET_ARCH=arm TB --- 2013-11-24 14:49:45 - TZ=UTC TB --- 2013-11-24 14:49:45 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:49:45 - cd /src TB --- 2013-11-24 14:49:45 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sun Nov 24 14:49:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Sun Nov 24 14:53:37 UTC 2013 TB --- 2013-11-24 14:53:37 - cd /src/sys/arm/conf TB --- 2013-11-24 14:53:37 - /usr/sbin/config -m EFIKA_MX TB --- 2013-11-24 14:53:37 - skipping EFIKA_MX kernel TB --- 2013-11-24 14:53:37 - cd /src/sys/arm/conf TB --- 2013-11-24 14:53:37 - /usr/sbin/config -m EP80219 TB --- 2013-11-24 14:53:38 - skipping EP80219 kernel TB --- 2013-11-24 14:53:38 - cd /src/sys/arm/conf TB --- 2013-11-24 14:53:38 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-11-24 14:53:38 - building ETHERNUT5 kernel TB --- 2013-11-24 14:53:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 14:53:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 14:53:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 14:53:38 - SRCCONF=/dev/null TB --- 2013-11-24 14:53:38 - TARGET=arm TB --- 2013-11-24 14:53:38 - TARGET_ARCH=arm TB --- 2013-11-24 14:53:38 - TZ=UTC TB --- 2013-11-24 14:53:38 - __MAKE_CONF=/dev/null TB --- 2013-11-24 14:53:38 - cd /src TB --- 2013-11-24 14:53:38 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sun Nov 24 14:53:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ETHERNUT5 completed on Sun Nov 24 15:05:42 UTC 2013 TB --- 2013-11-24 15:05:42 - cd /src/sys/arm/conf TB --- 2013-11-24 15:05:42 - /usr/sbin/config -m GUMSTIX TB --- 2013-11-24 15:05:42 - building GUMSTIX kernel TB --- 2013-11-24 15:05:42 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 15:05:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 15:05:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 15:05:42 - SRCCONF=/dev/null TB --- 2013-11-24 15:05:42 - TARGET=arm TB --- 2013-11-24 15:05:42 - TARGET_ARCH=arm TB --- 2013-11-24 15:05:42 - TZ=UTC TB --- 2013-11-24 15:05:42 - __MAKE_CONF=/dev/null TB --- 2013-11-24 15:05:42 - cd /src TB --- 2013-11-24 15:05:42 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Sun Nov 24 15:05:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GUMSTIX completed on Sun Nov 24 15:09:20 UTC 2013 TB --- 2013-11-24 15:09:20 - cd /src/sys/arm/conf TB --- 2013-11-24 15:09:20 - /usr/sbin/config -m GUMSTIX-QEMU TB --- 2013-11-24 15:09:20 - building GUMSTIX-QEMU kernel TB --- 2013-11-24 15:09:20 - CROSS_BUILD_TESTING=YES TB --- 2013-11-24 15:09:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-24 15:09:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-24 15:09:20 - SRCCONF=/dev/null TB --- 2013-11-24 15:09:20 - TARGET=arm TB --- 2013-11-24 15:09:20 - TARGET_ARCH=arm TB --- 2013-11-24 15:09:20 - TZ=UTC TB --- 2013-11-24 15:09:20 - __MAKE_CONF=/dev/null TB --- 2013-11-24 15:09:20 - cd /src TB --- 2013-11-24 15:09:20 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX-QEMU >>> Kernel build for GUMSTIX-QEMU started on Sun Nov 24 15:09:20 UTC 2013 >>> 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 [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/arm.arm/src/sys/GUMSTIX-QEMU/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-11-24 15:09:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-24 15:09:23 - ERROR: failed to build GUMSTIX-QEMU kernel TB --- 2013-11-24 15:09:23 - 12606.80 user 4624.24 system 17320.85 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 15:43:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 600C7DB4; Sun, 24 Nov 2013 15:43:23 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCB32267C; Sun, 24 Nov 2013 15:43:22 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id n12so1850662wgh.14 for ; Sun, 24 Nov 2013 07:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ce1rm9lEZ8IiSIg+MfBASYXQY2V87SpHFLCEGFqIBqM=; b=Ji6FrspQk7GgBlwzvJJ3nYH1bsdVhiLvJtR92mA/IKNG5Jhx02e+trBlEJ2EjW+IYl s3fSWQSCA3f7tZuwvMI6TBJR+IkV81o49qyOudnEVGcsra0u28mMycKSMlIgjzez7gMR cXz/nnRGZOygtq63IvkECdao7r5EDQH9e693Y+8jkHSioEFnBURFn+AFW8rleq6jkcA3 OxUWFG9CFjcH23kHjGesSfspuwxfTIqYXAhALgMuPUwaMQtBjQ1SwlDvzuBzs5gmhKZP Xw1Yy/vO+BM64mYq38xE0IUxGnuhUiUnrmH5JwXkWGALtA3bZgnifmSt7C2K11OIVffU 1uIw== MIME-Version: 1.0 X-Received: by 10.180.103.233 with SMTP id fz9mr10340533wib.20.1385307801283; Sun, 24 Nov 2013 07:43:21 -0800 (PST) Received: by 10.216.119.200 with HTTP; Sun, 24 Nov 2013 07:43:21 -0800 (PST) In-Reply-To: <52911993.8010108@ipfw.ru> References: <52911993.8010108@ipfw.ru> Date: Sun, 24 Nov 2013 17:43:21 +0200 Message-ID: Subject: Re: ipfw table add problem From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-ipfw , freebsd-stable , Luigi Rizzo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 24 Nov 2013 15:43:23 -0000 Hi, I tested patch. This patch solves, ipfw table 1 add 4899 But, ipfw table 1 add 10.2.3.01 works incorrectly. output is below. # ./ipfw table 1 flush # ./ipfw table 1 add 10.2.3.01 # ./ipfw table 1 list 0.0.0.10/32 0 On Sat, Nov 23, 2013 at 11:09 PM, Alexander V. Chernikov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 19.11.2013 23:55, =EF=BF=96zkan KIRIK wrote: > > Hi, > > > > I'm using kernel FreeBSD 10.0-BETA3 #2 r257635 kernel. I am trying > > to add port number to ipfw tables. But there is something strange > > : Problem is easily repeatable. > > > > #ipfw table 1 flush #ipfw table 1 add 4899 #ipfw table 1 list ::/0 > > 0 > > > > #ipfw table 1 flush #ipfw table 1 add 10.2.3.01 ( not > > 10.0.0.1, the last 1 has 0 as prefix ) #ipfw table 1 list ::/0 0 > > > > #ipfw table 1 delete ::/0 ipfw: setsockopt(IP_FW_TABLE_XDEL): No > > such process > > > > > > I guess that, this problem is related to radix mask calculation > > problem/fix. > Hello. > I'm sorry, it seems that key lookups were broken for quite a long time. > > Can you apply attached patch, rebuild ipfw(8) binary and see if this > helps? > > > > > > Is there a quick solution for this. Best, regards, > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To > > unsubscribe, send any mail to > > "freebsd-ipfw-unsubscribe@freebsd.org" > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (FreeBSD) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlKRGZIACgkQwcJ4iSZ1q2n0hgCgkiqRewC61LptUaG4ejvHIg0q > PawAoID3nfNxh3sTOVE/iKNtfjHpl9u0 > =3D6GdO > -----END PGP SIGNATURE----- > From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 16:37:28 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5065FD86; Sun, 24 Nov 2013 16:37:28 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB17A28A8; Sun, 24 Nov 2013 16:37:27 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006814025.msg; Sun, 24 Nov 2013 16:37:24 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 24 Nov 2013 16:37:24 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=10402a06b3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andriy Gapon" , References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <9A58D6B0691A4C1294883AD91F9D4743@multiplay.co.uk> <5289D2FB.1010600@FreeBSD.org> <705640231AF04A91B66B0654D2531EC9@multiplay.co.uk> <5289DF99.9080101@FreeBSD.org> Subject: Re: Help with filing a [maybe] ZFS/mmap bug. Date: Sun, 24 Nov 2013 16:37:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 24 Nov 2013 16:37:28 -0000 ----- Original Message ----- From: "Andriy Gapon" >>>> ----- Original Message ----- From: "Andriy Gapon" >>>>> - vm_page_clear_dirty(pp, off, nbytes); >>>>> + if (nbytes != 0) >>>>> + vm_page_clear_dirty(pp, off, nbytes); >>>>> } >>>>> break; >>>> >>>> Thanks Andriy, looking to test this here but 8.3 doesn't have a page_busy >>>> method in zfs_vnops.c so I'm not sure how to proceed on this? >>> >>> Does it have vm_page_clear_dirty call? >> >> Nope. >> > > Then you do not have this bug. It's possible that you might have a different > bug, though. Perhaps merge the relevant change from stable/8 and then apply the > patch?.. Backported the r248946 & 248960 then applied this fix and we've not seen any rrd corruption since :) Thanks for working on this! Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 16:23:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99BB5C39 for ; Sun, 24 Nov 2013 16:23:10 +0000 (UTC) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [IPv6:2a02:6b8:0:801::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 115EE2846 for ; Sun, 24 Nov 2013 16:23:10 +0000 (UTC) Received: from web17j.yandex.ru (web17j.yandex.ru [5.45.198.58]) by forward13.mail.yandex.net (Yandex) with ESMTP id 61CEC1413AC for ; Sun, 24 Nov 2013 20:22:59 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web17j.yandex.ru (Yandex) with ESMTP id 1853D64E0078; Sun, 24 Nov 2013 20:22:59 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1385310179; bh=FxB11N3ythjAcEFU3PjcR3OJdWkqyDOSd1ZBc4zbclk=; h=From:To:Subject:Date; b=DKL57IBxJoTHQg5jhbVF7Dt5fQ8CCuTnOqy/cl2+UCr+UpQd6bJmyqZD4dTFi55Pl utA7j7VgOiDdkr7M7Qmx/+41XxxpnVQVya+RIfnfSbu2YCwEfG1Qg8AXMejqNy/siX zwNJ3ax1wrgtTRGtlhu39MX7s2UGfVr0TvCsqetQ= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web17j.yandex.ru with HTTP; Sun, 24 Nov 2013 20:22:58 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: freebsd-stable@freebsd.org Subject: Error in lib/libroken when buildowrld 10-BETA3 MIME-Version: 1.0 Message-Id: <29371385310178@web17j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 24 Nov 2013 22:22:58 +0600 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-Mailman-Approved-At: Sun, 24 Nov 2013 16:39:37 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 24 Nov 2013 16:23:10 -0000 Hi All! I have a problem when tryin to update from 9.2-BETA2 FreeBSD 9.2-BETA2 #0: Thu Aug 8 11:51:18 amd64 to latest 10-STABLE What can cause problem? make buildworld ============================================================================= cc -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -mtune=athlon64 -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libroken/../../include -DNDEBUG -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c -o unvis.o cc -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -mtune=athlon64 -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libroken/../../include -DNDEBUG -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c -o verify.o cc -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -mtune=athlon64 -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libroken/../../include -DNDEBUG -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c -o vis.o /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c: In function 'rk_svis': /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c:264: error: 'VIS_HTTPSTYLE' undeclared (first use in this function) /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c:264: error: (Each undeclared identifier is reported only once /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c:264: error: for each function it appears in.) /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c: In function 'rk_strsvis': /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c:306: error: 'VIS_HTTPSTYLE' undeclared (first use in this function) /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c: In function 'rk_strsvisx': /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c:336: error: 'VIS_HTTPSTYLE' undeclared (first use in this function) *** Error code 1 Stop. bmake[2]: stopped in /usr/src/kerberos5/lib/libroken *** Error code 1 Stop. bmake[1]: stopped in /usr/src *** Error code 1 Stop. bmake: stopped in /usr/src *** [buildworld] Error code 1 Stop in /usr/src. make.conf ============================================================================= CPUTYPE?=athlon64 CFLAGS=-O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -mtune=athlon64 COPTFLAGS=-O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -mtune=athlon64 TARGET_ARCH=amd64 KERNCONF=MY.RU NO_WERROR=yes WERROR=-Wno-error NO_INET6=true NO_GAMES=true NO_I4B=true MAKE_JOBS_NUMBER=5 WITH_PKGNG=yes FORCE_PKG_REGISTER=YES NO_SUID_XSERVER=YES LOCALIZED_LANG=ru WITH_NEW_XORG=yes WITH_GNUSTEP_DEVEL=yes WANT_MYSQL_VER=56 OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 WITHOUT_NOUVEAU=true WITH_BUNDLED_PCRE="YES" WITH_KDE_PHONON="YES" DEFAULT_VERSIONS= perl5=5.18 ruby=2.0 src.conf ============================================================================= WITHOUT_ACCT=YES #WITHOUT_AMD=YES WITHOUT_ASSERT_DEBUG=YES WITHOUT_ATM=YES WITHOUT_AUDIT=YES WITHOUT_AUTHPF=YES WITHOUT_BIND=YES WITHOUT_BLUETOOTH=YES WITHOUT_BSNMP=YES WITHOUT_CLANG=YES WITHOUT_CTM=YES WITHOUT_FDT=YES WITHOUT_FLOPPY=YES WITHOUT_GDB=YES WITHOUT_HTML=YES WITHOUT_INET6=YES WITHOUT_INFO=YES WITHOUT_IPFILTER=YES WITHOUT_IPX=YES WITHOUT_KERNEL_SYMBOLS=YES WITHOUT_KVM=YES WITHOUT_LPR=YES WITHOUT_MAIL=YES WITHOUT_NCP=YES WITHOUT_NDIS=YES WITHOUT_OFED=YES WITHOUT_PF=YES WITHOUT_PMC=YES WITHOUT_QUOTAS=YES WITHOUT_RCMDS=YES WITHOUT_RCS=YES WITHOUT_SHAREDOCS=YES WITHOUT_ZFS=YES -------------------------------------------- ó Õ×ÁÖÅÎÉÅÍ, çÕÌÑÅ× çÏÛÁ. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 17:25:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B4E0878; Sun, 24 Nov 2013 17:25:28 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC5322ABB; Sun, 24 Nov 2013 17:25:27 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ec20so2271276lab.38 for ; Sun, 24 Nov 2013 09:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=sN/J3cbkGOtUVkwOl3Gi9jePZWj3+I4kmQOoEAmHLjU=; b=tDwmryPmtndrL7rUoc8u83wqX7oFkPCEoELe1HT/GV1reKV8FQ//hcpmuobDL2/H9M 46y7yrUvZpyINoWKTTcbFHDoCnaVedcoKd+TZp26O/OLmrYtwMOyhLUXI2OwlC9OInPN umJoHXtNNqHT/HubctLQqwyO8+1czMbZIkho09u/TkC2sJUExC+i6cjftqQEw+IzbWGt INpz6UB9k44ZPr7kdcfAALc1hL6lOGxeKEH469X/lOn3//TBkUy0aprRySEQqaBj5Nw6 uJqzf5/miuIRNWTPXGypwlHCCWGyxxudIiOiwnGDCeEm/Ba/EvklWW6jtvBdzHB5B+53 POyg== X-Received: by 10.112.154.129 with SMTP id vo1mr1985534lbb.31.1385313925641; Sun, 24 Nov 2013 09:25:25 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id i8sm4208818lbh.2.2013.11.24.09.25.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2013 09:25:24 -0800 (PST) Sender: Mikolaj Golub Date: Sun, 24 Nov 2013 19:25:21 +0200 From: Mikolaj Golub To: Pete French Subject: Re: Hast locking up under 9.2 Message-ID: <20131124172520.GB17292@gmail.com> References: <20131121203711.GA3736@gmail.com> <20131123215950.GA17292@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131123215950.GA17292@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 24 Nov 2013 17:25:28 -0000 On Sat, Nov 23, 2013 at 11:59:51PM +0200, Mikolaj Golub wrote: > So I propose: > > 1) Use hio_countdown only for counting components we waiting to > complete, i.e. initially it is always 2 for any replication mode. > > 2) To distinguish between "memsync ack" or "memsync fin" responses from > the secondary, add and use hio_memsyncacked field. > > 3) Call write_complete() in component threads _before_ releasing > hio_countdown (i.e. before the hio may be returned to the done > queue). > > 4) Add and use hio_writecount refcounter to detect when > write_complete() should be called in memsync case. > > 5) As hio_done is used only for async, rename it to hio_asyncdone and > check/modify outside of more generic write_complete(), only when it > is needed. > > Now, write_complete(): > - for fullsync is called by ggate_send_thread; > - for async case -- either by local component thread or by ggate_send_thread; > - for memsync case -- by one of the component threads. I just realized that in the case when the write failed locally I can't do write_complete() until "memsync fin" is recieved (to get the status from the secondary), i.e. in this case write_complete() should be called by ggate_send_thread. Here is an updated patch: http://people.freebsd.org/~trociny/patches/hast.primary.c.memsync_write_complete.2.patch I have reverted (5), so hio_done is used to detect if write_complete is needed in ggate_send_thread for memsync case too. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Nov 24 19:56:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96370D7A; Sun, 24 Nov 2013 19:56:51 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 573412259; Sun, 24 Nov 2013 19:56:51 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Vkbzc-0005cS-6U; Sun, 24 Nov 2013 19:53:04 +0400 Message-ID: <529259DE.2040701@FreeBSD.org> Date: Sun, 24 Nov 2013 23:56:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JKWEJWRTHEUCKVBDGILP" Cc: freebsd-ipfw , freebsd-stable , Luigi Rizzo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 24 Nov 2013 19:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JKWEJWRTHEUCKVBDGILP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24.11.2013 19:43, =C3=96zkan KIRIK wrote: > Hi, >=20 > I tested patch. This patch solves, ipfw table 1 add 4899 Ok. So I'll commit this fix soon. >=20 > But, ipfw table 1 add 10.2.3.01 works incorrectly. > output is below. > # ./ipfw table 1 flush > # ./ipfw table 1 add 10.2.3.01 inet_pton() does not recognize this as valid IPv4 address, so it is treated as usigned unteger key. It looks like this behavior is mentioned in STANDARDS section. > # ./ipfw table 1 list > 0.0.0.10/32 0 >=20 >=20 >=20 >=20 > On Sat, Nov 23, 2013 at 11:09 PM, Alexander V. Chernikov > wrote: >=20 > On 19.11.2013 23:55, =EF=BF=96zkan KIRIK wrote: >>>> Hi, >>>> >>>> I'm using kernel FreeBSD 10.0-BETA3 #2 r257635 kernel. I am trying >>>> to add port number to ipfw tables. But there is something strange >>>> : Problem is easily repeatable. >>>> >>>> #ipfw table 1 flush #ipfw table 1 add 4899 #ipfw table 1 list ::/0 >>>> 0 >>>> >>>> #ipfw table 1 flush #ipfw table 1 add 10.2.3.01 ( not >>>> 10.0.0.1, the last 1 has 0 as prefix ) #ipfw table 1 list ::/0 0 >>>> >>>> #ipfw table 1 delete ::/0 ipfw: setsockopt(IP_FW_TABLE_XDEL): No >>>> such process >>>> >>>> >>>> I guess that, this problem is related to radix mask calculation >>>> problem/fix. > Hello. > I'm sorry, it seems that key lookups were broken for quite a long time.= >=20 > Can you apply attached patch, rebuild ipfw(8) binary and see if this > helps? >=20 >=20 >>>> >>>> Is there a quick solution for this. Best, regards, >>>> _______________________________________________ >>>> freebsd-ipfw@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To >>>> unsubscribe, send any mail to >>>> "freebsd-ipfw-unsubscribe@freebsd.org" >>>> >=20 >> > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"= >=20 ------enig2JKWEJWRTHEUCKVBDGILP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKSWeMACgkQwcJ4iSZ1q2njZACfdD3Slr+nei3etHXm83sRilmD 2hoAoICRbULOBCyJMBFXqMW6but3XSS4 =FFua -----END PGP SIGNATURE----- ------enig2JKWEJWRTHEUCKVBDGILP-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 04:31:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A077589C; Mon, 25 Nov 2013 04:31:26 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C352293D; Mon, 25 Nov 2013 04:31:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id rAP4UQqj028170; Mon, 25 Nov 2013 15:30:26 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 25 Nov 2013 15:30:26 +1100 (EST) From: Ian Smith To: "Alexander V. Chernikov" Subject: Re: ipfw table add problem In-Reply-To: <529259DE.2040701@FreeBSD.org> Message-ID: <20131125152238.S78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-ipfw , Luigi Rizzo , freebsd-stable , =?UTF-8?B?w5Z6a2FuIEtJUklL?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 04:31:26 -0000 On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > On 24.11.2013 19:43, Özkan KIRIK wrote: > > Hi, > > > > I tested patch. This patch solves, ipfw table 1 add 4899 > Ok. So I'll commit this fix soon. > > > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > > output is below. > > # ./ipfw table 1 flush > > # ./ipfw table 1 add 10.2.3.01 > inet_pton() does not recognize this as valid IPv4 address, so it is > treated as usigned unteger key. It looks like this behavior is mentioned > in STANDARDS section. > > # ./ipfw table 1 list > > 0.0.0.10/32 0 I'm wondering if "so don't do that" is really sufficient to deal with this? If it's not recognised as a valid address, shouldn't it fail to add anything, with a complaint? I don't see how a string containing dots can be seen as a valid unsigned integer? cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 08:32:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 753918F5; Mon, 25 Nov 2013 08:32:18 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3E33F24D7; Mon, 25 Nov 2013 08:32:18 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 5E106411; Mon, 25 Nov 2013 09:25:45 +0100 (CET) Date: Mon, 25 Nov 2013 09:32:23 +0100 From: Pawel Jakub Dawidek To: Mikolaj Golub Subject: Re: Hast locking up under 9.2 Message-ID: <20131125083223.GE1398@garage.freebsd.pl> References: <20131121203711.GA3736@gmail.com> <20131123215950.GA17292@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WplhKdTI2c8ulnbP" Content-Disposition: inline In-Reply-To: <20131123215950.GA17292@gmail.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Pete French X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 08:32:18 -0000 --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 23, 2013 at 11:59:51PM +0200, Mikolaj Golub wrote: > On Fri, Nov 22, 2013 at 11:18:29AM +0000, Pete French wrote: >=20 > > "Assertion failed: (!hio->hio_done), function write_complete, file > > /usr/src/sbin/hastd/primary.c, line 1130." >=20 > It looks like write_complete usage (which should be called once per > write request) for memsync is racy. >=20 > Consider the following scenario: >=20 > 1) remote_recv_thread: memsync ack received, refcount -> 2; > 2) local_send_thread: local write completed, refcount -> 1, entering > write_complete() > 3) remote_recv_thread: memsync fin received, refcount -> 0, move hio > to done queue, ggate_send_thread gets the hio, checks for > !hio->hio_done and (if loca_send_thread is still in > write_complete()) entering write_complete() I don't see how is that possible. The write_complete() function is called only when hio_countdown goes from 2 to 1 and because this is atomic operation it can only happen in one thread. Can you elaborate on how calling write_complete() concurrently for the same request is possible? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --WplhKdTI2c8ulnbP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlKTCxcACgkQForvXbEpPzQmGwCaA5vKu0Jo/FrPxvpYDZiJydk2 JTQAoNctwZNEWmgY14oXdxJBrinujWVN =Qm2c -----END PGP SIGNATURE----- --WplhKdTI2c8ulnbP-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 09:46:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD11FFE0; Mon, 25 Nov 2013 09:46:18 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3BB2929E4; Mon, 25 Nov 2013 09:46:18 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ec20so2753093lab.38 for ; Mon, 25 Nov 2013 01:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9WA+wNiWGrqZOloAep+Yv/LezSYJP1TBMMuJxo5PnA8=; b=L/hMHEeCLVkzWq/jPxvzoFV4hmgYOmY5eCtd2+JOXKq0G08w7lm7qJm8nas85pDRuJ xBv7cKp7KT7NjEP2pMNBeD01LNF7eTN714C015tX+fAMRXKv+v21uums3A9eJcnreGGq cXzr0+0mrqtJ9sa3eLbQDbw3llw65Ah3/nyhmljlTEWFtQaPAaVxC0EeOVsrcl1BgO0y bePLECFI/uC1MypJytn4Nc3O/gf7ismlElNTobY5c8expahzbSrBZqy9O6qAvXsR4dNu w+UFmDvakrmrWZaYgApWHWfxiXjvrTSfirlYbk9cjel8Bi6LAlmAFycDArPo/L3dABby KwGw== X-Received: by 10.152.140.193 with SMTP id ri1mr22274508lab.18.1385372475205; Mon, 25 Nov 2013 01:41:15 -0800 (PST) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id bo10sm5323033lbb.16.2013.11.25.01.41.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Nov 2013 01:41:14 -0800 (PST) Date: Mon, 25 Nov 2013 11:41:12 +0200 From: Mikolaj Golub To: Pawel Jakub Dawidek Subject: Re: Hast locking up under 9.2 Message-ID: <20131125094111.GA22396@gmail.com> References: <20131121203711.GA3736@gmail.com> <20131123215950.GA17292@gmail.com> <20131125083223.GE1398@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131125083223.GE1398@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Pete French X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 09:46:19 -0000 On Mon, Nov 25, 2013 at 09:32:23AM +0100, Pawel Jakub Dawidek wrote: > On Sat, Nov 23, 2013 at 11:59:51PM +0200, Mikolaj Golub wrote: > > On Fri, Nov 22, 2013 at 11:18:29AM +0000, Pete French wrote: > > > > > "Assertion failed: (!hio->hio_done), function write_complete, file > > > /usr/src/sbin/hastd/primary.c, line 1130." > > > > It looks like write_complete usage (which should be called once per > > write request) for memsync is racy. > > > > Consider the following scenario: > > > > 1) remote_recv_thread: memsync ack received, refcount -> 2; > > 2) local_send_thread: local write completed, refcount -> 1, entering > > write_complete() > > 3) remote_recv_thread: memsync fin received, refcount -> 0, move hio > > to done queue, ggate_send_thread gets the hio, checks for > > !hio->hio_done and (if loca_send_thread is still in > > write_complete()) entering write_complete() > > I don't see how is that possible. The write_complete() function is > called only when hio_countdown goes from 2 to 1 and because this is > atomic operation it can only happen in one thread. Can you elaborate on > how calling write_complete() concurrently for the same request is > possible? Yes, hio_countdown protects calling write_complete() concurently by "component" threads. But it may also be called by ggate_send_thread(): if (!hio->hio_done) write_complete(res, hio); So if write_complete() has already started executing in local_send_thread(), and at that time memsync fin is received, the request is moved to ggate_send_thread, and write_complete can be reentered if it is still in progress in local_send_thread (hio_done is set on exiting write_complete). That is why statement (3) in my patch: write_complete() in component threads is called only before releasing hio_countdown. Otherwise you are not protected from running it simultaneously by ggate_send_thread, or even hio be moved to free before write_complete is finished in local_send_thread. And so hio_countdown can't be used for detecting the current memsync state. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 12:41:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E8CC2A0; Mon, 25 Nov 2013 12:41:06 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17F362687; Mon, 25 Nov 2013 12:41:06 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VkvTD-00005j-Ao; Mon, 25 Nov 2013 12:40:55 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VkvTD-000KvV-2b; Mon, 25 Nov 2013 12:40:55 +0000 To: pjd@FreeBSD.org, to.my.trociny@gmail.com Subject: Re: Hast locking up under 9.2 In-Reply-To: <20131125094111.GA22396@gmail.com> Message-Id: From: Pete French Date: Mon, 25 Nov 2013 12:40:55 +0000 Cc: freebsd-stable@freebsd.org, petefrench@ingresso.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 12:41:06 -0000 Hi, I should be able to make some time today to test a patch if you would like me to. From following the thread I get the idea this bug only applies to memsync mode, is that right ? That would fit with my observations. I will see if I can reproduce the failure first, and then try your second patch if that is the latest pne you would like me to test... let me know if there is a more recent one... cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 12:48:43 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A703F55E for ; Mon, 25 Nov 2013 12:48:43 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 03DEC26D8 for ; Mon, 25 Nov 2013 12:48:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA20442; Mon, 25 Nov 2013 14:48:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VkvaX-000MIr-1k; Mon, 25 Nov 2013 14:48:29 +0200 Message-ID: <529346E5.4070900@FreeBSD.org> Date: Mon, 25 Nov 2013 14:47:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Daniel O'Connor" , freebsd-stable stable Subject: Re: ZFS devd messages References: <85290551-4239-495E-ACCD-9F03C20D40EF@gsoft.com.au> In-Reply-To: <85290551-4239-495E-ACCD-9F03C20D40EF@gsoft.com.au> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 12:48:43 -0000 on 12/10/2013 03:51 Daniel O'Connor said the following: > Hi, > It seems that the ZFS messages no longer match entries in devd.conf, eg.. > notify 10 { > match "system" "ZFS"; > match "type" "vdev"; > action "logger -p kern.err 'ZFS: vdev failure, zpool=$pool type=$type'"; > }; > > Doesn't match anything because messages now look like.. > Processing event '!system=ZFS subsystem=ZFS type=resource.fs.zfs.removed version=0 class=resource.fs.zfs.removed pool_guid=469710819 vdev_guid=215223839' > > Does anyone have an updated set of rules handy? I've come up with the following change: http://people.freebsd.org/~avg/devd-zfs.diff I will appreciate any testing and reviews. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 13:36:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58383E1 for ; Mon, 25 Nov 2013 13:36:06 +0000 (UTC) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61FB629D8 for ; Mon, 25 Nov 2013 13:36:06 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id o10so3553902eaj.27 for ; Mon, 25 Nov 2013 05:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=F6VHKyW4jmVwwRgci90iREvg61huGt79xpo/5i+KxFo=; b=z8TQs9vhMGftRVi+ziMDTN3fWi7dGmFAgi2CmRhvLn69LnO+VN1a9a6CzIZN2JqmlG c1dS4DQ4xUbHULQi8ODvHmG+5py5ma5n2z5VS2fkg0Xq8L4TzOCQPiZ3DDKqTkztVvut pK1b57UOLCvaW1Jsw/qR0Eob3qJvoqxiidl1UaJpHXoND8Esk80Bbn33lm2xA5B6AnXe 2dZpY711tnC9pc1gNaMKxURQS8qShRHd+I0+ma2LNrltJtv7fp7LbjTI0wXw4L64eQBy iT/zQMwnFpbaj9aR37N2TThJUJ+8lFIY5yYugiOt48GuGtI397xSsPSNHaiF+djPAVvk 5kXw== X-Received: by 10.15.77.134 with SMTP id p6mr12085633eey.0.1385386564615; Mon, 25 Nov 2013 05:36:04 -0800 (PST) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id v45sm44578243eef.11.2013.11.25.05.36.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 05:36:04 -0800 (PST) Message-ID: <52935242.2050008@gmail.com> Date: Mon, 25 Nov 2013 14:36:02 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-stable Subject: Lots of DMA messages on FreeBSD 10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 13:36:06 -0000 Hello all. I just updated my machine from 9-STABLE to 10-Stable today. beasty ~ # uname -a FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258543: Mon Nov 25 13:23:31 CET 2013 root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 After a reboot, the console gets cluttered with a lot of messages. ata2: FAILURE - zero length DMA transfer attempted ata2: setting up DMA failed These messages go on and on. ata2 is my cdrom drive! Is there something i can try? regards Johan From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 13:57:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 880E8831; Mon, 25 Nov 2013 13:57:01 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60F952AE8; Mon, 25 Nov 2013 13:57:01 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 7BB2A15504; Mon, 25 Nov 2013 13:56:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 7BB2A15504 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 25 Nov 2013 08:56:56 -0500 From: Glen Barber To: Johan Hendriks Subject: Re: Lots of DMA messages on FreeBSD 10 Message-ID: <20131125135656.GF2310@glenbarber.us> References: <52935242.2050008@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UBnjLfzoMQYIXCvq" Content-Disposition: inline In-Reply-To: <52935242.2050008@gmail.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 13:57:01 -0000 --UBnjLfzoMQYIXCvq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 02:36:02PM +0100, Johan Hendriks wrote: > I just updated my machine from 9-STABLE to 10-Stable today. >=20 > beasty ~ # uname -a > FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r25854= 3: > Mon Nov 25 13:23:31 CET 2013 > root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 >=20 > After a reboot, the console gets cluttered with a lot of messages. >=20 > ata2: FAILURE - zero length DMA transfer attempted > ata2: setting up DMA failed > These messages go on and on. >=20 > ata2 is my cdrom drive! >=20 > Is there something i can try? >=20 Is there a CD in the drive? Glen --UBnjLfzoMQYIXCvq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSk1coAAoJELls3eqvi17QgTQP/1uCWbh0MaEHixQA1eBNtevg CtKMEHGf/g8qDgNKbbPaFIj/xZq7yoaBB1RPR/ctMXD6cpNZmngzZsUP9kcNkbXC AZiWOnY8lfg69IoBb15Qq/kLULnLorVPiQME+/hWjNYt1KCcDyagglI9wUFtktGS +KUcbQEXJME6OrtRwf/kyNCIN7mPfYWenH2lJU7L93j2ETDgVgZUe1gThhM4Ay+q 1u5SpXNRGIYtg//3EuxLeNdjmRcOv6V/0AjnwL6bKEcyIpb9sGIyLUSqOWCDQi9F 2ikca66bjMkUzQF6hA6VpKovFnircVMebyqR/mmCuvXA/dw5OJJBzK0j4/o2PuqI +286lEgMkl/DmI97IenKAFOUGXABD6yE/49krcKW5H974/q+Kp/BrMQtnoSwgAwC iR1cVlVSP+XEX/486tSrfPIGQupXCJNyeRJaAiyhOIxYl1+5O1RM9UixpJyh/DiS gxR783stBMJfJGsm9lf/tlxtHSxV59JWWzwORkMgqTyqILBUTdMTTawO//qVdlZ8 LvhD7oQ91KtAScVeJoqnhaH4taeTNcNmjUeUAtIs4Z0PNUQ3zH3WK6QTezgCKzHr atiVeJcMMek5ZyHjDBl4kN6BbbU0+MUINqvrocoCgFGsgE/XZjVJADslBZya5GmH RGUIswv1ojzQsNjBmqGD =42nZ -----END PGP SIGNATURE----- --UBnjLfzoMQYIXCvq-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 14:14:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF5EEE21; Mon, 25 Nov 2013 14:14:42 +0000 (UTC) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 352ED2C68; Mon, 25 Nov 2013 14:14:42 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g15so2425378eak.4 for ; Mon, 25 Nov 2013 06:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uZKaRbqTGJai2tqC41N8AMZVpMzm35n9Ld8fB/7QDz8=; b=DU/4skNXzapvN7rE5K6ipMHix97OBHRnQhwokLKKDqbzo1iZ+O4aap4v+ZQfh0dxNG dh+q2HXEaSNmL4vzLe0N4lOFQnJZXn011Qooz8o/0+PmFt2oywi0aT1N76k7sBmaa0JO NUTiL1u+K5ZKsc9OMYFhURJgo3pr3EEOg3LeGapR7/26EnenItsGC7wj128yoO/llprM SyGb/xKw6vioFjOWZZxr0H9DgijOBzuXpVdBeemWieRYq2sz5TDF4Xq+ofM/OOe+QHpS uUGjfpcVQI29JQnLV7PD6FXUy8YIH1ooio6F0d/qJPz5tceQJXRsHgJXzcoHePgRVQuc 8loQ== X-Received: by 10.14.107.3 with SMTP id n3mr546528eeg.67.1385388880571; Mon, 25 Nov 2013 06:14:40 -0800 (PST) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id 44sm94742838eek.5.2013.11.25.06.14.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 06:14:39 -0800 (PST) Message-ID: <52935B4E.1040207@gmail.com> Date: Mon, 25 Nov 2013 15:14:38 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Glen Barber Subject: Re: Lots of DMA messages on FreeBSD 10 References: <52935242.2050008@gmail.com> <20131125135656.GF2310@glenbarber.us> In-Reply-To: <20131125135656.GF2310@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 14:14:42 -0000 Glen Barber schreef: > On Mon, Nov 25, 2013 at 02:36:02PM +0100, Johan Hendriks wrote: >> I just updated my machine from 9-STABLE to 10-Stable today. >> >> beasty ~ # uname -a >> FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258543: >> Mon Nov 25 13:23:31 CET 2013 >> root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 >> >> After a reboot, the console gets cluttered with a lot of messages. >> >> ata2: FAILURE - zero length DMA transfer attempted >> ata2: setting up DMA failed >> These messages go on and on. >> >> ata2 is my cdrom drive! >> >> Is there something i can try? >> > Is there a CD in the drive? > > Glen > No there is no disk in the drive! gr Johan From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 14:25:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C030C2B1; Mon, 25 Nov 2013 14:25:16 +0000 (UTC) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3837E2D2E; Mon, 25 Nov 2013 14:25:16 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id d10so2475953eaj.37 for ; Mon, 25 Nov 2013 06:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kXjdKsY1TyEEztkTK5nR96/Gz9b+9Sk37eFTBZd8TLY=; b=t5ZummlWFfMQg6FuXgXlyLobJ81dT20llr7JO5vR8VRiYrDP0MzIAt3MFXo+ctXPsx Q7YsoZTlXr+b/lqxnIPuX1bU8RpRNMsPQ/wu4s0SCEVIkGCm2BKEqCV/iPDfOt8J7Vhu y4eKR/fbzA93TdXlQ1YY4VMOFC/jy7vos5qv1P49RWfmZwuQ4KgVuAGTHNP2DqUqocx5 A545mYRsD1Fqfb2dqrJZbBPlubn4DztOwrHMoME+oTniwMJyxvn0WLxtlZ9HvxcUI7pC 5MQSjx6J62DpXLw9xOiq1IBYnRvac1uLIR6nJ1neTitmVtuZObGh0jzCoLU6DIHRyZMD WlAQ== X-Received: by 10.15.23.206 with SMTP id h54mr36810217eeu.17.1385389514618; Mon, 25 Nov 2013 06:25:14 -0800 (PST) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id n1sm1338826eep.20.2013.11.25.06.25.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 06:25:13 -0800 (PST) Message-ID: <52935DC7.7000409@gmail.com> Date: Mon, 25 Nov 2013 15:25:11 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Glen Barber Subject: Re: Lots of DMA messages on FreeBSD 10 References: <52935242.2050008@gmail.com> <20131125135656.GF2310@glenbarber.us> In-Reply-To: <20131125135656.GF2310@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 14:25:16 -0000 Glen Barber schreef: > On Mon, Nov 25, 2013 at 02:36:02PM +0100, Johan Hendriks wrote: >> I just updated my machine from 9-STABLE to 10-Stable today. >> >> beasty ~ # uname -a >> FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258543: >> Mon Nov 25 13:23:31 CET 2013 >> root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 >> >> After a reboot, the console gets cluttered with a lot of messages. >> >> ata2: FAILURE - zero length DMA transfer attempted >> ata2: setting up DMA failed >> These messages go on and on. >> >> ata2 is my cdrom drive! >> >> Is there something i can try? >> > Is there a CD in the drive? > > Glen > Ok i found the culprit, but do not know how to isolate the problem. I noticed that the message came every two seconds. So my thought was to disable hald and dbus, I rebooted and the message is gone. Is there a setting to disable the cdrom check? regards johan From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 14:27:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 022384BB; Mon, 25 Nov 2013 14:27:12 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE97E2D67; Mon, 25 Nov 2013 14:27:11 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 5D5BA157CD; Mon, 25 Nov 2013 14:27:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 5D5BA157CD Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 25 Nov 2013 09:27:08 -0500 From: Glen Barber To: Johan Hendriks Subject: Re: Lots of DMA messages on FreeBSD 10 Message-ID: <20131125142708.GH2310@glenbarber.us> References: <52935242.2050008@gmail.com> <20131125135656.GF2310@glenbarber.us> <52935DC7.7000409@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WIIRZ1HQ6FgrlPgb" Content-Disposition: inline In-Reply-To: <52935DC7.7000409@gmail.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 14:27:12 -0000 --WIIRZ1HQ6FgrlPgb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 03:25:11PM +0100, Johan Hendriks wrote: > Glen Barber schreef: > >On Mon, Nov 25, 2013 at 02:36:02PM +0100, Johan Hendriks wrote: > >>I just updated my machine from 9-STABLE to 10-Stable today. > >> > >>beasty ~ # uname -a > >>FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258= 543: > >>Mon Nov 25 13:23:31 CET 2013 > >>root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 > >> > >>After a reboot, the console gets cluttered with a lot of messages. > >> > >>ata2: FAILURE - zero length DMA transfer attempted > >>ata2: setting up DMA failed > >>These messages go on and on. > >> > >>ata2 is my cdrom drive! > >> > >>Is there something i can try? > >> > >Is there a CD in the drive? > > > >Glen > > > Ok i found the culprit, but do not know how to isolate the problem. > I noticed that the message came every two seconds. > So my thought was to disable hald and dbus, I rebooted and the message is > gone. >=20 > Is there a setting to disable the cdrom check? >=20 Ah. Due to some CAM changes, after upgrading from 9.x to 10.x, rebuilding sysutils/hald should work. Anything using the CAM system will have to be rebuilt as well (i.e., sysutils/smartmontools). Glen --WIIRZ1HQ6FgrlPgb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSk148AAoJELls3eqvi17Qc0gP/RrUmEggrTeOrCK+g3bnwCgm FchS9kZVCXUCc530Wn/cDTCKLUTHot2rr/43iqzRc2peXw3xycTi6zPXe1fmb9+C hkc4Kd7dHSOMy4WvC8CvrNf2a7v2QtnRbt31LsAm5JHk9x1/WcebZpZxUw0pgjZv /kgPpeNKJVzIjtnpnu0tauxKqJa1gCeChBwScTg5udyJ5JTI5IUhuR2wxdch+nVM BV65ZXVQ38te//+dPCjWJyppMYCTiVk3tfGCKFETSo5/1+au6a457IRglgcThpxE ITrrhoHsTPxEiL+A0VJc9/ktKY5rAylH1mejbIeA2wpCWmKY/QVdPkH26BtQF+ax Qlwm72cwFzwZk6DzRSLYu5ezUf/YNED851LAj9VKPVDqyWQ/ddhIJbQGBJkT2kiy v+CKzzLJRNZhgQqYzzxWDDT4HacPyx4Vcs+tW5bEW1zepLsVwysYrxl4cSxtT/Gi d+mr4/j40qxC55xgzLDHxhTvvBYJLF8Ivam/MEe4BA/LNgJJy3jzyky3TZIdsXp3 ea8WUWkcATZiTGnfsqkQgSD1tTRemtMfkRNNpm2mU+ANu+8is281viwJD60vPpTG 0Ayu+Mz2VRlLH8m9nuAEugpc7BFyQj4XSzg3yj+F+jWPzQjhtHDFJmKlXkb2cr6R GpNM6pLJ4BBGPUBUcn1e =tmad -----END PGP SIGNATURE----- --WIIRZ1HQ6FgrlPgb-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 14:41:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 467C5929; Mon, 25 Nov 2013 14:41:12 +0000 (UTC) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B163B2E88; Mon, 25 Nov 2013 14:41:11 +0000 (UTC) Received: by mail-ea0-f172.google.com with SMTP id q10so2437548ead.17 for ; Mon, 25 Nov 2013 06:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/cBr2DTk9n5KpWIe2r8tk7j64anIzHXTTY0K+lkeGZU=; b=yJRuYIUuZMzF1k0CoMa8H1pULZ2g4ucApLPY5vzIv0xPyLGCHFb4t/e0v2CMU+7y8B HhpRvnXVERjrOgan1Ysz9bUNfSNFpvJf1Ju+STftFhRafvxaLCANvju9/xspeu6A8XGD 9qsv0zgf8nsu76r+fycwgwxPgHQKHHgfZXyIlnrNSsF7gq+DJsFhTTV+ylN18/acP25P 0OdM4krgNm5xbUL/1hgpVNSntTQR5yKvk1Z0+07B+2E/0PSVyjlRlbshOh4SfyjSw2oZ qCQmhpELIaLcGozQIeUfvke62uEkhisKT4FEB4+D+fSTSmjRv6SfXndjPAUG+nRWty5G ATCg== X-Received: by 10.14.202.137 with SMTP id d9mr9286727eeo.23.1385390036578; Mon, 25 Nov 2013 06:33:56 -0800 (PST) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id v45sm44992440eef.11.2013.11.25.06.33.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 06:33:55 -0800 (PST) Message-ID: <52935FD2.2010502@gmail.com> Date: Mon, 25 Nov 2013 15:33:54 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Glen Barber Subject: Re: Lots of DMA messages on FreeBSD 10 References: <52935242.2050008@gmail.com> <20131125135656.GF2310@glenbarber.us> <52935DC7.7000409@gmail.com> <20131125142708.GH2310@glenbarber.us> In-Reply-To: <20131125142708.GH2310@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 14:41:12 -0000 Glen Barber schreef: > On Mon, Nov 25, 2013 at 03:25:11PM +0100, Johan Hendriks wrote: >> Glen Barber schreef: >>> On Mon, Nov 25, 2013 at 02:36:02PM +0100, Johan Hendriks wrote: >>>> I just updated my machine from 9-STABLE to 10-Stable today. >>>> >>>> beasty ~ # uname -a >>>> FreeBSD beasty.schavemaker2.local 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r258543: >>>> Mon Nov 25 13:23:31 CET 2013 >>>> root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 >>>> >>>> After a reboot, the console gets cluttered with a lot of messages. >>>> >>>> ata2: FAILURE - zero length DMA transfer attempted >>>> ata2: setting up DMA failed >>>> These messages go on and on. >>>> >>>> ata2 is my cdrom drive! >>>> >>>> Is there something i can try? >>>> >>> Is there a CD in the drive? >>> >>> Glen >>> >> Ok i found the culprit, but do not know how to isolate the problem. >> I noticed that the message came every two seconds. >> So my thought was to disable hald and dbus, I rebooted and the message is >> gone. >> >> Is there a setting to disable the cdrom check? >> > Ah. Due to some CAM changes, after upgrading from 9.x to 10.x, > rebuilding sysutils/hald should work. > > Anything using the CAM system will have to be rebuilt as well (i.e., > sysutils/smartmontools). > > Glen > Thanks, i will start and rebuild all of the installed ports. It will take some time. Thanks again for your time!! regards Johan From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 15:03:05 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AB1D428; Mon, 25 Nov 2013 15:03:05 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5ED1A2FF7; Mon, 25 Nov 2013 15:03:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vkxgm-000NtG-Fv; Mon, 25 Nov 2013 15:03:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAPF2w68004656; Mon, 25 Nov 2013 08:02:58 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX187EZWJOYy3dfW2L8BSCaSJ Subject: Re: ipfw table add problem From: Ian Lepore To: Ian Smith In-Reply-To: <20131125152238.S78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 25 Nov 2013 08:02:58 -0700 Message-ID: <1385391778.1220.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id rAPF2w68004656 Cc: freebsd-ipfw , "Alexander V. Chernikov" , Luigi Rizzo , freebsd-stable , =?ISO-8859-1?Q?=D6zkan?= KIRIK X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 15:03:05 -0000 On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > > On 24.11.2013 19:43, =D6zkan KIRIK wrote: > > > Hi, > > >=20 > > > I tested patch. This patch solves, ipfw table 1 add 4899 > > Ok. So I'll commit this fix soon. > > >=20 > > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > > > output is below. > > > # ./ipfw table 1 flush > > > # ./ipfw table 1 add 10.2.3.01 > > inet_pton() does not recognize this as valid IPv4 address, so it is > > treated as usigned unteger key. It looks like this behavior is menti= oned > > in STANDARDS section. > > > # ./ipfw table 1 list > > > 0.0.0.10/32 0 >=20 > I'm wondering if "so don't do that" is really sufficient to deal with=20 > this? If it's not recognised as a valid address, shouldn't it fail to=20 > add anything, with a complaint? I don't see how a string containing=20 > dots can be seen as a valid unsigned integer? It's still not clear to me that inet_pton() is doing the right thing. Per the rfc cited earlier in the thread, it's not supposed to interpret the digits as octal or hex -- they are specifically declared to be decimal numbers. There's nothing invalid about "01" as a decimal number. The fact that many of us have a C-programming background and tend to think of leading-zero as implying octal doesn't change that. -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 15:47:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1685C670 for ; Mon, 25 Nov 2013 15:47:59 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id E70D522F6 for ; Mon, 25 Nov 2013 15:47:58 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-145-254-96.range109-145.btcentralplus.com [109.145.254.96]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 4B52D4509D for ; Mon, 25 Nov 2013 15:41:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 4B52D4509D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1385394080; bh=vMZs/SnrNHm7/7jK8ct6ICOLUAg9O/+8HrKmO0tYlvk=; h=Date:From:To:Subject:References:In-Reply-To; b=RC+xNN1RQiZoowjKiu7yywlVxPBdB2L5+VsQSSJ+AJXA86pLzW3TQyttnoMkdO+W3 /VWHJ6daw8BMlBJtSIvRtxdjJeoffVTpETmTEjsqD8CH73C3a7AdNIqKtnAZKKnlx+ QBFVKf6V1hEguSAVMoSRWqUxrcrUn4tmeDAOcacU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id E63F8F5ED; Mon, 25 Nov 2013 15:41:15 +0000 (GMT) Date: Mon, 25 Nov 2013 15:41:15 +0000 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem Message-ID: <20131125154110.GA32738@anubis.morrow.me.uk> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1385391778.1220.4.camel@revolution.hippie.lan> X-Newsgroups: gmane.os.freebsd.devel.ipfw,gmane.os.freebsd.stable User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 15:47:59 -0000 Quoth Ian Lepore : > On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > > On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > > > > I'm wondering if "so don't do that" is really sufficient to deal with > > this? If it's not recognised as a valid address, shouldn't it fail to > > add anything, with a complaint? I don't see how a string containing > > dots can be seen as a valid unsigned integer? > > It's still not clear to me that inet_pton() is doing the right thing. > Per the rfc cited earlier in the thread, it's not supposed to interpret > the digits as octal or hex -- they are specifically declared to be > decimal numbers. There's nothing invalid about "01" as a decimal > number. The fact that many of us have a C-programming background and > tend to think of leading-zero as implying octal doesn't change that. OTOH having inet_pton and inet_aton treat 10.0.0.010 as different addresses would be rather confusing. Ben From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 16:36:50 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FFFE1FE for ; Mon, 25 Nov 2013 16:36:50 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55C65261F for ; Mon, 25 Nov 2013 16:36:50 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vkz9V-00085G-6a; Mon, 25 Nov 2013 16:36:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAPGakci004729; Mon, 25 Nov 2013 09:36:46 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Ca292/Y7P13P8909OVAtU Subject: Re: ipfw table add problem From: Ian Lepore To: Ben Morrow In-Reply-To: <20131125154110.GA32738@anubis.morrow.me.uk> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <20131125154110.GA32738@anubis.morrow.me.uk> Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 2013 09:36:46 -0700 Message-ID: <1385397406.1220.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 16:36:50 -0000 On Mon, 2013-11-25 at 15:41 +0000, Ben Morrow wrote: > Quoth Ian Lepore : > > On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > > > On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > > > > > > I'm wondering if "so don't do that" is really sufficient to deal with > > > this? If it's not recognised as a valid address, shouldn't it fail to > > > add anything, with a complaint? I don't see how a string containing > > > dots can be seen as a valid unsigned integer? > > > > It's still not clear to me that inet_pton() is doing the right thing. > > Per the rfc cited earlier in the thread, it's not supposed to interpret > > the digits as octal or hex -- they are specifically declared to be > > decimal numbers. There's nothing invalid about "01" as a decimal > > number. The fact that many of us have a C-programming background and > > tend to think of leading-zero as implying octal doesn't change that. > > OTOH having inet_pton and inet_aton treat 10.0.0.010 as different > addresses would be rather confusing. But that's exactly the situation we have right now. If inet_aton() or inet_addr() is in use in a given utility you get one behavior, and if inet_pton() is is use you get a different behavior. Right now that different behavior is also incorrect (unless there are some other words in a standard somewhere that specifically forbid leading zeros in the decimal components). -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 16:52:02 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 845DA96F for ; Mon, 25 Nov 2013 16:52:02 +0000 (UTC) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id F18C827D5 for ; Mon, 25 Nov 2013 16:52:00 +0000 (UTC) Received: from tazar.mimar.rs (localhost [127.0.0.1]) by www.mimar.rs (Postfix) with ESMTP id 75494B9040 for ; Mon, 25 Nov 2013 17:51:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:message-id:subject:subject:from:from:date :date:received:received; s=mimar-0901; t=1385398315; x= 1387212716; bh=CruSSni6NnY6/af2wbGU5gv+iYKXop0gaMXYX11cpFk=; b=s AMdj4aZVvVdXxmWEsuDoUlgvwu9petu38Q86fA3y9v+Y/UxxIhxLYQfdgAJP5/dx wkpBQRmDDIp787oPgMgdSlD8jUmd6OY8XaSexVWVskwk+Valv0lskdojbmcuVEs8 vrN2wIPGI/vWncZEHpYJDvxgtfAMpqRUadrh2fccvQ= X-Virus-Scanned: amavisd-new at mimar.rs Received: from www.mimar.rs ([127.0.0.1]) by tazar.mimar.rs (tazar.mimar.rs [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jv4JVFTH5ixw for ; Mon, 25 Nov 2013 17:51:55 +0100 (CET) Received: from kaa.mimar.rs (nat.kappastar.com [193.53.106.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id C1A6CB9042 for ; Mon, 25 Nov 2013 17:51:55 +0100 (CET) Date: Mon, 25 Nov 2013 17:51:55 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@FreeBSD.org Subject: ntfs-3g related errors while rsync Message-Id: <20131125175155.aa6a9ad37ffcb7d2ecd329c4@mimar.rs> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 16:52:02 -0000 uname -a: FreeBSD kaa.mimar.rs 10.0-BETA3 FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 I am getting a lot of errors while rsyncing data from local hdd to ntfs partition on USB disk. Is my data backed up correctly? >From /var/log/messages: Nov 25 17:22:49 kaa ntfs-3g[1807]: Corrupt index block signature: vcn 0 inode 21754 Nov 25 17:22:49 kaa ntfs-3g[1807]: Failed to find place for new entry: Input/output error Nov 25 17:22:49 kaa ntfs-3g[1807]: Failed to add entry to the index: Input/output error Nov 25 17:22:49 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:49 kaa ntfs-3g[1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:49 kaa ntfs-3g [1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:49 kaa ntfs-3g[1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:49 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:49 kaa ntfs-3g [1807]: Corrupt index block signature: vcn 0 inode 21754 Nov 25 17:22:49 kaa ntfs-3g[1807]: Failed to find place for new entry: Input/output error Nov 25 17:22:49 kaa ntfs-3g[1807]: Failed to add entry to the index: Input/output error Nov 25 17:22:50 kaa ntfs-3g [1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g[1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:50 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g [1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:50 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g [1807]: Corrupt index block signature: vcn 0 inode 21754 Nov 25 17:22:50 kaa ntfs-3g[1807]: Failed to find place for new entry: Input/output error Nov 25 17:22:50 kaa ntfs-3g[1807]: Failed to add entry to the index: Input/output error Nov 25 17:22:50 kaa ntfs-3g [1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g[1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:50 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g [1807]: Actual VCN (0x2a2a2a2a2a2a2a2a) of index buffer is different from expected VCN (0x0). Nov 25 17:22:50 kaa ntfs-3g[1807]: ntfs_mst_post_read_fixup_warn: magic: 0x2a2a2a2f size: 4096 usa_ofs: 10794 usa_count: 10793: Invalid argument Nov 25 17:22:50 kaa ntfs-3g [1807]: Corrupt index block signature: vcn 0 inode 21754 Nov 25 17:22:50 kaa ntfs-3g[1807]: Failed to find place for new entry: Input/output error Nov 25 17:22:50 kaa ntfs-3g[1807]: Failed to add entry to the index: Input/output error --=20 Marko Cupa=C4=87 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 17:36:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A27AAC7; Mon, 25 Nov 2013 17:36:01 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFEAB2AC1; Mon, 25 Nov 2013 17:36:00 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vl04c-000AUe-OF; Mon, 25 Nov 2013 17:35:50 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Vl04c-000K0v-IR; Mon, 25 Nov 2013 17:35:50 +0000 To: pjd@FreeBSD.org, to.my.trociny@gmail.com Subject: Re: Hast locking up under 9.2 In-Reply-To: <20131125094111.GA22396@gmail.com> Message-Id: From: Pete French Date: Mon, 25 Nov 2013 17:35:50 +0000 Cc: freebsd-stable@freebsd.org, petefrench@ingresso.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 17:36:01 -0000 I was birning up nmy hast system to do some testing and I got another asseryion failure in it: Assertion failed: (memsyncack), function remote_recv_thread, file /usr/src/sbin/hastd/primary.c, line 1854. Again, that looks memsync related - does that aid your investigations at all ? cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 18:33:21 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 469CEC27; Mon, 25 Nov 2013 18:33:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D937B2EA1; Mon, 25 Nov 2013 18:33:20 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPIXHmR071336; Mon, 25 Nov 2013 18:33:17 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id rAPIXHmS071324; Mon, 25 Nov 2013 18:33:17 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 18:33:17 GMT Message-Id: <201311251833.rAPIXHmS071324@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:33:21 -0000 TB --- 2013-11-25 17:30:12 - tinderbox 2.20 running on freebsd-legacy2.sentex.ca TB --- 2013-11-25 17:30:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 17:30:12 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2013-11-25 17:30:12 - cleaning the object tree TB --- 2013-11-25 17:30:12 - /usr/local/bin/svn stat /src TB --- 2013-11-25 17:30:16 - At svn revision 258565 TB --- 2013-11-25 17:30:17 - building world TB --- 2013-11-25 17:30:17 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 17:30:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 17:30:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 17:30:17 - SRCCONF=/dev/null TB --- 2013-11-25 17:30:17 - TARGET=pc98 TB --- 2013-11-25 17:30:17 - TARGET_ARCH=i386 TB --- 2013-11-25 17:30:17 - TZ=UTC TB --- 2013-11-25 17:30:17 - __MAKE_CONF=/dev/null TB --- 2013-11-25 17:30:17 - cd /src TB --- 2013-11-25 17:30:17 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 25 17:30:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 25 18:15:07 UTC 2013 TB --- 2013-11-25 18:15:07 - generating LINT kernel config TB --- 2013-11-25 18:15:07 - cd /src/sys/pc98/conf TB --- 2013-11-25 18:15:07 - /usr/bin/make -B LINT TB --- 2013-11-25 18:15:07 - cd /src/sys/pc98/conf TB --- 2013-11-25 18:15:07 - /usr/sbin/config -m LINT TB --- 2013-11-25 18:15:07 - building LINT kernel TB --- 2013-11-25 18:15:07 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 18:15:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 18:15:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 18:15:07 - SRCCONF=/dev/null TB --- 2013-11-25 18:15:07 - TARGET=pc98 TB --- 2013-11-25 18:15:07 - TARGET_ARCH=i386 TB --- 2013-11-25 18:15:07 - TZ=UTC TB --- 2013-11-25 18:15:07 - __MAKE_CONF=/dev/null TB --- 2013-11-25 18:15:07 - cd /src TB --- 2013-11-25 18:15:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 25 18:15:07 UTC 2013 >>> 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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'page_busy': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: implicit declaration of function 'rounddown2' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: nested extern declaration of 'rounddown2' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-11-25 18:33:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 18:33:17 - ERROR: failed to build LINT kernel TB --- 2013-11-25 18:33:17 - 3173.58 user 535.14 system 3784.64 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 18:36:45 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3C36E36; Mon, 25 Nov 2013 18:36:45 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9D022EED; Mon, 25 Nov 2013 18:36:44 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPIaiIO037622; Mon, 25 Nov 2013 18:36:44 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id rAPIaivx037621; Mon, 25 Nov 2013 18:36:44 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 18:36:44 GMT Message-Id: <201311251836.rAPIaivx037621@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:36:45 -0000 TB --- 2013-11-25 17:30:12 - tinderbox 2.20 running on freebsd-legacy2.sentex.ca TB --- 2013-11-25 17:30:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 17:30:12 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2013-11-25 17:30:12 - cleaning the object tree TB --- 2013-11-25 17:30:12 - /usr/local/bin/svn stat /src TB --- 2013-11-25 17:30:16 - At svn revision 258565 TB --- 2013-11-25 17:30:17 - building world TB --- 2013-11-25 17:30:17 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 17:30:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 17:30:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 17:30:17 - SRCCONF=/dev/null TB --- 2013-11-25 17:30:17 - TARGET=i386 TB --- 2013-11-25 17:30:17 - TARGET_ARCH=i386 TB --- 2013-11-25 17:30:17 - TZ=UTC TB --- 2013-11-25 17:30:17 - __MAKE_CONF=/dev/null TB --- 2013-11-25 17:30:17 - cd /src TB --- 2013-11-25 17:30:17 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 25 17:30:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 25 18:15:40 UTC 2013 TB --- 2013-11-25 18:15:40 - generating LINT kernel config TB --- 2013-11-25 18:15:40 - cd /src/sys/i386/conf TB --- 2013-11-25 18:15:40 - /usr/bin/make -B LINT TB --- 2013-11-25 18:15:40 - cd /src/sys/i386/conf TB --- 2013-11-25 18:15:40 - /usr/sbin/config -m LINT TB --- 2013-11-25 18:15:40 - building LINT kernel TB --- 2013-11-25 18:15:40 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 18:15:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 18:15:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 18:15:40 - SRCCONF=/dev/null TB --- 2013-11-25 18:15:40 - TARGET=i386 TB --- 2013-11-25 18:15:40 - TARGET_ARCH=i386 TB --- 2013-11-25 18:15:40 - TZ=UTC TB --- 2013-11-25 18:15:40 - __MAKE_CONF=/dev/null TB --- 2013-11-25 18:15:40 - cd /src TB --- 2013-11-25 18:15:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 25 18:15:40 UTC 2013 >>> 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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'page_busy': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: implicit declaration of function 'rounddown2' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: nested extern declaration of 'rounddown2' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-11-25 18:36:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 18:36:44 - ERROR: failed to build LINT kernel TB --- 2013-11-25 18:36:44 - 3370.70 user 550.68 system 3991.35 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 18:42:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA4A4FFA; Mon, 25 Nov 2013 18:42:54 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40E0F2F6E; Mon, 25 Nov 2013 18:42:53 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rAPIcdlf059897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 19:38:39 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <52939929.2090705@omnilan.de> Date: Mon, 25 Nov 2013 19:38:33 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Help with filing a [maybe] ZFS/mmap bug. References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <4B5798F5-269A-4E71-9799-E1B4E0C1545F@transactionware.com> <5289DFFD.7080607@FreeBSD.org> In-Reply-To: <5289DFFD.7080607@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3448F188F5A0814D37ED50B7" Cc: Jan Mikkelsen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 18:42:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3448F188F5A0814D37ED50B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Andriy Gapon's Nachricht vom 18.11.2013 10:38 (localtime): > ... >>> Here is a patch (for head) that should fix the described above issue:= >>> >>> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops= =2Ec >>> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>> index 2e2cbd6..4fcd571 100644 >>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>> @@ -328,6 +328,20 @@ page_busy(vnode_t *vp, int64_t start, int64_t of= f, int64_t >>> nbytes) >>> { >>> vm_object_t obj; >>> vm_page_t pp; >>> + int64_t end; >>> + >>> + /* >>> + * At present vm_page_clear_dirty extends the cleared range to DEV_= BSIZE >>> + * aligned boundaries, if the range is not aligned. As a result a >>> + * DEV_BSIZE subrange with partially dirty data may get marked as c= lean. >>> + * It may happen that all DEV_BSIZE subranges are marked clean and = thus >>> + * the whole page would be considred clean despite have some dirty = data. >>> + * For this reason we should shrink the range to DEV_BSIZE aligned >>> + * boundaries before calling vm_page_clear_dirty. >>> + */ >>> + end =3D rounddown2(off + nbytes, DEV_BSIZE); >>> + off =3D roundup2(off, DEV_BSIZE); >>> + nbytes =3D end - off; >>> >>> obj =3D vp->v_object; >>> zfs_vmobject_assert_wlocked(obj); >>> @@ -362,7 +376,8 @@ page_busy(vnode_t *vp, int64_t start, int64_t off= , int64_t >>> nbytes) >>> ASSERT3U(pp->valid, =3D=3D, VM_PAGE_BITS_ALL); >>> vm_object_pip_add(obj, 1); >>> pmap_remove_write(pp); >>> - vm_page_clear_dirty(pp, off, nbytes); >>> + if (nbytes !=3D 0) >>> + vm_page_clear_dirty(pp, off, nbytes); >>> } >>> break; >>> } >> >> 9.2 does not seem to have a rounddown2() macro. > Thanks for the heads-up! > You could use a plain rounddown() or just 'x & ~(DEV_BSIZE - 1)'. Hello, saw that this fix made it int 9-stable: http://svnweb.freebsd.org/base/stable/9/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/zfs_vnops.c?r1=3D255517&r2=3D258555 But it uses rounddown2(), so I guess it's not workit atm, right? Thanks, -Harry --------------enig3448F188F5A0814D37ED50B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKTmS8ACgkQLDqVQ9VXb8hvXQCfbZW87zScPG453DUiaE1WFou4 jIsAoK55BFn9S0667zSkCYyn0wB6F3eo =ywUQ -----END PGP SIGNATURE----- --------------enig3448F188F5A0814D37ED50B7-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 18:53:43 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBAA0A95; Mon, 25 Nov 2013 18:53:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78E482054; Mon, 25 Nov 2013 18:53:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPIrgbF023605; Mon, 25 Nov 2013 18:53:42 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id rAPIrgKd023600; Mon, 25 Nov 2013 18:53:42 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 18:53:42 GMT Message-Id: <201311251853.rAPIrgKd023600@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:53:43 -0000 TB --- 2013-11-25 17:30:12 - tinderbox 2.20 running on freebsd-legacy2.sentex.ca TB --- 2013-11-25 17:30:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 17:30:12 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2013-11-25 17:30:12 - cleaning the object tree TB --- 2013-11-25 17:30:12 - /usr/local/bin/svn stat /src TB --- 2013-11-25 17:30:16 - At svn revision 258565 TB --- 2013-11-25 17:30:17 - building world TB --- 2013-11-25 17:30:17 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 17:30:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 17:30:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 17:30:17 - SRCCONF=/dev/null TB --- 2013-11-25 17:30:17 - TARGET=amd64 TB --- 2013-11-25 17:30:17 - TARGET_ARCH=amd64 TB --- 2013-11-25 17:30:17 - TZ=UTC TB --- 2013-11-25 17:30:17 - __MAKE_CONF=/dev/null TB --- 2013-11-25 17:30:17 - cd /src TB --- 2013-11-25 17:30:17 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 25 17:30:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Nov 25 18:35:28 UTC 2013 TB --- 2013-11-25 18:35:28 - generating LINT kernel config TB --- 2013-11-25 18:35:28 - cd /src/sys/amd64/conf TB --- 2013-11-25 18:35:28 - /usr/bin/make -B LINT TB --- 2013-11-25 18:35:28 - cd /src/sys/amd64/conf TB --- 2013-11-25 18:35:28 - /usr/sbin/config -m LINT TB --- 2013-11-25 18:35:28 - building LINT kernel TB --- 2013-11-25 18:35:28 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 18:35:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 18:35:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 18:35:28 - SRCCONF=/dev/null TB --- 2013-11-25 18:35:28 - TARGET=amd64 TB --- 2013-11-25 18:35:28 - TARGET_ARCH=amd64 TB --- 2013-11-25 18:35:28 - TZ=UTC TB --- 2013-11-25 18:35:28 - __MAKE_CONF=/dev/null TB --- 2013-11-25 18:35:28 - cd /src TB --- 2013-11-25 18:35:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 25 18:35:28 UTC 2013 >>> 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/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 -mno-omit-leaf-frame-pointer -I/obj/amd64/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 -ffree! standing -fstack-protector -std=iso9899:1999 -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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.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/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 -mno-omit-leaf-frame-pointer -I/obj/amd64/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 -ffree! standing -fstack-protector -std=iso9899:1999 -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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.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/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 -mno-omit-leaf-frame-pointer -I/obj/amd64/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 -ffree! standing -fstack-protector -std=iso9899:1999 -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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.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/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 -mno-omit-leaf-frame-pointer -I/obj/amd64/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 -ffree! standing -fstack-protector -std=iso9899:1999 -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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'page_busy': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: implicit declaration of function 'rounddown2' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: nested extern declaration of 'rounddown2' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-11-25 18:53:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 18:53:42 - ERROR: failed to build LINT kernel TB --- 2013-11-25 18:53:42 - 4225.32 user 732.80 system 5009.68 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 18:57:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ADEFD6D; Mon, 25 Nov 2013 18:57:51 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97261209B; Mon, 25 Nov 2013 18:57:50 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006825793.msg; Mon, 25 Nov 2013 18:57:49 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 25 Nov 2013 18:57:49 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=10418f1d7e=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <85B049105AD44EF795BA6DAE4FF879C2@multiplay.co.uk> From: "Steven Hartland" To: "Harald Schmalzbauer" , "Andriy Gapon" References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <4B5798F5-269A-4E71-9799-E1B4E0C1545F@transactionware.com> <5289DFFD.7080607@FreeBSD.org> <52939929.2090705@omnilan.de> Subject: Re: Help with filing a [maybe] ZFS/mmap bug. Date: Mon, 25 Nov 2013 18:57:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Jan Mikkelsen , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 18:57:51 -0000 ----- Original Message ----- From: "Harald Schmalzbauer" Andriy already MFC'ed that too: http://svnweb.freebsd.org/changeset/base/258575 ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 19:12:10 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B99B33 for ; Mon, 25 Nov 2013 19:12:10 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9662621CA for ; Mon, 25 Nov 2013 19:12:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA25473; Mon, 25 Nov 2013 21:11:46 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vl1ZS-000Mku-2c; Mon, 25 Nov 2013 21:11:46 +0200 Message-ID: <5293A0B4.9070507@FreeBSD.org> Date: Mon, 25 Nov 2013 21:10:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: Help with filing a [maybe] ZFS/mmap bug. References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <4B5798F5-269A-4E71-9799-E1B4E0C1545F@transactionware.com> <5289DFFD.7080607@FreeBSD.org> <52939929.2090705@omnilan.de> In-Reply-To: <52939929.2090705@omnilan.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Jan Mikkelsen , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 19:12:10 -0000 on 25/11/2013 20:38 Harald Schmalzbauer said the following: > Bezüglich Andriy Gapon's Nachricht vom 18.11.2013 10:38 (localtime): >> ... >>>> Here is a patch (for head) that should fix the described above issue: >>>> >>>> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> index 2e2cbd6..4fcd571 100644 >>>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >>>> @@ -328,6 +328,20 @@ page_busy(vnode_t *vp, int64_t start, int64_t off, int64_t >>>> nbytes) >>>> { >>>> vm_object_t obj; >>>> vm_page_t pp; >>>> + int64_t end; >>>> + >>>> + /* >>>> + * At present vm_page_clear_dirty extends the cleared range to DEV_BSIZE >>>> + * aligned boundaries, if the range is not aligned. As a result a >>>> + * DEV_BSIZE subrange with partially dirty data may get marked as clean. >>>> + * It may happen that all DEV_BSIZE subranges are marked clean and thus >>>> + * the whole page would be considred clean despite have some dirty data. >>>> + * For this reason we should shrink the range to DEV_BSIZE aligned >>>> + * boundaries before calling vm_page_clear_dirty. >>>> + */ >>>> + end = rounddown2(off + nbytes, DEV_BSIZE); >>>> + off = roundup2(off, DEV_BSIZE); >>>> + nbytes = end - off; >>>> >>>> obj = vp->v_object; >>>> zfs_vmobject_assert_wlocked(obj); >>>> @@ -362,7 +376,8 @@ page_busy(vnode_t *vp, int64_t start, int64_t off, int64_t >>>> nbytes) >>>> ASSERT3U(pp->valid, ==, VM_PAGE_BITS_ALL); >>>> vm_object_pip_add(obj, 1); >>>> pmap_remove_write(pp); >>>> - vm_page_clear_dirty(pp, off, nbytes); >>>> + if (nbytes != 0) >>>> + vm_page_clear_dirty(pp, off, nbytes); >>>> } >>>> break; >>>> } >>> >>> 9.2 does not seem to have a rounddown2() macro. >> Thanks for the heads-up! >> You could use a plain rounddown() or just 'x & ~(DEV_BSIZE - 1)'. > > Hello, > > saw that this fix made it int 9-stable: > http://svnweb.freebsd.org/base/stable/9/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c?r1=255517&r2=258555 > > But it uses rounddown2(), so I guess it's not workit atm, right? Yeah, sorry about this. I had a headsup and made a note to myself about it, but then got distracted at the actual mfc time. Should be fixed now. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 19:19:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B3FA198; Mon, 25 Nov 2013 19:19:47 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 008A92227; Mon, 25 Nov 2013 19:19:46 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rAPJJi6i060535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 20:19:44 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5293A2D0.5010503@omnilan.de> Date: Mon, 25 Nov 2013 20:19:44 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Steven Hartland Subject: Re: Help with filing a [maybe] ZFS/mmap bug. References: <20967.760.95825.310085@gargle.gargle.HOWL><51E80B30.1090004@FreeBSD.org><20968.10645.880772.30501@gargle.gargle.HOWL><520202E5.30300@FreeBSD.org><20994.55913.93606.436124@gargle.gargle.HOWL> <21111.12085.958991.356982@gargle.gargle.HOWL> <4EB902F80CE84DD2BF36C85EF4CE8EF8@multiplay.co.uk> <5284B8A5.8040604@FreeBSD.org> <52889105.7040404@FreeBSD.org> <4B5798F5-269A-4E71-9799-E1B4E0C1545F@transactionware.com> <5289DFFD.7080607@FreeBSD.org> <52939929.2090705@omnilan.de> <85B049105AD44EF795BA6DAE4FF879C2@multiplay.co.uk> In-Reply-To: <85B049105AD44EF795BA6DAE4FF879C2@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0451AE9C42F5B0896147895" Cc: Jan Mikkelsen , freebsd-stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 19:19:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0451AE9C42F5B0896147895 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Steven Hartland's Nachricht vom 25.11.2013 19:57 (localtime)= : > ----- Original Message ----- From: "Harald Schmalzbauer" > > > Andriy already MFC'ed that too: > http://svnweb.freebsd.org/changeset/base/258575 Great, should have looked myself, sorry! -Harry --------------enigA0451AE9C42F5B0896147895 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKTotAACgkQLDqVQ9VXb8icHQCeKbW0/PO3f/TQYzGoxlD+8H+S HVEAoMYio/GV2FYsBY0Nzthv1oYjlD0+ =VWSd -----END PGP SIGNATURE----- --------------enigA0451AE9C42F5B0896147895-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 19:27:49 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31C576BC; Mon, 25 Nov 2013 19:27:49 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3C8D22E1; Mon, 25 Nov 2013 19:27:48 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id rAPJRme8043169; Mon, 25 Nov 2013 19:27:48 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id rAPJRmM7043167; Mon, 25 Nov 2013 19:27:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Nov 2013 19:27:48 GMT Message-Id: <201311251927.rAPJRmM7043167@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:27:49 -0000 TB --- 2013-11-25 18:34:46 - tinderbox 2.20 running on freebsd-legacy2.sentex.ca TB --- 2013-11-25 18:34:46 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-25 18:34:46 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-11-25 18:34:46 - cleaning the object tree TB --- 2013-11-25 18:34:46 - /usr/local/bin/svn stat /src TB --- 2013-11-25 18:34:48 - At svn revision 258565 TB --- 2013-11-25 18:34:49 - building world TB --- 2013-11-25 18:34:49 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 18:34:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 18:34:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 18:34:49 - SRCCONF=/dev/null TB --- 2013-11-25 18:34:49 - TARGET=sparc64 TB --- 2013-11-25 18:34:49 - TARGET_ARCH=sparc64 TB --- 2013-11-25 18:34:49 - TZ=UTC TB --- 2013-11-25 18:34:49 - __MAKE_CONF=/dev/null TB --- 2013-11-25 18:34:49 - cd /src TB --- 2013-11-25 18:34:49 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 25 18:34:50 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 25 19:13:14 UTC 2013 TB --- 2013-11-25 19:13:14 - generating LINT kernel config TB --- 2013-11-25 19:13:14 - cd /src/sys/sparc64/conf TB --- 2013-11-25 19:13:14 - /usr/bin/make -B LINT TB --- 2013-11-25 19:13:14 - cd /src/sys/sparc64/conf TB --- 2013-11-25 19:13:14 - /usr/sbin/config -m LINT TB --- 2013-11-25 19:13:14 - building LINT kernel TB --- 2013-11-25 19:13:14 - CROSS_BUILD_TESTING=YES TB --- 2013-11-25 19:13:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-25 19:13:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-25 19:13:14 - SRCCONF=/dev/null TB --- 2013-11-25 19:13:14 - TARGET=sparc64 TB --- 2013-11-25 19:13:14 - TARGET_ARCH=sparc64 TB --- 2013-11-25 19:13:14 - TZ=UTC TB --- 2013-11-25 19:13:14 - __MAKE_CONF=/dev/null TB --- 2013-11-25 19:13:14 - cd /src TB --- 2013-11-25 19:13:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 25 19:13:14 UTC 2013 >>> 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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.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 -include /src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/debug_compat.h -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'page_busy': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: implicit declaration of function 'rounddown2' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:341: warning: nested extern declaration of 'rounddown2' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-11-25 19:27:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-25 19:27:48 - ERROR: failed to build LINT kernel TB --- 2013-11-25 19:27:48 - 2809.42 user 411.54 system 3181.14 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 21:27:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 665B8899; Mon, 25 Nov 2013 21:27:13 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBD202A9F; Mon, 25 Nov 2013 21:27:12 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id ep20so3471355lab.20 for ; Mon, 25 Nov 2013 13:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=D0w4T72I2J4sINXKdgJPtHenxZr+3qCMMbsnh4ITMVc=; b=qS9eyKKeJrxqIWAIB2nHOn/8j5hLJbP8/CQLhAgQmirC/1zsA8j8qsP0Q2N4VRRHwe 3D1SXsFq8Rq9ZOC9p8jxvJV30j2i0/g1nhrrAP68DPy0JYd3LcIP3ao/J0J+Od60teHH OukH3Q4epclSr8Cil18NxXIy6+jXgLVffUD/E/Lg6ir8D3I3BWkonKP7K9ixE6zq7Ln1 TiS+xApE7tX1cJOAgGf8QPQoJw6hSx7RUC1g3VeTTrULEM0CyuxllFSL/0eoOZrx14tx eGCMu3C2nObMA6ggmkbqM9dkr/iHNrIiEuypBkqBWof8UT2rNq/BPJN6I9cXTZ6uHP7D h5Og== X-Received: by 10.152.245.1 with SMTP id xk1mr64439lac.49.1385414830702; Mon, 25 Nov 2013 13:27:10 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id a8sm5281789lae.5.2013.11.25.13.27.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2013 13:27:09 -0800 (PST) Sender: Mikolaj Golub Date: Mon, 25 Nov 2013 23:27:07 +0200 From: Mikolaj Golub To: Pete French Subject: Re: Hast locking up under 9.2 Message-ID: <20131125212706.GA6870@gmail.com> References: <20131125094111.GA22396@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org, to.my.trociny@gmail.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 21:27:13 -0000 On Mon, Nov 25, 2013 at 05:35:50PM +0000, Pete French wrote: > I was birning up nmy hast system to do some testing and I got another > asseryion failure in it: > > Assertion failed: (memsyncack), function remote_recv_thread, file /usr/src/sbin/hastd/primary.c, line 1854. It looks you were using the first version of my patch. This was false positive: memsyncack may be false here if the request to the secondary failed, e.g. due to disconnect. I fixed this later but forgot to mention. Please use the latest patch: http://people.freebsd.org/~trociny/patches/hast.primary.c.memsync_write_complete.2.patch Thanks for testing. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Nov 25 21:48:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC0FE151; Mon, 25 Nov 2013 21:48:03 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DAFD2C13; Mon, 25 Nov 2013 21:48:03 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id c11so3672325lbj.5 for ; Mon, 25 Nov 2013 13:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=B+1Dd4rMAawpwvbnBkgXiPJNn4UoU7PaEi3X4zYH2as=; b=UEBjcLuLwpOkDD9xDJjqe7wg/a9hlvHVK18SXvuXsL6H5iBdSNp6zJo1KQTm3/0oFP qFDMAZJtczA+dRYLJhFTdNB771lxfhLRjlbOLVWiWfRZ73uHrmKvuN2QMG3sMvDsm/aj +1T3Mv0b9stVpXLXC9uE34f5+KlNljyDLunWRwvvNNVLbyxv44nuW7Q5r78dTy5qrd+y VijNEcLy76jD9rQZXE1I2W4umyDlNoHljoDMOodSbuGIGrdwDXza1Ivh/SbGgRVQkaVy 494tNxyZNAM28wnxbrcWl6XeUAjQXDw9FjUPsmYOHbLqzAUUwTF8ZC0ul0G41mzMHrwW V9hA== X-Received: by 10.152.22.4 with SMTP id z4mr24163734lae.14.1385416081161; Mon, 25 Nov 2013 13:48:01 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id go4sm39417128lbc.3.2013.11.25.13.47.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Nov 2013 13:48:00 -0800 (PST) Sender: Mikolaj Golub Date: Mon, 25 Nov 2013 23:47:58 +0200 From: Mikolaj Golub To: Pete French Subject: Re: Hast locking up under 9.2 Message-ID: <20131125214757.GB6870@gmail.com> References: <20131125094111.GA22396@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 25 Nov 2013 21:48:03 -0000 On Mon, Nov 25, 2013 at 12:40:55PM +0000, Pete French wrote: > Hi, I should be able to make some time today to test a patch > if you would like me to. From following the thread I get > the idea this bug only applies to memsync mode, is that right ? That > would fit with my observations. Yes, this is the fix for memsync mode, but testing any mode is appreciated to be sure no regression has been introduced. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 00:18:23 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 321DB2D3; Tue, 26 Nov 2013 00:18:23 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6A002443; Tue, 26 Nov 2013 00:18:22 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id BD41F2383A8; Tue, 26 Nov 2013 00:18:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 783DF160436; Tue, 26 Nov 2013 00:25:19 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 481E116042E; Tue, 26 Nov 2013 00:25:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 27951AD3DBF; Tue, 26 Nov 2013 11:18:06 +1100 (EST) To: Ian Lepore From: Mark Andrews References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> Subject: Re: ipfw table add problem In-reply-to: Your message of "Mon, 25 Nov 2013 08:02:58 -0700." <1385391778.1220.4.camel@revolution.hippie.lan> Date: Tue, 26 Nov 2013 11:18:05 +1100 Message-Id: <20131126001806.27951AD3DBF@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: "Alexander V. Chernikov" , Ian Smith , freebsd-ipfw , freebsd-stable , Luigi Rizzo , =?ISO-8859-1?Q?=D6zkan?= KIRIK X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 00:18:23 -0000 In message <1385391778.1220.4.camel@revolution.hippie.lan>, Ian Lepore writes: > On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > > On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > > > On 24.11.2013 19:43, =D6zkan KIRIK wrote: > > > > Hi, > > > > = > > > > > I tested patch. This patch solves, ipfw table 1 add 4899 > > > Ok. So I'll commit this fix soon. > > > > = > > > > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > > > > output is below. > > > > # ./ipfw table 1 flush > > > > # ./ipfw table 1 add 10.2.3.01 > > > inet_pton() does not recognize this as valid IPv4 address, so it is > > > treated as usigned unteger key. It looks like this behavior is mention= > ed > > > in STANDARDS section. > > > > # ./ipfw table 1 list > > > > 0.0.0.10/32 0 > > = > > > I'm wondering if "so don't do that" is really sufficient to deal with = > > > this? If it's not recognised as a valid address, shouldn't it fail to = > > > add anything, with a complaint? I don't see how a string containing = > > > dots can be seen as a valid unsigned integer? > > It's still not clear to me that inet_pton() is doing the right thing. > Per the rfc cited earlier in the thread, it's not supposed to interpret > the digits as octal or hex -- they are specifically declared to be > decimal numbers. There's nothing invalid about "01" as a decimal > number. The fact that many of us have a C-programming background and > tend to think of leading-zero as implying octal doesn't change that. But it does result in unexpected results when there is code that does treat 070 as 56 not 70. Rejecting ambigious input is a good thing. Part of what inet_pton() was trying to do was to get rid of the ambiguity in address inputs by tightening up the specification. 10.2.3.70 is not ambigious 10.2.3.070 is ambigious Mark > -- Ian > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- 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 Tue Nov 26 00:31:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AAFA73D for ; Tue, 26 Nov 2013 00:31:22 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1184D2511 for ; Tue, 26 Nov 2013 00:31:21 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 83CB96132 for ; Mon, 25 Nov 2013 19:31:20 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Zyk8m/SzqgOjsj1oCxeRsMuKSUki0KIDm8qeECZ9rI2vIICJGNqQRZ1bdLIxdy/ge eZFH3/UvL2ehU6UZNck0Gn7a5yJvebwe42avzn8ebGDzOAgBDUFX6CP/pFMPi4i Message-ID: <5293EBD6.8010009@protected-networks.net> Date: Mon, 25 Nov 2013 19:31:18 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> In-Reply-To: <20131126001806.27951AD3DBF@rock.dv.isc.org> X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 00:31:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/13 19:18, Mark Andrews wrote: > > In message <1385391778.1220.4.camel@revolution.hippie.lan>, Ian Lepore writes: >> On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: >>> On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: >>> > On 24.11.2013 19:43, =D6zkan KIRIK wrote: >>> > > Hi, >>> > > = >> >>> > > I tested patch. This patch solves, ipfw table 1 add 4899 >>> > Ok. So I'll commit this fix soon. >>> > > = >> >>> > > But, ipfw table 1 add 10.2.3.01 works incorrectly. >>> > > output is below. >>> > > # ./ipfw table 1 flush >>> > > # ./ipfw table 1 add 10.2.3.01 >>> > inet_pton() does not recognize this as valid IPv4 address, so it is >>> > treated as usigned unteger key. It looks like this behavior is mention= >> ed >>> > in STANDARDS section. >>> > > # ./ipfw table 1 list >>> > > 0.0.0.10/32 0 >>> = >> >>> I'm wondering if "so don't do that" is really sufficient to deal with = >> >>> this? If it's not recognised as a valid address, shouldn't it fail to = >> >>> add anything, with a complaint? I don't see how a string containing = >> >>> dots can be seen as a valid unsigned integer? >> >> It's still not clear to me that inet_pton() is doing the right thing. >> Per the rfc cited earlier in the thread, it's not supposed to interpret >> the digits as octal or hex -- they are specifically declared to be >> decimal numbers. There's nothing invalid about "01" as a decimal >> number. The fact that many of us have a C-programming background and >> tend to think of leading-zero as implying octal doesn't change that. > > But it does result in unexpected results when there is code that > does treat 070 as 56 not 70. Rejecting ambigious input is a good > thing. Part of what inet_pton() was trying to do was to get rid > of the ambiguity in address inputs by tightening up the specification. > > 10.2.3.70 is not ambigious > 10.2.3.070 is ambigious > When the "STANDARDS" section of the inet_pton() man page explicitly defines the interpretation to be decimal, its rejection of a leading zero or misinterpretation as octal defies that definition. It does not say "decimal except when a leading zero is present". As long as the input string can be be properly interpreted as a decimal number, it should be. Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a warning from either inet_pton() or ipfw is an egregious breach of POLA, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKT69YACgkQQv9rrgRC1JKNKgCgj4WOaZ4neyDEdkbVyVDqoKbz vf8AnRV3uv/LCzO+OjXiIGA6S8eGQqAm =tjly -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 00:39:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A242DA5F for ; Tue, 26 Nov 2013 00:39:55 +0000 (UTC) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82095257D for ; Tue, 26 Nov 2013 00:39:55 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F3D98C94DB; Tue, 26 Nov 2013 00:39:41 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1385426395; bh=nS0liiWQP//UXhWJcAxupqtnXqgDR3JOxJdogH1w5zs=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=DEdkcjC3/CUQ5OmdKbjoJeC90k4yCcCFRRwBBPxZJ3bftJbuNY5mEMW/km6W+DYvd iXogHObm4TKEh2OvDsa20tjc1LMXpl5o3ipopBTDAtXb4wyhHU/K+tgrG8SJtQC2e2 kFIRCNMzFaPgXoVfeemJ6P8N70VZF/zz8nl/XbCo= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 26 Nov 2013 00:39:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 58E83160436; Tue, 26 Nov 2013 00:46:54 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id EA71316042E; Tue, 26 Nov 2013 00:46:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1ACD9AD41B4; Tue, 26 Nov 2013 11:39:41 +1100 (EST) To: Michael Butler From: Mark Andrews References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net> Subject: Re: ipfw table add problem In-reply-to: Your message of "Mon, 25 Nov 2013 19:31:18 -0500." <5293EBD6.8010009@protected-networks.net> Date: Tue, 26 Nov 2013 11:39:40 +1100 Message-Id: <20131126003941.1ACD9AD41B4@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 00:39:55 -0000 In message <5293EBD6.8010009@protected-networks.net>, Michael Butler writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/13 19:18, Mark Andrews wrote: > > > > In message <1385391778.1220.4.camel@revolution.hippie.lan>, Ian Lepore writes: > >> On Mon, 2013-11-25 at 15:30 +1100, Ian Smith wrote: > >>> On Sun, 24 Nov 2013 23:56:14 +0400, Alexander V. Chernikov wrote: > >>> > On 24.11.2013 19:43, =D6zkan KIRIK wrote: > >>> > > Hi, > >>> > > = > >> > >>> > > I tested patch. This patch solves, ipfw table 1 add 4899 > >>> > Ok. So I'll commit this fix soon. > >>> > > = > >> > >>> > > But, ipfw table 1 add 10.2.3.01 works incorrectly. > >>> > > output is below. > >>> > > # ./ipfw table 1 flush > >>> > > # ./ipfw table 1 add 10.2.3.01 > >>> > inet_pton() does not recognize this as valid IPv4 address, so it is > >>> > treated as usigned unteger key. It looks like this behavior is mention= > >> ed > >>> > in STANDARDS section. > >>> > > # ./ipfw table 1 list > >>> > > 0.0.0.10/32 0 > >>> = > >> > >>> I'm wondering if "so don't do that" is really sufficient to deal with = > >> > >>> this? If it's not recognised as a valid address, shouldn't it fail to = > >> > >>> add anything, with a complaint? I don't see how a string containing = > >> > >>> dots can be seen as a valid unsigned integer? > >> > >> It's still not clear to me that inet_pton() is doing the right thing. > >> Per the rfc cited earlier in the thread, it's not supposed to interpret > >> the digits as octal or hex -- they are specifically declared to be > >> decimal numbers. There's nothing invalid about "01" as a decimal > >> number. The fact that many of us have a C-programming background and > >> tend to think of leading-zero as implying octal doesn't change that. > > > > But it does result in unexpected results when there is code that > > does treat 070 as 56 not 70. Rejecting ambigious input is a good > > thing. Part of what inet_pton() was trying to do was to get rid > > of the ambiguity in address inputs by tightening up the specification. > > > > 10.2.3.70 is not ambigious > > 10.2.3.070 is ambigious > > > > When the "STANDARDS" section of the inet_pton() man page explicitly > defines the interpretation to be decimal, its rejection of a leading > zero or misinterpretation as octal defies that definition. It does not > say "decimal except when a leading zero is present". > > As long as the input string can be be properly interpreted as a decimal > number, it should be. > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > warning from either inet_pton() or ipfw is an egregious breach of POLA, When inet_pton() implementations have been rejecting leading zero's since they were first written their can't be a POLA. There can be a difference but not a POLA. To make is now accept a leading zero would be a POLA as there is code that depends on leading zeros being rejected by it. > imb > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (FreeBSD) > > iEYEARECAAYFAlKT69YACgkQQv9rrgRC1JKNKgCgj4WOaZ4neyDEdkbVyVDqoKbz > vf8AnRV3uv/LCzO+OjXiIGA6S8eGQqAm > =tjly > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- 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 Tue Nov 26 01:31:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 718A8771 for ; Tue, 26 Nov 2013 01:31:01 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4ED27E2 for ; Tue, 26 Nov 2013 01:31:01 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 20C5B6132; Mon, 25 Nov 2013 20:30:59 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WYqEQlUJKTNCQLkAgeo7k40G+HY8VQp8+nGCHSv66C8ghqe2Q2TNh9Ivyoum5uPrd usqEBWk4EJW6AeQzRi1TmP4tjMfP9y0PbpB3eC88+zU86vnXbEEP8YqIIIaLvG/ Message-ID: <5293F9D1.2030800@protected-networks.net> Date: Mon, 25 Nov 2013 20:30:57 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Andrews Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net> <20131126003941.1ACD9AD41B4@rock.dv.isc.org> In-Reply-To: <20131126003941.1ACD9AD41B4@rock.dv.isc.org> X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 01:31:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/13 19:39, Mark Andrews wrote: >> When inet_pton() implementations have been rejecting leading zero's since >> they were first written their can't be a POLA. There can be a difference >> but not a POLA. To make is now accept a leading zero would be a POLA as >> there is code that depends on leading zeros being rejected by it. History disagrees with you; from the BIND 4 sources: /* This is from the BIND 4.9.4 release, modified to compile by itself */ /* Copyright (c) 1996 by Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS * SOFTWARE. */ #if defined(LIBC_SCCS) && !defined(lint) static char rcsid[] = "$Id: inet_pton.c,v 8.6 1996/06/26 23:17:26 vixie Exp $"; #endif /* LIBC_SCCS and not lint */ [ .. snip .. ] /* int * inet_pton4(src, dst) * like inet_aton() but without all the hexadecimal and shorthand. * return: * 1 if `src' is a valid dotted quad, else 0. * notice: * does not touch `dst' unless it's returning 1. * author: * Paul Vixie, 1996. */ static int inet_pton4(src, dst) const char *src; u_char *dst; { static const char digits[] = "0123456789"; int saw_digit, octets, ch; u_char tmp[INADDRSZ], *tp; saw_digit = 0; octets = 0; *(tp = tmp) = 0; while ((ch = *src++) != '\0') { const char *pch; if ((pch = strchr(digits, ch)) != NULL) { u_int new = *tp * 10 + (pch - digits); if (new > 255) return (0); *tp = new; if (! saw_digit) { if (++octets > 4) return (0); saw_digit = 1; } } else if (ch == '.' && saw_digit) { if (octets == 4) return (0); *++tp = 0; saw_digit = 0; } else return (0); } if (octets < 4) return (0); /* bcopy(tmp, dst, INADDRSZ); */ memcpy(dst, tmp, INADDRSZ); return (1); } Note especially that at some time after 1996, an additional two lines were added and the man page not updated to reflect their addition. Above the test "(new > 255)" these lines were added: if (saw_digit && *tp == 0) return (0); .. and which now causes this confusion. Either the code or the man page are wrong, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKT+dEACgkQQv9rrgRC1JJOxwCgpqtkHUv+d15C49JPpnNrwPI/ zrkAmwSXukkcAhAKKfteEuFRe7tbTqnT =1JzH -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 02:02:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0BF7E94 for ; Tue, 26 Nov 2013 02:02:23 +0000 (UTC) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F976295B for ; Tue, 26 Nov 2013 02:02:23 +0000 (UTC) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C7939C94D9; Tue, 26 Nov 2013 02:02:09 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1385431343; bh=4TbTRqKU+rzVosAIHmy0ZsmjLEHmueergm6rtXgWvi8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=i5/S98w5fswRzXBojIQQCoqZ9Ikjecxdod3HRcK2bArx2hhjQVllxQvk+bStwcmwj ncG4I9xBjFS/ULmcwzLIY51eZ5H7IdFb6u648xPOQWhpaqn5yYPGIWPI0olXUUEo1i zIcMW3cKlMkewcqxVl2R3fDGaEDCnU2et4xjjIm4= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 26 Nov 2013 02:02:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6A9FA160436; Tue, 26 Nov 2013 02:09:22 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0F30916042E; Tue, 26 Nov 2013 02:09:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 37AF9AD4D2C; Tue, 26 Nov 2013 13:02:08 +1100 (EST) To: Michael Butler From: Mark Andrews References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net> <20131126003941.1ACD9AD41B4@rock.dv.isc.org> <5293F9D1.2030800@protected-networks.net> Subject: Re: ipfw table add problem In-reply-to: Your message of "Mon, 25 Nov 2013 20:30:57 -0500." <5293F9D1.2030800@protected-networks.net> Date: Tue, 26 Nov 2013 13:02:07 +1100 Message-Id: <20131126020208.37AF9AD4D2C@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 02:02:23 -0000 I remember incorrectly, the actual change was this one. revision 1.8 date: 2001-07-16 13:22:24 +1000; author: marka; state: Exp; lines: +4 -2; 1242. [bug] inet_pton() failed to reject octal input. Index: inet/inet_pton.c =================================================================== RCS file: /proj/cvs/prod/bind8/src/lib/inet/inet_pton.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- inet/inet_pton.c 13 Oct 1999 16:39:28 -0000 1.7 +++ inet/inet_pton.c 16 Jul 2001 03:22:24 -0000 1.8 @@ -16,7 +16,7 @@ */ #if defined(LIBC_SCCS) && !defined(lint) -static const char rcsid[] = "$Id: inet_pton.c,v 1.7 1999-10-13 16:39:28 vixie Exp $"; +static const char rcsid[] = "$Id: inet_pton.c,v 1.8 2001-07-16 03:22:24 marka Exp $"; #endif /* LIBC_SCCS and not lint */ #include "port_before.h" @@ -95,10 +95,12 @@ if ((pch = strchr(digits, ch)) != NULL) { u_int new = *tp * 10 + (pch - digits); + if (saw_digit && *tp == 0) + return (0); if (new > 255) return (0); *tp = new; - if (! saw_digit) { + if (!saw_digit) { if (++octets > 4) return (0); saw_digit = 1; Now if you want to make it accept 0+[89][0-9]* go ahead but 0+[01234567][01234567]* need to be rejected when the inet_aton accepts octal and hexadecimal. Having different routines return different values for 070.070.070.070 is infintitely worse than having 070.070.070.070 be rejected by one. Yes there is a small subset of 8 octal inputs that match decimal input for which there is no harm. I'm much more worried about the ones that do differ. Mark In message <5293F9D1.2030800@protected-networks.net>, Michael Butler writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/13 19:39, Mark Andrews wrote: > > >> When inet_pton() implementations have been rejecting leading zero's since > >> they were first written their can't be a POLA. There can be a difference > >> but not a POLA. To make is now accept a leading zero would be a POLA as > >> there is code that depends on leading zeros being rejected by it. > > History disagrees with you; from the BIND 4 sources: > > /* This is from the BIND 4.9.4 release, modified to compile by itself */ > > /* Copyright (c) 1996 by Internet Software Consortium. > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > * copyright notice and this permission notice appear in all copies. > * > * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM > DISCLAIMS > * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED > WARRANTIES > * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE > * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL > * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR > * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS > * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE > OF THIS > * SOFTWARE. > */ > > #if defined(LIBC_SCCS) && !defined(lint) > static char rcsid[] = "$Id: inet_pton.c,v 8.6 1996/06/26 23:17:26 vixie > Exp $"; > #endif /* LIBC_SCCS and not lint */ > > [ .. snip .. ] > > /* int > * inet_pton4(src, dst) > * like inet_aton() but without all the hexadecimal and shorthand. > * return: > * 1 if `src' is a valid dotted quad, else 0. > * notice: > * does not touch `dst' unless it's returning 1. > * author: > * Paul Vixie, 1996. > */ > static int > inet_pton4(src, dst) > const char *src; > u_char *dst; > { > static const char digits[] = "0123456789"; > int saw_digit, octets, ch; > u_char tmp[INADDRSZ], *tp; > > saw_digit = 0; > octets = 0; > *(tp = tmp) = 0; > while ((ch = *src++) != '\0') { > const char *pch; > > if ((pch = strchr(digits, ch)) != NULL) { > u_int new = *tp * 10 + (pch - digits); > > if (new > 255) > return (0); > *tp = new; > if (! saw_digit) { > if (++octets > 4) > return (0); > saw_digit = 1; > } > } else if (ch == '.' && saw_digit) { > if (octets == 4) > return (0); > *++tp = 0; > saw_digit = 0; > } else > return (0); > } > if (octets < 4) > return (0); > /* bcopy(tmp, dst, INADDRSZ); */ > memcpy(dst, tmp, INADDRSZ); > return (1); > } > > Note especially that at some time after 1996, an additional two lines > were added and the man page not updated to reflect their addition. > > Above the test "(new > 255)" these lines were added: > > if (saw_digit && *tp == 0) > return (0); > > .. and which now causes this confusion. > > Either the code or the man page are wrong, > > imb > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (FreeBSD) > > iEYEARECAAYFAlKT+dEACgkQQv9rrgRC1JJOxwCgpqtkHUv+d15C49JPpnNrwPI/ > zrkAmwSXukkcAhAKKfteEuFRe7tbTqnT > =1JzH > -----END PGP SIGNATURE----- -- 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 Tue Nov 26 02:13:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36261120 for ; Tue, 26 Nov 2013 02:13:19 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0700929EB for ; Tue, 26 Nov 2013 02:13:19 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 8495A6132; Mon, 25 Nov 2013 21:13:17 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=EQyzEB/cNv8Ah2KWlq+RD/uhkEk+j7tVnw/P+nZGdiBIKw8Q3r87wX5luOQQuXakG ZCcpAHeeneJ5gN2ypkMqpbTC0hlKAkozqyXx20IC4XN8G8KmbGCRWgrAMETAx0T Message-ID: <529403BB.60602@protected-networks.net> Date: Mon, 25 Nov 2013 21:13:15 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Andrews Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <5293EBD6.8010009@protected-networks.net> <20131126003941.1ACD9AD41B4@rock.dv.isc.org> <5293F9D1.2030800@protected-networks.net> <20131126020208.37AF9AD4D2C@rock.dv.isc.org> In-Reply-To: <20131126020208.37AF9AD4D2C@rock.dv.isc.org> X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 02:13:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/25/13 21:02, Mark Andrews wrote: > I remember incorrectly, the actual change was this one. Right - that was *way* after I left bindworkers in June, 1997 and why I couldn't reconcile it with my memory. If this is now to be the commonly expected behaviour, perhaps the man page should be updated to reflect (current) reality, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKUA7sACgkQQv9rrgRC1JLYkgCghYdb34tzPrA6rIGifmDevbaO rJoAoJrWJPYur9SEyXtcZrJiq/6FDZe3 =bu5F -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 04:45:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F9B17C9; Tue, 26 Nov 2013 04:45:26 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E12E82130; Tue, 26 Nov 2013 04:45:25 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id rAQ4SbEm002944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 14:58:43 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: ZFS devd messages Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <529346E5.4070900@FreeBSD.org> Date: Tue, 26 Nov 2013 14:58:37 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <74DBAE0D-D88C-467D-867E-C4C4676FC2AE@gsoft.com.au> References: <85290551-4239-495E-ACCD-9F03C20D40EF@gsoft.com.au> <529346E5.4070900@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1822) X-Spam-Score: -3.55 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 04:45:26 -0000 On 25 Nov 2013, at 23:17, Andriy Gapon wrote: >> Doesn't match anything because messages now look like.. >> Processing event '!system=3DZFS subsystem=3DZFS = type=3Dresource.fs.zfs.removed version=3D0 = class=3Dresource.fs.zfs.removed pool_guid=3D469710819 = vdev_guid=3D215223839' >>=20 >> Does anyone have an updated set of rules handy? >=20 > I've come up with the following change: > http://people.freebsd.org/~avg/devd-zfs.diff >=20 > I will appreciate any testing and reviews. I'd prefer it sent email but that is probably a POLA violation. I can't test it yet but I am building up a new server soon so I can = (although the change looks good to me). -- 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 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 11:11:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D3824A4; Tue, 26 Nov 2013 11:11:22 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29ED82524; Tue, 26 Nov 2013 11:11:22 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VlGXs-000N3F-Vn; Tue, 26 Nov 2013 11:11:09 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VlGXr-000J7k-H7; Tue, 26 Nov 2013 11:11:07 +0000 To: petefrench@ingresso.co.uk, trociny@FreeBSD.org Subject: Re: Hast locking up under 9.2 In-Reply-To: <20131125212706.GA6870@gmail.com> Message-Id: From: Pete French Date: Tue, 26 Nov 2013 11:11:07 +0000 Cc: freebsd-stable@freebsd.org, to.my.trociny@gmail.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 11:11:22 -0000 > It looks you were using the first version of my patch. This was false > positive: memsyncack may be false here if the request to the secondary > failed, e.g. due to disconnect. I fixed this later but forgot to > mention. Please use the latest patch: Actually, that assertions was from the unpatched code - I should have made that clear. > http://people.freebsd.org/~trociny/patches/hast.primary.c.memsync_write_complete.2.patch Will try and give this a test today. My hast stuff is getting a bit more complex due to the fact I;ve out one of them back into production with fullsync enabled as I have verified it works like that. WIll try this on the other drive later today though. -pete. , From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 11:21:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C71E9894; Tue, 26 Nov 2013 11:21:14 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E63E25C1; Tue, 26 Nov 2013 11:21:14 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VlGhV-000NOk-6L; Tue, 26 Nov 2013 11:21:05 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VlGhU-000PFN-VP; Tue, 26 Nov 2013 11:21:04 +0000 To: petefrench@ingresso.co.uk, trociny@FreeBSD.org Subject: Re: Hast locking up under 9.2 In-Reply-To: Message-Id: From: Pete French Date: Tue, 26 Nov 2013 11:21:04 +0000 Cc: freebsd-stable@freebsd.org, to.my.trociny@gmail.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 11:21:14 -0000 I just tried to apply the pathc, but it didnt apply cleanly _ I am patching against 9.2 STABLE latest version, the rejected bits of the patch are below... *************** *** 1322,1334 **** } pjdlog_debug(2, "ggate_recv: (%p) Moving request to the send queues.", hio); - if (hio->hio_replication == HAST_REPLICATION_MEMSYNC && - ggio->gctl_cmd == BIO_WRITE) { - /* Each remote request needs two responses in memsync. */ - refcnt_init(&hio->hio_countdown, ncomps + 1); - } else { - refcnt_init(&hio->hio_countdown, ncomps); - } for (ii = ncomp; ii < ncomps; ii++) QUEUE_INSERT1(hio, send, ii); } --- 1338,1344 ---- } pjdlog_debug(2, "ggate_recv: (%p) Moving request to the send queues.", hio); + refcnt_init(&hio->hio_countdown, ncomps); for (ii = ncomp; ii < ncomps; ii++) QUEUE_INSERT1(hio, send, ii); } *************** *** 1808,1889 **** hio->hio_errors[ncomp] = 0; nv_free(nv); done_queue: - if (hio->hio_replication != HAST_REPLICATION_MEMSYNC || - hio->hio_ggio.gctl_cmd != BIO_WRITE || ISSYNCREQ(hio)) { - if (refcnt_release(&hio->hio_countdown) > 0) - continue; - } else { - /* - * Depending on hio_countdown value, requests finished - * in the following order: - * - * 0: local write, remote memsync, remote final - * or - * 0: remote memsync, local write, remote final - * - * 1: local write, remote memsync, (remote final) - * or - * 1: remote memsync, remote final, (local write) - * - * 2: remote memsync, (local write), (remote final) - * or - * 2: remote memsync, (remote final), (local write) - */ - switch (refcnt_release(&hio->hio_countdown)) { - case 0: - /* - * Remote final reply arrived. - */ - PJDLOG_ASSERT(!memsyncack); - break; - case 1: - if (memsyncack) { - /* - * Local request already finished, so we - * can complete the write. - */ if (hio->hio_errors[0] == 0) write_complete(res, hio); - /* - * We still need to wait for final - * remote reply. - */ pjdlog_debug(2, - "remote_recv: (%p) Moving request back to the recv queue.", - hio); mtx_lock(&hio_recv_list_lock[ncomp]); TAILQ_INSERT_TAIL(&hio_recv_list[ncomp], hio, hio_next[ncomp]); hio_recv_list_size[ncomp]++; mtx_unlock(&hio_recv_list_lock[ncomp]); - } else { - /* - * Remote final reply arrived before - * local write finished. - * Nothing to do in such case. - */ } - continue; - case 2: - /* - * We received remote memsync reply even before - * local write finished. - */ - PJDLOG_ASSERT(memsyncack); - - pjdlog_debug(2, - "remote_recv: (%p) Moving request back to the recv queue.", - hio); - mtx_lock(&hio_recv_list_lock[ncomp]); - TAILQ_INSERT_TAIL(&hio_recv_list[ncomp], hio, - hio_next[ncomp]); - hio_recv_list_size[ncomp]++; - mtx_unlock(&hio_recv_list_lock[ncomp]); - continue; - default: - PJDLOG_ABORT("Invalid hio_countdown."); } } if (ISSYNCREQ(hio)) { mtx_lock(&sync_lock); SYNCREQDONE(hio); --- 1792,1825 ---- hio->hio_errors[ncomp] = 0; nv_free(nv); done_queue: + if (ISMEMSYNCWRITE(hio)) { + if (!hio->hio_memsyncacked) { + PJDLOG_ASSERT(memsyncack || + hio->hio_errors[ncomp] != 0); + /* Remote ack arrived. */ + if (refcnt_release(&hio->hio_writecount) == 0) { if (hio->hio_errors[0] == 0) write_complete(res, hio); + } + hio->hio_memsyncacked = true; + if (hio->hio_errors[ncomp] == 0) { pjdlog_debug(2, + "remote_recv: (%p) Moving request " + "back to the recv queue.", hio); mtx_lock(&hio_recv_list_lock[ncomp]); TAILQ_INSERT_TAIL(&hio_recv_list[ncomp], hio, hio_next[ncomp]); hio_recv_list_size[ncomp]++; mtx_unlock(&hio_recv_list_lock[ncomp]); + continue; } + } else { + PJDLOG_ASSERT(!memsyncack); + /* Remote final reply arrived. */ } } + if (refcnt_release(&hio->hio_countdown) > 0) + continue; if (ISSYNCREQ(hio)) { mtx_lock(&sync_lock); SYNCREQDONE(hio); From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 12:48:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DB5BA18 for ; Tue, 26 Nov 2013 12:48:13 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4D12B56 for ; Tue, 26 Nov 2013 12:48:12 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-145-254-96.range109-145.btcentralplus.com [109.145.254.96]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id E7E8B4509D for ; Tue, 26 Nov 2013 12:48:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk E7E8B4509D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1385470088; bh=zBuQFRybDgR6vwmPhMdv2bQJLqejq7m6snQaw8khuUA=; h=Date:From:To:Subject:References:In-Reply-To; b=TjUJOv8RULOtPN70nhgCSu8sm8SFyNPz3A+l+72I3gkjYQQ0HxIHGG8a+QcuOGkFh 10A1BeKvr/Yzdsvn/59Y6oolmLXloJ9IhJX7SeLs9vFpwSBCtNBpOYoBSc3z/yHDWm m+y7GWv/QrBmlH9ZXX3xu8rkAwMIviyWEFtwUTz8= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 288CDF774; Tue, 26 Nov 2013 12:48:01 +0000 (GMT) Date: Tue, 26 Nov 2013 12:48:01 +0000 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: ipfw table add problem Message-ID: <20131126124757.GA9974@anubis.morrow.me.uk> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5293EBD6.8010009@protected-networks.net> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 26 Nov 2013 12:48:13 -0000 Quoth Michael Butler : > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > warning from either inet_pton() or ipfw is an egregious breach of POLA, That's not a bug in inet_pton, though, that's a bug in ipfw. It's blindly passing the string to atoi or some such when inet_pton fails, and ignoring the fact it doesn't consume the whole string. Ben From owner-freebsd-stable@FreeBSD.ORG Tue Nov 26 16:55:43 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F66A1D2; Tue, 26 Nov 2013 16:55:43 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 670AE2CFE; Tue, 26 Nov 2013 16:55:41 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id rAQGtUSe098527; Tue, 26 Nov 2013 18:55:30 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id rAQGtU9H098126; Tue, 26 Nov 2013 16:55:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Nov 2013 16:55:30 GMT Message-Id: <201311261655.rAQGtU9H098126@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:55:43 -0000 TB --- 2013-11-26 16:10:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-26 16:10:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-26 16:10:42 - starting RELENG_10 tinderbox run for amd64/amd64 TB --- 2013-11-26 16:10:42 - cleaning the object tree TB --- 2013-11-26 16:10:42 - /usr/local/bin/svn stat /src TB --- 2013-11-26 16:11:34 - At svn revision 258654 TB --- 2013-11-26 16:11:35 - building world TB --- 2013-11-26 16:11:35 - CROSS_BUILD_TESTING=YES TB --- 2013-11-26 16:11:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-26 16:11:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-26 16:11:35 - SRCCONF=/dev/null TB --- 2013-11-26 16:11:35 - TARGET=amd64 TB --- 2013-11-26 16:11:35 - TARGET_ARCH=amd64 TB --- 2013-11-26 16:11:35 - TZ=UTC TB --- 2013-11-26 16:11:35 - __MAKE_CONF=/dev/null TB --- 2013-11-26 16:11:35 - cd /src TB --- 2013-11-26 16:11:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Nov 26 16:11:45 UTC 2013 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaObjCProperty.cpp -o SemaObjCProperty.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaOpenMP.cpp -o SemaOpenMP.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/amd64.amd64/src/tmp\" -I/obj/amd64.amd64/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaOverload.cpp -o SemaOverload.o /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaOverload.cpp: In member function 'void clang::::BuiltinOperatorOverloadBuilder::addRelationalPointerOrEnumeralOverloads()': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaOverload.cpp:6883: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangsema *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2013-11-26 16:55:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-26 16:55:29 - ERROR: failed to build world TB --- 2013-11-26 16:55:29 - 2137.13 user 562.14 system 2686.98 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 04:58:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B28E2B35 for ; Wed, 27 Nov 2013 04:58:02 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B1B526B3 for ; Wed, 27 Nov 2013 04:58:02 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id rAR4w0Bl054339; Tue, 26 Nov 2013 23:58:00 -0500 (EST) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at mail.pix.net Message-ID: <52957BD7.9060906@pix.net> Date: Tue, 26 Nov 2013 23:57:59 -0500 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 10-BETA3 - zfs clone of zvol snapshot is not created References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 04:58:02 -0000 > Hi, > > am I doing something wrong, ZFS does not support that or there is a bug that zvol clone does not show up under /dev/zvol after creating it from other zvol snapshot? > > # zfs list -t all | grep local > local 136G 76.8G 144K none > local/home 117G 76.8G 117G /home > local/vm 18.4G 76.8G 144K none > local/vm/vbox_pcbsd_10 5.35G 76.8G 5.35G - > local/vm/vbox_windows_7 10.8G 76.8G 9.86G - > local/vm/vbox_windows_7 at clean 940M - 8.12G - > local/vm/vbox_windows_xp 2.27G 76.8G 2.16G - > local/vm/vbox_windows_xp at clean 109M - 1.07G - > > # zfs clone local/vm/vbox_windows_7 at clean local/vm/vbox_windows_7_personal > > # zfs list -t all | grep local > local 136G 76.8G 144K none > local/home 117G 76.8G 117G /home > local/vm 18.4G 76.8G 144K none > local/vm/vbox_pcbsd_10 5.35G 76.8G 5.35G - > local/vm/vbox_windows_7 10.8G 76.8G 9.86G - > local/vm/vbox_windows_7 at clean 940M - 8.12G - > local/vm/vbox_windows_7_personal 8K 76.8G 8.12G - > local/vm/vbox_windows_xp 2.27G 76.8G 2.16G - > local/vm/vbox_windows_xp at clean 109M - 1.07G - Does it show up after a reboot? If so, it's probably this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=178999 Still not fixed. Sigh. -Kurt From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 07:57:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC6D9567 for ; Wed, 27 Nov 2013 07:57:42 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 053E62E20 for ; Wed, 27 Nov 2013 07:57:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id rAR7uahG034742; Wed, 27 Nov 2013 18:56:36 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 27 Nov 2013 18:56:36 +1100 (EST) From: Ian Smith To: Ben Morrow Subject: Re: ipfw table add problem In-Reply-To: <20131126124757.GA9974@anubis.morrow.me.uk> Message-ID: <20131127011442.P78756@sola.nimnet.asn.au> References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <20131126124757.GA9974@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20131127181617.C78756@sola.nimnet.asn.au> Cc: "Alexander V.Chernikov" , Ian Lepore , freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, Luigi Rizzo , =?ISO-8859-1?Q?=D6zkan_KIRIK?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 07:57:42 -0000 On Tue, 26 Nov 2013 12:48:01 +0000, Ben Morrow wrote: > To: freebsd-stable@freebsd.org Restoring cc ipfw@ and others after the inet_pton side?thread in stable@. grepping /usr/src for inet_pton suggests that a behavioural change in inet_pton at this stage seems rather unlikely :) > Quoth Michael Butler : > > > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > > warning from either inet_pton() or ipfw is an egregious breach of POLA, > > That's not a bug in inet_pton, though, that's a bug in ipfw. It's > blindly passing the string to atoi or some such when inet_pton fails, > and ignoring the fact it doesn't consume the whole string. Indeed it is; strtol actually, which quits at the first (here decimal) non-digit. It does return a pointer to it though, and a check for that character being '.' seems like a fair indicator of a failed dotted quad? http://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw2.c?revision=250759&view=co if (ishexnumber(*arg) != 0 || *arg == ':') { /* Remove / if exists */ if ((p = strchr(arg, '/')) != NULL) { *p = '\0'; mask = atoi(p + 1); } if (inet_pton(AF_INET, arg, paddr) == 1) { ... } else if (inet_pton(AF_INET6, arg, paddr) == 1) { ... } else { /* Port or any other key */ key = strtol(arg, &p, 10); /* Skip non-base 10 entries like 'fa1' */ if (p != arg) { pkey = (uint32_t *)paddr; *pkey = htonl(key); type = IPFW_TABLE_CIDR; addrlen = sizeof(uint32_t); } } } if (type == 0 && strchr(arg, '.') == NULL) { /* Assume interface name. Copy significant data only */ ... } if (type == 0) { if (lookup_host(arg, (struct in_addr *)paddr) != 0) errx(EX_NOHOST, "hostname ``%s'' unknown", arg); ... } ... } I'm mostly a pascal programmer (oh, the shame! :) so I can easily misuse C pointers, but my reading of strtol(3) leads to suggest something like: } else { /* Port or any other key */ key = strtol(arg, &p, 10); /* Skip non-base 10 entries like 'fa1' */ if (p != arg) { + /* IPv4 address that failed inet_pton */ + if (*p == '.') { + errx(EX_DATAERR, "bad IPv4 address"); + } pkey = (uint32_t *)paddr; *pkey = htonl(key); type = IPFW_TABLE_CIDR; addrlen = sizeof(uint32_t); } } cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 10:05:49 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB97155C; Wed, 27 Nov 2013 10:05:49 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FA40253A; Wed, 27 Nov 2013 10:05:49 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 988E3DBD0; Wed, 27 Nov 2013 10:05:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 988E3DBD0 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Nov 2013 05:05:45 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: FreeBSD 10.0-BETA3 snapshots (pre -BETA4) now available Message-ID: <20131127100545.GI1710@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zqjkMoGlbUJ91oFe" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 10:05:49 -0000 --zqjkMoGlbUJ91oFe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline FreeBSD 10.0-BETA3 snapshots are now available. These images are generated from r258657 of stable/10, and are intended as pre -BETA4 snapshots for public testing, until 10.0-BETA4 is rolled (which should be within the next few days). Please note, freebsd-update(8) upgrades are not available for this set of builds. As these builds are considered "snapshot-only", the change list is not included, in case something needs to be reverted for the 10.0-BETA4 builds. If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. The images may be downloaded from the 'snapshots' directory on FTP: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ In addition, pre-built virtual machine images are also available: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Checksums for the installation ISOs and the VM disk images follow at the end of this email. == ISO CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = bbaf40b51278e7f0f31ca056459539acd4eeca07eb3db77468e70f68dadfbc93 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = e3f35a786af16bf8ea7f8ba8a1ce1a4ca0aaeb4388bd1af0f5d948072768472a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 61c8031ad3c7daafe619e686485d04ee219dc6cdec5636ac171f3e6317c37004 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 7f8bb8e0815772a9277d8465f7b43c22b07b7dd6251ddc0809ae9309c379d743 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = 573f679c2eacfbf46dd8452975c5a807 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = 6ca7358887c622b7d9290da0acc4373c MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 833e47010f72aaed8e4ef5df8ef2f65d MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 576c2fc5c63aa3b3e46da38f7c40dec4 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = d08bf30619af86c5c8013a64be3fe3496c6b45b522a431660617011039a966a5 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 59e98e4f91bee70d9101b04f315ea2b5e2d3650f1f203ed9bba0a9e3bea09159 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 0680818b9bf51513a5fbf311720873207f528c6201f9b05dbe322843a83ca9de SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 7c333fd25bb9e16c9b52027b3991e96b89f5cf44bb9e6d4e5ffb2162cb5f8654 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = 3e950d40c7f807d0a4b8eef2d85da4c5 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 95c5deb510b2d7d89d39435210c93e90 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 961394ea39d97ed706b8f840566aa7cd MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 12366e49affc33a9104861172adab6f4 - 10.0-BETA3 ia64: SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 843d2f6c7c2c57063e0de773f98c3d6327deded9fbe7488fdd90f5d3b091399d SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 2f2b51ec6f9a32cd12db58bcb9e577f39689c250da666e7d3ceecbc54883377c SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 08902cfd3447df4edac150ff96bbf1235bab4ac461e4238c1125eea83cba15b1 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 876d0a31510cf6a1251324738be82177 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 0acf4517db5df9407e97857d7811277b MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 55025d6ac489769ebb251ac137fe89e7 - 10.0-BETA3 powerpc: SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = fff26c419a1a7380af4fdf8cee86aabd97584d03c6da71b2dff7e3f277f17711 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 2cdad79753ca5dc45907f14587fcfd06eed1b8449ed367f225045372762119b9 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 16f2f54a9b7943b4eff89a8d52e96724caefecb39683125543a507a20df49953 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = 9fb3857c394473d1e6fa7bd0753a6201 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 4e9304f55d8a63310e4eda6c5bd8e4c7 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 11fc39cb92d9ef2d643c56368221443e - 10.0-BETA3 powerpc64: SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 7eb672f81d4c3cb32399f4285bb049e8576d1fabe46350210ca37bb01ea2e523 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = 3ee0949bcab657b461fa5ca9eeef82ec8cd561750e098fbfd899330178bf2337 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = df21073b158b9be8bedd8d7ed55bd385a02844234c0ecb61701a3b42b6e035bb MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 342212e97db9c2ea53c16c3aad2dea98 MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = b5789471b9f4428468b906e140da5ea7 MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = 8f6ef84f4f9ba3fd46e57166434ec4e3 - 10.0-BETA3 sparc64: SHA256 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-bootonly.iso) = 7e9217cd7ba5dce8704288c9fe05a10e91bcefc134fbbe45fa951c00ad8e3e54 SHA256 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-disc1.iso) = 36401ec2425a8cb2417dc389ad664262d618bf69d39142960c94d6622581b42b MD5 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-bootonly.iso) = 27c5c1c6e7b5ad113f66f4a2c59a3bce MD5 (FreeBSD-10.0-BETA3-sparc64-20131126-r258657-disc1.iso) = fd9c5289fceaa3a3d650e15ad4c0c682 == VM IMAGE CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.qcow2.xz) = dfa8b295a247e760209df361dbe7d62425645360f3ab03f2bbb052ffa1d27f1a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vhd.xz) = d3306bdb526b6afe44a09cad6583b4c8ad747d202c970bfe234ae540688d526b SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vmdk.xz) = 6982f66914a9f63f3e2301609aa2aff09b10a737cc3b07eb1b7972ac4e1e0fa1 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.qcow2.xz) = 55e56a789b3b5b3c989df6bc27831b2f MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vhd.xz) = 51a5cae2c6bb54c245a2c0a3388024dc MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657.vmdk.xz) = 232455466d35471efea92e20e533b435 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.qcow2.xz) = 49ba5bbb5f33986f3b451f278063718e453b81a92a8b33cdd6d4f8af0fd236e8 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vhd.xz) = baadc51e47e21f18f8394dec36342f387f0c4875e8c819b449e317f2a674924d SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vmdk.xz) = cce2a2eb73576231488fb46fa6869130db119cf10f1c5aadc371a6f3723fcbd2 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.qcow2.xz) = f2f90e6b00c1f1bfa3e865f2a524f543 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vhd.xz) = b6d1dff90067336083c3b56e48d6d15f MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657.vmdk.xz) = 1bca9e2f6c70df490984cf810480e7f2 Glen --zqjkMoGlbUJ91oFe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSlcP5AAoJELls3eqvi17QtKUP/05cP2iMYx2ESMzJM3Avwh6C 8lSbeHznczfcxiuGkalr7c/J5iu/G9PuN3Wy7fVIP9uOzc3bKTMZu4qCVV947ye2 RghecmsNUkEgNfypKawx9EZHd8U8EZYhpNbvCx1SenfB7vcNLJxbzEsL3eEdsV6O pzPl7bbm6XeAVbwdcsC6Sof/XGIEKR/awDYt5MzhaMSmlXXbze0LHQEWXnJ3Oji3 j6jHKClIZv4o4Yl5xLaGQVS2lup3X8hWB+ZjEcRI8kjkqCfzQacy4meYmFuMJK9S GcLuV+m8g0uP48u3p/EOyrXwLS6w4oQdvaArkqNOXRb23olNyDc5cYUEL8QHxg1t aZvWwSMDwylactuWoX1zevirZ9MLswOkRhahM4vL2i30ETAFTzCyhsRJ5ARMkCvM F98e6x6aL30SW4K5bQ04bV8KuVdQUIe7CmSnqkhTIphk1SG8lmRPmvCqO2JbX6LN CWe678gQo7oJcpHUhYDcVAJGESGPwijqQpump8PTW+uKH9HvycXp0xyaZ97dT8T5 hMuSLxptlVdN3yvLBlXVXSJ189RpdrSrbpeMmc/M1uO+5i5T8R237I9kMXtUx+Sl MYv5uQZ3izVrGal2gLYErCzs1eaZFhHOKPoYYqRvfNnthcx8nOu+aefvc8970+Ec uGAinpbZDMZh/a1IKa1d =aNMc -----END PGP SIGNATURE----- --zqjkMoGlbUJ91oFe-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 10:12:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7038CD5E; Wed, 27 Nov 2013 10:12:50 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 311AD25FF; Wed, 27 Nov 2013 10:12:50 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=95.108.170.36.red-dhcp.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VlYId-0007JI-J0; Wed, 27 Nov 2013 10:08:35 +0400 Message-ID: <5295C539.8070400@FreeBSD.org> Date: Wed, 27 Nov 2013 14:11:05 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ian Smith , Ben Morrow Subject: Re: ipfw table add problem References: <52911993.8010108@ipfw.ru> <529259DE.2040701@FreeBSD.org> <20131125152238.S78756@sola.nimnet.asn.au> <1385391778.1220.4.camel@revolution.hippie.lan> <20131126001806.27951AD3DBF@rock.dv.isc.org> <20131126124757.GA9974@anubis.morrow.me.uk> <20131127011442.P78756@sola.nimnet.asn.au> In-Reply-To: <20131127011442.P78756@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Ian Lepore , freebsd-ipfw@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 10:12:50 -0000 On 27.11.2013 11:56, Ian Smith wrote: > On Tue, 26 Nov 2013 12:48:01 +0000, Ben Morrow wrote: > > To: freebsd-stable@freebsd.org > > Restoring cc ipfw@ and others after the inet_pton side?thread in > stable@. grepping /usr/src for inet_pton suggests that a behavioural > change in inet_pton at this stage seems rather unlikely :) > > > Quoth Michael Butler : > > > > > > Misinterpreting "10.2.3.01" as "0.0.0.10/32" without so much as a > > > warning from either inet_pton() or ipfw is an egregious breach of POLA, > > > > That's not a bug in inet_pton, though, that's a bug in ipfw. It's > > blindly passing the string to atoi or some such when inet_pton fails, > > and ignoring the fact it doesn't consume the whole string. > > Indeed it is; strtol actually, which quits at the first (here decimal) > non-digit. It does return a pointer to it though, and a check for that > character being '.' seems like a fair indicator of a failed dotted quad? Fixed in r258677, thanks! > > http://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw2.c?revision=250759&view=co > > if (ishexnumber(*arg) != 0 || *arg == ':') { > /* Remove / if exists */ > if ((p = strchr(arg, '/')) != NULL) { > *p = '\0'; > mask = atoi(p + 1); > } > > if (inet_pton(AF_INET, arg, paddr) == 1) { > ... > } else if (inet_pton(AF_INET6, arg, paddr) == 1) { > ... > } else { > /* Port or any other key */ > key = strtol(arg, &p, 10); > /* Skip non-base 10 entries like 'fa1' */ > if (p != arg) { > pkey = (uint32_t *)paddr; > *pkey = htonl(key); > type = IPFW_TABLE_CIDR; > addrlen = sizeof(uint32_t); > } > } > } > > if (type == 0 && strchr(arg, '.') == NULL) { > /* Assume interface name. Copy significant data only */ > ... > } > > if (type == 0) { > if (lookup_host(arg, (struct in_addr *)paddr) != 0) > errx(EX_NOHOST, "hostname ``%s'' unknown", arg); > ... > } > ... > } > > I'm mostly a pascal programmer (oh, the shame! :) so I can easily misuse > C pointers, but my reading of strtol(3) leads to suggest something like: > > } else { > /* Port or any other key */ > key = strtol(arg, &p, 10); > /* Skip non-base 10 entries like 'fa1' */ > if (p != arg) { > + /* IPv4 address that failed inet_pton */ > + if (*p == '.') { > + errx(EX_DATAERR, "bad IPv4 address"); > + } > pkey = (uint32_t *)paddr; > *pkey = htonl(key); > type = IPFW_TABLE_CIDR; > addrlen = sizeof(uint32_t); > } > } > > cheers, Ian > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 12:03:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5162B2B7 for ; Wed, 27 Nov 2013 12:03:21 +0000 (UTC) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1AD42B5C for ; Wed, 27 Nov 2013 12:03:20 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id rARC3BVB001234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 13:03:12 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <5295DF79.8060400@omnilan.de> Date: Wed, 27 Nov 2013 13:03:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Feature request: sticky bit inheritance X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig018AA610A2354483A05CDDA9" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 12:03:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig018AA610A2354483A05CDDA9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, ever since I took a FreeBSD machine into production, acting as any kind of file server, I have to work arround the problem, that write access to a directory implies unlinking (deleting) directory contents. Never heard any sensible explanation why anybody would ever want that behaviour, but it's been like that for decades and everybody seems to be fine with that!?! Maybe because there's the stick bit, which is a usable workarroun= d. Unfortunately, there's no =E2=80=9Csticky=E2=80=9D equivalent in nfs4acls= =2E More unfortunate, newly created directories don't inherit the sticky bit =E2=80=93 unlike the group settings. And most unfortunate, I'm not able to implement sticky bit inheritance myself :-( Since there's already a kind of inheritance when calling mkdir(1), I guess extendig the inheritance to respect the sticky bit shouldn't be too complex, is it? I'd love to see a sysctl which controls the behaviour, so there's no unexpected behaviour, but the possibillity to make FreeBSDs filsystem-permission-control more real-world-usable. But if a sysctl is noticable more effort than just a kern-conf (compile time) option, I'd also highly appreciate that option! Is there anybody who might want to look into that? Thanks, -Harry --------------enig018AA610A2354483A05CDDA9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlKV338ACgkQLDqVQ9VXb8h0LQCfVUp4T48D9KHk2/ToL9cBemYZ 5xYAn0HAcLTWhEF0tUNigBMKLyzV9U2g =ddOw -----END PGP SIGNATURE----- --------------enig018AA610A2354483A05CDDA9-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 27 18:58:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55881DC3; Wed, 27 Nov 2013 18:58:32 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9BFB218E; Wed, 27 Nov 2013 18:58:31 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id y6so5790031lbh.28 for ; Wed, 27 Nov 2013 10:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=veKyPXxYKmX7KwEpcQERGvIVRTXe8P0JCYjkCFwIM90=; b=YTDrEWDB1IwDgDDPEUVRXABiKxtXA3tduKmVWmsM6kgbFdAu1XrFGXZ9gCcMwjz0JQ nUA6DwqhY5tRjpLTuggobS6B7lYzmsxd5yHYm3wz2SdhEUuLv5ipPN+oNiCpnnIk2h8T 9gPgqzzY9N4jpTfpukJMKT9vwyO5S1ZpQtJ3L2nJ8zYRSqyvnc2Nr6pq/7iy0JdtEM3c KeGf9bI0Js8EHA7F//MDoSHFDAFbKBOJ/8gX4riRTxsvbx8ZMl1gk7rhu3CO45kW5MXz NZ7wjh6XqSQBVaAHeQZ9f/G+9EDy9xg+S9PdzFkafvySiBz12DerZsEOI1IWNyIALf8P ajww== X-Received: by 10.112.144.66 with SMTP id sk2mr11286lbb.95.1385578709209; Wed, 27 Nov 2013 10:58:29 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id dm10sm46686562lbc.14.2013.11.27.10.58.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2013 10:58:28 -0800 (PST) Sender: Mikolaj Golub Date: Wed, 27 Nov 2013 20:58:24 +0200 From: Mikolaj Golub To: Pete French Subject: Re: Hast locking up under 9.2 Message-ID: <20131127185822.GA8244@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 27 Nov 2013 18:58:32 -0000 On Tue, Nov 26, 2013 at 11:21:04AM +0000, Pete French wrote: > I just tried to apply the pathc, but it didnt apply cleanly _ I > am patching against 9.2 STABLE latest version, the rejected bits > of the patch are below... Please try this: http://people.freebsd.org/~trociny/patches/hast.primary.c.memsync_write_complete.2.stable9.patch -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 07:04:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 249822FF for ; Thu, 28 Nov 2013 07:04:31 +0000 (UTC) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9BAF1949 for ; Thu, 28 Nov 2013 07:04:30 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g15so5402496eak.32 for ; Wed, 27 Nov 2013 23:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IRUOyC4vOxzx1SkOERRtzpmBrifu7T+EliAxadN7//Q=; b=bjdDjqRO01nx5m/vwgkh0cUF+hX6Fo3hay+Wd8faK8BUeRMloUY/cGwYocOH8PHNs+ QPCSVI9JjRlRuWMDpgV+qOozrEeuMBH4ZdPoCn/XICWfooPKXSdCPrw2xvYX3LTfZ1FR ZZ6KdpegCqofR0CQ89aqh42cLmZwFSX42r9GvoJk6lx0c9tTPoH8RnWtqrD9Pe7EWyc/ 9lk5olCZCWY8aQRgaT9Yo0ploQKJk0WHDOLToeeUR76a/rRhndlSojMbl0xhIPtRzou4 2kLYog/ExEOMlJ9B29Ue/cTONhPKevvauWCjAUKuTrHv9E9rigv9b+hRmd/ceqXPMyQr 03Uw== X-Received: by 10.14.0.72 with SMTP id 48mr4228873eea.50.1385622268980; Wed, 27 Nov 2013 23:04:28 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id a45sm26751318eem.6.2013.11.27.23.04.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 23:04:28 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Feature request: sticky bit inheritance Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1250 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <5295DF79.8060400@omnilan.de> Date: Thu, 28 Nov 2013 08:04:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FC93589-6AB1-4F43-98B3-C9281603A2AD@FreeBSD.org> References: <5295DF79.8060400@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 07:04:31 -0000 Wiadomo=9C=E6 napisana przez Harald Schmalzbauer w dniu 27 lis 2013, o = godz. 13:03: > Hello, >=20 > ever since I took a FreeBSD machine into production, acting as any = kind > of file server, I have to work arround the problem, that write access = to > a directory implies unlinking (deleting) directory contents. Never = heard > any sensible explanation why anybody would ever want that behaviour, = but > it's been like that for decades and everybody seems to be fine with > that!?! Maybe because there's the stick bit, which is a usable = workarround. > Unfortunately, there's no =93sticky=94 equivalent in nfs4acls. One idea is to use NFSv4 ACLs and add entry that denies delete_child and is inherited by directories, i.e. "everyone@:D:d:deny". This should prevent deletion despite write access. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 14:09:08 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 504C5742; Thu, 28 Nov 2013 14:09:08 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 85CB21FD5; Thu, 28 Nov 2013 14:09:06 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id rASE8uxO057658; Thu, 28 Nov 2013 16:08:56 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id rASE8tcX055780; Thu, 28 Nov 2013 14:08:55 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Nov 2013 14:08:55 GMT Message-Id: <201311281408.rASE8tcX055780@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 14:09:08 -0000 TB --- 2013-11-28 14:00:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-28 14:00:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-28 14:00:42 - starting RELENG_10 tinderbox run for ia64/ia64 TB --- 2013-11-28 14:00:42 - cleaning the object tree TB --- 2013-11-28 14:00:42 - /usr/local/bin/svn stat /src TB --- 2013-11-28 14:01:32 - At svn revision 258709 TB --- 2013-11-28 14:01:33 - building world TB --- 2013-11-28 14:01:33 - CROSS_BUILD_TESTING=YES TB --- 2013-11-28 14:01:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-28 14:01:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-28 14:01:33 - SRCCONF=/dev/null TB --- 2013-11-28 14:01:33 - TARGET=ia64 TB --- 2013-11-28 14:01:33 - TARGET_ARCH=ia64 TB --- 2013-11-28 14:01:33 - TZ=UTC TB --- 2013-11-28 14:01:33 - __MAKE_CONF=/dev/null TB --- 2013-11-28 14:01:33 - cd /src TB --- 2013-11-28 14:01:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Nov 28 14:01:44 UTC 2013 >>> 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 [...] cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-dfa.c -o tree-dfa.o cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-eh.c -o tree-eh.o cc -O2 -pipe -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/obj/ia64.ia64/src/tmp/usr\" -DCROSS_COMPILE -I/obj/ia64.ia64/src/tmp/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -std=gnu89 -I/obj/ia64.ia64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-ssa.c -o tree-ssa.o /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-ssa.c: In function 'verify_alias_info': /src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/tree-ssa.c:660: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/usr.bin/cc/cc_int *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2013-11-28 14:08:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-28 14:08:54 - ERROR: failed to build world TB --- 2013-11-28 14:08:54 - 313.09 user 189.80 system 492.20 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 20:47:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E14EB20 for ; Thu, 28 Nov 2013 20:47:20 +0000 (UTC) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D540B13D5 for ; Thu, 28 Nov 2013 20:47:19 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id mz12so4024916bkb.30 for ; Thu, 28 Nov 2013 12:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zlUld1rQItUKS+j9EO0w58gMWrSkiNmrUjK54OFKI8g=; b=exRoT7tz97kMIHh48M/M3cpdDPATeDIuHBALQkC4Xe+gu1SuP/wPTShIGgoqVpQDBl lGei7bOfNq0ayiICrHCNi+LJEg5iDHN9qLawyW4kBKTQwFAf5ivHnHFYt6SWpw2/xMB3 5QiemjV5RQD43nvnqEaY72IWFVJfm5fI3XjrDw1QcWCk5VenHTOaUeeyGSxAnQLGciaG erSHA0Nl/lff82eRorIhyc+TzPr8KIqceRxWNro44dCQJz/o7O0nPsYlXmvIsqXZeWxw JTQJpoq9X+e/Y3RKOFOsLW4ES1gdwquuk8ZbdDUv+YI1Pw3z4LkvUL8uCA57v3Ya7Dz+ 7dhQ== X-Received: by 10.205.10.200 with SMTP id pb8mr36019431bkb.16.1385671638251; Thu, 28 Nov 2013 12:47:18 -0800 (PST) Received: from [192.168.1.103] ([212.96.32.60]) by mx.google.com with ESMTPSA id pu8sm60973044bkb.9.2013.11.28.12.47.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Nov 2013 12:47:17 -0800 (PST) Message-ID: <5297ABD5.5060504@gmail.com> Date: Thu, 28 Nov 2013 21:47:17 +0100 From: =?ISO-8859-1?Q?Szalai_Andr=E1s?= User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: gmirror: writes are faster than reads Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 20:47:20 -0000 Hi Guys, Has somebody encountered (significantly) different read/write speeds when using gmirror? I have 2xWD WD30EFRX RED drives which are configured as follows: $ gmirror status Name Status Components mirror/root COMPLETE ada0p2 (ACTIVE) ada1p2 (ACTIVE) mirror/data COMPLETE ada0p4 (ACTIVE) ada1p4 (ACTIVE) mirror/root is mounted as the root fs (UFS2). Doing write: $ time dd if=/dev/zero of=/IMAGE bs=1024k count=`expr 4 \* 1024` 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 29.326044 secs (146455733 bytes/sec) Doing read: $ time dd if=/IMAGE of=/dev/null bs=1024k count=`expr 4 \* 1024` 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 48.821649 secs (87972598 bytes/sec) As you can see, read is much slower than write (87 vs 146 MB/s). Why? Any help would be appreciated. Best regards, Andrew PS: Partition layout (partitions are 4k aligned): $ gpart show ada0 ada1 => 34 5860533101 ada0 GPT (2.7T) 34 6 - free - (3.0k) 40 1024 1 freebsd-boot (512k) 1064 16777216 2 freebsd-ufs (8.0G) 16778280 16777216 3 freebsd-swap (8.0G) 33555496 5826977632 4 freebsd-ufs (2.7T) 5860533128 7 - free - (3.5k) => 34 5860533101 ada1 GPT (2.7T) 34 6 - free - (3.0k) 40 1024 1 freebsd-boot (512k) 1064 16777216 2 freebsd-ufs (8.0G) 16778280 16777216 3 freebsd-swap (8.0G) 33555496 5826977632 4 freebsd-ufs (2.7T) 5860533128 7 - free - (3.5k) From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 21:03:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95FEBE2C for ; Thu, 28 Nov 2013 21:03:17 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 508011503 for ; Thu, 28 Nov 2013 21:03:17 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9254C20BE2 for ; Thu, 28 Nov 2013 16:03:09 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 28 Nov 2013 16:03:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=QThTkFL8n0lllt7SGcM/FTZ/TiI=; b=MiNPTERshIROsezicKKocwE02yHj uTIFxnDrgCRwptXPZlYFrKKCFafyNAEdtLhHGR5sQiHKB2eQpt9gFiJ0h1JCu3nG PNAFWozTybvoGNQ8yzwOyXxZAXtyShJixumQJP1EkDNtXtNsZGJV57d5DCLlt50D eJEgFc4zqs96Wis= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=QThTkFL8n0lllt7SGcM/FT Z/TiI=; b=TYnxFor0i9byJjhrROw2sEpiPVnA8xNovpJ0A3yFKhYRxcSlYwz3Vf Smk1hzgEyOfhW3R0U8ogZLaCOzqkpfkSG4/OX3AKuTDNkMopMC8qO2rsHQ/4JbMy 9Sb7xfcyl0WRDkwOsJTskVAuQWXtq4dbuKtlY+hPVQemWrOINVzo0= X-Sasl-enc: oKohJPfx8QNkfsQQkmqPHShQvLhaTD8kkFf3X9HH79Gc 1385672589 Received: from harmony.localnet.edu (unknown [141.87.213.68]) by mail.messagingengine.com (Postfix) with ESMTPA id 23481680135 for ; Thu, 28 Nov 2013 16:03:09 -0500 (EST) Date: Thu, 28 Nov 2013 22:03:05 +0100 From: Schaich Alonso To: freebsd-stable@freebsd.org Subject: Re: gmirror: writes are faster than reads Message-Id: <20131128220305.e715adb95b16f494224052f5@fastmail.fm> In-Reply-To: <5297ABD5.5060504@gmail.com> References: <5297ABD5.5060504@gmail.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 21:03:17 -0000 On Thu, 28 Nov 2013 21:47:17 +0100 Szalai Andr=C3=A1s wrote: > Hi Guys, >=20 > Has somebody encountered (significantly) different read/write speeds > when using gmirror? >=20 > I have 2xWD WD30EFRX RED drives which are configured as follows: >=20 > $ gmirror status > Name Status Components > mirror/root COMPLETE ada0p2 (ACTIVE) > ada1p2 (ACTIVE) > mirror/data COMPLETE ada0p4 (ACTIVE) > ada1p4 (ACTIVE) >=20 > mirror/root is mounted as the root fs (UFS2). >=20 > Doing write: >=20 > $ time dd if=3D/dev/zero of=3D/IMAGE bs=3D1024k count=3D`expr 4 \* 1024` > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 29.326044 secs (146455733 bytes/sec) >=20 > Doing read: >=20 > $ time dd if=3D/IMAGE of=3D/dev/null bs=3D1024k count=3D`expr 4 \* 1024` > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 48.821649 secs (87972598 bytes/sec) >=20 > As you can see, read is much slower than write (87 vs 146 MB/s). Why? >=20 > Any help would be appreciated. >=20 > Best regards, > Andrew >=20 > PS: Partition layout (partitions are 4k aligned): >=20 > $ gpart show ada0 ada1 > =3D> 34 5860533101 ada0 GPT (2.7T) > 34 6 - free - (3.0k) > 40 1024 1 freebsd-boot (512k) > 1064 16777216 2 freebsd-ufs (8.0G) > 16778280 16777216 3 freebsd-swap (8.0G) > 33555496 5826977632 4 freebsd-ufs (2.7T) > 5860533128 7 - free - (3.5k) >=20 > =3D> 34 5860533101 ada1 GPT (2.7T) > 34 6 - free - (3.0k) > 40 1024 1 freebsd-boot (512k) > 1064 16777216 2 freebsd-ufs (8.0G) > 16778280 16777216 3 freebsd-swap (8.0G) > 33555496 5826977632 4 freebsd-ufs (2.7T) > 5860533128 7 - free - (3.5k) Modern HDDs have both Command Queuing and Excessive Cache Memory. Using them a spindle disk can cache multiple write requests and do them all in one revolution. While multiple read requests can also be done at once chances are the on-disk cache is not usefull (because the requested data is only resident if it was accessed short before, and then it's also availible in the kernel's larger Filesystem/GEOM caches which reside in main memory and were consulted prior to disk accesses) and the GEOM layer might not have issued them yet. IIRC the UFS subsystem will perform no read requests small= er than 512kB by default, which means it does some readahead just in case the issuing application wants to read more data soon - however you have used re= ad blocks which are exact multiples of 512kB, so there is no gain in this. readahead is the buzzword for tuning large sequencial reads, and I had thou= ght there was a sysctl for it, though I can't find it now. Alonso From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 22:15:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147D824D for ; Thu, 28 Nov 2013 22:15:17 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD3521848 for ; Thu, 28 Nov 2013 22:15:16 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rASMFDF5050936; Thu, 28 Nov 2013 15:15:13 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rASMFBlu050933; Thu, 28 Nov 2013 15:15:11 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 28 Nov 2013 15:15:11 -0700 (MST) From: Warren Block To: =?ISO-8859-15?Q?Szalai_Andr=E1s?= , Schaich Alonso Subject: Re: gmirror: writes are faster than reads In-Reply-To: <20131128220305.e715adb95b16f494224052f5@fastmail.fm> Message-ID: References: <5297ABD5.5060504@gmail.com> <20131128220305.e715adb95b16f494224052f5@fastmail.fm> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 28 Nov 2013 15:15:13 -0700 (MST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 22:15:17 -0000 On Thu, 28 Nov 2013, Schaich Alonso wrote: > Modern HDDs have both Command Queuing and Excessive Cache Memory. Using them > a spindle disk can cache multiple write requests and do them all in one > revolution. While multiple read requests can also be done at once chances > are the on-disk cache is not usefull (because the requested data is only > resident if it was accessed short before, and then it's also availible in > the kernel's larger Filesystem/GEOM caches which reside in main memory and > were consulted prior to disk accesses) and the GEOM layer might not have > issued them yet. IIRC the UFS subsystem will perform no read requests smaller > than 512kB by default, which means it does some readahead just in case the > issuing application wants to read more data soon - however you have used read > blocks which are exact multiples of 512kB, so there is no gain in this. > > readahead is the buzzword for tuning large sequencial reads, and I had thought > there was a sysctl for it, though I can't find it now. gmirror also has four different load-balancing algorithms which can affect read and write speeds. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 23:09:58 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59DE297A for ; Thu, 28 Nov 2013 23:09:58 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A1E51A49 for ; Thu, 28 Nov 2013 23:09:57 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VmAiV-0006sx-87; Thu, 28 Nov 2013 23:09:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rASN9m5m009465; Thu, 28 Nov 2013 16:09:48 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/qEUJ8BevLcP2vk5J4rqP2 Subject: Re: gmirror: writes are faster than reads From: Ian Lepore To: Szalai =?ISO-8859-1?Q?Andr=E1s?= In-Reply-To: <5297ABD5.5060504@gmail.com> References: <5297ABD5.5060504@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 28 Nov 2013 16:09:48 -0700 Message-ID: <1385680188.58852.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id rASN9m5m009465 Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 28 Nov 2013 23:09:58 -0000 On Thu, 2013-11-28 at 21:47 +0100, Szalai Andr=E1s wrote: > Hi Guys, >=20 > Has somebody encountered (significantly) different read/write speeds > when using gmirror? >=20 > I have 2xWD WD30EFRX RED drives which are configured as follows: >=20 > $ gmirror status > Name Status Components > mirror/root COMPLETE ada0p2 (ACTIVE) > ada1p2 (ACTIVE) > mirror/data COMPLETE ada0p4 (ACTIVE) > ada1p4 (ACTIVE) >=20 > mirror/root is mounted as the root fs (UFS2). >=20 > Doing write: >=20 > $ time dd if=3D/dev/zero of=3D/IMAGE bs=3D1024k count=3D`expr 4 \* 1024= ` > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 29.326044 secs (146455733 bytes/sec) >=20 > Doing read: >=20 > $ time dd if=3D/IMAGE of=3D/dev/null bs=3D1024k count=3D`expr 4 \* 1024= ` > 4096+0 records in > 4096+0 records out > 4294967296 bytes transferred in 48.821649 secs (87972598 bytes/sec) >=20 > As you can see, read is much slower than write (87 vs 146 MB/s). Why? >=20 > Any help would be appreciated. You can't use dd to a file to measure performance -- you're just measuring the behavior of the filesystem caching. Much, perhaps most, of the actual writing to disk happens long after the dd command has ended. If you followed the dd command with an unmount of the filesystem and included the time until the umount command completes, you'd have a much closer measure. -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Nov 29 12:01:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D589317A for ; Fri, 29 Nov 2013 12:01:25 +0000 (UTC) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACDE911A9 for ; Fri, 29 Nov 2013 12:01:25 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id uo5so14375750pbc.15 for ; Fri, 29 Nov 2013 04:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S3oLkHGPuQR6TwNddjKvEmqdgc29kZUDlCrkHer5bNQ=; b=acDFdXl/HN8zmNK7Ak8g+Cj+uoDAnGo3DabUPSHFfLTcLNvQxtz/rj7jFQhZGPUW/F 3ovQPP0YMaIIp4V+TSxXlF1y9uIm4hig+McRKSZHyXHw3qr4q+UKND7mQIdzIeCqlr8P qdVkzzDahbbdAF5T9LkFRdcygDWGMjVOG56IMbE5tI8yfLfWfOvR0gTM8RkgLgeHD0LK /5E0M1jsijkg547lrWGSCvvZ28QJJXPd72ot7rvdtlbvvUoeP6bhkGGafCxMRh5NDJ6U iFAchfARFGXAvKQu9nM4R7qHf3ENlZnXnvWRS3wTQP1tvFccBsDWbvJypWDe6vOYjtNH gNDQ== MIME-Version: 1.0 X-Received: by 10.66.168.12 with SMTP id zs12mr13623859pab.122.1385726485083; Fri, 29 Nov 2013 04:01:25 -0800 (PST) Received: by 10.68.16.232 with HTTP; Fri, 29 Nov 2013 04:01:25 -0800 (PST) In-Reply-To: <20131128220305.e715adb95b16f494224052f5@fastmail.fm> References: <5297ABD5.5060504@gmail.com> <20131128220305.e715adb95b16f494224052f5@fastmail.fm> Date: Fri, 29 Nov 2013 07:01:25 -0500 Message-ID: Subject: Re: gmirror: writes are faster than reads From: "illoai@gmail.com" To: Schaich Alonso Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ml-freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 12:01:26 -0000 On 28 November 2013 16:03, Schaich Alonso wrote= : > On Thu, 28 Nov 2013 21:47:17 +0100 > Szalai Andr=E1s wrote: > >> Hi Guys, >> >> Has somebody encountered (significantly) different read/write speeds >> when using gmirror? >> >> I have 2xWD WD30EFRX RED drives which are configured as follows: >> >> $ gmirror status >> Name Status Components >> mirror/root COMPLETE ada0p2 (ACTIVE) >> ada1p2 (ACTIVE) >> mirror/data COMPLETE ada0p4 (ACTIVE) >> ada1p4 (ACTIVE) >> >> mirror/root is mounted as the root fs (UFS2). >> >> Doing write: >> >> $ time dd if=3D/dev/zero of=3D/IMAGE bs=3D1024k count=3D`expr 4 \* 1024` >> 4096+0 records in >> 4096+0 records out >> 4294967296 bytes transferred in 29.326044 secs (146455733 bytes/sec) >> >> Doing read: >> >> $ time dd if=3D/IMAGE of=3D/dev/null bs=3D1024k count=3D`expr 4 \* 1024` >> 4096+0 records in >> 4096+0 records out >> 4294967296 bytes transferred in 48.821649 secs (87972598 bytes/sec) >> >> As you can see, read is much slower than write (87 vs 146 MB/s). Why? >> >> Any help would be appreciated. >> >> Best regards, >> Andrew >> >> PS: Partition layout (partitions are 4k aligned): >> >> $ gpart show ada0 ada1 >> =3D> 34 5860533101 ada0 GPT (2.7T) >> 34 6 - free - (3.0k) >> 40 1024 1 freebsd-boot (512k) >> 1064 16777216 2 freebsd-ufs (8.0G) >> 16778280 16777216 3 freebsd-swap (8.0G) >> 33555496 5826977632 4 freebsd-ufs (2.7T) >> 5860533128 7 - free - (3.5k) >> >> =3D> 34 5860533101 ada1 GPT (2.7T) >> 34 6 - free - (3.0k) >> 40 1024 1 freebsd-boot (512k) >> 1064 16777216 2 freebsd-ufs (8.0G) >> 16778280 16777216 3 freebsd-swap (8.0G) >> 33555496 5826977632 4 freebsd-ufs (2.7T) >> 5860533128 7 - free - (3.5k) > > Modern HDDs have both Command Queuing and Excessive Cache Memory. Using t= hem > a spindle disk can cache multiple write requests and do them all in one > revolution. While multiple read requests can also be done at once chances > are the on-disk cache is not usefull (because the requested data is only > resident if it was accessed short before, and then it's also availible in > the kernel's larger Filesystem/GEOM caches which reside in main memory an= d > were consulted prior to disk accesses) and the GEOM layer might not have > issued them yet. IIRC the UFS subsystem will perform no read requests sma= ller > than 512kB by default, which means it does some readahead just in case th= e > issuing application wants to read more data soon - however you have used = read > blocks which are exact multiples of 512kB, so there is no gain in this. > > readahead is the buzzword for tuning large sequencial reads, and I had th= ought > there was a sysctl for it, though I can't find it now. > vfs.read_max, perhaps? IIRC, it's 16 by default, & frequently can improve disk read speed by 100% or more by simply setting it to a larger value. --=20 -- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 29 18:39:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2C1D8E8 for ; Fri, 29 Nov 2013 18:39:55 +0000 (UTC) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 84E711846 for ; Fri, 29 Nov 2013 18:39:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=kxi7DXdrvqIenWjiT1a+LOrZTh9cm48J+M66rwdVDeU=; b=ksNfPWvKOSyCC+5Qn0mmf7YWW62McnL4o7sCLf3yuaQ62J7tjWo9+O3AHb6vIOtA226NY7ZBcfjVATHAe1D6lJLTmGIfb5OdhZbGqNgDj6vqm08cBAC6M46oQaTnP9Bw2Vmm0OiXN4ltswcSWjETGtg7fTm7RTuUo9CITdnvtAY=; Received: from iglou4.iglou.com ([192.107.41.39]:62283 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1VmSyp-00039S-8n by authid with igloumta_auth for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 13:39:55 -0500 Received: from shell1.iglou.com ([192.107.41.17]:62715 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1VmSyo-00001D-S7 for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 13:39:55 -0500 Date: Fri, 29 Nov 2013 13:39:54 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-stable@freebsd.org Subject: kernel "mismatch" on r256420 Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:39:55 -0000 I installed FreeBSD 10 from a BETA cd-rom. I chose 'experimental ZFS on root - mirror'. The FreeBSD firewall will not load. Any suggestions? This is from 'dmesg': KLD ipfw.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type This is from 'ls -l' of /boot drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/ This is from 'ls -l' of /bootpool/boot drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/ This is my kernel file: include GENERIC ident theEleven options AUDIT options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=15 options DUMMYNET This is from rc.conf: firewall_enable="YES" firewall_logging="YES" firewall_script="/etc/myScript" firewall_quiet="NO" firewall_logif="YES" firewall_nat_enable="NO" Darrel From owner-freebsd-stable@FreeBSD.ORG Fri Nov 29 18:48:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C258F05 for ; Fri, 29 Nov 2013 18:48:20 +0000 (UTC) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4A218D6 for ; Fri, 29 Nov 2013 18:48:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date; bh=uspQnYSAtXbBZ3TytjvZBZvJt2pK4hCUtITRrih5Eeo=; b=ozY6WF/kZXIw9bU0xNdr88KLu3pqkjOWfYH/+E4kI2w3JvejkCyCpVn2kYb3h1yG8sANqyk9H4Vrr0/ioFpyNCCmVEV2vEk+dhcnwyT4Tw2d2q6VAScPtkOYkXrzjWF/o0GEUS8MF/q4xDnOvozhQzn0jr73cJcMdhGlwiIWIdU=; Received: from iglou4.iglou.com ([192.107.41.39]:64284 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1VmT6r-0004JT-Ef by authid with igloumta_auth for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 13:48:13 -0500 Received: from shell1.iglou.com ([192.107.41.17]:62726 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1VmT6r-0000uN-5i for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 13:48:13 -0500 Date: Fri, 29 Nov 2013 13:48:12 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-stable@freebsd.org Subject: Re: kernel "mismatch" on r256420 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 18:48:20 -0000 On Fri, 29 Nov 2013, Darrel wrote: > I installed FreeBSD 10 from a BETA cd-rom. I chose 'experimental ZFS on root > - mirror'. The FreeBSD firewall will not load. Any suggestions? > > This is from 'dmesg': > > KLD ipfw.ko: depends on kernel - not available or version mismatch > linker_load_file: Unsupported file type > > This is from 'ls -l' of /boot > drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/ > > This is from 'ls -l' of /bootpool/boot > drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/> It *is* a mismatch! The output of 'uname -i': GENERIC I should update again, but am almost certain that KERNCONF= was in my last update. Darrel From owner-freebsd-stable@FreeBSD.ORG Fri Nov 29 19:27:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36347EB4 for ; Fri, 29 Nov 2013 19:27:32 +0000 (UTC) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id E96F41ACB for ; Fri, 29 Nov 2013 19:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date; bh=eKqrKQ3R0ZFdyJEVfM0awb2UAcWLPTonVE05sIu2WLk=; b=YhzBhju09d4jhquXOYXnsu0bIeGbmOSodCwQ1QpdJOgy16jJ36TPnYpkOL80pvnmGAcb5zthqyzbUU+oXtEHsWEJOiHNvGj9u3czh2bjb8IIBP9y0Gxpd5tFuN+hnp9zg97PF5/0j8jZMR2NUNR2pd6Pvfl89M5YhyecDs+KDX4=; Received: from iglou4.iglou.com ([192.107.41.39]:41276 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1VmTit-0003Lq-4M by authid with igloumta_auth for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 14:27:31 -0500 Received: from shell1.iglou.com ([192.107.41.17]:62799 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1VmTis-000605-Pi for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 14:27:30 -0500 Date: Fri, 29 Nov 2013 14:27:30 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-stable@freebsd.org Subject: Re: kernel "mismatch" on r256420 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 29 Nov 2013 19:27:32 -0000 >> I installed FreeBSD 10 from a BETA cd-rom. I chose 'experimental ZFS on >> root - mirror'. The FreeBSD firewall will not load. Any suggestions? >> >> This is from 'dmesg': >> >> KLD ipfw.ko: depends on kernel - not available or version mismatch >> linker_load_file: Unsupported file type >> >> This is from 'ls -l' of /boot >> drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/ >> >> This is from 'ls -l' of /bootpool/boot >> drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/> > > It *is* a mismatch! The output of 'uname -i': > > GENERIC > > I should update again, but am almost certain that KERNCONF= was in my last > update. > In the existing versions of my 'ZFS mirror root' there is no directory called BOOTPOOL. I suspect something is not in sync with UPGRADING and the experimental sysinstall, or whatever it is currently called. I did not use the installer menu to make the earlier versions of ZFS on root. I typed commands. Anyhow, I ran svn and now 'make buildworld' is running- revision 258748 Darrel From owner-freebsd-stable@FreeBSD.ORG Sat Nov 30 03:13:01 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8C04EFA; Sat, 30 Nov 2013 03:13:01 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACEF9130A; Sat, 30 Nov 2013 03:13:01 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 61E27186EB; Sat, 30 Nov 2013 03:12:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 61E27186EB Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 29 Nov 2013 22:12:55 -0500 From: Glen Barber To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: 10.0-RELEASE status update Message-ID: <20131130031255.GG31807@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v2/QI0iRXglpx0hK" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 30 Nov 2013 03:13:01 -0000 --v2/QI0iRXglpx0hK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Quick 10.0-RELEASE status update: - iconv(3) changes have been made in head/, and merged to stable/10 today. - Two MFCs are undergoing review, one of which I will commit right before updating the stable/10 branch name to reflect '-BETA4'.[1] - Builds for 10.0-BETA4 will begin tomorrow. The schedule page on the website will be updated to reflect the start of the -BETA4 builds, as well as updating the remainder of the schedule to reflect the adjustments after the delay. [1] - Important note to those tracking stable/10: An update will be committed tomorrow that will disable automatic creation of pkg.conf(5). Those installing new systems from 10.0-BETA4 should experience no trouble, as the update pkg(8) version (pkg-1.2.1) should be available around the same time 10.0-BETA4 is announced. This affects the pkg(8) bootstrap functionality *only*. Those with bootstrapped pkg(8) will not be affected. For those doing source-based upgrades from stable/10 *and* do not have pkg(8) already bootstrapped, there will be a brief (about 1 day, "brief" being relative) window of time where pkg(8) (versions less than 1.2) will not have a pre-configured pkg.conf(5). This will also be noted in the 10.0-BETA4 announcement mail.[2] [2] - I believe this is a non-issue, since usr.sbin/pkg/config.c has pkg.FreeBSD.org set as the packagesite, but I am sure I am overlooking something obvious that will prove me wrong. So, that is why the "important note" is longer than the actual status update. :-) Thank you for your patience. Glen On behalf of: re@ --v2/QI0iRXglpx0hK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSmVe3AAoJELls3eqvi17Qyd8QAIjFXgxYx+I7uXGvycYuMH0N lgoZBfonPmu5JBYDEjIQtzBpnQg0B+NWHshgIErPArMYC9nhNXhRhNdgoqrW+IEm 0YIv8Nrp05z27paGR4m7PMN1KhD1tv/NtosAhUB/LIFnswLxEPR5nHmLWs1HNGkh iZNGzGc9fxcMMPwpetJjhdxkUmyoPa5QAaMpc/Z1dfBIm88OTXdD3BhlIKAmnPIm l5qpY1mShh018zDerh28STlja8MUwAt957ei8TsalrA9F3z+FUB7K18C1Vmu+mEn l2pFtprkAsE6vZ4a2Pu+skB8CqN78a7qF4+3RhiPw/HMSaK3bzOsOcyFlPgV3qPB MtE3gZA33dgqNO8pQyA4sWRtchyVnZXbmf+ZBF08RSMtxd1NXcZub5y4su81WL21 Wor6uy3X3CiV1BifvEss2oXBwmEWHkk4EpVlAz6GzmwJvhqoM6Zg7H05347EZBLW tjyAFr7lMXyDTYksIULomS8SI/yOS16pjP4ubjXhQdi0lJD0qiBrgA6bvz3F5Uga CYLSzWbPKdhGN0G7kKJP1kNFsslJEAfHOGHYoiWsW84exx7wlxoJY7ZSLve0DIXS zQZWQLiqrzYXvEEt4bSgEiXMAdsoSSZU/YKXAJ+eORaatP03NxTmnbmXhf8AT7J2 EfcOZl2QzZVE1uyg2ZGG =y+5d -----END PGP SIGNATURE----- --v2/QI0iRXglpx0hK-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 30 03:28:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 377D9610 for ; Sat, 30 Nov 2013 03:28:40 +0000 (UTC) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id E28971451 for ; Sat, 30 Nov 2013 03:28:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date; bh=ZDzLg/xdkRdzLZZN2D2OdmASzL3IGjmiMgKR9rrO6co=; b=BQYBZFfiXcWqD6wBd9+naCMxN1nZ/LF+iiExHGDoI6nmgVi7wnspCC9TP4mzD94dZ3H3kJQwOX7dads8JcylxxEJ5DpuWtX+SIYQEIe49vdGjWzQHZmnHvrQcTPL9esH0/vIiz+Lf5PyyWH7+drheKxQvi6ziWXKbjgoXELBuRw=; Received: from iglou3.iglou.com ([192.107.41.6]:37052 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1VmbEU-0001o3-Ob by authid with igloumta_auth for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 22:28:38 -0500 Received: from shell1.iglou.com ([192.107.41.17]:63559 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1VmbEU-0000n5-9L for freebsd-stable@freebsd.org; Fri, 29 Nov 2013 22:28:38 -0500 Date: Fri, 29 Nov 2013 22:28:34 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: freebsd-stable@freebsd.org Subject: Re: kernel "mismatch" on r256420 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 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, 30 Nov 2013 03:28:40 -0000 >>> I installed FreeBSD 10 from a BETA cd-rom. I chose 'experimental ZFS on >>> root - mirror'. The FreeBSD firewall will not load. Any suggestions? >>> >>> This is from 'dmesg': >>> >>> KLD ipfw.ko: depends on kernel - not available or version mismatch >>> linker_load_file: Unsupported file type >>> >>> This is from 'ls -l' of /boot >>> drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/ >>> >>> This is from 'ls -l' of /bootpool/boot >>> drwxr-xr-x 2 root wheel 1.5K Nov 28 21:55 kernel/> >> >> It *is* a mismatch! The output of 'uname -i': >> >> GENERIC >> >> I should update again, but am almost certain that KERNCONF= was in my last >> update. >> > > In the existing versions of my 'ZFS mirror root' there is no directory called > BOOTPOOL. I suspect something is not in sync with UPGRADING and the > experimental sysinstall, or whatever it is currently called. > > I did not use the installer menu to make the earlier versions of ZFS on root. > I typed commands. > > Anyhow, I ran svn and now 'make buildworld' is running- revision 258748 > This is driving me insane. I put my kernel into /usr/src/sys/amd64/conf/ and made a backup of it in /root/kernels. The link from /usr/src/sys/amd64/conf was removed before I built the kernel yet again. The firewall still does not load and the output of 'uname -i' is GENERIC. Does anyone have an idea of how I could install my kernel? When I look at the ascii spray it seems like it is actually building my custom kernel. When I install it with 'make installkernel KERNCONF=THIS', reboot and it turns out GENERIC. Darrel From owner-freebsd-stable@FreeBSD.ORG Sat Nov 30 20:16:24 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52966E02; Sat, 30 Nov 2013 20:16:24 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86C1B1739; Sat, 30 Nov 2013 20:16:19 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id rAUKG9H3015954; Sat, 30 Nov 2013 22:16:09 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id rAUKG8pH015867; Sat, 30 Nov 2013 20:16:08 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Nov 2013 20:16:08 GMT Message-Id: <201311302016.rAUKG8pH015867@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 20:16:24 -0000 TB --- 2013-11-30 19:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-30 19:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-30 19:50:43 - starting RELENG_10 tinderbox run for armv6/arm TB --- 2013-11-30 19:50:43 - cleaning the object tree TB --- 2013-11-30 19:50:43 - /usr/local/bin/svn stat /src TB --- 2013-11-30 19:51:31 - At svn revision 258775 TB --- 2013-11-30 19:51:32 - building world TB --- 2013-11-30 19:51:32 - CROSS_BUILD_TESTING=YES TB --- 2013-11-30 19:51:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-30 19:51:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-30 19:51:32 - SRCCONF=/dev/null TB --- 2013-11-30 19:51:32 - TARGET=arm TB --- 2013-11-30 19:51:32 - TARGET_ARCH=armv6 TB --- 2013-11-30 19:51:32 - TZ=UTC TB --- 2013-11-30 19:51:32 - __MAKE_CONF=/dev/null TB --- 2013-11-30 19:51:32 - cd /src TB --- 2013-11-30 19:51:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Nov 30 19:51:42 UTC 2013 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp -o CGDeclCXX.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp -o CGException.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.armv6/src/tmp\" -I/obj/arm.armv6/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp -o CGExpr.o /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp: In member function 'void clang::CodeGen::CodeGenFunction::EmitStoreThroughLValue(clang::CodeGen::RValue, clang::CodeGen::LValue, bool)': /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:1423: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangcodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2013-11-30 20:16:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-30 20:16:07 - ERROR: failed to build world TB --- 2013-11-30 20:16:07 - 1123.08 user 401.57 system 1524.78 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-armv6-arm.full