From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 00:13:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 373F6ADB for ; Sun, 9 Feb 2014 00:13:19 +0000 (UTC) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E23C61C03 for ; Sun, 9 Feb 2014 00:13:18 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j5so7597926qaq.34 for ; Sat, 08 Feb 2014 16:13:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TkItOJ1UxRw6FRXFdgpH2m658xh5VcenVk77nQ+KmXo=; b=fLS3JZ5yLr5dto2IkxHGVueGjlOL55hO7bmfCUxsI7zTNe1Y3EVdB0nWWcmAhS5myK NejffCYlC52EPkiuBFGsRgt33dDX7k/fPn9wcvpxjns07gKfBSzhNTH3+Ket4Cf9s+Nj tzIf/LX1akKp3eyNv/TIC79nG7ZxTx/hUNsgMs+NJDLbs21XRSEliLIOt4JXrlzdnJA0 7+YgU0MPbXLaVvLxulcvupEVJpmyj5xyaavIlh6cL200W/CkWigwlAD2TJKuMLCItA11 afXNiOo9c1xXQ7kw17mTiUWUexNUXpbOPJ3N0T4LPe3gEC9+sSzEqf2C7N6192yGFmST dPig== X-Gm-Message-State: ALoCoQktug0uWvQaqbXqO74jG24jci8KrbmwVrR7Kd/d90lqHqEdbL0moDnGZAkGaDszCUFuR2pi X-Received: by 10.140.102.69 with SMTP id v63mr33212738qge.5.1391904792599; Sat, 08 Feb 2014 16:13:12 -0800 (PST) Received: from [192.168.1.3] (pool-96-225-163-50.nrflva.fios.verizon.net. [96.225.163.50]) by mx.google.com with ESMTPSA id h12sm16697203qge.0.2014.02.08.16.13.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Feb 2014 16:13:11 -0800 (PST) Message-ID: <52F6C7D9.20501@ohlste.in> Date: Sat, 08 Feb 2014 19:12:09 -0500 From: Jim Ohlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Roger Leigh Subject: Re: 10.0 toolchain broken for C++11 code References: <20140208233255.GA6282@amys.codelibre.net> In-Reply-To: <20140208233255.GA6282@amys.codelibre.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Chisnall , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 00:13:19 -0000 Hello, On 2/8/14, 6:32 PM, Roger Leigh wrote: > Hi folks, > > I'm new to using FreeBSD. I'm the author of the schroot(1) tool, and I've > been porting it to FreeBSD using the new 10.0-RELEASE on amd64 and powerpc. > The plan is to make it support jails and ZFS snapshots on FreeBSD systems. > However, I've hit a blocker in that after fixing a few Linux-isms I've > I've found that I can't actually link my code. > > This is a minimal testcase: > > % cat test.cpp > #include > > int main() > { > const std::type_info& t = typeid(nullptr); > } > > % CC -std=c++11 -o test test.cpp > /tmp/test-OoDHHT.o: In function `main': > test.cpp:(.text+0xd): undefined reference to `_ZTIDn' > CC: error: linker command failed with exit code 1 (use -v to see invocation) > > See also: > standards/185663 > https://github.com/pathscale/libcxxrt/issues/16 The fix was committed to head (260553) on 1/11/14 and was supposed to be MFC'd in one week. See http://svnweb.freebsd.org/base?view=revision&revision=260553. I don't see that it's happened as of r261643. I have cc'd David Chisnall. Perhaps he can address it. > > Being unfamiliar with FreeBSD my question is really, what sort of timescale > is typical for fixing this type of issue? At least for my code, the > toolchain is basically unusable until this is fixed, and I don't think > there's a workaround for it. If it gets fixed in -STABLE, is it possible > to selectively cherry-pick this somehow, or would I need to switch to > -STABLE wholesale? Is there an expected date for 10.1 to be released? Probably a little while. 10.0-RELEASE was just finalized last moonth. If there's going to be an 8.5-RELEASE it will probably be next. Otherwise, 9.3-RELASE will probably be next. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 00:46:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06CEE3AE; Sun, 9 Feb 2014 00:45:59 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A95451E44; Sun, 9 Feb 2014 00:45:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::20a4:db0:4ac7:1cb7] (unknown [IPv6:2001:7b8:3a7:0:20a4:db0:4ac7:1cb7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C8D2E5C45; Sun, 9 Feb 2014 01:45:52 +0100 (CET) Subject: Re: 10.0 toolchain broken for C++11 code Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E8EB6B11-9F83-4A6D-B734-A9540CF9483E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <52F6C7D9.20501@ohlste.in> Date: Sun, 9 Feb 2014 01:45:44 +0100 Message-Id: References: <20140208233255.GA6282@amys.codelibre.net> <52F6C7D9.20501@ohlste.in> To: Jim Ohlstein X-Mailer: Apple Mail (2.1827) Cc: Roger Leigh , David Chisnall , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 00:46:00 -0000 --Apple-Mail=_E8EB6B11-9F83-4A6D-B734-A9540CF9483E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 09 Feb 2014, at 01:12, Jim Ohlstein wrote: > On 2/8/14, 6:32 PM, Roger Leigh wrote: ... >> See also: >> standards/185663 >> https://github.com/pathscale/libcxxrt/issues/16 >=20 > The fix was committed to head (260553) on 1/11/14 and was supposed to = be MFC'd in one week. = Seehttp://svnweb.freebsd.org/base?view=3Drevision&revision=3D260553. I = don't see that it's happened as of r261643. I have merged the fix to stable/10 in r261644, and while I was at it, I sync'd up stable/9 too, in r261645. There are now only two differences left between the version of libcxxrt in head and in stable/{9,10}; one of these will be MFC'd very soon, and the other is up for reversal. >> Being unfamiliar with FreeBSD my question is really, what sort of = timescale >> is typical for fixing this type of issue? At least for my code, the >> toolchain is basically unusable until this is fixed, and I don't = think >> there's a workaround for it. If it gets fixed in -STABLE, is it = possible >> to selectively cherry-pick this somehow, or would I need to switch to >> -STABLE wholesale? Is there an expected date for 10.1 to be = released? It is easy to cherry-pick. Either use svn to merge changelist 260553 to your local source tree, or download the following as a patch, and apply it manually: = http://svnweb.freebsd.org/base/head/lib/libcxxrt/Version.map?view=3Dpatch&= r1=3D260553&r2=3D260552&pathrev=3D260553 Then do: cd /usr/src/lib/libcxxrt make sudo make install > Probably a little while. 10.0-RELEASE was just finalized last moonth. = If there's going to be an 8.5-RELEASE it will probably be next. = Otherwise, 9.3-RELASE will probably be next. Unfortunately, we only patch releases for security issues. So the earliest will either be 10.1-RELEASE or 9.3-RELEASE, since 8.x has neither clang nor libcxxrt. That said, 10-STABLE should mostly be just fine to run on a daily basis. -Dimitry --Apple-Mail=_E8EB6B11-9F83-4A6D-B734-A9540CF9483E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlL2z70ACgkQsF6jCi4glqOkJACg/5ITf922IXiCTbgMQa6z7awb wXIAnAw3NVpLHWjQIRJX3VCb62J1Dxc6 =QCzO -----END PGP SIGNATURE----- --Apple-Mail=_E8EB6B11-9F83-4A6D-B734-A9540CF9483E-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 13:29:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEC2CE9E; Sun, 9 Feb 2014 13:29:26 +0000 (UTC) Received: from nagini.codelibre.net (nagini.codelibre.net [80.68.93.164]) by mx1.freebsd.org (Postfix) with ESMTP id B292E15C7; Sun, 9 Feb 2014 13:29:26 +0000 (UTC) Received: by nagini.codelibre.net (Postfix, from userid 1000) id 3172618283; Sun, 9 Feb 2014 13:29:10 +0000 (GMT) Date: Sun, 9 Feb 2014 13:29:10 +0000 From: Roger Leigh To: Dimitry Andric Subject: Re: 10.0 toolchain broken for C++11 code Message-ID: <20140209132909.GH11464@codelibre.net> References: <20140208233255.GA6282@amys.codelibre.net> <52F6C7D9.20501@ohlste.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable stable , David Chisnall X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 13:29:27 -0000 On Sun, Feb 09, 2014 at 01:45:44AM +0100, Dimitry Andric wrote: > On 09 Feb 2014, at 01:12, Jim Ohlstein wrote: > > On 2/8/14, 6:32 PM, Roger Leigh wrote: > ... > >> See also: > >> standards/185663 > >> https://github.com/pathscale/libcxxrt/issues/16 > > > > The fix was committed to head (260553) on 1/11/14 and was supposed to be MFC'd in one week. Seehttp://svnweb.freebsd.org/base?view=revision&revision=260553. I don't see that it's happened as of r261643. > > I have merged the fix to stable/10 in r261644, and while I was at it, I > sync'd up stable/9 too, in r261645. There are now only two differences > left between the version of libcxxrt in head and in stable/{9,10}; one > of these will be MFC'd very soon, and the other is up for reversal. > > > >> Being unfamiliar with FreeBSD my question is really, what sort of timescale > >> is typical for fixing this type of issue? At least for my code, the > >> toolchain is basically unusable until this is fixed, and I don't think > >> there's a workaround for it. If it gets fixed in -STABLE, is it possible > >> to selectively cherry-pick this somehow, or would I need to switch to > >> -STABLE wholesale? Is there an expected date for 10.1 to be released? > > It is easy to cherry-pick. Either use svn to merge changelist 260553 to > your local source tree, or download the following as a patch, and apply > it manually: > > http://svnweb.freebsd.org/base/head/lib/libcxxrt/Version.map?view=patch&r1=260553&r2=260552&pathrev=260553 > > Then do: > > cd /usr/src/lib/libcxxrt > make > sudo make install This worked just fine, thanks, so I can carry on porting the code. I guess I'll just have to wait until 10.1 is out before others can make proper use of it, but that's fine. One other toolchain related issue I have is that on powerpc, which isn't using clang yet, it's using GCC 4.2 which doesn't support C++11. Are there plans to have a common toolchain across all architectures (or at least, feature parity)? [This was an issue we had in Debian until a few weeks back; now it's GCC 4.8 for all.] While the newer clang and gcc versions are available in ports, in practice there are compatibility issues particularly if there's a mismatch between libstdc++/libc++. This makes it difficult to use clang 3.3/3.4 for example, since dependent C++ libraries were linked against libstdc++. Thanks all, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 18:38:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13F6B179; Sun, 9 Feb 2014 18:38:00 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8B1F1AF4; Sun, 9 Feb 2014 18:37:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::20a4:db0:4ac7:1cb7] (unknown [IPv6:2001:7b8:3a7:0:20a4:db0:4ac7:1cb7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3EE155C45; Sun, 9 Feb 2014 19:37:54 +0100 (CET) Subject: Re: Squid aufs crashes under 10.0 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E87A879D-D177-4169-A07F-9199A7700C54"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: Date: Sun, 9 Feb 2014 19:37:34 +0100 Message-Id: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> References: To: Pavel Timofeev X-Mailer: Apple Mail (2.1827) Cc: freebsd-stable stable , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 18:38:00 -0000 --Apple-Mail=_E87A879D-D177-4169-A07F-9199A7700C54 Content-Type: multipart/mixed; boundary="Apple-Mail=_DDD4A3DE-3493-4A20-94EF-80FE31FB5ED1" --Apple-Mail=_DDD4A3DE-3493-4A20-94EF-80FE31FB5ED1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 07 Feb 2014, at 14:24, Pavel Timofeev wrote: > Sorry, it has to be in freebsd-ports@ too. >=20 > 2014-02-07 Pavel Timofeev : >> Hi! >> There is a problem with squid under FreeBSD10.0. >> Squid crashes immediately if storage type is set to aufs. >> It goes down during read of config file. >>=20 >> No problem with diskd. No problem with aufs under FreeBSD9.2. >>=20 >> Someone thinks that it's related to clang which is default compiler = on >> FreeBSD 10.0. Nope, it is a bug in Squid's configure script. It recognizes FreeBSD 10.x and later as FreeBSD 1.x, causing it to disable pthreads support. This leads to the required DiskThreads module being disabled too. It then crashes when it tries to access a NULL pointer returned by DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc: Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) = : SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd = (-1), currentIOOptions(new ConfigOptionVector()), = ioType(xstrdup(anIOType)), cur_size(0), n_disk_objects(0) { /* modulename is only set to disk modules that are built, by = configure, * so the Find call should never return NULL here. */ IO =3D new = Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy()); } Very bad coding practice, obviously. It should call Find() first, and if that returns NULL, it should abort in some sort of controlled way. In any case, the cause is the following fragment in the configure script: freebsd) if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; = then { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library = requires FreeBSD 7 or later" >&5 $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;} squid_opt_use_diskthreads=3D"no" else which was edited here: http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124 I have attached a tentative patch for the port. However, this causes the configure script logic to run a little differently, and there is some sort of very strange bug in it, that leads to the SQUID_CFLAGS and SQUID_CXXFLAGS values being mangled in the default case. With my patch the DiskThreads detection runs again, but the variables are not mangled anymore, and this leads to -Werror being enabled again, causing errors about deprecated kerberos5 functions later on in the build. For now, I would not bother with -Werror and Squid, but just add --disable-strict-error-checking to CONFIGURE_ARGS in the Makefile. That is, until somebody with autoconf knowledge can fix the badly broken configure script... >> I recompiled www/squid33 with DEBUG option. Got coredump. >> Then I did and got this: >> gdb /usr/local/sbin/squid /var/squid/squid.core >> .... >> Reading symbols from /usr/lib/private/libheimipcc.so.11...done. >> Loaded symbols for /usr/lib/private/libheimipcc.so.11 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> Segmentation fault (core dumped) >>=20 >> Gdb goes down too =3D) >> Any ideas? Yes, please don't use gdb in base for anything serious. Use ports gdb instead. :-) -Dimitry --Apple-Mail=_DDD4A3DE-3493-4A20-94EF-80FE31FB5ED1 Content-Disposition: attachment; filename=www__squid33-fix-pthreads-detection-1.diff Content-Type: application/octet-stream; name="www__squid33-fix-pthreads-detection-1.diff" Content-Transfer-Encoding: 7bit Index: www/squid33/files/patch-configure =================================================================== --- www/squid33/files/patch-configure (revision 341653) +++ www/squid33/files/patch-configure (working copy) @@ -1,5 +1,14 @@ --- configure.orig 2013-03-12 11:18:22.000000000 +0100 +++ configure 2013-04-09 11:43:01.000000000 +0200 +@@ -19343,7 +19343,7 @@ + $as_echo "$as_me: Windows threads support automatically enabled" >&6;} + ;; + freebsd) +- if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then ++ if test `echo "$squid_host_os_version" | cut -d. -f1` -lt 7 ; then + { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library requires FreeBSD 7 or later" >&5 + $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;} + squid_opt_use_diskthreads="no" @@ -22798,7 +22798,7 @@ done --Apple-Mail=_DDD4A3DE-3493-4A20-94EF-80FE31FB5ED1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_DDD4A3DE-3493-4A20-94EF-80FE31FB5ED1-- --Apple-Mail=_E87A879D-D177-4169-A07F-9199A7700C54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlL3yvcACgkQsF6jCi4glqPApgCfSA6cbPdPF1BVRxfMW8goxd/O txAAoOelds0kVWuI/m3EAiukcfOUrLHu =Voe2 -----END PGP SIGNATURE----- --Apple-Mail=_E87A879D-D177-4169-A07F-9199A7700C54-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 19:17:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1D09BCF; Sun, 9 Feb 2014 19:17:09 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC2A1DD2; Sun, 9 Feb 2014 19:17:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s19JGxBS020172; Sun, 9 Feb 2014 11:16:59 -0800 (PST) (envelope-from freebsd@pki2.com) Subject: Re: Squid aufs crashes under 10.0 From: Dennis Glatting To: Dimitry Andric In-Reply-To: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 09 Feb 2014 11:16:59 -0800 Message-ID: <1391973419.88145.103.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s19JGxBS020172 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: Pavel Timofeev , freebsd-stable stable , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 19:17:09 -0000 On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote: > On 07 Feb 2014, at 14:24, Pavel Timofeev wrote: > > Sorry, it has to be in freebsd-ports@ too. > > > > 2014-02-07 Pavel Timofeev : > >> Hi! > >> There is a problem with squid under FreeBSD10.0. > >> Squid crashes immediately if storage type is set to aufs. > >> It goes down during read of config file. > >> > >> No problem with diskd. No problem with aufs under FreeBSD9.2. > >> > >> Someone thinks that it's related to clang which is default compiler on > >> FreeBSD 10.0. > > Nope, it is a bug in Squid's configure script. It recognizes FreeBSD > 10.x and later as FreeBSD 1.x, causing it to disable pthreads support. > This leads to the required DiskThreads module being disabled too. It > then crashes when it tries to access a NULL pointer returned by > DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc: > > Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) : SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd (-1), currentIOOptions(new ConfigOptionVector()), ioType(xstrdup(anIOType)), cur_size(0), n_disk_objects(0) > { > /* modulename is only set to disk modules that are built, by configure, > * so the Find call should never return NULL here. > */ > IO = new Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy()); > } > > Very bad coding practice, obviously. It should call Find() first, and > if that returns NULL, it should abort in some sort of controlled way. > Found that too but not the reason why: (lldb) run -d -z -F -f /root/squid.conf Process 23598 launched: './src/squid' (x86_64) Find(): Mmapped Find(): IpcIo Find(): DiskDaemon Find(): Blocking Find(): AIO Returning NULL There's a lot of faulty (i.e., a lack thereof) checking in Squid. For example, I replaced strlen() with a custom version that first checks for NULL and returns 0 if that is the case (strlen() was often called by std::cstring::c_str() that was not yet initialized). That small code fragment resolved a lot of SEGVs. > In any case, the cause is the following fragment in the configure > script: > > freebsd) > if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then > { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library requires FreeBSD 7 or later" >&5 > $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;} > squid_opt_use_diskthreads="no" > else > > which was edited here: > > http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124 > > I have attached a tentative patch for the port. However, this causes > the configure script logic to run a little differently, and there is > some sort of very strange bug in it, that leads to the SQUID_CFLAGS and > SQUID_CXXFLAGS values being mangled in the default case. > > With my patch the DiskThreads detection runs again, but the variables > are not mangled anymore, and this leads to -Werror being enabled again, > causing errors about deprecated kerberos5 functions later on in the > build. > > For now, I would not bother with -Werror and Squid, but just add > --disable-strict-error-checking to CONFIGURE_ARGS in the Makefile. > > That is, until somebody with autoconf knowledge can fix the badly broken > configure script... > > > >> I recompiled www/squid33 with DEBUG option. Got coredump. > >> Then I did and got this: > >> gdb /usr/local/sbin/squid /var/squid/squid.core > >> .... > >> Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > >> Loaded symbols for /usr/lib/private/libheimipcc.so.11 > >> Reading symbols from /libexec/ld-elf.so.1...done. > >> Loaded symbols for /libexec/ld-elf.so.1 > >> Segmentation fault (core dumped) > >> > >> Gdb goes down too =) > >> Any ideas? > > Yes, please don't use gdb in base for anything serious. Use ports gdb > instead. :-) > > -Dimitry From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 19:57:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95A5251B; Sun, 9 Feb 2014 19:57:18 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD7911A0; Sun, 9 Feb 2014 19:57:18 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::20a4:db0:4ac7:1cb7] (unknown [IPv6:2001:7b8:3a7:0:20a4:db0:4ac7:1cb7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 01F7F5C45; Sun, 9 Feb 2014 20:57:09 +0100 (CET) Subject: Re: Squid aufs crashes under 10.0 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3C69EC2F-0210-4093-9A87-17EC5854F226"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <1391973419.88145.103.camel@btw.pki2.com> Date: Sun, 9 Feb 2014 20:56:52 +0100 Message-Id: <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> To: Dennis Glatting X-Mailer: Apple Mail (2.1827) Cc: Pavel Timofeev , freebsd-stable stable , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 19:57:18 -0000 --Apple-Mail=_3C69EC2F-0210-4093-9A87-17EC5854F226 Content-Type: multipart/mixed; boundary="Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC" --Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 09 Feb 2014, at 20:16, Dennis Glatting wrote: > On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote: ... >> Very bad coding practice, obviously. It should call Find() first, and >> if that returns NULL, it should abort in some sort of controlled way. >> > > Found that too but not the reason why: > > (lldb) run -d -z -F -f /root/squid.conf > Process 23598 launched: './src/squid' (x86_64) > Find(): Mmapped > Find(): IpcIo > Find(): DiskDaemon > Find(): Blocking > Find(): AIO > Returning NULL > > There's a lot of faulty (i.e., a lack thereof) checking in Squid. For > example, I replaced strlen() with a custom version that first checks for > NULL and returns 0 if that is the case (strlen() was often called by > std::cstring::c_str() that was not yet initialized). That small code > fragment resolved a lot of SEGVs. There are a bunch of places where they use std::ostream::operator<< to output e.g. configuration strings to the debug stream, for example in uniqueHostname(), in src/tools.cc: const char * uniqueHostname(void) { debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'"); return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname(); } The problem case is when Config.uniqueHostname is NULL: this gets converted into a std::string first (which is _undefined behavior_), then it gets streamed to the debug stream. However, there is a difference between libstdc++ and libc++ here: the former silently accepts NULL arguments passed to the std::string constructor, creating a sort of "empty" string for you, which seems to work as normal. The latter just stores your NULL pointer, and if you actually try to do anything with it, the program will crash. To fix at least two places where this is done, drop the attached patches in www/squid33/files. -Dimitry --Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC Content-Disposition: attachment; filename=patch-src-acl-Acl.cc Content-Type: application/octet-stream; name="patch-src-acl-Acl.cc" Content-Transfer-Encoding: 7bit --- src/acl/Acl.cc.orig 2013-11-30 14:55:13.000000000 +0100 +++ src/acl/Acl.cc 2014-02-09 20:17:03.000000000 +0100 @@ -361,7 +361,7 @@ ACL::~ACL() { - debugs(28, 3, "ACL::~ACL: '" << cfgline << "'"); + debugs(28, 3, "ACL::~ACL: '" << (cfgline ? cfgline : "") << "'"); safe_free(cfgline); } --Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC Content-Disposition: attachment; filename=patch-src-tools.cc Content-Type: application/octet-stream; name="patch-src-tools.cc" Content-Transfer-Encoding: 7bit --- src/tools.cc.orig 2013-11-30 14:55:13.000000000 +0100 +++ src/tools.cc 2014-02-09 20:05:29.000000000 +0100 @@ -582,7 +582,7 @@ const char * uniqueHostname(void) { - debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'"); + debugs(21, 3, HERE << " Config: '" << (Config.uniqueHostname ? Config.uniqueHostname : "") << "'"); return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname(); } --Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_03EC8C9A-50D4-4325-AFB5-44939AB8EBDC-- --Apple-Mail=_3C69EC2F-0210-4093-9A87-17EC5854F226 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlL33YwACgkQsF6jCi4glqOy5gCfVe3+/0nVEa1mgzGlkKlMvHvS akkAoMKMROPX0EQTo0aFMt0gkQM2Jrsj =rnde -----END PGP SIGNATURE----- --Apple-Mail=_3C69EC2F-0210-4093-9A87-17EC5854F226-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 9 22:37:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D4B1F1B for ; Sun, 9 Feb 2014 22:37:21 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB66F1E3E for ; Sun, 9 Feb 2014 22:37:19 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WCczx-0006y0-UI for freebsd-stable@freebsd.org; Sun, 09 Feb 2014 22:37:14 +0000 Date: Sun, 9 Feb 2014 23:37:15 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Re: ZFS commits corruption to disk when kernel allocation fails Message-ID: <20140209233715.00002e70@unknown> In-Reply-To: <20140207095049.00003c7b@unknown> References: <20140201203112.0000210c@unknown> <20140202200446.000076c8@unknown> <20140207095049.00003c7b@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:37:21 -0000 On Fri, 7 Feb 2014 09:50:49 +0100 Matthew Rezny wrote: > On Sun, 2 Feb 2014 20:04:46 +0100 > Matthew Rezny wrote: > > > On Sat, 1 Feb 2014 20:31:12 +0100 > > Matthew Rezny wrote: > > > > > I'm seeing rather strange behavior from 10.0 on i386 thus far. > > > This is another long message, so if you want the summary without > > > back-story, skip to the end. Sometimes it's hard to include > > > relevant details without feeling like I'm rambling. I'm seeing > > > rather strange behavior from 10.0 on i386 thus far. > > > > > > I started with FreeBSD not long before 4.0 release and ran 4.x > > > releases on i386 and Alpha for a long time. I tried the 5.x > > > releases and had nothing but trouble so stuck with 4.x through > > > that time. The Alpha never did move off 4.x before it got > > > retired, but some of my i386 boxes made it onto 6.x and then sat > > > there until they were taken out of active use. For years, FreeBSD > > > 4.x and 6.x was the reliable OS I used for everything but my > > > desktop (which had been OS X). > > > > > > More recently I started using FreeBSD 8 on amd64 with ZFS and > > > quickly moved on to 9 as soon as 9.0 was released. At the same > > > time, i386 hardware retired from desktop roles but suitable for > > > network services got 8.x installed on UFS. I had rather good > > > experience with 9-STABLE on amd64 running with ZFS. For the most > > > part it's solid, ZFS support is much better than the sorry state > > > Apple left it in before abandoning it on OS X, though I did get a > > > few kernel panics when simply connecting disks that contained > > > zpools from OS X. Due to both compilation speed difference and the > > > fact older hardware tends to be in more entrenched roles, I left > > > my i386 systems out of the ZFS and 9.x experiments. I did also > > > try 9.x on my one ppc64 box at various times to see if that might > > > be a good way to utilize hardware Apple dropped support for years > > > prior. The state on ppc64 varied between panic on boot to being > > > able to buildworld but an idle system left for a few days would > > > randomly go zombie, console freezes but clearly there is some > > > system activity and it responds to ping but might not take a ssh > > > connection, which I chalked up to the experimental state of the > > > port. I did see console freezes on i386 boxes booted from a 9.1 > > > mfsbsd image but never investigated because I was just using it > > > to image and erase disks on old machines where I considered the > > > hardware suspect. > > > > > > In the last couple months I've been moving my amd64 systems to 10, > > > starting during the RCs and keeping up such that they are now all > > > 10-STABLE. The transition was fairly smooth and they are running > > > quite well. Even one box that has prior chipset and BIOS, which > > > was panicking with an early 10-BETA is now running 10.0-RELEASE > > > with KMS. All very impressive. So, time to start migrating some > > > i386 boxes I figure. I had recently moved a number of them to 9.2 > > > and figured I should just go ahead and move everything up to 10.0 > > > at close to the same time if possible. I had seen no problems > > > with 9.2 or 9-STABLE on the i386 boxes that I was preparing to > > > upgrade, I already sorted out one Clang bug that affected a few > > > (but less worse than a similar GCC bug that remains unfixed) > > > since I had switched compilers when going to 9. > > > > > > Since I started moving i386 boxes to 10.0, I've had nothing but > > > strange problems. Last night I wrote a message about > > > kern.maxswzone, something I started getting warnings about on one > > > particular box when I put 9.2 on it but which I didn't try to do > > > anything about until now. I wrote that message with this one in > > > mind, mentioning that I would have another about processes > > > hanging. That one came first because it has at least some hard > > > numbers and not so much subjective feelings of performance and > > > reliability. Between then and now, the pattern struck me, all my > > > early successes with 10 were amd64, and now all the i386 boxes > > > I've upgraded are barely functional. > > > > > > I have 4 i386 boxes that I tried to put 10.0 on in the past week > > > with various degrees of fail. There are 2 sets within the four, > > > two are the low-end C3 boxes with 256MB and 384MB RAM described > > > in my prior message to the list. The other two are Pentium4 > > > systems, one with 2GB RAM and the other with 3GB, substantially > > > bigger disks, decent GPU, etc. In other words, two are ancient > > > and two are merely a little dated but still very usable. This > > > faster pair I will mention first, then I will return to the slow > > > pair. All these boxes are things I use around the house for > > > network services or as essentially terminals in other rooms > > > (kitchen pc to look up stuff, bedroom pc to watch movies, etc). > > > The i386 boxes that run important services (externally facing > > > network services, routing/firewall, etc) and being left two a > > > second round once all issues are sorted out on these > > > lower-importance boxes first. > > > > > > The P4s had 9-STABLE installed on UFS volumes. I did the switch > > > from csup to svnup to pull the 10.0 sources, did the > > > buildworld/kernel and install on both and all looked good. Before > > > I went on to reinstall packages or anything else, I decided now > > > might be a good time to try switching from UFS to ZFS, everything > > > in /home was already backed up. So far I had only tried ZFS on > > > amd64 due to early reports of flakiness on i386 related to > > > exhausting kernel memory. In the couple years since initial > > > support, the ZFS code has gotten better integrated, more people > > > have tried it, some tuning guides have been written, and I've > > > seen reports of it being used on boxes with 512MB RAM. Most of my > > > i386 boxes in server roles have 2GB and it would be nice to > > > migrate those to ZFS if possible. Best to test on these boxes > > > first and try tuning if needed. > > > > > > I booted both P4 boxes from mfsbsd CD, mounted the existing UFS > > > volums, tar the whole mess and drop the uncompressed tar on my > > > file server. On the server, I fired off xz to compresses the tar > > > file to speed the restore (or so I thought) while I prepared the > > > machines. I setup the zpools in the normal way I'd done all my > > > amd64 boxes. One P4 box has a single disk, the other has two, so > > > one is a single vdev pool and the other is multiple, which adds a > > > little variety for testing. Aside from vdevs, the pool > > > properties, filesystems and their properties are all identical to > > > how I've been setting up my other ZFS boxes. LZ4 on most > > > filesystems, gzip or none on a few, sha256 hashes entirely, no > > > dedupe, pretty normal. With the pools configured and mounted > > > on /zroot, I scp the tar.xz file for each box into /tmp (which is > > > tmpfs), and try tar xjpvf in /zroot. > > > > > > After initial good progress, both boxes seemed to hang at about > > > the same time. Disk activity stops, tar is sitting there as if > > > it's going to do something, but no further progress on either > > > when left for an hour. I started top on both boxes and notice > > > that the tar process on each is in the state "kmem a" and the > > > resident memory allocation on each is exactly the same (around > > > 750MB). My first thought was that I used too much RAM with the > > > 500MB tar.xz file in tmpfs. One box says 800MB free and the other > > > says 1800MB free but maybe there is a shortage of kernel memory. > > > I can't seem to kill tar, so I just reboot each, clear the zpools > > > to try from a fresh state again, mount the swap before > > > filling /tmp this time, then attempt another extract. No joy, it > > > stops the same way, with the exact same memory allocation, and > > > each box is stopped on the exact same file as where each stopped > > > on the first attempt. The free memory reports are the same as > > > before, no sawp is being used, whatever is running out must be > > > non-pageable. > > > > > > The next thing I try is decoupling the stages. The tar process is > > > growing so large because it has to decompress lzma which requires > > > a huge dictionary. I figure maybe the heavy disk I/O is causing > > > buffers/cache to contend with the process in some way. Reboot > > > again for a fresh start, scp the .tar.xz to /zroot/tmp, xz -d so > > > it's just a plain tar, then tar xpvf in /zroot and both complete > > > without error. Set the mointpoint to / for each zroot and reboot > > > into the running system. That was strange but solvable. I don't > > > know what the "kmem a" state is but I can guess it's probably > > > short for something like "kmem alloc" which would suggest to me > > > the process is waiting on a kernel allocation. So I figure I've > > > got some tuning to do and a hung process isn't as bad as the > > > kernel panics others had reported on i386 under heavy I/O load > > > (e.g. rsync) with default settings. After all, the boot messages > > > include two warnings about tuning ZFS memory on i386. In order to > > > do the tuning, I need some reproducible load, and buildworld is > > > good for that. So, first thing is switch from svnup to svnlite > > > that is now in base and use that to get 10-STABLE sources. I do > > > the rm -r on /usr/src and /usr/ports and then fire off the > > > svnlite co for each. I find that the slowness of svn checkout is > > > due to network latency and running the two in parallel doesn't > > > create I/O contention on either disk or network. > > > > > > While the P4s are fetching their sources, I go to deal with the > > > pair of Via C3 boxes that I had taken to 10-PRERELEASE just a > > > week prior and was ready to upgrade to 10-STABLE. Since that > > > upgrade, they sat unused waiting for an impending MFC so I could > > > do away with a local patch. As mentioned in my other message, I > > > made a mistake here on my first attempt, I forgot to clear the > > > existing /usr/src and /usr/ports before starting the svnlite > > > checkout. After realizing my mistake, I did the now larger (as it > > > includes a .svn dir) rm -r of those dirs to start fresh. That's > > > when I hit the problem with rm hanging on one box. Without > > > repeating all the details, I had to boot mfsbsd to do the rm on > > > the one box with only 256MB RAM, but what difference that made is > > > simply inexplicable. Once I had gotten that straightened out, I > > > started off the svnlite checkout fresh. On the box with 384MB, > > > the completed with only one restart for network dropout (common > > > since it takes 2-3 hours per checkout). On the box with 256MB > > > (which had previously fully checked out and gotten to the point > > > where it wanted to prompt me for the conflict on every file in > > > the tree), svnlite could only do a hundred files or so before it > > > seemed to hang in the same way as rm. Running just one instance > > > on /usr/src without the parallel checkout on /usr/ports made no > > > difference. When rm was hanging, I might be able to kill it > > > (after several minutes wait) and reboot or the console might > > > lock. When svnlite hung, I could not login but I might be able to > > > run a command on another VT. I was able to catch that svnlite is > > > getting stuck in the state "kmem a". Hmmm... the same state that > > > tar was getting stuck in on the other boxes. How were those doing > > > now? > > > > > > I look back at the P4s, which should be done as it's been a few > > > hours spent on the C3 boxes. They are sitting there in the middle > > > of checkout not making any visible progress. Ctrl-c doesn't work, > > > I can't switch VTs, even ctrl-alt-del seems to not work. Seems > > > like the consoles are hung in a way eerily similar to what I'd > > > seen from 9.x on non-amd64 platforms (both ppc64 and i386). I > > > attempted to initiate an ssh connection into each of the P4s and > > > then walked off for a minute for refreshment. When I came back, > > > expecting to find a login prompt or a timeout, I found the ssh > > > attempts timed out and the two boxes had rebooted. I don't know > > > if the ctrl-alt-del finally registered or if the incoming ssh > > > connection pushed them over the edge. I wasn't there to see and > > > the logs for both stop sometime before the hang. With both > > > rebooted, I do a svnlite cleanup in /usr/src and /usr/pots or > > > both, then fire off the svnlite co for each directory on both > > > boxes. > > > > > > While those were running, I started digging into the > > > kern.maxswzone tunable on the C3 box with less RAM. The box with > > > more RAM was able to do the rm, svn checkout of both src and > > > ports in parallel, and showed no obvious sign of trouble, though > > > I hadn't started a buildworld yet. The box with less RAM was > > > failing all over the place and the only obvious difference was > > > the warning about that tunable. After I wasted hours figuring out > > > the value is already sufficient but is apparently reduced after > > > it's set, so it can't be effectively turned up, only down, I > > > wrote my previous message to this list on that topic specifically > > > and then went to bed. > > > > > > This morning I got up and was already thinking about the > > > correlation, that 10 is a disaster on all my i386 boxes thus far. > > > The first thing I checked was the P4 boxes. Both completed the svn > > > checkout on both src and ports, good sign. However, the box with > > > 3GB RAM has the message "vm_thread_new: kstack allocation failed" > > > repeated about a dozen times, bad sign. First thing I do is try to > > > run top to see what the size of ARC is, free RAM, etc. "No more > > > processes." Uh Oh, that's no good at all, can't even run top. > > > Curiously, the box with less RAM, only 2GB, has no messages so I > > > try to start top on it to see what it's state is. Nothing happens > > > when I push return, the cursor is just sitting there after top. On > > > another VT, reboot gets the same response, none, cursor just sits. > > > I can't type but I can switch VTs and scroll, until I do > > > ctrl-alt-del, then every key press after that is a beep. Back on > > > the once that said no processes left for top, reboot gets the same > > > non-response. ctrl-alt-del doesn't beep, it just spits out the > > > ^[[3~ typical of a dead console. Ugh, not even a reset button to > > > punch on these P4 boxes. > > > > > > So, svnlite checkout is a real strain that can bring a system to > > > it's knees. I'm not sure if this should be regarded as horrible > > > inefficiency or as a means of checking the box before launching > > > into a buildworld (as if that wasn't enough strain to uncover most > > > problems). While 10.0 is good on amd64, it seems a disaster on > > > i386. Processes hang in this "kmem a" state it doesn't take much > > > more to get the box to livelock. I've only seen the "kmem a" > > > state a few times as most other times I can't inspect anything > > > before the box is locked too hard to do anything. In some cases > > > I'm not sure there's even a way to get the box shutdown clean as > > > the most trivial of things lock it up hard. It's not even > > > required to do anything. When I was experimenting with > > > kern.maxswzone last night I rebooted one box a few dozen times, > > > so if I didn't need to look at systcl output I just hit > > > ctrl-alt-del at the login prompt. Once the console died right > > > then, it had just booted and ctrl-alt-del was met with a beep and > > > then it's hung, have to punch reset. I'm guessing the console > > > dies as a result of total wedging of I/O systems following heavy > > > disk I/O. The cause is not just ZFS because the C3 boxes are UFS. > > > The problem is not just the excess swap on the smallest box > > > because I see the same sort of troubles on the box with the most > > > RAM. Some kernel resource seems to be exhausted regardless of how > > > much RAM or swap is present. > > > > > > I'm going to try buildworld on 3 of these to see what happens. For > > > the fourth, I still need to get sources onto the disk before I can > > > even attempt that. I'm not sure what to expect. It might be > > > instant miserable failure, or it might actually run a long time > > > since the I/O load is in bursts with lots of recovery time > > > between. It'll take a few hours to see if the P4s succeed. It'll > > > take two days to see a C3 succeed. Maybe by that time, someone > > > will get through all I've written and have some useful suggestion > > > for debugging. To me, it's rather hard to debug since I have > > > little hint where to start, when the problem manifests any > > > logging stops, and the box is in a state where it is essentially > > > unobservable without a JTAG to jump in and directly inspect the > > > state of it's world. > > > > Replying to self to give status update to anyone reading along. > > > > The pair of P4 boxes made it through buildworld/kernel after a few > > tries. On these boxes I have /usr/obj mounted on a tmpfs as that's > > how I've been setting up the other boxes with ZFS. Between the ZFS > > ARC filling with source, the tmpfs filling with binaries, and the > > actual compilation tasks there should be a good bit of memory > > pressure. > > > > The first build attempt was with -j10 on both boxes. As these are > > single core CPUs, -j4 would have probably been more appropriate for > > optimal speed. The build process on each failed after about an hour. > > The exact stopping point was not noted since the actual error is > > beyond reach of syscons history by the time the parallel build > > process exits. The two boxes appear to have stopped at different > > points. > > > > I restarted the make buildworld on each without any -j parameter and > > without rebooting. I didn't want to clear the state, if the overly > > parallel build caused anything to leak, I want to see that blow up > > the non-parallel build. The first run through on each failed at > > different points with one of the strangest compiler errors I've yet > > to see. The builds failed with a fatal error: unable to open file > > [something}.c (where something was rlogin.c on one and > > citrus_[forgotten].c on the other). On both boxes, the first thing > > I did was cat thefile.c and of course I see the source file as > > expected, so the compiler failing to open the source file is a > > transient error. > > > > Following those odd errors, I restarted the build on each box with > > exactly the same options and without rebooting to check > > reproducibility. On the second non-parallel build attempt, both > > boxes succeeded to build world and then proceeded on to the kernel > > build without issue. Whatever resource exhaustion had cleared > > itself. I checked the memory stats at that point. The box with 3GB > > RAM had no swap currently in use, but might have experienced > > swapping during the build. The box with 2GB RAM had 800MB swap > > used, which is reasonable given the /usr/obj tmpfs was holding > > 2.2GB. Interestingly, the box with more RAM was the first of the > > pair to fail out of the build both times. The installkernel and > > installworld went off without a hitch. I did get a warning about > > swapoff failing when dropping to single user on the box with only > > 2GB, which is expected given the tmpfs spill into swap. > > > > The situation with buildworld is not too bad. The spurious file open > > errors are troubling, but not as bad as a panic or hang. The problem > > is likely more specifically ZFS-triggered kernel memory pressure and > > not general memory pressure. The low memory use but higher disk I/O > > processes like tar and svn are more prone to trigger the problem. > > Even higher disk I/O might hit the point of panic as some others > > have reported with e.g. rsync on i386. Perhaps with some tuning, > > these boxes can be made to behave reasonably. The initial problems > > with tar seemed very troubling and I still don't have a good > > explanation for why the memory use of the decompress while untaring > > seemed to make such a difference. > > > > The situation with the C3 boxes is much worse. More details on those > > will be in the other thread since that is where I gave the initial > > details on those and got some reply. The most interesting bit from > > that pair of boxes is the possible spurious file open fail. Running > > svnlite through truss, I couldn't help but notice that it hung > > immediately following a failure to stat a file that was in fact > > present (fsck truncated it on the reboot after hang). Some VFS issue > > that therefore affects UFS and ZFS on i386? > > Continuing this discussion with myself. > > I found the cause of the file open errors during buildworld and the > cause is more troubling than the symptom. After getting ZFS tuned > (details below) I ran a scrub and found that there was a bad file > under /usr/src on both system. Different files on each, and on each it > was the exact same file that the compile had failed on. I know ZFS > will deny reads when it can't verify data integrity (which is > annoying for file recovery, but potential very bad when the > corruption is inside directory data). So it could have denied the > reads when the compiler opened the file, but then why could I read it > moments later with cat? Better question, why is there a corrupt file? > A bad sector, maybe, except ZFS doesn't report read or checksum > errors on the vdevs during the scrub. A bad sector on drives in two > boxes, not reporting SMART errors either? Unlikely. Bad sectors on > three drives (one box is a mirror zpool), all unreported, and two on > independent disks coinciding with the same file such that ZFS can't > heal the file data? Impossibly unlikely! The only possible > explanation is in-memory corruption of ZFS data that is then > committed to disk. The hang during svn checkout was likely the moment > ZFS lost it's marbles and wrote some junk to disk in the directory it > was working in. > > After the last message, I started on tuning ZFS on i386. I should > have started into the tuning effort sooner, but my vision was clouded > by the similarity to the problem I had just hit on the C3 boxes which > have UFS filesystems. Also, most reports I saw of ZFS failing on i386 > had manifested as panics whereas I was seeing livelock with failed > kernel allocations. Once I started tuning the P4 boxes with ZFS, it > became clear the kmem_size adjustment would also be the solution for > the troubled box running UFS. > > First thing was vm.kmem_size as that is both first in the tuning guide > (in conjunction with KVA_PAGES) and was mentioned in the warning from > the kernel. It was a little under 400MB by default. I turned it up to > 512MB, the claimed max without adjusting KVA_PAGES. That was enough to > do fresh svn checkout, to tar and untar the entire /usr/src and > /usr/ports in a temp dir, xz compress it, untar with -j, rebuild > the world a few times, etc all without any hangs or reboots to reset > state. I tried with tmpfs full enough to spill to disk to duplicate > the mfsbsd case and still no trouble. So it seemed that setting > vm.kmem_size to 512MB is the magic. Considering that is so important a > value to the extent it can be difficult to even get installed onto a > zpool without setting it, I wonder why the kernel only warns about it > but doesn't just set it to the appropriate size. If it knows to warn > it knows enough to set it. > > Unfortunately, 512MB is not enough and the repercussions of > overrunning can be far worse. I continued through the ZFS tuning > guide, increased ARC a bit to 320MB while leaving more room between > arc_max and kmem_size than there was by default (192MB gap vs 150MB), > enabled prefetch, set vdev cache size to 5MB, etc. With all the > suggested tuning, I ran through everything again and all seemed ok. > > Content the problem was resolved, I went on to ports installs. Both > built Xorg and I quickly tested it. On the box with 2GB RAM I built > XBMC, tested it, and called that one done for the moment. On the box > with 3GB RAM I started compiling KDE4 yesterday. I expected it to > finish today and would have declared this matter resolved if it had. > Unfortunately, it didn't finish, but died about 580 ports into a set > of over 650. The place where it died was installing lapack, which > would be a burst of disk I/O. The symptoms were all the same, hung > process, can't start any new processes, can't login on another > console, can't run top on already logged in console, can't reboot > clean. The real surprise was on reboot, immediately after "Trying to > mount root from zfs:zroot []..." I get a double fault. Tried booting > twice, same fault both times. > > Fatal double fault: > eip = 0xc1618ec7 > esp = 0xe96b4f80 > ebp = 0xe96b52e0 > cpuid = 0; apic id = 00 > panic: double fault > cpuid = 0 > KDB: stack backtrace: > #0 0xc0a1cdbf at kdb_backtrace+0x52 > #1 0xc09ef0db at panic+0x121 > #2 0xc0e526bb at cpu_fetch_syscall_args+0 > Uptime: 10s > > That doesn't tell me much specifically. Generally, I know the zpool > must be severely borked to cause that on attempt to import the > pool/mount root. It was bad enough to see that ZFS could manage to > write corrupt data to disk that damages a file. At least that was > easy to fix with an svn revert followed by another svn up and another > scrub to be sure. This time it looked fatal. Fortunately, I was able > to boot a mfsbsd CD and import the pool without panic. Scrub showed > zero errors of any type and the following attempt to boot off the > pool succeeded. The error must have been minor enough to fix without > note on import or scrub, but is severe enough to make the pool > unbootable. > > Why don't we default to higher vm.kmem_size, at least when using ZFS > if not always? (It is undersize with UFS on low memory boxes too) Is > there a benefit to not letting the kernel use all the RAM on i386 as > it's allowed to do on amd64? Why does KVA_PAGES, which gives 1GB > kernel address space by default, need to be increased in order to > increase vm.kmem_size beyond 512M? Is there something other than the > kernel allocating inside the kernel's address space? Is there some > reason to not let the kernel grow to the limit of it's address space > or physical RAM, whichever is less, when it feels a need to? Unfortunately, this problem is easily reproducible, After fixing the pool and booting the system off it, I resumed the portmaster run. It got through lapack (starting off clean) but soon hung exactly the same way after installing py27-numpy. On reboot it panics almost exactly the same (backtrace is identical, register values differ by only a few bytes). So, large ports that strain the system harder than building world are able to knock this box over. Each time that happens, the pool is unbootable until I scrub it after booting mfsBSD. Obviously I've still got some tuning to do to stop it from crashing. It's rather disturbing that each time the system hangs the pool is left in a rather bad state. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 03:30:49 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60C6B926; Mon, 10 Feb 2014 03:30:49 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9630318B9; Mon, 10 Feb 2014 03:30:48 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s1A3Ubr0017885; Mon, 10 Feb 2014 05:30:37 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s1A3UaBN017750; Mon, 10 Feb 2014 03:30:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 10 Feb 2014 03:30:37 GMT Message-Id: <201402100330.s1A3UaBN017750@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 03:30:49 -0000 TB --- 2014-02-10 01:40:31 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-10 01:40:31 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-10 01:40:31 - starting RELENG_10 tinderbox run for powerpc64/powerpc TB --- 2014-02-10 01:40:31 - cleaning the object tree TB --- 2014-02-10 01:40:31 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-10 01:41:25 - At svn revision 261702 TB --- 2014-02-10 01:41:26 - building world TB --- 2014-02-10 01:41:26 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 01:41:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 01:41:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 01:41:26 - SRCCONF=/dev/null TB --- 2014-02-10 01:41:26 - TARGET=powerpc TB --- 2014-02-10 01:41:26 - TARGET_ARCH=powerpc64 TB --- 2014-02-10 01:41:26 - TZ=UTC TB --- 2014-02-10 01:41:26 - __MAKE_CONF=/dev/null TB --- 2014-02-10 01:41:26 - cd /src TB --- 2014-02-10 01:41:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 10 01:41:37 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/PointerSubChecker.cpp -o PointerSubChecker.o c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp -o PthreadLockChecker.o c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp -o RetainCountChecker.o /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp: In member function 'void::RetainCountChecker::processObjCLiterals(clang::ento::CheckerContext&, const clang::Expr*) const': /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp:2714: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/clang/libclangstaticanalyzercheckers *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-10 03:30:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-10 03:30:35 - ERROR: failed to build world TB --- 2014-02-10 03:30:35 - 5102.36 user 1626.49 system 6603.95 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 03:44:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C03A8CB5 for ; Mon, 10 Feb 2014 03:44:08 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 786A61A1E for ; Mon, 10 Feb 2014 03:44:08 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1A3hq4D000157 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 9 Feb 2014 21:43:52 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F84AF8.8050007@tundraware.com> Date: Sun, 09 Feb 2014 21:43:52 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: And Here I Thought buildworld/makeworld Was IO Bound 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Sun, 09 Feb 2014 21:43:52 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1A3hq4D000157 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 03:44:08 -0000 For some years now, I have been doing nightly builds of -STABLE on an old Pentium D machine with 2G of memory. Buildworld + 2 different kernels was taking in the neighborhood of 3 1/2 hours or so to run. I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure enough, the build time for all the above came down to 30-35 mins or so. "So", says I, "I'll bet a faster drive would help considering all the scribbling to the disk the compilers and makes do". So, I upgdared to a Kingston SSD Now 300, 120G hard drive and he time to do the above went down to .... wait, it's still about 30-35 mins ???? So, I've tried fiddling with different values for -j on the make command line to little avail. Well, -j8 and -j16 show no real difference here. So is the bounding function here actually CPU not IO? Am I missing something? Thanks, P.S. Trying now with no -j arg on make invocation. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 03:45:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1F65DAF; Mon, 10 Feb 2014 03:45:03 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C375C1A31; Mon, 10 Feb 2014 03:45:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1A3iuEb020701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Feb 2014 19:44:57 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1A3itJk020700; Sun, 9 Feb 2014 19:44:55 -0800 (PST) (envelope-from jmg) Date: Sun, 9 Feb 2014 19:44:55 -0800 From: John-Mark Gurney To: kpneal@pobox.com Subject: Re: where to find FreeBSD torrent file Message-ID: <20140210034455.GS89104@funkthat.com> Mail-Followup-To: kpneal@pobox.com, "illoai@gmail.com" , gjb@freebsd.org, freebsd-stable@freebsd.org, "freebsd-questions@freebsd.org" , Shankar , lists@eitanadler.com References: <1391945788.29258.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20140210023754.GC99503@neutralgood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140210023754.GC99503@neutralgood.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 09 Feb 2014 19:44:57 -0800 (PST) Cc: freebsd-stable@freebsd.org, Shankar , lists@eitanadler.com, gjb@freebsd.org, "illoai@gmail.com" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 03:45:04 -0000 kpneal@pobox.com wrote this message on Sun, Feb 09, 2014 at 21:37 -0500: > This means we need two thiings: > 1) A no-frills tracker with > 2) verified copies of the old torrents > > Can we safely use whatever tracker NetBSD is using? Why don't we set up trackerless torrents? I've been meaning to do that, but the last time I tried to seed a trackerless torrent, the other person never was able to d/l it, and I haven't tried again.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 04:41:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13CD4D31; Mon, 10 Feb 2014 04:41:44 +0000 (UTC) Received: from out.packetderm.com (out.packetderm.com [66.203.85.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C35D71FA3; Mon, 10 Feb 2014 04:41:43 +0000 (UTC) Received: from localhost (localhost[127.0.0.1]) (authenticated bits=0) by smtp (5.7.4/5.7.4) with ESMTP id s1A4fTd7060620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Feb 2014 23:41:31 -0500 (EST) (envelope-from miker@cotse.net) From: Michael Ray To: John-Mark Gurney Subject: Re: where to find FreeBSD torrent file Date: Sun, 09 Feb 2014 22:41:30 -0600 Message-ID: References: <1391945788.29258.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20140210023754.GC99503@neutralgood.org> <20140210034455.GS89104@funkthat.com> In-Reply-To: <20140210034455.GS89104@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Shankar , gjb@freebsd.org, kpneal@pobox.com, lists@eitanadler.com, "illoai@gmail.com" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: miker@cotse.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 04:41:44 -0000 On Sun, 9 Feb 2014 19:44:55 -0800, you wrote: >kpneal@pobox.com wrote this message on Sun, Feb 09, 2014 at 21:37 -0500: >> This means we need two thiings: >> 1) A no-frills tracker with >> 2) verified copies of the old torrents >>=20 >> Can we safely use whatever tracker NetBSD is using? > >Why don't we set up trackerless torrents? I've been meaning to do that, >but the last time I tried to seed a trackerless torrent, the other >person never was able to d/l it, and I haven't tried again.. btdigg is a trackerless torrent search engine=20 https://btdigg.org/search?info_hash=3D&q=3Dfreebsd+10 I've been seeding FreeBSD images for a while as are many others. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 05:45:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 996CC927 for ; Mon, 10 Feb 2014 05:45:19 +0000 (UTC) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AE4F15AB for ; Mon, 10 Feb 2014 05:45:19 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h14so2717404eaj.35 for ; Sun, 09 Feb 2014 21:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lDz7cEv2gWeS7qkVzEGQGjXwC4gql7u/P2xVfIKiiXs=; b=ytJwlsEYfd+AUNOkahVtuw9mZINQIXrjfHcbm2HChB58DiuDOAcn2Drv8yLQV7eNvu 1frasK7VRhaqh9DQC1SBKyZklPUCUylYSyHRO30lKQjF12t8pWUqO4Wobv8dW5i7W1fm P/oEsUSyxdMFShUDTdifTGjiUhSpln+7TD17tGlDF2KHDmMKQn/vfzqfXXic/FaZB6DS 659sTVRQq8Fd6wiJAu8sbxj8ssT9HLqEtY6upxMNim8KGciIYGJvf3I2NJMDt4ZbjVim 2ga9SsXYqbdZNvgm0JCu02KrAvvnXLrtqCq7AYTsexGqgQbMt9iaVl3JzRYfQzYbD4FF gzWg== X-Received: by 10.15.44.202 with SMTP id z50mr86251eev.81.1392011117402; Sun, 09 Feb 2014 21:45:17 -0800 (PST) Received: from macbook-pro.local (ip-178-200-30-115.unitymediagroup.de. [178.200.30.115]) by mx.google.com with ESMTPSA id q44sm15221193eez.1.2014.02.09.21.45.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 21:45:16 -0800 (PST) Message-ID: <52F86768.9000109@googlemail.com> Date: Mon, 10 Feb 2014 06:45:12 +0100 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tim Daneliuk , freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> In-Reply-To: <52F84AF8.8050007@tundraware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 05:45:19 -0000 Am 10/02/14 04:43, schrieb Tim Daneliuk: > For some years now, I have been doing nightly builds of -STABLE > on an old Pentium D machine with 2G of memory. Buildworld + 2 > different kernels was taking in the neighborhood of 3 1/2 hours or so > to run. > > I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure > enough, the build time for all the above came down to 30-35 mins or so. > > "So", says I, "I'll bet a faster drive would help considering all the > scribbling to the disk the compilers and makes do". So, I upgdared to > a Kingston SSD Now 300, 120G hard drive and he time to do the above > went down to .... wait, it's still about 30-35 mins ???? > > So, I've tried fiddling with different values for -j on the make > command line to little avail. Well, -j8 and -j16 show no real > difference here. > > So is the bounding function here actually CPU not IO? Am I missing > something? > > Thanks, > > P.S. Trying now with no -j arg on make invocation. Hi, the new machine has a lot more memory, I assume. The build probably will not even hit the disk due to caching. Also remember, the build process spawns probably millions of processes and that alone takes some time. And 30min sounds pretty great to me :D Best regards From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 07:15:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4942CE13; Mon, 10 Feb 2014 07:15:46 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D35271BD0; Mon, 10 Feb 2014 07:15:45 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id ie18so4538305vcb.12 for ; Sun, 09 Feb 2014 23:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qIZZI231tKdzlaEzzDjBkS1aYnbQGD/4YdQGZVrcJ+0=; b=cV/FKBAom3cfXlQR/m9OBnoCcj2UMdY57i94LTZafcUCS61PyyAAHxOYa6x4/7Y9Zs YII4l9sEesmqsWU4uQT1SUgtBlOlKy32aghRGbNlEyOJHj/lZSP0NwzE0Y/0mJc5VOu3 GhXg7asKAgr0RLz2SUX0XIar8DOvJ18dbd3e4vAyRpOEFFmH+naDrQ56+37IvdRlqjzT kNhNr/Mt6OUMLgAURm6dXOlB/hp17QTyywN0MJynoiL8vnuy7D6t3NFktEkngOHDgpRt N06KH7xV1w5RuScqjCawgn8c0IMUwoC6LC6nHjUVbnGWdCusp32SPRhPsxFhmDF77WDe Bj8Q== MIME-Version: 1.0 X-Received: by 10.58.235.129 with SMTP id um1mr23172461vec.17.1392016544035; Sun, 09 Feb 2014 23:15:44 -0800 (PST) Received: by 10.52.171.80 with HTTP; Sun, 9 Feb 2014 23:15:43 -0800 (PST) In-Reply-To: <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> Date: Mon, 10 Feb 2014 11:15:43 +0400 Message-ID: Subject: Re: Squid aufs crashes under 10.0 From: Pavel Timofeev To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable stable , Dennis Glatting , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 07:15:46 -0000 So what should I do? Write a PR to squid's bugzilla with link to this thread? Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't look at PRs about squid). And it seems like this problem is retaled to all of squid ports, not only to www/squid33. 2014-02-09 23:56 GMT+04:00 Dimitry Andric : > On 09 Feb 2014, at 20:16, Dennis Glatting wrote: >> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote: > ... >>> Very bad coding practice, obviously. It should call Find() first, and >>> if that returns NULL, it should abort in some sort of controlled way. >>> >> >> Found that too but not the reason why: >> >> (lldb) run -d -z -F -f /root/squid.conf >> Process 23598 launched: './src/squid' (x86_64) >> Find(): Mmapped >> Find(): IpcIo >> Find(): DiskDaemon >> Find(): Blocking >> Find(): AIO >> Returning NULL >> >> There's a lot of faulty (i.e., a lack thereof) checking in Squid. For >> example, I replaced strlen() with a custom version that first checks for >> NULL and returns 0 if that is the case (strlen() was often called by >> std::cstring::c_str() that was not yet initialized). That small code >> fragment resolved a lot of SEGVs. > > There are a bunch of places where they use std::ostream::operator<< to > output e.g. configuration strings to the debug stream, for example in > uniqueHostname(), in src/tools.cc: > > const char * > uniqueHostname(void) > { > debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'"); > return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname(); > } > > The problem case is when Config.uniqueHostname is NULL: this gets > converted into a std::string first (which is _undefined behavior_), then > it gets streamed to the debug stream. > > However, there is a difference between libstdc++ and libc++ here: the > former silently accepts NULL arguments passed to the std::string > constructor, creating a sort of "empty" string for you, which seems to > work as normal. The latter just stores your NULL pointer, and if you > actually try to do anything with it, the program will crash. > > To fix at least two places where this is done, drop the attached patches > in www/squid33/files. > > -Dimitry > > > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 07:57:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05048FB8; Mon, 10 Feb 2014 07:57:02 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B028C1FC0; Mon, 10 Feb 2014 07:57:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::20a4:db0:4ac7:1cb7] (unknown [IPv6:2001:7b8:3a7:0:20a4:db0:4ac7:1cb7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AFD355C45; Mon, 10 Feb 2014 08:56:53 +0100 (CET) Subject: Re: 10.0 toolchain broken for C++11 code Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F4E14D7C-1B8B-4E66-AAAA-E32D335F3FAA"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <20140209132909.GH11464@codelibre.net> Date: Mon, 10 Feb 2014 08:56:37 +0100 Message-Id: <170A5F41-3BB1-4297-B36A-E78B0D769F60@FreeBSD.org> References: <20140208233255.GA6282@amys.codelibre.net> <52F6C7D9.20501@ohlste.in> <20140209132909.GH11464@codelibre.net> To: Roger Leigh X-Mailer: Apple Mail (2.1827) Cc: freebsd-stable stable , Roman Divacky , David Chisnall X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 07:57:02 -0000 --Apple-Mail=_F4E14D7C-1B8B-4E66-AAAA-E32D335F3FAA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 09 Feb 2014, at 14:29, Roger Leigh wrote: ... > One other toolchain related issue I have is that on powerpc, which isn't > using clang yet, it's using GCC 4.2 which doesn't support C++11. Are there > plans to have a common toolchain across all architectures (or at least, > feature parity)? Across all architectures is unlikely, since we still carry at least one (e.g. ia64) that has no support in clang at all, and even newer versions of gcc dropped support for it. However, that architecture is 'Tier-2', which means it is only supported on a best-effort basis. That said, some people are working on full powerpc support for clang (and I am assuming that means both the 32 bit and 64 bit variants), mips is also being worked on, though I have no idea if it is production-ready at all, and there are even some people working on the sparc64 backend. So if everything goes as I hope it does, we might have support for most of our architectures with clang 3.5. Note that even though I am the de facto clang maintainer, I have no problems with adding support for building our base system with newer (external) gcc-based toolchains. In fact, I would rather see that sooner than later, because we could then drop the old gcc 4.2 from our contrib area entirely. :-) > [This was an issue we had in Debian until a few weeks back; > now it's GCC 4.8 for all.] While the newer clang and gcc versions are > available in ports, in practice there are compatibility issues particularly > if there's a mismatch between libstdc++/libc++. This makes it difficult to > use clang 3.3/3.4 for example, since dependent C++ libraries were linked > against libstdc++. As far as I know, the ports guys are working on this, by using a ports-specific version of libc++ to provide C++11 support. This way you can compile C++-based ports that really require gcc (for whatever reason) without mixing libstd++ and libc++, which will almost always lead to trouble. -Dimitry --Apple-Mail=_F4E14D7C-1B8B-4E66-AAAA-E32D335F3FAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlL4hkEACgkQsF6jCi4glqNpHgCeMu8qfZqhJ4rKSECZThz09pgI dBYAmwYcA4AVNETErhz1aQE652i9ce5F =cIUa -----END PGP SIGNATURE----- --Apple-Mail=_F4E14D7C-1B8B-4E66-AAAA-E32D335F3FAA-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 08:50:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77F98BB5 for ; Mon, 10 Feb 2014 08:50:58 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2E413CF for ; Mon, 10 Feb 2014 08:50:58 +0000 (UTC) Received: from blazon-pc.rw.local ([78.84.244.14]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MH0Nw-1W09Fo3KnS-00Dqev for ; Mon, 10 Feb 2014 09:50:51 +0100 Message-ID: <52F892EA.80902@mail.com> Date: Mon, 10 Feb 2014 10:50:50 +0200 From: Jeff Tipton User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121030 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: regression: msk0 watchdog timeout and interrupt storm References: <52E6CB2B.9040208@mail.com> <52E911E8.2090104@mail.com> <20140207051340.GC1369@michelle.cdnetworks.com> <52F56B1A.3020904@mail.com> <52F60B9F.8010807@mail.com> In-Reply-To: <52F60B9F.8010807@mail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ir4w5aOOGTnPuQjC1afhbmtluKvI3G1qtiFpqZPhrSUzxLkykOv JIvsUB0DNs+eqiOnhGVPkd3a9qb8rli3K3uVFQDup1ecSxWVXz65I5B2AIOM6cEWOxIa91o M4QDM2758jEl+oaMEuuqICG3gT3+EfEzw1ZjFDhd9MF5wmzuIdOYJfn8KTmRHO3zKS8LeAc bAlsJzIqb0uPZuGNclrHw== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:50:58 -0000 On 02/08/2014 12:49, Jeff Tipton wrote: > The buildworld is in the process for 13 hours now, but I begin to > doubt whether my checkout results are correct. Instead of > > svn checkout -r261577 https://svn0.eu.FreeBSD.org/base/releng/10.0 > /usr/src > > I did > > svn checkout -r261577 https://svn0.eu.FreeBSD.org/base/head /usr/src > > However, the checkout ended with "Checked out revision 261577" > message. Do you think this is ok? I would cleanse the src and obj > directories if it did not mean so many hours of compiling. > > On 02/08/2014 01:24, Jeff Tipton wrote: >> >> On 02/07/2014 07:13, Yonghyeon PYUN wrote: >>> On Wed, Jan 29, 2014 at 04:36:24PM +0200, Jeff Tipton wrote: >>>> On 01/27/2014 23:10, Jeff Tipton wrote: >>>>> Hi, >>>>> >>>>> I also have this problem on Samsung N220 netbook, except I don't have >>>>> any "interrupt storm" messages. When it boots up, it works a >>>>> couple of >>>>> minutes, and then "msk0: watchdog timeout" message appears. And, yes, >>>>> the fastest way to reproduce the error is to try to copy a file via >>>>> scp (even a 6MB file is enough). >>>>> >>>>> uname -a >>>>> >>>>> FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>>>> 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC >>>>> amd64 >>>>> >>>>> pciconf -lcv >>>>> [..] >>>>> >>>>> mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab >>>>> rev=0x00 hdr=0x00 >>>>> vendor = 'Marvell Technology Group Ltd.' >>>>> device = '88E8040 PCI-E Fast Ethernet Controller' >>>>> class = network >>>>> subclass = ethernet >>>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 >>>>> message >>>>> cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link >>>>> x1(x1) >>>>> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) >>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>>> ecap 0003[130] = Serial 1 f0d173ffff542400 >>>>> >>>>> I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just >>>>> fine there. >>>>> >>>>> I also tried to change if_mskreg.h as Curtis suggested, recompiled >>>>> the >>>>> kernel but it didn't help; nothing changed :( >>>>> >>>>> Jeff >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to >>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>> And, yes, I also found out that after having been booted into 10.0, >>>> if I >>>> immediately reboot into 9.2, msk0 doesn't work there either; no >>>> "watchdof timeout" messages, though; but ifconfig shows "no carrier"; >>>> restarting interface or netif service doesn't help. I had to switch >>>> the >>>> netbook off completely and take the battery out for some minutes, and >>>> only then it finally worked in 9.2 again. >>> Jeff, please try r261577 and let me know how it works. >>> As you said, cold-boot is recommended way to test r261577. >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> Ok, I'm working on but it will take some time. Meanwhile I can tell >> that I experimented with PC-BSD 10, and that worked without any flaw. >> I don't know how it relates here but their revision was: >> >> 10.0-RELEASE-p5 FreeBSD 10.0-RELEASE-p5 #8 b261212(releng/10.0): Fri >> Jan 24 11:21:56 EST 2014 >> root@avenger:/usr/obj/root/pcbsd-build10.0/git/freebsd/sys/GENERIC amd64 >> >> Then an update reverted it back to p4 which also worked ok. >> >> -Jeff >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Ok, I completed building both kernel and userland but, as I already said, probably not a pure r261577: FreeBSD 11.0-CURRENT #0 r261577: Sun Feb 9 19:12:18 EET 2014 [..] /usr/obj/usr/src/sys/GENERIC amd64 But it works. It's up for 43 minutes already, I copied 700MB of files to and from it, and no "watchdog timeout" messages so far. -Jeff From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 11:13:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D70C3B92 for ; Mon, 10 Feb 2014 11:13:07 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A62B1212 for ; Mon, 10 Feb 2014 11:13:07 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id y1so4551249lam.22 for ; Mon, 10 Feb 2014 03:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4FpM5bW/exQozOCi4a8MqNiBmVJAcv0HBobEfp5dS2k=; b=MPh9f5+u1z+dasbCvjaF8yU/gt/CNBjXJUsdJ4P7IAtf5j/LPiS5BtCjm6lKH9TOOZ 2Qojp19ar7TUum0UZKoRu9aEMd2qZADA7XUakBMMsuqOYmVlf02eeTzKLatC3x5KiQ+h wOWFdfAhTqzYXvaC/H2fc/xdbXSZoH1fRxACl3v8u5co2cKZsGw1uJOt379dgrcI22og dhgkqjK4cS/97JomV+2oIsdt9/fC2sZeZa5l555JRIduD1jJ+HqgQuqYu8qryK16ej2Q By9TbDmGXe+MCGtvP9Qst2s3kQWLiHDRzxRgF2HCruP6FoXs37I7huwRIlwZqkH4tzB8 PFKA== X-Received: by 10.152.209.7 with SMTP id mi7mr1204374lac.42.1392030785365; Mon, 10 Feb 2014 03:13:05 -0800 (PST) Received: from [192.168.1.129] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id v5sm21803975laj.0.2014.02.10.03.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 03:13:04 -0800 (PST) Message-ID: <52F8B42B.70006@gmail.com> Date: Mon, 10 Feb 2014 13:12:43 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Pavel Timofeev , freebsd-stable stable Subject: Re: Squid aufs crashes under 10.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:13:07 -0000 07.02.2014 15:17, Pavel Timofeev wrote: > Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > ..... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas? Well... I'd just like to share some thoughts and facts: * aufs is not asynchronous anymore, it uses threads now; * diskd is highly experimental, broken and I suppose noone would fix it as it all comes down to incorrect prerequisites when planning this datastore internals; * rock is not working. Besides that ufs is still stable and usable. And fast. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 11:15:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 149FBDDC for ; Mon, 10 Feb 2014 11:15:26 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C41E6123C for ; Mon, 10 Feb 2014 11:15:25 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WCope-0001nZ-Cj for freebsd-stable@freebsd.org; Mon, 10 Feb 2014 12:15:22 +0100 Received: from jtotz2.cs.ucl.ac.uk ([128.16.6.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Feb 2014 12:15:22 +0100 Received: from johannes by jtotz2.cs.ucl.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Feb 2014 12:15:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Subject: Re: where to find FreeBSD torrent file Date: Mon, 10 Feb 2014 11:15:16 +0000 Lines: 43 Message-ID: References: <1391945788.29258.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20140210023754.GC99503@neutralgood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: jtotz2.cs.ucl.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <20140210023754.GC99503@neutralgood.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:15:26 -0000 On 10/02/2014 02:37, kpneal@pobox.com wrote: > On Sun, Feb 09, 2014 at 01:39:08PM -0500, illoai@gmail.com wrote: >> On 9 February 2014 06:36, Shankar wrote: >>> I am trying to download FreeBSD 10 but I can only find the iso link. Where can I find a torrent file? Torrents will be faster for me and it will also reduce bandwidth demands on your servers. >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >> >> After a bit of searching, Linuxtracker seems to have FreeBSD 10 torrents: >> http://linuxtracker.org/index.php?page=torrent-details&id=27d4121e14d66f9068a602aa888148b5b0e4e7f1 >> http://linuxtracker.org/index.php?page=torrent-details&id=7a947685620bff41bbc89f9cc1c0b194c773b1f2 > > Are these the same torrents seen on Slashdot? > > Folks, It is increasingly clear that FreeBSD _must_ support bittorrent. > > I can't see how anyone would think that having people get FreeBSD from > random unofficial untrusted non-FreeBSD.org places online is at all a good > idea. FreeBSD needs to bring back a basic torrent tracker that recognizes > the last set of official torrents issued by FreeBSD plus new torrents for > the subsequent releases. > > If we do this then people will be getting reliable copies of FreeBSD but > will at the same time be using torrents. > > This means we need two thiings: > 1) A no-frills tracker with > 2) verified copies of the old torrents > > Can we safely use whatever tracker NetBSD is using? > > I realize this will take someone time. I also realize that time == money. > So, if someone officially FreeBSD can give me a cost estimate then I will > myself pay as much as I can towards getting this done. Really. Contact > me offlist to discuss, please. > > I'm CC'ing the people and list involved the last time this came up. I > apologize in advance for the double posting/crossposting. http://gotbsd.net/ has some older releases. But I would very much like to see an official tracker go online (again). From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 11:22:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7093D96 for ; Mon, 10 Feb 2014 11:22:17 +0000 (UTC) Received: from forward1h.mail.yandex.net (forward1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E65612E2 for ; Mon, 10 Feb 2014 11:22:17 +0000 (UTC) Received: from web17h.yandex.ru (web17h.yandex.ru [84.201.186.46]) by forward1h.mail.yandex.net (Yandex) with ESMTP id 8F3A29E10EC for ; Mon, 10 Feb 2014 15:22:04 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web17h.yandex.ru (Yandex) with ESMTP id E83BBDC071E; Mon, 10 Feb 2014 15:22:03 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bekreyev.ru; s=mail; t=1392031324; bh=EWT4+ETPkJD/7BhDgzjtUAmL4fjmDioEI1jDqp6BJ7Y=; h=From:To:In-Reply-To:References:Subject:Date; b=jNaaaiT5jp9Y5/DP1gnIiDheHBsqTcWk2UfBrbgbKIrvrBLQVct/gvVeiO3Vygqns DBPH/E8hIPDJbzLuKzVfFcbCVu0T+bZT9okor5CE5WLNi/Y4UNxfP/QcesydH7pvyq My8P9O/ctGQi3EXRqtTbnjRvEItxJ+wSlLEBA+Es= Received: from ip134.98.ulttk.ru (ip134.98.ulttk.ru [79.132.98.134]) by web17h.yandex.ru with HTTP; Mon, 10 Feb 2014 15:22:03 +0400 From: Konstantin V Bekreyev Envelope-From: konstantin@bekreyev.ru To: "freebsd-stable@freebsd.org" In-Reply-To: References: <1391945788.29258.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20140210023754.GC99503@neutralgood.org> Subject: Re: where to find FreeBSD torrent file MIME-Version: 1.0 Message-Id: <237331392031323@web17h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 10 Feb 2014 15:22:03 +0400 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:22:17 -0000 äÏÂÒÙÊ ÄÅÎØ 10.02.2014, 15:15, "Johannes Totz" : > But I would very much like to see an official tracker go online (again). I agree that it is necessary. But I think that we must use more complex system, like MirrorBrain: http://mirrorbrain.org/ This will greatly improve the distribution of FreeBSD. -- With best regards, Konstantin V Bekreyev (CVB-RIPE) Internet Society, Russia From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 14:57:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03DE1BF for ; Mon, 10 Feb 2014 14:57:13 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1EA31501 for ; Mon, 10 Feb 2014 14:57:12 +0000 (UTC) Received: from [10.219.131.92] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1AEuwSL058171 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 10 Feb 2014 08:56:59 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F8E8C6.2060909@tundraware.com> Date: Mon, 10 Feb 2014 08:57:10 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> In-Reply-To: <52F86768.9000109@googlemail.com> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 08:56:59 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1AEuwSL058171 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:57:13 -0000 On 02/09/2014 11:45 PM, army.of.root wrote: > Am 10/02/14 04:43, schrieb Tim Daneliuk: >> For some years now, I have been doing nightly builds of -STABLE >> on an old Pentium D machine with 2G of memory. Buildworld + 2 >> different kernels was taking in the neighborhood of 3 1/2 hours or so >> to run. >> >> I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure >> enough, the build time for all the above came down to 30-35 mins or so. >> >> "So", says I, "I'll bet a faster drive would help considering all the >> scribbling to the disk the compilers and makes do". So, I upgdared to >> a Kingston SSD Now 300, 120G hard drive and he time to do the above >> went down to .... wait, it's still about 30-35 mins ???? >> >> So, I've tried fiddling with different values for -j on the make >> command line to little avail. Well, -j8 and -j16 show no real >> difference here. >> >> So is the bounding function here actually CPU not IO? Am I missing >> something? >> >> Thanks, >> >> P.S. Trying now with no -j arg on make invocation. > > Hi, > > the new machine has a lot more memory, I assume. Yes, 8G as opposed to 2G. I suppose I could bump it out to 16G and see if this makes any material difference with even more cache space. > The build probably will not even hit the disk due to caching. Well ... it has to hit the disk sooner or later. But, if the frequency of physical writes is low because of aggregated IO from the cache, I guess that would tend to make the whole business more CPU bound than IO bound. I just found this surprising. > > Also remember, the build process spawns probably millions of processes and that alone takes some time. > > And 30min sounds pretty great to me :D Yeah, I wonder what other people are seeing for a full buildworld/kernel and/or what the master machines at FreeBSD.org do in this regards. Would anyone else care to share with the class? > > Best regards -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 15:03:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85B326AF for ; Mon, 10 Feb 2014 15:03:57 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36C751607 for ; Mon, 10 Feb 2014 15:03:57 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1AF3lTg013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Feb 2014 08:03:47 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1AF3lcG013783; Mon, 10 Feb 2014 08:03:47 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 10 Feb 2014 08:03:47 -0700 (MST) From: Warren Block To: Tim Daneliuk Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound In-Reply-To: <52F84AF8.8050007@tundraware.com> Message-ID: References: <52F84AF8.8050007@tundraware.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 10 Feb 2014 08:03:47 -0700 (MST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:03:57 -0000 On Sun, 9 Feb 2014, Tim Daneliuk wrote: > For some years now, I have been doing nightly builds of -STABLE > on an old Pentium D machine with 2G of memory. Buildworld + 2 > different kernels was taking in the neighborhood of 3 1/2 hours or so > to run. > > I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure > enough, the build time for all the above came down to 30-35 mins or so. > > "So", says I, "I'll bet a faster drive would help considering all the > scribbling to the disk the compilers and makes do". So, I upgdared to > a Kingston SSD Now 300, 120G hard drive and he time to do the above > went down to .... wait, it's still about 30-35 mins ???? > > So, I've tried fiddling with different values for -j on the make > command line to little avail. Well, -j8 and -j16 show no real > difference here. > > So is the bounding function here actually CPU not IO? Am I missing > something? Yes, it mostly is CPU. Make sure you are running powerd on that i5, it enables turbo mode and gives a noticeable speed increase. Also, consider using -DNO_CLEAN, leaving all the untouched object files in place for make to find and skip. I've seen buildworld times under a minute with that on my i5 and SSD. There are downsides (uname is not always updated correctly), but removing /usr/obj every so often and starting from scratch will fix that. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 15:21:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16696DC; Mon, 10 Feb 2014 15:21:27 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC8801785; Mon, 10 Feb 2014 15:21:26 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s1AFLFu3038519; Mon, 10 Feb 2014 07:21:15 -0800 (PST) (envelope-from freebsd@pki2.com) Subject: Re: Squid aufs crashes under 10.0 From: Dennis Glatting To: Pavel Timofeev In-Reply-To: References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 10 Feb 2014 07:21:15 -0800 Message-ID: <1392045675.20238.9.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1AFLFu3038519 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: freebsd-stable stable , Dimitry Andric , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:21:27 -0000 On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote: > So what should I do? > Write a PR to squid's bugzilla with link to this thread? > Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't > look at PRs about squid). > And it seems like this problem is retaled to all of squid ports, not > only to www/squid33. > Good question. I don't know. I ported 3.4 and sent email to the maintainer and to the list. Zip in response. My 3.4 patch to the Makefile, based on the 3.3 Makefile, are specific to FreeBSD 10 and clang++ std=c++11 but I'm not a ports Makefile hack (it leaves me bewildered at times) and that patch reflects it. Tutoring may be required. :) Dimitry's insight to cstring was insightful but that needs to be fed back to the Squid developers. I recall compiling 3.4 using GCC 4.8 and 4.9 but I don't recall the results. > 2014-02-09 23:56 GMT+04:00 Dimitry Andric : > > On 09 Feb 2014, at 20:16, Dennis Glatting wrote: > >> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote: > > ... > >>> Very bad coding practice, obviously. It should call Find() first, and > >>> if that returns NULL, it should abort in some sort of controlled way. > >>> > >> > >> Found that too but not the reason why: > >> > >> (lldb) run -d -z -F -f /root/squid.conf > >> Process 23598 launched: './src/squid' (x86_64) > >> Find(): Mmapped > >> Find(): IpcIo > >> Find(): DiskDaemon > >> Find(): Blocking > >> Find(): AIO > >> Returning NULL > >> > >> There's a lot of faulty (i.e., a lack thereof) checking in Squid. For > >> example, I replaced strlen() with a custom version that first checks for > >> NULL and returns 0 if that is the case (strlen() was often called by > >> std::cstring::c_str() that was not yet initialized). That small code > >> fragment resolved a lot of SEGVs. > > > > There are a bunch of places where they use std::ostream::operator<< to > > output e.g. configuration strings to the debug stream, for example in > > uniqueHostname(), in src/tools.cc: > > > > const char * > > uniqueHostname(void) > > { > > debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'"); > > return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname(); > > } > > > > The problem case is when Config.uniqueHostname is NULL: this gets > > converted into a std::string first (which is _undefined behavior_), then > > it gets streamed to the debug stream. > > > > However, there is a difference between libstdc++ and libc++ here: the > > former silently accepts NULL arguments passed to the std::string > > constructor, creating a sort of "empty" string for you, which seems to > > work as normal. The latter just stores your NULL pointer, and if you > > actually try to do anything with it, the program will crash. > > > > To fix at least two places where this is done, drop the attached patches > > in www/squid33/files. > > > > -Dimitry > > > > > > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 15:24:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6293B3C6; Mon, 10 Feb 2014 15:24:14 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BEDB17B1; Mon, 10 Feb 2014 15:24:14 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 9E46621035; Mon, 10 Feb 2014 15:24:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 9E46621035 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 10 Feb 2014 10:24:07 -0500 From: Glen Barber To: Tim Daneliuk Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound Message-ID: <20140210152407.GB1629@glenbarber.us> References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6FinHCQBQ0zFDOqT" Content-Disposition: inline In-Reply-To: <52F8E8C6.2060909@tundraware.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:24:14 -0000 --6FinHCQBQ0zFDOqT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 08:57:10AM -0600, Tim Daneliuk wrote: > On 02/09/2014 11:45 PM, army.of.root wrote: > >Am 10/02/14 04:43, schrieb Tim Daneliuk: > >>For some years now, I have been doing nightly builds of -STABLE > >>on an old Pentium D machine with 2G of memory. Buildworld + 2 > >>different kernels was taking in the neighborhood of 3 1/2 hours or so > >>to run. > >> > >>I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure > >>enough, the build time for all the above came down to 30-35 mins or so. > >> > >>"So", says I, "I'll bet a faster drive would help considering all the > >>scribbling to the disk the compilers and makes do". So, I upgdared to > >>a Kingston SSD Now 300, 120G hard drive and he time to do the above > >>went down to .... wait, it's still about 30-35 mins ???? > >> > >>So, I've tried fiddling with different values for -j on the make > >>command line to little avail. Well, -j8 and -j16 show no real > >>difference here. > >> > >>So is the bounding function here actually CPU not IO? Am I missing > >>something? > >> > >>Thanks, > >> > >>P.S. Trying now with no -j arg on make invocation. > > > >Hi, > > > >the new machine has a lot more memory, I assume. >=20 > Yes, 8G as opposed to 2G. I suppose I could bump it out > to 16G and see if this makes any material difference with > even more cache space. >=20 > >The build probably will not even hit the disk due to caching. >=20 >=20 > Well ... it has to hit the disk sooner or later. But, if the > frequency of physical writes is low because of aggregated > IO from the cache, I guess that would tend to make the whole > business more CPU bound than IO bound. I just found this surprising. >=20 What is the underlying filesystem? > > > >Also remember, the build process spawns probably millions of processes a= nd that alone takes some time. > > > >And 30min sounds pretty great to me :D >=20 > Yeah, I wonder what other people are seeing for a full buildworld/kernel = and/or what > the master machines at FreeBSD.org do in this regards. >=20 > Would anyone else care to share with the class? >=20 If you mean "what do the machines do with regard to tuning", the only specific tuning is turning off atime. If you mean "what do the machines do as far as overall build time", with a clean obj/ directory, 35 minutes sounds about right. I do not have exact numbers. The machine that currently produces weekly snapshot images uses '-j10' for buildworld and '-j6' for buildkernel for each build. It also runs the builds in parallel. Even with three parallel 'make -j10 buildworld' (one for head/, stable/10/, and stable/9/), disk IO is minimal. The only time the disk IO becomes a bottleneck is when creating the distribution files (base.txz, kernel.txz, etc.). Glen --6FinHCQBQ0zFDOqT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJS+O8WAAoJELls3eqvi17QTsgQAI7AFT8oJ5S4cldDMCgAxyrx irQoGSLCTCdIzTlOMKHbG6O4InDPN5SwBZj6+91tAAjYQA/WefYqQCJ7U2/no9ga VFtp6No1q2UI56Gf2rV04w6kScoTLnRzOriT+fkqE9t/YG642CBwll7MREpv0JUI AmMPjGCt5Tc77cQwvDk/iwhMZYzs4RVVW2Vpvb0Cv6iMYUFXmw/xdW6vIKciTuUX 2YGSWjFzORK1LMrICzFbppmwMb94Gr7mcKC1TeYZAONiuUFg0LzsW+pWU1K0wHQb P8Ph2PVuYHctbZYPd4vBIVX6i4R809w0rK6bbW71FsGTGQIysxWNksmADXXKTzG2 1Vjg27hUbLJKJm0h3guAdz3mBIUPc0apT2ixSccO6KvNsfqgc0a90d2nCO+8z3bW OTfMqu0NLnoeoxMqhcDyKwrsfB2H+tli5w+JvlvKSO4TthvDL3R0uP2GjIc8L7as BnbFtd47Cd/EJLALmLzE63thLTHvH04Uls7CJML3TuLWrAtnMeAOwux/gxzzBUiX VCfGj+Klt+vkQL/0bpT06sJ4s4zl00xz5qM99PNudo7QUxhKiJ3DtdeOEMLAbkSG fTMII0GtIJWCDrnO2pa8bI6V8MCfJx2azVJ4FbYDkXW/PlFmnyxA473NCoDdIoGt YpCgsfS28MppyynaNRVL =EfKs -----END PGP SIGNATURE----- --6FinHCQBQ0zFDOqT-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 15:45:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FE8B9CF; Mon, 10 Feb 2014 15:45:57 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 135481988; Mon, 10 Feb 2014 15:45:56 +0000 (UTC) Received: from [10.219.131.92] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1AFjlwT017521 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 09:45:48 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F8F426.9000003@tundraware.com> Date: Mon, 10 Feb 2014 09:45:42 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Glen Barber Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> In-Reply-To: <20140210152407.GB1629@glenbarber.us> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 09:45:48 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1AFjlwT017521 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:45:57 -0000 On 02/10/2014 09:24 AM, Glen Barber wrote: > On Mon, Feb 10, 2014 at 08:57:10AM -0600, Tim Daneliuk wrote: >> On 02/09/2014 11:45 PM, army.of.root wrote: >>> Am 10/02/14 04:43, schrieb Tim Daneliuk: >>>> For some years now, I have been doing nightly builds of -STABLE >>>> on an old Pentium D machine with 2G of memory. Buildworld + 2 >>>> different kernels was taking in the neighborhood of 3 1/2 hours or so >>>> to run. >>>> >>>> I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure >>>> enough, the build time for all the above came down to 30-35 mins or so. >>>> >>>> "So", says I, "I'll bet a faster drive would help considering all the >>>> scribbling to the disk the compilers and makes do". So, I upgdared to >>>> a Kingston SSD Now 300, 120G hard drive and he time to do the above >>>> went down to .... wait, it's still about 30-35 mins ???? >>>> >>>> So, I've tried fiddling with different values for -j on the make >>>> command line to little avail. Well, -j8 and -j16 show no real >>>> difference here. >>>> >>>> So is the bounding function here actually CPU not IO? Am I missing >>>> something? >>>> >>>> Thanks, >>>> >>>> P.S. Trying now with no -j arg on make invocation. >>> >>> Hi, >>> >>> the new machine has a lot more memory, I assume. >> >> Yes, 8G as opposed to 2G. I suppose I could bump it out >> to 16G and see if this makes any material difference with >> even more cache space. >> >>> The build probably will not even hit the disk due to caching. >> >> >> Well ... it has to hit the disk sooner or later. But, if the >> frequency of physical writes is low because of aggregated >> IO from the cache, I guess that would tend to make the whole >> business more CPU bound than IO bound. I just found this surprising. >> > > What is the underlying filesystem? > UFS w/Softupdates, no journaling. >>> >>> Also remember, the build process spawns probably millions of processes and that alone takes some time. >>> >>> And 30min sounds pretty great to me :D >> >> Yeah, I wonder what other people are seeing for a full buildworld/kernel and/or what >> the master machines at FreeBSD.org do in this regards. >> >> Would anyone else care to share with the class? >> > > If you mean "what do the machines do with regard to tuning", the only > specific tuning is turning off atime. > Could you comment a bit more about this please? How you do it, rationale', etc. > If you mean "what do the machines do as far as overall build time", with > a clean obj/ directory, 35 minutes sounds about right. I do not have > exact numbers. > > The machine that currently produces weekly snapshot images uses '-j10' > for buildworld and '-j6' for buildkernel for each build. It also runs > the builds in parallel. Even with three parallel 'make -j10 buildworld' > (one for head/, stable/10/, and stable/9/), disk IO is minimal. The > only time the disk IO becomes a bottleneck is when creating the > distribution files (base.txz, kernel.txz, etc.). What sort of CPU/Mem/Disk is that machine? > > Glen > -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 15:55:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49A1ED2C for ; Mon, 10 Feb 2014 15:55:14 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C46051A51 for ; Mon, 10 Feb 2014 15:55:13 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id hr17so4915214lab.34 for ; Mon, 10 Feb 2014 07:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NdkxfiPM5WZquh2eenrHvnEsUKEPIkRU1ykIP05j5R0=; b=mBG5a4GEm4p1U51gJ380fP4AYYx5v3oySnWxiVWGVIn6FtIIs2irjcpmjLSoHr4W6C EIUg/aj9qs0mARbw//zIYOi6J9asSL9xP6v9c0Fb3EUiPZGoZsq+IkXYvy6kq2y0I39N T0/0zu5vPFcLBi/I8svMB4t41BvbIKKJmyNFFQWQK9bPTB1BEAriakakAxUwgW7gHLn5 aYaTrVE1KUbN65CPs0/1DVdHe58wIYwAcaUfkLQ7F0tAK5vQ7Mdf8sKnwp4IF/3wtgYq 2B7z9AYv/IheW4BtBArXlMXiXDqRKlmmifyR5eqRhW+DXHBM3eKq4n0iid56X2sz8Kw3 KE4Q== MIME-Version: 1.0 X-Received: by 10.152.205.197 with SMTP id li5mr1822851lac.50.1392047711895; Mon, 10 Feb 2014 07:55:11 -0800 (PST) Received: by 10.112.0.205 with HTTP; Mon, 10 Feb 2014 07:55:11 -0800 (PST) In-Reply-To: <52F84AF8.8050007@tundraware.com> References: <52F84AF8.8050007@tundraware.com> Date: Mon, 10 Feb 2014 15:55:11 +0000 Message-ID: Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound From: Tom Evans To: Tim Daneliuk Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:55:14 -0000 On Mon, Feb 10, 2014 at 3:43 AM, Tim Daneliuk wrote: > For some years now, I have been doing nightly builds of -STABLE > on an old Pentium D machine with 2G of memory. Buildworld + 2 > different kernels was taking in the neighborhood of 3 1/2 hours or so > to run. > > I then upgraded the Mobo/CPU to a Haswell Quadcore I5-4570 and, sure > enough, the build time for all the above came down to 30-35 mins or so. > > "So", says I, "I'll bet a faster drive would help considering all the > scribbling to the disk the compilers and makes do". So, I upgdared to > a Kingston SSD Now 300, 120G hard drive and he time to do the above > went down to .... wait, it's still about 30-35 mins ???? > > So, I've tried fiddling with different values for -j on the make > command line to little avail. Well, -j8 and -j16 show no real > difference here. > > So is the bounding function here actually CPU not IO? Am I missing > something? > > Thanks, > > P.S. Trying now with no -j arg on make invocation. Does poudriere buildworld on tmpfs if you have USE_TMPFS=all? That might give you an absolute baseline. I was astounded how fast poudriere builds ports, if you build ports from source and haven't switched your ports upgrade routine to build packages with poudriere, well, you're really missing out. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 16:07:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FA7AF6D; Mon, 10 Feb 2014 16:07:40 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BED121B23; Mon, 10 Feb 2014 16:07:39 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 290E821416; Mon, 10 Feb 2014 16:07:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 290E821416 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 10 Feb 2014 11:07:36 -0500 From: Glen Barber To: Tim Daneliuk Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound Message-ID: <20140210160736.GC1629@glenbarber.us> References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qXCixuLMVvZDruUh" Content-Disposition: inline In-Reply-To: <52F8F426.9000003@tundraware.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:07:40 -0000 --qXCixuLMVvZDruUh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 09:45:42AM -0600, Tim Daneliuk wrote: > >>Well ... it has to hit the disk sooner or later. But, if the > >>frequency of physical writes is low because of aggregated > >>IO from the cache, I guess that would tend to make the whole > >>business more CPU bound than IO bound. I just found this surprising. > >> > > > >What is the underlying filesystem? > > >=20 > UFS w/Softupdates, no journaling. >=20 >=20 > [...] > >>Yeah, I wonder what other people are seeing for a full buildworld/kerne= l and/or what > >>the master machines at FreeBSD.org do in this regards. > >> > >>Would anyone else care to share with the class? > >> > > > >If you mean "what do the machines do with regard to tuning", the only > >specific tuning is turning off atime. > > >=20 >=20 > Could you comment a bit more about this please? How you do it, > rationale', etc. >=20 Each build happens in its own ZFS dataset, so atime is disabled during dataset creation (zfs create -o atime=3Doff zroot/11-amd64-GENERIC-snap). The tuning(7) manual has more details, but basically each time a file is read, a separate write happens to update the file access time. Turning off atime eliminates these excessive writes. > >If you mean "what do the machines do as far as overall build time", with > >a clean obj/ directory, 35 minutes sounds about right. I do not have > >exact numbers. > > > >The machine that currently produces weekly snapshot images uses '-j10' > >for buildworld and '-j6' for buildkernel for each build. It also runs > >the builds in parallel. Even with three parallel 'make -j10 buildworld' > >(one for head/, stable/10/, and stable/9/), disk IO is minimal. The > >only time the disk IO becomes a bottleneck is when creating the > >distribution files (base.txz, kernel.txz, etc.). >=20 >=20 > What sort of CPU/Mem/Disk is that machine? >=20 This machine is 48-core (4 x 12 cores) Opteron 6174 (2.2GHz), 128GB RAM, with 5 drives in a raidz1 on a PERC H700 controller. Glen --qXCixuLMVvZDruUh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJS+PlIAAoJELls3eqvi17Qfm0QANJxYsvQLV3GZSceGcfYENMf dIUXehF3QAY34LiJKSX2lGbaXkmWMh9+yS0VaviOR96gaiywQeW8ncp86k/lsl3w ywsZQgcAFs6FeD/OrIgNkNQii4hYrlhE+Dhr+v+1glyO8L0HSqpLOgInJBi9C7lx +3GU38+b6TMRXiHi1NNG8KROjXYFYRsLXatNIBmEodCz5k3wUWc037VUQ4NUn7KQ /fTSr+td231VK7tlmdiC2c+gtWQQB4JUbRGmFSru34+Dl+ZWBa0w7Topc648LyRP w66XOcODhkmogyFnJdPkYSkctzZjou1KfGng65+0bE0cP4jnNu89fBHJUpvtoU98 8DeEDWEoerYaL1/gfN51Suo+b3EpL0ao8cf7PK+ioWC1tMZF8HTU8Be4K7wEo5wD 5qFFIs2S9o7Lpr2/ZhdFzmhxAY8AvoiuKMnaVSqnKsZD+VZbFpgw+jx8rOPw7qXQ FQ1c4epiooo2LaDbRVvyKR9mtBbWzramHzvR4t28cbST4a7Q8NnIFnwhKmOOPfzv /tUCYrYDE+CeSUIrGkRA2DL32DxHJP4w3UrkMbtaZRPsyTOTrYxE5+z4RmebAhJW ThagFoWT/t+g19HUrJs9HTjbsl3K4m9xh/d23IQ9heuejKGrNnmTVcPVkHljOHqt z86RnWlEzqoQIEEmDvJp =Wm6a -----END PGP SIGNATURE----- --qXCixuLMVvZDruUh-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 17:19:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92B0FA59 for ; Mon, 10 Feb 2014 17:19:02 +0000 (UTC) Received: from nm26-vm8.access.bullet.mail.gq1.yahoo.com (nm26-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5175212AD for ; Mon, 10 Feb 2014 17:19:01 +0000 (UTC) Received: from [216.39.60.172] by nm26.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2014 17:15:39 -0000 Received: from [67.195.23.146] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2014 17:15:39 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.gq1.yahoo.com with NNFMP; 10 Feb 2014 17:15:39 -0000 X-Yahoo-Newman-Id: 885291.11969.bm@smtp118.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YI4N9.QVM1kHw0J3FQFTLf.YDIo7Rb6328KG1EaTd0dGn4q c4Iv0ZtpitjMZz3gXejP8LOeJAVlFMiUuFVK5O9AU5wJndATHsh_krYLmynq 7oFcnsBBHTfpMGuKq4HzuWJL3lfdJSNb8_oTFjnEy7TrLAvSn4poU1bPHXWM 7zhBEh8QIIzufN2lSEON4txWl8qUrPhdV.uii1rnEBtqJTH7slb42xO4Vdn5 djYa3gOSsTPIU7t87Q1Qm9VLOeDuaPEOvNNcr6zzf2ghdpzko0TReRivkWpF Kh9m7F8dpzgBYy3NhQ2mUfQW8PewiAuZBOpa51FOq4Qr.mGCsLdmhDC9QoWf TUi8z900I1uO9cLQqse6JxpRMrnB2tr0S_iBVPIX.Qu6OX0EYW0UP6atILIA CorvJby.RS965N_fSaRqa2wTSuBONz26CYletgufkqi6FHZNGWEAxHpFTNl6 Gj1qJvhBP9XnwQiTSX6AC7K74Ud3p9bsFBiuWDjHX2ILLqACG.4UxJ2hQ8yZ 05UfcAq3RN6nPBsCHvzB8jxUPYXJSZIonQEik.BGNDXzChVHyVDm1k9VQsPA - X-Yahoo-SMTP: 5Gpe5lSswBBjxDLzXR4T6WeX4oSzvbvEC6CXOr15Kd9FvJA- X-Rocket-Received: from Antikythera (alexander@99.189.173.81 with plain [67.195.15.5]) by smtp118.sbc.mail.gq1.yahoo.com with SMTP; 10 Feb 2014 17:15:39 +0000 UTC From: "Alexander K. Beros" To: Subject: problem with /usr/ports/MOVED Date: Mon, 10 Feb 2014 09:15:22 -0800 Message-ID: <000301cf2683$b6234610$2269d230$@berosfilms.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8mg6qfAo7F1wwRSM6NZB73JmTyxQ== Content-Language: en-us X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:19:02 -0000 After updating my ports tree, I ran pkgdb -F and received the following message portsdb: MOVED file format error I believe the problem stems from the final line of /usr/ports/MOVED, which is presently irc/trickyirc||Abandonware, segfaults, no releases in 15 years by changing it to irc/trickyirc||2014-02-09|Abandonware, segfaults, no releases in 15 years the problem was resolved, but I don't know if that is actually the correct date. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 18:54:33 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC824E42; Mon, 10 Feb 2014 18:54:33 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD6881BD9; Mon, 10 Feb 2014 18:54:28 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s1AIsPWN007932; Mon, 10 Feb 2014 20:54:25 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s1AIsNDh007727; Mon, 10 Feb 2014 18:54:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 10 Feb 2014 18:54:23 GMT Message-Id: <201402101854.s1AIsNDh007727@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:54:34 -0000 TB --- 2014-02-10 16:50:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-10 16:50:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-10 16:50:42 - starting RELENG_10 tinderbox run for mips64/mips TB --- 2014-02-10 16:50:42 - cleaning the object tree TB --- 2014-02-10 16:50:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-10 16:51:34 - At svn revision 261719 TB --- 2014-02-10 16:51:35 - building world TB --- 2014-02-10 16:51:35 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 16:51:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 16:51:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 16:51:35 - SRCCONF=/dev/null TB --- 2014-02-10 16:51:35 - TARGET=mips TB --- 2014-02-10 16:51:35 - TARGET_ARCH=mips64 TB --- 2014-02-10 16:51:35 - TZ=UTC TB --- 2014-02-10 16:51:35 - __MAKE_CONF=/dev/null TB --- 2014-02-10 16:51:35 - cd /src TB --- 2014-02-10 16:51:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 10 16:51:45 UTC 2014 >>> 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 Feb 10 18:16:23 UTC 2014 TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m ADM5120 TB --- 2014-02-10 18:16:23 - skipping ADM5120 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m ALCHEMY TB --- 2014-02-10 18:16:23 - skipping ALCHEMY kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AP121 TB --- 2014-02-10 18:16:23 - skipping AP121 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AP91 TB --- 2014-02-10 18:16:23 - skipping AP91 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AP93 TB --- 2014-02-10 18:16:23 - skipping AP93 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AP94 TB --- 2014-02-10 18:16:23 - skipping AP94 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AP96 TB --- 2014-02-10 18:16:23 - skipping AP96 kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AR71XX_BASE TB --- 2014-02-10 18:16:23 - skipping AR71XX_BASE kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AR724X_BASE TB --- 2014-02-10 18:16:23 - skipping AR724X_BASE kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AR91XX_BASE TB --- 2014-02-10 18:16:23 - skipping AR91XX_BASE kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AR933X_BASE TB --- 2014-02-10 18:16:23 - skipping AR933X_BASE kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m AR934X_BASE TB --- 2014-02-10 18:16:23 - skipping AR934X_BASE kernel TB --- 2014-02-10 18:16:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:16:23 - /usr/sbin/config -m BERI_DE4_BASE TB --- 2014-02-10 18:16:24 - building BERI_DE4_BASE kernel TB --- 2014-02-10 18:16:24 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:16:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:16:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:16:24 - SRCCONF=/dev/null TB --- 2014-02-10 18:16:24 - TARGET=mips TB --- 2014-02-10 18:16:24 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:16:24 - TZ=UTC TB --- 2014-02-10 18:16:24 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:16:24 - cd /src TB --- 2014-02-10 18:16:24 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Mon Feb 10 18:16:24 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_BASE completed on Mon Feb 10 18:21:08 UTC 2014 TB --- 2014-02-10 18:21:08 - cd /src/sys/mips/conf TB --- 2014-02-10 18:21:08 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2014-02-10 18:21:08 - building BERI_DE4_MDROOT kernel TB --- 2014-02-10 18:21:08 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:21:08 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:21:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:21:08 - SRCCONF=/dev/null TB --- 2014-02-10 18:21:08 - TARGET=mips TB --- 2014-02-10 18:21:08 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:21:08 - TZ=UTC TB --- 2014-02-10 18:21:08 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:21:08 - cd /src TB --- 2014-02-10 18:21:08 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Mon Feb 10 18:21:08 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Mon Feb 10 18:25:58 UTC 2014 TB --- 2014-02-10 18:25:58 - cd /src/sys/mips/conf TB --- 2014-02-10 18:25:58 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2014-02-10 18:25:59 - building BERI_DE4_SDROOT kernel TB --- 2014-02-10 18:25:59 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:25:59 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:25:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:25:59 - SRCCONF=/dev/null TB --- 2014-02-10 18:25:59 - TARGET=mips TB --- 2014-02-10 18:25:59 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:25:59 - TZ=UTC TB --- 2014-02-10 18:25:59 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:25:59 - cd /src TB --- 2014-02-10 18:25:59 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Mon Feb 10 18:26:00 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Mon Feb 10 18:30:40 UTC 2014 TB --- 2014-02-10 18:30:40 - cd /src/sys/mips/conf TB --- 2014-02-10 18:30:40 - /usr/sbin/config -m BERI_NETFPGA_MDROOT TB --- 2014-02-10 18:30:40 - building BERI_NETFPGA_MDROOT kernel TB --- 2014-02-10 18:30:40 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:30:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:30:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:30:40 - SRCCONF=/dev/null TB --- 2014-02-10 18:30:40 - TARGET=mips TB --- 2014-02-10 18:30:40 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:30:40 - TZ=UTC TB --- 2014-02-10 18:30:40 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:30:40 - cd /src TB --- 2014-02-10 18:30:40 - /usr/bin/make -B buildkernel KERNCONF=BERI_NETFPGA_MDROOT >>> Kernel build for BERI_NETFPGA_MDROOT started on Mon Feb 10 18:30:40 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_NETFPGA_MDROOT completed on Mon Feb 10 18:34:57 UTC 2014 TB --- 2014-02-10 18:34:57 - cd /src/sys/mips/conf TB --- 2014-02-10 18:34:57 - /usr/sbin/config -m BERI_SIM_BASE TB --- 2014-02-10 18:34:57 - building BERI_SIM_BASE kernel TB --- 2014-02-10 18:34:57 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:34:57 - SRCCONF=/dev/null TB --- 2014-02-10 18:34:57 - TARGET=mips TB --- 2014-02-10 18:34:57 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:34:57 - TZ=UTC TB --- 2014-02-10 18:34:57 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:34:57 - cd /src TB --- 2014-02-10 18:34:57 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_BASE >>> Kernel build for BERI_SIM_BASE started on Mon Feb 10 18:34:57 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_BASE completed on Mon Feb 10 18:39:12 UTC 2014 TB --- 2014-02-10 18:39:12 - cd /src/sys/mips/conf TB --- 2014-02-10 18:39:12 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2014-02-10 18:39:12 - building BERI_SIM_MDROOT kernel TB --- 2014-02-10 18:39:12 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:39:12 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:39:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:39:12 - SRCCONF=/dev/null TB --- 2014-02-10 18:39:12 - TARGET=mips TB --- 2014-02-10 18:39:12 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:39:12 - TZ=UTC TB --- 2014-02-10 18:39:12 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:39:12 - cd /src TB --- 2014-02-10 18:39:12 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Mon Feb 10 18:39:12 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Mon Feb 10 18:43:23 UTC 2014 TB --- 2014-02-10 18:43:23 - cd /src/sys/mips/conf TB --- 2014-02-10 18:43:23 - /usr/sbin/config -m BERI_SIM_SDROOT TB --- 2014-02-10 18:43:24 - building BERI_SIM_SDROOT kernel TB --- 2014-02-10 18:43:24 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:43:24 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:43:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:43:24 - SRCCONF=/dev/null TB --- 2014-02-10 18:43:24 - TARGET=mips TB --- 2014-02-10 18:43:24 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:43:24 - TZ=UTC TB --- 2014-02-10 18:43:24 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:43:24 - cd /src TB --- 2014-02-10 18:43:24 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_SDROOT >>> Kernel build for BERI_SIM_SDROOT started on Mon Feb 10 18:43:24 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_SDROOT completed on Mon Feb 10 18:47:21 UTC 2014 TB --- 2014-02-10 18:47:21 - cd /src/sys/mips/conf TB --- 2014-02-10 18:47:21 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2014-02-10 18:47:21 - building BERI_TEMPLATE kernel TB --- 2014-02-10 18:47:21 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:47:21 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:47:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:47:21 - SRCCONF=/dev/null TB --- 2014-02-10 18:47:21 - TARGET=mips TB --- 2014-02-10 18:47:21 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:47:21 - TZ=UTC TB --- 2014-02-10 18:47:21 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:47:21 - cd /src TB --- 2014-02-10 18:47:21 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Mon Feb 10 18:47:21 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Mon Feb 10 18:51:12 UTC 2014 TB --- 2014-02-10 18:51:12 - cd /src/sys/mips/conf TB --- 2014-02-10 18:51:12 - /usr/sbin/config -m CARAMBOLA2 TB --- 2014-02-10 18:51:13 - skipping CARAMBOLA2 kernel TB --- 2014-02-10 18:51:13 - cd /src/sys/mips/conf TB --- 2014-02-10 18:51:13 - /usr/sbin/config -m DB120 TB --- 2014-02-10 18:51:13 - skipping DB120 kernel TB --- 2014-02-10 18:51:13 - cd /src/sys/mips/conf TB --- 2014-02-10 18:51:13 - /usr/sbin/config -m DIR-825 TB --- 2014-02-10 18:51:13 - skipping DIR-825 kernel TB --- 2014-02-10 18:51:13 - cd /src/sys/mips/conf TB --- 2014-02-10 18:51:13 - /usr/sbin/config -m ENH200 TB --- 2014-02-10 18:51:13 - skipping ENH200 kernel TB --- 2014-02-10 18:51:13 - cd /src/sys/mips/conf TB --- 2014-02-10 18:51:13 - /usr/sbin/config -m GXEMUL TB --- 2014-02-10 18:51:13 - building GXEMUL kernel TB --- 2014-02-10 18:51:13 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:51:13 - SRCCONF=/dev/null TB --- 2014-02-10 18:51:13 - TARGET=mips TB --- 2014-02-10 18:51:13 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:51:13 - TZ=UTC TB --- 2014-02-10 18:51:13 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:51:13 - cd /src TB --- 2014-02-10 18:51:13 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Mon Feb 10 18:51:13 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Mon Feb 10 18:54:19 UTC 2014 TB --- 2014-02-10 18:54:19 - cd /src/sys/mips/conf TB --- 2014-02-10 18:54:19 - /usr/sbin/config -m GXEMUL32 TB --- 2014-02-10 18:54:19 - skipping GXEMUL32 kernel TB --- 2014-02-10 18:54:19 - cd /src/sys/mips/conf TB --- 2014-02-10 18:54:19 - /usr/sbin/config -m IDT TB --- 2014-02-10 18:54:19 - skipping IDT kernel TB --- 2014-02-10 18:54:19 - cd /src/sys/mips/conf TB --- 2014-02-10 18:54:19 - /usr/sbin/config -m MALTA TB --- 2014-02-10 18:54:19 - skipping MALTA kernel TB --- 2014-02-10 18:54:19 - cd /src/sys/mips/conf TB --- 2014-02-10 18:54:19 - /usr/sbin/config -m MALTA64 TB --- 2014-02-10 18:54:19 - skipping MALTA64 kernel TB --- 2014-02-10 18:54:19 - cd /src/sys/mips/conf TB --- 2014-02-10 18:54:19 - /usr/sbin/config -m OCTEON1 TB --- 2014-02-10 18:54:19 - building OCTEON1 kernel TB --- 2014-02-10 18:54:19 - CROSS_BUILD_TESTING=YES TB --- 2014-02-10 18:54:19 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-10 18:54:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-10 18:54:19 - SRCCONF=/dev/null TB --- 2014-02-10 18:54:19 - TARGET=mips TB --- 2014-02-10 18:54:19 - TARGET_ARCH=mips64 TB --- 2014-02-10 18:54:19 - TZ=UTC TB --- 2014-02-10 18:54:19 - __MAKE_CONF=/dev/null TB --- 2014-02-10 18:54:19 - cd /src TB --- 2014-02-10 18:54:19 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Mon Feb 10 18:54:19 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/mips.mips64/src/tmp/legacy/usr/sbin:/obj/mips.mips64/src/tmp/legacy/usr/bin:/obj/mips.mips64/src/tmp/legacy/usr/games:/obj/mips.mips64/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/mips.mips64/src/sys/OCTEON1/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-10 18:54:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-10 18:54:22 - ERROR: failed to build OCTEON1 kernel TB --- 2014-02-10 18:54:22 - 5206.48 user 2590.43 system 7419.41 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-mips64-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 19:12:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDE2A24E; Mon, 10 Feb 2014 19:12:10 +0000 (UTC) Received: from mail.solomo.de (mail.solomo.de [5.9.87.18]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6CF1D4D; Mon, 10 Feb 2014 19:12:10 +0000 (UTC) Received: from cpos1.nexxtmobile.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 6269E905B; Mon, 10 Feb 2014 20:12:08 +0100 (CET) X-Virus-Scanned: amavisd-new at nexxtmobile.de Received: from mail.solomo.de ([127.0.0.1]) by cpos1.nexxtmobile.de (cpos1.nexxtmobile.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UkEAbbqvteze; Mon, 10 Feb 2014 20:12:06 +0100 (CET) Received: from nibbler-wlan.home.lan (85-22-78-228.ip.dokom21.de [85.22.78.228]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 2B0189047; Mon, 10 Feb 2014 20:12:03 +0100 (CET) Message-ID: <52F9247E.3020307@smeets.im> Date: Mon, 10 Feb 2014 20:11:58 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0a1 MIME-Version: 1.0 To: Dennis Glatting , Pavel Timofeev Subject: Re: Squid aufs crashes under 10.0 References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> <1392045675.20238.9.camel@btw.pki2.com> In-Reply-To: <1392045675.20238.9.camel@btw.pki2.com> X-Enigmail-Version: 1.7a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RSLEenmglkgwvAQItfGuc9rcHhmik0kEG" Cc: Dimitry Andric , freebsd-stable stable , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:12:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RSLEenmglkgwvAQItfGuc9rcHhmik0kEG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/02/14 16:21, Dennis Glatting wrote: > On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote: >> So what should I do? >> Write a PR to squid's bugzilla with link to this thread? >> Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't >> look at PRs about squid). >> And it seems like this problem is retaled to all of squid ports, not >> only to www/squid33. >> >=20 > Good question. I don't know. I ported 3.4 and sent email to the > maintainer and to the list. Zip in response. >=20 I plan to take care of it this week. (squid34 + aufs patches) Florian --RSLEenmglkgwvAQItfGuc9rcHhmik0kEG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS+SSBAAoJEOcFPfn/hvB2YdAP/1DumKUR4VBlSi/RVIiYDVWV CNZz0ytvSF7+hk6s+j23go7vOO86OiN8p+kwqfiCxlFNp6O9QtrfcKW1XOfVOjP1 4++MsaseOcpab2d3xN7RMtGH0N7hylLJSOGBMwZQIBerKwwhPzElGDRKuJPXy++3 duVqnGcdg00K4u4giqOFtQ5sInHdPN1Zb6cG1aG5Vp+52oQfBAuSZtv3WJ1U4MHW WO10+Kk9yUUN4rI9bhPsRIlZzNys7tTS1lQyIG+vFVFZcXLa6Zgb/7avy9iR0mIZ sGB+UpLVpr62mfqzmfwO/bdhO1ErHtRhhVcNiBOLS7UM9EjKSIrsrBZ/DZN/mfbA eeQpqEgst/g3Bwqh64hbfmJaT6v7COD9AxaBrItmvfUyhv6ty9v2Y8+/Q6MZzoak VL6+t7xF1iUD+9N6EK278BZu1gVYlrGM7gpGnl1qMsD4ZNTR5dJWiAjcn2cJesOy 9ouYsFvHTsbuwiJdbMCsTlTYIueXnw7o6eTB7WO4R/e498WoXMFVlVwpZqunFzdo lqBpixHWyZ/8KL4jB4auv9pR91WuJdUDYG6cik1T5L3jCOFbmByRkefqYTNBC5iK rUL5Vw0tzSgMMeXY+p8a3lg2t8rJOLxWSdAeRJ+KsnB37u9Zp2suKehMj07QiqxT R9ydpkVT27YcpNNF0/8X =Dk4v -----END PGP SIGNATURE----- --RSLEenmglkgwvAQItfGuc9rcHhmik0kEG-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 20:40:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8442F4E4 for ; Mon, 10 Feb 2014 20:40:39 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43DD21718 for ; Mon, 10 Feb 2014 20:40:38 +0000 (UTC) Received: from [10.219.131.92] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1AKeNIv054306 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 10 Feb 2014 14:40:24 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F93929.1070203@tundraware.com> Date: Mon, 10 Feb 2014 14:40:09 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> <20140210160736.GC1629@glenbarber.us> In-Reply-To: <20140210160736.GC1629@glenbarber.us> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 14:40:27 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1AKeNIv054306 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:40:39 -0000 On 02/10/2014 10:07 AM, Glen Barber wrote: > > This machine is 48-core (4 x 12 cores) Opteron 6174 (2.2GHz), 128GB RAM, > with 5 drives in a raidz1 on a PERC H700 controller. > > Glen > So ... in that config, you're saying that a buildworld/kernel time on the order of 30-ish minutes is about right, is that correct? -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 20:43:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC0B0638; Mon, 10 Feb 2014 20:43:43 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B381175D; Mon, 10 Feb 2014 20:43:42 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 877AB21CDF; Mon, 10 Feb 2014 20:43:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 877AB21CDF Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 10 Feb 2014 15:43:39 -0500 From: Glen Barber To: Tim Daneliuk Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound Message-ID: <20140210204339.GI1629@glenbarber.us> References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> <20140210160736.GC1629@glenbarber.us> <52F93929.1070203@tundraware.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2+N3zU4ZlskbnZaJ" Content-Disposition: inline In-Reply-To: <52F93929.1070203@tundraware.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:43:43 -0000 --2+N3zU4ZlskbnZaJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 02:40:09PM -0600, Tim Daneliuk wrote: > On 02/10/2014 10:07 AM, Glen Barber wrote: > >=20 > > > >This machine is 48-core (4 x 12 cores) Opteron 6174 (2.2GHz), 128GB RAM, > >with 5 drives in a raidz1 on a PERC H700 controller. > > > >Glen > > >=20 > So ... in that config, you're saying that a buildworld/kernel time > on the order of 30-ish minutes is about right, is that correct? >=20 Yes, for a stock (GENERIC kernel, empty src.conf and make.conf), this is correct. Glen --2+N3zU4ZlskbnZaJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJS+Tn7AAoJELls3eqvi17QLG4P+wWk23IMowo+7YIKlPr6d7g8 h2Z0dcllFgLo5U74cmGVopDz+9qi7LduK7WhKkpLRId8wznsHofkTPcR6FFDtJiA x9qR06zUE2dOSO+DwtmmwCIw4oJozPSqtN7FJbeT3fFn9ziwD8HNQHerSTRcw9Ey Bde6JLfZT1ydDNsVGcyKNPnJ5zDH6tHISqvheJRrm46TMNCZ23NiIOeEB3Z6BbIA nl1tnq5rOIh8XUemMyjBwORamMnFicy3lZNVdZfLf0mPzzwsaTKK3fuUW77G8qxz 9iXq8E6v9ITLFr3pXm8P9aWOAfd8I8ebHYo3xwTw9Z4URAJ+7whu8TvDmdI3hcVc 5kCmv+gplxfBnHz/WOuHhYHv59PlxeTUTI6PV0RqzFPs6q8emBAaydEPKImDtogp kMAfgIBswvGygl4CU/Q9Hc69Skbovhry/RlC+4ULUt24guoz+xH84qTjHE/YF4Hj 7ss3tVN9Bww0lqoOihFpcfuaqyhOfM3YbvuB/P5JSIK4r359rRYCa4sHC4e4WqdN krlRGiHAJohEqSTWyY4rYD/1G7cqyvWPtRzPW+EuU/0oDqmvkyuJ7FoR4wQfH78R SNZsp/JfnDY4X7myAxaC16rM/1l6dv3XdrNEShzfcBK+IgHB9hzLG8/i/MdBbsXh dHnHDH3eFPgJMJ+7kO4m =vpD7 -----END PGP SIGNATURE----- --2+N3zU4ZlskbnZaJ-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 20:48:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F17967C0 for ; Mon, 10 Feb 2014 20:48:15 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1D701796 for ; Mon, 10 Feb 2014 20:48:15 +0000 (UTC) Received: from [10.219.131.92] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1AKm5hT054461 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 10 Feb 2014 14:48:06 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F93AFF.9090806@tundraware.com> Date: Mon, 10 Feb 2014 14:47:59 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> <20140210160736.GC1629@glenbarber.us> <52F93929.1070203@tundraware.com> <20140210204339.GI1629@glenbarber.us> In-Reply-To: <20140210204339.GI1629@glenbarber.us> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 14:48:06 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1AKm5hT054461 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:48:16 -0000 On 02/10/2014 02:43 PM, Glen Barber wrote: > On Mon, Feb 10, 2014 at 02:40:09PM -0600, Tim Daneliuk wrote: >> On 02/10/2014 10:07 AM, Glen Barber wrote: >> >> >>> >>> This machine is 48-core (4 x 12 cores) Opteron 6174 (2.2GHz), 128GB RAM, >>> with 5 drives in a raidz1 on a PERC H700 controller. >>> >>> Glen >>> >> >> So ... in that config, you're saying that a buildworld/kernel time >> on the order of 30-ish minutes is about right, is that correct? >> > > Yes, for a stock (GENERIC kernel, empty src.conf and make.conf), this is > correct. > > Glen > 'Really interesting given that I am getting comparable times on a lowly quad I5 with 8GB. It speaks pretty loudly to just how much you can scale up the compilation. Of course, I'd expect your boxes to be able to do more of them simultaneously (scale out)... -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 20:59:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB93CD90; Mon, 10 Feb 2014 20:59:10 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B91A71890; Mon, 10 Feb 2014 20:59:10 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id A629521E51; Mon, 10 Feb 2014 20:59:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us A629521E51 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 10 Feb 2014 15:59:02 -0500 From: Glen Barber To: Tim Daneliuk Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound Message-ID: <20140210205902.GJ1629@glenbarber.us> References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> <20140210160736.GC1629@glenbarber.us> <52F93929.1070203@tundraware.com> <20140210204339.GI1629@glenbarber.us> <52F93AFF.9090806@tundraware.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H6o9R95t2FPeZmf3" Content-Disposition: inline In-Reply-To: <52F93AFF.9090806@tundraware.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:59:11 -0000 --H6o9R95t2FPeZmf3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 02:47:59PM -0600, Tim Daneliuk wrote: > On 02/10/2014 02:43 PM, Glen Barber wrote: > >On Mon, Feb 10, 2014 at 02:40:09PM -0600, Tim Daneliuk wrote: > >>On 02/10/2014 10:07 AM, Glen Barber wrote: > >> > >> > >>> > >>>This machine is 48-core (4 x 12 cores) Opteron 6174 (2.2GHz), 128GB RA= M, > >>>with 5 drives in a raidz1 on a PERC H700 controller. > >>> > >>>Glen > >>> > >> > >>So ... in that config, you're saying that a buildworld/kernel time > >>on the order of 30-ish minutes is about right, is that correct? > >> > > > >Yes, for a stock (GENERIC kernel, empty src.conf and make.conf), this is > >correct. > > > >Glen > > >=20 >=20 > 'Really interesting given that I am getting comparable times > on a lowly quad I5 with 8GB. It speaks pretty loudly > to just how much you can scale up the compilation. Of course, > I'd expect your boxes to be able to do more of them simultaneously > (scale out)... >=20 There are two things to consider though. I'm not cranking the number of '-j' as high as it probably can go. I'm intentionally limiting it to 'j10' and '-j6' in order to do parallel builds. I'm sure '-j24' or higher in this case would reduce overall build time. I'm just not comfortable doing that, because there are a few (sometimes easily-triggered, other times not so easily-triggered) race conditions that can cause the builds to fall over to easily. So limiting to a relatively safe number, scaling out certainly does help. But this is a very specific, and probably atypical use case. :) Glen --H6o9R95t2FPeZmf3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJS+T2WAAoJELls3eqvi17QLx8P/j3OTSn5dlLxw7wZJkoLkwta xg01mVGDj/D/zlWmlFtjwy2TYbKU9kg9EWUZjgIpBJFVe5zHnfLG0wLa7wV6qMW+ ZW4wFsj8AXR1t+kiVDX40+R5sBa+mXrW5R3RXfHO5H/YgJdw98xNdOdZpePchFSo dvwHwTAUzsRPzAUqkZKqUfq39k84alF8n8iUhuaD3w+X7GaNB988IXOU/rmehsLJ oP8oSzHCIBCvPn4hhu1Vfx4oEyyt2g8H3EI25dQ+Ue6PYnxo28mYfwIM5E45LOI0 E6UzX6P91GZ4ooS230aiiZYMvdj5+MVN+PEE9Q/kU1/HwLxxRFZFTKYmkchbT7m6 bp76Z99bXjJ0UO0TtfsvgUTEgMsEUzczgk1CJz71KhQksoWahoIxDoBWQ25aKSu/ S7dMCsWB/8HmY/c0rLMiPC0d7692v8e9Oyyvla1fr/9bh+uHQW7wAc7H5gB74xeI hsliJxVWqDDFQy+xrmEAMMXs+I6PuVl08c4LR4Ml0n/dA4/s0dnOJRGiNKe9NLX7 zIPhPlUIZr4itW2btAqq/ZblZ+ZJISVBN5/nv96zMg02RY2qJJsHkjtbSDwWppMz Bn+LieoXfXKq9IsBAXRCODmiqCvaMgppy+pHQ2KGLn9ppTsb8C63pYMm6pUEXNMU GXPzvWOKEnUmdn5HS2zl =XuHT -----END PGP SIGNATURE----- --H6o9R95t2FPeZmf3-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 22:08:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78FE0F82; Mon, 10 Feb 2014 22:08:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44F3F1DF0; Mon, 10 Feb 2014 22:08:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1A685B95D; Mon, 10 Feb 2014 17:08:44 -0500 (EST) From: John Baldwin To: freebsd-hardware@freebsd.org Subject: Re: Followup On Recent MCA Madness. WAS: Need Help With MCA Code Date: Mon, 10 Feb 2014 16:18:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E73717.3000503@tundraware.com> <52EBE1FA.2040603@tundraware.com> <52ED5C97.8030503@tundraware.com> In-Reply-To: <52ED5C97.8030503@tundraware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402101618.43685.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Feb 2014 17:08:44 -0500 (EST) Cc: Tim Daneliuk , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:08:45 -0000 On Saturday, February 01, 2014 3:44:07 pm Tim Daneliuk wrote: > On 01/31/2014 11:48 AM, Tim Daneliuk wrote: > > On 01/31/2014 11:22 AM, John Baldwin wrote: > >> On Wednesday, January 29, 2014 6:49:21 pm Tim Daneliuk wrote: > >>> Resending in hopes that people on one of the other lists will have some insight here: > >>> > >>> On 01/27/2014 10:50 PM, Tim Daneliuk wrote: > >>>> I am running 9.2 stable i386 r261207. As noted earlier: > >>>> > >>>>> I just replaced mobo/CPU on FBSD server (Gigabyte Z-87-D3HP with > >>>>> an Intel i3-4130). I am not overclocking ... but I continue to see this sort of thing: > >>>> > >>>>> MCA: CPU 0 COR (1) internal parity error > >>>> > >>>> Dmesg shows: > >>>> > >>>>> MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 0 > >>>>> MCA: CPU 0 COR (1) internal parity error > >>>>> MCA: Bank 0, Status 0x90000040000f0005 > >>>>> MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000_ > >>>> > >>>> I've swapped CPUs (i5). I've fiddled with an endless supply of > >>>> mobo settings. I've switched power supplies. I've moved mem > >>>> sticks around .... No joy. > >>>> > > This got resolved when I did a completely fresh install of FBSD 10 > on the server. This made the MCAs go away. I therefore conclude > that there were one of several possible root causes: > > - FreeBSD i386 doesn't play nice with Haswell parts > - FreeBSD 9.2-STABLE i386 doesn't place nice with Haswell parts > - My FreeBSD 9.2-STABLE i386 instance was corrupted somehow > > My belief is that it is mostly likely the last culprit, absent > someone confirming that the first two are possibilities. > > The good thing that came out of this is that I finally > upgraded this server in some important ways: > > - 64 bit > - FreeBSD 10 > - Latest bind 9 > > Now, if I could just figure out how to get stock X to > run at 1920x1080 on HD4600 graphics. Apparently neither the > intel of vesa drivers know how to do this, or at least I've > had no luck with it. The intel driver doesn't even recognize > the hardware as something it supports. > > "X on a server?" you say? Yes, for intermittent use of fluxbox > to run a bunch of xterms. For the Intel graphics you want to use i915kms. However, you need to build your ports with 'WITH_NEW_XORG=yes' set in /etc/make.conf. There are more details about this on the wiki. https://wiki.freebsd.org/Graphics -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 22:17:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8175C364 for ; Mon, 10 Feb 2014 22:17:18 +0000 (UTC) Received: from mx01.ilk.net (mx01.ilk.net [212.86.193.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DEB71FB4 for ; Mon, 10 Feb 2014 22:17:17 +0000 (UTC) Received: from smo.de (p5B131DB3.dip0.t-ipconnect.de [91.19.29.179]) (authenticated bits=0) by mx01.ilk.net (8.13.4/8.13.4/ilk-relay) with ESMTP id s1AMCqeC031847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Feb 2014 23:12:53 +0100 Received: from skjaldbreidur.intern.smo.de (skjaldbreidur.intern.smo.de [192.168.153.212]) by smo.de (8.14.4/8.14.4) with ESMTP id s1AMCqTh003796; Mon, 10 Feb 2014 23:12:52 +0100 (CET) Message-ID: <52F95D6C.10508@smo.de> Date: Mon, 10 Feb 2014 23:14:52 +0000 From: Philipp-Joachim Ost User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: Tim Daneliuk , freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> In-Reply-To: <52F8E8C6.2060909@tundraware.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040509060205040903020807" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:17:18 -0000 This is a cryptographically signed message in MIME format. --------------ms040509060205040903020807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim Daneliuk wrote: [...] > Yeah, I wonder what other people are seeing for a full buildworld/kerne= l > and/or what > the master machines at FreeBSD.org do in this regards. >=20 > Would anyone else care to share with the class? On my main machine 'make -j12 buildworld' takes 43:38.42 minutes to complete; -j4 takes 1:53 hours to complete. My stripped down kernel is built in 1:52 minutes... It's a AMD FX 6100, 8GB RAM, ZFS all around. I'm shure I can improve those numbers, as I was running other stuff in the background. Some days ago, I dug out an older machine of mine (sporting a PIII@500MHz, 256MB memory). That machine needs ~25 hours to build world. Crazy fast :D To be honest, I don't exactly care a lot how long it takes to build a new world/kernel. I'm happy as long as it finishes in a reasonable timeframe (those 25 hours are stretching it a bit, though...). Philipp --------------ms040509060205040903020807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFbTCC BWkwggNRoAMCAQICAw2etzANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzA4 MDUyMDEyMzdaFw0xNTA4MDUyMDEyMzdaMDgxHDAaBgNVBAMTE1BoaWxpcHAtSm9hY2hpbSBP c3QxGDAWBgkqhkiG9w0BCQEWCXBqQHNtby5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAJ7QrfW9eWrnxSQC+1Jt2wYbk1Juto8Pg7Yie3tQ9Q/HmWYIUQy8Y2VIIyksHjpD MrjdcmIU3vRLHTbJxHwH1hjbkFruD9k4FFpoVGw5/Tc6bMj+XqCKFJKcD3XyaO1oW8l/dcVL j+T+jtQG5N+twFXR9UqBfuj5haQrF/zT1yzDtfC/bPXhBndoM9T9AY6tl4Sm+LKWtGDR0xq5 YH56T41U/V7+aUUQjVw1rutDAjDsbER1zYZblLRsrDOZfA4XZCiXeOku2XrRfyLjmn3y/XD5 RrVbG5wCM7XGNwVvj9d5Dukq6bc+ZlvvoNooPTYYi7obW5OQLgvLzLfNxemdsPMCAwEAAaOC ATkwggE1MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBj ZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3Jn MA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQB gjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2Ny bC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwFAYDVR0RBA0wC4EJcGpAc21vLmRlMA0GCSqGSIb3 DQEBBQUAA4ICAQAMLUNYgIHg7XfVlGR25uw/WyG4fIAzxS9GX/DQ72WVS3PSfD1INfb21uCa K4SaubaJ/JZ+Tm2FLXWhge+flmaPu1lm/j+eD52kgJ5vKujQ4Iq8EBthFkacnwaXw6hpH+c1 RHwrU4jqcUbOmvNVFIFJFJuqGxUWfIY8Chqi+UN9kWyNYLx93yY/BvqyScRMRkdDUjwnqdLl K6ZlIwTRHToz46Fgau0MRX8W/j7RUoe3Xh2C6o/MM6IpMZuV4Zd090VZst7Hs3Hko+nlLti5 PH96DSOUjw4T5E0NBpAG7EJKAalLRI59qQUH67v9wgnjVCy/5gkT3Md4kTdJQqt+iWe9xq/m 9JpT/+r/V4uCS4VJANgtBpCJZJf+2LSt83Sv5+2kDbWIQk2dQs+uiB3227+EOvsfMA31dGJ/ FBZKe9EcoNgEkmTiwADhmYD6pkZTKH69tGwv54kois1jbfH2Ae6l9LULJ9pFr8LwMRUVw2fv ZHSgEB6hPhPR0y1vABQ3AfeTAJzH7YBMZm6qYRbsNZ0c7QNO96va0SB1oyX4BXhspp0JhY/G YsKoYhsVWS5rJknGnFNpuOKhJaC0mj7bSmexZGkdRILB23mNLxPEt29gAVMj7zLRKzEWCgj9 Wr2k8Y7MCkR+Qbw8ieOicTOD+OJS6BOuYfPer/pY7FdwSbsceTGCA6EwggOdAgEBMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAG A1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y dEBjYWNlcnQub3JnAgMNnrcwCQYFKw4DAhoFAKCCAfUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjEwMjMxNDUyWjAjBgkqhkiG9w0BCQQxFgQUEX2a bwH0SGMIXNAIcuhAmAJU/DcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jv b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2Vy dCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMNnrcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMNnrcwDQYJKoZI hvcNAQEBBQAEggEAVs09AEvwRvoimqMXWUY+iiNtikKdYbpLsta7eHNXNRTLaIVKGpTwtO6s JYR8OrB1Mu02hSvZcxoXLI6DrnyWsWTWtPeB2icD3Jp47jG57Mpo9t/q/CvLp63kU9sDaJN6 6y1LWZgGSL06rjAhSDqgbmuc2jwuSB1ZyfHDefXIc8isHbEhO6xyUvCh+IvhHd+vE9IuQHAA 63Nky2qttUkoYWV55X9hpuvzlAWv8xwJ7LdDNvLNLjf9bk8reuGCx4HQQdgvYWPhI1eYxLKa 56+4Y2pNVROICrjepUP4PqYU0xq7unAe+66G2ElKKI13NoOTnz/lpLZu4yNoA9CnjLEblAAA AAAAAA== --------------ms040509060205040903020807-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 23:53:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2222AD5; Mon, 10 Feb 2014 23:53:48 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0C2E1821; Mon, 10 Feb 2014 23:53:47 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1ANrbcI010637 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 17:53:37 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F96681.3080604@tundraware.com> Date: Mon, 10 Feb 2014 17:53:37 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Subject: Re: Followup On Recent MCA Madness. WAS: Need Help With MCA Code References: <52E73717.3000503@tundraware.com> <52EBE1FA.2040603@tundraware.com> <52ED5C97.8030503@tundraware.com> <201402101618.43685.jhb@freebsd.org> In-Reply-To: <201402101618.43685.jhb@freebsd.org> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 17:53:37 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1ANrbcI010637 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:53:48 -0000 On 02/10/2014 03:18 PM, John Baldwin wrote: >> On Saturday, February 01, 2014 3:44:07 pm Tim Daneliuk wrote: >> Now, if I could just figure out how to get stock X to >> run at 1920x1080 on HD4600 graphics. Apparently neither the >> intel of vesa drivers know how to do this, or at least I've >> had no luck with it. The intel driver doesn't even recognize >> the hardware as something it supports. >> >> "X on a server?" you say? Yes, for intermittent use of fluxbox >> to run a bunch of xterms. > > For the Intel graphics you want to use i915kms. However, you need to build > your ports with 'WITH_NEW_XORG=yes' set in /etc/make.conf. There are more > details about this on the wiki. > > https://wiki.freebsd.org/Graphics I've been considering this, but I have a few more questions, if I may: - There was a time when the new Xorg stuff did not play well with VTYs. Is this still the case or has it been resolved? - If I were to set this option in make.conf, is it sufficient to simply force a recompilation of every port on the machine via portupgrade, or is there a better way? TIA, -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 23:57:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 900C4246 for ; Mon, 10 Feb 2014 23:57:49 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49CC61854 for ; Mon, 10 Feb 2014 23:57:48 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1ANvdJx063178 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 10 Feb 2014 17:57:39 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F96773.7040503@tundraware.com> Date: Mon, 10 Feb 2014 17:57:39 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F86768.9000109@googlemail.com> <52F8E8C6.2060909@tundraware.com> <20140210152407.GB1629@glenbarber.us> <52F8F426.9000003@tundraware.com> <20140210160736.GC1629@glenbarber.us> <52F93929.1070203@tundraware.com> <20140210204339.GI1629@glenbarber.us> <52F93AFF.9090806@tundraware.com> <20140210205902.GJ1629@glenbarber.us> In-Reply-To: <20140210205902.GJ1629@glenbarber.us> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 17:57:39 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1ANvdJx063178 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:57:49 -0000 On 02/10/2014 02:59 PM, Glen Barber wrote: > There are two things to consider though. I'm not cranking the number of > '-j' as high as it probably can go. I'm intentionally limiting it to > 'j10' and '-j6' in order to do parallel builds. I'm sure '-j24' or > higher in this case would reduce overall build time. Noted. > > I'm just not comfortable doing that, because there are a few (sometimes > easily-triggered, other times not so easily-triggered) race conditions > that can cause the builds to fall over to easily. So limiting to > a relatively safe number, scaling out certainly does help. > I have seen this already trying to crank up the process from j8 to j16. Thanks for the insight and help. Most interesting. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:05:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D403D4D3 for ; Tue, 11 Feb 2014 00:05:42 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9CC1924 for ; Tue, 11 Feb 2014 00:05:42 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1B05Xng021727 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 18:05:34 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F9694D.2060609@tundraware.com> Date: Mon, 10 Feb 2014 18:05:33 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warren Block Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> In-Reply-To: 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 18:05:34 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1B05Xng021727 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:05:42 -0000 On 02/10/2014 09:03 AM, Warren Block wrote: > On Sun, 9 Feb 2014, Tim Daneliuk wrote: > >> So is the bounding function here actually CPU not IO? Am I missing >> something? > > Yes, it mostly is CPU. Make sure you are running powerd on that i5, it enables turbo mode and gives a noticeable speed increase. I enabled the various turbo features on the mobo and rebooted with powerd turned on. It appears to knock about 2 minutes off the build, but I need a bigger baseline than one try to confirm this. > > Also, consider using -DNO_CLEAN, leaving all the untouched object files in place for make to find and skip. I've seen buildworld times under a minute with that on my i5 and SSD. There are downsides (uname is not always updated correctly), but removing /usr/obj every so often and starting from scratch will fix that. Right after I did a complete buildworld/kernel, I ran it again with this option enabled. Essentially, I wanted to see how long it takes the make infrastructure to figure out it has nothing to do... about 2 minutes appears to be the answer. If I were sure that everything was being picked up properly (including uname), I'd do it this way every time ;) Thanks for the feedback and help. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:13:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B0B8686 for ; Tue, 11 Feb 2014 00:13:36 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1745819EC for ; Tue, 11 Feb 2014 00:13:35 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1B0DR3I029097 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 18:13:27 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52F96B27.4090509@tundraware.com> Date: Mon, 10 Feb 2014 18:13:27 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tom Evans Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 10 Feb 2014 18:13:27 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1B0DR3I029097 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:13:36 -0000 On 02/10/2014 09:55 AM, Tom Evans wrote: > Does poudriere buildworld on tmpfs if you have USE_TMPFS=all? That > might give you an absolute baseline. I'm not exactly sure what you're suggesting here. I think of poudriere as a way to build ports trees rapidly. Can it also be used to compile arbitrary (non ports) programs? -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:21:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B200E7F9 for ; Tue, 11 Feb 2014 00:21:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66A971A8E for ; Tue, 11 Feb 2014 00:21:44 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1B0Lgg0039905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 16:21:43 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1B0LeBp039903; Mon, 10 Feb 2014 16:21:40 -0800 (PST) (envelope-from jmg) Date: Mon, 10 Feb 2014 16:21:40 -0800 From: John-Mark Gurney To: kpneal@pobox.com Subject: Re: where to find FreeBSD torrent file Message-ID: <20140211002139.GH34851@funkthat.com> Mail-Followup-To: kpneal@pobox.com, "illoai@gmail.com" , freebsd-stable@freebsd.org, Shankar , lists@eitanadler.com References: <1391945788.29258.YahooMailNeo@web140803.mail.bf1.yahoo.com> <20140210023754.GC99503@neutralgood.org> <20140210034455.GS89104@funkthat.com> <20140210041005.GA50898@neutralgood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140210041005.GA50898@neutralgood.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 10 Feb 2014 16:21:43 -0800 (PST) Cc: lists@eitanadler.com, freebsd-stable@freebsd.org, "illoai@gmail.com" , Shankar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:21:45 -0000 kpneal@pobox.com wrote this message on Sun, Feb 09, 2014 at 23:10 -0500: > In your case "the other person"'s seeder didn't know to contact your seeder. > That's why it didn't work. Except that DHT is designed to allow the leacher to "find" the seeder through the DHT... It is possible that there are multiple disjoint DHTs out there, but I would imagine it is hard to keep them from merging together... I was trying a magnet link where the leacher uses the DHT to find someone who has the torrent metadata and d/l the torrent metadata... It was probably a problem w/ my torrent client not being able to serve up the metadata... > I still daily see people downloading various FreeBSD torrents from my > server. But the level of traffic is a fraction of what I saw when the > official FreeBSD tracker was running. The only tracker I use now is the > one for Project Gutenburg. So it seems there's a set of people who are > both interested in Gutenburg _and_ FreeBSD. But that's a fraction of the > people wanting to torrent FreeBSD. I also see the occasional d/l, but I don't use a tracker anymore, just DHT... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:23:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FE9C977 for ; Tue, 11 Feb 2014 00:23:02 +0000 (UTC) Received: from teaspoon.mischlersflorist.com (rrcs-72-45-221-198.nys.biz.rr.com [72.45.221.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A81241AB3 for ; Tue, 11 Feb 2014 00:23:01 +0000 (UTC) Received: from [192.168.254.253] ([192.168.254.253]) by teaspoon.mischlersflorist.com (8.14.7/8.14.5) with ESMTP id s1B0GCWn011638 for ; Mon, 10 Feb 2014 19:16:12 -0500 (EST) (envelope-from dave@mischler.com) Subject: Is "nc" broken in 10.0? From: Dave Mischler To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Feb 2014 19:16:11 -0500 Message-ID: <1392077771.9826.4.camel@barrel.mischler.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dave@mischler.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:23:02 -0000 the 'nc' program doesn't seem to close the network connection anymore when it reaches EOF. This worked fine in 9.x. Can somebody else confirm this broken behavior? Example: On one session, listen for an incoming connection: % nc -l 5101 On another session, open an outgoing connection, then close the input: % nc 127.0.0.1 5101 ^D The session will not close. It doesn't seem to matter if the input is a terminal, file, pipe, or whatever else you can think of. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:28:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A87D3B55 for ; Tue, 11 Feb 2014 00:28:51 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69BBE1AF9 for ; Tue, 11 Feb 2014 00:28:50 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1B0Sosb040034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 16:28:50 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1B0Snbt040033; Mon, 10 Feb 2014 16:28:49 -0800 (PST) (envelope-from jmg) Date: Mon, 10 Feb 2014 16:28:49 -0800 From: John-Mark Gurney To: Dave Mischler Subject: Re: Is "nc" broken in 10.0? Message-ID: <20140211002849.GI34851@funkthat.com> Mail-Followup-To: Dave Mischler , freebsd-stable@freebsd.org References: <1392077771.9826.4.camel@barrel.mischler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1392077771.9826.4.camel@barrel.mischler.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 10 Feb 2014 16:28:50 -0800 (PST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:28:51 -0000 Dave Mischler wrote this message on Mon, Feb 10, 2014 at 19:16 -0500: > the 'nc' program doesn't seem to close the network connection anymore > when it reaches EOF. This worked fine in 9.x. Can somebody else > confirm this broken behavior? > > Example: > > On one session, listen for an incoming connection: > > % nc -l 5101 > > On another session, open an outgoing connection, then close the input: > > % nc 127.0.0.1 5101 > ^D > > The session will not close. It doesn't seem to matter if the input is a > terminal, file, pipe, or whatever else you can think of. I can't find the thread, but try adding the -N flag to nc: -N shutdown(2) the network socket after EOF on the input. Some servers require this to finish their work. For example, if you were POST'ing to an older HTTP/1.0 website w/o a content-length header, need this for the server to know that no more data is coming and to process the request and send you you're response.. nc was previously broken where a local EOF would shutdown the entire process instead of waiting for the remote side to finish sending... for example: cat << EOF | nc -N webserver 80 POST /cgi-bin/printenv HTTP/1.0 Host: webserver post=data&more=info EOF -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 00:28:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFCADB56; Tue, 11 Feb 2014 00:28:56 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A149C1AFA; Tue, 11 Feb 2014 00:28:56 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 3066421136; Tue, 11 Feb 2014 00:28:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 3066421136 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 10 Feb 2014 19:28:53 -0500 From: Glen Barber To: Dave Mischler Subject: Re: Is "nc" broken in 10.0? Message-ID: <20140211002853.GL1629@glenbarber.us> References: <1392077771.9826.4.camel@barrel.mischler.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M9YpAf2t6OxtMGzg" Content-Disposition: inline In-Reply-To: <1392077771.9826.4.camel@barrel.mischler.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:28:56 -0000 --M9YpAf2t6OxtMGzg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 07:16:11PM -0500, Dave Mischler wrote: > the 'nc' program doesn't seem to close the network connection anymore > when it reaches EOF. This worked fine in 9.x. Can somebody else > confirm this broken behavior? >=20 > Example: >=20 > On one session, listen for an incoming connection: >=20 > % nc -l 5101 >=20 > On another session, open an outgoing connection, then close the input: >=20 > % nc 127.0.0.1 5101 > ^D >=20 > The session will not close. It doesn't seem to matter if the input is a > terminal, file, pipe, or whatever else you can think of. >=20 I think you want the '-N' flag. ------------------------------------------------------------------------ r249499 | delphij | 2013-04-15 01:31:59 -0400 (Mon, 15 Apr 2013) | 8 lines MFV r249496,249498. The most visible change is that we no longer shuts down the connection when stdin closes, by default. This matches Hobbit's original netcat and GNU netcat. Old behavior can be restored with the new -N flag. ------------------------------------------------------------------------ Glen --M9YpAf2t6OxtMGzg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJS+W7FAAoJELls3eqvi17Qm74P/RKnNZe344U9ao6LTmNYQ4hr rZ2zT79EL5pxG0xfrDUeWJAinAT/VIO5ciAaDAvaQdl/jdQ/wR0QZz3Q4TTycHK2 SB2t4dWycSOCcsDTKwxe9eeArf5HwHmocF0TS+oeR7UxJMCDScoDAKpnaV0Ncpom Du0Btk0KLku1kh+HD19rtwU1K8tf1K9bdU5Wy44sp9FemmvgaqqQ2ihWxWxOA0H5 i+j+WEryWePFJuySsxLicOLVGMXA1fpTtuMS6h1S10IgX/sD4wzIg2XYzEB3HD7B 6iFtH2QjC71KtEt9/70gBMqXK/gig3amuZ6i7abTl2N02ERm0Nl+FvTnJUy9R+99 l0oPA7QexH2J9zcOzhY4Js+ONoo7SDwH4tneIcHCniY+VA6/JLTvc9gkHRJUD3uD 9BxtBsbFGUACi67BT8cwIwwAiS3KCanauSqmpMysYI5j74hMuqxB/9rP6j0+yamK L7HetMhCBHsBOklFW/bnyk2QOzMfSYBL6eaEsdr3PKCFMIvQVGB2ckL85VyTYKzG OmQYhNcgF69R7pnX0uajUYFGAactWcJRY/nZ1uO5uOLbnoLpTEsL4peUsisvQWfN IuVX12qKLS4EGaSzIobin9sQTZfudbe232FNdrHMpGBS6xB5HS05av7OVrOizhpH yhyWKspdbxGnaghGD0fO =a7ux -----END PGP SIGNATURE----- --M9YpAf2t6OxtMGzg-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 02:32:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D3E7F82; Tue, 11 Feb 2014 02:32:18 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9FC315E1; Tue, 11 Feb 2014 02:32:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1B2WAcT023863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Feb 2014 19:32:10 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1B2W98U023860; Mon, 10 Feb 2014 19:32:10 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 10 Feb 2014 19:32:09 -0700 (MST) From: Warren Block To: Tim Daneliuk Subject: Re: Followup On Recent MCA Madness. WAS: Need Help With MCA Code In-Reply-To: <52F96681.3080604@tundraware.com> Message-ID: References: <52E73717.3000503@tundraware.com> <52EBE1FA.2040603@tundraware.com> <52ED5C97.8030503@tundraware.com> <201402101618.43685.jhb@freebsd.org> <52F96681.3080604@tundraware.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 10 Feb 2014 19:32:10 -0700 (MST) Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:32:18 -0000 On Mon, 10 Feb 2014, Tim Daneliuk wrote: > On 02/10/2014 03:18 PM, John Baldwin wrote: >>> On Saturday, February 01, 2014 3:44:07 pm Tim Daneliuk wrote: > > >>> Now, if I could just figure out how to get stock X to >>> run at 1920x1080 on HD4600 graphics. Apparently neither the >>> intel of vesa drivers know how to do this, or at least I've >>> had no luck with it. The intel driver doesn't even recognize >>> the hardware as something it supports. >>> >>> "X on a server?" you say? Yes, for intermittent use of fluxbox >>> to run a bunch of xterms. >> >> For the Intel graphics you want to use i915kms. However, you need to build >> your ports with 'WITH_NEW_XORG=yes' set in /etc/make.conf. There are more >> details about this on the wiki. >> >> https://wiki.freebsd.org/Graphics Important note: fourth-generation (Haswell) Intel CPU graphics are not supported yet. No idea on a time frame for that. > I've been considering this, but I have a few more questions, if I may: > > - There was a time when the new Xorg stuff did not play well with VTYs. > Is this still the case or has it been resolved? See https://wiki.freebsd.org/Newcons This has not yet been MFCed to 10-stable, so at present consoles are not visible after X has been started. Commands can still be typed, though. > - If I were to set this option in make.conf, is it sufficient to simply > force a recompilation of every port on the machine via portupgrade, > or is there a better way? The better way is shown on the KMS page, a bit farther down: https://wiki.freebsd.org/Graphics#Installing_KMS_Ports From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 04:16:29 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D7EC21F; Tue, 11 Feb 2014 04:16:29 +0000 (UTC) Received: from um-tip1-missouri-out.um.umsystem.edu (um-tip1-missouri-out.um.umsystem.edu [198.209.49.135]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D6521171; Tue, 11 Feb 2014 04:16:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABij+VLPoJ7I/2dsb2JhbABYgwyBD790FnSCLHgTASkWGAMCAQIBICcEAQwIAQGIAcJzhyWTLwSJEKE6gy2CKg X-IPAS-Result: AgsFABij+VLPoJ7I/2dsb2JhbABYgwyBD790FnSCLHgTASkWGAMCAQIBICcEAQwIAQGIAcJzhyWTLwSJEKE6gy2CKg Received: from um-tcas3.um.umsystem.edu ([207.160.158.200]) by um-tip1-exch-relay.um.umsystem.edu with ESMTP; 10 Feb 2014 22:15:08 -0600 Received: from UM-MBX-N02.um.umsystem.edu ([169.254.5.113]) by UM-TCAS3.um.umsystem.edu ([207.160.158.200]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 22:15:08 -0600 From: "Montgomery-Smith, Stephen" To: FreeBSD Ports , "freebsd-stable@freebsd.org" Subject: Concerning pkgng Thread-Topic: Concerning pkgng Thread-Index: AQHPJt/YBr29SRuI/ESjvzo6gvfMdA== Date: Tue, 11 Feb 2014 04:15:07 +0000 Message-ID: <52F9A3C9.6090804@missouri.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [207.160.158.206] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <98F9A5A44133B245AFCD4EEA03344490@missouri.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 04:16:29 -0000 So I have started using pkgng. It is extremely easy to convert, it runs very fast, and I really like it. However, it would be nice if the old pkg_install, pkg_info, etc programs were somehow disabled on FreeBSD-8. Maybe they could look inside /etc/make.conf and see if /var/db/pkg/local.sqlite exists, and then decide not to operate. The reason for this is because I can easily see me accidentally doing pkg_delete instead of pkg delete. And especially since pkg convert seems to leave all the old directories in /var/db/pkg, I can see this creating quite a mess. I know I can simply delete the pkg_delete, pkg_info binaries. But I'll have to remember to do that each time I remake world. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 05:01:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92DB18F3 for ; Tue, 11 Feb 2014 05:01:30 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 6B65714D3 for ; Tue, 11 Feb 2014 05:01:30 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-168-41-64.range86-168.btcentralplus.com [86.168.41.64]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 95A2245060; Tue, 11 Feb 2014 05:01:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 95A2245060 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1392094883; bh=PFbw7ElOtk+xN+PH3/UheFlxmooI8PBvw6NRqLR2bQE=; h=Date:From:To:Subject:In-Reply-To; b=0EZXlhzibfuHfM2/00Bv41tUAVlNHjvlXtU5K1Btr6ctfZP4XVE8eBLrpomeW0+e1 GCPb2+wRtdyhvMZg4GbozdlS99oiCJ5OEBYgopZ0U05Pqsy3aBpMC5Qppp4D30Gd6U Be39T5gMU3E0g/oBeKAzyOR1yh14PpsWAgxciyjM= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 940AA10A9D; Tue, 11 Feb 2014 05:01:19 +0000 (GMT) Date: Tue, 11 Feb 2014 05:01:19 +0000 From: Ben Morrow To: stephen@missouri.edu, freebsd-stable@freebsd.org Subject: Re: Concerning pkgng Message-ID: <20140211050114.GA7990@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F9A3C9.6090804@missouri.edu> X-Newsgroups: gmane.os.freebsd.devel.ports,gmane.os.freebsd.stable User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 05:01:30 -0000 Quoth "Montgomery-Smith, Stephen" : > So I have started using pkgng. It is extremely easy to convert, it runs > very fast, and I really like it. > > However, it would be nice if the old pkg_install, pkg_info, etc programs > were somehow disabled on FreeBSD-8. Maybe they could look inside > /etc/make.conf and see if /var/db/pkg/local.sqlite exists, and then > decide not to operate. > > The reason for this is because I can easily see me accidentally doing > pkg_delete instead of pkg delete. And especially since pkg convert > seems to leave all the old directories in /var/db/pkg, I can see this > creating quite a mess. > > I know I can simply delete the pkg_delete, pkg_info binaries. But I'll > have to remember to do that each time I remake world. Put WITHOUT_PKGTOOLS=1 in your /etc/src.conf. (Remember to make delete-old next time you build world.) Ben From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 05:40:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B880D4D; Tue, 11 Feb 2014 05:40:34 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC5C816FC; Tue, 11 Feb 2014 05:40:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s1B5eMeF087630; Mon, 10 Feb 2014 21:40:22 -0800 (PST) (envelope-from freebsd@pki2.com) Subject: Re: Squid aufs crashes under 10.0 From: Dennis Glatting To: Florian Smeets In-Reply-To: <52F9247E.3020307@smeets.im> References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> <1392045675.20238.9.camel@btw.pki2.com> <52F9247E.3020307@smeets.im> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 10 Feb 2014 21:40:22 -0800 Message-ID: <1392097222.38537.38.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1B5eMeF087630 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: Dimitry Andric , Pavel Timofeev , freebsd-stable stable , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 05:40:34 -0000 On Mon, 2014-02-10 at 20:11 +0100, Florian Smeets wrote: > On 10/02/14 16:21, Dennis Glatting wrote: > > On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote: > >> So what should I do? > >> Write a PR to squid's bugzilla with link to this thread? > >> Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't > >> look at PRs about squid). > >> And it seems like this problem is retaled to all of squid ports, not > >> only to www/squid33. > >> > > > > Good question. I don't know. I ported 3.4 and sent email to the > > maintainer and to the list. Zip in response. > > > > I plan to take care of it this week. (squid34 + aufs patches) > My stuff here: fetch http://www.pki2.com/squid34.tar > Florian > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 10:04:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7DB97B2 for ; Tue, 11 Feb 2014 10:04:26 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E51A1E9A for ; Tue, 11 Feb 2014 10:04:26 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id hr13so5690604lab.17 for ; Tue, 11 Feb 2014 02:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2u25BNG0HmHKSfux26ei9BRdAjNzqEw0kNd404NuL3U=; b=dt6JwycmbzNjUHbXkwhd9nQ7XnGYjbtjmW/qhnyHpm5IOllPUDqdixdxF9rUjA/TFW E+Ed3eS3C8ZysTU/ka8CfcSjn1JPZmiQrbZR7hqezsYihriDyTyBnd0gTsqUJ0Cc+MtN RzX3olSbgLqtpbQOInU06ZyL4QWgwDF63QI6TIHSC65hj/pMdsoaRNKvU4VAGS6W3toq sXBfv+lskrbvvxUP4OhGtY6mQe8yYW0FImslDO6om54LDXr8a/T02ArcFWNbrn2uyNV/ qodIFON3H58YUBOh3GxWjABO2ucf7Inp/aqEK3W6701cKrbEx5GuRR9/BR1ASMDrm5TP cn4Q== MIME-Version: 1.0 X-Received: by 10.112.27.239 with SMTP id w15mr464826lbg.60.1392113064360; Tue, 11 Feb 2014 02:04:24 -0800 (PST) Received: by 10.112.0.205 with HTTP; Tue, 11 Feb 2014 02:04:24 -0800 (PST) In-Reply-To: <52F96B27.4090509@tundraware.com> References: <52F84AF8.8050007@tundraware.com> <52F96B27.4090509@tundraware.com> Date: Tue, 11 Feb 2014 10:04:24 +0000 Message-ID: Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound From: Tom Evans To: Tim Daneliuk Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 10:04:26 -0000 On Tue, Feb 11, 2014 at 12:13 AM, Tim Daneliuk wrote: > On 02/10/2014 09:55 AM, Tom Evans wrote: >> >> Does poudriere buildworld on tmpfs if you have USE_TMPFS=all? That >> might give you an absolute baseline. > > > I'm not exactly sure what you're suggesting here. I think of > poudriere as a way to build ports trees rapidly. Can it > also be used to compile arbitrary (non ports) programs? Poudriere starts by installing a base jail on which it compiles packages. If you ask it nicely, it will do so by checking out/updating a tree from SVN and compiling it. I was wondering if you had set USE_TMPFS=all, whether it would do that build on tmpfs. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 18:05:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C90EC357 for ; Tue, 11 Feb 2014 18:05:23 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AF9E1DC8 for ; Tue, 11 Feb 2014 18:05:23 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so8057164pbc.2 for ; Tue, 11 Feb 2014 10:05:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=Ha4MD2gbG9wJozkpC9ytqmo5XzdaUdJPhvhE1Pt+OOI=; b=UOolyvnwNlKECt3ngoBI9/Q+TfeXZE49mBg3JzCwkT5MUOM7k1GPeDTwziWExuFVWX QYKFoOKwjoldsgayWcwAsRuVXPk3Yvzc2ulonE5q1iOZz5S7APwh/yYEILb3M77TZoj7 o/qrK0RpDR+A8NxdzNjhz+TvX/9ElNfVOVN4m9bTlrRf+ab6ESQu4hX5HxYfcbydNkAl 4iqnTDdyhcLXVvbDklCBVVEDCXgmFxV6ZrTH2Q3I7FtNzLJJ/NIB8PXdIju1mBZYpfx4 vwJl6ycql43rnW9n3K/NT00AfVbKdriLKzRrH+KDkmOxvY2Sv8A+4uGrXgvGuWgYn2+k Iqow== X-Gm-Message-State: ALoCoQkmJ8S4xyaSnUfA8p2m8zstpavXp5iixtA2VaUZV0gN8CpF7WBCLbRj3YpBX9M3gWuW70fO X-Received: by 10.67.2.106 with SMTP id bn10mr33923187pad.38.1392141917575; Tue, 11 Feb 2014 10:05:17 -0800 (PST) Received: from [192.168.10.2] ([187.210.81.114]) by mx.google.com with ESMTPSA id lh13sm140848684pab.4.2014.02.11.10.05.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 10:05:17 -0800 (PST) Message-ID: <52FA665B.8050802@motumweb.com> Date: Tue, 11 Feb 2014 12:05:15 -0600 From: =?ISO-8859-1?Q?Efra=EDn_D=E9ctor?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: CARP in FreeBSD10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:05:23 -0000 Hello. I am triying to enable CARP on FreeBSD 10.0-RELEASE, I have read the documentation (http://www.freebsd.org/doc/en/books/handbook/carp.html) I tried to enable the module of carp, putting if_carp_load="YES" on /boot/loader.conf, rebooted and after that I tried to enable it using the command/ifconfig carp0 create/. However after that I get the following message: "ifconfig: SIOCIFCREATE2: Invalid argument". Then after that I rebuilded the kernel putting the option: device carp But afther rebuilding and installing I still get the message "ifconfig: SIOCIFCREATE2: Invalid argument". Can you guys point me in the right direction?. What am I doing wrong?. Thank you very much From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 18:36:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD606FE1 for ; Tue, 11 Feb 2014 18:36:25 +0000 (UTC) Received: from mta1-filtered.netlife.no (mail.netlife.no [62.92.26.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8775D1207 for ; Tue, 11 Feb 2014 18:36:24 +0000 (UTC) Received: from amavis3.netlife.no (unknown [10.115.1.13]) by mta1-filtered.netlife.no (Postfix) with ESMTP id CDFE7308B2D; Tue, 11 Feb 2014 19:27:57 +0100 (CET) X-Virus-Scanned: amavisd-new at netlife.no Received: from mta1-submission.netlife.no ([62.92.26.226]) by amavis3.netlife.no (amavis3.netlife.no [10.115.1.13]) (amavisd-new, port 10026) with ESMTP id f0dALTlOuygm; Tue, 11 Feb 2014 18:27:57 +0000 (UTC) Received: from [10.0.0.41] (unknown [195.1.220.218]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: erik@tefre.com) by mta1-submission.netlife.no (Postfix) with ESMTPSA id 970B5308B28; Tue, 11 Feb 2014 19:27:57 +0100 (CET) Message-ID: <52FA6BAD.7030302@tefre.com> Date: Tue, 11 Feb 2014 19:27:57 +0100 From: Erik Stian Tefre User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Efra=EDn_D=E9ctor?= , freebsd-stable@freebsd.org Subject: Re: CARP in FreeBSD10 References: <52FA665B.8050802@motumweb.com> In-Reply-To: <52FA665B.8050802@motumweb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:36:25 -0000 On 11. feb. 2014 19:05, Efraín Déctor wrote: > Hello. > > I am triying to enable CARP on FreeBSD 10.0-RELEASE, I have read the > documentation (http://www.freebsd.org/doc/en/books/handbook/carp.html) > I tried to enable the module of carp, putting if_carp_load="YES" on > /boot/loader.conf, rebooted and after that I tried to enable it using > the command/ifconfig carp0 create/. However after that I get the > following message: > > "ifconfig: SIOCIFCREATE2: Invalid argument". > > Then after that I rebuilded the kernel putting the option: > > device carp > > But afther rebuilding and installing I still get the message > "ifconfig: SIOCIFCREATE2: Invalid argument". [...] http://people.freebsd.org/~glebius/newcarp/README And of course: man carp -- Erik From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 18:43:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A10DF602 for ; Tue, 11 Feb 2014 18:43:49 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6ED8B12ED for ; Tue, 11 Feb 2014 18:43:49 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id rd3so7975578pab.5 for ; Tue, 11 Feb 2014 10:43:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eucPz9Si6KF1eaThYqAwJshkCaVeoe/FUtRRJRY1238=; b=Lhv6VZYu5xOv++spg5/uAaJHyamGByZNpDNdt7ONvGGUq0y+11v7sz4eJB+Z81kQ4g SG0/4Y3T3pxnO6Vd5O1EHcpE7D+Nj15fifO7YLUnMB4HRV55BLxyxqX8xrUi3BmvpLVH 4OX7pWoNdj4xIcIihqyZQhaoUrZJ2Cs8BSfjYriweLdPAoDX4Sqmclu90dzrjJ15Y/za MwsvPg1uhJDycQaFi5n7swfZW0WXVDR3hQqrJwFmE1vJhWoZXP7L9GQUNsLAtcJAndp5 rRCC0LNQjV4mITOvYo5abSV9RgedorrGeduI4ap/TkP4sXpcm8xHPxO/t8xTnSYMAk42 J8YA== X-Gm-Message-State: ALoCoQn1ecwpAMd37dQUfrcqlJC7i/MD9hqbZBiAbr1+ijyGbPmRINL9FAMg3s8pydliNT3+T+DT X-Received: by 10.68.200.74 with SMTP id jq10mr6801585pbc.169.1392144223455; Tue, 11 Feb 2014 10:43:43 -0800 (PST) Received: from [192.168.10.2] ([187.210.81.114]) by mx.google.com with ESMTPSA id tu3sm55444859pbc.40.2014.02.11.10.43.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 10:43:42 -0800 (PST) Message-ID: <52FA6F5C.6070500@motumweb.com> Date: Tue, 11 Feb 2014 12:43:40 -0600 From: =?ISO-8859-1?Q?Efra=EDn_D=E9ctor?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Erik Stian Tefre , freebsd-stable@freebsd.org Subject: Re: CARP in FreeBSD10 References: <52FA665B.8050802@motumweb.com> <52FA6BAD.7030302@tefre.com> In-Reply-To: <52FA6BAD.7030302@tefre.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:43:49 -0000 El 11/02/2014 12:27 p.m., Erik Stian Tefre escribió: > http://people.freebsd.org/~glebius/newcarp/README > > And of course: > man carp > > -- > Erik Thank you very much. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 18:50:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6310A922 for ; Tue, 11 Feb 2014 18:50:26 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2120713A9 for ; Tue, 11 Feb 2014 18:50:25 +0000 (UTC) Received: from [10.219.131.92] ([66.175.245.1]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1BIo7Ot020261 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 11 Feb 2014 12:50:08 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52FA70DA.7050601@tundraware.com> Date: Tue, 11 Feb 2014 12:50:02 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F96B27.4090509@tundraware.com> In-Reply-To: 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Tue, 11 Feb 2014 12:50:08 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1BIo7Ot020261 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:50:26 -0000 On 02/11/2014 04:04 AM, Tom Evans wrote: > On Tue, Feb 11, 2014 at 12:13 AM, Tim Daneliuk wrote: >> On 02/10/2014 09:55 AM, Tom Evans wrote: >>> >>> Does poudriere buildworld on tmpfs if you have USE_TMPFS=all? That >>> might give you an absolute baseline. >> >> >> I'm not exactly sure what you're suggesting here. I think of >> poudriere as a way to build ports trees rapidly. Can it >> also be used to compile arbitrary (non ports) programs? > > Poudriere starts by installing a base jail on which it compiles > packages. If you ask it nicely, it will do so by checking out/updating > a tree from SVN and compiling it. I was wondering if you had set > USE_TMPFS=all, whether it would do that build on tmpfs. > As an aside here, having nothing to do with poudriere, does buildworld/kernel even use /tmp or otherwise access tmpfs? It seems to produce temporary output somewhere deep in /usr/obj. Is there a way to get it to use tmpfs or write it's output to /tmp instead? -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 22:05:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B91D9E57 for ; Tue, 11 Feb 2014 22:05:15 +0000 (UTC) Received: from triton.bsd-unix.net (triton.bsd-unix.net [199.58.160.195]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6281795 for ; Tue, 11 Feb 2014 22:05:15 +0000 (UTC) Received: from [172.17.2.6] (pool-71-178-237-60.washdc.fios.verizon.net [71.178.237.60]) (Authenticated sender: ajc) by triton.bsd-unix.net (Postfix) with ESMTPSA id D5F1992C3 for ; Tue, 11 Feb 2014 16:57:07 -0500 (EST) Message-ID: <52FA9CB3.4060609@halplant.com> Date: Tue, 11 Feb 2014 16:57:07 -0500 From: "Andrew J. Caines" Organization: H.A.L. Plant User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F96B27.4090509@tundraware.com> <52FA70DA.7050601@tundraware.com> In-Reply-To: <52FA70DA.7050601@tundraware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:05:15 -0000 On 02/11/2014 01:50 PM, Tim Daneliuk wrote: > does buildworld/kernel even use /tmp or otherwise access tmpfs? It > seems to produce temporary output somewhere deep in /usr/obj. Is > there a way to get it to use tmpfs or write it's output to /tmp > instead? I've been using a mfs for /usr/obj and WRKDIRPREFIX for ports for years. md /usr/obj mfs rw,async,noatime,noauto,-s6g 0 0 md /var/work mfs rw,async,noatime,noauto,-s2g 0 0 Makes cleanup quick and easy, too. -- -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing From owner-freebsd-stable@FreeBSD.ORG Tue Feb 11 22:10:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 316724EE for ; Tue, 11 Feb 2014 22:10:05 +0000 (UTC) Received: from mail.ultra-secure.de (static.88-198-178-88.clients.your-server.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 895EC1803 for ; Tue, 11 Feb 2014 22:10:03 +0000 (UTC) Received: (qmail 92575 invoked by uid 89); 11 Feb 2014 22:08:51 -0000 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by static.88-198-178-88.clients.your-server.de with ESMTPA; 11 Feb 2014 22:08:51 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: CARP in FreeBSD10 From: Rainer Duffner In-Reply-To: <52FA6BAD.7030302@tefre.com> Date: Tue, 11 Feb 2014 23:08:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D8778FD-67A1-4296-9BF6-4B896F057F14@ultra-secure.de> References: <52FA665B.8050802@motumweb.com> <52FA6BAD.7030302@tefre.com> To: Erik Stian Tefre X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Stable , =?windows-1252?Q?Efra=EDn_D=E9ctor?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:10:05 -0000 Am 11.02.2014 um 19:27 schrieb Erik Stian Tefre : > On 11. feb. 2014 19:05, Efra=EDn D=E9ctor wrote: >> Hello. >>=20 >> I am triying to enable CARP on FreeBSD 10.0-RELEASE, I have read the = documentation (http://www.freebsd.org/doc/en/books/handbook/carp.html) I = tried to enable the module of carp, putting if_carp_load=3D"YES" on = /boot/loader.conf, rebooted and after that I tried to enable it using = the command/ifconfig carp0 create/. However after that I get the = following message: >>=20 >> "ifconfig: SIOCIFCREATE2: Invalid argument". >>=20 >> Then after that I rebuilded the kernel putting the option: >>=20 >> device carp >>=20 >> But afther rebuilding and installing I still get the message = "ifconfig: SIOCIFCREATE2: Invalid argument". > [...] >=20 > http://people.freebsd.org/~glebius/newcarp/README >=20 > And of course: > man carp >=20 BTW: the handbook=92s CARP-section still shows the old syntax. I=92ve opened a PR for this http://www.freebsd.org/cgi/query-pr.cgi?pr=3Ddocs/186464 The man-page is correct, though. But the FreeBSD handbook is actually quite good, most of the time, and = sometimes contains more examples than the man-pages. So, I guess a lot of people actually first go to the handbook these days = (especially those from the younger generation, who do *everything* in = their browser) ;-) With CARP being so different between 9 and 10, I=92d advocate to have = both syntaxes reflected in the handbook (if possible). From owner-freebsd-stable@FreeBSD.ORG Wed Feb 12 01:21:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AACE40D for ; Wed, 12 Feb 2014 01:21:44 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B2EF192F for ; Wed, 12 Feb 2014 01:21:43 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s1C1LZsL004401 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 11 Feb 2014 19:21:35 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52FACC9F.3000009@tundraware.com> Date: Tue, 11 Feb 2014 19:21:35 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: And Here I Thought buildworld/makeworld Was IO Bound References: <52F84AF8.8050007@tundraware.com> <52F96B27.4090509@tundraware.com> <52FA70DA.7050601@tundraware.com> <52FA9CB3.4060609@halplant.com> In-Reply-To: <52FA9CB3.4060609@halplant.com> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Tue, 11 Feb 2014 19:21:35 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s1C1LZsL004401 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 01:21:44 -0000 On 02/11/2014 03:57 PM, Andrew J. Caines wrote: > On 02/11/2014 01:50 PM, Tim Daneliuk wrote: >> does buildworld/kernel even use /tmp or otherwise access tmpfs? It >> seems to produce temporary output somewhere deep in /usr/obj. Is >> there a way to get it to use tmpfs or write it's output to /tmp >> instead? > > I've been using a mfs for /usr/obj and WRKDIRPREFIX for ports for years. > > md /usr/obj mfs rw,async,noatime,noauto,-s6g 0 0 > md /var/work mfs rw,async,noatime,noauto,-s2g 0 0 > > Makes cleanup quick and easy, too. > > Final Results: I did a number of different timings including symlinking /usr/obj to /tmp/obj when /tmp is a tmfs as well as mounting /usr/obj on an md as suggested above. In all cases, the time to do the buildworld/kernels was about the same. So, I conclude the following: When running on an SSD, at least the one I am using, the performance is bounded by CPU, not disk. Many thanks to all who took the time to answer my stupid questions ... ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 12 08:19:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E54AF3D for ; Wed, 12 Feb 2014 08:19:01 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1FA314A6 for ; Wed, 12 Feb 2014 08:19:00 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id f73so8116410yha.31 for ; Wed, 12 Feb 2014 00:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H3K5yMmZVaJGW3aIr1tSpWj4fXU2U2FUaM7kfeqSQBU=; b=Jo5CXgw8Ox7TABd8Y/bCWs4sbY8Nu4oRKsXjnIfihxqv2U+Q7A4n9HXxbac/xEO7Ki nbkpj/gwyyiLwwjSbg/Wm2ddI3vgkgpZsg/xu+HD7Piuj1xpviVVquMYzd6Xx0RVSvgJ A+H4A6Jt7VDFk0goD/KgN3N4ZT5Q+3xmx9JsVQlAeEmznzuZBdS1/EBrXvMSI3OJzeHR uejYJyoyKyVZrSwislN904ZlT1GEQt2HNKnbKbfVK3vbh8QT0vpJJiiTYWEsIEbDtpCv 6090+GuCD2kkX4nZXUn+AreD2SnlBhuhwABVaWJFs4P91Pw8qPe2hPDx3hm3pKhMZ6QU DuGg== MIME-Version: 1.0 X-Received: by 10.236.106.99 with SMTP id l63mr831816yhg.81.1392193140058; Wed, 12 Feb 2014 00:19:00 -0800 (PST) Received: by 10.170.136.20 with HTTP; Wed, 12 Feb 2014 00:18:59 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 08:18:59 +0000 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: krad To: Alban Hertroys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 08:19:01 -0000 have a look at this port /usr/ports/net/ntlmaps/pkg-descr it should be on the dvd. Combined with the http_proxy env variables you should be able to sit it between your ms proxy with ntlm auth and the cli tools to abstract them from the auth issue. Ive not used it myself so so hopefully it will work from you. If not maybe something could be done with squid or another socks proxy. On 7 February 2014 12:17, Alban Hertroys wrote: > Hi all, > > For an experiment @work I figured I'd install FreeBSD 10 x64 in a > VMWare virtual machine that was made available to me, but I'm kind of > stuck installing ports or packages... > > The thing is, the vmware tools provided with this version of VMWare > (VMware=AE Workstation 10.0.1 build-1379776) are packaged with a Perl > script and there it looks like there is no Perl in FreeBSD 10. > > We're behind an NT/LM authenticated proxy, which I haven't managed to > get past yet from the FreeBSD installation in the VM, so downloading > distfiles (Perl, for example) isn't currently possible. > > I created a shared folder in VMWare to store distfiles on, but > apparently I need VMWare tools installed to access such a folder, > which brings me back to the Perl problem. > > It appears that I need samba & squid to have NT/LM authentication to > get through the proxy so that I can download ports & packages, but to > obtain packages for those I need to be able to get through the proxy > first. > > How do I solve this conundrum? > > If only I had a writable CD or an USB stick here, I could use that to > transfer the files between the systems, but unfortunately I don't have > any at hand (after the weekend perhaps, if I remember to bring them). > > -- > If you can't see the forest for the trees, > Cut the trees and you'll see there is no forest. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 12 11:02:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F202223 for ; Wed, 12 Feb 2014 11:02:11 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF8314A0 for ; Wed, 12 Feb 2014 11:02:11 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id p61so5817574wes.3 for ; Wed, 12 Feb 2014 03:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=gLA+VgvcQyuCTdxTqGt06GvJCU3RDcnTqOGrH8ZhMrU=; b=W+IAikLV5aFbeV9U4oekr7mu7fyIW2zlNRkmSfGiHg62xq8greW8Vt1b+krACxpUcB N+d7kIj7b9B+43wIZ2LabQOdKfjKjs4yHHJRQ7aiQyDspQgrxFoWvfIchVz19Cqh1zRT mFLjRAP5qweTKIMdtowO/Bp7PUdYhWTUg/mpKqCzhmh28nkQukQTFIBJ7BScVfhe8aoX SpOPFtxQ3gMGGeNMzCK0Y3I79nKOWAelI4E736ix86ybul+HI0+GuiYallgP3rbmHCAB mofnV7M7xEr0z1spVs7hXcq8FTW0/kP8Na3V8E67jIanvUaxkjzpPFse5gS9iSqFU/in hN4g== X-Received: by 10.194.109.68 with SMTP id hq4mr29470801wjb.12.1392202929589; Wed, 12 Feb 2014 03:02:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.161.129 with HTTP; Wed, 12 Feb 2014 03:01:49 -0800 (PST) From: sadegh solati Date: Wed, 12 Feb 2014 14:31:49 +0330 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? To: haramrae@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 11:02:11 -0000 Hi. for Example: in directory: /usr/ports/lang/perl5.18 #make all-depends-list it's output will be something like this /usr/ports/ports-mgmt/pkg take a look at distfiles in each directory ( perl and pkg).download the exact version that mentioned there to a pc which have acces to internet . use SCP to put the downloaded files in /usr/ports/distfiles. after that go to perl folder and use "make install" (without quotes) and it should be done. Don't forget to you can't connect to ssh or scp with root user. create another user or edit /etc/sshd.conf and enable PermitRootLogin then restart sshd service. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 12 17:08:30 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73408956; Wed, 12 Feb 2014 17:08:30 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9A92917E2; Wed, 12 Feb 2014 17:08:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06549; Wed, 12 Feb 2014 19:08:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WDdIK-000EyW-UC; Wed, 12 Feb 2014 19:08:20 +0200 Message-ID: <52FBAA33.9010005@FreeBSD.org> Date: Wed, 12 Feb 2014 19:06:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable List Subject: panic: vm_page_unwire: page 0xfffffe104d4c9cd8's wire count is zero X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:08:30 -0000 I've got an odd panic on a stable/9 system: (kgdb) bt #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266 #1 0xffffffff808f9814 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff808f9d07 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80b81b45 in vm_page_unwire (m=, activate=) at /usr/src/sys/vm/vm_page.c:2018 #4 0xffffffff80b6e062 in vm_fault_unwire (map=, start=, end=4202496, fictitious=0) at /usr/src/sys/vm/vm_fault.c:1238 #5 0xffffffff80b7617f in vm_map_delete (map=0xfffffe01a8eeaaf0, start=4096, end=140737488355328) at /usr/src/sys/vm/vm_map.c:2713 #6 0xffffffff80b764e1 in vm_map_remove (map=0xfffffe01a8eeaaf0, start=4096, end=140737488355328) at /usr/src/sys/vm/vm_map.c:2903 #7 0xffffffff80b79837 in vmspace_exit (td=0xfffffe01b8056490) at /usr/src/sys/vm/vm_map.c:350 #8 0xffffffff808c2f00 in exit1 (td=0xfffffe01b8056490, rv=0) at /usr/src/sys/kern/kern_exit.c:322 #9 0xffffffff808c424e in sys_sys_exit (td=, uap=) at /usr/src/sys/kern/kern_exit.c:121 #10 0xffffffff80cec26a in amd64_syscall (td=0xfffffe01b8056490, traced=0) at subr_syscall.c:135 #11 0xffffffff80cd64c7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 (kgdb) p *entry $2 = { prev = 0xfffffe01a8eeaaf0, next = 0xfffffe01a8f02500, left = 0x0, right = 0xfffffe01b805f800, start = 4194304, end = 4202496, avail_ssize = 0, adj_free = 2093056, max_free = 140703107510272, object = { vm_object = 0xfffffe025d23b0e8, sub_map = 0xfffffe025d23b0e8 }, offset = 0, eflags = 1068, // MAP_ENTRY_COW | MAP_ENTRY_NEEDS_COPY | MAP_ENTRY_USER_WIRED | MAP_ENTRY_NOCOREDUMP protection = 5 '\005', max_protection = 7 '\a', inheritance = 1 '\001', read_ahead = 0 '\0', wired_count = 1, next_read = 2, cred = 0x0, wiring_thread = 0x0 } (kgdb) p *entry->object.vm_object $4 = { mtx = { lock_object = { lo_name = 0xffffffff80fc2940 "vm object", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 }, object_list = { tqe_next = 0xfffffe027019c828, tqe_prev = 0xfffffe0263ca0a18 }, shadow_head = { lh_first = 0x0 }, shadow_list = { le_next = 0xfffffe0263d24828, le_prev = 0xfffffe0029189a28 }, memq = { tqh_first = 0xfffffe104d4c9cd8, tqh_last = 0xfffffe10520616b0 }, root = 0xfffffe104d4c9cd8, size = 3, generation = 1, ref_count = 1, shadow_count = 0, memattr = 6 '\006', type = 2 '\002', // OBJT_VNODE flags = 4100, // OBJ_ACTIVE | OBJ_COLORED pg_color = 0, pad1 = 0, resident_page_count = 2, backing_object = 0x0, backing_object_offset = 0, pager_object_list = { tqe_next = 0x0, tqe_prev = 0x0 }, rvq = { lh_first = 0x0 }, cache = 0x0, handle = 0xfffffe0263c4b000, un_pager = { vnp = { vnp_size = 9872, writemappings = 0 }, devp = { devp_pglist = { tqh_first = 0x2690, tqh_last = 0x0 }, ops = 0x0 }, sgp = { sgp_pglist = { tqh_first = 0x2690, tqh_last = 0x0 } }, swp = { swp_bcount = 9872 } }, cred = 0x0, charge = 0, paging_in_progress = 0 } (kgdb) p *(vnode_t)entry->object.vm_object->handle $6 = { v_type = VREG, v_tag = 0xffffffff8185f1ac "zfs", v_op = 0xffffffff8186b280, v_data = 0xfffffe0263c62000, v_mount = 0xfffffe001cec09a8, v_nmntvnodes = { tqe_next = 0xfffffe025d8035f8, tqe_prev = 0xfffffe027038a620 }, v_un = { vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0 }, v_hashlist = { le_next = 0x0, le_prev = 0x0 }, v_hash = 2157506860, v_cache_src = { lh_first = 0x0 }, v_cache_dst = { tqh_first = 0x0, tqh_last = 0xfffffe0263c4b060 }, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = { lock_object = { lo_name = 0xffffffff8185f1ac "zfs", lo_flags = 108724224, lo_data = 0, lo_witness = 0x0 }, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96 }, v_interlock = { lock_object = { lo_name = 0xffffffff80f9ae39 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 }, v_vnlock = 0xfffffe0263c4b098, v_holdcnt = 3, v_usecount = 2, v_iflag = 512, // VI_ACTIVE v_vflag = 32, // VV_TEXT v_writecount = 0, v_actfreelist = { tqe_next = 0xfffffe027038a5f8, tqe_prev = 0xfffffe0263c7d708 }, v_bufobj = { bo_mtx = { lock_object = { lo_name = 0xffffffff80f9ae49 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0 }, mtx_lock = 4 }, bo_clean = { bv_hd = { tqh_first = 0x0, tqh_last = 0xfffffe0263c4b140 }, bv_root = 0x0, bv_cnt = 0 }, bo_dirty = { bv_hd = { tqh_first = 0x0, tqh_last = 0xfffffe0263c4b160 }, bv_root = 0x0, bv_cnt = 0 }, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff81316f20, bo_bsize = 131072, bo_object = 0xfffffe025d23b0e8, bo_synclist = { le_next = 0x0, le_prev = 0x0 }, bo_private = 0xfffffe0263c4b000, __bo_vnode = 0xfffffe0263c4b000 }, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = { rl_waiters = { tqh_first = 0x0, tqh_last = 0xfffffe0263c4b1e0 }, rl_currdep = 0x0 }, v_fullpath = '\0' } (kgdb) i loc pa = va = 4194304 m = 0xfffffe104d4c9cd8 pmap = 0xfffffe01a8eeac28 (kgdb) p *m $7 = { pageq = { tqe_next = 0xfffffe106fb96e68, tqe_prev = 0xfffffe10520616a0 }, listq = { tqe_next = 0xfffffe10520616a0, tqe_prev = 0xfffffe025d23b130 }, left = 0x0, right = 0xfffffe10520616a0, object = 0xfffffe025d23b0e8, pindex = 0, phys_addr = 41917632512, md = { pv_list = { tqh_first = 0xfffffe02703de0b8, tqh_last = 0xfffffe02703de0c0 }, pat_mode = 6 }, queue = 1 '\001', segind = 3 '\003', hold_count = 0, order = 13 '\r', pool = 0 '\0', cow = 0, wire_count = 0, aflags = 0 '\0', flags = 0 '\0', oflags = 0, act_count = 64 '@', busy = 0 '\0', valid = 255 '�', dirty = 0 '\0' } (kgdb) p *m->right $8 = { pageq = { tqe_next = 0xfffffe104d4c9cd8, tqe_prev = 0xfffffe105187aab8 }, listq = { tqe_next = 0x0, tqe_prev = 0xfffffe104d4c9ce8 }, left = 0x0, right = 0x0, object = 0xfffffe025d23b0e8, pindex = 1, phys_addr = 44623183872, md = { pv_list = { tqh_first = 0xfffffe02703de0a0, tqh_last = 0xfffffe02703de0a8 }, pat_mode = 6 }, queue = 1 '\001', segind = 3 '\003', hold_count = 0, order = 13 '\r', pool = 0 '\0', cow = 0, wire_count = 0, aflags = 0 '\0', flags = 0 '\0', oflags = 0, act_count = 64 '@', busy = 0 '\0', valid = 255 '�', dirty = 0 '\0' } (kgdb) p *m->md.pv_list.tqh_first $9 = { pv_va = 4194304, pv_list = { tqe_next = 0x0, tqe_prev = 0xfffffe104d4c9d20 } } Everything looks pretty consistent and sane to me. Except, of course, for wire_count in both resident pages. The process in question is watchdogd which seems to mlockall(MCL_CURRENT | MCL_FUTURE) and that explains why the mapping is wired. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 08:30:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47872252 for ; Thu, 13 Feb 2014 08:30:51 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5371849 for ; Thu, 13 Feb 2014 08:30:51 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h16so12227207oag.24 for ; Thu, 13 Feb 2014 00:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Vy44nsnI0OuWOZUOKhFLo5I68yApFWlY6RIsK0+fxeY=; b=DLryDiTFfztO3g4JHVwqXclLvAohRme/wTNlobfdF8PEeGMWreRFYwyME11TUO4UmS UtDioPr2bXrQw/ZKg8L0qAcx+tBh8ffPbjr2Vr06GHgFoh4zk2x+KRpchy3laaUPF8EX gLEPvOfRvjOrv31OHvvYJe0Nj30QClUWIQr806PagHrPEPWl0v/HrlhQ2GgqrQIdeWHO CglVZlJP1vbU50IrNi/i1Yq3WpqcS+tRBY72dP8QuGAKzt8IsrRYKIsXJIELyhL8IKi7 Cfz1VoAEKARPL4i6NLJqywp7fGmegQ/varA/h8z8EDEHIIER3jWOB6NTru6Cdkv3/WQa rmog== X-Received: by 10.182.34.196 with SMTP id b4mr130437obj.13.1392280250366; Thu, 13 Feb 2014 00:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.167.34 with HTTP; Thu, 13 Feb 2014 00:30:30 -0800 (PST) In-Reply-To: References: From: n j Date: Thu, 13 Feb 2014 09:30:30 +0100 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 08:30:51 -0000 > > It appears that I need samba & squid to have NT/LM authentication to > get through the proxy so that I can download ports & packages, but to > obtain packages for those I need to be able to get through the proxy > first. > As krad above pointed out, you can use ntlmaps (/usr/ports/net/ntlmaps): a simple python proxy that does NTLM authentication for you. However, you could also use cntlm (/usr/ports/www/cntlm - http://cntlm.sourceforge.net). It's a C proxy so there is no python dependency. The package is about 50KB, but you do have to transfer it to your VM somehow (burn to CD if nothing else?). Regards, -- Nino From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 10:18:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA9EF36A for ; Thu, 13 Feb 2014 10:18:25 +0000 (UTC) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 968941259 for ; Thu, 13 Feb 2014 10:18:25 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id p14so7780695vbm.25 for ; Thu, 13 Feb 2014 02:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LyPLai57elem7hDvsoeDACWoTaz1U8lCz1M8EIDvx1g=; b=hsTGkzpKMMxT378dyh/F29gTeMQcgvi7HF9hP/aSd3Yrhy2owtaU5XWZbZ3fqWcwZu pp7K/OF3bP3z4Fdf2eCiNsqZtLSG7P0MppS8/8u3N3p9XzjAsSrsNwEffjMxwghPohnn IWbrncYbSKUxalpSTu9dqH8HAmAI9w1oTvnWUw48qo0e9uT0HDw/31W4Vu7MOZPCeIaB DaYtjJger7ONQLFE/zuD7EIOTCoSKA7BnTmi65/7QlU9TFJOZOtmZfxAshMwEhHhViYH RtKSwae1RwUqi5ggd1eRiJazBwssPfmKxPIct46NMdfKr3rWDqYfr42y+v10XCle2f8J TLIw== MIME-Version: 1.0 X-Received: by 10.220.161.132 with SMTP id r4mr327854vcx.29.1392286704720; Thu, 13 Feb 2014 02:18:24 -0800 (PST) Received: by 10.220.142.196 with HTTP; Thu, 13 Feb 2014 02:18:24 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 11:18:24 +0100 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Alban Hertroys To: n j Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:18:25 -0000 On 13 February 2014 09:30, n j wrote: >> >> It appears that I need samba & squid to have NT/LM authentication to >> get through the proxy so that I can download ports & packages, but to >> obtain packages for those I need to be able to get through the proxy >> first. >> > > As krad above pointed out, you can use ntlmaps (/usr/ports/net/ntlmaps): a > simple python proxy that does NTLM authentication for you. > However, you could also use cntlm (/usr/ports/www/cntlm - > http://cntlm.sourceforge.net). It's a C proxy so there is no python > dependency. The package is about 50KB, but you do have to transfer it to > your VM somehow (burn to CD if nothing else?). Thanks for the suggestions so far. ntlmaps is probably the first thing to try, because it's readily available on the DVD. I haven't really gotten around to trying out any suggestions yet, been too busy with regular work and this is kind of a low-priority/hobby thing I'm attempting. Regards, Alban. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 11:46:43 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0227154 for ; Thu, 13 Feb 2014 11:46:43 +0000 (UTC) Received: from fr-exchange.activnetworks.com (anwadmin.net8.nerim.net [213.41.185.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD9A1974 for ; Thu, 13 Feb 2014 11:46:40 +0000 (UTC) Received: from rn.activnetworks.com ([192.168.1.100]) by fr-exchange.activnetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 12:39:02 +0100 Message-ID: <52FCB056.6030007@activnetworks.com> Date: Thu, 13 Feb 2014 12:45:26 +0100 From: Remy Nonnenmacher User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130906 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable List Subject: Damaged tar files Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2014 11:39:02.0509 (UTC) FILETIME=[3164F9D0:01CF28B0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:46:43 -0000 Hi there, While moving big files using tar c | tar x, I found that every time, at 30GB sent, the receiving tar outputs a "tar: Damaged tar archive". I also checked that a Linux machine also sees a broken stream. It seems that in stable -10 and stable -9, tar creation is broken (libarchive update ?). Have someone seen this before I fill a PR ? TIA. RN. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 15:47:33 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0D8BCBA; Thu, 13 Feb 2014 15:47:33 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30021120E; Thu, 13 Feb 2014 15:47:32 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s1DFlJ6V011571; Thu, 13 Feb 2014 17:47:19 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s1DFlI4X011435; Thu, 13 Feb 2014 15:47:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 13 Feb 2014 15:47:18 GMT Message-Id: <201402131547.s1DFlI4X011435@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:47:34 -0000 TB --- 2014-02-13 13:30:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-13 13:30:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-13 13:30:42 - starting RELENG_10 tinderbox run for sparc64/sparc64 TB --- 2014-02-13 13:30:42 - cleaning the object tree TB --- 2014-02-13 13:30:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-13 13:31:34 - At svn revision 261834 TB --- 2014-02-13 13:31:35 - building world TB --- 2014-02-13 13:31:35 - CROSS_BUILD_TESTING=YES TB --- 2014-02-13 13:31:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-13 13:31:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-13 13:31:35 - SRCCONF=/dev/null TB --- 2014-02-13 13:31:35 - TARGET=sparc64 TB --- 2014-02-13 13:31:35 - TARGET_ARCH=sparc64 TB --- 2014-02-13 13:31:35 - TZ=UTC TB --- 2014-02-13 13:31:35 - __MAKE_CONF=/dev/null TB --- 2014-02-13 13:31:35 - cd /src TB --- 2014-02-13 13:31:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 13 13:31:46 UTC 2014 >>> 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 Thu Feb 13 15:07:44 UTC 2014 TB --- 2014-02-13 15:07:44 - generating LINT kernel config TB --- 2014-02-13 15:07:44 - cd /src/sys/sparc64/conf TB --- 2014-02-13 15:07:44 - /usr/bin/make -B LINT TB --- 2014-02-13 15:07:44 - cd /src/sys/sparc64/conf TB --- 2014-02-13 15:07:44 - /usr/sbin/config -m LINT TB --- 2014-02-13 15:07:44 - building LINT kernel TB --- 2014-02-13 15:07:44 - CROSS_BUILD_TESTING=YES TB --- 2014-02-13 15:07:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-13 15:07:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-13 15:07:44 - SRCCONF=/dev/null TB --- 2014-02-13 15:07:44 - TARGET=sparc64 TB --- 2014-02-13 15:07:44 - TARGET_ARCH=sparc64 TB --- 2014-02-13 15:07:44 - TZ=UTC TB --- 2014-02-13 15:07:44 - __MAKE_CONF=/dev/null TB --- 2014-02-13 15:07:44 - cd /src TB --- 2014-02-13 15:07:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 13 15:07:44 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Feb 13 15:46:57 UTC 2014 TB --- 2014-02-13 15:46:57 - cd /src/sys/sparc64/conf TB --- 2014-02-13 15:46:57 - /usr/sbin/config -m GENERIC TB --- 2014-02-13 15:46:57 - building GENERIC kernel TB --- 2014-02-13 15:46:57 - CROSS_BUILD_TESTING=YES TB --- 2014-02-13 15:46:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-13 15:46:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-13 15:46:57 - SRCCONF=/dev/null TB --- 2014-02-13 15:46:57 - TARGET=sparc64 TB --- 2014-02-13 15:46:57 - TARGET_ARCH=sparc64 TB --- 2014-02-13 15:46:57 - TZ=UTC TB --- 2014-02-13 15:46:57 - __MAKE_CONF=/dev/null TB --- 2014-02-13 15:46:57 - cd /src TB --- 2014-02-13 15:46:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Feb 13 15:46:57 UTC 2014 >>> 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 [...] yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/GENERIC *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-13 15:47:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-13 15:47:17 - ERROR: failed to build GENERIC kernel TB --- 2014-02-13 15:47:17 - 5963.38 user 2483.58 system 8194.73 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 17:16:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 188F59A5 for ; Thu, 13 Feb 2014 17:16:06 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C88BA1A8A for ; Thu, 13 Feb 2014 17:16:05 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 84970139CA for ; Thu, 13 Feb 2014 15:08:11 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1392311290; x=1393175291; bh=de7i52Vm3EGyrtkTLptN2p/cgSg3UY/5BaJ UanaM2oI=; b=lYxjQBfV4HtpRsheQq5Rq/4iVDpYjqyyPBBbBlUsSjTI8I6o73k DglOM0/+4Xy24UCNDmWMW541rl3UNvCHMjYj/TRy1+LnwNJ8tHuwi3C4tOEmYcjk RW6Bj14LRW/T2N3ZN+bLPGPzyV7lsODs6HtMVCkpAbaeNFuiPx9v8skI= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X96b4AUtm6jT for ; Thu, 13 Feb 2014 15:08:10 -0200 (BRST) Received: from MacBook-de-Gondim-2.local (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id B6927139C3 for ; Thu, 13 Feb 2014 15:08:09 -0200 (BRST) Message-ID: <52FCFB8C.1030800@bsdinfo.com.br> Date: Thu, 13 Feb 2014 15:06:20 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: dummynet problem in FreeBSD 10.0-STABLE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:16:06 -0000 Hi all, The following rules do not work anymore and block access to outside: ipfw add pipe 1 ip from 67.xxx.89.78 to any 80 out via xn0 ipfw add pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M Using these rules on the server, I can not surf the Internet through the server. In FreeBSD 9.x these rules worked. Doing: links http://www.any_website.com not work My Firewall rules: # ipfw show 00100 67191 13584242 allow ip from any to any via lo0 00200 0 0 deny ip from 127.0.0.0/8 to any 00300 0 0 deny ip from any to 127.0.0.0/8 00400 0 0 check-state 00500 0 0 deny ip from 192.168.0.0/16 to any in via xn0 00600 0 0 deny ip from 10.0.0.0/8 to any in via xn0 00700 0 0 deny ip from 172.16.0.0/12 to any in via xn0 00800 0 0 deny ip from 224.0.0.0/4 to any in via xn0 00900 0 0 deny ip from 255.255.255.255 to any in via xn0 01000 0 0 deny tcp from any to any in tcpflags fin,psh,urg recv xn0 01100 0 0 deny tcp from any to any in tcpflags !syn,!fin,!ack,!psh,!rst,!urg recv xn0 01200 0 0 deny tcp from any to any in tcpflags syn,fin recv xn0 01300 0 0 deny tcp from any to any in tcpflags fin,rst recv xn0 01400 0 0 deny ip from any to any in ipoptions ssrr,lsrr,rr,ts recv xn0 01500 78 2496 deny ip from table(99) to any in via xn0 01600 0 0 deny ip from table(1) to any 01700 276 16560 pipe 1 ip from 67.xxx.89.78 to any dst-port 80 out via xn0 01800 3 144 pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 01900 4 276 allow icmp from any to any icmptypes 3,11,12 02000 0 0 allow icmp from me to any icmptypes 0,8 keep-state 02100 1 75 deny icmp from any to any 02200 2226 298340 allow tcp from any to me dst-port 4321 in via xn0 setup keep-state 02300 1997 768000 allow tcp from any to me dst-port 995 in via xn0 setup keep-state 02400 1363 519377 allow tcp from any to me dst-port 25 in via xn0 setup keep-state 02500 733 549931 allow tcp from any to me dst-port 587 in via xn0 setup keep-state 02600 8952 8756999 allow tcp from any to me dst-port 80 in via xn0 setup keep-state 02700 2748 2125603 allow tcp from any to me dst-port 443 in via xn0 setup keep-state 02800 0 0 allow tcp from any to me dst-port 143 in via xn0 setup keep-state 02900 0 0 allow tcp from any to me dst-port 110 in via xn0 setup keep-state 03000 1094 360419 allow tcp from any to me dst-port 993 in via xn0 setup keep-state 03100 0 0 allow tcp from any to me dst-port 21 in via xn0 setup keep-state 03200 0 0 allow tcp from any to me dst-port 30000-50000 in via xn0 setup keep-state 03300 3558 1151840 allow tcp from me to any out setup keep-state 03400 6693 880724 allow ip from me to any out keep-state 65534 170 20283 deny log logamount 100 ip from any to any 65535 36 5424 allow ip from any to any When I remove the upload rule, navigation back to work: # ipfw delete 1700 links http://www.any_website.com work again. # uname -a FreeBSD mail.xxxxx.xxx.xx 10.0-STABLE FreeBSD 10.0-STABLE #2 r261419: Thu Feb 6 16:51:10 BRST 2014 root@mail.xxxxx.xxx.xx:/usr/obj/usr/src/sys/GONDIM amd64 It seems that something has changed and that stopped the bandwidth control. []'s Gondim From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 17:30:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 480CBE14 for ; Thu, 13 Feb 2014 17:30:20 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAB51BAC for ; Thu, 13 Feb 2014 17:30:18 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id hr13so8473346lab.15 for ; Thu, 13 Feb 2014 09:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/lhkzZgXgf76WQhlRxuS2e+IDOyfHhAVnjhEaPwADjk=; b=S049W2DZmuVUqNylWtPUnmI3WT57496bJ8vEcBi/bmCuVnMhQhpkDDxE3z9zbw4iY9 uaifwcEhDgDCPZjpzOtTWbD3X3eje3tcKafgiF2xrgyLEmrRUTazfczuSD8HrV4H7dor ihSU48yLh+1T8NYroD1DRHHGfRTBPP59myKdgyKG0s7yu+llvjE1GJW40lzaQIrNTvKX ZfwYK8CSuzTCLsE1poTe7ZChcVSZOirEAANk7PWgC1zeHZ+jle3PQD0CXaNzyu9yezYl PLiqDAXdtM0fsh+9o6CywSMTElVPLzWdb7v1WpMKbv3vP29pBQiZ1v1htr6oybxNFh3J n4fQ== MIME-Version: 1.0 X-Received: by 10.152.27.193 with SMTP id v1mr1913248lag.4.1392312617085; Thu, 13 Feb 2014 09:30:17 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Thu, 13 Feb 2014 09:30:17 -0800 (PST) In-Reply-To: <52FCFB8C.1030800@bsdinfo.com.br> References: <52FCFB8C.1030800@bsdinfo.com.br> Date: Thu, 13 Feb 2014 09:30:17 -0800 X-Google-Sender-Auth: wg2M-BXp8_UiM5a-gGlUM6T3o0w Message-ID: Subject: Re: dummynet problem in FreeBSD 10.0-STABLE From: Luigi Rizzo To: Marcelo Gondim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:30:20 -0000 hi, do you have the dummynet module loaded ? what does "ipfw pipe show" say, before and after the pipe's configuration ? cheers luigi On Thu, Feb 13, 2014 at 9:06 AM, Marcelo Gondim wrote: > Hi all, > > The following rules do not work anymore and block access to outside: > > ipfw add pipe 1 ip from 67.xxx.89.78 to any 80 out via xn0 > ipfw add pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 > ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M > ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M > > Using these rules on the server, I can not surf the Internet through the > server. In FreeBSD 9.x these rules worked. > Doing: links http://www.any_website.com not work > > My Firewall rules: > # ipfw show > > 00100 67191 13584242 allow ip from any to any via lo0 > 00200 0 0 deny ip from 127.0.0.0/8 to any > 00300 0 0 deny ip from any to 127.0.0.0/8 > 00400 0 0 check-state > 00500 0 0 deny ip from 192.168.0.0/16 to any in via xn0 > 00600 0 0 deny ip from 10.0.0.0/8 to any in via xn0 > 00700 0 0 deny ip from 172.16.0.0/12 to any in via xn0 > 00800 0 0 deny ip from 224.0.0.0/4 to any in via xn0 > 00900 0 0 deny ip from 255.255.255.255 to any in via xn0 > 01000 0 0 deny tcp from any to any in tcpflags fin,psh,urg recv > xn0 > 01100 0 0 deny tcp from any to any in tcpflags > !syn,!fin,!ack,!psh,!rst,!urg recv xn0 > 01200 0 0 deny tcp from any to any in tcpflags syn,fin recv xn0 > 01300 0 0 deny tcp from any to any in tcpflags fin,rst recv xn0 > 01400 0 0 deny ip from any to any in ipoptions ssrr,lsrr,rr,ts > recv xn0 > 01500 78 2496 deny ip from table(99) to any in via xn0 > 01600 0 0 deny ip from table(1) to any > > 01700 276 16560 pipe 1 ip from 67.xxx.89.78 to any dst-port 80 out > via xn0 > 01800 3 144 pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 > > 01900 4 276 allow icmp from any to any icmptypes 3,11,12 > 02000 0 0 allow icmp from me to any icmptypes 0,8 keep-state > 02100 1 75 deny icmp from any to any > 02200 2226 298340 allow tcp from any to me dst-port 4321 in via xn0 > setup keep-state > 02300 1997 768000 allow tcp from any to me dst-port 995 in via xn0 > setup keep-state > 02400 1363 519377 allow tcp from any to me dst-port 25 in via xn0 setup > keep-state > 02500 733 549931 allow tcp from any to me dst-port 587 in via xn0 > setup keep-state > 02600 8952 8756999 allow tcp from any to me dst-port 80 in via xn0 setup > keep-state > 02700 2748 2125603 allow tcp from any to me dst-port 443 in via xn0 > setup keep-state > 02800 0 0 allow tcp from any to me dst-port 143 in via xn0 > setup keep-state > 02900 0 0 allow tcp from any to me dst-port 110 in via xn0 > setup keep-state > 03000 1094 360419 allow tcp from any to me dst-port 993 in via xn0 > setup keep-state > 03100 0 0 allow tcp from any to me dst-port 21 in via xn0 setup > keep-state > 03200 0 0 allow tcp from any to me dst-port 30000-50000 in via > xn0 setup keep-state > 03300 3558 1151840 allow tcp from me to any out setup keep-state > 03400 6693 880724 allow ip from me to any out keep-state > 65534 170 20283 deny log logamount 100 ip from any to any > 65535 36 5424 allow ip from any to any > > When I remove the upload rule, navigation back to work: > > # ipfw delete 1700 > > links http://www.any_website.com work again. > > # uname -a > FreeBSD mail.xxxxx.xxx.xx 10.0-STABLE FreeBSD 10.0-STABLE #2 r261419: Thu > Feb 6 16:51:10 BRST 2014 root@mail.xxxxx.xxx.xx:/usr/obj/usr/src/sys/GONDIM > amd64 > > It seems that something has changed and that stopped the bandwidth control. > > []'s > Gondim > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 17:38:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7411B27C for ; Thu, 13 Feb 2014 17:38:25 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D6771C82 for ; Thu, 13 Feb 2014 17:38:24 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 3B6B9139C9 for ; Thu, 13 Feb 2014 15:40:11 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1392313210; x=1393177211; bh=2IUAILgeLQ3J TS6miMvHm+jcDgAULdXu+aBT+oMMMck=; b=DS7lOYYdh5JTRYNj3qZAuqZ5lYB0 pFuOSbxzMtJei4Sx2OcycAVubkBMK5YHT1jyQ6swPTx+LHclhdz77/+ea2PkjuVg R8Eeld/bsNWKBTQV4wn4kV7ZfK0vpOdyA7kjNxeEtwyq1RdSvZpDxB1e7zOAvRFC 1ngTQAJ8bYSnlxw= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfG_kMHNAJlL for ; Thu, 13 Feb 2014 15:40:10 -0200 (BRST) Received: from MacBook-de-Gondim-2.local (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 7DE6C139C3 for ; Thu, 13 Feb 2014 15:40:09 -0200 (BRST) Message-ID: <52FD030D.7010507@bsdinfo.com.br> Date: Thu, 13 Feb 2014 15:38:21 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: dummynet problem in FreeBSD 10.0-STABLE References: <52FCFB8C.1030800@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:38:25 -0000 Hi Luigi, I found out what happened: when I ran the rules from script file, did not show any error messages. But running rules manually, these appeared: # ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M ipfw: 2 <= queue size <= 100 # ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M ipfw: 2 <= queue size <= 100 I changed the net.inet.ip.dummynet.pipe_slot_limit to 128 and everything worked. Thanks and sorry! Em 13/02/14 15:30, Luigi Rizzo escreveu: > hi, > do you have the dummynet module loaded ? > what does "ipfw pipe show" say, before and > after the pipe's configuration ? > > cheers > luigi > > > > On Thu, Feb 13, 2014 at 9:06 AM, Marcelo Gondim wrote: > >> Hi all, >> >> The following rules do not work anymore and block access to outside: >> >> ipfw add pipe 1 ip from 67.xxx.89.78 to any 80 out via xn0 >> ipfw add pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 >> ipfw pipe 1 config bw 1024Kbit/s queue 128 burst 2M >> ipfw pipe 2 config bw 1024Kbit/s queue 128 burst 2M >> >> Using these rules on the server, I can not surf the Internet through the >> server. In FreeBSD 9.x these rules worked. >> Doing: links http://www.any_website.com not work >> >> My Firewall rules: >> # ipfw show >> >> 00100 67191 13584242 allow ip from any to any via lo0 >> 00200 0 0 deny ip from 127.0.0.0/8 to any >> 00300 0 0 deny ip from any to 127.0.0.0/8 >> 00400 0 0 check-state >> 00500 0 0 deny ip from 192.168.0.0/16 to any in via xn0 >> 00600 0 0 deny ip from 10.0.0.0/8 to any in via xn0 >> 00700 0 0 deny ip from 172.16.0.0/12 to any in via xn0 >> 00800 0 0 deny ip from 224.0.0.0/4 to any in via xn0 >> 00900 0 0 deny ip from 255.255.255.255 to any in via xn0 >> 01000 0 0 deny tcp from any to any in tcpflags fin,psh,urg recv >> xn0 >> 01100 0 0 deny tcp from any to any in tcpflags >> !syn,!fin,!ack,!psh,!rst,!urg recv xn0 >> 01200 0 0 deny tcp from any to any in tcpflags syn,fin recv xn0 >> 01300 0 0 deny tcp from any to any in tcpflags fin,rst recv xn0 >> 01400 0 0 deny ip from any to any in ipoptions ssrr,lsrr,rr,ts >> recv xn0 >> 01500 78 2496 deny ip from table(99) to any in via xn0 >> 01600 0 0 deny ip from table(1) to any >> >> 01700 276 16560 pipe 1 ip from 67.xxx.89.78 to any dst-port 80 out >> via xn0 >> 01800 3 144 pipe 2 ip from any 80 to 67.xxx.89.78 in via xn0 >> >> 01900 4 276 allow icmp from any to any icmptypes 3,11,12 >> 02000 0 0 allow icmp from me to any icmptypes 0,8 keep-state >> 02100 1 75 deny icmp from any to any >> 02200 2226 298340 allow tcp from any to me dst-port 4321 in via xn0 >> setup keep-state >> 02300 1997 768000 allow tcp from any to me dst-port 995 in via xn0 >> setup keep-state >> 02400 1363 519377 allow tcp from any to me dst-port 25 in via xn0 setup >> keep-state >> 02500 733 549931 allow tcp from any to me dst-port 587 in via xn0 >> setup keep-state >> 02600 8952 8756999 allow tcp from any to me dst-port 80 in via xn0 setup >> keep-state >> 02700 2748 2125603 allow tcp from any to me dst-port 443 in via xn0 >> setup keep-state >> 02800 0 0 allow tcp from any to me dst-port 143 in via xn0 >> setup keep-state >> 02900 0 0 allow tcp from any to me dst-port 110 in via xn0 >> setup keep-state >> 03000 1094 360419 allow tcp from any to me dst-port 993 in via xn0 >> setup keep-state >> 03100 0 0 allow tcp from any to me dst-port 21 in via xn0 setup >> keep-state >> 03200 0 0 allow tcp from any to me dst-port 30000-50000 in via >> xn0 setup keep-state >> 03300 3558 1151840 allow tcp from me to any out setup keep-state >> 03400 6693 880724 allow ip from me to any out keep-state >> 65534 170 20283 deny log logamount 100 ip from any to any >> 65535 36 5424 allow ip from any to any >> >> When I remove the upload rule, navigation back to work: >> >> # ipfw delete 1700 >> >> links http://www.any_website.com work again. >> >> # uname -a >> FreeBSD mail.xxxxx.xxx.xx 10.0-STABLE FreeBSD 10.0-STABLE #2 r261419: Thu >> Feb 6 16:51:10 BRST 2014 root@mail.xxxxx.xxx.xx:/usr/obj/usr/src/sys/GONDIM >> amd64 >> >> It seems that something has changed and that stopped the bandwidth control. >> >> []'s >> Gondim >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 20:02:06 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57E41530 for ; Thu, 13 Feb 2014 20:02:06 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFCE51C7B for ; Thu, 13 Feb 2014 20:02:05 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id f8so9151271wiw.15 for ; Thu, 13 Feb 2014 12:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:organization:user-agent :mime-version:content-type; bh=yKsbFnpRkSgN4A+klVm/c9vYar7+ockRX/fOzZuiJCY=; b=UfpL6JJbKtm6J7XyGAXQlhViHUcxm4LAJ8LM47jqnrzeHnp1Q3Eo1cFDBx/yP40+17 7mN+BKoDHVwHV86TaBQfCLWUeHmo1UWE4V3STT4jME2eTwueX5zZy8rUDgl2WkyXzcwe KcX2iiO4d1Xaj8xEcqqyJvwn+uv8qXEhsq1dC4pArvU8W7jRBNjCb2KENy/D2s6/Hzq9 srIh7clgezzWQ7rZlgwva0Y+qYcfyJIx8Mp31VRvOfe62XvrRjSDCUSzStL3Uj9ROMjF jP0G+80Y8P77OzwIr30VLMfZhB42gwrIhVb21fMu5732Eti3jwol+pdaXBXXL+kvWFEV AbkQ== X-Received: by 10.180.73.173 with SMTP id m13mr7935850wiv.52.1392321724118; Thu, 13 Feb 2014 12:02:04 -0800 (PST) Received: from dragon.dg ([197.87.228.138]) by mx.google.com with ESMTPSA id 12sm6999326wjm.10.2014.02.13.12.02.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Feb 2014 12:02:02 -0800 (PST) Sender: David Naylor From: David Naylor To: stable@freebsd.org Subject: MPCP Opcode Pause and unresponsive computer Date: Thu, 13 Feb 2014 22:01:56 +0300 Message-ID: <1403963.5sDsKbxfoF@dragon.dg> Organization: FreeBSD User-Agent: KMail/4.10.5 (FreeBSD/9.2-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1971164.yiCTdHp6Gg"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:02:06 -0000 --nextPart1971164.yiCTdHp6Gg Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hi, I recently installed FreeBSD 10.0-RELEASE on an headless Intense-PC. I am experiencing two network related issues with the computer. First issue ----------- When compiling lang/ruby19 the network freezes. The build was done directly from the command line using ssh. After a while ssh reports "Write failed: Broken pipe". I attached the monitor and no messages were displayed on the output (and the machine was still running). The Intense-PC does not respond to pings at this point either. Of note, I was capable of transferring multiple GB of data and successfully compiled other ports but compiling lang/ruby19 messes up everything. Second issue ------------ After a period of uptime (after the freeze from building lang/ruby19) the entire network stops working, nothing is capable of connecting or communicating on the network. When I do a tcpdump (from a different, affected computer) I find the following: 20:57:58.254626 MPCP, Opcode Pause, length 46 These messages get repeated a few times a second. The moment I disconnect the Intense-PC from the network functionality is restored (and is clearly illustrated by the tcpdump). Information ----------- # uname -a FreeBSD dragonbsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0 d44ce30(releng/10.0): Sun Feb 9 20:11:55 SAST 2014 root@dragon.dg:/tmp/home/freebsd/10.0/src/sys/MODULAR amd64 # ifconfig lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=4219b ether XX:XX:XX:XX:XX:XX inet 192.168.0.160 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active re0: flags=8843 metric 0 mtu 1500 options=8209b ether XX:XX:XX:XX:XX:XX nd6 options=29 media: Ethernet autoselect (none) status: no carrier Any assistance to resolve this issue will be greatly appreciated. Regards, P.S. Please keep me CC'ed, I'm not subscribed on the list. --nextPart1971164.yiCTdHp6Gg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEABECAGYFAlL9JLZfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NDBCNDdDNTRBQTNFQkFCMjNCNThBQzUx QTY4NTgwRkY2OTE2QjIACgkQUaaFgP9pFrKGmQCgixwFVYQvqb2iHGf0CeOSUiO0 8gAAn1NdczBoSxhauJDVKypQnARkJ84f =WN5r -----END PGP SIGNATURE----- --nextPart1971164.yiCTdHp6Gg-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 20:23:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D297CD38 for ; Thu, 13 Feb 2014 20:23:12 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 780E41E2B for ; Thu, 13 Feb 2014 20:23:12 +0000 (UTC) X-AuditID: 1209190d-f79776d000000ce9-3d-52fd287c76d4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id F7.9E.03305.C782DF25; Thu, 13 Feb 2014 15:18:04 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s1DKI3Un019624 for ; Thu, 13 Feb 2014 15:18:03 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1DKI1qd013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Feb 2014 15:18:03 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1DKI1m2004489; Thu, 13 Feb 2014 15:18:01 -0500 (EST) Date: Thu, 13 Feb 2014 15:18:01 -0500 (EST) From: Benjamin Kaduk To: freebsd-stable@freebsd.org Subject: failing to link custom kernel on 10.0-release Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixG6nrluj8TfIoK2b0+Jws5ADo8eMT/NZ AhijuGxSUnMyy1KL9O0SuDLmv53AXPCPqWLjj9usDYxbmLoYOTgkBEwkNu6T7GLkBDLFJC7c W8/WxcjFISQwm0li6ZXNTBDOJUaJo31vWEGqhAQeM0m0rTKDSDQwSkxua2cDSbAIaEvcP93G AmKzCahIzHyzESwuIiAncXr1FbBtwgJmEv2vTEHCvAIOEpvXPgWbKSqgI7F6/xQWiLigxMmZ T8BsZgFLiX9rf7FOYOSbhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3U lNJNjKBA4pTk3cH47qDSIUYBDkYlHt4Pd/8ECbEmlhVX5h5ilORgUhLlVVX9GyTEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhNdJHijHm5JYWZValA+TkuZgURLnrbX4FSQkkJ5YkpqdmlqQWgST leHgUJLg9VEHahQsSk1PrUjLzClBSDNxcIIM5wEaHghSw1tckJhbnJkOkT/FqCglzluqBpQQ AElklObB9cIi/RWjONArwrxqIO08wCQB1/0KaDAT0ODUqN8gg0sSEVJSDYwr5u6t6LXU2tew Qcy7qf/T23SxXedm309hEP9Q8Wp6xY65ky3EXsmzlNz5Vbj443U7l45tqybKqHa/O9kUsXR7 vtHVnQnLwuqdNy/b33V41yW2txu9z2UWVBQ7+Lgdz77Rm1RsN9OuSp7D77OA/v0n3O+jDt4y d3ji1zv9+obtBeH1jvOruhSUWIozEg21mIuKEwGbmI+OzwIAAA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:23:12 -0000 Hi all, I'm trying to build this kernel config (amd64) on a 10-release machine: http://web.mit.edu/kaduk/freebsd/tmp/PALAVER It gets to "linking kernel.debug" and then spews a pile of errors about "undefined reference to '__mtx_assert'" for (presumably) every object file. I suspect that this is related to DEBUG_LOCKS, but what am I missing? Thanks, Ben Kaduk From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 20:28:14 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9ABAB0 for ; Thu, 13 Feb 2014 20:28:14 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C51A1FD3 for ; Thu, 13 Feb 2014 20:28:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WE2tI-0004lS-5I; Thu, 13 Feb 2014 20:28:12 +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 s1DKS8tD075528; Thu, 13 Feb 2014 13:28:09 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4+hPwCv75bU/Us17l1b2d Subject: Re: failing to link custom kernel on 10.0-release From: Ian Lepore To: Benjamin Kaduk In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Feb 2014 13:28:08 -0700 Message-ID: <1392323288.1145.91.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:28:14 -0000 On Thu, 2014-02-13 at 15:18 -0500, Benjamin Kaduk wrote: > Hi all, > > I'm trying to build this kernel config (amd64) on a 10-release machine: > http://web.mit.edu/kaduk/freebsd/tmp/PALAVER > > It gets to "linking kernel.debug" and then spews a pile of errors about > "undefined reference to '__mtx_assert'" for (presumably) every object > file. > > I suspect that this is related to DEBUG_LOCKS, but what am I missing? > > Thanks, > > Ben Kaduk Quick guess without a lot of digging: You might need to add option INVARIANT_SUPPORT. -- Ian From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 20:31:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 217D3D61; Thu, 13 Feb 2014 20:31:12 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8973F10BC; Thu, 13 Feb 2014 20:31:11 +0000 (UTC) X-AuditID: 1209190c-f794a6d000000c27-b2-52fd2b8d42b7 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id EE.1C.03111.D8B2DF25; Thu, 13 Feb 2014 15:31:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s1DKV98q023426; Thu, 13 Feb 2014 15:31:09 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1DKV7uh018069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Feb 2014 15:31:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1DKV7EB006216; Thu, 13 Feb 2014 15:31:07 -0500 (EST) Date: Thu, 13 Feb 2014 15:31:07 -0500 (EST) From: Benjamin Kaduk To: Ian Lepore Subject: Re: failing to link custom kernel on 10.0-release In-Reply-To: <1392323288.1145.91.camel@revolution.hippie.lan> Message-ID: References: <1392323288.1145.91.camel@revolution.hippie.lan> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6notur/TfI4NciG4vDzUIWT46/YXZg 8pjxaT5LAGMUl01Kak5mWWqRvl0CV8b3GW9YCxazV/Re92tgfMbaxcjBISFgInHybWEXIyeQ KSZx4d56ti5GLg4hgdlMElc/9UM5Gxkl2n5OYASpEhI4xCSx9hIPRKKBUWL3jT5mkASLgLZE 44cr7CA2m4CKxMw3G9lAbBEBBYkt81aD1TALyEmcebecCcQWFrCSeLblH5jNKWArsWvFZhYQ m1fAQWLxhb1g1wkJFEpMu18LEhYV0JFYvX8KVImgxMmZT1ggRlpKnPtznW0Co+AsJKlZSFIL GJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBAUmpyTPDsY3B5UOMQpwMCrx 8Ho8+BMkxJpYVlyZe4hRkoNJSZT3mubfICG+pPyUyozE4oz4otKc1OJDjBIczEoivBO1gHK8 KYmVValF+TApaQ4WJXHeWotfQUIC6YklqdmpqQWpRTBZGQ4OJQneyyCNgkWp6akVaZk5JQhp Jg5OkOE8QMPngQ0vLkjMLc5Mh8ifYlSUEue1BblIACSRUZoH1wtLHK8YxYFeEeZ9CdLOA0w6 cN2vgAYzAQ1OjfoNMrgkESEl1cCosMflOmfLccNN7Spcp9Y03LydPiH03MXplpfO3/SPXvlG q01Xsb5O99l6ue1ZXl98ayOUllQbzrLcsfH6rZUJ20445WcnrFHfHmbWK+ev+2/mRPsmWwYO T8U/fTO8uQIDeG5bHT/xvOvEQ+Z7liq7arYcZSl8zsjNPGvJvD9xkXdVa2RrXWqUWIozEg21 mIuKEwE5KCO59wIAAA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:31:12 -0000 On Thu, 13 Feb 2014, Ian Lepore wrote: > On Thu, 2014-02-13 at 15:18 -0500, Benjamin Kaduk wrote: >> Hi all, >> >> I'm trying to build this kernel config (amd64) on a 10-release machine: >> http://web.mit.edu/kaduk/freebsd/tmp/PALAVER >> >> It gets to "linking kernel.debug" and then spews a pile of errors about >> "undefined reference to '__mtx_assert'" for (presumably) every object >> file. >> >> I suspect that this is related to DEBUG_LOCKS, but what am I missing? >> >> Thanks, >> >> Ben Kaduk > > Quick guess without a lot of digging: You might need to add option > INVARIANT_SUPPORT. Oh, that's probably it. I got an error from INVARIANTS_SUPPORT (extra 'S') and then failed to check in sys/conf/NOTES, did not find it in sys/amd64/conf/NOTES, and assumed that the support had been set to "always-enabled" due to some vague memory of what hit head. Thanks for the prompt cluebat. -Ben From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 20:45:02 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BD256A1 for ; Thu, 13 Feb 2014 20:45:02 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id E3A5F11EE for ; Thu, 13 Feb 2014 20:45:01 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 1CA7233C19; Thu, 13 Feb 2014 15:44:49 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id 3D86F39828; Thu, 13 Feb 2014 15:44:47 -0500 (EST) From: Lowell Gilbert To: Remy Nonnenmacher Subject: Re: Damaged tar files References: <52FCB056.6030007@activnetworks.com> Date: Thu, 13 Feb 2014 15:44:47 -0500 In-Reply-To: <52FCB056.6030007@activnetworks.com> (Remy Nonnenmacher's message of "Thu, 13 Feb 2014 12:45:26 +0100") Message-ID: <44ob2ahhds.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:45:02 -0000 Remy Nonnenmacher writes: > Hi there, > > While moving big files using tar c | tar x, I found that every time, > at 30GB sent, the receiving tar outputs a "tar: Damaged tar > archive". I also checked that a Linux machine also sees a broken > stream. > > It seems that in stable -10 and stable -9, tar creation is broken > (libarchive update ?). > > Have someone seen this before I fill a PR ? I can't reproduce it on RELENG_9... From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 21:14:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15044C7F for ; Thu, 13 Feb 2014 21:14:31 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 946BF14F9 for ; Thu, 13 Feb 2014 21:14:29 +0000 (UTC) X-AuditID: 1209190e-f79ee6d000000c40-7f-52fd3481cb4b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D8.71.03136.1843DF25; Thu, 13 Feb 2014 16:09:21 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s1DL9LJu028390 for ; Thu, 13 Feb 2014 16:09:21 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1DL9JTT001288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Feb 2014 16:09:21 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1DL9J0L010992; Thu, 13 Feb 2014 16:09:19 -0500 (EST) Date: Thu, 13 Feb 2014 16:09:19 -0500 (EST) From: Benjamin Kaduk To: freebsd-stable@freebsd.org Subject: Re: failing to link custom kernel on 10.0-release In-Reply-To: Message-ID: References: <1392323288.1145.91.camel@revolution.hippie.lan> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6notto8jfI4NZ+M4vDzUIOjB4zPs1n CWCM4rJJSc3JLEst0rdL4Mq4uvcZS8E7xoqtK1YyNTDuY+xi5OSQEDCR+PTyMzuELSZx4d56 ti5GLg4hgdlMEnu+3WeEcC4xStxe1Q+VecwkManpOAuE08Ao0fBpCZDDwcEioC2xdrYPyCg2 ARWJmW82soHYIgJyEqdXX2ECsYUFrCSebfnHBFLOKeAo8fRUPEiYV8BBYsvrzVDzlzFKvD10 lwUkISqgI7F6/xQWiCJBiZMzn4DZzAKWEuf+XGebwCgwC0lqFpLUAkamVYyyKblVurmJmTnF qcm6xcmJeXmpRbrGermZJXqpKaWbGEHBxynJt4Px60GlQ4wCHIxKPLweD/4ECbEmlhVX5h5i lORgUhLlzTf4GyTEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHeiFlCONyWxsiq1KB8mJc3BoiTO W2vxK0hIID2xJDU7NbUgtQgmK8PBoSTB22MM1ChYlJqeWpGWmVOCkGbi4AQZzgM0vAWkhre4 IDG3ODMdIn+KUVFKnNcGJCEAksgozYPrhSWHV4ziQK8I88aDVPEAEwtc9yugwUxAg1OjfoMM LklESEk1MGbvt1t+9cmC63XZr6cctow9uvoj4+wezWX9DgmL3nm0aC574Xot8U79igUaKSnl GiyTHKIXPZ/xkv3mgQNp6/wUj0wOO7Xe+ptP/zP5Xd9erC3Ur2E9JPWdXf/aWj6tbctmKVaF ujz6kZMh+EjmGW++4j/5ittp12efUQyN/pA+49LBmo7X03qUWIozEg21mIuKEwGcTaAG6QIA AA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:14:31 -0000 With INVARIANT_SUPPORT added, the kernel builds. On boot, I get panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:500 I guess I get to rebuild with WITNESS_SKIPSPIN. -Ben From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 23:04:14 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00E053E6 for ; Thu, 13 Feb 2014 23:04:13 +0000 (UTC) Received: from fr-exchange.activnetworks.com (anwadmin.net8.nerim.net [213.41.185.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8126E1E08 for ; Thu, 13 Feb 2014 23:04:12 +0000 (UTC) Received: from rn.activnetworks.com ([192.168.1.100]) by fr-exchange.activnetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 23:57:45 +0100 Message-ID: <52FD4F6A.5070400@activnetworks.com> Date: Fri, 14 Feb 2014 00:04:10 +0100 From: Remy Nonnenmacher User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130906 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lowell Gilbert Subject: Re: Damaged tar files References: <52FCB056.6030007@activnetworks.com> <44ob2ahhds.fsf@lowell-desk.lan> In-Reply-To: <44ob2ahhds.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2014 22:57:45.0417 (UTC) FILETIME=[02239B90:01CF290F] Cc: freebsd-stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:04:14 -0000 On 02/13/14 21:44, Lowell Gilbert wrote: > Remy Nonnenmacher writes: > >> Hi there, >> >> While moving big files using tar c | tar x, I found that every time, >> at 30GB sent, the receiving tar outputs a "tar: Damaged tar >> archive". I also checked that a Linux machine also sees a broken >> stream. >> >> It seems that in stable -10 and stable -9, tar creation is broken >> (libarchive update ?). >> >> Have someone seen this before I fill a PR ? > > I can't reproduce it on RELENG_9... > It needs further investigation since conditions are too specific. I guess this is transient I have not enough narrowed. Sorry for the noise. I will be back when I have something and if it needs fix. Thanks (oo) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 13 23:41:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65752ED8 for ; Thu, 13 Feb 2014 23:41:04 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E4F2125A for ; Thu, 13 Feb 2014 23:41:04 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id e16so19298765qcx.10 for ; Thu, 13 Feb 2014 15:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aTthfRycuBpsscOP5wBgFoQsw7zrctk9OICXzOXckzc=; b=DNs5O9h6mmyUfpZfH44GF9CVLxVnzaq9vWwH6te43z1Qu1dW5zTAOfKv73pHeP++li ReRvUf5S4OQU0kysmxVp8tmr4VIW1C7SPB3qOnLfgJePRiqFqN2ox5g5Rn+WB9RmHFCw xsxIetpSlgFgc8UeX1PkrVNujoPVUhH7BHkaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aTthfRycuBpsscOP5wBgFoQsw7zrctk9OICXzOXckzc=; b=BXhaCM+94+f86l4rd3Q8qxkIY2kfuwsCHbNOJrqIoCKnbcpw8nS54e0J1mcEx/dAZu /5scgFk0jMCVN5ImtOEPIxf8u0XqjdVLd9Sd55aDvxIFic/R6f7SO7IqCEEbYBu05YcT OajoyjTa4NL7FYYOePnGYH0zSpQtQUr+yifmztqaaMsWvD6LMSFTyeOYUuiBKVRrCELE /D2/ZJwtCoLLzyLKGLgVhATedawcL1+JJsJemgNh9PlSNU37Za6vGoYQe8Ih7pOPZtLr TCmqC7wWB9Fkh9V3SsJCKPk1Ktf+K6oKtvYdiLIwGeG4kHMQvn4Vr0DsC4Rr0Thf67Ql 4Q1w== X-Gm-Message-State: ALoCoQn+1ZPyxA/9DQQFKv2+O0MnVMqR/LKdLGSWOaoGYl3pUHN1p+tcSM+aiPbPMt4RpYS5mYUv X-Received: by 10.224.44.8 with SMTP id y8mr7709887qae.44.1392334863307; Thu, 13 Feb 2014 15:41:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.175.169 with HTTP; Thu, 13 Feb 2014 15:40:33 -0800 (PST) In-Reply-To: <52FCB056.6030007@activnetworks.com> References: <52FCB056.6030007@activnetworks.com> From: Eitan Adler Date: Thu, 13 Feb 2014 18:40:33 -0500 Message-ID: Subject: Re: Damaged tar files To: Remy Nonnenmacher Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:41:04 -0000 On Thu, Feb 13, 2014 at 6:45 AM, Remy Nonnenmacher wrote: > Hi there, > > While moving big files using tar c | tar x, I found that every time, at 30GB > sent, the receiving tar outputs a "tar: Damaged tar archive". I also checked > that a Linux machine also sees a broken stream. > > It seems that in stable -10 and stable -9, tar creation is broken > (libarchive update ?). > > Have someone seen this before I fill a PR ? Is this true for all large files or just some? Does it stop at a deterministic point in each file? If multiple files are affected does it stop at the same byte count for each file, or does it stop around the same point? -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 09:16:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 054E733A for ; Fri, 14 Feb 2014 09:16:26 +0000 (UTC) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 85C92115A for ; Fri, 14 Feb 2014 09:16:25 +0000 (UTC) Received: from dyn-ant66.edvz.uni-linz.ac.at (dyn-ant66.edvz.uni-linz.ac.at [140.78.6.66]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTPSA id 566655C01F for ; Fri, 14 Feb 2014 10:06:43 +0100 (CET) From: Ferdinand Goldmann Subject: pkg: Error loading trusted certificates Message-Id: <95CFCCEF-05A1-4C59-B4E0-3C8B459A38C8@jku.at> Date: Fri, 14 Feb 2014 10:06:42 +0100 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:16:26 -0000 Hello, tried to migrate a FreeBSD 9.1-RELEASE-p10 system from old pkg-tools to = pkgng according to the instructions here: http://www2.at.freebsd.org/doc/handbook/pkgng-intro.html I manually had to add /etc/pkg/FreeBSD.conf: # cat /etc/pkg/FreeBSD.conf=20 # $FreeBSD: release/10.0.0/etc/pkg/FreeBSD.conf 258710 2013-11-28 = 14:24:26Z gjb $ FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } After that I added a key: # cat /usr/share/keys/pkg/trusted=20 # $FreeBSD: = releng/10.0/share/keys/pkg/trusted/pkg.freebsd.org.2013102301 260609 = 2014-01-13 22:15:57Z bdrewery $ function: "sha256" fingerprint: = "b0170035af3acc5f3f3ae1859dc717101b4e6c1d0a794ad554928ca0cbb2f438" However, running pkg update failed: # pkg update =20 Updating repository catalogue digests.txz = 100% 1096KB 1.1MB/s 1.1MB/s 00:01 =20 pkg: Error loading trusted certificates pkg: Unable to find catalogs Only when I commented out signature_type and fingerprints in = /etc/pkg/FreeBSD.conf pkg update ran without errors. I guess this might be due to the fact that the key is meant to be used = on FreeBSD 10.0 instead of FreeBSD 9.1 ? Can anybody tell me where to find a key for FreeBSD 9 ? Unfortuneately, = the handbook does not mention the upgrade process at all. :-( Best regards, Ferdinand= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 12:44:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA81C3EC; Fri, 14 Feb 2014 12:44:35 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) by mx1.freebsd.org (Postfix) with ESMTP id 794121389; Fri, 14 Feb 2014 12:44:35 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id DC0179DC7B1; Fri, 14 Feb 2014 13:44:27 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 10, ServeRAID M5210e, syspd corruption Date: Fri, 14 Feb 2014 13:44:26 +0100 Message-Id: To: freebsd-scsi@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 12:44:35 -0000 (crossposting to -Stable just in case) Hello, I am configuring an IBM server with FreeBSD 10-RELEASE, a ServeRAID = M5210e and 23 SSD disks. uname -a FreeBSD hostname 10.0-RELEASE FreeBSD 10.0-RELEASE #1: Fri Feb 14 = 09:35:12 CET 2014 toor@ hostname:/usr/obj/usr/src/sys/GENERIC amd64 The server has a SAS backplane and a controller recognized by the mfi = driver. mfi0 Adapter: Product Name: ServeRAID M5210e Serial Number: 3CJ0SG =20 Firmware: 24.0.2-0013 RAID Levels: JBOD, RAID0, RAID1, RAID10 Battery Backup: not present NVRAM: 32K Onboard Memory: 0M Minimum Stripe: 64K Maximum Stripe: 64K As I am intending to use ZFS, I need direct access to the disks, no need = for fancy RAID features. I have seen that the newest cards support a so-called "syspd" mode that = gives direct acess to the disks. However, in this configuration, syspd consistently corrupts data on the = disks. I have done tests with three models of disks: - Samsung SSD 840 BB0Q (1 TB) - OCZ-VERTEX4 1.5 (512 GB) - SEAGATE ST9146803SS FS03 (136 GB) In the three cases there is data corruption. Using FFS on the disks = results in a panic if I run a benchmark, for example, bonnie++. Using ZFS (I've been creating one disk pools to test) I don't get panics = but the data is consistently corrupted. The writes work, but whenever there is read activity (either bonnie++ reaching the "rewrite" phase, or = a ZFS scrub), ZFS detects data corruption. Trying the =FCber neat hw.mfi.allow_cam_disk_passthrough (which is = great, because ZFS can detect the SSDs and issue TRIM commands) I get the same result: data corruption. However, I have tried to create a one-disk raid0 volume, and in that = case it works like a charm, no corruption at all, so I can safely assume that this is not a defective backplane, expander or cabling.=20 So: mfisyspd -> CORRUPT da -> CORRUPT mfid -> NOT CORRUPT Any ideas? Could be a driver error or a firmware problem, I am clueless = for now. Anything I can test? The machine is not in production, I can try patches = or whatever. Thanks!! Borja. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 13:37:18 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0EDC363; Fri, 14 Feb 2014 13:37:18 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D25F617E0; Fri, 14 Feb 2014 13:37:17 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s1EDbCOs062427; Fri, 14 Feb 2014 15:37:12 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s1EDbCrs062271; Fri, 14 Feb 2014 13:37:12 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 14 Feb 2014 13:37:12 GMT Message-Id: <201402141337.s1EDbCrs062271@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:37:18 -0000 TB --- 2014-02-14 12:30:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-14 12:30:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-14 12:30:42 - starting RELENG_10 tinderbox run for powerpc64/powerpc TB --- 2014-02-14 12:30:42 - cleaning the object tree TB --- 2014-02-14 12:30:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-14 12:31:33 - At svn revision 261885 TB --- 2014-02-14 12:31:34 - building world TB --- 2014-02-14 12:31:34 - CROSS_BUILD_TESTING=YES TB --- 2014-02-14 12:31:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-14 12:31:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-14 12:31:34 - SRCCONF=/dev/null TB --- 2014-02-14 12:31:34 - TARGET=powerpc TB --- 2014-02-14 12:31:34 - TARGET_ARCH=powerpc64 TB --- 2014-02-14 12:31:34 - TZ=UTC TB --- 2014-02-14 12:31:34 - __MAKE_CONF=/dev/null TB --- 2014-02-14 12:31:34 - cd /src TB --- 2014-02-14 12:31:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 14 12:31:45 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentLexer.cpp -o CommentLexer.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentParser.cpp -o CommentParser.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentSema.cpp -o CommentSema.o /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentSema.cpp: In member function 'void clang::comments::Sema::resolveParamCommandIndexes(const clang::comments::FullComment*)': /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentSema.cpp:704: internal compiler error: in var_ann, at tree-flow-inline.h:130 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/clang/libclangast *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-14 13:37:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-14 13:37:11 - ERROR: failed to build world TB --- 2014-02-14 13:37:11 - 2954.99 user 1161.30 system 3988.27 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 13:44:42 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 521A66F4; Fri, 14 Feb 2014 13:44:42 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A232018B8; Fri, 14 Feb 2014 13:44:41 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so9500825lbi.0 for ; Fri, 14 Feb 2014 05:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T3zoRPxjPz2DYss2XSE3Q05jpSTd1MVe2tdn+gJR8IM=; b=KBG5DomhFDxlhM1msUmQmbI/wlcphgrTAgE+kjiGdjQW+V6qwzYEv1tLjpef+U7gTo a52Nmi82+EBwjPbLD668MAzLgYXSU2x0q/Q5ZAhVFOuTq9MeLsV2IEfl7nLe5OuD1Kxr nAv9IX5NI3nbNCoGXswaubXlA2og+e657AlMDVtCaLv6Y9xC2R53AnptJ3eOuoVT6+fm EgcYIgN/gg01KGYVkhpr3dsZOReObaapeH55GeGmyWaxfU2d53ttEKbGiWUOQxN92lf7 y9QvRytMx0lKBRKUb2bLtSAhzGGG4jrH3yz6Zb7R33hZevN4MO+QjTsOMjr3CdpzYA7l Fj+g== MIME-Version: 1.0 X-Received: by 10.112.160.200 with SMTP id xm8mr5188105lbb.24.1392385479597; Fri, 14 Feb 2014 05:44:39 -0800 (PST) Received: by 10.112.35.167 with HTTP; Fri, 14 Feb 2014 05:44:39 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Feb 2014 13:44:39 +0000 Message-ID: Subject: Re: FreeBSD 10, ServeRAID M5210e, syspd corruption From: Tom Evans To: Borja Marcos Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org, Stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:44:42 -0000 On Fri, Feb 14, 2014 at 12:44 PM, Borja Marcos wrote: > (crossposting to -Stable just in case) > > Hello, > > I am configuring an IBM server with FreeBSD 10-RELEASE, a ServeRAID M5210e and 23 SSD disks. > I'm afraid I have no solution to offer you for this issue, but with this setup an mps(8) card (LSI SAS2008 and similar) in IT (passthru) mode would work excellently. Maybe easier to change the card than struggle to get it to do something it doesn't want to? Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 13:49:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 656D68AD for ; Fri, 14 Feb 2014 13:49:06 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 335C118FA for ; Fri, 14 Feb 2014 13:49:05 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4576E20C19 for ; Fri, 14 Feb 2014 08:49:05 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 14 Feb 2014 08:49:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=dAmQQxZOj07g33LCEwu4kggg2Ac=; b=TFp gcN9UNrVg6aj37uEjS/AGO+p1KfxG1rNb3s+ehoSPwfSG6HjFqL2xuF1xPuMuP26 Q7xWXLnkD0A6RrtwPqb8wjd2MQRzXfHz3VuFCIatdhG+k7fYwilcDPtmFrKSQw7q zym/jRyh0rpldwBpUzN/mj8+n0rFazrtBXWsfEeA= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 27A7411E375; Fri, 14 Feb 2014 08:49:05 -0500 (EST) Message-Id: <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> X-Sasl-Enc: YiW/ImKCoWajY0vvGOMjDSzAC+69CDqCZ6NGr2bUO6tX 1392385745 From: Mark Felder To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e72899be In-Reply-To: <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? Date: Fri, 14 Feb 2014 07:49:05 -0600 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:49:06 -0000 On Sat, Feb 8, 2014, at 13:38, Marko Cupa=C4=87 wrote: > First of all, I wouldn't go with 10-RELEASE, as it is not officially > supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. >=20 "FreeBSD" is "not officially supported" by VMWare. Trust me. We threw $60,000 at them and they still wouldn't acknowledge bugs. I couldn't even find an engineer that knew what FreeBSD was! Plus you have to consider that we don't even know what version of ESXi he's working with in the first place. According to their OS support matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. http://www.vmware.com/resources/compatibility/search.php?deviceCategory=3Ds= oftware&partner=3D109&testConfigurations=3D16&page=3D1&display_interval=3D1= 0&sortColumn=3DPartner&sortOrder=3DAsc&testConfig=3D16 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 14:00:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4079BF1E; Fri, 14 Feb 2014 14:00:10 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 489601A03; Fri, 14 Feb 2014 14:00:10 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 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 6F97260F5; Fri, 14 Feb 2014 09:00:02 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=BNvBkca/eP6BI7XgVAc0zhsy2PaCWk9wX+UB2B9XpNitsEnkZok1gnPCCpDVaaDaM I81OiWuWttVfZ2kO/5WC7q+uTDU5OW8AS+SnCkTyPGCixI5XWyAG6aclb1ZID0t Message-ID: <52FE2160.5030805@protected-networks.net> Date: Fri, 14 Feb 2014 09:00:00 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Borja Marcos , freebsd-scsi@freebsd.org Subject: Re: FreeBSD 10, ServeRAID M5210e, syspd corruption References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:00:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/14/14 07:44, Borja Marcos wrote: > I have seen that the newest cards support a so-called "syspd" mode that gives direct acess to the disks. > However, in this configuration, syspd consistently corrupts data on the disks. Just a silly "left field" idea .. can you try adding .. vfs.unmapped_buf_allowed=0 .. to /boot/loader.conf and re-testing? As I say, just an idea .. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlL+IWAACgkQQv9rrgRC1JK/LwCfS8cO2BWAimSO/W7Y8E1VsjuK L6wAnRgl46sXeO1f04Dn1oF+wwHK1zng =k1oh -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 14:24:22 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59968671 for ; Fri, 14 Feb 2014 14:24:22 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D43231C2A for ; Fri, 14 Feb 2014 14:24:21 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id pv20so9307813lab.16 for ; Fri, 14 Feb 2014 06:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=p26TaD/qIdTFLnHtV7Rze/RE79VjWxWb82YPiotSRoY=; b=hMquhTbcqRsynCHI+E90P3i7YN5GJhk0+NK8lKmlxf6mVYYQYAjM8r9N8GAST8c7Bl nKDXKRGl86X2KIXty8xTYZ0y9u9/bX9HJmjHWU2Ji6NURo1jdUmg5ioBDnUeih089iaR M6ONKedcrzcqe+EPF56RHbwiUh+9rNW4kYHdG3ciNGojMH+c2WYAGxJo6V2M3BkaHq62 9iPSLg5K90wSF405QlgbOCQDMaiRTU6lWBu1U42PRcld3p51J59+jod4I5CMo0mBQnb9 qkiH5YiHCzB6cZ+VKaPSJYTzTM2o5fQ1zBhij/c3EobP68wSiLBccIvfEzNcvJqOo7uF XY4Q== X-Received: by 10.152.236.72 with SMTP id us8mr5588446lac.11.1392387859903; Fri, 14 Feb 2014 06:24:19 -0800 (PST) Received: from magnetron.intra ([213.160.145.196]) by mx.google.com with ESMTPSA id w2sm8463451lad.4.2014.02.14.06.24.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 06:24:19 -0800 (PST) Message-ID: <52FE26FC.3070708@gmail.com> Date: Fri, 14 Feb 2014 16:23:56 +0200 From: Alexander Panyushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: converters/php55-iconv in FreeBSD 10 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:24:22 -0000 Hello All ! I need install converters/php55-iconv in FreeBSD 10 But this depends on the port converters/libiconv converters/libiconv is not installed in FreeBSD10 What would you suggest cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -D_FORTIFY_SOURCE=2 -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -c error.c error.c:378:12: warning: data argument not used by format string [-Wformat-extra-args] file_name, line_number); ^ 1 warning generated. rm -f libicrt.a ar cru libicrt.a allocator.o areadlink.o careadlinkat.o malloca.o progname.o safe-read.o width.o xmalloc.o xstrdup.o xreadlink.o canonicalize-lgpl.o error.o ranlib libicrt.a cd src && /usr/bin/make all cc -c -I. -I. -I.. -I../include -I./../include -I../srclib -I./../srclib -I../lib -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -DINSTALLDIR=\"/usr/local/bin\" -DLOCALEDIR=\"/usr/local/share/locale\" ./iconv_no_i18n.c /bin/sh ../libtool --mode=link cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security iconv_no_i18n.o ../srclib/libicrt.a ../lib/libiconv.la -o iconv_no_i18n libtool: link: cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security iconv_no_i18n.o -o .libs/iconv_no_i18n ../srclib/libicrt.a ../lib/.libs/libiconv.so -Wl,-rpath -Wl,/usr/local/lib ../lib/.libs/libiconv.so: undefined reference to `aliases2_lookup' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/ports/converters/libiconv/work/libiconv-1.14/src *** Error code 1 uname -a FreeBSD magnetron.intra 10.0-STABLE FreeBSD 10.0-STABLE #0 r261274: Thu Jan 30 11:34:04 EET 2014 root@magnetron.intra:/usr/obj/usr/src/sys/Kernel amd64 -- With best regards Alexander From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 14:43:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C4D567B for ; Fri, 14 Feb 2014 14:43:17 +0000 (UTC) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6B1C1E44 for ; Fri, 14 Feb 2014 14:43:16 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id o15so18215723qap.16 for ; Fri, 14 Feb 2014 06:43:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=is/mFhvPDnR641c5XwpNnXF27oihW7bZy/G/4EPK0pk=; b=bzTYiE80yYW+Jn+dARRqEdPUYSmo+CgLGuNjcsQZKUnA7F0Vmfg9HP4WSBFohbqHSS sBn9JG/lLH0a0nD9YJqMC1o0AuG2vIAyV5FKbG9CendLRyUQO5KhxkDqDhQ1X96o/INc t7gYs9B+r0CCc+fJBzsmKWg+Nyr8sNJGaDSNM9teabjx/KpzjIsy222XfBDJqEVkRiV9 9uWegQbEXvN/4pIWbgb5QMcdGsIuSImgP5cOgDec0mmYNLNhQ7VsDnuGApRfAQG8pRzr 1789O8fy+S1sRkJtyiAPalGv+uxg0aFBQFijjvXHODv/tOjne0rEok9kEkpnRntn+uYz eudg== X-Gm-Message-State: ALoCoQmXqBPHU6wGUhIjKOdSzd+tPh7jKWp9iAL6cOe/whpW+0vDW0YZd3cpc7xFxij6vez6StI8 X-Received: by 10.229.118.4 with SMTP id t4mr13616876qcq.9.1392388990401; Fri, 14 Feb 2014 06:43:10 -0800 (PST) Received: from [97.251.168.225] (225.sub-97-251-168.myvzw.com. [97.251.168.225]) by mx.google.com with ESMTPSA id u1sm6526876qac.1.2014.02.14.06.43.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 06:43:09 -0800 (PST) Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> From: Mark Saad Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (11B554a) In-Reply-To: <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> Message-Id: <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> Date: Fri, 14 Feb 2014 09:43:08 -0500 To: "freebsd-stable@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:43:17 -0000 > On Feb 14, 2014, at 8:49 AM, Mark Felder wrote: >=20 >=20 >=20 >> On Sat, Feb 8, 2014, at 13:38, Marko Cupa=C4=87 wrote: >> First of all, I wouldn't go with 10-RELEASE, as it is not officially >> supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. >=20 > "FreeBSD" is "not officially supported" by VMWare. Trust me. We threw > $60,000 at them and they still wouldn't acknowledge bugs. I couldn't > even find an engineer that knew what FreeBSD was! >=20 So you need to remind the engineers at VMware their parent company EMC uses a= nd sells things based on FreeBSD. Mainly Isilon and spectra logic as well as= other things .=20 > Plus you have to consider that we don't even know what version of ESXi > he's working with in the first place. According to their OS support > matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. >=20 > http://www.vmware.com/resources/compatibility/search.php?deviceCategory=3D= software&partner=3D109&testConfigurations=3D16&page=3D1&display_interval=3D1= 0&sortColumn=3DPartner&sortOrder=3DAsc&testConfig=3D16 > ______________________________________________ If we , all of the VMware users who use FreeBSD on esxi , work out a good se= t I notes for using VMware esxi + FreeBSD and work up a good page on wiki.f= reebsd.org; we can make some of the users have a better experience and we c= an help EMC / VMware with support as a Side effect .=20 Anyone interested in helping ?=20 --/ Mark Saad=20= From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 14:46:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 955B4B2C; Fri, 14 Feb 2014 14:46:43 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) by mx1.freebsd.org (Postfix) with ESMTP id 535D81F9F; Fri, 14 Feb 2014 14:46:42 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 280D19DCE86; Fri, 14 Feb 2014 15:46:41 +0100 (CET) Subject: Re: FreeBSD 10, ServeRAID M5210e, syspd corruption Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="utf8"; X-Pgp-Agent: GPGMail (null) From: Borja Marcos In-Reply-To: <52FE2160.5030805@protected-networks.net> Date: Fri, 14 Feb 2014 15:46:33 +0100 Content-Transfer-Encoding: 8bit Message-Id: References: <52FE2160.5030805@protected-networks.net> To: Michael Butler X-Mailer: Apple Mail (2.1283) Cc: freebsd-scsi@freebsd.org, Stable Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:46:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 14, 2014, at 3:00 PM, Michael Butler wrote: Signed PGP part On 02/14/14 07:44, Borja Marcos wrote: > I have seen that the newest cards support a so-called "syspd" mode that gives direct acess to the disks. > However, in this configuration, syspd consistently corrupts data on the disks. Just a silly "left field" idea .. can you try adding .. vfs.unmapped_buf_allowed=0 Thanks. Same result unfortunately. Borja. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlL+LE8ACgkQULpVo4XWgJ+GSwCguixlvwrVRgc73VgaqcSbEN1M 7fEAoKMa0ksOUd2DxQskoYGRTHpCzEOj =Othe -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 15:05:17 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37348B07 for ; Fri, 14 Feb 2014 15:05:17 +0000 (UTC) Received: from mailrelay003.isp.belgacom.be (mailrelay003.isp.belgacom.be [195.238.6.53]) by mx1.freebsd.org (Postfix) with ESMTP id C485C11F3 for ; Fri, 14 Feb 2014 15:05:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGAGkw/lJbsJEl/2dsb2JhbABZgwY4wAmBExd0giUBAQU6HCMQCw4KCSUPKh4GiBwByRsXjnkHhDgEmCuBM5Bxgy47 Received: from 37.145-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.145.37]) by relay.skynet.be with ESMTP; 14 Feb 2014 16:04:56 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id s1EF4tlu088689; Fri, 14 Feb 2014 16:04:56 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Fri, 14 Feb 2014 16:04:55 +0100 From: Tijl Coosemans To: Alexander Panyushkin Subject: Re: converters/php55-iconv in FreeBSD 10 Message-ID: <20140214160455.26d39e9d@kalimero.tijl.coosemans.org> In-Reply-To: <52FE26FC.3070708@gmail.com> References: <52FE26FC.3070708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:05:17 -0000 On Fri, 14 Feb 2014 16:23:56 +0200 Alexander Panyushkin wrote: > Hello All ! > I need install converters/php55-iconv in FreeBSD 10 > But this depends on the port converters/libiconv > converters/libiconv is not installed in FreeBSD10 > > What would you suggest > > > cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl > -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -D_FORTIFY_SOURCE=2 -Oz > -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments > -Qunused-parameter -Wformat -Wformat-security -c error.c > error.c:378:12: warning: data argument not used by format string > [-Wformat-extra-args] > file_name, line_number); > ^ > 1 warning generated. > rm -f libicrt.a > ar cru libicrt.a allocator.o areadlink.o careadlinkat.o malloca.o > progname.o safe-read.o width.o xmalloc.o xstrdup.o xreadlink.o > canonicalize-lgpl.o error.o > ranlib libicrt.a > cd src && /usr/bin/make all > cc -c -I. -I. -I.. -I../include -I./../include -I../srclib -I./../srclib > -I../lib -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_FORTIFY_SOURCE=2 -DINSTALLDIR=\"/usr/local/bin\" > -DLOCALEDIR=\"/usr/local/share/locale\" ./iconv_no_i18n.c > /bin/sh ../libtool --mode=link cc -Oz -march=athlon64-sse3 > -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter > -Wformat -Wformat-security iconv_no_i18n.o ../srclib/libicrt.a > ../lib/libiconv.la -o iconv_no_i18n > libtool: link: cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > iconv_no_i18n.o -o .libs/iconv_no_i18n ../srclib/libicrt.a > ../lib/.libs/libiconv.so -Wl,-rpath -Wl,/usr/local/lib > ../lib/.libs/libiconv.so: undefined reference to `aliases2_lookup' > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > > Stop. > make[3]: stopped in src > *** Error code 1 > > > > > uname -a > FreeBSD magnetron.intra 10.0-STABLE FreeBSD 10.0-STABLE #0 r261274: Thu > Jan 30 11:34:04 EET 2014 > root@magnetron.intra:/usr/obj/usr/src/sys/Kernel amd64 Last time someone reported this they had O_NOATIME in /usr/include/fcntl.h. If that's the case for you too then update world+kernel. If not, send me /usr/ports/converters/libiconv/work/libiconv-1.14/config.log From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 15:12:48 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D30DAF6C for ; Fri, 14 Feb 2014 15:12:48 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4CA12C4 for ; Fri, 14 Feb 2014 15:12:48 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id i4so14683308oah.13 for ; Fri, 14 Feb 2014 07:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nY5wK+ElTN5oEd90EUDzTMsaTRxCj6XVpOJZQAL4oHc=; b=YRKmHRw6g5JGBwq/tJ68RXI+kd0brrTlmhquPBB7pR7SB7S5OcAaD5mjf8GQB8aGqp eeDaSiQPegRYFUQmhW1FROFIZxZD12lGb3xmlszmkXXEBZQ+NiYCRa5CtUKfr5tJbVXI fsev2edICiv6gsY8S2TzTZZnbQNAh0WbL2rXFXuqh/T8VcT8Qw8rryobVYwLf4qxRmWM JJUbCSTnPgq+C9VUHji5oHQ0qixVX8SQyIwnZAsuIFqXlYnPa9adATaTaE+bvlyYeB1R jQT+RuxqglGiQng2C0zy1y85RzKqxiyCEB8g+NIMvjrHag4LPFlkXyx0rtJnn4mTjCzj CEQA== MIME-Version: 1.0 X-Received: by 10.60.33.229 with SMTP id u5mr743650oei.85.1392390767887; Fri, 14 Feb 2014 07:12:47 -0800 (PST) Received: by 10.60.23.33 with HTTP; Fri, 14 Feb 2014 07:12:47 -0800 (PST) In-Reply-To: <52FE26FC.3070708@gmail.com> References: <52FE26FC.3070708@gmail.com> Date: Fri, 14 Feb 2014 10:12:47 -0500 Message-ID: Subject: Re: converters/php55-iconv in FreeBSD 10 From: Stephen R Guglielmo To: Alexander Panyushkin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:12:48 -0000 On Fri, Feb 14, 2014 at 9:23 AM, Alexander Panyushkin wrote: > Hello All ! > I need install converters/php55-iconv in FreeBSD 10 > But this depends on the port converters/libiconv > converters/libiconv is not installed in FreeBSD10 > > What would you suggest > Both seem to be installed and working on my 10.0-RELEASE amd64 system: ~# pkg version -vP | g icon libiconv-1.14_1 = up-to-date with port php55-iconv-5.5.9 = up-to-date with port Your ports are up-to-date? Sometimes weird build errors can be caused by things in your src.conf when you built the system. What do you have in there? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 15:13:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABBDEDE; Fri, 14 Feb 2014 15:13:16 +0000 (UTC) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59EAC12D7; Fri, 14 Feb 2014 15:13:15 +0000 (UTC) Received: from www.dweimer.net (webmail [192.168.5.2]) by webmail.dweimer.net (8.14.7/8.14.7) with ESMTP id s1EFD8Lv000246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Feb 2014 09:13:08 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 14 Feb 2014 09:13:08 -0600 From: dweimer To: Mark Saad Subject: Re: FreeBSD 10 on VMWare in a corporate network; =?UTF-8?Q?How=3F?= Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> Message-ID: <5dcefb214b0503028606f53da194f4c1@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.0-rc Cc: owner-freebsd-stable@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:13:16 -0000 On 02/14/2014 8:43 am, Mark Saad wrote: >> On Feb 14, 2014, at 8:49 AM, Mark Felder wrote: >> >> >> >>> On Sat, Feb 8, 2014, at 13:38, Marko Cupać wrote: >>> First of all, I wouldn't go with 10-RELEASE, as it is not officially >>> supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. >> >> "FreeBSD" is "not officially supported" by VMWare. Trust me. We threw >> $60,000 at them and they still wouldn't acknowledge bugs. I couldn't >> even find an engineer that knew what FreeBSD was! >> > > So you need to remind the engineers at VMware their parent company EMC > uses and sells things based on FreeBSD. Mainly Isilon and spectra > logic as well as other things . > > >> Plus you have to consider that we don't even know what version of ESXi >> he's working with in the first place. According to their OS support >> matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. >> >> http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software&partner=109&testConfigurations=16&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc&testConfig=16 >> ______________________________________________ > > If we , all of the VMware users who use FreeBSD on esxi , work out a > good set I notes for using VMware esxi + FreeBSD and work up a good > page on wiki.freebsd.org; we can make some of the users have a better > experience and we can help EMC / VMware with support as a Side effect > . > > Anyone interested in helping ? > > --/ > Mark Saad > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" I would be interested, I have been running various version of FreeBSD on various ESX and VMWare for some time. I have found few little gotchas, but for the most part it has been running great. Including FreeBSD 10, on the latest version of VMware Workstation, ESXi 5.5 and ESXi 5.1. I don't however use the VMware Tools install from within VMware, and instead use the emulators/open-vm-tools port. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 15:34:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE72B2C3 for ; Fri, 14 Feb 2014 15:34:53 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A55621531 for ; Fri, 14 Feb 2014 15:34:53 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 853DD20AA5 for ; Fri, 14 Feb 2014 10:34:52 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Fri, 14 Feb 2014 10:34:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=t1D85gY9gVoNWDGAXc49znzA864=; b=f95 +CXKvv5fNGKAE/WZQx9G90TeXpWWWNa6k5/u8CtFeZMcuiO45D1gKndquNcs9rwJ ZAk6lhoMSH5nJN4DqSyfevJLpag6VzMLPJNRcsCe3Gj1141Pd+lRy6qd/JvRepNt c9NP6LQ3egQgWpAWQ0dHCpukBIaQ5F1+m3zpL1lY= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 6500C11EC62; Fri, 14 Feb 2014 10:34:52 -0500 (EST) Message-Id: <1392392092.3444.83451713.6EEBCBB9@webmail.messagingengine.com> X-Sasl-Enc: 96W2buZlKKY+yF9cAEaO6eXn2nrOoSe9AbNGmHXvoxRx 1392392092 From: Mark Felder To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e72899be In-Reply-To: <5dcefb214b0503028606f53da194f4c1@dweimer.net> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> <5dcefb214b0503028606f53da194f4c1@dweimer.net> Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? Date: Fri, 14 Feb 2014 09:34:52 -0600 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:34:54 -0000 On Fri, Feb 14, 2014, at 9:13, dweimer wrote: > On 02/14/2014 8:43 am, Mark Saad wrote: > >> On Feb 14, 2014, at 8:49 AM, Mark Felder wrote: > >>=20 > >>=20 > >>=20 > >>> On Sat, Feb 8, 2014, at 13:38, Marko Cupa=C4=87 wrote: > >>> First of all, I wouldn't go with 10-RELEASE, as it is not officially > >>> supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. > >>=20 > >> "FreeBSD" is "not officially supported" by VMWare. Trust me. We threw > >> $60,000 at them and they still wouldn't acknowledge bugs. I couldn't > >> even find an engineer that knew what FreeBSD was! > >>=20 > >=20 > > So you need to remind the engineers at VMware their parent company EMC > > uses and sells things based on FreeBSD. Mainly Isilon and spectra > > logic as well as other things . > >=20 > >=20 > >> Plus you have to consider that we don't even know what version of ESXi > >> he's working with in the first place. According to their OS support > >> matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. > >>=20 > >> http://www.vmware.com/resources/compatibility/search.php?deviceCategor= y=3Dsoftware&partner=3D109&testConfigurations=3D16&page=3D1&display_interva= l=3D10&sortColumn=3DPartner&sortOrder=3DAsc&testConfig=3D16 > >> ______________________________________________ > >=20 > > If we , all of the VMware users who use FreeBSD on esxi , work out a > > good set I notes for using VMware esxi + FreeBSD and work up a good > > page on wiki.freebsd.org; we can make some of the users have a better > > experience and we can help EMC / VMware with support as a Side effect > > . > >=20 > > Anyone interested in helping ? > >=20 > > --/ > > Mark Saad > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to=20 > > "freebsd-stable-unsubscribe@freebsd.org" >=20 > I would be interested, I have been running various version of FreeBSD on= =20 > various ESX and VMWare for some time. I have found few little gotchas,=20 > but for the most part it has been running great. Including FreeBSD 10,=20 > on the latest version of VMware Workstation, ESXi 5.5 and ESXi 5.1. I=20 > don't however use the VMware Tools install from within VMware, and=20 > instead use the emulators/open-vm-tools port. >=20 I will gladly offer any relevant notes I may have from our internal wiki if someone starts some documentation. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 16:07:29 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40F90DFF for ; Fri, 14 Feb 2014 16:07:29 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F251B1893 for ; Fri, 14 Feb 2014 16:07:23 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 839D2139C4 for ; Fri, 14 Feb 2014 14:09:10 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1392394149; x=1393258150; bh=QtXXagZxw/GHESLJ9iDGsG7sf1AozQhdI2W iZrxtcKo=; b=UuQ9XChQNQBRxAYOZiNXkqcTKOG6O4p3Y3rvkDXkKYJ7UWzNL3W t9qM/FaVU8h31zkHYpgRTv/F7cuWozwX0+BqtYWCYYIfZ2USL1Kysbpl46j6DBoS IRjTItr5oGaGxh8K0cQj6X+fN2ar9uZoEY9zoo9Mu2ia4g/TCoQpJhyk= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vBIoY2UpPxZ for ; Fri, 14 Feb 2014 14:09:09 -0200 (BRST) Received: from MacBook-de-Gondim-2.local (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 6D768139C3 for ; Fri, 14 Feb 2014 14:09:09 -0200 (BRST) Message-ID: <52FE3F37.90504@bsdinfo.com.br> Date: Fri, 14 Feb 2014 14:07:19 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: Re: converters/php55-iconv in FreeBSD 10 References: <52FE26FC.3070708@gmail.com> In-Reply-To: <52FE26FC.3070708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:07:29 -0000 Hi, Look this before: 20130904: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv AUTHOR: madpilot@FreeBSD.org 10-CURRENT after r254273 (committed on August 13, 2013) has an implementation of iconv enabled by default in libc. Due to this change some major overhauling of the ports tree has been necessary to move the ports to using that implementation. People using pkgng binary packages should have little problems, "pkg upgrade" will update all software to not depend on libiconv anymore, once updated packages are available. Please make sure to perform a "pkg autoremove" after that and check that libiconv is correctly removed by it. If you are using ports the update requires some manual intervention. The following procedure should be followed: # pkg query %ro libiconv >ports_to_update # pkg delete -f libiconv # cat ports_to_update | xargs portmaster or: # pkg query %ro libiconv >ports_to_update # pkg delete -f libiconv # cat ports_to_update | xargs portupgrade -f and try it: pkg delete -f php55-iconv and after re-install port php55-iconv Em 14/02/14 12:23, Alexander Panyushkin escreveu: > Hello All ! > I need install converters/php55-iconv in FreeBSD 10 > But this depends on the port converters/libiconv > converters/libiconv is not installed in FreeBSD10 > > What would you suggest > > > cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl > -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -D_FORTIFY_SOURCE=2 > -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-arguments > -Qunused-parameter -Wformat -Wformat-security -c error.c > error.c:378:12: warning: data argument not used by format string > [-Wformat-extra-args] > file_name, line_number); > ^ > 1 warning generated. > rm -f libicrt.a > ar cru libicrt.a allocator.o areadlink.o careadlinkat.o malloca.o > progname.o safe-read.o width.o xmalloc.o xstrdup.o xreadlink.o > canonicalize-lgpl.o error.o > ranlib libicrt.a > cd src && /usr/bin/make all > cc -c -I. -I. -I.. -I../include -I./../include -I../srclib > -I./../srclib -I../lib -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 > -pipe -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > -D_FORTIFY_SOURCE=2 -DINSTALLDIR=\"/usr/local/bin\" > -DLOCALEDIR=\"/usr/local/share/locale\" ./iconv_no_i18n.c > /bin/sh ../libtool --mode=link cc -Oz -march=athlon64-sse3 > -mtune=athlon64-sse3 -pipe -Qunused-arguments -Qunused-parameter > -Wformat -Wformat-security iconv_no_i18n.o ../srclib/libicrt.a > ../lib/libiconv.la -o iconv_no_i18n > libtool: link: cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-arguments -Qunused-parameter -Wformat -Wformat-security > iconv_no_i18n.o -o .libs/iconv_no_i18n ../srclib/libicrt.a > ../lib/.libs/libiconv.so -Wl,-rpath -Wl,/usr/local/lib > ../lib/.libs/libiconv.so: undefined reference to `aliases2_lookup' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Stop. > make[3]: stopped in /usr/ports/converters/libiconv/work/libiconv-1.14/src > *** Error code 1 > > > > > uname -a > FreeBSD magnetron.intra 10.0-STABLE FreeBSD 10.0-STABLE #0 r261274: > Thu Jan 30 11:34:04 EET 2014 > root@magnetron.intra:/usr/obj/usr/src/sys/Kernel amd64 > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 19:27:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3618ACC; Fri, 14 Feb 2014 19:27:03 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 785601CD0; Fri, 14 Feb 2014 19:27:03 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s1EJPXrL085831; Fri, 14 Feb 2014 11:25:34 -0800 (PST) (envelope-from freebsd@pki2.com) Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Dennis Glatting To: dweimer@dweimer.net In-Reply-To: <5dcefb214b0503028606f53da194f4c1@dweimer.net> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> <5dcefb214b0503028606f53da194f4c1@dweimer.net> Content-Type: text/plain; charset="iso-8859-2" Date: Fri, 14 Feb 2014 11:25:33 -0800 Message-ID: <1392405933.19170.1.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1EJPXrL085831 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: owner-freebsd-stable@freebsd.org, Mark Saad , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:27:03 -0000 On Fri, 2014-02-14 at 09:13 -0600, dweimer wrote: > On 02/14/2014 8:43 am, Mark Saad wrote: > >> On Feb 14, 2014, at 8:49 AM, Mark Felder wrote: > >> > >> > >> > >>> On Sat, Feb 8, 2014, at 13:38, Marko Cupaæ wrote: > >>> First of all, I wouldn't go with 10-RELEASE, as it is not officially > >>> supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. > >> > >> "FreeBSD" is "not officially supported" by VMWare. Trust me. We threw > >> $60,000 at them and they still wouldn't acknowledge bugs. I couldn't > >> even find an engineer that knew what FreeBSD was! > >> > > > > So you need to remind the engineers at VMware their parent company EMC > > uses and sells things based on FreeBSD. Mainly Isilon and spectra > > logic as well as other things . > > > > > >> Plus you have to consider that we don't even know what version of ESXi > >> he's working with in the first place. According to their OS support > >> matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. > >> > >> http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software&partner=109&testConfigurations=16&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc&testConfig=16 > >> ______________________________________________ > > > > If we , all of the VMware users who use FreeBSD on esxi , work out a > > good set I notes for using VMware esxi + FreeBSD and work up a good > > page on wiki.freebsd.org; we can make some of the users have a better > > experience and we can help EMC / VMware with support as a Side effect > > . > > > > Anyone interested in helping ? > > > > --/ > > Mark Saad > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > I would be interested, I have been running various version of FreeBSD on > various ESX and VMWare for some time. I have found few little gotchas, > but for the most part it has been running great. Including FreeBSD 10, > on the latest version of VMware Workstation, ESXi 5.5 and ESXi 5.1. I > don't however use the VMware Tools install from within VMware, and > instead use the emulators/open-vm-tools port. > Sorry to jump in the middle of this thread but I too have been running FreeBSD 9.x and 10.0 under ESXi 5.1 for some time. It is NOT problem free, such as 'dump' can cause the system to lock, but it does work well enough. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 14 20:48:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A825526; Fri, 14 Feb 2014 20:48:08 +0000 (UTC) Received: from smtp2.bway.net (smtp2.v6.bway.net [IPv6:2607:d300:1::28]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EACEC157C; Fri, 14 Feb 2014 20:48:07 +0000 (UTC) Received: from [10.3.2.41] (host-216-220-116-154.dsl.bway.net [216.220.116.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp2.bway.net (Postfix) with ESMTPSA id 2F25195871; Fri, 14 Feb 2014 15:47:56 -0500 (EST) References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> <1392385745.4914.83410473.135CDC76@webmail.messagingengine.com> <28B68434-113E-4ABA-931E-3DAB666A2BA5@longcount.org> <5dcefb214b0503028606f53da194f4c1@dweimer.net> <1392405933.19170.1.camel@btw.pki2.com> In-Reply-To: <1392405933.19170.1.camel@btw.pki2.com> Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 Message-Id: <21D8F382-134A-4F9F-B5DC-4A4E7A0C7CC6@bway.net> Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? Date: Fri, 14 Feb 2014 15:47:55 -0500 To: Dennis Glatting X-Mailer: Apple Mail (2.1085) Cc: owner-freebsd-stable@freebsd.org, Mark Saad , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:48:08 -0000 On Feb 14, 2014, at 2:25 PM, Dennis Glatting wrote: > On Fri, 2014-02-14 at 09:13 -0600, dweimer wrote: >> On 02/14/2014 8:43 am, Mark Saad wrote: >>>> On Feb 14, 2014, at 8:49 AM, Mark Felder wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Sat, Feb 8, 2014, at 13:38, Marko Cupa=C4=87 wrote: >>>>> First of all, I wouldn't go with 10-RELEASE, as it is not = officially >>>>> supported. Go for 9.2-RELEASE amd64 or expect all kinds of = problems. >>>>=20 >>>> "FreeBSD" is "not officially supported" by VMWare. Trust me. We = threw >>>> $60,000 at them and they still wouldn't acknowledge bugs. I = couldn't >>>> even find an engineer that knew what FreeBSD was! >>>>=20 >>>=20 >>> So you need to remind the engineers at VMware their parent company = EMC >>> uses and sells things based on FreeBSD. Mainly Isilon and spectra >>> logic as well as other things . >>>=20 >>>=20 >>>> Plus you have to consider that we don't even know what version of = ESXi >>>> he's working with in the first place. According to their OS support >>>> matrix, FreeBSD 9.2 is only "supported" on ESXi 5.5. >>>>=20 >>>> = http://www.vmware.com/resources/compatibility/search.php?deviceCategory=3D= software&partner=3D109&testConfigurations=3D16&page=3D1&display_interval=3D= 10&sortColumn=3DPartner&sortOrder=3DAsc&testConfig=3D16 >>>> ______________________________________________ >>>=20 >>> If we , all of the VMware users who use FreeBSD on esxi , work out a >>> good set I notes for using VMware esxi + FreeBSD and work up a good >>> page on wiki.freebsd.org; we can make some of the users have a = better >>> experience and we can help EMC / VMware with support as a Side = effect >>> . >>>=20 >>> Anyone interested in helping ? >>>=20 >>> --/ >>> Mark Saad >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to=20 >>> "freebsd-stable-unsubscribe@freebsd.org" >>=20 >> I would be interested, I have been running various version of FreeBSD = on=20 >> various ESX and VMWare for some time. I have found few little = gotchas,=20 >> but for the most part it has been running great. Including FreeBSD = 10,=20 >> on the latest version of VMware Workstation, ESXi 5.5 and ESXi 5.1. = I=20 >> don't however use the VMware Tools install from within VMware, and=20 >> instead use the emulators/open-vm-tools port. >>=20 >=20 > Sorry to jump in the middle of this thread but I too have been running > FreeBSD 9.x and 10.0 under ESXi 5.1 for some time. It is NOT problem > free, such as 'dump' can cause the system to lock, but it does work = well > enough. We're running 8.4 under ESXi 5.0 and 5.1 with no huge issues. I am still unclear on what the best choices are for vmware tools - the open source tools or the vmware-supplied tools. Ditto on which NIC is most proper. I've also seen conflicting notes on whether to let the host sync time using vmware tools or ntp. I'm currently using ntp. I can also share an ugly bug and workaround. We had time stop on a bunch of hosts. It was not immediately apparent what was going on, as the first symptom was the inability to create new inbound connections. This was pf not seeing time move forward, and therefore not aging anything out of the state tables. Oops. My notes reference this KB article: = http://kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&cmd= =3DdisplayKC&externalId=3D2021185 Apparently it's fixed. The workaround worked. Upating vmware does scare the crap out of me. I'm seriously considering moving to Xen or BHyve the next time an upgrade is necessary. Charles >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 14:23:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A53C8AA3 for ; Sat, 15 Feb 2014 14:23:36 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 644B51AD7 for ; Sat, 15 Feb 2014 14:23:36 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ij19so10119231vcb.20 for ; Sat, 15 Feb 2014 06:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YY1h9hqkcZYgzaWfgfY124k64kyzSS3HrFJqIehyZZk=; b=Ap55T9hR27JNyGTj3i996i7rl2UHJVrTcAJOZDAd5xq0ZazPP9eqDzsrELlgUMEQ7d 2DfKOtatwxYmglLmXV7Jkep1U7+KUBRDTVHWsNW6GxC3CnzsN4Vh1gWspDTaCRH4Pyc7 ClPFs2gJRnd3WxC9k5xvweGTJ77fjzp4ku8AG8TDpuHdnloe6dHnK0N7luac6ZCKMK/q sQMstk9WXDDQjPmzJplBCMsl4v8UK7jbS0irZGgOs915Kv4lZNmRkrVWAOe7Zcaj2rJr TDoFSH6c8BYuY2HewtPV1ZtXt36AAlMeBgCdbJwAdQ2dmyNd6IXWLDt3zC3nwWUmd8To 1Y6w== MIME-Version: 1.0 X-Received: by 10.220.247.68 with SMTP id mb4mr123484vcb.37.1392474215353; Sat, 15 Feb 2014 06:23:35 -0800 (PST) Received: by 10.58.169.113 with HTTP; Sat, 15 Feb 2014 06:23:35 -0800 (PST) Date: Sat, 15 Feb 2014 22:23:35 +0800 Message-ID: Subject: Recommend FreeBSD VPS From: =?UTF-8?B?5pyx5rGf?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 14:23:36 -0000 Hi, I'm looking for a cheap FreeBSD VPS, can you guys provide me some good service provider? BTW, I currently in China and I hope the VPS should have low latency. Thanks, -- Jiang Zhu mail.jiang.cn@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 16:52:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC1C501 for ; Sat, 15 Feb 2014 16:52:03 +0000 (UTC) Received: from apollo.teardrop.org (apollo.teardrop.org [173.228.105.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D74E916D1 for ; Sat, 15 Feb 2014 16:52:03 +0000 (UTC) Received: by apollo.teardrop.org (Postfix, from userid 30000) id 3002AF7E; Sat, 15 Feb 2014 16:45:10 +0000 (UTC) Date: Sat, 15 Feb 2014 08:45:10 -0800 From: James Snow To: mail.jiang.cn@gmail.com Subject: Re: Recommend FreeBSD VPS Message-ID: <20140215164510.GZ24097@teardrop.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 16:52:04 -0000 > I'm looking for a cheap FreeBSD VPS, can you guys provide me some good > service provider? BTW, I currently in China and I hope the VPS should have > low latency. I have been happy with these guys: http://www.hostvirtual.com/os/bsd-hosting/freebsd-vps They have a site in Hong Kong: http://www.hostvirtual.com/cloud-locations/asia/ -Snow From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 18:54:07 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B07E0CDE for ; Sat, 15 Feb 2014 18:54:07 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 252C61FDE for ; Sat, 15 Feb 2014 18:54:06 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id hr13so10290281lab.31 for ; Sat, 15 Feb 2014 10:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=zaQggqLm/ZVxp4iY6e2GZzXNC79d/biZIfHoVV2lZ8U=; b=OAVyAfd+MT2KLomuB6bjhm1c3dlSAnvR14BvhTZldGotzJyzkF/Hnp/QaRe/LLyjRt ZImmjKPcue3RXxYUpCjwON8cGPdQsP5ivvUeC/eKoWHxgbNJF0+ISZgaKSBSFJKcQ14E 9Xfp7OxGF6Du2E4Hm1Eing8xOiEfOgr6x1IJqbkjrgbYrtkJ+6BpZ6/CnTLlBXujOaTv hz8LwzIjRYoxnHyRA301Pk3mfubGVmXvmlyn1X63A4naVxXiNBrW2PgMDpNWrjM0gBlF 0v0wTJ+xiVjR3EuOo5EZEkCSQ8sAcCDXPf9Tumipha+WzK00rmD8vLryzQKO8WOF9NaH uihA== X-Received: by 10.112.40.114 with SMTP id w18mr10190715lbk.20.1392490445183; Sat, 15 Feb 2014 10:54:05 -0800 (PST) Received: from alex.super ([195.238.246.110]) by mx.google.com with ESMTPSA id jf8sm10964978lbc.8.2014.02.15.10.54.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 10:54:03 -0800 (PST) From: "Alex V. Petrov" To: stable@freebsd.org Subject: converters/php5-iconv in FreeBSD 10 Date: Sun, 16 Feb 2014 02:53:59 +0800 Message-ID: <18385084.zn1sEgg2iJ@alex.super> User-Agent: KMail/4.12.2 (FreeBSD/10.0-STABLE; KDE/4.12.2; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:54:07 -0000 I see the topic "converters/php55-iconv in FreeBSD 10" What do you say about this: php5-iconv-5.4.25 The deinstallation will free 52 KB Proceed with deinstalling packages [y/N]: y [1/1] Deleting php5-iconv-5.4.25... php5-iconv-5.4.25 is required by: php5-extensions-1.7, deleting anyway done # portmaster converters/php5-iconv ===>>> Port directory: /usr/ports/converters/php5-iconv ===>>> Launching 'make checksum' for converters/php5-iconv in background ===>>> Gathering dependency list for converters/php5-iconv from ports ===>>> Launching child to install converters/libiconv ===>>> converters/php5-iconv >> converters/libiconv (1/1) ===>>> Port directory: /usr/ports/converters/libiconv ===>>> Launching 'make checksum' for converters/libiconv in background ===>>> Gathering dependency list for converters/libiconv from ports ===>>> Initial dependency check complete for converters/libiconv ===>>> Continuing initial dependency check for converters/php5-iconv ===>>> Initial dependency check complete for converters/php5-iconv ===>>> converters/php5-iconv >> (1) ===>>> The following actions will be taken if you choose to proceed: Install converters/php5-iconv Install converters/libiconv ===>>> Proceed? y/n [y] n -- ----- Alex V. Petrov From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 18:57:38 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD8E8DEB for ; Sat, 15 Feb 2014 18:57:38 +0000 (UTC) Received: from Opium.Pharm.Guru (Opium.Pharm.Guru [162.243.227.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 886302000 for ; Sat, 15 Feb 2014 18:57:38 +0000 (UTC) X-OurDotGuru-Mailborder-Watermark: 1393095322.53044@4V9FKPoGXmbgptlXjy+r0Q X-OurDotGuru-Mailborder-From: lucius.rizzo@lucius.xxx X-OurDotGuru-Mailborder-SpamCheck: not spam, SpamAssassin (not cached, score=-0.75, required 3, autolearn=not spam, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_DNSWL_BLOCKED 0.00, RP_MATCHES_RCVD -0.65) X-OurDotGuru-Mailborder-IP-Protocol: IPv4 X-OurDotGuru-Mailborder: Found to be clean X-OurDotGuru-Mailborder-ID: BC19D40EBD.AA549 X-OurDotGuru-Mailborder-Information: Please contact your admin for more information Received: from lucius.XxX (lucius.XxX [95.85.22.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by Opium.Pharm.Guru (Postfix) with ESMTPS id BC19D40EBD; Sat, 15 Feb 2014 13:55:21 -0500 (EST) Authentication-Results: Opium.Pharm.Guru; dkim=pass reason="2048-bit key; unprotected key" header.d=lucius.xxx header.i=@lucius.xxx header.b=M2LIKlUs; dkim-adsp=pass Received: from Lucius.XxX (lrizzo@localhost.localdomain [127.0.0.1]) by lucius.XxX (8.14.8/8.14.8) with ESMTP id s1FItJwB012997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Feb 2014 18:55:19 GMT DKIM-Filter: OpenDKIM Filter v2.9.0 lucius.XxX s1FItJwB012997 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucius.xxx; s=default; t=1392490520; bh=3Cq7i2jJcemBsJWoNBfvFgzIIg/pxw5mlnLb9uz+19g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; z=Date:=20Sat,=2015=20Feb=202014=2018:55:19=20+0000|From:=20Lucius= 20Rizzo=20|To:=20??????=20|Cc:=20freebsd-stable@freebsd.org|Subject:=20Re:=20Recom mend=20FreeBSD=20VPS|References:=20|In-Reply-To:=20; b=M2LIKlUsGkufmyMQ6kkXp6bgS3qS/oSCqzXwBWoVEtfDUq2nr4BPWADjjvLZPs22i f/A1hLwENL/2R5hThu3Gd2/BZAFXtEAIWyqzVa4souY2BFfnPvf+/4dEpMpjBcx7zd 2JWygC9EA7ehqvDlutGtcIC3DmPpCzcvOoHLMWoE3EWI086Z8YjNCrQt9XVOGh8csw UYyraQzQUk1SAaC5sUpVlCp1QYQ2nSFtFjlwmB2wY5AuscCeiMd+TKZdmKQlVn4BJ+ uWisO0rhP/VvgRyNyhj8z8NJTzD1rtYWx4tL9vkp0DwXYrfSEpR7+pFLHwFe3kl9Eu BR3J3KgxDglxQ== Received: (from lrizzo@localhost) by Lucius.XxX (8.14.8/8.14.8/Submit) id s1FItJEl012996; Sat, 15 Feb 2014 18:55:19 GMT X-Authentication-Warning: Lucius.XxX: lrizzo set sender to Lucius.Rizzo@Lucius.XxX using -f Date: Sat, 15 Feb 2014 18:55:19 +0000 From: Lucius Rizzo To: ?????? Subject: Re: Recommend FreeBSD VPS Message-ID: <20140215185519.GA12962@lucius.XxX> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Organization: T.gT Consulting - http://t.gt X-Homepage: http://www.Say.Si User-Agent: Mutt/1.5.22 (2013-10-16) X-PWhois-Status: No originator identified Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:57:39 -0000 * ?????? [2014-02-15 22:23]: > Hi, > > I'm looking for a cheap FreeBSD VPS, can you guys provide me some good > service provider? BTW, I currently in China and I hope the VPS should have > low latency. I am currently using BlueVM (bluevm.com) KVM4's spread over US East/West and Zurich. They are pretty good and actually work out to be even cheaper than DigitalOcean (For Specs/month). Being a KVM, one can run FreeBSD/NetBSD easily and the isos are provided. I have had issues with OpenBSD seeing only 1 cpu which aren't seen in FreeBSD or NetBSD. In terms of the cloud VPS providers, I have migrated mostly from AWS to Azure to DO and now to BlueVM. Though I have servers spread in many various VPS providersi, in terms of cost I get 4core CPU, 2GB RAM, 40GB Disk, 3TB of bandwidth, Any OS of my choice for around $5/monthly. Spread over Zurich, Switzerland, California and Buffalo are nice options for redudancy. Though you may need to define what you want this for and what audience. You can spin them in Asia-Pacific region VPS providers with similar prices. Though you can spin FreeBSD instances in AWS Asia-Pacific easily. We have instances in Singapore (in DO) and Tokyo. BlueVM are coming out with Native IPv6 in their ZU node soon and I am kinda excited to ditch HE TB. Linode offers full IPv6/rDNS but they are 4x more than BlueVM for me. PS - If you find that their website doesn't show load/availability, join their chat room and speak to someone there. Sometimes you can find awesome deals. Disclaimer - I do not work for any of the providers above -- | _o _ |_)o_ _ _ |_|_|(_||_|_> | \|/_/_(_) - Lucius.Tel -------------------------------------- ++ "Elves and Dragons!" I says to him. "Cabbages and potatoes are better ++ ++ for you and me." ++ ++ -- J. R. R. Tolkien ++ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 19:01:56 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44CF9AE for ; Sat, 15 Feb 2014 19:01:56 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DEEA10B5 for ; Sat, 15 Feb 2014 19:01:55 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id C30F2139C9 for ; Sat, 15 Feb 2014 17:03:37 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1392491017; x=1393355018; bh=7q54Irp8KKTU 4U8iLjMUMXFUDm+wLqgFwqmmvXVJFVs=; b=XBgrNJA0KG1MyDvEkLvdUl8hXfJ3 wK1lmROBjCentPNzNSgWSBlUzwvEkbFc+q8hFX1SuQgPPK825i0/Zvmhk8mTe79H ICuat2L/31kpQZVRhNQu6z7kOwER/UNgFK2FnVXGozGnOJsAQVDa0npbysCMoZo/ hRlTWTtHLmE5/l8= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql2AlJzon-k2 for ; Sat, 15 Feb 2014 17:03:37 -0200 (BRST) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 8B110139C3 for ; Sat, 15 Feb 2014 17:03:36 -0200 (BRST) Message-ID: <52FFB999.8010200@bsdinfo.com.br> Date: Sat, 15 Feb 2014 17:01:45 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: Re: converters/php5-iconv in FreeBSD 10 References: <18385084.zn1sEgg2iJ@alex.super> In-Reply-To: <18385084.zn1sEgg2iJ@alex.super> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 19:01:56 -0000 Hi, Did you read this before? 20130904: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv AUTHOR: madpilot@FreeBSD.org 10-CURRENT after r254273 (committed on August 13, 2013) has an implementation of iconv enabled by default in libc. Due to this change some major overhauling of the ports tree has been necessary to move the ports to using that implementation. People using pkgng binary packages should have little problems, "pkg upgrade" will update all software to not depend on libiconv anymore, once updated packages are available. Please make sure to perform a "pkg autoremove" after that and check that libiconv is correctly removed by it. If you are using ports the update requires some manual intervention. The following procedure should be followed: # pkg query %ro libiconv >ports_to_update # pkg delete -f libiconv # cat ports_to_update | xargs portmaster or: # pkg query %ro libiconv >ports_to_update # pkg delete -f libiconv # cat ports_to_update | xargs portupgrade -f Cheers Em 15/02/14 16:53, Alex V. Petrov escreveu: > I see the topic "converters/php55-iconv in FreeBSD 10" > > What do you say about this: > > > php5-iconv-5.4.25 > > The deinstallation will free 52 KB > > Proceed with deinstalling packages [y/N]: y > [1/1] Deleting php5-iconv-5.4.25... > php5-iconv-5.4.25 is required by: php5-extensions-1.7, deleting anyway > done > > # portmaster converters/php5-iconv > > ===>>> Port directory: /usr/ports/converters/php5-iconv > > ===>>> Launching 'make checksum' for converters/php5-iconv in background > ===>>> Gathering dependency list for converters/php5-iconv from ports > ===>>> Launching child to install converters/libiconv > > ===>>> converters/php5-iconv >> converters/libiconv (1/1) > > ===>>> Port directory: /usr/ports/converters/libiconv > > ===>>> Launching 'make checksum' for converters/libiconv in background > ===>>> Gathering dependency list for converters/libiconv from ports > ===>>> Initial dependency check complete for converters/libiconv > > ===>>> Continuing initial dependency check for converters/php5-iconv > ===>>> Initial dependency check complete for converters/php5-iconv > > > ===>>> converters/php5-iconv >> (1) > > ===>>> The following actions will be taken if you choose to proceed: > Install converters/php5-iconv > Install converters/libiconv > > ===>>> Proceed? y/n [y] n > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 19:09:33 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26E772A3 for ; Sat, 15 Feb 2014 19:09:33 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1987110A for ; Sat, 15 Feb 2014 19:09:32 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id va2so15506026obc.29 for ; Sat, 15 Feb 2014 11:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EFeSrNKxIkCR5Jos2Usnf6JiOTDpp6SlboM7R6x/xfM=; b=nQmavx5Vuqm6a8EP7CFYvIgGab1xZht05NbAooEfulGeUZL8SxFjnMcfEcUKCJ2l3y Js/vE/Cwb+YHT1+ZHhje4bIr4pUCg0fuZ578itoGDVruV04QUgvbWlWXZ+jjWVXd/lNc WhZlJiPhDJsVmX1sCwIpwJ4TW29FOZ3WSTPkRkuMTO2u9BcCZtkYHEx7WRkcWNzGlyI2 v7tHXO0DOcFn2a37mKq0y2RMCYgHvXFHFoe69GCLvXzfEILmzHeZuqZ/jx6WBVKylPcn BX73AcSmARVdnyjXk2J+0xB8qb8zhrEWJnYgDw0z130sr+kZUWTCdXnjA6dpAGaHzGLi CqTA== X-Received: by 10.60.132.234 with SMTP id ox10mr12534109oeb.17.1392491372166; Sat, 15 Feb 2014 11:09:32 -0800 (PST) MIME-Version: 1.0 Sender: alexvpetrov@gmail.com Received: by 10.182.202.6 with HTTP; Sat, 15 Feb 2014 11:09:11 -0800 (PST) In-Reply-To: <52FFB999.8010200@bsdinfo.com.br> References: <18385084.zn1sEgg2iJ@alex.super> <52FFB999.8010200@bsdinfo.com.br> From: "Alex V. Petrov" Date: Sun, 16 Feb 2014 03:09:11 +0800 X-Google-Sender-Auth: VZAo2mx0l32wZNlulYD3FhBXaUM Message-ID: Subject: Re: converters/php5-iconv in FreeBSD 10 To: Marcelo Gondim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 19:09:33 -0000 I read and did it. Moreover, I recently rearranged all ports: portmaster -af And for me, only this port requires converters/libiconv 2014-02-16 3:01 GMT+08:00 Marcelo Gondim : > Hi, > > Did you read this before? > > 20130904: > AFFECTS: 10-CURRENT users with any port depending on converters/libiconv > AUTHOR: madpilot@FreeBSD.org > > 10-CURRENT after r254273 (committed on August 13, 2013) has an > implementation of iconv enabled by default in libc. > > Due to this change some major overhauling of the ports tree has > been necessary to move the ports to using that implementation. > > People using pkgng binary packages should have little problems, > "pkg upgrade" will update all software to not depend on libiconv > anymore, once updated packages are available. Please make sure to > perform a "pkg autoremove" after that and check that libiconv is > correctly removed by it. > > If you are using ports the update requires some manual intervention. > The following procedure should be followed: > > # pkg query %ro libiconv >ports_to_update > # pkg delete -f libiconv > # cat ports_to_update | xargs portmaster > > or: > > # pkg query %ro libiconv >ports_to_update > # pkg delete -f libiconv > # cat ports_to_update | xargs portupgrade -f > > Cheers > > Em 15/02/14 16:53, Alex V. Petrov escreveu: > > I see the topic "converters/php55-iconv in FreeBSD 10" >> >> What do you say about this: >> >> >> php5-iconv-5.4.25 >> >> The deinstallation will free 52 KB >> >> Proceed with deinstalling packages [y/N]: y >> [1/1] Deleting php5-iconv-5.4.25... >> php5-iconv-5.4.25 is required by: php5-extensions-1.7, deleting anyway >> done >> >> # portmaster converters/php5-iconv >> >> ===>>> Port directory: /usr/ports/converters/php5-iconv >> >> ===>>> Launching 'make checksum' for converters/php5-iconv in background >> ===>>> Gathering dependency list for converters/php5-iconv from ports >> ===>>> Launching child to install converters/libiconv >> >> ===>>> converters/php5-iconv >> converters/libiconv (1/1) >> >> ===>>> Port directory: /usr/ports/converters/libiconv >> >> ===>>> Launching 'make checksum' for converters/libiconv in background >> ===>>> Gathering dependency list for converters/libiconv from ports >> ===>>> Initial dependency check complete for converters/libiconv >> >> ===>>> Continuing initial dependency check for converters/php5-iconv >> ===>>> Initial dependency check complete for converters/php5-iconv >> >> >> ===>>> converters/php5-iconv >> (1) >> >> ===>>> The following actions will be taken if you choose to proceed: >> Install converters/php5-iconv >> Install converters/libiconv >> >> ===>>> Proceed? y/n [y] n >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 20:12:29 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BED2F67 for ; Sat, 15 Feb 2014 20:12:29 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50A8E15C6 for ; Sat, 15 Feb 2014 20:12:29 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id i4so16004464oah.39 for ; Sat, 15 Feb 2014 12:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a/HQKyhFTOmkOEiZGhFF971jqTg2st8JycnFwnPRtQQ=; b=Emex9UgANxVDHyo0EOAayCNSexLuP3ITZyawe0xPurfd1O6A+N9axXF8MkQd/mvZmP Yg6uex30R+mu0q4+IXTVwSY8+0YTgM/eb/4I3doWWiZkNflUD5LOuZo+vEEnSfiBg2LN +srFdplqsBRcnZqmfsvxrRQDIOykqmGczQnQTln9LRZV90Wcs7mNUw7pC9QwcJfCx43e c3N+cx2J6HFh6nFYPb10FG81SjxXR+idUncFhSbvR2EJvI72OAhLH+iM05vEkvzuWPJH LETJS/xR5VtL80+qt7Ti7uADmu2jABrJGvx3ED6gGuGNGkvVyhcTBb+5PD9kC4IY6jeM MyTg== MIME-Version: 1.0 X-Received: by 10.60.84.143 with SMTP id z15mr13110602oey.27.1392495148630; Sat, 15 Feb 2014 12:12:28 -0800 (PST) Received: by 10.182.92.36 with HTTP; Sat, 15 Feb 2014 12:12:28 -0800 (PST) In-Reply-To: <20140112034203.GA59496@kib.kiev.ua> References: <1389478327.46758.7.camel@powernoodle.corp.yahoo.com> <1389480297.46758.9.camel@powernoodle.corp.yahoo.com> <20140112034203.GA59496@kib.kiev.ua> Date: Sat, 15 Feb 2014 15:12:28 -0500 Message-ID: Subject: Re: panic: stable/10 with Debugging enabled in kern_cons.c:500 From: Benjamin Kaduk To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:12:29 -0000 On Sat, Jan 11, 2014 at 10:42 PM, Konstantin Belousov wrote: > On Sat, Jan 11, 2014 at 02:44:57PM -0800, Sean Bruno wrote: > > > panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx > > > @ /usr/src/sys/kern/kern_cons.c:500 > > Add > options WITNESS_SKIPSPIN > to the kernel config. This is required now, unfortunately. > I ran into this a few days ago (I had missed Sean's report here) as well. It seems a poor state to be in; can we mark the cnputs_mtx to not be checked by WITNESS? (Or is it a more generic problem with all spin locks and cnputs is just the first one that is used?) -Ben From owner-freebsd-stable@FreeBSD.ORG Sat Feb 15 21:59:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EAC4694 for ; Sat, 15 Feb 2014 21:59:06 +0000 (UTC) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 51C991CAC for ; Sat, 15 Feb 2014 21:59:05 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 025331152C for ; Sat, 15 Feb 2014 16:49:23 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fK-3RefvCwv for ; Sat, 15 Feb 2014 16:49:22 -0500 (EST) Received: from EGR authenticated sender Message-ID: <52FFE0E1.70603@egr.msu.edu> Date: Sat, 15 Feb 2014 16:49:21 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: converters/php5-iconv in FreeBSD 10 References: <18385084.zn1sEgg2iJ@alex.super> In-Reply-To: <18385084.zn1sEgg2iJ@alex.super> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 21:59:06 -0000 On 02/15/2014 13:53, Alex V. Petrov wrote: > I see the topic "converters/php55-iconv in FreeBSD 10" > > What do you say about this: > > > php5-iconv-5.4.25 > > The deinstallation will free 52 KB > > Proceed with deinstalling packages [y/N]: y > [1/1] Deleting php5-iconv-5.4.25... > php5-iconv-5.4.25 is required by: php5-extensions-1.7, deleting anyway > done > > # portmaster converters/php5-iconv > > ===>>> Port directory: /usr/ports/converters/php5-iconv > > ===>>> Launching 'make checksum' for converters/php5-iconv in background > ===>>> Gathering dependency list for converters/php5-iconv from ports > ===>>> Launching child to install converters/libiconv > > ===>>> converters/php5-iconv >> converters/libiconv (1/1) > > ===>>> Port directory: /usr/ports/converters/libiconv > > ===>>> Launching 'make checksum' for converters/libiconv in background > ===>>> Gathering dependency list for converters/libiconv from ports > ===>>> Initial dependency check complete for converters/libiconv > > ===>>> Continuing initial dependency check for converters/php5-iconv > ===>>> Initial dependency check complete for converters/php5-iconv > > > ===>>> converters/php5-iconv >> (1) > > ===>>> The following actions will be taken if you choose to proceed: > Install converters/php5-iconv > Install converters/libiconv > > ===>>> Proceed? y/n [y] n > This should be correct. This change re-allowed FreeBSD 10 to use libiconv from ports: http://svnweb.freebsd.org/ports?view=revision&revision=341775 And this change made the php-iconv ports use it to fix a bug: http://svnweb.freebsd.org/ports?view=revision&revision=341778 However some other ports are unaware (unless fixed already) that libiconv is now allowed yet they complain about it.