From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 03:12:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A877E44B for ; Tue, 1 Jan 2013 03:12:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6485D8FC08 for ; Tue, 1 Jan 2013 03:12:04 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so11822940obc.41 for ; Mon, 31 Dec 2012 19:12:03 -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=p5JYNly2ii7rtlqA5Z+UVeOcnVNPIdrU+48JmYje1+Q=; b=DS52hRiqNg7IQVJmg9DYL1CYs3ChiFCD9dmnHLvoaGYcxvubfaeo7nBz7Ns/n57D+P gdSFut9kcz4cpgBXBoE/gxc+tYtgvDPztX6VOk+zWta1wOiGCWyzd/Czs3u+rysZPi0Q O1boAxjbT9nNfQWZ67wJ76ZnQ9Jkym0INl04fk8W7nfJqxzqxp9m0TXRaxTw/Nvz3/PV slf+AdSqNHJE62U7Xm2h9cDCirpopdDh28ID/hghzeoQ56VQKE8AQSrZRXi/o1Amk5Hw k+7gsR05jscCIjDQs2DYSs2CRTyVOK4bFoVOjmMfWMLb6br6XbWZK0aVkitG15zR6BaY Hkqw== MIME-Version: 1.0 Received: by 10.182.77.230 with SMTP id v6mr11957254obw.66.1357009923595; Mon, 31 Dec 2012 19:12:03 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 31 Dec 2012 19:12:03 -0800 (PST) In-Reply-To: References: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> Date: Mon, 31 Dec 2012 19:12:03 -0800 Message-ID: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd From: Garrett Cooper To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Cc: Rick Macklem , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 03:12:04 -0000 On Mon, Dec 31, 2012 at 7:08 PM, Benjamin Kaduk wrote: ... > src.conf(5) is (well, should be) authoritative for WITH_ and WITHOUT_ flags. Just to be clear because my reply was a bit ambiguous, I was referring to the C sourcecode, not the Makefiles :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 03:13:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EF59560 for ; Tue, 1 Jan 2013 03:13:59 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1621E8FC08 for ; Tue, 1 Jan 2013 03:13:58 +0000 (UTC) X-AuditID: 1209190e-b7fa16d000001402-38-50e25344e693 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C6.92.05122.44352E05; Mon, 31 Dec 2012 22:08:52 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r0138qaa007761; Mon, 31 Dec 2012 22:08:52 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id r0138nPQ011676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Dec 2012 22:08:51 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r0138nAF023828; Mon, 31 Dec 2012 22:08:49 -0500 (EST) Date: Mon, 31 Dec 2012 22:08:49 -0500 (EST) From: Benjamin Kaduk To: Garrett Cooper Subject: Re: svn commit: r244604 - head/usr.sbin/gssd In-Reply-To: Message-ID: References: <1905046872.1604317.1356954929867.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nousS/CjAYM9KMYs5bz4wWTxcdo3J Yv33ZYwOzB4zPs1n8dg56y67x+/Ne5kCmKO4bFJSczLLUov07RK4MvoXOhW8Ya14cegsYwPj WZYuRk4OCQETif+f57NB2GISF+6tB7OFBPYxSpy7Id7FyAVkb2CUeHh6IlTiBJPExa9qEIkG RokPcxexgiRYBLQlHu5qYwex2QRUJGa+2QjWICKgLnHpwBagOAcHs4CLxOaFlSBhYQFTiQ/t q8FKOAUCJdbM38gIYvMKOEo0TfvKCDH/FqPE0Y6rTCAJUQEdidX7p7BAFAlKnJz5BMxmFrCU OPfnOtsERsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECApd Tkm+HYxfDyodYhTgYFTi4U14+jBAiDWxrLgy9xCjJAeTkijv0qBHAUJ8SfkplRmJxRnxRaU5 qcWHGCU4mJVEeE/dAyrnTUmsrEotyodJSXOwKInzXkm56S8kkJ5YkpqdmlqQWgSTleHgUJLg LQMZKliUmp5akZaZU4KQZuLgBBnOAzS8E6SGt7ggMbc4Mx0if4pRUUqctw0kIQCSyCjNg+uF pZZXjOJArwjzdoNU8QDTElz3K6DBTECDtRgegAwuSURISTUwTlRYljf/+KaHBsbFt76VbLto lZyzUuB08eSOHCPjiU3/qr0KLqxgr44TsK2dvvqL+cE9h87YmrqedeLxmiYgJBgcN0U9eMK/ lV+fNhyUfhe6XJ7xsdKzUxN4Ll89tG5RYcKS9r9vLY89LmndfGSTTk2y4BWT/UvmtzgJ1aoV tl0MvO6SqPK0UImlOCPRUIu5qDgRAPO6oGIIAwAA Cc: Rick Macklem , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 03:13:59 -0000 On Mon, 31 Dec 2012, Garrett Cooper wrote: > On Mon, Dec 31, 2012 at 3:55 AM, Rick Macklem wrote: > > ... > >> WITHOUT_KERBEROS is used other places, like telnetd. Were you aware of that? >> (I just thought it would keep it consistent, but if you think it is better >> to use a different name, I don't care.) > > Ah, no. I wasn't aware of that :). Given that something else has been > standardized around the tree, I agree that your approach of using > WITHOUT_KERBEROS is ok. I wasn't keen on the name just because it > could have simplified the code using a positive instead of a negative > predicate in the #ifdef. src.conf(5) is (well, should be) authoritative for WITH_ and WITHOUT_ flags. -Ben From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 07:27:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19642361; Tue, 1 Jan 2013 07:27:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D26138FC14; Tue, 1 Jan 2013 07:27:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r017RFBR006335; Tue, 1 Jan 2013 02:27:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r017RFYC006309; Tue, 1 Jan 2013 07:27:15 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Jan 2013 07:27:15 GMT Message-Id: <201301010727.r017RFYC006309@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 07:27:17 -0000 TB --- 2013-01-01 06:25:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-01 06:25:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-01 06:25:39 - starting HEAD tinderbox run for mips64/mips TB --- 2013-01-01 06:25:39 - cleaning the object tree TB --- 2013-01-01 06:27:03 - /usr/local/bin/svn stat /src TB --- 2013-01-01 06:27:06 - At svn revision 244918 TB --- 2013-01-01 06:27:07 - building world TB --- 2013-01-01 06:27:07 - CROSS_BUILD_TESTING=YES TB --- 2013-01-01 06:27:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-01 06:27:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-01 06:27:07 - SRCCONF=/dev/null TB --- 2013-01-01 06:27:07 - TARGET=mips TB --- 2013-01-01 06:27:07 - TARGET_ARCH=mips64 TB --- 2013-01-01 06:27:07 - TZ=UTC TB --- 2013-01-01 06:27:07 - __MAKE_CONF=/dev/null TB --- 2013-01-01 06:27:07 - cd /src TB --- 2013-01-01 06:27:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jan 1 06:27:11 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 Tue Jan 1 07:26:57 UTC 2013 TB --- 2013-01-01 07:26:57 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:57 - /usr/sbin/config -m ADM5120 TB --- 2013-01-01 07:26:57 - skipping ADM5120 kernel TB --- 2013-01-01 07:26:57 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:57 - /usr/sbin/config -m ALCHEMY TB --- 2013-01-01 07:26:57 - skipping ALCHEMY kernel TB --- 2013-01-01 07:26:57 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:57 - /usr/sbin/config -m AP91 TB --- 2013-01-01 07:26:57 - skipping AP91 kernel TB --- 2013-01-01 07:26:57 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:57 - /usr/sbin/config -m AP93 TB --- 2013-01-01 07:26:57 - skipping AP93 kernel TB --- 2013-01-01 07:26:57 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:57 - /usr/sbin/config -m AP94 TB --- 2013-01-01 07:26:58 - skipping AP94 kernel TB --- 2013-01-01 07:26:58 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:58 - /usr/sbin/config -m AP96 TB --- 2013-01-01 07:26:58 - skipping AP96 kernel TB --- 2013-01-01 07:26:58 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:58 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-01-01 07:26:58 - skipping AR71XX_BASE kernel TB --- 2013-01-01 07:26:58 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:58 - /usr/sbin/config -m AR724X_BASE TB --- 2013-01-01 07:26:58 - skipping AR724X_BASE kernel TB --- 2013-01-01 07:26:58 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:58 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-01-01 07:26:58 - skipping AR91XX_BASE kernel TB --- 2013-01-01 07:26:58 - cd /src/sys/mips/conf TB --- 2013-01-01 07:26:58 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-01-01 07:26:58 - building BERI_DE4_MDROOT kernel TB --- 2013-01-01 07:26:58 - CROSS_BUILD_TESTING=YES TB --- 2013-01-01 07:26:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-01 07:26:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-01 07:26:58 - SRCCONF=/dev/null TB --- 2013-01-01 07:26:58 - TARGET=mips TB --- 2013-01-01 07:26:58 - TARGET_ARCH=mips64 TB --- 2013-01-01 07:26:58 - TZ=UTC TB --- 2013-01-01 07:26:58 - __MAKE_CONF=/dev/null TB --- 2013-01-01 07:26:58 - cd /src TB --- 2013-01-01 07:26:58 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Tue Jan 1 07:26:58 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/linker_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h rm -f .newdep /obj/src/make.amd64/make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding In file included from /src/sys/dev/fdt/fdt_common.h:37, from /src/sys/mips/beri/beri_machdep.c:58: /src/sys/dev/ofw/ofw_bus.h:36:24: error: ofw_bus_if.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-01 07:27:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-01 07:27:15 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-01-01 07:27:15 - 2677.74 user 595.41 system 3695.53 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 08:40:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACE3C9EB for ; Tue, 1 Jan 2013 08:40:33 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5848FC08 for ; Tue, 1 Jan 2013 08:40:33 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id k25so11255001iah.9 for ; Tue, 01 Jan 2013 00:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5RkAeoGfhmUQXoviqHE8W3tGl8gid3T/kYWXp2yxLu0=; b=nUfzqjtNQFa8lr0PHNo1YwCvixFILZ0Zx15VHKO1e/wxkJOkdVNTKndsSNSekpUU7E QCseYFpXtdNU3EF1UgzBQrDEWBJ/pECSA7Ohl4ay/i3NYVvl3TV+6vQ8fzfsZ/J5y+P8 GbpDXEYjb3750Shq4oO0UlXEGG01BOs/NvqIG05xDQYU7Ob65GaUh9nP0wmGdkUcJAUf urCbf5/FhFym67uDbp4raEqKG969dbFjYJYbk4LAHKqCsOPYPT9nB6gGN/8e+cim/uNT cVqtauuUCbqXdTIFDStnobQqLCJNRuBQXvujLo/mwg+zuMOvl5Qf5nMCRasuoiXigfwQ 6OEA== MIME-Version: 1.0 Received: by 10.50.42.232 with SMTP id r8mr31959139igl.100.1357029631128; Tue, 01 Jan 2013 00:40:31 -0800 (PST) Received: by 10.50.88.137 with HTTP; Tue, 1 Jan 2013 00:40:31 -0800 (PST) In-Reply-To: References: <44353525.1604353.1356956294487.JavaMail.root@erie.cs.uoguelph.ca> <419702074.1604361.1356956417866.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 1 Jan 2013 08:40:31 +0000 Message-ID: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd From: "b.f." To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 08:40:33 -0000 On 1/1/13, b.f. wrote: > On 12/31/12, Rick Macklem wrote: >> Rick Macklem wrote: >>> Rick Macklem wrote: >>> > Garrett Cooper wrote: >>> > > On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem >>> > > >>> > > wrote: >>> > > > bf1783 wrote: >>> > > >> >Author: rmacklem >>> > > >> >Date: Sat Dec 22 23:21:17 2012 >>> > > >> >New Revision: 244604 >>> > > >> >URL: http://svnweb.freebsd.org/changeset/base/244604 > >>> > > >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. > >>> > > > Could you please test the attached patch. > >> Oh, and I've attached the updated patch, rick > > Your patch fixes the build problem. I leave it to you to decide > whether, if gssd is so dependent upon the Kerberos mechanism support, > it should be built at all when base system Kerberos isn't available. > And also, if it is to be built, whether your additions should depend > upon MK_KERBEROS_SUPPORT or MK_KERBEROS (the former is implied by the > latter, but the converse isn't true). Of course, I meant above that WITHOUT_KERBEROS_SUPPORT is implied by WITHOUT_KERBEROS, and that the converse isn't true. b. From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 08:41:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E71BAF7 for ; Tue, 1 Jan 2013 08:41:28 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ia0-f170.google.com (mail-ia0-f170.google.com [209.85.210.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8CD8FC13 for ; Tue, 1 Jan 2013 08:41:27 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id i1so11094465iaa.1 for ; Tue, 01 Jan 2013 00:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uXfANJo6WAvens9/dIoJQ588W1aSP+XqzqTBCypEZ6w=; b=ciXpK4yRCbGU7zZOWfTsbvtTW02luxxZrcVaS0TukK4zQ1LhbBoUdaD7wtSoW5WEWo DGi2W7hTBNVHn8C3fg197v8OZ+nIbmzC9OoXrJCKhLOtWXlK4EtX6J2PkIr7I+EufiMR tVGuQkdqiLBT4hhjWyQieyCk0w36uLHvzIPQ6z9DVyrEOQP1S7YsFxihmOf7lOxSCx+O veKS4eQt7G4HxFDFWH1Far91WAU94pV946nX/9nJhddcNMswsqviWNP/mhxpkw7KwcQ8 gyVWys15NxFGGMkO7oGMsn5X6NlAAcJ3NWXijswfANp2+g0fy19+ULu+778sTjm9vmjI OVmw== MIME-Version: 1.0 Received: by 10.50.42.232 with SMTP id r8mr31954118igl.100.1357029355587; Tue, 01 Jan 2013 00:35:55 -0800 (PST) Received: by 10.50.88.137 with HTTP; Tue, 1 Jan 2013 00:35:55 -0800 (PST) In-Reply-To: <419702074.1604361.1356956417866.JavaMail.root@erie.cs.uoguelph.ca> References: <44353525.1604353.1356956294487.JavaMail.root@erie.cs.uoguelph.ca> <419702074.1604361.1356956417866.JavaMail.root@erie.cs.uoguelph.ca> Date: Tue, 1 Jan 2013 08:35:55 +0000 Message-ID: Subject: Re: svn commit: r244604 - head/usr.sbin/gssd From: "b.f." To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 08:41:28 -0000 On 12/31/12, Rick Macklem wrote: > Rick Macklem wrote: >> Rick Macklem wrote: >> > Garrett Cooper wrote: >> > > On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem >> > > >> > > wrote: >> > > > bf1783 wrote: >> > > >> >Author: rmacklem >> > > >> >Date: Sat Dec 22 23:21:17 2012 >> > > >> >New Revision: 244604 >> > > >> >URL: http://svnweb.freebsd.org/changeset/base/244604 >> > > >> This breaks world built WITHOUT_KERBEROS and WITH_GSSAPI. >> > > > Could you please test the attached patch. > Oh, and I've attached the updated patch, rick Your patch fixes the build problem. I leave it to you to decide whether, if gssd is so dependent upon the Kerberos mechanism support, it should be built at all when base system Kerberos isn't available. And also, if it is to be built, whether your additions should depend upon MK_KERBEROS_SUPPORT or MK_KERBEROS (the former is implied by the latter, but the converse isn't true). Thanks and Happy New Year, b. From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 10:47:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458333FE for ; Tue, 1 Jan 2013 10:47:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id B60D88FC0A for ; Tue, 1 Jan 2013 10:47:27 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r01AMut6036859; Tue, 1 Jan 2013 14:22:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r01AMtdu036858; Tue, 1 Jan 2013 14:22:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 1 Jan 2013 14:22:55 +0400 From: Gleb Smirnoff To: Manfred Antar Subject: Re: loopback interface broken on current Message-ID: <20130101102255.GA25661@FreeBSD.org> References: <201212271705.qBRH5VHU006208@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201212271705.qBRH5VHU006208@pozo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 10:47:29 -0000 Manfred, On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote: M> For the past few days the loopback interface 127.0.0.1 is broken on current. M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012 M> Here are some of the errors from current today: Can you please track this down to the specific revision that made the regression? The timeframe is samll, so binary search probably won't take long time. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 17:39:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57FDD28A; Tue, 1 Jan 2013 17:39:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1B78FC0A; Tue, 1 Jan 2013 17:39:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r01HdWtn059556; Tue, 1 Jan 2013 12:39:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r01HdWnZ059542; Tue, 1 Jan 2013 17:39:32 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Jan 2013 17:39:32 GMT Message-Id: <201301011739.r01HdWnZ059542@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 17:39:35 -0000 TB --- 2013-01-01 16:38:04 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-01 16:38:04 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-01 16:38:04 - starting HEAD tinderbox run for mips64/mips TB --- 2013-01-01 16:38:04 - cleaning the object tree TB --- 2013-01-01 16:39:20 - /usr/local/bin/svn stat /src TB --- 2013-01-01 16:39:23 - At svn revision 244923 TB --- 2013-01-01 16:39:24 - building world TB --- 2013-01-01 16:39:24 - CROSS_BUILD_TESTING=YES TB --- 2013-01-01 16:39:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-01 16:39:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-01 16:39:24 - SRCCONF=/dev/null TB --- 2013-01-01 16:39:24 - TARGET=mips TB --- 2013-01-01 16:39:24 - TARGET_ARCH=mips64 TB --- 2013-01-01 16:39:24 - TZ=UTC TB --- 2013-01-01 16:39:24 - __MAKE_CONF=/dev/null TB --- 2013-01-01 16:39:24 - cd /src TB --- 2013-01-01 16:39:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jan 1 16:39:28 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 Tue Jan 1 17:39:15 UTC 2013 TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m ADM5120 TB --- 2013-01-01 17:39:15 - skipping ADM5120 kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m ALCHEMY TB --- 2013-01-01 17:39:15 - skipping ALCHEMY kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AP91 TB --- 2013-01-01 17:39:15 - skipping AP91 kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AP93 TB --- 2013-01-01 17:39:15 - skipping AP93 kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AP94 TB --- 2013-01-01 17:39:15 - skipping AP94 kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AP96 TB --- 2013-01-01 17:39:15 - skipping AP96 kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-01-01 17:39:15 - skipping AR71XX_BASE kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AR724X_BASE TB --- 2013-01-01 17:39:15 - skipping AR724X_BASE kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-01-01 17:39:15 - skipping AR91XX_BASE kernel TB --- 2013-01-01 17:39:15 - cd /src/sys/mips/conf TB --- 2013-01-01 17:39:15 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-01-01 17:39:15 - building BERI_DE4_MDROOT kernel TB --- 2013-01-01 17:39:15 - CROSS_BUILD_TESTING=YES TB --- 2013-01-01 17:39:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-01 17:39:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-01 17:39:15 - SRCCONF=/dev/null TB --- 2013-01-01 17:39:15 - TARGET=mips TB --- 2013-01-01 17:39:15 - TARGET_ARCH=mips64 TB --- 2013-01-01 17:39:15 - TZ=UTC TB --- 2013-01-01 17:39:15 - __MAKE_CONF=/dev/null TB --- 2013-01-01 17:39:15 - cd /src TB --- 2013-01-01 17:39:15 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Tue Jan 1 17:39:15 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/linker_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h rm -f .newdep /obj/src/make.amd64/make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=mips64 -mabi=64 -msoft-float -ffreestanding In file included from /src/sys/dev/fdt/fdt_common.h:37, from /src/sys/mips/beri/beri_machdep.c:58: /src/sys/dev/ofw/ofw_bus.h:36:24: error: ofw_bus_if.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 Stop in /obj/mips.mips64/src/sys/BERI_DE4_MDROOT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-01 17:39:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-01 17:39:32 - ERROR: failed to build BERI_DE4_MDROOT kernel TB --- 2013-01-01 17:39:32 - 2676.54 user 594.33 system 3687.78 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 17:46:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558E0547 for ; Tue, 1 Jan 2013 17:46:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0693A8FC0C for ; Tue, 1 Jan 2013 17:46:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tq5um-0003qx-Uj for freebsd-current@freebsd.org; Tue, 01 Jan 2013 18:46:12 +0100 Received: from 50-46-160-143.evrt.wa.frontiernet.net ([50.46.160.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2013 18:46:12 +0100 Received: from atkin901 by 50-46-160-143.evrt.wa.frontiernet.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Jan 2013 18:46:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: loopback interface broken on current Date: Tue, 01 Jan 2013 09:45:45 -0800 Lines: 20 Message-ID: References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 50-46-160-143.evrt.wa.frontiernet.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <20130101102255.GA25661@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 17:46:08 -0000 On 1/1/2013 2:22 AM, Gleb Smirnoff wrote: > Manfred, > > On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote: > M> For the past few days the loopback interface 127.0.0.1 is broken on current. > M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012 > M> Here are some of the errors from current today: > > Can you please track this down to the specific revision that made the > regression? The timeframe is samll, so binary search probably won't > take long time. > > nc -l 127.0.0.1 works for me on r244911 From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 01:21:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74B45989; Tue, 1 Jan 2013 01:21:17 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2C08B8FC13; Tue, 1 Jan 2013 01:21:16 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r011LE8U059818; Mon, 31 Dec 2012 20:21:15 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 31 Dec 2012 20:21:15 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: CFT: Overhauled CPSW driver for BeagleBone Message-ID: <20121231202115.10615df6@ivory.wynn.com> In-Reply-To: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> References: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Jan 2013 17:48:34 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 01:21:17 -0000 Greeting- This is a follow up to my previous private message about how your driver is working on my BeagleBone. wynkoop@beaglebone:~ % w 8:15PM up 15:17, 2 users, load averages: 0.05, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT root u0 - 5:00AM 3:36 -csh (csh) wynkoop pts/0 cherry.wynn.com 2:05PM - w wynkoop@beaglebone:~ % date Mon Dec 31 20:15:13 EST 2012 wynkoop@beaglebone:~ % As you can see I am logged in on pts/0 since 2:05PM. I was never able to keep an ssh connection alive more than 30-40 min with the driver that is in head. I think you should check it into head now so people setting up new BBs get the benefit. As discussed off list there is still room for improvement, but I think that can be better handled if this much more stable driver goes into the tree sooner rather than later. It will allow for more testing and feedback to assist with the next round of improvements. This thing is running so well now that I am about to put a web server on the box and give it a static IP address. Once we have USB I think the BB will become my primary mail and web server......Think of the power I will save! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 16:12:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEDCAA1; Tue, 1 Jan 2013 16:12:50 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF718FC0C; Tue, 1 Jan 2013 16:12:49 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r01GCl0A071385; Tue, 1 Jan 2013 11:12:47 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 1 Jan 2013 11:12:47 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: CFT: Overhauled CPSW driver for BeagleBone Message-ID: <20130101111247.734a45fd@ivory.wynn.com> In-Reply-To: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> References: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Jan 2013 17:56:15 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 16:12:50 -0000 On Mon, 31 Dec 2012 15:25:15 -0800 Tim Kientzle wrote: > I've made some progress reworking the CPSW driver for > BeagleBone and would appreciate any feedback: > > https://github.com/kientzle/cpsw > Greeting- The driver is working much better than the driver currently in head. I have maintained an ssh connection to the BeagleBone for more than 24 hours! Thanks so much Tim! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 18:11:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EAB7A6D for ; Tue, 1 Jan 2013 18:11:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id CFB368FC0A for ; Tue, 1 Jan 2013 18:11:42 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id oi10so12316838obb.12 for ; Tue, 01 Jan 2013 10:11:36 -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=JFzEuV3D8BVZ1j/u4++JCcvOKMG0U9t6Icf7EHNxzJs=; b=v4tgrMDaMa7emAWVUg3uco6hTS5weD6hJ0BMS/JsrlMtzUQk/NoBeMACnA4q+MMTvJ jHVrHyY0HcW5B485grDZzMdiHURtOR8La2ypSuyjP2BhtF8f4z9LpDBt4hfsziH/EV+p S+UgQgmEVvp8ltbsZu3+YGIY1DBTXJNQmJUTFk3I+vGBp1MgYQeBaWNEeaaYQfOfrOkK HF3w6w/RvagW7LQGOK9Bevf1uxktf2hTs9qDM/DWyDTd2m4Tu03L3MxqMUzJoL9WiRb9 aj8F3iW4ljr59NGlZEgcLfLO+wkL6ppqXqDCZpFuEsq8fKgMvu5DLAcQM4vWWSGumBss Y8Ag== MIME-Version: 1.0 Received: by 10.182.131.100 with SMTP id ol4mr36405010obb.38.1357063589865; Tue, 01 Jan 2013 10:06:29 -0800 (PST) Received: by 10.76.143.33 with HTTP; Tue, 1 Jan 2013 10:06:29 -0800 (PST) In-Reply-To: References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> Date: Tue, 1 Jan 2013 10:06:29 -0800 Message-ID: Subject: Re: loopback interface broken on current From: Garrett Cooper To: Mark Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 18:11:43 -0000 Maybe it's this commit? HTH, -Garrett ------------------------------------------------------------------------ r244678 | glebius | 2012-12-25 05:01:58 -0800 (Tue, 25 Dec 2012) | 17 lines The SIOCSIFFLAGS ioctl handler runs if_up()/if_down() that notify all interested parties in case if interface flag IFF_UP has changed. However, not only SIOCSIFFLAGS can raise the flag, but SIOCAIFADDR and SIOCAIFADDR_IN6 can, too. The actual |= is done not in the protocol code, but in code of interface drivers. To fix this historical layering violation, we will check whether ifp->if_ioctl(SIOCSIFADDR) raised the IFF_UP flag, and if it did, run the if_up() handler. This fixes configuring an address under CARP control on an interface that was initially !IFF_UP. P.S. I intentionally omitted handling the IFF_SMART flag. This flag was never ever used in any driver since it was introduced, and since it means another layering violation, it should be garbage collected instead of pretended to be supported. From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 18:56:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D625C9E3; Tue, 1 Jan 2013 18:56:09 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AAB238FC0A; Tue, 1 Jan 2013 18:56:09 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r01ItxUH022302; Tue, 1 Jan 2013 18:55:59 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 6fd5rv5n492syx9zphkdyv7hk6; Tue, 01 Jan 2013 18:55:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: CFT: Overhauled CPSW driver for BeagleBone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130101111247.734a45fd@ivory.wynn.com> Date: Tue, 1 Jan 2013 10:55:58 -0800 Content-Transfer-Encoding: 7bit Message-Id: <0DD7F54B-20CF-42B5-A83E-29E8CF58D390@freebsd.org> References: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> <20130101111247.734a45fd@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 18:56:09 -0000 On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote: > On Mon, 31 Dec 2012 15:25:15 -0800 > Tim Kientzle wrote: > >> I've made some progress reworking the CPSW driver for >> BeagleBone and would appreciate any feedback: >> >> https://github.com/kientzle/cpsw >> > Greeting- > > The driver is working much better than the driver currently in head. I > have maintained an ssh connection to the BeagleBone for more than 24 > hours! Just committed this to -CURRENT r244939. Tim From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 20:42:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFDA222D; Tue, 1 Jan 2013 20:42:58 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 751498FC0A; Tue, 1 Jan 2013 20:42:58 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r01Kgq6E001548 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Tue, 1 Jan 2013 12:42:53 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201301012042.r01Kgq6E001548@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Jan 2013 12:42:47 -0800 To: Gleb Smirnoff From: Manfred Antar Subject: Re: loopback interface broken on current In-Reply-To: <20130101194803.GB25661@glebius.int.ru> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r01Kgq6E001548 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 20:42:58 -0000 At 11:48 AM 1/1/2013, Gleb Smirnoff wrote: >On Tue, Jan 01, 2013 at 02:39:58AM -0800, Manfred Antar wrote: >M> >On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote: >M> >M> For the past few days the loopback interface 127.0.0.1 is broken on current. >M> >M> The last good kernel that works for me is r244662: Mon Dec 24 06:43:07 PST 2012 >M> >M> Here are some of the errors from current today: >M> > >M> >Can you please track this down to the specific revision that made the >M> >regression? The timeframe is samll, so binary search probably won't >M> >take long time. >M> Hi >M> I'm not sure how to do this :( >M> I just switched from CVS to SVN 2 weeks ago. >M> I still have a current CVS tree on my machine. >M> I guess i can try to check out a /usr/src/sys from the 25 on and see what changes were made. >M> I'm just learning SVN so not sure how to do it with that. > >With SVN you don't need to care about dates, you just go through the >sequential list of revisions. So you just seek between r244662 and the >most recent revision tht didn't work for you. On first step you >divide the bad revision (let it be 244768) and good one r244662: > >(244662 + 244768)/2 = 244715 > >Ok, it is 244715. Let's take it and test: > >svn up -r 244715 > >If it is fine, you check the one in the middle between 244715and >244768. Otherwise you chek in between 244715 and 244662. And so on... > >-- >Totus tuus, Glebius. OK I tracked it down to revision 244678 244677 works the files involved are: (src)5012}svn up -r 244678 Updating '.': U sys/netinet/in.c U sys/netinet6/in6.c Updated to revision 244678 It seems like the ip6 for localhost is configured but ip4 isn't: Setting hostname: pozo.com. ifa_del_loopback_route: deletion failed: 3 ifconfig: ioctl (SIOCAIFADDR): File exists bge0: link state changed to DOWN ifa_del_loopback_route: deletion failed: 3 lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=21 From 244677: Setting hostname: pozo.com. Starting Network: lo0 bge0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=21 Manfred ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 21:26:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B71ECA9 for ; Tue, 1 Jan 2013 21:26:49 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id E84658FC08 for ; Tue, 1 Jan 2013 21:26:47 +0000 (UTC) Received: from [79.164.58.122] (port=46796 helo=dc7700p.lissyara.su) by mx.lissyara.su with esmtpa (Exim 4.80 (FreeBSD)) (envelope-from ) id 1Tq8jd-000Eqh-R5 for current@freebsd.org; Wed, 02 Jan 2013 00:46:53 +0400 Message-ID: <50E34B3D.40104@lissyara.su> Date: Wed, 02 Jan 2013 00:46:53 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@freebsd.org Subject: fsck problem Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 21:26:49 -0000 Starting file system checks: /dev/label/rootFS: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/rootFS: clean, 11916812 free (74068 frags, 1480343 blocks, 0.5% fragmentation) ** SU+J Recovering /dev/label/homeFS ** Reading 33554432 byte journal from inode 12. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck_ufs: Directory 1136967 name not found THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/label/homeFS (/home) Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jan 2 04:35:11 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # g\^H\^[[Kfsck -y .home fsck: cannot open `/dev/.home': No such file or directory # fsck -y .home\^H\^H\^H\^H\^Hhome\^[[K\^H\^H\^H\^H/home\^H\^H\^H\^H twa0: INFO: (0x04: 0x0029): Verify started: unit=0, subunit=1 twa0: INFO: (0x04: 0x0029): Verify started: unit=0, subunit=0 ** /dev/label/homeFS USE JOURNAL? yes ** SU+J Recovering /dev/label/homeFS ** Reading 33554432 byte journal from inode 12. RECOVER? yes ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. fsck_ufs: Directory 1136967 name not found # tunefs -j disable .\^H\^[[K/home Clearing journal flags from inode 12 tunefs: soft updates journaling cleared but soft updates still set. tunefs: remove .sujournal to reclaim space # tunefs -j disable /home\^[[23D\^[[10Pfsck -y\^[[6C ** /dev/label/homeFS ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=48071192 OWNER=www MODE=100600 SIZE=5472256 MTIME=Jan 1 23:59 2013 CLEAR? yes UNREF FILE I=48071193 OWNER=www MODE=100600 SIZE=3538944 MTIME=Jan 2 00:01 2013 CLEAR? yes UNREF FILE I=53478932 OWNER=h40708 MODE=100644 SIZE=81 MTIME=Dec 29 00:24 2012 CLEAR? yes UNREF FILE I=53478934 OWNER=h40708 MODE=100644 SIZE=67 MTIME=Dec 27 17:24 2012 CLEAR? yes UNREF FILE I=53478935 OWNER=h40708 MODE=100644 SIZE=71 MTIME=Dec 28 12:34 2012 CLEAR? yes UNREF FILE I=53478947 OWNER=h40708 MODE=100644 SIZE=88 MTIME=Jan 1 18:10 2013 CLEAR? yes UNREF FILE I=53478953 OWNER=h40708 MODE=100644 SIZE=70 MTIME=Dec 28 00:42 2012 CLEAR? yes UNREF FILE I=53478954 OWNER=h40708 MODE=100644 SIZE=66 MTIME=Dec 31 08:20 2012 CLEAR? yes UNREF FILE I=53478956 OWNER=h40708 MODE=100644 SIZE=72 MTIME=Dec 28 00:48 2012 CLEAR? yes ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 2587656 files, 12137676 used, 212163011 free (637755 frags, 26440657 blocks, 0.3% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** # # # # # ^DSetting hostuuid: 564d258e-1ef7-b7a3-bde0-b6bca10c3382. Setting hostid: 0x88403a99. Entropy harvesting: interrupts ethernet point_to_point kickstart. Fast boot: skipping disk checks. Mounting local file systems:. =================================== so, whats rason for use SUJ? about system: srv0$ uname -a FreeBSD srv0.host-food.ru 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Wed Dec 5 04:05:50 MSK 2012 toor@srv0.host-food.ru:/usr/obj/usr/src/sys/HOST-FOOD amd64 srv0$ mount /dev/label/rootFS on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/label/homeFS on /home (ufs, local, noatime, nosuid, with quotas, soft-updates) linprocfs on /proc (linprocfs, local) tmpfs on /tmp (tmpfs, local, noexec, nosuid) devfs on /var/named/dev (devfs, local, multilabel) srv0$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/label/rootFS 59G 13G 40G 25% / devfs 1.0k 1.0k 0B 100% /dev /dev/label/homeFS 855G 46G 740G 6% /home linprocfs 4.0k 4.0k 0B 100% /proc tmpfs 14G 4.0k 14G 0% /tmp devfs 1.0k 1.0k 0B 100% /var/named/dev srv0$ From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 22:48:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D059A9BD for ; Tue, 1 Jan 2013 22:48:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF7B8FC08 for ; Tue, 1 Jan 2013 22:48:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8OABln41CDaFvO/2dsb2JhbABFgX+EO7c0c4IeAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdsBgynN4JAjhyBIotQgxWBEwOIYop8gi6BHI8sgxKBUzU X-IronPort-AV: E=Sophos;i="4.84,393,1355115600"; d="scan'208";a="7095705" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 01 Jan 2013 17:48:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BED65B3F43; Tue, 1 Jan 2013 17:48:40 -0500 (EST) Date: Tue, 1 Jan 2013 17:48:40 -0500 (EST) From: Rick Macklem To: Cy Schubert Message-ID: <1743194234.1613766.1357080520720.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201212291738.qBTHcgDZ006852@slippy.cwsent.com> Subject: Re: Amd(8) Hangs at Boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 22:48:48 -0000 Cy Schubert wrote: > Just udated to the latest current and amd hangs at boot. Ideas? > It appears that r244678 broke the ip4 configuration of loopback for some network interfaces. I don't know, but it might explain why this is happening? Also, if you happen to have a bxe(4) interface, it looks like a recent commit broke UDP checksums, which could also explain it. rick > NFS access cache time=0 > Starting amd. > [halt - sent] > KDB: enter: Break to debugger > [ thread pid 762 tid 100072 ] > Stopped at kdb_break+0x4e: movl $0,kdb_why > db> bt > Tracing pid 762 tid 100072 td 0x8a1675e0 > kdb_break(87641200,c7c8617c,807a9208,81ac6b54,81ac6b50,...) at > kdb_break+0x4e/frame 0xc7c86130 > uart_intr(87641200,0,8a1675e0,4,875f30d0,...) at uart_intr+0x8e/frame > 0xc7c8615c > intr_event_handle(8757fa80,c7c861c0,1,8a1675e0,8a22d6e4,...) at > intr_event_handle+0x85/frame 0xc7c8617c > intr_execute_handlers(875f30d0,c7c861c0,0) at > intr_execute_handlers+0x42/fra > me 0xc7c8619c > lapic_handle_intr(42,c7c861c0) at lapic_handle_intr+0x3d/frame > 0xc7c861b0 > Xapic_isr2() at Xapic_isr2+0x35/frame 0xc7c861b0 > --- interrupt, eip = 0x80929af4, esp = 0xc7c86200, ebp = 0xc7c86220 > --- > udp_bind(8a4b71a0,8a125380,8a1675e0,8a1675e0,8758b400,...) at > udp_bind+0x104/frame 0xc7c86220 > bindresvport(8a4b71a0,0,c7c86380,89fa8300,c7c86408,...) at > bindresvport+0x14a/frame 0xc7c86284 > clnt_reconnect_call(876e82e0,c7c86358,1,89fa8300,c7c86408,...) at > clnt_reconnect_call+0x2a0/frame 0xc7c862e8 > newnfs_request(c7c86408,8a229200,0,8a229310,0,...) at > newnfs_request+0x82a/frame 0xc7c863b0 > nfsrpc_getattrnovp(8a229200,8a22928c,20,1,8758be80,...) at > nfsrpc_getattrnovp+0xfa/frame 0xc7c864b0 > mountnfs(8a125b40,c7c86870,c7c8678c,0,c7c86728,...) at > mountnfs+0x883/frame > 0xc7c865a0 > nfs_mount(8a11c2a0,80d1e8e8,8a0fc400,8758be80,0,...) at > nfs_mount+0x169f/frame 0xc7c86960 > vfs_donmount(8a1675e0,800000,0,c7c86b58,8a10b000,...) at > vfs_donmount+0xc94/frame 0xc7c86b40 > kernel_mount(87557a80,800000,0,58,3,...) at kernel_mount+0x52/frame > 0xc7c86b80 > nfs_cmount(87557a80,7fbfd170,800000,0,80b46c55,...) at > nfs_cmount+0x63/frame 0xc7c86c08 > sys_mount(8a1675e0,c7c86cc8,8a1675e0,88bb82f0,80d94a80,...) at > sys_mount+0x20b/frame 0xc7c86c40 > syscall(c7c86d08) at syscall+0x479/frame 0xc7c86cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7c86cfc > --- syscall (21, FreeBSD ELF32, sys_mount), eip = 0x280ebef7, esp = > 0x7fbfd09c, ebp = 0x7fbfd0c0 --- > db> > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 22:57:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5E0FCF4; Tue, 1 Jan 2013 22:57:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 547258FC08; Tue, 1 Jan 2013 22:57:01 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TqAlX-0029cN-LM>; Tue, 01 Jan 2013 23:56:59 +0100 Received: from e178001208.adsl.alicedsl.de ([85.178.1.208] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TqAlX-001HqF-Gx>; Tue, 01 Jan 2013 23:56:59 +0100 Message-ID: <50E369B3.6040109@zedat.fu-berlin.de> Date: Tue, 01 Jan 2013 23:56:51 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Manfred Antar Subject: Re: loopback interface broken on current References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> In-Reply-To: <201301012042.r01Kgq6E001548@pozo.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7057F6D1E16ABC969076556D" X-Originating-IP: 85.178.1.208 Cc: Gleb Smirnoff , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 22:57:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7057F6D1E16ABC969076556D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/01/13 21:42, schrieb Manfred Antar: > At 11:48 AM 1/1/2013, Gleb Smirnoff wrote: >> On Tue, Jan 01, 2013 at 02:39:58AM -0800, Manfred Antar wrote: >> M> >On Thu, Dec 27, 2012 at 09:05:26AM -0800, Manfred Antar wrote: >> M> >M> For the past few days the loopback interface 127.0.0.1 is brok= en on current. >> M> >M> The last good kernel that works for me is r244662: Mon Dec 24 = 06:43:07 PST 2012 >> M> >M> Here are some of the errors from current today: >> M> > >> M> >Can you please track this down to the specific revision that made = the >> M> >regression? The timeframe is samll, so binary search probably won'= t=20 >> M> >take long time. >> M> Hi >> M> I'm not sure how to do this :( >> M> I just switched from CVS to SVN 2 weeks ago. >> M> I still have a current CVS tree on my machine. >> M> I guess i can try to check out a /usr/src/sys from the 25 on and se= e what changes were made. >> M> I'm just learning SVN so not sure how to do it with that. >> >> With SVN you don't need to care about dates, you just go through the >> sequential list of revisions. So you just seek between r244662 and the= >> most recent revision tht didn't work for you. On first step you >> divide the bad revision (let it be 244768) and good one r244662: >> >> (244662 + 244768)/2 =3D 244715 >> >> Ok, it is 244715. Let's take it and test: >> >> svn up -r 244715 >> >> If it is fine, you check the one in the middle between 244715and >> 244768. Otherwise you chek in between 244715 and 244662. And so on...= >> >> --=20 >> Totus tuus, Glebius. >=20 > OK > I tracked it down to revision 244678 > 244677 works > the files involved are: > (src)5012}svn up -r 244678 > Updating '.': > U sys/netinet/in.c > U sys/netinet6/in6.c > Updated to revision 244678 >=20 > It seems like the ip6 for localhost is configured but ip4 isn't: > Setting hostname: pozo.com. > ifa_del_loopback_route: deletion failed: 3 > ifconfig: ioctl (SIOCAIFADDR): File exists > bge0: link state changed to DOWN > ifa_del_loopback_route: deletion failed: 3 >=20 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 > nd6 options=3D21 >=20 > From 244677: > Setting hostname: pozo.com. >=20 > Starting Network: lo0 bge0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet 127.0.0.1 netmask 0xff000000=20 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 > nd6 options=3D21 >=20 > Manfred I have a similar issue here. It came out after a lot of problems with the amd automounter which rendered a server completeley useless and the very interesting issue is, that the loopback interface, lo0, has IPv6 configured, but it doesn't have IPv4 configured anymore. After a recompilation of the kernel on the 31.12.2012 and a reboot, the box is not responsive anymore (it a remote box I reach not before 07th Jan). NAGIOS is still reporting ICMP ping is good, but every other service is down. On another server I do not face this problem - or have faced that problem and I use the very same OS revisions on most of the CURRENT boxes. But all machines started suffering from some amd automounter issue before the problem got serious. This is strange ... oh --------------enig7057F6D1E16ABC969076556D 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ42m6AAoJEOgBcD7A/5N85LoIAI3dbxqkN66HGdappKrMcUdS dbKUV0eUmKeO3uuPHVdeoV6eQMDRvgJAKPdCNPRBCiBuTAFxCHqc+xLP0mw2gFRR AzUbwjBRATxG30jfqZq/nOE/xn2N4a40aQtbfU97oQuReWZL122L5pvcEK93QlOJ o48iVVH3qP6tAAST0AAl+oQ7kjaSM07jFAKAsabNLQJOR6WtkUF/XnIp63MJd+zh ilRywYu09Fc8b05naMRPBJuDri6QV0i6qW6fzT3nkHZEDg/4c1iSc5v3Q8+5XJxL zoeDuc7/zGo9KR50GSkpdIsTFqAtFYpUBCVMQaQaNdnsEpkuiUxlWuAkkTZrOrA= =NrNq -----END PGP SIGNATURE----- --------------enig7057F6D1E16ABC969076556D-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 1 23:09:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F28F72 for ; Tue, 1 Jan 2013 23:09:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4457B8FC14 for ; Tue, 1 Jan 2013 23:09:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8OADps41CDaFvO/2dsb2JhbABFgX+EO7c0c4IeAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdsBgynNIJAjhqBIotAEIMVgRMDiGKKfIIugRyPLIMSgVM1 X-IronPort-AV: E=Sophos;i="4.84,393,1355115600"; d="scan'208";a="7097082" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 01 Jan 2013 18:09:49 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4DA90B404B; Tue, 1 Jan 2013 18:09:49 -0500 (EST) Date: Tue, 1 Jan 2013 18:09:49 -0500 (EST) From: Rick Macklem To: Cy Schubert Message-ID: <1781411372.1613846.1357081789268.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201212291738.qBTHcgDZ006852@slippy.cwsent.com> Subject: Re: Amd(8) Hangs at Boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 23:09:50 -0000 Cy Schubert wrote: > Just udated to the latest current and amd hangs at boot. Ideas? > I think I spoke too soon w.r.t. the bxe(4) device and UDP checksums. I thought I saw some email about UDP checksum offload for it being broken but I can't locate the email, so I probably have this wrong. Sorry about the noise, rick ps: The loopback configuration issue might still be the culprit. > NFS access cache time=0 > Starting amd. > [halt - sent] > KDB: enter: Break to debugger > [ thread pid 762 tid 100072 ] > Stopped at kdb_break+0x4e: movl $0,kdb_why > db> bt > Tracing pid 762 tid 100072 td 0x8a1675e0 > kdb_break(87641200,c7c8617c,807a9208,81ac6b54,81ac6b50,...) at > kdb_break+0x4e/frame 0xc7c86130 > uart_intr(87641200,0,8a1675e0,4,875f30d0,...) at uart_intr+0x8e/frame > 0xc7c8615c > intr_event_handle(8757fa80,c7c861c0,1,8a1675e0,8a22d6e4,...) at > intr_event_handle+0x85/frame 0xc7c8617c > intr_execute_handlers(875f30d0,c7c861c0,0) at > intr_execute_handlers+0x42/fra > me 0xc7c8619c > lapic_handle_intr(42,c7c861c0) at lapic_handle_intr+0x3d/frame > 0xc7c861b0 > Xapic_isr2() at Xapic_isr2+0x35/frame 0xc7c861b0 > --- interrupt, eip = 0x80929af4, esp = 0xc7c86200, ebp = 0xc7c86220 > --- > udp_bind(8a4b71a0,8a125380,8a1675e0,8a1675e0,8758b400,...) at > udp_bind+0x104/frame 0xc7c86220 > bindresvport(8a4b71a0,0,c7c86380,89fa8300,c7c86408,...) at > bindresvport+0x14a/frame 0xc7c86284 > clnt_reconnect_call(876e82e0,c7c86358,1,89fa8300,c7c86408,...) at > clnt_reconnect_call+0x2a0/frame 0xc7c862e8 > newnfs_request(c7c86408,8a229200,0,8a229310,0,...) at > newnfs_request+0x82a/frame 0xc7c863b0 > nfsrpc_getattrnovp(8a229200,8a22928c,20,1,8758be80,...) at > nfsrpc_getattrnovp+0xfa/frame 0xc7c864b0 > mountnfs(8a125b40,c7c86870,c7c8678c,0,c7c86728,...) at > mountnfs+0x883/frame > 0xc7c865a0 > nfs_mount(8a11c2a0,80d1e8e8,8a0fc400,8758be80,0,...) at > nfs_mount+0x169f/frame 0xc7c86960 > vfs_donmount(8a1675e0,800000,0,c7c86b58,8a10b000,...) at > vfs_donmount+0xc94/frame 0xc7c86b40 > kernel_mount(87557a80,800000,0,58,3,...) at kernel_mount+0x52/frame > 0xc7c86b80 > nfs_cmount(87557a80,7fbfd170,800000,0,80b46c55,...) at > nfs_cmount+0x63/frame 0xc7c86c08 > sys_mount(8a1675e0,c7c86cc8,8a1675e0,88bb82f0,80d94a80,...) at > sys_mount+0x20b/frame 0xc7c86c40 > syscall(c7c86d08) at syscall+0x479/frame 0xc7c86cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc7c86cfc > --- syscall (21, FreeBSD ELF32, sys_mount), eip = 0x280ebef7, esp = > 0x7fbfd09c, ebp = 0x7fbfd0c0 --- > db> > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:11:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0762A3C1; Wed, 2 Jan 2013 03:11:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id ADDFE8FC0C; Wed, 2 Jan 2013 03:11:45 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id k1so12594012oag.2 for ; Tue, 01 Jan 2013 19:11:39 -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=TrQ+mgGSjQFWnGKokQX8zlOaDbrjpCUPqaUWhvOhAtw=; b=TIE0hJNziDW3JW8gtZRUWf8F6YXthZZxUmvCXJjBuOQed0CLvg9rtMkmsz8+bk7aJ2 ARfDkCywRNgHrl6sTNLZ6/gJ/17fu9KJQ7rvih0fsycGQafgv5oSN378aHBQrdJnx8zZ EeOtnR3RsuhzynCgP6mnQyKdt7x+CCuJ6Y94XGMfs1nPcr4n0vXZ9VgKqR1nOl+ZvPwU TrtiVX5NPXvtweGf4ID1uVFPmSqdgS72+0jU+iEm9Vslo2/OsCv3qyC4BazOnExjxCN1 NKKm9sF4I+Ng1hnAP0lx5EQcdr9f9GCrV24i/WhPFPH7nWMdTOUk3qE5obGrNzUMOdYE CmvA== MIME-Version: 1.0 Received: by 10.182.172.74 with SMTP id ba10mr37090315obc.83.1357096298924; Tue, 01 Jan 2013 19:11:38 -0800 (PST) Received: by 10.76.143.33 with HTTP; Tue, 1 Jan 2013 19:11:38 -0800 (PST) In-Reply-To: <20121221210237.GA47912@lor.one-eyed-alien.net> References: <20121221210237.GA47912@lor.one-eyed-alien.net> Date: Tue, 1 Jan 2013 19:11:38 -0800 Message-ID: Subject: Re: NetBSD mtree committed From: Garrett Cooper To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 03:11:46 -0000 On Fri, Dec 21, 2012 at 1:02 PM, Brooks Davis wrote: > I have committed NetBSD's mtree to the tree and am building and > installing it as nmtree. I plan to replace our mtree with this version > after the following steps: > > - Add a WITH_NMTREE build option to install nmtree as mtree and the > old mtree as omtree. > - Switch the default to WITH_NMTREE. > - Remove the old mtree. > - Rename usr.sbin/nmtree to usr.sbin/mtree. > > During this process I will also commit patches to switch makefs > to use NetBSD's mtree which will make the -F specfile option more > useful. > > As a reminder we are doing this because, we will gain the -C option > which produces mtree files compatible with libarchive and makefs (one > line per file with full path) and the -N option which allows a stand > alone set of passwd and group files. When mated with the -U and -M > options to NetBSD's install we will have most of the pieces require to > allow installworld to run as a user and then build images containing > proper permissions. > > The new mtree does introduce some incompatibilities, but nearly all can > be overcome with small command line changes. With one exception, > FreeBSD 9 compatible behavior can be restored by adding the "-F > freebsd9" to the command line. In some cases new warnings are > generate to aid transition, but the output should otherwise be the same. > If you find cases where it is not, please let me know. > > Known incompatibilities are: > > - The -u and -U (update) options do not update the modification time or > set file flags unless the -t and -i options are passed respectively. > - Because the -i option as already take, FreeBSD's option to indent > 4 spaces for each directory level is now -j. > - The -d (directories only) option does not omit blank lines when > entering a new directory or leaving one. The -b option now enables > this behavior independently. > - The handling of the uname and group keywords when the uid or gid can > not be resolved is changed. In the new code, when the uname or group > keyword is request and the name can not be found a uid or gid keyword > is emitted instead. Historically, mtree would report and error and > exit unless the -w option was passed. If that happened then a > warning was printed and no keyword was emitted. That resulted in > potentially dangerous /set statements. As a result I declined to > implement this behavior. > > Here is an example of the dangerous \set statements: > > $ ls -l > total 0 > -rwxr-xr-x 1 root wheel 0 Dec 21 14:13 a > -rwsr-xr-x 1 12345 wheel 0 Dec 21 14:13 b > $ mtree -c -p . -n -k uname,mode -w > ../mtree.out > mtree: Could not get uname for uid=12345 > $ cat ../mtree.out > > /set type=file uname=root mode=0755 > . type=dir uname=brooks > a > b mode=04755 > .. > > $ mtree -f ../mtree.out -u -p . > b: user (0, 12345, modified) > $ ll > total 0 > -rwxr-xr-x 1 root wheel 0 Dec 21 14:13 a > -rwsr-xr-x 1 root wheel 0 Dec 21 14:13 b > $ > > I have heard some requests to MFC the new mtree code. At this time I > have no concrete plans to do so. If it were done then I would modify > the code to run with -F freebsd9 and would implement full uname/group > compatibility. Ran into this linker error when running make installworld going from 10-CURRENT from a month ago to now: /tmp/install.9ten1vtn/mtree: Undefined symbol "strunvis" *** Error code 1 And I'm running into similar issues with mergemaster. Is this a known chicken and egg problem? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 03:17:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA50508; Wed, 2 Jan 2013 03:17:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mx1.freebsd.org (Postfix) with ESMTP id C135A8FC08; Wed, 2 Jan 2013 03:17:31 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id i18so12740250oag.18 for ; Tue, 01 Jan 2013 19:17:30 -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=3hst8NczGJCeZPuJOJpZYRj+r2vkEEqxmMv2er7cT2c=; b=CUZ5tQ4g15GSjCdStYrj41dFLQfuvFFuoaVPne9Laor7Gf0g0p+GaXAgbQPWVtm4EV YXG7nR5IjUbXVYs5ZCFVEkrsvbA5vTX9skIMiIGwRSbYsmLn8nzI/hTPwNW38SPOzUIq BU5JvmJw39IOGjeqDN1wEGowMOC19Cm2zo/2U9u7W0QpH3pmK4oQF4CcYl5kIp9/o6MV d34MndAXHRpGbf1luMhwo+Qk0eUiIVX5gnYKx+6D90h1TiLBikvbSIBUeGW/Iuy487XU d0LhKzn2lRAMMhWTxTsLD59Svu2bwGcgSoZKFfgCkQsTl97ezffB+16azSZDINimZ6j3 16BQ== MIME-Version: 1.0 Received: by 10.182.77.230 with SMTP id v6mr13443947obw.66.1357096650878; Tue, 01 Jan 2013 19:17:30 -0800 (PST) Received: by 10.76.143.33 with HTTP; Tue, 1 Jan 2013 19:17:30 -0800 (PST) In-Reply-To: References: <20121221210237.GA47912@lor.one-eyed-alien.net> Date: Tue, 1 Jan 2013 19:17:30 -0800 Message-ID: Subject: Re: NetBSD mtree committed From: Garrett Cooper To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 03:17:32 -0000 On Tue, Jan 1, 2013 at 7:11 PM, Garrett Cooper wrote: ... > Ran into this linker error when running make installworld going > from 10-CURRENT from a month ago to now: > > /tmp/install.9ten1vtn/mtree: Undefined symbol "strunvis" > *** Error code 1 > > And I'm running into similar issues with mergemaster. Is this a > known chicken and egg problem? Ugh, the environment is fubared. Let's put this question on hold until I've done enough digging to figure out why it's doing the wrong thing.. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 09:21:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73569CA9 for ; Wed, 2 Jan 2013 09:21:38 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 22B8F8FC0A for ; Wed, 2 Jan 2013 09:21:37 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1TqKW1-002umr-6Z>; Wed, 02 Jan 2013 10:21:37 +0100 Received: from e178007124.adsl.alicedsl.de ([85.178.7.124] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1TqKW1-001ji4-2T>; Wed, 02 Jan 2013 10:21:37 +0100 Message-ID: <50E3FC1F.6070509@zedat.fu-berlin.de> Date: Wed, 02 Jan 2013 10:21:35 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Current FreeBSD Subject: FreeBSD 10.0-CURRENT r244916M: osm_console.c:70:1: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator],on: 0, delay_s: 2, loop_function:NULL}; X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08186146E3B1944B37B549B6" X-Originating-IP: 85.178.7.124 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 09:21:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08186146E3B1944B37B549B6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Current r244916M fails to compile a world with following error: [...] cc -O2 -pipe -O3 -march=3Dnative -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werro= r -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/main.= c cc -O2 -pipe -O3 -march=3Dnative -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werro= r -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_c= onsole_io.c cc -O2 -pipe -O3 -march=3Dnative -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -pthread -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP -I/usr/src/contrib/ofed/usr.bin/opensm/../../include/infiniband -I/usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/include/ -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werro= r -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_c= onsole.c /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_c= onsole.c:70:1: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~~ =2Eon =3D /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_c= onsole.c:70:8: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~~~~~~~ .delay_s =3D /usr/src/contrib/ofed/usr.bin/opensm/../../management/opensm/opensm/osm_c= onsole.c:70:20: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] on: 0, delay_s: 2, loop_function:NULL}; ^~~~~~~~~~~~~~ .loop_function =3D 3 errors generated. *** [osm_console.o] Error code 1 Stop in /usr/src/contrib/ofed/usr.bin/opensm. *** [all] Error code 1 Stop in /usr/src/contrib/ofed/usr.bin. *** [all] Error code 1 Stop in /usr/src/contrib/ofed. *** [contrib/ofed.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. --------------enig08186146E3B1944B37B549B6 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ4/wgAAoJEOgBcD7A/5N8cRsH/RIr9uW4JL8kX8dBKcrXQmD/ +lGPVdwGcDkEiaSULT3tUPsyBU146STzMTk/csCH2MfsFENTUHpxMB9Jk1lIuO7v L3WGXleU2AnzUPJ3ypgAu0g/NAjFJ8OtSVUpwLuGWY1UIbng0gkFOVrzJvgy/RxA Wjjse+TnUA3IdnJx0EuPiK7cJloYABy1un4NAOyJratxfJCO3fjIGj/5/1Vvx/Dw IDkMrppf0pTCPCupZkY+6uTHNI02kzTpCErbWwtMUtA97wswmK99EByNKb+07i+s ZuUKpbMO41hijZrR48M0iTwKTi879koxcw5luaexyIxTjD+h1GxKnpEhSUY+WIc= =MNVF -----END PGP SIGNATURE----- --------------enig08186146E3B1944B37B549B6-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 09:24:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04CFBDE0; Wed, 2 Jan 2013 09:24:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 987768FC0C; Wed, 2 Jan 2013 09:24:31 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id n12so12912852oag.10 for ; Wed, 02 Jan 2013 01:24:24 -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=E87zh5U4dEGIMQCkfPuYoqCiC9D09V1NOV8sAM3CFhw=; b=uXWfuOc6FhQEBookp3A9ZAwruOaV9CrO3Wl+CXY9nKlAWkEd1atV8CQr1VGOrB8Q6Z ZMtkRJlPYtDE12u7Nk5u+hSUI0uMPIo1SOAMxvGmdkm8YMYVu4z2NJlxzpZwcfxBZnPY apy4KvOwtPVw6M3QYv1LX53yGf66pIIlbQ4UH33dg1nqrTGMzVwYMusBfsoLSIDEbOMD Wx67lO/kYNA3z3gVaA0EnAia2ApKZxFsRFRrob9V+9oD5tYwCymtsuaUiN4FfXo9hhtT QPBUuy4y+8w/X3cndS7kbyTX56tTvlFOsxECKTJEcd3zjI1H+nUP6n3YdwbX+qorOM33 2OgQ== MIME-Version: 1.0 Received: by 10.60.172.178 with SMTP id bd18mr26213959oec.133.1357118664925; Wed, 02 Jan 2013 01:24:24 -0800 (PST) Received: by 10.76.143.33 with HTTP; Wed, 2 Jan 2013 01:24:24 -0800 (PST) In-Reply-To: <50E3FC1F.6070509@zedat.fu-berlin.de> References: <50E3FC1F.6070509@zedat.fu-berlin.de> Date: Wed, 2 Jan 2013 01:24:24 -0800 Message-ID: Subject: Re: FreeBSD 10.0-CURRENT r244916M: osm_console.c:70:1: error: use of GNU old-style field designator extension [-Werror, -Wgnu-designator], on: 0, delay_s: 2, loop_function:NULL}; From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 09:24:32 -0000 On Wed, Jan 2, 2013 at 1:21 AM, O. Hartmann wrote: > Current r244916M fails to compile a world with following error: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/174214 -- not sure why it hasn't already been committed. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 10:58:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14FE2A14; Wed, 2 Jan 2013 10:58:35 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1D68FC08; Wed, 2 Jan 2013 10:58:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3209473027; Wed, 2 Jan 2013 11:57:30 +0100 (CET) Date: Wed, 2 Jan 2013 11:57:30 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102105730.GA42542@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E16637.9070501@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Ian Lepore , FreeBSD Current , Marius Strobl , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 10:58:35 -0000 On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote: > On 31.12.2012 08:17, Luigi Rizzo wrote: > >On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: ... > >>Then I noticed you had a 12_26 patchset so I tested > >>that (after crudely fixing a couple uninitialized var warnings), and it > >>all looks good on this arm (Raspberry Pi). I'll attach the results. > >> > >>It's so sweet to be able to do precision sleeps. > > Thank you for testing, Ian. > > >interesting numbers, but there seems to be some problem in computing > >the exact interval; delays are much larger than expected. > > > >In this test, the original timer code used to round to the next multiple > >of 1 tick and then add another tick (except for the kqueue case), > >which is exactly what you see in the second set of measurements. > > > >The calloutng code however seems to do something odd: > >in addition to fixed overhead (some 50us, which you can see in > >the tests for 1us and 300us), all delay seem to be ~10% larger > >than what is requested, upper bounded to 10ms (note, the > >numbers are averages so i cannot tell whether all samples are > >the same or there is some distribution of values). > > > >I am not sure if this error is peculiar of the ARM version or also > >appears on x86/amd64 but I believe it should be fixed. > > > >If you look at the results below: > > > >1us possily ok: > > for very short intervals i would expect some kind > > of 'reschedule' without actually firing a timer; maybe > > 50us are what it takes to do a round through the scheduler ? > > > >300us probably ok > > i guess the extra 50-90us are what it takes to do a round > > through the scheduler > > > >1000us borderline (this is the case for poll and kqueue, which are > > rounded to 1ms) > > here intervals seem to be increased by 10%, and i cannot see > > a good reason for this (more below). > > > >3000us and above: wrong > > here again, the intervals seem to be 10% larger than what is > > requested, perhaps limiting the error to 10-20ms. > > > > > >Maybe the 10% extension results from creating a default 'precision' > >for legacy calls, but i do not think this is done correctly. > > > >First of all, if users do not specify a precision themselves, the > >automatically generated value should never exceed one tick. > > > >Second, the only point of a 'precision' parameter is to merge > >requests that may be close in time, so if there is already a > >timer scheduled within [Treq, Treq+precision] i will get it; > >but if there no pending timer, then one should schedule it > >for the requested interval. > > > >Davide/Alexander, any ideas ? > > All mentioned effects could be explained with implemented logic. 50us at > 1us is probably sum of minimal latency of the hardware eventtimer on the > specific platform and some software processing overhead (syscall, > callout, timecouters, scheduler, etc). At later points system starts to > noticeably use precision specified by kern.timecounter.alloweddeviation > sysctl. It affects results from two sides: 1) extending intervals for > specified percent of time to allow event aggregation, and 2) choosing > time base between fast getbinuptime() and precise binuptime(). Extending > interval is needed to aggregate not only callouts with each other, but > also callouts with other system events, which are impossible to schedule > in advance. It gives specified relative error, but no more then one CPU > wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) > it is 1/hz, for completely idle one it can be up to 0.5s. Second point > allows to reduce processing overhead by the cost of error up to 1/hz for > long periods (>(100/allowed)*(1/hz)), when it is used. i am not sure what you mean by "extending interval", but i believe the logic should be the following: - say user requests a timeout after X seconds and with a tolerance of D second (both X and D are fractional, so they can be short). Interpret this as "the system should do its best to generate an event between X and X+D seconds" - convert X to an absolute time, T_X - if there are any pending events already scheduled between T_X and T_X+D, then by definition they are acceptable. Attach the requested timeout to the earliest of these events. - otherwise, schedule an event at time T_X (because there is no valid reason to generate a late event, and it makes no sense from an energy saving standpoint, either -- see below). It seems to me that you are instead extending the requested interval upfront, which causes some gratuitous pessimizations in scheduling the callout. Re. energy savings: the gain in extending the timeout cannot exceed the value D/X. So while it may make sense to extend a 1us request to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, it is completely pointless from an energy saving standpoint to introduce a 10ms error on a 300ms request. (even though i hate the idea that a 1us request defaults to a 50us delay; but that is hopefully something that can be tuned in a platform-specific way and perhaps at runtime). cheers luigi > To get best possible precision kern.timecounter.alloweddeviation sysctl > can be set to smaller value. Setting it to 0 will effectively disable > all optimizations, but should give 50us precision in all cases. > > >>for t in 1 300 3000 30000 300000 ; do > >> for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > >> ./testsleep $t $m > >> done > >>done > >> > >> > >>With calloutng_12_26.patch... > >> > >> HZ=100 HZ=250 HZ=1000 > >>---------- ---------------- ---------------- ---------------- > >>select 1 55.79 1 50.96 1 61.32 > >>poll 1 1109.46 1 1107.86 1 1114.38 > >>usleep 1 56.33 1 72.90 1 62.78 > >>nanosleep 1 52.66 1 55.23 1 64.23 > >>kqueue 1 1114.23 1 1113.81 1 1121.21 > >>kqueueto 1 65.44 1 71.00 1 75.01 > >>syscall 1 4.70 1 4.45 1 4.55 > >>select 300 355.79 300 357.76 300 362.35 > >>poll 300 1107.85 300 1122.55 300 1115.62 > >>usleep 300 355.28 300 357.28 300 360.79 > >>nanosleep 300 354.49 300 355.82 300 360.62 > >>kqueue 300 1112.57 300 1118.13 300 1117.16 > >>kqueueto 300 375.98 300 378.62 300 395.61 > >>syscall 300 4.41 300 4.45 300 4.54 > >>select 3000 3246.75 3000 3246.74 3000 3252.72 > >>poll 3000 3238.10 3000 3229.12 3000 3250.10 > >>usleep 3000 3242.47 3000 3237.06 3000 3249.61 > >>nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 > >>kqueue 3000 3240.01 3000 3236.07 3000 3247.60 > >>kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 > >>syscall 3000 4.69 3000 4.44 3000 4.50 > >>select 30000 31714.60 30000 31941.17 30000 32467.69 > >>poll 30000 31522.76 30000 31983.00 30000 32497.81 > >>usleep 30000 31459.67 30000 31980.76 30000 32458.71 > >>nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 > >>kqueue 30000 31466.75 30000 31873.90 30000 31973.54 > >>kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 > >>syscall 30000 4.70 30000 4.73 30000 4.89 > >>select 300000 319133.02 300000 311562.33 300000 309918.62 > >>poll 300000 319604.27 300000 311422.94 300000 310000.76 > >>usleep 300000 319314.60 300000 311269.69 300000 309996.34 > >>nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 > >>kqueue 300000 309995.55 300000 303980.27 300000 309908.82 > >>kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 > >>syscall 300000 4.41 300000 4.45 300000 4.89 > >> > >> > >>With no patches... > >> > >> HZ=100 HZ=250 HZ=1000 > >>---------- ---------------- ---------------- ---------------- > >>select 1 19941.70 1 7989.10 1 1999.16 > >>poll 1 19904.61 1 7987.32 1 1999.78 > >>usleep 1 19904.95 1 7993.30 1 1999.96 > >>nanosleep 1 19905.64 1 7993.71 1 1999.72 > >>kqueue 1 10001.61 1 4004.00 1 1000.27 > >>kqueueto 1 19904.00 1 7993.03 1 1999.54 > >>syscall 1 4.04 1 4.05 1 4.75 > >>select 300 19904.66 300 7998.39 300 2000.27 > >>poll 300 19904.35 300 7993.47 300 1999.86 > >>usleep 300 19903.96 300 7994.11 300 1999.81 > >>nanosleep 300 19904.48 300 7993.77 300 1999.80 > >>kqueue 300 10001.68 300 4004.18 300 1000.31 > >>kqueueto 300 19997.86 300 7993.37 300 1999.59 > >>syscall 300 4.01 300 4.00 300 4.32 > >>select 3000 19904.80 3000 7998.85 3000 3998.43 > >>poll 3000 19904.92 3000 8005.93 3000 3999.39 > >>usleep 3000 19904.50 3000 7992.88 3000 3999.44 > >>nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 > >>kqueue 3000 10001.58 3000 4003.97 3000 3000.72 > >>kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 > >>syscall 3000 4.02 3000 4.37 3000 4.29 > >>select 30000 39905.02 30000 35991.79 30000 31051.77 > >>poll 30000 39905.49 30000 35980.35 30000 30995.64 > >>usleep 30000 39903.78 30000 35979.48 30000 30995.23 > >>nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 > >>kqueue 30000 30002.73 30000 32019.54 30000 30004.83 > >>kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 > >>syscall 30000 4.44 30000 4.04 30000 4.31 > >>select 300000 310001.23 300000 303995.86 300000 300994.30 > >>poll 300000 309902.73 300000 303981.58 300000 300996.17 > >>usleep 300000 309903.64 300000 303980.17 300000 300997.42 > >>nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 > >>kqueue 300000 300002.77 300000 300019.46 300000 300006.90 > >>kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 > >>syscall 300000 4.01 300000 4.04 300000 4.29 > > > -- > Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 11:24:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3C63FF3; Wed, 2 Jan 2013 11:24:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by mx1.freebsd.org (Postfix) with ESMTP id C58628FC14; Wed, 2 Jan 2013 11:24:36 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id k11so5884314eaa.23 for ; Wed, 02 Jan 2013 03:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6epBEEoEP6d+FP+YxO1bxtw+aDC9aFKnX7YDOkS3OPg=; b=d9FZUY+/cGhYonLELHujxH3ivyxhBqHU011TQ+2uVwdsHidt6JBQKEWn+VOdAkC7JR Ll8+wvIarXcXDIafVX9eDkk0RTvASajbSuMq0yxW50qcNwplgiR+8zB1MXGQh1zT+7BG nmKloM8yresyJvzireaFXksaCzon6SrFTILACgXvTmVSqQsQC4V7N3vodFg2rQw9Ptmz 9iF4D4+6fON8X16/LzMHfDp4F48GmI4spkH2Z3WZhkAEPnhUS/rL9KMzsqx5wsE8xVQ8 d2IilXIJMW4pS3TvyCe05eZiBr8mYishaKC5jM/CYa1ZOOIr4N8xhOi9B8SD+okGh0ce +yGQ== X-Received: by 10.14.215.6 with SMTP id d6mr124479099eep.40.1357125869943; Wed, 02 Jan 2013 03:24:29 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id 43sm96922786eed.10.2013.01.02.03.24.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 03:24:28 -0800 (PST) Sender: Alexander Motin Message-ID: <50E418EA.7030801@FreeBSD.org> Date: Wed, 02 Jan 2013 13:24:26 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> In-Reply-To: <20130102105730.GA42542@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , FreeBSD Current , Marius Strobl , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 11:24:37 -0000 On 02.01.2013 12:57, Luigi Rizzo wrote: > On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote: >> On 31.12.2012 08:17, Luigi Rizzo wrote: >>> On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote: > ... >>>> Then I noticed you had a 12_26 patchset so I tested >>>> that (after crudely fixing a couple uninitialized var warnings), and it >>>> all looks good on this arm (Raspberry Pi). I'll attach the results. >>>> >>>> It's so sweet to be able to do precision sleeps. >> >> Thank you for testing, Ian. >> >>> interesting numbers, but there seems to be some problem in computing >>> the exact interval; delays are much larger than expected. >>> >>> In this test, the original timer code used to round to the next multiple >>> of 1 tick and then add another tick (except for the kqueue case), >>> which is exactly what you see in the second set of measurements. >>> >>> The calloutng code however seems to do something odd: >>> in addition to fixed overhead (some 50us, which you can see in >>> the tests for 1us and 300us), all delay seem to be ~10% larger >>> than what is requested, upper bounded to 10ms (note, the >>> numbers are averages so i cannot tell whether all samples are >>> the same or there is some distribution of values). >>> >>> I am not sure if this error is peculiar of the ARM version or also >>> appears on x86/amd64 but I believe it should be fixed. >>> >>> If you look at the results below: >>> >>> 1us possily ok: >>> for very short intervals i would expect some kind >>> of 'reschedule' without actually firing a timer; maybe >>> 50us are what it takes to do a round through the scheduler ? >>> >>> 300us probably ok >>> i guess the extra 50-90us are what it takes to do a round >>> through the scheduler >>> >>> 1000us borderline (this is the case for poll and kqueue, which are >>> rounded to 1ms) >>> here intervals seem to be increased by 10%, and i cannot see >>> a good reason for this (more below). >>> >>> 3000us and above: wrong >>> here again, the intervals seem to be 10% larger than what is >>> requested, perhaps limiting the error to 10-20ms. >>> >>> >>> Maybe the 10% extension results from creating a default 'precision' >>> for legacy calls, but i do not think this is done correctly. >>> >>> First of all, if users do not specify a precision themselves, the >>> automatically generated value should never exceed one tick. >>> >>> Second, the only point of a 'precision' parameter is to merge >>> requests that may be close in time, so if there is already a >>> timer scheduled within [Treq, Treq+precision] i will get it; >>> but if there no pending timer, then one should schedule it >>> for the requested interval. >>> >>> Davide/Alexander, any ideas ? >> >> All mentioned effects could be explained with implemented logic. 50us at >> 1us is probably sum of minimal latency of the hardware eventtimer on the >> specific platform and some software processing overhead (syscall, >> callout, timecouters, scheduler, etc). At later points system starts to >> noticeably use precision specified by kern.timecounter.alloweddeviation >> sysctl. It affects results from two sides: 1) extending intervals for >> specified percent of time to allow event aggregation, and 2) choosing >> time base between fast getbinuptime() and precise binuptime(). Extending >> interval is needed to aggregate not only callouts with each other, but >> also callouts with other system events, which are impossible to schedule >> in advance. It gives specified relative error, but no more then one CPU >> wakeup period in absolute: for busy CPU (not skipping hardclock() ticks) >> it is 1/hz, for completely idle one it can be up to 0.5s. Second point >> allows to reduce processing overhead by the cost of error up to 1/hz for >> long periods (>(100/allowed)*(1/hz)), when it is used. > > i am not sure what you mean by "extending interval", but i believe the > logic should be the following: > > - say user requests a timeout after X seconds and with a tolerance of D second > (both X and D are fractional, so they can be short). Interpret this as > > "the system should do its best to generate an event between X and X+D seconds" > > - convert X to an absolute time, T_X > > - if there are any pending events already scheduled between T_X and T_X+D, > then by definition they are acceptable. Attach the requested timeout > to the earliest of these events. All above is true, but not following. > - otherwise, schedule an event at time T_X (because there is no valid > reason to generate a late event, and it makes no sense from an > energy saving standpoint, either -- see below). System may have many interrupts except timer: network, disk, ... WiFi cards generate interrupts with AP beacon rate -- dozens times per second. It is not very efficient to wake up CPU precisely at T_X time, that may be just 100us earlier then next hardware interrupt. That's why timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next statclock, ...). As result, event will be handled within allowed range, but real delay will depends on current environment conditions. > It seems to me that you are instead extending the requested interval > upfront, which causes some gratuitous pessimizations in scheduling > the callout. > > Re. energy savings: the gain in extending the timeout cannot exceed > the value D/X. So while it may make sense to extend a 1us request > to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, > it is completely pointless from an energy saving standpoint to > introduce a 10ms error on a 300ms request. I am not so sure in this. When CPU package is in C7 sleep state with all buses and caches shut down and memory set to self refresh, it consumes very few (some milli-Watts) of power. Wake up from that state takes 100us or even more with power consumption much higher then normal operational one. Sure, if we compare it with power consumption of 100% CPU load, difference between 10 and 100 wakeups per second may be small, but when comparing to each other in some low-power environment for mostly idle system it may be much more significant. > (even though i hate the idea that a 1us request defaults to > a 50us delay; but that is hopefully something that can be tuned > in a platform-specific way and perhaps at runtime). It is 50us on this ARM. On SandyBridge Core i7 it is only about 2us. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 12:05:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCECD766 for ; Wed, 2 Jan 2013 12:05:04 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm20-vm0.bullet.mail.ird.yahoo.com (nm20-vm0.bullet.mail.ird.yahoo.com [77.238.189.221]) by mx1.freebsd.org (Postfix) with ESMTP id CE99C8FC08 for ; Wed, 2 Jan 2013 12:05:03 +0000 (UTC) Received: from [77.238.189.232] by nm20.bullet.mail.ird.yahoo.com with NNFMP; 02 Jan 2013 12:04:57 -0000 Received: from [217.146.189.66] by tm13.bullet.mail.ird.yahoo.com with NNFMP; 02 Jan 2013 12:04:57 -0000 Received: from [127.0.0.1] by smtp146.mail.ird.yahoo.com with NNFMP; 02 Jan 2013 12:04:57 -0000 X-Yahoo-Newman-Id: 169403.19021.bm@smtp146.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AhYtvA4VM1kzJuuwc7yVOfAykmPQ7plT.8YLFrPwL340.it a06i1mMihjaANnvS2p5H1LDvV6zTd175o4WZKBU2gqQFyUAuPlL4kNYPlG9w sVtf5yhj1ZUtbHDm1.3d58A0dNQXa4vO4iDxs8bCXiVF8GsLZSL9a8_26kpR nr5NrNEohb.1XBulAxQG7pXsp6Yu8Ec3TvNUpEagtiU1Izd1RSuiaTt076rm ndb6YoPg_4G11CPze.yfb0Ix9TEKXmd65kUD7nKiwoopqI2.2t2k_iPgvcxV qsJdFrD_SNwtBDJB.Pq5s6n5wRMQcn.dB7BQ8Gr4RLOE17aLm5XT8C_JkzK8 bSWj0cZDc90EPlmpN.yNos3GXBWosgzcLw3FylUKpHGbuNudUzVUA50vhqyb O8vJ_opUPPSwaXzYbNVkml0O7BvVx5DqpGSFcxvnseKU_ X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.11] (se@87.158.26.233 with plain) by smtp146.mail.ird.yahoo.com with SMTP; 02 Jan 2013 04:04:57 -0800 PST Message-ID: <50E42264.4010609@freebsd.org> Date: Wed, 02 Jan 2013 13:04:52 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, nwhitehorn@freebsd.org Subject: installworld failure due to cross-device links X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------020704000602010000070205" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 12:05:04 -0000 This is a multi-part message in MIME format. --------------020704000602010000070205 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that this assumption is documented. I'm using a ZFS only installation of -CURRENT and have separate file systems for several of the directories in / and /usr, that usually share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin and /usr/libexec are independent file systems). An older case is the link from /usr/bin/chgrp to /usr/sbin/chown (see usr.sbin/chown/Makefile), which is easily fixed by using a SMYLINK instead of a LINK. And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. This breaks with /usr/bin and /usr/sbin on different file systems, while it should not according to the commit message: ---------------------------------------------------------------------- r244859 | nwhitehorn | 2012-12-30 15:35:00 +0100 (Sun, 30 Dec 2012) | 7 lines Replace sade the extracted piece of sysinstall with sade the extracted piece of bsdinstall (although this time with a symlink instead of duplicated source code). Discussed on: freebsd-geom MFC after: 3 months ---------------------------------------------------------------------- The SYMLINK mentioned in the commit message is a LINK to a different directory, which might be on a different file system, actually. This should be fixed by the attached patch, to remove the implied assumption and to make the Makefile match the commit message. Regards, STefan --------------020704000602010000070205 Content-Type: text/plain; charset=windows-1252; name="partedit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="partedit.patch" Index: Makefile =================================================================== --- Makefile (revision 244957) +++ Makefile (working copy) @@ -2,7 +2,8 @@ BINDIR= /usr/libexec/bsdinstall PROG= partedit -LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit /usr/sbin/sade +LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit +SYMLINKS= /usr/sbin/sade LDADD= -lgeom -lncursesw -lutil -ldialog -lm PARTEDIT_ARCH= ${MACHINE} --------------020704000602010000070205-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 12:28:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A35DFC3E; Wed, 2 Jan 2013 12:28:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1E42F8FC12; Wed, 2 Jan 2013 12:28:39 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9B8E87300A; Wed, 2 Jan 2013 13:27:43 +0100 (CET) Date: Wed, 2 Jan 2013 13:27:43 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102122743.GA43241@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E418EA.7030801@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Ian Lepore , FreeBSD Current , Marius Strobl , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 12:28:41 -0000 On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: > On 02.01.2013 12:57, Luigi Rizzo wrote: ... > >i am not sure what you mean by "extending interval", but i believe the > >logic should be the following: > > > >- say user requests a timeout after X seconds and with a tolerance of D > >second > > (both X and D are fractional, so they can be short). Interpret this as > > > > "the system should do its best to generate an event between X and X+D > > seconds" > > > >- convert X to an absolute time, T_X > > > >- if there are any pending events already scheduled between T_X and T_X+D, > > then by definition they are acceptable. Attach the requested timeout > > to the earliest of these events. > > All above is true, but not following. > > >- otherwise, schedule an event at time T_X (because there is no valid > > reason to generate a late event, and it makes no sense from an > > energy saving standpoint, either -- see below). > > System may have many interrupts except timer: network, disk, ... WiFi > cards generate interrupts with AP beacon rate -- dozens times per > second. It is not very efficient to wake up CPU precisely at T_X time, > that may be just 100us earlier then next hardware interrupt. That's why > timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next > statclock, ...). As result, event will be handled within allowed range, > but real delay will depends on current environment conditions. I don't see why system events (hardclock, statclock, 0.5s,...) need to be treated specially -- and i am saying this also in the interest of simplifying the logic of the code. First of all, if you know that there is already a hardclock/statclock/* scheduled in [T_X, T_X+D] you just reuse that. This particular bullet was ""no event scheduled in [T_X, T_X+D]" so you need to generate a new one. Surely scheduling the event at T_X+D instead of T_X increases the chance of merging events. But the saving are smaller and smaller as the value X increases. This particular client will only change its request rate from 1/X to 1/(X+D) so in relative terms the gain is ( 1/X - 1/(X+D) ) / (1/(X+D) ) = D/X Example: if X = 300ms, and D = 10ms (as in the test case) you just save one interrupt every 30seconds by scheduling at T_X+D instead of T_X. Are we actually able to measure the difference ? Even at high interrupt rates (e.g. X = 1ms) you are not going to save a lot unless the tolerance D is very large, which is generally undesirable for other reasons (presumably, applications are not going to be happy if you artificially double their timeouts). Now, say your application requests timeouts every X = 300ms. > >It seems to me that you are instead extending the requested interval > >upfront, which causes some gratuitous pessimizations in scheduling > >the callout. > > > >Re. energy savings: the gain in extending the timeout cannot exceed > >the value D/X. So while it may make sense to extend a 1us request > >to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, > >it is completely pointless from an energy saving standpoint to > >introduce a 10ms error on a 300ms request. > > I am not so sure in this. When CPU package is in C7 sleep state with all > buses and caches shut down and memory set to self refresh, it consumes > very few (some milli-Watts) of power. Wake up from that state takes > 100us or even more with power consumption much higher then normal > operational one. Sure, if we compare it with power consumption of 100% > CPU load, difference between 10 and 100 wakeups per second may be small, > but when comparing to each other in some low-power environment for > mostly idle system it may be much more significant. see above -- at low rates the difference is not measurable, at high rates thCe only obvious answer is "do not use C7 unless if the next interrupt is due in less than 2..5 milliseconds" > >(even though i hate the idea that a 1us request defaults to > >a 50us delay; but that is hopefully something that can be tuned > >in a platform-specific way and perhaps at runtime). > > It is 50us on this ARM. On SandyBridge Core i7 it is only about 2us. very good, i suspected something similar, just wanted to be sure :) cheers luigi > -- > Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:11:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CCCA27D; Wed, 2 Jan 2013 13:11:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2539B8FC08; Wed, 2 Jan 2013 13:11:07 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id k27so11814000iad.16 for ; Wed, 02 Jan 2013 05:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ge93wgbmwXzBy5wLHFxOPAMkTtllBOn/XYFxpSV6pMg=; b=MCWbvY3CpRUbFneMcabounMspKT0sSpk6f2qARWW9WOKXEfN53e3dzOf4uSoZpIkaS YY4SoT1V6FyIY4OLA/8XBSuS96ra6DJNnctXvT6A5aLO667HLTotfIWAk0H8n7kxBxcw Jujob+9zNT4UGv8XWAytj1JvqVgrkTScPLEueVstkob/tAssk9dF0QmB589AUrL0Y4qz fOeMFsSKEd8FUqQGJ3pRzsUwMqqPUjUNxGHujHOICcXBv+ezkSi4X47VBfZgNyFnPEV9 ydhMiPJmmff2ovijM4CbouCcBdtd6Nx1vT4JGe/wWwdZHCwtnsFZGp5AuCannINT5PoR PF9g== MIME-Version: 1.0 Received: by 10.50.190.199 with SMTP id gs7mr30698329igc.89.1357132266513; Wed, 02 Jan 2013 05:11:06 -0800 (PST) Sender: mavbsd@gmail.com Received: by 10.231.25.76 with HTTP; Wed, 2 Jan 2013 05:11:05 -0800 (PST) Received: by 10.231.25.76 with HTTP; Wed, 2 Jan 2013 05:11:05 -0800 (PST) In-Reply-To: <20130102122743.GA43241@onelab2.iet.unipi.it> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> Date: Wed, 2 Jan 2013 15:11:05 +0200 X-Google-Sender-Auth: c0dsQh7t4Ciqz-RqfgDDC7ofqvc Message-ID: Subject: Re: [RFC/RFT] calloutng From: Alexander Motin To: Luigi Rizzo Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Davide Italiano , Ian Lepore , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 13:11:08 -0000 02.01.2013 14:28 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Luigi Rizzo" =CE=C1=D0=C9=D3=C1=CC: > > On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: > > On 02.01.2013 12:57, Luigi Rizzo wrote: > ... > > >i am not sure what you mean by "extending interval", but i believe the > > >logic should be the following: > > > > > >- say user requests a timeout after X seconds and with a tolerance of = D > > >second > > > (both X and D are fractional, so they can be short). Interpret this as > > > > > > "the system should do its best to generate an event between X and X+D > > > seconds" > > > > > >- convert X to an absolute time, T_X > > > > > >- if there are any pending events already scheduled between T_X and T_X+D, > > > then by definition they are acceptable. Attach the requested timeou= t > > > to the earliest of these events. > > > > All above is true, but not following. > > > > >- otherwise, schedule an event at time T_X (because there is no valid > > > reason to generate a late event, and it makes no sense from an > > > energy saving standpoint, either -- see below). > > > > System may have many interrupts except timer: network, disk, ... WiFi > > cards generate interrupts with AP beacon rate -- dozens times per > > second. It is not very efficient to wake up CPU precisely at T_X time, > > that may be just 100us earlier then next hardware interrupt. That's why > > timer interrupts are scheduled at min(T_X+D, 0.5s, next hardclock, next > > statclock, ...). As result, event will be handled within allowed range, > > but real delay will depends on current environment conditions. > > I don't see why system events (hardclock, statclock, 0.5s,...) > need to be treated specially -- and i am saying this also in > the interest of simplifying the logic of the code. Sure. That is mostly for historical reasons. At some point they should disappear, just not now, as patch is already quite big. > First of all, if you know that there is already a hardclock/statclock/* > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > a new one. That is true, but my main point was about merging with external events, which I can't predict and the only way to merge is increase sleep period, hoping for better. > Surely scheduling the event at T_X+D instead of T_X increases the > chance of merging events. But the saving are smaller and smaller > as the value X increases. This particular client will only > change its request rate from 1/X to 1/(X+D) so in relative terms > the gain is ( 1/X - 1/(X+D) ) / (1/(X+D) ) =3D D/X > > Example: if X =3D 300ms, and D =3D 10ms (as in the test case) > you just save one interrupt every 30seconds by scheduling at > T_X+D instead of T_X. Are we actually able to measure the > difference ? > > Even at high interrupt rates (e.g. X =3D 1ms) you are not > going to save a lot unless the tolerance D is very large, > which is generally undesirable for other reasons > (presumably, applications are not going to be happy > if you artificially double their timeouts). > Now, say your application requests timeouts every X =3D 300ms. With default precision set to 5% it will be only 5% save from periods increase. But that is absolutely not my goal! Imagine different case: you have NIC interrupts at 1000Hz. Also you have 100 callouts with 100ms period each. If we program timer with absolute precision, you will get about 2000Hz of total interrupt rate. But if we allow just 2% deviation, most of callouts will be grouped with NIC interrupts and total rate will be 1000Hz. Loosing _less_ then 2% of precision we are reducing interrupt rate in _half_! > > >It seems to me that you are instead extending the requested interval > > >upfront, which causes some gratuitous pessimizations in scheduling > > >the callout. > > > > > >Re. energy savings: the gain in extending the timeout cannot exceed > > >the value D/X. So while it may make sense to extend a 1us request > > >to 50us to go (theoretically) from 1M callouts/s to 20K callouts/s, > > >it is completely pointless from an energy saving standpoint to > > >introduce a 10ms error on a 300ms request. > > > > I am not so sure in this. When CPU package is in C7 sleep state with al= l > > buses and caches shut down and memory set to self refresh, it consumes > > very few (some milli-Watts) of power. Wake up from that state takes > > 100us or even more with power consumption much higher then normal > > operational one. Sure, if we compare it with power consumption of 100% > > CPU load, difference between 10 and 100 wakeups per second may be small= , > > but when comparing to each other in some low-power environment for > > mostly idle system it may be much more significant. > > see above -- at low rates the difference is not measurable, > at high rates thCe only obvious answer is "do not use C7 unless > if the next interrupt is due in less than 2..5 milliseconds" > > > >(even though i hate the idea that a 1us request defaults to > > >a 50us delay; but that is hopefully something that can be tuned > > >in a platform-specific way and perhaps at runtime). > > > > It is 50us on this ARM. On SandyBridge Core i7 it is only about 2us. > > very good, i suspected something similar, just wanted to be sure :) > > cheers > luigi > > > -- > > Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:26:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28E078B4; Wed, 2 Jan 2013 13:26:29 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id E8B968FC0A; Wed, 2 Jan 2013 13:26:28 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG0004002NXAS00@smtpauth1.wiscmail.wisc.edu>; Wed, 02 Jan 2013 07:26:21 -0600 (CST) Received: from wanderer.tachypleus.net (pool-72-66-126-15.washdc.fios.verizon.net [72.66.126.15]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG0000FE2NWUW10@smtpauth1.wiscmail.wisc.edu>; Wed, 02 Jan 2013 07:26:21 -0600 (CST) Date: Wed, 02 Jan 2013 08:26:19 -0500 From: Nathan Whitehorn Subject: Re: installworld failure due to cross-device links In-reply-to: <50E42264.4010609@freebsd.org> Sender: whitehorn@wisc.edu To: Stefan Esser Message-id: <50E4357B.7020400@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=72.66.126.15 X-Spam-PmxInfo: Server=avs-16, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.2.131523, SenderIP=72.66.126.15 References: <50E42264.4010609@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 13:26:29 -0000 On 01/02/13 07:04, Stefan Esser wrote: > I'd be interested in the general policy on LINKS vs. SYMLINKS > between directories that might end up on different file systems. > > There seems to be an assumption that system directories in /usr > (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file > system, but I do not think that this assumption is documented. > > I'm using a ZFS only installation of -CURRENT and have separate file > systems for several of the directories in / and /usr, that usually > share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin > and /usr/libexec are independent file systems). > > An older case is the link from /usr/bin/chgrp to /usr/sbin/chown > (see usr.sbin/chown/Makefile), which is easily fixed by using a > SMYLINK instead of a LINK. > > And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of > r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. > > This breaks with /usr/bin and /usr/sbin on different file systems, > while it should not according to the commit message: > Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. -Nathan From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 13:59:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7AAC31C; Wed, 2 Jan 2013 13:59:55 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep11.mx.upcmail.net (fep11.mx.upcmail.net [62.179.121.31]) by mx1.freebsd.org (Postfix) with ESMTP id A7DA28FC12; Wed, 2 Jan 2013 13:59:53 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130102135952.STYZ2060.viefep11-int.chello.at@edge04.upcmail.net>; Wed, 2 Jan 2013 14:59:52 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id j1zs1k00T2xdvHc041zsEq; Wed, 02 Jan 2013 14:59:52 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id F3B036D454; Wed, 2 Jan 2013 14:59:50 +0100 (CET) Date: Wed, 2 Jan 2013 14:59:50 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130102135950.GA1464@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E0BD66.4070609@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 13:59:55 -0000 On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: > > I have been playing with Stefan's testcase for a while now, and while I > can reproduce the crashes, I am still at a loss about the cause. It > does seem to have something to do with throwing exceptions, but I am > still not sure whether I am looking at a bug in boost, gcc, clang, or > libgcc... > > Do you happen to have a smaller testcase, by any chance? Not yet, but I'll try to come up with something smaller. Stefan From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:03:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9388A5B5; Wed, 2 Jan 2013 14:03:06 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA3B8FC08; Wed, 2 Jan 2013 14:03:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r02E2waO021163; Wed, 2 Jan 2013 07:02:58 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r02E2sIQ087850; Wed, 2 Jan 2013 07:02:54 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> Content-Type: text/plain; charset="koi8-r" Date: Wed, 02 Jan 2013 07:02:54 -0700 Message-ID: <1357135374.54953.150.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Davide Italiano , Marius Strobl , FreeBSD Current , Luigi Rizzo , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:03:06 -0000 On Wed, 2013-01-02 at 15:11 +0200, Alexander Motin wrote: > 02.01.2013 14:28 ÐÏÌØÚÏ×ÁÔÅÌØ "Luigi Rizzo" ÎÁÐÉÓÁÌ: > > > > On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: > > > On 02.01.2013 12:57, Luigi Rizzo wrote: > > First of all, if you know that there is already a hardclock/statclock/* > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > a new one. > > That is true, but my main point was about merging with external events, > which I can't predict and the only way to merge is increase sleep period, > hoping for better. > This really is the crux of the problem, because you can't *by default* dispatch an event earlier than requested because that's just a violation of the usual rules of precision timing (where you expect to be late but never early). Sometimes there is no need for such precision, and an early wakeup is no more or less detrimental than a late wakeup. In fact, that may even be the majority case. I wonder if it might make sense to allow the precision specification to indicate whether it needs traditional "never early" behavior or whether it can be interpretted as "plus or minus this amount is fine." Like maybe negative precision is interpretted as "plus or minus abs(precision)" or something like that. Or maybe even the other way around... you get "plus or minus" precision by default and the few things that really care about precision timing have a way of indicating that. (But in that case the userland sleeps would have to assume the traditional behavior because that's how they've always been documented.) -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:09:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D23827B3 for ; Wed, 2 Jan 2013 14:09:55 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 91BD68FC0C for ; Wed, 2 Jan 2013 14:09:55 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so12684046obc.41 for ; Wed, 02 Jan 2013 06:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Et0hdwdZqg2NEu4jyM1HhIQw48/gP2Kd8CIEvjgodbc=; b=ycAPpntl3IGrjUIYjosQQZDbLqmsKNaWfup5cb1yr95C34UDW61AL52auY+39cX+zY 2qekAbnneVRtcArGZ8l8KOKsoK4svx47c8u13aeG7FLm4VP09hBluTtUGCCFXopAtJ8R FK7UJg6/bi91HX11ByrPlfOtZqfUjC3kOQSR8JPnZPYa7tBAX0bi70QJkbyY+ZZS7ZAe vfSw3G+kuREop5zOSV3V93vGPFG91buQoBzgw9KlLCu7o/ZzHxUVSgSyAAmcDcL/ccCF 0Make08FzRtwNOxtNEIxAbqEyQyqZTSjosg7SPrwewu4zpgHxpLeyhhaF95zQ+M6z0pb 1rlQ== MIME-Version: 1.0 Received: by 10.182.18.165 with SMTP id x5mr38183457obd.73.1357135453288; Wed, 02 Jan 2013 06:04:13 -0800 (PST) Received: by 10.60.170.167 with HTTP; Wed, 2 Jan 2013 06:04:13 -0800 (PST) Date: Wed, 2 Jan 2013 16:04:13 +0200 Message-ID: Subject: Auditdistd user question From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:09:55 -0000 Hello there and please excuse my harshness. I just installed 9.1, and I tried to set up poudriere with 9/stable. It took a lot of time compiling kernel and world, and after this it all failed with message about missing auditdistd user. I just can't find words. Why this user presence not checked during buildworld at least? Or by just invoking updated Makefile? If there any need to build world without install it, wouldn't be better make some conditional flag, like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing after that at install stage. Of course, in current way just "buildworld" not broken, but "buildworld installworld" is. This looks like like carefully hidden trap, from someone with specific sense of humor. Or am I missing something, and this is not terribly wrong? -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:20:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6D0AA50 for ; Wed, 2 Jan 2013 14:20:41 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by mx1.freebsd.org (Postfix) with ESMTP id 777EF8FC0C for ; Wed, 2 Jan 2013 14:20:41 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id k14so16666080iea.38 for ; Wed, 02 Jan 2013 06:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=RzM5NMjhxOgZ1Svk2JMRZqf/RdZbxZOgmN6A1Eih36I=; b=dGEy3SRltjiVSQxIeLEoG2esGRtx15TJ6djozUJy7rCTdIvV4ANPZ51lc1dqPw0LES O00dODr782UYoZekCSfJqj3pP3K4MwHM1Bi4uAxs2E/Pt93vP4FZCGrFRRpaU5Mqnuii lm+p1vqEsBMWHkjFzNf8M1cN+Re7lmC6Ad19NG0nBIGNL+rilQeiNEXxRV5GcbCa6eFl oXSourCk1u5msjOEopkWIrx7qRx8GhDIXgIavbJ8aLQwfSMmzLWpLZi6YmlY+YxeffUT rzJwGyIOjdgW/JGm6yVX0Hg84TwkGR+IXh6qFwcodNw4V9rUYqws11VhcXWXsJFNrSJK f49Q== Received: by 10.50.153.194 with SMTP id vi2mr40929974igb.15.1357136435612; Wed, 02 Jan 2013 06:20:35 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.65.132 with HTTP; Wed, 2 Jan 2013 06:20:05 -0800 (PST) In-Reply-To: References: From: Chris Rees Date: Wed, 2 Jan 2013 14:20:05 +0000 X-Google-Sender-Auth: Fd00AhDS26TbI96382vPIkPvdfI Message-ID: Subject: Re: Auditdistd user question To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:20:41 -0000 On 2 January 2013 14:04, Alexander Yerenkow wrote: > Hello there and please excuse my harshness. > > I just installed 9.1, and I tried to set up poudriere with 9/stable. > It took a lot of time compiling kernel and world, and after this it all > failed with message about missing auditdistd user. > I just can't find words. > Why this user presence not checked during buildworld at least? Or by just > invoking updated Makefile? If there any need to build world without install > it, wouldn't be better make some conditional flag, > like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing after > that at install stage. > Of course, in current way just "buildworld" not broken, but "buildworld > installworld" is. > This looks like like carefully hidden trap, from someone with specific > sense of humor. > Or am I missing something, and this is not terribly wrong? While I agree with you in principle, I must point out that you mustn't try to run package builds on a newer jail than your host. This causes weird kernel/world synchronisation issues. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169659 [for an example] As far as I know there are no problems with running older jails on newer hosts (thankfully). Chris From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:43:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 666A7106; Wed, 2 Jan 2013 14:43:37 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx1.freebsd.org (Postfix) with ESMTP id 147E38FC13; Wed, 2 Jan 2013 14:43:36 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id h1so13274667oag.34 for ; Wed, 02 Jan 2013 06:43:36 -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=IItlJO2y4tBPXDc4XpoCDE5QVgiyINQseXjx848rLBg=; b=sLmfS30zANqaw/XB+8X5b4d8obDRUeQlD6Xg//Pn+bUqycIPH+mAeIqRCw8jCsWVQE bxnsYf6fE0JbV2ap8QeQQ0SzaexNf+HmZNGJiJVfXivbFwP5B0nGIcs1YRLXrXTWIXmv SgPvk9eX8lYOrHj+B29DMSvz6K9otp7ljMN2+67AyRMTJefXUD/QxVO1hAVUS0RV8tOf Vna+aBKRYkxXRe2g9t/x4O6qVY5sJAWiOGQzPtfnl/kJ4y/XrMhB9N1+yUwiwsvgeljK Ur1vbI8hreH5FgXVwf/isww5lh5ZJ1MxjMvVnNdywTbQgNjqlSqlrLlgFy8/1lmhWfBy 9N0A== MIME-Version: 1.0 Received: by 10.60.172.229 with SMTP id bf5mr25325665oec.81.1357137816387; Wed, 02 Jan 2013 06:43:36 -0800 (PST) Received: by 10.60.170.167 with HTTP; Wed, 2 Jan 2013 06:43:36 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Jan 2013 16:43:36 +0200 Message-ID: Subject: Re: Auditdistd user question From: Alexander Yerenkow To: Chris Rees Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:43:37 -0000 2013/1/2 Chris Rees > On 2 January 2013 14:04, Alexander Yerenkow wrote: > > Hello there and please excuse my harshness. > > > > I just installed 9.1, and I tried to set up poudriere with 9/stable. > > It took a lot of time compiling kernel and world, and after this it all > > failed with message about missing auditdistd user. > > I just can't find words. > > Why this user presence not checked during buildworld at least? Or by just > > invoking updated Makefile? If there any need to build world without > install > > it, wouldn't be better make some conditional flag, > > like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing > after > > that at install stage. > > Of course, in current way just "buildworld" not broken, but "buildworld > > installworld" is. > > This looks like like carefully hidden trap, from someone with specific > > sense of humor. > > Or am I missing something, and this is not terribly wrong? > > While I agree with you in principle, I must point out that you mustn't > try to run package builds on a newer jail than your host. This causes > weird kernel/world synchronisation issues. > I'm just provided info about my setup as background. My main builder is on some current revision, and it can't build 9.1 due to some compiler bug. To not mess with upgrading it, I tried to setup additional 9.1 builder (With having in plans probably upgrade host to stable, maybe not). I just think that such improvements could be improved, and in future better think of all possible cases, not about one. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169659 [for an example] > > As far as I know there are no problems with running older jails on > newer hosts (thankfully). > > Chris > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 16:23:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 192E191B; Wed, 2 Jan 2013 16:23:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BF0181616; Wed, 2 Jan 2013 16:23:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 622AA7300A; Wed, 2 Jan 2013 17:22:06 +0100 (CET) Date: Wed, 2 Jan 2013 17:22:06 +0100 From: Luigi Rizzo To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102162206.GA45701@onelab2.iet.unipi.it> References: <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Ian Lepore , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 16:23:04 -0000 On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: ... > > First of all, if you know that there is already a hardclock/statclock/* > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > a new one. > > That is true, but my main point was about merging with external events, > which I can't predict and the only way to merge is increase sleep period, > hoping for better. ok, now i understand why you want to schedule for T_X+D. Probably one way to close this discussion would be to provide a sysctl so the sysadmin can decide which point in the interval to pick when there is no suitable callout already scheduled. cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 17:01:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE7CF890; Wed, 2 Jan 2013 17:01:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by mx1.freebsd.org (Postfix) with ESMTP id BB21B17C1; Wed, 2 Jan 2013 17:01:51 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id z53so6928298wey.34 for ; Wed, 02 Jan 2013 09:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MQ2/8MvxPXr3Mfaq7+CzCJq3Asbu/F7W+iECw1K5ZLk=; b=BG0WgUU5j933tfR8FChP08xQshElk+KiP04OcjMogmx3Pw/Gq2mznTwTWYCo20JrZJ kX5eC2kiO9HEve+tA1EXv9CuCaMJMfYX8PQjPZDxGgbH82r2rOVZwu07A6XqjcquMJ5F fs6Tf9b4R+hWb7fpm+Bez/RaxmVCahfYCFAZk5x/c/OnFhdyQk+HmZt+X3ZiwaB5Rj/K vquQ6pZdKlXmbgghrTDbEap0VfXHHCSD523G2sPyxbPpu1VsUKhA7inpg8Nk/yS4q9ND TykABw8tCyoTtfXqVew4tJxif4oG97T9Q7fHCghEPUSjk4X33+ZdYEla0MuhxcdzPcRy o1IA== MIME-Version: 1.0 Received: by 10.194.83.36 with SMTP id n4mr73372240wjy.59.1357142883202; Wed, 02 Jan 2013 08:08:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 2 Jan 2013 08:08:03 -0800 (PST) In-Reply-To: <1357135374.54953.150.camel@revolution.hippie.lan> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <1357135374.54953.150.camel@revolution.hippie.lan> Date: Wed, 2 Jan 2013 08:08:03 -0800 X-Google-Sender-Auth: ziUubih1EPjyqc6VtzirwSbcEKY Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , Marius Strobl , FreeBSD Current , freebsd-arch@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:01:52 -0000 .. I'm pretty damned sure we're going to need to enforce a "never earlier than X" latency. Is there a more detailed writeup of calloutng somewhere, besides David's slides? The wiki page is rather empty. Eg - I think this work does coalesce wakeups, right? Or it can? So when in low-power scenarios you can end up with lower-resolution callout periods, but many less CPU wakeups a second? (Do we actually _expose_ wakeups-per-second somewhere?) Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 17:09:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23BE2DEF for ; Wed, 2 Jan 2013 17:09:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B005A17E4 for ; Wed, 2 Jan 2013 17:09:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r02H9YJs040574; Wed, 2 Jan 2013 19:09:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r02H9YJs040574 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r02H9Y1b040573; Wed, 2 Jan 2013 19:09:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Jan 2013 19:09:34 +0200 From: Konstantin Belousov To: Luigi Rizzo Subject: Re: [RFC/RFT] calloutng Message-ID: <20130102170934.GA82219@kib.kiev.ua> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1XmnKQGVLLNJnMip" Content-Disposition: inline In-Reply-To: <20130102162206.GA45701@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Davide Italiano , Ian Lepore , Alexander Motin , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:09:45 -0000 --1XmnKQGVLLNJnMip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: > On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote: > ... > > > First of all, if you know that there is already a hardclock/statclock= /* > > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > > a new one. > >=20 > > That is true, but my main point was about merging with external events, > > which I can't predict and the only way to merge is increase sleep perio= d, > > hoping for better. >=20 > ok, now i understand why you want to schedule for T_X+D. >=20 > Probably one way to close this discussion would be to provide > a sysctl so the sysadmin can decide which point in the interval > to pick when there is no suitable callout already scheduled. Isn't trying to synchronize to the external events in this way unsafe ? I remember, but cannot find the reference right now, a scheduler exploit(s) which completely hide malicious thread from the time accounting, by making it voluntary yielding right before statclock should fire. If statistic gathering could be piggy-backed on the external interrupt, and attacker can control the source of the external events, wouldn't this give her a handle ? --1XmnKQGVLLNJnMip Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ5GnNAAoJEJDCuSvBvK1BD7wP/AiejtH6wGLURiyHvqLN6rvo pjj0tVyGyBErD8Fk/iGaeT6Ok4mqMoKU2bNEGLE9FhC+9ixqxGJzZdGargtDSigq f5qDnnGx0ZYGRz9M/E66E8HJnUT0dLd4eb5zOPdHYUS4vceOdhXDOhRma68fRU4a pPsAPMVgZCFjh44MuL5Ip5hUYYXBvFqloMjsWX5QCm3oYm1mmAN6EX+45jO201sy BP10zANSKFD59QgFr8vWV9zBzx3dfeG6TjJFDKQ9UCV9OohxdrkFeanxE6cq7gxi kEjjUUNcCKiQ9XdzfdCawncYoO+9sioPrg+tHMLCaAPXOW+N8v9PGlPwUechS5kj HAdUwUhEOqFWppPSC9w89WaDGMUWDLo3DXSi+spk+towdaT3caZkKm+EVAmkCYqL xXwFNCmu/xHMLvqPUvnyH/6uq0DmNOHrtoJxKMMcP3fzRjdWFwzJYNMM6kMTDZGu /AcLEVJwU9+FgWGZgz+nAyQv62Z23YXk8nLOgUD33lS3zC4KV19onkhzYZ9XHQf2 TasP7/TFUgxjnU8l8QGwTgeb9oaHZHy2O4qH2jvPP3Eb22mkfoiaJHpVWrJ8iwek C7ZDUJVat0HIdazS6lE1geveBoDmINZemHyBK+f5XGYNfGUefVMqcSU77i8yOfFL 2h3QNlI93AdfFutRaPTU =oZCF -----END PGP SIGNATURE----- --1XmnKQGVLLNJnMip-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 18:07:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B0BD87A for ; Wed, 2 Jan 2013 18:07:17 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5EE1A11 for ; Wed, 2 Jan 2013 18:07:17 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 02 Jan 2013 13:05:59 -0500 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BWC35933; Wed, 2 Jan 2013 13:05:58 -0500 X-Auth-ID: roberthuff Received: from 209-6-85-139.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO [192.168.1.101]) ([209.6.85.139]) by smtp04.lnh.mail.rcn.net with ESMTP; 02 Jan 2013 13:05:58 -0500 Message-ID: <50E476D3.2030609@rcn.com> Date: Wed, 02 Jan 2013 13:05:07 -0500 From: Robert Huff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: current@freebsd.org Subject: problem after installkernel going from 9.0 to CURRENT References: <50E0BFA0.6070702@rcn.com> In-Reply-To: <50E0BFA0.6070702@rcn.com> X-Forwarded-Message-Id: <50E0BFA0.6070702@rcn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 18:07:17 -0000 (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1 freebsd-boot 128k ada2p2 freebsd-swap 4g ada2p3 freebsd-ufs 25g (There are non-bootable disks at ada0, -1, and -3.) 2) Installed off the 9.0 CD, got it up and running, everything was good. 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. 4a) Built world - OK. 4b) Build kernel - OK. 4c) Ran mergemaster - OK. 4d) Installed kernel - OK. 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in "mountroot > ". Providing the presumptive value by hand returns "error 19". 6) Boot using installation CD and use "gpart show" to double check device names and partitions; everything looks good. 7) Try normal booting again, no go. This is my first time installing to a completely GPT partitioned system, and I have (obviously) failed to grok something. I checked src/UPDATING and found nothing which covered this. What have I bungled, and how do I fix it? Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 18:11:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E20D8DBB; Wed, 2 Jan 2013 18:11:02 +0000 (UTC) (envelope-from bjk@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D37861A76; Wed, 2 Jan 2013 18:11:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id r02IB2db063220; Wed, 2 Jan 2013 18:11:02 GMT (envelope-from bjk@freebsd.org) Received: from localhost (bjk@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) with ESMTP id r02IAvXe063206; Wed, 2 Jan 2013 18:11:02 GMT (envelope-from bjk@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bjk owned process doing -bs Date: Wed, 2 Jan 2013 18:10:57 +0000 (UTC) From: Benjamin Kaduk To: freebsd-current@freebsd.org Subject: auditdistd (again) Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 18:11:03 -0000 My recent upgrading experience led to the installkernel portion of 'make kernel' failing on the lack of an auditdistd user, for which 'mergemaster -p' was ample workaround. However, the instructions for "to rebuild everything" in UPDATING still have 'mergemaster -p' before installworld and after kernel/installkernel. There is a bug here, but it could be either a documentation bug (fix UPDATING) or a code bug (only check UID/GIDs before installworld and not installkernel, which only ever uses root:wheel). Unfortunately, testing code for the latter is somewhat time-consuming. Pawel mentioned on #bsddev that he had an untested patch for the latter. Is there interest in testing that and getting it in the tree? (Or would people prefer to just change UPDATING?) -Ben From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 18:57:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8620C1F for ; Wed, 2 Jan 2013 18:57:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0731DA2 for ; Wed, 2 Jan 2013 18:57:17 +0000 (UTC) X-AuditID: 12074423-b7ef96d000000725-de-50e4830656c0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 41.8F.01829.60384E05; Wed, 2 Jan 2013 13:57:10 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r02IvAg4012314; Wed, 2 Jan 2013 13:57:10 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id r02Iv8YE026547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 13:57:10 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r02Iv8Nv002991; Wed, 2 Jan 2013 13:57:08 -0500 (EST) Date: Wed, 2 Jan 2013 13:57:08 -0500 (EST) From: Benjamin Kaduk To: Robert Huff Subject: Re: problem after installkernel going from 9.0 to CURRENT In-Reply-To: <50E476D3.2030609@rcn.com> Message-ID: References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixCmqrMvW/CTAYN9DPYsJV34wWXRfvM7q wOQx49N8Fo+nKyaxBDBFcdmkpOZklqUW6dslcGU8+/uLteAGb8WuZ8/YGxivcHUxcnBICJhI 3Nnp0sXICWSKSVy4t54NxBYS2McosW6mZxcjF5C9nlHiWPNOdgjnOJPEvFtToKrqJVYcmcoK MohFQEviyGlRkDCbgIrEzDcb2UDCIkB2z2UPEJNZQFziZb8SSIWwgJPEgjUP2UFsTgF1ia1n /zODlPAKOEo8eFoGMdtRovXCKhYQW1RAR2L1/ilgNq+AoMTJmU/AbGYBS4lzf66zTWAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK91JTSTYyg8GR3Ud7B+Oeg0iFG AQ5GJR7eFTVPAoRYE8uKK3MPMUpyMCmJ8vI3AYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8F7P AcrxpiRWVqUW5cOkpDlYlMR5r6Xc9BcSSE8sSc1OTS1ILYLJynBwKEnwyoIMFSxKTU+tSMvM KUFIM3FwggznARp+uxFkeHFBYm5xZjpE/hSjopQ4rxlIswBIIqM0D64Xlj5eMYoDvSLMqwJS xQNMPXDdr4AGMwENfvXmMcjgkkSElFQDY270If+Vzi9uMWWY3z/25uyCJWF/+wU0c00fznRb 9DFlmSTHzMMy6q4CF55MjHBzXvFr0z3j2aH7Ftz+qHdP72Okw74EndcLN9+wmMIiwDXzVZdU 7yYzuTXHu/k4C7vOHTvKNbH1qFbh83+r485fMvdqcZhcO0dlwdL2dv+t/42adVOEzQTun1Ni Kc5INNRiLipOBAAd1bjF+gIAAA== Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 18:57:18 -0000 On Wed, 2 Jan 2013, Robert Huff wrote: > (While this may not be a strictly CURRENT issue, I asked on > questions@, but have not found a solution.) > > Situation: > One of my boxes failed, and for various reasons it became easier to > just scrub and rebuild it. Like its predecessor it will run CURRENT > 1) Using BSDinstall, I flushed then created the first disk: > > ada2p1 freebsd-boot 128k > ada2p2 freebsd-swap 4g > ada2p3 freebsd-ufs 25g > > (There are non-bootable disks at ada0, -1, and -3.) For a full clean install, I believe that bsdinstall should prompt about installing bootcode around here. I don't really understand from your procedure how bsdinstall was used; there might be some edge case where there is no prompt about bootcode. > 2) Installed off the 9.0 CD, got it up and running, everything was > good. > 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. > 4a) Built world - OK. > 4b) Build kernel - OK. > 4c) Ran mergemaster - OK. > 4d) Installed kernel - OK. > 5) On rebooting, the loader(??) claims to not be able to find a > bootable partition - i.e. I get a screen that ends in "mountroot > ". > Providing the presumptive value by hand returns "error 19". > 6) Boot using installation CD and use "gpart show" to double check > device names and partitions; everything looks good. > 7) Try normal booting again, no go. > > This is my first time installing to a completely GPT partitioned > system, and I have (obviously) failed to grok something. I checked > src/UPDATING and found nothing which covered this. > What have I bungled, and how do I fix it? I think you should investigate the 'bootcode' subcommand of gpart(8). -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 19:41:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BBF995F for ; Wed, 2 Jan 2013 19:41:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC421FDD for ; Wed, 2 Jan 2013 19:41:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id r02JfqQK067587 for ; Wed, 2 Jan 2013 19:41:52 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id r02JfqTE067586 for freebsd-current@freebsd.org; Wed, 2 Jan 2013 19:41:52 GMT (envelope-from bdrewery) Received: (qmail 76835 invoked from network); 2 Jan 2013 13:41:50 -0600 Received: from unknown (HELO ?192.168.0.74?) (freebsd@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 2 Jan 2013 13:41:50 -0600 Message-ID: <50E48D87.7080908@FreeBSD.org> Date: Wed, 02 Jan 2013 13:41:59 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: auditdistd (again) References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig655868ACF77EA338DF684381" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 19:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig655868ACF77EA338DF684381 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/2/2013 12:10 PM, Benjamin Kaduk wrote: > My recent upgrading experience led to the installkernel portion of 'mak= e > kernel' failing on the lack of an auditdistd user, for which > 'mergemaster -p' was ample workaround. However, the instructions for > "to rebuild everything" in UPDATING still have 'mergemaster -p' before > installworld and after kernel/installkernel. This is also documented in misc/174405 >=20 > There is a bug here, but it could be either a documentation bug (fix > UPDATING) or a code bug (only check UID/GIDs before installworld and no= t > installkernel, which only ever uses root:wheel). >=20 > Unfortunately, testing code for the latter is somewhat time-consuming. >=20 > Pawel mentioned on #bsddev that he had an untested patch for the latter= =2E > Is there interest in testing that and getting it in the tree? (Or woul= d > people prefer to just change UPDATING?) >=20 --=20 Regards, Bryan Drewery --------------enig655868ACF77EA338DF684381 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5I2LAAoJEG54KsA8mwz5uIgQAJqPjj7/y/nv5hdVCnEEerwk DqLb7vXwfkE7dpuwBRdt0PqYahE+hgbb8obyNSfCiulVLQMB/uLVB1L9DW4eDjmw dHLpK+eLgekou8E2xWVLlp4su8LOUpKuMnYBvkycKpPpT7LN66jE7xQrryOBUTMc EMu1a40M6VslMz4uirPp4x7YNoAQ8XbobxPWxAzVD/XmtUwRLyK6QE55OMg5W7hR CONh5qiPXFAv2zohYJNJDP7/5erKn8dSyBEQNgPsOigfzew3Wee/nwUXY2/iheV6 BZVCDFVJc844v+IB7S72ehGDc6zR3rYXxo90k8QoFBkY2x7Y4+HxvCmJgLZg+wFj DTscdXalrNSjqeIt5Qh4yqA4f4j8ZRbhJwwpGETHyQ6snsnu5jrigfFMDLOAmsR0 Hb1undhbV6jdev4JZ12ZVdTnZdYvrKKuaQjfe5Gej6WMpUdqviSog/nzYqnXVnoU i662weOmSzFuIDSfqUZUDSAuMcVXWyxvFnyuEbvGPI6zWXiUl1+Am5nHMeWWkNVs b4aempLx7ECtxL6FyrgpSixBI9YQS4ml03FaLulO06aKHD0xi18pyYtWHEqy/BsM PYSs4lscIJAUgSlwQl+8WXZS0siSxQVwmwo3Gpl6/w0O3QzNbVu+9nVZYi2l7ON7 HasH5qjLgwG8EYtnogjy =CkK5 -----END PGP SIGNATURE----- --------------enig655868ACF77EA338DF684381-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 20:05:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0E37F41 for ; Wed, 2 Jan 2013 20:05:19 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id A83D910B for ; Wed, 2 Jan 2013 20:05:18 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 02 Jan 2013 15:05:18 -0500 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id CDY85943; Wed, 2 Jan 2013 15:05:17 -0500 X-Auth-ID: roberthuff Received: from 209-6-85-139.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO [192.168.1.101]) ([209.6.85.139]) by smtp04.lnh.mail.rcn.net with ESMTP; 02 Jan 2013 15:05:16 -0500 Message-ID: <50E49298.5030000@rcn.com> Date: Wed, 02 Jan 2013 15:03:36 -0500 From: Robert Huff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: problem after installkernel going from 9.0 to CURRENT References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr16.lnh.mail.rcn.net) Cc: Robert Huff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 20:05:19 -0000 On 1/2/2013 1:57 PM, Benjamin Kaduk wrote: > On Wed, 2 Jan 2013, Robert Huff wrote: > For a full clean install, I believe that bsdinstall should prompt about > installing bootcode around here. I don't really understand from your > procedure how bsdinstall was used; there might be some edge case where > there is no prompt about bootcode. > >> 2) Installed off the 9.0 CD, got it up and running, everything was >> good. Let me elaborate on this: 2) Installed off the 9.0 CD, had a fully bootable system connected to the Internet, everything was good. > I think you should investigate the 'bootcode' subcommand of gpart(8). Does the above change things? It was my expectation "installkernel" would Do The Right Thing with respect to new bootcode, and I am surprised it did not. Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 20:13:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7854275 for ; Wed, 2 Jan 2013 20:13:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADC2167 for ; Wed, 2 Jan 2013 20:13:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r02KDVmV042999; Thu, 3 Jan 2013 00:13:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r02KDUpj042998; Thu, 3 Jan 2013 00:13:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 3 Jan 2013 00:13:30 +0400 From: Gleb Smirnoff To: Manfred Antar Subject: Re: loopback interface broken on current Message-ID: <20130102201330.GC25661@glebius.int.ru> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201301012042.r01Kgq6E001548@pozo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 20:13:40 -0000 On Tue, Jan 01, 2013 at 12:42:47PM -0800, Manfred Antar wrote: M> OK M> I tracked it down to revision 244678 M> 244677 works M> the files involved are: M> (src)5012}svn up -r 244678 M> Updating '.': M> U sys/netinet/in.c M> U sys/netinet6/in6.c M> Updated to revision 244678 M> M> It seems like the ip6 for localhost is configured but ip4 isn't: M> Setting hostname: pozo.com. M> ifa_del_loopback_route: deletion failed: 3 M> ifconfig: ioctl (SIOCAIFADDR): File exists M> bge0: link state changed to DOWN M> ifa_del_loopback_route: deletion failed: 3 M> M> lo0: flags=8049 metric 0 mtu 16384 M> options=600003 M> inet6 ::1 prefixlen 128 M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 M> nd6 options=21 M> M> From 244677: M> Setting hostname: pozo.com. M> M> Starting Network: lo0 bge0. M> lo0: flags=8049 metric 0 mtu 16384 M> options=600003 M> inet 127.0.0.1 netmask 0xff000000 M> inet6 ::1 prefixlen 128 M> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 M> nd6 options=21 Ok, so this is my failure. :( Sorry. I will look at it as soon as I get to decent internet connection. Right now I am on very bad GPRS. Can you please show your rc.conf (the network related part)? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 04:50:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D5B6BE; Wed, 2 Jan 2013 04:50:40 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id C2A948FC08; Wed, 2 Jan 2013 04:50:39 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r024oW1W082808; Tue, 1 Jan 2013 23:50:32 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 1 Jan 2013 23:50:32 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: CFT: Overhauled CPSW driver for BeagleBone Message-ID: <20130101235032.68391134@ivory.wynn.com> In-Reply-To: <0DD7F54B-20CF-42B5-A83E-29E8CF58D390@freebsd.org> References: <53026BDB-88DA-4869-99B3-B63D34667451@freebsd.org> <20130101111247.734a45fd@ivory.wynn.com> <0DD7F54B-20CF-42B5-A83E-29E8CF58D390@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Jan 2013 21:18:44 +0000 Cc: freebsd-arm , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 04:50:40 -0000 On Tue, 1 Jan 2013 10:55:58 -0800 Tim Kientzle wrote: > > On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote: > > Greeting- > > > > The driver is working much better than the driver currently in > > head. I have maintained an ssh connection to the BeagleBone for > > more than 24 hours! > > Just committed this to -CURRENT r244939. > > Tim Ok time to cvsup then rebuild the kernel followed by a buildworld! Thanks Tim! -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:39:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2006AA95; Wed, 2 Jan 2013 21:39:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by mx1.freebsd.org (Postfix) with ESMTP id 614D7623; Wed, 2 Jan 2013 21:39:20 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id k11so6115397eaa.37 for ; Wed, 02 Jan 2013 13:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uo48LHfkJdD9FVWjrQOe4d6qpXXXfB1b+Md8xaa4JYg=; b=VCkGVKddQebRYa8Q1TsRe+UT1A7G4zqhQ5qE35Vl9FSrEYf3vuE0unLy0IDdMTVBcG neVE6n/PQOcvLFXPLDj07I9hsWv8lWOBq93PpRsG3d4XQjchEwSEPnafb6EJJt7vmUy3 AAViJ5qAHFBQXogJVkfMc4pk9uxwV//T3vJZQLdnqzHKs4d33w1LC7sGBl9NSA+CQVr+ fdrveDjF6t6PdJCwEPaUhBrSEzLpcatPTf3McPzGQ2r0L4bHiqnciDi6Wcv5WjnWrNPn 6S47+OLdrd2gVT++CtmLncq3JDNJsPvaYOsBXkTGLnVf/8fVRLJBtz5piVmVHxpZFW3+ bJdQ== X-Received: by 10.14.204.70 with SMTP id g46mr102666330eeo.15.1357162759189; Wed, 02 Jan 2013 13:39:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id l3sm100090480eem.14.2013.01.02.13.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 13:39:17 -0800 (PST) Sender: Alexander Motin Message-ID: <50E4A902.4050307@FreeBSD.org> Date: Wed, 02 Jan 2013 23:39:14 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: [RFC/RFT] calloutng References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> In-Reply-To: <20130102170934.GA82219@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:39:21 -0000 On 02.01.2013 19:09, Konstantin Belousov wrote: > On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: >> Probably one way to close this discussion would be to provide >> a sysctl so the sysadmin can decide which point in the interval >> to pick when there is no suitable callout already scheduled. > Isn't trying to synchronize to the external events in this way unsafe ? > I remember, but cannot find the reference right now, a scheduler > exploit(s) which completely hide malicious thread from the time > accounting, by making it voluntary yielding right before statclock > should fire. If statistic gathering could be piggy-backed on the > external interrupt, and attacker can control the source of the external > events, wouldn't this give her a handle ? There are many different kinds of accounting with different characteristics. Run time for each thread calculated using high resolution per-CPU clocks on each context switch. It is impossible to hide from it. System load average updated using callout and aligned with hardclock(). Hiding from it was easy before, but it can be made more complicated (asynchronous) now. Per-CPU SYSTEM/INTERRUPT/USER/NICE/IDLE counters are updated by statcklock(), that is asynchronous to hardclock() and hiding from it supposed to be more complicated. But even before it was possible, since hardclock() frequency is 8 times higher then statclock() one. More important for scheduling fairness thread's CPU percentage is also based on hardclock() and hiding from it was trivial before, since all sleep primitives were strictly aligned to hardclock(). Now it is slightly less trivial, since this alignment was removed and user-level APIs provide no easy way to enforce it. The only way to get really safe accounting is forget about sampling and use potentially more expensive other ways. It was always stopped by lack of cheap and reliable clocks. But since TSC is P-state invariant on most of CPUs present now it could probably be reconsidered. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 21:59:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23DB16CA for ; Wed, 2 Jan 2013 21:59:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by mx1.freebsd.org (Postfix) with ESMTP id 9EEA86E3 for ; Wed, 2 Jan 2013 21:59:48 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id fn20so6760402lab.26 for ; Wed, 02 Jan 2013 13:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AelFtaPB0oywVrQWUuttJ4EazZbSqE+z9hgtQc7Sh+A=; b=cakpyiFgcNon+lk1xKOBVAhUroijXSyzWG0k29MgScfOamQjGpaknQ2TsrwY6vdLnj F+aVRzYrAwZxIf6LLoDtZCCC0D7kya4/oMjAGBqWebjmQLiIkj9irCuqc/00ZnzuhJVm fVFsVCpGBcZNW3iu8j/I3DmGRl8lOHAcL0J3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AelFtaPB0oywVrQWUuttJ4EazZbSqE+z9hgtQc7Sh+A=; b=Bx11mfz0Vh/Cu/YFk2jdNE2GX7nU5d03I5RuhgakxI185M/bcStjUJSDHZZb8uxgF9 NlyVRG/AjswKgOoFSBeQ1wY9DDhOLMLc/RGSeXMtgBbw8Ve4Ix7+0lmJvZvSy1nQtPmB WvpsiDyfTjRbjd11Ri971yuwlG3DS+23oOLtOwvrPhRDFAv+3HixUCnwDvTkygS9vHgZ YHEyX2zsYPSm6iEDmoknLCSXQsa0GdBW1aCSL8nXfr3UoNqS7q3kzZH/zerJpjv0xkq6 jHm37zOuVcqaKXZ1FgjrIaYDgYTTzwDk+bPKzWCcGLmzeVBo9FXZ0r/C3Z/Wfy9tMIEA u5fA== Received: by 10.152.125.237 with SMTP id mt13mr45089553lab.45.1357163987247; Wed, 02 Jan 2013 13:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.75.200 with HTTP; Wed, 2 Jan 2013 13:59:17 -0800 (PST) In-Reply-To: <20130102135950.GA1464@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> From: Eitan Adler Date: Wed, 2 Jan 2013 16:59:17 -0500 Message-ID: Subject: Re: clang 3.2 RC2 miscompiles libgcc? To: Stefan Farfeleder Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkilsJQMVG3ItlMXHB6qCHDvnxU9TJp/m1RZYjWiRmaIsKFrIGt3obNKJqcI9YP0y+TqPlj Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 21:59:49 -0000 On 2 January 2013 08:59, Stefan Farfeleder wrote: > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: >> >> I have been playing with Stefan's testcase for a while now, and while I >> can reproduce the crashes, I am still at a loss about the cause. It >> does seem to have something to do with throwing exceptions, but I am >> still not sure whether I am looking at a bug in boost, gcc, clang, or >> libgcc... >> >> Do you happen to have a smaller testcase, by any chance? > > Not yet, but I'll try to come up with something smaller. Take a look at devel/delta as well as creduce (require ToT clang so it is unported at this time) to help you with finding minimal testcase. If you need help, let me know. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 22:06:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 43B89B05; Wed, 2 Jan 2013 22:06:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by mx1.freebsd.org (Postfix) with ESMTP id 272BC742; Wed, 2 Jan 2013 22:06:16 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id k14so5830467eaa.26 for ; Wed, 02 Jan 2013 14:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3EcKGr55zw6+/irtMq+g7UAr+0y89PXbs2Myu69P0YQ=; b=Tv8eLhy6bKcOnHGEpyLTNFPl+wJaa2eKk4/HAH1XsZZE4Gwv21IwvSTBvEIhkDBL8s 1yssBkVYX9kSyeHoev85Q3s3HeNMXNtSH2DzX38QxtR6vw47RlAB93FE2LlA2T0jEAAp eQmqdTCMC0vEsNg1UrG37axDth1r4lG2CidlwvcH8ca+AQuZWFY5U6pCRbrV7PEVFu8W uIPuN090Wg0q3mE9mTcU5jsBxDFT1xtIetBH+BSQSurcEH/ixhxV04t2GDbKgqJY3bim eB/1j6yFuy0WVLYPE6B7q/0oBHFmvH7DG/QpvS6stDrkrfvL8fOWSbnzN4Dh8UJangIY dWyA== X-Received: by 10.14.0.133 with SMTP id 5mr127300082eeb.29.1357164370592; Wed, 02 Jan 2013 14:06:10 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id w44sm100140868eep.6.2013.01.02.14.06.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 14:06:09 -0800 (PST) Sender: Alexander Motin Message-ID: <50E4AF4C.2070902@FreeBSD.org> Date: Thu, 03 Jan 2013 00:06:04 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <1357135374.54953.150.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , Marius Strobl , FreeBSD Current , freebsd-arch@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 22:06:18 -0000 On 02.01.2013 18:08, Adrian Chadd wrote: > .. I'm pretty damned sure we're going to need to enforce a "never > earlier than X" latency. Do you mean here that we should never wake up before specified time (just as specified by the most of existing APIs), or that we should not allow sleep shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't allow to block the system. Also there is already present mechanism for specifying minimum timer programming interval in eventtimers(9) KPI. > Is there a more detailed writeup of calloutng somewhere, besides > David's slides? The wiki page is rather empty. There are updated manual pages in the patch. Also Davide written some blog during GSoC. Now we are working on papers for the AsiaBSDCon. > Eg - I think this work does coalesce wakeups, right? Or it can? So > when in low-power scenarios you can end up with lower-resolution > callout periods, but many less CPU wakeups a second? This work does coalesce wakeups out of the box, but also provide ways to improve it further, where possible. With additional tuning of some kernel subsystems and drivers I was able to drop total idle interrupt rate down to 10-15Hz on arm and 20-30Hz on x86. > (Do we actually _expose_ wakeups-per-second somewhere?) On systems with ACPI there are average per-CPU sleep times exposed via sysctls dev.cpu.X.cx_usage. Also cpu_idle() call rate calculated by both schedulers for purposes of idle loop optimizations, but it is not exposed outside now. Also for idle SMP system enabling COUNT_IPIS should give number of interrupts in systat comparable to number of wakeups. I am mostly using the last way. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 23:25:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2F153D3; Wed, 2 Jan 2013 23:25:37 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 625359B9; Wed, 2 Jan 2013 23:25:37 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r02NPKEE076633 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 15:25:20 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201301022325.r02NPKEE076633@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Jan 2013 15:25:14 -0800 To: Gleb Smirnoff From: Manfred Antar Subject: Re: loopback interface broken on current In-Reply-To: <20130102201330.GC25661@glebius.int.ru> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r02NPKEE076633 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 23:25:37 -0000 > > >Ok, so this is my failure. :( Sorry. I will look at it as soon as >I get to decent internet connection. Right now I am on very bad GPRS. > >Can you please show your rc.conf (the network related part)? > > >-- >Totus tuus, Glebius. Here you go: /etc/hosts: ::1 localhost localhost.pozo.com 127.0.0.1 localhost localhost.pozo.com /etc/rc.conf: ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" defaultrouter="192.168.0.1" # Set to default gateway ipv6_network_interfaces="auto" # List of IPv6 network interfaces # (or "auto" or "none"). ipv6_activate_all_interfaces="NO" # If NO, interfaces which have no ipv6_defaultrouter="NO" # Set to IPv6 default gateway (or NO). ipv6_static_routes="" # Set to static route list (or leave empty). #ipv6_static_routes="xxx" # An example to set fec0:0000:0000:0006::/64 # route toward loopback interface. #ipv6_route_xxx="fec0:0000:0000:0006:: -prefixlen 64 ::1" ipv6_gateway_enable="NO" # Set to YES if this host will be a gateway. ipv6_cpe_wanif="NO" # Set to the upstram interface name if this # node will work as a router to forward IPv6 # packets not explicitly addressed to itself. ipv6_privacy="NO" # Use privacy address on RA-receiving IFs # (RFC 4941) route6d_enable="NO" # Set to YES to enable an IPv6 routing daemon. route6d_program="/usr/sbin/route6d" # Name of IPv6 routing daemon. route6d_flags="" # Flags to IPv6 routing daemon. #route6d_flags="-l" # Example for route6d with only IPv6 site local # addrs. #route6d_flags="-q" # If you want to run a routing daemon on an end # node, you should stop advertisement. #ipv6_network_interfaces="ed0 ep0" # Examples for router # or static configuration for end node. # Choose correct prefix value. #ipv6_prefix_ed0="fec0:0000:0000:0001 fec0:0000:0000:0002" # Examples for rtr. #ipv6_prefix_ep0="fec0:0000:0000:0003 fec0:0000:0000:0004" # Examples for rtr. ipv6_default_interface="NO" # Default output interface for scoped addrs. # This works only with # ipv6_gateway_enable="NO". That pretty much it, nothing special I haven't made any changes to it in over 2 years. The only thing about 1 year ago I enabled: ### Network link/usability verification options netwait_enable="YES" # Enable rc.d/netwait (or NO) netwait_ip="192.168.0.1" # IP addresses to be pinged by netwait. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 01:37:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44189F01; Thu, 3 Jan 2013 01:37:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0349CE15; Thu, 3 Jan 2013 01:37:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r031bIXe061541; Wed, 2 Jan 2013 20:37:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r031bIvP061529; Thu, 3 Jan 2013 01:37:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 3 Jan 2013 01:37:18 GMT Message-Id: <201301030137.r031bIvP061529@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 01:37:25 -0000 TB --- 2013-01-03 00:12:40 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-03 00:12:40 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-03 00:12:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-01-03 00:12:40 - cleaning the object tree TB --- 2013-01-03 00:12:40 - /usr/local/bin/svn stat /src TB --- 2013-01-03 00:14:21 - At svn revision 244959 TB --- 2013-01-03 00:14:22 - building world TB --- 2013-01-03 00:14:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-03 00:14:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-03 00:14:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-03 00:14:22 - SRCCONF=/dev/null TB --- 2013-01-03 00:14:22 - TARGET=powerpc TB --- 2013-01-03 00:14:22 - TARGET_ARCH=powerpc TB --- 2013-01-03 00:14:22 - TZ=UTC TB --- 2013-01-03 00:14:22 - __MAKE_CONF=/dev/null TB --- 2013-01-03 00:14:22 - cd /src TB --- 2013-01-03 00:14:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 3 00:14:27 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 [...] ranlib libllvmasmprinter.a ===> lib/clang/libllvmbitreader (all) c++ -O2 -pipe -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/include -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader -I. -I/src/lib/clang/libllvmbitreader/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp -o BitcodeReader.o /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp: In member function 'bool llvm::BitcodeReader::ParseFunctionBody(llvm::Function*)': /src/lib/clang/libllvmbitreader/../../../contrib/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1905: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [BitcodeReader.o] Error code 1 Stop in /src/lib/clang/libllvmbitreader. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-03 01:37:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-03 01:37:18 - ERROR: failed to build world TB --- 2013-01-03 01:37:18 - 4087.23 user 492.52 system 5077.28 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 03:09:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2D418C7 for ; Thu, 3 Jan 2013 03:09:44 +0000 (UTC) (envelope-from kaho@ed.niigata-u.ac.jp) Received: from caav02.cais.niigata-u.ac.jp (caav02.cais.niigata-u.ac.jp [133.35.17.134]) by mx1.freebsd.org (Postfix) with ESMTP id 8A46D103 for ; Thu, 3 Jan 2013 03:09:44 +0000 (UTC) Received: from caav02.cais.niigata-u.ac.jp (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5AA612829F5; Thu, 3 Jan 2013 12:09:13 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (pf2.ed.niigata-u.ac.jp [133.35.172.22]) by caav02.cais.niigata-u.ac.jp (Postfix) with ESMTPS id 3E2752817DE; Thu, 3 Jan 2013 12:09:13 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (localhost [127.0.0.1]) by pf2.ed.niigata-u.ac.jp (8.14.6/8.14.6) with ESMTP id r0339AT6089161; Thu, 3 Jan 2013 12:09:13 +0900 (JST) (envelope-from kaho@pf2.ed.niigata-u.ac.jp) To: Manfred Antar From: KAHO Toshikazu Subject: Re: loopback interface broken on current X-Mailer: MH-E 8.3.1; MH 6.8.4.JP-3.05; GNU Emacs 24.2.1 References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/24.2 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Jan 2013 12:09:10 +0900 Message-ID: <89160.1357182550@pf2.ed.niigata-u.ac.jp> Sender: kaho@ed.niigata-u.ac.jp Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 03:09:44 -0000 Hello, I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf. Can you remove lo0 configure line from /etc/rc.conf. > /etc/rc.conf: > ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. -- vinwa@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 03:55:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BFD4EDF8; Thu, 3 Jan 2013 03:55:18 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 82A13273; Thu, 3 Jan 2013 03:55:18 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r033t4aI001542 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 19:55:05 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201301030355.r033t4aI001542@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Jan 2013 19:54:59 -0800 To: KAHO Toshikazu From: Manfred Antar Subject: Re: loopback interface broken on current In-Reply-To: <89160.1357182550@pf2.ed.niigata-u.ac.jp> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r033t4aI001542 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: , freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 03:55:18 -0000 At 07:09 PM 1/2/2013, KAHO Toshikazu wrote: > Hello, > >I have a similar problem if "ifconfig_lo0" line is exist in /etc/rc.conf. >Can you remove lo0 configure line from /etc/rc.conf. > >> /etc/rc.conf: >> ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. Ok I commented out that line and it seems to work. There is still ====>ifa_del_loopback_route: deletion failed: 3 that wasn't there before,but the 127.0.0.1 seems to be configured now: Setting hostname: pozo.com. bge0: link state changed to DOWN ifa_del_loopback_route: deletion failed: 3 bge0: link state changed to UP Starting Network: lo0 bge0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:0e:7f:66:30:20 inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::20e:7fff:fe66:3020%bge0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active Starting devd. add net default: gateway 192.168.0.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Waiting for bge0 to have link. Waiting for 192.168.0.1 to respond to ICMP. ######################################################################### (~)4999}ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.039 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.050 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.045 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.042 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.044 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.047 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.045 ms ^C --- localhost ping statistics --- 8 packets transmitted, 8 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.029/0.043/0.050/0.006 ms (~)5000} Manfred ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 05:52:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E965A71D; Thu, 3 Jan 2013 05:52:45 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id E335C6CE; Thu, 3 Jan 2013 05:52:44 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id d13so5967972eaa.7 for ; Wed, 02 Jan 2013 21:52:38 -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=YIee0nzPlls5BnzFjKLFHW7KoULSislsRykqse+eXTw=; b=PhzqX8ilrQY+1U+fo3LmWn5BIEhr+UvMkrclm3V7ctg08p26oOrMSmLRsy7YofqmGN U75qKZv4DoBeDgOiVn91Jk71GnGNOlDVo+/7Xs07TiPgs/KdKMxin+m8JUOkbkL+yZvA 33OnhVMRQwIRxc/mRBlwEM2ZI8eCr0NcIEb8kZNeiCM6RzosYQDY5G/qknV9iv4EHjz9 jTofSwPkY8GOX/Oq9i/9fznwptIZ1BNRGpMXu7uV9gU79nvYg2ZCW7rDyB24p5/tVpY/ +E9R8WjEUDbVAI7RpCJ3fofcO6NinxswQJPmk5EIfF+MUHBeXy2PCSLkbpmbY8xUH2RI Hg0g== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr130647516eem.43.1357192358178; Wed, 02 Jan 2013 21:52:38 -0800 (PST) Received: by 10.223.170.193 with HTTP; Wed, 2 Jan 2013 21:52:37 -0800 (PST) In-Reply-To: <50E4AF4C.2070902@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <1357135374.54953.150.camel@revolution.hippie.lan> <50E4AF4C.2070902@FreeBSD.org> Date: Wed, 2 Jan 2013 21:52:37 -0800 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Kevin Oberman To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: Davide Italiano , Ian Lepore , Adrian Chadd , Marius Strobl , FreeBSD Current , freebsd-arch@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 05:52:46 -0000 On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin wrote: > On 02.01.2013 18:08, Adrian Chadd wrote: >> >> .. I'm pretty damned sure we're going to need to enforce a "never >> earlier than X" latency. > > > Do you mean here that we should never wake up before specified time (just as > specified by the most of existing APIs), or that we should not allow sleep > shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't > allow to block the system. Also there is already present mechanism for > specifying minimum timer programming interval in eventtimers(9) KPI. I can see serious performance issues with some hardware (wireless comes to mind) if things happen too quickly. Intuition is that it could also play hob with VMs. I believe that the proper way is to wake between T_X and T_X + D. This assumes that D is max_wake_delay, not deviation, which leaves us at the original of (T_X) =< event_time =< (T_X + D). -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 08:42:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5737B333; Thu, 3 Jan 2013 08:42:25 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 06BBB6CF; Thu, 3 Jan 2013 08:42:24 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C099A7300A; Thu, 3 Jan 2013 09:41:26 +0100 (CET) Date: Thu, 3 Jan 2013 09:41:26 +0100 From: Luigi Rizzo To: Kevin Oberman Subject: Re: [RFC/RFT] calloutng Message-ID: <20130103084126.GC54360@onelab2.iet.unipi.it> References: <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <1357135374.54953.150.camel@revolution.hippie.lan> <50E4AF4C.2070902@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Davide Italiano , Ian Lepore , Adrian Chadd , Alexander Motin , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 08:42:25 -0000 On Wed, Jan 02, 2013 at 09:52:37PM -0800, Kevin Oberman wrote: > On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin wrote: > > On 02.01.2013 18:08, Adrian Chadd wrote: > >> > >> .. I'm pretty damned sure we're going to need to enforce a "never > >> earlier than X" latency. > > > > > > Do you mean here that we should never wake up before specified time (just as > > specified by the most of existing APIs), or that we should not allow sleep > > shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't > > allow to block the system. Also there is already present mechanism for > > specifying minimum timer programming interval in eventtimers(9) KPI. > > I can see serious performance issues with some hardware (wireless > comes to mind) if things happen too quickly. Intuition is that it > could also play hob with VMs. > > I believe that the proper way is to wake between T_X and T_X + D. > This assumes that D is max_wake_delay, not deviation, which leaves us > at the original of (T_X) =< event_time =< (T_X + D). i think "max delay" was the intended meaning of the D parameter. We picked bad names (tolerance, deviation,...) for it. cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 11:30:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DEE98977; Thu, 3 Jan 2013 11:30:52 +0000 (UTC) (envelope-from kaho@ed.niigata-u.ac.jp) Received: from caav02.cais.niigata-u.ac.jp (caav02.cais.niigata-u.ac.jp [133.35.17.134]) by mx1.freebsd.org (Postfix) with ESMTP id 94D5ACB; Thu, 3 Jan 2013 11:30:52 +0000 (UTC) Received: from caav02.cais.niigata-u.ac.jp (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C329A2817DD; Thu, 3 Jan 2013 20:30:30 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (pf2.ed.niigata-u.ac.jp [133.35.172.22]) by caav02.cais.niigata-u.ac.jp (Postfix) with ESMTPS id AA0B02817D8; Thu, 3 Jan 2013 20:30:30 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (localhost [127.0.0.1]) by pf2.ed.niigata-u.ac.jp (8.14.6/8.14.6) with ESMTP id r03BUIk0090300; Thu, 3 Jan 2013 20:30:22 +0900 (JST) (envelope-from kaho@pf2.ed.niigata-u.ac.jp) To: Manfred Antar From: KAHO Toshikazu Subject: Re: loopback interface broken on current References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> X-Mailer: MH-E 8.3.1; MH 6.8.4.JP-3.05; GNU Emacs 24.2.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/24.2 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Jan 2013 20:30:18 +0900 Message-ID: <90299.1357212618@pf2.ed.niigata-u.ac.jp> Sender: kaho@ed.niigata-u.ac.jp Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 11:30:52 -0000 Hello, > There is still ====>ifa_del_loopback_route: deletion failed: 3 > that wasn't there before,but the 127.0.0.1 seems to be configured now: Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? If you have it, try to remove it. I think something broken, but people using automatic configuration don't notice the breakage. -- kaho@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 13:07:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 978D84B7; Thu, 3 Jan 2013 13:07:28 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6CA743; Thu, 3 Jan 2013 13:07:28 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r03D7CmV048416 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 05:07:13 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201301031307.r03D7CmV048416@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Jan 2013 05:07:07 -0800 To: KAHO Toshikazu From: Manfred Antar Subject: Re: loopback interface broken on current In-Reply-To: <90299.1357212618@pf2.ed.niigata-u.ac.jp> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r03D7CmV048416 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:07:28 -0000 At 03:30 AM 1/3/2013, KAHO Toshikazu wrote: > Hello, > >> There is still ====>ifa_del_loopback_route: deletion failed: 3 >> that wasn't there before,but the 127.0.0.1 seems to be configured now: > > Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? >If you have it, try to remove it. > > I think something broken, but people using automatic configuration >don't notice the breakage. > >-- >kaho@elam.kais.kyoto-u.ac.jp > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. I have : network_interfaces="auto" ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" I will try to comment out the above line and see what happens. But I think it might screw up my routing ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 13:17:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52C0C6BC; Thu, 3 Jan 2013 13:17:53 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 186997C0; Thu, 3 Jan 2013 13:17:52 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r03DHdjN002901 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 05:17:40 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201301031317.r03DHdjN002901@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Jan 2013 05:17:34 -0800 To: KAHO Toshikazu From: Manfred Antar Subject: Re: loopback interface broken on current In-Reply-To: <90299.1357212618@pf2.ed.niigata-u.ac.jp> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r03DHdjN002901 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:17:53 -0000 At 03:30 AM 1/3/2013, KAHO Toshikazu wrote: > Hello, > >> There is still ====>ifa_del_loopback_route: deletion failed: 3 >> that wasn't there before,but the 127.0.0.1 seems to be configured now: > > Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? >If you have it, try to remove it. > > I think something broken, but people using automatic configuration >don't notice the breakage. > >-- >kaho@elam.kais.kyoto-u.ac.jp > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. Hi If I comment out : ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" Network doesn't work. ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 14:30:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD810EE5; Thu, 3 Jan 2013 14:30:11 +0000 (UTC) (envelope-from kaho@ed.niigata-u.ac.jp) Received: from caav01.cais.niigata-u.ac.jp (caav01.cais.niigata-u.ac.jp [133.35.17.133]) by mx1.freebsd.org (Postfix) with ESMTP id 98B2AAAC; Thu, 3 Jan 2013 14:30:11 +0000 (UTC) Received: from caav01.cais.niigata-u.ac.jp (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FBA4A25C5; Thu, 3 Jan 2013 23:10:47 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (pf2.ed.niigata-u.ac.jp [133.35.172.22]) by caav01.cais.niigata-u.ac.jp (Postfix) with ESMTPS id 57390A25BE; Thu, 3 Jan 2013 23:10:43 +0900 (JST) Received: from pf2.ed.niigata-u.ac.jp (localhost [127.0.0.1]) by pf2.ed.niigata-u.ac.jp (8.14.6/8.14.6) with ESMTP id r03EAZF1031970; Thu, 3 Jan 2013 23:10:39 +0900 (JST) (envelope-from kaho@pf2.ed.niigata-u.ac.jp) To: Manfred Antar From: KAHO Toshikazu Subject: Re: loopback interface broken on current References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> <201301031317.r03DHdjN002901@pozo.com> X-Mailer: MH-E 8.3.1; MH 6.8.4.JP-3.05; GNU Emacs 24.2.1 User-Agent: EMH/1.14.1 SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/24.2 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Jan 2013 23:10:35 +0900 Message-ID: <31969.1357222235@pf2.ed.niigata-u.ac.jp> Sender: kaho@ed.niigata-u.ac.jp Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 14:30:11 -0000 Hello, > If I comment out : > ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" > Network doesn't work. Yes, you should not commnet out it, you cannot connect from/to outside. network_interfaces="auto" is same as /etc/default/rc.conf, so that you can remove it safely from /etc/rc.conf. I cannot identify the problematic line caused the problem. -- vinwa@elam.kais.kyoto-u.ac.jp From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 14:49:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1816F7CB; Thu, 3 Jan 2013 14:49:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id BFC73CCA; Thu, 3 Jan 2013 14:49:19 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r03EnHad066185; Thu, 3 Jan 2013 09:49:17 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <50E59A6B.1000802@sentex.net> Date: Thu, 03 Jan 2013 09:49:15 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-Current Subject: steady stream of ath errors X-Enigmail-Version: 1.4.2 Content-Type: multipart/mixed; boundary="------------060805000506040404000304" X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 14:49:20 -0000 This is a multi-part message in MIME format. --------------060805000506040404000304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Experimenting with ath under RELENG8,9 and HEAD at home on my wifi router, I found that with current from today (r244989) gives a steady stream of errors. How can I debug the issue in my setup ? input (Total) output packets errs idrops bytes packets errs bytes colls 72 7 0 38865 78 0 76117 0 57 4 0 989 32 0 2062 0 47 0 0 3369 29 0 5724 0 1625 11 0 1394179 2214 0 2779765 0 3146 20 0 2369588 3955 0 4723911 0 3269 14 0 2499654 4130 0 4984206 0 3570 19 0 2549189 4330 0 5082261 0 3399 15 0 2485682 4201 0 4956613 0 3530 22 0 2612967 4375 0 5207076 0 3340 16 0 2371278 4040 0 4728272 0 3281 14 0 2321800 3947 0 4628010 0 3092 15 0 2263990 3826 0 4514317 0 2905 8 0 2124069 3572 0 4235585 0 3017 18 0 2229250 3722 0 4444773 0 2701 11 0 1709542 3064 0 3407885 0 2245 11 0 1918413 3038 0 3824605 0 3428 12 0 2508519 4251 0 5001890 0 3428 14 0 2473616 4180 0 4931945 0 3227 11 0 2264217 3886 0 4514416 0 3223 14 0 2403237 4016 0 4792172 0 3313 17 0 2402811 4048 0 4791158 0 ath0@pci0:2:0:0: class=0x028000 card=0x2c371a3b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network bar [10] = type Memory, range 64, base 0xfe9f0000, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[60] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0000000000000000 ecap 0004[170] = Power Budgeting 1 stats etc attached. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ --------------060805000506040404000304 Content-Type: text/plain; charset=windows-1252; name="ath.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ath.txt" 0{zotac}# ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 74:2f:68:af:b9:47 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running 0{zotac}# ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 74:2f:68:af:b9:47 inet6 fe80::762f:68ff:feaf:b947%wlan0 prefixlen 64 tentative scopeid 0x5 inet 192.168.241.129 netmask 0xffffff00 broadcast 192.168.241.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: running ssid policevan2 channel 6 (2437 MHz 11g ht/20) bssid 74:2f:68:af:b9:47 regdomain 96 indoor ecm authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 20 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -dfs 0{zotac}# 0{zotac}# sysctl -a dev.ath dev.ath.0.%desc: Atheros 9285 dev.ath.0.%driver: ath dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBP1.NP1S dev.ath.0.%pnpinfo: vendor=0x168c device=0x002b subvendor=0x1a3b subdevice=0x2c37 class=0x028000 dev.ath.0.%parent: pci2 dev.ath.0.smoothing_rate: 75 dev.ath.0.sample_rate: 10 dev.ath.0.sample_stats: 0 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 96 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 64 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.hardled: 0 dev.ath.0.led_net_pin: -1 dev.ath.0.led_pwr_pin: -1 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.txagg: 0 dev.ath.0.forcebstuck: 0 dev.ath.0.intmit: 1 dev.ath.0.monpass: 24 dev.ath.0.hwq_limit: 2 dev.ath.0.tid_hwq_lo: 2 dev.ath.0.tid_hwq_hi: 4 dev.ath.0.txq_data_minfree: 10 dev.ath.0.txq_mcastq_maxdepth: 512 dev.ath.0.clear_stats: 0 dev.ath.0.stats.ast_watchdog: 0 dev.ath.0.stats.ast_hardware: 0 dev.ath.0.stats.ast_bmiss: 0 dev.ath.0.stats.ast_bmiss_phantom: 0 dev.ath.0.stats.ast_bstuck: 0 dev.ath.0.stats.ast_rxorn: 0 dev.ath.0.stats.ast_rxeol: 0 dev.ath.0.stats.ast_txurn: 0 dev.ath.0.stats.ast_mib: 0 dev.ath.0.stats.ast_intrcoal: 0 dev.ath.0.stats.ast_tx_packets: 0 dev.ath.0.stats.ast_tx_mgmt: 0 dev.ath.0.stats.ast_tx_discard: 0 dev.ath.0.stats.ast_tx_qstop: 0 dev.ath.0.stats.ast_tx_encap: 0 dev.ath.0.stats.ast_tx_nonode: 0 dev.ath.0.stats.ast_tx_nombuf: 0 dev.ath.0.stats.ast_tx_nomcl: 0 dev.ath.0.stats.ast_tx_linear: 0 dev.ath.0.stats.ast_tx_nodata: 0 dev.ath.0.stats.ast_tx_busdma: 0 dev.ath.0.stats.ast_tx_xretries: 44 dev.ath.0.stats.ast_tx_fifoerr: 0 dev.ath.0.stats.ast_tx_filtered: 12 dev.ath.0.stats.ast_tx_shortretry: 218190 dev.ath.0.stats.ast_tx_longretry: 7514 dev.ath.0.stats.ast_tx_badrate: 0 dev.ath.0.stats.ast_tx_noack: 886 dev.ath.0.stats.ast_tx_rts: 0 dev.ath.0.stats.ast_tx_cts: 0 dev.ath.0.stats.ast_tx_shortpre: 874363 dev.ath.0.stats.ast_tx_altrate: 71 dev.ath.0.stats.ast_tx_protect: 0 dev.ath.0.stats.ast_tx_ctsburst: 0 dev.ath.0.stats.ast_tx_ctsext: 0 dev.ath.0.stats.ast_rx_nombuf: 0 dev.ath.0.stats.ast_rx_busdma: 0 dev.ath.0.stats.ast_rx_orn: 0 dev.ath.0.stats.ast_rx_crcerr: 19731 dev.ath.0.stats.ast_rx_fifoerr: 0 dev.ath.0.stats.ast_rx_badcrypt: 0 dev.ath.0.stats.ast_rx_badmic: 0 dev.ath.0.stats.ast_rx_phyerr: 0 dev.ath.0.stats.ast_rx_tooshort: 20 dev.ath.0.stats.ast_rx_toobig: 0 dev.ath.0.stats.ast_rx_packets: 0 dev.ath.0.stats.ast_rx_mgt: 0 dev.ath.0.stats.ast_rx_ctl: 0 dev.ath.0.stats.ast_be_xmit: 27393 dev.ath.0.stats.ast_be_nombuf: 0 dev.ath.0.stats.ast_per_cal: 95 dev.ath.0.stats.ast_per_calfail: 0 dev.ath.0.stats.ast_per_rfgain: 0 dev.ath.0.stats.ast_rate_calls: 0 dev.ath.0.stats.ast_rate_raise: 0 dev.ath.0.stats.ast_rate_drop: 0 dev.ath.0.stats.ast_ant_defswitch: 0 dev.ath.0.stats.ast_ant_txswitch: 0 dev.ath.0.stats.ast_cabq_xmit: 0 dev.ath.0.stats.ast_cabq_busy: 0 dev.ath.0.stats.ast_tx_raw: 189 dev.ath.0.stats.ast_ff_txok: 0 dev.ath.0.stats.ast_ff_txerr: 0 dev.ath.0.stats.ast_ff_rx: 0 dev.ath.0.stats.ast_ff_flush: 0 dev.ath.0.stats.ast_tx_qfull: 0 dev.ath.0.stats.ast_tx_nobuf: 0 dev.ath.0.stats.ast_tdma_update: 0 dev.ath.0.stats.ast_tdma_timers: 0 dev.ath.0.stats.ast_tdma_tsf: 0 dev.ath.0.stats.ast_tdma_ack: 0 dev.ath.0.stats.ast_tx_raw_fail: 0 dev.ath.0.stats.ast_tx_nofrag: 0 dev.ath.0.stats.ast_be_missed: 6 dev.ath.0.stats.ast_ani_cal: 28052 dev.ath.0.stats.ast_rx_agg: 419069 dev.ath.0.stats.ast_rx_halfgi: 0 dev.ath.0.stats.ast_rx_2040: 0 dev.ath.0.stats.ast_rx_pre_crc_err: 244 dev.ath.0.stats.ast_rx_post_crc_err: 223 dev.ath.0.stats.ast_rx_decrypt_busy_err: 0 dev.ath.0.stats.ast_rx_hi_rx_chain: 0 dev.ath.0.stats.ast_tx_htprotect: 301169 dev.ath.0.stats.ast_rx_hitqueueend: 0 dev.ath.0.stats.ast_tx_timeout: 0 dev.ath.0.stats.ast_tx_cst: 0 dev.ath.0.stats.ast_tx_xtxop: 0 dev.ath.0.stats.ast_tx_timerexpired: 0 dev.ath.0.stats.ast_tx_desccfgerr: 0 dev.ath.0.stats.ast_tx_swretries: 3027 dev.ath.0.stats.ast_tx_swretrymax: 0 dev.ath.0.stats.ast_tx_data_underrun: 0 dev.ath.0.stats.ast_tx_delim_underrun: 0 dev.ath.0.stats.ast_tx_aggr_failall: 4 dev.ath.0.stats.ast_tx_aggr_ok: 773187 dev.ath.0.stats.ast_tx_aggr_fail: 3025 dev.ath.0.stats.ast_rx_intr: 207166 dev.ath.0.stats.ast_tx_intr: 319444 dev.ath.0.stats.ast_tx_mcastq_overflow: 0 dev.ath.0.stats.ast_rx_keymiss: 0 dev.ath.0.stats.ast_tx_swfiltered: 57 dev.ath.0.stats.rx_phy_err.0: 0 dev.ath.0.stats.rx_phy_err.1: 0 dev.ath.0.stats.rx_phy_err.2: 0 dev.ath.0.stats.rx_phy_err.3: 0 dev.ath.0.stats.rx_phy_err.4: 0 dev.ath.0.stats.rx_phy_err.5: 0 dev.ath.0.stats.rx_phy_err.6: 0 dev.ath.0.stats.rx_phy_err.7: 0 dev.ath.0.stats.rx_phy_err.8: 0 dev.ath.0.stats.rx_phy_err.9: 0 dev.ath.0.stats.rx_phy_err.10: 0 dev.ath.0.stats.rx_phy_err.11: 0 dev.ath.0.stats.rx_phy_err.12: 0 dev.ath.0.stats.rx_phy_err.13: 0 dev.ath.0.stats.rx_phy_err.14: 0 dev.ath.0.stats.rx_phy_err.15: 0 dev.ath.0.stats.rx_phy_err.16: 0 dev.ath.0.stats.rx_phy_err.17: 0 dev.ath.0.stats.rx_phy_err.18: 0 dev.ath.0.stats.rx_phy_err.19: 0 dev.ath.0.stats.rx_phy_err.20: 0 dev.ath.0.stats.rx_phy_err.21: 0 dev.ath.0.stats.rx_phy_err.22: 0 dev.ath.0.stats.rx_phy_err.23: 0 dev.ath.0.stats.rx_phy_err.24: 0 dev.ath.0.stats.rx_phy_err.25: 0 dev.ath.0.stats.rx_phy_err.26: 0 dev.ath.0.stats.rx_phy_err.27: 0 dev.ath.0.stats.rx_phy_err.28: 0 dev.ath.0.stats.rx_phy_err.29: 0 dev.ath.0.stats.rx_phy_err.30: 0 dev.ath.0.stats.rx_phy_err.31: 0 dev.ath.0.stats.rx_phy_err.32: 0 dev.ath.0.stats.rx_phy_err.33: 0 dev.ath.0.stats.rx_phy_err.34: 0 dev.ath.0.stats.rx_phy_err.35: 0 dev.ath.0.stats.rx_phy_err.36: 0 dev.ath.0.stats.rx_phy_err.37: 0 dev.ath.0.stats.rx_phy_err.38: 0 dev.ath.0.stats.rx_phy_err.39: 0 dev.ath.0.stats.rx_phy_err.40: 0 dev.ath.0.stats.rx_phy_err.41: 0 dev.ath.0.stats.rx_phy_err.42: 0 dev.ath.0.stats.rx_phy_err.43: 0 dev.ath.0.stats.rx_phy_err.44: 0 dev.ath.0.stats.rx_phy_err.45: 0 dev.ath.0.stats.rx_phy_err.46: 0 dev.ath.0.stats.rx_phy_err.47: 0 dev.ath.0.stats.rx_phy_err.48: 0 dev.ath.0.stats.rx_phy_err.49: 0 dev.ath.0.stats.rx_phy_err.50: 0 dev.ath.0.stats.rx_phy_err.51: 0 dev.ath.0.stats.rx_phy_err.52: 0 dev.ath.0.stats.rx_phy_err.53: 0 dev.ath.0.stats.rx_phy_err.54: 0 dev.ath.0.stats.rx_phy_err.55: 0 dev.ath.0.stats.rx_phy_err.56: 0 dev.ath.0.stats.rx_phy_err.57: 0 dev.ath.0.stats.rx_phy_err.58: 0 dev.ath.0.stats.rx_phy_err.59: 0 dev.ath.0.stats.rx_phy_err.60: 0 dev.ath.0.stats.rx_phy_err.61: 0 dev.ath.0.stats.rx_phy_err.62: 0 dev.ath.0.stats.rx_phy_err.63: 0 dev.ath.0.stats.sync_intr.0: 0 dev.ath.0.stats.sync_intr.1: 0 dev.ath.0.stats.sync_intr.2: 0 dev.ath.0.stats.sync_intr.3: 0 dev.ath.0.stats.sync_intr.4: 0 dev.ath.0.stats.sync_intr.5: 0 dev.ath.0.stats.sync_intr.6: 0 dev.ath.0.stats.sync_intr.7: 0 dev.ath.0.stats.sync_intr.8: 0 dev.ath.0.stats.sync_intr.9: 0 dev.ath.0.stats.sync_intr.10: 0 dev.ath.0.stats.sync_intr.11: 0 dev.ath.0.stats.sync_intr.12: 0 dev.ath.0.stats.sync_intr.13: 0 dev.ath.0.stats.sync_intr.14: 0 dev.ath.0.stats.sync_intr.15: 0 dev.ath.0.stats.sync_intr.16: 0 dev.ath.0.stats.sync_intr.17: 0 dev.ath.0.stats.sync_intr.18: 0 dev.ath.0.stats.sync_intr.19: 0 dev.ath.0.stats.sync_intr.20: 0 dev.ath.0.stats.sync_intr.21: 0 dev.ath.0.stats.sync_intr.22: 0 dev.ath.0.stats.sync_intr.23: 0 dev.ath.0.stats.sync_intr.24: 0 dev.ath.0.stats.sync_intr.25: 0 dev.ath.0.stats.sync_intr.26: 0 dev.ath.0.stats.sync_intr.27: 0 dev.ath.0.stats.sync_intr.28: 0 dev.ath.0.stats.sync_intr.29: 0 dev.ath.0.stats.sync_intr.30: 0 dev.ath.0.stats.sync_intr.31: 0 dev.ath.0.hal.debug: 0 dev.ath.0.hal.ar5416_biasadj: 0 dev.ath.0.hal.dma_brt: 2 dev.ath.0.hal.sw_brt: 10 dev.ath.0.hal.swba_backoff: 0 dev.ath.0.hal.force_full_reset: 0 dev.ath.0.hal.serialise_reg_war: 0 dev.ath.0.wake: 0 0{zotac}# 0{zotac}# cat /var/run/dmesg.boot Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r244989: Thu Jan 3 06:32:57 EST 2013 mdtancsa@cage.simianscience.com:/usr/HEAD/obj/i386.i386/pxe/HEAD/src/sys/alix i386 CPU: VIA Nano X2 U4025 @ 1.2 GHz (1200.07-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6fc Family = 0x6 Model = 0xf Stepping = 12 Features=0xbfc9fbff Features2=0x8863a9 AMD Features=0x20100800 VIA Padlock Features=0x1ec13dcc TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3405004800 (3247 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <083011 APIC0920> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 3 ioapic1: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: <083011 XSDT0920> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fed02000, 1000 (3) failed acpi0: reservation of fed03000, 1000 (3) failed acpi0: reservation of fed05000, 1000 (3) failed acpi0: reservation of fff00000, 100000 (3) failed acpi0: reservation of fecc0000, 1000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xfc000000-0xfcffffff,0xfd000000-0xfdffffff,0xd0000000-0xdfffffff irq 40 at device 1.0 on pci0 pci0: at device 1.1 (no driver attached) pcib1: irq 27 at device 3.0 on pci0 pci1: on pcib1 pcib2: irq 31 at device 3.1 on pci0 pci2: on pcib2 ath0: mem 0xfe9f0000-0xfe9fffff irq 28 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] 1 RX streams; 1 TX streams ath0: AR9285 mac 192.2 RF5133 phy 14.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 pcib3: irq 35 at device 3.2 on pci0 pci3: on pcib3 vge0: port 0xe800-0xe8ff mem 0xfeaffc00-0xfeaffcff irq 32 at device 0.0 on pci3 vge0: Using 1 MSI message miibus0: on vge0 ip1000phy0: PHY 1 on miibus0 ip1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow vge0: Ethernet address: 00:01:2e:3a:a5:a8 pcib4: irq 39 at device 3.3 on pci0 pci4: on pcib4 xhci0: mem 0xfebff000-0xfebfffff irq 36 at device 0.0 on pci4 xhci0: 32 byte context size. usbus0 on xhci0 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f irq 21 at device 15.0 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 uhci0: port 0xd080-0xd09f irq 20 at device 16.0 on pci0 uhci0: LegSup = 0xa000 usbus1 on uhci0 uhci1: port 0xd000-0xd01f irq 22 at device 16.1 on pci0 uhci1: LegSup = 0xa000 usbus2 on uhci1 uhci2: port 0xcc00-0xcc1f irq 21 at device 16.2 on pci0 uhci2: LegSup = 0xa000 usbus3 on uhci2 uhci3: port 0xc880-0xc89f irq 23 at device 16.3 on pci0 uhci3: LegSup = 0xa000 usbus4 on uhci3 ehci0: mem 0xfe8ebc00-0xfe8ebcff irq 23 at device 16.4 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 pcib5: at device 19.0 on pci0 pci5: on pcib5 pci0: at device 20.0 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ctl: CAM Target Layer loaded est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: <0x1106> at usbus0 uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 uhub0: 5 ports with 4 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 9375540 Hz quality 800 Root mount waiting for: usbus5 usbus0 ugen0.2: at usbus0 uhub6: on usbus0 uhub6: 4 ports with 4 removable, self powered Root mount waiting for: usbus5 uhub5: 8 ports with 8 removable, self powered Root mount waiting for: usbus5 Trying to mount root from nfs: []... NFS ROOT: 192.168.0.12:/pxe/HEAD ugen4.2: at usbus4 wlan0: Ethernet address: 74:2f:68:af:b9:47 0{zotac}# --------------060805000506040404000304-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 14:45:55 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8ED726E5; Thu, 3 Jan 2013 14:45:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id F2217C2F; Thu, 3 Jan 2013 14:45:54 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r03EjbNs031145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 01:45:39 +1100 Date: Fri, 4 Jan 2013 01:45:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin Subject: Re: [RFC/RFT] calloutng In-Reply-To: <50E4A902.4050307@FreeBSD.org> Message-ID: <20130103232413.O947@besplex.bde.org> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> <50E4A902.4050307@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=BrrFWvr5 c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=F1MZp-0HJ9x99sWca6YA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 X-Mailman-Approved-At: Thu, 03 Jan 2013 15:57:20 +0000 Cc: Davide Italiano , Ian Lepore , Marius Strobl , FreeBSD Current , freebsd-arch@FreeBSD.org, Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 14:45:55 -0000 On Wed, 2 Jan 2013, Alexander Motin wrote: > On 02.01.2013 19:09, Konstantin Belousov wrote: >> On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote: >>> Probably one way to close this discussion would be to provide >>> a sysctl so the sysadmin can decide which point in the interval >>> to pick when there is no suitable callout already scheduled. >> Isn't trying to synchronize to the external events in this way unsafe ? >> I remember, but cannot find the reference right now, a scheduler >> exploit(s) which completely hide malicious thread from the time >> accounting, by making it voluntary yielding right before statclock >> should fire. If statistic gathering could be piggy-backed on the >> external interrupt, and attacker can control the source of the external >> events, wouldn't this give her a handle ? Fine-grained timeouts complete fully opening this security hole. Synchronization without fine-grained timeouts might allow the same, but is harder to exploit since you can't control the yielding points directly. With fine-grained timeouts, you just have to predict the statclock firing points. Use one timeout to arrange to yield just before statclock fires and another to regain control just after it has fired. If the timeout resolution is say 50 usec, then this can hope to run for all except 100 usec out of every 1/stathz seconds. With stathz = 128, 1/stathz is 7812 usec, so this gives 7712/7812 of the CPU with 0 statclock ticks. Since the scheduler never sees you running, your priority remains minimal, so the scheduler should prefer to run you whenever a timeout expires, with only round-robin with other minimal-priority threads preventing you getting 7712/7812 of the (user non-rtprio) CPU. The previous stage of fully opening this security hole was changing (the default) HZ from 100 to 1000. HZ must not be much smaller than stathz, else the security hole is almost fully open. With HZ = 100 being less than stathz and timeout granularity limiting the fine control to 2/HZ = 20 msec (except you can use a periodic itimer to get a 1/HZ granularity at a minor cost of getting more SIGALRMs), it is impossible to get near 100% of the CPU with 0 statclock ticks. After yielding, you can't get control for another 100 or 200 msec. Since this exceeds 1/stathz = 78.12 usec, you can only hide from statclock ticks by not running very often or for very long. Limited hiding is possible by wasting even more CPU to determine when to hide: since the timeout granularity is large, it is also ineffective for determining when to yield. So when running, you must poll the current time a lot to determine when to yield. Yield just before statclock fires, as above. (Do it 50 usec early, as above, to avoid most races involving polling the time.) This actually has good chances of not limiting the hiding too much, depending on the details of the scheduling. It yields just before a statclock tick. After this tick fires, if the scheduler reschedules for any reason, then the hiding process would most likely be run again, since its priority is minimal. But at least the old 4BSD scheduler doesn't reschedule after _every_ statclock tick. This depends on the bugfeature that the priority is not checked on _every_ return to user mode (sched_clock() does change the priority, but this is not acted on until much later). Without this bugfeature, there would be excessive context switches. OTOH, with timeouts, at least old non-fine-grained ones, you can force a rescheduling that is acted on soon enough simply by using timeouts (since timeouts give a context switch to the softclock thread, the scheduler has no option to skip checking the priority on return to user mode). After the previous stage of changing HZ to 1000, the granuarity is fine enough for using timeouts to hide from the scheduler. Using a periodic itimer to get a granularity of 1000 usec, start hiding 50-1000 usec before each statclock tick and regain control 1000 usec later. With stathz = 128, 6812/7812 of the CPU with 0 statclock ticks. Not much worse (for the hider) than 7712/7812. Statclock was supposed to be aperiodic to avoid hiding (see statclk-usenix93.ps), but this was never implemented in FreeBSD. With fine-grained timeouts, it would have to be very aperiodic, to the point of giving large inaccuracies, to limit the hiding very much. For example, suppose that it has an average period of 7812 usec with +-50% jitter. You would try to hide from it most of the time by running for a bit less than 7812/2 usec before yielding in most cases. If too much scheduling is done on each statclock tick, then you are likely to regain control after each one (as above) and then know that there is almost a full minimal period until the next one. Otherwise, it seems to be necessary to determine when the previous statclock tick occurred, so as to determine the minimum time until the next one. > There are many different kinds of accounting with different characteristics. > Run time for each thread calculated using high resolution per-CPU clocks on > each context switch. It is impossible to hide from it. But this (td_runtime) is not used at all for scheduling, since the high-resolution per-CPU clocks didn't exist originally and now since reading of them is expensive. However, the read is done on every context switch. This pessimizes context switches, with the pessimization reduced a little by using inaccurate cpu_ticks() timers instead of timecounters, so the expenses for using td_runtime for scheduling are mostly already paid for. The main case where it doesn't work is when there are few context switches, but there are usually more than a few for interrupts to ithreads for network and disk i/o. Updating td_runtime in statclock() (where it is not normally updated since there is no context switch) would probably make td_runtime usable for scheduling without increasing the pessimization much. > System load average > updated using callout and aligned with hardclock(). Hiding from it was easy > before, but it can be made more complicated (asynchronous) now. I think you mean it was easy because the timeout period is so long. Any aperiodicity in a timer of course means that it is harder to predict. The load average timeout was already randomized (I think it is 5 +- 2 seconds with 1/hz granularity). That is a large variance, but you can still hide from it about 3/5 of the time. loadav is not very important, and is not even used by SCHED_ULE. SCHED_ULE uses more fine-grained statistics based on statclock. > Per-CPU > SYSTEM/INTERRUPT/USER/NICE/IDLE counters are updated by statcklock(), that is > asynchronous to hardclock() and hiding from it supposed to be more > complicated. But even before it was possible, since hardclock() frequency is > 8 times higher then statclock() one. These are not used for scheduling. In SCHED_4BSD, little more than the event of a statclock tick is used for scheduling. sched_clock() uses this to update td_estcpu and then the priority but not much more. In SCHED_ULE, sched_clock() updates many more private variables. There are also statistics for memory use and similar things maintained by statclock(). These are not very important, like loadav for SCHED_ULE (purely information, for userland). I don't see s better way than _periodic_ statclock ticks for maintaining these. Aperiodicity just makes them less accurate for the usual case where there is no hiding (unless this is not the usual case, due to accidental synchronization causing non-malicious hiding, and if this is a problem then it can be fixed using only a small amount of aperiodicity). > More important for scheduling fairness > thread's CPU percentage is also based on hardclock() and hiding from it was > trivial before, since all sleep primitives were strictly aligned to > hardclock(). Now it is slightly less trivial, since this alignment was > removed and user-level APIs provide no easy way to enforce it. %cpu is actually based on statclock(), and not even used for scheduling. The alignment of sleep primitives mainly increased the chances of accidental synchronization. (This was apparently a problem when all clocks were derived from the lapic timer. I didn't like the fixes for that.) For malicious hiding, it only makes the hiding less trivial for hardclock ticks to be periodic and somewhat aligned with statclock ticks. The phase will drift, so that there is no long-term alignment, unless the clocks are derived for the same one (and not randomized). So the statclock firings will sometimes be mispredicted, or the hiding would have to be conservative, or the prediction updated a lot. It is simplest and probably most malicious to accept occasional mispredictions and recalibrate the prediction after missing. This is any easy case of relcalibrating often for highly aperiodic statclocks. > The only way to get really safe accounting is forget about sampling and use > potentially more expensive other ways. It was always stopped by lack of cheap > and reliable clocks. But since TSC is P-state invariant on most of CPUs > present now it could probably be reconsidered. And even if the clock is expensive and unreliable, it is already used for td_runtime, as described above. Large unreliability is actually less of a problem for scheduling than for td_runtime -- an error of 50% would barely affect scheduling since scheduling is only heuristic, but if td_runtime is off by 50% (as it often is without P-state invariance and with longstanding bugs in cpu_ticks() calibration), then it gives nonsense like user times exceeding real times by 50%. When I last thought about using reliable clocks for statistics, I was most interested in simplifiying things by removing all the the tick counters and not in making schedulers fairer. I still can't see how to do the former. To do the user/sys/interrupt accounting accurately, the clock would have to be read on every syscall entry and exit, and that is too much (it is bad enough that it is read on almost every interrupt, without even making interrupt accounting actually work right). But for scheduling decisions, a fuzzy copy of the full td_runtime is enough, at least for SCHED_4BSD. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 15:58:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CB2B299 for ; Thu, 3 Jan 2013 15:58:22 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm6.bullet.mail.ird.yahoo.com (nm6.bullet.mail.ird.yahoo.com [77.238.189.63]) by mx1.freebsd.org (Postfix) with ESMTP id EFB6412B for ; Thu, 3 Jan 2013 15:58:21 +0000 (UTC) Received: from [77.238.189.232] by nm6.bullet.mail.ird.yahoo.com with NNFMP; 03 Jan 2013 15:58:19 -0000 Received: from [217.146.188.63] by tm13.bullet.mail.ird.yahoo.com with NNFMP; 03 Jan 2013 15:58:19 -0000 Received: from [127.0.0.1] by smtp105.mail.ird.yahoo.com with NNFMP; 03 Jan 2013 15:58:19 -0000 X-Yahoo-Newman-Id: 750553.4072.bm@smtp105.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nWMt1pQVM1mDOMMQUQrNtd1wP.qRcsW0a465oUs3ywlRfb7 rwl0c4pSIcfyvIj1Xm3aq8wu_rslQHCR40IrjOeLK6VwrmQRVji_EBux5yBq .A.GrH54OqS20qHz.EyHFM8705Eq1lwbOvPPC8VU_UrjzNmHYUYswig1dUzi mUqYyt57TPDYqNCOP3Dqpds6xHvSGT0wHaQWcAWDFMwppR8NfIdTDY80O1yM 6V6QxQOhwGWxccIzbM_hccv3eWJjNHtKXQFh3F1P_9KjjfgwErGRQ0Yj0tYg FvE5cnrPa99vDTJhh3wRoeWnZZH1N_aNvBJqYnuSjvFL6mfpApkLKBm4Rl0B BvFhcZhsaCJQI1hT5lPvWoPk67N3HD7Y4HlTqVNUKGeQYKuIXeiUt2xEgHER eft8VS8i7CJh01qh12r5Dcqkij.SE7p5VUoaMy8Gn8ARd X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.11] (se@87.158.27.114 with plain) by smtp105.mail.ird.yahoo.com with SMTP; 03 Jan 2013 07:58:19 -0800 PST Message-ID: <50E5AA95.5080603@freebsd.org> Date: Thu, 03 Jan 2013 16:58:13 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: installworld failure due to cross-device links References: <50E42264.4010609@freebsd.org> <50E4357B.7020400@freebsd.org> In-Reply-To: <50E4357B.7020400@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:58:22 -0000 Am 02.01.2013 14:26, schrieb Nathan Whitehorn: > On 01/02/13 07:04, Stefan Esser wrote: >> I'd be interested in the general policy on LINKS vs. SYMLINKS >> between directories that might end up on different file systems. >> >> There seems to be an assumption that system directories in /usr >> (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file >> system, but I do not think that this assumption is documented. >> >> I'm using a ZFS only installation of -CURRENT and have separate file >> systems for several of the directories in / and /usr, that usually >> share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin >> and /usr/libexec are independent file systems). >> >> An older case is the link from /usr/bin/chgrp to /usr/sbin/chown >> (see usr.sbin/chown/Makefile), which is easily fixed by using a >> SMYLINK instead of a LINK. >> >> And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of >> r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. >> >> This breaks with /usr/bin and /usr/sbin on different file systems, >> while it should not according to the commit message: >> > > Thanks for the patch! I've committed it (slightly modified) as r244958. > I haven't taken any action on the chgrp/chown issue, though. Thanks for the fix. Seems I had a wrong idea of the semantics of the (SYM)LINKS macro, as I had assumed that the build target would be linked to the list of names (instead of pairs of source/dest). I did not expect you to do anything with chown/chgrp, but I still think there should be a policy on whether hard links may be used to connect files in different directories (which might be in different file systems). Regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 16:12:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 32EE842C; Thu, 3 Jan 2013 16:12:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4875F192; Thu, 3 Jan 2013 16:12:24 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id fj20so8223223lab.38 for ; Thu, 03 Jan 2013 08:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ph9x+C/HqilLh+giuX2YFQtzManr/VaLiqQB1Y/XUuA=; b=cn7hfXcSx2tfRJOyNVaZxZxUQr62OM29cZRc+20Z8lsortEHEpc3O0v6F/KdH6SPhF EfKysg2/bmPoaAzkbcZPXk5LfevG2KebC4gbRIZVEh5W2L8O0hIaMCrE6x0ScscLY/d4 p8l+U6cDUtmT8jHOSb4tlLXtNEK54wWv9FLz5mo+IYa0xuQU8Dt5GJ+7d1A3iVxYFRQF yfOl6Fp8+ee7Hnd5EuKnbjmF4if7tcy7sMAiV2YdY+NC76yq1gLARnD0Wzqq0Hz5P9sV oEm4Zlws7Ee08bZPSnmyjone6sze43OS+Bo489yXyhi4M0YmQ6IrMqAN4a6WU7/IbNSf pFoQ== X-Received: by 10.112.38.72 with SMTP id e8mr15978420lbk.123.1357229543977; Thu, 03 Jan 2013 08:12:23 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id hc20sm18566188lab.11.2013.01.03.08.12.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2013 08:12:21 -0800 (PST) Sender: Alexander Motin Message-ID: <50E5ADE1.4020104@FreeBSD.org> Date: Thu, 03 Jan 2013 18:12:17 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans Subject: Re: [RFC/RFT] calloutng References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> <50E4A902.4050307@FreeBSD.org> <20130103232413.O947@besplex.bde.org> In-Reply-To: <20130103232413.O947@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , Marius Strobl , FreeBSD Current , freebsd-arch@FreeBSD.org, Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:12:26 -0000 On 03.01.2013 16:45, Bruce Evans wrote: > On Wed, 2 Jan 2013, Alexander Motin wrote: >> More important for scheduling fairness thread's CPU percentage is also >> based on hardclock() and hiding from it was trivial before, since all >> sleep primitives were strictly aligned to hardclock(). Now it is >> slightly less trivial, since this alignment was removed and user-level >> APIs provide no easy way to enforce it. > > %cpu is actually based on statclock(), and not even used for scheduling. May be for SCHED_4BSD, but not for SCHED_ULE. In SCHED_ULE both %cpu and thread priority based on the same ts_ticks counter, that is based on hardclock() as time source. Interactivity calculation uses alike logic and uses the same time source. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 16:40:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 206152E1 for ; Thu, 3 Jan 2013 16:40:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id D94882B9 for ; Thu, 3 Jan 2013 16:40:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r03GeU59035076; Thu, 3 Jan 2013 09:40:30 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r03GeU15035073; Thu, 3 Jan 2013 09:40:30 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 3 Jan 2013 09:40:29 -0700 (MST) From: Warren Block To: Robert Huff Subject: Re: problem after installkernel going from 9.0 to CURRENT In-Reply-To: <50E476D3.2030609@rcn.com> Message-ID: References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 03 Jan 2013 09:40:30 -0700 (MST) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:40:37 -0000 On Wed, 2 Jan 2013, Robert Huff wrote: > (While this may not be a strictly CURRENT issue, I asked on > questions@, but have not found a solution.) > > Situation: > One of my boxes failed, and for various reasons it became easier to > just scrub and rebuild it. Like its predecessor it will run CURRENT > 1) Using BSDinstall, I flushed then created the first disk: > > ada2p1 freebsd-boot 128k > ada2p2 freebsd-swap 4g > ada2p3 freebsd-ufs 25g > > (There are non-bootable disks at ada0, -1, and -3.) > > 2) Installed off the 9.0 CD, got it up and running, everything was > good. > 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. > 4a) Built world - OK. > 4b) Build kernel - OK. > 4c) Ran mergemaster - OK. > 4d) Installed kernel - OK. > 5) On rebooting, the loader(??) claims to not be able to find a > bootable partition - i.e. I get a screen that ends in "mountroot > ". > Providing the presumptive value by hand returns "error 19". > 6) Boot using installation CD and use "gpart show" to double check > device names and partitions; everything looks good. > 7) Try normal booting again, no go. > > This is my first time installing to a completely GPT partitioned > system, and I have (obviously) failed to grok something. I checked > src/UPDATING and found nothing which covered this. > What have I bungled, and how do I fix it? It really does not sound like a GPT problem, because 9.0 booted. The -current kernel can't find/detect the device. Scrolling back in the console buffer might find a problem. buildworld/kernel/installworld do not affect the disk partitioning, but can change the code that looks for those partitions. From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 16:55:07 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A6F27E4; Thu, 3 Jan 2013 16:55:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 21F17364; Thu, 3 Jan 2013 16:55:06 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r03GstDD010598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 03:54:56 +1100 Date: Fri, 4 Jan 2013 03:54:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin Subject: Re: [RFC/RFT] calloutng In-Reply-To: <50E5ADE1.4020104@FreeBSD.org> Message-ID: <20130104034917.O1929@besplex.bde.org> References: <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <20130102162206.GA45701@onelab2.iet.unipi.it> <20130102170934.GA82219@kib.kiev.ua> <50E4A902.4050307@FreeBSD.org> <20130103232413.O947@besplex.bde.org> <50E5ADE1.4020104@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zr21sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=5cdyoQTr-aBsL13Ni88A:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 X-Mailman-Approved-At: Thu, 03 Jan 2013 17:10:07 +0000 Cc: Davide Italiano , Ian Lepore , Marius Strobl , FreeBSD Current , Bruce Evans , freebsd-arch@FreeBSD.org, Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:55:07 -0000 On Thu, 3 Jan 2013, Alexander Motin wrote: > On 03.01.2013 16:45, Bruce Evans wrote: >> On Wed, 2 Jan 2013, Alexander Motin wrote: >>> More important for scheduling fairness thread's CPU percentage is also >>> based on hardclock() and hiding from it was trivial before, since all >>> sleep primitives were strictly aligned to hardclock(). Now it is >>> slightly less trivial, since this alignment was removed and user-level >>> APIs provide no easy way to enforce it. >> >> %cpu is actually based on statclock(), and not even used for scheduling. > > May be for SCHED_4BSD, but not for SCHED_ULE. In SCHED_ULE both %cpu and > thread priority based on the same ts_ticks counter, that is based on > hardclock() as time source. Interactivity calculation uses alike logic and > uses the same time source. Hmm. I missed this because it hacks on the 'ticks' global. It is clearer in intermediate versions which use the scheduler API sched_tick(), which is the hardclock analogue of sched_clock() for statclock. sched_tick() is now bogus since it is null for all schedulers. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 23:24:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 309CBE63 for ; Thu, 3 Jan 2013 23:24:46 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id DEFEFD7E for ; Thu, 3 Jan 2013 23:24:45 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 03 Jan 2013 18:24:39 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id CEA51393; Thu, 3 Jan 2013 18:24:38 -0500 Received-SPF: None identity=pra; client-ip=209.6.85.139; receiver=smtp01.lnh.mail.rcn.net; envelope-from="roberthuff@rcn.com"; x-sender="roberthuff@rcn.com"; x-conformance=sidf_compatible Received-SPF: Neutral identity=mailfrom; client-ip=209.6.85.139; receiver=smtp01.lnh.mail.rcn.net; envelope-from="roberthuff@rcn.com"; x-sender="roberthuff@rcn.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None identity=helo; client-ip=209.6.85.139; receiver=smtp01.lnh.mail.rcn.net; envelope-from="roberthuff@rcn.com"; x-sender="postmaster@[192.168.1.101]"; x-conformance=sidf_compatible X-Auth-ID: roberthuff Received: from 209-6-85-139.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO [192.168.1.101]) ([209.6.85.139]) by smtp01.lnh.mail.rcn.net with ESMTP; 03 Jan 2013 18:24:38 -0500 Message-ID: <50E612DA.8020704@rcn.com> Date: Thu, 03 Jan 2013 18:23:06 -0500 From: Robert Huff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Warren Block Subject: Re: problem after installkernel going from 9.0 to CURRENT References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr16.lnh.mail.rcn.net) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:24:46 -0000 On 1/3/2013 11:40 AM, Warren Block wrote: > On Wed, 2 Jan 2013, Robert Huff wrote: > >> (While this may not be a strictly CURRENT issue, I asked on >> questions@, but have not found a solution.) >> >> Situation: >> One of my boxes failed, and for various reasons it became easier >> to just scrub and rebuild it. Like its predecessor it will run CURRENT >> 1) Using BSDinstall, I flushed then created the first disk: >> >> ada2p1 freebsd-boot 128k >> ada2p2 freebsd-swap 4g >> ada2p3 freebsd-ufs 25g >> >> 5) On rebooting, the loader(??) claims to not be able to find a >> bootable partition - i.e. I get a screen that ends in "mountroot > ". >> Providing the presumptive value by hand returns "error 19". > > It really does not sound like a GPT problem, because 9.0 booted. I don't (at the moment) think it's GPT caused; but I do think it may be GPT related. > The > -current kernel can't find/detect the device. Scrolling back in the > console buffer might find a problem. buildworld/kernel/installworld do > not affect the disk partitioning, but can change the code that looks for > those partitions. Exactly. I'm looking for help figuring out how the hand-off from loader to kernel got broken and what I have to do to fix it. One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 01:32:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D8C95D1 for ; Fri, 4 Jan 2013 01:32:37 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by mx1.freebsd.org (Postfix) with ESMTP id D90181E7 for ; Fri, 4 Jan 2013 01:32:36 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id i13so6371840eaa.4 for ; Thu, 03 Jan 2013 17:32:30 -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=/jj7BHAtN+yUMdtFv+YZzAxn3jX3ixFlhZVR/bJHswY=; b=zdA3Dm4B3l+J2uQjW6CO1xUBRXiJl7lyAu9h0QY+K+bUzDE3CDVZqDLBbsAlpTSmgz mrg0oqgQz5ercSwd/CoNO+yB4j+HAmJ9Zg4mmIbeKXEgwKftGpYiW9LcjgqjQbSEKZjK 2f8rhFAWJ45H3xUIHWTIukAUpgpmv5kb1FKqbi/Uo4F/e7MoykjUxWG5dFDk24XTy3oM OC4TJsk8C4+kAqtjjWjbH94VGnP10lX9VxanSRwWm/smr8FlVPURxcZqLq82v16Iaaml 49ZLwo+P1f6/xOsPiVSOVdh4PEIl07+W8wFzh3OI/BPB8cyixKNQz2Clm6YMAeM4vjZM aMZg== MIME-Version: 1.0 Received: by 10.14.204.198 with SMTP id h46mr139375543eeo.1.1357263150094; Thu, 03 Jan 2013 17:32:30 -0800 (PST) Received: by 10.223.170.193 with HTTP; Thu, 3 Jan 2013 17:32:29 -0800 (PST) In-Reply-To: <50E49298.5030000@rcn.com> References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> <50E49298.5030000@rcn.com> Date: Thu, 3 Jan 2013 17:32:29 -0800 Message-ID: Subject: Re: problem after installkernel going from 9.0 to CURRENT From: Kevin Oberman To: Robert Huff Content-Type: text/plain; charset=UTF-8 Cc: Benjamin Kaduk , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 01:32:37 -0000 On Wed, Jan 2, 2013 at 12:03 PM, Robert Huff wrote: > On 1/2/2013 1:57 PM, Benjamin Kaduk wrote: >> >> On Wed, 2 Jan 2013, Robert Huff wrote: > > >> For a full clean install, I believe that bsdinstall should prompt about >> installing bootcode around here. I don't really understand from your >> procedure how bsdinstall was used; there might be some edge case where >> there is no prompt about bootcode. >> >>> 2) Installed off the 9.0 CD, got it up and running, everything was >>> good. > > > Let me elaborate on this: > > 2) Installed off the 9.0 CD, had a fully bootable system connected > to the Internet, everything was good. > > >> I think you should investigate the 'bootcode' subcommand of gpart(8). > > > Does the above change things? > It was my expectation "installkernel" would Do The Right Thing with > respect to new bootcode, and I am surprised it did not. installkernel does absolutely nothing to the boot partition. You need to use bsdinstall or gpart to write the new image to disk. That said, I know of no reason that the boot code written by the 9.0 install would fail to boot head. I am running 9.1 on a GPT disk and it works fine, but I that disk is ada1 and I have booteasy installed on the MBR of ada0. It has no problems booting the 9.1 system. (Windows 7 in on ada0.) Then again, I am hardly an expert on the subject. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 01:35:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 446F57EA for ; Fri, 4 Jan 2013 01:35:52 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id D9033220 for ; Fri, 4 Jan 2013 01:35:51 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id d13so6646938eaa.35 for ; Thu, 03 Jan 2013 17:35:50 -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=JVQQhd94TiVSWSbiundLbJgFbFd8kb0Hsl+sxXiDuZQ=; b=SF8Yhl8Z1GahxbGknxhWQ6hs8bq8kPCGisne1fW90EkZZWL4hROgS/kaB2x7vFf6zq M95nPtMOEPfzX36NTUFwSoVOoNYDbpdbu16TIPe142HDVWchD8lJqNELSWFbRFKTamcB 0DogkegZkasvwPE+dijsdPheeJmg6jaCufw7RAJTllyKNvMdtfPOv6xCpISykRyNsM/Y QP+fBcIuwdw0MYD+UGegLiQx0C9vffwrEw631RaJcqA4tGEjei4b5qbXkCg9vCL3xIUK Rwq0QlzYjkV79s6KuZZY4uqAgpNG5VbnR6QsLqoVOMluzwvfX6st85mAEgberUIkvZl8 tnYw== MIME-Version: 1.0 Received: by 10.14.176.66 with SMTP id a42mr138712638eem.34.1357263350589; Thu, 03 Jan 2013 17:35:50 -0800 (PST) Received: by 10.223.170.193 with HTTP; Thu, 3 Jan 2013 17:35:50 -0800 (PST) In-Reply-To: <50E612DA.8020704@rcn.com> References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> <50E612DA.8020704@rcn.com> Date: Thu, 3 Jan 2013 17:35:50 -0800 Message-ID: Subject: Re: problem after installkernel going from 9.0 to CURRENT From: Kevin Oberman To: Robert Huff Content-Type: text/plain; charset=UTF-8 Cc: Warren Block , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 01:35:52 -0000 On Thu, Jan 3, 2013 at 3:23 PM, Robert Huff wrote: > On 1/3/2013 11:40 AM, Warren Block wrote: >> >> On Wed, 2 Jan 2013, Robert Huff wrote: >> >>> (While this may not be a strictly CURRENT issue, I asked on >>> questions@, but have not found a solution.) >>> >>> Situation: >>> One of my boxes failed, and for various reasons it became easier >>> to just scrub and rebuild it. Like its predecessor it will run CURRENT >>> 1) Using BSDinstall, I flushed then created the first disk: >>> >>> ada2p1 freebsd-boot 128k >>> ada2p2 freebsd-swap 4g >>> ada2p3 freebsd-ufs 25g >>> >>> 5) On rebooting, the loader(??) claims to not be able to find a >>> bootable partition - i.e. I get a screen that ends in "mountroot > ". >>> Providing the presumptive value by hand returns "error 19". >> >> >> It really does not sound like a GPT problem, because 9.0 booted. > > > I don't (at the moment) think it's GPT caused; but I do think it may > be GPT related. > > > >> The >> -current kernel can't find/detect the device. Scrolling back in the >> console buffer might find a problem. buildworld/kernel/installworld do >> not affect the disk partitioning, but can change the code that looks for >> those partitions. > > > Exactly. I'm looking for help figuring out how the hand-off from > loader to kernel got broken and what I have to do to fix it. > One possibility: I believe I labeled each of the partitions during > the gpt creation process. Can I use those labels to (hopefully) by-pass > this issue? Yes! This is the current recommended way of doing it. > cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/gpt/swap none swap sw 0 0 /dev/gpt/root / ufs rw 1 1 /dev/gpt/tmp /tmp ufs rw 2 2 /dev/gpt/usr /usr ufs rw 2 2 /dev/gpt/var /var ufs rw 2 2 -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 03:24:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 22679DE7 for ; Fri, 4 Jan 2013 03:24:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id CB7A472F for ; Fri, 4 Jan 2013 03:24:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r043OGQ9099807; Thu, 3 Jan 2013 20:24:16 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r043OGss099804; Thu, 3 Jan 2013 20:24:16 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 3 Jan 2013 20:24:15 -0700 (MST) From: Warren Block To: Kevin Oberman Subject: Re: problem after installkernel going from 9.0 to CURRENT In-Reply-To: Message-ID: References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> <50E612DA.8020704@rcn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 03 Jan 2013 20:24:16 -0700 (MST) Cc: Robert Huff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 03:24:18 -0000 On Thu, 3 Jan 2013, Kevin Oberman wrote: >> One possibility: I believe I labeled each of the partitions during >> the gpt creation process. Can I use those labels to (hopefully) by-pass >> this issue? > > Yes! This is the current recommended way of doing it. >> cat /etc/fstab > # Device Mountpoint FStype Options Dump Pass# > /dev/gpt/swap none swap sw 0 0 > /dev/gpt/root / ufs rw 1 1 > /dev/gpt/tmp /tmp ufs rw 2 2 > /dev/gpt/usr /usr ufs rw 2 2 > /dev/gpt/var /var ufs rw 2 2 To avoid collisions, I recommend people use unique labels on each system. I sometimes pick a couple of letters from the system name or drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 04:23:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A6DCB7ED; Fri, 4 Jan 2013 04:23:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7915489E; Fri, 4 Jan 2013 04:23:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r044NQb8052336; Thu, 3 Jan 2013 23:23:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r044NQwQ052317; Fri, 4 Jan 2013 04:23:26 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 4 Jan 2013 04:23:26 GMT Message-Id: <201301040423.r044NQwQ052317@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 04:23:33 -0000 TB --- 2013-01-04 02:04:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-04 02:04:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-04 02:04:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-04 02:04:44 - cleaning the object tree TB --- 2013-01-04 02:04:44 - /usr/local/bin/svn stat /src TB --- 2013-01-04 02:04:48 - At svn revision 245019 TB --- 2013-01-04 02:04:49 - building world TB --- 2013-01-04 02:04:49 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 02:04:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 02:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 02:04:49 - SRCCONF=/dev/null TB --- 2013-01-04 02:04:49 - TARGET=ia64 TB --- 2013-01-04 02:04:49 - TARGET_ARCH=ia64 TB --- 2013-01-04 02:04:49 - TZ=UTC TB --- 2013-01-04 02:04:49 - __MAKE_CONF=/dev/null TB --- 2013-01-04 02:04:49 - cd /src TB --- 2013-01-04 02:04:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 4 02:04:54 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 Fri Jan 4 03:40:35 UTC 2013 TB --- 2013-01-04 03:40:35 - generating LINT kernel config TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf TB --- 2013-01-04 03:40:35 - /usr/bin/make -B LINT TB --- 2013-01-04 03:40:35 - cd /src/sys/ia64/conf TB --- 2013-01-04 03:40:35 - /usr/sbin/config -m LINT TB --- 2013-01-04 03:40:35 - building LINT kernel TB --- 2013-01-04 03:40:35 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 03:40:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 03:40:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 03:40:35 - SRCCONF=/dev/null TB --- 2013-01-04 03:40:35 - TARGET=ia64 TB --- 2013-01-04 03:40:35 - TARGET_ARCH=ia64 TB --- 2013-01-04 03:40:35 - TZ=UTC TB --- 2013-01-04 03:40:35 - __MAKE_CONF=/dev/null TB --- 2013-01-04 03:40:35 - cd /src TB --- 2013-01-04 03:40:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 4 03:40: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 LINT completed on Fri Jan 4 04:15:09 UTC 2013 TB --- 2013-01-04 04:15:09 - cd /src/sys/ia64/conf TB --- 2013-01-04 04:15:09 - /usr/sbin/config -m GENERIC TB --- 2013-01-04 04:15:09 - building GENERIC kernel TB --- 2013-01-04 04:15:09 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 04:15:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 04:15:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 04:15:09 - SRCCONF=/dev/null TB --- 2013-01-04 04:15:09 - TARGET=ia64 TB --- 2013-01-04 04:15:09 - TARGET_ARCH=ia64 TB --- 2013-01-04 04:15:09 - TZ=UTC TB --- 2013-01-04 04:15:09 - __MAKE_CONF=/dev/null TB --- 2013-01-04 04:15:09 - cd /src TB --- 2013-01-04 04:15:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 4 04:15: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 [...] /src/sys/dev/firewire/if_fwip.c:499: undefined reference to `crom_add_simple_text' /src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry' /src/sys/dev/firewire/if_fwip.c:501: undefined reference to `crom_add_simple_text' if_fwip.o: In function `fwip_stream_input': /src/sys/dev/firewire/if_fwip.c:840: undefined reference to `fw_noderesolve_nodeid' if_fwip.o: In function `fwip_unicast_input': /src/sys/dev/firewire/if_fwip.c:939: undefined reference to `fw_noderesolve_nodeid' if_fwip.o:(.data.rel+0x80): undefined reference to `sysctl__hw_firewire_children' *** [kernel.debug] Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-04 04:23:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-04 04:23:26 - ERROR: failed to build GENERIC kernel TB --- 2013-01-04 04:23:26 - 6534.29 user 1389.55 system 8321.70 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 06:09:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DE687E8D for ; Fri, 4 Jan 2013 06:09:28 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8A691DE6 for ; Fri, 4 Jan 2013 06:09:28 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 04 Jan 2013 01:09:28 -0500 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BWE27055; Fri, 4 Jan 2013 01:09:27 -0500 X-Auth-ID: roberthuff@rcn.com Received: from 209-6-85-139.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org) ([209.6.85.139]) by smtp04.lnh.mail.rcn.net with ESMTP; 04 Jan 2013 01:09:27 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20710.29199.528433.376185@jerusalem.litteratus.org> Date: Fri, 4 Jan 2013 01:09:19 -0500 To: Robert Huff Subject: SOLVED: problem after installkernel going from 9.0 to CURRENT In-Reply-To: <50E49298.5030000@rcn.com> References: <50E49298.5030000@rcn.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) Cc: Benjamin Kaduk , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:09:28 -0000 Using the GPT labels is a winning solution. Thanks to all those who helped, Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 06:15:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B13076 for ; Fri, 4 Jan 2013 06:15:41 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by mx1.freebsd.org (Postfix) with ESMTP id C95DEE2E for ; Fri, 4 Jan 2013 06:15:40 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id a12so6448379eaa.14 for ; Thu, 03 Jan 2013 22:15:34 -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=cECCWVSshykraGyhUp8n2lzQFrs3WzLzAYvEIZMLeGA=; b=TDE9yM/TcR5IMNqSJGKNl5Y4MixLg8CiatFNhz4068jjD7jpLgn5HTwE/0LOst5+yF /tAQPh2o016eQ26390yY5QTh//CxGrE6pmWzdPu74HcX40NkNRKAgNOdUZubApyJs3BC ihTj+kNu9zBII0pGUhn+QKlXH5HDqSjOhGezqidxrqjXYVThrJH/NLfRq46+RnrxiL7i S9W/smlMymCQU6pDvus2IfvLaiD+1qUnrbbN5YQ3q9NrOA0cWvWHsiXA3jRLPrVo5aaN QD5hoYUs5LsBTTtjS2odKnlmfyEcvt+N9e6lHPggsvUEV9z79y2avgS5ONB/3mlMvUR+ 6juw== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr140555538eef.25.1357280134315; Thu, 03 Jan 2013 22:15:34 -0800 (PST) Received: by 10.223.170.193 with HTTP; Thu, 3 Jan 2013 22:15:34 -0800 (PST) In-Reply-To: References: <50E0BFA0.6070702@rcn.com> <50E476D3.2030609@rcn.com> <50E612DA.8020704@rcn.com> Date: Thu, 3 Jan 2013 22:15:34 -0800 Message-ID: Subject: Re: problem after installkernel going from 9.0 to CURRENT From: Kevin Oberman To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: Robert Huff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:15:41 -0000 On Thu, Jan 3, 2013 at 7:24 PM, Warren Block wrote: > On Thu, 3 Jan 2013, Kevin Oberman wrote: > >>> One possibility: I believe I labeled each of the partitions >>> during >>> the gpt creation process. Can I use those labels to (hopefully) by-pass >>> this issue? >> >> >> Yes! This is the current recommended way of doing it. >>> >>> cat /etc/fstab >> >> # Device Mountpoint FStype Options Dump >> Pass# >> /dev/gpt/swap none swap sw 0 0 >> /dev/gpt/root / ufs rw 1 1 >> /dev/gpt/tmp /tmp ufs rw 2 2 >> /dev/gpt/usr /usr ufs rw 2 2 >> /dev/gpt/var /var ufs rw 2 2 > > > To avoid collisions, I recommend people use unique labels on each system. I > sometimes pick a couple of letters from the system name or drive: xfswap, > xfrootfs, xftmpfs, xfusrfs, xfvarfs. Good point (as usual). The example was from my laptop where this is not an issue, but in larger environments it is an excellent suggestion. I would put the unique ID at the end of the label as the eye tends to read from left to right (at least in most language so you can recognize whether it is usr or swap or home pretty much instantly. Sticking letters at the start make the most fundamental information harder to see. swaprxf xfswap usrfsxf xfusrfs Still, this is a nit and I appreciate the suggestion!.. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 08:45:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EC4B730; Fri, 4 Jan 2013 08:45:45 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A18D683; Fri, 4 Jan 2013 08:45:43 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id ji2so7115767bkc.1 for ; Fri, 04 Jan 2013 00:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=YO5g3wctMsrH968HOtsPyMQCl9kq0tCqDh5W2IbyIdM=; b=N/++GIpAFcREHpO92DoaHAFZwoGBpSm/BzQQqtvMoApOUqZ/UIWtnf3iPpKQHEEfqS duacKVmwn1mDjK266sTKiHYRDj52rtwX7GeUiyyc/ZAeU64qItA2VimWAFXTyyNnDo8s eFHM8t5G49iWgeIQIoXvlWxW40fAocuHucwoIXdex1cVRCmFphXiB5AGvmoCbLGzMfF7 3UFX6D38P8maL6/iMhXpVkeG5qOgrKJO66ykHnRJGK3PlUo8iPZtIRB1KlVQh8J2o0Zn p0SLR12aJfDxIrv/MU4xNue0dIuAf8QoWMky+KV8p2Pi0zeiMP9laQMzT3DjECSXVZq4 813w== X-Received: by 10.204.133.219 with SMTP id g27mr25185868bkt.65.1357289136905; Fri, 04 Jan 2013 00:45:36 -0800 (PST) Received: from ernst.jennejohn.org (p4FC0FE67.dip.t-dialin.net. [79.192.254.103]) by mx.google.com with ESMTPS id o9sm35788931bko.15.2013.01.04.00.45.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 00:45:35 -0800 (PST) Date: Fri, 4 Jan 2013 09:45:32 +0100 From: Gary Jennejohn To: KAHO Toshikazu Subject: Re: loopback interface broken on current Message-ID: <20130104094532.4a921e47@ernst.jennejohn.org> In-Reply-To: <90299.1357212618@pf2.ed.niigata-u.ac.jp> References: <201212271705.qBRH5VHU006208@pozo.com> <20130101102255.GA25661@FreeBSD.org> <201301011040.r01Ae37A043153@pozo.com> <20130101194803.GB25661@glebius.int.ru> <201301012042.r01Kgq6E001548@pozo.com> <20130102201330.GC25661@glebius.int.ru> <201301022325.r02NPKEE076633@pozo.com> <89160.1357182550@pf2.ed.niigata-u.ac.jp> <201301030355.r033t4aI001542@pozo.com> <90299.1357212618@pf2.ed.niigata-u.ac.jp> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 08:45:45 -0000 On Thu, 03 Jan 2013 20:30:18 +0900 KAHO Toshikazu wrote: > Hello, > > > There is still ====>ifa_del_loopback_route: deletion failed: 3 > > that wasn't there before,but the 127.0.0.1 seems to be configured now: > > Do you have a line like network_interfaces="lo0 bge0" in /etc/rc.conf? > If you have it, try to remove it. > > I think something broken, but people using automatic configuration > don't notice the breakage. > Something is definitely broken because I don't have network_interfaces in /etc/rc.conf but my lo0 does not have even ipv6 addresses assigned. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 10:14:08 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D429B2EE for ; Fri, 4 Jan 2013 10:14:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 87EE19F4 for ; Fri, 4 Jan 2013 10:14:08 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1Tr4Hv-003eOs-7t>; Fri, 04 Jan 2013 11:14:07 +0100 Received: from e178016018.adsl.alicedsl.de ([85.178.16.18] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1Tr4Hv-0047OD-4f>; Fri, 04 Jan 2013 11:14:07 +0100 Message-ID: <50E6AB65.5030309@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 11:13:57 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Current FreeBSD Subject: r245005M: NFSv4 usermapping not working anymore X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8D08BD1B0996FB3333F6915" X-Originating-IP: 85.178.16.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:14:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8D08BD1B0996FB3333F6915 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT boxes, i realize a strange behaviour. I have one server exporting via NFSv4 several ZFS volumes. The UID mapping went pretty well so far, but with a reboot of yesterday (after a buildworld), files are seen with uid root:wheel and users are no longer seen. The server and client in question are server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013 client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013 I think this is not supposed to be that way. Another box, our lab's server, doesn't show this phenomenon (but at the moment I have only the opportunity to check with a FreeBSD 9.1-STABLE client). This specific server is server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013 By the way, can someone give me a hint why some boxes show up with an attached "M" to the SVN revision number (like r245005M)? Thanks, oh --------------enigD8D08BD1B0996FB3333F6915 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5qtuAAoJEOgBcD7A/5N8Kq4IANGgiXuD6krw6UGO1VAqDURF 2BbEwmJw9CRuPUur3aro48cpxuO0vyyhimxZWRAQPxvDSBr6coOJONdZSplW+YmA vQxXX9xJOLgsbV2h5mtop0OaQAevtIAq60TCjuZVSuq3Abm+hJOQC/1ZiJHMdEM9 H+1K4XhlArbxFzdVMoLzT8rAA49gne06oJTMKc088XRmrN4oCWJn0U5M347rv0U1 fycqTjHD7djZbRotJMY8AmJ5kN8Wxk2aUgejG8hu1J+XtR2jB2wUQizFnvTKgJQg oobxZVXh48mw1zbwdqL4+Nl7MGE4P8Jd70CeOyEHeR/S4I0oFEhwaW4mA35zy7c= =FGT1 -----END PGP SIGNATURE----- --------------enigD8D08BD1B0996FB3333F6915-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 10:17:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 051BD4A4; Fri, 4 Jan 2013 10:17:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CF74FA1D; Fri, 4 Jan 2013 10:17:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r04AHh46059920; Fri, 4 Jan 2013 05:17:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r04AHhKk059919; Fri, 4 Jan 2013 10:17:43 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 4 Jan 2013 10:17:43 GMT Message-Id: <201301041017.r04AHhKk059919@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:17:45 -0000 TB --- 2013-01-04 09:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-04 09:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-04 09:40:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-01-04 09:40:20 - cleaning the object tree TB --- 2013-01-04 09:40:20 - /usr/local/bin/svn stat /src TB --- 2013-01-04 09:40:24 - At svn revision 245034 TB --- 2013-01-04 09:40:25 - building world TB --- 2013-01-04 09:40:25 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 09:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 09:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 09:40:25 - SRCCONF=/dev/null TB --- 2013-01-04 09:40:25 - TARGET=amd64 TB --- 2013-01-04 09:40:25 - TARGET_ARCH=amd64 TB --- 2013-01-04 09:40:25 - TZ=UTC TB --- 2013-01-04 09:40:25 - __MAKE_CONF=/dev/null TB --- 2013-01-04 09:40:25 - cd /src TB --- 2013-01-04 09:40:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 4 09:40:29 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/libclangserialization/../../../contrib/llvm/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization -I. -I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"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/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp -o ASTReaderDecl.o c++ -O2 -pipe -I/src/lib/clang/libclangserialization/../../../contrib/llvm/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization -I. -I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"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/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTReaderStmt.cpp -o ASTReaderStmt.o c++ -O2 -pipe -I/src/lib/clang/libclangserialization/../../../contrib/llvm/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization -I. -I/src/lib/clang/libclangserialization/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"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/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp -o ASTWriter.o /src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp: In member function 'void clang::ASTWriter::WriteSourceManagerBlock(clang::SourceManager&, const clang::Preprocessor&, llvm::StringRef)': /src/lib/clang/libclangserialization/../../../contrib/llvm/tools/clang/lib/Serialization/ASTWriter.cpp:1558: 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. *** [ASTWriter.o] Error code 1 Stop in /src/lib/clang/libclangserialization. *** [all] Error code 1 Stop in /src/lib/clang. *** [cross-tools] Error code 1 Stop in /src. *** [_cross-tools] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-04 10:17:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-04 10:17:43 - ERROR: failed to build world TB --- 2013-01-04 10:17:43 - 1957.48 user 189.41 system 2243.16 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:09:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D311114 for ; Fri, 4 Jan 2013 11:09:16 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 07C8FC28 for ; Fri, 4 Jan 2013 11:09:15 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Tr59A-0006xQ-KZ for freebsd-current@freebsd.org; Fri, 04 Jan 2013 11:09:08 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Tr59A-0005P4-8S for freebsd-current@freebsd.org; Fri, 04 Jan 2013 11:09:08 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r04B97ZP001898; Fri, 4 Jan 2013 11:09:07 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r04B97QU001888; Fri, 4 Jan 2013 11:09:07 GMT (envelope-from mexas) Date: Fri, 4 Jan 2013 11:09:07 GMT From: Anton Shterenlikht Message-Id: <201301041109.r04B97QU001888@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org, sparc64@bristol.ac.uk Subject: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:09:16 -0000 I got this error on make installworld: ===> sbin/dhclient (install) install -s -o root -g wheel -m 555 dhclient /sbin ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 12794 (install) install: /sbin/dhclient: Bad address *** [_proginstall] Error code 71 Stop in /usr/src/sbin/dhclient. *** [realinstall] Error code 1 Stop in /usr/src/sbin. *** [realinstall] Error code 1 Stop in /usr/src. *** [reinstall] Error code 1 Stop in /usr/src. *** [installworld] Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What's going on? This is on sparc64 SunBlade 1500 silver, updating to r244988. The disk is: # gpart show ad0 => 0 234432720 ad0 VTOC8 (111G) 0 41946480 1 !0 (20G) 41946480 33558000 2 !0 (16G) 75504480 158928240 4 !0 (75G) # # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/ad0a 40620236 21769888 15600732 58% / devfs 2 2 0 100% /dev # I've run fsck -p before installworld, and didn't see any problems. Thanks Anton From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:24:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A6CD85B1; Fri, 4 Jan 2013 11:24:08 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2FDD05; Fri, 4 Jan 2013 11:24:08 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Tr5NW-0004rG-Mw; Fri, 04 Jan 2013 11:24:01 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Tr5NW-00023T-Iz; Fri, 04 Jan 2013 11:23:58 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r04BNwVO014118; Fri, 4 Jan 2013 11:23:58 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r04BNwTU014117; Fri, 4 Jan 2013 11:23:58 GMT (envelope-from mexas) Date: Fri, 4 Jan 2013 11:23:58 GMT From: Anton Shterenlikht Message-Id: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 In-Reply-To: <201301041109.r04B97QU001888@mech-cluster241.men.bris.ac.uk> X-Spam-Score: -4.0 X-Spam-Level: ---- X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:24:08 -0000 Date: Fri, 4 Jan 2013 11:09:07 GMT From: Anton Shterenlikht I got this error on make installworld: ===> sbin/dhclient (install) install -s -o root -g wheel -m 555 dhclient /sbin ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 12794 (install) install: /sbin/dhclient: Bad address *** [_proginstall] Error code 71 Stop in /usr/src/sbin/dhclient. *** [realinstall] Error code 1 Stop in /usr/src/sbin. *** [realinstall] Error code 1 Stop in /usr/src. *** [reinstall] Error code 1 Stop in /usr/src. *** [installworld] Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What's going on? This is on sparc64 SunBlade 1500 silver, updating to r244988. The disk is: # gpart show ad0 => 0 234432720 ad0 VTOC8 (111G) 0 41946480 1 !0 (20G) 41946480 33558000 2 !0 (16G) 75504480 158928240 4 !0 (75G) # # df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/ad0a 40620236 21769888 15600732 58% / devfs 2 2 0 100% /dev # I've run fsck -p before installworld, and didn't see any problems. Is my disk dying? # fsck ** /dev/ad0a (NO WRITE) ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ad0: FAILURE - READ_DMA status=51 error=40 LBA=23328672 CANNOT READ BLK: 23328608 CONTINUE? [yn] Thanks Anton From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:42:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C63B9BD for ; Fri, 4 Jan 2013 11:42:35 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 90F10DB5 for ; Fri, 4 Jan 2013 11:42:34 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-current@freebsd.org; Fri, 4 Jan 2013 12:42:32 +0100 Message-ID: <50E6C004.8020109@ose.nl> Date: Fri, 04 Jan 2013 12:41:56 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 References: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:42:35 -0000 On 01/04/2013 12:23 PM, Anton Shterenlikht wrote: > Date: Fri, 4 Jan 2013 11:09:07 GMT > From: Anton Shterenlikht > > I got this error on make installworld: > > ===> sbin/dhclient (install) > install -s -o root -g wheel -m 555 dhclient /sbin > ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 > g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5 > vnode_pager_getpages: I/O read error > vm_fault: pager read error, pid 12794 (install) > install: /sbin/dhclient: Bad address > *** [_proginstall] Error code 71 > > Stop in /usr/src/sbin/dhclient. > *** [realinstall] Error code 1 > > Stop in /usr/src/sbin. > *** [realinstall] Error code 1 > > Stop in /usr/src. > *** [reinstall] Error code 1 > > Stop in /usr/src. > *** [installworld] Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > What's going on? > > This is on sparc64 SunBlade 1500 silver, > updating to r244988. > > The disk is: > > # gpart show ad0 > => 0 234432720 ad0 VTOC8 (111G) > 0 41946480 1 !0 (20G) > 41946480 33558000 2 !0 (16G) > 75504480 158928240 4 !0 (75G) > > # > > # df > Filesystem 512-blocks Used Avail Capacity Mounted on > /dev/ad0a 40620236 21769888 15600732 58% / > devfs 2 2 0 100% /dev > # > > I've run fsck -p before installworld, > and didn't see any problems. > > Is my disk dying? I don't know if smartmontools work for sparc64 though > > # fsck > ** /dev/ad0a (NO WRITE) > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ad0: FAILURE - READ_DMA status=51 error=40 LBA=23328672 > > CANNOT READ BLK: 23328608 > CONTINUE? [yn] > > Thanks > > Anton > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- *Bas Smeelen* /System administrator/ b.smeelen@ose.nl Dr. Nolenslaan 157 6136GM Sittard The Netherlands Tel: +31 (0) 46 4200 933 Fax: +31 (0) 46 4200 934 www.ose.nl This e-mail message, including any attachment(s), is confidential and intended solely for the addressee. Any unauthorized review, use, disclosure, or distribution is prohibited. If you believe this message has been sent to you by mistake, please notify the sender by replying to this transmission, and delete the message and its attachments without disclosing them. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OverNite Software Europe bv. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 11:51:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B6873B6C for ; Fri, 4 Jan 2013 11:51:11 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id E5F51DFA for ; Fri, 4 Jan 2013 11:51:10 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-current@freebsd.org; Fri, 4 Jan 2013 12:41:00 +0100 Message-ID: <50E6BFA8.4000609@ose.nl> Date: Fri, 04 Jan 2013 12:40:24 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 References: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:51:11 -0000 On 01/04/2013 12:23 PM, Anton Shterenlikht wrote: > Date: Fri, 4 Jan 2013 11:09:07 GMT > From: Anton Shterenlikht > > I got this error on make installworld: > > ===> sbin/dhclient (install) > install -s -o root -g wheel -m 555 dhclient /sbin > ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 > g_vfs_done():ad0a[READ(offset=14372651008, length=16384)]error = 5 > vnode_pager_getpages: I/O read error > vm_fault: pager read error, pid 12794 (install) > install: /sbin/dhclient: Bad address > *** [_proginstall] Error code 71 > > Stop in /usr/src/sbin/dhclient. > *** [realinstall] Error code 1 > > Stop in /usr/src/sbin. > *** [realinstall] Error code 1 > > Stop in /usr/src. > *** [reinstall] Error code 1 > > Stop in /usr/src. > *** [installworld] Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > What's going on? > > This is on sparc64 SunBlade 1500 silver, > updating to r244988. > > The disk is: > > # gpart show ad0 > => 0 234432720 ad0 VTOC8 (111G) > 0 41946480 1 !0 (20G) > 41946480 33558000 2 !0 (16G) > 75504480 158928240 4 !0 (75G) > > # > > # df > Filesystem 512-blocks Used Avail Capacity Mounted on > /dev/ad0a 40620236 21769888 15600732 58% / > devfs 2 2 0 100% /dev > # > > I've run fsck -p before installworld, > and didn't see any problems. > > Is my disk dying? Diagnose with sysutils/smartmontools > > # fsck > ** /dev/ad0a (NO WRITE) > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ad0: FAILURE - READ_DMA status=51 error=40 LBA=23328672 > > CANNOT READ BLK: 23328608 > CONTINUE? [yn] > > Thanks > > Anton > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- *Bas Smeelen* /System administrator/ b.smeelen@ose.nl Dr. Nolenslaan 157 6136GM Sittard The Netherlands Tel: +31 (0) 46 4200 933 Fax: +31 (0) 46 4200 934 www.ose.nl This e-mail message, including any attachment(s), is confidential and intended solely for the addressee. Any unauthorized review, use, disclosure, or distribution is prohibited. If you believe this message has been sent to you by mistake, please notify the sender by replying to this transmission, and delete the message and its attachments without disclosing them. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OverNite Software Europe bv. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:25:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 286A14ED for ; Fri, 4 Jan 2013 12:25:11 +0000 (UTC) (envelope-from mueller23@insightbb.com) Received: from mail.insightbb.com (smtp1.insight.synacor.com [208.47.185.23]) by mx1.freebsd.org (Postfix) with ESMTP id E6FF3F58 for ; Fri, 4 Jan 2013 12:25:09 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=AMIyp9Gn c=1 sm=0 a=Dm9TOXL4taQ+Gy1KovpL+A==:17 a=4_Al_TwyEyoA:10 a=jLN7EqiLvroA:10 a=9YQ-1ebCAAAA:8 a=Uire-KlexSQA:10 a=6I5d2MoRAAAA:8 a=w33rRxbrAAAA:8 a=PCQA-OVpHJNCy5wGSF4A:9 a=SV7veod9ZcQA:10 a=V5EgUw7NdT4A:10 a=Dm9TOXL4taQ+Gy1KovpL+A==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com header.from=mueller23@insightbb.com; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com smtp.mail=mueller23@insightbb.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.130.198.7 as permitted sender) Received: from [74.130.198.7] ([74.130.198.7:53283] helo=localhost) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 87/A1-00942-989C6E05; Fri, 04 Jan 2013 07:22:33 -0500 Date: Fri, 04 Jan 2013 07:22:33 -0500 Message-ID: <87.A1.00942.989C6E05@smtp02.insight.synacor.com> From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: CFT: Overhauled CPSW driver for BeagleBone Cc: Brett Wynkoop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:25:11 -0000 > On Tue, 1 Jan 2013 10:55:58 -0800 > Tim Kientzle wrote: > > On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote: > > > Greeting- > > > The driver is working much better than the driver currently in > > > head. I have maintained an ssh connection to the BeagleBone for > > > more than 24 hours! > > Just committed this to -CURRENT r244939. > > Tim > Ok time to cvsup then rebuild the kernel followed by a buildworld! > Thanks Tim! > wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt Watch what you say about cvsup! Have you been following the many messages on the deprecation of cvs, cvsup and csup following the recent security breach on FreeBSD servers? Now you need subversion port (svn) to download and update the source tree. Tom From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:34:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59978736 for ; Fri, 4 Jan 2013 12:34:34 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id 92798FA7 for ; Fri, 4 Jan 2013 12:34:33 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104123426.WERS26940.viefep19-int.chello.at@edge02.upcmail.net> for ; Fri, 4 Jan 2013 13:34:26 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id jobo1k00P2xdvHc01obo6T; Fri, 04 Jan 2013 13:35:48 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id A67F76D454; Fri, 4 Jan 2013 13:34:25 +0100 (CET) Date: Fri, 4 Jan 2013 13:34:25 +0100 From: Stefan Farfeleder To: freebsd-current@freebsd.org Subject: Unbreaking gdb's catch throw Message-ID: <20130104123424.GA1430@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:34:34 -0000 Hi, gdb's command 'catch throw' is broken on FreeBSD head. While it does set a breakpoint on __cxa_throw, the function seems to be never entered when an exception is thrown. Does someone know how to fix this? It used to work a couple of months ago. Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:38:58 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D36586B; Fri, 4 Jan 2013 12:38:58 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6232CFCB; Fri, 4 Jan 2013 12:38:57 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r04CcnYv021380 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 4 Jan 2013 12:38:50 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Unbreaking gdb's catch throw Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20130104123424.GA1430@mole.fafoe.narf.at> Date: Fri, 4 Jan 2013 12:38:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130104123424.GA1430@mole.fafoe.narf.at> To: Stefan Farfeleder X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:38:58 -0000 Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, and = libsupc++ or or libcxxrt are the filtee. This means that the = __cxa_throw symbol appears to be in libstdc++ (for symbol versioning = purposes), but is actually in the ABI library. If you tell gdb to put = the breakpoint on __cxa_throw itself, then it should tell you that there = are multiple definitions and ask which one you want (if it doesn't, it's = a gdb bug). =20 David On 4 Jan 2013, at 12:34, Stefan Farfeleder wrote: > Hi, >=20 > gdb's command 'catch throw' is broken on FreeBSD head. While it does = set > a breakpoint on __cxa_throw, the function seems to be never entered = when > an exception is thrown. Does someone know how to fix this? It used to > work a couple of months ago. >=20 > Stefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:47:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B923E9F8 for ; Fri, 4 Jan 2013 12:47:59 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6409FAC for ; Fri, 4 Jan 2013 12:47:59 +0000 (UTC) Received: from [78.35.174.75] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Tr6fm-0006V9-G8 for freebsd-current@freebsd.org; Fri, 04 Jan 2013 13:46:54 +0100 Date: Fri, 4 Jan 2013 13:46:34 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: Unbreaking gdb's catch throw Message-ID: <20130104134634.045f9ea6@fabiankeil.de> In-Reply-To: <20130104123424.GA1430@mole.fafoe.narf.at> References: <20130104123424.GA1430@mole.fafoe.narf.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/oGXe72jgDY3XG8GiS3U73Cw"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:47:59 -0000 --Sig_/oGXe72jgDY3XG8GiS3U73Cw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Stefan Farfeleder wrote: > gdb's command 'catch throw' is broken on FreeBSD head. While it does set > a breakpoint on __cxa_throw, the function seems to be never entered when > an exception is thrown. Does someone know how to fix this? It used to > work a couple of months ago. My impression is that gdb from base is pretty useless in general when compiling with a modern compiler like clang or a more recent version of gcc. gdb751 from the ports seems to suck a lot less. Obviously I'm not saying that it wouldn't be nice if gdb from base worked better, though. Fabian --Sig_/oGXe72jgDY3XG8GiS3U73Cw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDmzzoACgkQBYqIVf93VJ0yigCghNnfXoevhpKLyG7fDgRZ8Cpd oxYAoLZ/rYZdC7yVx08zFBv3lnMsugCP =5M/c -----END PGP SIGNATURE----- --Sig_/oGXe72jgDY3XG8GiS3U73Cw-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:49:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A773BB0E; Fri, 4 Jan 2013 12:49:36 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id C831AC2; Fri, 4 Jan 2013 12:49:35 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104124928.VVAW2598.viefep15-int.chello.at@edge02.upcmail.net>; Fri, 4 Jan 2013 13:49:28 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id joqq1k0072xdvHc01oqqTT; Fri, 04 Jan 2013 13:50:50 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id A079C6D454; Fri, 4 Jan 2013 13:49:27 +0100 (CET) Date: Fri, 4 Jan 2013 13:49:27 +0100 From: Stefan Farfeleder To: David Chisnall Subject: Re: Unbreaking gdb's catch throw Message-ID: <20130104124927.GB1430@mole.fafoe.narf.at> References: <20130104123424.GA1430@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:49:36 -0000 On Fri, Jan 04, 2013 at 12:38:44PM +0000, David Chisnall wrote: > Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, and libsupc++ or or libcxxrt are the filtee. This means that the __cxa_throw symbol appears to be in libstdc++ (for symbol versioning purposes), but is actually in the ABI library. If you tell gdb to put the breakpoint on __cxa_throw itself, then it should tell you that there are multiple definitions and ask which one you want (if it doesn't, it's a gdb bug). > This is on 10.0-CURRENT r244738 amd64. The commands 'b __cxa_throw' and 'catch throw' seemd to be identical, and gdb does not ask about multiple versions of __cxa_throw. To be honest, I don't care exactly whose bug it is, I want it to work again :D $ cat throw.cc int main(void) { throw 1; } $ c++ -g throw.cc $ gdb a.out GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) b main Breakpoint 1 at 0x4007f9: file throw.cc, line 3. (gdb) r Starting program: /usr/home/stefan/scratch/a.out Breakpoint 1, main () at throw.cc:3 3 throw 1; (gdb) b __cxa_throw Breakpoint 2 at 0x800898d34 (gdb) c Continuing. terminate called after throwing an instance of 'int' Program received signal SIGABRT, Aborted. 0x0000000800e52fca in kill () from /lib/libc.so.7 Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 12:54:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34BB3C90; Fri, 4 Jan 2013 12:54:12 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id E8970F8; Fri, 4 Jan 2013 12:54:10 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r04Cs8wL021430 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 4 Jan 2013 12:54:09 GMT (envelope-from theraven@freebsd.org) Subject: Re: Unbreaking gdb's catch throw Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20130104124927.GB1430@mole.fafoe.narf.at> Date: Fri, 4 Jan 2013 12:54:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8FA4D44F-0D32-4374-810F-5630E995F61F@freebsd.org> References: <20130104123424.GA1430@mole.fafoe.narf.at> <20130104124927.GB1430@mole.fafoe.narf.at> To: Stefan Farfeleder X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:54:12 -0000 On 4 Jan 2013, at 12:49, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 12:38:44PM +0000, David Chisnall wrote: >> Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, = and libsupc++ or or libcxxrt are the filtee. This means that the = __cxa_throw symbol appears to be in libstdc++ (for symbol versioning = purposes), but is actually in the ABI library. If you tell gdb to put = the breakpoint on __cxa_throw itself, then it should tell you that there = are multiple definitions and ask which one you want (if it doesn't, it's = a gdb bug). =20 >>=20 >=20 > This is on 10.0-CURRENT r244738 amd64. The commands 'b __cxa_throw' = and > 'catch throw' seemd to be identical, and gdb does not ask about = multiple > versions of __cxa_throw. >=20 > To be honest, I don't care exactly whose bug it is, I want it to work = again :D As a work-around, you can put the breakpoint on _Unwind_RaiseException = instead. This will work for any language, not just C++ (e.g. it will = notice Objective-C or gcj-compiled Java exceptions). David= From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:02:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DAB6E98; Fri, 4 Jan 2013 13:02:27 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA3A14A; Fri, 4 Jan 2013 13:02:25 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep14-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104130218.EMXE11100.viefep14-int.chello.at@edge02.upcmail.net>; Fri, 4 Jan 2013 14:02:18 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge02.upcmail.net with edge id jp3g1k01T2xdvHc01p3gQ7; Fri, 04 Jan 2013 14:03:40 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 4BDF66D454; Fri, 4 Jan 2013 14:02:18 +0100 (CET) Date: Fri, 4 Jan 2013 14:02:18 +0100 From: Stefan Farfeleder To: David Chisnall Subject: Re: Unbreaking gdb's catch throw Message-ID: <20130104130217.GC1430@mole.fafoe.narf.at> References: <20130104123424.GA1430@mole.fafoe.narf.at> <20130104124927.GB1430@mole.fafoe.narf.at> <8FA4D44F-0D32-4374-810F-5630E995F61F@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8FA4D44F-0D32-4374-810F-5630E995F61F@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:02:27 -0000 On Fri, Jan 04, 2013 at 12:54:03PM +0000, David Chisnall wrote: > > As a work-around, you can put the breakpoint on _Unwind_RaiseException instead. This will work for any language, not just C++ (e.g. it will notice Objective-C or gcj-compiled Java exceptions). > Thank you, that works for me. Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:10:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE13A18B; Fri, 4 Jan 2013 13:10:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 861C01A7; Fri, 4 Jan 2013 13:10:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r04DAlQ5023585; Fri, 4 Jan 2013 08:10:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r04DAlhB023572; Fri, 4 Jan 2013 13:10:47 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 4 Jan 2013 13:10:47 GMT Message-Id: <201301041310.r04DAlhB023572@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:10:49 -0000 TB --- 2013-01-04 10:53:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-04 10:53:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-04 10:53:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-04 10:53:42 - cleaning the object tree TB --- 2013-01-04 10:55:17 - /usr/local/bin/svn stat /src TB --- 2013-01-04 10:55:21 - At svn revision 245034 TB --- 2013-01-04 10:55:22 - building world TB --- 2013-01-04 10:55:22 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 10:55:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 10:55:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 10:55:22 - SRCCONF=/dev/null TB --- 2013-01-04 10:55:22 - TARGET=ia64 TB --- 2013-01-04 10:55:22 - TARGET_ARCH=ia64 TB --- 2013-01-04 10:55:22 - TZ=UTC TB --- 2013-01-04 10:55:22 - __MAKE_CONF=/dev/null TB --- 2013-01-04 10:55:22 - cd /src TB --- 2013-01-04 10:55:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 4 10:55:27 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 Fri Jan 4 12:28:25 UTC 2013 TB --- 2013-01-04 12:28:25 - generating LINT kernel config TB --- 2013-01-04 12:28:25 - cd /src/sys/ia64/conf TB --- 2013-01-04 12:28:25 - /usr/bin/make -B LINT TB --- 2013-01-04 12:28:25 - cd /src/sys/ia64/conf TB --- 2013-01-04 12:28:25 - /usr/sbin/config -m LINT TB --- 2013-01-04 12:28:25 - building LINT kernel TB --- 2013-01-04 12:28:25 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 12:28:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 12:28:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 12:28:25 - SRCCONF=/dev/null TB --- 2013-01-04 12:28:25 - TARGET=ia64 TB --- 2013-01-04 12:28:25 - TARGET_ARCH=ia64 TB --- 2013-01-04 12:28:25 - TZ=UTC TB --- 2013-01-04 12:28:25 - __MAKE_CONF=/dev/null TB --- 2013-01-04 12:28:25 - cd /src TB --- 2013-01-04 12:28:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 4 12:28:25 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 Fri Jan 4 13:02:15 UTC 2013 TB --- 2013-01-04 13:02:15 - cd /src/sys/ia64/conf TB --- 2013-01-04 13:02:15 - /usr/sbin/config -m GENERIC TB --- 2013-01-04 13:02:15 - building GENERIC kernel TB --- 2013-01-04 13:02:15 - CROSS_BUILD_TESTING=YES TB --- 2013-01-04 13:02:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-04 13:02:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-04 13:02:15 - SRCCONF=/dev/null TB --- 2013-01-04 13:02:15 - TARGET=ia64 TB --- 2013-01-04 13:02:15 - TARGET_ARCH=ia64 TB --- 2013-01-04 13:02:15 - TZ=UTC TB --- 2013-01-04 13:02:15 - __MAKE_CONF=/dev/null TB --- 2013-01-04 13:02:15 - cd /src TB --- 2013-01-04 13:02:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 4 13:02:15 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 [...] /src/sys/dev/firewire/if_fwip.c:499: undefined reference to `crom_add_simple_text' /src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry' /src/sys/dev/firewire/if_fwip.c:501: undefined reference to `crom_add_simple_text' if_fwip.o: In function `fwip_stream_input': /src/sys/dev/firewire/if_fwip.c:840: undefined reference to `fw_noderesolve_nodeid' if_fwip.o: In function `fwip_unicast_input': /src/sys/dev/firewire/if_fwip.c:939: undefined reference to `fw_noderesolve_nodeid' if_fwip.o:(.data.rel+0x80): undefined reference to `sysctl__hw_firewire_children' *** [kernel.debug] Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-04 13:10:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-04 13:10:47 - ERROR: failed to build GENERIC kernel TB --- 2013-01-04 13:10:47 - 6476.27 user 1154.48 system 8224.57 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:30:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DFE63F7 for ; Fri, 4 Jan 2013 13:30:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 41BD3241 for ; Fri, 4 Jan 2013 13:30:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAE7Y5lCDaFvO/2dsb2JhbABFhjm3KnOCHgEBBAEjVgUWGAICDRkCWQaIIQalJ49MgSKOYIETA4hhjSqQSYMSggg X-IronPort-AV: E=Sophos;i="4.84,409,1355115600"; d="scan'208";a="7447395" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Jan 2013 08:30:20 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8E349B3F0B; Fri, 4 Jan 2013 08:30:20 -0500 (EST) Date: Fri, 4 Jan 2013 08:30:20 -0500 (EST) From: Rick Macklem To: "O. Hartmann" Message-ID: <416983367.1668162.1357306220561.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50E6AB65.5030309@zedat.fu-berlin.de> Subject: Re: r245005M: NFSv4 usermapping not working anymore MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:30:22 -0000 O. Hartmann wrote: > Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT > boxes, i realize a strange behaviour. I have one server exporting via > NFSv4 several ZFS volumes. The UID mapping went pretty well so far, > but > with a reboot of yesterday (after a buildworld), files are seen with > uid > root:wheel and users are no longer seen. > You might want to check (ifconfig -a) and see that there is a mapping for 127.0.0.1 for lo. That is what is used to do the upcall to nfsused and some systems have had this missing recently. (I had the impression that the problem was caused by r244678, which was reverted by r244989, but maybe your system still has that issue.) Here's basically how it works, which may help with diagnosing what is going on: - when the nfsuserd starts up, it pushes a DNS domain (usually the hostname with the first component stripped off) plus a couple of hundred mappings acquired via getpwent()/getgrent() into the kernel cache. (The easiest way to break it for all users is to have the wrong DNS domain name. "man nfsuserd" gives you a command line option that can override the default of using the hostname.) - Then the nfsuserd waits for upcalls for cache misses and pushes mappings for those requests into the kernel. - The cache entries time out with a rather long default of 1hr. To get entries, nfsused just uses the getpwent() and getgrent() libc calls, so it depends on whatever you have configured for that via /etc/nsswitch.conf. I'll grab a new kernel and do a quick test, to see if it works ok for me. (The most recent commit related to this is r240720, which added support to the client for numeric uids/gids in the string on the wire. This change should not have affected the server.) Good luck with it, rick > The server and client in question are > > server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013 > client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013 > > I think this is not supposed to be that way. Another box, our lab's > server, doesn't show this phenomenon (but at the moment I have only > the > opportunity to check with a FreeBSD 9.1-STABLE client). This specific > server is > > server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013 > > By the way, can someone give me a hint why some boxes show up with an > attached "M" to the SVN revision number (like r245005M)? > > Thanks, > > oh From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:52:33 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BBB18BC for ; Fri, 4 Jan 2013 13:52:33 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id CE5CA303 for ; Fri, 4 Jan 2013 13:52:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1Tr7hB-0046p8-0D>; Fri, 04 Jan 2013 14:52:25 +0100 Received: from e178029108.adsl.alicedsl.de ([85.178.29.108] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1Tr7hA-0007pe-S4>; Fri, 04 Jan 2013 14:52:24 +0100 Message-ID: <50E6DE91.7010404@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 14:52:17 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Current FreeBSD Subject: ZFS/RAIDZ and SAMBA: abyssimal performance X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C265D08FBE00A13812E55FE" X-Originating-IP: 85.178.29.108 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:52:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C265D08FBE00A13812E55FE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable I use a small testing server. The hardware is most modern Intel hardware (i3-3220, Z77 chipset), 16GB RAM. The OS is FreeBSD 10.0-CURRENT #1 r245036M: Fri Jan 4 12:48:53 CET 2013. The ZFS subsystem is comprised by 3 Western Digital 3 TB harddrives (WDC WD30EZRX-00DC0B0 80.00A80> ATA-9 SATA 3.x device), setup as a ZFS RAIDZ: --- root@gate [etc] zpool status pool: ASGARD00 state: ONLINE scan: scrub repaired 0 in 1h45m with 0 errors on Sat Dec 1 20:59:44 20= 12 config: NAME STATE READ WRITE CKSUM ASGARD00 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gptid/1e716118-1492-11e2-b828-90f6526a24d6 ONLINE 0 0 0 gptid/294a6798-1492-11e2-b828-90f6526a24d6 ONLINE 0 0 0 gptid/30c813f8-1492-11e2-b828-90f6526a24d6 ONLINE 0 0 0 logs ada0p1 ONLINE 0 0 0 cache ada0p2 ONLINE 0 0 0 errors: No known data errors --- The "logs" and "cache" device is a single SAMSUNG 830 SSD, 60 GB capacity, GPT partinioned, logs (ZIL) has 5GB, cache has ~55 GB. I think its not the optimal setup using the very same SSD for both caching/L2ARC and ZIL, but without the cache device the performance doen't differ much at the moment. Luckliy, with ZFS I can change the arrangement as I like. The ZFS volumes created on the pool named ASGARD00 are standard, only options sharenfs/sharesmb/checksum are set to yes. Everthing elese is set to the defaults. In /boot/loader.conf I set the following parameters according to many (and confusing!) help and suggestions on the web: # ZFS #vfs.zfs.cache_flush_disable=3D1 # #vfs.zfs.write_limit_override=3D1073741824 # 1GB vfs.zfs.l2arc_noprefetch=3D0 vfs.zfs.l2arc_headroom=3D6 The NFSv4 performance (client is also FreeBSD 10.0-CURRENT of the same date) is moderate to disapointing and doesn't exceed 45 - 55 MB/s sustained, but here are sometimes "spikes" I can watch with "systat -vm 1" reporting 120 MB/s per drive (ada2/ada3/ada4, the 3x 3TB WD drives in RAIDZ). I still benchmark via iozone. Both server and client use JUMBO frames (MTU=3D6120), which gives better throughput compared to the standard MTU=3D1500. The local performance on the server itself is slightly better, but iozone reports some strange numbers. The benchmark "writes" (using 4 threads, 4k blocksizes, writing four times files of size 1G to the ZFS volume reports sometimes 150 MB/s throughput, and then 70 MB/s and re-writes is then 1/10 of the "write" throughput and according to the manual of iozone, re-write is considered to have higher values due to the lack of writing the meta data again. But I'm still testing this case.= Well, the ZFS volumes are also shared as SAMBA CIFS volumes and here I experience something that is simply described as "abyssimal" performance! From both a dedicated Windows 7 Pro client and a VirtualBox 4.2.6-client access to folders in a share, say my local home, can take ages! Opening files takes eons, if possible, in most cases windows reports "can not open ...". Copying files from Windows to the SAMBA share doesn't work or take ages, the throughput visible on the server side watched by "systat -vm 1" reports spiking 0.48 MB/s, with a hiatus of several seconds. Well, the SAMBA setup is straightforward, for two weeks now I have permutated nearly every parameter suggested on all the web's help sites and I simply took the well configuration from one of our lab's FreeBSD 9.1-STABLE SAMBA servers and changed the local settings for IP and domain names etc. The working server (FreeBSD 9.1-STABLE) in question has a single ZFS drive and is exporting this also via NFSv4. It doesn't have RAIDZ setup! Before I start benchmarking further with iozone I need to know whether there is an unresolved problem in FreeBSD 10.0 with ZFS/RAIDZ and SAMBA or whether I'm mislead and have overseen an important setup option. Before exposing all of my setups here I need to clearify. I didn't find so far any issues on the web regarding SAMBA, NFSv4 and ZFS/RAIDZ. Thanks in advance, Oliver --------------enig0C265D08FBE00A13812E55FE 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5t6YAAoJEOgBcD7A/5N8mQ4H/2+kV0yTu8ItrjJYqANJ2w+z zS6k9Wa3lFo0lrz6hY8w2F7ZilSMJuYkgn5Ugif/g/vNxs8KVjTm+CcZ2pQ/fPdO /Wv9eu+NGHZ1QhaBvQ0sKG1ZKNH6KcTnWlIhBviB8B98OEFGMQF7C8TQ37NwO40y hbdJGiAu16Lbkn1TGuMmWOfrW0FJfrhjqWJfDDVigr+gDTlHhW/fh0GZ3NSbzdVX jIBZTv3SSCRAIWyZieqTxzNXzHjPZ3otWL97vUM3+gFMPHXVQQEcmfdZOYzdJnnA 9DMNFedFbShCxIMlkm/n5fS5OsrOHXKgKocYyVw4BKVhpGt59GMv9ysVVHX8xFw= =n/b2 -----END PGP SIGNATURE----- --------------enig0C265D08FBE00A13812E55FE-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:06:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C3C2AD6 for ; Fri, 4 Jan 2013 14:06:05 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 24AB9371 for ; Fri, 4 Jan 2013 14:06:04 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so9262381wib.1 for ; Fri, 04 Jan 2013 06:06:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=usF0XiTu/77nrMRCIusTyWNqsfXD5sEH2HJJI9iiZ8E=; b=PAx3++D/iGr4sOzCExwAru9ty2hHOgzczcS+0hIC6Z/+wh9bkVShFPTlbYmZSGhEXJ iPzL7/hMG1DLWnIiUmG4KxEg2NDSr3ZpzZhvh3JCpriqpkTQviHoTYkrvbOOT5lOlmKv X4E6lOStLyibGnIah8C6QBfo9FiNkerXvald6z7p4YyEhQh6jM+nVdAsj+gfdnx/Nca5 lMXR2/QsSsNF5OcmMlxGgwxIDwHkY58YiICllG3YS2MvZT3s0HlP6pbSj5AwXgP0ctrd w3v3lWC/jqeG8CELyEJjGRpqyVEUpp2xr4JEog14vGdynIi19SrPBYZp7/oVwYo8Xeuk ATZQ== X-Received: by 10.194.88.98 with SMTP id bf2mr84253307wjb.49.1357308363130; Fri, 04 Jan 2013 06:06:03 -0800 (PST) Received: from [10.75.0.66] ([83.167.62.196]) by mx.google.com with ESMTPS id g2sm90400225wiy.0.2013.01.04.06.06.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 06:06:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Fleuriot Damien In-Reply-To: <50E6DE91.7010404@zedat.fu-berlin.de> Date: Fri, 4 Jan 2013 15:06:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQn4k1aq5+wXXdMKcK4aagQZrjLPaGft7cLRxjEwo1B64xohRWa/VU47bqWDqqVTNu9Xk+wd Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:06:05 -0000 On Jan 4, 2013, at 2:52 PM, "O. Hartmann" = wrote: > I use a small testing server. The hardware is most modern Intel = hardware > (i3-3220, Z77 chipset), 16GB RAM. The OS is FreeBSD 10.0-CURRENT #1 > r245036M: Fri Jan 4 12:48:53 CET 2013. >=20 > The ZFS subsystem is comprised by 3 Western Digital 3 TB harddrives = (WDC > WD30EZRX-00DC0B0 80.00A80> ATA-9 SATA 3.x device), setup as a ZFS = RAIDZ: >=20 > --- > root@gate [etc] zpool status > pool: ASGARD00 > state: ONLINE > scan: scrub repaired 0 in 1h45m with 0 errors on Sat Dec 1 20:59:44 = 2012 > config: >=20 > NAME STATE READ > WRITE CKSUM > ASGARD00 ONLINE 0 > 0 0 > raidz1-0 ONLINE 0 > 0 0 > gptid/1e716118-1492-11e2-b828-90f6526a24d6 ONLINE 0 > 0 0 > gptid/294a6798-1492-11e2-b828-90f6526a24d6 ONLINE 0 > 0 0 > gptid/30c813f8-1492-11e2-b828-90f6526a24d6 ONLINE 0 > 0 0 > logs > ada0p1 ONLINE 0 > 0 0 > cache > ada0p2 ONLINE 0 > 0 0 >=20 > errors: No known data errors > --- >=20 > The "logs" and "cache" device is a single SAMSUNG 830 SSD, 60 GB > capacity, GPT partinioned, logs (ZIL) has 5GB, cache has ~55 GB. >=20 > I think its not the optimal setup using the very same SSD for both > caching/L2ARC and ZIL, but without the cache device the performance > doen't differ much at the moment. Luckliy, with ZFS I can change the > arrangement as I like. >=20 > The ZFS volumes created on the pool named ASGARD00 are standard, only > options sharenfs/sharesmb/checksum are set to yes. Everthing elese is > set to the defaults. >=20 > In /boot/loader.conf I set the following parameters according to many > (and confusing!) help and suggestions on the web: >=20 > # ZFS > #vfs.zfs.cache_flush_disable=3D1 > # > #vfs.zfs.write_limit_override=3D1073741824 # 1GB > vfs.zfs.l2arc_noprefetch=3D0 > vfs.zfs.l2arc_headroom=3D6 >=20 > The NFSv4 performance (client is also FreeBSD 10.0-CURRENT of the same > date) is moderate to disapointing and doesn't exceed 45 - 55 MB/s > sustained, but here are sometimes "spikes" I can watch with "systat = -vm > 1" reporting 120 MB/s per drive (ada2/ada3/ada4, the 3x 3TB WD drives = in > RAIDZ). I still benchmark via iozone. Both server and client use JUMBO > frames (MTU=3D6120), which gives better throughput compared to the > standard MTU=3D1500. >=20 > The local performance on the server itself is slightly better, but > iozone reports some strange numbers. The benchmark "writes" (using 4 > threads, 4k blocksizes, writing four times files of size 1G to the ZFS > volume reports sometimes 150 MB/s throughput, and then 70 MB/s and > re-writes is then 1/10 of the "write" throughput and according to the > manual of iozone, re-write is considered to have higher values due to > the lack of writing the meta data again. But I'm still testing this = case. >=20 > Well, the ZFS volumes are also shared as SAMBA CIFS volumes and here I > experience something that is simply described as "abyssimal" > performance! =46rom both a dedicated Windows 7 Pro client and a = VirtualBox > 4.2.6-client access to folders in a share, say my local home, can take > ages! Opening files takes eons, if possible, in most cases windows > reports "can not open ...". Copying files from Windows to the SAMBA > share doesn't work or take ages, the throughput visible on the server > side watched by "systat -vm 1" reports spiking 0.48 MB/s, with a = hiatus > of several seconds. >=20 > Well, the SAMBA setup is straightforward, for two weeks now I have > permutated nearly every parameter suggested on all the web's help = sites > and I simply took the well configuration from one of our lab's FreeBSD > 9.1-STABLE SAMBA servers and changed the local settings for IP and > domain names etc. The working server (FreeBSD 9.1-STABLE) in question > has a single ZFS drive and is exporting this also via NFSv4. It = doesn't > have RAIDZ setup! >=20 > Before I start benchmarking further with iozone I need to know whether > there is an unresolved problem in FreeBSD 10.0 with ZFS/RAIDZ and = SAMBA > or whether I'm mislead and have overseen an important setup option. > Before exposing all of my setups here I need to clearify. >=20 > I didn't find so far any issues on the web regarding SAMBA, NFSv4 and > ZFS/RAIDZ. >=20 > Thanks in advance, > Oliver >=20 >=20 I experienced the same performance problem, then followed Jeremy = Chadwick's advice and tuned variables a bit, I'm getting excellent = performance now. /boot/loader.conf # Tune ZFS somewhat aye ? vm.kmem_size=3D"3072M" vfs.zfs.arc_min=3D"128M" vfs.zfs.arc_max=3D"2048M" # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the "bursty" stalls that # happen during immense I/O with ZFS. # = http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # = http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout=3D"5" And network cards: # Up a bit our intel cards parameters hw.em.txd=3D4096 hw.em.rxd=3D4096 hw.em.tx_int_delay=3D512 hw.em.rx_int_delay=3D512 hw.em.tx_abs_int_delay=3D1024 hw.em.rx_abs_int_delay=3D1024 And this is under [global] in /usr/local/etc/smb.conf: min receivefile size =3D 16384 aio read size =3D 16384 aio write size =3D 16384 aio write behind =3D yes From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:14:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F7AEE60; Fri, 4 Jan 2013 14:14:38 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB9D23FB; Fri, 4 Jan 2013 14:14:37 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5CCBF5C5A; Fri, 4 Jan 2013 15:14:26 +0100 (CET) Message-ID: <50E6E3C3.8040801@FreeBSD.org> Date: Fri, 04 Jan 2013 15:14:27 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Stefan Farfeleder Subject: Re: Unbreaking gdb's catch throw References: <20130104123424.GA1430@mole.fafoe.narf.at> <20130104124927.GB1430@mole.fafoe.narf.at> <8FA4D44F-0D32-4374-810F-5630E995F61F@freebsd.org> <20130104130217.GC1430@mole.fafoe.narf.at> In-Reply-To: <20130104130217.GC1430@mole.fafoe.narf.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:14:38 -0000 On 2013-01-04 14:02, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 12:54:03PM +0000, David Chisnall wrote: >> As a work-around, you can put the breakpoint on _Unwind_RaiseException instead. This will work for any language, not just C++ (e.g. it will notice Objective-C or gcj-compiled Java exceptions). > Thank you, that works for me. Alternatively, install the gdb port, which seems to work just fine: $ /usr/local/bin/gdb ./throw GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd10.0". For bug reporting instructions, please see: ... Reading symbols from /tmp/throw...done. (gdb) break __cxa_throw Breakpoint 1 at 0x400604 (gdb) run Starting program: /tmp/throw Breakpoint 1, __cxxabiv1::__cxa_throw (obj=0x801c060f0, tinfo=0x600c00 <_ZTIi@@CXXABI_1.3>, dest=0x0) at /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:60 60 __cxa_exception *header = __get_exception_header_from_obj (obj); From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:45:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8AEB87C for ; Fri, 4 Jan 2013 14:45:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA7E73A for ; Fri, 4 Jan 2013 14:45:27 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j6so15053762oag.26 for ; Fri, 04 Jan 2013 06:45: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=IpRk0vVul+zkUwyTPQD1ghKLA5poW8gV2qzTSodeCkw=; b=n1M1gvLyOH8SBB9KngqNiHzcgk09UyAjo3AYCdp67XwiXLlAGSIEgmiJ/RTOc/O1XY IVI+G5rThNb92rc8BxrdqikHqJqQskdooSAKXAGEdq7JNVQ9lL2X62A6sXYUCGYRq4at CboiD5hMOWLZvODs3jjvVYlPPrOoQxI2VrmweXPmCA+h4yyE56eeKmmule1TA6756HxF 6t7ja6Fpwf0jk/hn6anhKZSyv2RquIpkI34MmPd9SJGz9TH9rNnkSE8u+8t8RWfmF9wD jSAL7GIbaDY1p6qDiaWuoPm6B63ORv4wz5HDw4kRpCqVBfG8s1hf6BOOspGkYORGK6TK SSiQ== MIME-Version: 1.0 Received: by 10.60.172.178 with SMTP id bd18mr30747947oec.133.1357310721512; Fri, 04 Jan 2013 06:45:21 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 4 Jan 2013 06:45:21 -0800 (PST) In-Reply-To: <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> Date: Fri, 4 Jan 2013 06:45:21 -0800 Message-ID: Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Garrett Cooper To: Fleuriot Damien Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:45:27 -0000 On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: ... > And this is under [global] in /usr/local/etc/smb.conf: > min receivefile size = 16384 > aio read size = 16384 > aio write size = 16384 > aio write behind = yes These are still pretty low, depending on what your networking/disk setup is like; my important performance settings are: socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT write cache size = 65536 aio read size = 65536 aio write size = 65536 directory name cache size = 0 HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:48:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FB5AA01; Fri, 4 Jan 2013 14:48:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx1.freebsd.org (Postfix) with ESMTP id E6B78765; Fri, 4 Jan 2013 14:48:54 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n5so15239417oag.3 for ; Fri, 04 Jan 2013 06:48:48 -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=QSbxuWjuOsaww8eKNLi9uf5vg30QA97c2n+xREbJUDw=; b=E0WcoBERq2LWdQVDXwQizXCtwzohgwcBmFdB4Ei7UflahXtFzr3SMVN6pOFzHYS0qs 5nG6nG8aPsnDkkWmuHfTSkgyVk1qVg/U+pneiyOCDxYrF1g8ncRtPO1RDTtYJGPmVgRd lavJGZ0ZLuz/X/xcc4ajYlt09Jwql8JsC55ulJyPWApr4JxsD21j3rTMXuRYMFljqWaG e7iXJYmvM+JxLwY9jra4DQA9bfRv8SOo5ZnyQbKQrIZU/x0s3lWB2utTTjqcTTeUAx9l bParO4ipG5pymI4eP4+vOrkwmiQhBPRGRmaF1CJ3n1jTebQyksIxYv+1wgHwDp4v8OsY 5Jxw== MIME-Version: 1.0 Received: by 10.60.0.165 with SMTP id 5mr30829300oef.128.1357310928561; Fri, 04 Jan 2013 06:48:48 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 4 Jan 2013 06:48:48 -0800 (PST) In-Reply-To: <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> References: <201301041109.r04B97QU001888@mech-cluster241.men.bris.ac.uk> <201301041123.r04BNwTU014117@mech-cluster241.men.bris.ac.uk> Date: Fri, 4 Jan 2013 06:48:48 -0800 Message-ID: Subject: Re: installworld error: ad0: FAILURE - READ_DMA status=51 error=40 LBA=28071584 From: Garrett Cooper To: mexas@bristol.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:48:55 -0000 On Fri, Jan 4, 2013 at 3:23 AM, Anton Shterenlikht wrote: ... > Is my disk dying? Uncorrectable read errors suggest yes (especially because the LBA varies between the two error messages). I would definitely backup your data at the very least, and as others suggested use smartmontools [via a livecd?]. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:52:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94373C1D for ; Fri, 4 Jan 2013 14:52:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6802B7A7 for ; Fri, 4 Jan 2013 14:52:19 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id ta14so14817424obb.5 for ; Fri, 04 Jan 2013 06:52:12 -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=FGltg+KYkCOonIbZ1qLZ9yUKd0UdeAGfG+z1P+FHacQ=; b=mEdtUvABjgV0g5u5AEnSMXUou+r7ozcMeUT96brZckdjjdhzSH/rIeDGkfXY0l4i5Y Ng8EnCFZwMLWzTC/X8sv+8/dTplk8I6LwmhLcprUqQ8ew5Kg2pF5eCRRyUPP5n+fHMZW IglgYoJ00fBZ5oh/427Gb23EFr+3jWQxnmpxhHHCvHuvXkPfM6DstXFuPMg/JiplptPE EkV2E5FEXNMHv+IbdLV+QU/bHqCZ5vfVJmAy3RI7s1wqqdNYE0OkbjZ4LQjfp5sxMqeG jonJlcP5Goci9DTPXGTvK5YzkD6/T/JlON7EV8s+gFh51hjhuzZfT9xRU/xKAHKlrwIM mV7Q== MIME-Version: 1.0 Received: by 10.60.172.164 with SMTP id bd4mr29609128oec.51.1357311132250; Fri, 04 Jan 2013 06:52:12 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 4 Jan 2013 06:52:12 -0800 (PST) In-Reply-To: <50E6AB65.5030309@zedat.fu-berlin.de> References: <50E6AB65.5030309@zedat.fu-berlin.de> Date: Fri, 4 Jan 2013 06:52:12 -0800 Message-ID: Subject: Re: r245005M: NFSv4 usermapping not working anymore From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:52:19 -0000 Answering just the trivial question... On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote: ... > server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013 > > By the way, can someone give me a hint why some boxes show up with an > attached "M" to the SVN revision number (like r245005M)? The M stands for sources modified after checkout: http://gotofritz.net/blog/howto/svn-status-codes/ HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:56:50 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 71049D7B for ; Fri, 4 Jan 2013 14:56:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA077D8 for ; Fri, 4 Jan 2013 14:56:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Tr8hU-0003F2-32>; Fri, 04 Jan 2013 15:56:48 +0100 Received: from e178036024.adsl.alicedsl.de ([85.178.36.24] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Tr8hT-000BP6-VQ>; Fri, 04 Jan 2013 15:56:48 +0100 Message-ID: <50E6EDAE.9010908@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 15:56:46 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: r245005M: NFSv4 usermapping not working anymore References: <416983367.1668162.1357306220561.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <416983367.1668162.1357306220561.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1FA6F100C8E3CE763C93D9B" X-Originating-IP: 85.178.36.24 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:56:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1FA6F100C8E3CE763C93D9B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 01/04/13 14:30, schrieb Rick Macklem: > O. Hartmann wrote: >> Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT >> boxes, i realize a strange behaviour. I have one server exporting via >> NFSv4 several ZFS volumes. The UID mapping went pretty well so far, >> but >> with a reboot of yesterday (after a buildworld), files are seen with >> uid >> root:wheel and users are no longer seen. >> > You might want to check (ifconfig -a) and see that there is a mapping > for 127.0.0.1 for lo. That is what is used to do the upcall to nfsused > and some systems have had this missing recently. (I had the impression > that the problem was caused by r244678, which was reverted by r244989, > but maybe your system still has that issue.) >=20 > Here's basically how it works, which may help with diagnosing what is > going on: > - when the nfsuserd starts up, it pushes a DNS domain (usually the > hostname with the first component stripped off) plus a couple of > hundred mappings acquired via getpwent()/getgrent() into the kernel > cache. > (The easiest way to break it for all users is to have the wrong DNS > domain name. "man nfsuserd" gives you a command line option that can > override the default of using the hostname.) > - Then the nfsuserd waits for upcalls for cache misses and pushes > mappings for those requests into the kernel. > - The cache entries time out with a rather long default of 1hr. >=20 > To get entries, nfsused just uses the getpwent() and getgrent() libc > calls, so it depends on whatever you have configured for that via > /etc/nsswitch.conf. >=20 > I'll grab a new kernel and do a quick test, to see if it works ok for m= e. > (The most recent commit related to this is r240720, which added support= > to the client for numeric uids/gids in the string on the wire. This ch= ange > should not have affected the server.) >=20 > Good luck with it, rick >=20 >> The server and client in question are >> >> server: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:25:00 CET 2013 >> client: FreeBSD 10.0-CURRENT #2 r245005M: Thu Jan 3 20:27:25 CET 2013 >> >> I think this is not supposed to be that way. Another box, our lab's >> server, doesn't show this phenomenon (but at the moment I have only >> the >> opportunity to check with a FreeBSD 9.1-STABLE client). This specific >> server is >> >> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013= >> >> By the way, can someone give me a hint why some boxes show up with an >> attached "M" to the SVN revision number (like r245005M)? >> >> Thanks, >> >> oh Me stupid killed the nfsuserd=3D"YES" entry in rc.conf on the client side= ! So, by starting it again, everything works as before and expected. Many thanks for the quick response! Oliver --------------enigE1FA6F100C8E3CE763C93D9B 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5u2vAAoJEOgBcD7A/5N8yngIAMigBSnTb5uH/GdalzwhOs0Q iglQB7wWuF47YFhSX64QjC2nwUnUV8SwybUS5Z30S2ob4RJNCkPGv7Effc4qi5a3 bR5YoFRZiJJg5apM3aASsZcqpursRMEl3dI2rd8TYHxhJHgES0f3hK8pQ13imoWx dYULGPujOGQ/Yo0lVNA8lR6L/Z7TZXvfib5tU9jX11d2P3meiMKpHGkcjJZ25JGl m2WyYxRGlW1wdo5p78YK0b4eS8Fb5FFZRN6A5Fgfe2yk1e8/0Bs9w/TxKa2v9ks7 4aZEqIzWIOOmOYyrOmbDp8J/5o1EEya1HMTYiIz0f1yFrxzp/kotqKfci6xmcbU= =UCaJ -----END PGP SIGNATURE----- --------------enigE1FA6F100C8E3CE763C93D9B-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 15:19:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 54ED6BD for ; Fri, 4 Jan 2013 15:19:28 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 151758A6 for ; Fri, 4 Jan 2013 15:19:27 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Tr93O-0006CE-8o>; Fri, 04 Jan 2013 16:19:26 +0100 Received: from e178036024.adsl.alicedsl.de ([85.178.36.24] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Tr93O-000CgJ-5C>; Fri, 04 Jan 2013 16:19:26 +0100 Message-ID: <50E6F2FC.3060903@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 16:19:24 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A7323CD0EC96C3D095C6966" X-Originating-IP: 85.178.36.24 Cc: Fleuriot Damien , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 15:19:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A7323CD0EC96C3D095C6966 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/04/13 15:45, schrieb Garrett Cooper: > On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: >=20 > ... >=20 >> And this is under [global] in /usr/local/etc/smb.conf: >> min receivefile size =3D 16384 >> aio read size =3D 16384 >> aio write size =3D 16384 >> aio write behind =3D yes >=20 > These are still pretty low, depending on what your networking/disk > setup is like; my important performance settings are: >=20 > socket options =3D SO_RCVBUF=3D64240 SO_SNDBUF=3D64240 TCP_NODE= LAY > IPTOS_LOWDELAY IPTOS_THROUGHPUT > write cache size =3D 65536 > aio read size =3D 65536 > aio write size =3D 65536 > directory name cache size =3D 0 >=20 > HTH, > -Garrett Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot Damien's values to /boot/loader.conf and yours to the smb.conf. Somewhere in the handbook this should be documented! it is to much efford to get SAMBA working properly with ZFS, if the tricks and problems are so widespread over several architectural aspects of the syst= em. It could save a lot of time for adminsitartors and those which try FreeBSD as a serving system instead of Linux. Just for the record. I feel a bit confused about all the tricks and tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would be a great deal if all these things could be lined up a s a primer with a bit more explanations than "put this number there". And by the way, it is like changing from hell to heaven having now ~ 100 MB/s throughput compared to ~1/500! Thanks a lot, Oliver --------------enig0A7323CD0EC96C3D095C6966 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5vL9AAoJEOgBcD7A/5N8fn4H/2BiBbdPYdFEe9t650FgYT6J GBYzfxZ7415SzEWmUwzdOf4CbIZzSUeXPT7HhYaeVoIEXnRu2A8DGRPK1xkuPHPA V7sOoaiHI78j6uRIrsdARkECigckpUYHeGaq4PTjf3wDT9s5i7Kw5eMwTYtAXX4T 7Y8xmsab1Gj0G2F89O7yXNsKPTKpfhGwbZ+rPthGhy1RLiGJMEnFpkPOwWD7+Zld B/Gany/vQ9j2Bm24nCFEUL5ofzC9xwKADN1Wylhw2FjwzGEy+uU36y2jHQgxdfRS 9iYQFo9QzKhRVigTvHz/seOQsdd975WK5lfBFU1OZuvml26rqoTK+WnIymAYaWw= =AZzG -----END PGP SIGNATURE----- --------------enig0A7323CD0EC96C3D095C6966-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 15:29:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34B5553F for ; Fri, 4 Jan 2013 15:29:36 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id C25D28F2 for ; Fri, 4 Jan 2013 15:29:35 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so276131wgb.4 for ; Fri, 04 Jan 2013 07:29:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=vVwYOxPws+T8U3aLSU9ZtmmRNqNtCHyITU3zKs+G4F4=; b=MF6kh8xHTBbluIpv6SJ4vZa3eMsPTaAYZoUu/cOmOfpeGvzaSgEYAeeHotr6iegrIL xKWhcHrncX/rDnxo+AWkFYZPeazqJCdEYDBAkIT9sB2qP7IsX87SohW8Z4rkBeDFqdcK oNVkZzKky0OZFULHNJnAxLd25kd+rJqMCFcgObLiW5UiSyxUEIR1HBuoa8ge2JG5Z/Fq cjHsa+/WpW+J17GAtsvnqSwOepSKCJIZImhpW1YgB5tksOcT2MNqiVj02apei+oaVfLB a/Fwc2SCfSSuzCyz5yAb8coXdCfXrjHWakOrKdyvDhTqkZOH84YkApvlkhv2q7sw84fw adEg== X-Received: by 10.194.177.199 with SMTP id cs7mr84524755wjc.41.1357313057223; Fri, 04 Jan 2013 07:24:17 -0800 (PST) Received: from [10.75.0.66] ([83.167.62.196]) by mx.google.com with ESMTPS id p3sm94309293wic.8.2013.01.04.07.24.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 07:24:16 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Fleuriot Damien In-Reply-To: <50E6F2FC.3060903@zedat.fu-berlin.de> Date: Fri, 4 Jan 2013 16:24:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlIj9sXIYbOR5/Eqyplbo4ze8YqaOaSyuBIBp1eKaHFpnO3NOeHC7UDuH8zx+A91BlJVXaU Cc: Garrett Cooper , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 15:29:36 -0000 On Jan 4, 2013, at 4:19 PM, O. Hartmann = wrote: > Am 01/04/13 15:45, schrieb Garrett Cooper: >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: >>=20 >> ... >>=20 >>> And this is under [global] in /usr/local/etc/smb.conf: >>> min receivefile size =3D 16384 >>> aio read size =3D 16384 >>> aio write size =3D 16384 >>> aio write behind =3D yes >>=20 >> These are still pretty low, depending on what your networking/disk >> setup is like; my important performance settings are: >>=20 >> socket options =3D SO_RCVBUF=3D64240 SO_SNDBUF=3D64240 = TCP_NODELAY >> IPTOS_LOWDELAY IPTOS_THROUGHPUT >> write cache size =3D 65536 >> aio read size =3D 65536 >> aio write size =3D 65536 >> directory name cache size =3D 0 >>=20 >> HTH, >> -Garrett > Well, now I have peak values ~ 120 MB/s when copying. I applied = Fleuriot > Damien's values to /boot/loader.conf and yours to the smb.conf. > Somewhere in the handbook this should be documented! it is to much > efford to get SAMBA working properly with ZFS, if the tricks and > problems are so widespread over several architectural aspects of the = system. >=20 > It could save a lot of time for adminsitartors and those which try > FreeBSD as a serving system instead of Linux. >=20 > Just for the record. I feel a bit confused about all the tricks and > tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem = wizzardy > thingis. The ZFS Wiki seems to be a bit outdated and confusing, it = would > be a great deal if all these things could be lined up a s a primer = with > a bit more explanations than "put this number there". >=20 > And by the way, it is like changing from hell to heaven having now ~ = 100 > MB/s throughput compared to ~1/500! >=20 > Thanks a lot, > Oliver >=20 The problem, Oliver, is that these values are system dependant. Notice how Garret replied that these values are a bit low (and they = might be indeed !). However, while you have 16gb RAM, my ZFS NAS only has 4gb. Basically and as Jeremy Chadwick pointed out at the time, there is no = one set of correct values for 100% of the population. One has to adjust them step by step and decide what is best for them. @garret: I'll try with the values you posted, although I get = 90-120mbytes/s most of the time so I pretty much saturate my 1gbs link. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 15:49:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 023A6A02; Fri, 4 Jan 2013 15:49:44 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id DF62C9C9; Fri, 4 Jan 2013 15:49:43 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104154941.FLJM2598.viefep15-int.chello.at@edge03.upcmail.net>; Fri, 4 Jan 2013 16:49:41 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id jrph1k00S2xdvHc03rpha2; Fri, 04 Jan 2013 16:49:41 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 1FE9C6D454; Fri, 4 Jan 2013 16:49:41 +0100 (CET) Date: Fri, 4 Jan 2013 16:49:41 +0100 From: Stefan Farfeleder To: Dimitry Andric Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130104154940.GD1430@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130102135950.GA1464@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 15:49:45 -0000 On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote: > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: > > > > I have been playing with Stefan's testcase for a while now, and while I > > can reproduce the crashes, I am still at a loss about the cause. It > > does seem to have something to do with throwing exceptions, but I am > > still not sure whether I am looking at a bug in boost, gcc, clang, or > > libgcc... > > > > Do you happen to have a smaller testcase, by any chance? > > Not yet, but I'll try to come up with something smaller. Here's a minimal test case that reproduces the bug: $ cat throw-crash.cc #include void f2(void) { std::string s; throw std::runtime_error("foo"); } void f1(void) { f2(); } int main(void) { try { std::string s1, s2; f1(); return 0; } catch (const std::exception &) { return 1; } } $ g++ -O2 -finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error (core dumped) ./a.out Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 16:52:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D476990C for ; Fri, 4 Jan 2013 16:52:44 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 83E11D77 for ; Fri, 4 Jan 2013 16:52:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrAVf-000HR4-3p>; Fri, 04 Jan 2013 17:52:43 +0100 Received: from e178036024.adsl.alicedsl.de ([85.178.36.24] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrAVf-000Hmd-0b>; Fri, 04 Jan 2013 17:52:43 +0100 Message-ID: <50E708D9.5000605@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 17:52:41 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: r245005M: NFSv4 usermapping not working anymore References: <50E6AB65.5030309@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC0D52D80FE0190EAF0A6194" X-Originating-IP: 85.178.36.24 Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 16:52:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC0D52D80FE0190EAF0A6194 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/04/13 15:52, schrieb Garrett Cooper: > Answering just the trivial question... >=20 > On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote: >=20 > ... >=20 >> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 201= 3 >> >> By the way, can someone give me a hint why some boxes show up with an >> attached "M" to the SVN revision number (like r245005M)? >=20 > The M stands for sources modified after checkout: > http://gotofritz.net/blog/howto/svn-status-codes/ > HTH, > -Garrett >=20 Well, from what I received by now - does this imply that I have supposedly manipulated my sources? Well, I'm not aware of that except that I use non-GENERIC kernel configuration file, but that is named different. I'm surprised and a bit confused ... Oliver --------------enigEC0D52D80FE0190EAF0A6194 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5wjaAAoJEOgBcD7A/5N82cUH/i3q7bACOyUObUW/t844wj70 pI1L7+aC3nmPxzboMQ+be6EMxJQ0yiHP+AvC0lDdxjKmjAFDyQSOM9p7aZxTI7kS 9vs5VtICjFpt3GFXtCP1aaQdLvSMTx7JGBUtd9ZZBdiF6JiUpaJFkqXGJlubc5Hc XdZEG24PIPz3s64R7NCXoocxEfld6WLrF3iDXF9/A/C1GVbq5PbqSiEyQbBSsoP0 qbB0bDUrVqq+06rvo528kZFsciJkffxX5xZyKj53hjALinOoHUyO4yIh6pdqSX3y BTxf39yGsYY1ayYTtVcmthv55YjdpYjxSiILaFRVq06jfIxlVgKRvL70OEgB6Fs= =5pM7 -----END PGP SIGNATURE----- --------------enigEC0D52D80FE0190EAF0A6194-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:00:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDD19A94 for ; Fri, 4 Jan 2013 17:00:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 91822DBD for ; Fri, 4 Jan 2013 17:00:18 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r04H0CSx093628; Fri, 4 Jan 2013 09:00:12 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r04H0C5V093627; Fri, 4 Jan 2013 09:00:12 -0800 (PST) (envelope-from sgk) Date: Fri, 4 Jan 2013 09:00:12 -0800 From: Steve Kargl To: "O. Hartmann" Subject: Re: r245005M: NFSv4 usermapping not working anymore Message-ID: <20130104170012.GA93592@troutmask.apl.washington.edu> References: <50E6AB65.5030309@zedat.fu-berlin.de> <50E708D9.5000605@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E708D9.5000605@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:00:18 -0000 On Fri, Jan 04, 2013 at 05:52:41PM +0100, O. Hartmann wrote: > Am 01/04/13 15:52, schrieb Garrett Cooper: > > Answering just the trivial question... > > On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote: > >> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013 > >> > >> By the way, can someone give me a hint why some boxes show up with an > >> attached "M" to the SVN revision number (like r245005M)? > > > > The M stands for sources modified after checkout: > > http://gotofritz.net/blog/howto/svn-status-codes/ > > Well, from what I received by now - does this imply that I have > supposedly manipulated my sources? > cd /usr/src svn status -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:01:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC0C2BAE for ; Fri, 4 Jan 2013 17:01:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 74F6FDD4 for ; Fri, 4 Jan 2013 17:01:32 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B52985C5A; Fri, 4 Jan 2013 18:01:29 +0100 (CET) Message-ID: <50E70AE9.1080907@FreeBSD.org> Date: Fri, 04 Jan 2013 18:01:29 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: r245005M: NFSv4 usermapping not working anymore References: <50E6AB65.5030309@zedat.fu-berlin.de> <50E708D9.5000605@zedat.fu-berlin.de> In-Reply-To: <50E708D9.5000605@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:01:32 -0000 On 2013-01-04 17:52, O. Hartmann wrote: > Am 01/04/13 15:52, schrieb Garrett Cooper: >> Answering just the trivial question... ... >> The M stands for sources modified after checkout: >> http://gotofritz.net/blog/howto/svn-status-codes/ > Well, from what I received by now - does this imply that I have > supposedly manipulated my sources? > > Well, I'm not aware of that except that I use non-GENERIC kernel > configuration file, but that is named different. Just run "svn status" in your source tree, and Subversion will show you what it thinks is modified. From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:00:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB0CEBA5 for ; Fri, 4 Jan 2013 17:00:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6D906DD0 for ; Fri, 4 Jan 2013 17:00:52 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 5FC6F153433; Fri, 4 Jan 2013 18:00:50 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfcqJ2i2q2RI; Fri, 4 Jan 2013 18:00:49 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id BE9DD153435; Fri, 4 Jan 2013 18:00:49 +0100 (CET) Message-ID: <50E70ACA.6040300@digiware.nl> Date: Fri, 04 Jan 2013 18:00:58 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: r245005M: NFSv4 usermapping not working anymore References: <50E6AB65.5030309@zedat.fu-berlin.de> <50E708D9.5000605@zedat.fu-berlin.de> In-Reply-To: <50E708D9.5000605@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130104-0, 01/04/2013), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Fri, 04 Jan 2013 17:07:26 +0000 Cc: Garrett Cooper , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:00:52 -0000 On 2013-01-04 17:52, O. Hartmann wrote: > Am 01/04/13 15:52, schrieb Garrett Cooper: >> Answering just the trivial question... >> >> On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote: >> >> ... >> >>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2013 >>> >>> By the way, can someone give me a hint why some boxes show up with an >>> attached "M" to the SVN revision number (like r245005M)? >> >> The M stands for sources modified after checkout: >> http://gotofritz.net/blog/howto/svn-status-codes/ >> HTH, >> -Garrett >> > > > Well, from what I received by now - does this imply that I have > supposedly manipulated my sources? > > Well, I'm not aware of that except that I use non-GENERIC kernel > configuration file, but that is named different. > > I'm surprised and a bit confused ... Go to /usr/src and go: svn status. It will tell you the files it does not like. ?'s are for files that are not in SVN. M are for modified files. --WjW From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 17:51:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C69C56A1 for ; Fri, 4 Jan 2013 17:51:36 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7F21DF71 for ; Fri, 4 Jan 2013 17:51:36 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrBQc-000OLP-3k>; Fri, 04 Jan 2013 18:51:34 +0100 Received: from e178037200.adsl.alicedsl.de ([85.178.37.200] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrBQc-000Ksh-0L>; Fri, 04 Jan 2013 18:51:34 +0100 Message-ID: <50E716A4.3070102@zedat.fu-berlin.de> Date: Fri, 04 Jan 2013 18:51:32 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: r245005M: NFSv4 usermapping not working anymore References: <50E6AB65.5030309@zedat.fu-berlin.de> <50E708D9.5000605@zedat.fu-berlin.de> <20130104170012.GA93592@troutmask.apl.washington.edu> In-Reply-To: <20130104170012.GA93592@troutmask.apl.washington.edu> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig32FB3AFD2478203614D23F40" X-Originating-IP: 85.178.37.200 Cc: Garrett Cooper , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:51:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig32FB3AFD2478203614D23F40 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01/04/13 18:00, schrieb Steve Kargl: > On Fri, Jan 04, 2013 at 05:52:41PM +0100, O. Hartmann wrote: >> Am 01/04/13 15:52, schrieb Garrett Cooper: >>> Answering just the trivial question... >>> On Fri, Jan 4, 2013 at 2:13 AM, O. Hartmann wrote: >>>> server-1: FreeBSD 10.0-CURRENT #0 r244957: Wed Jan 2 12:06:13 CET 2= 013 >>>> >>>> By the way, can someone give me a hint why some boxes show up with a= n >>>> attached "M" to the SVN revision number (like r245005M)? >>> >>> The M stands for sources modified after checkout: >>> http://gotofritz.net/blog/howto/svn-status-codes/ >> >> Well, from what I received by now - does this imply that I have >> supposedly manipulated my sources? >> >=20 > cd /usr/src > svn status >=20 Thanks. Did so. And found some "sins" in GENERIC. Oliver --------------enig32FB3AFD2478203614D23F40 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.19 (FreeBSD) iQEcBAEBAgAGBQJQ5xalAAoJEOgBcD7A/5N829MH/jUZ7/WO/QVQwj0PSalv+nYF Tw2VgRv4RQmekRJMNfG/zIlRtiXIUtPF8+vS5zUW0eWDTttUdDMN2G/fDHyZrqZH rshwLeq5PHQ8GQq/M8WhAs7gSZ7tDmjf5oKqhu1kv7nt/yADcAxhTnwRChAwWv+p rhOREBoEwlwHUVwKQXslFksFtJ1ePLeBvQWCOtaioaOq2qzRlVF7oKmSfyaSCSJc VHoAYst7gMDQW5GRbNm+23ZcyXn+9ijcv4ZpBtbKNw/WEfzA7jlHPi62bf5ZaW8i a4zC3WK7PSQIBTyRiGWD83wVxdW5OrrGzPbcC3/GUANpnF8k1gC36XaQIGBqjAE= =A/T8 -----END PGP SIGNATURE----- --------------enig32FB3AFD2478203614D23F40-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:10:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 38504A3C for ; Fri, 4 Jan 2013 18:10:32 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by mx1.freebsd.org (Postfix) with ESMTP id C1274B9 for ; Fri, 4 Jan 2013 18:10:31 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id ik5so7333730bkc.24 for ; Fri, 04 Jan 2013 10:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Tpx/Q0jbqcelkDfyKzB0/cbEQWNS1RJHTX+sK4+CWCs=; b=k6cDS5KjKZ4s7sxaevRm3PtqdmHLY6UIX9Mgso3dZ6ddeibjcKXGZ7Abw2v1tCuuPW 4vIOXRi+1zsJ64kYlyccTjgNyqi022+4H+PlHOovx2svoO5HzXz5hbz7XFlN7MLz8jSU 7WX6M7VnsVwnrAnz8lN4XcmFwD4mbEKFPwqVGuXzlZU9Cqu6X84RmzD15bWF5C+LZLFa WbUuDM3evBtRREdt6BQiY+1qnf7yrepKoH0E0gz+bUpiaG/JTSvrWiSN4/WKR4yMsaJ/ dwlWFSs3Q591vhKNGFsKEk8NDEjPY1tE3M7wwKKDIV3XtYrhJQiydnGicedrHqQJRxTz fNmw== X-Received: by 10.204.9.3 with SMTP id j3mr25600754bkj.134.1357323025267; Fri, 04 Jan 2013 10:10:25 -0800 (PST) Received: from [192.168.1.15] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id hm8sm37532273bkc.10.2013.01.04.10.10.23 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2013 10:10:24 -0800 (PST) Message-ID: <50E71B0D.602@gmail.com> Date: Fri, 04 Jan 2013 19:10:21 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> In-Reply-To: <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:10:32 -0000 Fleuriot Damien schreef: > On Jan 4, 2013, at 4:19 PM, O. Hartmann wrote: > >> Am 01/04/13 15:45, schrieb Garrett Cooper: >>> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: >>> >>> ... >>> >>>> And this is under [global] in /usr/local/etc/smb.conf: >>>> min receivefile size = 16384 >>>> aio read size = 16384 >>>> aio write size = 16384 >>>> aio write behind = yes >>> These are still pretty low, depending on what your networking/disk >>> setup is like; my important performance settings are: >>> >>> socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 TCP_NODELAY >>> IPTOS_LOWDELAY IPTOS_THROUGHPUT >>> write cache size = 65536 >>> aio read size = 65536 >>> aio write size = 65536 >>> directory name cache size = 0 >>> >>> HTH, >>> -Garrett >> Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot >> Damien's values to /boot/loader.conf and yours to the smb.conf. >> Somewhere in the handbook this should be documented! it is to much >> efford to get SAMBA working properly with ZFS, if the tricks and >> problems are so widespread over several architectural aspects of the system. >> >> It could save a lot of time for adminsitartors and those which try >> FreeBSD as a serving system instead of Linux. >> >> Just for the record. I feel a bit confused about all the tricks and >> tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy >> thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would >> be a great deal if all these things could be lined up a s a primer with >> a bit more explanations than "put this number there". >> >> And by the way, it is like changing from hell to heaven having now ~ 100 >> MB/s throughput compared to ~1/500! >> >> Thanks a lot, >> Oliver >> > > The problem, Oliver, is that these values are system dependant. > > Notice how Garret replied that these values are a bit low (and they might be indeed !). > > However, while you have 16gb RAM, my ZFS NAS only has 4gb. > > > > Basically and as Jeremy Chadwick pointed out at the time, there is no one set of correct values for 100% of the population. > > One has to adjust them step by step and decide what is best for them. > > > > @garret: I'll try with the values you posted, although I get 90-120mbytes/s most of the time so I pretty much saturate my 1gbs link. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" The only zfs tunable i use in my /boot/loader.conf is vfs.zfs.arc_max= I leave 4 GB for the system itself in most cases. In my smb.conf i use the following socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072 max protocol = SMB2 But if you set that then you can not use the aio settings as samba will crash then. if you use aio also make sure you load the aio module by setting the following in the /boot/loader.conf aio_load="YES" @Oliver I see you use one device for ZIL/log and L2ARC/cache. Be aware that you can lose the L2ARC/cache without data corruption, but losing the ZIL/log device might cause corrupted data. So always create a mirror for the ZIL/log device. gr Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:14:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5DBAD65; Fri, 4 Jan 2013 18:14:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 65CA6E4; Fri, 4 Jan 2013 18:14:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r04IEdxp083716; Fri, 4 Jan 2013 20:14:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r04IEdxp083716 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r04IEc4D083715; Fri, 4 Jan 2013 20:14:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2013 20:14:38 +0200 From: Konstantin Belousov To: Stefan Farfeleder Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130104181438.GL82219@kib.kiev.ua> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NhnzZsTWd+R/yp6D" Content-Disposition: inline In-Reply-To: <20130104154940.GD1430@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:14:42 -0000 --NhnzZsTWd+R/yp6D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote: > > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: > > >=20 > > > I have been playing with Stefan's testcase for a while now, and while= I > > > can reproduce the crashes, I am still at a loss about the cause. It > > > does seem to have something to do with throwing exceptions, but I am > > > still not sure whether I am looking at a bug in boost, gcc, clang, or > > > libgcc... > > >=20 > > > Do you happen to have a smaller testcase, by any chance? > >=20 > > Not yet, but I'll try to come up with something smaller. >=20 > Here's a minimal test case that reproduces the bug: >=20 > $ cat throw-crash.cc > #include >=20 > void f2(void) { > std::string s; > throw std::runtime_error("foo"); > } >=20 > void f1(void) { > f2(); > } >=20 > int main(void) { > try { > std::string s1, s2; > f1(); > return 0; > } catch (const std::exception &) { > return 1; > } > } > $ g++ -O2 -finline-limit=3D0 throw-crash.cc=20 > $ ./a.out=20 > zsh: bus error (core dumped) ./a.out What is the backtrace ? Compile the system libraries (ld-elf, libc, libgcc etc) with the debugging information and obtain the backtrace once more. --NhnzZsTWd+R/yp6D Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ5xwMAAoJEJDCuSvBvK1BixkQAKKlG6UuLrcLIDTYZobr5xVV TpDaRk9K2vVq6oeFbJ7NEMhxqFq70qIk0Pnr51VFCFSNKB5ezSKTxsBucKoxW511 ZNWlqghsfafluN7MRM8u+tzFgP69rMeYsYZ+T8703RksmftCn/IKp8uVYt1Qdnr2 5sZCIGE4/enfNvY1VPEHELKcMCtDZS5JVWdNsNaE8NcudZuXIOlE4Ich0GQQ0P/r VYrw2SnZQMbj5D39Z6z5lvDJ641P9jxhSjnP30MLKBguKRWBPly/MjH0/URyxnSY xFYuzQV4Zp8I7ua2AdDiqqJGxABc3pC3PncgQ8fsiKc0LCewrK52aZWzOKargPQ6 AJC/37eduYdh9BkFSs+TMN7FJ8bRplKgupp3lNlDaK4enH89pR6wgOqevhWJ5K8d n9h5tx5PTBGFZNuKIgbQC8enx3nCy3GttdkqqcoHS15Co7Xzzx2Hahs21e+aOePK cvawiEfZRItHjoLsK2ET1ypYvRMPHUHueDzEKixixASayMXgPK3NIc0OF+eiFgSn MgmWHXl7FfsTcw+5FvYn2vjLcZXJCjJ+unAIhcwWqdUE2zyf7pJltF84V447Dao1 K+1d352YHxFe/RwxBy3eAyddNYOLI4e0pElvxsTNbSLp6ys5u4yKsXCBg12jOl/y /hnxkFXJR6wcs6doe5Qt =+7na -----END PGP SIGNATURE----- --NhnzZsTWd+R/yp6D-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 18:28:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2EF58FFF for ; Fri, 4 Jan 2013 18:28:41 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by mx1.freebsd.org (Postfix) with ESMTP id BB03915D for ; Fri, 4 Jan 2013 18:28:40 +0000 (UTC) Received: from [78.35.174.75] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TrC0O-0002KS-RY for freebsd-current@freebsd.org; Fri, 04 Jan 2013 19:28:32 +0100 Date: Fri, 4 Jan 2013 19:28:16 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance Message-ID: <20130104192816.560f5bf6@fabiankeil.de> In-Reply-To: <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/YHk9yyAq5=oq4ZJM6O=gADJ"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:28:41 -0000 --Sig_/YHk9yyAq5=oq4ZJM6O=gADJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fleuriot Damien wrote: >=20 > On Jan 4, 2013, at 4:19 PM, O. Hartmann wro= te: >=20 > > Am 01/04/13 15:45, schrieb Garrett Cooper: > >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: > >>=20 > >> ... > >>=20 > >>> And this is under [global] in /usr/local/etc/smb.conf: > >>> min receivefile size =3D 16384 > >>> aio read size =3D 16384 > >>> aio write size =3D 16384 > >>> aio write behind =3D yes > >>=20 > >> These are still pretty low, depending on what your networking/disk > >> setup is like; my important performance settings are: > >>=20 > >> socket options =3D SO_RCVBUF=3D64240 SO_SNDBUF=3D64240 TCP_NODE= LAY > >> IPTOS_LOWDELAY IPTOS_THROUGHPUT > >> write cache size =3D 65536 > >> aio read size =3D 65536 > >> aio write size =3D 65536 > >> directory name cache size =3D 0 > > Well, now I have peak values ~ 120 MB/s when copying. I applied Fleuriot > > Damien's values to /boot/loader.conf and yours to the smb.conf. > > Somewhere in the handbook this should be documented! it is to much > > efford to get SAMBA working properly with ZFS, if the tricks and > > problems are so widespread over several architectural aspects of the sy= stem. > >=20 > > It could save a lot of time for adminsitartors and those which try > > FreeBSD as a serving system instead of Linux. > >=20 > > Just for the record. I feel a bit confused about all the tricks and > > tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem wizzardy > > thingis. The ZFS Wiki seems to be a bit outdated and confusing, it would > > be a great deal if all these things could be lined up a s a primer with > > a bit more explanations than "put this number there". > The problem, Oliver, is that these values are system dependant. While I agree that the values are system dependant the purpose of the tunables could still be documented together with a description of how to properly test that they have any effect at all and that it's an improvement compared to the defaults. Scarce ZFS tuning documentation is also a problem upstream which probably doesn't help. Fabian --Sig_/YHk9yyAq5=oq4ZJM6O=gADJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDnH04ACgkQBYqIVf93VJ1hgwCggdVXWRVaoZe0OM9MzxTjW5pW MhEAn0UzjXYE07C+3pzigW+dTO+i11Yv =fAK9 -----END PGP SIGNATURE----- --Sig_/YHk9yyAq5=oq4ZJM6O=gADJ-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 19:06:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20F7A568; Fri, 4 Jan 2013 19:06:06 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEAB268; Fri, 4 Jan 2013 19:06:04 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104190603.PSBO2598.viefep15-int.chello.at@edge04.upcmail.net>; Fri, 4 Jan 2013 20:06:03 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id jv621k0292xdvHc04v62yw; Fri, 04 Jan 2013 20:06:03 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 9CFD66D454; Fri, 4 Jan 2013 20:06:02 +0100 (CET) Date: Fri, 4 Jan 2013 20:06:02 +0100 From: Stefan Farfeleder To: Konstantin Belousov Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130104190602.GE1430@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130104181438.GL82219@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:06:06 -0000 On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote: > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > > Here's a minimal test case that reproduces the bug: > > > > $ cat throw-crash.cc > > #include > > > > void f2(void) { > > std::string s; > > throw std::runtime_error("foo"); > > } > > > > void f1(void) { > > f2(); > > } > > > > int main(void) { > > try { > > std::string s1, s2; > > f1(); > > return 0; > > } catch (const std::exception &) { > > return 1; > > } > > } > > $ g++ -O2 -finline-limit=0 throw-crash.cc > > $ ./a.out > > zsh: bus error (core dumped) ./a.out > > What is the backtrace ? > Compile the system libraries (ld-elf, libc, libgcc etc) with the > debugging information and obtain the backtrace once more. I'm afraid the backtrace is not really interesting: Program received signal SIGBUS, Bus error. std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) at atomicity.h:69 69 _Atomic_word __result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) at atomicity.h:69 #1 0x000000080089d168 in ~basic_string (this=0x7fffffffd62fe8) at basic_string.h:482 #2 0x0000000000401038 in main () at throw-crash.cc:16 I think the stack is somehow corrupted after the exception was performed. As with the original test case, loading an old libgcc_s.so.1 instead makes the program run correctly. It seems the std::string destructor is called with an invalid this pointer for s2: (gdb) r Starting program: /usr/home/stefan/scratch/a.out Breakpoint 1, main () at throw-crash.cc:12 12 int main(void) { (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4 (gdb) c Continuing. Breakpoint 2, 0x0000000800d420b4 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 (gdb) f 2 #2 0x0000000000400f51 in f2 () at throw-crash.cc:5 5 throw std::runtime_error("foo"); (gdb) p &s $1 = (string *) 0x7fffffffd600 (gdb) up #3 0x0000000000400fe2 in main () at throw-crash.cc:15 15 f1(); (gdb) p &s1 $2 = (string *) 0x7fffffffd650 (gdb) p &s2 $3 = (string *) 0x7fffffffd640 ^^^^ (gdb) b 'std::basic_string, std::allocator >::~basic_string()' Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd600) at basic_string.h:279 279 _M_data() const (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd640) at basic_string.h:279 279 _M_data() const (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd60f) at basic_string.h:279 ^^^^ 279 _M_data() const So, the address of s2 is 0x7fffffffd640, but the dtor is called with 0x7fffffffd60f which is also very unaligned. I think this is the reason for the crash. Stefan From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:23:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F54997F; Fri, 4 Jan 2013 20:23:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 95AD576F; Fri, 4 Jan 2013 20:23:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r04KNY6o032960; Fri, 4 Jan 2013 22:23:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua r04KNY6o032960 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r04KNYSg032959; Fri, 4 Jan 2013 22:23:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jan 2013 22:23:34 +0200 From: Konstantin Belousov To: Stefan Farfeleder Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130104202334.GN82219@kib.kiev.ua> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> <20130104190602.GE1430@mole.fafoe.narf.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jobRqqe4Hp8P9iE7" Content-Disposition: inline In-Reply-To: <20130104190602.GE1430@mole.fafoe.narf.at> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:23:42 -0000 --jobRqqe4Hp8P9iE7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote: > > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > > > Here's a minimal test case that reproduces the bug: > > >=20 > > > $ cat throw-crash.cc > > > #include > > >=20 > > > void f2(void) { > > > std::string s; > > > throw std::runtime_error("foo"); > > > } > > >=20 > > > void f1(void) { > > > f2(); > > > } > > >=20 > > > int main(void) { > > > try { > > > std::string s1, s2; > > > f1(); > > > return 0; > > > } catch (const std::exception &) { > > > return 1; > > > } > > > } > > > $ g++ -O2 -finline-limit=3D0 throw-crash.cc=20 > > > $ ./a.out=20 > > > zsh: bus error (core dumped) ./a.out > >=20 > > What is the backtrace ? > > Compile the system libraries (ld-elf, libc, libgcc etc) with the > > debugging information and obtain the backtrace once more. >=20 > I'm afraid the backtrace is not really interesting: >=20 > Program received signal SIGBUS, Bus error. > std::string::_Rep::_M_dispose (this=3D0x7fffffffd62fe8, __a=3D@0x7fffffff= d628) > at atomicity.h:69 > 69 _Atomic_word __result =3D *__mem; > (gdb) bt > #0 std::string::_Rep::_M_dispose (this=3D0x7fffffffd62fe8, __a=3D@0x7fff= ffffd628) > at atomicity.h:69 > #1 0x000000080089d168 in ~basic_string (this=3D0x7fffffffd62fe8) > at basic_string.h:482 > #2 0x0000000000401038 in main () at throw-crash.cc:16 >=20 > I think the stack is somehow corrupted after the exception was > performed. As with the original test case, loading an old libgcc_s.so.1 > instead makes the program run correctly. >=20 > It seems the std::string destructor is called with an invalid this > pointer for s2: >=20 > (gdb) r > Starting program: /usr/home/stefan/scratch/a.out=20 >=20 > Breakpoint 1, main () at throw-crash.cc:12 > 12 int main(void) { > (gdb) b _Unwind_RaiseException > Breakpoint 2 at 0x800d420b4 > (gdb) c > Continuing. >=20 > Breakpoint 2, 0x0000000800d420b4 in _Unwind_RaiseException () > from /lib/libgcc_s.so.1 > (gdb) f 2 > #2 0x0000000000400f51 in f2 () at throw-crash.cc:5 > 5 throw std::runtime_error("foo"); > (gdb) p &s > $1 =3D (string *) 0x7fffffffd600 > (gdb) up > #3 0x0000000000400fe2 in main () at throw-crash.cc:15 > 15 f1(); > (gdb) p &s1 > $2 =3D (string *) 0x7fffffffd650 > (gdb) p &s2 > $3 =3D (string *) 0x7fffffffd640 > ^^^^ > (gdb) b 'std::basic_string, std::allocator >::~basic_string()'=20 > Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. > (gdb) c > Continuing. >=20 > Breakpoint 3, ~basic_string (this=3D0x7fffffffd600) at basic_string.h:279 > 279 _M_data() const > (gdb) c > Continuing. >=20 > Breakpoint 3, ~basic_string (this=3D0x7fffffffd640) at basic_string.h:279 > 279 _M_data() const > (gdb) c > Continuing. >=20 > Breakpoint 3, ~basic_string (this=3D0x7fffffffd60f) at basic_string.h:279 > ^^^^ > 279 _M_data() const >=20 > So, the address of s2 is 0x7fffffffd640, but the dtor is called with > 0x7fffffffd60f which is also very unaligned. I think this is the reason > for the crash. Thank you for digging more. In fact, it is more likely that there is some bug or incompatibility in c++ unwinder than in the libgcc itself, but as you noted, a compiler bug is also possible. Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug also cannot be excluded at this stage, but it not much likely. --jobRqqe4Hp8P9iE7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ5zpFAAoJEJDCuSvBvK1BiXIQAI3dQYqz6mmhplx7gzcqBM+Z 0Z4+u0vgmgKCHfYrDxGEZokBJPEd0Io6jrQjriBRWMjuarEx6FctRcBEkTmUV/Re yfXWcAvnBlSfC3al8X+f3qmVuXFmG40dpTB8pkFJWCSoX3Z/UWWhpXvdqC8jajJz UNshhVn65cmuDYbfRc+D+aVu6BKoZ7jbP8ZTeKn6v3/wUyZfdHK7iZYmnscuRLiv 4tFGF5oo0yZyipaNk2ichSxbb1UTpyT/Tg/HY0LgYWy0DDn46Zce2VYiO1HEahdk rjqkwbOeaLnkjR9YBawa8kT+fMjHmu/xbbvrgTmqYuar8+caPY5U3xi4bTLKQVLy MCD/tX8G7Q3xZK9NvAqihQdIB1ZU6a5OxuqSoa2J9umFM6pXZlKyc1Y9Z9vL5B7A 2487YS8TOITNRsr8qNqWPHB5JZwwNh/khCEuwgxusTAGNxu5uwivOYudFP3ulAM0 L7dqF55waaTOMsjOxWxEwFwuqRW4u0nwquSulp/QiHgqOjt9lrZho4HLxOWuWS48 6+ZeMLqiyI3TuSJ8mVM+wEi7HDFiW7dKK/opjJp+jtv9ss3QbhS64xM7M23rHUKB gLgwcpSbOE7FtkbV7tP2LDDEuZyDdkfG7QJxJGpM/bKRYSUnOQw7+QbR7t/W/Nvu BIiujTvHg1xpnNRq/L/F =oLMM -----END PGP SIGNATURE----- --jobRqqe4Hp8P9iE7-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:33:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CBE53E79 for ; Fri, 4 Jan 2013 20:33:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8F07C3 for ; Fri, 4 Jan 2013 20:33:07 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id k1so15449785oag.30 for ; Fri, 04 Jan 2013 12:33:06 -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=g7n/CA4IzpgCjADXEGpp0gh01WGPNUxTIn6hHBZIvQk=; b=lziXFr0ukSBwIHh4GuxYwIIFPQzQyDpxKMkFQNIsym4lmNH7I+46HK5bjUmEYhfs0Y 1E43bfkmBZDYkkw9Md18kmRYeYZqyIksAsFa2v4EQHFQ6kT51T3WzBhkA+RvnLnlS3LX SQ0ijelVw0D0JJSfRGrBOjVBbVr/LZ7I51zRgBEtZ5cd3LXf+62vPj+U7kOAhEb81u+O RJZ4Lzr1A1bO4W7F7+MaOLpmaBObBg5/R50Sss/Kp9I50/mCLsyL5tTA/aRYuOWE5qRI qVae8EVzAgGlQnnverF7pv00XwnWvCHeesN3n0QKBvfFhtfSFylpaHVnRFP/NTE3xflI VDLQ== MIME-Version: 1.0 Received: by 10.182.146.107 with SMTP id tb11mr39824235obb.30.1357331586682; Fri, 04 Jan 2013 12:33:06 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 4 Jan 2013 12:33:06 -0800 (PST) In-Reply-To: <20130104192816.560f5bf6@fabiankeil.de> References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> <20130104192816.560f5bf6@fabiankeil.de> Date: Fri, 4 Jan 2013 12:33:06 -0800 Message-ID: Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Garrett Cooper To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:33:07 -0000 On Fri, Jan 4, 2013 at 10:28 AM, Fabian Keil wrote: ... > While I agree that the values are system dependant the purpose of > the tunables could still be documented together with a description > of how to properly test that they have any effect at all and that > it's an improvement compared to the defaults. > > Scarce ZFS tuning documentation is also a problem upstream which > probably doesn't help. The documentation is there (see the Evil ZFS Tuning Guide, etc), the problem is that our OS is Solaris so the directions do not directly apply. As for the Samba settings, there's already a document at samba.org that describes what needs to be done: http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/speed.html . My point is: the documentation is already there in both areas. One just has to read, tweak, and test. There isn't a magic formula or recipe for getting your box to go faster for all cases. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:33:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45FDFF8D for ; Fri, 4 Jan 2013 20:33:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mx1.freebsd.org (Postfix) with ESMTP id 14D617D4 for ; Fri, 4 Jan 2013 20:33:56 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id v19so15061717obq.28 for ; Fri, 04 Jan 2013 12:33:56 -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=BC9/iCSuVuVAWhjzbotu5ndEtRcbyV9W5YY362agn4c=; b=B8pxHY60sFn8WOR+HpGq1CVK7XfII8ePHUH+y+ZwmseofujvyX8BU/T7iiPFg/lcU4 dFIV7oX7Wrgq6LyZo1FBA5VXClnI/OJtxovtjNOwcMt8JbZ7zSkqUjgykq0zBVOjxzUB i0s0H/Dfg8rF7okxd3I5kI00ce/XzvQiM4kr1LUpMr70HFwDPRIx7QJ4l+OpVwVt41VO RDuXKKOhf7WgUT3p/fjaNi4b1UipQNVtPeKzzB5bFX9oux0bAg0+vVnSLwaDc7K03lab /4nNiq6fDH8N1FFbuiNsQhoj7E6Ae7cFz4oPYigSBlr0HbsbzLxtuEcOjRSnez79rPFH 1FcA== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr30609968oeg.17.1357331636266; Fri, 04 Jan 2013 12:33:56 -0800 (PST) Received: by 10.76.143.33 with HTTP; Fri, 4 Jan 2013 12:33:55 -0800 (PST) In-Reply-To: References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> <20130104192816.560f5bf6@fabiankeil.de> Date: Fri, 4 Jan 2013 12:33:55 -0800 Message-ID: Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance From: Garrett Cooper To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:33:57 -0000 On Fri, Jan 4, 2013 at 12:33 PM, Garrett Cooper wrote: ... > The documentation is there (see the Evil ZFS Tuning Guide, etc), the > problem is that our OS is Solaris so the directions do not directly > apply. Meant to say: ... is not Solaris... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:39:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A7252C3 for ; Fri, 4 Jan 2013 20:39:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 24207812 for ; Fri, 4 Jan 2013 20:39:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EABk951CDaFvO/2dsb2JhbABFhjm3KnOCHgEBBAEjVgUWDgoCAg0ZAlkGE4gOBqQ3j0KBIo5ggRMDiGGNKpBJgxKCCA X-IronPort-AV: E=Sophos;i="4.84,412,1355115600"; d="scan'208";a="7515925" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Jan 2013 15:39:15 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 144A0B3EE1; Fri, 4 Jan 2013 15:39:15 -0500 (EST) Date: Fri, 4 Jan 2013 15:39:15 -0500 (EST) From: Rick Macklem To: Fabian Keil Message-ID: <157811899.1684695.1357331955066.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130104192816.560f5bf6@fabiankeil.de> Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:39:17 -0000 Fabian Keil wrote: > Fleuriot Damien wrote: > > > > > On Jan 4, 2013, at 4:19 PM, O. Hartmann > > wrote: > > > > > Am 01/04/13 15:45, schrieb Garrett Cooper: > > >> On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien wrote: > > >> > > >> ... > > >> > > >>> And this is under [global] in /usr/local/etc/smb.conf: > > >>> min receivefile size = 16384 > > >>> aio read size = 16384 > > >>> aio write size = 16384 > > >>> aio write behind = yes > > >> > > >> These are still pretty low, depending on what your > > >> networking/disk > > >> setup is like; my important performance settings are: > > >> > > >> socket options = SO_RCVBUF=64240 SO_SNDBUF=64240 > > >> TCP_NODELAY > > >> IPTOS_LOWDELAY IPTOS_THROUGHPUT > > >> write cache size = 65536 > > >> aio read size = 65536 > > >> aio write size = 65536 > > >> directory name cache size = 0 > > > > Well, now I have peak values ~ 120 MB/s when copying. I applied > > > Fleuriot > > > Damien's values to /boot/loader.conf and yours to the smb.conf. > > > Somewhere in the handbook this should be documented! it is to much > > > efford to get SAMBA working properly with ZFS, if the tricks and > > > problems are so widespread over several architectural aspects of > > > the system. > > > > > > It could save a lot of time for adminsitartors and those which try > > > FreeBSD as a serving system instead of Linux. > > > > > > Just for the record. I feel a bit confused about all the tricks > > > and > > > tweak now "published" for ZFS, its magic L2ARC, the kernel_vmem > > > wizzardy > > > thingis. The ZFS Wiki seems to be a bit outdated and confusing, it > > > would > > > be a great deal if all these things could be lined up a s a primer > > > with > > > a bit more explanations than "put this number there". > > > The problem, Oliver, is that these values are system dependant. > > While I agree that the values are system dependant the purpose of > the tunables could still be documented together with a description > of how to properly test that they have any effect at all and that > it's an improvement compared to the defaults. > What about capturing a few examples, like this one for a system with 16Gb of Ram. Basically cases of: - this is my hardware config and here's what works well for me It's pretty easy for people to choose the example closest to their setup as a starting point. Then urls to where the docs are, so people can read/fine tune from there? rick rick > Scarce ZFS tuning documentation is also a problem upstream which > probably doesn't help. > > Fabian From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 20:53:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 889E87DC for ; Fri, 4 Jan 2013 20:53:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 460CD8A4 for ; Fri, 4 Jan 2013 20:53:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TrEGx-0001Jl-SL for freebsd-current@freebsd.org; Fri, 04 Jan 2013 21:53:47 +0100 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2013 21:53:47 +0100 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Jan 2013 21:53:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: clang 3.2 RC2 miscompiles libgcc? Date: Fri, 04 Jan 2013 12:53:18 -0800 Lines: 137 Message-ID: References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> <20130104190602.GE1430@mole.fafoe.narf.at> <20130104202334.GN82219@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <20130104202334.GN82219@kib.kiev.ua> X-Enigmail-Version: 1.4.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:53:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/2013 12:23, Konstantin Belousov wrote: > On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote: >> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov >> wrote: >>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder >>> wrote: >>>> Here's a minimal test case that reproduces the bug: >>>> >>>> $ cat throw-crash.cc #include >>>> >>>> void f2(void) { std::string s; throw >>>> std::runtime_error("foo"); } >>>> >>>> void f1(void) { f2(); } >>>> >>>> int main(void) { try { std::string s1, s2; f1(); return 0; } >>>> catch (const std::exception &) { return 1; } } $ g++ -O2 >>>> -finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error >>>> (core dumped) ./a.out >>> >>> What is the backtrace ? Compile the system libraries (ld-elf, >>> libc, libgcc etc) with the debugging information and obtain the >>> backtrace once more. >> >> I'm afraid the backtrace is not really interesting: >> >> Program received signal SIGBUS, Bus error. >> std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, >> __a=@0x7fffffffd628) at atomicity.h:69 69 _Atomic_word >> __result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose >> (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) at atomicity.h:69 #1 >> 0x000000080089d168 in ~basic_string (this=0x7fffffffd62fe8) at >> basic_string.h:482 #2 0x0000000000401038 in main () at >> throw-crash.cc:16 >> >> I think the stack is somehow corrupted after the exception was >> performed. As with the original test case, loading an old >> libgcc_s.so.1 instead makes the program run correctly. >> >> It seems the std::string destructor is called with an invalid >> this pointer for s2: >> >> (gdb) r Starting program: /usr/home/stefan/scratch/a.out >> >> Breakpoint 1, main () at throw-crash.cc:12 12 int main(void) >> { (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4 >> (gdb) c Continuing. >> >> Breakpoint 2, 0x0000000800d420b4 in _Unwind_RaiseException () >> from /lib/libgcc_s.so.1 (gdb) f 2 #2 0x0000000000400f51 in f2 () >> at throw-crash.cc:5 5 throw std::runtime_error("foo"); >> (gdb) p &s $1 = (string *) 0x7fffffffd600 (gdb) up #3 >> 0x0000000000400fe2 in main () at throw-crash.cc:15 15 >> f1(); (gdb) p &s1 $2 = (string *) 0x7fffffffd650 (gdb) p &s2 $3 = >> (string *) 0x7fffffffd640 ^^^^ (gdb) b 'std::basic_string> std::char_traits, std::allocator >::~basic_string()' >> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. >> (gdb) c Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd600) at >> basic_string.h:279 279 _M_data() const (gdb) c >> Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd640) at >> basic_string.h:279 279 _M_data() const (gdb) c >> Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd60f) at >> basic_string.h:279 ^^^^ 279 _M_data() const >> >> So, the address of s2 is 0x7fffffffd640, but the dtor is called >> with 0x7fffffffd60f which is also very unaligned. I think this is >> the reason for the crash. > > Thank you for digging more. > > In fact, it is more likely that there is some bug or > incompatibility in c++ unwinder than in the libgcc itself, but as > you noted, a compiler bug is also possible. > > Anyway, I was mostly looking could the backtrace starts in rtld. > Rtld bug also cannot be excluded at this stage, but it not much > likely. > Since this is similar to the pain I was seeing rebuilding everything with clang so I have been following this thread with much interest. Just to add more data, I get different results. This is all i386. gcc v464 built using an earlier clang from -current world/kernel r243027. boost was also built using this revision. $ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib - -lboost_program_options -o unwinder unwinder.cc [atkinson@moby ~/dev]$ ldd unwinder unwinder: libboost_program_options.so => /usr/local/lib/libboost_program_options.so (0x2806e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c2000) libm.so.5 => /lib/libm.so.5 (0x281a1000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c2000) libc.so.7 => /lib/libc.so.7 (0x281cd000) libthr.so.3 => /lib/libthr.so.3 (0x28317000) [atkinson@moby ~/dev]$ ./unwinder Abort trap (core dumped) clang 32 built from -current world/kernel r244958 works just fine. $ c++ -O2 -I/usr/local/include -L/usr/local/lib - -lboost_program_options -o unwinder unwinder.cc [atkinson@moby ~/dev]$ ./unwinder [atkinson@moby ~/dev]$ ldd unwinder unwinder: libboost_program_options.so => /usr/local/lib/libboost_program_options.so (0x2806d000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c1000) libm.so.5 => /lib/libm.so.5 (0x281a0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c1000) libc.so.7 => /lib/libc.so.7 (0x281cc000) libthr.so.3 => /lib/libthr.so.3 (0x28316000) It might be useful to expand -O2 into all it's -f components and elminate them one by one until the crash is not reproducable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDnQT4ACgkQrDN5kXnx8yZpZgCfXhiKtV1b4H/zu/M0KZvSE/Yi y5MAnRTejLBvCqCgSP9FTKhGOZpDiQBQ =8PU9 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 01:00:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68771768; Sat, 5 Jan 2013 01:00:23 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4194A15A; Sat, 5 Jan 2013 01:00:20 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG400C00O4CV800@smtpauth2.wiscmail.wisc.edu>; Fri, 04 Jan 2013 19:00:12 -0600 (CST) Received: from wanderer.tachypleus.net (dhcp107-17-54-205.hil-sfofhhh.sfo.wayport.net [107.17.54.205]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG400C5VO4AGJ00@smtpauth2.wiscmail.wisc.edu>; Fri, 04 Jan 2013 19:00:12 -0600 (CST) Date: Fri, 04 Jan 2013 20:00:10 -0500 From: Nathan Whitehorn Subject: Re: clang 3.2 RC2 miscompiles libgcc? In-reply-to: <20130104202334.GN82219@kib.kiev.ua> Sender: whitehorn@wisc.edu To: Konstantin Belousov Message-id: <50E77B1A.9080401@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=107.17.54.205 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.5.4831, SenderIP=107.17.54.205 References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> <20130104190602.GE1430@mole.fafoe.narf.at> <20130104202334.GN82219@kib.kiev.ua> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: Stefan Farfeleder , Dimitry Andric , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 01:00:23 -0000 On 01/04/13 15:23, Konstantin Belousov wrote: > On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote: >> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote: >>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>>> Here's a minimal test case that reproduces the bug: >>>> >>>> $ cat throw-crash.cc >>>> #include >>>> >>>> void f2(void) { >>>> std::string s; >>>> throw std::runtime_error("foo"); >>>> } >>>> >>>> void f1(void) { >>>> f2(); >>>> } >>>> >>>> int main(void) { >>>> try { >>>> std::string s1, s2; >>>> f1(); >>>> return 0; >>>> } catch (const std::exception &) { >>>> return 1; >>>> } >>>> } >>>> $ g++ -O2 -finline-limit=0 throw-crash.cc >>>> $ ./a.out >>>> zsh: bus error (core dumped) ./a.out >>> >>> What is the backtrace ? >>> Compile the system libraries (ld-elf, libc, libgcc etc) with the >>> debugging information and obtain the backtrace once more. >> >> I'm afraid the backtrace is not really interesting: >> >> Program received signal SIGBUS, Bus error. >> std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) >> at atomicity.h:69 >> 69 _Atomic_word __result = *__mem; >> (gdb) bt >> #0 std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) >> at atomicity.h:69 >> #1 0x000000080089d168 in ~basic_string (this=0x7fffffffd62fe8) >> at basic_string.h:482 >> #2 0x0000000000401038 in main () at throw-crash.cc:16 >> >> I think the stack is somehow corrupted after the exception was >> performed. As with the original test case, loading an old libgcc_s.so.1 >> instead makes the program run correctly. >> >> It seems the std::string destructor is called with an invalid this >> pointer for s2: >> >> (gdb) r >> Starting program: /usr/home/stefan/scratch/a.out >> >> Breakpoint 1, main () at throw-crash.cc:12 >> 12 int main(void) { >> (gdb) b _Unwind_RaiseException >> Breakpoint 2 at 0x800d420b4 >> (gdb) c >> Continuing. >> >> Breakpoint 2, 0x0000000800d420b4 in _Unwind_RaiseException () >> from /lib/libgcc_s.so.1 >> (gdb) f 2 >> #2 0x0000000000400f51 in f2 () at throw-crash.cc:5 >> 5 throw std::runtime_error("foo"); >> (gdb) p &s >> $1 = (string *) 0x7fffffffd600 >> (gdb) up >> #3 0x0000000000400fe2 in main () at throw-crash.cc:15 >> 15 f1(); >> (gdb) p &s1 >> $2 = (string *) 0x7fffffffd650 >> (gdb) p &s2 >> $3 = (string *) 0x7fffffffd640 >> ^^^^ >> (gdb) b 'std::basic_string, std::allocator >::~basic_string()' >> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. >> (gdb) c >> Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd600) at basic_string.h:279 >> 279 _M_data() const >> (gdb) c >> Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd640) at basic_string.h:279 >> 279 _M_data() const >> (gdb) c >> Continuing. >> >> Breakpoint 3, ~basic_string (this=0x7fffffffd60f) at basic_string.h:279 >> ^^^^ >> 279 _M_data() const >> >> So, the address of s2 is 0x7fffffffd640, but the dtor is called with >> 0x7fffffffd60f which is also very unaligned. I think this is the reason >> for the crash. > > Thank you for digging more. > > In fact, it is more likely that there is some bug or incompatibility in > c++ unwinder than in the libgcc itself, but as you noted, a compiler bug > is also possible. > > Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug > also cannot be excluded at this stage, but it not much likely. > If this is the same bug I was seeing, recompiling only the file unwind-dw2.c in libgcc with GCC/old clang, leaving everything else the same, fixed everything. This would lead me to suspect an error in one of the many __builtins called by unwind-dw2.c. -Nathan From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 04:37:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D7501 for ; Sat, 5 Jan 2013 04:37:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx1.freebsd.org (Postfix) with ESMTP id 51837909 for ; Sat, 5 Jan 2013 04:37:27 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n5so15786138oag.3 for ; Fri, 04 Jan 2013 20:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=35KopL00bTqQHfmARuus0trZMhaPSqiC9gtZdf5lcjI=; b=KRmBW4fFLupeKBkVRfoZQU0wD0/Nx4IC86VXGVifxwLDfOwpvR6zf+HeLZuxjHbwfO 3dYLVJBuwcIHQlW7gOWSqb8srLJPcGVjerw53mM74McRhxClSJMC4LaivgBKs2bEWZyd AZ4t7TVh9tcoOiso99Lg5X8478A4hZKFmazDYv5OoXFtnPJPYgZ8TL28Ai4IkrYf3e+9 0dPzaAmIqfKIgDH5lqwrp8gK/qUZw0rmnzqdzuIvUMy1OAjOLuLlnIzLu2MYjakNp3ZR nH1rVuW8O27iGmkOPn21YsmL6NJ/rlNJ/c0tOrTL+6uV5yKH2U8wTdiQYFHDOjr7Tnci Q6zQ== MIME-Version: 1.0 Received: by 10.60.172.6 with SMTP id ay6mr30348504oec.10.1357360646373; Fri, 04 Jan 2013 20:37:26 -0800 (PST) Received: by 10.182.160.99 with HTTP; Fri, 4 Jan 2013 20:37:26 -0800 (PST) Date: Fri, 4 Jan 2013 23:37:26 -0500 Message-ID: Subject: Problems in /usr/src From: Super Bisquit To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 04:37:27 -0000 In sys/modules/svr4 needs machine/_align.h to read X86/include/_align.h, if that means anything. In sys/modules/ath_ahb: cc1: warnings being treated as errors In file included from /usr/src/sys/modules/ath_ahb/../../dev/ath/if_ath_ahb.c:61: @/mips/atheros/ar71xxreg.h: In function 'ar71xx_ddr_flush': @/mips/atheros/ar71xxreg.h:497: warning: implicit declaration of function 'MIPS_PHYS_TO_KSEG1' @/mips/atheros/ar71xxreg.h:497: warning: nested extern declaration of 'MIPS_PHYS_TO_KSEG1' [-Wnested-externs] *** Error code 1 Stop in /usr/src/sys/modules/ath_ahb. peoples# In sys/modules/ath:fdiagnostics-show-option -c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3534: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3536: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3538: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3540: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3542: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3544: error: 'struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3732: error: 'struct ath_rx_status' has no member named 'rs_isaggr' *** Error code 1 Stop in /usr/src/sys/modules/ath. peoples# Now sys/modules/ath_pci will build. When running make world or make buildworld there is an error at gnu/lib/libgcc. peoples# uname -a FreeBSD peoples 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 peoples# From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 05:03:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52CC3739 for ; Sat, 5 Jan 2013 05:03:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by mx1.freebsd.org (Postfix) with ESMTP id DD5EA98F for ; Sat, 5 Jan 2013 05:03:30 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id 15so8216913wgd.16 for ; Fri, 04 Jan 2013 21:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3PAQV5wVkUa+h8D7gzIgcCVPnZtW3IUIcjmqMUarll8=; b=ixEIt2O+8Oni8NihMQHZWmvwGN3cFzZnya7hBnfFO847BRiT72UII8ELVGt4JpTlp3 chYNuqT1hQOHF9/4bSOMoPYzYXcBMOe3f0D8REq83L+BI+jX4o/DczopW+c0+mgvErQO psAv7r7RJyixkUJ2NQbuazfZixJoL/3jgMlXZkq/Dvg1pOw68wAqyJnhsSzHDXnRuycc 0mbyNPr9lr+aAugXw+bOiqAxqwXluc97cFH5TQDlmsNhxK6Q1gdArKXmAexJCFx5T0n/ t1GWA+WZKkz/CcmWtrUn8Zid14Pjjrxc4PIrfKewtXa2OQrufcq5gVhIZcwbywc8WPXr 7E0A== MIME-Version: 1.0 X-Received: by 10.180.33.44 with SMTP id o12mr821609wii.28.1357362204431; Fri, 04 Jan 2013 21:03:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 4 Jan 2013 21:03:24 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Jan 2013 21:03:24 -0800 X-Google-Sender-Auth: 4paqoBKEMHN1dFXC_wYdi2ERJzo Message-ID: Subject: Re: Problems in /usr/src From: Adrian Chadd To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 05:03:31 -0000 ... ath_ahb is only needed for MIPS platforms. Why are you building it for x86? Also, do you have the 5416 support option in your kernel? adrian On 4 January 2013 20:37, Super Bisquit wrote: > In sys/modules/svr4 needs machine/_align.h to read > X86/include/_align.h, if that means anything. > > In sys/modules/ath_ahb: cc1: warnings being treated as errors > In file included from > /usr/src/sys/modules/ath_ahb/../../dev/ath/if_ath_ahb.c:61: > @/mips/atheros/ar71xxreg.h: In function 'ar71xx_ddr_flush': > @/mips/atheros/ar71xxreg.h:497: warning: implicit declaration of > function 'MIPS_PHYS_TO_KSEG1' > @/mips/atheros/ar71xxreg.h:497: warning: nested extern declaration of > 'MIPS_PHYS_TO_KSEG1' [-Wnested-externs] > *** Error code 1 > > Stop in /usr/src/sys/modules/ath_ahb. > peoples# > > > In sys/modules/ath:fdiagnostics-show-option -c > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3534: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3536: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3538: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3540: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3542: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3544: error: 'struct > ath_rx_status' has no member named 'rs_flags' > /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3732: error: 'struct > ath_rx_status' has no member named 'rs_isaggr' > *** Error code 1 > > Stop in /usr/src/sys/modules/ath. > peoples# > Now sys/modules/ath_pci will build. > > When running make world or make buildworld there is an error at > gnu/lib/libgcc. > > peoples# uname -a > FreeBSD peoples 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 > 07:15:25 UTC 2012 > root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > peoples# > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 05:54:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FF59BA9; Sat, 5 Jan 2013 05:54:00 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id E8818A91; Sat, 5 Jan 2013 05:53:59 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id ta14so15511524obb.33 for ; Fri, 04 Jan 2013 21:53:59 -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=ErOudmo3Oq/PAEA78GoZth97zRTyzWdb+1RPweceBx0=; b=HnTgfFMA6AvXHD/5kJdh8L9faHgOE0/jpxcLpEUqAUKZLQQ4badVRnK2vDoniYFGl2 dmy0NgdfbTRySGgM+DlnGMtoeO7FyZ7FtJsIaj1yaQRVxO0PmYyFDD50YFhqNwPA1HF+ wvQGYXGsu+Yk04adCWif6lnNZxyxXub0NGGD9B25HWeEbh7rnxDdPAYB+u9c2umzhn6D 2gopOoJtO4oVg3fZS1bSoVHMbp30gkvOn0hYyQBZ8RwjJRQEpJTUq74xaOCfsVE9dRDh VdA8/NYJVNLdc6IMRyDC0fz2ePT7Pk+3s9nhw6x4sGaFETyigLUvpmhJPJ+qjkonbyfA D/rw== MIME-Version: 1.0 Received: by 10.60.32.69 with SMTP id g5mr31693658oei.21.1357365239043; Fri, 04 Jan 2013 21:53:59 -0800 (PST) Received: by 10.182.160.99 with HTTP; Fri, 4 Jan 2013 21:53:59 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Jan 2013 00:53:59 -0500 Message-ID: Subject: Re: Problems in /usr/src From: Super Bisquit To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 05:54:00 -0000 I did not know that ath_ahb was MIPS only. Why? I wanted the most/best performance for my system's wireless. Support for 5416 is there but the card is a 2413. On Sat, Jan 5, 2013 at 12:03 AM, Adrian Chadd wrote: > ... ath_ahb is only needed for MIPS platforms. Why are you building it for x86? > > Also, do you have the 5416 support option in your kernel? > > > > adrian > > On 4 January 2013 20:37, Super Bisquit wrote: >> In sys/modules/svr4 needs machine/_align.h to read >> X86/include/_align.h, if that means anything. >> >> In sys/modules/ath_ahb: cc1: warnings being treated as errors >> In file included from >> /usr/src/sys/modules/ath_ahb/../../dev/ath/if_ath_ahb.c:61: >> @/mips/atheros/ar71xxreg.h: In function 'ar71xx_ddr_flush': >> @/mips/atheros/ar71xxreg.h:497: warning: implicit declaration of >> function 'MIPS_PHYS_TO_KSEG1' >> @/mips/atheros/ar71xxreg.h:497: warning: nested extern declaration of >> 'MIPS_PHYS_TO_KSEG1' [-Wnested-externs] >> *** Error code 1 >> >> Stop in /usr/src/sys/modules/ath_ahb. >> peoples# >> >> >> In sys/modules/ath:fdiagnostics-show-option -c >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_rx_proc': >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3534: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3536: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3538: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3540: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3542: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3544: error: 'struct >> ath_rx_status' has no member named 'rs_flags' >> /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:3732: error: 'struct >> ath_rx_status' has no member named 'rs_isaggr' >> *** Error code 1 >> >> Stop in /usr/src/sys/modules/ath. >> peoples# >> Now sys/modules/ath_pci will build. >> >> When running make world or make buildworld there is an error at >> gnu/lib/libgcc. >> >> peoples# uname -a >> FreeBSD peoples 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 >> 07:15:25 UTC 2012 >> root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> peoples# >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 10:08:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51AAC778 for ; Sat, 5 Jan 2013 10:08:36 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.freebsd.org (Postfix) with ESMTP id 143827C8 for ; Sat, 5 Jan 2013 10:08:35 +0000 (UTC) Received: from [78.35.191.97] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TrQdF-000791-OY for freebsd-current@freebsd.org; Sat, 05 Jan 2013 11:05:37 +0100 Date: Sat, 5 Jan 2013 11:05:30 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance Message-ID: <20130105110530.10009e62@fabiankeil.de> In-Reply-To: References: <50E6DE91.7010404@zedat.fu-berlin.de> <1ADC2ECB-70FF-4DDD-9D62-16E2EEECDD8B@my.gd> <50E6F2FC.3060903@zedat.fu-berlin.de> <23BF8538-FB5A-4432-A4E1-721B5F566CA2@my.gd> <20130104192816.560f5bf6@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/wsa3U4I8kNfCI+TIQbizGVu"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 10:08:36 -0000 --Sig_/wsa3U4I8kNfCI+TIQbizGVu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Garrett Cooper wrote: > On Fri, Jan 4, 2013 at 10:28 AM, Fabian Keil > wrote: > > While I agree that the values are system dependant the purpose of > > the tunables could still be documented together with a description > > of how to properly test that they have any effect at all and that > > it's an improvement compared to the defaults. > > > > Scarce ZFS tuning documentation is also a problem upstream which > > probably doesn't help. >=20 > The documentation is there (see the Evil ZFS Tuning Guide, etc), the > problem is that our OS is Solaris so the directions do not directly > apply. I was actually referring to the "Evil ZFS Tuning Guide" which, while helpful, doesn't come close to completely documenting the tunables that exist and in my opinion also doesn't really address the testing issue. Obviously I don't expect anyone else to benchmark my own systems for me, but more information about the expected effects would allow me to test more efficiently. The fact that it targets Solaris and that the directions don't apply directly never bothered me so far and I think the existing parts are pretty good in general. Fabian --Sig_/wsa3U4I8kNfCI+TIQbizGVu Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDn+u0ACgkQBYqIVf93VJ1tPwCfXopk/0AX/nir6CmKYMeAe+RU MNUAn17DjDXLf2DnQcvJkI/+RQl8skAr =3mY6 -----END PGP SIGNATURE----- --Sig_/wsa3U4I8kNfCI+TIQbizGVu-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 16:40:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F10F7988; Sat, 5 Jan 2013 16:40:48 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id DD9FF389; Sat, 5 Jan 2013 16:40:47 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130105164040.ZFCJ26940.viefep19-int.chello.at@edge03.upcmail.net>; Sat, 5 Jan 2013 17:40:40 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge03.upcmail.net with edge id kGgf1k00p2xdvHc03GgfiG; Sat, 05 Jan 2013 17:40:40 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 96EB06D454; Sat, 5 Jan 2013 17:40:39 +0100 (CET) Date: Sat, 5 Jan 2013 17:40:39 +0100 From: Stefan Farfeleder To: Konstantin Belousov Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130105164034.GA1436@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> <20130104190602.GE1430@mole.fafoe.narf.at> <20130104202334.GN82219@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130104202334.GN82219@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 16:40:49 -0000 On Fri, Jan 04, 2013 at 10:23:34PM +0200, Konstantin Belousov wrote: > > Thank you for digging more. > > In fact, it is more likely that there is some bug or incompatibility in > c++ unwinder than in the libgcc itself, but as you noted, a compiler bug > is also possible. > > Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug > also cannot be excluded at this stage, but it not much likely. FWIW, the diff between working and non-working assembler can be found at http://people.freebsd.org/~stefanf/tmp/libgcc_s.s.diff . Not that I expect much from that. Stefan From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 18:35:31 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB37C8E8 for ; Sat, 5 Jan 2013 18:35:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id C1211C39 for ; Sat, 5 Jan 2013 18:35:31 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r05IZPqJ028428 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 5 Jan 2013 18:35:27 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: ZFS/RAIDZ and SAMBA: abyssimal performance Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <157811899.1684695.1357331955066.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 5 Jan 2013 18:35:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE7D306-86B8-40D7-9F0C-2964D6D5BB04@FreeBSD.org> References: <157811899.1684695.1357331955066.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 18:35:32 -0000 On 4 Jan 2013, at 20:39, Rick Macklem wrote: > What about capturing a few examples, like this one for a system with > 16Gb of Ram. Basically cases of: > - this is my hardware config and here's what works well for me > It's pretty easy for people to choose the example closest to their > setup as a starting point. This would be very helpful. One of the longer-term goals for the = storage stack is to make all of these things self-tuning, and some = well-tested data points showing system configuration, workload, and = performance would be a good starting point for this. David=