From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 01:18:58 2012 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 08406106564A for ; Sun, 29 Jul 2012 01:18:58 +0000 (UTC) (envelope-from tim@kientzle.com) 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 D6BE08FC14 for ; Sun, 29 Jul 2012 01:18:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q6T1IuDh031572; Sun, 29 Jul 2012 01:18:56 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id shcnpdanwk5it53gnya4hasrbs; Sun, 29 Jul 2012 01:18:56 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <50141F96.5070808@zedat.fu-berlin.de> Date: Sat, 28 Jul 2012 18:18:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50141F96.5070808@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1278) Cc: "freeb >> Current FreeBSD" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 01:18:58 -0000 On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: > When updating ports (like databases/sqlite3 or graphics/png via = portmaster graphics/png), the installation process comes to a point = where a backup of the old port is created with bsdtar. The process hangs = then =85 > My operating system is > FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 That's newer than my -CURRENT system here; I'm updating now. Martin imported a few changes from upstream just recently, so this is likely a new problem. > What to do? Can you get the full command line for the command that's hanging? $ ps auxww | grep tar Knowing the exact options that were used will help narrow it down. Thanks for reporting it, Tim From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 01:39:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D674D1065670 for ; Sun, 29 Jul 2012 01:39:07 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED338FC1B for ; Sun, 29 Jul 2012 01:39:07 +0000 (UTC) Received: by weyx56 with SMTP id x56so3422934wey.13 for ; Sat, 28 Jul 2012 18:39:06 -0700 (PDT) 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=kSiC6sIQis5tWFhVaIqGRNaDiRUv9e2G+J5tr8U6Z18=; b=D6BaybSedBu7W7rJ9FeshZO70sgngFafC+xlWbQDJw3q7WWDpmmN2lbSiMdDUrSBOx dw5nDZ4dixBOy5OBHHxjr70VmIAnbGdCkD5VwTUWltHJc11do/yPqB+4rUv3BBKORKyZ 1cHMFomcRbuF/EK5kXHc59KW3IjHAQ9L9gOocuViFY6B1sMh5RNvL6+Zg5TanwevU7EN e/EuF1lHFMAoVVqzu97wx7yqBazyeussLSPG+XRJcxTKBcdl+w54kc1t01xl57uiQhcb z54ijQVLxDQvnlydhg9pdG0SeAzjXVp5ExNkPOlpZry+QSyi3GZg6btDNquS0tyT2p+i 4l3Q== MIME-Version: 1.0 Received: by 10.180.84.169 with SMTP id a9mr16566497wiz.8.1343525946148; Sat, 28 Jul 2012 18:39:06 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sat, 28 Jul 2012 18:39:06 -0700 (PDT) In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> Date: Sat, 28 Jul 2012 21:39:06 -0400 Message-ID: From: Arnaud Lacombe To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 01:39:07 -0000 Hi, On Sat, Jul 28, 2012 at 7:46 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 28, 2012 at 6:44 PM, Bjoern A. Zeeb > wrote: >> Which again leaves me with the question - why does libc have it? >> > as for the semantic, theoretical, "why", I would refer you to the > POSIX's comity, as inet_ntop() is part of it. > actually, it is slightly more complicated than that. POSIX has inet_ntoa(), inet_ntop() and no inet_ntoa_r(). libc's inet_ntoa{,_r}() are implemented on top inet_ntop(), which *does* fail if the provided buffer is not large enough, and set errno to ENOSPC. However, inet_ntoa{,_r}() do not propagate inet_ntop() failure. As for the userland version of inet_ntoa{,_r}(), I would change it to at least stop ignoring inet_ntop() return value, add an assertion on its success, drop this awful `strcpy(ret, "[inet_ntoa error]");' and use the proper size in inet_ntoa() definition. As for the kernel version... it is a lost cause to argue one way or another... - Arnaud From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 01:59:50 2012 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 91DE3106564A; Sun, 29 Jul 2012 01:59:50 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 549F38FC0A; Sun, 29 Jul 2012 01:59:50 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 58) id 870C81C6454; Sun, 29 Jul 2012 09:53:51 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.hs.ntnu.edu.tw X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 Received: from mail.hs.ntnu.edu.tw (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hs.ntnu.edu.tw (Postfix) with ESMTPS id 23D5D1C643F; Sun, 29 Jul 2012 09:53:51 +0800 (CST) Received: (from dennylin93@localhost) by mail.hs.ntnu.edu.tw (8.14.5/8.14.5/Submit) id q6T1roJo021847; Sun, 29 Jul 2012 09:53:50 +0800 (CST) (envelope-from dennylin93@hs.ntnu.edu.tw) X-Authentication-Warning: mail.hs.ntnu.edu.tw: dennylin93 set sender to dennylin93@hs.ntnu.edu.tw using -f Date: Sun, 29 Jul 2012 09:53:50 +0800 From: Denny Lin To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Message-ID: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 01:59:50 -0000 Hi, I updated to r238858 yesterday, but I was unable to load i915kms (I tried loading it manually and putting it in /boot/loader.conf). The computer becomes unresponsive and the screen turns black in either case. I'm using the GENERIC kernel with WITNESS and INVARIANTS disabled. Output of pciconf -lvb: vgapci1@pci0:0:2:0: class=0x030000 card=0x15f21043 chip=0x01168086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xdd400000, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xb0000000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xe000, size 64, enabled Modules loaded at boot: Id Refs Address Size Name 1 38 0xffffffff80200000 12c57f0 kernel 2 1 0xffffffff814c6000 70a8 acpi_video.ko 3 1 0xffffffff814ce000 6568 cuse4bsd.ko 4 1 0xffffffff81612000 cea0 geom_eli.ko 5 1 0xffffffff8161f000 1abc1 crypto.ko 6 1 0xffffffff8163a000 a4f9 zlib.ko 7 1 0xffffffff81645000 15e2 fdescfs.ko 8 1 0xffffffff81647000 3daf linprocfs.ko 9 1 0xffffffff8164b000 1eeb2 linux.ko 10 1 0xffffffff8166a000 2393 ums.ko 11 1 0xffffffff8166d000 17d3 uhid.ko 12 1 0xffffffff8166f000 a9f3 fuse.ko 13 1 0xffffffff8167a000 7019 i915.ko 14 1 0xffffffff81682000 111c4 drm.ko I have WITH_KMS=YES and WITH_NEW_XORG=YES in /etc/make.conf. I also rebuilt xorg-* and xf86-video-intel after updating to r238858. Xorg previously worked on my laptop with all.14.3.patch on top of -CURRENT from around mid-April, so I'm not sure what went wrong. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 02:08:00 2012 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 38E22106564A; Sun, 29 Jul 2012 02:08:00 +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 07E0C8FC14; Sun, 29 Jul 2012 02:07:59 +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 q6T27xrZ017379; Sat, 28 Jul 2012 22:07:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6T27xqe017378; Sun, 29 Jul 2012 02:07:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 29 Jul 2012 02:07:59 GMT Message-Id: <201207290207.q6T27xqe017378@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 02:08:00 -0000 TB --- 2012-07-29 00:59:25 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-29 00:59:25 - 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 --- 2012-07-29 00:59:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-29 00:59:25 - cleaning the object tree TB --- 2012-07-29 00:59:25 - cvsupping the source tree TB --- 2012-07-29 00:59:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-29 01:00:34 - building world TB --- 2012-07-29 01:00:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 01:00:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 01:00:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 01:00:34 - SRCCONF=/dev/null TB --- 2012-07-29 01:00:34 - TARGET=sparc64 TB --- 2012-07-29 01:00:34 - TARGET_ARCH=sparc64 TB --- 2012-07-29 01:00:34 - TZ=UTC TB --- 2012-07-29 01:00:34 - __MAKE_CONF=/dev/null TB --- 2012-07-29 01:00:34 - cd /src TB --- 2012-07-29 01:00:34 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 29 01:00:35 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 29 02:01:59 UTC 2012 TB --- 2012-07-29 02:01:59 - generating LINT kernel config TB --- 2012-07-29 02:01:59 - cd /src/sys/sparc64/conf TB --- 2012-07-29 02:01:59 - /usr/bin/make -B LINT TB --- 2012-07-29 02:01:59 - cd /src/sys/sparc64/conf TB --- 2012-07-29 02:01:59 - /usr/sbin/config -m LINT TB --- 2012-07-29 02:01:59 - building LINT kernel TB --- 2012-07-29 02:01:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 02:01:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 02:01:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 02:01:59 - SRCCONF=/dev/null TB --- 2012-07-29 02:01:59 - TARGET=sparc64 TB --- 2012-07-29 02:01:59 - TARGET_ARCH=sparc64 TB --- 2012-07-29 02:01:59 - TZ=UTC TB --- 2012-07-29 02:01:59 - __MAKE_CONF=/dev/null TB --- 2012-07-29 02:01:59 - cd /src TB --- 2012-07-29 02:01:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 29 02:01:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_library.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_sbus.c /src/sys/dev/isp/isp_sbus.c: In function 'dma2': /src/sys/dev/isp/isp_sbus.c:603: error: too few arguments to function 'isp_send_cmd' *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-29 02:07:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-29 02:07:59 - ERROR: failed to build LINT kernel TB --- 2012-07-29 02:07:59 - 3271.40 user 585.58 system 4113.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 03:57:38 2012 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 9AC63106566B; Sun, 29 Jul 2012 03:57:38 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 3326C8FC08; Sun, 29 Jul 2012 03:57:37 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6T3vMYB025053; Sat, 28 Jul 2012 21:57:31 -0600 Date: Sun, 29 Jul 2012 10:59:54 +0700 From: Erich Dollansky To: Denny Lin Message-ID: <20120729105954.7de47bbf@AMD620.ovitrap.com> In-Reply-To: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 03:57:38 -0000 Hi, On Sun, 29 Jul 2012 09:53:50 +0800 Denny Lin wrote: >=20 > I updated to r238858 yesterday, but I was unable to load i915kms (I > tried loading it manually and putting it in /boot/loader.conf). The > computer becomes unresponsive and the screen turns black in either > case. I'm using the GENERIC kernel with WITNESS and INVARIANTS > disabled. >=20 > Output of pciconf -lvb: > vgapci1@pci0:0:2:0: class=3D0x030000 card=3D0x15f21043 > chip=3D0x01168086 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' > device =3D '2nd Generation Core Processor Family Integrated > Graphics Controller' class =3D display > subclass =3D VGA > bar [10] =3D type Memory, range 64, base 0xdd400000, size > 4194304, enabled bar [18] =3D type Prefetchable Memory, range 64, > base 0xb0000000, size 268435456, enabled bar [20] =3D type I/O Port, > range 32, base 0xe000, size 64, enabled >=20 > Modules loaded at boot: > Id Refs Address Size Name > 1 38 0xffffffff80200000 12c57f0 kernel > 2 1 0xffffffff814c6000 70a8 acpi_video.ko > 3 1 0xffffffff814ce000 6568 cuse4bsd.ko > 4 1 0xffffffff81612000 cea0 geom_eli.ko > 5 1 0xffffffff8161f000 1abc1 crypto.ko > 6 1 0xffffffff8163a000 a4f9 zlib.ko > 7 1 0xffffffff81645000 15e2 fdescfs.ko > 8 1 0xffffffff81647000 3daf linprocfs.ko > 9 1 0xffffffff8164b000 1eeb2 linux.ko > 10 1 0xffffffff8166a000 2393 ums.ko > 11 1 0xffffffff8166d000 17d3 uhid.ko > 12 1 0xffffffff8166f000 a9f3 fuse.ko this seems to be wrong: > 13 1 0xffffffff8167a000 7019 i915.ko > 14 1 0xffffffff81682000 111c4 drm.ko >=20 =46rom my machine: 2 1 0xffffffff817e4000 aee0 sem.ko 3 1 0xffffffff81a12000 9db3 linprocfs.ko 4 1 0xffffffff81a1c000 587a5 linux.ko 5 1 0xffffffff81a75000 3900 ums.ko 6 1 0xffffffff81a79000 2b0d uhid.ko 7 1 0xffffffff81a7c000 1b7a1 ng_btsocket.ko 8 1 0xffffffff81a98000 ba58 netgraph.ko 9 1 0xffffffff81aa4000 118b ng_bluetooth.ko 10 1 0xffffffff81aa6000 a9f3 fuse.ko 11 1 0xffffffff81ab1000 69298 i915kms.ko 12 1 0xffffffff81b1b000 1ba2 iicbb.ko 13 4 0xffffffff81b1d000 1ddb iicbus.ko 14 1 0xffffffff81b1f000 1cd5 iic.ko 15 1 0xffffffff81b21000 32386 drm2.ko 16 1 0xffffffff81b54000 241 acpi_call.ko So, why did drm.ko and i915.ko make it into your kernel? > I have WITH_KMS=3DYES and WITH_NEW_XORG=3DYES in /etc/make.conf. I also > rebuilt xorg-* and xf86-video-intel after updating to r238858. >=20 > Xorg previously worked on my laptop with all.14.3.patch on top of > -CURRENT from around mid-April, so I'm not sure what went wrong. >=20 I did not touch this machine since 16.07.12. Maybe your patches affected something. Can you download a fresh source tree? Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 04:20:19 2012 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 237EC106566B; Sun, 29 Jul 2012 04:20:19 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id D74D28FC0A; Sun, 29 Jul 2012 04:20:18 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 58) id EFF751C6455; Sun, 29 Jul 2012 12:20:16 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.hs.ntnu.edu.tw X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from mail.hs.ntnu.edu.tw (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hs.ntnu.edu.tw (Postfix) with ESMTPS id 59D5C1C644B; Sun, 29 Jul 2012 12:20:16 +0800 (CST) Received: (from dennylin93@localhost) by mail.hs.ntnu.edu.tw (8.14.5/8.14.5/Submit) id q6T4KD9X023035; Sun, 29 Jul 2012 12:20:13 +0800 (CST) (envelope-from dennylin93@hs.ntnu.edu.tw) X-Authentication-Warning: mail.hs.ntnu.edu.tw: dennylin93 set sender to dennylin93@hs.ntnu.edu.tw using -f Date: Sun, 29 Jul 2012 12:20:13 +0800 From: Denny Lin To: Erich Dollansky Message-ID: <20120729042013.GA22960@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120729105954.7de47bbf@AMD620.ovitrap.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 04:20:19 -0000 On Sun, Jul 29, 2012 at 10:59:54AM +0700, Erich Dollansky wrote: > this seems to be wrong: > > > 13 1 0xffffffff8167a000 7019 i915.ko > > 14 1 0xffffffff81682000 111c4 drm.ko > > > From my machine: > > 2 1 0xffffffff817e4000 aee0 sem.ko > 3 1 0xffffffff81a12000 9db3 linprocfs.ko > 4 1 0xffffffff81a1c000 587a5 linux.ko > 5 1 0xffffffff81a75000 3900 ums.ko > 6 1 0xffffffff81a79000 2b0d uhid.ko > 7 1 0xffffffff81a7c000 1b7a1 ng_btsocket.ko > 8 1 0xffffffff81a98000 ba58 netgraph.ko > 9 1 0xffffffff81aa4000 118b ng_bluetooth.ko > 10 1 0xffffffff81aa6000 a9f3 fuse.ko > 11 1 0xffffffff81ab1000 69298 i915kms.ko > 12 1 0xffffffff81b1b000 1ba2 iicbb.ko > 13 4 0xffffffff81b1d000 1ddb iicbus.ko > 14 1 0xffffffff81b1f000 1cd5 iic.ko > 15 1 0xffffffff81b21000 32386 drm2.ko > 16 1 0xffffffff81b54000 241 acpi_call.ko > > So, why did drm.ko and i915.ko make it into your kernel? Both are built by default, but only drm.ko and i915.ko are loaded automatically. i915kms.ko has to loaded manually: http://lists.freebsd.org/pipermail/freebsd-x11/2012-May/011857.html I do have i915kms and drm2.ko, but every time I try to load i915kms.ko, the computer blacks out. > > I have WITH_KMS=YES and WITH_NEW_XORG=YES in /etc/make.conf. I also > > rebuilt xorg-* and xf86-video-intel after updating to r238858. > > > > Xorg previously worked on my laptop with all.14.3.patch on top of > > -CURRENT from around mid-April, so I'm not sure what went wrong. > > > I did not touch this machine since 16.07.12. > > Maybe your patches affected something. Can you download a fresh source > tree? I used a new checkout when I updated to r238858, so this shouldn't be a problem. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 04:49:19 2012 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 EC1CF106566C; Sun, 29 Jul 2012 04:49:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6858FC0A; Sun, 29 Jul 2012 04:49:19 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so629852wib.13 for ; Sat, 28 Jul 2012 21:49:18 -0700 (PDT) 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=TvjVR1Ke9GmyQvEbvsCUSz9x8X1CGSl0NjQjosW8+mQ=; b=Jt3R+1JzNycSBH+IUh+idaH/S43j66J9bYYikxEf120GWM29Ddh4F2Bq14Nh+doblR xNXZcX0ghteRWtFlFbXg42JTtATDyIlTTgniPoFHFUwGged3gihCK+GTGTC8dgHexc+9 1RDBw9Wz9fnB1nBGS9lCH42TUiAhgtPJUztYRegtpvJLi/AMlSy6vIhGuQoHpUq7pXNr ed8phi1/cYywEatQmnPJL/GfmMVn9YTAXZ+PLhol07M6tr+TRgKsiLwkXZrxnwX/21Ff Dm1XB8+klXq7YANoEdB/fEs0XFjzPdjTj55KcZIB+FH00ifgAgWAn24yPbW6jhyankV9 HKfA== MIME-Version: 1.0 Received: by 10.180.84.1 with SMTP id u1mr17188946wiy.15.1343537358135; Sat, 28 Jul 2012 21:49:18 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Sat, 28 Jul 2012 21:49:18 -0700 (PDT) In-Reply-To: <20120729042013.GA22960@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> <20120729042013.GA22960@mail.hs.ntnu.edu.tw> Date: Sat, 28 Jul 2012 21:49:18 -0700 Message-ID: From: Kevin Oberman To: Denny Lin Content-Type: text/plain; charset=UTF-8 Cc: Erich Dollansky , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 04:49:20 -0000 On Sat, Jul 28, 2012 at 9:20 PM, Denny Lin wrote: > On Sun, Jul 29, 2012 at 10:59:54AM +0700, Erich Dollansky wrote: >> this seems to be wrong: >> >> > 13 1 0xffffffff8167a000 7019 i915.ko >> > 14 1 0xffffffff81682000 111c4 drm.ko >> > >> From my machine: >> >> 2 1 0xffffffff817e4000 aee0 sem.ko >> 3 1 0xffffffff81a12000 9db3 linprocfs.ko >> 4 1 0xffffffff81a1c000 587a5 linux.ko >> 5 1 0xffffffff81a75000 3900 ums.ko >> 6 1 0xffffffff81a79000 2b0d uhid.ko >> 7 1 0xffffffff81a7c000 1b7a1 ng_btsocket.ko >> 8 1 0xffffffff81a98000 ba58 netgraph.ko >> 9 1 0xffffffff81aa4000 118b ng_bluetooth.ko >> 10 1 0xffffffff81aa6000 a9f3 fuse.ko >> 11 1 0xffffffff81ab1000 69298 i915kms.ko >> 12 1 0xffffffff81b1b000 1ba2 iicbb.ko >> 13 4 0xffffffff81b1d000 1ddb iicbus.ko >> 14 1 0xffffffff81b1f000 1cd5 iic.ko >> 15 1 0xffffffff81b21000 32386 drm2.ko >> 16 1 0xffffffff81b54000 241 acpi_call.ko >> >> So, why did drm.ko and i915.ko make it into your kernel? > > Both are built by default, but only drm.ko and i915.ko are loaded > automatically. i915kms.ko has to loaded manually: > http://lists.freebsd.org/pipermail/freebsd-x11/2012-May/011857.html > > I do have i915kms and drm2.ko, but every time I try to load i915kms.ko, > the computer blacks out. > >> > I have WITH_KMS=YES and WITH_NEW_XORG=YES in /etc/make.conf. I also >> > rebuilt xorg-* and xf86-video-intel after updating to r238858. >> > >> > Xorg previously worked on my laptop with all.14.3.patch on top of >> > -CURRENT from around mid-April, so I'm not sure what went wrong. >> > >> I did not touch this machine since 16.07.12. >> >> Maybe your patches affected something. Can you download a fresh source >> tree? > > I used a new checkout when I updated to r238858, so this shouldn't be > a problem. You are working too hard from old information. Do not attempt to load i915kms.ko. Do not attempt to load drm2.ko. For the past months the drivers have been fixed to automatically load all needed drivers and kernel modules when Xorg is started. My Sandybridge behaves just like your system if I try to manually load i915kms.ko. Screen goes black and that is the end. Oh, and you didn't mention libdrm. It should be built with WITH_KMS, too. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 04:56:39 2012 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 D3CFA106566B; Sun, 29 Jul 2012 04:56:39 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id A0BA98FC17; Sun, 29 Jul 2012 04:56:39 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6T4uU7T002821; Sat, 28 Jul 2012 22:56:35 -0600 Date: Sun, 29 Jul 2012 11:59:02 +0700 From: Erich Dollansky To: Denny Lin Message-ID: <20120729115902.6013885f@AMD620.ovitrap.com> In-Reply-To: <20120729042013.GA22960@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> <20120729042013.GA22960@mail.hs.ntnu.edu.tw> X-Mailer: Claws Mail 3.8.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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 04:56:39 -0000 Hi, On Sun, 29 Jul 2012 12:20:13 +0800 Denny Lin wrote: > On Sun, Jul 29, 2012 at 10:59:54AM +0700, Erich Dollansky wrote: > > this seems to be wrong: > > > > > 13 1 0xffffffff8167a000 7019 i915.ko > > > 14 1 0xffffffff81682000 111c4 drm.ko > > > > > From my machine: > > > > 2 1 0xffffffff817e4000 aee0 sem.ko > > 3 1 0xffffffff81a12000 9db3 linprocfs.ko > > 4 1 0xffffffff81a1c000 587a5 linux.ko > > 5 1 0xffffffff81a75000 3900 ums.ko > > 6 1 0xffffffff81a79000 2b0d uhid.ko > > 7 1 0xffffffff81a7c000 1b7a1 ng_btsocket.ko > > 8 1 0xffffffff81a98000 ba58 netgraph.ko > > 9 1 0xffffffff81aa4000 118b ng_bluetooth.ko > > 10 1 0xffffffff81aa6000 a9f3 fuse.ko > > 11 1 0xffffffff81ab1000 69298 i915kms.ko > > 12 1 0xffffffff81b1b000 1ba2 iicbb.ko > > 13 4 0xffffffff81b1d000 1ddb iicbus.ko > > 14 1 0xffffffff81b1f000 1cd5 iic.ko > > 15 1 0xffffffff81b21000 32386 drm2.ko > > 16 1 0xffffffff81b54000 241 acpi_call.ko > > > > So, why did drm.ko and i915.ko make it into your kernel? > > Both are built by default, but only drm.ko and i915.ko are loaded > automatically. i915kms.ko has to loaded manually: > http://lists.freebsd.org/pipermail/freebsd-x11/2012-May/011857.html > ok, try to use my script: http://www.alogreentechnologies.com/freebsd/XonX220 I do not know what this script will do when drm and i915 are already loaded. > I do have i915kms and drm2.ko, but every time I try to load > i915kms.ko, the computer blacks out. The black screen is normal if you do not start X. > > > > I have WITH_KMS=YES and WITH_NEW_XORG=YES in /etc/make.conf. I > > > also rebuilt xorg-* and xf86-video-intel after updating to > > > r238858. > > > > > > Xorg previously worked on my laptop with all.14.3.patch on top of > > > -CURRENT from around mid-April, so I'm not sure what went wrong. > > > > > I did not touch this machine since 16.07.12. > > > > Maybe your patches affected something. Can you download a fresh > > source tree? > > I used a new checkout when I updated to r238858, so this shouldn't be > a problem. > It could be that the two loaded modules cause the problem. Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 05:00:43 2012 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 CDB14106564A for ; Sun, 29 Jul 2012 05:00:43 +0000 (UTC) (envelope-from dave-lists-freebsd-current@weller-fahy.com) Received: from tigger.weller-fahy.com (sinecure.xen.prgmr.com [71.19.148.52]) by mx1.freebsd.org (Postfix) with ESMTP id B15038FC0A for ; Sun, 29 Jul 2012 05:00:43 +0000 (UTC) Received: (qmail 28762 invoked from network); 28 Jul 2012 21:56:02 -0700 Received: from unknown (HELO weller-fahy.com) (dave@weller-fahy.com@24.209.97.39) by tigger.weller-fahy.com with AES256-SHA encrypted SMTP; 28 Jul 2012 21:56:02 -0700 Date: Sun, 29 Jul 2012 00:53:55 -0400 From: "David J. Weller-Fahy" To: freebsd-current@freebsd.org Message-ID: <20120729045354.GA1054@weller-fahy.com> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.21+66 (70810a88ce9f) (2011-07-01) Subject: Panic on boot after svn update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 05:00:43 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So, I recently updated and encountered a panic on boot which is reproducible, and wanted to see if anyone's encountered this before I file a PR. I found a problem in (I think) recent changes to the e1000 driver. I'm running FreeBSD 10-CURRENT as a VirtualBox guest. #v+ FreeBSD fork-pooh 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238764: Sat Jul 28 = 17:21:47 EDT 2012 root@fork-pooh:/usr/obj/usr/src/sys/GENERIC amd64 #v- I have the Adapter Type set to, "Intel PRO/1000 MT Desktop (82540EM)", and = the following card is detected by pciconf. #v+ dave@fork-pooh:~$ sudo pciconf -l -bcev =2E.. em0@pci0:0:3:0: class=3D0x020000 card=3D0x001e8086 chip=3D0x100e8086 rev=3D= 0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82540EM Gigabit Ethernet Controller' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xf0000000, size 131072, ena= bled bar [18] =3D type I/O Port, range 32, base 0xd010, size 8, enabled cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X supports 2048 burst read, 1 split transaction =2E.. #v- With revision 238764 the system boots and connects to the network with no problem. However, if I update to 238770 (as for why 238770, last revision which touched if_lem.c [1])... [1]: http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_lem.c?view=3Dlog #v+ dave@fork-pooh:/usr/src$ sudo svn up -r 238770 Password: Updating '.': U sys/netinet/ip_carp.c U sys/dev/e1000/if_lem.c U sys/dev/usb/serial/uplcom.c U sys/dev/usb/usbdevs Updated to revision 238770. dave@fork-pooh:/usr/src$ cd /usr/obj/ dave@fork-pooh:/usr/obj$ sudo chflags -R noschg * dave@fork-pooh:/usr/obj$ sudo rm -rf * dave@fork-pooh:/usr/obj$ cd /usr/src/ dave@fork-pooh:/usr/src$ sudo make buildkernel dave@fork-pooh:/usr/src$ make installkernel dave@fork-pooh:/usr/src$ sudo shutdown -r now =2E.. #v- Upon reboot, I see... #v+ =2E.. Updating motd:. Starting ntpd. panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 cpuid =3D 0 KDB: enter: panic [ thread pid 12 tid 100025 ] Stopped at kdb_enter+0x3b: movq $0,0x9c4752(%rip) #v- After changing the Network Adapter (in VirtualBox) to "PCnet-PCI II (Am79C970A)" the system boots up correctly (on the same revision), and the network is functional. What other information would be useful in figuring out what's wrong? Regards, --=20 dave [ please don't CC me ] --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQFMHizahokXOb2UwRAphAAKCkJZfiOM3hRDNct+xqeJ0kj5T5igCcD1fa Tz+QMCvX6ziwyHfW5OyfTUA= =QXwO -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 05:09:44 2012 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 45146106566B; Sun, 29 Jul 2012 05:09:44 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id E1C448FC19; Sun, 29 Jul 2012 05:09:43 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6T59TQb005336; Sat, 28 Jul 2012 23:09:35 -0600 Date: Sun, 29 Jul 2012 12:12:01 +0700 From: Erich Dollansky To: Kevin Oberman Message-ID: <20120729121201.5ca6db2e@AMD620.ovitrap.com> In-Reply-To: References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> <20120729042013.GA22960@mail.hs.ntnu.edu.tw> X-Mailer: Claws Mail 3.8.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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 05:09:44 -0000 Hi, On Sat, 28 Jul 2012 21:49:18 -0700 Kevin Oberman wrote: > You are working too hard from old information. Do not attempt to load > i915kms.ko. Do not attempt to load drm2.ko. For the past months the > drivers have been fixed to automatically load all needed drivers and > kernel modules when Xorg is started. My Sandybridge behaves just like How do the wrong modules get loaded? > your system if I try to manually load i915kms.ko. Screen goes black > and that is the end. It still works for me. You know, never change a winning team. There seem to be small differences between the CPU/GPUs. Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 05:15:12 2012 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 A1A3B106566B for ; Sun, 29 Jul 2012 05:15:12 +0000 (UTC) (envelope-from grog@lemis.com) Received: from w3.lemis.com (w3.lemis.com [208.86.224.149]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC208FC0A for ; Sun, 29 Jul 2012 05:15:12 +0000 (UTC) Received: from eureka.lemis.com (1032.x.rootbsd.net [208.86.224.149]) by w3.lemis.com (Postfix) with ESMTP id 242333B77A for ; Sun, 29 Jul 2012 05:15:11 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id C102AF74EC; Sun, 29 Jul 2012 15:15:09 +1000 (EST) Date: Sun, 29 Jul 2012 15:15:09 +1000 From: Greg 'groggy' Lehey To: freebsd-current@freebsd.org Message-ID: <20120729051509.GA40138@eureka.lemis.com> References: <20120729045354.GA1054@weller-fahy.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20120729045354.GA1054@weller-fahy.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Re: Panic on boot after svn update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 05:15:12 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 29 July 2012 at 0:53:55 -0400, David J. Weller-Fahy wrote: > So, I recently updated and encountered a panic on boot which is > reproducible, and wanted to see if anyone's encountered this before I > file a PR. I found a problem in (I think) recent changes to the e1000 > driver. I'm running FreeBSD 10-CURRENT as a VirtualBox guest. > > #v+ > FreeBSD fork-pooh 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238764: Sat Jul 28 17:21:47 EDT 2012 root@fork-pooh:/usr/obj/usr/src/sys/GENERIC amd64 > #v- > > I have the Adapter Type set to, "Intel PRO/1000 MT Desktop (82540EM)", and the > following card is detected by pciconf. > ... > Updating motd:. > Starting ntpd. > panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 Me too The panic message is identical, and I'm also running in VirtualBox. My version string (from strings on the kernel) is: FreeBSD 10.0-CURRENT #4: Sat Jul 28 09:45:10 EST 2012 root@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC Note that this is a different EST (UTC+10). I have a dump, but I can't get much sense out of it: kgdb: kvm_read: invalid address (0x354540a) #0 0x00000000 in ?? () I'm currently rebuilding the system, but it looks as if that won't help much. One interesting point is that the first panic happened after installing the new image (from yesterday's sources) while I was trying to reboot with the old kernel, dating back to FreeBSD swamp.lemis.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3: Sun May 13 14:34:43 EST 2012 root@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC i386 Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAUxtwACgkQIubykFB6QiOY+gCfQLo/x9d2FjbYQWnyKMXH+s/1 YJsAniMb5VZj6iXzOQmlHuxA5COPXov5 =PE4n -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 06:29:58 2012 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 56ADC106564A; Sun, 29 Jul 2012 06:29:58 +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 C86F08FC0A; Sun, 29 Jul 2012 06:29:57 +0000 (UTC) Received: by obbun3 with SMTP id un3so8957224obb.13 for ; Sat, 28 Jul 2012 23:29:57 -0700 (PDT) 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=w+WTNCV58Z/V5Neq+ACEFPN4J9M8DFVhswsP63nAziA=; b=ogsrMzIxeLJ4e0NCLhd+cTd60u9aH+sEtv76o3jO2SXGZaOvOsDRJ0RhebCuLDS/Q/ wInK2lpeXRyGaE1KXAAO753qT+ExglRoYlbMqnidey/tqVPapWkr+MPVpl+c/+4FyX6D ximGUU3J67PQtJ5R0iDnJ0iYNHTIJKnlDGN+rvBkX2QwI9iWIpggDJYKH2KVPY2uKFPG opeRjNREJS/seXVee7KOZNmXYf64FVY5glPC1OkhwUHEjwT8cB1A0HhvTgPOHAYPZ1qc CP1RYHvxgGCV+i79a8RVQESwPA5adJZ1TYsvJnRN8Li6hBbYhrbfIM6pVVH6K94rV1g9 iqwA== MIME-Version: 1.0 Received: by 10.60.29.230 with SMTP id n6mr11229725oeh.22.1343543397123; Sat, 28 Jul 2012 23:29:57 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 28 Jul 2012 23:29:57 -0700 (PDT) In-Reply-To: <20120729051509.GA40138@eureka.lemis.com> References: <20120729045354.GA1054@weller-fahy.com> <20120729051509.GA40138@eureka.lemis.com> Date: Sat, 28 Jul 2012 23:29:57 -0700 Message-ID: From: Garrett Cooper To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Panic on boot after svn update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 06:29:58 -0000 On Sat, Jul 28, 2012 at 10:15 PM, Greg 'groggy' Lehey wrote: > On Sunday, 29 July 2012 at 0:53:55 -0400, David J. Weller-Fahy wrote: >> So, I recently updated and encountered a panic on boot which is >> reproducible, and wanted to see if anyone's encountered this before I >> file a PR. I found a problem in (I think) recent changes to the e1000 >> driver. I'm running FreeBSD 10-CURRENT as a VirtualBox guest. >> >> #v+ >> FreeBSD fork-pooh 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238764: Sat Jul 28 17:21:47 EDT 2012 root@fork-pooh:/usr/obj/usr/src/sys/GENERIC amd64 >> #v- >> >> I have the Adapter Type set to, "Intel PRO/1000 MT Desktop (82540EM)", and the >> following card is detected by pciconf. >> ... >> Updating motd:. >> Starting ntpd. >> panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 > > Me too The panic message is identical, and I'm also running > in VirtualBox. My version string (from strings on the kernel) is: > > FreeBSD 10.0-CURRENT #4: Sat Jul 28 09:45:10 EST 2012 > root@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC > > Note that this is a different EST (UTC+10). > > I have a dump, but I can't get much sense out of it: > > kgdb: kvm_read: invalid address (0x354540a) > #0 0x00000000 in ?? () > > I'm currently rebuilding the system, but it looks as if that won't > help much. One interesting point is that the first panic happened > after installing the new image (from yesterday's sources) while I was > trying to reboot with the old kernel, dating back to > > FreeBSD swamp.lemis.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3: Sun May 13 14:34:43 EST 2012 root@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC i386 See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035593.html . -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 06:30:14 2012 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 F1B8510656E7 for ; Sun, 29 Jul 2012 06:30:13 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9AD8FC12 for ; Sun, 29 Jul 2012 06:30:13 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 6F528390CA; Sun, 29 Jul 2012 08:30:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id fUFV39zCghag; Sun, 29 Jul 2012 08:30:10 +0200 (CEST) Received: from [10.0.0.28] (unknown [213.81.198.162]) by mail.vx.sk (Postfix) with ESMTPSA id 935EE390C3; Sun, 29 Jul 2012 08:30:10 +0200 (CEST) Message-ID: <5014D873.5090406@FreeBSD.org> Date: Sun, 29 Jul 2012 08:30:11 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Tim Kientzle References: <50141F96.5070808@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 06:30:15 -0000 I am also looking into it: 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) 2. It happens only if archiving files located on ZFS (UFS works fine) 3. Backtrace: #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, archive_entry_acl_type=256) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474 #1 0x0000000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100, entry=0x801d69100, fd=6, st=Variable "st" is not available. ) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434 #2 0x000000080087831e in _archive_read_next_header2 (_a=0x801c45100, entry=0x801d69100) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_posix.c:1070 #3 0x00000000004078d5 in write_hierarchy (bsdtar=0x7fffffffd940, a=0x801c17140, path=Variable "path" is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:825 #4 0x0000000000407d51 in write_archive (a=0x801c17140, bsdtar=0x7fffffffd940) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:471 #5 0x0000000000404fbd in main (argc=4, argv=Variable "argv" is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/bsdtar.c:668 This infinite loop has been fixed in libarchive master: https://github.com/libarchive/libarchive/commit/d8b9dbd d8b9dbd6dac0125957b997c2fe8d246237ec9f94 I suggest you backport to release also the following: f67370d5c33b336b103c43fe35984defe7e0e473 https://github.com/libarchive/libarchive/commit/f67370d c6d3cd33aecdc579966c3fbe7b9424cea83c7555 https://github.com/libarchive/libarchive/commit/c6d3cd3 Dňa 29. 7. 2012 3:18 Tim Kientzle wrote / napísal(a): > > On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: > >> When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then … > >> My operating system is >> FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 > > That's newer than my -CURRENT system here; I'm updating now. > Martin imported a few changes from upstream just recently, so this > is likely a new problem. > >> What to do? > > Can you get the full command line for the command that's > hanging? > > $ ps auxww | grep tar > > Knowing the exact options that were used will help narrow > it down. > > Thanks for reporting it, > > Tim > > _______________________________________________ > 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 Sun Jul 29 07:21:39 2012 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 E2452106566B; Sun, 29 Jul 2012 07:21:39 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2A42C8FC08; Sun, 29 Jul 2012 07:21:39 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 58) id 091D21C6451; Sun, 29 Jul 2012 15:21:38 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.hs.ntnu.edu.tw X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from mail.hs.ntnu.edu.tw (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hs.ntnu.edu.tw (Postfix) with ESMTPS id 832451C643F; Sun, 29 Jul 2012 15:21:37 +0800 (CST) Received: (from dennylin93@localhost) by mail.hs.ntnu.edu.tw (8.14.5/8.14.5/Submit) id q6T7LaD8025070; Sun, 29 Jul 2012 15:21:36 +0800 (CST) (envelope-from dennylin93@hs.ntnu.edu.tw) X-Authentication-Warning: mail.hs.ntnu.edu.tw: dennylin93 set sender to dennylin93@hs.ntnu.edu.tw using -f Date: Sun, 29 Jul 2012 15:21:36 +0800 From: Denny Lin To: Erich Dollansky Message-ID: <20120729072136.GA23082@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> <20120729042013.GA22960@mail.hs.ntnu.edu.tw> <20120729121201.5ca6db2e@AMD620.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120729121201.5ca6db2e@AMD620.ovitrap.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 07:21:40 -0000 Hi, On Sun, Jul 29, 2012 at 12:12:01PM +0700, Erich Dollansky wrote: > On Sat, 28 Jul 2012 21:49:18 -0700 > Kevin Oberman wrote: > > > You are working too hard from old information. Do not attempt to load > > i915kms.ko. Do not attempt to load drm2.ko. For the past months the > > drivers have been fixed to automatically load all needed drivers and > > kernel modules when Xorg is started. My Sandybridge behaves just like > > How do the wrong modules get loaded? Thanks for all the help guys. The problem was the result of my own stupidity. I went through some code trying to find out why the wrong modules were loaded, and I discovered that I previously commented out this line in x11-drivers/xf86-video-intel/Makefile: EXTRA_PATCHES+= ${PATCHDIR}/extra-i915kms This patch is for -CURRENT since the name of the module changed when kib@ imported the code to -CURRENT: - intel->drmSubFD = drmOpen("i915", busid); + intel->drmSubFD = drmOpen("i915kms", busid); Since I built -CURRENT from around 3 months ago and an up-to-date ports tree, I had to remove this patch to make it work. So it fell apart when I tried to upgrade to the lastest -CURRENT... Apparently portsnap doesn't overwrite local modifications to the ports tree unless there are updates (unlike csup), so the patch wasn't included until I discovered my mistake. Next time I'll keep a list of local changes for my ports tree, so I don't shoot myself in the foot again. Sorry for the noise. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 08:21:03 2012 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 A0E39106564A; Sun, 29 Jul 2012 08:21:03 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD928FC12; Sun, 29 Jul 2012 08:21:03 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6T8Kq0Y006763; Sun, 29 Jul 2012 02:20:57 -0600 Date: Sun, 29 Jul 2012 15:23:24 +0700 From: Erich Dollansky To: Denny Lin Message-ID: <20120729152324.5896ca0b@AMD620.ovitrap.com> In-Reply-To: <20120729072136.GA23082@mail.hs.ntnu.edu.tw> References: <20120729015350.GH72464@mail.hs.ntnu.edu.tw> <20120729105954.7de47bbf@AMD620.ovitrap.com> <20120729042013.GA22960@mail.hs.ntnu.edu.tw> <20120729121201.5ca6db2e@AMD620.ovitrap.com> <20120729072136.GA23082@mail.hs.ntnu.edu.tw> X-Mailer: Claws Mail 3.8.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-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unable to load i915kms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 08:21:03 -0000 Hi, On Sun, 29 Jul 2012 15:21:36 +0800 Denny Lin wrote: > > How do the wrong modules get loaded? > > Thanks for all the help guys. The problem was the result of my own > stupidity. > > I went through some code trying to find out why the wrong modules were > loaded, and I discovered that I previously commented out this line in > x11-drivers/xf86-video-intel/Makefile: > EXTRA_PATCHES+= ${PATCHDIR}/extra-i915kms so, wrong name --> wrong modules. This simple. Erich From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 09:18:07 2012 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 2F7D3106566C; Sun, 29 Jul 2012 09:18:07 +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 DAF898FC14; Sun, 29 Jul 2012 09:18:06 +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 <1SvPdP-0004ZZ-Bm>; Sun, 29 Jul 2012 11:17:59 +0200 Received: from e178031138.adsl.alicedsl.de ([85.178.31.138] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SvPdP-00064w-7d>; Sun, 29 Jul 2012 11:17:59 +0200 Message-ID: <5014FFC6.9000307@zedat.fu-berlin.de> Date: Sun, 29 Jul 2012 11:17:58 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Matuska References: <50141F96.5070808@zedat.fu-berlin.de> <5014D873.5090406@FreeBSD.org> In-Reply-To: <5014D873.5090406@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.31.138 Cc: freebsd-current@freebsd.org Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 09:18:07 -0000 On 07/29/12 08:30, Martin Matuska wrote: > I am also looking into it: > > 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) > 2. It happens only if archiving files located on ZFS (UFS works fine) It happens in my case also on UFS2 filesystem (SU+J). My ports are residing on an UFS partition - but ZFS is also available on the system ... > 3. Backtrace: > #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, > archive_entry_acl_type=256) > at > /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474 > #1 0x0000000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100, > entry=0x801d69100, fd=6, st=Variable "st" is not available. > ) > at > /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434 > #2 0x000000080087831e in _archive_read_next_header2 (_a=0x801c45100, > entry=0x801d69100) > at > /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_posix.c:1070 > #3 0x00000000004078d5 in write_hierarchy (bsdtar=0x7fffffffd940, > a=0x801c17140, path=Variable "path" is not available. > ) > at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:825 > #4 0x0000000000407d51 in write_archive (a=0x801c17140, > bsdtar=0x7fffffffd940) > at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:471 > #5 0x0000000000404fbd in main (argc=4, argv=Variable "argv" is not > available. > ) > at /base/head/usr.bin/tar/../../contrib/libarchive/tar/bsdtar.c:668 > > This infinite loop has been fixed in libarchive master: > https://github.com/libarchive/libarchive/commit/d8b9dbd > d8b9dbd6dac0125957b997c2fe8d246237ec9f94 > > I suggest you backport to release also the following: > f67370d5c33b336b103c43fe35984defe7e0e473 > https://github.com/libarchive/libarchive/commit/f67370d > c6d3cd33aecdc579966c3fbe7b9424cea83c7555 > https://github.com/libarchive/libarchive/commit/c6d3cd3 > > > Dňa 29. 7. 2012 3:18 Tim Kientzle wrote / napísal(a): >> >> On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: >> >>> When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then … >> >>> My operating system is >>> FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 >> >> That's newer than my -CURRENT system here; I'm updating now. >> Martin imported a few changes from upstream just recently, so this >> is likely a new problem. >> >>> What to do? >> >> Can you get the full command line for the command that's >> hanging? >> >> $ ps auxww | grep tar >> >> Knowing the exact options that were used will help narrow >> it down. >> >> Thanks for reporting it, >> >> Tim From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 09:38:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8625D106568C for ; Sun, 29 Jul 2012 09:38:32 +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 1FBAE8FC17 for ; Sun, 29 Jul 2012 09:38:31 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B9E007300A; Sun, 29 Jul 2012 11:58:33 +0200 (CEST) Date: Sun, 29 Jul 2012 11:58:33 +0200 From: Luigi Rizzo To: "Bjoern A. Zeeb" Message-ID: <20120729095833.GB80946@onelab2.iet.unipi.it> References: <20120725155211.GA33971@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: current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 09:38:32 -0000 On Sat, Jul 28, 2012 at 10:14:10PM +0000, Bjoern A. Zeeb wrote: > On Wed, 25 Jul 2012, Luigi Rizzo wrote: > > >During some ipfw/dummynet cleanup i noticed that the libkern version of > >inet_ntoa_r() is missing the buffer size argument that is present in > >the libc counterpart. > > > >Any objection if i fix it ? > > And why exactly would you need it? What does libc do with it? Render > partial IPv4 addresses? Thanks for raising the issue because things are actually simpler than i thought. In general, having a function with same name and different arguments/behaviour in the kernel and userspace is annoying and should be avoided/fixed if possible. We have to live with malloc/free as they are too widely used to suggest a change, but this inet_ntoa_r() is very seldom used. In fact, the libc version is never used in HEAD, stable/9 and stable/8 and only the libkern version has a small number of clients (see below). Given that libkern has inet_ntop, with the same arguments of the userspace version, we'd be much better off with the following course of action: 1. replace calls to inet_ntoa_r() with inet_ntop() This needs to be done only in the kernel, because the libc version is never used at least in the source tree (maybe some port does). 2. nuke inet_ntoa_r() from libkern 3. nuke inet_ntoa_r() from libc The discussion on the cost of the extra argument is not very relevant here, because the function is intrinsically slow and called on slow paths (involves an snprintf, and likely some device I/O downstream). cheers luigi # grep -r net_ntoa_r . | grep -Ev pristine ./include/arpa/inet.h:#define inet_ntoa_r __inet_ntoa_r ./include/arpa/inet.h:char *inet_ntoa_r(struct in_addr, char *buf, socklen_t size); ./lib/libc/inet/Symbol.map: __inet_ntoa_r; ./lib/libc/inet/Symbol.map: inet_ntoa_r; ./lib/libc/inet/inet_ntoa.c:inet_ntoa_r(struct in_addr in, char *buf, socklen_t size) ./lib/libc/inet/inet_ntoa.c:__weak_reference(__inet_ntoa_r, inet_ntoa_r); ./lib/libc/net/Makefile.inc: inet.3 inet_network.3 inet.3 inet_ntoa.3 inet.3 inet_ntoa_r.3\ ./lib/libc/net/inet.3:.Nm inet_ntoa_r , ./lib/libc/net/inet.3:.Fo inet_ntoa_r ./lib/libc/net/inet.3:.Fn inet_ntoa_r ./sys/libkern/inet_ntoa.c:inet_ntoa_r(struct in_addr ina, char *buf) ./sys/net/flowtable.c: inet_ntoa_r(ssin->sin_addr, saddr); ./sys/net/flowtable.c: inet_ntoa_r(dsin->sin_addr, daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &dsin->sin_addr, daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &hashkey[2], daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) &hashkey[1], saddr); ./sys/net/if_llatbl.c: inet_ntoa_r(sin->sin_addr, l3s); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip->ip_src, src); ./sys/netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip->ip_dst, dst); ./sys/netinet/in.h:char *inet_ntoa_r(struct in_addr ina, char *buf); /* in libkern */ ./sys/netinet/in_pcb.c: inet_ntoa_r(inc->inc_laddr, laddr_str); ./sys/netinet/in_pcb.c: inet_ntoa_r(inc->inc_faddr, faddr_str); ./sys/netinet/tcp_subr.c: inet_ntoa_r(inc->inc_faddr, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(inc->inc_laddr, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(ip->ip_src, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(ip->ip_dst, sp); > ` I need it because i would like to compile parts of the kernel in userspace, and having a kernel function with the same name and different arguments from of a libc function is annoying. I can accept that > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 11:18:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A968106564A; Sun, 29 Jul 2012 11:18:47 +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 D634F8FC08; Sun, 29 Jul 2012 11:18:46 +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 q6TBIdHb004425; Sun, 29 Jul 2012 07:18:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6TBIdaO004416; Sun, 29 Jul 2012 11:18:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 29 Jul 2012 11:18:39 GMT Message-Id: <201207291118.q6TBIdaO004416@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 11:18:47 -0000 TB --- 2012-07-29 10:08:15 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-29 10:08:15 - 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 --- 2012-07-29 10:08:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-29 10:08:15 - cleaning the object tree TB --- 2012-07-29 10:10:14 - cvsupping the source tree TB --- 2012-07-29 10:10:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-29 10:11:09 - building world TB --- 2012-07-29 10:11:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 10:11:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 10:11:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 10:11:09 - SRCCONF=/dev/null TB --- 2012-07-29 10:11:09 - TARGET=sparc64 TB --- 2012-07-29 10:11:09 - TARGET_ARCH=sparc64 TB --- 2012-07-29 10:11:09 - TZ=UTC TB --- 2012-07-29 10:11:09 - __MAKE_CONF=/dev/null TB --- 2012-07-29 10:11:09 - cd /src TB --- 2012-07-29 10:11:09 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 29 10:11:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 29 11:12:28 UTC 2012 TB --- 2012-07-29 11:12:28 - generating LINT kernel config TB --- 2012-07-29 11:12:28 - cd /src/sys/sparc64/conf TB --- 2012-07-29 11:12:28 - /usr/bin/make -B LINT TB --- 2012-07-29 11:12:28 - cd /src/sys/sparc64/conf TB --- 2012-07-29 11:12:28 - /usr/sbin/config -m LINT TB --- 2012-07-29 11:12:28 - building LINT kernel TB --- 2012-07-29 11:12:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 11:12:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 11:12:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 11:12:28 - SRCCONF=/dev/null TB --- 2012-07-29 11:12:28 - TARGET=sparc64 TB --- 2012-07-29 11:12:28 - TARGET_ARCH=sparc64 TB --- 2012-07-29 11:12:28 - TZ=UTC TB --- 2012-07-29 11:12:28 - __MAKE_CONF=/dev/null TB --- 2012-07-29 11:12:28 - cd /src TB --- 2012-07-29 11:12:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 29 11:12:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_library.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_sbus.c /src/sys/dev/isp/isp_sbus.c: In function 'dma2': /src/sys/dev/isp/isp_sbus.c:603: error: too few arguments to function 'isp_send_cmd' *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-29 11:18:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-29 11:18:39 - ERROR: failed to build LINT kernel TB --- 2012-07-29 11:18:39 - 3268.52 user 590.20 system 4223.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 16:44:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B93F1065673 for ; Sun, 29 Jul 2012 16:44:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 29F7A8FC08 for ; Sun, 29 Jul 2012 16:44:27 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 755E325D3A85; Sun, 29 Jul 2012 16:44:19 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 762AFBE856C; Sun, 29 Jul 2012 16:44:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id BWd94ROqVhKg; Sun, 29 Jul 2012 16:44:17 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 150E8BE84EF; Sun, 29 Jul 2012 16:44:16 +0000 (UTC) Date: Sun, 29 Jul 2012 16:44:16 +0000 (UTC) From: "Bjoern A. Zeeb" To: Luigi Rizzo In-Reply-To: <20120729095833.GB80946@onelab2.iet.unipi.it> Message-ID: References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 16:44:27 -0000 On Sun, 29 Jul 2012, Luigi Rizzo wrote: > On Sat, Jul 28, 2012 at 10:14:10PM +0000, Bjoern A. Zeeb wrote: >> On Wed, 25 Jul 2012, Luigi Rizzo wrote: .. > Given that libkern has inet_ntop, with the same arguments of the > userspace version, we'd be much better off with the following > course of action: > > 1. replace calls to inet_ntoa_r() with inet_ntop() > This needs to be done only in the kernel, because the libc version > is never used at least in the source tree (maybe some port does). > > 2. nuke inet_ntoa_r() from libkern I am Ok with that I think (without looking at source implications) but I guess you'll post a patch. > 3. nuke inet_ntoa_r() from libc I am not sure we can easily do that (despite not being used in base). I fear some broader research into ports is needed, or as a shortcut, does linux have an inet_ntoa_r()? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 16:55:27 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664DB106566B for ; Sun, 29 Jul 2012 16:55:27 +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 33D0B8FC0C for ; Sun, 29 Jul 2012 16:55:27 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6TGtOgK055989 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 29 Jul 2012 16:55:26 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120729095833.GB80946@onelab2.iet.unipi.it> Date: Sun, 29 Jul 2012 17:55:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1278) Cc: "Bjoern A. Zeeb" , current@FreeBSD.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 16:55:27 -0000 On 29 Jul 2012, at 10:58, Luigi Rizzo wrote: > 3. nuke inet_ntoa_r() from libc inet_ntoa_r is a public symbol and therefore part of our ABI contract = with userspace applications. Even if no one that we are aware of is = using it, we should officially deprecate it for one major release before = removing it. ABI churn for purely aesthetic reasons does not make users = happy people. =20 > I need it because i would like to compile parts of the kernel in = userspace, > and having a kernel function with the same name and different = arguments > from of a libc function is annoying. Presumably this usage can be trivially fixed with a trivial macro in a = prefix header? David= From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 16:56:46 2012 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 8AE7E1065673; Sun, 29 Jul 2012 16:56:46 +0000 (UTC) (envelope-from tim@kientzle.com) 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 4917E8FC14; Sun, 29 Jul 2012 16:56:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q6TGudxc034931; Sun, 29 Jul 2012 16:56:39 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id eyymphgu5rq68p8f42ay2zbtwe; Sun, 29 Jul 2012 16:56:39 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Tim Kientzle In-Reply-To: <5014D873.5090406@FreeBSD.org> Date: Sun, 29 Jul 2012 09:56:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50141F96.5070808@zedat.fu-berlin.de> <5014D873.5090406@FreeBSD.org> To: Martin Matuska X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 16:56:46 -0000 Do you know what the value of acl_tag is at this point? On Jul 28, 2012, at 11:30 PM, Martin Matuska wrote: > I am also looking into it: >=20 > 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) > 2. It happens only if archiving files located on ZFS (UFS works fine) > 3. Backtrace: > #0 setup_acl_posix1e (a=3D0x801c45100, entry=3D0x801d69100, = acl=3D0x801d8a000, > archive_entry_acl_type=3D256) > at > = /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read= _disk_entry_from_file.c:474 > #1 0x0000000800879036 in archive_read_disk_entry_from_file = (_a=3D0x801c45100, > entry=3D0x801d69100, fd=3D6, st=3DVariable "st" is not available. > ) > at > = /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read= _disk_entry_from_file.c:434 >=20 > This infinite loop has been fixed in libarchive master: > https://github.com/libarchive/libarchive/commit/d8b9dbd > d8b9dbd6dac0125957b997c2fe8d246237ec9f94 >=20 > I suggest you backport to release also the following: > f67370d5c33b336b103c43fe35984defe7e0e473 > https://github.com/libarchive/libarchive/commit/f67370d > c6d3cd33aecdc579966c3fbe7b9424cea83c7555 > https://github.com/libarchive/libarchive/commit/c6d3cd3 >=20 >=20 > D=C5=88a 29. 7. 2012 3:18 Tim Kientzle wrote / nap=C3=ADsal(a): >>=20 >> On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: >>=20 >>> When updating ports (like databases/sqlite3 or graphics/png via = portmaster graphics/png), the installation process comes to a point = where a backup of the old port is created with bsdtar. The process hangs = then =E2=80=A6 >>=20 >>> My operating system is >>> FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 >>=20 >> That's newer than my -CURRENT system here; I'm updating now. >> Martin imported a few changes from upstream just recently, so this >> is likely a new problem. >>=20 >>> What to do? >>=20 >> Can you get the full command line for the command that's >> hanging? >>=20 >> $ ps auxww | grep tar >>=20 >> Knowing the exact options that were used will help narrow >> it down. >>=20 >> Thanks for reporting it, >>=20 >> Tim >>=20 >> _______________________________________________ >> 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" >>=20 >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 17:19:59 2012 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 630AC106564A for ; Sun, 29 Jul 2012 17:19:59 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id B030A8FC08 for ; Sun, 29 Jul 2012 17:19:58 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 6283439CE3; Sun, 29 Jul 2012 19:19:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id pSwFd9ex-De9; Sun, 29 Jul 2012 19:19:49 +0200 (CEST) Received: from [10.0.0.28] (unknown [213.81.198.162]) by mail.vx.sk (Postfix) with ESMTPSA id AA6B339CDA; Sun, 29 Jul 2012 19:19:49 +0200 (CEST) Message-ID: <501570B5.1090200@FreeBSD.org> Date: Sun, 29 Jul 2012 19:19:49 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "O. Hartmann" References: <50141F96.5070808@zedat.fu-berlin.de> In-Reply-To: <50141F96.5070808@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freeb >> Current FreeBSD" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 17:19:59 -0000 Do you still have this problem after r238882? Dňa 28. 7. 2012 19:21 O. Hartmann wrote / napísal(a): > When updating ports (like databases/sqlite3 or graphics/png via > portmaster graphics/png), the installation process comes to a point > where a backup of the old port is created with bsdtar. The process hangs > then: > > ===>>> Starting build for graphics/png <<<=== > > ===>>> All dependencies are up to date > > > ===>>> Creating a backup package for old version png-1.5.12 > load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k > > > And a look on top: > > last pid: 3365; load averages: 1.49, 1.44, 1.41 > up 0+04:39:08 > 19:17:44 > 65 processes: 2 running, 63 sleeping > CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle > Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free > ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other > Swap: 32G Total, 32G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 99286 root 1 103 0 71724K 5672K CPU1 1 24:10 100.00% > bsdtar > 1339 root 1 21 0 3221M 38008K select 1 3:02 1.71% > Xorg > 3364 ohartmann 28 20 0 634M 301M uwait 1 0:06 0.63% > thunderbird > 737 root 1 20 0 16520K 1492K select 0 0:42 0.00% > moused > 3286 ohartmann 22 20 0 681M 368M uwait 1 0:14 0.00% > firefox > 1469 ohartmann 1 20 0 72364K 10612K select 1 0:05 0.00% > xterm > > > I can circumvent by doing a make reinstall in the port's directory, but > this doesn't work for ports which copy files around using tar - like > www/firefox and mail/thunderbird (which also get stuck when bsdtar is > involved). > > My operating system is > FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 > > buildworld and kernel from today's sources, ports seem to be up to date, > I updated everything successfully before installing the new world which > seems to be faulty. > > I also recompiled usr.bin/tar separately and installed it, but without > success. > > What to do? > > regards, > > Oliver From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 17:41:02 2012 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 AD8EB106564A for ; Sun, 29 Jul 2012 17:41:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 72DD58FC14 for ; Sun, 29 Jul 2012 17:41:02 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 362EE60E4 for ; Sun, 29 Jul 2012 13:40:55 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type; b=fn7V2JLvAfpMWicWMhEdB6j+KlgH8vAw2bkF9sVs0mle21eOnED02PjTlP80W9nRP jqHg68WPwqNeT8QUy6lp+Z2tLNFED+pGzcmqxAw+NR3vGuKKqKQT862diVSF3XI Message-ID: <501575A0.2080007@protected-networks.net> Date: Sun, 29 Jul 2012 13:40:48 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E910F132B28C92396A41642" Cc: Subject: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 17:41:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E910F132B28C92396A41642 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( imb --------------enig6E910F132B28C92396A41642 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.12 (FreeBSD) iEYEARECAAYFAlAVdaUACgkQQv9rrgRC1JLLnQCgn2EnL3/DoWM8ZJOPS4JRqli4 AKYAn3+W6K8YPOlR8H8aw203aHUTrR3E =KZqF -----END PGP SIGNATURE----- --------------enig6E910F132B28C92396A41642-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 17:51:54 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06DB3106566B for ; Sun, 29 Jul 2012 17:51:54 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id B93218FC08 for ; Sun, 29 Jul 2012 17:51:53 +0000 (UTC) Received: from p508c7f19.dip.t-dialin.net ([80.140.127.25] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SvXeW-0005jE-Ho; Sun, 29 Jul 2012 19:51:40 +0200 Message-ID: <50157828.5000008@gwdg.de> Date: Sun, 29 Jul 2012 19:51:36 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Butler References: <501575A0.2080007@protected-networks.net> In-Reply-To: <501575A0.2080007@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: current@FreeBSD.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 17:51:54 -0000 On 29.07.2012 19:40 (UTC+2), Michael Butler wrote: > Is anyone else having troubles getting -current after SVN r238886 to > boot? In my case, I have an unstoppable stream of pager_something > console messages :-( > > imb Yes, it's the same here. I had to revert to old kernel. Rainer From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:24:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDC6F106564A for ; Sun, 29 Jul 2012 18:24:12 +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 95C6F8FC14 for ; Sun, 29 Jul 2012 18:24:12 +0000 (UTC) Received: by obbun3 with SMTP id un3so9952320obb.13 for ; Sun, 29 Jul 2012 11:24:12 -0700 (PDT) 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=JMwyJpYSj64TWVIpFyvBzrLRwOEqopgfqWj5PlYosDw=; b=cgNQKifjj140ZQY2jg2ElLIlqZzjnbvM5EvpGNEycWntEsPuBubT2OYspr2RRd65Kd q2X0q0Iq6I7dt9B9B3Df696CZNdhZZ5vk5tXb3T138YmycFfQTFRAcXYGskdNpbf0fzF jkVHCj7B9Km6IJ3nuxrGsL93z5i0r6+pDSz+gTmSjlmEyo8otWFpAqMo0742cTGDUS/M ck5S+kh7YgoLV3LAILjqpaoXGYaQwJ5RA1d9ETA2o+tfQ1M/r18cLdK+YlVGvM9AQZHO HI1bt4EnPwjtzlKZI+CAJ/zevAzw0KBJpiVRW6JmjOuLVHanyd3l+tc3tn1+aL3rZkZC +yxw== MIME-Version: 1.0 Received: by 10.60.29.230 with SMTP id n6mr13585910oeh.22.1343586252224; Sun, 29 Jul 2012 11:24:12 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sun, 29 Jul 2012 11:24:12 -0700 (PDT) In-Reply-To: <501575A0.2080007@protected-networks.net> References: <501575A0.2080007@protected-networks.net> Date: Sun, 29 Jul 2012 11:24:12 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 18:24:12 -0000 On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler wrote: > Is anyone else having troubles getting -current after SVN r238886 to > boot? In my case, I have an unstoppable stream of pager_something > console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:28:54 2012 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 7BEA6106564A for ; Sun, 29 Jul 2012 18:28:54 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 537018FC0C for ; Sun, 29 Jul 2012 18:28:54 +0000 (UTC) Received: from [192.168.135.103] (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q6TISl2F075989 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 29 Jul 2012 11:28:48 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <501580DA.4060608@feral.com> Date: Sun, 29 Jul 2012 11:28:42 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <501575A0.2080007@protected-networks.net> In-Reply-To: <501575A0.2080007@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sun, 29 Jul 2012 11:28:48 -0700 (PDT) Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matt Jacob List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 18:28:54 -0000 On 7/29/2012 10:40 AM, Michael Butler wrote: > Is anyone else having troubles getting -current after SVN r238886 to > boot? In my case, I have an unstoppable stream of pager_something > console messages :-( > > imb > me2 If I stop at single user and then continue, then all seems okay. I'm guessing (just a SWAG) that it might be related to the disk resize CAM stuff just added. From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:36:20 2012 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 D8C81106566C for ; Sun, 29 Jul 2012 18:36:20 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF2E8FC14 for ; Sun, 29 Jul 2012 18:36:20 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 4484B60E4; Sun, 29 Jul 2012 14:36:19 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type; b=Qh10S8ArGdHBInaWYLKVftYhVKpIQlb/6GCJgqGTjKL/tyCWOpZqqUWPHtVKvZ14J Gb9rZG8XpvzeBRaITrAkhtY5J5sABczaXS4/e+NNHBc/h6tl2VNTfM6qkKRZ5FK Message-ID: <5015829C.6060508@protected-networks.net> Date: Sun, 29 Jul 2012 14:36:12 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <501575A0.2080007@protected-networks.net> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig378B6C7AB6F0A1C5B975AAB2" Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 18:36:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig378B6C7AB6F0A1C5B975AAB2 Content-Type: multipart/mixed; boundary="------------040501040609080501090105" This is a multi-part message in MIME format. --------------040501040609080501090105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/29/12 14:24, Garrett Cooper wrote: > On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler > wrote: >> Is anyone else having troubles getting -current after SVN r238886 to >> boot? In my case, I have an unstoppable stream of pager_something >> console messages :-( >=20 > What was the previous version you booted and what's your configurat= ion? > Thanks, > -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, imb --------------040501040609080501090105 Content-Type: text/plain; charset=us-ascii; name="TOSHI" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="TOSHI" # TOSHI include GENERIC =20 ident TOSHI-SMP =20 nomakeoption DEBUG #makeoptions WITH_CTF=3Dno =20 nocpu I486_CPU nocpu I586_CPU #nooptions SCHED_ULE # ULE scheduler #options SCHED_4BSD # 4BSD scheduler nooptions MD_ROOT # MD is a potential root device nooptions NFSSERVER # Network Filesystem Server nooptions NFS_ROOT # NFS usable as /, requires NFSCLIENT nooptions NFSD # Experimental Network Filesystem Server #options NFSCL nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4 nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5 nooptions COMPAT_FREEBSD6 # Compatible with FreeBSD6 nooptions COMPAT_FREEBSD7 # Compatible with FreeBSD7 #nooptions SCSI_DELAY # Debugging for use in -current nooptions KDB # Enable kernel debugger support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures= , required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed #options KDB_TRACE # print a stack trace on panic #options DEBUG_MEMGUARD # detect reads or writes from allocated memory a= fter free #options DIAGNOSTIC # enable additional, more expensive diagnostic test= s along # the lines of options INVARIANTS. nodevice eisa nodevice fdc =20 #device ata nodevice ataraid # ATA RAID drives nodevice atapifd # ATAPI floppy drives nodevice atapist # ATAPI tape drives nodevice atadisk # ATA disk drives nodevice atapicd # ATAPI CDROM drives #device atausb # ATA-USB bridge #device atapicam # emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) #device atacore # Core ATA functionality =20 #device atapci # PCI bus support; only generic chipset support #device ataahci # AHCI SATA #device ataintel # Intel #device ahci #device ada nodevice mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA nodevice siis # SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers nodevice ahb # EISA AHA1742 family nodevice ahc # AHA2940 and onboard AIC7xxx devices nooptions AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. nodevice ahd # AHA39320/29320 and onboard AIC79xx devices nooptions AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. nodevice amd # AMD 53C974 (Tekram DC-390(T)) nodevice esp # AMD Am53C974 (Tekram DC-390(T)) nodevice hptiop # Highpoint RocketRaid 3xxx series nodevice isp # Qlogic family nodevice mpt # LSI-Logic MPT-Fusion nodevice sym # NCR/Symbios Logic (newer chipsets + those of `ncr') nodevice trm # Tekram DC395U/UW/F DC315U adapters =20 nodevice adv # Advansys SCSI adapters nodevice adw # Advansys wide SCSI adapters nodevice aha # Adaptec 154x SCSI adapters nodevice aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. nodevice bt # Buslogic/Mylex MultiMaster SCSI adapters =20 nodevice ncv # NCR 53C500 nodevice nsp # Workbit Ninja SCSI-3 nodevice stg # TMC 18C30/18C50 nodevice isci # Intel C600 SAS controller =20 nodevice ch # SCSI media changers nodevice sa # Sequential Access (tape etc) nodevice ses # SCSI Environmental Services (and SAF-TE) =20 nodevice amr # AMI MegaRAID nodevice arcmsr # Areca SATA II RAID nodevice asr # DPT SmartRAID V, VI and Adaptec SCSI RAID nodevice ciss # Compaq Smart RAID 5* nodevice dpt # DPT Smartcache III, IV - See NOTES for options nodevice hptmv # Highpoint RocketRAID 182x nodevice rr232x # Highpoint RocketRAID 232x nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx nodevice iir # Intel Integrated RAID nodevice ips # IBM (Adaptec) ServeRAID nodevice mly # Mylex AcceleRAID/eXtremeRAID nodevice twa # 3ware 9000 series PATA/SATA RAID nodevice tws # LSI 3ware 9750 SATA+SAS 6Gb/s RAID controller =20 nodevice aac # Adaptec FSA RAID nodevice aacp # SCSI passthrough for aac (requires CAM) nodevice ida # Compaq Smart RAID nodevice mfi # LSI MegaRAID SAS nodevice mlx # Mylex DAC960 family nodevice pst # Promise Supertrak SX6000 nodevice twe # 3ware ATA RAID =20 nodevice ppc nodevice ppbus # Parallel port bus (required) nodevice lpt # Printer nodevice plip # TCP/IP over parallel nodevice ppi # Parallel port interface device =20 nodevice bxe # Broadcom BCM57710/BCM57711/BCM57711E 10Gb Ethernet nodevice de # DEC/Intel DC21x4x (``Tulip'') nodevice em # Intel PRO/1000 adapter Gigabit Ethernet Card nodevice igb # Intel PRO/1000 PCIE Server Gigabit Family nodevice ixgb # Intel PRO/10GbE Ethernet Card nodevice le # AMD Am7900 LANCE and Am79C9xx PCnet nodevice ti # Alteon Networks Tigon I/II gigabit Ethernet nodevice txp # 3Com 3cR990 (``Typhoon'') nodevice vx # 3Com 3c590, 3c595 (``Vortex'') =20 nodevice ae # Attansic/Atheros L2 FastEthernet nodevice age # Attansic/Atheros L1 Gigabit Ethernet nodevice alc # Atheros AR8131/AR8132 Ethernet nodevice ale # Atheros AR8121/AR8113/AR8114 Ethernet nodevice bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet nodevice bfe # Broadcom BCM440x 10/100 Ethernet nodevice bge # Broadcom BCM570xx Gigabit Ethernet nodevice cas # Sun Cassini/Cassini+ and NS DP83065 Saturn nodevice dc # DEC/Intel 21143 and various workalikes nodevice et # Agere ET1310 10/100/Gigabit Ethernet nodevice gem # Sun GEM/Sun ERI/Apple GMAC nodevice hme # Sun HME (Happy Meal Ethernet) nodevice jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet nodevice lge # Level 1 LXT1001 gigabit Ethernet nodevice msk # Marvell/SysKonnect Yukon II Gigabit Ethernet nodevice nfe # nVidia nForce MCP on-board Ethernet nodevice nge # NatSemi DP83820 gigabit Ethernet nodevice pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S nodevice rl # RealTek 8129/8139 nodevice sf # Adaptec AIC-6915 (``Starfire'') nodevice sge # Silicon Integrated Systems SiS190/191 nodevice sis # Silicon Integrated Systems SiS 900/SiS 7016 nodevice sk # SysKonnect SK-984x & SK-982x gigabit Ethernet nodevice ste # Sundance ST201 (D-Link DFE-550TX) nodevice stge # Sundance/Tamarack TC9021 gigabit Ethernet nodevice tl # Texas Instruments ThunderLAN nodevice tx # SMC EtherPower II (83c170 ``EPIC'') nodevice vge # VIA VT612x gigabit Ethernet nodevice vr # VIA Rhine, Rhine II nodevice vte # DM&P Vortex86 RDC R6040 Fast Ethernet nodevice wb # Winbond W89C840F nodevice xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') =20 nodevice cs # Crystal Semiconductor CS89x0 NIC nodevice ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards nodevice ex # Intel EtherExpress Pro/10 and Pro/10+ nodevice ep # Etherlink III based cards nodevice fe # Fujitsu MB8696x based cards nodevice ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. nodevice sn # SMC's 9000 series of Ethernet chips nodevice xe # Xircom pccard Ethernet =20 nodevice an # Aironet 4500/4800 802.11 wireless NICs. #nodevice ath # Atheros pci/cardbus NIC's #nodevice ath_pci # Atheros pci/cardbus glue #nodevice ath_hal # pci/cardbus chip support #nooptions AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors #nodevice ath_rate_sample # SampleRate tx rate control for ath #nodevice awi # BayStack 660 and others #nodevice bwi # Broadcom BCM430x/BCM431x wireless NICs. #nodevice bwn # Broadcom BCM43xx wireless NICs. nodevice ipw # Intel 2100 wireless NICs. nodevice iwi # Intel 2200BG/2225BG/2915ABG wireless NICs. nodevice iwn # Intel 4965/1000/5000/6000 wireless NICs. nodevice malo # Marvell Libertas wireless NICs. nodevice mwl # Marvell 88W8363 802.11n wireless NICs. nodevice ral # Ralink Technology RT2500 wireless NICs. #nodevice wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. nodevice wpi # Intel 3945ABG wireless NICs. =20 nodevice sl # Kernel SLIP nodevice ppp # Kernel PPP #device faith # IPv6-to-IPv4 relaying (translation) # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) nodevice xhci # XHCI PCI->USB interface (USB 3.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device uhid # "Human Interface Devices" #device ukbd # Keyboard nodevice ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse nodevice rum # Ralink Technology RT2501USB wireless NICs nodevice run # Ralink Technology RT2700/RT2800/RT3000 NICs. nodevice uath # Atheros AR5523 wireless NICs nodevice upgt # Conexant/Intersil PrismGT wireless NICs. nodevice ural # Ralink Technology RT2500USB wireless NICs nodevice urtw # Realtek RTL8187B/L wireless NICs nodevice zyd # ZyDAS zb1211/zb1211b wireless NICs nodevice urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Serial devices #device ucom # Generic com ttys nodevice u3g # USB-based 3G modems (Option, Huawei, Sierra) nodevice uark # Technologies ARK3116 based serial adapters nodevice ubsa # Belkin F5U103 and compatible serial adapters nodevice uftdi # For FTDI usb serial adapters nodevice uipaq # Some WinCE based devices nodevice uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters nodevice uvisor # Visor and Palm devices nodevice uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus nodevice aue # ADMtek USB Ethernet nodevice axe # ASIX Electronics USB Ethernet nodevice cdce # Generic USB over Ethernet nodevice cue # CATC USB Ethernet nodevice kue # Kawasaki LSI USB Ethernet nodevice rue # RealTek RTL8150 USB Ethernet nodevice udav # Davicom DM9601E USB =20 nodevice fwe # Ethernet over FireWire (non-standard!) nodevice fwip # IP over FireWire (RFC 2734,3146) =20 device smbus # Bus support, required for smb below. device ichsmb device smb =20 #options VESA =20 # ACPI WMI Mapping driver #device acpi_wmi # ACPI Video Extensions (LCD backlight/brightness, video output, etc.) device acpi_video =20 # ACPI Docking Station #device acpi_dock # Hardware watchdog timers: # # ichwd: Intel ICH watchdog timer # device ichwd # # System Management Bus (SMB) # options ENABLE_ALART # Control alarm on Intel intpm driver # Direct Rendering modules for 3D acceleration. #device drm # DRM core module required by DRM drivers #device i915drm # Intel i830 through i915 #device drm2 device smbios =20 # netgraph(4). Enable the base netgraph code with the NETGRAPH option. # Individual node types can be enabled with the corresponding option # listed below; however, this is not strictly necessary as netgraph # will automatically load the corresponding KLD module if the node type # is not already compiled into the kernel. Each type below has a # corresponding man page, e.g., ng_async(8). options NETGRAPH # netgraph(4) system #options NETGRAPH_DEBUG # enable extra debugging, this # affects netgraph(4) and nodes # Node types #options NETGRAPH_ASYNC #options NETGRAPH_ATMLLC #options NETGRAPH_ATM_ATMPIF options NETGRAPH_BLUETOOTH # ng_bluetooth(4) #options NETGRAPH_BLUETOOTH_BT3C # ng_bt3c(4) #options NETGRAPH_BLUETOOTH_H4 # ng_h4(4) options NETGRAPH_BLUETOOTH_HCI # ng_hci(4) options NETGRAPH_BLUETOOTH_L2CAP # ng_l2cap(4) options NETGRAPH_BLUETOOTH_SOCKET # ng_btsocket(4) options NETGRAPH_BLUETOOTH_UBT # ng_ubt(4) #options NETGRAPH_BLUETOOTH_UBTBCMFW # ubtbcmfw(4) #options NETGRAPH_BPF #options NETGRAPH_BRIDGE #options NETGRAPH_CISCO #options NETGRAPH_DEVICE #options NETGRAPH_ECHO #options NETGRAPH_EIFACE options NETGRAPH_ETHER #options NETGRAPH_FEC #options NETGRAPH_FRAME_RELAY #options NETGRAPH_GIF #options NETGRAPH_GIF_DEMUX #options NETGRAPH_HOLE #options NETGRAPH_IFACE #options NETGRAPH_IP_INPUT #options NETGRAPH_IPFW #options NETGRAPH_KSOCKET #options NETGRAPH_L2TP #options NETGRAPH_LMI # MPPC compression requires proprietary files (not included) #options NETGRAPH_MPPC_COMPRESSION #options NETGRAPH_MPPC_ENCRYPTION #options NETGRAPH_NETFLOW #options NETGRAPH_NAT #options NETGRAPH_ONE2MANY #options NETGRAPH_PPP #options NETGRAPH_PPPOE #options NETGRAPH_PPTPGRE #options NETGRAPH_RFC1490 options NETGRAPH_SOCKET #options NETGRAPH_SPLIT #options NETGRAPH_SPPP #options NETGRAPH_TCPMSS #options NETGRAPH_TEE #options NETGRAPH_TTY #options NETGRAPH_UI #options NETGRAPH_VJC # NgATM - Netgraph ATM #options NGATM_ATM #options NGATM_ATMBASE #options NGATM_SSCOP #options NGATM_SSCFU #options NGATM_UNI #options NGATM_CCATM device blank_saver # Enable Linux ABI emulation options COMPAT_LINUX # Enable the linux-like proc filesystem support (requires COMPAT_LINUX # and PSEUDOFS) options LINPROCFS #Enable the linux-like sys filesystem support (requires COMPAT_LINUX) options LINSYSFS # Linux-specific pseudo devices support device lindev options NTFS #NT File System #options UDF #Universal Disk Format # options SMBFS #SMB/CIFS filesystem # # SMB/CIFS requester # NETSMB enables support for SMB protocol, it requires LIBMCHAIN and # LIBICONF options. # NETSMBCRYPTO enables support for encrypted passwords. options NETSMB #SMB/CIFS requester #options NETSMBCRYPTO #encrypted password support for = SMB # options LIBMCHAIN options LIBICONV # Sound support #device sound # Generic sound driver (required) nodevice snd_es137x # Ensoniq AudioPCI ES137x #device snd_hda # Intel High Definition Audio #device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_uaudio # USB Audio nodevice snd_via8233 # VIA VT8233x Audio device crypto device tap options CD9660_ICONV options MSDOSFS_ICONV options NTFS_ICONV #options UDF_ICONV options VFS_AIO # Temperature sensors: # # coretemp: on-die sensor on Intel Core and newer CPUs # device coretemp device wpifw #device wpi #device mmc #device mmcsd #device sdhci device hwpmc device cpuctl # Zero copy sockets support. This enables "zero copy" for sending and # receiving data via a socket. The send side works for any type of NIC, # the receive side only works for NICs that support MTUs greater than the= # page size of your architecture and that support header splitting. See # zero_copy(9) for more details. #options ZERO_COPY_SOCKETS # Provide read/write access to the memory in the clock chip. device nvram # Access to rtc cmos via /dev/nvram device dpms # DPMS suspend & resume via VESA BIOS # x86 real mode BIOS emulator, required by atkbdc/dpms/vesa options X86BIOS #device smapi #device vpd #options IEEE80211_SUPPORT_SUPERG # ATH superG #options IEEE80211_SUPPORT_TDMA # TDMA support # POSIX message queue options P1003_1B_MQUEUE #options GEOM_JOURNAL # Journaling. #options ATA_CAM device mii # Minimal MII support device mii_bitbang # Common module for bit-bang'ing the MII nodevice miibus # MII support including all PHYs #device inphy # Intel 82553/82555 device rgephy device iicbus device iicbb device iic #device mc146818 options VFS_ALLOW_NONMPSAFE #device virtio #device virtio_pci #device virtio_balloon #device virtio_blk #device vtnet --------------040501040609080501090105-- --------------enig378B6C7AB6F0A1C5B975AAB2 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.12 (FreeBSD) iEYEARECAAYFAlAVgqEACgkQQv9rrgRC1JKbigCghrCEFNL2L5nGKVzL02TiqI4k 9fYAniCdNRq9HYP4V/QH3kZv5tzvC9lU =Q1uN -----END PGP SIGNATURE----- --------------enig378B6C7AB6F0A1C5B975AAB2-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:39:14 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1523106564A for ; Sun, 29 Jul 2012 18:39:14 +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 67CB58FC0A for ; Sun, 29 Jul 2012 18:39:14 +0000 (UTC) Received: by obbun3 with SMTP id un3so9972399obb.13 for ; Sun, 29 Jul 2012 11:39:14 -0700 (PDT) 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=JauBCjyeJs7AJ1l003s+MumV6huJ5up+izqs1LkeMLE=; b=yhVcZthET84/13TJt74QAkfBYh3xqQgxX/TS3hHUBbgxMWzdDS/EBC4zqqVgqvVcXy 8HzghMJXBWoM/RooY0bwRbb3VK8OSgOdUd40Bvr1WcU02VNM1uuygRkZP0R/+oVCSnvV A7prnhts7LSGOMJlyuS+kvAmEsDB9oVupDUldOtG5YvAXohPMUyQ4NhNNSo0q6x+fSzN FIr3xD1F8Adv/mQG3Z4nwSKF9CVxAhVdb6iDYomS8lVygzfP3otvJJLzAfIj7HVz8sOq cBo/H9qSM1OvLw/MOjw2B6YZmv2aA+C9cxHB/CPM7ANdEmecahWWw/s52e7DNjxz6IC1 +MTA== MIME-Version: 1.0 Received: by 10.60.31.165 with SMTP id b5mr13579860oei.58.1343587154067; Sun, 29 Jul 2012 11:39:14 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sun, 29 Jul 2012 11:39:14 -0700 (PDT) In-Reply-To: <5015829C.6060508@protected-networks.net> References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> Date: Sun, 29 Jul 2012 11:39:14 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 18:39:14 -0000 On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler wrote: > On 07/29/12 14:24, Garrett Cooper wrote: >> On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler >> wrote: >>> Is anyone else having troubles getting -current after SVN r238886 to >>> boot? In my case, I have an unstoppable stream of pager_something >>> console messages :-( >> >> What was the previous version you booted and what's your configuration? >> Thanks, >> -Garrett > > I'm on an x86 core duo laptop with a single SATA disk split between > Windoze-7 and FreeBSD. Nothing really special in the kernel config (as > attached). > > The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:41:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691A31065670 for ; Sun, 29 Jul 2012 18:41:41 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF128FC15 for ; Sun, 29 Jul 2012 18:41:41 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 482AC60E4; Sun, 29 Jul 2012 14:41:40 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=ERzfFZi9sR17wUWD7k8ZR7XEJHzBXzkXCNI5aq9eQAVPDqMG4qLhh2boAQo7RQcHt nnX/YmywKpRYXVhvYQN666XECvYKEfp4vJmrFY2QydsHEAl97uKvK5gburqE4UF Message-ID: <501583E2.4070404@protected-networks.net> Date: Sun, 29 Jul 2012 14:41:38 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 18:41:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/12 14:39, Garrett Cooper wrote: > On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler > wrote: >> On 07/29/12 14:24, Garrett Cooper wrote: >>> On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler >>> wrote: >>>> Is anyone else having troubles getting -current after SVN r238886 to >>>> boot? In my case, I have an unstoppable stream of pager_something >>>> console messages :-( >>> >>> What was the previous version you booted and what's your configuration? >>> Thanks, >>> -Garrett >> >> I'm on an x86 core duo laptop with a single SATA disk split between >> Windoze-7 and FreeBSD. Nothing really special in the kernel config (as >> attached). >> >> The kernel from r238864 (yesterday) is working just fine, > > And if you go back to r238885...? Building that now, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAVg+EACgkQQv9rrgRC1JKpZgCfbvRx7bliF7yZs0ekBneTsXif AKYAnjP4bgD3H0bZPl5HZdMDCkXtiMxm =7OJA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 18:46:12 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174EF106566C for ; Sun, 29 Jul 2012 18:46:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D1F9E8FC14 for ; Sun, 29 Jul 2012 18:46:11 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6TIkBco003110; Sun, 29 Jul 2012 11:46:11 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6TIkB5Y003109; Sun, 29 Jul 2012 11:46:11 -0700 (PDT) (envelope-from david) Date: Sun, 29 Jul 2012 11:46:10 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20120729184610.GD1444@albert.catwhisker.org> References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="llIrKcgUOe3dCx0c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 18:46:12 -0000 --llIrKcgUOe3dCx0c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 29, 2012 at 11:39:14AM -0700, Garrett Cooper wrote: > ... > >> What was the previous version you booted and what's your configura= tion? > >> Thanks, > >> -Garrett > > > > I'm on an x86 core duo laptop with a single SATA disk split between > > Windoze-7 and FreeBSD. Nothing really special in the kernel config (as > > attached). > > > > The kernel from r238864 (yesterday) is working just fine, >=20 > And if you go back to r238885...? > Thanks! FWIW, I built & booted r238885 on both my laptop & my home build machine (without icident), and I'm in the process of building r238886 on my desktop at work as I type. (I haven't a serial console attached to the latter, and I'm remote from it, so this may be ... interesting for me.... :-}) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --llIrKcgUOe3dCx0c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAVhPIACgkQmprOCmdXAD0jHwCbB7YvdP3X2Hwt/ryIXAUBsn90 M1MAn02ff5Zgezho+evpUPXtFj+P72gb =ihXA -----END PGP SIGNATURE----- --llIrKcgUOe3dCx0c-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:00:02 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E90E1065672; Sun, 29 Jul 2012 19:00:02 +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 098678FC0A; Sun, 29 Jul 2012 19:00:01 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6941C7300A; Sun, 29 Jul 2012 21:19:58 +0200 (CEST) Date: Sun, 29 Jul 2012 21:19:58 +0200 From: Luigi Rizzo To: David Chisnall Message-ID: <20120729191958.GB85015@onelab2.iet.unipi.it> References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@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: "Bjoern A. Zeeb" , current@FreeBSD.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 19:00:02 -0000 On Sun, Jul 29, 2012 at 05:55:19PM +0100, David Chisnall wrote: > On 29 Jul 2012, at 10:58, Luigi Rizzo wrote: > > > 3. nuke inet_ntoa_r() from libc > > inet_ntoa_r is a public symbol and therefore part of our ABI contract with userspace applications. Even if no one that we are aware of is using it, we should officially deprecate it for one major release before removing it. ABI churn for purely aesthetic reasons does not make users happy people. sure, interpret "nuke" as a long term thing (starting with deprecation, manpage notes, etc.) > > > I need it because i would like to compile parts of the kernel in userspace, > > and having a kernel function with the same name and different arguments > > from of a libc function is annoying. > > > Presumably this usage can be trivially fixed with a trivial macro in a prefix header? Remapping f(a) into f(a, b) requires both a macro and a wrapping function, something like this T __f(T1 a, T2 b) { return f(a, b); } #define f(a) __f(a, b) Surely can be done (in fact, i have done it already, see http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz but i am not so interested in participating to the IOCCC :) http://www.ioccc.org/ From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:02:22 2012 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 7AB70106564A for ; Sun, 29 Jul 2012 19:02:22 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 18EF48FC12 for ; Sun, 29 Jul 2012 19:02:21 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 1154660E4; Sun, 29 Jul 2012 15:02:20 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type; b=QAtiC36KRim/90nSvBlDu8JGSSBGA6MJvzfVNPxtc5ug2PxHrQsP5TRmGTGzL4ROP GID5t6io+n/exbgYTkrHWy0cylPcWKfZHakh4rhz1ArnkYGaJ1g2kfmxzdczqta Message-ID: <501588B7.6000902@protected-networks.net> Date: Sun, 29 Jul 2012 15:02:15 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3094D914F2494EC5B6EE36BD" Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 19:02:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3094D914F2494EC5B6EE36BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/29/12 14:39, Garrett Cooper wrote: > On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler > wrote: >> On 07/29/12 14:24, Garrett Cooper wrote: >>> On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler >>> wrote: >>>> Is anyone else having troubles getting -current after SVN r238886 to= >>>> boot? In my case, I have an unstoppable stream of pager_something >>>> console messages :-( >>> >>> What was the previous version you booted and what's your configur= ation? >>> Thanks, >>> -Garrett >> >> I'm on an x86 core duo laptop with a single SATA disk split between >> Windoze-7 and FreeBSD. Nothing really special in the kernel config (as= >> attached). >> >> The kernel from r238864 (yesterday) is working just fine, >=20 > And if you go back to r238885...? > Thanks! Boots just fine .. imb@toshi:/home/imb> uname -a FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 imb@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sy= s/TOSHI i386 --------------enig3094D914F2494EC5B6EE36BD 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.12 (FreeBSD) iEYEARECAAYFAlAViLsACgkQQv9rrgRC1JL0/wCfehfeSW26j4w9KsK3dpGp5GlC IB8An13WTlyXJvCoKRa2H9buR9M2+lB6 =B9lG -----END PGP SIGNATURE----- --------------enig3094D914F2494EC5B6EE36BD-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:04:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D94A5106564A; Sun, 29 Jul 2012 19:04:17 +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 8F8208FC1D; Sun, 29 Jul 2012 19:04:17 +0000 (UTC) Received: by obbun3 with SMTP id un3so10006184obb.13 for ; Sun, 29 Jul 2012 12:04:17 -0700 (PDT) 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=gEK2z/s3Ac9SznVpNPn8sVyNMOlYjUfNjhS9rfOLI5Y=; b=jOk9925+WTjpEet/5q9rj4797kvRFnvza3TLrAQ1C8/dsxVktee6ZCNVSR5OQx0ohy 8I1Cu2R+lJi5eJtmNce7yGa/4bmPHflMTlM5qDmQJcoQGrPosegFrzGmtC0pfLni9eBB gZzQGrGgLH/VY9VIClWl5CV95XuTDK9pT0wKJAiwQYvipO7E/RjWs1UogTLutAQH9Kz6 BV9TDLp4EPPJTJ6P55bRL32ms72+A5sxJGNniuS6D5e4gYNzzD/e74vp+83ekrkOa8n5 kdbgjeh6jNBzoowKz860ypLPPuSbeM54OBPQr3QQWHuMskeX+v+djeRvnXN+OuhTcZXw D4XA== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr13880864oba.39.1343588657151; Sun, 29 Jul 2012 12:04:17 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sun, 29 Jul 2012 12:04:17 -0700 (PDT) In-Reply-To: <501588B7.6000902@protected-networks.net> References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> <501588B7.6000902@protected-networks.net> Date: Sun, 29 Jul 2012 12:04:17 -0700 Message-ID: From: Garrett Cooper To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 19:04:18 -0000 On Sun, Jul 29, 2012 at 12:02 PM, Michael Butler wrote: > On 07/29/12 14:39, Garrett Cooper wrote: >> On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler >> wrote: >>> On 07/29/12 14:24, Garrett Cooper wrote: >>>> On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler >>>> wrote: >>>>> Is anyone else having troubles getting -current after SVN r238886 to >>>>> boot? In my case, I have an unstoppable stream of pager_something >>>>> console messages :-( >>>> >>>> What was the previous version you booted and what's your configuration? >>>> Thanks, >>>> -Garrett >>> >>> I'm on an x86 core duo laptop with a single SATA disk split between >>> Windoze-7 and FreeBSD. Nothing really special in the kernel config (as >>> attached). >>> >>> The kernel from r238864 (yesterday) is working just fine, >> >> And if you go back to r238885...? >> Thanks! > > Boots just fine .. > > imb@toshi:/home/imb> uname -a > FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD > 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 > imb@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI > i386 CCed mav@ because it appears to be fallout from r238886. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:15:16 2012 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 1BD0F10656B7 for ; Sun, 29 Jul 2012 19:15:16 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99C2C8FC23 for ; Sun, 29 Jul 2012 19:15:15 +0000 (UTC) Received: by weyx56 with SMTP id x56so3770456wey.13 for ; Sun, 29 Jul 2012 12:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e5LUVX2CQxPjUstoJ4xpdrHWlMwweA6EIVL++sv/JoY=; b=CgtPJ2shQIbnJcDj8lLtghwBRRpq6aycfd4gJsuXd8BQ6bLB8OLyzBFN/FcHIRSzUZ ztnY3oiymY3iwlQw+e7P/P3y+2mjEbCqBM7QuPCdM2jxCl47/BEDT097CETUQoBVfr0c D6HTzDNvJfTCPZo8YOnSOoMeBpazl9Rc142BiCGRZpgu8+Bb3YoxOMupLLVF8isr/ZrY iSpYfXFP4FSkf/x6klgK0N3bg3+Ja9rzyFDthIIMCSd7kXOPnQ5ZyaOHx0w3YlfQK1zB dwUMz+U+te0rFl27Kuisby81YbOpE5aVwIw3a3kfQOL6hl/nlyui/bYqbfNWXFjVzrJu G+jg== Received: by 10.180.90.195 with SMTP id by3mr20898876wib.7.1343589309367; Sun, 29 Jul 2012 12:15:09 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id dc3sm12261560wib.7.2012.07.29.12.15.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 12:15:08 -0700 (PDT) Sender: Alexander Motin Message-ID: <50158BBA.5060206@FreeBSD.org> Date: Sun, 29 Jul 2012 22:15:06 +0300 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: Michael Butler References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> <501588B7.6000902@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 19:15:16 -0000 On 29.07.2012 22:04, Garrett Cooper wrote: > On Sun, Jul 29, 2012 at 12:02 PM, Michael Butler > wrote: >> On 07/29/12 14:39, Garrett Cooper wrote: >>> On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler >>> wrote: >>>> On 07/29/12 14:24, Garrett Cooper wrote: >>>>> On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler >>>>> wrote: >>>>>> Is anyone else having troubles getting -current after SVN r238886 to >>>>>> boot? In my case, I have an unstoppable stream of pager_something >>>>>> console messages :-( >>>>> >>>>> What was the previous version you booted and what's your configuration? >>>>> Thanks, >>>>> -Garrett >>>> >>>> I'm on an x86 core duo laptop with a single SATA disk split between >>>> Windoze-7 and FreeBSD. Nothing really special in the kernel config (as >>>> attached). >>>> >>>> The kernel from r238864 (yesterday) is working just fine, >>> >>> And if you go back to r238885...? >>> Thanks! >> >> Boots just fine .. >> >> imb@toshi:/home/imb> uname -a >> FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD >> 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 >> imb@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI >> i386 > > CCed mav@ because it appears to be fallout from r238886. Do you have any devices other then SATA disk? CD or some USB drive? Can you make at least any screenshot or tell something diagnostic about the problem? If there is chance to grab some output, could you set via the loader prompt variable kern.cam.dflags=0x41 and grab output after that? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:39:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BF20106566C; Sun, 29 Jul 2012 19:39:01 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 78BC38FC17; Sun, 29 Jul 2012 19:39:00 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4050328wgb.31 for ; Sun, 29 Jul 2012 12:38:59 -0700 (PDT) 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=B8xkzH7r9G1ebsxseCUNAtZuS+wHdNLIBf9GXkjSFA4=; b=MusjrRcEelDWs/EW1vls3xCCpp5pdQWdY62PJJdMCsSGwy8pzhNsvoCBR83TQl/4Bd b6c6LuVKWmBhzlVJoVRswMfh01TDvhC/ke58yTMQvqKoXUDqRpLFjqu3ZGeOgYsgcHz3 Bua7dTcbB3JozryW4iOLbhvPq6D7ZQI8kZcabjdUL95KrebqQMEJttA80P35a/xoxLVS ccZM0hBw0/Ubai2bdv5Ckze1tUpLcWPzh33BNu7WlDaO15d1nQLOHbheN4mKi160UC4D Ocg1x+bajxvXCHBuf4LENKPPjJIvf9gRFX3uiPI13jB5oOAfwD8bB5eoCAL7YT+hkVz8 lGqg== MIME-Version: 1.0 Received: by 10.180.85.167 with SMTP id i7mr10523585wiz.8.1343590739411; Sun, 29 Jul 2012 12:38:59 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sun, 29 Jul 2012 12:38:59 -0700 (PDT) In-Reply-To: <20120729191958.GB85015@onelab2.iet.unipi.it> References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> <20120729191958.GB85015@onelab2.iet.unipi.it> Date: Sun, 29 Jul 2012 15:38:59 -0400 Message-ID: From: Arnaud Lacombe To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "Bjoern A. Zeeb" , David Chisnall , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 19:39:01 -0000 Hi, On Sun, Jul 29, 2012 at 3:19 PM, Luigi Rizzo wrote: > Remapping f(a) into f(a, b) requires both a macro > and a wrapping function, something like this > > T __f(T1 a, T2 b) { return f(a, b); } > #define f(a) __f(a, b) > This can be done way more easily: void fn(int a, int b) { printf("%d %d\n", a, b); } #define fn(x) ({ fn(x, 42); }) int main(int argc, char **argv) { fn(0); return 0; } works just fine. > but i am not so interested in participating to the IOCCC :) > maybe you should ;-) - Arnaud ps: this construct is used all over the Linux kernel compatibility libraries. From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 19:52:51 2012 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 482D6106566B; Sun, 29 Jul 2012 19:52:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0A18FC0C; Sun, 29 Jul 2012 19:52:50 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9db0:4615:f8f5:e1a7]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6699C4AC2D; Sun, 29 Jul 2012 23:52:48 +0400 (MSK) Date: Sun, 29 Jul 2012 23:52:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <345962186.20120729235239@serebryakov.spb.ru> To: Alexander Motin In-Reply-To: <50158BBA.5060206@FreeBSD.org> References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> <501588B7.6000902@protected-networks.net> <50158BBA.5060206@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------08D1C918D1BCF8439" Cc: Garrett Cooper , Michael Butler , current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 19:52:51 -0000 ------------08D1C918D1BCF8439 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Alexander. You wrote 29 =E8=FE=EB=FF 2012 =E3., 23:15:06: AM> Do you have any devices other then SATA disk? CD or some USB drive? ``Me too'' I have same problem on my net5501. IT is i386 (AMD GEODE) with CF card attached as IDE (not SATA) disk. I have no swap configured. AM> Can you make at least any screenshot or tell something diagnostic about AM> the problem? If there is chance to grab some output, could you set via AM> the loader prompt variable kern.cam.dflags=3D0x41 and grab output after= that? Attached log of booting without kern.cam.dflags=3D0x41 and with kern.cam.dflags=3D0x41 (two files), as I have serial console. To be honest, I can not spot the difference. --=20 // Black Lion AKA Lev Serebryakov ------------08D1C918D1BCF8439 Content-Type: application/octet-stream; name="bad-boot-no-cam-debug.txt.bz2" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="bad-boot-no-cam-debug.txt.bz2" QlpoOTFBWSZTWR5Ox+UABGhfgGwQem///3///+q////0YBHOfW93naOzo4C86PTsO21xp4pe rnvvvl8yAHtrrC7CsREKVofd3V3aq4SiBJppk00ZBNME0Aap5o00p+qep4pnqnqbTFNqPKeo CUQgaYTUygIeU8Uep6j1AAAAA0AGgEomgamk0GjVT/SYmknp6iNNGmgGR6g0ABo0DCREITE0 CJ6nqp/qnpqn4plNqHpDQ/VH6p6aDSH6TUMCPUGlEAZAaGmQBoNABpiNAANAAAJEhNBMgTNT TENBI0nqe1RtCNplDQaGhkAPqUKokSinzRTtvZm2/ptMC+yulzbGq8JVgnqwYTKk/9z2ZUkq 4GeRx8KZPCsViW32SUH4VwlHn/G93aVNTdaX03OBSNlhw2BWAhtIc3+NiugMtdEarYFYMvQO Ub5kdcLIYzM1ls21eCIK/hClkPhP3OaFsHqbbbbbbbbpVf91N22zM0mZzmZhZ++6gTI1Xrvc rLPpiCjTYD9685aW/kd/W473Yd7enH1X8NfH4c61rWta1q7u7u7u+7oeD0sx6trJ/KgqpPxS gMqKNOneR6vX9BINfFBBN9bBrtcB3CIRfd+AaD/mLKtfKenQFdAB6BU0XdJtzl6tiIqmwpu8 nopaWw96NNZfMnJk3cKA6ozn4cCDa6Vqf6kODdbYOg1rbvaDW7pCDGjARKVQjly1zTQrGwwt j/g8yxiNfRz10RAuvYBiQXlsT9mXkUl7X7LASXeFwXyEdN6mfLb7fD02ZyLIhRg8Xt7AsvbA LGKdk7XBgC/mMpLnhk33Rukxrc49FstkRapBiIfg+NWgM+eBr4G8HVv0jkIpo6Mib5qZeznA 7g3IIljOSzAcs2Saxu4sJpQttkBJR51Eo4pWKuqRAINheMk+ktsiD4URDk18ON4bOE9HkX5b zK+qnMnD2QabTBJppC82CMPlncgdA7Mq3yfs9kE8MPtO6pn9YY5CwwDlJKd+J67MwssaMvL4 MbRi/SmaWJlc5ORjNWgbnmVGeLP6GyaCpTIwCs8rR7kdGJfDfed+30CR9bBBRlOPSeZlhyPo j4coN9AiGujUogJakDFuNkzUjT6bwRZkCsxtBHDf1miAaPAmZX0+n6xfiCS3gjns8d3LE7NZ r3C9DTCPSKNBICpWi715A5BdZvIa62INizYZ5irDK2Iwuv89tAtlGWNjWLpXpFDTfZAIEs6S +pQfPsL9NC6ch+BwmHQxEMMzEAOf3tUcF245AZfe0Q7Sbm3pXcMEC/4cPlCmo87RACQOEO6L pmwOuVPpkVaeHXITBzBfKq69CrWBCIbQbECjvOxlz0KPjbjy8lXk+NZwYebAlBQNvQzDmOLe yUSRZgxh8mmMrfsxwqmFMEzRmYHpIvbl3+blNme4t2m6+D4RZ16o9UXDNXDYT08d8Zx4qnXn U8zx4RKjFcxkSuBo/ZlpzRnU4bPvXNfBYGg+LD07fAElbmubfSWvvfOgSYBejhK3n8rhyPVV Wf/qlw5i4R0gFFRXDbAgblyV3IhGLSOLK9+5B9b8ldsyeHYykTWgRVta0CbrBRKk0rEY5t1v POc52h9ze9B4G4nrY2OuB9489PRKFdds16dM1pYqDQUxnUqQ7FYmN0qZmudbDQWikXdt/g67 NPv+FNiRk22k0rjQP0BmCuyvWiuDZK0DGF58ZJTOTShYhEDs0tPRx93l6/09Qxf15Uf0Mt1S tHrcrUU/pklrQMAMcdrBs2gQA48IiW3HRTAPbyhtD+efe6U9NZq4biEUbbbbbq4bbcxEuG22 231xxDhmgyWyNslrMLowrzdPk2x5DUeMF7OjF/DdfbuYUA8QYEqwI8fz/sYyvNU4RXdJupTK lIRiUoS4eolfZXJUJIh07d/OHA6SlyVUwqMj3meeUZzq1Au+5sU3axtNxA4sbWmLymVDcVY2 GzY084IqzUtYxZ1hmHn1HDCd0PBrNkh8zPMJvjRu7eZS0O+SPHVthaKu92E3nUyMLuclhbXF 8r1FhttQN7IxxFUWV9NQ+clzTcNXGwoFbEsnfNgXlx78Zy4QtF6hAMVaWyn2D54BlZF0UqsI z7NBOkEa36UzodtCNbzhoO99C98t2qF91l1g20hbMMxjBg6UdTevxM+8R+YFZUvHCZqYVS8y FuCNuKo3Nwo22eZhktJWs+iMpVDTacXVK0438+vSPypB4eRQt2Y9mw75XHhvmd8S8+G+VK15 UijDOOGka2e20SaoxDWtlfilQhrGLMIN9O3KuynV/bvX7mvLSZUGAewxgPUGSyKRSYTYxpse WUhMzITMyF582bvMZ81PTwrNLquCzSW8ltdti1OYfCUFlJvCz3UBES3KkG4MUOMdtvjHKZme 6mh3JEG54wugC7dNdPpklBnuJwYG1o+z5txWhyZdQEQkbAHL4p4BfQ8Mg+MNm2QZ6GVGgLzM oOuyavkxu3REVUQ91RE+62bsZrFyQxhzXxncpud/geNxxJyLeFBsoXZzs2gp2FlBe3uS6ovK w+w0/5EGh1+I5vtJJdYjDpG89YzbiF8JMw+iSj7MhPusPt9rT6CT6B40gupFG21fvBtMbY6U N6/YavaA4AOsFDUsoep1z2GkY8MQRJcO+J/1+Do8qY0FLEdQDj3dmyOCJRRYxEwatb4ggxcU ha9SgfYFnGZA8OqA4lukGwYSCS/4DCQqEBzLzckd6/kbNbsqChrWsmYlhoIPB21VdZ1Bt48I 5onccxGeiOzOqh9By7Z0MD3bzRpDSNtLIs9C4ElZjODXFy0QeWGy0npYcC0iyevqe0oJmPPP bKmLkiEBmE9rUQyOIjcmCSaUS4HnGg+GarJHC6RhvKTRUUVObqxNgFNANTf4Dh1y4qRvBIDD lmGKOHJ72cA6Kk+G4GRE5y6sdUQYFBQ67pyiHHbgH6mQeQBphQgZveqjWNjjcMGLC6SG2xSX ADGVcAhRI8AiJ+aiCJJOB31rfavoCi1fqJt8IqgQVy6+ztGQkNsLdYpnltPWVgVjxC/d/ldI AjpOAyh70NEeVpkGvL4khAUNGaax+JzW1By3wbJmwAvT4hSlfWO4NF1oTcU1tQJ8oSIhXf3v pC1UlwGksjKEpYSwwAHxB61bkJaWlaPsO+CLsVquz5BYls1faXwXXYaBztKEZpIqBN55BiWJ rye7m5M4I++77QDnFTmNDaVueCWoaViN6i4N/vn+A+CwvxTY2m02wolTPHz1CP3kf42FtEaw Bx8kuUizAxzGCt2B1WCQtAVKy6gtC9lV4DENt6mq1d04HLXOppZIaPiAzdXccSXFQMKAkUD8 eUlY4mbEMCRo6A8nNLV3d8kjaxBcmrXNos4RcJB9LhXgCKxBEIGwGzbsCTmdnu5353lhfcBw iuw2+2NVfIP1l4Lkla1zaQKVpwlKTIkiSSpliizNn3WI7Wdo5mJPIw+SzlO0FKKmRJ3SN7xH ut8kiDtwMAoQfLjrtuiITAREAosKhJTKLie1rxaWWNGDOmAO40o7wRZQxEbWALFCEVTD8g1X lsI24r8dtRU+aElexBMcNJ5aSyBE2T/sy+VMsEVSxJKvvfwoFutd3HSXNUaLNAxeIKUJskiJ uHE7AqfkhHUd5XMqy7r6heF7C+Bu+4EWwdSR7VaUhLS5PMp8o0RKO0VBN5JCRRYKx4bIvBJY Yp4wjjTERcV8AB5MElyVDvwMM0YnSKzELrYLVVC6AQMfFClAWXogxlzQjMlIrUE4lqHcZDPB fzZNcCGY4gQfmSyDO/B6qEw5+X9dVNrf076bDYkkZnBA3CHoDWTEvJHF0WJaeoJJEMFUfKJN EmG1el6oflzwPnrMEeI0kJRw1gkrVgKyi7qk0GE72QcqKgC83pBiPNG7uND8QaVWiAvwyb6p +9WQMF4hvWi5tjMA1hmgyLkgp+46w2Tzxn4hMkiOAFUU4JIT6bZoMxJUi1MknyBeyiOhAyIB xA3hBBPExdmioPc67vKIHuAxtlqoVStISyeDXveQd6EsDmNFo7bGwYMIF3cj8LEt4UEtTFY3 PrR80e7WuHNCV80G18FPsLTeGWxxSe6XDdM51tiIj5vpy3GYe6LGG/TqW0DzsDEHe5FEFFGs kjpIpKcggRM4ohJBJS6t1VPE0nQKZZQhoVYCEAgpU+fBkH8LJWtiyDPhVyAMtq/VKqqcBlzf 2XXk+wa2BctAkN88TIvYLE3wMUzxBGmIzyILvR16r1moV4XNBRrIojClorc223JdahZBBCwT AsQeXWRukuDCj7b+7Qt+PRiBKzIIQI5sDUf3gpVsAyJCpvKge4oLqQWE9S4arAvoXtoHIisw Yd3WMaGOnY0QKluMXlokKcEkJUYkscLMAqwWxBvakxQ0ChCWLSTTGA+7d9gi0wZfD0jBkMoS eNERR6WU1ek5zOuPJvS70MDEdn1peHJZ76FmHPEM6iY0MGcGoGJL2dS5eHXciTUpam/iZWIh WeXqW5wCklZPBCQzNpVgGJC9UiIa31Wz5xig8ouJFUxICMo85JbpAiRfy8ts+HUJRnJDLY6k uRx3AkQNjQMCzJqCul3HxoLSs/dYlsEdFYcQyNZpn4M7NfFEjtB9beqgI9aQlmCS9WVVTetk GhjaT4Q3bLzs6GkLOoBl7GxsbGxsbGxs3b5nRoUsN26Oo2fw5HrLN+0RiI037hlqNwKAxCQk Aw8RwkPvGCIbBDNws2C4SGkDL5UJIS3NIDPUeYKTyqHNF7SOIFN+iNaIygyAEY3xibV0xWkV 4iGx3tAo0nejReLIJhYSyQyoTUTf7CRz0z4O+iOAQqJIsCMq/X6C5MOWLp8XpmcUQSMPHdVL r1AqAAtIJ60TugmWlRFGBdXXWvY0pvNfVqOlLdPMte01mvHrldM0xBEy46+zNFmIB3JgyuIM HeCS6FY1Q4HUWIh+7MSgFYt2sEVzvlCqdZGFpfKRohBhtxQ2ay6m77si6dEtyIEZJBBi3vKZ FkQtrSuxUyeMVEfkrAwftRgixg8EalCQhpFB2ETsZMTKrQO6s0QQNEgUQRM974lQuEGyUsDi 3DTIlgQyYnGYaKwr8h+YywutAK1ua0InF6Q7bSIW53zIaiiLELTSAJCrh7qF3lpQer4QOrKF qaRyEkeGgv2bZqpBJG5UVMBVAs7aijUCSvoIstTki2tm/EwnW9BS5d9t8xH+IHwXlDakggEX BmQwrHMIQZfALqAfBdRj8m9JHhSgHMYjHIGxHdyNFK8KIQUIgfkkLK5MabY9aQfoz3iMWIaO pm0BiLsuS+2ihFC6CAksSID1MMGBhXVyrs6EsBlsyMZCV7ElgNCs1Aj/w0hG2YBsGwbRQzPN sE1Uyx7Cdt4XEhhFsDpRZ+0ErWimRCQE0jw0QMya1O92jczoyKz4SaNaRrFZbhwFIuHUpVII nciPlsxA9Yu5IpwoSA8nY/KA ------------08D1C918D1BCF8439 Content-Type: application/octet-stream; name="bad-boot-with-cam-debug.txt.bz2" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="bad-boot-with-cam-debug.txt.bz2" QlpoOTFBWSZTWUAiwJwAA/lfgGwQeu///////+q////0YBGuFY+95ve7nrAe3e7tm7gG7u3k 3Xtaedur2RqzOw0BpW1iIda7W1NV3O5eEohBMTTQ0yamGk9JqntE2kzFEe0mRqbaoY0I9NR+ qAlE0mjJoaaU0yU22pNHqR+kj0gMgyaPUHqaaNBoaNBKJkCEynonlHop6o/TKnqNGgaaP1I0 epoaGIANACREECTamTTKaZGqb9UnknqaeoPSH6o2mp6jTajEHqeoD1DhoZNNDTI0NMjIMjI0 MgMTRk0AZMjEMJEhCYE0NEyEwaSm0yTeiQ/VNo1AaPU9Ro0ADxL6qJAopwvlG+rO2f4wbzEv 9K9bz9rVeEeT7MGEqpN+J550mlYkZxcfGmbxrg5tFHL50Jwceu15R5/9Yu+6pm3Wk7nXEVBs gcCKwENpDnD7rFdQZa8RrhArDMk31yRyhdAxnE3F6Nr35gSYNRoPfP+HNCuLybbpVf9ybt0z M0mZ2TM22/f3IOhS6vn87Ln1yhe1yB+02qRheXi43eeN3ow+FOzNtYxjWtbe0HDza00zSvgw bU+j/cEtMadfKR5vRyJDXkoKb4Q143Ac4g5CUf5CZXB1nR7D7uYIZgEksYXji0Xr4bURVO8Z 8fNl2ZxI4ehGNSdCmTqP3ID7DU9bxoVgp7azr70BpxZo9oM28hBzDgRNioRw6ZHiqrmhztH0 H6k9Tx+v12pIOFIAwILSyJ+zHmUl878qgBdoagtkI7s0c79PFxhjnYtiGOnni3ML4tIK78IY M4aB19hwNXKVfI606PKs+novl8gLuAGIh/I3r9QWWPmzr0Ol0Z5xyEMkUFaZzkZTrNDtHE+i SZy3KBzMlrlk1ZMuM9aE7YgSUePaYkze67nvZYAievEiSr8d9CluVVaR6J4R13hu6bYel/Ro ctMGd5aPkQ02NJsENNJfhYGfzUxTsDnxtky/T2dasWTn2HeuN30BjkJOV4avRLKzyPDbuCCB UJq/coqoXF6nsKJBcKGOT5sZnkzDq7g+Vys/0NMyDWzcZhUfZIzuoqY4l+G+47jd5BI+tggo ynV4W0yMb+s/LHw64N9AiGu9qUQEs0xaG2ZmjX7t4FWIJLVQDTX1l0AVDkOX2R5+QT9gBMwN +vhl3tRtxM9BeRlCPKKNBIDfbEx+3nxXzD8zmjzt7Ee/X17NZTktthMjuLrnScvWWmNYuxdo obMTHwfLcyW/qXj78BfDpXXYfccJj6ftscgmWZiImv8X5+WqhyMxPNDvJvXotu530xeHN8n6 cJ9LqPgRhzB8IPZLjdPQ9gjVcHN2RkodIVFES7FWECAbeO1L3gbmT+Re9N9fH0UfJ60s2pRp 9GBKCgXOtmOw0581+OCwKw/w12iHgxwqmNMWZoywHkjXVZ2flq6DROuGK1Tagfgh0Lki2wcv dEEu67loqGV14HYXV9Dw8ECoxXMZArgaPbqJruFDdVaMWDyStO9LZKe9Q6quQASGpK2+c7up +SoSwDBHCVvP1XHI8qqz/9UuOYuI4gE1NVjbAgbk5FNiIRc0jiyn17EH3PhTNmO7ko8Gi4al aS4hg8xRInFdRB2rTsN7vwsq3OcgPSZcHNhwmesXLi5BIQ7+eOW1oPtLAVAfe1R7nYrExvlT M16K2GgtFIvlh63XXb8PjTVI0bbSaVZkHSGAKu/JVBryC302wHJpTtCCGll+Lo/nx7enUYv1 2Wx6mWVxdbG6Stap/TJZRMQM9HBnUBwHHfEJ8pwX2dkNifsn+7pT0Vmo4biEUbbbbbq4bbcx EuG22233xhxDfsWr8fQXswwjK/c6+ffHMajwgtZ3MXx122aMKAeAMF7f1waXGXjylR0iSmUZ O5LMju9RHXathGZFEO3lp68Nx2xjvVUvoMlbjdu3PhC5rQl2tsoOMYjjnY0e+BvY5Q2FzFSt WhucirBS+RTR8oObcHlzO5lC12Pu1NIEtxu3BCUbW8+Zy2YRjc2Wjuq+xYxlDbcbTGPdkrpV jt0UndHqigcuw5OQVRYW598lljXF5ssdyXFQtpOjgkXHlxeykpAyoQc7SzuC63hhN0ZNCN7t sBoOSXqhOBwgPtvK9OB3vrXwE7FCcr1oDaDr9gbTFRscO+3i4O9OBfUFdZzTyOlw/HzIXUSJ Zh4JPzq11NHJB87cGfO0NaQvWySpG7fPo6KEYLc7goUvxr3anAjbotWarmXDSsno9MZ2OeoY O0yjJn3VRIui8MlPqhQhq2KMIN8/C6mU+v7PNeTXGcyoMQ9gwz9IaLQdIhNjGmx6aSEzMhMs wUPFqWpa3sv7hsizzYJ9hT8Z1pNYvA9F9y33t1Q+/EAS7kzmy0Q5h/G/DCbMzcH5HBEHFV2T ZHAW1azb7ZJWzcTiwOlo+z1bitDsZegEJGoDl8k8QhcbpA5EJrrQXlWg1BhZxg/THt4Fbsgi KqIeioifNbkNKntFzP1h6qhncpi7/eb53EfOuEUG2wp87p+niDPA1Q/X7FyY/ng+0k+KRIeH uKT8M8+UKD1E/mwOfajsDPmV3Z7v5xbXyQf0/i0+BJ7R50gvSKNtrDeDVFFVRXvNE+Al+ADw A8gKHjXAP3PJSbESwPWCadJ5Zx839Hh9OVUFLq5gOfm/Hg4TUUWoibfk8cbQg5dbzP1FSyYt BSYLHVwbiHKCqCgwAn4AwkFAgOosNiR2r5GzN1VgoazWZlBiVmBA4rWiT1nSFm7SG9B5neEN WCHHVFILkbeTYFT8Nhk0hpGc6kVPIrAFVhOhIzlqV8HO7ZqJ5MOJcOg/PkXQsEUw37dGswVk QmOplxZEKnMYRSiYsZrUFpyRbfspuUx9xBozJNMa6u/aekDPsCS38Do8MeOeFwK8g/3kjapk 19PRAeLVXToEkl2U5bdcwkCgoZYn3nBjnlDyKCRAYqXBf4h0nib29n7nt7HqiLnz7QPZ3bQO qwkAEjYiIhJdA77VvtXyBRaPcJ8fLPIEFdefR5CErTzS2UMm0xPnIwEkekKa/OmYCJmbhkz7 0NEcWmQY3/JJApmTHliOr5HUs1y2wUZrQBPD+YPfZ5hXWh17Xhjxy0UDNekJIhKzzw2hnr3r cEzG+KLSDCrkAfAHmrMRLJpWD5HbA6OCUjt5wgiVp2EnEY3zFfcWDtqIWgPXbiGBBGvlfDuc sv4kffH7wDui52jQ2lbtxSyGlYjeoKw2/fL3D3LVZcmxtNpthNKeF3poEe0j46yrJGIA49Uv niaRWwL8R62kW7Q0rEhYhYWS0DANGXXMYhtvc1e7xpA530udLJGj6gGuu5qdpPaoGFQSKg/f 3QrOKG5DAnT5AfQ6Ja9/4JBb2gMU1g6NFuyMRL9LhZAJXggiE1AVTSoMrz3Pl5bnlzrQNza1 NH72pbwDr+wmCb0WTXkaSCcTsmZZEShpLu6unpRfxM91zytGA6GQ+hfxhvfcCM5LTEaLHPyO xF5Y+BEHHRMmFg4s9WOw1WxEJgIiAUVlgSUyi7/QfS14+MJZVMGc7wdpmjwBEzERowQYoSVS Yewaq2bSDq0Xv6rir+OADJoCg4aT12lpkKMj+zMpr0ZoulsJV/2v11WHSufdtMWqtFtDcUNg hmBeVYoZFgnIKnoQfE5LUupHuuoFwXKFICrSYEqrEkPNVSAWLSRlYniU8hoiSPFKgm8kgCiv VTv2RaAK/FPGEdNMEamhlermARewBclQ87S2xFxsFUxC7GCtohaAgY+hDNgZUREbu9Rz0G5I Xre8l7C+vxrf5446BX3nqAfYlVgGMYvKhMOfP+Sqm1vDwp0mqSRsOCBuEPdqEI2sS5o6nUsT UekJJEMFWPriTRJhuX0Wqh9GFx9VcwOY0kkPjmAKwh3CnUu2smrppnXMJgLqeQMR4o07C5+A NKtogLbsG90/eqoP41yBcw4LCbbGXhvDoQZFqQU+44htnwwnzCZIiNAKInokhPhVgsAU4qne k+kF+maN6kkB1gcggE365FvFNGq3UzT3CD2BI3U11lispCWLua+14h3JFx6BosHZU2DBhAu3 qPwqS3hQS1qJJVfrQ8EMfj1ppvRC106V0R9pUqF+tYRfJtMnN87IiI9fnjouAfkiphvy1raB 6agwB2uRRUUZkkd0ikpyCBEzpRCSCSluNK1PAyO4K9++IwbgRAIKUO69iKpXvulI2lqDVvpU WAMttPG00kaCmpv4arSfIa2BgWrAQ314ky1gsCrfIYpz6ANuYziIv5+/PBZqFgF2go1oURjS 0Vu223JOTkhCBAKooEiBpeQ1sTCrryp7GBL1ZWgMmxQQkB2sDI90FOFoYBsKBY6ioH3FRcFY nmuOdQW0LW0DkQVkwYdl4xoY6cmiBUswi0sEhTgkhKjBYXVXBWwWwhi3tQxQ0KEJYNJNMYD7 NPgIsLmWw8hgyGTJH20RFHtspq9s7Jnojcl4IYGQ6vvS+nxLTdQsw7cg0qJjQwZvagYg9vkX 099heMyUtThxNLEQrPT0rc4QpJWjxSQM2NKpAMSF5pIhrTZYn7hig5xjaTLExCXjKcpSSekg IN13T4bqcdBKK5IZZG5LpXToCRA2NAwKsWoMrDUfooLJcK/qrS2CO1VnSGJmZTuZxq1vkiZ1 g+DdAPUkkbwBeNlSpvWcFzG0n0Q3ZLn82Vncaws3AKSUVRVK6M2aoIyhpo7Ur28xQhTQQwEM pbBliNAUBgEhCTDvHAJvsIAhsBmguLBeaRpAzKakoQtMTyh1z2VDtRg0jkBptyRCL5OC8BK6 uLjau69ZCtEQ227WAoyOCFROgGCI16CkgvFE06kfrwlurXU94QoJbIYKW/4fWZLo7t+K+j32 O1IAz58LpctQVQEG0EuKD1gOUJiEVArPGc9qojr1Jz6DsjTDeUXYYmOHRLVMyiCOihaQcuCK sADsTBleAMHaALuLxrDzkjAWwQ/VxEoBXXDpBF+JnMK5yIzeBbEjCFdtwQ2bDVp8cSzU6J6k gwxV6IdxabNCvYGFla7XDIhpZcHAa0y+ZSIkxeKMlCQhpFB2ETqyazSi1pUPltNUEE0IMEjl 4ssTAMhBs1LQqLYNIctAzYk8gum7JZeL2ikysgC98ZhaIeSHhgRC4PKhDYxOgZ2UAoviHuoW eGcytK3wNucLZ4FSEUrDUWa9jpMgMhkkUjaK4FvJcUagCyqItgnKMLR17DXbbJDMX1zntEl9 QSmvsC/imIYAzwqhSAipP2ha8D2pqX9WiI985gdQxF2INiOfIvpPjRCChED5pCxsTGm2PNIP PhvEWsQ0ehmYDEV3+fSv5UUIiUgQBiYwgHwKFigXT6d89nEa0Uo5i2DiJmxJaDQr2A+IxJQw bBsG0SaHftE1Uzy5k64BckMYticUW+tCWDRXYQkBRHPSBTRQ6LIUFVzipCb7WZ6TejrHIqAo 9Q3eCBVGonciRU35wP/F3JFOFCQQCLAnAA== ------------08D1C918D1BCF8439-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 20:13:34 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3D8106566B; Sun, 29 Jul 2012 20:13:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3BD08FC08; Sun, 29 Jul 2012 20:13:33 +0000 (UTC) Received: by weyx56 with SMTP id x56so3791808wey.13 for ; Sun, 29 Jul 2012 13:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BSLXhkeoqONNXAIc06kXjmHrpsVccRDrY2L7xWY6T8Y=; b=bQ+oOElA8eLQ4qHqBKXpbR0QT4gYGPF9H+aHUFVPYMDZz54nViC35Zv2zbOwA4rOnN 3S1UoDRzMDFfJ6W3L+pUWYudg4fP7jbqsUbs/oJab0rTma4W8Ny8dAYJjxxn8ip+wg8e qViwtXh/8Bk6qasfDSfFh/+0Fhl+D1GZvbZ9mD9wdfZecoivzEZ81eJPL3ctA/KLZ4vZ wkm4VO1PTrqj6wRW9BeUbca1uwsPDoNR2JSn0Zmp/o/mgz4pdxiIco59HuQo/KSAiGP7 iHGimrfGk+awnKCBuT1hSk2Jh9sBJR/GhSWtbg3B8zwdTYM0Dc8jl17FfQ8+0Pnd6iHn V9Qw== Received: by 10.216.138.220 with SMTP id a70mr4591832wej.170.1343592812701; Sun, 29 Jul 2012 13:13:32 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id ex20sm18274652wid.7.2012.07.29.13.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 13:13:31 -0700 (PDT) Sender: Alexander Motin Message-ID: <50159969.7000008@FreeBSD.org> Date: Sun, 29 Jul 2012 23:13:29 +0300 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: lev@FreeBSD.org References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> <501588B7.6000902@protected-networks.net> <50158BBA.5060206@FreeBSD.org> <345962186.20120729235239@serebryakov.spb.ru> In-Reply-To: <345962186.20120729235239@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Garrett Cooper , Michael Butler , current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 20:13:34 -0000 On 29.07.2012 22:52, Lev Serebryakov wrote: > Hello, Alexander. > You wrote 29 èþëÿ 2012 ã., 23:15:06: > > AM> Do you have any devices other then SATA disk? CD or some USB drive? > ``Me too'' > > I have same problem on my net5501. IT is i386 (AMD GEODE) with CF card > attached as IDE (not SATA) disk. I have no swap configured. I was able to diagnose problem and it is not related to CAM as I've thought initially. It is related to GEOM spoiling mechanism. During boot process fsck opens checked disks for writing, while root at that time mounted as read-only. Disks close by fsck causes spoiling of the root partition's GEOM VFS, that with r238886 change made it inaccessible. I've reverted that GEOM VFS change at r238892, that should fix the problem until better solution will be found. I'm sorry. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 20:27:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B15B9106566B; Sun, 29 Jul 2012 20:27:20 +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 6D0C58FC16; Sun, 29 Jul 2012 20:27:19 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F346D7300A; Sun, 29 Jul 2012 22:47:21 +0200 (CEST) Date: Sun, 29 Jul 2012 22:47:21 +0200 From: Luigi Rizzo To: Arnaud Lacombe Message-ID: <20120729204721.GA87481@onelab2.iet.unipi.it> References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> <20120729191958.GB85015@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: "Bjoern A. Zeeb" , David Chisnall , current@freebsd.org Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 20:27:20 -0000 On Sun, Jul 29, 2012 at 03:38:59PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Jul 29, 2012 at 3:19 PM, Luigi Rizzo wrote: > > Remapping f(a) into f(a, b) requires both a macro > > and a wrapping function, something like this > > > > T __f(T1 a, T2 b) { return f(a, b); } > > #define f(a) __f(a, b) > > > This can be done way more easily: > > void fn(int a, int b) > { > printf("%d %d\n", a, b); > } > > #define fn(x) ({ fn(x, 42); }) nice trick, one always learns something on these lists... now i wonder how it works with MSVC (windows being one of the other platforms where i need to build the ipfw+dummynet code...) cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 20:30:09 2012 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 6BC0F106566C; Sun, 29 Jul 2012 20:30:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A36B8FC1A; Sun, 29 Jul 2012 20:30:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9db0:4615:f8f5:e1a7]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 05C004AC2D; Mon, 30 Jul 2012 00:30:07 +0400 (MSK) Date: Mon, 30 Jul 2012 00:30:00 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1119098728.20120730003000@serebryakov.spb.ru> To: Luigi Rizzo In-Reply-To: <20120729204721.GA87481@onelab2.iet.unipi.it> References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> <20120729191958.GB85015@onelab2.iet.unipi.it> <20120729204721.GA87481@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , David Chisnall , current@freebsd.org, Arnaud Lacombe Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 20:30:09 -0000 Hello, Luigi. You wrote 30 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 0:47:21: >> #define fn(x) ({ fn(x, 42); }) LR> nice trick, one always learns something on these lists... LR> now i wonder how it works with MSVC (windows being one of the LR> other platforms where i need to build the ipfw+dummynet code...) It looks very gcc-ish. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 21:19:47 2012 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 C79ED106564A; Sun, 29 Jul 2012 21:19:47 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAA98FC12; Sun, 29 Jul 2012 21:19:47 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 4D8AF60E4; Sun, 29 Jul 2012 17:19:46 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Pu3zv22MmC4kVx0IZKqwhKLBq8F6YIsYvClPORG7HjbnrSzkv3QoTcCiARA1CXZRX t+80zP9pGjLE+CPy5N3uvclrW0vbC9UgYToxU7xMIR1rW7Pgr1MEuAI/KVfVl+Z Message-ID: <5015A8F1.70808@protected-networks.net> Date: Sun, 29 Jul 2012 17:19:45 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: Alexander Motin References: <501575A0.2080007@protected-networks.net> <5015829C.6060508@protected-networks.net> <501588B7.6000902@protected-networks.net> <50158BBA.5060206@FreeBSD.org> <345962186.20120729235239@serebryakov.spb.ru> <50159969.7000008@FreeBSD.org> In-Reply-To: <50159969.7000008@FreeBSD.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: post SVN r238886 no boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 21:19:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/12 16:13, Alexander Motin wrote: > I was able to diagnose problem and it is not related to CAM as I've > thought initially. It is related to GEOM spoiling mechanism. > > During boot process fsck opens checked disks for writing, while root at > that time mounted as read-only. Disks close by fsck causes spoiling of > the root partition's GEOM VFS, that with r238886 change made it > inaccessible. > > I've reverted that GEOM VFS change at r238892, that should fix the > problem until better solution will be found. I can confirm that this change avoids/fixes the issue - thanks :-) > I'm sorry. No apology required - if I'm running -current, I should and do expect the occasional breakage. It's better found now than when it hits a wider release, i.e. I don't put -current on a production box .. imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAVqPAACgkQQv9rrgRC1JLfagCgzA7Rxtq7Sy4ps6CR0AaqDIvT Nh0AoKX+xn3KjEUjQy3SHWyA8vhvCSwe =65il -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 22:17:12 2012 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 91439106564A; Sun, 29 Jul 2012 22:17:12 +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 4331E8FC17; Sun, 29 Jul 2012 22:17:12 +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 <1SvbnT-0002mv-0q>; Mon, 30 Jul 2012 00:17:11 +0200 Received: from e178031138.adsl.alicedsl.de ([85.178.31.138] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SvbnS-00030v-Qs>; Mon, 30 Jul 2012 00:17:11 +0200 Message-ID: <5015B660.1010006@zedat.fu-berlin.de> Date: Mon, 30 Jul 2012 00:17:04 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120729 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Matuska References: <50141F96.5070808@zedat.fu-berlin.de> <501570B5.1090200@FreeBSD.org> In-Reply-To: <501570B5.1090200@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5EEE839404FEB754FB5D9ED" X-Originating-IP: 85.178.31.138 Cc: "freeb >> Current FreeBSD" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 22:17:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5EEE839404FEB754FB5D9ED Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 07/29/12 19:19, schrieb Martin Matuska: > Do you still have this problem after r238882? >=20 > D=C5=88a 28. 7. 2012 19:21 O. Hartmann wrote / nap=C3=ADsal(a): >> When updating ports (like databases/sqlite3 or graphics/png via >> portmaster graphics/png), the installation process comes to a point >> where a backup of the old port is created with bsdtar. The process han= gs >> then: >> >> =3D=3D=3D>>> Starting build for graphics/png <<<=3D=3D=3D >> >> =3D=3D=3D>>> All dependencies are up to date >> >> >> =3D=3D=3D>>> Creating a backup package for old version png-1.5.12 >> load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5= 656k >> >> >> And a look on top: >> >> last pid: 3365; load averages: 1.49, 1.44, 1.41 >> up 0+04:39:08 >> 19:17:44 >> 65 processes: 2 running, 63 sleeping >> CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle= >> Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M = Free >> ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other= >> Swap: 32G Total, 32G Free >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCP= U >> COMMAND >> 99286 root 1 103 0 71724K 5672K CPU1 1 24:10 100.0= 0% >> bsdtar >> 1339 root 1 21 0 3221M 38008K select 1 3:02 1.71= % >> Xorg >> 3364 ohartmann 28 20 0 634M 301M uwait 1 0:06 0.63= % >> thunderbird >> 737 root 1 20 0 16520K 1492K select 0 0:42 0.00= % >> moused >> 3286 ohartmann 22 20 0 681M 368M uwait 1 0:14 0.00= % >> firefox >> 1469 ohartmann 1 20 0 72364K 10612K select 1 0:05 0.00= % >> xterm >> >> >> I can circumvent by doing a make reinstall in the port's directory, bu= t >> this doesn't work for ports which copy files around using tar - like >> www/firefox and mail/thunderbird (which also get stuck when bsdtar is >> involved). >> >> My operating system is >> FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 >> >> buildworld and kernel from today's sources, ports seem to be up to dat= e, >> I updated everything successfully before installing the new world whic= h >> seems to be faulty. >> >> I also recompiled usr.bin/tar separately and installed it, but without= >> success. >> >> What to do? >> >> regards, >> >> Oliver The specific problem has gone - bsdtar now performs well. But another issue occurs now: Ports like mail/thunderbird or www/firefox which seems to install using bsdtar, install files with weird access bits set: --xr-xr-x I need to adjust the access bits manually. I do not know whether this is also libarchive related. I did not investigate further due to time constraints. Regards, Oliver --------------enigD5EEE839404FEB754FB5D9ED 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) iQEcBAEBAgAGBQJQFbZmAAoJEOgBcD7A/5N8yZQIAN7XgXnaUfPDo+0Ix3mn2U8N ihQ/+9/vB5hbg52UzskX7aM+Ow7SDuUHUy0G1q0HjvtWbXDYGZLE8kzl4fSp4hDf hp+99zVFT2Hv59LdobmYgT+/Olv9M80GxC5qHD+9s78CK5GXgQgxRefWvfJdy7io Ae6AkVvyXOBRsOTbzRO8EKGDeYxCFo3ECes5bZ+T+ziVrG8ljHDsmudkUoWfGvXE aLyHu3nnTbgkrzhms/XM8nqDhRkJXNV22oHrPzQA58XSnoLCzEU4ymrU3cGX0dQS eBeVS9P8fm2D9ynmp34Tj+iN4w8Z4lIz/VJw/AzPBvSX3e7Yj1m4ywrD9tAsUkE= =xmY3 -----END PGP SIGNATURE----- --------------enigD5EEE839404FEB754FB5D9ED-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 22:30:23 2012 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 33F33106564A; Sun, 29 Jul 2012 22:30:23 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 65B208FC15; Sun, 29 Jul 2012 22:30:22 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so4114842wgb.31 for ; Sun, 29 Jul 2012 15:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=onHD85A1m9eBg4hBaRW8BZcqj3Ppqz1bIAuhMZEI1Kw=; b=MEgu1qLhZ1V9/Ortru/QjO/HedYogDFLd4po3blRMdeueKY2//7t/Q6eG6Zl6b2H4x XiTsh0c4CwmqSRWlLQ7tlfBkv9uce7w0JOEqoLZT/Q1bepnHFMjrlOiO8InP2TN+KNVh 1DPAuN7V3RPbXtg5G9brsnb6gtHPGcwZed/iaYSJ/tk4InPqqdVhTteH3d3+sscDeCT0 m3LY/+UbW0VWmI1n/55z+tRl+GAY1Ffn6UlLqBizrBHVF5a5F7KySSBeJKqtfaQJ5wI8 CCA/50CuJ0dZ50DVcfVF4/fL+x1v4Pf0butX6uM/4Amw00/BhsTd0kwSQ0fAy5MBxotN 17eA== MIME-Version: 1.0 Received: by 10.216.86.74 with SMTP id v52mr4782249wee.4.1343601021295; Sun, 29 Jul 2012 15:30:21 -0700 (PDT) Received: by 10.216.199.31 with HTTP; Sun, 29 Jul 2012 15:30:21 -0700 (PDT) In-Reply-To: <1119098728.20120730003000@serebryakov.spb.ru> References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> <20120729191958.GB85015@onelab2.iet.unipi.it> <20120729204721.GA87481@onelab2.iet.unipi.it> <1119098728.20120730003000@serebryakov.spb.ru> Date: Sun, 29 Jul 2012 18:30:21 -0400 Message-ID: From: Arnaud Lacombe To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Luigi Rizzo , current@freebsd.org, David Chisnall Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 22:30:23 -0000 Hi, On Sun, Jul 29, 2012 at 4:30 PM, Lev Serebryakov wrote: > Hello, Luigi. > You wrote 30 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 0:47:21: > >>> #define fn(x) ({ fn(x, 42); }) > LR> nice trick, one always learns something on these lists... > LR> now i wonder how it works with MSVC (windows being one of the > LR> other platforms where i need to build the ipfw+dummynet code...) > It looks very gcc-ish. > could you back your point with a technical argument, please ? This sounds rather FUD'ish so far. The ({ ... }) is nothing more than a primary-expression enclosing a compound-statement; this part is not specifically necessary. As for the expansion, I would assume the following part of iso9899:1999 applies: << 6.10.3 Macro replacement 10 A preprocessing directive of the form # define identifier lparen identifier-listopt ) replacement-list new-line # define identifier lparen ... ) replacement-list new-line # define identifier lparen identifier-list , ... ) replacement-list new-lin= e defines a function-like macro with arguments, similar syntactically to a function call. [...] Each subsequent instance of the function-like macro name followed by a ( as the next preprocessing token introduces the sequence of preprocessing tokens that is replaced by the replacement list in the definition (an invocation of the macro). The replaced sequence of preprocessing tokens is terminated by the matching ) preprocessing token, [...] >> Note that the standard say "Each subsequent", no "All", so fn(1, 2); #define fn(a) fn(a, 2) fn(1); would produces: fn(1, 2); fn(1, 2); I do not see any gcc'ism here. Now, I might be wrong, and would enjoy being proven so. Thanks, - Arnaud From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 23:26:24 2012 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 D61431065670 for ; Sun, 29 Jul 2012 23:26:24 +0000 (UTC) (envelope-from dave-lists-freebsd-current@weller-fahy.com) Received: from tigger.weller-fahy.com (sinecure.xen.prgmr.com [71.19.148.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7D78FC14 for ; Sun, 29 Jul 2012 23:26:24 +0000 (UTC) Received: (qmail 10407 invoked from network); 29 Jul 2012 16:28:27 -0700 Received: from unknown (HELO weller-fahy.com) (dave@weller-fahy.com@24.209.97.39) by tigger.weller-fahy.com with AES256-SHA encrypted SMTP; 29 Jul 2012 16:28:27 -0700 Date: Sun, 29 Jul 2012 19:26:15 -0400 From: "David J. Weller-Fahy" To: freebsd-current@freebsd.org Message-ID: <20120729232615.GA62354@weller-fahy.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20120729045354.GA1054@weller-fahy.com> <20120729051509.GA40138@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21+66 (70810a88ce9f) (2011-07-01) Subject: Re: Panic on boot after svn update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 23:26:24 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper [2012-07-29 02:34 -0400]: > See this thread: > http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035593.html Huh - apparently my SA was not at its highest yesterday... Thanks for the heads up! --=20 dave [ please don't CC me ] --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD4DBQFQFcaWzahokXOb2UwRAor2AJ4xNHYNCB/twSSBOGvmtZComRUrbwCYigNu bc592+Cem8qWirJxMFmr0g== =XYZi -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 29 23:31:06 2012 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 E6711106564A for ; Sun, 29 Jul 2012 23:31:06 +0000 (UTC) (envelope-from dave-lists-freebsd-current@weller-fahy.com) Received: from tigger.weller-fahy.com (sinecure.xen.prgmr.com [71.19.148.52]) by mx1.freebsd.org (Postfix) with ESMTP id AA39E8FC16 for ; Sun, 29 Jul 2012 23:31:06 +0000 (UTC) Received: (qmail 11336 invoked from network); 29 Jul 2012 16:33:09 -0700 Received: from unknown (HELO weller-fahy.com) (dave@weller-fahy.com@24.209.97.39) by tigger.weller-fahy.com with AES256-SHA encrypted SMTP; 29 Jul 2012 16:33:09 -0700 Date: Sun, 29 Jul 2012 19:30:58 -0400 From: "David J. Weller-Fahy" To: freebsd-current@freebsd.org Message-ID: <20120729233057.GA62404@weller-fahy.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20120726154610.GC1587@albert.catwhisker.org> <5012E233.3050007@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21+66 (70810a88ce9f) (2011-07-01) Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 29 Jul 2012 23:31:07 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper [2012-07-28 18:43 -0400]: > On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe wrot= e: > Close, but you missed a spot. The attached patch (based on your's) > works, i.e. no longer panics at boot on my vbox instance. > Thanks! FYI - The patch works for me as well, thank you! --=20 dave [ please don't CC me ] --5vNYLRcllDrimb99 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQFcewzahokXOb2UwRAkJaAJ9b0+dZvj4QFAdnB8jzyMqQCCJm6wCeMCzQ O2LxidzdImc4wTvU0lN6940= =Y1V/ -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 07:10:06 2012 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 AEC7E1065678; Mon, 30 Jul 2012 07:10:06 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id C9B918FC0A; Mon, 30 Jul 2012 07:10:05 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id D6BF4B805F; Mon, 30 Jul 2012 11:02:58 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id A045CB805E; Mon, 30 Jul 2012 11:02:58 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 9B02EBA09A; Mon, 30 Jul 2012 11:02:58 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 60CCEBA084; Mon, 30 Jul 2012 11:02:58 +0400 (MSK) Message-ID: <5016319D.5000503@FreeBSD.org> Date: Mon, 30 Jul 2012 11:02:53 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig934F2ECCF177386C153B9787" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: Marcel Moolenaar , Andriy Gapon , Hiroki Sato Subject: [Request for review] loader changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jul 2012 07:10:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig934F2ECCF177386C153B9787 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi, All. It's been a long ago, when i published my patches first time. And it seems, there is no one who is against or wants suggest something. So I'm asking for review, and I want start merge changes at the end of we= ek. Patches are here: http://people.freebsd.org/~ae/bootcode/ full.diff: The full diff, except tools. tools.diff: A small test program bootparttest. It uses sys/boot/common/part.c to taste GEOM provider or disk image in the similar way, how loader does. common.diff: Changes to the common code. This code is used with many architectures and= libraries. * common/Makefile.inc added LOADER_NO_DISK_SUPPORT knob to disable build common code related = to disks and partitions. By default GPT and MBR support are enabled, LOADER_NO_GPT_S= UPPORT and LOADER_NO_MBR_SUPPORT can disable they. * common/part.c common/part.h these files are new. They contains partition tables related code. Sever= al words about API: Partition table described with opaque type "struct ptable", partition e= ntries with struct ptable_entry { uint64_t start; uint64_t end; int index; enum partition_type type; }; The partition tables detection occurs when ptable_open() is called. Thi= s function takes as arguments the number of disk sectors, sector size and pointer to the= callback function, that is know how to read from the disk. The ptable_close() function releases allocated resources. The ptable_gettype() functions returns the type of partition table. The ptable_getpart() functions returns information about specified part= ition. The ptable_iterate() functions calls a callback function for each parti= tion in the table. The parttype2str() converts partition type to the string. The following partition tables are supported: BSD label, GPT, MBR, EBR = and VTOC8. * common/disk.c common/disk.h These files have been changed and they use new API to work with partiti= ons. Also now they provide new disk API to the devsw disk drivers: disk_open(), disk_= close(), disk_print(), disk_fmtdev() and disk_parsedev(). i386.diff: Changes related to the i386 architecture: * i386/libi386/devicename.c Use disk_fmtdev() and disk_parsedev() functions from the common code. * i386/libi386/biosdisk.c The disk driver was rewritten to use new disk API. To the devsw ioctl h= andler was added. It handles DIOCGSECTORSIZE and DIOCGMEDIASIZE ioctls. * i386/libi386/libi386.h The offset field was added to the i386_devdesc.d_kind.biosdisk structur= e. * i386/libi386/Makefile removed unneeded flag. * i386/pmbr/pmbr.s Added secondary GPT support. * i386/loader/main.c ZFS probing simplified. * i386/loader/Makefile removed unneeded flag. userboot.diff: The disk driver and sample program updated according to the changes in th= e disk.c. Also new diskioctl callback added. uboot.diff: The disk driver was rewritten to use new disk API. arm.diff: powerpc.diff: Added LOADER_NO_DISK_SUPPORT handling to be able build uboot with or with= out disk support. zfs.diff: Use new partitions API to probe all ZFS partitions in the GPT and BSD par= tition tables. So, if there will not any opinions against these APIs and patches I will = start commit. The first step will be common and userboot code, then - i386 and = zfs parts. --=20 WBR, Andrey V. Elsukov --------------enig934F2ECCF177386C153B9787 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJQFjGiAAoJEAHF6gQQyKF6RIcIAJLsM6DEb+zxEkzD7SLGYOxO kFcgC6wHVPunH5tluSf8FVQn6yDkSFin3Sw8xe9qFDmFQ7UCdPbhnrGPDRizzUPD W6Od797a+iEhDdhWx2odglPyCdzaAgogw+sppPjvteRE3qNqK9bWM2MSS472CEpY xcB6Q5Ar1szNph/x2L9JXMt7WMkc7NRGQMGCTb02kss7SAzxxkjUDxxVhY/DCgxV auGBR+xxbRckVAFK27RyxCJuA5/114tbpA7wFiVh70SLu91l29zwc1aOPY0f87NW 6wDDP+QUdL+oO6wxY2f9OqjcL9qmJiyMZ42h4lQG+2Lg9BmT7Qo1q6txo61XTDM= =RWeO -----END PGP SIGNATURE----- --------------enig934F2ECCF177386C153B9787-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 07:12:13 2012 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 402FB1065674; Mon, 30 Jul 2012 07:12:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C41838FC18; Mon, 30 Jul 2012 07:12:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9db0:4615:f8f5:e1a7]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D24F74AC2D; Mon, 30 Jul 2012 11:12:10 +0400 (MSK) Date: Mon, 30 Jul 2012 11:12:09 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <492266872.20120730111209@serebryakov.spb.ru> To: Arnaud Lacombe In-Reply-To: References: <20120725155211.GA33971@onelab2.iet.unipi.it> <20120729095833.GB80946@onelab2.iet.unipi.it> <20120729191958.GB85015@onelab2.iet.unipi.it> <20120729204721.GA87481@onelab2.iet.unipi.it> <1119098728.20120730003000@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , Luigi Rizzo , current@freebsd.org, David Chisnall Subject: Re: RFC: libkern version of inet_ntoa_r X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 07:12:13 -0000 Hello, Arnaud. You wrote 30 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 2:30:21: >> It looks very gcc-ish. AL> could you back your point with a technical argument, please ? This AL> sounds rather FUD'ish so far. AL> The ({ ... }) is nothing more than a primary-expression enclosing a AL> compound-statement; And how will it return value? It is completely illegal for compound statement to return value. And to be a part of primary expression, too. Here is simple test: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 #include 2 #include 3 4 int fn(int x, int y) { return x + y; } 5 6 #define fn(x) ({ fn(x, 42); }) 7 8 int main(int argc, char *argv[]) { 9 printf("%d\n", fn(10)); 10 return 0; 11 } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D gcc compiles it and prints "52", but MSVC++ 10.0 cannot compile this at all, and it is in its own right: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D D:\home\lev\test>cl test.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 8= 0x86 Copyright (C) Microsoft Corporation. All rights reserved. test.c test.c(9) : error C2059: syntax error : '{' test.c(9) : error C2059: syntax error : ')' test.c(9) : error C2059: syntax error : ')' test.c(10) : error C2059: syntax error : 'return' test.c(11) : error C2059: syntax error : '}' =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html -- it is clearly marked as "GNU C" construct, not ANSI/ISO C/C++ one. And even more: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > gcc -Wall -ansi -pedantic -std=3Dc99 test.c test.c: In function 'main': test.c:9: warning: ISO C forbids braced-groups within expressions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 07:44:36 2012 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 8D0FF106564A for ; Mon, 30 Jul 2012 07:44:36 +0000 (UTC) (envelope-from gjb@glenbarber.us) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 399F48FC16 for ; Mon, 30 Jul 2012 07:44:36 +0000 (UTC) Received: (qmail 50429 invoked by uid 0); 30 Jul 2012 07:44:29 -0000 Received: from unknown (HELO 173-100-16-13.pools.spcsdns.net) (173.100.16.13) by 0 with SMTP; 30 Jul 2012 07:44:29 -0000 References: <50122891.5050301@rsu.ru> <20120727200944.GA1442@glenbarber.us> <501636B5.9040207@rsu.ru> User-Agent: K-9 Mail for Android In-Reply-To: <501636B5.9040207@rsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Glen Barber Date: Mon, 30 Jul 2012 03:44:26 -0400 To: Alexander Pyhalov ,Glen Barber Message-ID: <721bae49-cdf6-4e14-873a-20b1761d1baa@email.android.com> X-Mailman-Approved-At: Mon, 30 Jul 2012 11:23:40 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: make release recursion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jul 2012 07:44:36 -0000 Alexander Pyhalov wrote: >Hello. > >On 07/28/2012 00:09, Glen Barber wrote: >> Hello, >> >> On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: >>> Hello. >>> I've tried to do "make cdrom" on recent 10-current (svn revision >238763) >>> and got after day of work: >>> >> >> [...] >> >> Could you please retry the cdrom build with NOSRC=yes set? > >I've tried "make NOSRC=yes cdrom" and the command completed in about an > >hour without recursion. >-- >Best regards, >Alexander Pyhalov, >system administrator of Computer Center of Southern Federal University Thank you for reporting back on this. I believe I know where the recursion is happening, and will look into it further for a fix. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 14:50:30 2012 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 DB09B1065676 for ; Mon, 30 Jul 2012 14:50:30 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD0F8FC15 for ; Mon, 30 Jul 2012 14:50:30 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 6DB9F39C71; Mon, 30 Jul 2012 16:50:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id fYKLHK14U7i4; Mon, 30 Jul 2012 16:50:24 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id D8D0C39C43; Mon, 30 Jul 2012 16:50:23 +0200 (CEST) Message-ID: <50169F30.608@FreeBSD.org> Date: Mon, 30 Jul 2012 16:50:24 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "O. Hartmann" References: <50141F96.5070808@zedat.fu-berlin.de> <501570B5.1090200@FreeBSD.org> <5015B660.1010006@zedat.fu-berlin.de> In-Reply-To: <5015B660.1010006@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freeb >> Current FreeBSD" Subject: Re: r238860: bsdtar: eating up 100% CPU, hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jul 2012 14:50:30 -0000 Please check with CURRENT r238909. I have backported the NFSv4 ACL fix for now. It will be reverted and re-merged when fixed in libarchive's release branch. On 30.7.2012 0:17, O. Hartmann wrote: > Am 07/29/12 19:19, schrieb Martin Matuska: >> Do you still have this problem after r238882? >> > The specific problem has gone - bsdtar now performs well. But another > issue occurs now: > > Ports like mail/thunderbird or www/firefox which seems to install using > bsdtar, install files with weird access bits set: --xr-xr-x > I need to adjust the access bits manually. I do not know whether this is > also libarchive related. > I did not investigate further due to time constraints. > > Regards, > Oliver > -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 21:14:59 2012 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 02374106564A; Mon, 30 Jul 2012 21:14:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B0B228FC1A; Mon, 30 Jul 2012 21:14:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E555B944; Mon, 30 Jul 2012 17:14:58 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 30 Jul 2012 17:06:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207301706.02788.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 17:14:58 -0400 (EDT) Cc: FreeBSD Hackers , Warner Losh , Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jul 2012 21:14:59 -0000 On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe wrote: > > Hi, > > > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > >> [..] > >> Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > >> > > I will just pass function pointers for now, if things should be done > > dirty, let's be explicit about it. > > > > Now, the hinted device attachment did work quite smoothly, however, I > > would have a few suggestion: > > 1) add a call to bus_enumerate_hinted_children() before the call > > DEVICE_IDENTIFY() call in bus_generic_driver_added() > > > > this is required to be able to support dynamic loading and attachment > > of hinted children. I'm not sure this is a feature we want to support (to date hinted children have only been created at boot time). > > 2) have a generic bus_hinted_child method which would just add a new > > child to the bus. Possibly, but hinted children are intentionally opt-in and not enabled by default. > > 3) have bus_enumerate_hinted_children() and bus_generic_attach() > > always ran on device attachment. > > > > There is current +100 explicit call to bus_generic_attach() in the > > sys/dev/ tree. This should be done always and implicitly. No. One of the problems is that different busses want to do it at different times. It is usually done last, but some buses may want to do additional work after the bus_generic_attach(). > > 4) have bus_generic_detach() always ran prior to device detachment Similar. > > 5) have the bus_generic_* method be the default of their respective method No. However, what would be a good idea (and one thing I've had on my list), is to create a "bus_generic" driver that uses the bus_generic_* methods for all it's methods and let bus drivers inherit from that to get the generic methods if they are appropriate. If you do this, I would also add a second "bus_generic_rl" that inherits from "bus_generic" but uses the generic resource list methods for resources. > > 6) have device_delete_child() called upon device detachment. No. This is for a bus to decide. This would be horrifically wrong for things like kldunloading a PCI device driver. Just because you unload a driver (so that it detaches from devices) does not mean those physical devices have gone away. > > As a rule of thumb, when a kld is unloaded there should not be any > > remains of anything built previously. Without device_delete_child() or > > proper singleton implementation, multiple load/unload sequence of bus > > will attempt to attach multiple version of a child, even if the single > > child was added prior to the bus_generic_attach() call. Hinted devices should perhaps be removed, yes. However, what other drivers often do is use a singleton approach instead (despite your claim that they don't). For example: static void ipmi_isa_identify(driver_t *driver, device_t parent) { struct ipmi_get_info info; uint32_t devid; if (ipmi_smbios_identify(&info) && info.iface_type != SSIF_MODE && device_find_child(parent, "ipmi", -1) == NULL) { ... BUS_ADD_CHILD(parent, 0, "ipmi", -1); } } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 22:40:48 2012 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 613631065670 for ; Mon, 30 Jul 2012 22:40:48 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8078FC0C for ; Mon, 30 Jul 2012 22:40:48 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta11.emeryville.ca.mail.comcast.net with comcast id gdfZ1j0050QkzPwABmgins; Mon, 30 Jul 2012 22:40:42 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta02.emeryville.ca.mail.comcast.net with comcast id gmgh1j00G4NgCEG8Nmgi1Y; Mon, 30 Jul 2012 22:40:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6UMed69034570; Mon, 30 Jul 2012 16:40:39 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201207301706.02788.jhb@freebsd.org> References: <201207301706.02788.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Jul 2012 16:40:39 -0600 Message-ID: <1343688039.1101.112.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jul 2012 22:40:48 -0000 On Mon, 2012-07-30 at 17:06 -0400, John Baldwin wrote: > On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote: > > Hi, > > > > On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe wrote: > > > Hi, > > > > > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > > >> [..] > > >> Honestly, though, I think you'll be more pissed when you find out that > the N:1 interface that you want is being done in the wrong domain. But I've > been wrong before and look forward to seeing your replacement. > > >> > > > I will just pass function pointers for now, if things should be done > > > dirty, let's be explicit about it. > > > > > > Now, the hinted device attachment did work quite smoothly, however, I > > > would have a few suggestion: > > > 1) add a call to bus_enumerate_hinted_children() before the call > > > DEVICE_IDENTIFY() call in bus_generic_driver_added() > > > > > > this is required to be able to support dynamic loading and attachment > > > of hinted children. > > I'm not sure this is a feature we want to support (to date hinted children > have only been created at boot time). It seems to me that the bus should be in control of calling bus_enumerate_hinted_children() at whatever time works best for it. Also, shouldn't it only ever be called once? The comment block for BUS_HINTED_CHILD in bus_if.h says "This method is only called in response to the parent bus asking for hinted devices to be enumerated." I think one of the implications of that is that any given bus may not call bus_enumerate_hinted_children() because it may not be able to do anything for hinted children. Adding a "hint.somedev.0.at=somebus" and then forcing the bus to enumerate hinted children amounts to forcing the bus to adopt a child it may not be able to provide resources for, which sounds like a panic or crash waiting to happen (or at best, no crash but nothing useful happens either). -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 23:17:54 2012 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 8653B106566B; Mon, 30 Jul 2012 23:17:54 +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 54C888FC08; Mon, 30 Jul 2012 23:17:54 +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 q6UNHmPa055932; Mon, 30 Jul 2012 19:17:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6UNHmLY055902; Mon, 30 Jul 2012 23:17:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jul 2012 23:17:48 GMT Message-Id: <201207302317.q6UNHmLY055902@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:17:54 -0000 TB --- 2012-07-30 22:07:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-30 22:07:59 - 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 --- 2012-07-30 22:07:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-30 22:07:59 - cleaning the object tree TB --- 2012-07-30 22:07:59 - cvsupping the source tree TB --- 2012-07-30 22:07:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-30 22:08:42 - building world TB --- 2012-07-30 22:08:42 - CROSS_BUILD_TESTING=YES TB --- 2012-07-30 22:08:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-30 22:08:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-30 22:08:42 - SRCCONF=/dev/null TB --- 2012-07-30 22:08:42 - TARGET=sparc64 TB --- 2012-07-30 22:08:42 - TARGET_ARCH=sparc64 TB --- 2012-07-30 22:08:42 - TZ=UTC TB --- 2012-07-30 22:08:42 - __MAKE_CONF=/dev/null TB --- 2012-07-30 22:08:42 - cd /src TB --- 2012-07-30 22:08:42 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 30 22:08:43 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 30 23:11:12 UTC 2012 TB --- 2012-07-30 23:11:12 - generating LINT kernel config TB --- 2012-07-30 23:11:12 - cd /src/sys/sparc64/conf TB --- 2012-07-30 23:11:12 - /usr/bin/make -B LINT TB --- 2012-07-30 23:11:12 - cd /src/sys/sparc64/conf TB --- 2012-07-30 23:11:12 - /usr/sbin/config -m LINT TB --- 2012-07-30 23:11:12 - building LINT kernel TB --- 2012-07-30 23:11:12 - CROSS_BUILD_TESTING=YES TB --- 2012-07-30 23:11:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-30 23:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-30 23:11:12 - SRCCONF=/dev/null TB --- 2012-07-30 23:11:12 - TARGET=sparc64 TB --- 2012-07-30 23:11:12 - TARGET_ARCH=sparc64 TB --- 2012-07-30 23:11:12 - TZ=UTC TB --- 2012-07-30 23:11:12 - __MAKE_CONF=/dev/null TB --- 2012-07-30 23:11:12 - cd /src TB --- 2012-07-30 23:11:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 30 23:11:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-30 23:17:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-30 23:17:47 - ERROR: failed to build LINT kernel TB --- 2012-07-30 23:17:47 - 3310.54 user 593.28 system 4188.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Jul 30 23:20:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DAEE1065706; Mon, 30 Jul 2012 23:20:39 +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 BF8A38FC23; Mon, 30 Jul 2012 23:20:38 +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 q6UNKcef067582; Mon, 30 Jul 2012 19:20:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6UNKcmx067581; Mon, 30 Jul 2012 23:20:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 30 Jul 2012 23:20:38 GMT Message-Id: <201207302320.q6UNKcmx067581@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:20:39 -0000 TB --- 2012-07-30 21:00:16 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-30 21:00:16 - 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 --- 2012-07-30 21:00:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-30 21:00:16 - cleaning the object tree TB --- 2012-07-30 21:00:16 - cvsupping the source tree TB --- 2012-07-30 21:00:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-30 21:01:40 - building world TB --- 2012-07-30 21:01:40 - CROSS_BUILD_TESTING=YES TB --- 2012-07-30 21:01:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-30 21:01:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-30 21:01:40 - SRCCONF=/dev/null TB --- 2012-07-30 21:01:40 - TARGET=powerpc TB --- 2012-07-30 21:01:40 - TARGET_ARCH=powerpc TB --- 2012-07-30 21:01:40 - TZ=UTC TB --- 2012-07-30 21:01:40 - __MAKE_CONF=/dev/null TB --- 2012-07-30 21:01:40 - cd /src TB --- 2012-07-30 21:01:40 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 30 21:01:41 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 30 23:15:36 UTC 2012 TB --- 2012-07-30 23:15:36 - generating LINT kernel config TB --- 2012-07-30 23:15:36 - cd /src/sys/powerpc/conf TB --- 2012-07-30 23:15:36 - /usr/bin/make -B LINT TB --- 2012-07-30 23:15:36 - cd /src/sys/powerpc/conf TB --- 2012-07-30 23:15:36 - /usr/sbin/config -m LINT TB --- 2012-07-30 23:15:36 - building LINT kernel TB --- 2012-07-30 23:15:36 - CROSS_BUILD_TESTING=YES TB --- 2012-07-30 23:15:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-30 23:15:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-30 23:15:36 - SRCCONF=/dev/null TB --- 2012-07-30 23:15:36 - TARGET=powerpc TB --- 2012-07-30 23:15:36 - TARGET_ARCH=powerpc TB --- 2012-07-30 23:15:36 - TZ=UTC TB --- 2012-07-30 23:15:36 - __MAKE_CONF=/dev/null TB --- 2012-07-30 23:15:36 - cd /src TB --- 2012-07-30 23:15:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 30 23:15:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-30 23:20:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-30 23:20:38 - ERROR: failed to build LINT kernel TB --- 2012-07-30 23:20:38 - 6875.96 user 904.83 system 8421.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 00:06:34 2012 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 8AD261065670; Tue, 31 Jul 2012 00:06:34 +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 593F58FC0C; Tue, 31 Jul 2012 00:06: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 q6V06Xia077965; Mon, 30 Jul 2012 20:06:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V06XPh077964; Tue, 31 Jul 2012 00:06:33 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 00:06:33 GMT Message-Id: <201207310006.q6V06XPh077964@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 00:06:34 -0000 TB --- 2012-07-30 21:19:20 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-30 21:19: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 --- 2012-07-30 21:19:20 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-30 21:19:20 - cleaning the object tree TB --- 2012-07-30 21:19:20 - cvsupping the source tree TB --- 2012-07-30 21:19:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-30 21:20:49 - building world TB --- 2012-07-30 21:20:49 - CROSS_BUILD_TESTING=YES TB --- 2012-07-30 21:20:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-30 21:20:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-30 21:20:49 - SRCCONF=/dev/null TB --- 2012-07-30 21:20:49 - TARGET=powerpc TB --- 2012-07-30 21:20:49 - TARGET_ARCH=powerpc64 TB --- 2012-07-30 21:20:49 - TZ=UTC TB --- 2012-07-30 21:20:49 - __MAKE_CONF=/dev/null TB --- 2012-07-30 21:20:49 - cd /src TB --- 2012-07-30 21:20:49 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 30 21:20:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 31 00:01:31 UTC 2012 TB --- 2012-07-31 00:01:31 - generating LINT kernel config TB --- 2012-07-31 00:01:31 - cd /src/sys/powerpc/conf TB --- 2012-07-31 00:01:31 - /usr/bin/make -B LINT TB --- 2012-07-31 00:01:31 - cd /src/sys/powerpc/conf TB --- 2012-07-31 00:01:31 - /usr/sbin/config -m LINT TB --- 2012-07-31 00:01:31 - building LINT kernel TB --- 2012-07-31 00:01:31 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 00:01:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 00:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 00:01:31 - SRCCONF=/dev/null TB --- 2012-07-31 00:01:31 - TARGET=powerpc TB --- 2012-07-31 00:01:31 - TARGET_ARCH=powerpc64 TB --- 2012-07-31 00:01:31 - TZ=UTC TB --- 2012-07-31 00:01:31 - __MAKE_CONF=/dev/null TB --- 2012-07-31 00:01:31 - cd /src TB --- 2012-07-31 00:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 00:01:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 00:06:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 00:06:33 - ERROR: failed to build LINT kernel TB --- 2012-07-31 00:06:33 - 8408.59 user 1137.16 system 10033.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 02:30:21 2012 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 ED1EF106564A; Tue, 31 Jul 2012 02:30:20 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FADE8FC1D; Tue, 31 Jul 2012 02:30:19 +0000 (UTC) Received: by lbon10 with SMTP id n10so4656732lbo.13 for ; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) 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=/w03AC2jsU/TVLFYBXLFpLq7Zn9yq1Gd6j7wp3hqFv0=; b=PXdKsxYRjXvb66GtUG3zmvhVOTpD0wsTbKFPAkIQTPRe508PgvROzuWhDqp7vI1qzp Jht5xFu24jksSZX19Cc7kwigofOYcD3mPSkLAd00qyW3U/PWHTn9v8xJ8WFfaRX9Un0Y RqalxVypJEEQ/ZWoh9OBJOjrqmINfaXvV/bgdme7iaNzlevp84O28+zIYkMo+XRMUdhf yHrAM45fXo4i1Ifnhp77nl+U8TTiS7j5BFRvL6SVL0t6JfsvFYItVej5s2ujmP/ik3FC SdBi4CKcXLsP6ryUnXUXnnhg1hUzSGouHgowSijxdzpWectuvGe2ODWPVikNzG7GJPMn 7APA== MIME-Version: 1.0 Received: by 10.152.103.109 with SMTP id fv13mr13341493lab.33.1343701818802; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Mon, 30 Jul 2012 19:30:18 -0700 (PDT) In-Reply-To: <201207301706.02788.jhb@freebsd.org> References: <201207301706.02788.jhb@freebsd.org> Date: Mon, 30 Jul 2012 22:30:18 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 02:30:21 -0000 Hi, On Mon, Jul 30, 2012 at 5:06 PM, John Baldwin wrote: > On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote: >> Hi, >> >> On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe wrote: >> > Hi, >> > >> > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: >> >> [..] >> >> Honestly, though, I think you'll be more pissed when you find out that > the N:1 interface that you want is being done in the wrong domain. But I've > been wrong before and look forward to seeing your replacement. >> >> >> > I will just pass function pointers for now, if things should be done >> > dirty, let's be explicit about it. >> > >> > Now, the hinted device attachment did work quite smoothly, however, I >> > would have a few suggestion: >> > 1) add a call to bus_enumerate_hinted_children() before the call >> > DEVICE_IDENTIFY() call in bus_generic_driver_added() >> > >> > this is required to be able to support dynamic loading and attachment >> > of hinted children. > > I'm not sure this is a feature we want to support (to date hinted children > have only been created at boot time). > >> > 2) have a generic bus_hinted_child method which would just add a new >> > child to the bus. > > Possibly, but hinted children are intentionally opt-in and not enabled > by default. > >> > 3) have bus_enumerate_hinted_children() and bus_generic_attach() >> > always ran on device attachment. >> > >> > There is current +100 explicit call to bus_generic_attach() in the >> > sys/dev/ tree. This should be done always and implicitly. > > No. One of the problems is that different busses want to do it at > different times. It is usually done last, but some buses may want to > do additional work after the bus_generic_attach(). > >> > 4) have bus_generic_detach() always ran prior to device detachment > > Similar. > >> > 5) have the bus_generic_* method be the default of their respective > method > > No. However, what would be a good idea (and one thing I've had on my > list), is to create a "bus_generic" driver that uses the bus_generic_* > methods for all it's methods and let bus drivers inherit from that to > get the generic methods if they are appropriate. If you do this, I > would also add a second "bus_generic_rl" that inherits from "bus_generic" > but uses the generic resource list methods for resources. > >> > 6) have device_delete_child() called upon device detachment. > > No. This is for a bus to decide. This would be horrifically wrong > for things like kldunloading a PCI device driver. Just because you > unload a driver (so that it detaches from devices) does not mean those > physical devices have gone away. > >> > As a rule of thumb, when a kld is unloaded there should not be any >> > remains of anything built previously. Without device_delete_child() or >> > proper singleton implementation, multiple load/unload sequence of bus >> > will attempt to attach multiple version of a child, even if the single >> > child was added prior to the bus_generic_attach() call. > > Hinted devices should perhaps be removed, yes. However, what other drivers > often do is use a singleton approach instead (despite your claim that they > don't). > FreeBSD's newbus device framework already sucks (as in "too static"/"inflexible"), making it sucks even more (as in "more static"/"more inflexible") might not be the wisest approach... This is no longer the 90'. The good old enumerating-buses, tree-based, model is to be relegated to a corner-case of the computer world with profusion of embedded, non-enumerating, highly integrated, highly interconnected, highly custom SoCs. I am yet to see a robust approach to the various problem I submitted. > For example: > static void > ipmi_isa_identify(driver_t *driver, device_t parent) > { > struct ipmi_get_info info; > uint32_t devid; > > if (ipmi_smbios_identify(&info) && info.iface_type != SSIF_MODE && > device_find_child(parent, "ipmi", -1) == NULL) { > ... > BUS_ADD_CHILD(parent, 0, "ipmi", -1); > } > } > duplicated code doing the exact same abstract, hardcoded, function, all over the tree, absolutely unacceptable, if not a blatant proof of failure of what should be made generic, if not fully dynamic. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 02:50:39 2012 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 8B366106564A; Tue, 31 Jul 2012 02:50:39 +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 50EF38FC18; Tue, 31 Jul 2012 02:50:39 +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 q6V2ocdA009177; Mon, 30 Jul 2012 22:50:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V2ocVd009150; Tue, 31 Jul 2012 02:50:38 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 02:50:38 GMT Message-Id: <201207310250.q6V2ocVd009150@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:50:39 -0000 TB --- 2012-07-31 00:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 00:10:00 - 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 --- 2012-07-31 00:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-31 00:10:00 - cleaning the object tree TB --- 2012-07-31 00:10:00 - cvsupping the source tree TB --- 2012-07-31 00:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-31 00:12:18 - building world TB --- 2012-07-31 00:12:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 00:12:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 00:12:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 00:12:18 - SRCCONF=/dev/null TB --- 2012-07-31 00:12:18 - TARGET=i386 TB --- 2012-07-31 00:12:18 - TARGET_ARCH=i386 TB --- 2012-07-31 00:12:18 - TZ=UTC TB --- 2012-07-31 00:12:18 - __MAKE_CONF=/dev/null TB --- 2012-07-31 00:12:18 - cd /src TB --- 2012-07-31 00:12:18 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 00:12:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 02:38:27 UTC 2012 TB --- 2012-07-31 02:38:27 - generating LINT kernel config TB --- 2012-07-31 02:38:27 - cd /src/sys/i386/conf TB --- 2012-07-31 02:38:27 - /usr/bin/make -B LINT TB --- 2012-07-31 02:38:27 - cd /src/sys/i386/conf TB --- 2012-07-31 02:38:27 - /usr/sbin/config -m LINT TB --- 2012-07-31 02:38:27 - building LINT kernel TB --- 2012-07-31 02:38:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 02:38:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 02:38:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 02:38:27 - SRCCONF=/dev/null TB --- 2012-07-31 02:38:27 - TARGET=i386 TB --- 2012-07-31 02:38:27 - TARGET_ARCH=i386 TB --- 2012-07-31 02:38:27 - TZ=UTC TB --- 2012-07-31 02:38:27 - __MAKE_CONF=/dev/null TB --- 2012-07-31 02:38:27 - cd /src TB --- 2012-07-31 02:38:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 02:38:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 02:50:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 02:50:38 - ERROR: failed to build LINT kernel TB --- 2012-07-31 02:50:38 - 6959.95 user 992.02 system 9637.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 02:51:51 2012 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 69F79106564A; Tue, 31 Jul 2012 02:51:51 +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 392678FC0C; Tue, 31 Jul 2012 02:51:51 +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 q6V2poK4018023; Mon, 30 Jul 2012 22:51:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V2popt018015; Tue, 31 Jul 2012 02:51:50 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 02:51:50 GMT Message-Id: <201207310251.q6V2popt018015@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:51:51 -0000 TB --- 2012-07-31 00:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 00:10:00 - 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 --- 2012-07-31 00:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-31 00:10:00 - cleaning the object tree TB --- 2012-07-31 00:10:00 - cvsupping the source tree TB --- 2012-07-31 00:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-31 00:16:39 - building world TB --- 2012-07-31 00:16:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 00:16:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 00:16:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 00:16:39 - SRCCONF=/dev/null TB --- 2012-07-31 00:16:39 - TARGET=pc98 TB --- 2012-07-31 00:16:39 - TARGET_ARCH=i386 TB --- 2012-07-31 00:16:39 - TZ=UTC TB --- 2012-07-31 00:16:39 - __MAKE_CONF=/dev/null TB --- 2012-07-31 00:16:39 - cd /src TB --- 2012-07-31 00:16:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 00:16:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 02:41:10 UTC 2012 TB --- 2012-07-31 02:41:10 - generating LINT kernel config TB --- 2012-07-31 02:41:10 - cd /src/sys/pc98/conf TB --- 2012-07-31 02:41:10 - /usr/bin/make -B LINT TB --- 2012-07-31 02:41:11 - cd /src/sys/pc98/conf TB --- 2012-07-31 02:41:11 - /usr/sbin/config -m LINT TB --- 2012-07-31 02:41:11 - building LINT kernel TB --- 2012-07-31 02:41:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 02:41:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 02:41:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 02:41:11 - SRCCONF=/dev/null TB --- 2012-07-31 02:41:11 - TARGET=pc98 TB --- 2012-07-31 02:41:11 - TARGET_ARCH=i386 TB --- 2012-07-31 02:41:11 - TZ=UTC TB --- 2012-07-31 02:41:11 - __MAKE_CONF=/dev/null TB --- 2012-07-31 02:41:11 - cd /src TB --- 2012-07-31 02:41:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 02:41:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 02:51:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 02:51:50 - ERROR: failed to build LINT kernel TB --- 2012-07-31 02:51:50 - 6840.81 user 970.09 system 9710.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 03:26:08 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA3F106566B; Tue, 31 Jul 2012 03:26:08 +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 954E28FC1C; Tue, 31 Jul 2012 03:26:08 +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 q6V3Q8KM089291; Mon, 30 Jul 2012 23:26:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V3Q8AV089288; Tue, 31 Jul 2012 03:26:08 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 03:26:08 GMT Message-Id: <201207310326.q6V3Q8AV089288@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 03:26:09 -0000 TB --- 2012-07-31 00:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 00:10:00 - 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 --- 2012-07-31 00:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-31 00:10:00 - cleaning the object tree TB --- 2012-07-31 00:10:00 - cvsupping the source tree TB --- 2012-07-31 00:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-31 00:12:32 - building world TB --- 2012-07-31 00:12:32 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 00:12:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 00:12:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 00:12:32 - SRCCONF=/dev/null TB --- 2012-07-31 00:12:32 - TARGET=amd64 TB --- 2012-07-31 00:12:32 - TARGET_ARCH=amd64 TB --- 2012-07-31 00:12:32 - TZ=UTC TB --- 2012-07-31 00:12:32 - __MAKE_CONF=/dev/null TB --- 2012-07-31 00:12:32 - cd /src TB --- 2012-07-31 00:12:32 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 00:12:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 31 03:15:38 UTC 2012 TB --- 2012-07-31 03:15:38 - generating LINT kernel config TB --- 2012-07-31 03:15:38 - cd /src/sys/amd64/conf TB --- 2012-07-31 03:15:38 - /usr/bin/make -B LINT TB --- 2012-07-31 03:15:38 - cd /src/sys/amd64/conf TB --- 2012-07-31 03:15:38 - /usr/sbin/config -m LINT TB --- 2012-07-31 03:15:38 - building LINT kernel TB --- 2012-07-31 03:15:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 03:15:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 03:15:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 03:15:38 - SRCCONF=/dev/null TB --- 2012-07-31 03:15:38 - TARGET=amd64 TB --- 2012-07-31 03:15:38 - TARGET_ARCH=amd64 TB --- 2012-07-31 03:15:38 - TZ=UTC TB --- 2012-07-31 03:15:38 - __MAKE_CONF=/dev/null TB --- 2012-07-31 03:15:38 - cd /src TB --- 2012-07-31 03:15:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 03:15:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 03:26:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 03:26:07 - ERROR: failed to build LINT kernel TB --- 2012-07-31 03:26:07 - 8390.59 user 1310.90 system 11767.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 03:51:09 2012 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 BD3C21065670 for ; Tue, 31 Jul 2012 03:51:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2E68FC12 for ; Tue, 31 Jul 2012 03:51:09 +0000 (UTC) Received: by ghbz22 with SMTP id z22so6505070ghb.13 for ; Mon, 30 Jul 2012 20:51:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sFu9+q3iJ0KvQwRqVWhzdEOuqktO2lEKgbGu99hxL3k=; b=EWeTIKwTIZj40wU/mG85Io0kX821K90BxF0JHA9OS4RWmqjljwJyuzN5DigCXWKAdP HNELp9CLCA4ivgfW8qxY0qVPXTcsZvW0grn7CMkDNGtOAdb9CiUW691x5GXZF9fvrKQ0 yBhJy9w84x7DQmMtA8x16nAYpittZ+lwefdzWqe9YnpuaQ6O7B/NhgZCvUvJsNB2z86Q mfp72OwPLiKCLbluJZHTn6C1J+4UU+RiJMNE9Ep8ncdz3mTlY6ZHzoDG5T1Dsz0tw1B8 FbTV0vmLAGMOK6KknRoryFqXBnt8oDuxsItKJa20936OJnBj/lXuUMOWPUAoA5yMy0/5 BgRw== Received: by 10.50.10.234 with SMTP id l10mr188698igb.4.1343706668439; Mon, 30 Jul 2012 20:51:08 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id dk7sm17497019igb.10.2012.07.30.20.51.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 20:51:07 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 30 Jul 2012 21:51:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207301706.02788.jhb@freebsd.org> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkhaijfzcIXuI18OT1RANRkrgX2QTOwolhL9hgM+svuK/+FC6aaJ7MG32ujW+RKXqZml75m Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 03:51:09 -0000 On Jul 30, 2012, at 8:30 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Mon, Jul 30, 2012 at 5:06 PM, John Baldwin wrote: >> On Tuesday, July 17, 2012 2:03:14 am Arnaud Lacombe wrote: >>> Hi, >>>=20 >>> On Fri, Jul 13, 2012 at 1:56 PM, Arnaud Lacombe = wrote: >>>> Hi, >>>>=20 >>>> On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh = wrote: >>>>> [..] >>>>> Honestly, though, I think you'll be more pissed when you find out = that >> the N:1 interface that you want is being done in the wrong domain. = But I've >> been wrong before and look forward to seeing your replacement. >>>>>=20 >>>> I will just pass function pointers for now, if things should be = done >>>> dirty, let's be explicit about it. >>>>=20 >>>> Now, the hinted device attachment did work quite smoothly, however, = I >>>> would have a few suggestion: >>>> 1) add a call to bus_enumerate_hinted_children() before the call >>>> DEVICE_IDENTIFY() call in bus_generic_driver_added() >>>>=20 >>>> this is required to be able to support dynamic loading and = attachment >>>> of hinted children. >>=20 >> I'm not sure this is a feature we want to support (to date hinted = children >> have only been created at boot time). Yes. FDT should replace hinted things as much as possible. However, = FDT is an in for a penny, in for a pound technology like acpi: you more = or less have to use it for everything. >>>> 2) have a generic bus_hinted_child method which would just add a = new >>>> child to the bus. >>=20 >> Possibly, but hinted children are intentionally opt-in and not = enabled >> by default. Yes. I made it that way on purpose because most buses are enumerated, = and things are moving that way even in the embedded world, or at least = seemed that way when I was doing it. Either the buses are enumerated, = like PCI or some of the silicon frameworks, or you used FDT, which is = also fully enumerated. >>>> 3) have bus_enumerate_hinted_children() and bus_generic_attach() >>>> always ran on device attachment. >>>>=20 >>>> There is current +100 explicit call to bus_generic_attach() in the >>>> sys/dev/ tree. This should be done always and implicitly. >>=20 >> No. One of the problems is that different busses want to do it at >> different times. It is usually done last, but some buses may want to >> do additional work after the bus_generic_attach(). Yes. This was specifically due to how different buses enumerate. >>>> 4) have bus_generic_detach() always ran prior to device detachment >>=20 >> Similar. >>=20 >>>> 5) have the bus_generic_* method be the default of their respective >> method >>=20 >> No. However, what would be a good idea (and one thing I've had on my >> list), is to create a "bus_generic" driver that uses the = bus_generic_* >> methods for all it's methods and let bus drivers inherit from that to >> get the generic methods if they are appropriate. If you do this, I >> would also add a second "bus_generic_rl" that inherits from = "bus_generic" >> but uses the generic resource list methods for resources. It has been a mistake to not more aggressively investigate this line of = coding. >>>> 6) have device_delete_child() called upon device detachment. >>=20 >> No. This is for a bus to decide. This would be horrifically wrong >> for things like kldunloading a PCI device driver. Just because you >> unload a driver (so that it detaches from devices) does not mean = those >> physical devices have gone away. It is almost always horrifically wrong. >>>> As a rule of thumb, when a kld is unloaded there should not be any >>>> remains of anything built previously. Without device_delete_child() = or >>>> proper singleton implementation, multiple load/unload sequence of = bus >>>> will attempt to attach multiple version of a child, even if the = single >>>> child was added prior to the bus_generic_attach() call. >>=20 >> Hinted devices should perhaps be removed, yes. However, what other = drivers >> often do is use a singleton approach instead (despite your claim that = they >> don't). >>=20 > FreeBSD's newbus device framework already sucks (as in "too > static"/"inflexible"), making it sucks even more (as in "more > static"/"more inflexible") might not be the wisest approach... This is > no longer the 90'. The good old enumerating-buses, tree-based, model > is to be relegated to a corner-case of the computer world with > profusion of embedded, non-enumerating, highly integrated, highly > interconnected, highly custom SoCs. FDT handles the enumeration problem. FreeBSD's lack of a decent gpio, = pinctl, pinmux and other infrastructure are much bigger issues. At = least those are the real issues that I'm running into working on the = Atmel SoCs and bringing FDT to them. Hinted buses really have no place = in an FDT world. None. They are an ugly hack that were intended to be = a stop-gap until something better than hints came along. If you are = trying to use them in an FDT world, you are likely doing something = horribly wrong. > I am yet to see a robust approach to the various problem I submitted. That's because you're asking us to pound screws with a hammer. For the = things you've complained about, we really need to have better GPIO = infrastructure, a better pin control and pin mux infrastructure, etc. = We lack that right now, which is why you're trying to shoe-horn the FDT = connections into a newbus world and complaining that everything sucks = because it is a poor fit. I'd suggest that different mechanisms are = necessary. >> For example: >> static void >> ipmi_isa_identify(driver_t *driver, device_t parent) >> { >> struct ipmi_get_info info; >> uint32_t devid; >>=20 >> if (ipmi_smbios_identify(&info) && info.iface_type !=3D = SSIF_MODE && >> device_find_child(parent, "ipmi", -1) =3D=3D NULL) { >> ... >> BUS_ADD_CHILD(parent, 0, "ipmi", -1); >> } >> } >>=20 > duplicated code doing the exact same abstract, hardcoded, function, > all over the tree, absolutely unacceptable, if not a blatant proof of > failure of what should be made generic, if not fully dynamic. Perhaps, but design patterns can be just as useful for extremely short = code snippets. Warner= From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 03:57:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A541065781; Tue, 31 Jul 2012 03:57:18 +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 5E3898FC18; Tue, 31 Jul 2012 03:57:18 +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 q6V3vHtr072168; Mon, 30 Jul 2012 23:57:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V3vH36072163; Tue, 31 Jul 2012 03:57:17 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 03:57:17 GMT Message-Id: <201207310357.q6V3vH36072163@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 03:57:18 -0000 TB --- 2012-07-31 02:50:38 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 02:50:38 - 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 --- 2012-07-31 02:50:38 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-31 02:50:38 - cleaning the object tree TB --- 2012-07-31 02:50:38 - cvsupping the source tree TB --- 2012-07-31 02:50:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-31 02:51:27 - building world TB --- 2012-07-31 02:51:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 02:51:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 02:51:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 02:51:27 - SRCCONF=/dev/null TB --- 2012-07-31 02:51:27 - TARGET=mips TB --- 2012-07-31 02:51:27 - TARGET_ARCH=mips TB --- 2012-07-31 02:51:27 - TZ=UTC TB --- 2012-07-31 02:51:27 - __MAKE_CONF=/dev/null TB --- 2012-07-31 02:51:27 - cd /src TB --- 2012-07-31 02:51:27 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 02:51:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 03:56:19 UTC 2012 TB --- 2012-07-31 03:56:19 - cd /src/sys/mips/conf TB --- 2012-07-31 03:56:19 - /usr/sbin/config -m ADM5120 TB --- 2012-07-31 03:56:19 - skipping ADM5120 kernel TB --- 2012-07-31 03:56:19 - cd /src/sys/mips/conf TB --- 2012-07-31 03:56:19 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-31 03:56:19 - skipping ALCHEMY kernel TB --- 2012-07-31 03:56:19 - cd /src/sys/mips/conf TB --- 2012-07-31 03:56:19 - /usr/sbin/config -m AP93 TB --- 2012-07-31 03:56:19 - building AP93 kernel TB --- 2012-07-31 03:56:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 03:56:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 03:56:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 03:56:19 - SRCCONF=/dev/null TB --- 2012-07-31 03:56:19 - TARGET=mips TB --- 2012-07-31 03:56:19 - TARGET_ARCH=mips TB --- 2012-07-31 03:56:19 - TZ=UTC TB --- 2012-07-31 03:56:19 - __MAKE_CONF=/dev/null TB --- 2012-07-31 03:56:19 - cd /src TB --- 2012-07-31 03:56:19 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue Jul 31 03:56:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_textdump.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_variables.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_watch.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_write_cmd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -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=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_reset': /src/sys/dev/ath/if_ath.c:2210: error: 'struct ath_tx_methods' has no member named 'xmit_dma_restart' *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 03:57:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 03:57:17 - ERROR: failed to build AP93 kernel TB --- 2012-07-31 03:57:17 - 2616.29 user 579.89 system 3998.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 04:29:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AF4106564A; Tue, 31 Jul 2012 04:29:30 +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 D7B1B8FC0A; Tue, 31 Jul 2012 04:29:29 +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 q6V4TTCm017064; Tue, 31 Jul 2012 00:29:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V4TTsX017060; Tue, 31 Jul 2012 04:29:29 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 04:29:29 GMT Message-Id: <201207310429.q6V4TTsX017060@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 04:29:30 -0000 TB --- 2012-07-31 02:47:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 02:47:05 - 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 --- 2012-07-31 02:47:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-31 02:47:05 - cleaning the object tree TB --- 2012-07-31 02:47:05 - cvsupping the source tree TB --- 2012-07-31 02:47:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-31 02:48:06 - building world TB --- 2012-07-31 02:48:06 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 02:48:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 02:48:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 02:48:06 - SRCCONF=/dev/null TB --- 2012-07-31 02:48:06 - TARGET=ia64 TB --- 2012-07-31 02:48:06 - TARGET_ARCH=ia64 TB --- 2012-07-31 02:48:06 - TZ=UTC TB --- 2012-07-31 02:48:06 - __MAKE_CONF=/dev/null TB --- 2012-07-31 02:48:06 - cd /src TB --- 2012-07-31 02:48:06 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 02:48:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 04:23:34 UTC 2012 TB --- 2012-07-31 04:23:34 - generating LINT kernel config TB --- 2012-07-31 04:23:34 - cd /src/sys/ia64/conf TB --- 2012-07-31 04:23:34 - /usr/bin/make -B LINT TB --- 2012-07-31 04:23:34 - cd /src/sys/ia64/conf TB --- 2012-07-31 04:23:34 - /usr/sbin/config -m LINT TB --- 2012-07-31 04:23:34 - building LINT kernel TB --- 2012-07-31 04:23:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 04:23:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 04:23:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 04:23:34 - SRCCONF=/dev/null TB --- 2012-07-31 04:23:34 - TARGET=ia64 TB --- 2012-07-31 04:23:34 - TARGET_ARCH=ia64 TB --- 2012-07-31 04:23:34 - TZ=UTC TB --- 2012-07-31 04:23:34 - __MAKE_CONF=/dev/null TB --- 2012-07-31 04:23:34 - cd /src TB --- 2012-07-31 04:23:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 04:23:35 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_reset': /src/sys/dev/ath/if_ath.c:2210: error: 'struct ath_tx_methods' has no member named 'xmit_dma_restart' *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 04:29:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 04:29:29 - ERROR: failed to build LINT kernel TB --- 2012-07-31 04:29:29 - 4558.85 user 710.80 system 6143.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 05:11:04 2012 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 9D6401065670; Tue, 31 Jul 2012 05:11:04 +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 6432B8FC08; Tue, 31 Jul 2012 05:11:04 +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 q6V5B3sV088190; Tue, 31 Jul 2012 01:11:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V5B3xk088181; Tue, 31 Jul 2012 05:11:03 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 05:11:03 GMT Message-Id: <201207310511.q6V5B3xk088181@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:11:04 -0000 TB --- 2012-07-31 03:57:17 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 03:57:17 - 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 --- 2012-07-31 03:57:17 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-31 03:57:17 - cleaning the object tree TB --- 2012-07-31 03:58:31 - cvsupping the source tree TB --- 2012-07-31 03:58:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-31 03:59:13 - building world TB --- 2012-07-31 03:59:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 03:59:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 03:59:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 03:59:13 - SRCCONF=/dev/null TB --- 2012-07-31 03:59:13 - TARGET=sparc64 TB --- 2012-07-31 03:59:13 - TARGET_ARCH=sparc64 TB --- 2012-07-31 03:59:13 - TZ=UTC TB --- 2012-07-31 03:59:13 - __MAKE_CONF=/dev/null TB --- 2012-07-31 03:59:13 - cd /src TB --- 2012-07-31 03:59:13 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 03:59:13 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 05:04:21 UTC 2012 TB --- 2012-07-31 05:04:21 - generating LINT kernel config TB --- 2012-07-31 05:04:21 - cd /src/sys/sparc64/conf TB --- 2012-07-31 05:04:21 - /usr/bin/make -B LINT TB --- 2012-07-31 05:04:22 - cd /src/sys/sparc64/conf TB --- 2012-07-31 05:04:22 - /usr/sbin/config -m LINT TB --- 2012-07-31 05:04:22 - building LINT kernel TB --- 2012-07-31 05:04:22 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 05:04:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 05:04:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 05:04:22 - SRCCONF=/dev/null TB --- 2012-07-31 05:04:22 - TARGET=sparc64 TB --- 2012-07-31 05:04:22 - TARGET_ARCH=sparc64 TB --- 2012-07-31 05:04:22 - TZ=UTC TB --- 2012-07-31 05:04:22 - __MAKE_CONF=/dev/null TB --- 2012-07-31 05:04:22 - cd /src TB --- 2012-07-31 05:04:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 05:04:22 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 05:11:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 05:11:03 - ERROR: failed to build LINT kernel TB --- 2012-07-31 05:11:03 - 3328.95 user 593.02 system 4425.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 05:15:41 2012 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 5BA8A1065670; Tue, 31 Jul 2012 05:15:41 +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 2C1218FC12; Tue, 31 Jul 2012 05:15:41 +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 q6V5FeoB022169; Tue, 31 Jul 2012 01:15:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V5Fegv022168; Tue, 31 Jul 2012 05:15:40 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 05:15:40 GMT Message-Id: <201207310515.q6V5Fegv022168@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:15:41 -0000 TB --- 2012-07-31 02:51:50 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 02:51:50 - 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 --- 2012-07-31 02:51:50 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-31 02:51:50 - cleaning the object tree TB --- 2012-07-31 02:53:51 - cvsupping the source tree TB --- 2012-07-31 02:53:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-31 02:55:00 - building world TB --- 2012-07-31 02:55:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 02:55:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 02:55:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 02:55:00 - SRCCONF=/dev/null TB --- 2012-07-31 02:55:00 - TARGET=powerpc TB --- 2012-07-31 02:55:00 - TARGET_ARCH=powerpc TB --- 2012-07-31 02:55:00 - TZ=UTC TB --- 2012-07-31 02:55:00 - __MAKE_CONF=/dev/null TB --- 2012-07-31 02:55:00 - cd /src TB --- 2012-07-31 02:55:00 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 02:55:01 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 05:11:44 UTC 2012 TB --- 2012-07-31 05:11:44 - generating LINT kernel config TB --- 2012-07-31 05:11:44 - cd /src/sys/powerpc/conf TB --- 2012-07-31 05:11:44 - /usr/bin/make -B LINT TB --- 2012-07-31 05:11:44 - cd /src/sys/powerpc/conf TB --- 2012-07-31 05:11:44 - /usr/sbin/config -m LINT TB --- 2012-07-31 05:11:44 - building LINT kernel TB --- 2012-07-31 05:11:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 05:11:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 05:11:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 05:11:44 - SRCCONF=/dev/null TB --- 2012-07-31 05:11:44 - TARGET=powerpc TB --- 2012-07-31 05:11:44 - TARGET_ARCH=powerpc TB --- 2012-07-31 05:11:44 - TZ=UTC TB --- 2012-07-31 05:11:44 - __MAKE_CONF=/dev/null TB --- 2012-07-31 05:11:44 - cd /src TB --- 2012-07-31 05:11:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 05:11:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_reset': /src/sys/dev/ath/if_ath.c:2210: error: 'struct ath_tx_methods' has no member named 'xmit_dma_restart' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 05:15:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 05:15:40 - ERROR: failed to build LINT kernel TB --- 2012-07-31 05:15:40 - 6826.69 user 915.70 system 8629.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 06:15:32 2012 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 5C84F106564A; Tue, 31 Jul 2012 06:15:32 +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 2296F8FC16; Tue, 31 Jul 2012 06:15:32 +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 q6V6FVcn049815; Tue, 31 Jul 2012 02:15:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V6FVAb049814; Tue, 31 Jul 2012 06:15:31 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 06:15:31 GMT Message-Id: <201207310615.q6V6FVAb049814@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:15:32 -0000 TB --- 2012-07-31 03:26:08 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 03:26:08 - 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 --- 2012-07-31 03:26:08 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-31 03:26:08 - cleaning the object tree TB --- 2012-07-31 03:28:47 - cvsupping the source tree TB --- 2012-07-31 03:28:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-31 03:30:22 - building world TB --- 2012-07-31 03:30:22 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 03:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 03:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 03:30:22 - SRCCONF=/dev/null TB --- 2012-07-31 03:30:22 - TARGET=powerpc TB --- 2012-07-31 03:30:22 - TARGET_ARCH=powerpc64 TB --- 2012-07-31 03:30:22 - TZ=UTC TB --- 2012-07-31 03:30:22 - __MAKE_CONF=/dev/null TB --- 2012-07-31 03:30:22 - cd /src TB --- 2012-07-31 03:30:22 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 03:30:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 31 06:12:05 UTC 2012 TB --- 2012-07-31 06:12:05 - generating LINT kernel config TB --- 2012-07-31 06:12:05 - cd /src/sys/powerpc/conf TB --- 2012-07-31 06:12:05 - /usr/bin/make -B LINT TB --- 2012-07-31 06:12:05 - cd /src/sys/powerpc/conf TB --- 2012-07-31 06:12:05 - /usr/sbin/config -m LINT TB --- 2012-07-31 06:12:05 - building LINT kernel TB --- 2012-07-31 06:12:05 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 06:12:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 06:12:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 06:12:05 - SRCCONF=/dev/null TB --- 2012-07-31 06:12:05 - TARGET=powerpc TB --- 2012-07-31 06:12:05 - TARGET_ARCH=powerpc64 TB --- 2012-07-31 06:12:05 - TZ=UTC TB --- 2012-07-31 06:12:05 - __MAKE_CONF=/dev/null TB --- 2012-07-31 06:12:05 - cd /src TB --- 2012-07-31 06:12:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 06:12:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_reset': /src/sys/dev/ath/if_ath.c:2210: error: 'struct ath_tx_methods' has no member named 'xmit_dma_restart' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 06:15:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 06:15:31 - ERROR: failed to build LINT kernel TB --- 2012-07-31 06:15:31 - 8352.31 user 1121.56 system 10162.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 09:24:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C726106566B; Tue, 31 Jul 2012 09:24:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD0A8FC0A; Tue, 31 Jul 2012 09:24:36 +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 q6V9OZsc086674; Tue, 31 Jul 2012 05:24:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V9OZvq086663; Tue, 31 Jul 2012 09:24:35 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 09:24:35 GMT Message-Id: <201207310924.q6V9OZvq086663@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 09:24:36 -0000 TB --- 2012-07-31 06:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 06:20:00 - 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 --- 2012-07-31 06:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-31 06:20:00 - cleaning the object tree TB --- 2012-07-31 06:26:06 - cvsupping the source tree TB --- 2012-07-31 06:26:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-31 06:28:39 - building world TB --- 2012-07-31 06:28:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 06:28:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 06:28:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 06:28:39 - SRCCONF=/dev/null TB --- 2012-07-31 06:28:39 - TARGET=pc98 TB --- 2012-07-31 06:28:39 - TARGET_ARCH=i386 TB --- 2012-07-31 06:28:39 - TZ=UTC TB --- 2012-07-31 06:28:39 - __MAKE_CONF=/dev/null TB --- 2012-07-31 06:28:39 - cd /src TB --- 2012-07-31 06:28:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 06:28:40 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 09:12:53 UTC 2012 TB --- 2012-07-31 09:12:53 - generating LINT kernel config TB --- 2012-07-31 09:12:53 - cd /src/sys/pc98/conf TB --- 2012-07-31 09:12:53 - /usr/bin/make -B LINT TB --- 2012-07-31 09:12:54 - cd /src/sys/pc98/conf TB --- 2012-07-31 09:12:54 - /usr/sbin/config -m LINT TB --- 2012-07-31 09:12:54 - building LINT kernel TB --- 2012-07-31 09:12:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 09:12:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 09:12:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 09:12:54 - SRCCONF=/dev/null TB --- 2012-07-31 09:12:54 - TARGET=pc98 TB --- 2012-07-31 09:12:54 - TARGET_ARCH=i386 TB --- 2012-07-31 09:12:54 - TZ=UTC TB --- 2012-07-31 09:12:54 - __MAKE_CONF=/dev/null TB --- 2012-07-31 09:12:54 - cd /src TB --- 2012-07-31 09:12:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 09:12:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 09:24:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 09:24:35 - ERROR: failed to build LINT kernel TB --- 2012-07-31 09:24:35 - 6844.88 user 989.78 system 11074.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 09:25:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 115AE106567B; Tue, 31 Jul 2012 09:25:48 +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 D5EA98FC15; Tue, 31 Jul 2012 09:25:47 +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 q6V9Pl6E090711; Tue, 31 Jul 2012 05:25:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6V9Plnx090710; Tue, 31 Jul 2012 09:25:47 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 09:25:47 GMT Message-Id: <201207310925.q6V9Plnx090710@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 09:25:48 -0000 TB --- 2012-07-31 06:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 06:20:00 - 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 --- 2012-07-31 06:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-31 06:20:00 - cleaning the object tree TB --- 2012-07-31 06:26:30 - cvsupping the source tree TB --- 2012-07-31 06:26:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-31 06:29:05 - building world TB --- 2012-07-31 06:29:05 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 06:29:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 06:29:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 06:29:05 - SRCCONF=/dev/null TB --- 2012-07-31 06:29:05 - TARGET=i386 TB --- 2012-07-31 06:29:05 - TARGET_ARCH=i386 TB --- 2012-07-31 06:29:05 - TZ=UTC TB --- 2012-07-31 06:29:05 - __MAKE_CONF=/dev/null TB --- 2012-07-31 06:29:05 - cd /src TB --- 2012-07-31 06:29:05 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 06:29:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 09:11:54 UTC 2012 TB --- 2012-07-31 09:11:54 - generating LINT kernel config TB --- 2012-07-31 09:11:54 - cd /src/sys/i386/conf TB --- 2012-07-31 09:11:54 - /usr/bin/make -B LINT TB --- 2012-07-31 09:11:54 - cd /src/sys/i386/conf TB --- 2012-07-31 09:11:54 - /usr/sbin/config -m LINT TB --- 2012-07-31 09:11:54 - building LINT kernel TB --- 2012-07-31 09:11:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 09:11:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 09:11:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 09:11:54 - SRCCONF=/dev/null TB --- 2012-07-31 09:11:54 - TARGET=i386 TB --- 2012-07-31 09:11:54 - TARGET_ARCH=i386 TB --- 2012-07-31 09:11:54 - TZ=UTC TB --- 2012-07-31 09:11:54 - __MAKE_CONF=/dev/null TB --- 2012-07-31 09:11:54 - cd /src TB --- 2012-07-31 09:11:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 09:11:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 09:25:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 09:25:47 - ERROR: failed to build LINT kernel TB --- 2012-07-31 09:25:47 - 6975.59 user 997.05 system 11146.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 10:01:28 2012 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 BC693106564A; Tue, 31 Jul 2012 10:01:28 +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 8B7E18FC14; Tue, 31 Jul 2012 10:01:28 +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 q6VA1S3h073632; Tue, 31 Jul 2012 06:01:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6VA1S67073628; Tue, 31 Jul 2012 10:01:28 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 10:01:28 GMT Message-Id: <201207311001.q6VA1S67073628@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 10:01:28 -0000 TB --- 2012-07-31 06:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 06:20:00 - 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 --- 2012-07-31 06:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-31 06:20:00 - cleaning the object tree TB --- 2012-07-31 06:29:29 - cvsupping the source tree TB --- 2012-07-31 06:29:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-31 06:29:58 - building world TB --- 2012-07-31 06:29:58 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 06:29:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 06:29:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 06:29:58 - SRCCONF=/dev/null TB --- 2012-07-31 06:29:58 - TARGET=amd64 TB --- 2012-07-31 06:29:58 - TARGET_ARCH=amd64 TB --- 2012-07-31 06:29:58 - TZ=UTC TB --- 2012-07-31 06:29:58 - __MAKE_CONF=/dev/null TB --- 2012-07-31 06:29:58 - cd /src TB --- 2012-07-31 06:29:58 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 06:29:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 31 09:51:00 UTC 2012 TB --- 2012-07-31 09:51:00 - generating LINT kernel config TB --- 2012-07-31 09:51:00 - cd /src/sys/amd64/conf TB --- 2012-07-31 09:51:00 - /usr/bin/make -B LINT TB --- 2012-07-31 09:51:00 - cd /src/sys/amd64/conf TB --- 2012-07-31 09:51:00 - /usr/sbin/config -m LINT TB --- 2012-07-31 09:51:00 - building LINT kernel TB --- 2012-07-31 09:51:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 09:51:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 09:51:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 09:51:00 - SRCCONF=/dev/null TB --- 2012-07-31 09:51:00 - TARGET=amd64 TB --- 2012-07-31 09:51:00 - TARGET_ARCH=amd64 TB --- 2012-07-31 09:51:00 - TZ=UTC TB --- 2012-07-31 09:51:00 - __MAKE_CONF=/dev/null TB --- 2012-07-31 09:51:00 - cd /src TB --- 2012-07-31 09:51:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 31 09:51:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/my/if_my.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ncv/ncr53c500_pccard.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors In file included from /src/sys/dev/netmap/netmap.c:99: /src/sys/dev/netmap/netmap_kern.h:84: warning: redundant redeclaration of 'M_NETMAP' [-Wredundant-decls] /src/sys/dev/netmap/netmap.c:95: warning: previous definition of 'M_NETMAP' was here *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 10:01:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 10:01:27 - ERROR: failed to build LINT kernel TB --- 2012-07-31 10:01:27 - 8405.20 user 1320.39 system 13287.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 11:58:41 2012 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 5ECA7106566B for ; Tue, 31 Jul 2012 11:58:41 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D759B8FC14 for ; Tue, 31 Jul 2012 11:58:40 +0000 (UTC) Received: by bkcje9 with SMTP id je9so3245003bkc.13 for ; Tue, 31 Jul 2012 04:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CaSUvGmv/WykUt4G0jyPQo2IxpLAQF/b/PFSEJWCi7o=; b=WBOjo/JprUR3LUQJEXBngoog2NUcc380HRBC+EoqHf+DHtCSsfZJlmb8bsLuCuKvkd zGKpNvPy81vc3v9d1vnCNcBvfuECA0UQOF/5k+fn7BUGcV0vVROfXjKfK+Ya1R6D1Muo SOlYAaiu30vSPsteLQ9Hc1qooZyuI9uxp0+eTb64LGcyiC8E4w2TNfl+CI7sJk41bXI3 OVQgGRRRDIB0iWZ5K9NF6GEWH+IhkD+VThTaWK2B+1IS0QSOHn0OF8mJ0ePXmc6f5VKb VhGDoXXWwWreYMGk76xWAaFjV7G5PPCfy5j+Ip4OjO16MJ+0JXf8ewTtBtooPhW9RO5T QwiA== Received: by 10.205.127.131 with SMTP id ha3mr5258676bkc.123.1343735913804; Tue, 31 Jul 2012 04:58:33 -0700 (PDT) Received: from [192.168.1.80] ([145.236.87.209]) by mx.google.com with ESMTPS id hs2sm5250102bkc.1.2012.07.31.04.58.31 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 04:58:32 -0700 (PDT) Message-ID: <5017C9A4.2010708@gmail.com> Date: Tue, 31 Jul 2012 14:03:48 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120716 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: portupgrade/ruby code error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 11:58:41 -0000 My previous upgrade run was about 2 weeks ago. Today I ran portupgrade (``portupgrade -wfuck <2012-07-31T04:38:00''), but interrupted it (pausing the upgrade process). Later I continued the upgrade process (using the same command line), and got a Ruby script error. The error occurred with portupgrade-2.4.9.6,2 and ruby-1.8.7.370,1. The log is ~: $ portupgrade -wfuck <2012-07-31T04:38:00 [Gathering depends for devel/ice ............ done] [Gathering depends for devel/ORBit2 ................................. done] [Gathering depends for x11/Terminal ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. done] /usr/local/sbin/portupgrade:635:in `main': undefined method `length' for nil:NilClass (NoMethodError) from /usr/local/sbin/portupgrade:633:in `each' from /usr/local/sbin/portupgrade:633:in `main' from /usr/local/sbin/portupgrade:607:in `each' from /usr/local/sbin/portupgrade:607:in `main' from /usr/local/sbin/portupgrade:581:in `catch' from /usr/local/sbin/portupgrade:581:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:1310:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1310:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1306:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1306:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1254:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1254:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1248:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order' from /usr/local/sbin/portupgrade:558:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:791:in `initialize' from /usr/local/sbin/portupgrade:230:in `new' from /usr/local/sbin/portupgrade:230:in `main' from /usr/local/sbin/portupgrade:2245 From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 15:20:59 2012 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 63F45106566B; Tue, 31 Jul 2012 15:20:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 98AFC8FC0C; Tue, 31 Jul 2012 15:20:58 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so5732307wgb.31 for ; Tue, 31 Jul 2012 08:20:57 -0700 (PDT) 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=GmyOKy/keGLKXs3liywoMnftHvIK0XKKEwlU55ylaS8=; b=E39Q/7yJIfIfh7haev6pMzE5nbnn/2Kko2bp6t1vqF9OMuh78qz2kcMt8ysGiDyNK0 e+B4ycVoBr7n47s0gT1W1f4hQI2r748QQKhu7+mCNjbLzqB9aOUSjORh1ESklekDIwy0 ueoteZ7+wsrbZyzWyouhkSWkeLPHyWqcvic3fbO68MKNBuh/C0xp/3h3gRGPTp2eXp0V 6qDiaplyCZK8IVv/59rBq4OrU6VSY53LXQ99fisKGTLRfDGS5TKT2CTXwpFqmHoz6dJf +iis64y2zddBxQV6sMYAx4wHeItC19aOdaatgjrXHu07ZAXWxyvdsVioW2ZZTN8XsCJ1 zxOA== MIME-Version: 1.0 Received: by 10.180.106.137 with SMTP id gu9mr7709594wib.20.1343748057828; Tue, 31 Jul 2012 08:20:57 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Tue, 31 Jul 2012 08:20:57 -0700 (PDT) In-Reply-To: References: <201207301706.02788.jhb@freebsd.org> Date: Tue, 31 Jul 2012 11:20:57 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 15:20:59 -0000 Hi, On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: > [...] We lack that right now, which is why you're trying to shoe-horn the FDT connections into a newbus world and complaining that everything sucks because it is a poor fit. I'd suggest that different mechanisms are necessary. > I'm not trying anything, or at least no longer. I do not see the point working on that when I can not get trivial patches in, especially those fixing poorly maintained drivers, whose issues _do_ affect people. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 16:27:32 2012 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 DD4AE1065672 for ; Tue, 31 Jul 2012 16:27:32 +0000 (UTC) (envelope-from imp@bsdimp.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 946508FC14 for ; Tue, 31 Jul 2012 16:27:32 +0000 (UTC) Received: by obbun3 with SMTP id un3so13958812obb.13 for ; Tue, 31 Jul 2012 09:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=j/znrdXuemTc7vA9FitYbL8AyPYNYWD9eLWCBsHVrg8=; b=dWP8SVH6XoEvE2XU6u4VqUOh7eX8H/ZP+C2wnUv6A7udZeMH2of1blIMXT2KRX7cCk KlS/SiYPRaqXDS5yRMQeB70knrnXXtZwKrFxkLd/WE+n7r6o3AY67kebT12dJJuOJoqX FEjxgMhEIIZ5EFhu6jq3F4jNayW6d5QipR9yp3THDQQHBMkaMMQ3NLMwaU7fCk3ycsm2 Ind7IOy5wWcTUdtq4z0oRyJJ8bH28z6mrowN2Y0jwW3nmvhTAlJeiz2FAVFCE0M4S1hE iULdPZqaDtm1uBp3J8/lfQRLhfUchFfLpOzCoWlZiKHaUL9Pb67RMPgOihswe8rDVRAU ifgw== Received: by 10.182.8.6 with SMTP id n6mr24433295oba.39.1343752051974; Tue, 31 Jul 2012 09:27:31 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id n7sm296700oec.2.2012.07.31.09.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 09:27:31 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 31 Jul 2012 10:27:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207301706.02788.jhb@freebsd.org> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmIMUtJYzpMf7FnCphC8RzL9wd45uIBNAlid+PeHMhOLOAhxxztMSzbx2F9v8CAqCEfQO9i Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 16:27:32 -0000 On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: > Hi, >=20 > On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: >> [...] We lack that right now, which is why you're trying to shoe-horn = the FDT connections into a newbus world and complaining that everything = sucks because it is a poor fit. I'd suggest that different mechanisms = are necessary. >>=20 > I'm not trying anything, or at least no longer. I do not see the point > working on that when I can not get trivial patches in, especially > those fixing poorly maintained drivers, whose issues _do_ affect > people. Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less = and cooperated more, people would be more willing to work with you. Having said that, I'd be happy to help fix this problem. I've not seen = the patches you're talking about, I'd be happy to take a look and try to = get them in, as appropriate. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 19:47:22 2012 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 E7D2C106564A; Tue, 31 Jul 2012 19:47:21 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA158FC0A; Tue, 31 Jul 2012 19:47:20 +0000 (UTC) Received: by weyx56 with SMTP id x56so5567475wey.13 for ; Tue, 31 Jul 2012 12:47:20 -0700 (PDT) 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=eYl4yEqmuUtxh2mK10eZkSuXCFMuNURgdhCXK8v/BhQ=; b=Os8FM5DMTzz9JK7tB+B4aPsRNWg/pMdxr/nSG2kE3RWEDBB9I5F45F2MofeHIYYgSR V7dEoAn6eHgDDm8AcCsWIVluamLfKYtsc5X4qCjHkGZSYDn2DoTx/l7g2CNqlXTiRXAk jLVqnSuVnRxNmRARN0zCk5VLJyND1tyc6LM2zB/0r5JPC9das4uDsvwZlhtnEPVuMDmb AwNbAZ6RNTk61l0T9AxlbwE/YXyTSRRAa79cNrIlzomaCgi4W9JzBpwIY6xcivle6jaP IVl+nf4IdbbZjCJYe1jEBiqNR13RV1pLWvU5WT1GYxybcbyUcVyOEOYOVvQc3DMPWKUu MbBg== MIME-Version: 1.0 Received: by 10.180.91.1 with SMTP id ca1mr5365731wib.8.1343764040093; Tue, 31 Jul 2012 12:47:20 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Tue, 31 Jul 2012 12:47:20 -0700 (PDT) In-Reply-To: References: <201207301706.02788.jhb@freebsd.org> Date: Tue, 31 Jul 2012 15:47:20 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 19:47:22 -0000 Hi, On Tue, Jul 31, 2012 at 12:27 PM, Warner Losh wrote: > > On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: > >> Hi, >> >> On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: >>> [...] We lack that right now, which is why you're trying to shoe-horn the FDT connections into a newbus world and complaining that everything sucks because it is a poor fit. I'd suggest that different mechanisms are necessary. >>> >> I'm not trying anything, or at least no longer. I do not see the point >> working on that when I can not get trivial patches in, especially >> those fixing poorly maintained drivers, whose issues _do_ affect >> people. > > Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less and cooperated more, people would be more willing to work with you. > I tried to be Mr Nice Guy in the past, all I got in return was being ignored. Lists are full of unanswered problem because people do not want to insist getting an answer. Now, believe me on one point, if you are a driver or subsystem author, might I have an issue with your work, I *will* be a recurring pain in your butt to get the issue fixed, or to get in what I do believe, with the limited set of knowledge and resources to my disposal[0], to be a correct fix for the issue, at the time. If you are condescending, arrogant, or advocates of the status-quo, as have been committers in the past, I will return you favor. Let face it, FreeBSD is not the most outstanding OS out there (despite obvious capabilities), and I would not be too proud of its state. All that to say that asking politely does not work in the arbitrary FreeBSD realm, where "the power to serve", is today nothing more that a relic. - Arnaud ps: note that I am ready to be wrong and to be publicly proven so, as it's been the case recently. [0]: which certainly not mean I am wrong, very far from that. > Having said that, I'd be happy to help fix this problem. I've not seen the patches you're talking about, I'd be happy to take a look and try to get them in, as appropriate. > > Warner > From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 19:56:49 2012 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 877E5106566C for ; Tue, 31 Jul 2012 19:56:49 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 1183F8FC17 for ; Tue, 31 Jul 2012 19:56:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=sweb; b=EX1h6FoltS3hXOwv4P8cPLdvs2QvHhKD mmuoL7iI85jVIM23ho6BQ2phK66UMGAMLATBsoDmnuG/oKiNDa/6Dl6+WQro62Ba oLMqlWoV+7C6rq9qtgvoQFRS56VvEK9DRRJ1xLpJKBHHHAfM5fFsL7Ib/4Wzup0V JAkqApXb1IU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=sweb; bh=fpTFKpKFFTLDvim3yyV3dlSQFhQskI4HaL0Gly C3BVI=; b=wWE06q8N5Z6yuyR5umAQ+ZKd6Y+lccLZGNoRB8ZGoExvpFx8MfYNZe mbA+g+l9a8rrLVOmnS9Y1FQ0NmSe8aSgtEmye06/Uz2hUyNep5n1Nan6VBkAhRS5 8ybLWzxnccsAy6ycYvJ6/wvwCRSjwDqGSsXHvqsiH/mWXr6+a3xNE= Received: (qmail 73634 invoked from network); 31 Jul 2012 14:56:47 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 31 Jul 2012 14:56:47 -0500 Message-ID: <50183881.5080503@shatow.net> Date: Tue, 31 Jul 2012 14:56:49 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: deeptech71@gmail.com References: <5017C9A4.2010708@gmail.com> In-Reply-To: <5017C9A4.2010708@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1789B03952DBF3FF8EBBDBF1" Cc: ports@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: portupgrade/ruby code error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jul 2012 19:56:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1789B03952DBF3FF8EBBDBF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/31/2012 7:03 AM, deeptech71@gmail.com wrote: > My previous upgrade run was about 2 weeks ago. Today I ran portupgrade > (``portupgrade -wfuck <2012-07-31T04:38:00''), but interrupted it > (pausing the upgrade process). Later I continued the upgrade process > (using the same command line), and got a Ruby script error. >=20 > The error occurred with portupgrade-2.4.9.6,2 and ruby-1.8.7.370,1. This crash was fixed in 2.4.9.7, released yesterday. --=20 Regards, Bryan Drewery bdrewery@freenode/EFNet --------------enig1789B03952DBF3FF8EBBDBF1 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 Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQGDiGAAoJEG54KsA8mwz5RLYQAIf1/GR4pRVE0gimwjZfb0LA afo7FzzWqMwBDVA6PRIQSCtdtICbLYPujGzmHdEH3Ui3AJLt8pmHq+i2X5WIsO6s K8m59uCgwigWwOqz1xA+0qyikTFMy7V0eeUrhiNhPKCWIdbvovyoOVC49NYEzNk7 SxD1xCuCHspOEkNq9QbpgcAZ0HuG0CFTLG7/ZEBhzdOMxT0Nn6fy6wpekZJxC+jm K69CczPc4V4WNXJfDHqFGdkQnkGkX95+i5r39W4IJ5ghVuNp/XWsIB7FYxM4Eb2J PkTB1F4gcZG4Z9aHiaLOI6yNtIqMfbn2o916aUaNJlDqDsBiAEk42JKI4hKHH2eV I1AJpTbTCuC3dLh0MhhfQILp5b4AyRCl/kcmw/xQdjt2f7PKNQhj7EQk9k6GiSLA 9FA8zG81/7r34Gw2iYRs4b1B4gY41/HXrukb8J9pcCsvRhsOzYvHe6U6+kFYhRtd A4SAm6g8NRzK62Gwxzhl/+8bezQAT87mafbny4XilHVdmZqezOW8HcL1rD7UKyM1 EqE4z8kagW7lRkgFzuowLumHXAtzssP74K7bZouIx7KFw8HxpGvMwlbR9xjHF4lY NgBtVfHA1S4yWNj0pdDfhj27T8a8i7FJ3pxCk7Hk6aIerfXdncc9iptBkmLvV1qg YDENFwS64V87aST7C3oW =fGzM -----END PGP SIGNATURE----- --------------enig1789B03952DBF3FF8EBBDBF1-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 20:14:29 2012 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 1386A1065670; Tue, 31 Jul 2012 20:14:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50F3F8FC0A; Tue, 31 Jul 2012 20:14:28 +0000 (UTC) Received: by lbon10 with SMTP id n10so5272904lbo.13 for ; Tue, 31 Jul 2012 13:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=47UrBOJDYSbPz2s2ugNJs9E6pTG7sNjNhAUwQlfkybc=; b=qtLUAS/vp0z7gBmVc3ESra4WAoXbbgEHY5OYptL3QCs/c5xTJ2VlP0Cr3DVAZCFPs5 cidpl63Y5vXvr7XVcUhMG6JG/NKe5ckDu4WxW6XDPPAPEWpZsk0gvRVSWN083K0QCehh BrNlwWgkSOZab+FC/OlBDznbPl0pgl6Ws1gFlXoMOMjtmIqOWkwjYbp5QeleL0s/fojk QVlP5/uvvUF21DX4vDUw2eesOUR7LUC7uUmSZ2CF66EdqZNUOqR6YKdonbRJPm/Q4u0t vm3mi617zyg/ZPkBUeyw14B23zghWkMF1ACArEKpjNa+Ev3Z5zXjEA6Bg05i6tycu30V iaCA== MIME-Version: 1.0 Received: by 10.112.11.100 with SMTP id p4mr7247166lbb.35.1343765667060; Tue, 31 Jul 2012 13:14:27 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Tue, 31 Jul 2012 13:14:26 -0700 (PDT) In-Reply-To: References: <201207301706.02788.jhb@freebsd.org> Date: Tue, 31 Jul 2012 21:14:26 +0100 X-Google-Sender-Auth: lvT5vYIH5XgrNU6hqL6JEQudXpY Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:14:29 -0000 On Tue, Jul 31, 2012 at 8:47 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Jul 31, 2012 at 12:27 PM, Warner Losh wrote: >> >> On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: >>>> [...] We lack that right now, which is why you're trying to shoe-horn the FDT connections into a newbus world and complaining that everything sucks because it is a poor fit. I'd suggest that different mechanisms are necessary. >>>> >>> I'm not trying anything, or at least no longer. I do not see the point >>> working on that when I can not get trivial patches in, especially >>> those fixing poorly maintained drivers, whose issues _do_ affect >>> people. >> >> Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less and cooperated more, people would be more willing to work with you. >> > I tried to be Mr Nice Guy in the past, all I got in return was being > ignored. Lists are full of unanswered problem because people do not > want to insist getting an answer. Now, believe me on one point, if you > are a driver or subsystem author, might I have an issue with your > work, I *will* be a recurring pain in your butt to get the issue > fixed, or to get in what I do believe, with the limited set of > knowledge and resources to my disposal[0], to be a correct fix for the > issue, at the time. If you are condescending, arrogant, or advocates > of the status-quo, as have been committers in the past, I will return > you favor. Let face it, FreeBSD is not the most outstanding OS out > there (despite obvious capabilities), and I would not be too proud of > its state. > > All that to say that asking politely does not work in the arbitrary > FreeBSD realm, where "the power to serve", is today nothing more that > a relic. Arnaud, the problem I see here is that as always you make strong and false claims on bugs and missing support from FreeBSD kernel, but when people points out what are you missing/misunderstanding, you turn the whole thread into "FreeBSD is a relic" baby-whining, without replying with real technical arguments and simply ignoring e-mail by freebsd developers. I didn't see any response from you to several technical e-mail in this threads and others (please don't force me to open mailman and show exactly all the responses you have deliberately ignored), spitting unrespectful, poison-weighted words on developers of our project. You don't want to work cooperatively. You don't want to build something with FreeBSD community. So why you keep insist on sending e-mail like this? Don't you think it would be more productive for you to stick with another project? (I have a couple of names into my head that may be a good fit for you...). I think it is very offensive that you mock our statement like that. For many people reading this e-mail it has a true meaning, people like you should really watch his mouth when speaking about FreeBSD. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jul 31 23:58:21 2012 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 B53A7106566C; Tue, 31 Jul 2012 23:58:21 +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 8686A8FC0A; Tue, 31 Jul 2012 23:58:21 +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 q6VNwFnX050094; Tue, 31 Jul 2012 19:58:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6VNwF0b050093; Tue, 31 Jul 2012 23:58:15 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 31 Jul 2012 23:58:15 GMT Message-Id: <201207312358.q6VNwF0b050093@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:58:21 -0000 TB --- 2012-07-31 22:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-31 22:50:00 - 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 --- 2012-07-31 22:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-31 22:50:00 - cleaning the object tree TB --- 2012-07-31 22:50:00 - cvsupping the source tree TB --- 2012-07-31 22:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-31 22:52:25 - building world TB --- 2012-07-31 22:52:25 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 22:52:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 22:52:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 22:52:25 - SRCCONF=/dev/null TB --- 2012-07-31 22:52:25 - TARGET=arm TB --- 2012-07-31 22:52:25 - TARGET_ARCH=arm TB --- 2012-07-31 22:52:25 - TZ=UTC TB --- 2012-07-31 22:52:25 - __MAKE_CONF=/dev/null TB --- 2012-07-31 22:52:25 - cd /src TB --- 2012-07-31 22:52:25 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 31 22:52:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 31 23:54:48 UTC 2012 TB --- 2012-07-31 23:54:48 - cd /src/sys/arm/conf TB --- 2012-07-31 23:54:48 - /usr/sbin/config -m ATMEL TB --- 2012-07-31 23:54:48 - building ATMEL kernel TB --- 2012-07-31 23:54:48 - CROSS_BUILD_TESTING=YES TB --- 2012-07-31 23:54:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-31 23:54:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-31 23:54:48 - SRCCONF=/dev/null TB --- 2012-07-31 23:54:48 - TARGET=arm TB --- 2012-07-31 23:54:48 - TARGET_ARCH=arm TB --- 2012-07-31 23:54:48 - TZ=UTC TB --- 2012-07-31 23:54:48 - __MAKE_CONF=/dev/null TB --- 2012-07-31 23:54:48 - cd /src TB --- 2012-07-31 23:54:48 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Jul 31 23:54:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91_rst.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91_rtc.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91_spi.c /src/sys/arm/at91/at91_spi.c: In function 'at91_spi_transfer': /src/sys/arm/at91/at91_spi.c:294: error: 'struct spi_command' has no member named 'cs' /src/sys/arm/at91/at91_spi.c:294: error: 'struct spi_command' has no member named 'cs' /src/sys/arm/at91/at91_spi.c:296: error: 'struct spi_command' has no member named 'cs' /src/sys/arm/at91/at91_spi.c:316: error: 'struct spi_command' has no member named 'cs' *** Error code 1 Stop in /obj/arm.arm/src/sys/ATMEL. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-31 23:58:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-31 23:58:15 - ERROR: failed to build ATMEL kernel TB --- 2012-07-31 23:58:15 - 2634.23 user 600.47 system 4094.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 16:03:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5500B1065670; Wed, 1 Aug 2012 16:03:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E08A38FC0A; Wed, 1 Aug 2012 16:03:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q71G3aiY026500; Wed, 1 Aug 2012 19:03:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q71G3NZr073885; Wed, 1 Aug 2012 19:03:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q71G3Nfj073884; Wed, 1 Aug 2012 19:03:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Aug 2012 19:03:23 +0300 From: Konstantin Belousov To: current@freebsd.org Message-ID: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K21AJ9EWb/UqY1dh" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: ed@freebsd.org Subject: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 16:03:28 -0000 --K21AJ9EWb/UqY1dh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Long story, the summary is in last two paragraphs] I use several APC UPS some of which are connected by the USB<->serial dongle. Said USBs very much like to drop from the USB bus on a smallest power glitch. Today I noted that a machine dropped UPS serial USB device, and did not reattached it. More, attempt to show the list of the USB devices resulted in usbconfig locking hard: tom% sudo usbconfig list ~ load: 0.00 cmd: usbconfig 76210 [USB config SX lock] 4.63r 0.00u 0.00s 1% 1000k ^C^C load: 0.07 cmd: usbconfig 76210 [USB config SX lock] 33.87r 0.00u 0.00s 0% 1000k Quick inspection of the said sx revealed that the owner of the lock is the kernel thread, with the backtrace 84 100089 usb usbus3 mi_switch+0x184 sleepq_wait+0x42 _cv_wait+0x11e ucom_detach+0x142 uplcom_detach+0x20 device_detach+0x74 usb_detach_device+0x4a usb_unconfigure+0x34 usb_free_device+0x166 uhub_explore+0x12e usb_bus_explore+0xd2 usb_process+0x9b fork_exit+0x11f fork_trampoline+0xe Apparently, in ucom_detach_tty(), the condition sc->sc_ttyfreed == 0 was not satisfied because apcupsd has a thread inside a tty devsw method, which prevented the destroy_dev_sched from succeeding and the wait hang almost forever. More, the Giant taskqueue was stopped due to stuck job. Killing apcupsd, which slept interruptible, allowed the tty destruction to proceed and freed USB config SX. This unwedged the USB subsystem and machine become fully functional again. I would blame tty subsystem rather then USB subsystem. The d_purge method of the ttydev_cdevsw is not implemented, but it is the only measure that can break the deadlocks like the one I described. The d_purge shall wake up threads sleeping inside devsw methods, which was specifically added to notify driver about device gone events. I am sorry for not catching the backtrace for the apcupsd itself, since it was only afterthought that apcupsd is interesting part of the deadlock. I am sure that it was not poll() which was entered by apcupsd, most likely it was read/write or some termios ioctl. --K21AJ9EWb/UqY1dh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAZU0oACgkQC3+MBN1Mb4hviACcDU8f2SUrI7ghu0033uSrvfq7 QacAnR8/H4tkKnYXyJRDr8NZDo+2KX3B =dfle -----END PGP SIGNATURE----- --K21AJ9EWb/UqY1dh-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 16:32:58 2012 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 0296E1065796; Wed, 1 Aug 2012 16:32:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1468FC08; Wed, 1 Aug 2012 16:32:55 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so6848658wgb.31 for ; Wed, 01 Aug 2012 09:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=QOKgZqLaGgIf29vP15vsJx5sPCeS8WiVIdH4X20oxtk=; b=SGV/fYv6w9JslqQof6/qWmT3CC4ZMhpcVOzuA9yZ/fR33HS8G1J41pu5VUkOVn3y6l W76XyqHGHJbsT1UIQPh+RY8XmWb/VCpMAAWg3JjuZ+vQLt0zoBjL6hvvZeFlxEH84lGZ vm/O072Ti/Cu7CAdPcllSjgPGU+u5RzYDJZcIufvr9sl7IqqVhF44SvEfsAofR/6KFQT mss2gUj2v2PfFKvlhxSYyQVgcuaF/m1z1mUF7zDN18NTOS8OjabKHQjzVPFFyJWcjdMT FEC8T2mzo2UXkbJtHE6He8WT/GRJxXzPPyqqxhurD6tXA0lsM4BLmHzrtyaWgGPVDJby kxAw== MIME-Version: 1.0 Received: by 10.217.0.75 with SMTP id k53mr8785733wes.214.1343838769094; Wed, 01 Aug 2012 09:32:49 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Wed, 1 Aug 2012 09:32:49 -0700 (PDT) Date: Wed, 1 Aug 2012 12:32:49 -0400 Message-ID: From: Arnaud Lacombe To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 16:32:58 -0000 Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: > > You don't want to work cooperatively. > Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 16:40:17 2012 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 63D21106566B; Wed, 1 Aug 2012 16:40:17 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A3B7A8FC12; Wed, 1 Aug 2012 16:40:16 +0000 (UTC) Received: by laai10 with SMTP id i10so5797543laa.13 for ; Wed, 01 Aug 2012 09:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tYRg3Cq0Y8NZLSuwk5ohIqqqTovz08AkeFSye68OsPM=; b=gaXCJqKSpGZRnoQa6fajoxh44Fuh2Yl2MMIXNO7B2RlmMOmI5jMQZ1bjE/vErB7nuq aVyRuiEvUgu4krUVQSiatZ27LzCn/tCCpWPMS/14ezVbkEIW/AxMqE2ytqkKSfjEWo+h EhohKQaF1cUOId8d6ucv826Umlf1sWBcbFRNDbEVtqujDno69yu9dacTFIA2L241j62w QxTWyX1RE1PCiX+4NLTg3PHpvDdi48uaVFwdXuDhcgNcSS3O+Y0lYp5swfvUmyAhY4RM LMBB+KjP/x9Uy0XDnsrGI1+DsyY7gqs01wRyYlt3W2Lmj2WP6sHLhpCW9BUweKwMShxe ekpA== MIME-Version: 1.0 Received: by 10.152.131.9 with SMTP id oi9mr18488685lab.39.1343839215238; Wed, 01 Aug 2012 09:40:15 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 1 Aug 2012 09:40:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 17:40:15 +0100 X-Google-Sender-Auth: wO7F85j8seZVw0Su8m2kihdTn9U Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:40:17 -0000 On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >> >> You don't want to work cooperatively. >> > Why is it that mbuf's refactoring consultation is being held in > internal, private, committers-and-invite-only-restricted meeting at > BSDCan ? > > Why is it that so much review and discussion on changes are held privately ? Arnaud, belive me, to date I don't recall a single major technical decision that has been settled exclusively in private (not subjected to peer review) and in particular in person (e-mail help you focus on a lot of different details that you may not have under control when talking to people, etc). Sometimes it is useful that a limited number of developers is involved in initial brainstorming of some works, but after this period constructive people usually ask for peer review publishing their plans on the mailing lists or other media. If you don't see any public further discussion this may be meaning: a) the BSDCan meetings have been fruitless and there is no precise plan/roadmap/etc. b) there is still not consensus on details and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 17:05:15 2012 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 C0A75106566C; Wed, 1 Aug 2012 17:05:15 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id EF6238FC1C; Wed, 1 Aug 2012 17:05:14 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so3301634wib.13 for ; Wed, 01 Aug 2012 10:05:08 -0700 (PDT) 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=vKqyBBbtlOQ8J+CIkvkglPLj/fF5b2mywAuC9aAJObk=; b=gr122OREYMqendZoEgCImt0uOknHtez/RiF6lxN2Fu6wXhzHOAGjgn/7aJaxpy81pb JwO2HCqDlnU/kgZp9z4ah/zFh/fqb3gNgRmUGn+YgVpocu0FWiqS8ilD6+NyedJu46Fc YfQgwLHEsIRN4tC0xeVRRAG/sMyukt7DUM7AzPxFNLwMUYJblbMOfWqbbqHuworLEa+Z YvDC4MOy3Fz1Rln60NZ0KYMLmpxtdyaD9jQ3QcqyIpFPOBmvDsUJSOn+T9MtD7pMa12f I9NwAVZxHr3Ah7TWbW5X6IAECT9rxPXpjqvIM6VAme+IkHUB+ZneqD9O+PQM6nMxo+yR HBmQ== MIME-Version: 1.0 Received: by 10.180.85.167 with SMTP id i7mr18049853wiz.8.1343840708438; Wed, 01 Aug 2012 10:05:08 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Wed, 1 Aug 2012 10:05:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 13:05:08 -0400 Message-ID: From: Arnaud Lacombe To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 17:05:16 -0000 Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >>> >>> You don't want to work cooperatively. >>> >> Why is it that mbuf's refactoring consultation is being held in >> internal, private, committers-and-invite-only-restricted meeting at >> BSDCan ? >> >> Why is it that so much review and discussion on changes are held privately ? > > Arnaud, > belive me, to date I don't recall a single major technical decision > that has been settled exclusively in private (not subjected to peer > review) and in particular in person (e-mail help you focus on a lot of > different details that you may not have under control when talking to > people, etc). > Whose call is it to declare something worth public discussion ? No one. Every time I see a "Suggested by:", "Submitted by:", "Reported by:", and especially "Approved by:", there should to be a public reference of the mentioned communication. > Sometimes it is useful that a limited number of developers is involved > in initial brainstorming of some works, > Never. > but after this period > constructive people usually ask for peer review publishing their plans > on the mailing lists or other media. > Again, never. By doing so, you merely put the community in a situation where, well, "We, committers, have come with this, you can either accept or STFU, but no major changes will be made because we decided so." The callout-ng conference at BSDCan was just beautiful, it was basically: Speaker: "we will do this" Audience: "how about this situation ? What you will do will not work." Speaker: "thank you for listening, end of the conference" It was beautiful to witness. > If you don't see any public further discussion this may be meaning: > a) the BSDCan meetings have been fruitless and there is no precise > plan/roadmap/etc. > so not only you make it private, but it shamelessly failed... > b) there is still not consensus on details > Then the discussion should stop, public records are kept for reference in the future. There is no problem with this. > and you can always publically asked on what was decided and what not. > Just send a mail to interested recipients and CC any FreeBSD mailing > list. > This is not the way "openness" should be about. - Arnaud > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 18:18:31 2012 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 9353E106564A; Wed, 1 Aug 2012 18:18:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B9F018FC0C; Wed, 1 Aug 2012 18:18:30 +0000 (UTC) Received: by laai10 with SMTP id i10so5864706laa.13 for ; Wed, 01 Aug 2012 11:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G58ahDoqZx5DAM/xsRJp7ktRMO8AKxr+HV1yF2sEYL8=; b=LbQyQ+O4fpqVqC9+QBBoS0ZSV6C8NaNedi+86kFrLtvycOjkKhSyWglcW8bj6Ygyms UxhujsG9T5zf0LPOF7H/2axRe2j7d7YYLncBujD/I9723K4ZtlNzy27AMtXL375Gjaqs 721YD7wwmFf+exivBRfFW4QLIEGXbnUmV8Y/gRAf93E7tSTwWx7TjVDCzy2SdZAjjqqE P361NSdbShx/LUciv8habDMX0GwoLD78tbmml5i6Su/PX2WTcTubpsAj8Dk96Xv2wnGK i75He9Ak94orpcrpk3QPaFCKv6xFkL1aqiXxp5UNGKRyZqjQRu6ImcQprIK3+y2MDows 9QbQ== MIME-Version: 1.0 Received: by 10.112.42.34 with SMTP id k2mr8582422lbl.0.1343845109200; Wed, 01 Aug 2012 11:18:29 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 1 Aug 2012 11:18:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 19:18:28 +0100 X-Google-Sender-Auth: cO2Hq5cflnC0rxHVHrVm193MuaU Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 18:18:31 -0000 On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >> wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao >>> wrote: >>>> >>>> You don't want to work cooperatively. >>>> >>> Why is it that mbuf's refactoring consultation is being held in >>> internal, private, committers-and-invite-only-restricted meeting at >>> BSDCan ? >>> >>> Why is it that so much review and discussion on changes are held >>> privately ? >> >> Arnaud, >> belive me, to date I don't recall a single major technical decision >> that has been settled exclusively in private (not subjected to peer >> review) and in particular in person (e-mail help you focus on a lot of >> different details that you may not have under control when talking to >> people, etc). >> > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. Not necessarilly. Every developer must ensure to produce a quality work, with definition of "quality" being discretional. Some people fail this expectation, while others do very good. As a general rule, some people send patches to experts on the matter and they just trust their judgment, others also full-fill testing cycles by thirdy part people, others again ask for public reviews. Often this process is adapted based on the dimension of the work and the number of architectural changes it introduces. As a personal matter, for a big architectural change things I would *personally* do are: - Prepare a master-plan with experts of the matter - Post a plan (after having achived consensus) on the public mailing list for further discussions - Adjust the plan based on public feedbacks (if necessary) - Implement the plan - Ask the experts if they have objections to the implementation - Ask testers to perform some stress-testing - Ask testers to perform benchmark (if I find people interested in that) - Send out to the public mailing list for public review - Integrate suggestions - Ask testers to stress-test again - Commit I think this model in general works fairly well, but people may have different ideas on that, meaning that people may want to not involve thirdy part for testing or review. This is going to be risky and lower the quality of their work but it is their call. >> Sometimes it is useful that a limited number of developers is involved >> in initial brainstorming of some works, >> > Never. > >> but after this period >> constructive people usually ask for peer review publishing their plans >> on the mailing lists or other media. >> > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." You are forgetting one specific detail: you can always review a work *after* it entered the tree. This is something you would never do, but sometimes, when poor quality code is committed there is nothing else you can do than just raise your concern after it is in. > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. Not sure if you realized but I was what you mention "Audience". I think you are referring to a specific case where a quick heads-up on a summer of code project has been presented, you cannot really believe all the technical discussion around FreeBSD evolve this way. >> If you don't see any public further discussion this may be meaning: >> a) the BSDCan meetings have been fruitless and there is no precise >> plan/roadmap/etc. >> > so not only you make it private, but it shamelessly failed... And so? I think you have a wrong point of view of what is shamelessly... I'm working on the same project since 6 months, i thought I could finish it in 1 but then I understood that in order to get the quality I was hoping I had to do more work... does it qualify as failed, according to your standard? >> b) there is still not consensus on details >> > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > >> and you can always publically asked on what was decided and what not. >> Just send a mail to interested recipients and CC any FreeBSD mailing >> list. >> > This is not the way "openness" should be about. There is not much more you can do when people don't share details and discussions automatically. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 19:45:38 2012 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 4FBCE106564A; Wed, 1 Aug 2012 19:45:38 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5758FC0A; Wed, 1 Aug 2012 19:45:37 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so7004548wgb.31 for ; Wed, 01 Aug 2012 12:45:35 -0700 (PDT) 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=SzedmssDr5OQGcpPEtLAFzoUsa7MPo7YTp08DpRTa7Q=; b=bAvtTEHO0SQ2UNPmaOC1FObfNACRfdwp+kVbnRLWieJQqs+c4jpFtHxybyB4lQkY94 BJBmT7IVZ7T1NTKSqBTIloMVPpZPt1ZwCBVqVCAT6RoFGolN8/3tJObIqpBM+L4Ai6ur VfhVdFzrBAZr7xym8cqUev27PVt0wkOBCsLiaQ3e1A+03qlHqdyvqVQTaHc0UFbSpmSy vPedIQZ63Ji1scIsk2Zsi5kcRru1T14se1B0VGcv/Rt693iYEKa/tVDk6fyS0ScppQ4d 7SXvbLepA90498wa6kqV5+AotIEwMqysumtghTTMEx3MKtDKzidx9Eo5azJwGlDZs5UA vFmw== MIME-Version: 1.0 Received: by 10.180.81.66 with SMTP id y2mr18959943wix.22.1343850335435; Wed, 01 Aug 2012 12:45:35 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Wed, 1 Aug 2012 12:45:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 15:45:35 -0400 Message-ID: From: Arnaud Lacombe To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 19:45:38 -0000 Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: > On 8/1/12, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >>> wrote: >>>> Hi, >>>> >>>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao >>>> wrote: >>>>> >>>>> You don't want to work cooperatively. >>>>> >>>> Why is it that mbuf's refactoring consultation is being held in >>>> internal, private, committers-and-invite-only-restricted meeting at >>>> BSDCan ? >>>> >>>> Why is it that so much review and discussion on changes are held >>>> privately ? >>> >>> Arnaud, >>> belive me, to date I don't recall a single major technical decision >>> that has been settled exclusively in private (not subjected to peer >>> review) and in particular in person (e-mail help you focus on a lot of >>> different details that you may not have under control when talking to >>> people, etc). >>> >> Whose call is it to declare something worth public discussion ? No one. >> >> Every time I see a "Suggested by:", "Submitted by:", "Reported by:", >> and especially "Approved by:", there should to be a public reference >> of the mentioned communication. > > Not necessarilly. Every developer must ensure to produce a quality > work, with definition of "quality" being discretional. Some people > fail this expectation, while others do very good. As a general rule, > some people send patches to experts on the matter and they just trust > their judgment, others also full-fill testing cycles by thirdy part > people, others again ask for public reviews. Often this process is > adapted based on the dimension of the work and the number of > architectural changes it introduces. > > As a personal matter, for a big architectural change things I would > *personally* do are: > - Prepare a master-plan with experts of the matter > - Post a plan (after having achived consensus) on the public mailing > list for further discussions > - Adjust the plan based on public feedbacks (if necessary) > - Implement the plan > - Ask the experts if they have objections to the implementation > - Ask testers to perform some stress-testing > - Ask testers to perform benchmark (if I find people interested in that) > - Send out to the public mailing list for public review > - Integrate suggestions > - Ask testers to stress-test again > - Commit > > I think this model in general works fairly well, > I agree. > but people may have > different ideas on that, meaning that people may want to not involve > thirdy part for testing or review. This is going to be risky and lower > the quality of their work but it is their call. > >>> Sometimes it is useful that a limited number of developers is involved >>> in initial brainstorming of some works, >>> >> Never. >> >>> but after this period >>> constructive people usually ask for peer review publishing their plans >>> on the mailing lists or other media. >>> >> Again, never. By doing so, you merely put the community in a situation >> where, well, "We, committers, have come with this, you can either >> accept or STFU, but no major changes will be made because we decided >> so." > > You are forgetting one specific detail: you can always review a work > *after* it entered the tree. This is something you would never do, but > sometimes, when poor quality code is committed there is nothing else > you can do than just raise your concern after it is in. > Unfortunately, not. First, the developer will certainly have moved on after the commit, API may have been changed tree-wide, etc. Then, time is likely to have passed between the time you figure potential regression or bugs, which makes the first point even more problematic. Finally, if my point of view is being ignored *before* it goes to the tree, do you really expect it will be considered *after* ? >From my external point of view, committers not only have the possibility, but *do* commit mess in the tree without non-committers could say or do anything, just as well as committers being able to arbitrarily close PR even if the original reporter disagree. >> The callout-ng conference at BSDCan was just beautiful, it was basically: >> >> Speaker: "we will do this" >> Audience: "how about this situation ? What you will do will not work." >> Speaker: "thank you for listening, end of the conference" >> >> It was beautiful to witness. > > Not sure if you realized but I was what you mention "Audience". I > think you are referring to a specific case where a quick heads-up on a > summer of code project has been presented, you cannot really believe > all the technical discussion around FreeBSD evolve this way. > indeed, but that was still the case back then. >>> If you don't see any public further discussion this may be meaning: >>> a) the BSDCan meetings have been fruitless and there is no precise >>> plan/roadmap/etc. >>> >> so not only you make it private, but it shamelessly failed... > > And so? I think you have a wrong point of view of what is > shamelessly... I'm working on the same project since 6 months, i > thought I could finish it in 1 but then I understood that in order to > get the quality I was hoping I had to do more work... does it qualify > as failed, according to your standard? > not specifically, but at the end of that project of your, I would run a post-mortem meeting to see what went correctly and where things got out-of-control. As for the mbuf meeting, all I can find from it online is: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html which is not worth much... Rather than doing things internally, maybe it is time to open up... oh, wait, you will certainly come to the community with a design plan, figure out it's not gonna work while doing the implementation, change the design plan while implementing, go public with a +3k/-2k loc change patch, ask for benediction, go ahead and commit it up until someone comes with an obvious design flaw which would render the change pretty much useless, but there will be man-month of work to fix it, so it's never gonna be done. One obvious problem in FreeBSD is that committers are prosecutor, judge and jury altogether. That's not the first time I point this out. >>> b) there is still not consensus on details >>> >> Then the discussion should stop, public records are kept for reference >> in the future. There is no problem with this. >> >>> and you can always publically asked on what was decided and what not. >>> Just send a mail to interested recipients and CC any FreeBSD mailing >>> list. >>> >> This is not the way "openness" should be about. > > There is not much more you can do when people don't share details and > discussions automatically. > keep reporting regressions, interface flaws, POLA violations, ABI breakages, bugs, etc. - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 19:57:10 2012 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 5743E1065673; Wed, 1 Aug 2012 19:57:10 +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 11EE38FC17; Wed, 1 Aug 2012 19:57:09 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Swf2b-0007Ez-5l; Wed, 01 Aug 2012 20:57:09 +0100 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 1Swf2a-0004GM-V1; Wed, 01 Aug 2012 20:57:09 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q71Jv8QL020512; Wed, 1 Aug 2012 20:57:08 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q71Jv83U020511; Wed, 1 Aug 2012 20:57:08 +0100 (BST) (envelope-from mexas) Date: Wed, 1 Aug 2012 20:57:08 +0100 (BST) From: Anton Shterenlikht Message-Id: <201208011957.q71Jv83U020511@mech-cluster241.men.bris.ac.uk> To: attilio@freebsd.org, lacombar@gmail.com In-Reply-To: Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 19:57:10 -0000 Date: Wed, 1 Aug 2012 15:45:35 -0400 From: Arnaud Lacombe One obvious problem in FreeBSD is that committers are prosecutor, judge and jury altogether. As a user, I accept this. I think if you can make a meaningful contribution to FreeBSD developments in the design stages, then become a committer. Otherwise contribute as a user - testing and bug reports mainly. From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 20:06:37 2012 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 49352106564A; Wed, 1 Aug 2012 20:06:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB5928FC12; Wed, 1 Aug 2012 20:06:36 +0000 (UTC) Received: by yhfs35 with SMTP id s35so9061041yhf.13 for ; Wed, 01 Aug 2012 13:06:36 -0700 (PDT) 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=Is6cPwt7vJ/s0rgBzxY7fLBUAGUg4QECfF2MJHD5oZQ=; b=I9ce32TIWABSLm6xmlb3bxnBGcYvJAEbO5yGSjCOo2Or50HekqfMatOg08Xoyg0aV3 b4rQi8zJdOEH/upydQDWqpa2ubMR8eJAj+UK50RcERxYZwxLqUiY1jFc9x+Ir9ZSr52D VVFtB6/Sh5Pg2HQl65HQDqEz5Iv3M0JokWgcelS4vg3gg2fSyIcj1EQY5eM+pUcY9R7B 5bxIv2m6Zj5orbgbZSscRCt3x8yUq4Kxg12JA6q/zlTpBTp5IJgsi9CPq5lniqhqkzfj hZMsnuUHDzz6Abbr0Cp3UgXsNvNnmAIPi4vhxoR1vhZ7PkVw/5nKaG/NfRByPO63A2rn oRmQ== MIME-Version: 1.0 Received: by 10.68.241.35 with SMTP id wf3mr54296461pbc.102.1343851595611; Wed, 01 Aug 2012 13:06:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Wed, 1 Aug 2012 13:06:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 13:06:35 -0700 X-Google-Sender-Auth: NTpezFgf4Vm_WCq6Jy4M026hHYU Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 20:06:37 -0000 Any interested party is very welcome to approach a developer and get added to the developer summits. Plenty of the people at the most recent developer summit weren't @freebsd.org committers - we had plenty of representation from companies using FreeBSD. If you want to participate, just ask a friendly developer who is going to the developer summit to sponsor you in going. You're pleasant in person, so I'd have no problem sponsoring you if I am going to an event. :) And/or, work with warner to get improvements into the tree and someone will sponsor a commit bit for you. Perhaps we as developers should more openly publish the results of developer summits. But as I said, they're not "closed" - they're just "invite only for non-developers." We're not going to exclude anyone from coming unless they really ARE going to just sit there and troll. You're motivated, you're enthusiastic and you want to see things change for the better. You're also not confrontational in person. I have no problem with you coming along. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 20:32:46 2012 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 445F21065672; Wed, 1 Aug 2012 20:32:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84D728FC0A; Wed, 1 Aug 2012 20:32:45 +0000 (UTC) Received: by lbbgm13 with SMTP id gm13so334638lbb.13 for ; Wed, 01 Aug 2012 13:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ifULWAoBuNT4o/8MD2e+KyORQdnC4kFyou11I4f8xFM=; b=QYMYYT6vSbG0dcjFgbLBtRaoHiGZlwkn33uu6KvlSj5zX62gF/5XlSGIRTXzv/msMN OwykkGCU/DnfLvFUEb16EQ55WRhj+2Nq1TsR9KMxY643OAP7CfE5UEdwaDtj2KM4o5yX YCoRFWTRAz1NVFfCOH6hHcPjm02DefviDgafSBtV/2aRTBRvm2cL3ToygeK3lmGA/l+c sXiyjCaTWJVobcCTvNqOIyWFuVqVfiyXsCuI/RXFplXjnVIbF3Tj/emPbMv+zBYDTyz3 FLjG6SOiJUvwEPhVvfEHb1xH+++K8iPTWJI+EAVZAOGPmPi3amHM8WT7jouF3yyEvqdv UhZQ== MIME-Version: 1.0 Received: by 10.112.11.100 with SMTP id p4mr8684940lbb.35.1343853164343; Wed, 01 Aug 2012 13:32:44 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Wed, 1 Aug 2012 13:32:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 21:32:44 +0100 X-Google-Sender-Auth: nrVUHQjaUP-1g3h8Q92MNdaj7e8 Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:32:46 -0000 On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: [ trimm ] >> You are forgetting one specific detail: you can always review a work >> *after* it entered the tree. This is something you would never do, but >> sometimes, when poor quality code is committed there is nothing else >> you can do than just raise your concern after it is in. >> > Unfortunately, not. First, the developer will certainly have moved on > after the commit, API may have been changed tree-wide, etc. Then, time > is likely to have passed between the time you figure potential > regression or bugs, which makes the first point even more problematic. > Finally, if my point of view is being ignored *before* it goes to the > tree, do you really expect it will be considered *after* ? There is one thing you are not considering: committers are as powerless as non-committers in face of someone stuck on his own buggy ideas/implementations. Often people are just convinced their idea is better than your and they won't change their mind, regardeless their status in the opensource community. And there is nothing more you can do apart from learning how to deal with such situations. Granted, there are projects blowing up and people abbandoning successful opensource community because of this. > From my external point of view, committers not only have the > possibility, but *do* commit mess in the tree without non-committers > could say or do anything, just as well as committers being able to > arbitrarily close PR even if the original reporter disagree. You should look at svn-src@ more often I suspect. You will see how many discussions are in there. >> And so? I think you have a wrong point of view of what is >> shamelessly... I'm working on the same project since 6 months, i >> thought I could finish it in 1 but then I understood that in order to >> get the quality I was hoping I had to do more work... does it qualify >> as failed, according to your standard? >> > not specifically, but at the end of that project of your, I would run > a post-mortem meeting to see what went correctly and where things got > out-of-control. Arnaud, my friend, I have a new for you: this stuff is hard. I see the brightest people I've ever met stuck for weeks on problems, thinking about how to fix them in elegant way. Sometimes things get understimated, sometimes not, this is just part of the game. But an important thing is accepting critics in costructive way and learn. This makes things much easier. > As for the mbuf meeting, all I can find from it online is: > > http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html > > which is not worth much... Rather than doing things internally, maybe > it is time to open up... oh, wait, you will certainly come to the > community with a design plan, figure out it's not gonna work while > doing the implementation, change the design plan while implementing, > go public with a +3k/-2k loc change patch, ask for benediction, go > ahead and commit it up until someone comes with an obvious design flaw > which would render the change pretty much useless, but there will be > man-month of work to fix it, so it's never gonna be done. > > One obvious problem in FreeBSD is that committers are prosecutor, > judge and jury altogether. That's not the first time I point this out. You are drammatizing. As I already told, please, if you are interested in this topic, ask for the state of the discussion and ask politely to be included from now on. Nobody will reject you only because you don't have a @freebsd.org. >>>> b) there is still not consensus on details >>>> >>> Then the discussion should stop, public records are kept for reference >>> in the future. There is no problem with this. >>> >>>> and you can always publically asked on what was decided and what not. >>>> Just send a mail to interested recipients and CC any FreeBSD mailing >>>> list. >>>> >>> This is not the way "openness" should be about. >> >> There is not much more you can do when people don't share details and >> discussions automatically. >> > keep reporting regressions, interface flaws, POLA violations, ABI > breakages, bugs, etc. I agree. But with the correct and humble mindset and avoiding aggressive behaviour. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 20:40:39 2012 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 A05B71065670; Wed, 1 Aug 2012 20:40:39 +0000 (UTC) (envelope-from matthewstory@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 43E3C8FC0A; Wed, 1 Aug 2012 20:40:39 +0000 (UTC) Received: by obbun3 with SMTP id un3so16407778obb.13 for ; Wed, 01 Aug 2012 13:40:38 -0700 (PDT) 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=hYhQkO9ytYRZytt2JlYps3vUccg3IvOzLxD3naBPzJk=; b=oznlieGPDfmmYs81uGue7BRCc5vPBqsxNe4jgGCJjmJpC4LGMMZUg0FCpFRIlimyXO +vXoDdhkQeTr+4sP15IEEYUX1QFm+ZMreHJS69GxM1tmKLrWFpUM27pIU9JGS9saohnv GL3nMpHmHA6qccAM9i3mej6ncnLpEpiYS2rt/uoVfxvz0MsmEqWvFyzyN5tgHG4uRNzR 3IjWGLkCuVzeF9Y2YzxZWDCf+O+uimO0tJmy+LEdVaV/hWeSvtfyjMcUVAFKV5ZZILVs UhmVDs1Df+BMz3jKEhub3c2TzOeEBEWyvIyKtv+TmTsgLw4z/ihI7CeIyePf1QZmFjDQ N/BQ== MIME-Version: 1.0 Received: by 10.182.44.68 with SMTP id c4mr31322841obm.27.1343853638738; Wed, 01 Aug 2012 13:40:38 -0700 (PDT) Received: by 10.76.21.48 with HTTP; Wed, 1 Aug 2012 13:40:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 16:40:38 -0400 Message-ID: From: Matthew Story To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 20:40:39 -0000 On Wed, Aug 1, 2012 at 1:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe > wrote: > >> Hi, > >> > >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao > wrote: > >>> > >>> You don't want to work cooperatively. > >>> > >> Why is it that mbuf's refactoring consultation is being held in > >> internal, private, committers-and-invite-only-restricted meeting at > >> BSDCan ? > >> > >> Why is it that so much review and discussion on changes are held > privately ? > > > > Arnaud, > > belive me, to date I don't recall a single major technical decision > > that has been settled exclusively in private (not subjected to peer > > review) and in particular in person (e-mail help you focus on a lot of > > different details that you may not have under control when talking to > > people, etc). > > > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. > > > Sometimes it is useful that a limited number of developers is involved > > in initial brainstorming of some works, > > > Never. > > > but after this period > > constructive people usually ask for peer review publishing their plans > > on the mailing lists or other media. > > > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." > > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. > > > If you don't see any public further discussion this may be meaning: > > a) the BSDCan meetings have been fruitless and there is no precise > > plan/roadmap/etc. > > > so not only you make it private, but it shamelessly failed... > > > b) there is still not consensus on details > > > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > > > and you can always publically asked on what was decided and what not. > > Just send a mail to interested recipients and CC any FreeBSD mailing > > list. > > > This is not the way "openness" should be about. > I attended the developer summit, and attended the mbuf working group ... I'm also not a committer. My ASCII transcription of the results of the white-board session were posted to freebsd-arch in june, the post is available for viewing here: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html When the information is readily available (as it is in this case), there is a clear case of confusing one's inability to engage the entirety of FreeBSD with "openness". If you are concerned about the mbuf decisions, you should be subscribed to (and reading) the arch list. > - Arnaud > > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- regards, matt From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 20:46:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 047A5106564A for ; Wed, 1 Aug 2012 20:46:59 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B29008FC15 for ; Wed, 1 Aug 2012 20:46:58 +0000 (UTC) Received: by ghbz22 with SMTP id z22so9095435ghb.13 for ; Wed, 01 Aug 2012 13:46:58 -0700 (PDT) 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=CvgeXVdC3ONQfLB7sOco4SOH1br2eL0r4oAi2oa0Bw4=; b=RFwDgT4N5brWNq31q004IKOmojPnUIRABiyLnqln6tSMcD7wrFHglINwbsGok7DSX1 6/2F4RU+OxxaHU8lL2og9wg3JAYWQOY7gcFak80fpg0mEncCRUMJzRZtIL+LlIMHmr0K DZLNu0LbQ61DDw/KMI4urFdEc4OYCGLrhGBtmno0Y41Tm3F0dQbPDzTvomlb/06pDOBt FxfpSIG3XJeV0W8S1+EDnB7lj01Y9FLpkVzHkqlmGyfuIEd1aj9IkQcojmtu030MYHHn Sl3Ef6pjtw6ViZnjLLYgNBjsiurEhgkFrR/KU4dkbdIMAVMtEqdtR/5yUBwfCiq+2dQY fyfw== MIME-Version: 1.0 Received: by 10.60.29.161 with SMTP id l1mr31612089oeh.43.1343854018064; Wed, 01 Aug 2012 13:46:58 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Wed, 1 Aug 2012 13:46:58 -0700 (PDT) In-Reply-To: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> Date: Wed, 1 Aug 2012 22:46:58 +0200 X-Google-Sender-Auth: 9i2_6e-4M9vq4gu4gbxklded3SA Message-ID: From: Ed Schouten To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 20:46:59 -0000 Hi Kostik, 2012/8/1 Konstantin Belousov : > I would blame tty subsystem rather then USB subsystem. The d_purge > method of the ttydev_cdevsw is not implemented, but it is the only > measure that can break the deadlocks like the one I described. The > d_purge shall wake up threads sleeping inside devsw methods, which was > specifically added to notify driver about device gone events. I guess d_purge was added quite recently, right? In the current design, the USB code must call into tty_gone() to report that the TTY is no longer associated with an actual device. This shall result in all threads blocking on a TTY to be woken up. Also, it will prevent any further calls into the USB code by the TTY layer. Still, if the processes are not actually interacting with the TTY (e.g. sleep 100000, just waiting for nanosleep() to return), then there is no way the TTY code can actually garbage collect the TTY. It must stay there. Removing the actual TTY would introduce a whole bunch of races and unwanted behaviour. Applications may cache the pathname to the TTY. If the pathname were to be reused by another device, apps would start writing to random TTYs. So that's why TTYs may still stick around in devfs, even though the device underneath went missing. The driver simply calls tty_gone() and leaves the TTY alone. It will die eventually, but you shouldn't wait for it to happen. Still, I seem to remember the USB code does something weird. I think the USB serial driver tries to block until the TTY is actually destroyed. This is a bug, which I've discussed with hselasky@ numerous times. It simply must not do that. -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:02:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0488C106564A; Wed, 1 Aug 2012 21:02:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACA78FC0C; Wed, 1 Aug 2012 21:02:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q71L2NKr058655; Thu, 2 Aug 2012 00:02:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q71L2Al1075890; Thu, 2 Aug 2012 00:02:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q71L2AZG075889; Thu, 2 Aug 2012 00:02:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Aug 2012 00:02:10 +0300 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120801210210.GU2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ilwtao6+P+Teod98" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, hselasky@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 21:02:17 -0000 --ilwtao6+P+Teod98 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 01, 2012 at 10:46:58PM +0200, Ed Schouten wrote: > Hi Kostik, >=20 > 2012/8/1 Konstantin Belousov : > > I would blame tty subsystem rather then USB subsystem. The d_purge > > method of the ttydev_cdevsw is not implemented, but it is the only > > measure that can break the deadlocks like the one I described. The > > d_purge shall wake up threads sleeping inside devsw methods, which was > > specifically added to notify driver about device gone events. >=20 > I guess d_purge was added quite recently, right? No, it was there at least in 2006. In fact, it seems to be added in 2004, see r135843. >=20 > In the current design, the USB code must call into tty_gone() to You mean tty_rel_gone(), right ? > report that the TTY is no longer associated with an actual device. > This shall result in all threads blocking on a TTY to be woken up. > Also, it will prevent any further calls into the USB code by the TTY > layer. >=20 > Still, if the processes are not actually interacting with the TTY > (e.g. sleep 100000, just waiting for nanosleep() to return), then > there is no way the TTY code can actually garbage collect the TTY. It > must stay there. Removing the actual TTY would introduce a whole bunch > of races and unwanted behaviour. Applications may cache the pathname > to the TTY. If the pathname were to be reused by another device, apps > would start writing to random TTYs. So that's why TTYs may still stick > around in devfs, even though the device underneath went missing. The > driver simply calls tty_gone() and leaves the TTY alone. It will die > eventually, but you shouldn't wait for it to happen. Well, IMO it is weird, and tty should be destroyed immediately. Do we have any problems with pts-style pty which would force reuse of device names ? For hardware ttys, immediate removal looks just right unconditionally. >=20 > Still, I seem to remember the USB code does something weird. I think > the USB serial driver tries to block until the TTY is actually > destroyed. This is a bug, which I've discussed with hselasky@ numerous > times. It simply must not do that. Yes, it does. ucom_detach_tty(): tty_rel_gone(tp); mtx_lock(sc->sc_mtx); /* Wait for the callback after the TTY is torn down */ while (sc->sc_ttyfreed =3D=3D 0) cv_wait(&sc->sc_cv, sc->sc_mtx); and sc_ttyfreed is set from destroy_dev_sched callback. --ilwtao6+P+Teod98 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAZmVIACgkQC3+MBN1Mb4g/bgCg8E/RDnksdoqCy4SZF1CEdDkC KbkAoOZ5UeKLTqcn4cZ1EtEwl7GRKYxa =uxK2 -----END PGP SIGNATURE----- --ilwtao6+P+Teod98-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:13:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12421065675; Wed, 1 Aug 2012 21:13:49 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 588888FC19; Wed, 1 Aug 2012 21:13:48 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0581E3B74D; Wed, 1 Aug 2012 21:13:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q71LDkDb076408; Wed, 1 Aug 2012 21:13:46 GMT (envelope-from phk@phk.freebsd.dk) To: Konstantin Belousov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 02 Aug 2012 00:02:10 +0300." <20120801210210.GU2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 01 Aug 2012 21:13:46 +0000 Message-ID: <76407.1343855626@critter.freebsd.dk> Cc: Ed Schouten , current@freebsd.org, hselasky@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 21:13:49 -0000 In message <20120801210210.GU2676@deviant.kiev.zoral.com.ua>, Konstantin Belous ov writes: >> I guess d_purge was added quite recently, right? > >No, it was there at least in 2006. In fact, it seems to be added in 2004, >see r135843. Ahh yes, I remember that one :-) It was added so that when PCMCIA cards (anyone remember those ?) were pulled out, ppp(8) and tip(1) would not stay stuck forever. Today all devices drivers should assume that the hardware can disappear under their feet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:39:57 2012 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 0F1F7106564A; Wed, 1 Aug 2012 21:39:57 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1B93A8FC12; Wed, 1 Aug 2012 21:39:55 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so3479579wib.13 for ; Wed, 01 Aug 2012 14:39:54 -0700 (PDT) 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=xLIa80/xEXNtoRPAQveycdb1XMlbfVOc6RT3fbZM928=; b=hcz+gBHmcs3vAwtiPaOPTwYmNwRbHuCa6gDKQueDz03UXN3wiy38/zDyzqS3LfCjq0 6oBgmfAt2lRmMYNqnukW2WrrR/4x6YO+oaKORy9V29iS5YowDaL7ZNpACXb5ki94rbXL uoY0RcFqhnwLsDnfaNe3Ht84XkOOLCQx3ADSKgUb4LbO83uaU8BBhCPLw+VJ/RbbzIJt xVlQK5ATdazZSEynfP7wqwbKXo5T6B0vRJRlzxPK1LuDnmN8PLEOlZMWpS9d+cg2vQyV zOYnAAdVPqSfmQ3uJLKoFexvemb6+16gugxJ1m5pw5of36QDIUN2XpTfurlql1iEqgli IHAw== MIME-Version: 1.0 Received: by 10.180.91.1 with SMTP id ca1mr15093245wib.8.1343857194611; Wed, 01 Aug 2012 14:39:54 -0700 (PDT) Received: by 10.216.140.155 with HTTP; Wed, 1 Aug 2012 14:39:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 17:39:54 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 21:39:57 -0000 Hi, On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: > Any interested party is very welcome to approach a developer and get > added to the developer summits. Plenty of the people at the most > recent developer summit weren't @freebsd.org committers - we had > plenty of representation from companies using FreeBSD. > > If you want to participate, just ask a friendly developer who is going > to the developer summit to sponsor you in going. You're pleasant in > person, so I'd have no problem sponsoring you if I am going to an > event. :) > I have a very deep, quasi-philosophical, trouble/problem with that whole idea of sponsor-requirement to attend a such meeting. There is just something which does not feel right about it. From my point of view, this is a matter of common sense, focus is gonna be very narrow and deeply technical. Attendee should go there only if they think they will give positive feedback. As for myself, I would not attend a developer meeting on the fiber-channel over infiniband optimization, but would attend a developer meeting on next-generation mbuf. Now, maybe I'll just push the door of some developer meeting I'd be interested in during next BSDCan, and see what happen :-) The outcome might be interesting to study in a social interaction, prisoner dilemma related, point-of-view. - Arnaud > And/or, work with warner to get improvements into the tree and someone > will sponsor a commit bit for you. > > Perhaps we as developers should more openly publish the results of > developer summits. But as I said, they're not "closed" - they're just > "invite only for non-developers." We're not going to exclude anyone > from coming unless they really ARE going to just sit there and troll. > You're motivated, you're enthusiastic and you want to see things > change for the better. You're also not confrontational in person. I > have no problem with you coming along. > > > Adrian From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:41:10 2012 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 EB8351065672 for ; Wed, 1 Aug 2012 21:41:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 776EE8FC12 for ; Wed, 1 Aug 2012 21:41:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 302371102; Wed, 01 Aug 2012 23:41:03 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 1 Aug 2012 23:41:25 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208012341.25509.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 21:41:11 -0000 On Wednesday 01 August 2012 22:46:58 Ed Schouten wrote: > Hi Kostik, > > 2012/8/1 Konstantin Belousov : > > I would blame tty subsystem rather then USB subsystem. The d_purge > > method of the ttydev_cdevsw is not implemented, but it is the only > > measure that can break the deadlocks like the one I described. The > > d_purge shall wake up threads sleeping inside devsw methods, which was > > specifically added to notify driver about device gone events. > > I guess d_purge was added quite recently, right? > > In the current design, the USB code must call into tty_gone() to > report that the TTY is no longer associated with an actual device. > This shall result in all threads blocking on a TTY to be woken up. > Also, it will prevent any further calls into the USB code by the TTY > layer. > > Still, if the processes are not actually interacting with the TTY > (e.g. sleep 100000, just waiting for nanosleep() to return), then > there is no way the TTY code can actually garbage collect the TTY. It > must stay there. Removing the actual TTY would introduce a whole bunch > of races and unwanted behaviour. Applications may cache the pathname > to the TTY. If the pathname were to be reused by another device, apps > would start writing to random TTYs. So that's why TTYs may still stick > around in devfs, even though the device underneath went missing. The > driver simply calls tty_gone() and leaves the TTY alone. It will die > eventually, but you shouldn't wait for it to happen. > Still, I seem to remember the USB code does something weird. I think > the USB serial driver tries to block until the TTY is actually > destroyed. This is a bug, which I've discussed with hselasky@ numerous > times. It simply must not do that. Hi Ed & Others, I think the problem is like this, that in order to re-use the unit numbers for USB serial tty devices, the USB stack needs to wait until a TTY is actually freed, right? Else you will have a panic on creating devfs entries having the same name. For /dev/usb/XXX nodes the USB stack supports that the client and dynamic kernel USB device structures can be separated at any time. I think Andrew Thompson was part of that design, that we allocate a small structure containing some information that allows us to quickly _lookup_ the USB kernel device at every read/write/ioctl/whatever, and then we simply mark the so- called cdev_priv invalid in case of detach, and it is actually freed when the fd is closed, while the kernel structures go away immediately. I think this same approach must be taken inside the TTY layer. I'm not sure how easy this will be, though. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 22:47:38 2012 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 D8465106566B for ; Wed, 1 Aug 2012 22:47:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A189C8FC12 for ; Wed, 1 Aug 2012 22:47:38 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q71MlPfs086283 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 15:47:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5019B1F8.5080802@freebsd.org> Date: Wed, 01 Aug 2012 15:47:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> In-Reply-To: <201208012341.25509.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Ed Schouten , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 22:47:39 -0000 On 8/1/12 2:41 PM, Hans Petter Selasky wrote: > On Wednesday 01 August 2012 22:46:58 Ed Schouten wrote: >> Hi Kostik, >> >> 2012/8/1 Konstantin Belousov : >>> I would blame tty subsystem rather then USB subsystem. The d_purge >>> method of the ttydev_cdevsw is not implemented, but it is the only >>> measure that can break the deadlocks like the one I described. The >>> d_purge shall wake up threads sleeping inside devsw methods, which was >>> specifically added to notify driver about device gone events. >> I guess d_purge was added quite recently, right? >> >> In the current design, the USB code must call into tty_gone() to >> report that the TTY is no longer associated with an actual device. >> This shall result in all threads blocking on a TTY to be woken up. >> Also, it will prevent any further calls into the USB code by the TTY >> layer. >> >> Still, if the processes are not actually interacting with the TTY >> (e.g. sleep 100000, just waiting for nanosleep() to return), then >> there is no way the TTY code can actually garbage collect the TTY. It >> must stay there. Removing the actual TTY would introduce a whole bunch >> of races and unwanted behaviour. Applications may cache the pathname >> to the TTY. If the pathname were to be reused by another device, apps >> would start writing to random TTYs. So that's why TTYs may still stick >> around in devfs, even though the device underneath went missing. The >> driver simply calls tty_gone() and leaves the TTY alone. It will die >> eventually, but you shouldn't wait for it to happen. > >> Still, I seem to remember the USB code does something weird. I think >> the USB serial driver tries to block until the TTY is actually >> destroyed. This is a bug, which I've discussed with hselasky@ numerous >> times. It simply must not do that. > Hi Ed & Others, > > I think the problem is like this, that in order to re-use the unit numbers for > USB serial tty devices, the USB stack needs to wait until a TTY is actually > freed, right? Else you will have a panic on creating devfs entries having the > same name. I think that the /dev/entries can (and SHOULD) go away when the hardware goes away and even be re-used. The devfs entry is after all just a name.. it's the underlying parts (the bottom of the iceberg) that needs to stay to handle calls from file descriptors that are still open and THAT > > For /dev/usb/XXX nodes the USB stack supports that the client and dynamic > kernel USB device structures can be separated at any time. I think Andrew > Thompson was part of that design, that we allocate a small structure > containing some information that allows us to quickly _lookup_ the USB kernel > device at every read/write/ioctl/whatever, and then we simply mark the so- > called cdev_priv invalid in case of detach, and it is actually freed when the > fd is closed, while the kernel structures go away immediately. I think this > same approach must be taken inside the TTY layer. I'm not sure how easy this > will be, though. > > --HPS > _______________________________________________ > 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 Aug 1 22:53:11 2012 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 DCB1C106566C; Wed, 1 Aug 2012 22:53:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A73478FC0C; Wed, 1 Aug 2012 22:53:11 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q71MrAOc086299 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 15:53:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5019B351.7040600@freebsd.org> Date: Wed, 01 Aug 2012 15:53:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 22:53:12 -0000 On 8/1/12 12:45 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: > As for the mbuf meeting, all I can find from it online is: > http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html actually nothing has happenned on this yet that I know of, which is why there has been no action to see. We all agree that it is an item to put on our agenda but until there is someone who gets the free time it's just a "sanctioned priority item" > > which is not worth much... Rather than doing things internally, maybe > it is time to open up... oh, wait, you will certainly come to the > community with a design plan, figure out it's not gonna work while > doing the implementation, change the design plan while implementing, > go public with a +3k/-2k loc change patch, ask for benediction, go > ahead and commit it up until someone comes with an obvious design flaw > which would render the change pretty much useless, but there will be > man-month of work to fix it, so it's never gonna be done. > From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 23:28:38 2012 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 447EE1065673 for ; Wed, 1 Aug 2012 23:28:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8C608FC0C for ; Wed, 1 Aug 2012 23:28:37 +0000 (UTC) Received: by yenl8 with SMTP id l8so9356635yen.13 for ; Wed, 01 Aug 2012 16:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MKW5GhBiDKDxHkrPmShwljmSH03RkF/AKt8d+8srCvA=; b=biZ20mdFrsnTLt6g0zCFXZKs9Kn2rLRTm/T77HTdzIH+4d+IQan+SNHMaBCZfX7/O4 Zpc2WQonVEr3wbXpo/+glb2XYwKrP++P7WqPsXW726Pak6EZlBXX8mZgNU5jf3W+bM72 EBbKbuATw41xI/ZGuKUd5ftwAQz7xgVVy2+ByGPpRCQlnHE8PyYPlpOOpQBtnwHtDMvO 0M0Qlb+su+uHbej2jdvNulvRCnHW+3y7QBGFEdIaexg+KKVLWkcl9+YthaVCwvRrEfD0 3Gp0PndvwO9Q8wAbbq7mQlaw2QRleI9gk7OoCMchEA51p7xzgv8BrBrY+3ksrZrEvWva 1HEQ== Received: by 10.50.222.137 with SMTP id qm9mr6972435igc.64.1343863716867; Wed, 01 Aug 2012 16:28:36 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id dk7sm8367437igb.10.2012.08.01.16.28.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 16:28:36 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 1 Aug 2012 17:28:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnNQFDHnygI3IzAYqvWuQhQnjTFYxmP1NqJAZpXr1O1gyojEnrW1ObO6l2R87nXcZXQEfzw Cc: attilio@freebsd.org, FreeBSD Hackers , Adrian Chadd , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Aug 2012 23:28:38 -0000 On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd = wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >>=20 >> If you want to participate, just ask a friendly developer who is = going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >>=20 > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. =46rom my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. >=20 > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Given how ridiculously easy it is to get a proper invite, there's not = need to be a jerk just to prove an obscure philosophical point about = attendance. There's plenty of time to do that over the technical points = being discussed. Warner > - Arnaud >=20 >> And/or, work with warner to get improvements into the tree and = someone >> will sponsor a commit bit for you. >>=20 >> Perhaps we as developers should more openly publish the results of >> developer summits. But as I said, they're not "closed" - they're just >> "invite only for non-developers." We're not going to exclude anyone >> from coming unless they really ARE going to just sit there and troll. >> You're motivated, you're enthusiastic and you want to see things >> change for the better. You're also not confrontational in person. I >> have no problem with you coming along. >>=20 >>=20 >> Adrian > _______________________________________________ > 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 Thu Aug 2 01:06:27 2012 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 99F52106564A; Thu, 2 Aug 2012 01:06:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0E98FC0C; Thu, 2 Aug 2012 01:06:26 +0000 (UTC) Received: by weyx56 with SMTP id x56so6703180wey.13 for ; Wed, 01 Aug 2012 18:06:25 -0700 (PDT) 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=0XyXGYMfRd0Kt/DmK/nl97hty1wlsMpsFs9pdgveGO8=; b=Vccd9D5IeK+BGL7prkdYbS+WxjQPSIA3fWEybKE8AgsaJgFv73fq/rUHefRFqKy6FD L+ktxqDNlnyGJ6uIgU66dPK7rH3c9kv3yFGrZy69BTMuxbcfatvPQoyXhrfB6tOTAr/h RMDM8kVEd+RQ3q5jQQHh1YPVpBjDhKjS35kTY6ODl8TCylcEAimeTcgkenlGNxoWhmP5 xm5MeJxJwJVWGpQmFzNCk8QW13hNdKtdDWdZfmYYUNrKPUHudd+5a7hpWRWQmOGG0KZb QZ/nX54d7kMQTkHieQBex3m55CQseXzU27AAhZDaUkx1LXTnKrlAjCZ0AIfuFQxAgh7x +odg== MIME-Version: 1.0 Received: by 10.216.241.137 with SMTP id g9mr8403603wer.122.1343869585153; Wed, 01 Aug 2012 18:06:25 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Wed, 1 Aug 2012 18:06:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 18:06:25 -0700 Message-ID: From: Kevin Oberman To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: attilio@freebsd.org, FreeBSD Hackers , Adrian Chadd , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 01:06:27 -0000 On Wed, Aug 1, 2012 at 2:39 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >> >> If you want to participate, just ask a friendly developer who is going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >> > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. From my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. > > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Arnaud, I suggest that you attend some Internet Engineering Task Force Working Group meetings. They are, by rule, open. There is no procedure for excluding anyone. While this may be open, it can be painfully wasteful of time as one person can tie up the entire meeting and ensure nothing is accomplished. It happens all too often and has resulted in working groups being shut down as they have no chance on reaching consensus. One person can't block consensus in theory. but he can tie up so much time that no actual work is done.This is one of the primary reasons I stopped attending IETF meetings as opposed to being active on WG mail lists where a lot of the real work is done and annoying messages can simply be ignored. For a much smaller endeavor, like FreeBSD, this is simply unacceptable as is a brainstorming type of meeting with too many people present. almost all really effective projects are done by one or two people and they need the input of a fairly small set of other concerned people to vet the work. This has worked well, if not perfectly, for FreeBSD and many other projects. It may not be perfect, but trying to accomplish something that comes under the heading of brainstorming in a truly open environment is a wonderful goal, but really is not efficient. And, no, I don't expect you to agree. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 03:28:35 2012 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 5758C106564A; Thu, 2 Aug 2012 03:28:35 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38B6C8FC0A; Thu, 2 Aug 2012 03:28:33 +0000 (UTC) Received: by laai10 with SMTP id i10so6126039laa.13 for ; Wed, 01 Aug 2012 20:28:32 -0700 (PDT) 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=2B0/LZCDUKZmxIX2pIRzopczXH20MQLHPyVQSC5lwv4=; b=tQ2RvOnEtuCZ9uTzuxK7/O7lAXBkxVtezpFq6oDV4Htz2cjFeVf0X9o0o9uNg3M7eK DBvKN0rCCRfvFB5bmcbyIKrfCqI4S9zsKzoWiGoSJlqAXtmJknF33OjpG8gqVbL1dZ0w noK1bsvlUtDSUyyzaSf+oAxLGdQTlsMzWpdXXp2rPgP63VRo/bkVfluLWhcJzQ8veS1Q baAixxMOTUsvdPRh2v4wPIRWZ4ARJy6wzH1c6uhmoq2imnOiXYAFad/wvekKSG157hab +Yi7xZtg2d3jKXoX/xSzs/0nmfPwQfimVxouVw7AQ5EEZw7+MOIwCD712vgu8zN/0tH7 kr6w== MIME-Version: 1.0 Received: by 10.112.17.227 with SMTP id r3mr8906246lbd.41.1343878112540; Wed, 01 Aug 2012 20:28:32 -0700 (PDT) Received: by 10.114.24.133 with HTTP; Wed, 1 Aug 2012 20:28:32 -0700 (PDT) In-Reply-To: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> Date: Wed, 1 Aug 2012 23:28:32 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Hackers , Adrian Chadd , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 03:28:35 -0000 Hi, On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: > > On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >>> Any interested party is very welcome to approach a developer and get >>> added to the developer summits. Plenty of the people at the most >>> recent developer summit weren't @freebsd.org committers - we had >>> plenty of representation from companies using FreeBSD. >>> >>> If you want to participate, just ask a friendly developer who is going >>> to the developer summit to sponsor you in going. You're pleasant in >>> person, so I'd have no problem sponsoring you if I am going to an >>> event. :) >>> >> I have a very deep, quasi-philosophical, trouble/problem with that >> whole idea of sponsor-requirement to attend a such meeting. There is >> just something which does not feel right about it. From my point of >> view, this is a matter of common sense, focus is gonna be very narrow >> and deeply technical. Attendee should go there only if they think they >> will give positive feedback. As for myself, I would not attend a >> developer meeting on the fiber-channel over infiniband optimization, >> but would attend a developer meeting on next-generation mbuf. >> >> Now, maybe I'll just push the door of some developer meeting I'd be >> interested in during next BSDCan, and see what happen :-) The outcome >> might be interesting to study in a social interaction, prisoner >> dilemma related, point-of-view. > > Given how ridiculously easy it is to get a proper invite, there's not need to be a jerk just to prove an obscure philosophical point about attendance. There's plenty of time to do that over the technical points being discussed. > Let me explain my thoughts: I do not recognize the committers legitimacy to give such invite, and to some extend, I do not recognize committers self-given legitimacy altogether. This do not mean I'd praised a structure-less project; quite the opposite actually. Starting from that, I will certainly not defer to anybody to request such invite or commit bit. Feel free to kick me out of the meeting room if you want to; I would have proved my point. Now, if invites are so easy to get, just get rid of it. It's a worthless, cumbersome item. - Arnaud ps: please, do not get me wrong, I would apply this policy to anybody who propose to help. From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 03:36:37 2012 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 BAD59106567A for ; Thu, 2 Aug 2012 03:36:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63F178FC19 for ; Thu, 2 Aug 2012 03:36:37 +0000 (UTC) Received: by yhfs35 with SMTP id s35so9528348yhf.13 for ; Wed, 01 Aug 2012 20:36:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8i/dK6GMZ9vN7Bo+8+npg8P/zkBZG3yi9X0+jsmtaeg=; b=TdvQ90A1hn+9BHvbCLQFeTnJ7pld+lUqqEv3ew0Qgl91jGEpIV03X5hIe2JasdW+5m 96/ruANyTpwT3xNircQvyHN84lqi1KtJC0KgIYLCOjIeQVbiOlP+dIYOlHPUCAtGuLAy eOPezt391TN8b9S+NvS9t4v3y9soL/i4vxM+2b0Z+mNFhLkqrBZv0BYBkv8YVjUiOTGN 7yOGKv2BySnjFhSpbMPHe1btmgjySvxOKKytkuv3t/h4OR2bWRRfc9CtRRXGOdY3QfeM GDArJxRCPhi0EryDl0woPNu5oGdLUYhbm52IuAGEitBrwWTU/jZDeU6bwkLA1zRmyd7y AZ2g== Received: by 10.50.169.73 with SMTP id ac9mr810396igc.29.1343878596277; Wed, 01 Aug 2012 20:36:36 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id z3sm14637588igc.7.2012.08.01.20.36.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 20:36:35 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 1 Aug 2012 21:36:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQncxyzEdb21yrPMkXIlCE2HMGPiJm0u+FiVGUXPXCkF7rgVQYxyYkq9cYgD5oFegto8ImpZ Cc: attilio@freebsd.org, FreeBSD Hackers , Adrian Chadd , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 03:36:37 -0000 On Aug 1, 2012, at 9:28 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: >>=20 >> On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: >>=20 >>> Hi, >>>=20 >>> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd = wrote: >>>> Any interested party is very welcome to approach a developer and = get >>>> added to the developer summits. Plenty of the people at the most >>>> recent developer summit weren't @freebsd.org committers - we had >>>> plenty of representation from companies using FreeBSD. >>>>=20 >>>> If you want to participate, just ask a friendly developer who is = going >>>> to the developer summit to sponsor you in going. You're pleasant in >>>> person, so I'd have no problem sponsoring you if I am going to an >>>> event. :) >>>>=20 >>> I have a very deep, quasi-philosophical, trouble/problem with that >>> whole idea of sponsor-requirement to attend a such meeting. There is >>> just something which does not feel right about it. =46rom my point = of >>> view, this is a matter of common sense, focus is gonna be very = narrow >>> and deeply technical. Attendee should go there only if they think = they >>> will give positive feedback. As for myself, I would not attend a >>> developer meeting on the fiber-channel over infiniband optimization, >>> but would attend a developer meeting on next-generation mbuf. >>>=20 >>> Now, maybe I'll just push the door of some developer meeting I'd be >>> interested in during next BSDCan, and see what happen :-) The = outcome >>> might be interesting to study in a social interaction, prisoner >>> dilemma related, point-of-view. >>=20 >> Given how ridiculously easy it is to get a proper invite, there's not = need to be a jerk just to prove an obscure philosophical point about = attendance. There's plenty of time to do that over the technical points = being discussed. >>=20 > Let me explain my thoughts: I do not recognize the committers > legitimacy to give such invite, and to some extend, I do not recognize > committers self-given legitimacy altogether. This do not mean I'd > praised a structure-less project; quite the opposite actually. > Starting from that, I will certainly not defer to anybody to request > such invite or commit bit. Feel free to kick me out of the meeting > room if you want to; I would have proved my point. I think this proves the point everybody has been saying: you are being = needlessly contrary and confrontational. Warner > Now, if invites are so easy to get, just get rid of it. It's a > worthless, cumbersome item. >=20 > - Arnaud >=20 > ps: please, do not get me wrong, I would apply this policy to anybody > who propose to help. From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 03:43:09 2012 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 717BC106566C; Thu, 2 Aug 2012 03:43:09 +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 29F268FC12; Thu, 2 Aug 2012 03:43:09 +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 q723h2jg030411; Wed, 1 Aug 2012 20:43:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q723h2kN030410; Wed, 1 Aug 2012 20:43:02 -0700 (PDT) (envelope-from sgk) Date: Wed, 1 Aug 2012 20:43:02 -0700 From: Steve Kargl To: Warner Losh Message-ID: <20120802034302.GA30400@troutmask.apl.washington.edu> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: attilio@freebsd.org, FreeBSD Hackers , Adrian Chadd , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 03:43:09 -0000 On Wed, Aug 01, 2012 at 09:36:26PM -0600, Warner Losh wrote: > > I think this proves the point everybody has been saying: you > are being needlessly contrary and confrontational. > Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 04:30:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 25108106566C; Thu, 2 Aug 2012 04:30:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9B05A14DB9A; Thu, 2 Aug 2012 04:30:17 +0000 (UTC) Message-ID: <501A0258.4010101@FreeBSD.org> Date: Wed, 01 Aug 2012 21:30:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Warner Losh References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> In-Reply-To: X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 04:30:18 -0000 On 8/1/2012 8:36 PM, Warner Losh wrote: > I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. Actually if you take a step back and look at what Arnaud is saying objectively, he's right. If anyone can attend the meeting by simply getting an invitation from a committer, the only purpose the invitation serves is to force the mere-mortal user to kiss someone's ring. That's precisely the kind of elitist crap that I've been railing against for so many years now. OTOH, currently the dev summits generally take place with limited resources, so it's not really possible to have "everyone" attend. And (TMK) the "invitation" process is really more like a restaurant with a sign that says "we reserve the right to refuse service to anyone." But on the _other_ other hand, the problem of things being discussed and/or decisions being taken exclusively at the dev summits, especially BSDCAN, has gotten quite bad over the last several years. Even amongst committers, the community has become divided between the "haves" who can travel to the summit, and the "have nots" who can't. Note, I'm quite sure that this statement will be met with howls of protest, from the "haves," that this isn't the case. Even if they were sincere, it's incredibly easy for the people with the privileges to see their privileged state as "normal," and lose sight of how the world looks from the cheap seats. In spite of Kevin's concerns (and I don't know what working groups he's been attending) the IETF model is really a good one to examine here. The majority of the work gets done on the mailing lists, with working group meetings serving as an opportunity for group discussion, presentations, etc. The results of the meetings are then published to the mailing list in the form of minutes, and the final decisions are made in public, on the lists. Another incredibly important feature, the meetings are open to remote participation in the sense that slide decks are published in advance, the meeting audio is streamed live, and there are jabber rooms for remote participants to interact with the people in the meeting. I used to ask the PTB to provide *some* form of remote participation for even a fraction of the events at the dev summit. I don't bother asking anymore because year after year my requests were met with any of: indifference, hostility, shrugged shoulders (that's a hard problem that we can't solve), or embarrassment. Since if the right people around here want something to happen, it happens; I finally came to the conclusion that they didn't want remote participation to happen, so it won't. That's a shame. If the only large, open project you've ever participated in is FreeBSD, what gets done around here feels "normal" to you. But don't be so quick to dismiss the viewpoints of people who have experience in the wider world. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 04:53:15 2012 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 86A45106566C for ; Thu, 2 Aug 2012 04:53:15 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by mx1.freebsd.org (Postfix) with SMTP id 4FCC78FC0A for ; Thu, 2 Aug 2012 04:53:15 +0000 (UTC) Received: from [98.139.91.65] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 04:53:09 -0000 Received: from [98.139.91.12] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 04:53:09 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 02 Aug 2012 04:53:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 933930.19214.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 56963 invoked by uid 60001); 2 Aug 2012 04:53:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1343883189; bh=FI9RQh4GHNn+/62Il3zYd5mrlo+yhCK641uvT0YdUY4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MBrJ/aTZ0Vc2dRPh8YXJnR/YHminF98Ch2ROuLsKJ7JXuUoH2i5gG3GbRUA2IcmjYdkNxGFyarIKRdZTP0IrMM0sfsDQuVac0OF8K86dh32E4Bx6Ds7k01CbmGubAk0eq6PmtlxlJM8SecSTU75LYTI78JAdl+9F5v20X0BgKYM= X-YMail-OSG: TnX2V2YVM1kRbk65L81OARfyqqpfvQEBNHGquieuG1Nin7M e3AFixVkWij.f3Y221GmTxxleo5Og9f2mw3kzs9b7Q95KyYD2H6jz2lfl3_V _V1.kuH9dyWHvbYvEAlfU8EYqOkPGivjL00jiL3PQezZF4TcS4NbQZX_wakC JL8G4KyB_s_92Cw5R4twBR66dQS.vJIgQtwQ6jqI5isX4aVP37OcgrSmPOm3 R5VoSCyjqJMwqpoz.i6uPHYyuY3Bpgr0Qn5aQmmBt9b2M5nExatRtjwIXyG7 MH.Yz4tA.upiMtEg4Sce5DQWd8EeT93wjZG_2mAucG9lhzE60BTddj2yEZuA DUuWflAKCO7zWyTagzP6iP5JmBMeZwtw8XXhNIu2dQ0TkXb_pGhIAUtZPgac 6NPLCCjGrvGUxilfAEDpQCDRG9iKFpAmICxZ9IHxI6ugly1ST8QZmp_Y727V Pn9gXXx0EgyGKFRlDYbVJN.Oy5tZvXLGAmyiMOt1TNRA0xpqskw1QRW4gTz8 QLK4uDAlQZLQ7p26ekoS0dbPyFyOaD8yzO896kIy_pn7AnkKm7Q-- Received: from [200.118.157.7] by web113510.mail.gq1.yahoo.com via HTTP; Wed, 01 Aug 2012 21:53:09 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.120.356233 References: <50064FB2.3020409@entel.upc.edu> Message-ID: <1343883189.38543.YahooMailNeo@web113510.mail.gq1.yahoo.com> Date: Wed, 1 Aug 2012 21:53:09 -0700 (PDT) From: Pedro Giffuni To: "attilio@FreeBSD.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD FS , "freebsd-current@freebsd.org" Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pedro Giffuni List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:53:15 -0000 Hi;=0A=0AJust thought I'd share a link for the fuse-xfs project (for MacFUS= E);=0A=0A=A0http://sourceforge.net/projects/fusexfs/=0A=0AIt's read-only so= maybe it can be considered a feature compatible=0Areplacement=A0of=A0our k= ernel driver ;).=0A=0Acheers,=0A=0APedro.=0A=0Aps. I added it to the Wanted= Ports wiki so it won't be forgotten=0Atoo soon. From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 06:23:59 2012 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 88EB0106564A; Thu, 2 Aug 2012 06:23:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B69838FC0A; Thu, 2 Aug 2012 06:23:58 +0000 (UTC) Received: by weyx56 with SMTP id x56so6840310wey.13 for ; Wed, 01 Aug 2012 23:23:57 -0700 (PDT) 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=GN9KYOawEBRyPlbPdBv5v2LEG7AGsqV/nuqhkTQY9S4=; b=fEFf9N6bETnBIsCTk4E1YYe96S4shEYhvIcEMWA5B2MqLfRiB96UG/9riR89jQJ9T3 wo4Yp7/U2kJ/Mx1jidvB9ihoj9xDFVr5rPP2d5UOIYFMLV58QrS9YknpVgBsmfjBkZHC giFaESenfweAoFa5O8JIzsOOwWyjlXy3EUZFG18bca27a7tv1SfMjQlgRTOKEpBVr+kP OhW0jU90iK1dj/CEZ57sONCXAJ8xNT1rMGvbpCYYvKy+VUhS435W1sB3g4XirrsAjw/Y uKoMvOtJO0lbbIkwOgaTkO/IZiHizYahmGlUOesYaMgaA1AZ1KOVYvkDo6X+P2x5yRMh FrOg== MIME-Version: 1.0 Received: by 10.180.78.99 with SMTP id a3mr1891948wix.15.1343888637682; Wed, 01 Aug 2012 23:23:57 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Wed, 1 Aug 2012 23:23:57 -0700 (PDT) In-Reply-To: <501A0258.4010101@FreeBSD.org> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> Date: Wed, 1 Aug 2012 23:23:57 -0700 Message-ID: From: Kevin Oberman To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 06:23:59 -0000 On Wed, Aug 1, 2012 at 9:30 PM, Doug Barton wrote: > On 8/1/2012 8:36 PM, Warner Losh wrote: >> I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. > > Actually if you take a step back and look at what Arnaud is saying > objectively, he's right. If anyone can attend the meeting by simply > getting an invitation from a committer, the only purpose the invitation > serves is to force the mere-mortal user to kiss someone's ring. That's > precisely the kind of elitist crap that I've been railing against for so > many years now. > > OTOH, currently the dev summits generally take place with limited > resources, so it's not really possible to have "everyone" attend. And > (TMK) the "invitation" process is really more like a restaurant with a > sign that says "we reserve the right to refuse service to anyone." > > But on the _other_ other hand, the problem of things being discussed > and/or decisions being taken exclusively at the dev summits, especially > BSDCAN, has gotten quite bad over the last several years. Even amongst > committers, the community has become divided between the "haves" who can > travel to the summit, and the "have nots" who can't. Note, I'm quite > sure that this statement will be met with howls of protest, from the > "haves," that this isn't the case. Even if they were sincere, it's > incredibly easy for the people with the privileges to see their > privileged state as "normal," and lose sight of how the world looks from > the cheap seats. > > In spite of Kevin's concerns (and I don't know what working groups he's > been attending) the IETF model is really a good one to examine here. The > majority of the work gets done on the mailing lists, with working group > meetings serving as an opportunity for group discussion, presentations, > etc. The results of the meetings are then published to the mailing list > in the form of minutes, and the final decisions are made in public, on > the lists. Another incredibly important feature, the meetings are open > to remote participation in the sense that slide decks are published in > advance, the meeting audio is streamed live, and there are jabber rooms > for remote participants to interact with the people in the meeting. > > I used to ask the PTB to provide *some* form of remote participation for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem that > we can't solve), or embarrassment. Since if the right people around here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. > > If the only large, open project you've ever participated in is FreeBSD, > what gets done around here feels "normal" to you. But don't be so quick > to dismiss the viewpoints of people who have experience in the wider world. > > Doug Doug makes some good points. The lack of any opportunity for remote participation in this day and age seems quite odd. Almost all conferences of more that half a dozen people are available remotely, at least for observers. Some are set up for full remote participation including presentations, questions (via chat) and voting/polling. It is surprising to me that something is not available for significant FreeBSD meetings. By the way, WGs that gave me major issues were SNMP and DNS. SNMP was dissolved and the DNS group finally accomplished its job about two years later than it should have by scheduling meetings, still open, outside of IETF meetings and thanks to the stubborn determination of Randy Bush. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 07:54:15 2012 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 CE4671065670 for ; Thu, 2 Aug 2012 07:54:15 +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 881728FC14 for ; Thu, 2 Aug 2012 07:54:15 +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 <1SwqER-0003U3-Po>; Thu, 02 Aug 2012 09:54:07 +0200 Received: from munin.geoinf.fu-berlin.de ([130.133.86.110]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1SwqER-0002ke-N8>; Thu, 02 Aug 2012 09:54:07 +0200 Message-ID: <501A323E.6000106@zedat.fu-berlin.de> Date: Thu, 02 Aug 2012 09:54:38 +0200 From: "Hartmann, O." Organization: FU Berlin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.110 Subject: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 07:54:15 -0000 I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 11:23:26 2012 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 720A0106566B; Thu, 2 Aug 2012 11:23:26 +0000 (UTC) (envelope-from edschouten@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 280738FC12; Thu, 2 Aug 2012 11:23:26 +0000 (UTC) Received: by obbun3 with SMTP id un3so17640791obb.13 for ; Thu, 02 Aug 2012 04:23:25 -0700 (PDT) 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=2CSm5sSTEE0L6ZaUe16kyUhVEulxrGsSPMQkVvJECyg=; b=yy7PZcubDqxvo3QfAoGfyG9hD3OFdIwkz02LHYuKlJRxG1FjKLmD0ZAnvRNK5Cwa8h MJ3jDnbLGJakew7Hu771qIO9qDKiU8bbYegA2+oLgh3PVWdFbILGNequaB2eZdNL5eHi QQr7Nk6OE1b2YYERO8x04ePWKN7po9VSQGRmaKQ5o2f0HZd/PTm5t20wPnYe+uPoFNWu DoExJ8+fMgYWQgIyUlJjrvOejDiieBlr7WqdtPJqj+DZ5Y3PL9DGW/k0Xxu0ds+KMFBY sbq2fD1yliWD8FQXa4eX5ztaGnH5MnDLTIh+vK7cAobmUCfF66mFNCKuEiHpckrh69VP qsJA== MIME-Version: 1.0 Received: by 10.60.13.228 with SMTP id k4mr35494139oec.28.1343906605441; Thu, 02 Aug 2012 04:23:25 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Thu, 2 Aug 2012 04:23:25 -0700 (PDT) In-Reply-To: <5019B1F8.5080802@freebsd.org> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> <5019B1F8.5080802@freebsd.org> Date: Thu, 2 Aug 2012 13:23:25 +0200 X-Google-Sender-Auth: 5UtS0hd5iHmi9ER9ijEnioBEa2U Message-ID: From: Ed Schouten To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 11:23:26 -0000 2012/8/2 Julian Elischer : > I think that the /dev/entries can (and SHOULD) go away when the hardware > goes away and even be re-used. But here's the point. TTYs are used in a different way than other device nodes. Regular device nodes are simply opened by a set of independent process (e.g. dd if=/dev/da0, a music player opening /dev/dsp, etc). TTYs are used by a set of processes that share a weak relationship, namely all belonging to the same login session. Things *really* break if you were to forcefully remove a TTY device node and replace it by another TTY. Even for physical devices it would be really bad to do. Consider a system that has two USB to serial converters that are used for interactive login sessions. One is plugged in, the other one isn't. If you unplug one device and plug in the other, you never want the processes from the one login session to start interacting with the other device. Also, applications relying on the user accounting database (utmpx) will start to behave non-deterministically then. Do we really want biff and wall to write stuff to random TTYs? Whether or not the TTY is a pseudo-terminal or not is completely irrelevant in my opinion. -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 06:10:14 2012 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 D3FED1065670; Thu, 2 Aug 2012 06:10:14 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9C38FC14; Thu, 2 Aug 2012 06:10:13 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q726A4gM002750; Thu, 2 Aug 2012 08:10:04 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q726A4UJ002747; Thu, 2 Aug 2012 08:10:04 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 2 Aug 2012 08:10:04 +0200 (CEST) From: Wojciech Puchar To: Steve Kargl In-Reply-To: <20120802034302.GA30400@troutmask.apl.washington.edu> Message-ID: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <20120802034302.GA30400@troutmask.apl.washington.edu> 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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 02 Aug 2012 08:10:04 +0200 (CEST) X-Mailman-Approved-At: Thu, 02 Aug 2012 11:35:40 +0000 Cc: Adrian Chadd , FreeBSD Hackers , attilio@freebsd.org, freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 06:10:14 -0000 >> > > Yep. In 18+ years of being subscribed to various freebsd > lists, Arnaud has the honor of being only the 2nd person > to earn a killfile entry. He's now sitting next to Jesus > Monroy, Jr. it is not a proud from you to talk about who you are blocking. From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 12:00:55 2012 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 EAA9B10656E7; Thu, 2 Aug 2012 12:00:55 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A31968FC16; Thu, 2 Aug 2012 12:00:55 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 38FF73B764; Thu, 2 Aug 2012 12:00:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q72C0mwd079435; Thu, 2 Aug 2012 12:00:48 GMT (envelope-from phk@phk.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 02 Aug 2012 13:23:25 +0200." Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 02 Aug 2012 12:00:47 +0000 Message-ID: <79434.1343908847@critter.freebsd.dk> Cc: Konstantin Belousov , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 12:00:56 -0000 In message , Ed Schouten writes: >2012/8/2 Julian Elischer : TTYs are used *two* ways: As terminals and as comms to the real world. If a terminal-tty disappears, it should be handled like a HUP would be, analytically it is the exact same situation as a carrier drop on a modem. The implementation may need to do tricky stuff, but the result should be exactly like a HUP seen from userland. If a comms-tty disappears, it should be handled like any other disappearing device: ENXIO. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 12:54:49 2012 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 95330106564A; Thu, 2 Aug 2012 12:54:49 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 575A98FC22; Thu, 2 Aug 2012 12:54:49 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72Csbic078991 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 12:54:38 GMT (envelope-from theraven@theravensnest.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501A0258.4010101@FreeBSD.org> Date: Thu, 2 Aug 2012 13:54:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 02 Aug 2012 12:58:16 +0000 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 12:54:49 -0000 On 2 Aug 2012, at 05:30, Doug Barton wrote: > I used to ask the PTB to provide *some* form of remote participation = for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem = that > we can't solve), or embarrassment. Since if the right people around = here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. You haven't asked for this for the Cambridge DevSummit, but others have = and so we have arranged for cameras and microphones to be available for = two of the sessions (the DocSummit and the ARM working group) to allow = those who can not attend in person for various reasons to participate. =20= I don't know how useful it will be (hopefully everything will work, but = my experience with video conferencing is that it stops working as soon = as you try to do something important with it), but there is certainly no = active attempt to exclude people who can't attend. =20 After each DevSummit, the results seem to appear on the wiki quite = promptly - often during the sessions. At BSDCan this year, two of the = working groups that I attended used OpenEtherPad to take minutes, so = they were available in real time for non-attendees and people outside of = the room were able to add things to them. There are usually people in = the room on IRC as well, who are willing to relay things from people = outside. David= From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 15:04:51 2012 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 3BA7B10656AC for ; Thu, 2 Aug 2012 15:04:51 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3D978FC17 for ; Thu, 2 Aug 2012 15:04:50 +0000 (UTC) Received: by bkcje9 with SMTP id je9so4413449bkc.13 for ; Thu, 02 Aug 2012 08:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gnFTixluD4+hpbflBrfqtRqzwj7eHknsaqc8XIV3ybE=; b=xm6qe6ld+KBVwpG6zDkdu2V6QK2W8F4v1ygqcG0YU2GrSekTN4sgmDEvXQUsgaPvwu qzlXP8XC2pKj8qdWyMRMopNWXF5yBAqQZsFy8oSQwWNCx/ll4f8krjUpsaGMLMRLP2OT 7owDljx/XdHxKRM1USAoQQYWqfZp4klFUqEI0XWp45vytD8qcE5WmaCyp7hSo6kv+/02 1UpE9dPQSUcRPvsKS0twXpFH8MSkE9Vob0DfkziUWrE9HPC0AYvg2Iv6R8SuuiZHBLuh Z3FSvWxxlFx5AZEaE3A+/3Kol+4gZB77V1PMY0j3k3Oc/xFDFF1TGCjRSgtd5YgNmncT 1pAw== Received: by 10.204.154.211 with SMTP id p19mr8675679bkw.12.1343919889407; Thu, 02 Aug 2012 08:04:49 -0700 (PDT) Received: from [192.168.1.80] (dsl51B69674.pool.t-online.hu. [81.182.150.116]) by mx.google.com with ESMTPS id n5sm3598891bkv.14.2012.08.02.08.04.48 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 08:04:48 -0700 (PDT) Message-ID: <501A9849.3090804@gmail.com> Date: Thu, 02 Aug 2012 17:10:01 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120716 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: On cooperative work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 15:04:51 -0000 Has anyone, ever, proposed, thought about, or used a hierarchical feedback model, where conference participants are grouped into some tree, where one experienced (or trusted) person in a group would answer simple questions (coming from other members of the group), and forward advanced questions to the head presentor (or, generally, to a higher tree level) in a compact fashion? From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 16:20:39 2012 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 36B7C106566C; Thu, 2 Aug 2012 16:20:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C39BD8FC0A; Thu, 2 Aug 2012 16:20:38 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q72GKYsL097114; Thu, 2 Aug 2012 10:20:34 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Scott Long In-Reply-To: Date: Thu, 2 Aug 2012 10:20:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> To: Kevin Oberman X-Mailer: Apple Mail (2.1485) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD Hackers , Doug Barton , Warner Losh , Arnaud Lacombe , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 16:20:39 -0000 On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: > Doug makes some good points. No, he doesn't. He and Arnould being argumentative and accusatory where = none of that is warranted. I used to run the devsummits, and we did tele-conference lines for = remote people to participate. After I stepped down, others took it up = and did the same thing. Usually, the lines were unused. I suspect that = organizers simply stopped thinking about them after a while because of = poor interest. There is no conspiracy of exclusion here, just simple = human apathy. The invite system for the devsummit was, and still is, purely about = providing some order to the process. It ensures that people attending = are willing to demonstrate a minimum amount of interest, more than just = wondering by a room one day and dropping in for free food and wifi. If = anyone feels that they are being excluded, it's because they are too = lazy to go beyond being argumentative on a mailing list. Scott From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 15:17:03 2012 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 1FDAC106566B for ; Thu, 2 Aug 2012 15:17:03 +0000 (UTC) (envelope-from surajsandhu.2005@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE7658FC0A for ; Thu, 2 Aug 2012 15:17:02 +0000 (UTC) Received: by qaat11 with SMTP id t11so1481571qaa.13 for ; Thu, 02 Aug 2012 08:16:56 -0700 (PDT) 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=RgeOsmKIkAJM4BTu3d7Nfb1DykBvLw4x3z0p2UHvzZ4=; b=iMqs0fUwBi0K3TpN83N6V/DapyO9WvmKDHrk8eMY04YfIKdLvZdAKb6931f/nSukW/ /T9uM3RV9GkWzuH0paC6yZBlEzhL0JSz3nXgSEywrr/ETlYdmETO2KzhUBQ+/sItFy4d nRCXwAGPYr8kVOQAo9+IwUTjLq1oUyF1ciZg6jSSbfj8QqjtHruH2key1ob0pwozi5cb 01o+St6HoCr8qucLqXtgOHTGF9O6OwabIBgN8yJztbOAUae+bGGAeBxZDQSmHF24AcAD BX8LOayiRLYA62tKfRwafnaPFuIxuScdtN0boh/BMVoRZ6U6ZEIcsOxDwRzsOIzcnHBV +xEw== MIME-Version: 1.0 Received: by 10.224.189.17 with SMTP id dc17mr183722qab.47.1343920616390; Thu, 02 Aug 2012 08:16:56 -0700 (PDT) Received: by 10.229.204.131 with HTTP; Thu, 2 Aug 2012 08:16:56 -0700 (PDT) Date: Thu, 2 Aug 2012 11:16:56 -0400 Message-ID: From: suraj sandhu To: freebsd-current@freebsd.org X-Mailman-Approved-At: Thu, 02 Aug 2012 16:29:26 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Warning: ifaddr refcount use patch (svn commit: r194760 - in head/sys: contrib/rdma net net80211 netinet netinet6 netipx (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 15:17:03 -0000 Hi Robert, I am using Freebsd 8.2 and facing the Use-after-free issue because of the possible reference release on ifaddr without it being acquired. The issue is that ifa remains on the addr list of ifp but it is already free which leads to the panic in the code trying to traverse through the ifaddr list of ifp. I am wondering if the patches you mentioned in the thread are still available. Thanks, Suraj From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 16:37:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5B3C8106564A; Thu, 2 Aug 2012 16:37:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DEBFF14E2EC; Thu, 2 Aug 2012 16:37:09 +0000 (UTC) Message-ID: <501AACB5.5020004@FreeBSD.org> Date: Thu, 02 Aug 2012 09:37:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Scott Long References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> In-Reply-To: <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 16:37:10 -0000 On 08/02/2012 09:20, Scott Long wrote: > > On Aug 2, 2012, at 12:23 AM, Kevin Oberman > wrote: > >> Doug makes some good points. > > No, he doesn't. Yes I do! (So there) > He and Arnould being argumentative and accusatory > where none of that is warranted. > > I used to run the devsummits, and we did tele-conference lines for > remote people to participate. I singled out BSDCAN specifically since that's "where the action is" for the last several years. I do recall your efforts in this regard, but it so happened that I was able to attend most of them in person back then. No slight towards what you did was intended. > After I stepped down, others took it > up and did the same thing. Usually, the lines were unused. I > suspect that organizers simply stopped thinking about them after a > while because of poor interest. There is no conspiracy of exclusion > here, just simple human apathy. Here I have to disagree with you. Once again, speaking specifically about BSDCAN dev summits, I repeatedly asked the organizers to provide some sort of audio stream (phone, Internet, anything) and was repeatedly told it wasn't possible. This was not a case of lack of interest. This was a case of "We understand that it is something people want, but it isn't going to happen." > The invite system for the devsummit was, and still is, purely about > providing some order to the process. It ensures that people > attending are willing to demonstrate a minimum amount of interest, > more than just wondering by a room one day and dropping in for free > food and wifi. I specifically made allowances for this issue in my post. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 16:44:43 2012 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 30D741065674; Thu, 2 Aug 2012 16:44:43 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3A78FC14; Thu, 2 Aug 2012 16:44:42 +0000 (UTC) Received: by qcsg15 with SMTP id g15so6692052qcs.13 for ; Thu, 02 Aug 2012 09:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uOEMvAZkS+PqmVv7TP6y2wuWnkuhhO9G+niZC1tvaLA=; b=FXzKfbSpyNon91r6muY3McQ56+/Q+C245Z8yiaFBBP1R2HyfAs7+9u7vogb4LHhMV0 WleEvdJ/byyUwVz6VgOMEdHHwyUpzsc0cSq+9ykHJFWAGwI2i0Z3uWKiu3hTUpK7+ZUO fDcF5Qwpabv4Tbq/8/vFiSJKlgHMsz2q2ltcS+S7cYbvfAe0XlzRQdA1ZA4U7bfAFcFN m0TE0lX/t9+ApTiNZQt4qxKqbc7G4EGkJLlT4VtFxPKBG7QSUDrmrlps/FdqjNR6+pG1 JlUlGufz5JtUYNn6wxsv/yTY4Uel/WjUjFISPYXGsO/HLjQes8ymLHj4Kq86QmV4zivS mKvw== Received: by 10.60.30.35 with SMTP id p3mr38195405oeh.16.1343925881468; Thu, 02 Aug 2012 09:44:41 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id m7sm4905767oef.1.2012.08.02.09.44.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 09:44:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> Date: Thu, 2 Aug 2012 09:44:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> To: Scott Long X-Mailer: Apple Mail (2.1278) Cc: Doug Barton , FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 16:44:43 -0000 On Aug 2, 2012, at 9:20 AM, Scott Long wrote: >=20 > On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: >=20 >> Doug makes some good points. >=20 > No, he doesn't. He and Arnould being argumentative and accusatory = where none of that is warranted. >=20 > I used to run the devsummits, and we did tele-conference lines for = remote people to participate. After I stepped down, others took it up = and did the same thing. Usually, the lines were unused. I suspect that = organizers simply stopped thinking about them after a while because of = poor interest. There is no conspiracy of exclusion here, just simple = human apathy. The "Watson/Losh connection" worked really well in BSDCan 2010 = :). Advertising the teleconferencing lines might be an issue (I = would have loved to have joined in some of the remote conferences, if = for nothing more than be a fly on the wall, this year), but that's a = separate thing aside. There's some misunderstanding, assumption, etc mixed together in = this mailing chain that I think is probably better resolved with some = face-to-face conversations or maybe just more rational (and less heated) = discussion. Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 16:48:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E85541065674; Thu, 2 Aug 2012 16:48:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4C61A1508ED; Thu, 2 Aug 2012 16:46:42 +0000 (UTC) Message-ID: <501AAEF2.8060202@FreeBSD.org> Date: Thu, 02 Aug 2012 09:46:42 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Chisnall References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 16:48:27 -0000 On 08/02/2012 05:54, David Chisnall wrote: > On 2 Aug 2012, at 05:30, Doug Barton wrote: > >> I used to ask the PTB to provide *some* form of remote >> participation for even a fraction of the events at the dev summit. >> I don't bother asking anymore because year after year my requests >> were met with any of: indifference, hostility, shrugged shoulders >> (that's a hard problem that we can't solve), or embarrassment. >> Since if the right people around here want something to happen, it >> happens; I finally came to the conclusion that they didn't want >> remote participation to happen, so it won't. That's a shame. > > You haven't asked for this for the Cambridge DevSummit, You did read the part where I gave up, right? > but others > have and so we have arranged for cameras and microphones to be > available for two of the sessions (the DocSummit and the ARM working > group) to allow those who can not attend in person for various > reasons to participate. Well that's a start. :) And where was this availability announced? If I missed it, that's on me. But providing remote access that you don't tell people about isn't really any better than not providing it at all. > I don't know how useful it will be (hopefully everything will work, > but my experience with video conferencing is that it stops working as > soon as you try to do something important with it), If I can offer some advice from the trenches ... focus on making the audio robust, and put efforts into the video as resources permit. The combination of solid audio, making presentations available on line, and a chat room (IRC, jabber, whatever) allows for a great deal of remote participation. Video is nice, but if the video going down takes the audio with it, you're no better off than when you started. > but there is > certainly no active attempt to exclude people who can't attend. ... and here is where I need to push back. "No active attempt to exclude people" is not the same thing as actively encouraging remote participation. It's the latter that we're after. > After each DevSummit, the results seem to appear on the wiki quite > promptly - often during the sessions. At BSDCan this year, two of > the working groups that I attended used OpenEtherPad to take minutes, > so they were available in real time for non-attendees and people > outside of the room were able to add things to them. There are > usually people in the room on IRC as well, who are willing to relay > things from people outside. Those all sound like nice steps forward, thank you for pointing them out. Nothing would make me happier than to be proven wrong in this area. What would be nice I think would be if these steps were formalized, and shared more openly. Having things on the wiki is nice, but reporting things in detail on the mailing lists puts it in the archives for future reference, as well as making it more broadly available to start with. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 16:54:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DACD010656B9; Thu, 2 Aug 2012 16:54:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9CFF614DD7F; Thu, 2 Aug 2012 16:53:34 +0000 (UTC) Message-ID: <501AB08E.8020008@FreeBSD.org> Date: Thu, 02 Aug 2012 09:53:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 16:54:28 -0000 On 08/02/2012 09:44, Garrett Cooper wrote: > > The "Watson/Losh connection" worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for "the right people," even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. > Advertising the teleconferencing lines might be an issue (I would > have loved to have joined in some of the remote conferences, if for > nothing more than be a fly on the wall, this year), but that's a > separate thing aside. At various points when I was asking for remote participation at BSDCAN different people offered to provide this through their company's teleconferencing solutions, providing that the organizers could put a phone line in the room(s). They were told that it wasn't possible to do that. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:13:07 2012 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 7B6B9106564A; Thu, 2 Aug 2012 17:13:07 +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 3D70C8FC1A; Thu, 2 Aug 2012 17:13:06 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72HD49s079836 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 17:13:06 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501AAEF2.8060202@FreeBSD.org> Date: Thu, 2 Aug 2012 18:13:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , freebsd-current@FreeBSD.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:13:07 -0000 On 2 Aug 2012, at 17:46, Doug Barton wrote: > Well that's a start. :) And where was this availability announced? If = I > missed it, that's on me. But providing remote access that you don't = tell > people about isn't really any better than not providing it at all. It's not widely advertised, because we're likely to be able to support a = limited number of remote participants (10 seems like the upper limit for = the technology that we're looking at, and I wouldn't be surprised if it = degrades before then). As with all other things in the project, we = welcome people who are willing to make an effort to engage. We provide = it when people ask, not spontaneously, because organising cameras and = decent microphones requires effort on the bart of the organisers. We = only have one microphone available that will give good pickup over a = whole room, for example, so we can't offer remote participation in = parallel streams and we need to prioritise people who are willing to go = to the massive effort of sending a one-line email saying 'I would like = to make a contribution in this working group but am unable to attend'. =20= The FreeBSD Foundation has also offered to fund new contributors who = want to attend but are unable to afford to do so on their own. In spite = of the fact that I spent some effort encouraging people to apply for = this, only one person actually did. =20 We make a considerable effort to ensure that DevSummits are easy to = attend for anyone who wants to contribute to the projects. They are not = intended as spectator events, but for anyone who wishes to engage with = the community there are procedures in place for attending or = participating remotely. I have very little sympathy with people who = complain that the community isn't engaging with them, without making the = effort to engage with the community. =20 David From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:28:33 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 16C68106564A; Thu, 2 Aug 2012 17:28:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A926614E51C; Thu, 2 Aug 2012 17:28:32 +0000 (UTC) Message-ID: <501AB8C0.3020102@FreeBSD.org> Date: Thu, 02 Aug 2012 10:28:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Chisnall References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@FreeBSD.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:28:33 -0000 On 08/02/2012 10:13, David Chisnall wrote: > On 2 Aug 2012, at 17:46, Doug Barton wrote: > >> Well that's a start. :) And where was this availability announced? >> If I missed it, that's on me. But providing remote access that you >> don't tell people about isn't really any better than not providing >> it at all. > > It's not widely advertised, because we're likely to be able to > support a limited number of remote participants (10 seems like the > upper limit for the technology that we're looking at, and I wouldn't > be surprised if it degrades before then). Welcome to the 21st Century. :) There are widely available audio and video conferencing solutions that easily scale into the thousands of users, at minimal cost. > As with all other things > in the project, we welcome people who are willing to make an effort > to engage. We provide it when people ask, not spontaneously, because > organising cameras and decent microphones requires effort on the bart > of the organisers. Yes, "It takes effort." I get that. I've been part of the effort to provide remote participation for other groups, on a much larger scale than anything FreeBSD can dream of. My point, and I cannot emphasize this highly enough, is that your entire mindset about this is all wrong. It needs to shift from "We'll do this on a small scale, for those who ask" to "We'll make providing robust remote participation a top priority, built into the planning from day 1." It's as simple as that. > The FreeBSD Foundation has also offered to fund new contributors who > want to attend but are unable to afford to do so on their own. In > spite of the fact that I spent some effort encouraging people to > apply for this, only one person actually did. It isn't just the financial cost of attending the summit. Often (as in my case) it's the lack of ability to take time away from personal, work, and/or family commitments. For others it may be the difficulty of doing the traveling at all. The fact that only 1 person took you up on this offer (and IIRC there have been similar results in the past) pretty clearly indicates that you're trying to solve the wrong problem. Given that the foundation has money to spend here, why not put 2 and 2 together and have the foundation invest in providing remote participation? That would benefit far more people, and almost certainly at less cost. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:34:08 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DEFFF106566C; Thu, 2 Aug 2012 17:34:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 989BC14DAAE; Thu, 2 Aug 2012 17:34:08 +0000 (UTC) Message-ID: <501ABA10.4050204@FreeBSD.org> Date: Thu, 02 Aug 2012 10:34:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: FreeBSD Hackers , freebsd-current@FreeBSD.org References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> In-Reply-To: <501AB8C0.3020102@FreeBSD.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:34:09 -0000 BTW, for those who'd like to get a flavor of what the IETF model looks like, the Vancouver meeting is in process now: https://datatracker.ietf.org/meeting/84/agenda.html Feel free to join in as a lurker. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:37:13 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CDD94106567E; Thu, 2 Aug 2012 17:37:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A247015125B; Thu, 2 Aug 2012 17:36:41 +0000 (UTC) Message-ID: <501ABAA9.2030607@FreeBSD.org> Date: Thu, 02 Aug 2012 10:36:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: FreeBSD Hackers , freebsd-current@FreeBSD.org References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABA10.4050204@FreeBSD.org> In-Reply-To: <501ABA10.4050204@FreeBSD.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:37:13 -0000 On 08/02/2012 10:34, Doug Barton wrote: > BTW, for those who'd like to get a flavor of what the IETF model looks > like, the Vancouver meeting is in process now: > > https://datatracker.ietf.org/meeting/84/agenda.html > > Feel free to join in as a lurker. Sorry, this agenda makes it easier to see the remote participation stuff: https://tools.ietf.org/agenda/84/ -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:37:37 2012 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 87C861065747; Thu, 2 Aug 2012 17:37:37 +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 48DA58FC16; Thu, 2 Aug 2012 17:37:37 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72HbZTV079910 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 17:37:36 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501AB8C0.3020102@FreeBSD.org> Date: Thu, 2 Aug 2012 18:37:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:37:37 -0000 On 2 Aug 2012, at 18:28, Doug Barton wrote: > Welcome to the 21st Century. :) There are widely available audio and > video conferencing solutions that easily scale into the thousands of > users, at minimal cost. >=20 > Yes, "It takes effort." I get that. I've been part of the effort to > provide remote participation for other groups, on a much larger scale > than anything FreeBSD can dream of. >=20 > My point, and I cannot emphasize this highly enough, is that your = entire > mindset about this is all wrong. It needs to shift from "We'll do this > on a small scale, for those who ask" to "We'll make providing robust > remote participation a top priority, built into the planning from day > 1." It's as simple as that. Thank you for volunteering to organise this. It's good to see people = with both the motivation and experience required to do something well = actively contributing to the project. David= From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:40:45 2012 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 19A011065672 for ; Thu, 2 Aug 2012 17:40:45 +0000 (UTC) (envelope-from imp@bsdimp.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 BF9178FC21 for ; Thu, 2 Aug 2012 17:40:43 +0000 (UTC) Received: by obbun3 with SMTP id un3so18190489obb.13 for ; Thu, 02 Aug 2012 10:40:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5gLTnC0fWtxDHr9cU/6VfTjSPuarIcST/f9xiP5SV70=; b=BO1/TiJGsUKscCethfTdr79voqcno6SWk0OU0gEKNJSE34rCDH8+dGMAy3rpXeD7wQ Cth7NtjOqzYRGuL3RzFZIFn+51dy/QxmG8S5yY6SOgdaNP6Utp+o6RvPuEZaob2kwNHD NHqYfnBFAPuU28FYVm9OiDhJ1ybrC1Qu3o9QUMwistul6Qd1tYrIHtVApbrOQAtDW5PO 6Ku4J+vvpJtLI596bdKG0GobGd0GzU6P1VrRYuHYOTnPvQLUDY1AuWLdljxce+NEoHot shkFwFr0JEVOhi7gKMVCt/SKAskUEGxG8tP29/kh0dz8ZIdC99kUoq6la5Fi+XI0b07K ZmYA== Received: by 10.182.164.40 with SMTP id yn8mr38525397obb.40.1343929242752; Thu, 02 Aug 2012 10:40:42 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id a9sm6518625obp.14.2012.08.02.10.40.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 10:40:42 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <501AAEF2.8060202@FreeBSD.org> Date: Thu, 2 Aug 2012 11:40:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE87ACB-10FD-4B23-850E-B0C4F564AB8F@bsdimp.com> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlaBSGewqhJzpMDaSP1Lm+Sw1ILTEuQ4jfRXz1olm9EVMnbqVi+y5D408G+BU8zxDMFidl8 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, David Chisnall Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:40:45 -0000 On Aug 2, 2012, at 10:46 AM, Doug Barton wrote: > Those all sound like nice steps forward, thank you for pointing them > out. Nothing would make me happier than to be proven wrong in this = area. > What would be nice I think would be if these steps were formalized, = and > shared more openly. Having things on the wiki is nice, but reporting > things in detail on the mailing lists puts it in the archives for = future > reference, as well as making it more broadly available to start with. One thing to remember about the IETF. There's many vendors that devote = significant resources to the IETF. While I was at Cisco, for example, I = know that we provided audio and video bridges to IEFT meetings to = facilitate remote attendance at the meetings. Cisco dedicated several = engineers to ensure that the audio and video quality remained good = during the meetings and were able to use facilities cisco normally used = for things like WebEx and MeetingPlace. With a global presence and = infrastructure, they were able to pull it off. I'm not aware of similar = resources within the project. We don't have any such benefactor in the project, so we have to rely on = the kindness of strangers. AsiaBSDcon live streams most of its talks, = but uses a free service that changes from year to year and is quite good = for talks, but can't do meetings at all. Other meeting things do = meetings OK, but the video or audio quality sucks unless you have high = end gear for the source. Mapping out what hardware, software and service = combinations work would be very beneficial. I suspect this will vary = based on geographic location (stuff that works good in the US won't work = in EU or Asia and vice versa). These issues are what makes it hit or = miss. While it is easy to skype one or two people into a meeting, that = scales poorly to more than two. Plus if things are going poorly, the = attempt to broadcast the meeting can derail or eat into the time = available significantly. I guess this is a long way to say that while one to one, and one to many = problems have relatively easy solutions, many to many like we need still = remains fussy and difficult. Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:42:55 2012 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 8082B1065670; Thu, 2 Aug 2012 17:42:55 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B36E8FC1E; Thu, 2 Aug 2012 17:42:54 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so10330144vcb.13 for ; Thu, 02 Aug 2012 10:42:54 -0700 (PDT) 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=FARLlrA/7gityq7RSE8nvLZATOwvUv9/emPGJATdKZk=; b=Lv9HWioS86xNGsbhZoxoRtKwaVV7T9DjG8XxgqEYNRm3sC9nicK4uHq8CmcJ6x5H1l cA7aVCbdaJHE2u2PW+rPvfSwIWAjmnwD/fcmj+nF3u6oVttU44jjknSmcN10w24OHysc EniUPoW1y2GCE0jEv44GKFppT2L2GoQCIkZktyeXec48Rktoxp19RANJyEq1LOw07vpA bXa0cPx19c/FTzetFDOpueC489v84CTmHU++tWG1b3qyJruPZnctQBtdq/x8DInDUZEh d4Pya6LLxl6oYbRKwgoGaqxN3lZ8pJ8VyPLbPT/utLOJq09z7XVCLak+Um0OyrqW9OJy /5/w== MIME-Version: 1.0 Received: by 10.220.150.211 with SMTP id z19mr10494392vcv.48.1343929374276; Thu, 02 Aug 2012 10:42:54 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.58.196.170 with HTTP; Thu, 2 Aug 2012 10:42:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Aug 2012 19:42:54 +0200 X-Google-Sender-Auth: DTNJpdxM-s_crrafbYKLKxFnRGM Message-ID: From: Davide Italiano To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:42:55 -0000 On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >>>> >>>> You don't want to work cooperatively. >>>> >>> Why is it that mbuf's refactoring consultation is being held in >>> internal, private, committers-and-invite-only-restricted meeting at >>> BSDCan ? >>> >>> Why is it that so much review and discussion on changes are held privately ? >> >> Arnaud, >> belive me, to date I don't recall a single major technical decision >> that has been settled exclusively in private (not subjected to peer >> review) and in particular in person (e-mail help you focus on a lot of >> different details that you may not have under control when talking to >> people, etc). >> > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. > >> Sometimes it is useful that a limited number of developers is involved >> in initial brainstorming of some works, >> > Never. > >> but after this period >> constructive people usually ask for peer review publishing their plans >> on the mailing lists or other media. >> > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." > > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. > Well, my talk was mainly there to collect some opinion on how to continue my work. IIRC, the only one objection was on supporting callout execution from hw interrupt context. Mainly, the objection moved was that there were no practical applications for that. It turned out I found some, and in any case it wasn't "it will not work" but "probably it's not an effort you want to put because the consumers that can exploit some functionality are few". I wasn't really so familiar with that so I hesitated in answering. In any case, I liked a lot the objection moved by Attilio because it gave me the possibility to investigate and find out the right direction. As you may see, there's a branch in projects/ in which the feature that "won't work" is implemented, so, maybe you're missing something. If you had some concerns on it you can raise up your hand and tell: "hey, that sucks". It would be better than getting this feedback after 3 months of work honestly. I have nothing in contrary about getting feedbacks (negative or positive). But probably you belong to that kind of people that are able to tell only behind a monitor, so this is my last word on the topic. Get a life. >> If you don't see any public further discussion this may be meaning: >> a) the BSDCan meetings have been fruitless and there is no precise >> plan/roadmap/etc. >> > so not only you make it private, but it shamelessly failed... > >> b) there is still not consensus on details >> > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > >> and you can always publically asked on what was decided and what not. >> Just send a mail to interested recipients and CC any FreeBSD mailing >> list. >> > This is not the way "openness" should be about. > > - Arnaud > >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Davide From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:48:42 2012 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 D2E0D1065674; Thu, 2 Aug 2012 17:48:42 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 97FF78FC12; Thu, 2 Aug 2012 17:48:42 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1SwzVe-0003l2-2H; Thu, 02 Aug 2012 13:48:30 -0400 Date: Thu, 2 Aug 2012 13:48:29 -0400 From: Gary Palmer To: Doug Barton Message-ID: <20120802174829.GA574@in-addr.com> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501AAEF2.8060202@FreeBSD.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD Hackers , freebsd-current@freebsd.org, David Chisnall Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:48:43 -0000 On Thu, Aug 02, 2012 at 09:46:42AM -0700, Doug Barton wrote: > > but there is > > certainly no active attempt to exclude people who can't attend. > > ... and here is where I need to push back. "No active attempt to exclude > people" is not the same thing as actively encouraging remote > participation. It's the latter that we're after. s/encouraging remote/encouraging constructive remote/ The last thing we need is more people trying to get things done their way because they know best. People need to be willing to accept that maybe some widget they want won't be part of the goal of the project under discussion, for whatever reason. I've seen too many ... heated debates start up largely because people were not discussing things face to face. I'm not saying that all of the debates wouldn't happen if people were all in the same room, but a lot of them wouldn't. Larger/longer term projects should probably have their own mailing list set up for discussion. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:50:27 2012 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 8C98B1065676; Thu, 2 Aug 2012 17:50:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 432FF8FC14; Thu, 2 Aug 2012 17:50:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93D7FB968; Thu, 2 Aug 2012 13:50:26 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 2 Aug 2012 08:39:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <501A0258.4010101@FreeBSD.org> In-Reply-To: <501A0258.4010101@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208020839.07910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 Aug 2012 13:50:26 -0400 (EDT) Cc: FreeBSD Hackers , Doug Barton , Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:50:27 -0000 On Thursday, August 02, 2012 12:30:16 am Doug Barton wrote: > On 8/1/2012 8:36 PM, Warner Losh wrote: > > I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. > > Actually if you take a step back and look at what Arnaud is saying > objectively, he's right. If anyone can attend the meeting by simply > getting an invitation from a committer, the only purpose the invitation > serves is to force the mere-mortal user to kiss someone's ring. That's > precisely the kind of elitist crap that I've been railing against for so > many years now. > > OTOH, currently the dev summits generally take place with limited > resources, so it's not really possible to have "everyone" attend. And > (TMK) the "invitation" process is really more like a restaurant with a > sign that says "we reserve the right to refuse service to anyone." The latter bits here are mostly true. The biggest constraint is space. Also, I don't know of anyone that has asked to attend the developer summit as a guest that wasn't invited. > But on the _other_ other hand, the problem of things being discussed > and/or decisions being taken exclusively at the dev summits, especially > BSDCAN, has gotten quite bad over the last several years. Even amongst > committers, the community has become divided between the "haves" who can > travel to the summit, and the "have nots" who can't. Note, I'm quite > sure that this statement will be met with howls of protest, from the > "haves," that this isn't the case. Even if they were sincere, it's > incredibly easy for the people with the privileges to see their > privileged state as "normal," and lose sight of how the world looks from > the cheap seats. I find this a bit ironic from you given that I've met you in person at USENIX ATC which is an order of magnitude more expensive than BSDCan (and in fact, one of the reasons the US-based BSDCon died and was effectively supplanted by BSDCan was that BSDCan is far cheaper). > I used to ask the PTB to provide *some* form of remote participation for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem that > we can't solve), or embarrassment. Since if the right people around here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. To be honest, the preocuppations to date have been a bit more basic than that (figuring out a workable format, lots of effort on simple logistics like food and rooms). Also, in previous years we have often had breakout rooms in random conference rooms in what would be the equivalent of a dorm meeting area with no A/V equipment, etc. The last two years have cut down to fewer meetings in more reasonable rooms. The connectivity is now generally reliable as well. All that to say that now that some basic things are settled, we can probably make some forward progress on this. A first step might be to start recording the summit sessions (BSDCan already has a partner that does this). Live streaming I'm less sure of, mostly because I am completely ignorant of what is available. I do know that having a bunch of people skype in would not be feasible (not enough bandwidth to send video out in multiple streams). The video would need to go out in a single stream to a distributor of some sort. And, quite frankly, despite Doug's "haves" vs "have-nots" implications, we can't afford an expensive commercial solution (e.g. Cisco) AFAIK. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 17:52:14 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 28B09106566C; Thu, 2 Aug 2012 17:52:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 487C61563FB; Thu, 2 Aug 2012 17:47:48 +0000 (UTC) Message-ID: <501ABD43.5090604@FreeBSD.org> Date: Thu, 02 Aug 2012 10:47:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Chisnall References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 17:52:14 -0000 On 08/02/2012 10:37, David Chisnall wrote: > > Thank you for volunteering to organise this. It's good to see people with both the motivation and experience required to do something well actively contributing to the project. Cheap copout. And quite sad, especially coming from a newly elected core team member. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 18:02:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id DA969106564A; Thu, 2 Aug 2012 18:02:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 082CB161230; Thu, 2 Aug 2012 17:53:07 +0000 (UTC) Message-ID: <501ABE83.2000003@FreeBSD.org> Date: Thu, 02 Aug 2012 10:53:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Warner Losh References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <1DE87ACB-10FD-4B23-850E-B0C4F564AB8F@bsdimp.com> In-Reply-To: <1DE87ACB-10FD-4B23-850E-B0C4F564AB8F@bsdimp.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org, David Chisnall Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 18:02:51 -0000 On 08/02/2012 10:40, Warner Losh wrote: > One thing to remember about the IETF. There's many vendors that devote significant resources to the IETF. While I was at Cisco, for example, I know that we provided audio and video bridges to IEFT meetings to facilitate remote attendance at the meetings. Cisco dedicated several engineers to ensure that the audio and video quality remained good during the meetings and were able to use facilities cisco normally used for things like WebEx and MeetingPlace. With a global presence and infrastructure, they were able to pull it off. I'm not aware of similar resources within the project. I'm not suggesting we need anything at the full WebEx audio/video/presentation/chat level. And apparently the Foundation has money to spend on dev summits. As I suggested in a previous message, this would be a good long-term investment that would benefit a lot of people, especially in comparison to the money set aside for travel grants which is now going begging. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 18:06:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 48358106564A; Thu, 2 Aug 2012 18:06:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 113C114F80F; Thu, 2 Aug 2012 18:04:08 +0000 (UTC) Message-ID: <501AC118.40104@FreeBSD.org> Date: Thu, 02 Aug 2012 11:04:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <501A0258.4010101@FreeBSD.org> <201208020839.07910.jhb@freebsd.org> In-Reply-To: <201208020839.07910.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 18:06:31 -0000 On 08/02/2012 05:39, John Baldwin wrote: > I find this a bit ironic from you given that I've met you in person at > USENIX ATC which is an order of magnitude more expensive than BSDCan (and > in fact, one of the reasons the US-based BSDCon died and was effectively > supplanted by BSDCan was that BSDCan is far cheaper). Yep, back in 2004 when traveling to conferences was part of my job, and before my daughter was born. My life now is quite different. ... not to mention that this thread isn't about me. It's about the importance of remote participation to the FreeBSD community as a whole. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 18:12:14 2012 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 1B833106564A; Thu, 2 Aug 2012 18:12:14 +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 B5A1E8FC14; Thu, 2 Aug 2012 18:12:12 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72ICA4c080070 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 18:12:12 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501ABD43.5090604@FreeBSD.org> Date: Thu, 2 Aug 2012 19:12:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABD43.5090604@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 18:12:14 -0000 On 2 Aug 2012, at 18:47, Doug Barton wrote: > Cheap copout. And quite sad, especially coming from a newly elected = core > team member. FreeBSD is a volunteer project. Our DevSummits are not run by a = commercial organisation, they are run by volunteers. I am not being = paid to organise the Cambridge DevSummit, I am doing it in my spare = time, as are the other people here. The resources available are those = that I can beg or borrow from the university and from other developers. = The attendance fee is =A350, which is just about enough to cover the = costs (we hope). Comparing this to a professionally organised event = like an IETF meeting, with large commercial sponsors (the IETF event you = cite is hosted by Google), and complaining that it comes up short is = insulting. Saying 'solutions exist, therefore you must have the time, = expertise, and resources to deploy them' is insulting. It is not = constructive. If you are willing to make a helpful contribution, then = it is welcome. If you are going to complain, yet not offer anything = constructive, then you are just trolling and I am wasting my time by = reading your emails, let alone replying. We have arranged to borrow a decent microphone and camera from the video = conferencing suite in the department and have planned to use Skype to = allow remote participation in two sessions. If you wish to propose a = more scalable solution that can be easily deployed here by people with = no prior experience setting up such a system, then please do so. =20 If you feel that you can do a better job organising a DevSummit than the = people who have donated their free time to organise the ones in the past = and the ones planned in the next few months, then I am certain that they = would be very happy for you to assist in the organisation. If your = attitude is 'well, I'm not going to do anything, but it must be easy = because no effort from me is involved so you should do it' then I find = your attitude personally insulting and unproductive. David From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 18:33:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4DAB9106564A; Thu, 2 Aug 2012 18:33:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D148814DE23; Thu, 2 Aug 2012 18:33:19 +0000 (UTC) Message-ID: <501AC7EF.4070605@FreeBSD.org> Date: Thu, 02 Aug 2012 11:33:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: David Chisnall References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABD43.5090604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 18:33:20 -0000 On 08/02/2012 11:12, David Chisnall wrote: > FreeBSD is a volunteer project. Yeah, I get that. I've been around quite a bit longer than you have, in case you didn't notice. :) I understand what you're saying, it's going to take work to change this mindset, and to provide these resources. If you read my posts on a factual basis, I'm not suggesting that the dev summits provide remote participation at the same level as groups like the IETF or ICANN do, and your point (and Warner's) that these groups have significant financial backing is well taken. However, my point is that in spite of the fact that it's non-trivial, the mindset on this topic needs to change if the dev summits are going to continue to be significant focii of both work being done and decisions being made (which of course, they are). What I'm *not* doing is demanding that any one person, or even any one group take responsibility for solving the whole problem on their own. Unfortunately, due to my inability to actually attend these meetings, I won't be able to provide the kind of hands-on assistance that I'd like to be able to. However it sounds like there may be financial resources available through the foundation, which would go a long way towards making a solution possible. The next step would be for people to agree that this is a problem that *needs* to be solved, followed by willingness on the part of dev summit organizers to support these efforts, which will hopefully lead to people who are willing and interested to step up and actually provide solutions. It's already been true in the past that various companies have volunteered to do this. There is no reason to believe that it wouldn't happen again if organizers are willing to be supportive. What I'm hearing so far is defensiveness, and an attempt to focus the discussion on me. Neither is helpful. :) Acknowledging that this is a problem that needs to be solved does not imply that by not solving it you personally have failed in some way. I apologize if anything I've written so far has implied otherwise. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 19:18:21 2012 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 382BA106566B; Thu, 2 Aug 2012 19:18:21 +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 009438FC0A; Thu, 2 Aug 2012 19:18:20 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q72JIFcV080280 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 19:18:19 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <501AC7EF.4070605@FreeBSD.org> Date: Thu, 2 Aug 2012 20:18:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F923CD6-BCF1-4722-8E4A-9485A7D6E279@freebsd.org> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <501AAEF2.8060202@FreeBSD.org> <501AB8C0.3020102@FreeBSD.org> <501ABD43.5090604@FreeBSD.org> <501AC7EF.4070605@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , freebsd-current@freebsd.org Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 19:18:21 -0000 Thank you for your thoughtful reply, On 2 Aug 2012, at 19:33, Doug Barton wrote: > However, my point is that in spite of the fact that it's non-trivial, > the mindset on this topic needs to change if the dev summits are going > to continue to be significant focii of both work being done and > decisions being made (which of course, they are). I believe that, before that decision can be made, there needs to be some = consensus on what the purpose of the DevSummits is. In my view, = DevSummits do not exist to set project policy. They are places where: - People can talk face to face about their current and planned projects. - Developers can meet on a social basis, making remote working easier. The latter is very important - I've found in other projects that it's = far easier to work with someone on the other side of the world when = you've chatted with them over a few beverages-of-choice. =20 Any official conversations happen on the mailing lists. DevSummits are = for people working on similar things to meet and discuss their plans, = and for people to have a chance to get to know what everyone else is = doing, for a limited set of 'everyone else'. Slides and summaries so on = from the more structured parts of this are available afterwards, which = helps people who can't attend get the same benefit - they know what = other people are working on. The original complaint that spawned this long discussion was that = decisions about the project are made behind closed doors. This is = obviously true in the literal sense, as code always wins over chatter in = an open source project, and the person willing to sit down and write the = code gets the final say on how it should work, although ideally with = code review, design feedback and so on from others. Even if we = broadcast everything that happens in the official parts of the = DevSummits, that won't necessarily fix anything because a lot of the = most productive conversations happen over dinner or in the pub. =20 If there is a real problem to address, then it is people making policy = decisions at DevSummits, without adequate consultation. I have not = observed this happening, but I would regard it as no different to people = making policy decisions via private email, and something that should be = subject to the same response: revisit the decisions in public if there = are legitimate concerns raised about it, subject to the usual open = source rule that the person actually willing to do the work gets to make = the final call. > What I'm *not* doing is demanding that any one person, or even any one > group take responsibility for solving the whole problem on their own. > Unfortunately, due to my inability to actually attend these meetings, = I > won't be able to provide the kind of hands-on assistance that I'd like > to be able to. However it sounds like there may be financial resources > available through the foundation, which would go a long way towards > making a solution possible. Finance is not the only obstacle. In some venues, bandwidth is a = problem (not at Cambridge hopefully - people will have stopped using it = all to stream the olympics by then), but in other venues we only have = WiFi, which is shared with a room full of developers. If we buy some = equipment (decent microphones are not always available - we were unable = to find one at FOSDEM for remote attendees, for example), then it would = need to be transported between events, and someone would need to be = responsible for looking after it and ensuring that it is set up = correctly at each event. =20 > The next step would be for people to agree that this is a problem that > *needs* to be solved, followed by willingness on the part of dev = summit > organizers to support these efforts, which will hopefully lead to = people > who are willing and interested to step up and actually provide > solutions. It's already been true in the past that various companies > have volunteered to do this. There is no reason to believe that it > wouldn't happen again if organizers are willing to be supportive. There are two proposals: Remote viewing and remote participation. = Remote viewing, being non-interactive, does not have to be done via = streaming, it can be done by recording the event and making it available = online. Even this is not trivial: we've done it for the GNUstep devroom = at FOSDEM most years, and it typically takes a long time to get the = videos edited and uploaded. ARM sent a professional team to do it at = EuroLLVM, and yet they didn't have enough equipment to cover everything = (my tutorial, for example, was not recorded). I would say that this is = something that is very useful for presentation-style events, but = DevSummits are typically more round-table discussions and hacking = sessions than presentations. Remote participation is bidirectional, and I am a lot more wary about = that. The productivity of a meeting is usually inversely proportional = to the number of attendees, and allowing a lot more people in does not = necessarily improve anything for anyone. It's always tempting to speak = up and make A Contribution (I have certainly been guilty of this in the = past, and no doubt will be in the future) when really the meeting needs = everyone to shut up and move on to the next item. The main advantage of = the small group meetings is that they don't degenerate into bikesheds as = easily. Of course, the down side is that they also lack any kind of = mandate because they are not including everyone's opinions, which is why = summaries are posted on the wiki and linked to from the mailing list so = that longer discussions can take place online. Encouraging remote participation also has the unintended side effect of = discouraging real participation. I've seen in other projects that when = you try to make remote participation easy it means a lot of people think = 'well, I can just join in remotely, I don't need to make the effort to = turn up'. This is why I think we have about the right balance for the = Cambridge DevSummit. We have a few people (e.g. Dru, Warner) who would = benefit from being there (and whose presence the community would benefit = from), but who are unable to make it. We have set up something so that = they can (hopefully!) join in remotely, but this is very much a = second-choice option. Ideally, we'd see all of the remote attendees in = person. =20 If the majority are not present in person, then we may as well not have = a DevSummit at all, and just have a regular conference call that's open = to all. Or, to save bandwidth, a mailing list or IRC channel... =20 If anything, I suspect a large number of remote attendees would end up = having the opposite of the desired effect, and mean that the vast = majority of the actual decision making would take place in the pub after = the official meetings, where it won't even be reported on the mailing = lists until the commits start landing. David From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 21:39:55 2012 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 1CA651065670 for ; Thu, 2 Aug 2012 21:39:55 +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 D05F08FC12 for ; Thu, 2 Aug 2012 21:39:54 +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 q72Lds2R034940 for ; Thu, 2 Aug 2012 14:39:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q72LdsaI034939 for freebsd-current@freebsd.org; Thu, 2 Aug 2012 14:39:54 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Aug 2012 14:39:54 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20120802213954.GA34928@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: rtld dropping core on recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 21:39:55 -0000 % file /usr/local/bin/ppdpo /usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \ version 1 (FreeBSD), dynamically linked (uses shared libs), FreeBSD-style,\ for FreeBSD 10.0 (1000015), stripped % ldd /usr/local/bin/ppdpo /usr/local/bin/ppdpo: /usr/local/bin/ppdpo: signal 11 % gdb741 /usr/obj/usr/src/usr.bin/ldd/ldd ldd.core GNU gdb (GDB) 7.4.1 [GDB v7.4.1 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 "i386-portbld-freebsd10.0". For bug reporting instructions, please see: ... Reading symbols from /usr/obj/usr/src/usr.bin/ldd/ldd...done. [New process 100147] Core was generated by `ldd'. Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x4804fa4e in digest_notes (obj=0x4806b000, note_start=1208398156,\ note_end=1208398204) at /usr/src/libexec/rtld-elf/rtld.c:1326 #1 0x480566dc in map_object (fd=3, path=0x48065320 "/usr/local/bin/ppdpo",\ sb=0xbfbfd4dc) at /usr/src/libexec/rtld-elf/map_object.c:156 #2 0x48051627 in do_load_object (flags=, sbp=,\ path=, name=, fd=) at /usr/src/libexec/rtld-elf/rtld.c:2100 #3 load_object (name=0xbfbfd8d0 "/usr/local/bin/ppdpo", fd_u=-1,\ refobj=0x48067000, flags=) at /usr/src/libexec/rtld-elf/rtld.c:2070 #4 0x48052303 in dlopen_object (name=0xbfbfd8d0 "/usr/local/bin/ppdpo",\ fd=-1, refobj=0x48067000, lo_flags=6, mode=0, lockstate=0xbfbfd590) at /usr/src/libexec/rtld-elf/rtld.c:2799 #5 0x48052fea in rtld_dlopen (name=0xbfbfd8d0 "/usr/local/bin/ppdpo",\ fd=-1, mode=512) at /usr/src/libexec/rtld-elf/rtld.c:2761 #6 0x0804935b in main (argc=1, argv=0xbfbfd760) at /usr/src/usr.bin/ldd\ /ldd.c:251 (gdb) list 1321 obj->osrel = *(const int32_t *)(p); 1322 dbg("note osrel %d", obj->osrel); 1323 break; 1324 case CRT_NOINIT_NOTETYPE: 1325 /* FreeBSD 'crt does not call init' note */ 1326 obj->crt_no_init = true; 1327 dbg("note crt_no_init"); 1328 break; 1329 } 1330 } (gdb) print *obj->crt_no_init Cannot access memory at address 0x0 % pkg_info -W /usr/local/bin/ppdpo /usr/local/bin/ppdpo was installed by package cups-base-1.5.2_2 % portmaster cups-base % pkg_info -W /usr/local/bin/ppdpo /usr/local/bin/ppdpo was installed by package cups-base-1.5.2_2 % ldd /usr/local/bin/ppdpo /usr/local/bin/ppdpo: /usr/local/bin/ppdpo: signal 11 -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 22:32:47 2012 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 1E9FA106566B for ; Thu, 2 Aug 2012 22:32:47 +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 D23058FC08 for ; Thu, 2 Aug 2012 22:32:46 +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 q72MWklw035218 for ; Thu, 2 Aug 2012 15:32:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q72MWkrc035217 for freebsd-current@freebsd.org; Thu, 2 Aug 2012 15:32:46 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Aug 2012 15:32:46 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20120802223246.GA35208@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: possible je-malloc issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 22:32:47 -0000 Libc built today. Start X with fvwm window manager. Open xterm and su to root. 1. Use nedit to edit a file and close. fvwm drops core. If fvwm does not drop core repeat 1 until she does. (gdb) bt #0 0x4841e294 in __jemalloc_arena_mapbits_get (chunk=0x8000000, pageind=245) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:502 #1 0x4841e2c4 in __jemalloc_arena_mapbits_allocated_get (chunk=0x8000000, pageind=245) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:581 #2 0x4841e739 in __jemalloc_arena_salloc (ptr=0x80f58e0, demote=false) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:902 #3 0x48423dd1 in __jemalloc_isalloc (ptr=0x8000000, demote=false) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:791 #4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212 #5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701 #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363 #7 0x0806d3ab in HandlePropertyNotify (ea=0xbfbfd014) at events.c:3422 #8 0x0806c369 in dispatch_event (e=0xbfbfd044) at events.c:4135 #9 0x0806ca5f in HandleEvents () at events.c:4179 #10 0x0808e06e in main (argc=1, argv=0xbfbfd7ac) at fvwm.c:2591 (gdb) frame 4 #4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212 1212 usize = isalloc(ptr, config_prof); (gdb) print *ptr Attempt to dereference a generic pointer. (gdb) up 1 #5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701 1701 XlibInt.c: No such file or directory. (gdb) print *data Attempt to dereference a generic pointer. (gdb) up 1 #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363 2363 Flocale.c: No such file or directory. (gdb) print *ptext $5 = {name = 0x80f58e0 "Untitled", name_list = 0x0} -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 23:27:50 2012 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 882C3106564A for ; Thu, 2 Aug 2012 23:27:50 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 66AD88FC14 for ; Thu, 2 Aug 2012 23:27:50 +0000 (UTC) Received: from [172.25.18.176] (unknown [173.252.71.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id 1768928416; Thu, 2 Aug 2012 16:21:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jason Evans In-Reply-To: <20120802223246.GA35208@troutmask.apl.washington.edu> Date: Thu, 2 Aug 2012 16:21:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120802223246.GA35208@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1278) Cc: freebsd-current@freebsd.org Subject: Re: possible je-malloc issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 23:27:50 -0000 On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote: > Libc built today. > Start X with fvwm window manager. > Open xterm and su to root. >=20 > 1. Use nedit to edit a file and close. >=20 > fvwm drops core. If fvwm does not drop core repeat 1 until=20 > she does. >=20 > (gdb) bt > #0 0x4841e294 in __jemalloc_arena_mapbits_get (chunk=3D0x8000000, = pageind=3D245) > at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :502 > #1 0x4841e2c4 in __jemalloc_arena_mapbits_allocated_get = (chunk=3D0x8000000,=20 > pageind=3D245) > at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :581 > #2 0x4841e739 in __jemalloc_arena_salloc (ptr=3D0x80f58e0, = demote=3Dfalse) > at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h= :902 > #3 0x48423dd1 in __jemalloc_isalloc (ptr=3D0x8000000, demote=3Dfalse) > at = /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemallo= c_internal.h:791 > #4 0x4842408e in free (ptr=3D0x80f58e0) at jemalloc_jemalloc.c:1212 > #5 0x48164b7d in XFree (data=3D0x80f58e0) at XlibInt.c:1701 > #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=3D0xbfbfcfb4) at = Flocale.c:2363 > #7 0x0806d3ab in HandlePropertyNotify (ea=3D0xbfbfd014) at = events.c:3422 > #8 0x0806c369 in dispatch_event (e=3D0xbfbfd044) at events.c:4135 > #9 0x0806ca5f in HandleEvents () at events.c:4179 > #10 0x0808e06e in main (argc=3D1, argv=3D0xbfbfd7ac) at fvwm.c:2591 > (gdb) frame 4 > #4 0x4842408e in free (ptr=3D0x80f58e0) at jemalloc_jemalloc.c:1212 > 1212 usize =3D isalloc(ptr, config_prof); > (gdb) print *ptr > Attempt to dereference a generic pointer. > (gdb) up 1 > #5 0x48164b7d in XFree (data=3D0x80f58e0) at XlibInt.c:1701 > 1701 XlibInt.c: No such file or directory. > (gdb) print *data > Attempt to dereference a generic pointer. > (gdb) up 1 > #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=3D0xbfbfcfb4) at = Flocale.c:2363 > 2363 Flocale.c: No such file or directory. > (gdb) print *ptext > $5 =3D {name =3D 0x80f58e0 "Untitled", name_list =3D 0x0} jemalloc is asserting that the page which contains 0x80f58e0 is = allocated according to the containing chunk's page map, but the chunk = header isn't even mapped, and the attempted read causes a segfault. = This is almost certainly a result of calling free() with a bogus = pointer. Jason= From owner-freebsd-current@FreeBSD.ORG Thu Aug 2 23:36:36 2012 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 573B5106564A; Thu, 2 Aug 2012 23:36:36 +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 157938FC16; Thu, 2 Aug 2012 23:36:36 +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 q72NaZeK035493; Thu, 2 Aug 2012 16:36:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q72NaZRD035492; Thu, 2 Aug 2012 16:36:35 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Aug 2012 16:36:35 -0700 From: Steve Kargl To: Jason Evans Message-ID: <20120802233635.GA35429@troutmask.apl.washington.edu> References: <20120802223246.GA35208@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: possible je-malloc issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Aug 2012 23:36:36 -0000 On Thu, Aug 02, 2012 at 04:21:20PM -0700, Jason Evans wrote: > On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote: > > (gdb) print *ptr > > Attempt to dereference a generic pointer. > > (gdb) up 1 > > #5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701 > > 1701 XlibInt.c: No such file or directory. > > (gdb) print *data > > Attempt to dereference a generic pointer. > > (gdb) up 1 > > #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363 > > 2363 Flocale.c: No such file or directory. > > (gdb) print *ptext > > $5 = {name = 0x80f58e0 "Untitled", name_list = 0x0} > > jemalloc is asserting that the page which contains 0x80f58e0 is allocated > according to the containing chunk's page map, but the chunk header isn't > even mapped, and the attempted read causes a segfault. This is almost > certainly a result of calling free() with a bogus pointer. > I suspect, but cannot prove it yet, that ptext->name points at a static buffer. I'm trying to understand the code now. The failure starts in void FlocaleFreeNameProperty(FlocaleNameString *ptext) { if (ptext->name_list != NULL) { if (ptext->name != NULL && ptext->name != *ptext->name_list) XFree(ptext->name); XFreeStringList(ptext->name_list); ptext->name_list = NULL; } else if (ptext->name != NULL) { XFree(ptext->name); } ptext->name = NULL; return; } In the code the XFree(ptext->name) appears protected by the check for a NULL pointer, but it appears that 0x80f58e0 is invalid. I don't know how to check for an non-NULL invalid pointer. I suppose I can hack fvwm to leak memory at worse. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 00:15:57 2012 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 2604B106566C; Fri, 3 Aug 2012 00:15:57 +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 F0AEC8FC08; Fri, 3 Aug 2012 00:15:56 +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 q730FuOv035699; Thu, 2 Aug 2012 17:15:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q730Fu0j035698; Thu, 2 Aug 2012 17:15:56 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Aug 2012 17:15:56 -0700 From: Steve Kargl To: Jason Evans Message-ID: <20120803001556.GA35672@troutmask.apl.washington.edu> References: <20120802223246.GA35208@troutmask.apl.washington.edu> <20120802233635.GA35429@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120802233635.GA35429@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: possible je-malloc issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 00:15:57 -0000 On Thu, Aug 02, 2012 at 04:36:35PM -0700, Steve Kargl wrote: > On Thu, Aug 02, 2012 at 04:21:20PM -0700, Jason Evans wrote: > > On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote: > > > (gdb) print *ptr > > > Attempt to dereference a generic pointer. > > > (gdb) up 1 > > > #5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701 > > > 1701 XlibInt.c: No such file or directory. > > > (gdb) print *data > > > Attempt to dereference a generic pointer. > > > (gdb) up 1 > > > #6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363 > > > 2363 Flocale.c: No such file or directory. > > > (gdb) print *ptext > > > $5 = {name = 0x80f58e0 "Untitled", name_list = 0x0} > > > > jemalloc is asserting that the page which contains 0x80f58e0 is allocated > > according to the containing chunk's page map, but the chunk header isn't > > even mapped, and the attempted read causes a segfault. This is almost > > certainly a result of calling free() with a bogus pointer. > > > > I suspect, but cannot prove it yet, that ptext->name points at > a static buffer. I'm trying to understand the code now. The > failure starts in > > void FlocaleFreeNameProperty(FlocaleNameString *ptext) > { > if (ptext->name_list != NULL) > { > if (ptext->name != NULL && ptext->name != *ptext->name_list) > XFree(ptext->name); > XFreeStringList(ptext->name_list); > ptext->name_list = NULL; > } > else if (ptext->name != NULL) > { > XFree(ptext->name); > } > ptext->name = NULL; > > return; > } > > In the code the XFree(ptext->name) appears protected by the check > for a NULL pointer, but it appears that 0x80f58e0 is invalid. I > don't know how to check for an non-NULL invalid pointer. I suppose > I can hack fvwm to leak memory at worse. > I think I found the problem in fvwm/add_window.c one finds the global entity char NoName[] = "Untitled"; /* name if no name in XA_WM_NAME */ then later in fvwm/events.c one finds FlocaleNameString new_name = { NoName, NULL }; At some point FlocaleFreeNameProperty is called to free the FlocaleNameString that contains NoName, and XFree() is not happy. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 00:25:00 2012 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 95820106564A for ; Fri, 3 Aug 2012 00:25:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4858D8FC12 for ; Fri, 3 Aug 2012 00:24:59 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q730OglD001896 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 17:24:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <501B1A45.8010000@freebsd.org> Date: Thu, 02 Aug 2012 17:24:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ed Schouten References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> <5019B1F8.5080802@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 00:25:00 -0000 On 8/2/12 4:23 AM, Ed Schouten wrote: > 2012/8/2 Julian Elischer : >> I think that the /dev/entries can (and SHOULD) go away when the hardware >> goes away and even be re-used. > But here's the point. TTYs are used in a different way than other > device nodes. Regular device nodes are simply opened by a set of > independent process (e.g. dd if=/dev/da0, a music player opening > /dev/dsp, etc). TTYs are used by a set of processes that share a weak > relationship, namely all belonging to the same login session. > > Things *really* break if you were to forcefully remove a TTY device > node and replace it by another TTY. Even for physical devices it would > be really bad to do. Consider a system that has two USB to serial > converters that are used for interactive login sessions. One is > plugged in, the other one isn't. If you unplug one device and plug in > the other, you never want the processes from the one login session to > start interacting with the other device. > > Also, applications relying on the user accounting database (utmpx) > will start to behave non-deterministically then. Do we really want > biff and wall to write stuff to random TTYs? they would only do that if they were refering to the node BY NAME. Once it's opened, the accesses go via teh internal ( vnode?) objects. if you make the name go away then that wouldn't have any effect on processes that already have the node open. It would be a property of the driver though to decide what happens, but EVENTUALLY yu are going to need to do something about it. > > Whether or not the TTY is a pseudo-terminal or not is completely > irrelevant in my opinion. > From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 00:37:23 2012 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 3DB9F106564A; Fri, 3 Aug 2012 00:37:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 002578FC12; Fri, 3 Aug 2012 00:37:22 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q730bJ2R001942 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 17:37:20 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <501B1D3A.6080501@freebsd.org> Date: Thu, 02 Aug 2012 17:37:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Doug Barton References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> <501AB08E.8020008@FreeBSD.org> In-Reply-To: <501AB08E.8020008@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh , Arnaud Lacombe Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 00:37:23 -0000 On 8/2/12 9:53 AM, Doug Barton wrote: > On 08/02/2012 09:44, Garrett Cooper wrote: >> The "Watson/Losh connection" worked really well in BSDCan 2010 :). > I wasn't going to mention that, since I didn't want to tell tales out of > school. But the fact that remote participation actually was provided for > "the right people," even though I was told repeatedly that it wasn't > possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. > Doug From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 01:14:32 2012 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 615EF106566C; Fri, 3 Aug 2012 01:14:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 51F2E8FC08; Fri, 3 Aug 2012 01:14:31 +0000 (UTC) Received: by weyx56 with SMTP id x56so111565wey.13 for ; Thu, 02 Aug 2012 18:14:30 -0700 (PDT) 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=+j/HxlANKMy451Fl79QlSEDkJAkLyqfnjLgaHunmYOQ=; b=zG51jNwIyYx7Nnx1092P75S9/glG2e9Pf324HFSngTVvu1BqgokE5aX2zg1BtNewk0 4ILl4uPSWbzHMcJ9eJ1RApmmEvAc7aOlfFMvdu5YtuGB7D6fGZeCV1Zxabngxb9QzALX a/H6KMU7exsL3cqlp01Ojm97GCDp0nf8r1Gw0e6helZWycJ5Tt9bImo9DMwGCpdPh0wE 7n93xRy+4o0DHuRKZoCdqJ02pi9S2ZjQfCLe38Ytsbbp/byYae2QbruZ+uX6bOUNg5+D kR0Ji3UErjKop3pJRJ1aQ6JZjXy8ljFHzUvDkddb/sYdjLo9Gen7upDpKXnNPpBzLxqU YvfA== MIME-Version: 1.0 Received: by 10.180.100.37 with SMTP id ev5mr57068wib.5.1343956470253; Thu, 02 Aug 2012 18:14:30 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Thu, 2 Aug 2012 18:14:30 -0700 (PDT) In-Reply-To: <501B1D3A.6080501@freebsd.org> References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> <501AB08E.8020008@FreeBSD.org> <501B1D3A.6080501@freebsd.org> Date: Thu, 2 Aug 2012 18:14:30 -0700 Message-ID: From: Kevin Oberman To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Cc: Doug Barton , Garrett Cooper , FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe , Warner Losh Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 01:14:32 -0000 On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer wrote: > On 8/2/12 9:53 AM, Doug Barton wrote: >> >> On 08/02/2012 09:44, Garrett Cooper wrote: >>> >>> The "Watson/Losh connection" worked really well in BSDCan 2010 :). >> >> I wasn't going to mention that, since I didn't want to tell tales out of >> school. But the fact that remote participation actually was provided for >> "the right people," even though I was told repeatedly that it wasn't >> possible, actually highlights a big part of the problem. > > bandwidth was limited and a single 1:1 skype connection was all we really > could do. > > I did broadcast sessions a few years ago using the apple quicktime server > but it was a lot of work and I think one person looked at part of one > session. > >> Doug First, too many of these posts assume way too much. I don't think anyone should be thinking of any sort of what is commonly called "teleconferencing". That would be nice, but is far more complex and expensive, both in bandwidth and equipment, then should be considered as a starting point. I suggest the starting point is a webpage with a link to the slides being presented and a simple audio stream. This is trivially possible with a FreeBSD system and open-source software. A bandwidth of only about 70kbps would be needed. Less with reasonable codec choice. Several streams could be broadcast via a single, unicast stream to a well connected server which woild then stream to end users It might be augmented with jabber other open IM technology with someone at the meeting if procedures for this could be agreed to. (Some vetting is desirable, but will result in calls of censorship.) For small rooms, microphones are fairly easy to handle and one-way streams don't require echo cancellation. As costs for video come down, that might be something to think about some day, but is not required to allow remote "attendance". Of course, unless this is publicized, no one will come (which eliminates any technical issues). :-) -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 01:55:54 2012 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 97E31106566C; Fri, 3 Aug 2012 01:55:54 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19C588FC08; Fri, 3 Aug 2012 01:55:53 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so210390vcb.13 for ; Thu, 02 Aug 2012 18:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=FHFdAhmp1u7u3GBV7BKV4jPi/+AHUEp27RisJaooGbg=; b=sT2g8gOGaIPpP659dIyp8WDGRQMkaD4o1tD4XtbWTBC/agwavSNjpPmv8yIyEXBT1d gQ99GuS1caNunu7khmhRizPmMtY8762qthHFORIudZe5W7ChEzuQCxQ9PtNc7srTjuF5 OceYAqn/bts9w8Y3hbGDpasbfMvjXi2/PNgBO0xUP27fuVi6ioQ113tFJ7OCX8XRwR9Q g8/ljPVpJ7o6hg9ykb4CCUuxSeyIi4OaIitV8vNqmFL7MvhFOGwabs62TnQ8tOf6I4d9 vCu1NoHqMTfOryzira3Qdr7rsndinnG3SEwHz54By6nI9ASXBGEusuRb7ywJeqNP5cku N8bA== Received: by 10.52.30.168 with SMTP id t8mr50780vdh.45.1343958952557; Thu, 02 Aug 2012 18:55:52 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id cz2sm7525734vdb.3.2012.08.02.18.55.42 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 18:55:42 -0700 (PDT) Date: Thu, 2 Aug 2012 21:55:36 -0400 From: Alexander Kabaev To: Steve Kargl Message-ID: <20120802215536.027914c9@kan.dyndns.org> In-Reply-To: <20120802213954.GA34928@troutmask.apl.washington.edu> References: <20120802213954.GA34928@troutmask.apl.washington.edu> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/OAEWdHNI6dfDGCzj5mra2+V"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: rtld dropping core on recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 01:55:54 -0000 --Sig_/OAEWdHNI6dfDGCzj5mra2+V Content-Type: multipart/mixed; boundary="MP_/wtv/1FQa_M+lhEdRiKm_GCE" --MP_/wtv/1FQa_M+lhEdRiKm_GCE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 2 Aug 2012 14:39:54 -0700 Steve Kargl wrote: > % file /usr/local/bin/ppdpo > /usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \ > version 1 (FreeBSD), dynamically linked (uses shared libs), > FreeBSD-style,\ for FreeBSD 10.0 (1000015), stripped >=20 > % ldd /usr/local/bin/ppdpo > /usr/local/bin/ppdpo: > /usr/local/bin/ppdpo: signal 11 >=20 It is weird that program tries to dlopen what appears to be the binary (itself?), but that did uncover the issue. Please try attached patch, I only very lightly tested it here. Also available here: http://people.freebsd.org/~kan/rtld-digest-notes.diff --=20 Alexander Kabaev --MP_/wtv/1FQa_M+lhEdRiKm_GCE Content-Type: text/x-patch Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=rtld-digest-notes.diff diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c index 509a64f..350d437 100644 --- a/libexec/rtld-elf/map_object.c +++ b/libexec/rtld-elf/map_object.c @@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct stat = *sb) break; note_start =3D (Elf_Addr)(char *)hdr + phdr->p_offset; note_end =3D note_start + phdr->p_filesz; - digest_notes(obj, note_start, note_end); break; } =20 @@ -292,6 +291,11 @@ map_object(int fd, const char *path, const struct stat= *sb) obj->relro_page =3D obj->relocbase + trunc_page(relro_page); obj->relro_size =3D round_page(relro_size); =20 + if (note_start < note_end) + { + digest_notes(obj, note_start, note_end); + } + munmap(hdr, PAGE_SIZE); return (obj); =20 --MP_/wtv/1FQa_M+lhEdRiKm_GCE-- --Sig_/OAEWdHNI6dfDGCzj5mra2+V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQGy+dQ6z1jMm+XZYRAjVaAKCWwtCOiHermM7XJlBc3XWenaTC1wCfXyrI 5uZSQO6rlUwq2TJvgJszIAA= =e8ql -----END PGP SIGNATURE----- --Sig_/OAEWdHNI6dfDGCzj5mra2+V-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 02:13:14 2012 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 70DFD106564A; Fri, 3 Aug 2012 02:13:14 +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 2F3B08FC12; Fri, 3 Aug 2012 02:13:14 +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 q732DDqa036275; Thu, 2 Aug 2012 19:13:13 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q732DDt3036274; Thu, 2 Aug 2012 19:13:13 -0700 (PDT) (envelope-from sgk) Date: Thu, 2 Aug 2012 19:13:13 -0700 From: Steve Kargl To: Alexander Kabaev Message-ID: <20120803021313.GA36246@troutmask.apl.washington.edu> References: <20120802213954.GA34928@troutmask.apl.washington.edu> <20120802215536.027914c9@kan.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120802215536.027914c9@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: rtld dropping core on recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 02:13:14 -0000 On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote: > On Thu, 2 Aug 2012 14:39:54 -0700 > Steve Kargl wrote: > > > % file /usr/local/bin/ppdpo > > /usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \ > > version 1 (FreeBSD), dynamically linked (uses shared libs), > > FreeBSD-style,\ for FreeBSD 10.0 (1000015), stripped > > > > % ldd /usr/local/bin/ppdpo > > /usr/local/bin/ppdpo: > > /usr/local/bin/ppdpo: signal 11 > > > > It is weird that program tries to dlopen what appears to be the binary > (itself?), but that did uncover the issue. Please try attached patch, > I only very lightly tested it here. > > Also available here: > http://people.freebsd.org/~kan/rtld-digest-notes.diff > The patch appears to fix the problem. Before the patch % find /usr/local/bin -type f | xargs -n1 file -F ' ' | grep ELF \ | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libpng.so.6 /usr/local/bin/ppdc: signal 11 /usr/local/bin/ppdhtml: signal 11 /usr/local/bin/ipptool: signal 11 /usr/local/bin/cupstestdsc: signal 11 /usr/local/bin/cupstestppd: signal 11 /usr/local/bin/lpstat: signal 11 /usr/local/bin/lpq: signal 11 /usr/local/bin/lpr: signal 11 /usr/local/bin/ppdpo: signal 11 /usr/local/bin/cancel: signal 11 /usr/local/bin/lpoptions: signal 11 /usr/local/bin/lppasswd: signal 11 /usr/local/bin/ppdi: signal 11 /usr/local/bin/ppdmerge: signal 11 /usr/local/bin/inkscape libpng.so.6 /usr/local/bin/inkview libpng.so.6 /usr/local/bin/lp: signal 11 /usr/local/bin/lprm: signal 11 After applying the patch and rebuilding % find /usr/local/bin -type f | xargs -n1 file -F ' ' | grep ELF \ | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libpng.so.6 /usr/local/bin/inkscape libpng.so.6 /usr/local/bin/inkview libpng.so.6 Thanks for the quick response. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 04:18:34 2012 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 D97BB10657DA for ; Fri, 3 Aug 2012 04:18:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7BA8FC14 for ; Fri, 3 Aug 2012 04:18:34 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so4530150wib.13 for ; Thu, 02 Aug 2012 21:18:33 -0700 (PDT) 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=TlKViqqIX+gIt1tVoN9lRykMjhvXRQ1WgcU5OOnz4D4=; b=CTGWJ5ZfkdBLc5KjoXnmmH/BU1iVhJdxnkYs0tCDxq1YLMINCfsBZh5LISJrcwS8+5 3ymh+UYy1/VhOxzHiGQU/7KdiXK01/erIEXjYnF11aVOit+otxkt3GJ7NhG+xRT6P29u F5GD4T8oK8OnYsyilXC7/nNJFYNdjULweO4guApENeyn1SNQQ1q4M0TCh+brmLBGteBW L2kTepEjwFAIJNv7ni/SEeOHojHHS2BISSzjVmLDlZmpoavwBZfz0AYcgbRhwClwNiF5 Q9B1Jgxa/8p1Td32zKEWgrpUaidHhaFWIKvtYq10IxmYJOkwbwQcvEvY4MLZ77hMCemL 6vuA== MIME-Version: 1.0 Received: by 10.180.100.37 with SMTP id ev5mr1016739wib.5.1343967513237; Thu, 02 Aug 2012 21:18:33 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Thu, 2 Aug 2012 21:18:33 -0700 (PDT) In-Reply-To: <501A323E.6000106@zedat.fu-berlin.de> References: <501A323E.6000106@zedat.fu-berlin.de> Date: Thu, 2 Aug 2012 21:18:33 -0700 Message-ID: From: Kevin Oberman To: "Hartmann, O." Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 04:18:34 -0000 On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. wrote: > I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 > (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the > ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 > for more than a minute. For a minute or so, I can work, then, the freeze > occurs again. > > I can't see this behaviour with a Ubuntu Guest on the same box. Is there > Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 05:45:49 2012 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 46EB8106564A for ; Fri, 3 Aug 2012 05:45:49 +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 0A67D8FC12 for ; Fri, 3 Aug 2012 05:45:48 +0000 (UTC) Received: by obbun3 with SMTP id un3so669149obb.13 for ; Thu, 02 Aug 2012 22:45:48 -0700 (PDT) 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=NWkaET7Ofgvm7qwzUOuzan6YSqqCKurZWTBI7htPE54=; b=y4Gd0pmeEc5qBLRK2v8M5EyN0Ju0PyEcVTWnTBUswh43aPbIhj2iPc6v/NHQfpVKfe qE7tK2uGrdQYZf7tv1H6PEl4H2UWBFcTCu+hc+NTg/6JrXrXCbSu1JdGNyKAbiF1MskL w170ZeSJXn/rfii0bM0OQl6gXVBUndYpImO0MzqqD/M5fU5Y8Y0Am/dcKjbwNrrNGvhL jiqgLEZey5jXNzGMpuwHq5Huy+I7kl1DUIUj7AFcHZHCWKZvCx322hah+eOMkis+25ps /KJ8IzvstxmWBOsX405NqXuQsBb3m2qKNXjLYeWR9sPkMedh6095KiUlCaLEZ0/FI1E+ No1A== MIME-Version: 1.0 Received: by 10.182.46.65 with SMTP id t1mr1453769obm.20.1343972747989; Thu, 02 Aug 2012 22:45:47 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Thu, 2 Aug 2012 22:45:47 -0700 (PDT) In-Reply-To: References: <501A323E.6000106@zedat.fu-berlin.de> Date: Thu, 2 Aug 2012 22:45:47 -0700 Message-ID: From: Garrett Cooper To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 05:45:49 -0000 On Thu, Aug 2, 2012 at 9:18 PM, Kevin Oberman wrote: > On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. > wrote: >> I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 >> (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the >> ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 >> for more than a minute. For a minute or so, I can work, then, the freeze >> occurs again. >> >> I can't see this behaviour with a Ubuntu Guest on the same box. Is there >> Windows 7 specifica to be aware of? > > I am seeing the same thing. Also Win7 guest with Windows showing idle > process at 99%, but my system is showing VB at 100%. The VM is only > running a single CPU, so FreeBSD is still running OK, but the Win7 > system seems to freeze up periodically. > > 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way > since VB was updated to 4.1.18. Guest additions for 4.1.18 > installed.All ports current. I'm thinking of backing off to 4.1.16. I've been seeing consistent hangs with VBox 4.1.18, but mostly with shared folders and the like under Windows 7 with certain paths using Cygwin (probably an application issue, but I haven't dug into why things are that way). I'm not sure what the exact revision is for 9.1-BETA1, but there are a handful of threading and amd64-specific signal, etc related changes that may or may not affect things. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 08:15:37 2012 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 40A32106566C; Fri, 3 Aug 2012 08:15:37 +0000 (UTC) (envelope-from edschouten@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 E78528FC12; Fri, 3 Aug 2012 08:15:36 +0000 (UTC) Received: by obbun3 with SMTP id un3so886532obb.13 for ; Fri, 03 Aug 2012 01:15:36 -0700 (PDT) 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=zibvE0ZMHITdmQKnkRMbnpUq0p9byf8RRcN0XhXjSKo=; b=QN1b93C6aj6e2n5SM/VUzzVfsfHNH9iGRs1/w4juTEQmXLjm1+spqpdfa+M0eMZLH0 ZN2BNXQwtg1cKInNCL/Z19eTHoJyqHG6BDkLxa63aJt4bH5Mn9MtU3lzyEFjn+jRYAco T2WvHYHnnSsW1e0jfA6H9ArpCmjU1Z8IBXvvheKfttTIUvb7aOwr29LvYmONbEtV9mcH PHl7nhGCEobSbBfJitbDaMS9yVULSg0FGWKdvtWBQxqeQstPGKkntQ5o68j6vaRGgcbi Pz0n4fJA+GrN0SuGnm03SoDZmLXo8y2t7uut132NETunv2QndEty9awzpVqWabzqZUxs HnHA== MIME-Version: 1.0 Received: by 10.182.88.9 with SMTP id bc9mr2456017obb.4.1343981736577; Fri, 03 Aug 2012 01:15:36 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Fri, 3 Aug 2012 01:15:36 -0700 (PDT) In-Reply-To: <501B1A45.8010000@freebsd.org> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> <5019B1F8.5080802@freebsd.org> <501B1A45.8010000@freebsd.org> Date: Fri, 3 Aug 2012 10:15:36 +0200 X-Google-Sender-Auth: Yct2iraFQQDGue9jnjvZR-pylM8 Message-ID: From: Ed Schouten To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 08:15:37 -0000 2012/8/3 Julian Elischer : > they would only do that if they were refering to the node BY NAME. Which is exactly what a lot of software does when interacting with TTYs. -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 08:32:48 2012 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 BE01E106564A for ; Fri, 3 Aug 2012 08:32:48 +0000 (UTC) (envelope-from edschouten@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 802248FC0C for ; Fri, 3 Aug 2012 08:32:48 +0000 (UTC) Received: by obbun3 with SMTP id un3so911359obb.13 for ; Fri, 03 Aug 2012 01:32:47 -0700 (PDT) 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=wl2DWyTAgeMa9D4mYl+iytja1ZmM85F76EpBBb9tqfs=; b=ud20+5LZAuRWehpB4OI+rpq/edDhCMEDhao9PCTYjRlzG11ctUnCPdxGRf3hPWI2Mf pt4jKgdBxOnd0C/xWmWDmqYc2Qrz8Jj7NOkmX/MG8Aexog63ExcduX5FYbWWfvL5VHxZ 7Ky7UdfBheBhNufq0SfMgOv5grrRBt/1G7PVCgnDxd7C5icLZ+JRl/2nwXlAJVz5Gswm 9iYjnsvJBM+eAg+8rBjEZt56jpFlJqbKPGcvtLMwFVwNlxFxPh8XuSJuPWt+RyTqwX4T 7lnbec56V4E7azUzNSbKyLRr+SerQHtIfZP9N2wZAgLBw8/6l419v+g4jvS3ZDapEp/E zs/A== MIME-Version: 1.0 Received: by 10.60.13.228 with SMTP id k4mr2528796oec.28.1343982767579; Fri, 03 Aug 2012 01:32:47 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.76.153.195 with HTTP; Fri, 3 Aug 2012 01:32:47 -0700 (PDT) In-Reply-To: <201208012341.25509.hselasky@c2i.net> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> Date: Fri, 3 Aug 2012 10:32:47 +0200 X-Google-Sender-Auth: iDcfrQPT2SHIIS_dSuXMTB3Xy4U Message-ID: From: Ed Schouten To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 08:32:48 -0000 2012/8/1 Hans Petter Selasky : > I think the problem is like this, that in order to re-use the unit numbers for > USB serial tty devices, the USB stack needs to wait until a TTY is actually > freed, right? Else you will have a panic on creating devfs entries having the > same name. Indeed. So the USB code could simply pick a different unit number. -- Ed Schouten From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 08:59:50 2012 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 CA7231065670 for ; Fri, 3 Aug 2012 08:59:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF9D8FC08 for ; Fri, 3 Aug 2012 08:59:49 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q738xolY074704; Fri, 3 Aug 2012 11:59:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q738xbVA089198; Fri, 3 Aug 2012 11:59:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q738xbE9089197; Fri, 3 Aug 2012 11:59:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Aug 2012 11:59:37 +0300 From: Konstantin Belousov To: Alexander Kabaev Message-ID: <20120803085937.GJ2676@deviant.kiev.zoral.com.ua> References: <20120802213954.GA34928@troutmask.apl.washington.edu> <20120802215536.027914c9@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I9F9dHb6y8qwQWx+" Content-Disposition: inline In-Reply-To: <20120802215536.027914c9@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: rtld dropping core on recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 08:59:50 -0000 --I9F9dHb6y8qwQWx+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote: > It is weird that program tries to dlopen what appears to be the binary > (itself?), but that did uncover the issue. Please try attached patch, > I only very lightly tested it here. >=20 > Also available here: > http://people.freebsd.org/~kan/rtld-digest-notes.diff >=20 > --=20 > Alexander Kabaev diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c index 509a64f..350d437 100644 --- a/libexec/rtld-elf/map_object.c +++ b/libexec/rtld-elf/map_object.c @@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct stat = *sb) break; note_start =3D (Elf_Addr)(char *)hdr + phdr->p_offset; note_end =3D note_start + phdr->p_filesz; - digest_notes(obj, note_start, note_end); break; } =20 @@ -292,6 +291,11 @@ map_object(int fd, const char *path, const struct stat= *sb) obj->relro_page =3D obj->relocbase + trunc_page(relro_page); obj->relro_size =3D round_page(relro_size); =20 + if (note_start < note_end) + { + digest_notes(obj, note_start, note_end); + } + munmap(hdr, PAGE_SIZE); return (obj); =20 This is the right fix. Why do you need the '{}' there ? --I9F9dHb6y8qwQWx+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAbkvkACgkQC3+MBN1Mb4gPFQCgo6iYJoBRTLpyR5SLhADUOz3e ItkAnA61BcRblEy1vQ6DIs7ARb+9jlxP =GpIa -----END PGP SIGNATURE----- --I9F9dHb6y8qwQWx+-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 11:20:34 2012 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 06B61106564A for ; Fri, 3 Aug 2012 11:20:34 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A6CDE8FC08 for ; Fri, 3 Aug 2012 11:20:33 +0000 (UTC) Received: by vbmv11 with SMTP id v11so655102vbm.13 for ; Fri, 03 Aug 2012 04:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=1QmWz/3SIejdlhydgQXbNGc8KN52p72jaNGd5R9omGc=; b=oTk9vWfPHnQI/SLdbjh9ucMMKjN+D9WUsf/i2Zmc2dfn99PIitI9/dxO3QFrTyKuAS FRZJZvuR4RD8vEig0pZt3YQwTQgaA82ueSyef7Sjk+73Nsz49MskK7B9n0einZMTiDS/ CtqBuhrmQD0Hb2OUXpBkVm73kwOJSi7JoJn2EAtJCQzL909zKJ8dbqDGd/YXns63SDV5 APi7STNp+KNCtvX0uL3qek4TXtZICjibmWo1TGbb7oyRP3AhSm5Ecv9zCIVUYUq3yNIo zPAAPJL8555G7E0rMfpCmts9BauCc6Xa61i19LO88aIE7lFEsqKI6T9VaBDv7/yhOedX +WsA== Received: by 10.52.35.233 with SMTP id l9mr907767vdj.7.1343992832163; Fri, 03 Aug 2012 04:20:32 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id w11sm8399510vdt.16.2012.08.03.04.20.26 (version=SSLv3 cipher=OTHER); Fri, 03 Aug 2012 04:20:26 -0700 (PDT) Date: Fri, 3 Aug 2012 07:20:12 -0400 From: Alexander Kabaev To: Konstantin Belousov Message-ID: <20120803072012.521631d8@kan.dyndns.org> In-Reply-To: <20120803085937.GJ2676@deviant.kiev.zoral.com.ua> References: <20120802213954.GA34928@troutmask.apl.washington.edu> <20120802215536.027914c9@kan.dyndns.org> <20120803085937.GJ2676@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3CjV3YievG+qzotu5dy+uDe"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: rtld dropping core on recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 11:20:34 -0000 --Sig_/3CjV3YievG+qzotu5dy+uDe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 3 Aug 2012 11:59:37 +0300 Konstantin Belousov wrote: > On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote: > > It is weird that program tries to dlopen what appears to be the > > binary (itself?), but that did uncover the issue. Please try > > attached patch, I only very lightly tested it here. > >=20 > > Also available here: > > http://people.freebsd.org/~kan/rtld-digest-notes.diff > >=20 > > --=20 > > Alexander Kabaev >=20 > diff --git a/libexec/rtld-elf/map_object.c > b/libexec/rtld-elf/map_object.c index 509a64f..350d437 100644 > --- a/libexec/rtld-elf/map_object.c > +++ b/libexec/rtld-elf/map_object.c > @@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct > stat *sb) break; > note_start =3D (Elf_Addr)(char *)hdr + phdr->p_offset; > note_end =3D note_start + phdr->p_filesz; > - digest_notes(obj, note_start, note_end); > break; > } > =20 > @@ -292,6 +291,11 @@ map_object(int fd, const char *path, const > struct stat *sb) obj->relro_page =3D obj->relocbase + > trunc_page(relro_page); obj->relro_size =3D round_page(relro_size); > =20 > + if (note_start < note_end) > + { > + digest_notes(obj, note_start, note_end); > + } > + > munmap(hdr, PAGE_SIZE); > return (obj); > =20 > This is the right fix. >=20 > Why do you need the '{}' there ? I do not. I just automatically followed style used at work. I'll FreeBSD-fy this before commit. --=20 Alexander Kabaev --Sig_/3CjV3YievG+qzotu5dy+uDe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQG7P5Q6z1jMm+XZYRAn5VAJ9seFpyzjatdHihuZmQETg1QFACoACcCptK jwIta74NVSrBEBCKqRW7d+4= =lxWU -----END PGP SIGNATURE----- --Sig_/3CjV3YievG+qzotu5dy+uDe-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 05:44:32 2012 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 EA938106564A for ; Fri, 3 Aug 2012 05:44:31 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6508FC12 for ; Fri, 3 Aug 2012 05:44:30 +0000 (UTC) Received: by weyx56 with SMTP id x56so219676wey.13 for ; Thu, 02 Aug 2012 22:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=from:reply-to:to:cc:subject:x-mailer:references:in-reply-to :content-type:content-id:date:message-id:mime-version :content-transfer-encoding; bh=R7yXS23mOQGIfXfNZEmlIUXWlUOlxNXgPlUFsFB8YaM=; b=ZXOeMs3HWhlQN4Rt9/sFmSY9xIL7tN/VsW35f69mv/iKH5ahILP+1g1ixuL0SJqgyY 6P0/tQgqtqfwRw9gkaysEqzhH/UoJgA2qTuy1YHUKbjWMeCZ7PXYSiXLSL4nCrB9qbOx 8FC6H8pp1LWBwPYArcE+Gx//jzKR0ZWDR359Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:reply-to:to:cc:subject:x-mailer:references:in-reply-to :content-type:content-id:date:message-id:mime-version :content-transfer-encoding:x-gm-message-state; bh=R7yXS23mOQGIfXfNZEmlIUXWlUOlxNXgPlUFsFB8YaM=; b=HetLRkO3HHK9jksrKwdFTi3Fxg47Z9XvCk3ZoFgGnk2xrnvy1AP5TIAq0HKCc5buHZ WZEOzZ4TSgneo3NYhiobt9bp8k6BRrMUumgndDS3YtzaMc1gcLtwGiNh3uW/Ex9cvd5o nXG+ET9wg+DD29W309V3ZRFQ+n0+5Cq0uYkG+xCxaySWZkUoLjCWGfKE5/N/OpLjyA8B TN9BWml/bBXu2ryyU4qDTmt7bRlWOj8e4nP8aCMbOzkh4Ndw+y/1xBmDBFWVqQwIg/U/ K0LpunCzOAPQmeUpBWSGlEAWDl7WVw3wwMuZx1apGJupByVR+gWfXGgMdsg83PH/uk6U WoYg== Received: by 10.180.20.11 with SMTP id j11mr1417245wie.12.1343972669981; Thu, 02 Aug 2012 22:44:29 -0700 (PDT) Received: from [10.33.63.27] (089144192002.atnat0001.highway.a1.net. [89.144.192.2]) by mx.google.com with ESMTPS id eu4sm37566340wib.2.2012.08.02.22.44.28 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 22:44:29 -0700 (PDT) From: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= To: Kevin Oberman , "Hartmann, O." X-Mailer: Modest 3.90.7 References: <501A323E.6000106@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-ID: <1343972666.4952.4.camel@Nokia-N900-42-11> Date: Fri, 03 Aug 2012 07:44:27 +0200 Message-Id: <1343972667.4952.5.camel@Nokia-N900-42-11> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnaaIDgKkT5G/xND+X7pMXdHIiJJmEbXLX2z2Kns/IfkxaZLH4TIya9C653LIuq8pXd34hD X-Mailman-Approved-At: Fri, 03 Aug 2012 11:21:52 +0000 Cc: FreeBSD Current Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:44:32 -0000 On Fr.,  3. Aug. 2012 06:18:33 CEST, Kevin Oberman wrote: > On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. > wrote: > > I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 > > (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the > > ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 > > for more than a minute. For a minute or so, I can work, then, the > > freeze occurs again. > > > > I can't see this behaviour with a Ubuntu Guest on the same box. Is > > there Windows 7 specifica to be aware of? > > I am seeing the same thing. Also Win7 guest with Windows showing idle > process at 99%, but my system is showing VB at 100%. The VM is only > running a single CPU, so FreeBSD is still running OK, but the Win7 > system seems to freeze up periodically. > > 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way > since VB was updated to 4.1.18. Guest additions for 4.1.18 > installed.All ports current. I'm thinking of backing off to 4.1.16. Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. -- http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 13:21:21 2012 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 2945E106564A for ; Fri, 3 Aug 2012 13:21:21 +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 D71218FC0C for ; Fri, 3 Aug 2012 13:21:20 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5C18E7300A; Fri, 3 Aug 2012 15:41:23 +0200 (CEST) Date: Fri, 3 Aug 2012 15:41:23 +0200 From: Luigi Rizzo To: Bernhard Fr?hlich Message-ID: <20120803134123.GA52965@onelab2.iet.unipi.it> References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1343972667.4952.5.camel@Nokia-N900-42-11> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , "Hartmann, O." Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 13:21:21 -0000 On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote: > On Fr.,?? 3. Aug. 2012 06:18:33 CEST, Kevin Oberman wrote: > > > On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. > > wrote: > > > I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 > > > (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the > > > ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 > > > for more than a minute. For a minute or so, I can work, then, the > > > freeze occurs again. > > > > > > I can't see this behaviour with a Ubuntu Guest on the same box. Is > > > there Windows 7 specifica to be aware of? > > > > I am seeing the same thing. Also Win7 guest with Windows showing idle > > process at 99%, but my system is showing VB at 100%. The VM is only > > running a single CPU, so FreeBSD is still running OK, but the Win7 > > system seems to freeze up periodically. > > > > 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way > > since VB was updated to 4.1.18. Guest additions for 4.1.18 > > installed.All ports current. I'm thinking of backing off to 4.1.16. > > Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. Could it be a case of kernel and virtualbox modules out of sync ? I do see occasional crashes with virtualbox in both the host and guest, but a reinstall of in-sync kernel and modules usually fixes them. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 14:58:11 2012 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 D100E1065673; Fri, 3 Aug 2012 14:58:11 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4141B8FC1D; Fri, 3 Aug 2012 14:58:10 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1132476ggn.13 for ; Fri, 03 Aug 2012 07:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+wJ5zopgSGloFRc3UfM075X6muE243xJ04g9ktr5GvU=; b=LerpC4tPcX6mMFJn2QLo4CbVj0eH6Qd6cwEZmzRFOLSMxuKdVeHyjbsdlsmNGsHEVG gxGqyiqNXRLI6pQRE0D0Cu3aGCTC5uZB5QlwGX2U9LFD77PGJO9DiNT6DjaFszERSBoW GrzHfsgKi2/BriXcWYBFnVFUTMwDRmn/yIJdUEK5Fi+n2t8DijVfPKvE4q36ZOecYXPB lW4g/JjQnuCflLkrJ5Flwuwii5Ex/82SSmanVfbZu7WtZXX5+3MyXYoMFhvhdfNLkTCR y5YVB1s///ACTleguSH5hT0OvOJPmPVYubxBOGWG1iysAlzrwQJrn0HF4gMYGUIXiSOB vu1Q== Received: by 10.50.94.199 with SMTP id de7mr3980501igb.40.1344005888718; Fri, 03 Aug 2012 07:58:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.90.229 with HTTP; Fri, 3 Aug 2012 07:57:48 -0700 (PDT) In-Reply-To: References: <612DA8A3-121E-4E72-9E5B-F3CBA9DEB7F7@bsdimp.com> <501A0258.4010101@FreeBSD.org> <45815622-3CE2-42E3-B118-702AA70C7E4C@samsco.org> <501AB08E.8020008@FreeBSD.org> <501B1D3A.6080501@freebsd.org> From: Royce Williams Date: Fri, 3 Aug 2012 06:57:48 -0800 Message-ID: To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 03 Aug 2012 15:07:14 +0000 Cc: Doug Barton , Garrett Cooper , FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: On cooperative work [Was: Re: newbus' ivar's limitation..] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 14:58:11 -0000 On Thu, Aug 2, 2012 at 5:14 PM, Kevin Oberman wrote: > On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer wrote: >> On 8/2/12 9:53 AM, Doug Barton wrote: >>> >>> On 08/02/2012 09:44, Garrett Cooper wrote: >>>> >>>> The "Watson/Losh connection" worked really well in BSDCan 2010 :). >>> >>> I wasn't going to mention that, since I didn't want to tell tales out of >>> school. But the fact that remote participation actually was provided for >>> "the right people," even though I was told repeatedly that it wasn't >>> possible, actually highlights a big part of the problem. >> >> bandwidth was limited and a single 1:1 skype connection was all we really >> could do. >> >> I did broadcast sessions a few years ago using the apple quicktime server >> but it was a lot of work and I think one person looked at part of one >> session. >> >>> Doug > > First, too many of these posts assume way too much. I don't think > anyone should be thinking of any sort of what is commonly called > "teleconferencing". That would be nice, but is far more complex and > expensive, both in bandwidth and equipment, then should be considered > as a starting point. > > I suggest the starting point is a webpage with a link to the slides > being presented and a simple audio stream. This is trivially possible > with a FreeBSD system and open-source software. A bandwidth of only > about 70kbps would be needed. Less with reasonable codec choice. > Several streams could be broadcast via a single, unicast stream to a > well connected server which woild then stream to end users It might be > augmented with jabber other open IM technology with someone at the > meeting if procedures for this could be agreed to. (Some vetting is > desirable, but will result in calls of censorship.) > > For small rooms, microphones are fairly easy to handle and one-way > streams don't require echo cancellation. > As costs for video come down, that might be something to think about > some day, but is not required to allow remote "attendance". > > Of course, unless this is publicized, no one will come (which > eliminates any technical issues). :-) Nail -> head. Everything that Kevin just said. With so much collective technical experience and intelligence available, we can work out the minor kinks in a solved problem (one-to-many audio and slide sharing). Getting the word out is also a solved problem. Both are very high-leverage -- and very good for the project. If we think about live BSDCan streaming as a fun project with classic hack value, instead of "an amorphous cloud of undoability", things will just come together naturally. The next action I see is calling for boots-on-the-ground volunteers to coordinate the local setup, and maybe a wiki page to capture the state of the project. Royce From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 18:19:10 2012 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 AD10E1065673 for ; Fri, 3 Aug 2012 18:19:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 862FD8FC0A for ; Fri, 3 Aug 2012 18:19:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F0B3EB918 for ; Fri, 3 Aug 2012 14:19:09 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Fri, 3 Aug 2012 14:18:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201208031418.57941.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Aug 2012 14:19:10 -0400 (EDT) Cc: Subject: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 18:19:10 -0000 We only have a few storage drivers left that use Giant and twe(4) is one of them. I don't have any hardware to test with, however. I have verified the patch compiles, but I'd appreciate it if some folks with twe(4) hardware could test it. The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 18:56:02 2012 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 7ACE81065673; Fri, 3 Aug 2012 18:56:02 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DD1688FC12; Fri, 3 Aug 2012 18:56:01 +0000 (UTC) Received: by weyx56 with SMTP id x56so814986wey.13 for ; Fri, 03 Aug 2012 11:56:01 -0700 (PDT) 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=heJre3PTzvgmMhTAp4LkVFaX5J/l73nGXmHDkZJOuUk=; b=LXA3VGEBQwmb6a9jDeM6JnzMRugSWFDQ6zA8U00DInWHHxHxbXYE5+aGoQETNXnJy4 TVPHgfm+84t5aL10qpk1TGscpOKfg0Y+jvkeI+AFC6zohmk0+LTc+3sBTg2KKXg/900N 2U3lwzi7iwgzeeeU6Z+rCqv5YAFrULHVqaArBTO8OEyrPJH/EkSYaTIRD3mLSApiAIdW crb40XiGSrpTGrCDYFAqoMHENGevzYV/xOhb5XbwTCBzPOKxllw7QakSgOaewyT7H6DZ qG9xG417K9lpqjttSsvVCQAZ+85ejitCCuFjaaklyqyiueRmoTGpiOqnckFRxnGUFtWP NByA== MIME-Version: 1.0 Received: by 10.180.99.196 with SMTP id es4mr15400488wib.18.1344020160893; Fri, 03 Aug 2012 11:56:00 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Fri, 3 Aug 2012 11:56:00 -0700 (PDT) In-Reply-To: <201208031418.57941.jhb@freebsd.org> References: <201208031418.57941.jhb@freebsd.org> Date: Fri, 3 Aug 2012 11:56:00 -0700 Message-ID: From: Kevin Oberman To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 18:56:02 -0000 I'll try to find time to try it later today, but I'm in the middle of budget wrangling and I can't make any promises. Before I try, will these patches apply to the twe driver in 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. I really don't have time to install current right now. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin wrote: > We only have a few storage drivers left that use Giant and twe(4) is one of > them. I don't have any hardware to test with, however. I have verified the > patch compiles, but I'd appreciate it if some folks with twe(4) hardware could > test it. > > The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 19:39:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D7B31065670 for ; Fri, 3 Aug 2012 19:39:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D65C08FC18 for ; Fri, 3 Aug 2012 19:39:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 29B8BB992; Fri, 3 Aug 2012 15:39:55 -0400 (EDT) From: John Baldwin To: Kevin Oberman Date: Fri, 3 Aug 2012 15:39:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201208031418.57941.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208031539.47735.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Aug 2012 15:39:55 -0400 (EDT) Cc: current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 19:39:56 -0000 On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: > I'll try to find time to try it later today, but I'm in the middle of > budget wrangling and I can't make any promises. > > Before I try, will these patches apply to the twe driver in > 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. > I really don't have time to install current right now. I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for initial testing. Thanks! > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > > On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin wrote: > > We only have a few storage drivers left that use Giant and twe(4) is one of > > them. I don't have any hardware to test with, however. I have verified the > > patch compiles, but I'd appreciate it if some folks with twe(4) hardware could > > test it. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/twe_locking.patch > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 20:43:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A773106566B; Fri, 3 Aug 2012 20:43:28 +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 E026D8FC08; Fri, 3 Aug 2012 20:43:27 +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 q73KhRel088794; Fri, 3 Aug 2012 16:43:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <501C37D3.5040704@sentex.net> Date: Fri, 03 Aug 2012 16:42:59 -0400 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: John Baldwin References: <201208031418.57941.jhb@freebsd.org> <201208031539.47735.jhb@freebsd.org> In-Reply-To: <201208031539.47735.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 20:43:28 -0000 On 8/3/2012 3:39 PM, John Baldwin wrote: > On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: >> I'll try to find time to try it later today, but I'm in the middle of >> budget wrangling and I can't make any promises. >> >> Before I try, will these patches apply to the twe driver in >> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. >> I really don't have time to install current right now. > > I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 > please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for > initial testing. Thanks! Seems to apply to RELENG_9 just fine. Are there any stress tests you suggest I run that might expose some bugs ? The machine is not production yet, so its ok to crash it. {offsite2}# patch -p9 < twe_locking.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe.c 2009-12-25 17:35:14.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe.c 2012-08-03 04:00:49.000000000 0000 -------------------------- Patching file twe.c using Plan A... Hunk #1 succeeded at 151. Hunk #2 succeeded at 167. Hunk #3 succeeded at 189. Hunk #4 succeeded at 208. Hunk #5 succeeded at 226. Hunk #6 succeeded at 234. Hunk #7 succeeded at 271. Hunk #8 succeeded at 288. Hunk #9 succeeded at 310. Hunk #10 succeeded at 337. Hunk #11 succeeded at 349. Hunk #12 succeeded at 405. Hunk #13 succeeded at 521. Hunk #14 succeeded at 557. Hunk #15 succeeded at 580. Hunk #16 succeeded at 595. Hunk #17 succeeded at 608. Hunk #18 succeeded at 646. Hunk #19 succeeded at 769. Hunk #20 succeeded at 863. Hunk #21 succeeded at 921. Hunk #22 succeeded at 952. Hunk #23 succeeded at 1038. Hunk #24 succeeded at 1051. Hunk #25 succeeded at 1082. Hunk #26 succeeded at 1104. Hunk #27 succeeded at 1140. Hunk #28 succeeded at 1151. Hunk #29 succeeded at 1177. Hunk #30 succeeded at 1206. Hunk #31 succeeded at 1309. Hunk #32 succeeded at 1447. Hunk #33 succeeded at 1469. Hunk #34 succeeded at 1499. Hunk #35 succeeded at 1513. Hunk #36 succeeded at 1531. Hunk #37 succeeded at 1554. Hunk #38 succeeded at 1589. Hunk #39 succeeded at 1618. Hunk #40 succeeded at 1644. Hunk #41 succeeded at 1696. Hunk #42 succeeded at 1778. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe_compat.h 2005-05-29 04:45:51.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_compat.h 2012-08-03 03:58:12.000000000 0000 -------------------------- Patching file twe_compat.h using Plan A... Hunk #1 succeeded at 43. Hunk #2 succeeded at 68. Hunk #3 succeeded at 82. Hunk #4 succeeded at 92. Hunk #5 succeeded at 108. Hunk #6 succeeded at 128. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twe_freebsd.c 2012-03-12 08:05:24.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twe_freebsd.c 2012-08-03 18:10:04.000000000 0000 -------------------------- Patching file twe_freebsd.c using Plan A... Hunk #1 succeeded at 69. Hunk #2 succeeded at 83. Hunk #3 succeeded at 101. Hunk #4 succeeded at 180. Hunk #5 succeeded at 188. Hunk #6 succeeded at 211. Hunk #7 succeeded at 241. Hunk #8 succeeded at 292. Hunk #9 succeeded at 414. Hunk #10 succeeded at 425. Hunk #11 succeeded at 461. Hunk #12 succeeded at 496. Hunk #13 succeeded at 518. Hunk #14 succeeded at 533. Hunk #15 succeeded at 566. Hunk #16 succeeded at 585. Hunk #17 succeeded at 604. Hunk #18 succeeded at 680. Hunk #19 succeeded at 729. Hunk #20 succeeded at 834. Hunk #21 succeeded at 857. Hunk #22 succeeded at 876. Hunk #23 succeeded at 1038. Hunk #24 succeeded at 1097. Hunk #25 succeeded at 1151. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- //depot/vendor/freebsd/src/sys/dev/twe/twevar.h 2009-12-25 17:35:14.000000000 0000 |+++ //depot/user/jhb/cleanup/sys/dev/twe/twevar.h 2012-08-03 04:00:49.000000000 0000 -------------------------- Patching file twevar.h using Plan A... Hunk #1 succeeded at 134. Hunk #2 succeeded at 210. Hunk #3 succeeded at 255. done 0{offsite2}# -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 21:17:12 2012 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 0D965106564A; Fri, 3 Aug 2012 21:17:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA9CF8FC15; Fri, 3 Aug 2012 21:17:11 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2080180pbb.13 for ; Fri, 03 Aug 2012 14:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AQEsojrmN4Juxmk3jh/S5Kpz2dp+l1LLHdJfJ991Z3w=; b=ia5c3Tp6aKICRK2rHuUDkf9d5edfWaZE58ynl8AzZScKEAoFPKvXrMwZX2G4k0S1eX 3/9a3dMtsrban0xZC3vJILjAWOiwg+NdBMjJRh+MWrVLeoVnXQZHRnVHWhDrpyCf17Bu JAJRMN9nU+JEOwGz2qSmLjsxj5d9SjOR5r92b7jKW0ifFXBiqveM2Fv5nne6nOPH4ThY PTJb23QBgCZ/FkgCTmCkMNKL1sz4yZx1jqA2QH5esrXk7Cq+mg53GVagITld991LrygJ ZWem1Ax+TLSEmdHekoGTdErG8ztDk5Ni7AMWowKsVSsiwVFp2zl1kR/dkyryB3rRwKnp sv8A== Received: by 10.68.227.201 with SMTP id sc9mr471426pbc.163.1344028631066; Fri, 03 Aug 2012 14:17:11 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id tq4sm186546pbc.11.2012.08.03.14.17.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 14:17:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <501C37D3.5040704@sentex.net> Date: Fri, 3 Aug 2012 14:17:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com> References: <201208031418.57941.jhb@freebsd.org> <201208031539.47735.jhb@freebsd.org> <501C37D3.5040704@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.1278) Cc: current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 21:17:12 -0000 On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote: > On 8/3/2012 3:39 PM, John Baldwin wrote: >> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: >>> I'll try to find time to try it later today, but I'm in the middle = of >>> budget wrangling and I can't make any promises. >>>=20 >>> Before I try, will these patches apply to the twe driver in >>> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July = 18. >>> I really don't have time to install current right now. >>=20 >> I believe the patches should apply fine on 8 and 9. If you use it on = 8 or 9 >> please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least = for >> initial testing. Thanks! >=20 > Seems to apply to RELENG_9 just fine. Are there any stress tests you > suggest I run that might expose some bugs ? The machine is not > production yet, so its ok to crash it. Looking really quickly at the patch, it looks like most of the = locking changes are made around management pieces, and not data handling = pieces (but I might have missed something). If there's a tool for poking at the drives/controller, I would = use that, plus camcontrol. Of course you want a data intensive workload = (iometer/iozone/xdd with async and sync mode, random reads and = sequential reads, etc), and maybe resort to manual testing like pulling = drives (power, data) if you don't mind creating failures. If you have = some failed/failing drives kicking around, that would be a good test as = well (see that all/some of the failure paths are properly stimulated). Any variance or combining of these tests will help build = confidence in the change being proposed. HTH, -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 21:18:25 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C472106566C for ; Fri, 3 Aug 2012 21:18:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 036448FC16 for ; Fri, 3 Aug 2012 21:18:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C61EB918; Fri, 3 Aug 2012 17:18:24 -0400 (EDT) From: John Baldwin To: Mike Tancsa Date: Fri, 3 Aug 2012 17:18:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201208031418.57941.jhb@freebsd.org> <201208031539.47735.jhb@freebsd.org> <501C37D3.5040704@sentex.net> In-Reply-To: <501C37D3.5040704@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208031718.07569.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Aug 2012 17:18:24 -0400 (EDT) Cc: current@freebsd.org Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 21:18:25 -0000 On Friday, August 03, 2012 4:42:59 pm Mike Tancsa wrote: > On 8/3/2012 3:39 PM, John Baldwin wrote: > > On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: > >> I'll try to find time to try it later today, but I'm in the middle of > >> budget wrangling and I can't make any promises. > >> > >> Before I try, will these patches apply to the twe driver in > >> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. > >> I really don't have time to install current right now. > > > > I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 > > please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for > > initial testing. Thanks! > > Seems to apply to RELENG_9 just fine. Are there any stress tests you > suggest I run that might expose some bugs ? The machine is not > production yet, so its ok to crash it. Probably pho's stress2 stuff. Thinks like dbench might be a good start as well for initial testing. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 21:27:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680651065670 for ; Fri, 3 Aug 2012 21:27:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9758FC0A for ; Fri, 3 Aug 2012 21:27:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE75FB918; Fri, 3 Aug 2012 17:27:17 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Fri, 3 Aug 2012 17:26:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201208031418.57941.jhb@freebsd.org> <501C37D3.5040704@sentex.net> <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com> In-Reply-To: <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208031726.03652.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Aug 2012 17:27:17 -0400 (EDT) Cc: current@freebsd.org, Mike Tancsa Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 21:27:18 -0000 On Friday, August 03, 2012 5:17:09 pm Garrett Cooper wrote: > On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote: > > > On 8/3/2012 3:39 PM, John Baldwin wrote: > >> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: > >>> I'll try to find time to try it later today, but I'm in the middle of > >>> budget wrangling and I can't make any promises. > >>> > >>> Before I try, will these patches apply to the twe driver in > >>> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. > >>> I really don't have time to install current right now. > >> > >> I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 > >> please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for > >> initial testing. Thanks! > > > > Seems to apply to RELENG_9 just fine. Are there any stress tests you > > suggest I run that might expose some bugs ? The machine is not > > production yet, so its ok to crash it. > > Looking really quickly at the patch, it looks like most of the locking changes are made around management pieces, and not data handling pieces (but I might have missed something). No, it changes those paths, too. There just aren't many of them. All the data enters through twed_strategy() and leaves via twed_intr() (invoked from twe_intr()). > If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see that all/some of the failure paths are properly stimulated). 3dm2 testing would be good for the ioctl handling, but the most critical tests are basic I/O. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 3 22:36:14 2012 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 9A17C106566C for ; Fri, 3 Aug 2012 22:36:14 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 29CC78FC0C for ; Fri, 3 Aug 2012 22:36:13 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so985761wgb.31 for ; Fri, 03 Aug 2012 15:36:13 -0700 (PDT) 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=dq5Yw/g9IWL8Go549aLZ7Fg8+hJ16zQ4GBv2fVfoAVU=; b=kg6lGb4RHoG22vQtNzQL3unOUblZxDwNu2ol8R1kurSU6/OwNccl2Y1CKThHKJZY0r ad40S33Mr19F9mKpGSTnsL9Nn6wYdAsFUTgJDIGAdYXjKMPhG5+0dXUwjJX9C7uzdeEK CUcI2bB9AM7Gb7wRPoyBAj5GB7CThzz0P0W86G4M3A+hwjM+O8rg8dCPEX/OwdA6SVu/ 1MIO+XqYl2DbD2P46c1bodh67itUluTyQMEUlAkOKy882sNFgRd6sX+qKLjgLOTLn6Dp UJ7Jyc6bL42tWPp60+L9IA3hopdkuzbZKtgkwhd2ij5G6/oMcVf7tiQO38uArphvDH91 9noQ== MIME-Version: 1.0 Received: by 10.180.82.164 with SMTP id j4mr7638671wiy.18.1344033373277; Fri, 03 Aug 2012 15:36:13 -0700 (PDT) Received: by 10.223.60.147 with HTTP; Fri, 3 Aug 2012 15:36:13 -0700 (PDT) In-Reply-To: <20120803134123.GA52965@onelab2.iet.unipi.it> References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> Date: Fri, 3 Aug 2012 15:36:13 -0700 Message-ID: From: Kevin Oberman To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Bernhard Fr?hlich , FreeBSD Current , "Hartmann, O." Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Aug 2012 22:36:14 -0000 On Fri, Aug 3, 2012 at 6:41 AM, Luigi Rizzo wrote: > On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote: >> On Fr.,?? 3. Aug. 2012 06:18:33 CEST, Kevin Oberman wrote: >> >> > On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. >> > wrote: >> > > I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 >> > > (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the >> > > ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 >> > > for more than a minute. For a minute or so, I can work, then, the >> > > freeze occurs again. >> > > >> > > I can't see this behaviour with a Ubuntu Guest on the same box. Is >> > > there Windows 7 specifica to be aware of? >> > >> > I am seeing the same thing. Also Win7 guest with Windows showing idle >> > process at 99%, but my system is showing VB at 100%. The VM is only >> > running a single CPU, so FreeBSD is still running OK, but the Win7 >> > system seems to freeze up periodically. >> > >> > 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way >> > since VB was updated to 4.1.18. Guest additions for 4.1.18 >> > installed.All ports current. I'm thinking of backing off to 4.1.16. >> >> Can someone confirm that this is a regression in 4.1.18? Then I could talk to upstream and see if I can get that adressed. > > Could it be a case of kernel and virtualbox modules out of sync ? > I do see occasional crashes with virtualbox in both the host and guest, > but a reinstall of in-sync kernel and modules usually fixes them. Nope. To be really, really sure I just re-built the module and rebooted. VB still eats 100% CPU (out of 400%) continually. Thanks for the suggestion, though. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 07:40:56 2012 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 23280106566C for ; Sat, 4 Aug 2012 07:40:56 +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 C6B588FC0C for ; Sat, 4 Aug 2012 07:40:55 +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 <1SxYye-0002wu-An>; Sat, 04 Aug 2012 09:40:48 +0200 Received: from e178022250.adsl.alicedsl.de ([85.178.22.250] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SxYye-000207-5G>; Sat, 04 Aug 2012 09:40:48 +0200 Message-ID: <501CD1F8.1070404@zedat.fu-berlin.de> Date: Sat, 04 Aug 2012 09:40:40 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120801 Thunderbird/14.0 MIME-Version: 1.0 To: Kevin Oberman References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFD1B3BCFA8F41B44E92F82C2" X-Originating-IP: 85.178.22.250 Cc: Bernhard Fr?hlich , FreeBSD Current , Luigi Rizzo Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 07:40:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD1B3BCFA8F41B44E92F82C2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08/04/12 00:36, schrieb Kevin Oberman: > On Fri, Aug 3, 2012 at 6:41 AM, Luigi Rizzo wrote:= >> On Fri, Aug 03, 2012 at 07:44:27AM +0200, Bernhard Fr?hlich wrote: >>> On Fr.,?? 3. Aug. 2012 06:18:33 CEST, Kevin Oberman wrote: >>> >>>> On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. >>>> wrote: >>>>> I discover that when running Windows 7 in a VirtualBox On FreeBSD 1= 0 >>>>> (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from t= he >>>>> ports, that the VirtualBox eats up 100% CPU time and freezes Window= s 7 >>>>> for more than a minute. For a minute or so, I can work, then, the >>>>> freeze occurs again. >>>>> >>>>> I can't see this behaviour with a Ubuntu Guest on the same box. Is >>>>> there Windows 7 specifica to be aware of? >>>> >>>> I am seeing the same thing. Also Win7 guest with Windows showing idl= e >>>> process at 99%, but my system is showing VB at 100%. The VM is only >>>> running a single CPU, so FreeBSD is still running OK, but the Win7 >>>> system seems to freeze up periodically. >>>> >>>> 9.1-PRERELEASE on amd64 updated yesterday (though it has been this w= ay >>>> since VB was updated to 4.1.18. Guest additions for 4.1.18 >>>> installed.All ports current. I'm thinking of backing off to 4.1.16. >>> >>> Can someone confirm that this is a regression in 4.1.18? Then I could= talk to upstream and see if I can get that adressed. >> >> Could it be a case of kernel and virtualbox modules out of sync ? >> I do see occasional crashes with virtualbox in both the host and guest= , >> but a reinstall of in-sync kernel and modules usually fixes them. >=20 > Nope. To be really, really sure I just re-built the module and > rebooted. VB still eats 100% CPU (out of 400%) continually. >=20 > Thanks for the suggestion, though. >=20 No, also in my case. I build world and the VBox software with each kernel - usually. Regards, Oliver --------------enigFD1B3BCFA8F41B44E92F82C2 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) iQEcBAEBAgAGBQJQHNH/AAoJEOgBcD7A/5N8pMcH/j6i+Jftgv8L8sO3KqtroErE 4D78JLO2ftdDhWKkruSpcOeBXYU76YtOudAV/O8/rK0Kj5qlRFXskdhGW5Cknjvu zA6YWSJ09+v+ekCsX0SOIXfr1pXrD5E8alxAXsLupejnN0smcsQZb3BYAmtY5d1k vb/BKoou7UmQWFqgpdYSB7525C7nYr3plEaAA220EyZk/1Ycrq70KSTYHaIQdEFN tv4BocNf5WnzS3WRsvbzBlrGlwQ0APDW5O45yELe418DH3/xmmmxRpXT3RlDqhSP MANj40WYvCC6dKTsSOvBbA6IgTeMF4m6pEu07GEWvugsz9MEvAno1a9edtIVvnY= =bGHk -----END PGP SIGNATURE----- --------------enigFD1B3BCFA8F41B44E92F82C2-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 16:50:00 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1770106566B; Sat, 4 Aug 2012 16:50:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD488FC0A; Sat, 4 Aug 2012 16:50:00 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 697F7612E; Sat, 4 Aug 2012 12:49:51 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=lWJOkBrU6M4sdIJPXNil48S4ZYsba7/Cur74hC1WqS8+I5VYh/DS86xdSFaEDEZ1q 2ng8/5PUMnxk7r9jmHnhW54He2NRk2qMWR8y30PE/U5uL9fX7ZINa9JtwRyLGuo Message-ID: <501D52AD.4010105@protected-networks.net> Date: Sat, 04 Aug 2012 12:49:49 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: current@FreeBSD.org, stable@freebsd.org X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: geom mirror now rebuilding on every reboot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 16:50:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Something in -current and recently MFC'd to -stable is causing all of my gmirror drives to rebuild on reboot :-( Being remote and these being production machines, I suspect SVN r237929 and r237930 in -current and SVN r238500 to -stable but haven't yet been able to prove it. Is anyone else seeing this? imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAdUqwACgkQQv9rrgRC1JIVSwCfctGE6tASTXyhW1ejHsWLTDRs MTsAoMXqcQ3dwlurELdqm2ZBqTCCgRaR =J/No -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 17:55:33 2012 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 C770E106566B for ; Sat, 4 Aug 2012 17:55:33 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from mail.insightbb.com (smtp3.insight.synacor.com [208.47.185.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8830B8FC08 for ; Sat, 4 Aug 2012 17:55:32 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=1.1 cv=atjspXeKIBvubkJ4GvovWz4cNmgy3vPUj4c5TmWmWIU= c=1 sm=0 a=jLN7EqiLvroA:10 a=8nJEP1OIZ-IA:10 a=jSW02UzkF7qP-7K0OzwA:9 a=wPNLvfGTeEIA:10 a=VWp6FqSG4Vb1RlmLnQz6YQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.insight.synacor.com smtp.mail=David.Boyd@insightbb.com; spf=softfail; sender-id=softfail Authentication-Results: smtp02.insight.synacor.com header.from=David.Boyd@insightbb.com; sender-id=softfail Received-SPF: softfail (smtp02.insight.synacor.com: transitional domain insightbb.com does not designate 74.138.146.238 as permitted sender) Received: from [74.138.146.238] ([74.138.146.238:1648] helo=sneezy) by mail.insightbb.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 81/8B-16443-7716D105; Sat, 04 Aug 2012 13:52:56 -0400 From: "David Boyd" To: Date: Sat, 4 Aug 2012 13:52:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: pucdata.c addition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 17:55:33 -0000 Can someone please add the following definition to pucdata.c? { 0x1415, 0x950a, 0x131f, 0x2032, "SIIG Cyber Serial Dual PCI 16C850 (20x family)", DEFAULT_RCLK * 10, PUC_PORT_4S, 0x10, 0, 8, }, The card is identified as a SIIG CyberSerial Dual (2 ports) is expandable to 4 ports and registers four uart devices with FreeBSD (even without the expansion chip). The chipset is by Oxford Semicondutor (OX16PCI954). The card has a non-standard clock. Thanks. David Boyd From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 20:27:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 27BC5106566B for ; Sat, 4 Aug 2012 20:27:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B0E5314DB05; Sat, 4 Aug 2012 20:26:49 +0000 (UTC) Message-ID: <501D8589.50205@FreeBSD.org> Date: Sat, 04 Aug 2012 13:26:49 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: "O. Hartmann" References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> In-Reply-To: <501CD1F8.1070404@zedat.fu-berlin.de> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 20:27:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2012 00:40, O. Hartmann wrote: > No, also in my case. I build world and the VBox software with each > kernel - usually. You can ensure that by putting this in src.conf: PORTS_MODULES= emulators/virtualbox-ose-kmod You can place other modules in that list as well. I use vbox so you can be pretty confident that this is going to keep working. :) Doug - -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQHYWJAAoJEFzGhvEaGryEyLUIALgi1n65I8oBaFYJEcIkDB6P W3f5PMZa72DN4r2lI3A3XXdPUJsNRmNy/X0HYyrrIwvfD3Z3m8bReYCd7DHAKOX4 pBsLA/73cwns9c3+zsUe4i9TZOsJM8fNVsRp/BSvdtBgv61ZZUurvt43H+Ek0E0B h5ttGaIanxLqrkwP2FC/q30t0pmauJYu3jDTGiugOh98o/3oNT+25etyJBNgvg4c VxBs/5aCSc5VHAcLXRN6Y0BGGbeimpPqEFlq3FEFGLkC7LGjqoSBUaJVz1cgDP+t RIK9g0V+XIfyirgZ2VMeK3tfQ0Q17zfyl0+Iyzl2IxZptU67OBV/9LMqyhRaBOc= =KbES -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 21:26:01 2012 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 CD79D106564A; Sat, 4 Aug 2012 21:26:01 +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 80AC58FC0A; Sat, 4 Aug 2012 21:26:01 +0000 (UTC) Received: by obbun3 with SMTP id un3so4097711obb.13 for ; Sat, 04 Aug 2012 14:26:01 -0700 (PDT) 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=dpnB7XaV3q7pn1uqUB62zmEw4oPH56hmoHOj5kay07s=; b=mh6MqVuXZV/G+cL9VvyfzfrP+f7YDwnc2B49IdiEHG1poyeyeRpzwYwIf/jNfUvw/2 59MDbCaAprBX2qk75CU4zoLi805AhYicX2lbAzS7464zMGrvAlX0jDuZ9wsO5yGyzgXu JubvO/9tqvr+67JCMlgSmsBesFvsqOICM77P0/qQzVHeVJapwneuttZeAFjeWjYLP0L8 Zbs5l7lo6KGO/b5du8PYGLthdicFBUUuKDw3qPP+amJwsHdudpobARMxmhBSYZpbpjNz E0RdcKnUh3iK3TwoLl9H9/jtTi9sBgLmJY06OIfUpzSGSsq7StH/Jg8/lzQqGnzYnk7A M98w== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr12113923obx.11.1344115560944; Sat, 04 Aug 2012 14:26:00 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Sat, 4 Aug 2012 14:26:00 -0700 (PDT) In-Reply-To: <501D8589.50205@FreeBSD.org> References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> <501D8589.50205@FreeBSD.org> Date: Sat, 4 Aug 2012 14:26:00 -0700 Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "O. Hartmann" Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 21:26:01 -0000 On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 08/04/2012 00:40, O. Hartmann wrote: >> No, also in my case. I build world and the VBox software with each >> kernel - usually. > > You can ensure that by putting this in src.conf: > > PORTS_MODULES= emulators/virtualbox-ose-kmod > > You can place other modules in that list as well. I use vbox so you can > be pretty confident that this is going to keep working. :) That doesn't work because what variables are defined in the kernel compile that get passed through to the port's autoconf. I've seen it for a while but I need to figure out what to pass through exactly to make things work. That or I'll just file a PR and get back to it later. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Aug 4 21:30:31 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 439C8106564A for ; Sat, 4 Aug 2012 21:30:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EBFF214E131; Sat, 4 Aug 2012 21:30:30 +0000 (UTC) Message-ID: <501D9476.80902@FreeBSD.org> Date: Sat, 04 Aug 2012 14:30:30 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Garrett Cooper References: <501A323E.6000106@zedat.fu-berlin.de> <1343972667.4952.5.camel@Nokia-N900-42-11> <20120803134123.GA52965@onelab2.iet.unipi.it> <501CD1F8.1070404@zedat.fu-berlin.de> <501D8589.50205@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "O. Hartmann" Subject: Re: VirtualBox: Eating up 100% CPU, freezing Windows 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Aug 2012 21:30:31 -0000 On 08/04/2012 14:26, Garrett Cooper wrote: > On Sat, Aug 4, 2012 at 1:26 PM, Doug Barton wrote: > >> On 08/04/2012 00:40, O. Hartmann wrote: >>> No, also in my case. I build world and the VBox software with each >>> kernel - usually. >> >> You can ensure that by putting this in src.conf: >> >> PORTS_MODULES= emulators/virtualbox-ose-kmod >> >> You can place other modules in that list as well. I use vbox so you can >> be pretty confident that this is going to keep working. :) > > That doesn't work I assure you that it does. I have put a non-zero amount of work into fixing it, I use this method, and the resulting kernel module works just fine. If you actually try it and find something is not as it should be, then yes; please do file a PR and feel free to cc me. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)