From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 00:33:19 2013 Return-Path: Delivered-To: current@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 84347E1A; Sun, 1 Dec 2013 00:33:19 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30DFD1444; Sun, 1 Dec 2013 00:33:19 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id i13so3083128qae.10 for ; Sat, 30 Nov 2013 16:33: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=1yxCWMpZQgsom/cnYvh8R7hDXC1nd3mLBohnHiuqsns=; b=ykEkYhqPJWYe4VioZJcwqKBZQckZnwBQJuSWawGoCEbDuX1rsxi/ZlGR4Zcqv+dveB qPi5iIJBfBCs1t8nE8n0BYZfGQPlp8aK3aafzQktgITvUj0miF4pyCVjPDDBeWlHsnxR 3tyYKh0EN8XTVOEHBAkfGVeNzjYyalV+FF9xrHVDUOYgZ7EUsvsME30Fnrsdk2YQH7/b 77EyvwruMnMGWCR8yfznFtPGtPHk5ZGQH0SYLLtfTDNbQeN5gd7l0zOFmy8iZg126wNu lUlg0EeU7jsFkbJ5wWi+S+rPdvepT5/bfB/CU22zxsuhWevZHFpEN0K8TUrVdNohwZCB PvhA== MIME-Version: 1.0 X-Received: by 10.229.49.8 with SMTP id t8mr99912267qcf.21.1385857997212; Sat, 30 Nov 2013 16:33:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sat, 30 Nov 2013 16:33:17 -0800 (PST) In-Reply-To: References: <20131130135616.GA59496@kib.kiev.ua> Date: Sat, 30 Nov 2013 16:33:17 -0800 X-Google-Sender-Auth: lzqRF1qjiayRik2OiuCEt2CBzpA Message-ID: Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 00:33:19 -0000 On 30 November 2013 15:25, Dimitry Andric wrote: > On 30 Nov 2013, at 14:56, Konstantin Belousov wrote: >> I propose to unconditionally add the switch -fno-strict-overflow to the >> kernel compilation. See the patch at the end of message for exact change >> proposed. >> >> What does it do. It disallows useless and counter-intuitive behaviour of >> the compiler(s) for the signed overflow. Basically, the issue is that >> the C standard left signed overflow as undefined to allow for different >> hardware implementation of signess to be used for signed arithmetic. >> De-facto, all architectures where FreeBSD works or have a chance to be >> ported, use two-complement signed integer representation, and developers >> intuition is right about it. > > I think this is quite a misrepresentation. Any C compiler is free to do > whatever it wants whenever it encounters undefined behavior. Some > behavior is undefined in the C standards, so compilers can do a better > job at optimization. > > If the optimized code fails to do what the programmer thinks it does, it > is almost always the programmer's fault, excluding actual compiler bugs > (which are unavoidable, as all software has bugs). > > Basically, if you rely on undefined behavior, you are inventing your own > de facto language, which is *not* C. That is fine with me, but let's > not pretend the FreeBSD kernel is written in C then. :-) Are you able to have clang/llvm/gcc tell us where/when code is relying on undefined behaviour? So we can, like, fix them? If there was a way to lint this stuff then yes, please lint it. Otherwise we don't have the tools to know whether we're doing sane things or not. (Same with things like strict aliasing..) -adrian From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 02:20:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0012E65B; Sun, 1 Dec 2013 02:20:05 +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 B04BB18B8; Sun, 1 Dec 2013 02:20:05 +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 rB12K3H6073939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Nov 2013 18:20:04 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rB12K39R073938; Sat, 30 Nov 2013 18:20:03 -0800 (PST) (envelope-from jmg) Date: Sat, 30 Nov 2013 18:20:03 -0800 From: John-Mark Gurney To: Luigi Rizzo Subject: Re: [RFC] how to get the size of a malloc(9) block ? Message-ID: <20131201022002.GE55638@funkthat.com> Mail-Followup-To: Luigi Rizzo , Adrian Chadd , freebsd-current , jb References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 30 Nov 2013 18:20:04 -0800 (PST) Cc: Adrian Chadd , freebsd-current , jb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 02:20:06 -0000 Luigi Rizzo wrote this message on Fri, Nov 29, 2013 at 17:11 -0800: > On Fri, Nov 29, 2013 at 4:49 PM, Adrian Chadd wrote: > > > The reason I wouldn't implement this is to avoid having code that > > _relies_ on this behaviour in order to function or perform well. > > > nobody ever said (or could reasonably expect to do) that. > > Applications don't know if the allocator overallocates, > so they have no hope unless they work even without the feature. > > This is only about giving them an option to improve > performance in those (rare ?) cases where, as i showed, > knowing the underlying allocation size may lead to > better usage of memory. This sounds like optimizing before measuring if your putting in code like that... Either it happens rarely, and always doing a realloc won't hurt performance, or it happens often, and then you should be using a larger buffer in the first place.. Do I need to quote the optimization rules? -- 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-current@FreeBSD.ORG Sun Dec 1 02:20:47 2013 Return-Path: Delivered-To: current@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 DDBC0780 for ; Sun, 1 Dec 2013 02:20:47 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76BEA18C5 for ; Sun, 1 Dec 2013 02:20:47 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpKY5-1VAZ1Z0qur-00f9NB for ; Sun, 01 Dec 2013 03:20:40 +0100 Message-ID: <529A9CD7.8080503@gmx.com> Date: Sun, 01 Dec 2013 03:20:07 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Adrian Chadd , Dimitry Andric Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds References: <20131130135616.GA59496@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TgkTlNeCGiSqNoUSajKmca5QCyeHV82A89mo2Z3cmTvjU1GMTjc gbcojAenZ/TEHVQ0IoEEDdKuWJ9NKDZMH7HZHVhv2f84e8Y7F44YwQAjBaomFSkeTS+yYZk OkYySFV32JY9iMczz2Kz7s2Y+vfBmbsEZJ+WKKlGjYx4pGI8XwJKUD8rS2bmt0zbtA9+ij6 HhrhsH1/BuoaeLxT49mNQ== Cc: Konstantin Belousov , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 02:20:47 -0000 Adrian Chadd wrote, On 12/01/2013 01:33: > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? Well, there's -ftrapv. From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 03:05:02 2013 Return-Path: Delivered-To: freebsd-current@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 8C09EFD9 for ; Sun, 1 Dec 2013 03:05:02 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 225C81AFC for ; Sun, 1 Dec 2013 03:05:02 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MAUpK-1Vsygw0lEA-00Bblb for ; Sun, 01 Dec 2013 04:05:00 +0100 Message-ID: <529AA73A.9@gmx.com> Date: Sun, 01 Dec 2013 04:04:26 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Luigi Rizzo , Adrian Chadd , freebsd-current , jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? References: <20131201022002.GE55638@funkthat.com> In-Reply-To: <20131201022002.GE55638@funkthat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZTco5Bl8PIVK9r7U9E0d92mmHH3WeNq4Zvshq3/nCtaKKm2iLRE sxK7VxdTVNHa/ajB8USuJ+dzpJoVR3R160PQZ9ihKEl1c/vk6W+ul274FYdQ2GLMhu3q+sI jFJmVYmIGMdxCxpkUi6BLYcPEsGD9egeubEtv3aTcx+txMqzilkrfi07XjO/wMXvhljER1A IePwd3/28UhHXWs5UbpQA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 03:05:02 -0000 John-Mark Gurney wrote, On 12/01/2013 03:20: > Either it happens rarely, and always doing a realloc won't hurt > performance, or it happens often, and then you should be using a larger > buffer in the first place.. What if a size-elastic implementation of a dynamic data structure would be able to adjust to the malloc implementation, such as agreeing to allocate regions of size (2^k - 8)? Much like the use of getpagesize() (yes, I know it's not part of a technical standard). From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 03:51:57 2013 Return-Path: Delivered-To: freebsd-current@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 BAFB59EF for ; Sun, 1 Dec 2013 03:51:57 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 854931D12 for ; Sun, 1 Dec 2013 03:51:57 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uz6so11371514obc.20 for ; Sat, 30 Nov 2013 19:51:56 -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=ovNBjF0v3RGculNFvJFjjMBi8fHCbaHtUQDTugXwcIo=; b=crGnnpZMsAQztG1wwL9oNWGMqH3PUs774zztnCn4+/ADSfL+M6g4KImi48SCGfBhIu PmFwcTf6PbxfYGXrPD16jZK7u3dbKshsEhQQlmZP98lbzGQo+Q8eos9/D+POPm8A/01w 8b5D2cQ2uIrnNORimfGbb6y97QUQQHiFWEbfga91H2cn7JT5XbNP+UUUF5dMccFJzgYR GLcC8IHd+3AWCozGKOkLlPWhtjFqWyDmld7hBVii1d3NFcNFX2hTZyPpznYT/vnRNEWb qutNrMJ3KDQPplsrKMUpAt7suDLSczHXV2WT1VrQrV68HK4OlPfT8IVCLfz9YR+Fl9sG 0bsw== MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr49073732oer.8.1385869916669; Sat, 30 Nov 2013 19:51:56 -0800 (PST) Received: by 10.76.99.210 with HTTP; Sat, 30 Nov 2013 19:51:56 -0800 (PST) Date: Sat, 30 Nov 2013 22:51:56 -0500 Message-ID: Subject: CURRENT 11.0 ZFS as of Today From: Outback Dingo To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 03:51:57 -0000 Just came across this error....... zfs -mm master errors with Assertion failed: (tq->tq_freelist != NULL), file /master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c, line 289. Abort (core dumped) From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:04:46 2013 Return-Path: Delivered-To: freebsd-current@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 AB91ED2C; Sun, 1 Dec 2013 04:04:46 +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 7F58B1D9F; Sun, 1 Dec 2013 04:04:46 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 8FE611920B; Sun, 1 Dec 2013 04:04:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 8FE611920B Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 30 Nov 2013 23:04:42 -0500 From: Glen Barber To: Outback Dingo Subject: Re: CURRENT 11.0 ZFS as of Today Message-ID: <20131201040442.GN31807@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zxEKvxCKojqA/Afl" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:04:46 -0000 --zxEKvxCKojqA/Afl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 30, 2013 at 10:51:56PM -0500, Outback Dingo wrote: > Just came across this error....... >=20 > zfs -mm master errors with >=20 > Assertion failed: (tq->tq_freelist !=3D NULL), file > /master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzp= ool/common/taskq.c, > line 289. > Abort (core dumped) What should it to? % zfs -mm master unrecognized command '-mm' Glen --zxEKvxCKojqA/Afl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSmrVaAAoJELls3eqvi17QfVsP/iBPQ2ZHnftnWXxuBH3JoTS1 4sBg/GXugoYYTIa357Zp7/Q9Mxq8mDheibPcmw10v/XU4+DAQC1BWm4HjufoSymW HdQ/5i5o1rcoSJ2fQbwyluAlwX3sM2OGmC4FgfLf3uNR0RjcclNz9amtpdx9PyUx HAuV3faupPfg4py7cnc73dHFt1jQQ2enwrOkfH7hjFvXabyoCdSSQV8xJV6mgpnc WOwBBAOyQsymFeBPFvPaySnJUlpJx3zXk6c+6ZRTJFDXXOfbzbJDHZWF8/UJ5m/4 AUD4TnrBMjHCr96Yal0vZIRn7tYg8yOAsf4Bv0nBL+IcIknv855s/e9ShXapoYdH r4hnUKH6iUe78ezfuAS54ATaoRui3nyW1qL+JY5DxkKcgab5cma6ggUbUVztaqtV nGeJeiR93qV6WV04MJ2VsTbE4eT9RHFZm42uKFl564tYM3jxOP1/WCNC3akWRkCJ 0gnN/+B/5/CJu+mgZ/Fo9eum7CkRbcsxKSMGYdTCOfg+1L8OIty7pzWVMahkFZX0 PnVm4YoO16NP3FqamBVw+oSZ4LhiPXsyEkBfTrNLxu3LPnmJWXJ8T+VUI4v4YUiw oDdLd8TWUz1c9Dsx9CD0At9Vd96HgcjDgTsNOlkd7t7xINhJEUVvwuxq/uLnyTFr dPyBPePrV9qsI3JtaO0D =VhLx -----END PGP SIGNATURE----- --zxEKvxCKojqA/Afl-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:09:27 2013 Return-Path: Delivered-To: freebsd-current@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 9411BEF1; Sun, 1 Dec 2013 04:09:27 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0031DC9; Sun, 1 Dec 2013 04:09:27 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wm4so11431991obc.14 for ; Sat, 30 Nov 2013 20:09:26 -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=xSReNYP7U+sDKGUsy7AS16y290wUDmPWqtO+kCCRzyw=; b=a5pz7pL0YHPEWuCC14cPFOfaiYTdPOU+Ry+JOgxIl1nSNYywP7erS/znxVGpYrQ330 B89UOB3mzw+L/n2Xr3iX6AyBK6JYQKqTf2X/T837J4WsAh5vA4EnYofooO2a6V1bjyMM w8s1io+MI3HMQj5xJvazQDLiqInk+gaWjJQ1cfJ0gnk2O5TItgUYKuxnqVZBuEi15DSY 3V2QnZJ8vAuVsG0VhVmlnfSrBnIEOyI8b2dkSYFHt4qIiApl8NpqHsJaDgtAVIiuO08U 3diNXb2xF45RQGcBMROaD4bHVpMX7dtx/4vXARyG8HZc+vsvbrckckfUEPkqQNBDoKb3 bSWg== MIME-Version: 1.0 X-Received: by 10.60.40.136 with SMTP id x8mr72396oek.49.1385870966472; Sat, 30 Nov 2013 20:09:26 -0800 (PST) Received: by 10.76.99.210 with HTTP; Sat, 30 Nov 2013 20:09:26 -0800 (PST) In-Reply-To: <20131201040442.GN31807@glenbarber.us> References: <20131201040442.GN31807@glenbarber.us> Date: Sat, 30 Nov 2013 23:09:26 -0500 Message-ID: Subject: Re: CURRENT 11.0 ZFS as of Today From: Outback Dingo To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:09:27 -0000 you have to upgrade your pool to enable histogram i believe zdb -mm master Metaslabs: vdev 0 metaslabs 103 offset spacemap free --------------- ------------------- --------------- ------------- metaslab 0 offset 0 spacemap 36 free 8.23M On-disk histogram: metaslab 1 offset 8000000 spacemap 160 free 13.9M On-disk histogram: metaslab 2 offset 10000000 spacemap 161 free 12.0M On-disk histogram: metaslab 3 offset 18000000 spacemap 163 free 4.53M On-disk histogram: metaslab 4 offset 20000000 spacemap 165 free 3.11M On-disk histogram: metaslab 5 offset 28000000 spacemap 166 free 2.53M On-disk histogram: metaslab 6 offset 30000000 spacemap 167 free 796K On-disk histogram: metaslab 7 offset 38000000 spacemap 168 free 12.5M On-disk histogram: metaslab 8 offset 40000000 spacemap 169 free 5.87M On-disk histogram: metaslab 9 offset 48000000 spacemap 171 free 23.6M On-disk histogram: metaslab 10 offset 50000000 spacemap 172 free 17.9M On-disk histogram: metaslab 11 offset 58000000 spacemap 173 free 54.3M On-disk histogram: metaslab 12 offset 60000000 spacemap 176 free 9.00M On-disk histogram: metaslab 13 offset 68000000 spacemap 178 free 7.07M On-disk histogram: metaslab 14 offset 70000000 spacemap 180 free 5.93M On-disk histogram: metaslab 15 offset 78000000 spacemap 182 free 21.1M On-disk histogram: metaslab 16 offset 80000000 spacemap 184 free 7.99M On-disk histogram: metaslab 17 offset 88000000 spacemap 186 free 9.9M On-disk histogram: metaslab 18 offset 90000000 spacemap 188 free 6.08M On-disk histogram: metaslab 19 offset 98000000 spacemap 190 free 5.28M On-disk histogram: metaslab 20 offset a0000000 spacemap 35 free 23.1M On-disk histogram: metaslab 21 offset a8000000 spacemap 159 free 7.71M On-disk histogram: metaslab 22 offset b0000000 spacemap 170 free 3.02M On-disk histogram: metaslab 23 offset b8000000 spacemap 162 free 8.93M On-disk histogram: metaslab 24 offset c0000000 spacemap 164 free 7.97M On-disk histogram: metaslab 25 offset c8000000 spacemap 191 free 6.54M On-disk histogram: metaslab 26 offset d0000000 spacemap 192 free 11.3M On-disk histogram: metaslab 27 offset d8000000 spacemap 195 free 5.45M On-disk histogram: metaslab 28 offset e0000000 spacemap 197 free 3.10M On-disk histogram: metaslab 29 offset e8000000 spacemap 198 free 13.6M On-disk histogram: metaslab 30 offset f0000000 spacemap 199 free 13.1M On-disk histogram: metaslab 31 offset f8000000 spacemap 200 free 376K On-disk histogram: metaslab 32 offset 100000000 spacemap 175 free 20.7M On-disk histogram: metaslab 33 offset 108000000 spacemap 177 free 8.16M On-disk histogram: metaslab 34 offset 110000000 spacemap 179 free 9.6M On-disk histogram: metaslab 35 offset 118000000 spacemap 181 free 47.7M On-disk histogram: metaslab 36 offset 120000000 spacemap 183 free 6.34M On-disk histogram: metaslab 37 offset 128000000 spacemap 185 free 30.4M On-disk histogram: metaslab 38 offset 130000000 spacemap 264 free 73.6M On-disk histogram: 12: 36 ************************************ 13: 11 *********** 14: 12 ************ 15: 7 ******* 16: 6 ****** 17: 7 ******* 18: 4 **** 19: 3 *** 20: 2 ** 21: 1 * 22: 2 ** 23: 2 ** 24: 1 * metaslab 39 offset 138000000 spacemap 203 free 30.2M On-disk histogram: metaslab 40 offset 140000000 spacemap 34 free 4.60M On-disk histogram: metaslab 41 offset 148000000 spacemap 262 free 62.2M On-disk histogram: 12: 40 **************************************** 13: 16 **************** 14: 23 *********************** 15: 22 ********************** 16: 41 **************************************** metaslab 42 offset 150000000 spacemap 207 free 2.23M On-disk histogram: metaslab 43 offset 158000000 spacemap 208 free 5.75M On-disk histogram: metaslab 44 offset 160000000 spacemap 202 free 4.32M On-disk histogram: metaslab 45 offset 168000000 spacemap 209 free 75.9M On-disk histogram: metaslab 46 offset 170000000 spacemap 210 free 668K On-disk histogram: metaslab 47 offset 178000000 spacemap 194 free 192K On-disk histogram: metaslab 48 offset 180000000 spacemap 196 free 6.68M On-disk histogram: metaslab 49 offset 188000000 spacemap 211 free 4.29M On-disk histogram: metaslab 50 offset 190000000 spacemap 212 free 252K On-disk histogram: metaslab 51 offset 198000000 spacemap 213 free 3.05M On-disk histogram: metaslab 52 offset 1a0000000 spacemap 174 free 64.9M On-disk histogram: metaslab 53 offset 1a8000000 spacemap 189 free 448K On-disk histogram: metaslab 54 offset 1b0000000 spacemap 214 free 2.95M On-disk histogram: metaslab 55 offset 1b8000000 spacemap 215 free 576K On-disk histogram: metaslab 56 offset 1c0000000 spacemap 216 free 188K On-disk histogram: metaslab 57 offset 1c8000000 spacemap 217 free 85.7M On-disk histogram: metaslab 58 offset 1d0000000 spacemap 218 free 64K On-disk histogram: metaslab 59 offset 1d8000000 spacemap 219 free 3.59M On-disk histogram: metaslab 60 offset 1e0000000 spacemap 220 free 83.1M On-disk histogram: metaslab 61 offset 1e8000000 spacemap 204 free 4.90M On-disk histogram: metaslab 62 offset 1f0000000 spacemap 206 free 3.41M On-disk histogram: metaslab 63 offset 1f8000000 spacemap 221 free 59.3M On-disk histogram: metaslab 64 offset 200000000 spacemap 201 free 18.8M On-disk histogram: metaslab 65 offset 208000000 spacemap 222 free 6.74M On-disk histogram: metaslab 66 offset 210000000 spacemap 223 free 89.7M On-disk histogram: metaslab 67 offset 218000000 spacemap 193 free 4.07M On-disk histogram: metaslab 68 offset 220000000 spacemap 225 free 2.83M On-disk histogram: metaslab 69 offset 228000000 spacemap 226 free 24.7M On-disk histogram: metaslab 70 offset 230000000 spacemap 227 free 4.49M On-disk histogram: metaslab 71 offset 238000000 spacemap 229 free 1.85M On-disk histogram: metaslab 72 offset 240000000 spacemap 230 free 3.58M On-disk histogram: metaslab 73 offset 248000000 spacemap 232 free 772K On-disk histogram: metaslab 74 offset 250000000 spacemap 233 free 90.2M On-disk histogram: metaslab 75 offset 258000000 spacemap 234 free 10.4M On-disk histogram: metaslab 76 offset 260000000 spacemap 235 free 1.63M On-disk histogram: metaslab 77 offset 268000000 spacemap 236 free 1.19M On-disk histogram: metaslab 78 offset 270000000 spacemap 237 free 2.46M On-disk histogram: metaslab 79 offset 278000000 spacemap 238 free 2.90M On-disk histogram: metaslab 80 offset 280000000 spacemap 239 free 276K On-disk histogram: metaslab 81 offset 288000000 spacemap 240 free 176K On-disk histogram: metaslab 82 offset 290000000 spacemap 241 free 58.4M On-disk histogram: metaslab 83 offset 298000000 spacemap 231 free 1.94M On-disk histogram: metaslab 84 offset 2a0000000 spacemap 242 free 5.70M On-disk histogram: metaslab 85 offset 2a8000000 spacemap 228 free 2.94M On-disk histogram: metaslab 86 offset 2b0000000 spacemap 243 free 2.31M On-disk histogram: metaslab 87 offset 2b8000000 spacemap 244 free 2.69M On-disk histogram: metaslab 88 offset 2c0000000 spacemap 245 free 3.56M On-disk histogram: metaslab 89 offset 2c8000000 spacemap 246 free 4.05M On-disk histogram: metaslab 90 offset 2d0000000 spacemap 247 free 8.32M On-disk histogram: metaslab 91 offset 2d8000000 spacemap 248 free 49.5M On-disk histogram: metaslab 92 offset 2e0000000 spacemap 249 free 4.20M On-disk histogram: metaslab 93 offset 2e8000000 spacemap 250 free 29.0M On-disk histogram: metaslab 94 offset 2f0000000 spacemap 251 free 1.14M On-disk histogram: metaslab 95 offset 2f8000000 spacemap 252 free 114M On-disk histogram: metaslab 96 offset 300000000 spacemap 253 free 85.3M On-disk histogram: metaslab 97 offset 308000000 spacemap 254 free 7.11M On-disk histogram: metaslab 98 offset 310000000 spacemap 255 free 23.4M On-disk histogram: metaslab 99 offset 318000000 spacemap 256 free 38.7M On-disk histogram: metaslab 100 offset 320000000 spacemap 260 free 101M On-disk histogram: 12: 13 ************* 13: 6 ****** 14: 12 ************ 15: 13 ************* 16: 18 ****************** 17: 1 * 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 2 ** 25: 1 * metaslab 101 offset 328000000 spacemap 224 free 9.8M On-disk histogram: metaslab 102 offset 330000000 spacemap 258 free 128M On-disk histogram: On Sat, Nov 30, 2013 at 11:04 PM, Glen Barber wrote: > On Sat, Nov 30, 2013 at 10:51:56PM -0500, Outback Dingo wrote: > > Just came across this error....... > > > > zfs -mm master errors with > > > > Assertion failed: (tq->tq_freelist != NULL), file > > > /master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c, > > line 289. > > Abort (core dumped) > > What should it to? > > % zfs -mm master > unrecognized command '-mm' > > Glen > > From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:15:20 2013 Return-Path: Delivered-To: freebsd-current@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 1D7D4184; Sun, 1 Dec 2013 04:15:20 +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 D1A791E27; Sun, 1 Dec 2013 04:15:19 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 72804192F6; Sun, 1 Dec 2013 04:15:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 72804192F6 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 30 Nov 2013 23:15:15 -0500 From: Glen Barber To: Outback Dingo Subject: Re: CURRENT 11.0 ZFS as of Today Message-ID: <20131201041515.GO31807@glenbarber.us> References: <20131201040442.GN31807@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O7Os1+MGCLLi8F5z" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:15:20 -0000 --O7Os1+MGCLLi8F5z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 30, 2013 at 11:09:26PM -0500, Outback Dingo wrote: > you have to upgrade your pool to enable histogram i believe >=20 > zdb -mm master >=20 So, is the problem with zfs(8), or zdb(8) ? >=20 > On Sat, Nov 30, 2013 at 11:04 PM, Glen Barber wrote: >=20 > > On Sat, Nov 30, 2013 at 10:51:56PM -0500, Outback Dingo wrote: > > > Just came across this error....... > > > > > > zfs -mm master errors with > > > > > > Assertion failed: (tq->tq_freelist !=3D NULL), file > > > > > /master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/lib= zpool/common/taskq.c, > > > line 289. > > > Abort (core dumped) > > > > What should it to? > > > > % zfs -mm master > > unrecognized command '-mm' > > > > Glen > > > > --O7Os1+MGCLLi8F5z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSmrfTAAoJELls3eqvi17QnAIP/iTBF/uXzJst+sXH4727MCUo 69QMeSUbYVfyRnIeX5uIJ2/XFLUEDi+e+/QHY4YNHW5+r/h8+NRTgMlIQDRueeUI zRdXIG9loQ6fP/oQgHR9tMtmdDxvZ/M6Pt6agBFCcNkWM6yNHHpa7IEkgg1KzOTG PKrtSJfPdiObbnMR49EFaBJXsa+8RNluT1mJzgANoXFBeDQhNMM0u5D1pX5k7kl3 MGBlOWsNwxdGEMwWBzcjujYjf+jAgDpnsd99tvX/MvfVOHD92Lx1QoAEwCzHn4fp VStEHyTsw5ljKbJOPiq8kKKVCrBetW0pS25LAaZ3dQGAqWHtEjjrIUaoJEtdevdH NWo+hs39CL5+IaHNVak8HG6yfcYy75huU5kpfrXe2kIghu0h23B9Vqu+qvaG6jxl 6o+s9vXZE6KNNNVhCB1PLhiyIuDeutFz9zXtQCNdMyw1SAPnIcxkd9Lxddslt3ih 0TMPxm+b64BVKjw055FmKKb6oC5wihIa13UnQEozmoA4oqwe+i1NvnomDKXv7m09 rwxSFI/lPuOJ54WvY/OZsVPNMy2eBOWPqxv81mhlJ6dxGImNWOgh3SvKjnsV2AVo SBpepKVvNw7f6If3rI/01j+Veya7s6NAhGcbp7RITn5Edc7WdbBosEorRw6v1jC/ gtJqMfd5ZPTMpVu3Qv21 =XWDK -----END PGP SIGNATURE----- --O7Os1+MGCLLi8F5z-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:26:20 2013 Return-Path: Delivered-To: current@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 913D939F for ; Sun, 1 Dec 2013 04:26:20 +0000 (UTC) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c: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 3DC001E93 for ; Sun, 1 Dec 2013 04:26:20 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id m10so7526251vbh.38 for ; Sat, 30 Nov 2013 20:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZTabH3Zi8LsCFbzvkvR3FxwEmEBJmAmKnnKMBAvWtXE=; b=0clB4P53FA41CfKe53pIfRj0fzP0G1QYFFCARFIG20soKNqCXG60K0U9ojwo40he6B frrPBQ6xlGo4p1fOpa25gWm3TNXl+sh/wOa/+E/Wa9rOuE2AlR90+s05JMF9hZXilEIq B94KCTLYwioWruvrfT8gk/YfjAVNZBlE6XPec= 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:date :message-id:subject:from:to:cc:content-type; bh=ZTabH3Zi8LsCFbzvkvR3FxwEmEBJmAmKnnKMBAvWtXE=; b=gbek/zr3k/wtWylL0ThTD3Y6T2gZ4dKCf5PDusMItYO6P7ipjaCDgjGijRqNKFDkh9 eFtsx7Wo/tVHkJjlvlWkIC1BdRbCt3azG6KwD5rDi83iwora0WwWbbFy3RAo+9P0klws 3zXMXnM2wOZlukWBxicJKNbu1VWAD0r9IVSqkahM9wMAxzEolO3uuQnssi1BHQ1P/O+F PmaX2Vaj/6EBir7w8TCV1dTTS729VxENbBXbPkEO96KdJ/k7OlzG0AwuLyFUomV135LA hugYJV6q/SrrE1VGfdZXznyRjXLBakWrPJub9EE4FGLRTgUENrTC0L1JvQ5n8dXEeSBN 6ttA== X-Gm-Message-State: ALoCoQlDXcvAZH9A0ieE8T4qJjsALGmi2YNbUB8aFneeXARKz9SfZZAoXBZlqQEQaYyK/6kTdEqP MIME-Version: 1.0 X-Received: by 10.221.44.136 with SMTP id ug8mr47474317vcb.13.1385871978635; Sat, 30 Nov 2013 20:26:18 -0800 (PST) Received: by 10.220.167.74 with HTTP; Sat, 30 Nov 2013 20:26:18 -0800 (PST) In-Reply-To: References: <20131130135616.GA59496@kib.kiev.ua> Date: Sat, 30 Nov 2013 20:26:18 -0800 Message-ID: Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:26:20 -0000 On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote: [..] > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? It wasn't all that long ago that we had this wonderful thing called -Werror and had a clean kernel build. The problem is that gcc and clang have different warning sets. I seem to recall we had -Werror on for gcc and off for clang. IMHO it would be more useful to do it the other way around. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:39:16 2013 Return-Path: Delivered-To: current@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 E51DD62E for ; Sun, 1 Dec 2013 04:39:16 +0000 (UTC) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d: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 9C3B71F0F for ; Sun, 1 Dec 2013 04:39:16 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id ne12so11997791qeb.39 for ; Sat, 30 Nov 2013 20:39:15 -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=I7NQI1GiE6Yvnpebx/gCiJRV+wbmV+CBSNTT9GeEjSA=; b=eU/HvaOtHvG1epP0taM8W+ZsHIig4yBTHYgCarVAbUei9uvIArH83D+IMG13eYa0zk Kg4Lyab7NXD5//6rNOWqPW39X3dHwpEOpNPoR/ssljqULW7neX5vIM+OfGujXDsqOmsv s/zZkbsckN5JxN675f11qWhJkDwco7DRR/dic= 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=I7NQI1GiE6Yvnpebx/gCiJRV+wbmV+CBSNTT9GeEjSA=; b=ZJ3N38vKPkzQ1slXNRFYJ4pSm8pbOgOvKSwqT7CQUMJ+RDA7Hrh4HCIfCI9nFDjoCK TLUaA+k5AzHd/Dk7UOenifr6tppQBCxlpZmCWCOhvU8t861lyLASZIA1Sosqg49Ah0y1 0jCRoZdYU2iV/a14HJmr2lBvumOcqRChSiVJf6iI8A3URph7WE5PE1htpI/ZpfPPiCZ9 ZhT7PhcF5Vr58RAgM2FDvjaMXNH8LcKkv5zGH9kFstGEer4unBm7QjaKUVMW9glYFLQm t8rReFCwlvJG22Lu69foSwXgK2CRjlmEckZ09klno9svp8wTJxR1xtG0cxTqtHYm2j2M mPSg== X-Gm-Message-State: ALoCoQk2A7WU7TDcxo538OrBQk2/i9BumS6Ho7DFOz9WrsNQQuLDfQIeIHtAVOHHapvKzC+aru6s X-Received: by 10.224.123.211 with SMTP id q19mr611860qar.78.1385872755734; Sat, 30 Nov 2013 20:39:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.86.42 with HTTP; Sat, 30 Nov 2013 20:38:45 -0800 (PST) In-Reply-To: References: <20131130135616.GA59496@kib.kiev.ua> From: Eitan Adler Date: Sat, 30 Nov 2013 23:38:45 -0500 Message-ID: Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Adrian Chadd , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:39:17 -0000 On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote: > On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote: > [..] >> Are you able to have clang/llvm/gcc tell us where/when code is relying >> on undefined behaviour? So we can, like, fix them? > > It wasn't all that long ago that we had this wonderful thing called > -Werror and had a clean kernel build. > > The problem is that gcc and clang have different warning sets. I seem > to recall we had -Werror on for gcc and off for clang. IMHO it would > be more useful to do it the other way around. Not all cases can be caught by static analysis. They would all be caught be the integer sanitizer. However, these have not yet been ported to FreeBSD. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 04:54:11 2013 Return-Path: Delivered-To: current@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 86A5C89F for ; Sun, 1 Dec 2013 04:54:11 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 377DC1FA3 for ; Sun, 1 Dec 2013 04:54:11 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id lc6so7723030vcb.27 for ; Sat, 30 Nov 2013 20:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HfwaIs+SxgBIphMXfMN+kbZWvtFK83tovuEdj4f0Kz8=; b=RUoT7E/fvW/1ZMiKt6fQ/8bdOsKY8SxrMXEFtpQScrrKFFUnlKhB53ea7kKmjWzPEu fuwRLYWoijej/tRltnFHWsoWX6G1qtvf0EoiU9CDKgbnbXBaSS1IsPGA4NRKKJIGy6Cd CgM8Mz6su1oJ7JDC1iILYCb7ZKgbh+S36BS00= 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:date :message-id:subject:from:to:cc:content-type; bh=HfwaIs+SxgBIphMXfMN+kbZWvtFK83tovuEdj4f0Kz8=; b=b/7W3ekn/WqUPAr6DDAZgd+OrjvnADw9uyF51Qir92LPIGYa8lvzMRCERDSgFt+VwB +tkwnalrNNfNEsVtt2BMFbJ4ykiznd5EU1+RvyFOQmqGlzeW1rPBL06ZsexDYN4Slryf eB3w/J3l/qetURROv18XfrTXIxTeSmQhlOJ9SZF08p4fpq5yZ6ivkc3o10hiyLPz+Gt7 yjrVg5HBZJW9T0TIQODI4678Ez+3E8FR2k8q2waHI/wkwH3R1LX06vD08ou+LrLAB6p0 y5B+LkZBw9Tytw1QfxVBG50+bXB5hcQqENpLBNJJb42089a+49azUgWbGcK5iQzuQcR4 CIug== X-Gm-Message-State: ALoCoQk/S0oci7ym3r7S7EmkS5NsowvpBKosHicSnryIwnuOBf2Oe6YBx3jKReGCtPHPGQMraJVG MIME-Version: 1.0 X-Received: by 10.220.169.203 with SMTP id a11mr3003422vcz.26.1385873650192; Sat, 30 Nov 2013 20:54:10 -0800 (PST) Received: by 10.220.167.74 with HTTP; Sat, 30 Nov 2013 20:54:10 -0800 (PST) In-Reply-To: References: <20131130135616.GA59496@kib.kiev.ua> Date: Sat, 30 Nov 2013 20:54:10 -0800 Message-ID: Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Peter Wemm To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , Adrian Chadd , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 04:54:11 -0000 On Sat, Nov 30, 2013 at 8:38 PM, Eitan Adler wrote: > On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote: >> On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote: >> [..] >>> Are you able to have clang/llvm/gcc tell us where/when code is relying >>> on undefined behaviour? So we can, like, fix them? >> >> It wasn't all that long ago that we had this wonderful thing called >> -Werror and had a clean kernel build. >> >> The problem is that gcc and clang have different warning sets. I seem >> to recall we had -Werror on for gcc and off for clang. IMHO it would >> be more useful to do it the other way around. > > Not all cases can be caught by static analysis. They would all be > caught be the integer sanitizer. However, these have not yet been > ported to FreeBSD. > I also missed the -Wno-error-tautological-compare setting. Oops. I personally tweak my builds a little so that: CC ../../../kern/kern_acct.c CC ../../../kern/kern_clock.c WARNING: kern_clock.c: enum pmc_event has too many values: 1669 > 1023 CC ../../../kern/kern_condvar.c CC ../../../kern/kern_conf.c CC ../../../kern/kern_cons.c CC ../../../kern/kern_cpu.c CC ../../../kern/kern_cpuset.c ../../../kern/kern_cpuset.c:637:16: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] for (i = 0; i < (_NCPUWORDS - 1); i++) { ~ ^ ~~~~~~~~~~~~~~~~ 1 warning generated. CC ../../../kern/kern_context.c CC ../../../kern/kern_descrip.c CC ../../../kern/kern_dtrace.c Warnings stand out nicely that way. The diff is along these lines: --- kern.pre.mk (revision 258784) +++ kern.pre.mk (working copy) @@ -126,12 +126,12 @@ # Optional linting. This can be overridden in /etc/make.conf. LINTFLAGS= ${LINTOBJKERNFLAGS} -NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC} -NORMAL_S= ${CC} -c ${ASM_CFLAGS} ${WERROR} ${.IMPSRC} +NORMAL_C= @echo " CC ${.IMPSRC}" ; ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC} +NORMAL_S= @echo " AS ${.IMPSRC}" ; ${CC} -c ${ASM_CFLAGS} ${WERROR} ${.IMPSRC} PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC} -NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC} +NORMAL_C_NOWERROR= @echo " CC_NOWERROR ${.IMPSRC}" ; ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC} ... Unfortunately that interferes with my usual use of 'make -s' - silent. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 07:59:25 2013 Return-Path: Delivered-To: current@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 925C6936; Sun, 1 Dec 2013 07:59:25 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2516E1691; Sun, 1 Dec 2013 07:59:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rB17xEV0052713; Sun, 1 Dec 2013 09:59:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rB17xEV0052713 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rB17xEuY052712; Sun, 1 Dec 2013 09:59:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Dec 2013 09:59:14 +0200 From: Konstantin Belousov To: Adrian Chadd Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds Message-ID: <20131201075914.GE59496@kib.kiev.ua> References: <20131130135616.GA59496@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6oogbsWdjksf+fv4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 07:59:25 -0000 --6oogbsWdjksf+fv4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 30, 2013 at 04:33:17PM -0800, Adrian Chadd wrote: > On 30 November 2013 15:25, Dimitry Andric wrote: > > On 30 Nov 2013, at 14:56, Konstantin Belousov wro= te: > >> I propose to unconditionally add the switch -fno-strict-overflow to t= he > >> kernel compilation. See the patch at the end of message for exact cha= nge > >> proposed. > >> > >> What does it do. It disallows useless and counter-intuitive behaviour = of > >> the compiler(s) for the signed overflow. Basically, the issue is that > >> the C standard left signed overflow as undefined to allow for different > >> hardware implementation of signess to be used for signed arithmetic. > >> De-facto, all architectures where FreeBSD works or have a chance to be > >> ported, use two-complement signed integer representation, and develope= rs > >> intuition is right about it. > > > > I think this is quite a misrepresentation. Any C compiler is free to do > > whatever it wants whenever it encounters undefined behavior. Some > > behavior is undefined in the C standards, so compilers can do a better > > job at optimization. Sure. And we are free to call such compiler useless and moronic. E.g. the standard explicitely marks any code implementing malloc-like allocator and VM 'forbidden', since it cannot be done without calling undefined behaviour. Should we stop writing the kernel or libc ? > > > > If the optimized code fails to do what the programmer thinks it does, it > > is almost always the programmer's fault, excluding actual compiler bugs > > (which are unavoidable, as all software has bugs). > > > > Basically, if you rely on undefined behavior, you are inventing your own > > de facto language, which is *not* C. That is fine with me, but let's > > not pretend the FreeBSD kernel is written in C then. :-) It is written in C, but no useful program can be written in the pure standard C. We must rely on the assumptions about underlying architecture, and compiler must provide sane access to the features of the underlying architecture to be useful. Just to list a few, - ILP32 or LP64; - ABI; - flat address space with arbitrary arithmetic on the data pointers; - code as data, in the same address space (yes, we patch code at runtime); - non-regular memory, both with additional side-effects when accessed, like register mappings (this cannot be modelled with volatile, think about e.g. address space switch caused by register access); and side-effect free memory with non-WC semantic. This can be continued infinitely. Why _sane_ implementation of signed arithmetic for 2-complement machine, which is just one item in the list above, is tolerated to be crippled ? Esp. since it causes (god forbids) *security* problems systematically ? >=20 > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? No, it is impossible. This is similar to the -fno-strict-aliasing. Compiler is sometimes able to note that it cheat on you by applying the undefined behaviour card, but this is not coded in the compiler systematically. And, the biggest problem, routine changes in the optimizer cause different places to become the victim. So the fact that your code is not flagged today does not assure that it would be not crippled tomorrow. >=20 > If there was a way to lint this stuff then yes, please lint it. >=20 > Otherwise we don't have the tools to know whether we're doing sane > things or not. >=20 > (Same with things like strict aliasing..) We do not have the tools, and indeed, same as with strict aliasing. --6oogbsWdjksf+fv4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSmuxRAAoJEJDCuSvBvK1Bnx0QAIZ1uGG+mzFaCRvt96LNsxHK MbpkO88U0A2/ADD4dNJV7uiuUUC7JPpgyqQ+l3pB6Q5jCOZiBA4q/Sr4o6ks/em2 ldfXhYzSiTq5/UOoXkl0qglMovCD8REtFohOAXkTLaHiICm9oezCzpfnLai83dqi utUhJRg4iphJe7ViUIirzMd9eb/RigwKZCIgMWv32ONiJPvFxYfJuupLScapM5RT o6SQmFWXuF+SG1RnzmzckNpzNootR07txhHNnmr5gT/s2+0m2xWhjMOgge8zU7mr qqpY8qb2jMisffgKKGngoHOFpyvIKctn9FtpY0DF4Xol1uo5SUqJCszILVtfNFSZ EM90h099/ZUyAdqEvk2y678FSEk7exjJjkIjL/fo07orJ7qCHq+2jkEe8mCRfYM8 /wiL4xRWHduXOwOFH7IFNzVLG0TnCxSFE8L/34oKxVZuOx6bDhV12rpoZtG3Pa9O j2Cm1nIZ1bX4Tx6OIaZWFfOmqFnuZIg13kaqkmcrmveXAzLr/C2lTQZa86XuI271 C+n/Y+S4xNifhi4ARl5GAkHIkHh58e+Odb/T1KLaAa2pHlAZKoH9+oGexoquo22x cd46QPpzwaubtVIKEdH8P/gjK147+aP+Y+VsOe31MWtmkYYIhniBqNOdrdsiPFHi dgB4KgtKM3ChQX6jC6Sh =fyGV -----END PGP SIGNATURE----- --6oogbsWdjksf+fv4-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 10:55:15 2013 Return-Path: Delivered-To: freebsd-current@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 166E529B; Sun, 1 Dec 2013 10:55:15 +0000 (UTC) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 732A21E0E; Sun, 1 Dec 2013 10:55:14 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id mz12so4933459bkb.30 for ; Sun, 01 Dec 2013 02:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PRr8lC3CaqJBiaDO9zu++rjM6jcUTjaqO7r1lDNxD5E=; b=GEq47MbAYZC6nNyCwk3Ku61aTbfFHy8FBVw7dnYY9sN5zDzQAjHnNHbgNfv5q8uABe Ibxk7OtcS+6jICfFpphQ3e49iNbr37OQVI/uwvnzBq+eq8T69fFd0i89kzwJ5JWi055V wz5/elIqd7OGvBjBI0yqMLFEgod0TF0PKPBLpr786iXYuJFm9UP1urC0RoycR88US/pw ocClBuQ9Cd7KL070oJA+sh5Jt+tApDo6UVfDzkI20zVoFrtb5QtglpPi/8FnbgWYQWbT 3iabl57oF+LoK4z1QGx93wlGGsPuBDbuo8S24VdI7+92g+DEEnxp5Q0K7SWJ2ynhPUiT EZGg== MIME-Version: 1.0 X-Received: by 10.204.227.198 with SMTP id jb6mr130118bkb.69.1385895312690; Sun, 01 Dec 2013 02:55:12 -0800 (PST) Received: by 10.204.163.129 with HTTP; Sun, 1 Dec 2013 02:55:12 -0800 (PST) In-Reply-To: <529AA73A.9@gmx.com> References: <20131201022002.GE55638@funkthat.com> <529AA73A.9@gmx.com> Date: Sun, 1 Dec 2013 11:55:12 +0100 Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Daniel Nebdal To: dt71@gmx.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: jb , Adrian Chadd , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 10:55:15 -0000 On Sun, Dec 1, 2013 at 4:04 AM, wrote: > John-Mark Gurney wrote, On 12/01/2013 03:20: > > Either it happens rarely, and always doing a realloc won't hurt >> performance, or it happens often, and then you should be using a larger >> buffer in the first place.. >> > > What if a size-elastic implementation of a dynamic data structure would be > able to adjust to the malloc implementation, such as agreeing to allocate > regions of size (2^k - 8)? Much like the use of getpagesize() (yes, I know > it's not part of a technical standard). > > That could alternatively be solved by having an "if I ask for N bytes right now, how large would the block be" - API that doesn't promise too much. Call it something like "malloc_suggest_size(size_t minsize) ", and make the description something like ... "return the largest number of bytes that would not allocate a larger block of memory than the provided minsize, in the current memory situation", plus some veiled threats about not using this value to do anything fancy with pointers to already-allocated memory. -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 11:31:05 2013 Return-Path: Delivered-To: freebsd-current@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 47EC4733 for ; Sun, 1 Dec 2013 11:31:05 +0000 (UTC) Received: from nm11-vm2.access.bullet.mail.bf1.yahoo.com (nm11-vm2.access.bullet.mail.bf1.yahoo.com [216.109.114.225]) by mx1.freebsd.org (Postfix) with SMTP id D9DB01FB7 for ; Sun, 1 Dec 2013 11:31:04 +0000 (UTC) Received: from [66.196.81.162] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2013 11:25:12 -0000 Received: from [98.139.221.158] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Dec 2013 11:25:12 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.bf1.yahoo.com with NNFMP; 01 Dec 2013 11:25:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1385897112; bh=1AfC492U/YqPxUVPt+f7/w9PkrNQgewx/+5RCxlh5NE=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=g/NVpZkerbqHhNi5lxt+EvgLXYd0eRwCh65oXUzRphu8qa2JMB9q7e5MmFxEXGrREkRpe/hzhvB2dyfyyGBupESoLPkNGkpDYDg1UAjia6yvX7cO6Lmas6eNXf7NEdRI3Ac+sSnimkcFlUMGHgZTyo7BTTB7myJOZrWgdUnvBLU= X-Yahoo-Newman-Id: 580296.67686.bm@smtp118.sbc.mail.bf1.yahoo.com Message-ID: <580296.67686.bm@smtp118.sbc.mail.bf1.yahoo.com> Date: Sun, 1 Dec 2013 11:25:12 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yNsPnaYVM1kEJOBhmbtgQ21knLFBTEmSD38F4nf5dg86JU. FqhfGXsYXxXZYlU0g87HnpvbpcpNMU.y_uSEZxUQbDqUQYMIQxPmzuEogmRa 6VGjvzH_dYjfECbOVirInfU8S8WIxWi42Mbqf_0kBUeiIMTrg0C3O4a.reGL ZgPuJZGzkJ2xPzXkJaHqh.z8tkjixkdgb4fc_k_K.zJzVmIMEmbfV70DvRky bnArDLVNTA4um58qx6N2bA92KI.2iCBmcFt.U41ON.UPE1vFd8..fE.5vVfY R11Rf9n47fI5hLAAx_6GroObngE_ce._ZFri0AuPgXFfzlxjaJ0Zr5gprpmT ED3O_MsovV20cCuFefGW8o1OLlY8ZRLurvOVQmFmp.85LJ9D0VPfyz6dxtGr MC7RQgdRwCw6gpyFkgxDb.kGumVACA9OzKHKppROCOwD_Xsx3FaR9D3muy__ llPm8Y8UMxFOpRrRhyZ89HOwe4_JfBKl8lZQewUknMkijrNywWv02xdbGwUM kZoJ7GSbXW.B2sD5j3GmXXDtiHUIn3FeohXPTExtud_i4jGbSBJoB_.fDWpn m2bPPvWGiLOMTxfdc__0- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@96.28.178.143 with ) by smtp118.sbc.mail.bf1.yahoo.com with SMTP; 01 Dec 2013 11:25:12 +0000 UTC From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: request for help: MFC net80211 fixes from -HEAD to -10 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 11:31:05 -0000 from Adrian Chadd: > hi all, > I'd like a developer or two to organise the MFC of anything that's in > net80211 on -HEAD back to -10 before 10.0-REL. > There's a few critical fixes that need to go in but I just don't have > the time to do it myself. :( > Thanks! There are a couple things I could work on, if I knew where to start, one wireless (for AR9271) and wired (re or if_re on some newer motherboards including MSI Z77 MPOWER). Same FreeBSD re bug with this motherboard occurs in DragonFlyBSD 3.6.0, I downloaded images and wrote to USB sticks. I don't really want to work with DragonFlyBSD, since it can't access anything on my hard drive. Tom From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 11:59:59 2013 Return-Path: Delivered-To: current@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 992C8D58 for ; Sun, 1 Dec 2013 11:59:59 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72984109E for ; Sun, 1 Dec 2013 11:59:59 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p10so16185632pdj.40 for ; Sun, 01 Dec 2013 03:59:59 -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:content-type; bh=UPZrITg59iTk7udjLtFbSiYQgfFfhF+tNqAnBRgrjNs=; b=fcSUnDU1iFMEPQCoukYUDsZAzzI29Okh6jc4gYlR6/eZowYhvkJU54O3i+f3eczfrb 0KkTC2KxRsRadV3Cc1+SrmHj2mg23UqPY0EXNXKirCNrB42fz0Xut7peXIiono2rgcVe cl5McYUCE9Rj4tAq47owuvjNo3/Y9anxV5ch8Sfdm3jecPODec51Hiuyqk/oQN8bw+Oo bqynv52T28XZ2+7dvcItSVF0Lz01gHJYtyoDyKudw2SoAbV26PAFMWsjirIlWzwzLkdM /597N8W4O9grnyGVEnPmEti/BgTnzsE/qvv97YT+9GTUudphHNhthjktWzpe5LsA6Mk4 YNxg== X-Received: by 10.68.196.3 with SMTP id ii3mr913017pbc.160.1385899199044; Sun, 01 Dec 2013 03:59:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.241.69 with HTTP; Sun, 1 Dec 2013 03:59:37 -0800 (PST) From: Eir Nym Date: Sun, 1 Dec 2013 15:59:37 +0400 Message-ID: Subject: ZFS: unknown file system on boot To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 11:59:59 -0000 I use zfs on root setup with system r258777. I've tried my kernel and generic one. I found new feature from r257650 that now loader.4th will load modules after menu gone (kernel selection). Now I have problem that modules won't loaded even I selected default kernel. for example, I have following contents of /boot/loader.conf, but none of modules will be loaded: zfs_load="YES" if_re_load="YES" Later on boot I got that system can't find filesystem zfs! If I break loader menu and manually load modules one by one, anything will be OK. How to boot my system correctly? -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 12:34:46 2013 Return-Path: Delivered-To: freebsd-current@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 4D23463C; Sun, 1 Dec 2013 12:34:46 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 031321231; Sun, 1 Dec 2013 12:34:46 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 44A0FB80CF; Sun, 1 Dec 2013 13:34:43 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 31371CB4E; Sun, 1 Dec 2013 13:34:43 +0100 (CET) Date: Sun, 1 Dec 2013 13:34:43 +0100 From: Jilles Tjoelker To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Message-ID: <20131201123442.GA6818@stack.nl> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> <529A6862.7060308@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529A6862.7060308@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 12:34:46 -0000 On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote: > This took much longer than I'd anticipated, but the patch to init is > attached. I chose not to make the changes to init rather than > getttyent() and friends in libc, which I am open to revisiting. lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and will not allow root login on a "fake" TTY that getttynam() does not know. This module is enabled by default for the "login" service. So it is probably better to patch libc rather than init. > The behavior changes are as follows: > If the "console" device in /etc/ttys in marked "on", instead of opening > /dev/console, init will loop through the active kernel console devices, > and for each will: > 1. If the kernel console device is in /etc/ttys and marked "on", it > already has a terminal and will be ignored. > 2. If marked "off", that is an explicit statement that a console is not > wanted and so it will be ignored. > 3. If not present in /etc/ttys, init will run getty with whatever > parameters "console" has. This seems to make sense. > (3) is the main behavioral change. No changes in behavior will occur if > /etc/ttys is not modified. If we turn on "console" by default, it will > usually have no effect instead of trying to run multiple gettys, which > is new. If we then also comment out the ttyu0 line, instead of marking > it "off", the result will be the conditional presence of a login prompt > on the first serial port depending on whether it is an active console > device for the kernel. I believe this is the behavior we are going for. The terminal type for the console entry should probably be changed to something other than "unknown" to reduce annoyance. > Comments and test results would be appreciated. As a preparatory patch, you could remove se_index and session_index from init. They are only used to warn about a changed slot number in utmp(5) which is irrelevant with utmpx. This noise warning would also appear in most cases when changing from a "fake" console entry to a real line in /etc/ttys. Also, if you do decide to fake ttys entries in init rather than libc, the patch to init will be simpler. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 13:23:03 2013 Return-Path: Delivered-To: current@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 408C9FC2 for ; Sun, 1 Dec 2013 13:23:03 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 64F7814C7 for ; Sun, 1 Dec 2013 13:23:02 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MJjvw-1VoDRo1sXs-001CNL for ; Sun, 01 Dec 2013 14:23:00 +0100 Message-ID: <529B3813.8080906@gmx.com> Date: Sun, 01 Dec 2013 14:22:27 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Konstantin Belousov , Adrian Chadd Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds References: <20131130135616.GA59496@kib.kiev.ua> <20131201075914.GE59496@kib.kiev.ua> In-Reply-To: <20131201075914.GE59496@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aXbOGQPAb9CvlCyckKRt+wXnujkz1DsHBFK1ArjPRiyCeuquloz LVd1eWtBPj1zyle5+9qfBfKSfpe0ToQAH0XXyb3e46yi/BH7Txc9vfBwiVq1cMdfocl6gku 3z7mmE9G7mt4Q8vDcRSEoa2JncTFDQOINZLD6uLsq4W8xLXcwF88eY4ehvbtGxzTxht1hih sBk8NavJPOZUC+b89iH5g== Cc: Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 13:23:03 -0000 Konstantin Belousov wrote, On 11/30/2013 13:56: > The compiler authors take the undefined part there as a blanket to perform > optimizations which are assuming that signed overflow cannot happen. Personally, when I first heard about such assumptions, it was inspiring to write code in a way that automatically gives the compiler certain ``overflow cannot happer'' (for example, because the input values given are always small) hints, such as turning some uses of ``unsigned int'' (where a negative value logically doesn't make sense, such as in a size/length value) into ``signed int''. However, I quickly found that this way of thinking leads to counter-production: coding becomes slower, the resulting code becomes less readable, while the performance gain remains questionable. It would be much better if hints could be given to the compiler using assert() (which would have effect even in non-debug mode). How do others feel? Konstantin Belousov wrote, On 12/01/2013 08:59: > It is written in C, but no useful program can be written in the pure > standard C. We must rely on the assumptions about underlying architecture, > and compiler must provide sane access to the features of the underlying > architecture to be useful. But what behavior do you want for signed arithmetic? Modular, saturating, or some other? And how do you signal that? Or maybe you just want to check for (signed/unsigned) integer overflow (which can't be done "cleanly and efficiently" in C), in which case someone should write a check_add_overflow() function... From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 14:07:53 2013 Return-Path: Delivered-To: freebsd-current@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 B54D6801; Sun, 1 Dec 2013 14:07:53 +0000 (UTC) Received: from mailrelay003.isp.belgacom.be (mailrelay003.isp.belgacom.be [195.238.6.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1BA1699; Sun, 1 Dec 2013 14:07:52 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGAPxBm1JR8Y7x/2dsb2JhbABZgwc4R7gUToEZF3SCJQEBBVYjEAsYCSUPKh4GARIJh3wBCL5JF48IB4QzA5Axh2KBMYsthTaDKjs Received: from 241.142-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.142.241]) by relay.skynet.be with ESMTP; 01 Dec 2013 15:06:42 +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 rB1E6eOg033018; Sun, 1 Dec 2013 15:06:41 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Sun, 1 Dec 2013 15:06:40 +0100 From: Tijl Coosemans To: stephen@FreeBSD.org, Maho Nakata , bapt@FreeBSD.org Subject: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> In-Reply-To: <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/sp.+OQgp.pRayk2rEtSgoni" Cc: Jan Henrik Sylvester , FreeBSD Current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 14:07:53 -0000 --MP_/sp.+OQgp.pRayk2rEtSgoni Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: > On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: >> Trying to migrate to 10, I would like to keep octave. Have you found >> anything new? Having build the port and all dependencies with standard >> options, octave is segfaulting for me, too. Anyhow, I can run octave with: >> >> env LD_PRELOAD=/usr/lib/libc++.so.1 octave >> >> Some very light testing indicates that it is working. Of course, this is >> not ideal. >> >> Maybe this gives a clue how to fix the octave port properly. > > I have a preliminary patch for math/octave that I wanted to test on > redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. --MP_/sp.+OQgp.pRayk2rEtSgoni Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=octave-fortran.patch Index: math/octave/Makefile =================================================================== --- math/octave/Makefile (revision 335379) +++ math/octave/Makefile (working copy) @@ -3,7 +3,7 @@ PORTNAME= octave PORTVERSION= 3.6.4 -PORTREVISION= 6 +PORTREVISION= 7 CATEGORIES= math MASTER_SITES= ftp://ftp.gnu.org/gnu/octave/ \ ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/ @@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/ umfpack.1:${PORTSDIR}/math/suitesparse \ glpk:${PORTSDIR}/math/glpk -USES= charsetfix gmake perl5 pkgconfig +USES= charsetfix fortran gmake perl5 pkgconfig USE_BZIP2= yes USE_PERL5= build USE_TEX= dvipsk:build @@ -74,8 +74,6 @@ BLAS= -lptf77blas LAPACK= -lalapack -lptcblas .endif -USE_FORTRAN= yes - OCTAVE_VERSION= ${PORTVERSION} GNU_HOST= ${ARCH}-portbld-freebsd${OSREL} PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST} @@ -140,7 +138,8 @@ post-install: ${ECHO_CMD} @dirrm share/octave >> ${WRKDIR}/PLIST cd ${WRKDIR} ; ${SED} -i -e "/PLIST/ r PLIST" ${TMPPLIST} -check: +check: regression-test +regression-test: build (cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check) .include Index: math/octave/files/patch-configure =================================================================== --- math/octave/files/patch-configure (revision 0) +++ math/octave/files/patch-configure (working copy) @@ -0,0 +1,11 @@ +--- configure.orig 2013-02-21 21:21:49.000000000 +0100 ++++ configure 2013-11-22 20:34:49.000000000 +0100 +@@ -58248,7 +58248,7 @@ + main () + { + +- std::unordered_map m; ++ std::unordered_map m; + + ; + return 0; Property changes on: math/octave/files/patch-configure ___________________________________________________________________ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: math/octave/files/patch-libgnu-math.in.h =================================================================== --- math/octave/files/patch-libgnu-math.in.h (revision 0) +++ math/octave/files/patch-libgnu-math.in.h (working copy) @@ -0,0 +1,11 @@ +--- libgnu/math.in.h.orig 2013-02-21 21:21:17.000000000 +0100 ++++ libgnu/math.in.h 2013-11-22 12:35:47.000000000 +0100 +@@ -17,7 +17,7 @@ + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +-#ifndef _@GUARD_PREFIX@_MATH_H ++#if 1 + + #if __GNUC__ >= 3 + @PRAGMA_SYSTEM_HEADER@ Property changes on: math/octave/files/patch-libgnu-math.in.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: math/octave/files/patch-liboctave-eigs-base.cc =================================================================== --- math/octave/files/patch-liboctave-eigs-base.cc (revision 0) +++ math/octave/files/patch-liboctave-eigs-base.cc (working copy) @@ -0,0 +1,11 @@ +--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.000000000 +0100 ++++ liboctave/eigs-base.cc 2013-11-22 20:19:19.000000000 +0100 +@@ -3832,7 +3832,7 @@ + bool cholB = 0, int disp = 0, int maxit = 300); + #endif + +-#ifndef _MSC_VER ++#if !defined(_MSC_VER) && !defined(__clang__) + template static octave_idx_type + lusolve (const SparseMatrix&, const SparseMatrix&, Matrix&); + Property changes on: math/octave/files/patch-liboctave-eigs-base.cc ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: Mk/Uses/fortran.mk =================================================================== --- Mk/Uses/fortran.mk (revision 0) +++ Mk/Uses/fortran.mk (working copy) @@ -0,0 +1,32 @@ +# $FreeBSD$ +# +# Establish Fortran-capable compiler as a build dependency +# +# MAINTAINER: ports@FreeBSD.org +# +# Feature: fortran +# Usage: USES=fortran +# Valid ARGS: does not require args + +.if !defined(_INCLUDE_USES_FORTRAN_MK) +_INCLUDE_USES_FORTRAN_MK= yes + +.if defined(fortran_ARGS) +IGNORE= USES=fortran does not require args +.endif + +.if !defined(FC) +BUILD_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc +RUN_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc + +USE_BINUTILS= yes + +FC= gfortran46 +FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 +LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 +.endif + +CONFIGURE_ENV+= F77="${FC}" FC="${FC}" FFLAGS="${FFLAGS}" +MAKE_ENV+= F77="${FC}" FC="${FC}" FFLAGS="${FFLAGS}" + +.endif Property changes on: Mk/Uses/fortran.mk ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property --MP_/sp.+OQgp.pRayk2rEtSgoni-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 14:11:01 2013 Return-Path: Delivered-To: current@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 567A3952; Sun, 1 Dec 2013 14:11:01 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [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 12DC016E9; Sun, 1 Dec 2013 14:11:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d491:85a3:d731:bb13] (unknown [IPv6:2001:7b8:3a7:0:d491:85a3:d731:bb13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1EFD15C43; Sun, 1 Dec 2013 15:10:56 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds From: Dimitry Andric In-Reply-To: Date: Sun, 1 Dec 2013 15:10:45 +0100 Message-Id: References: <20131130135616.GA59496@kib.kiev.ua> To: Adrian Chadd X-Mailer: Apple Mail (2.1822) Cc: Konstantin Belousov , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 14:11:01 -0000 --Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On 01 Dec 2013, at 01:33, Adrian Chadd wrote: > On 30 November 2013 15:25, Dimitry Andric wrote: ... >> Basically, if you rely on undefined behavior, you are inventing your own >> de facto language, which is *not* C. That is fine with me, but let's >> not pretend the FreeBSD kernel is written in C then. :-) > > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? Not in the most general sense, since that would amount to solving the halting problem. But there are some tools that can help quite a lot. I guess Coverity can already cover quite a lot of cases, and there is also the STACK tool from MIT: http://css.csail.mit.edu/stack/ It would be really nice to have this in ports. Another mechanism is run-time detection, e.g. the undefined behavior sanitizer and other sanitizers: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation some of which have also been ported to gcc, see: http://gcc.gnu.org/gcc-4.9/changes.html However, these have not been completely ported to FreeBSD yet, and come at a (sometimes large) run-time cost. Still a lot less than valgrind, though. :-) Also, for use in the kernel, the run-time support would have to be ported separately to the kernel environment. > If there was a way to lint this stuff then yes, please lint it. > > Otherwise we don't have the tools to know whether we're doing sane > things or not. > > (Same with things like strict aliasing..) Yes, the comparison with strict aliasing is spot-on. A lot of code has been written that is not aliasing safe, and if it is too much effort to fix it, using -fno-strict-aliasing is a reasonable workaround. Note this option can prevent a lot of very useful optimizations, but if you do not particularly care (for example if you are waiting for slow hardware anyway), it is fine to use it. -Dimitry --Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676 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) iEYEARECAAYFAlKbQ2kACgkQsF6jCi4glqOmawCaAhMUbWSkuCS5aEowsaXbsk1D vigAn1PjUXbAXJUl5ay3I05V9PmPbCL6 =rKnu -----END PGP SIGNATURE----- --Apple-Mail=_159D4490-6D58-409D-9F58-776BB4665676-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 16:12:26 2013 Return-Path: Delivered-To: freebsd-current@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 352A5BAB for ; Sun, 1 Dec 2013 16:12: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 DE9D21BCD for ; Sun, 1 Dec 2013 16:12:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vn9d0-0000kd-L9 for freebsd-current@freebsd.org; Sun, 01 Dec 2013 17:12:16 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Dec 2013 17:12:14 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Dec 2013 17:12:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Sun, 1 Dec 2013 16:11:52 +0000 (UTC) Lines: 19 Message-ID: References: <20131201022002.GE55638@funkthat.com> <529AA73A.9@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 16:12:26 -0000 Daniel Nebdal gmail.com> writes: > ... > That could alternatively be solved by having an "if I ask for N bytes right > now, how large would the block be" - API that doesn't promise too much. > Call it something like "malloc_suggest_size(size_t minsize) ", and make the > description something like ... "return the largest number of bytes that > would not allocate a larger block of memory than the provided minsize, in > the current memory situation", plus some veiled threats about not using > this value to do anything fancy with pointers to already-allocated memory. Yeap. It is like asking teenagers to be abstinent ... http://www.youtube.com/watch?v=SWlbN2b1PGg Good luck ! jb From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 18:20:28 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31214DE8 for ; Sun, 1 Dec 2013 18:20:28 +0000 (UTC) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id D5BAD1361 for ; Sun, 1 Dec 2013 18:20:27 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=Ytc2GeoX c=1 sm=0 tr=0 a=+wdeDari83nKenieuZZ65g==:117 a=+wdeDari83nKenieuZZ65g==:17 a=K-v-2zaBAAAA:8 a=eXnlHukMzTYA:10 a=YNqtyO0l_hcA:10 a=LaogzpLLAAAA:8 a=Kbdel01a00EA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=6I5d2MoRAAAA:8 a=UG8V2m1LQNdJdwOIEZAA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=fWc9v4rTpDHQw8Xet1oA:9 a=8llgMzyAtAC2yOwD:21 a=_W_S_7VecoQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 173.70.29.3 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [173.70.29.3] ([173.70.29.3:15174] helo=[192.168.1.8]) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id 55/BE-19303-4ED7B925; Sun, 01 Dec 2013 13:20:20 -0500 Message-ID: <529B7DE4.5030906@aldan.algebra.com> Date: Sun, 01 Dec 2013 13:20:20 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Current FreeBSD Subject: patch -p broken on HEAD? References: <201311301824.rAUIOg9S075512@beefy1.isc.freebsd.org> In-Reply-To: <201311301824.rAUIOg9S075512@beefy1.isc.freebsd.org> X-Mailman-Approved-At: Sun, 01 Dec 2013 18:38:48 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: pkg-fallout@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 18:20:28 -0000 On 30.11.2013 13:24, pkg-fallout@FreeBSD.org wrote: > ===> Applying FreeBSD patches for xmdiary-3.0.3_3 > removing the malloc.h includes > /bin/sh /usr/ports/deskutils/xmdiary/scripts/nomalloc /wrkdirs/usr/ports/deskutils/xmdiary/work/xmdiary-3.0.3 2>&1 > /dev/zero > patch: option requires an argument -- p > usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d directory] > [-F max-fuzz] [-i patchfile] [-o out-file] [-p strip-count] > [-r rej-name] [-V t | nil | never] [-x number] [-z backup-ext] > [--posix] [origfile [patchfile]] > patch patch: option requires an argument -- p It looks like the -p option can no longer be given to patch(1) by itself. Is this deliberate? Thanks, -mi From owner-freebsd-current@FreeBSD.ORG Sun Dec 1 18:57:01 2013 Return-Path: Delivered-To: freebsd-current@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 A255BD1A; Sun, 1 Dec 2013 18:57:01 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [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 5CF8D1543; Sun, 1 Dec 2013 18:57:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d491:85a3:d731:bb13] (unknown [IPv6:2001:7b8:3a7:0:d491:85a3:d731:bb13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D2E3E5C43; Sun, 1 Dec 2013 19:56:56 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_0D17A4BD-1640-4508-8E4E-7390E5410401"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: patch -p broken on HEAD? From: Dimitry Andric In-Reply-To: <529B7DE4.5030906@aldan.algebra.com> Date: Sun, 1 Dec 2013 19:56:34 +0100 Message-Id: <2D565D54-82B9-47DD-B52F-7C657D9129FC@FreeBSD.org> References: <201311301824.rAUIOg9S075512@beefy1.isc.freebsd.org> <529B7DE4.5030906@aldan.algebra.com> To: "Mikhail T." X-Mailer: Apple Mail (2.1822) Cc: pkg-fallout@FreeBSD.org, Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 18:57:01 -0000 --Apple-Mail=_0D17A4BD-1640-4508-8E4E-7390E5410401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 01 Dec 2013, at 19:20, Mikhail T. wrote: > On 30.11.2013 13:24, pkg-fallout@FreeBSD.org wrote: >> =3D=3D=3D> Applying FreeBSD patches for xmdiary-3.0.3_3 >> removing the malloc.h includes >> /bin/sh /usr/ports/deskutils/xmdiary/scripts/nomalloc = /wrkdirs/usr/ports/deskutils/xmdiary/work/xmdiary-3.0.3 2>&1 > /dev/zero >> patch: option requires an argument -- p >> usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d = directory] >> [-F max-fuzz] [-i patchfile] [-o out-file] [-p = strip-count] >> [-r rej-name] [-V t | nil | never] [-x number] [-z = backup-ext] >> [--posix] [origfile [patchfile]] >> patch > patch: option requires an argument -- p > It looks like the -p option can no longer be given to patch(1) by > itself. Is this deliberate? Thanks, I think so, yes. It was removed 10 years ago from OpenBSD's patch: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/patch/patch.c#rev1.34 'Historically, patch would treat a bare -p as -p0. This contradicts POSIX and GNU patch has also removed this, so we will too. No objections on icb (no one even seemed to know about this "feature").' Just add -p0, and you should be fine. -Dimitry --Apple-Mail=_0D17A4BD-1640-4508-8E4E-7390E5410401 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) iEYEARECAAYFAlKbhmoACgkQsF6jCi4glqNmzQCfcUMBv9RSb7Zikm+BapoZ0pGl v58Amwf4NaGFTK7GkDuemcae6rwcwrrp =2vNg -----END PGP SIGNATURE----- --Apple-Mail=_0D17A4BD-1640-4508-8E4E-7390E5410401-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 01:25:31 2013 Return-Path: Delivered-To: freebsd-current@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 24671A02 for ; Mon, 2 Dec 2013 01:25:31 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCC0A13AB for ; Mon, 2 Dec 2013 01:25:30 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rB21PN06055866; Sun, 1 Dec 2013 17:25:27 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201312020125.rB21PN06055866@gw.catspoiler.org> Date: Sun, 1 Dec 2013 17:24:02 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 01:25:31 -0000 On 30 Nov, To: kostikbel@gmail.com wrote: > On 30 Nov, Konstantin Belousov wrote: >> On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote: >>> On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: >>> > Peter, could you, please, try to reproduce the issue ? It does not look >>> > like a random hardware failure, since in all cases, it is curthread access >>> > which is faulting. The issue is only reported by Don, and so far only >>> > for i386 SMP. >>> >>> I'm not seeing this issue on my AMD Phenom(tm) 9150e Quad-Core >>> Processor with i386/r258703. >> >> Thank you. >> >> 9150 is family 0x10, which my indeed point out to some errata >> for family 0xf. Lets wait for Don. > > It's really looking like a hardware problem at this point. I've seen no > problems so far in about 2 1/2 passes through portupgrade -fr > lang/perl5.16 on my other machine with the same motherboard model but a > slightly different CPU. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2200.05-MHz 686-class CPU > ) > Origin = "AuthenticAMD" Id = 0x40fb2 Family = 0xf Model = 0x4b Stepping > = 2 > Features=0x178bfbff ,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > > It's also a family 0xF CPU, but strangely different. It only seems to > have half as many on-die temperature sensors. > > dev.amdtemp.0.sensor_offset: 0 > dev.amdtemp.0.core0.sensor0: 35.0C > dev.amdtemp.0.core0.sensor1: -49.0C > dev.amdtemp.0.core1.sensor0: 34.0C > dev.amdtemp.0.core1.sensor1: -49.0C > > I've never noticed this before because this is the first time FreeBSD > has been run on this hardware. > > I may have to dig out the fine manual to see if amdtemp can be tweaked > to recognize this variation. The fine manual says this CPU is rev BH-F2, which should have two sensors per core, so it looks like this particular CPU might just be slightly broken. > After the current test run, which should finish late tonight, I'll go > back to the original machine and try the patch. If I still see > failures, then I'll start swapping parts to find the bad one. Back on the original machine, with your patch applied, it croaked with another double fault after about five hours of port building. Stack trace: Time to start swapping parts ... From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 01:24:16 2013 Return-Path: Delivered-To: freebsd-current@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 03F1D9FB for ; Mon, 2 Dec 2013 01:24:16 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB35313A8 for ; Mon, 2 Dec 2013 01:24:15 +0000 (UTC) Received: from catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rB21O2Bq055856; Sun, 1 Dec 2013 17:24:06 -0800 (PST) (envelope-from spamvictim@catspoiler.org) Message-Id: <201312020124.rB21O2Bq055856@gw.catspoiler.org> Date: Sun, 1 Dec 2013 17:24:02 -0800 (PST) From: Don Lewis Subject: Re: panic: double fault with 11.0-CURRENT r258504 To: kostikbel@gmail.com In-Reply-To: <201311301848.rAUImMg1053041@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 02 Dec 2013 02:14:27 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 01:24:16 -0000 On 30 Nov, To: kostikbel@gmail.com wrote: > On 30 Nov, Konstantin Belousov wrote: >> On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote: >>> On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote: >>> > Peter, could you, please, try to reproduce the issue ? It does not look >>> > like a random hardware failure, since in all cases, it is curthread access >>> > which is faulting. The issue is only reported by Don, and so far only >>> > for i386 SMP. >>> >>> I'm not seeing this issue on my AMD Phenom(tm) 9150e Quad-Core >>> Processor with i386/r258703. >> >> Thank you. >> >> 9150 is family 0x10, which my indeed point out to some errata >> for family 0xf. Lets wait for Don. > > It's really looking like a hardware problem at this point. I've seen no > problems so far in about 2 1/2 passes through portupgrade -fr > lang/perl5.16 on my other machine with the same motherboard model but a > slightly different CPU. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2200.05-MHz 686-class CPU > ) > Origin = "AuthenticAMD" Id = 0x40fb2 Family = 0xf Model = 0x4b Stepping > = 2 > Features=0x178bfbff ,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > > It's also a family 0xF CPU, but strangely different. It only seems to > have half as many on-die temperature sensors. > > dev.amdtemp.0.sensor_offset: 0 > dev.amdtemp.0.core0.sensor0: 35.0C > dev.amdtemp.0.core0.sensor1: -49.0C > dev.amdtemp.0.core1.sensor0: 34.0C > dev.amdtemp.0.core1.sensor1: -49.0C > > I've never noticed this before because this is the first time FreeBSD > has been run on this hardware. > > I may have to dig out the fine manual to see if amdtemp can be tweaked > to recognize this variation. The fine manual says this CPU is rev BH-F2, which should have two sensors per core, so it looks like this particular CPU might just be slightly broken. > After the current test run, which should finish late tonight, I'll go > back to the original machine and try the patch. If I still see > failures, then I'll start swapping parts to find the bad one. Back on the original machine, with your patch applied, it croaked with another double fault after about five hours of port building. Stack trace: Time to start swapping parts ... From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 04:17:30 2013 Return-Path: Delivered-To: freebsd-current@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 2BD69A23; Mon, 2 Dec 2013 04:17:30 +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 0E5EF6EDA; Mon, 2 Dec 2013 04:17:28 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ec20so8179546lab.29 for ; Sun, 01 Dec 2013 20:17:27 -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=TBydLbV1oTwW4mrWjkravv0PuL225Hkj4WyuqT2q1D0=; b=METhUSh9DV/HufXjpgp5NtqgQhsJ0crKGT71Rx4NktT0m70z4FO/lrOQHli+F58BJ/ hlFw+CljShATBYr88RCpBhD73IrbS+O1kgnvwyvKoQuxAYxD/U4XEJRTLYtCynMco1im WzusAUumTtiQHdiGsAcH+wzfFksOkxOYGNUYXio2b1H/8qnWdAJnJPDPeDCniZSqUBVp JqZ7k/LpOzhcQS/PNjGYqJHvut4uuZFDcy7Ye0iLncn40oFoepZfdYdGUUMg2Aigf10M fWNAw0iUlaieokLs29melEPlqA9CvfXynqNVfILjYWHPFbvIoAcRLfzFt44G8eDtv8p4 Oagw== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr42224808lbh.9.1385957846897; Sun, 01 Dec 2013 20:17:26 -0800 (PST) Received: by 10.114.166.163 with HTTP; Sun, 1 Dec 2013 20:17:26 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Mon, 2 Dec 2013 12:17:26 +0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Sepherosa Ziehau To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 04:17:30 -0000 On Sat, Nov 30, 2013 at 2:42 AM, Ermal Lu=E7i wrote: > Well seems Dragonfly has some version of it already from commit [1]. > > The distribution algorithm was changed a little bit after initial commit to gain more idle time (bnx(4) output has already been maxed out): http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c275f18d832361be28b= 150d3f4fd518914bdeba6 Well, I also addressed a reasonable concern from nginx folks (I am not quite sure about Linux's position on it; Linux original implementation of SO_REUSEPORT from Google had this drawback, which I mentioned in the commit message): http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/02ad2f0b874fb0a45eb= 69750219f79f5e8982272 As about nginx, SO_REUSEPORT patch for nginx (both 1.4.x and 1.5.x) is in dports; should be easier to be back ported to FreeBSD's ports. I failed to convince nginx folks to merge it into mainline and I am currently onto other stuffs, will come back to them later. If FreeBSD is going to implement Linux's style of SO_REUSEPORT, pushing the patch to the nginx mainline will be easier. I also put up a brief description of SO_REUSEPORT in dfly; may be useful to you: http://leaf.dragonflybsd.org/~sephe/netisr_so_reuseport.txt Best Regards, sephe > In FreeBSD there is the framework for this with by defining PCBGROUP. > Also the explanation of it at [2] and [3]. > It can achieve approximately the same features of SO_RESUSEPORT of linux. > The only thing missing is the marketing behind it and i think and better > RSS support. > By looking at dates the support is there before linux so all you guys > looking for it can experiment with it. > > What i was trying to accomplish was something else from performance > improvement and > maybe put a sysctl behind it to make it more acceptable.. > > [1] > > http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c9c= 021abb8197718d7a2d441c9 > [2] > http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts#L= 51 > [3] http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html > > > On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko >wrote: > > > Tim, you are wrong. Read what is "multicast" definition, and read how U= DP > > and TCP sockets work in Linux 3.9+ kernels. > > > > Oleg . > > > > > > On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle >wrote: > > > >> > >> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: > >> > >> > Hello, > >> > > >> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemon= s > to > >> > share the same port and possibly listening ip =85 > >> > >> These flags are used with TCP-based servers. > >> > >> I=92ve used them to make software upgrades go more smoothly. > >> Without them, the following often happens: > >> > >> * Old server stops. In the process, all of its TCP connections are > >> closed. > >> > >> * Connections to old server remain in the TCP connection table until t= he > >> remote end can acknowledge. > >> > >> * New server starts. > >> > >> * New server tries to open port but fails because that port is =93stil= l in > >> use=94 by connections in the TCP connection table. > >> > >> With these flags, the new server can open the port even though > >> it is =93still in use=94 by existing connections. > >> > >> > >> > This is not the case today. > >> > Only multicast sockets seem to have the behaviour of broadcasting th= e > >> data > >> > to all sockets sharing the same properties through these options! > >> > >> That is what multicast is for. > >> > >> If you want the same data sent to all listeners, then > >> that is multicast behavior and you should be using > >> a multicast socket. > >> > >> > The patch at [1] implements/corrects the behaviour for UDP sockets. > >> > >> You=92re trying to turn all UDP sockets with those options > >> into multicast sockets. > >> > >> If you want a multicast socket, you should ask for one. > >> > >> Tim > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > > > > > > -- > Ermal > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Tomorrow Will Never Die From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 05:02:53 2013 Return-Path: Delivered-To: freebsd-current@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 83F38D5; Mon, 2 Dec 2013 05:02:53 +0000 (UTC) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AA3310B2; Mon, 2 Dec 2013 05:02:52 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id 6so12836248qea.18 for ; Sun, 01 Dec 2013 21:02:52 -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=5OZpeEVxX+5txyZVFMFemU3TsA/C5ipw0qvzHw7mRw0=; b=duNlyUeNGj9wLEaO6kiuT7UiTZfWp6NYk39dDrNzlQJe8LN/AyQsxKWZTd2Chwx/LZ 0hM6LUGOZ3t2ShHzstqgOwQLuPCWYeUIYLrF6wE1H6qTq6PiaMzSjxpB0n6VpfufrVML P7M7EoXNUMk2KmtBuMBzvI/oUDYOQBGJwLBV3ti0KucA6n8k5vrUB7hZ6G3/IijLWN89 4jIisZdhfjacqpPwU5YBEcX60/18kNIyETFOr6jfI0r9tT/LMxcTNBDpbofzThpAkxA9 RZ0F5LQpjmRAiy4Tv23GV5VDUIY76SWcx0e4AhFvByMwpfrlOE1LCPTICGiJO8rjhHoL vAtA== MIME-Version: 1.0 X-Received: by 10.229.122.195 with SMTP id m3mr109680144qcr.7.1385960572142; Sun, 01 Dec 2013 21:02:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sun, 1 Dec 2013 21:02:52 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Sun, 1 Dec 2013 21:02:52 -0800 X-Google-Sender-Auth: 1Fcg6ebyMlcDG_508SdPJ3VO2Qc Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Adrian Chadd To: Sepherosa Ziehau Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 05:02:53 -0000 Hi! Thanks for the writeup! On 1 December 2013 20:17, Sepherosa Ziehau wrote: > I also put up a brief description of SO_REUSEPORT in dfly; may be useful to > you: > http://leaf.dragonflybsd.org/~sephe/netisr_so_reuseport.txt Ok, so given this, how do you guarantee the UTHREAD stays on the given CPU? You assume it stays on the CPU that the initial listen socket was created on, right? If it's migrated to another CPU core then the listen queue still stays in the original hash group that's in a netisr on a different CPU? -adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 07:10:19 2013 Return-Path: Delivered-To: freebsd-current@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 D5DC47E1; Mon, 2 Dec 2013 07:10:19 +0000 (UTC) Received: from CMEXEDGE2.ext.emulex.com (cmexedge2.ext.emulex.com [138.239.224.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B35D31707; Mon, 2 Dec 2013 07:10:19 +0000 (UTC) Received: from CMEXHTCAS2.ad.emulex.com (138.239.115.218) by CMEXEDGE2.ext.emulex.com (138.239.224.100) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 1 Dec 2013 23:10:21 -0800 Received: from CMEXMB1.ad.emulex.com ([169.254.1.137]) by CMEXHTCAS2.ad.emulex.com ([2002:8aef:73da::8aef:73da]) with mapi id 14.03.0146.002; Sun, 1 Dec 2013 23:10:11 -0800 From: Venkata Duvvuru To: John-Mark Gurney Subject: RE: sysctl add macros Thread-Topic: sysctl add macros Thread-Index: Ac7py2Eb3GYul2HXQGupi09t7TvnXQAZRFYAABCOHkAA+O5hAAA1n36w Date: Mon, 2 Dec 2013 07:10:11 +0000 Message-ID: References: <20131130213006.GC55638@funkthat.com> In-Reply-To: <20131130213006.GC55638@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [138.239.141.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Matthew Fleming , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 07:10:19 -0000 I could use an int variable but if I have to dump huge number of statistics= through sysctl in which case I need to add many such variables to the node= s and even if most of these variables are char I have to declare them as in= t, hence resulting in an increased footprint. /Venkat. -----Original Message----- From: John-Mark Gurney [mailto:jmg@funkthat.com]=20 Sent: Sunday, December 01, 2013 3:00 AM To: Venkata Duvvuru Cc: Matthew Fleming; freebsd-current@freebsd.org Subject: Re: sysctl add macros Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +0000: > The problem with using int or u_int for 1 or 2 byte values is that while = printing these 1 or 2 byte values I observed that sysctl module is consider= ing 4 bytes. Hence I see an undesired output. It is actually considering th= e next two bytes also as the value. If you _NEED_ to use a char or short, you need to write your own/clone it f= rom the macros... Why can't you use an int for this variable? > From: mdf356@gmail.com [mailto:mdf356@gmail.com] On Behalf Of Matthew=20 > Fleming > Sent: Monday, November 25, 2013 8:18 PM > To: Venkata Duvvuru > Cc: freebsd-current@freebsd.org > Subject: Re: sysctl add macros >=20 > On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru > wrote: > Hi, > I'm unable to figure out how to add an unsigned short or an unsigned char= values to a sysctl node. > SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a= short values I couldn't find any macros. >=20 > Could you please let me know how to add them? >=20 > FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBS= D code that wants to do this has used int or u_int instead of a smaller typ= e. --=20 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-current@FreeBSD.ORG Mon Dec 2 07:14:39 2013 Return-Path: Delivered-To: freebsd-current@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 1BEC692D; Mon, 2 Dec 2013 07:14:39 +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 E7448173B; Mon, 2 Dec 2013 07:14:38 +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 rB27EaQI096116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Dec 2013 23:14:36 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rB27Eais096115; Sun, 1 Dec 2013 23:14:36 -0800 (PST) (envelope-from jmg) Date: Sun, 1 Dec 2013 23:14:36 -0800 From: John-Mark Gurney To: Venkata Duvvuru Subject: Re: sysctl add macros Message-ID: <20131202071436.GI55638@funkthat.com> Mail-Followup-To: Venkata Duvvuru , Matthew Fleming , "freebsd-current@freebsd.org" References: <20131130213006.GC55638@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 01 Dec 2013 23:14:36 -0800 (PST) Cc: Matthew Fleming , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 07:14:39 -0000 Venkata Duvvuru wrote this message on Mon, Dec 02, 2013 at 07:10 +0000: > I could use an int variable but if I have to dump huge number of statistics through sysctl in which case I need to add many such variables to the nodes and even if most of these variables are char I have to declare them as int, hence resulting in an increased footprint. If it's a few 10s of vars, then it isn't a big deal, but if it is 1000's, then you might want to look at another method to extract the data since the overhead of sysctl is expensive... Something like writing a _PROC routine that will copy them all out in a single sysctl call.. > -----Original Message----- > From: John-Mark Gurney [mailto:jmg@funkthat.com] > Sent: Sunday, December 01, 2013 3:00 AM > To: Venkata Duvvuru > Cc: Matthew Fleming; freebsd-current@freebsd.org > Subject: Re: sysctl add macros > > Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +0000: > > The problem with using int or u_int for 1 or 2 byte values is that while printing these 1 or 2 byte values I observed that sysctl module is considering 4 bytes. Hence I see an undesired output. It is actually considering the next two bytes also as the value. > > If you _NEED_ to use a char or short, you need to write your own/clone it from the macros... > > Why can't you use an int for this variable? > > > From: mdf356@gmail.com [mailto:mdf356@gmail.com] On Behalf Of Matthew > > Fleming > > Sent: Monday, November 25, 2013 8:18 PM > > To: Venkata Duvvuru > > Cc: freebsd-current@freebsd.org > > Subject: Re: sysctl add macros > > > > On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru > wrote: > > Hi, > > I'm unable to figure out how to add an unsigned short or an unsigned char values to a sysctl node. > > SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a short values I couldn't find any macros. > > > > Could you please let me know how to add them? > > > > FreeBSD does not have any sysctl handlers for 1 or 2 byte values. FreeBSD code that wants to do this has used int or u_int instead of a smaller type. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- 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-current@FreeBSD.ORG Mon Dec 2 08:29:24 2013 Return-Path: Delivered-To: freebsd-current@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 6ABA02D4 for ; Mon, 2 Dec 2013 08:29:24 +0000 (UTC) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 161181BE3 for ; Mon, 2 Dec 2013 08:29:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:content-type; s=smtpapi; bh=z/Y+mDi59VPC8YAmZSRVXv5go9Q=; b=Z3WLdZsLX7T9fE5XO4ITWSSAatfRA U89/9qj0Jg3RL/gMoOj8fHA9/bizunF6ML1AOoElzJBpVIoCKurQBlnNEEPS1FJs 5PpUHL2a4SjgW0Ws1U6oO5Z2JDJmIGu6w4gsLXl7U5WS274FBWKFMNd8qEzo/Ghc ZU1jjZa1LOEFNE= Received: by mf138.sendgrid.net with SMTP id mf138.37739.529C44E23 Mon, 02 Dec 2013 08:29:22 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi60 (SG) with ESMTP id 142b26d154b.5b02.13ee68 for ; Mon, 02 Dec 2013 02:29:22 -0600 (CST) Received: (qmail 12379 invoked from network); 2 Dec 2013 08:29:21 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 2 Dec 2013 08:29:21 -0000 Received: (qmail 21730 invoked from network); 2 Dec 2013 08:26:46 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 2 Dec 2013 08:26:46 -0000 Message-ID: <529C4446.6020508@freebsd.org> Date: Mon, 02 Dec 2013 00:26:46 -0800 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: FreeBSD current Subject: making PANIC_REBOOT_WAIT_TIME a tunable X-Enigmail-Version: 1.5.2 Content-Type: multipart/mixed; boundary="------------010603050706050309040401" X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S88hDVo7wPr0+CK+tH/z+ymQiprbVAx7lRDFIv9pWSs1jcDsLGlbmnzfgKXtIZyqU/j4fgI4L+zx5CB3yBP1gCW1wj0Xu7EUvBBmGphchOYODXA80G9DwglWpFspCQfy+0= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:29:24 -0000 This is a multi-part message in MIME format. --------------010603050706050309040401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, It seems that PANIC_REBOOT_WAIT_TIME has been a compile-time setting forever; and I can't see any reason for this, but I assume there was one... at some point in the distant past. The attached patch makes it a loader tunable and sysctl. My reason for wanting this is to make EC2 images reboot faster after a panic (not that it happens very often, of course) -- there's no point waiting for a key press at the console because the EC2 console is output-only. Any objections? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------010603050706050309040401 Content-Type: text/plain; charset=us-ascii; name="panic-wait-time-sysctl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="panic-wait-time-sysctl.patch" Index: sys/kern/kern_shutdown.c =================================================================== --- sys/kern/kern_shutdown.c (revision 258085) +++ sys/kern/kern_shutdown.c (working copy) @@ -89,6 +89,11 @@ #ifndef PANIC_REBOOT_WAIT_TIME #define PANIC_REBOOT_WAIT_TIME 15 /* default to 15 seconds */ #endif +int panic_reboot_wait_time = PANIC_REBOOT_WAIT_TIME; +SYSCTL_INT(_kern, OID_AUTO, panic_reboot_wait_time, CTLFLAG_RW | CTLFLAG_TUN, + &panic_reboot_wait_time, 0, + "Seconds to wait before rebooting after a panic"); +TUNABLE_INT("kern.panic_reboot_wait_time", &panic_reboot_wait_time); /* * Note that stdarg.h and the ANSI style va_start macro is used for both @@ -485,12 +490,12 @@ int loop; if (howto & RB_DUMP) { - if (PANIC_REBOOT_WAIT_TIME != 0) { - if (PANIC_REBOOT_WAIT_TIME != -1) { + if (panic_reboot_wait_time != 0) { + if (panic_reboot_wait_time != -1) { printf("Automatic reboot in %d seconds - " "press a key on the console to abort\n", - PANIC_REBOOT_WAIT_TIME); - for (loop = PANIC_REBOOT_WAIT_TIME * 10; + panic_reboot_wait_time); + for (loop = panic_reboot_wait_time * 10; loop > 0; --loop) { DELAY(1000 * 100); /* 1/10th second */ /* Did user type a key? */ --------------010603050706050309040401-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 08:46:56 2013 Return-Path: Delivered-To: current@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 2D70A718; Mon, 2 Dec 2013 08:46:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E45351CCC; Mon, 2 Dec 2013 08:46:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB28kmug087551; Mon, 2 Dec 2013 03:46:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB28kmju087544; Mon, 2 Dec 2013 08:46:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 08:46:48 GMT Message-Id: <201312020846.rB28kmju087544@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:46:56 -0000 TB --- 2013-12-02 05:22:34 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 05:22:34 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 05:22:34 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-02 05:22:34 - cleaning the object tree TB --- 2013-12-02 05:22:34 - /usr/local/bin/svn stat /src TB --- 2013-12-02 05:22:38 - At svn revision 258815 TB --- 2013-12-02 05:22:39 - building world TB --- 2013-12-02 05:22:39 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 05:22:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 05:22:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 05:22:39 - SRCCONF=/dev/null TB --- 2013-12-02 05:22:39 - TARGET=powerpc TB --- 2013-12-02 05:22:39 - TARGET_ARCH=powerpc TB --- 2013-12-02 05:22:39 - TZ=UTC TB --- 2013-12-02 05:22:39 - __MAKE_CONF=/dev/null TB --- 2013-12-02 05:22:39 - cd /src TB --- 2013-12-02 05:22:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 05:22:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Dec 2 07:59:47 UTC 2013 TB --- 2013-12-02 07:59:47 - generating LINT kernel config TB --- 2013-12-02 07:59:47 - cd /src/sys/powerpc/conf TB --- 2013-12-02 07:59:47 - /usr/bin/make -B LINT TB --- 2013-12-02 07:59:47 - cd /src/sys/powerpc/conf TB --- 2013-12-02 07:59:47 - /usr/sbin/config -m LINT TB --- 2013-12-02 07:59:47 - building LINT kernel TB --- 2013-12-02 07:59:47 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 07:59:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 07:59:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 07:59:47 - SRCCONF=/dev/null TB --- 2013-12-02 07:59:47 - TARGET=powerpc TB --- 2013-12-02 07:59:47 - TARGET_ARCH=powerpc TB --- 2013-12-02 07:59:47 - TZ=UTC TB --- 2013-12-02 07:59:47 - __MAKE_CONF=/dev/null TB --- 2013-12-02 07:59:47 - cd /src TB --- 2013-12-02 07:59:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 2 07:59:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Dec 2 08:22:46 UTC 2013 TB --- 2013-12-02 08:22:46 - cd /src/sys/powerpc/conf TB --- 2013-12-02 08:22:46 - /usr/sbin/config -m GENERIC TB --- 2013-12-02 08:22:46 - building GENERIC kernel TB --- 2013-12-02 08:22:46 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 08:22:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 08:22:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 08:22:46 - SRCCONF=/dev/null TB --- 2013-12-02 08:22:46 - TARGET=powerpc TB --- 2013-12-02 08:22:46 - TARGET_ARCH=powerpc TB --- 2013-12-02 08:22:46 - TZ=UTC TB --- 2013-12-02 08:22:46 - __MAKE_CONF=/dev/null TB --- 2013-12-02 08:22:46 - cd /src TB --- 2013-12-02 08:22:46 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Dec 2 08:22:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Dec 2 08:39:13 UTC 2013 TB --- 2013-12-02 08:39:13 - cd /src/sys/powerpc/conf TB --- 2013-12-02 08:39:13 - /usr/sbin/config -m GENERIC64 TB --- 2013-12-02 08:39:13 - skipping GENERIC64 kernel TB --- 2013-12-02 08:39:13 - cd /src/sys/powerpc/conf TB --- 2013-12-02 08:39:13 - /usr/sbin/config -m MPC85XX TB --- 2013-12-02 08:39:13 - building MPC85XX kernel TB --- 2013-12-02 08:39:13 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 08:39:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 08:39:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 08:39:13 - SRCCONF=/dev/null TB --- 2013-12-02 08:39:13 - TARGET=powerpc TB --- 2013-12-02 08:39:13 - TARGET_ARCH=powerpc TB --- 2013-12-02 08:39:13 - TZ=UTC TB --- 2013-12-02 08:39:13 - __MAKE_CONF=/dev/null TB --- 2013-12-02 08:39:13 - cd /src TB --- 2013-12-02 08:39:13 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Mon Dec 2 08:39:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for MPC85XX completed on Mon Dec 2 08:42:14 UTC 2013 TB --- 2013-12-02 08:42:14 - cd /src/sys/powerpc/conf TB --- 2013-12-02 08:42:14 - /usr/sbin/config -m WII TB --- 2013-12-02 08:42:14 - building WII kernel TB --- 2013-12-02 08:42:14 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 08:42:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 08:42:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 08:42:14 - SRCCONF=/dev/null TB --- 2013-12-02 08:42:14 - TARGET=powerpc TB --- 2013-12-02 08:42:14 - TARGET_ARCH=powerpc TB --- 2013-12-02 08:42:14 - TZ=UTC TB --- 2013-12-02 08:42:14 - __MAKE_CONF=/dev/null TB --- 2013-12-02 08:42:14 - cd /src TB --- 2013-12-02 08:42:14 - /usr/bin/make -B buildkernel KERNCONF=WII >>> Kernel build for WII started on Mon Dec 2 08:42:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/vm_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/wii/platform_wii.c /src/sys/powerpc/wii/platform_wii.c: In function 'wii_mem_regions': /src/sys/powerpc/wii/platform_wii.c:139: error: 'avail' undeclared (first use in this function) /src/sys/powerpc/wii/platform_wii.c:139: error: (Each undeclared identifier is reported only once /src/sys/powerpc/wii/platform_wii.c:139: error: for each function it appears in.) /src/sys/powerpc/wii/platform_wii.c:139: error: expected ')' before ';' token /src/sys/powerpc/wii/platform_wii.c:141: error: expected ';' before '}' token *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/WII *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 08:46:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 08:46:48 - ERROR: failed to build WII kernel TB --- 2013-12-02 08:46:48 - 10298.77 user 1320.96 system 12254.67 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:45:48 2013 Return-Path: Delivered-To: current@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 61B547AB; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FB5012B5; Mon, 2 Dec 2013 09:45:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29jloF093359; Mon, 2 Dec 2013 04:45:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29jlQm093315; Mon, 2 Dec 2013 09:45:47 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:45:47 GMT Message-Id: <201312020945.rB29jlQm093315@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:45:48 -0000 TB --- 2013-12-02 09:40:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:40:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:40:21 - starting HEAD tinderbox run for armv6/arm TB --- 2013-12-02 09:40:21 - cleaning the object tree TB --- 2013-12-02 09:40:21 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:40:26 - At svn revision 258841 TB --- 2013-12-02 09:40:27 - building world TB --- 2013-12-02 09:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:40:27 - SRCCONF=/dev/null TB --- 2013-12-02 09:40:27 - TARGET=arm TB --- 2013-12-02 09:40:27 - TARGET_ARCH=armv6 TB --- 2013-12-02 09:40:27 - TZ=UTC TB --- 2013-12-02 09:40:27 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:40:27 - cd /src TB --- 2013-12-02 09:40:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:40:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:45:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:45:47 - ERROR: failed to build world TB --- 2013-12-02 09:45:47 - 259.83 user 36.38 system 325.30 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:45:48 2013 Return-Path: Delivered-To: current@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 8FE1E7AC; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DFAA12B7; Mon, 2 Dec 2013 09:45:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29jlQZ093349; Mon, 2 Dec 2013 04:45:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29jl1X093292; Mon, 2 Dec 2013 09:45:47 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:45:47 GMT Message-Id: <201312020945.rB29jl1X093292@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:45:48 -0000 TB --- 2013-12-02 09:40:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:40:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:40:21 - starting HEAD tinderbox run for arm/arm TB --- 2013-12-02 09:40:21 - cleaning the object tree TB --- 2013-12-02 09:40:21 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:40:26 - At svn revision 258841 TB --- 2013-12-02 09:40:27 - building world TB --- 2013-12-02 09:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:40:27 - SRCCONF=/dev/null TB --- 2013-12-02 09:40:27 - TARGET=arm TB --- 2013-12-02 09:40:27 - TARGET_ARCH=arm TB --- 2013-12-02 09:40:27 - TZ=UTC TB --- 2013-12-02 09:40:27 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:40:27 - cd /src TB --- 2013-12-02 09:40:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:40:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:45:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:45:47 - ERROR: failed to build world TB --- 2013-12-02 09:45:47 - 259.66 user 36.52 system 325.29 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:45:48 2013 Return-Path: Delivered-To: current@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 9A63F7AE; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4534312B8; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29jlPW093705; Mon, 2 Dec 2013 04:45:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29jlLf093702; Mon, 2 Dec 2013 09:45:47 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:45:47 GMT Message-Id: <201312020945.rB29jlLf093702@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:45:48 -0000 TB --- 2013-12-02 09:40:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:40:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:40:21 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-12-02 09:40:21 - cleaning the object tree TB --- 2013-12-02 09:40:21 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:40:26 - At svn revision 258841 TB --- 2013-12-02 09:40:27 - building world TB --- 2013-12-02 09:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:40:27 - SRCCONF=/dev/null TB --- 2013-12-02 09:40:27 - TARGET=amd64 TB --- 2013-12-02 09:40:27 - TARGET_ARCH=amd64 TB --- 2013-12-02 09:40:27 - TZ=UTC TB --- 2013-12-02 09:40:27 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:40:27 - cd /src TB --- 2013-12-02 09:40:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:40:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:45:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:45:47 - ERROR: failed to build world TB --- 2013-12-02 09:45:47 - 259.62 user 35.78 system 325.65 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:45:48 2013 Return-Path: Delivered-To: current@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 95B5F7AD; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF7612B6; Mon, 2 Dec 2013 09:45:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29jlYm093637; Mon, 2 Dec 2013 04:45:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29jl3E093611; Mon, 2 Dec 2013 09:45:47 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:45:47 GMT Message-Id: <201312020945.rB29jl3E093611@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:45:48 -0000 TB --- 2013-12-02 09:40:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:40:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:40:21 - starting HEAD tinderbox run for i386/i386 TB --- 2013-12-02 09:40:21 - cleaning the object tree TB --- 2013-12-02 09:40:21 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:40:26 - At svn revision 258841 TB --- 2013-12-02 09:40:27 - building world TB --- 2013-12-02 09:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:40:27 - SRCCONF=/dev/null TB --- 2013-12-02 09:40:27 - TARGET=i386 TB --- 2013-12-02 09:40:27 - TARGET_ARCH=i386 TB --- 2013-12-02 09:40:27 - TZ=UTC TB --- 2013-12-02 09:40:27 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:40:27 - cd /src TB --- 2013-12-02 09:40:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:40:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:45:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:45:47 - ERROR: failed to build world TB --- 2013-12-02 09:45:47 - 259.61 user 36.43 system 325.53 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:47:51 2013 Return-Path: Delivered-To: current@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 49605E0A; Mon, 2 Dec 2013 09:47:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAD801302; Mon, 2 Dec 2013 09:47:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29lnKd007382; Mon, 2 Dec 2013 04:47:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29lnEU007356; Mon, 2 Dec 2013 09:47:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:47:49 GMT Message-Id: <201312020947.rB29lnEU007356@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:47:51 -0000 TB --- 2013-12-02 09:45:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:45:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:45:47 - starting HEAD tinderbox run for mips/mips TB --- 2013-12-02 09:45:47 - cleaning the object tree TB --- 2013-12-02 09:45:47 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:45:51 - At svn revision 258841 TB --- 2013-12-02 09:45:52 - building world TB --- 2013-12-02 09:45:52 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:45:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:45:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:45:52 - SRCCONF=/dev/null TB --- 2013-12-02 09:45:52 - TARGET=mips TB --- 2013-12-02 09:45:52 - TARGET_ARCH=mips TB --- 2013-12-02 09:45:52 - TZ=UTC TB --- 2013-12-02 09:45:52 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:45:52 - cd /src TB --- 2013-12-02 09:45:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:45:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:47:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:47:49 - ERROR: failed to build world TB --- 2013-12-02 09:47:49 - 84.02 user 15.70 system 122.29 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:47:52 2013 Return-Path: Delivered-To: current@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 F39E7E0B; Mon, 2 Dec 2013 09:47:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A11AF1303; Mon, 2 Dec 2013 09:47:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29log0007923; Mon, 2 Dec 2013 04:47:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29loLO007922; Mon, 2 Dec 2013 09:47:50 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:47:50 GMT Message-Id: <201312020947.rB29loLO007922@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:47:52 -0000 TB --- 2013-12-02 09:45:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:45:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:45:47 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-12-02 09:45:47 - cleaning the object tree TB --- 2013-12-02 09:45:47 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:45:51 - At svn revision 258841 TB --- 2013-12-02 09:45:52 - building world TB --- 2013-12-02 09:45:52 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:45:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:45:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:45:52 - SRCCONF=/dev/null TB --- 2013-12-02 09:45:52 - TARGET=ia64 TB --- 2013-12-02 09:45:52 - TARGET_ARCH=ia64 TB --- 2013-12-02 09:45:52 - TZ=UTC TB --- 2013-12-02 09:45:52 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:45:52 - cd /src TB --- 2013-12-02 09:45:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:45:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:47:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:47:50 - ERROR: failed to build world TB --- 2013-12-02 09:47:50 - 84.39 user 15.37 system 123.53 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:47:53 2013 Return-Path: Delivered-To: current@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 C0928EEB; Mon, 2 Dec 2013 09:47:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 714551304; Mon, 2 Dec 2013 09:47:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29lnt9007055; Mon, 2 Dec 2013 04:47:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29lnJF007005; Mon, 2 Dec 2013 09:47:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:47:49 GMT Message-Id: <201312020947.rB29lnJF007005@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:47:53 -0000 TB --- 2013-12-02 09:45:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:45:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:45:47 - starting HEAD tinderbox run for mips64/mips TB --- 2013-12-02 09:45:47 - cleaning the object tree TB --- 2013-12-02 09:45:47 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:45:51 - At svn revision 258841 TB --- 2013-12-02 09:45:52 - building world TB --- 2013-12-02 09:45:52 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:45:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:45:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:45:52 - SRCCONF=/dev/null TB --- 2013-12-02 09:45:52 - TARGET=mips TB --- 2013-12-02 09:45:52 - TARGET_ARCH=mips64 TB --- 2013-12-02 09:45:52 - TZ=UTC TB --- 2013-12-02 09:45:52 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:45:52 - cd /src TB --- 2013-12-02 09:45:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:45:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:47:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:47:49 - ERROR: failed to build world TB --- 2013-12-02 09:47:49 - 84.08 user 15.71 system 121.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:49:54 2013 Return-Path: Delivered-To: current@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 6D390223; Mon, 2 Dec 2013 09:49:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 195DB1338; Mon, 2 Dec 2013 09:49:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29nrNG015032; Mon, 2 Dec 2013 04:49:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29nrsL015031; Mon, 2 Dec 2013 09:49:53 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:49:53 GMT Message-Id: <201312020949.rB29nrsL015031@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:49:54 -0000 TB --- 2013-12-02 09:47:51 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:47:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:47:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-12-02 09:47:51 - cleaning the object tree TB --- 2013-12-02 09:47:51 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:47:54 - At svn revision 258841 TB --- 2013-12-02 09:47:55 - building world TB --- 2013-12-02 09:47:55 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:47:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:47:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:47:55 - SRCCONF=/dev/null TB --- 2013-12-02 09:47:55 - TARGET=sparc64 TB --- 2013-12-02 09:47:55 - TARGET_ARCH=sparc64 TB --- 2013-12-02 09:47:55 - TZ=UTC TB --- 2013-12-02 09:47:55 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:47:55 - cd /src TB --- 2013-12-02 09:47:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:48:02 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:49:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:49:53 - ERROR: failed to build world TB --- 2013-12-02 09:49:53 - 85.55 user 14.88 system 121.84 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:51:03 2013 Return-Path: Delivered-To: current@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 B0D8A3B9; Mon, 2 Dec 2013 09:51:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E77E137D; Mon, 2 Dec 2013 09:51:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29p2la018747; Mon, 2 Dec 2013 04:51:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29p2PE018746; Mon, 2 Dec 2013 09:51:02 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:51:02 GMT Message-Id: <201312020951.rB29p2PE018746@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:51:03 -0000 TB --- 2013-12-02 09:45:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:45:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:45:47 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-12-02 09:45:47 - cleaning the object tree TB --- 2013-12-02 09:45:47 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:45:51 - At svn revision 258841 TB --- 2013-12-02 09:45:52 - building world TB --- 2013-12-02 09:45:52 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:45:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:45:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:45:52 - SRCCONF=/dev/null TB --- 2013-12-02 09:45:52 - TARGET=pc98 TB --- 2013-12-02 09:45:52 - TARGET_ARCH=i386 TB --- 2013-12-02 09:45:52 - TZ=UTC TB --- 2013-12-02 09:45:52 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:45:52 - cd /src TB --- 2013-12-02 09:45:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:45:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:51:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:51:02 - ERROR: failed to build world TB --- 2013-12-02 09:51:02 - 258.23 user 32.43 system 315.08 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:52:52 2013 Return-Path: Delivered-To: current@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 48959506; Mon, 2 Dec 2013 09:52:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9DB913A3; Mon, 2 Dec 2013 09:52:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29qoBI024638; Mon, 2 Dec 2013 04:52:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29qoxj024627; Mon, 2 Dec 2013 09:52:50 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:52:50 GMT Message-Id: <201312020952.rB29qoxj024627@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:52:52 -0000 TB --- 2013-12-02 09:47:50 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:47:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:47:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-12-02 09:47:50 - cleaning the object tree TB --- 2013-12-02 09:47:50 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:47:53 - At svn revision 258841 TB --- 2013-12-02 09:47:54 - building world TB --- 2013-12-02 09:47:54 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:47:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:47:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:47:54 - SRCCONF=/dev/null TB --- 2013-12-02 09:47:54 - TARGET=powerpc TB --- 2013-12-02 09:47:54 - TARGET_ARCH=powerpc64 TB --- 2013-12-02 09:47:54 - TZ=UTC TB --- 2013-12-02 09:47:54 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:47:54 - cd /src TB --- 2013-12-02 09:47:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:48:01 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:52:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:52:50 - ERROR: failed to build world TB --- 2013-12-02 09:52:50 - 255.91 user 29.30 system 300.81 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 09:53:53 2013 Return-Path: Delivered-To: current@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 A3A71633; Mon, 2 Dec 2013 09:53:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F63713BB; Mon, 2 Dec 2013 09:53:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB29rqAN026982; Mon, 2 Dec 2013 04:53:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB29rqfl026981; Mon, 2 Dec 2013 09:53:52 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 09:53:52 GMT Message-Id: <201312020953.rB29rqfl026981@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:53:53 -0000 TB --- 2013-12-02 09:47:49 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 09:47:49 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 09:47:49 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-02 09:47:49 - cleaning the object tree TB --- 2013-12-02 09:49:06 - /usr/local/bin/svn stat /src TB --- 2013-12-02 09:49:09 - At svn revision 258841 TB --- 2013-12-02 09:49:10 - building world TB --- 2013-12-02 09:49:10 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 09:49:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 09:49:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 09:49:10 - SRCCONF=/dev/null TB --- 2013-12-02 09:49:10 - TARGET=powerpc TB --- 2013-12-02 09:49:10 - TARGET_ARCH=powerpc TB --- 2013-12-02 09:49:10 - TZ=UTC TB --- 2013-12-02 09:49:10 - __MAKE_CONF=/dev/null TB --- 2013-12-02 09:49:10 - cd /src TB --- 2013-12-02 09:49:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 09:49:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 09:53:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 09:53:52 - ERROR: failed to build world TB --- 2013-12-02 09:53:52 - 256.66 user 33.48 system 362.54 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:06:25 2013 Return-Path: Delivered-To: current@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 6D557A50; Mon, 2 Dec 2013 10:06:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A95114C8; Mon, 2 Dec 2013 10:06:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A6NTm046063; Mon, 2 Dec 2013 05:06:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A6Nax046051; Mon, 2 Dec 2013 10:06:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:06:23 GMT Message-Id: <201312021006.rB2A6Nax046051@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:06:25 -0000 TB --- 2013-12-02 10:00:15 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:00:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:00:15 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-12-02 10:00:15 - cleaning the object tree TB --- 2013-12-02 10:01:16 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:01:19 - At svn revision 258842 TB --- 2013-12-02 10:01:20 - building world TB --- 2013-12-02 10:01:20 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:01:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:01:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:01:20 - SRCCONF=/dev/null TB --- 2013-12-02 10:01:20 - TARGET=amd64 TB --- 2013-12-02 10:01:20 - TARGET_ARCH=amd64 TB --- 2013-12-02 10:01:20 - TZ=UTC TB --- 2013-12-02 10:01:20 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:01:20 - cd /src TB --- 2013-12-02 10:01:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:01:27 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:06:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:06:23 - ERROR: failed to build world TB --- 2013-12-02 10:06:23 - 260.32 user 31.44 system 368.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:06:30 2013 Return-Path: Delivered-To: current@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 10078B4A; Mon, 2 Dec 2013 10:06:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B29EC14C9; Mon, 2 Dec 2013 10:06:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A6S24047237; Mon, 2 Dec 2013 05:06:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A6SIS047235; Mon, 2 Dec 2013 10:06:28 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:06:28 GMT Message-Id: <201312021006.rB2A6SIS047235@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:06:30 -0000 TB --- 2013-12-02 10:00:15 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:00:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:00:15 - starting HEAD tinderbox run for arm/arm TB --- 2013-12-02 10:00:15 - cleaning the object tree TB --- 2013-12-02 10:01:17 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:01:20 - At svn revision 258842 TB --- 2013-12-02 10:01:21 - building world TB --- 2013-12-02 10:01:21 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:01:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:01:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:01:21 - SRCCONF=/dev/null TB --- 2013-12-02 10:01:21 - TARGET=arm TB --- 2013-12-02 10:01:21 - TARGET_ARCH=arm TB --- 2013-12-02 10:01:21 - TZ=UTC TB --- 2013-12-02 10:01:21 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:01:21 - cd /src TB --- 2013-12-02 10:01:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:01:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:06:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:06:28 - ERROR: failed to build world TB --- 2013-12-02 10:06:28 - 258.88 user 33.13 system 373.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:06:38 2013 Return-Path: Delivered-To: current@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 4959CC8B; Mon, 2 Dec 2013 10:06:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED39C14DE; Mon, 2 Dec 2013 10:06:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A6bBk049054; Mon, 2 Dec 2013 05:06:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A6big049053; Mon, 2 Dec 2013 10:06:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:06:37 GMT Message-Id: <201312021006.rB2A6big049053@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:06:38 -0000 TB --- 2013-12-02 10:00:15 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:00:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:00:15 - starting HEAD tinderbox run for i386/i386 TB --- 2013-12-02 10:00:15 - cleaning the object tree TB --- 2013-12-02 10:01:19 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:01:22 - At svn revision 258842 TB --- 2013-12-02 10:01:23 - building world TB --- 2013-12-02 10:01:23 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:01:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:01:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:01:23 - SRCCONF=/dev/null TB --- 2013-12-02 10:01:23 - TARGET=i386 TB --- 2013-12-02 10:01:23 - TARGET_ARCH=i386 TB --- 2013-12-02 10:01:23 - TZ=UTC TB --- 2013-12-02 10:01:23 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:01:23 - cd /src TB --- 2013-12-02 10:01:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:01:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:06:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:06:37 - ERROR: failed to build world TB --- 2013-12-02 10:06:37 - 259.46 user 33.08 system 381.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:06:36 2013 Return-Path: Delivered-To: current@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 C0A53B9C; Mon, 2 Dec 2013 10:06:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EAB814D9; Mon, 2 Dec 2013 10:06:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A6Zaf048343; Mon, 2 Dec 2013 05:06:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A6Zpg048342; Mon, 2 Dec 2013 10:06:35 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:06:35 GMT Message-Id: <201312021006.rB2A6Zpg048342@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:06:36 -0000 TB --- 2013-12-02 10:00:15 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:00:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:00:15 - starting HEAD tinderbox run for armv6/arm TB --- 2013-12-02 10:00:15 - cleaning the object tree TB --- 2013-12-02 10:01:19 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:01:23 - At svn revision 258842 TB --- 2013-12-02 10:01:24 - building world TB --- 2013-12-02 10:01:24 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:01:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:01:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:01:24 - SRCCONF=/dev/null TB --- 2013-12-02 10:01:24 - TARGET=arm TB --- 2013-12-02 10:01:24 - TARGET_ARCH=armv6 TB --- 2013-12-02 10:01:24 - TZ=UTC TB --- 2013-12-02 10:01:24 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:01:24 - cd /src TB --- 2013-12-02 10:01:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:01:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:06:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:06:35 - ERROR: failed to build world TB --- 2013-12-02 10:06:35 - 259.68 user 32.77 system 379.58 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:09:20 2013 Return-Path: Delivered-To: current@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 C1921ED; Mon, 2 Dec 2013 10:09:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7050D152B; Mon, 2 Dec 2013 10:09:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A9JhQ061899; Mon, 2 Dec 2013 05:09:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A9JkM061898; Mon, 2 Dec 2013 10:09:19 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:09:19 GMT Message-Id: <201312021009.rB2A9JkM061898@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:09:20 -0000 TB --- 2013-12-02 10:06:29 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:06:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:06:29 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-12-02 10:06:29 - cleaning the object tree TB --- 2013-12-02 10:07:27 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:07:31 - At svn revision 258842 TB --- 2013-12-02 10:07:32 - building world TB --- 2013-12-02 10:07:32 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:07:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:07:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:07:32 - SRCCONF=/dev/null TB --- 2013-12-02 10:07:32 - TARGET=ia64 TB --- 2013-12-02 10:07:32 - TARGET_ARCH=ia64 TB --- 2013-12-02 10:07:32 - TZ=UTC TB --- 2013-12-02 10:07:32 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:07:32 - cd /src TB --- 2013-12-02 10:07:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:07:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:09:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:09:19 - ERROR: failed to build world TB --- 2013-12-02 10:09:19 - 84.43 user 14.72 system 170.44 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:09:22 2013 Return-Path: Delivered-To: current@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 E7D1F14D; Mon, 2 Dec 2013 10:09:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 953E4152C; Mon, 2 Dec 2013 10:09:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A9LbN062569; Mon, 2 Dec 2013 05:09:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A9LUw062553; Mon, 2 Dec 2013 10:09:21 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:09:21 GMT Message-Id: <201312021009.rB2A9LUw062553@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:09:23 -0000 TB --- 2013-12-02 10:06:37 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:06:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:06:37 - starting HEAD tinderbox run for mips64/mips TB --- 2013-12-02 10:06:37 - cleaning the object tree TB --- 2013-12-02 10:07:29 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:07:33 - At svn revision 258842 TB --- 2013-12-02 10:07:34 - building world TB --- 2013-12-02 10:07:34 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:07:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:07:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:07:34 - SRCCONF=/dev/null TB --- 2013-12-02 10:07:34 - TARGET=mips TB --- 2013-12-02 10:07:34 - TARGET_ARCH=mips64 TB --- 2013-12-02 10:07:34 - TZ=UTC TB --- 2013-12-02 10:07:34 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:07:34 - cd /src TB --- 2013-12-02 10:07:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:07:40 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:09:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:09:21 - ERROR: failed to build world TB --- 2013-12-02 10:09:21 - 83.70 user 15.51 system 163.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:09:24 2013 Return-Path: Delivered-To: current@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 281701EB; Mon, 2 Dec 2013 10:09:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBF29152F; Mon, 2 Dec 2013 10:09:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2A9Mai063152; Mon, 2 Dec 2013 05:09:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2A9MXV063151; Mon, 2 Dec 2013 10:09:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:09:22 GMT Message-Id: <201312021009.rB2A9MXV063151@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:09:24 -0000 TB --- 2013-12-02 10:06:35 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:06:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:06:35 - starting HEAD tinderbox run for mips/mips TB --- 2013-12-02 10:06:35 - cleaning the object tree TB --- 2013-12-02 10:07:29 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:07:32 - At svn revision 258842 TB --- 2013-12-02 10:07:33 - building world TB --- 2013-12-02 10:07:33 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:07:33 - SRCCONF=/dev/null TB --- 2013-12-02 10:07:33 - TARGET=mips TB --- 2013-12-02 10:07:33 - TARGET_ARCH=mips TB --- 2013-12-02 10:07:33 - TZ=UTC TB --- 2013-12-02 10:07:33 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:07:33 - cd /src TB --- 2013-12-02 10:07:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:07:40 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:09:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:09:22 - ERROR: failed to build world TB --- 2013-12-02 10:09:22 - 83.91 user 15.33 system 166.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:12:05 2013 Return-Path: Delivered-To: current@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 15E4D4E5; Mon, 2 Dec 2013 10:12:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5BDC1591; Mon, 2 Dec 2013 10:12:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2AC3cX072350; Mon, 2 Dec 2013 05:12:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2AC3WE072347; Mon, 2 Dec 2013 10:12:03 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:12:03 GMT Message-Id: <201312021012.rB2AC3WE072347@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:12:05 -0000 TB --- 2013-12-02 10:09:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:09:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:09:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-12-02 10:09:22 - cleaning the object tree TB --- 2013-12-02 10:10:07 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:10:10 - At svn revision 258842 TB --- 2013-12-02 10:10:11 - building world TB --- 2013-12-02 10:10:11 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:10:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:10:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:10:11 - SRCCONF=/dev/null TB --- 2013-12-02 10:10:11 - TARGET=sparc64 TB --- 2013-12-02 10:10:11 - TARGET_ARCH=sparc64 TB --- 2013-12-02 10:10:11 - TZ=UTC TB --- 2013-12-02 10:10:11 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:10:11 - cd /src TB --- 2013-12-02 10:10:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:10:18 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:12:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:12:03 - ERROR: failed to build world TB --- 2013-12-02 10:12:03 - 84.41 user 15.48 system 160.99 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:12:25 2013 Return-Path: Delivered-To: current@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 149A0611; Mon, 2 Dec 2013 10:12:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5A56159B; Mon, 2 Dec 2013 10:12:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2ACN4e073929; Mon, 2 Dec 2013 05:12:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2ACNjr073928; Mon, 2 Dec 2013 10:12:23 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:12:23 GMT Message-Id: <201312021012.rB2ACNjr073928@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:12:25 -0000 TB --- 2013-12-02 10:06:24 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:06:24 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:06:24 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-12-02 10:06:24 - cleaning the object tree TB --- 2013-12-02 10:07:23 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:07:26 - At svn revision 258842 TB --- 2013-12-02 10:07:27 - building world TB --- 2013-12-02 10:07:27 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:07:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:07:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:07:27 - SRCCONF=/dev/null TB --- 2013-12-02 10:07:27 - TARGET=pc98 TB --- 2013-12-02 10:07:27 - TARGET_ARCH=i386 TB --- 2013-12-02 10:07:27 - TZ=UTC TB --- 2013-12-02 10:07:27 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:07:27 - cd /src TB --- 2013-12-02 10:07:27 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:07:34 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:12:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:12:23 - ERROR: failed to build world TB --- 2013-12-02 10:12:23 - 257.30 user 31.45 system 359.82 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:14:59 2013 Return-Path: Delivered-To: current@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 534FB787; Mon, 2 Dec 2013 10:14:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F392615CA; Mon, 2 Dec 2013 10:14:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2AEwRf081586; Mon, 2 Dec 2013 05:14:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2AEwiW081585; Mon, 2 Dec 2013 10:14:58 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:14:58 GMT Message-Id: <201312021014.rB2AEwiW081585@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:14:59 -0000 TB --- 2013-12-02 10:09:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:09:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:09:19 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-02 10:09:19 - cleaning the object tree TB --- 2013-12-02 10:10:06 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:10:10 - At svn revision 258842 TB --- 2013-12-02 10:10:11 - building world TB --- 2013-12-02 10:10:11 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:10:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:10:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:10:11 - SRCCONF=/dev/null TB --- 2013-12-02 10:10:11 - TARGET=powerpc TB --- 2013-12-02 10:10:11 - TARGET_ARCH=powerpc TB --- 2013-12-02 10:10:11 - TZ=UTC TB --- 2013-12-02 10:10:11 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:10:11 - cd /src TB --- 2013-12-02 10:10:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:10:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:14:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:14:58 - ERROR: failed to build world TB --- 2013-12-02 10:14:58 - 253.77 user 29.59 system 338.36 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 10:15:01 2013 Return-Path: Delivered-To: current@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 65DC67F1; Mon, 2 Dec 2013 10:15:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1257D15CC; Mon, 2 Dec 2013 10:15:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2AF0bK082215; Mon, 2 Dec 2013 05:15:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2AF01d082214; Mon, 2 Dec 2013 10:15:00 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 10:15:00 GMT Message-Id: <201312021015.rB2AF01d082214@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:15:01 -0000 TB --- 2013-12-02 10:09:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 10:09:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 10:09:22 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-12-02 10:09:22 - cleaning the object tree TB --- 2013-12-02 10:10:07 - /usr/local/bin/svn stat /src TB --- 2013-12-02 10:10:11 - At svn revision 258842 TB --- 2013-12-02 10:10:12 - building world TB --- 2013-12-02 10:10:12 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 10:10:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 10:10:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 10:10:12 - SRCCONF=/dev/null TB --- 2013-12-02 10:10:12 - TARGET=powerpc TB --- 2013-12-02 10:10:12 - TARGET_ARCH=powerpc64 TB --- 2013-12-02 10:10:12 - TZ=UTC TB --- 2013-12-02 10:10:12 - __MAKE_CONF=/dev/null TB --- 2013-12-02 10:10:12 - cd /src TB --- 2013-12-02 10:10:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 10:10:18 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree [...] rm -f a.out camlib.o scsi_cmdparse.o scsi_all.o scsi_da.o scsi_sa.o cam.o ata_all.o smp_all.o camlib.o.tmp scsi_cmdparse.o.tmp scsi_all.o.tmp scsi_da.o.tmp scsi_sa.o.tmp cam.o.tmp ata_all.o.tmp smp_all.o.tmp rm -f camlib.po scsi_cmdparse.po scsi_all.po scsi_da.po scsi_sa.po cam.po ata_all.po smp_all.po camlib.po.tmp scsi_cmdparse.po.tmp scsi_all.po.tmp scsi_da.po.tmp scsi_sa.po.tmp cam.po.tmp ata_all.po.tmp smp_all.po.tmp rm -f camlib.So scsi_cmdparse.So scsi_all.So scsi_da.So scsi_sa.So cam.So ata_all.So smp_all.So camlib.so scsi_cmdparse.so scsi_all.so scsi_da.so scsi_sa.so cam.so ata_all.so smp_all.so camlib.So.tmp scsi_cmdparse.So.tmp scsi_all.So.tmp scsi_da.So.tmp scsi_sa.So.tmp cam.So.tmp ata_all.So.tmp smp_all.So.tmp rm -f libcam.so rm -f libcam.a libcam_p.a libcam.so.6 rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> lib/libcasper (cleandir) cd: can't cd to /src/lib/libcasper *** Error code 2 Stop. bmake[2]: stopped in /src/lib *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 10:15:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 10:15:00 - ERROR: failed to build world TB --- 2013-12-02 10:15:00 - 253.53 user 29.97 system 338.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 11:36:48 2013 Return-Path: Delivered-To: freebsd-current@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 7E21C914; Mon, 2 Dec 2013 11:36:48 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CD4B1C65; Mon, 2 Dec 2013 11:36:47 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id c11so8403816lbj.33 for ; Mon, 02 Dec 2013 03:36:45 -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=qTU7Q/AIp9kHrcHK+lK70NkoSLxkcH8Ceb88oF4YTGA=; b=dCpyXHnM47pnGYFAmZzhhNqqcVbBZKgxmy0+ScCJbwPoQVPZ4pJKSqKtMo2MSmqWVg IV4mCZKr4iV+zUFDukIiRJVpQ/xWAY7hmU54XyKotPV8XpyWT5v1KsgqDu8IKIfNWYhB UqTzc/Ut+WyYlBneXatwFu98v43A/jYH6h+/RD5u34v7GEOHhvtxY0zSH9kZ7cdzJFT5 Y37mcRR8XvjkAXkAkbdy42TMG744MFBs4/JoPkjM28KOfUZO5LJ4MuXL28jidE3z2Dx/ kUKh/d2TAD6TObUcgacb1lSoOyus6k5Akz4Kf0xZ03bjOXRMjJMYe3HkHXb3iutseAae 4s1w== MIME-Version: 1.0 X-Received: by 10.152.28.230 with SMTP id e6mr39187123lah.3.1385984205170; Mon, 02 Dec 2013 03:36:45 -0800 (PST) Received: by 10.114.166.163 with HTTP; Mon, 2 Dec 2013 03:36:45 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Mon, 2 Dec 2013 19:36:45 +0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Sepherosa Ziehau To: Oleg Moskalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:36:48 -0000 On Mon, Dec 2, 2013 at 12:29 PM, Oleg Moskalenko wrote= : > Sepherosa, while reading your description I noticed another long-standing > problem for UDP application developers: the UDP sockets are always hashed > with 2-tuple. But UDP sockets can be "connected", too, to a remote addres= s, > with connect(...) > The connected UDP sockets will be in connect hash, which is hashed using faddr/laddr/fport/lport. SO_REUSEPORT only affects wildcard sockets. > function. Unfortunately, with 2-tuple hashing, that pattern is useless fo= r > large-scale applications: if a large number of UDP sockets on the same > local port are "connected" to remote address, then the kernel have to go > thru the long list of UDP sockets with the same hash value. > > If the connected UDP sockets would use 4-tuples, then it would be very > helpful for the new generation of the UDP-based media applications. For > example, servers which use DTLS protocol would become simpler and more > efficient. > > If you are talking about RSS, then igb, ixgbe and mxge (and may be other drivers) support RSS extension (mxge is not using RSS, but still 4-tuple hash), which will include UDP fport/lport into Toeplitz hash calculation. Well, for fragments of a UDP datagram, if the ports are taken into consideration the RSS hash will be different for leading fragment and rest of the fragments; I think that's why MS didn't include ports for UDP. Best Regards, sephe > Thanks > Oleg > > > > On Sun, Dec 1, 2013 at 8:17 PM, Sepherosa Ziehau wro= te: > >> >> >> >> On Sat, Nov 30, 2013 at 2:42 AM, Ermal Lu=E7i wrote: >> >>> Well seems Dragonfly has some version of it already from commit [1]. >>> >>> >> The distribution algorithm was changed a little bit after initial commit >> to gain more idle time (bnx(4) output has already been maxed out): >> >> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c275f18d832361be= 28b150d3f4fd518914bdeba6 >> >> Well, I also addressed a reasonable concern from nginx folks (I am not >> quite sure about Linux's position on it; Linux original implementation o= f >> SO_REUSEPORT from Google had this drawback, which I mentioned in the com= mit >> message): >> >> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/02ad2f0b874fb0a4= 5eb69750219f79f5e8982272 >> >> As about nginx, SO_REUSEPORT patch for nginx (both 1.4.x and 1.5.x) is i= n >> dports; should be easier to be back ported to FreeBSD's ports. I failed= to >> convince nginx folks to merge it into mainline and I am currently onto >> other stuffs, will come back to them later. If FreeBSD is going to >> implement Linux's style of SO_REUSEPORT, pushing the patch to the nginx >> mainline will be easier. >> >> I also put up a brief description of SO_REUSEPORT in dfly; may be useful >> to you: >> http://leaf.dragonflybsd.org/~sephe/netisr_so_reuseport.txt >> >> Best Regards, >> sephe >> >> >>> In FreeBSD there is the framework for this with by defining PCBGROUP. >>> Also the explanation of it at [2] and [3]. >>> It can achieve approximately the same features of SO_RESUSEPORT of linu= x. >>> The only thing missing is the marketing behind it and i think and bette= r >>> RSS support. >>> By looking at dates the support is there before linux so all you guys >>> looking for it can experiment with it. >>> >>> What i was trying to accomplish was something else from performance >>> improvement and >>> maybe put a sysctl behind it to make it more acceptable.. >>> >>> [1] >>> >>> http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/740d1d9f7b7bf9c= 9c021abb8197718d7a2d441c9 >>> [2] >>> http://fxr.watson.org/fxr/source/netinet/in_pcbgroup.c?im=3Dbigexcerpts= #L51 >>> [3] >>> http://lists.freebsd.org/pipermail/svn-src-head/2011-June/028190.html >>> >>> >>> On Fri, Nov 29, 2013 at 7:03 PM, Oleg Moskalenko >> >wrote: >>> >>> > Tim, you are wrong. Read what is "multicast" definition, and read how >>> UDP >>> > and TCP sockets work in Linux 3.9+ kernels. >>> > >>> > Oleg . >>> > >>> > >>> > On Fri, Nov 29, 2013 at 9:59 AM, Tim Kientzle >> >wrote: >>> > >>> >> >>> >> On Nov 29, 2013, at 4:04 AM, Ermal Lu=E7i wrote: >>> >> >>> >> > Hello, >>> >> > >>> >> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two >>> daemons to >>> >> > share the same port and possibly listening ip =85 >>> >> >>> >> These flags are used with TCP-based servers. >>> >> >>> >> I=92ve used them to make software upgrades go more smoothly. >>> >> Without them, the following often happens: >>> >> >>> >> * Old server stops. In the process, all of its TCP connections are >>> >> closed. >>> >> >>> >> * Connections to old server remain in the TCP connection table until >>> the >>> >> remote end can acknowledge. >>> >> >>> >> * New server starts. >>> >> >>> >> * New server tries to open port but fails because that port is =93st= ill >>> in >>> >> use=94 by connections in the TCP connection table. >>> >> >>> >> With these flags, the new server can open the port even though >>> >> it is =93still in use=94 by existing connections. >>> >> >>> >> >>> >> > This is not the case today. >>> >> > Only multicast sockets seem to have the behaviour of broadcasting >>> the >>> >> data >>> >> > to all sockets sharing the same properties through these options! >>> >> >>> >> That is what multicast is for. >>> >> >>> >> If you want the same data sent to all listeners, then >>> >> that is multicast behavior and you should be using >>> >> a multicast socket. >>> >> >>> >> > The patch at [1] implements/corrects the behaviour for UDP sockets= . >>> >> >>> >> You=92re trying to turn all UDP sockets with those options >>> >> into multicast sockets. >>> >> >>> >> If you want a multicast socket, you should ask for one. >>> >> >>> >> Tim >>> >> >>> >> _______________________________________________ >>> >> freebsd-net@freebsd.org mailing list >>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g >>> " >>> >> >>> > >>> > >>> >>> >>> -- >>> Ermal >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> >> >> -- >> Tomorrow Will Never Die >> > > --=20 Tomorrow Will Never Die From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 11:45:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60110C12; Mon, 2 Dec 2013 11:45:58 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 208AD1CE7; Mon, 2 Dec 2013 11:45:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id b8so2107915lan.13 for ; Mon, 02 Dec 2013 03:45:55 -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=vX313e18J9aw/XnxvVPUlETDS0/4b/gcKO+9Hem8Q6g=; b=BJsCbZajKAUpeNeIFQ3Jb3izcl56KP4rNuYRW1egj4kOaFQ+dJ8PjDz3las5sIebAI 8HXmz9ujfR5ilGahZdQk8/EYLIheuPcBHKtEFNL6/lYYLVunJ6i6H47ehHypwSeZdiyJ kQ31KxAu+7oo5IBInrUw2qlZfvOOe3HoprWYYSCPP9cOyxCYkbnc1EigYR22cOsxfiEh Gw8Zmv0bAKA0n9+Rubi2Ck7UJQGuhdjogql3zow2q4MDZdxaPIzm2LGrv1yXDlgbrbEC f4KJrQRFtvkFpo94KMNFKwmxyf2OlNK2CXa0Em4VqK9kXaFmPYIvEj1BNAYrMjOdTb20 t0xw== MIME-Version: 1.0 X-Received: by 10.152.140.193 with SMTP id ri1mr45245856lab.18.1385984754969; Mon, 02 Dec 2013 03:45:54 -0800 (PST) Received: by 10.114.166.163 with HTTP; Mon, 2 Dec 2013 03:45:54 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Mon, 2 Dec 2013 19:45:54 +0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Sepherosa Ziehau To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:45:58 -0000 On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd wrote: > Hi! Thanks for the writeup! > > On 1 December 2013 20:17, Sepherosa Ziehau wrote: > > > I also put up a brief description of SO_REUSEPORT in dfly; may be useful > to > > you: > > http://leaf.dragonflybsd.org/~sephe/netisr_so_reuseport.txt > > Ok, so given this, how do you guarantee the UTHREAD stays on the given > CPU? You assume it stays on the CPU that the initial listen socket was > created on, right? If it's migrated to another CPU core then the > listen queue still stays in the original hash group that's in a netisr > on a different CPU? > > As I wrote in the above brief introduction, Dfly currently relies on the scheduler doing the proper thing (the scheduler does do a very good job during my tests). I need to export certain kind of socket option to make that information available to user space programs. Force UTHREAD binding in kernel is not helpful, given in reverse proxy application, things are different. And even if that kind of binding information was exported to user space, user space program still would have to poll it periodically (in Dfly at least), since other programs binding to the same addr/port could come and go, which will cause reorganizing of the inp localgroup in the current Dfly implementation. Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 12:36:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAEA7C1E for ; Mon, 2 Dec 2013 12:36:38 +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 A37321FDC for ; Mon, 2 Dec 2013 12:36:38 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnSjn-0004uU-TI for freebsd-current@freebsd.org; Mon, 02 Dec 2013 13:36:36 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 13:36:31 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 13:36:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Mon, 2 Dec 2013 12:36:11 +0000 (UTC) Lines: 31 Message-ID: References: <52995C15.7010903@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:36:39 -0000 gmx.com> writes: > > So new flags could be [1]: > - realloc_flags(p, s, REALLOCF_NO_MOVE) > ... > - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC) > ... > For this, there could be a REALLOCF_FORCE flag In case of realloc_flags() failing the request, to avoid unnecessary followups with regular realloc() when desired, we should include an option like REALLOCF_FALLBACK_ANY that would allow to fallback on the regular realloc() logic, in one call. In addition, because I have an impression that realloc_flags() may have a future as a replacement for regular realloc() and we should aim for it, we should include an option like REALLOCF_ANY for that purpose. So far, the options could be as follows: - realloc_flags(p, s, option) where option is one or a combination (where appropriate) of: REALLOCF_ANY - default (move or no-move; regular realloc()) REALLOCF_NO_MOVE - no-move REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE REALLOCF_FORCE - combined with REALLOCF_NO_MOVE REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its derivatives like REALLOCF_ELASTIC, etc jb From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 13:29:09 2013 Return-Path: Delivered-To: freebsd-current@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 56E64D8B for ; Mon, 2 Dec 2013 13:29:09 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1EAB1329 for ; Mon, 2 Dec 2013 13:29:08 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id b8so2074482lan.41 for ; Mon, 02 Dec 2013 05:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Zmz5QXaXd5xdzBCVQvr9e1NHqrrlvINaIcv4lm+oR8Q=; b=l4Qgt0i19LRlV/t8ocVmkXoJZYuZ+rSjuKqXWkr5QOyOmx/J8h5h08R2fzbOs/5zuM BdFEKekWdTzDm8izKM+CtgMUvjY4jw1MX6Bbbn1gix6GnrayKcp3EvNnnR/bPbVkv6vY Kaa7DaTC5MsLjUSIHOenCe2t0vQwkl4hQZxv45z3NhKILfSCAjm292LxsJiSrUMxCcPz grXvpx8x7r9GvW3WRAvwwnIkvnCbvubhLNBnxgN08UFzC6v1oz79moVwTP8HeN246nBH Sgkojcb9i7wno4B5WTJ1iu8XEmJDeEytQLjOp1AobA/V3WYm34RFd8az5xINc+2j1qZF Kc8w== MIME-Version: 1.0 X-Received: by 10.152.234.75 with SMTP id uc11mr1021546lac.30.1385990946776; Mon, 02 Dec 2013 05:29:06 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Mon, 2 Dec 2013 05:29:06 -0800 (PST) In-Reply-To: References: <52995C15.7010903@gmx.com> Date: Mon, 2 Dec 2013 05:29:06 -0800 X-Google-Sender-Auth: 5DURvJ-ZaMWiDhKZP6DdtzTdKe0 Message-ID: Subject: Re: [RFC] how to get the size of a malloc(9) block ? From: Luigi Rizzo To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:29:09 -0000 On Mon, Dec 2, 2013 at 4:36 AM, jb wrote: > gmx.com> writes: > > > > > So new flags could be [1]: > > - realloc_flags(p, s, REALLOCF_NO_MOVE) > > ... > > - realloc_flags(p, s, REALLOCF_NO_MOVE | REALLOCF_ELASTIC) > > ... > > For this, there could be a REALLOCF_FORCE flag > > In case of realloc_flags() failing the request, to avoid unnecessary > followups with regular realloc() when desired, we should include an option > like REALLOCF_FALLBACK_ANY that would allow to fallback on the regular > realloc() logic, in one call. > > In addition, because I have an impression that realloc_flags() may have > a future as a replacement for regular realloc() and we should aim for it, > we should include an option like REALLOCF_ANY for that purpose. > > So far, the options could be as follows: > - realloc_flags(p, s, option) > where option is one or a combination (where appropriate) of: > REALLOCF_ANY - default (move or no-move; regular > realloc()) > REALLOCF_NO_MOVE - no-move > REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE > REALLOCF_FORCE - combined with REALLOCF_NO_MOVE > REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its > derivatives like REALLOCF_ELASTIC, etc > just five ? for a (quote) "clean, safe and maintainable API", I'd probably also add a few more, such as REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code, REALLOCF_I_AM_FEELING_LUCKY for the newbies, and REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC for skilled folks. I am not sure they are enough to cover the spectrum of possible options, but there are at least 32 bits in the flags so we have a few more left. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 14:38:50 2013 Return-Path: Delivered-To: freebsd-current@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 09BB5329 for ; Mon, 2 Dec 2013 14:38:50 +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 B42A61877 for ; Mon, 2 Dec 2013 14:38:49 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VnUe3-000476-Ag for freebsd-current@freebsd.org; Mon, 02 Dec 2013 15:38:47 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 15:38:43 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Dec 2013 15:38:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Mon, 2 Dec 2013 14:38:23 +0000 (UTC) Lines: 45 Message-ID: References: <52995C15.7010903@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:38:50 -0000 Luigi Rizzo iet.unipi.it> writes: > ... > > So far, the options could be as follows: > > - realloc_flags(p, s, option) > > where option is one or a combination (where appropriate) of: > > REALLOCF_ANY - default (move or no-move; regular > > realloc()) > > REALLOCF_NO_MOVE - no-move > > REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE > > REALLOCF_FORCE - combined with REALLOCF_NO_MOVE > > REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its > > derivatives like REALLOCF_ELASTIC, etc > > > > just five ? for a (quote) "clean, safe and maintainable API", > I'd probably also add a few more, such as > REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code, > REALLOCF_I_AM_FEELING_LUCKY for the newbies, and > REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC > for skilled folks. > ... These are more or less part of current implementation of realloc() :-) But seriously, the new API takes advantage of current logic - the no-move is already implemented as part of default. It will not (and should not) interfere with current implementation-specific details; it will just be smarter and useful thru its options by asking specific requests, some of which could be already be partially satisified now (think of that extra, unused allocated space, if present), thus giving a programmer more power in one call. Adding some if-else logic and perhaps limited code restructuring will yield a really powerful, functional API. Some of the hidden bugs in current realloc() & co, if any, will be discovered during testing of new implementation (which will be more specific and thus less forgiving). Think of it as being presented with a chance to become part of history, as a co-creator of a new-and-improved memory management function, admittedly being many OS' and libraries' Achilles' heel :-) jb From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 14:40:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86B11636; Mon, 2 Dec 2013 14:40:49 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 583C7195C; Mon, 2 Dec 2013 14:40:49 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so18278225pdj.29 for ; Mon, 02 Dec 2013 06:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=WnDgPFV3OFCkQA8RNFgaXyEaRqNRZc4CRUNkq3RtMHU=; b=f0lIEPCgpXeY+w+dsCMGluT9idouqlHd1SqOYEw/5Wl/3YXA3LxOoWgnlFfglMqV4e QFh3l3TAFeRR02C8+HEWFKXnpy+jsYY4R0MB+ToQevEI06+sVSO5fVfcy4k5rcMQ9rlW VRGfrH56GbkUnMpXLIykgQBSsNaxepg/Ngk6p72fKd4WUjSmidBMthTBwz99XCynDrWz MwhSGCr2woBFq9qpICK5mWXEdPCwIfblD9GQ52+F38CZQhDdmaNuD7O3yChl6xCa+a4a RG7E1BvWiUXfy6ZCVbeupzg5WbwFhqMNudhuPAeeXAgNoSCNmEnb+kn0ib3/e7xvqFIW HyFQ== X-Received: by 10.69.31.65 with SMTP id kk1mr17173611pbd.126.1385995248901; Mon, 02 Dec 2013 06:40:48 -0800 (PST) Received: from zhabar.gateway.2wire.net (76-253-2-5.lightspeed.sntcca.sbcglobal.net. [76.253.2.5]) by mx.google.com with ESMTPSA id sd3sm123041612pbb.42.2013.12.02.06.40.47 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 02 Dec 2013 06:40:48 -0800 (PST) Date: Mon, 2 Dec 2013 06:40:41 -0800 From: Justin Hibbits To: freebsd-current@freebsd.org Subject: Internal compiler error on gcc with latest updates Message-ID: <20131202064041.268a14b1@zhabar.gateway.2wire.net> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; powerpc64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:40:49 -0000 Yesterday I started a full world update for my machine (powerpc64), but the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb. I haven't tried reverting contrib/gcc yet, but is there a good way to debug this? - Justin From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 16:12:05 2013 Return-Path: Delivered-To: freebsd-current@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 C0CAE8D8; Mon, 2 Dec 2013 16:12:05 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3AC4103C; Mon, 2 Dec 2013 16:12:03 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="79756661" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 02 Dec 2013 16:11:51 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Mon, 2 Dec 2013 11:11:51 -0500 Message-ID: <529CB145.6030404@citrix.com> Date: Mon, 2 Dec 2013 17:11:49 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "freebsd-xen@freebsd.org" Subject: Re: FreeBSD PVH guest support References: <526E6807.9030005@citrix.com> <527BD793.8010606@citrix.com> <527E24D8.4010403@citrix.com> <52864749.1020308@citrix.com> <528F9699.4060307@citrix.com> In-Reply-To: <528F9699.4060307@citrix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Cc: emaste@freebsd.org, peter@FreeBSD.org, alc@FreeBSD.org, xen-devel , freebsd-current@freebsd.org, Konstantin Belousov , "Justin T. Gibbs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:12:05 -0000 Hello, I've yet updated the PVH work one more time, regarding some comments from emaste in order to try to make this work easier to merge with the UEFI changes. In this regard, the parse_memmap hook now fetches and parses the memmap, so UEFI can define it's own hook and do the fetching and parsing there. As usual, the patch can be found on my git tree: git://xenbits.xen.org/people/royger/freebsd.git pvh_v6 Or http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v6 I would really like to get this committed sooner rather than later, mainly because I plan to start working on Dom0 soon, and having to carry another patch on top of this is going to be quite hard. Roger. From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 17:11:51 2013 Return-Path: Delivered-To: freebsd-current@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 8E1F8F6E for ; Mon, 2 Dec 2013 17:11:51 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 49E65153B for ; Mon, 2 Dec 2013 17:11:50 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id ED82347EB7 for ; Mon, 2 Dec 2013 17:11:42 +0000 (UTC) Message-ID: <529CBF53.3090400@allanjude.com> Date: Mon, 02 Dec 2013 12:11:47 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: making PANIC_REBOOT_WAIT_TIME a tunable References: <529C4446.6020508@freebsd.org> In-Reply-To: <529C4446.6020508@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hX0KG8A3emQexbr7rROv7EjRmWx3gmNGL" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:11:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hX0KG8A3emQexbr7rROv7EjRmWx3gmNGL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-12-02 03:26, Colin Percival wrote: > Hi all, > > It seems that PANIC_REBOOT_WAIT_TIME has been a compile-time setting fo= rever; > and I can't see any reason for this, but I assume there was one... at s= ome > point in the distant past. > > The attached patch makes it a loader tunable and sysctl. My reason for= wanting > this is to make EC2 images reboot faster after a panic (not that it hap= pens > very often, of course) -- there's no point waiting for a key press at t= he > console because the EC2 console is output-only. > > Any objections? > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" This would be very useful for me as well, we almost always run GENERIC, so being able to set this via loader/sysctl would allow us to make a panic'd box wait a reasonable amount of time for me to view the console. --=20 Allan Jude --hX0KG8A3emQexbr7rROv7EjRmWx3gmNGL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSnL9WAAoJEJrBFpNRJZKfWOgP/305aEt024VAmIdl07QFnFFN lPyKmhg7pGtDWSXtCO0T1jXcyWjHI9pVVXAP1ORx4q5Giu2rRrbNKEgncDPRj4+T LKeg7insxdz0ZMOm+tthJEZnaIfYSV9BpSm/tsndW2xJqVvplOsjjFqYsHX0PQRZ aHd7y/IOpVf4LGqbi86oOTPxuKuvNcT5DkyLUfS80kFAeiI32jf/pSbGgZtaw3an VBlS8n1StFHewVelc2kQHR3PZKVG0aA0iSXOuB8ueFkGaDsqevmWAT/g8zroF8Lr k2okYqW6iARtkOclAZNi3b9/eX5LdUEwFjsApPX0ofS1vjWrHZ/a50OmJZnLwwNR zQR2DJUinqb/HREYYYBoRmMytaz05hJJX4F71y2bihFIk+V/bXq6Vv+HaBzqCoNh jhZBnXlV76gesSZh15WIIQYehlxIxLuzbjsUbBB72Qn7DUNBhU9v3kqVQeYmDjuE fnKAWqZAcqTfwzQQfd4lu1uWcjDBJuwS5LZrjqB7LwD9NVzd9/SLrs9vpUpbcrtr fDcLILYIicbKv3DEdTCHdibc+t8qbDQEaN61iIGgBTMeCtcyb1EpFGn/sl/z3hkL pdLOg5UT1L/jI9OfNphxexznsZlKgl18hz4Ipxwqd1/pU4TqHW4ynC6E8VTQKVS1 oI59P4PRZ6UGk49AOM04 =8jbK -----END PGP SIGNATURE----- --hX0KG8A3emQexbr7rROv7EjRmWx3gmNGL-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 17:19:21 2013 Return-Path: Delivered-To: freebsd-current@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 206DD627; Mon, 2 Dec 2013 17:19:21 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B44A215BF; Mon, 2 Dec 2013 17:19:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rB2HJEOn002802; Mon, 2 Dec 2013 19:19:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rB2HJEOn002802 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rB2HJEvl002801; Mon, 2 Dec 2013 19:19:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Dec 2013 19:19:13 +0200 From: Konstantin Belousov To: Roger Pau Monn? Subject: Re: FreeBSD PVH guest support Message-ID: <20131202171913.GL59496@kib.kiev.ua> References: <526E6807.9030005@citrix.com> <527BD793.8010606@citrix.com> <527E24D8.4010403@citrix.com> <52864749.1020308@citrix.com> <528F9699.4060307@citrix.com> <529CB145.6030404@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2b+TSQxcrVK82xr4" Content-Disposition: inline In-Reply-To: <529CB145.6030404@citrix.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: emaste@freebsd.org, peter@FreeBSD.org, alc@FreeBSD.org, xen-devel , "freebsd-xen@freebsd.org" , freebsd-current@freebsd.org, "Justin T. Gibbs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:19:21 -0000 --2b+TSQxcrVK82xr4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 02, 2013 at 05:11:49PM +0100, Roger Pau Monn? wrote: > Hello, >=20 > I've yet updated the PVH work one more time, regarding some comments > from emaste in order to try to make this work easier to merge with the > UEFI changes. In this regard, the parse_memmap hook now fetches and > parses the memmap, so UEFI can define it's own hook and do the fetching > and parsing there. >=20 > As usual, the patch can be found on my git tree: >=20 > git://xenbits.xen.org/people/royger/freebsd.git pvh_v6 >=20 > Or >=20 > http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Dshortlog= ;h=3Drefs/heads/pvh_v6 >=20 > I would really like to get this committed sooner rather than later, > mainly because I plan to start working on Dom0 soon, and having to carry > another patch on top of this is going to be quite hard. The patch is large, and I definitely do not have desire to look at the Xen-specific parts. Is it possible to split the patch into changes for common code, and the rest ? If not, could you provide only the chunks related to the common code anyway, so that I read what needed to read, and do not miss some part ? --2b+TSQxcrVK82xr4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSnMERAAoJEJDCuSvBvK1BqUQP/0cHpHDot+G4X2cdn+t8tFl/ v0wdKt2z9kQTcWKGFRT5s3khJL9wzemDQnFiYCaXyQ1LP0k/1rveQb5kHeqC50HV 3v8tYsq8IQ5t9TZAsrBb2799Hq7iUT7harQHEX/mPIM9tMLnTmkSkLO9qgK6gQ2V 5z2yrE6vr8lnj1WMQUUrxK2apjFtCLXgDMkeF/F5gXkgiX6eBOqtPEPEhUX2AeAi M1XzLHDXLoHyJmlBOQ0LQ51x4ZFrumjQ+9mcMU8aLXYG2H9AuH04Al9WYddMapo7 s7EE/StmlF6ufWX34sOquEEtwAKFMefC9pCQSfERLR0/zucMeSkOT4LUdjrgD9+H KN4enDxbv1xRkG3A3DqJ+O5WHASmI2zJvQO8W7/jJxzqRX6L26X72+VMWei/RApD luBI0bocOwTffjjrxF95u75HOtMNEHcarbGN4kQqqysRUla4rPhuRnaiGL+lR5uE CzyCVeNeKY4YFLcM7KAhyKvqsayqjsj3JoIAJkgxE0yfCNapdAnTswjqllU8DOik 29cZxE/SIiOTuobylUtj881GVIf43S3nj76l6RSNXTxWdHVDL/okGQVhbPGzL6FN Ku3FHAS0MgVC7/ret8uZFB1IP1c93ejqr4F0M+b9l/MACb7e8f0V6yb1tVXPX1L0 HhrgKlHsFzRk3eQOZFgS =SqUe -----END PGP SIGNATURE----- --2b+TSQxcrVK82xr4-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 17:58:04 2013 Return-Path: Delivered-To: freebsd-current@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 1F907C6B; Mon, 2 Dec 2013 17:58:04 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CEC71880; Mon, 2 Dec 2013 17:58:01 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208";a="77415356" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Dec 2013 17:57:53 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Mon, 2 Dec 2013 12:57:53 -0500 Message-ID: <529CCA1F.302@citrix.com> Date: Mon, 2 Dec 2013 18:57:51 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FreeBSD PVH guest support References: <526E6807.9030005@citrix.com> <527BD793.8010606@citrix.com> <527E24D8.4010403@citrix.com> <52864749.1020308@citrix.com> <528F9699.4060307@citrix.com> <529CB145.6030404@citrix.com> <20131202171913.GL59496@kib.kiev.ua> In-Reply-To: <20131202171913.GL59496@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: emaste@freebsd.org, peter@FreeBSD.org, alc@FreeBSD.org, xen-devel , "freebsd-xen@freebsd.org" , freebsd-current@freebsd.org, "Justin T. Gibbs" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:58:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/13 18:19, Konstantin Belousov wrote: > On Mon, Dec 02, 2013 at 05:11:49PM +0100, Roger Pau Monn? wrote: >> Hello, >> >> I've yet updated the PVH work one more time, regarding some >> comments from emaste in order to try to make this work easier to >> merge with the UEFI changes. In this regard, the parse_memmap >> hook now fetches and parses the memmap, so UEFI can define it's >> own hook and do the fetching and parsing there. >> >> As usual, the patch can be found on my git tree: >> >> git://xenbits.xen.org/people/royger/freebsd.git pvh_v6 >> >> Or >> >> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v6 >> >> >> I would really like to get this committed sooner rather than later, >> mainly because I plan to start working on Dom0 soon, and having >> to carry another patch on top of this is going to be quite hard. > > The patch is large, and I definitely do not have desire to look at > the Xen-specific parts. Is it possible to split the patch into > changes for common code, and the rest ? If not, could you provide > only the chunks related to the common code anyway, so that I read > what needed to read, and do not miss some part ? You can certainly use http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=e6b5f404ea805de4070a9ad501be8e91a722f05b in order to see the specific diffs for each modified file, this way you can only look at changes in common files and skip most of the Xen specific changes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJSnMofAAoJEKXZdqUyumTAzjUH/3fDf9TDgBbKJoOlgPGWhTc3 GDY9Vw2oRzfB7IAyNKGXesE5PPkl4S2A/VVxN/So9Jw1PdGwK/iUGNQIyR5jI5YW BOclDB42huRoHRPYXH/pDrdHpOKrudJg9GeXldT0Q+EXThDMKgTGuAekqdtSN6dS F8YtXMokMrIBkklCzTBsJLAhA8nAZ+CozLuIgHUelkY5XX8Zw7RhrAZNZWy6WZP5 nGgVL6eeJ1mQ6l8JLSwEAvo6mx7ka7HVLmx4IQ1Plm6nx17WLIUdJi9NI6tW7s5v LAD6BH+iPCxDOK6qDCVmSHAZ6RJmI+ksasqIRx4pAe02l806qAUsoXjyzymgn6Y= =ovkV -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 18:26:24 2013 Return-Path: Delivered-To: freebsd-current@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 6905B7FF; Mon, 2 Dec 2013 18:26:24 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D05741A74; Mon, 2 Dec 2013 18:26:23 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id n12so11094472wgh.26 for ; Mon, 02 Dec 2013 10:26:22 -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=DbOzfKCN8mh06sdfHgEcJ4Alj39UOkqtbFOIk3kDogg=; b=Ov0roD4jNUGLkvZW/ObklafM28AQKJ8oCcWLAsMQKEGu7PclVBCV4YUx7PBkzg4XZq mzv0r6u7yzn9JTOwR4jmbIu8Lrwk5CH4cEMwhwsJ4wbt+xwlqK2W3VqtqJ80k0hIj/9Y g25l1NaUWLryGTPxwy9TjVtnOcRdk4CkYQqIB+QuWHZ7Zh3s58HRMbYCPqGYCPR1Xu5I ZSAyTWhY45GXl+e8dMG8htsktzDTZf4UpUjreWxecaMqC9N12v7qbZ3IHFqzDmMh0z7t R/OKxPJ2Pcd/lnqwRAULAL9A/QTZ+ZaoNbGdTsChVmIJLGVkmM46xCO7lb7/pcKaCVRk tqWg== MIME-Version: 1.0 X-Received: by 10.180.211.71 with SMTP id na7mr19643616wic.5.1386008782197; Mon, 02 Dec 2013 10:26:22 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.216.84.208 with HTTP; Mon, 2 Dec 2013 10:26:22 -0800 (PST) In-Reply-To: <20131202064041.268a14b1@zhabar.gateway.2wire.net> References: <20131202064041.268a14b1@zhabar.gateway.2wire.net> Date: Mon, 2 Dec 2013 10:26:22 -0800 X-Google-Sender-Auth: St_PJNKEJ7TahG1mp5KKevxuJ5E Message-ID: Subject: Re: Internal compiler error on gcc with latest updates From: Craig Rodrigues To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current Current , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:26:24 -0000 On Mon, Dec 2, 2013 at 6:40 AM, Justin Hibbits wrote: > Yesterday I started a full world update for my machine (powerpc64), but > the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb. I > haven't tried reverting contrib/gcc yet, but is there a good way to > debug this? > If you are getting the same Internal Compiler Error, it may be worth doing a web search on the GCC web site to see if it is a known issue: https://www.google.com/#q=site:gcc.gnu.org -- Craig From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 18:54:51 2013 Return-Path: Delivered-To: freebsd-current@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 3D5E063F; Mon, 2 Dec 2013 18:54:51 +0000 (UTC) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 711271C46; Mon, 2 Dec 2013 18:54:50 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id e11so5597483bkh.37 for ; Mon, 02 Dec 2013 10:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p9xeoBTm4TSgwTH8tIXQeOHMnta8tVdoZskpPDGtcB8=; b=h8MRjep9LK8r6+u6HVmHcvnpPfqqkVvgfVidAxrTMb45yA1+DqTT4nQg1gq4Ix5cPs wiw7q6QWwQ/GNBLYCfrqhVAezG/szVSWGBJd2KYqGIK3Nnc3o3tPAmTWrSo1nd/7TTeY a3pvbabKuIw39PzCbSKCMntADkZrG1AXXbV2MDfiHNu1orjgRvpY4NRGKlUxXp7uwOb8 EcQUo6c6Raj9E69w4EowQO0IdVTXI2JA6cDjkN19QVaVnEr0AdsZ9R6VQwylR1Ldd5na lI/4phu59zc2AX30DK86G8gmSGN4SHlQgy3ee192GmUnMZ7viXKQuSePepIxBP42jKlT qHWw== MIME-Version: 1.0 X-Received: by 10.204.227.198 with SMTP id jb6mr468256bkb.69.1386010488651; Mon, 02 Dec 2013 10:54:48 -0800 (PST) Received: by 10.205.72.198 with HTTP; Mon, 2 Dec 2013 10:54:48 -0800 (PST) Received: by 10.205.72.198 with HTTP; Mon, 2 Dec 2013 10:54:48 -0800 (PST) In-Reply-To: References: <20131202064041.268a14b1@zhabar.gateway.2wire.net> Date: Mon, 2 Dec 2013 10:54:48 -0800 Message-ID: Subject: Re: Internal compiler error on gcc with latest updates From: Justin Hibbits To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 18:54:51 -0000 On Dec 2, 2013 10:26 AM, "Craig Rodrigues" wrote: > > On Mon, Dec 2, 2013 at 6:40 AM, Justin Hibbits wrote: >> >> Yesterday I started a full world update for my machine (powerpc64), but >> the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb. I >> haven't tried reverting contrib/gcc yet, but is there a good way to >> debug this? > > > If you are getting the same Internal Compiler Error, > it may be worth doing a web search on the GCC web site to see if it is a known issue: > > https://www.google.com/#q=site:gcc.gnu.org > > -- > Craig Good idea. It looks like it is related to GCC bug 48561/21307. -Justin From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 21:41:16 2013 Return-Path: Delivered-To: freebsd-current@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 99EE4AEA; Mon, 2 Dec 2013 21:41:16 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D1961AA9; Mon, 2 Dec 2013 21:41:16 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j5so4920197qaq.7 for ; Mon, 02 Dec 2013 13:41:14 -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=EC57TpugfYxzzijezRYWYhKJlDnMDzob9xIx5rcHmhs=; b=emc8FrTlknWZQkrwuFVDodUQvlkf+wFO+HbO9ZO3Z0V8X6HdP9tFP+4cxTnC7LfM0h 420sOCTDlKA4PcapacIL1YSq0vWQop8bNWo0AhSPq6z/oYCQu/3WUAPUOniJBsc7Gf/q yJL/7HKRqsX+hxUJZPpOb/e22bmjJx0+QGikNWUOXGUkvPxK4xFcnHCGeGnHhRVEWnNF gS/ph5trkDFhP9agRYvENpYjdG5FTj9V/HPqaYAqrz1uBYqkS6p0DiBFYzQUvwN1QrlS DhI54HdejTfLCGTmlSD+yQ43oj3/4v4iSfNCPnx8dspEUgLs3hDCV3bAx/uQacHwK5mH wW6A== MIME-Version: 1.0 X-Received: by 10.49.131.5 with SMTP id oi5mr76884665qeb.38.1386020474382; Mon, 02 Dec 2013 13:41:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Mon, 2 Dec 2013 13:41:14 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Mon, 2 Dec 2013 13:41:14 -0800 X-Google-Sender-Auth: nFocPVewXGPEdhU8tnGKtSD_dUk Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Adrian Chadd To: Sepherosa Ziehau Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 21:41:16 -0000 On 2 December 2013 03:45, Sepherosa Ziehau wrote: > > On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd wrote: > >> Ok, so given this, how do you guarantee the UTHREAD stays on the given >> CPU? You assume it stays on the CPU that the initial listen socket was >> created on, right? If it's migrated to another CPU core then the >> listen queue still stays in the original hash group that's in a netisr >> on a different CPU? > > As I wrote in the above brief introduction, Dfly currently relies on the > scheduler doing the proper thing (the scheduler does do a very good job > during my tests). I need to export certain kind of socket option to make > that information available to user space programs. Force UTHREAD binding in > kernel is not helpful, given in reverse proxy application, things are > different. And even if that kind of binding information was exported to > user space, user space program still would have to poll it periodically (in > Dfly at least), since other programs binding to the same addr/port could > come and go, which will cause reorganizing of the inp localgroup in the > current Dfly implementation. Right. I kinda gathered that. It's fine, I was conceptually thinking of doing some thead pinning into this anyway. How do you see this scaling on massively multi-core machines? Like 32, 48, 64, 128 cores? I had some vague handwav-y notion of maybe limiting the concept of pcbgroup hash / netisr threads to a subset of CPUs, or have them be able to float between sockets but only have 1 (or n, maybe) per socket. Or just have a fixed, smaller pool. The idea then is the scheduler would need to be told that a given userland thread/process belongs to a given netisr thread, and to schedule them on the same CPU when possible. Anyway, thanks for doing this work. I only wish that you'd do it for FreeBSD. :-) -adrian From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 21:56:23 2013 Return-Path: Delivered-To: current@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 3E521EBA; Mon, 2 Dec 2013 21:56:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 026651C8E; Mon, 2 Dec 2013 21:56:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2LuLA9089556; Mon, 2 Dec 2013 16:56:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2LuLcA089552; Mon, 2 Dec 2013 21:56:21 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 21:56:21 GMT Message-Id: <201312022156.rB2LuLcA089552@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 21:56:23 -0000 TB --- 2013-12-02 18:36:42 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 18:36:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 18:36:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-12-02 18:36:42 - cleaning the object tree TB --- 2013-12-02 18:36:52 - /usr/local/bin/svn stat /src TB --- 2013-12-02 18:37:00 - At svn revision 258843 TB --- 2013-12-02 18:37:01 - building world TB --- 2013-12-02 18:37:01 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 18:37:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 18:37:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 18:37:01 - SRCCONF=/dev/null TB --- 2013-12-02 18:37:01 - TARGET=powerpc TB --- 2013-12-02 18:37:01 - TARGET_ARCH=powerpc TB --- 2013-12-02 18:37:01 - TZ=UTC TB --- 2013-12-02 18:37:01 - __MAKE_CONF=/dev/null TB --- 2013-12-02 18:37:01 - cd /src TB --- 2013-12-02 18:37:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 18:37:08 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Dec 2 21:13:54 UTC 2013 TB --- 2013-12-02 21:13:54 - generating LINT kernel config TB --- 2013-12-02 21:13:54 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:13:54 - /usr/bin/make -B LINT TB --- 2013-12-02 21:13:54 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:13:54 - /usr/sbin/config -m LINT TB --- 2013-12-02 21:13:54 - building LINT kernel TB --- 2013-12-02 21:13:54 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 21:13:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 21:13:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 21:13:54 - SRCCONF=/dev/null TB --- 2013-12-02 21:13:54 - TARGET=powerpc TB --- 2013-12-02 21:13:54 - TARGET_ARCH=powerpc TB --- 2013-12-02 21:13:54 - TZ=UTC TB --- 2013-12-02 21:13:54 - __MAKE_CONF=/dev/null TB --- 2013-12-02 21:13:54 - cd /src TB --- 2013-12-02 21:13:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 2 21:13:54 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Dec 2 21:33:15 UTC 2013 TB --- 2013-12-02 21:33:15 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:33:15 - /usr/sbin/config -m GENERIC TB --- 2013-12-02 21:33:15 - building GENERIC kernel TB --- 2013-12-02 21:33:15 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 21:33:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 21:33:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 21:33:15 - SRCCONF=/dev/null TB --- 2013-12-02 21:33:15 - TARGET=powerpc TB --- 2013-12-02 21:33:15 - TARGET_ARCH=powerpc TB --- 2013-12-02 21:33:15 - TZ=UTC TB --- 2013-12-02 21:33:15 - __MAKE_CONF=/dev/null TB --- 2013-12-02 21:33:15 - cd /src TB --- 2013-12-02 21:33:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Dec 2 21:33:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Dec 2 21:49:10 UTC 2013 TB --- 2013-12-02 21:49:10 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:49:10 - /usr/sbin/config -m GENERIC64 TB --- 2013-12-02 21:49:10 - skipping GENERIC64 kernel TB --- 2013-12-02 21:49:10 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:49:10 - /usr/sbin/config -m MPC85XX TB --- 2013-12-02 21:49:10 - building MPC85XX kernel TB --- 2013-12-02 21:49:10 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 21:49:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 21:49:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 21:49:10 - SRCCONF=/dev/null TB --- 2013-12-02 21:49:10 - TARGET=powerpc TB --- 2013-12-02 21:49:10 - TARGET_ARCH=powerpc TB --- 2013-12-02 21:49:10 - TZ=UTC TB --- 2013-12-02 21:49:10 - __MAKE_CONF=/dev/null TB --- 2013-12-02 21:49:10 - cd /src TB --- 2013-12-02 21:49:10 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Mon Dec 2 21:49:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for MPC85XX completed on Mon Dec 2 21:52:05 UTC 2013 TB --- 2013-12-02 21:52:05 - cd /src/sys/powerpc/conf TB --- 2013-12-02 21:52:05 - /usr/sbin/config -m WII TB --- 2013-12-02 21:52:05 - building WII kernel TB --- 2013-12-02 21:52:05 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 21:52:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 21:52:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 21:52:05 - SRCCONF=/dev/null TB --- 2013-12-02 21:52:05 - TARGET=powerpc TB --- 2013-12-02 21:52:05 - TARGET_ARCH=powerpc TB --- 2013-12-02 21:52:05 - TZ=UTC TB --- 2013-12-02 21:52:05 - __MAKE_CONF=/dev/null TB --- 2013-12-02 21:52:05 - cd /src TB --- 2013-12-02 21:52:05 - /usr/bin/make -B buildkernel KERNCONF=WII >>> Kernel build for WII started on Mon Dec 2 21:52:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/powerpc/vm_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/wii/platform_wii.c /src/sys/powerpc/wii/platform_wii.c: In function 'wii_mem_regions': /src/sys/powerpc/wii/platform_wii.c:139: error: 'avail' undeclared (first use in this function) /src/sys/powerpc/wii/platform_wii.c:139: error: (Each undeclared identifier is reported only once /src/sys/powerpc/wii/platform_wii.c:139: error: for each function it appears in.) /src/sys/powerpc/wii/platform_wii.c:139: error: expected ')' before ';' token /src/sys/powerpc/wii/platform_wii.c:141: error: expected ';' before '}' token *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/WII *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 21:56:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 21:56:21 - ERROR: failed to build WII kernel TB --- 2013-12-02 21:56:21 - 10309.27 user 1329.50 system 11979.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Dec 2 23:20:34 2013 Return-Path: Delivered-To: current@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 16518994; Mon, 2 Dec 2013 23:20:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E087913C5; Mon, 2 Dec 2013 23:20:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB2NKWFc080547; Mon, 2 Dec 2013 18:20:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB2NKWMM080546; Mon, 2 Dec 2013 23:20:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 2 Dec 2013 23:20:32 GMT Message-Id: <201312022320.rB2NKWMM080546@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:20:34 -0000 TB --- 2013-12-02 22:40:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-02 22:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-02 22:40:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-12-02 22:40:17 - cleaning the object tree TB --- 2013-12-02 22:40:17 - /usr/local/bin/svn stat /src TB --- 2013-12-02 22:40:22 - At svn revision 258858 TB --- 2013-12-02 22:40:23 - building world TB --- 2013-12-02 22:40:23 - CROSS_BUILD_TESTING=YES TB --- 2013-12-02 22:40:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-02 22:40:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-02 22:40:23 - SRCCONF=/dev/null TB --- 2013-12-02 22:40:23 - TARGET=arm TB --- 2013-12-02 22:40:23 - TARGET_ARCH=arm TB --- 2013-12-02 22:40:23 - TZ=UTC TB --- 2013-12-02 22:40:23 - __MAKE_CONF=/dev/null TB --- 2013-12-02 22:40:23 - cd /src TB --- 2013-12-02 22:40:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 2 22:40:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] ===> lib/clang/libllvmasmparser (all) c++ -O2 -pipe -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser -I. -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser/LLLexer.cpp -o LLLexer.o c++ -O2 -pipe -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/include -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser -I. -I/src/lib/clang/libllvmasmparser/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser/LLParser.cpp -o LLParser.o /src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool)': /src/lib/clang/libllvmasmparser/../../../contrib/llvm/lib/AsmParser/LLParser.cpp:2916: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmasmparser *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-02 23:20:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-02 23:20:32 - ERROR: failed to build world TB --- 2013-12-02 23:20:32 - 2161.48 user 203.99 system 2414.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 08:31:22 2013 Return-Path: Delivered-To: freebsd-current@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 7C6E61B1 for ; Tue, 3 Dec 2013 08:31:22 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 338D81F91 for ; Tue, 3 Dec 2013 08:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:Message-Id:To:Subject:From:Date; bh=eCs4Bqqlq4iVv5dAOX1nbMNFT1ecNguaVemhiXKf8YA=; b=KzYu6qy/L/6hggQjBJ7OQlNpY+mKOD3MACjVqul/dWF1MZGSKT+efIppOo8dJ1vLWy1K8MESXVFIdjT3OZkOBQsztT6s4Ep6a/HOIqUEtgEDEC/b2aesEIxctmvVoyz5S8ZU/356Dnnym54UiQz8n9l8LeXKV670kSvizClnME8=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv199.fwdcdn.com with smtp ID 1VnlNv-000JJi-Qk for freebsd-current@freebsd.org; Tue, 03 Dec 2013 10:31:11 +0200 Date: Tue, 03 Dec 2013 10:31:11 +0200 From: Vladimir Sharun Subject: pf reply-to malfunction after r258468 (seems r258479) To: freebsd-current Current X-Mailer: mail.ukr.net 5.0 Message-Id: <1386059471.355638511.emzdei8w@frv45.ukr.net> Received: from atz@ukr.net by frv45.ukr.net; Tue, 03 Dec 2013 10:31:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:31:22 -0000 I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 443 And it works at least in r258468. After harware change/reboot yesterday I got strange performance via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing shows packet duplication from reply-to, looks like that: 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.577583 IP Testbed.4 3775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 10:31:03 2013 Return-Path: Delivered-To: freebsd-current@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 B3380FCD for ; Tue, 3 Dec 2013 10:31:03 +0000 (UTC) Received: from frv189.fwdcdn.com (frv189.fwdcdn.com [212.42.77.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68CA21714 for ; Tue, 3 Dec 2013 10:31:03 +0000 (UTC) Received: from [10.10.1.29] (helo=frv197.fwdcdn.com) by frv189.fwdcdn.com with esmtp ID 1Vnmej-000M8o-RP for freebsd-current@freebsd.org; Tue, 03 Dec 2013 11:52:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:Message-Id:To:Subject:From:Date; bh=M8C8GscTW8DjAiVS52mR8TTI1fEjaQlyi4f4W28JGeA=; b=hoBVuMiAZELFAOzgI/vzJ4ZEfY8Sm1Y61UUEH1/lGbit7tUQ3sYxWkHl1r0ezJMjqcjYvQ9DPuG80FpPijiYjMJ8+8tjCClrF9P+frM3D3iIksPm6W68HjJZ1QyDkP3PNqtKBrckPvOWs/3Mmnv98qDrGHAfxAWLNxktxVULN2w=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv197.fwdcdn.com with smtp ID 1VnmeY-000BIJ-V7 for freebsd-current@freebsd.org; Tue, 03 Dec 2013 11:52:26 +0200 Date: Tue, 03 Dec 2013 11:52:26 +0200 From: Vladimir Sharun Subject: pf reply-to malfunction after r258468 (seems r258479) To: freebsd-current Current X-Mailer: mail.ukr.net 5.0 Message-Id: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> Received: from atz@ukr.net by frv45.ukr.net; Tue, 03 Dec 2013 11:52:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:31:03 -0000 I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 443 And it works at least in r258468. After harware change/reboot yesterday I got strange performance via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing shows packet duplication from reply-to, looks like that: 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 09:36:59.577583 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 11:59:02 2013 Return-Path: Delivered-To: freebsd-current@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 72B41A75 for ; Tue, 3 Dec 2013 11:59:02 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 EEB471DAA for ; Tue, 3 Dec 2013 11:59:01 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB3BwxmJ062588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2013 15:58:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB3BwxMO062587; Tue, 3 Dec 2013 15:58:59 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 3 Dec 2013 15:58:59 +0400 From: Gleb Smirnoff To: Vladimir Sharun Subject: Re: pf reply-to malfunction after r258468 (seems r258479) Message-ID: <20131203115859.GU48919@FreeBSD.org> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:59:02 -0000 Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V> I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V> I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V> it came via tunnel: V> V> pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V> proto tcp from any to Real_IP_B port 443 V> V> And it works at least in r258468. After harware change/reboot yesterday I got strange performance V> via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V> saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V> shows packet duplication from reply-to, looks like that: V> 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.577583 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V> 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 12:09:21 2013 Return-Path: Delivered-To: freebsd-current@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 696A6C98 for ; Tue, 3 Dec 2013 12:09:21 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB191E3D for ; Tue, 3 Dec 2013 12:09:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=5UHxleY0zyBLulNUHA4SMZ9rSEnQG85QlVU3hXm9ZrM=; b=Iywm7lbHYmW8W5X+LBul3mhAhfUMvgz6/4PJHJe9WEwahxYxmOZg8brbOI+vih4o06+temRhUc5IeWaTNAvQvYNc7I+RgdyAoOKYi2zEOQ+kQgdSAriUft41oIn0AfHZhaAaMkV5HRVScRl+svutkeZ7+7b/B6+mmPHIi8XCgog=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv199.fwdcdn.com with smtp ID 1Vnomx-00063D-Oo for freebsd-current@freebsd.org; Tue, 03 Dec 2013 14:09:15 +0200 Date: Tue, 03 Dec 2013 14:09:14 +0200 From: Vladimir Sharun Subject: Re[2]: pf reply-to malfunction after r258468 (seems r258479) To: Gleb Smirnoff X-Mailer: mail.ukr.net 5.0 Message-Id: <1386072554.761553777.docrlaks@frv45.ukr.net> In-Reply-To: <20131203115859.GU48919@FreeBSD.org> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> Received: from atz@ukr.net by frv45.ukr.net; Tue, 03 Dec 2013 14:09:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 12:09:21 -0000 Dear Gleb, Is kernel rebuilding enuff ? Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V> I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V> I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V> it came via tunnel: V> V> pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V> proto tcp from any to Real_IP_B port 443 V> V> And it works at least in r258468. After harware change/reboot yesterday I got strange performance V> via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V> saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V> shows packet duplication from reply-to, looks like that: V> 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.577583 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V> 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 12:11:58 2013 Return-Path: Delivered-To: freebsd-current@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 5CC97DE2 for ; Tue, 3 Dec 2013 12:11:58 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 BCB7D1E88 for ; Tue, 3 Dec 2013 12:11:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB3CBtLP062678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2013 16:11:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB3CBtqs062677; Tue, 3 Dec 2013 16:11:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 3 Dec 2013 16:11:55 +0400 From: Gleb Smirnoff To: Vladimir Sharun Subject: Re: pf reply-to malfunction after r258468 (seems r258479) Message-ID: <20131203121155.GV48919@glebius.int.ru> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> <1386072554.761553777.docrlaks@frv45.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1386072554.761553777.docrlaks@frv45.ukr.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 12:11:58 -0000 On Tue, Dec 03, 2013 at 02:09:14PM +0200, Vladimir Sharun wrote: V> Dear Gleb, V> Is kernel rebuilding enuff ? Should be enough wrt pf(4), no API or ABI changes in it. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 16:17:21 2013 Return-Path: Delivered-To: freebsd-current@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 7870EA10; Tue, 3 Dec 2013 16:17:21 +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 4AC441F1E; Tue, 3 Dec 2013 16:17:21 +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 671AE1A499; Tue, 3 Dec 2013 16:17:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 671AE1A499 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 3 Dec 2013 11:17:11 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: FreeBSD 10.0-BETA4 now available Message-ID: <20131203161711.GO85910@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5G50dybFf3pRZKd7" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 16:17:21 -0000 --5G50dybFf3pRZKd7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The fourth BETA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. This is expected to be the final BETA build of the 10.0-RELEASE cycle. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. Important note to freebsd-update(8) users: Please be sure to follow the instructions in the following FreeBSD Errata Notices before upgrading the system to 10.0-BETA4: - EN-13:04.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc - EN-13:05.freebsd-update: http://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc Pre-installed virtual machine images for 10.0-BETA4 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA4/ The disk images are available in both QCOW2, VHD, and VMDK format. The image download size is approximately 135 MB, which decompress to a 20GB sparse image. The partition layout is: - 512k - freebsd-boot GPT partition type (bootfs GPT label) - 1GB - freebsd-swap GPT partition type (swapfs GPT label) - ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Changes between -BETA3 and -BETA4 include: - Add preliminary support for RTL8106E, RTL8168G, RTL8168GU, RTL8411B, and RTL8168EP. - Enable fingerprint checking in pkg(8) for FreeBSD-provided binary packages. - Remove the WITH_LIBICONV_COMPAT build option. - Update nvi to 2.1.2. - Various iconv(3) fixes. - Fix mergemaster -U by forcing FreeBSD 9 compatiblity in mtree when mtree is nmtree. - Fix to freebsd-update(8) in generating the list of old files/directories versus new files/directories (FreeBSD-EN-13:05.freebsd-update). == ISO CHECKSUMS == - 10.0-BETA4 amd64: SHA256 (FreeBSD-10.0-BETA4-amd64-bootonly.iso) = f113db8d210d831316c9f41a127781dd28ce782fa8de528cff47f09799fc8f9c SHA256 (FreeBSD-10.0-BETA4-amd64-disc1.iso) = bc85096a98fa261070ae7362225a5b7d63b60bc28525aba0c226917924c5a7ee SHA256 (FreeBSD-10.0-BETA4-amd64-memstick.img) = 4a1b9e0cce18afa2425c1cad685a3462f1a6d1db4e870bb9dd888ad5a4f6d1f5 MD5 (FreeBSD-10.0-BETA4-amd64-bootonly.iso) = 76d1ec5fd97f57c92b2c9dfdf512c388 MD5 (FreeBSD-10.0-BETA4-amd64-disc1.iso) = a3ce29e45a8d718fce09746c6552a45e MD5 (FreeBSD-10.0-BETA4-amd64-memstick.img) = 20e84a31c19697fbc0e46ee34182c4b8 - 10.0-BETA4 i386: SHA256 (FreeBSD-10.0-BETA4-i386-bootonly.iso) = bde072404dd82180a36fea909c10cfff7d1b0361622ae4ecfaf6b5bb07df6670 SHA256 (FreeBSD-10.0-BETA4-i386-disc1.iso) = 9a116fdbe192165c8af985357a07ce7727344f0e93b299900bfcf0fd4bb5bbbd SHA256 (FreeBSD-10.0-BETA4-i386-memstick.img) = 8bd1388553fe0892289e71077973706f55b24c6d0dc111bc502ae24ba44b4588 MD5 (FreeBSD-10.0-BETA4-i386-bootonly.iso) = 4eb173e2ae1da706b2ecb9bc56ba6433 MD5 (FreeBSD-10.0-BETA4-i386-disc1.iso) = 8b5646852ed99644d1cf97ca799188d1 MD5 (FreeBSD-10.0-BETA4-i386-memstick.img) = 9d5911b02554c8984341ea646d8dedfc - 10.0-BETA4 ia64: SHA256 (FreeBSD-10.0-BETA4-ia64-bootonly.iso) = 03ef03299a5717249b67b40b674ad8db139cd8e42839d01c8765a9ec7d04747f SHA256 (FreeBSD-10.0-BETA4-ia64-disc1.iso) = a70ea04f8a56bc6ca40f00b7ede052f3530b16b73a0fcf97ea8d090996f18ff2 SHA256 (FreeBSD-10.0-BETA4-ia64-memstick.img) = cd1de945be58d2410626bdfb0e3c6f5ad195a116b6602f35c606bb9959ec603e MD5 (FreeBSD-10.0-BETA4-ia64-bootonly.iso) = beb2710699be82f7a80df8d27ba876cf MD5 (FreeBSD-10.0-BETA4-ia64-disc1.iso) = 7bb09d29ba0dcb5cc13b9fd994ed2c74 MD5 (FreeBSD-10.0-BETA4-ia64-memstick.img) = 3bb46b075acba974b8c01e95662d3b56 - 10.0-BETA4 powerpc: SHA256 (FreeBSD-10.0-BETA4-powerpc-bootonly.iso) = 58bf6c38fe1a8c0e07d1f3b2a98dc82c70357d89cb0377e82ca845815752e7b3 SHA256 (FreeBSD-10.0-BETA4-powerpc-disc1.iso) = b3c6f64ea5cc61608fdefd9c642399808e8a00c95119f4b623a6cd0ec2163f3f SHA256 (FreeBSD-10.0-BETA4-powerpc-memstick.img) = 1d01fe35eb0b647673fefc1efa76b9eb6c9ea6c96ee76db8c83a08a6922659a1 MD5 (FreeBSD-10.0-BETA4-powerpc-bootonly.iso) = ae55f9dc30d8b4e86436efc11dc03b80 MD5 (FreeBSD-10.0-BETA4-powerpc-disc1.iso) = f97d8475440dea2204ef49a48dd04e3c MD5 (FreeBSD-10.0-BETA4-powerpc-memstick.img) = f7b146dd9edd2c59f566ee98630cfbb1 - 10.0-BETA4 powerpc64: SHA256 (FreeBSD-10.0-BETA4-powerpc-powerpc64-bootonly.iso) = 80837ec6c273f7c3d921297dccecc950962f196090c8dc11a5821f115efa5aa3 SHA256 (FreeBSD-10.0-BETA4-powerpc-powerpc64-disc1.iso) = 9657b983c7aa21812e49349733f3d383374a10250fdf558dce8126783e55c5b2 SHA256 (FreeBSD-10.0-BETA4-powerpc-powerpc64-memstick.img) = 0641efb6c8f919fceea8b0f6fd7bf5289ab734fd154c8e01df89dd2188b93419 MD5 (FreeBSD-10.0-BETA4-powerpc-powerpc64-bootonly.iso) = 357fb9d0d9e8fb8e9d7c6e6a6b20ba82 MD5 (FreeBSD-10.0-BETA4-powerpc-powerpc64-disc1.iso) = 28251d4dee87358e90b252b9ba940bc1 MD5 (FreeBSD-10.0-BETA4-powerpc-powerpc64-memstick.img) = ee24af1430c64863b64608639f14f8c1 - 10.0-BETA4 sparc64: SHA256 (FreeBSD-10.0-BETA4-sparc64-bootonly.iso) = fa2096f76ecd3a1580bfd858a8f7cd5bdbd817c58a7a5b047266aa0bcfeef1d5 SHA256 (FreeBSD-10.0-BETA4-sparc64-disc1.iso) = ac93329a5ee6dcfe0c3c378d0b78a52cbdf1b7038402f04c867d7542610de521 MD5 (FreeBSD-10.0-BETA4-sparc64-bootonly.iso) = 994608dab6fa79503bb317279bdd3371 MD5 (FreeBSD-10.0-BETA4-sparc64-disc1.iso) = b36dcfdc042c403473106c34a8d17bcd == VM IMAGE CHECKSUMS == - 10.0-BETA4 amd64: SHA256 (FreeBSD-10.0-BETA4-amd64.qcow2.xz) = c1795690cc75ea33d446e534055a32943cf81659eb31f634a58500c94a99f8a7 SHA256 (FreeBSD-10.0-BETA4-amd64.vhd.xz) = d47066331040a637cef3cddea8cd21bbd019d4a8e45fb0fe75e9e1ed2cd4324f SHA256 (FreeBSD-10.0-BETA4-amd64.vmdk.xz) = 6a87ecfb7c8f405476494bbdd2240de37d1fc474c3a92d1cf74fd526ffbe318d MD5 (FreeBSD-10.0-BETA4-amd64.qcow2.xz) = 8e9aaff6c503c8a4ac508ede6eb83659 MD5 (FreeBSD-10.0-BETA4-amd64.vhd.xz) = 5c984baaef25e2e1289621a5c98d2d52 MD5 (FreeBSD-10.0-BETA4-amd64.vmdk.xz) = a7128f0e640f020ccc8d510a0d94fa8d - 10.0-BETA4 i386: SHA256 (FreeBSD-10.0-BETA4-i386.qcow2.xz) = 8b8aebc4fb00e0cb1739af719b8e29904111ac5b2ee34f2a4ee22eb82db42a3d SHA256 (FreeBSD-10.0-BETA4-i386.vhd.xz) = 4102ac5ce2d25b8da78d6e63e252a6f6860ef29e112244e112b8a43e69d7811f SHA256 (FreeBSD-10.0-BETA4-i386.vmdk.xz) = 8a8c939cbc78deffc2cba8394e9094c747441d8419330e47025fc5c4ab3f7bac MD5 (FreeBSD-10.0-BETA4-i386.qcow2.xz) = 34db292de5113f2805e8adaad1bd5869 MD5 (FreeBSD-10.0-BETA4-i386.vhd.xz) = f0776abb8286e3cb93bd947a62af561e MD5 (FreeBSD-10.0-BETA4-i386.vmdk.xz) = 727d837f99db432d6c91ee185d98cbd3 Glen --5G50dybFf3pRZKd7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSngQHAAoJELls3eqvi17Q5P0QAIUmjL8hcAjEiXuN2SkDjKdt NIcyj0Q2t438+OxR6FhW2jSc1nDl+1NFsGDYBNFZlh3lHrEYL6INaUF057Lr5+uQ MQxtAmswY92KchIDapIUqiJeZsSQzT0Zct8grFd78lLh1C2MaEYUwYDH/JVxItex jAeX2A0gGflylRDtSWWf03uxPommLtkAmiFCSV/ro710wOlpG6ayqJd0q44hKJXA U8+hw67uqM4GBgjxhL4BGHgP5audZZpjjhHb7KGrLl0NXoypHUO52qYWDfbVUNyG PDD9BtH1/CC3BWC5oliYIQgafr8LhITK02sc0WjFQOWqxqXmfU3rW5PIZmCxEMx2 rvZSHskMPnQX4TrHf9EjQmyTly0fv9yb1z0OudRZxaY3cOH82xpeqJ53yaPHCkLf 1wLd+osWr50VDJ5JIZRutV1WMEqpicPQZ6XxpEfkYasabHaTk+PlzQ5scza7Bchp efNIgPSZXVPpkqM+Moj+TXnVCTYBVbNvAAr8Wl2MgtgbLW94XA2jkf9U8PyJLhhr a+LW5xh87kxll/5Ep8Z50mieOK3A2lf/f7gM6BUvjDq7mC1rh+xg3id05Ow6NI6d iFZ5lkeFuJCGpZVVS4tvDdmNA6JbuURxA1HuxegxrJUXnMocmpkyP8Wmik0e1h8v cdnINp9rM7ivxwmazd/Z =5PPP -----END PGP SIGNATURE----- --5G50dybFf3pRZKd7-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 17:54:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B1DD9CD for ; Tue, 3 Dec 2013 17:54:16 +0000 (UTC) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDE9715A4 for ; Tue, 3 Dec 2013 17:54:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=hSVzEmtD/Ee6bJ+eAvdTM3gvZBDZDdPTlc8aBdwTy5Q=; b=gF6UhrT8BmY7ndV2GZXyH1oAkyP6eCYRZ70lijWNZq/uqKZM6XMI6B/CP7b7XnXnKwyNjHOgBaQVcdQwqlwlngTm42kw5eCdoHnIs9GN9wtqsPuCwXpDtXtrZ4V5Ap/UgE8H0q2tu5jqzSjzGrStY8tGBH9nF6qpGp9jFq+Lfkc=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv196.fwdcdn.com with smtp ID 1VnuAi-000I59-P8 for freebsd-current@freebsd.org; Tue, 03 Dec 2013 19:54:08 +0200 Date: Tue, 03 Dec 2013 19:54:08 +0200 From: Vladimir Sharun Subject: Re[2]: pf reply-to malfunction after r258468 (seems r258479) To: Gleb Smirnoff X-Mailer: mail.ukr.net 5.0 Message-Id: <1386093248.507170714.54to5ae0@frv45.ukr.net> In-Reply-To: <20131203115859.GU48919@FreeBSD.org> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> Received: from atz@ukr.net by frv45.ukr.net; Tue, 03 Dec 2013 19:54:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:54:16 -0000 Dear Gleb, Unfortunately can't boot both revisions kernel, it hangs on "trying to mount root from ssdzfs"  (which is my zfs root). Vladimir, On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote: V> I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. V> I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if V> it came via tunnel: V> V> pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ V> proto tcp from any to Real_IP_B port 443 V> V> And it works at least in r258468. After harware change/reboot yesterday I got strange performance V> via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can V> saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing V> shows packet duplication from reply-to, looks like that: V> 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 V> 09:36:59.577583 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 V> 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 I doubt that r258479 can cause a regression in reply-to. Can you please test r258478 and r258479 and confirm or decline that? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 18:40:38 2013 Return-Path: Delivered-To: freebsd-current@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 EF08DF73 for ; Tue, 3 Dec 2013 18:40:38 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 6553B18A5 for ; Tue, 3 Dec 2013 18:40:37 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB3IE0r5064408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Dec 2013 22:14:00 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB3IE01n064407; Tue, 3 Dec 2013 22:14:00 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 3 Dec 2013 22:14:00 +0400 From: Gleb Smirnoff To: Vladimir Sharun Subject: Re: pf reply-to malfunction after r258468 (seems r258479) Message-ID: <20131203181400.GA48919@glebius.int.ru> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> <1386093248.507170714.54to5ae0@frv45.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1386093248.507170714.54to5ae0@frv45.ukr.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:40:39 -0000 On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V> Dear Gleb, V> Unfortunately can't boot both revisions kernel, it hangs on "trying to mount root from ssdzfs"  (which is my zfs root). V> Vladimir, You can run the kernel that boots, but update only sys/netpfil/pf directory to suspected revision(s), if you think this is related to changes in pf. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 19:28:46 2013 Return-Path: Delivered-To: freebsd-current@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 3937ED64; Tue, 3 Dec 2013 19:28:46 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF7F1C82; Tue, 3 Dec 2013 19:28:45 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id u57so8318659wes.4 for ; Tue, 03 Dec 2013 11:28:43 -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=nqLwdcbJQ4LN19xi6HJshTyIz98m/TrCdUQHV/kpMSY=; b=nHsTVrvFmCfwFFX2j/U1MozLIiWuQPJh0rnbkYe6Y1ITBhTu16JFD7i4nGdLfQ6wX/ YgRbLtA6TiQL3X2FjSS9YCptA3QlKwzrgRLcKj2IEV6oau6ZKITC2Y1aNYnJHv47ul5I x54qzy9Yl42ffxZ+WGKGBIwscxu+kArb70ONhtF+GgEpoUda6fh1PgCqOg8vKJmkv/pR 4CkYrVXa7EpaHVx/8oy7RYKaWTabGxhSzxcMPplo/AyqUJI6xaiqGslSIynQSN9iz/DT mW965RaPk6GUDyrOsZKmpeXenTHI6VhWJyOO7+fFfB4DF01kiCPff4lYY3welw5EPxsP DX1w== MIME-Version: 1.0 X-Received: by 10.180.205.138 with SMTP id lg10mr2773995wic.30.1386098923678; Tue, 03 Dec 2013 11:28:43 -0800 (PST) Sender: antoine.brodin.freebsd@gmail.com Received: by 10.194.64.199 with HTTP; Tue, 3 Dec 2013 11:28:43 -0800 (PST) In-Reply-To: <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> Date: Tue, 3 Dec 2013 20:28:43 +0100 X-Google-Sender-Auth: dOv4nzuuGD3OzdcTpt3LGdoswOE Message-ID: Subject: Re: libc++ vs. libstdc++ usage in the ports tree From: Antoine Brodin To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 Cc: Jan Henrik Sylvester , Baptiste Daroussin , stephen@freebsd.org, Maho Nakata , FreeBSD Current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:28:46 -0000 On Sun, Dec 1, 2013 at 3:06 PM, Tijl Coosemans wrote: > On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: >> On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: >>> Trying to migrate to 10, I would like to keep octave. Have you found >>> anything new? Having build the port and all dependencies with standard >>> options, octave is segfaulting for me, too. Anyhow, I can run octave with: >>> >>> env LD_PRELOAD=/usr/lib/libc++.so.1 octave >>> >>> Some very light testing indicates that it is working. Of course, this is >>> not ideal. >>> >>> Maybe this gives a clue how to fix the octave port properly. >> >> I have a preliminary patch for math/octave that I wanted to test on >> redports first, but it is down at the moment so here it is. > > The tests were successful: > https://redports.org/buildarchive/20131201105316-94935/ (octave) > https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) > The octave logs also contain the results of running the regression-test > target. The output is the same on all FreeBSD versions. > > The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means > the C++ code in math/octave is compiled with gcc46/libstdc++ which > does not work if dependencies have been built with clang/libc++. > > The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a > new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler > together with the base system C/C++ compiler. This is nice! Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 20:26:27 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6FFED6; Tue, 3 Dec 2013 20:26:27 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76435101D; Tue, 3 Dec 2013 20:26:22 +0000 (UTC) Received: from nb981.math (p57AEF3E3.dip0.t-ipconnect.de [87.174.243.227]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LzpYp-1Vacga2v4d-014Mve; Tue, 03 Dec 2013 21:26:20 +0100 Message-ID: <529E3E6A.2090107@janh.de> Date: Tue, 03 Dec 2013 21:26:18 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: libc++ vs. libstdc++ usage in the ports tree References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> In-Reply-To: <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> Content-Type: multipart/mixed; boundary="------------000205000607070909000901" X-Provags-ID: V02:K0:UcHOv1Mr/8HdS2aZ7Pm8GbrxIIwnx32MCcbcyztvwXg t6V44LV3kCS/tfsU6V27lTfDWmrY1LBElCQAlO1VKH7vzEja5/ qwyGCTsy/vL8rfehfnnXxvZ4Q3h2Xp2Y+cvtwXpR6Nz2e/RnZ0 UTut1+fPKwfHAppKc70kKBs7Mmhz5t8ChFdLiktn7JbTA78REF 1Vu6FNUruutckthztffbcMv72DcGNPCuSZz4ptXTmpHDpPF7G/ FvL1aPby7BLA1arQG4xAZI54u7EXbqrkyHcKvebzt0/WzOHoB5 WocW/Npo9m7iLuu9MyxpAIL3dTcfhZZ08/QfCJ5cQRnhCn6Wg= = X-Mailman-Approved-At: Tue, 03 Dec 2013 20:54:49 +0000 Cc: Maho Nakata , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:26:28 -0000 This is a multi-part message in MIME format. --------------000205000607070909000901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/01/2013 15:06, Tijl Coosemans wrote: > On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: >> On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: >>> Trying to migrate to 10, I would like to keep octave. Have you found >>> anything new? Having build the port and all dependencies with standard >>> options, octave is segfaulting for me, too. Anyhow, I can run octave with: >>> >>> env LD_PRELOAD=/usr/lib/libc++.so.1 octave >>> >>> Some very light testing indicates that it is working. Of course, this is >>> not ideal. >>> >>> Maybe this gives a clue how to fix the octave port properly. >> >> I have a preliminary patch for math/octave that I wanted to test on >> redports first, but it is down at the moment so here it is. > > The tests were successful: > https://redports.org/buildarchive/20131201105316-94935/ (octave) > https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) > The octave logs also contain the results of running the regression-test > target. The output is the same on all FreeBSD versions. > > The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means > the C++ code in math/octave is compiled with gcc46/libstdc++ which > does not work if dependencies have been built with clang/libc++. > > The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a > new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler > together with the base system C/C++ compiler. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Cheers, Jan Henrik --------------000205000607070909000901 Content-Type: application/octet-stream; name="octave-3.6.4_7-fortran_patch-9.2-RELEASE-amd64.log.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="octave-3.6.4_7-fortran_patch-9.2-RELEASE-amd64.log.xz" /Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4Jn9Fy9dAB7oC4QaCGYOTmuKhGENhSsemLEGec41 p4xrA3fQN4iebhUzcWkRXuu+Kc42epDPQKWi4LJI48bJ7JbbIN5b49xA5al00l85q/Vynpb2 PaW8lYavsjdhZOzEQusuOk7Awnx042flp3yrsosvSzxSjdErYFCHkYAgWZzmtLcf8CG51ow+ hsq/bRCnGzkZW1AY41bDgS690WpOxowD0nGhCSoWm1KpgnS+TpCcV0iKvKlcbjUEtG5Q7NJ6 I/EIg9tflgSa2aFuEkSs/+8sFJPJ6li4QhrWEogKpLi4NXXe9V31oBVdYcktskeGfRnM0k6B Iy0AxhVmSFJ8cchkpLVz1Eo8sRX6okzAI5hs/AJkiGg3RlQMt/vM+TVR+ntpWfduaQfjJp2v IEGlAkDds8+zvUqUj3r4x4LbdLOMnrXW68AqiynxDq7wCDKXcl9yiecKhCdeALQgOl7sfUrx uP7uiIKOoSm0JnT2T+WpXNjyPnbEO1QaNWZ6+McbUPRIXJT3AHYj6K9WmGyRuxqTQ9w3lN1Z uc2Uo/tSqOi5Dh4nPS1Ocqc4VMp7AbntBsejdQgwCCsuW1qxn80L3dIJUCq42YLkvmpYCe0h AvsHLyNEjOPzT4gzgWJLcPIt0mmPg2AEzly4H5RokCAsSAYsx3waJ9AQ6t0P8beg6zoGdIzK Oax/hf7PfDniPgingU912PXun/iZDBwx6PtwsMngO4SoIlejPPCD1nWJlubMgGJJqvFNRxC6 SYrZQSlltztEk+m/0O8O3yddFO59BCxaooONDBUv2AXWukClPGKU23pnrz0A2LfTpCFR3eDr A23tYPY+LuJRp/0ng+Z5N/6a/1PucTvEJS7fXBcSneKvi2btgbb63la4EqnJSdmKBkxyEP7Q +EJtngd3YjOVCwP59fQEV/kCLw0y7HxEtPo9II1uQ8snSc/2fa7Mvsw2o3fRL+Jyg6ocmNOw kCUTZURV2CLrZcwQM2WKFRHaUvcaDf6zKpd1hf7tEoDe8UxKbRUt9g91pI9808jtZkjX5ZmH /B1yS1TnqjCc9ACsxpR9tj984Z4bELMKoCRWZHRNKS9924tAEhgXFKZYTqVaQZ0HVdSF5Bsg LQZlnSH+5By3dQGP5wfg4Dmhr986fEkvl3eMAJvMPolQb6ZQdjJ7Z72csY+KvxKuT7hMORVC D5P3nHhYbUiOCzN0BJTuOaoV/cZOFNBcaPLrp4U2v8YIsLqlJcjWYJgk9GIQGTFVU3zYLI0y JDU2isHMKTdVzYxwwNBl1D8mptTxxXXdEvd8yaReEf8MuBR3cb6U9yIN0iySDBdd+T2cXvwV 1fLELi0uZC+AtNEd2UnUaAtJaPW6G8IfIMJPebMMKNscBQaeoCwv7PWZidvduSXm1XVeSShC jDNfceo7SKwHWmWAi3O/icZBFKgjp/lOLXUUUPzkDop6NO+sD1GyI1dQb02Lxa5eiJHMotkn bdmlm0rl2N0jbpiAH8AAL2lJewuUm2J6KogIn8vqVpOuE6i2gvEa2Ottn2jMYat9Pbs2Ozjx LkFDkgsuX612djan645BbyvmZSaAvCuVY8fvKeesZ7reGBE+c4iUHFyLUJeRmRAONRIwDHeV 0rqg1cZOi6GnNxceDXlpZgxhZE86v9qkhzY6pfridacxc/vpLkrF/bFwjNPKfBIjXLuVK02Q 9YSQGoGVFa0Umf07C/NuoSgGdjClOXQEqroGH1BI7bQFYAGu8auPm3JIEU0X78dlcGD8bcoK LwBPMVhq/F0G6kJcMslJ489IcsPopyHVwqfpLssY/nqBCvLqh8mpEo5Rgt3Be3ZqPHqwItuV dTyG/y9uVJdbR2KeQkH4leUQojpXno+eH5NgjZfQCP5OYqIbEYT0/Doa3q27zig/Vkst2k5T voL5ueMH01ImE9aXPs0cI5JHICbWSA8i/diz2pYGoUm2BKmsf9a0ZzciCRKMsyPTpal9rIyh cjtoYePXmetz9S/dMdsNPgIxBPIahJy628wR23bhb2Ym4nsNj2tkj9rlQn3GBVtrWzZqJKJE 4lYFrcCwwhFPZD8/nirOodMqaBxOmIJBmp/lZyZItRGA2zLKnDTP7PXr1D3kqtXXFOnJVcfq s0VI2iUYjlNaKaSgi0v0ChXZarxyKvg4N9yjhWsV+sedHfkMYTgvEGUMhbXRsHx9wNl8WPoh TSGJxCn3qYgCSwxgHE8O677hrmV4Iai4oWWdR018/4GznCQ6bWEtr+BH8OYD3ByXfvILgcJs F7CKZQMN0W3xPngFAI4RP4DRFB6FYDb1WccOZITV/yTIP8YF0xO4Dy2onFywlb615HcRkLXk ac/fxmaBVfrziHhQu2XFSEJEobozUY9jiMPxeXp5RvJQOTl4BX/kB/qhjluIwODyX5QID8Mp g3EoAdaX87uA0YbPFxXoTAdD99RdU60ELlCpTZnprHFnPvjpFf7udbq/rgDMH92Zg51SrJU4 clAuJn5wktD9wPwjQKuunYnoupc0PJ9LBSa3cJ00C1cQH+NOb/JcHxXQc1994SPQEX0FpL1K WHue1enPhI87Tx/MrqaTDU2FyiZOo6k5CtfyXoDHzqTw/kugYOf6RdjhrO0w9D5NTBiZ66Gs Ndfm7BAgP+AsQmC1uexiqkjn2mwv0/e6UQucGovDKSKvP1cJxRKYaD8wz4OngcTFQ/DakO3L 9CnjejBBbfqa3oH/ktZalAmWuQh+hpWKZI5WPoSjNfNJLui87F+EN5vrW3TUlIJHmpi0aqco sPzXmUnLh7ohISDUkhRbuN6in6E8g49h1EamvMZk8+tUJW2gWo5gid0H/5Ot9JJvK44VOfa5 kpDcuBfanN0+7tqigugkecmdquLoDbhjkyclJ5CwkRduax3VdFyLwGbkJ6ZZTPeJF/DRqzzn l0vLIC1R2FxiCH0C84lYuj8Wvh0FOHpV7i0wy3bPUWytTNUEUSMttBI5aolpo2vrH/ZiUboS yuLHytu17aNTcwNC/myqsnPUsLywYiET2Q/PhCmD7CztLherKqzSCwXwA9LLll2NY38thPLr PBLgMTSz0RuWXv0ShAwU8KxfhzsCubgoKJkaFywUH0alDnz8FFj20kjfCdIQLBej/5MQKLzG t+1dqJCinX4YPCpRF/Q22I/KPhvP2vwFt8v7eJoch2ctALabTU4lKFiALOeD8FXhGg7g+HFX /uOWktJbRiYhJ1YvqAwIZpcXYJyrHklS9FaSIyI+556gnbopBPakidmbMuWOw17YI8RT1y3K UVkp9HX/+wwA9XAqMRfOdyFFfZmhiqyV3Rtx7VEhGHtvEAwlcRJdNjUs4x/34KacjgqRNv/N /DVKdi4X/5bQn/Kvn78E2Kx+8xNB2S9GV77bYmI6DbN/VnVdK3sFNI2Ixzhpb7KDB9U4d/ac PsTJdGELWLdb7ZkuwfQIwz7iybcNV55L46BVyECRFK/RpeAzBPnsHu/gPtCh3BAr7Cqp6Ila X1Ypc3yYcb91kw1lrYS+Irc0112b2qiqkILWT3WneRZWaTA7Uq4Heg+ch3DBnQHv1pEU6Sld /e6NdOd1cX1MdUKkFCCZO/EODAxm1lnVn0aWUXt1NdIY2B0bWxGaV/cVdDN7ceMQBEaNZ+6y DVOZc7A3VE/uyjd1swHIIJYE8AjKCegVKwaSuCOhF8fKgG6eMIkE+4Hq4k+jikTLGwtATYhX tcNFirkMKIFBe7RaCYwLcl0YrWRcNRwLXjXVepdFNGwMnLghkPag6BUY+Cgv3XlrAqf7bg1v i9RH+nRHKOTO/7WDB4zXERv/0yFOBsaK6ASODUzloaMnA/tugAN35sul9ngB6Al+ARwVeLUS c2q0GSN/nYkWCneYT19rIV58t0lKHu2nbkaAg/xqG+Kq6CDdFaw31ge+efdBP5FI0xUPKAx6 B5g825hxidYPIIy9PtVNOptUS2ZhyDsDc5druRFBxDBEtKgQDO3jKhHiBVHdXvF01jz/Er4Y jNiUsQn46QjEAzGu0fIt26ZBX+tvpGRjcrq8hsC2ahTXVA//Vk0X9dOrHCxejgHW/ROaTFLp M5ZoegzMyO5E8Y4OTn5B8UoUHgGj+tSEju8plD/4lQVcb3kCwSIow/InP5e0SDgfuvJwPl9W RMS36+7hAAp1GKc0H+/0Z4sUtVvnmeEGB5nOYWr9GzCknyCG++lnlMdmjtsRL0+MjGYD+4Jh MUhgIcG7t3az2ZnBl2VnCpVfptNCy9hwTqgyFRnocG79Fs7cFNSSPPbsLJPgl0aeO3JiflWx n4Mp0JH+c6maTXoBNB0HAdOnoOJw9VL+3x6x1VgoycyKSAtH8McNWS7Xova2GI4KAksOpEp/ sy9tqPgy+KxveRnZ5hntdTOyzqDTFyFJtAdFFnW8x4yUj16p5UJpgJJ2e+ana1PDklZ2votq WKrE5ZxnuPhpLC8Er7EeOnUza0NNsF3MGxghqsCJjFQroFmOaRDXjw9F+1GWXXZY4WqatIeW OHVsRNyn7ubYjuBrF30p3M+Kx/LlaM8GxuYlRl+uuNgnRDA3c8HvCU8d1lWHtiW9H1ukPH/S cE9TRNPvOmhVBteQ8OuJ+jp1iqSsodkklARV0WqQv6T8KLkg1nE4efNIJ6A2Y2qAQcsCIUlD GllFM5+GEhqCtpVS15BFtPX+u/rPcuPuoPqwSBVPk+GCbiL7pc4A/PxIr9+WmlEu/WHNR52J s6NdJeraPJxEMIerDjz3mvWMD2zRU2DGMXfumqHPqY5K7ZsCsC4/NNR8yJ+vvYKB1TaB+ulo uLjBmsMRv8m9qUHEAxy3y6BvJpOnX3zTgbQBPt9kKQTgfaYKOIZKvPh5kfHetoOTxQ9XDY2z y50P991CPQ99m/OBXTrFUdrcOeJbjshYA1cppTxFeu+0Pq7mUtLaXKo6FATWOBlx2rHqZVz2 ot46qHl4Eo0Er2AApucyYZ61uBHuFSE3umvFPD29yStLEKTsDFRoJ2Ri1fqAM3Ekv+GF0tX1 N81gz+bP+kOVidUIXFjMkQx5WtBqdAT1Br2Z0YgnaZXL0G495NA3CHpngUaab6iBjTzDOrY6 7dP1phh+OP7rchQqRo7bnxExU5QiyzlX1tqsprg00XOcyDCDeRgddwAuoxg3cb7TLbqgzKAc i3S7GXSMRR3JQpuTxeJZgwq8MecOtRYiQFvrPAjaRxxQ3m9HhH4jY4sLr0BriqsmGFb2tOry YjjXIh9y/NbBgIWFi0RBQAltcAIAj3hLA5aXn0tcMHRWlhkj/Oq1u8VRVEwH8RILtgO097vM JO/2+c/4Er0zrGL19i+NjfZ6xajbh+VCwZXDCwqnHDbkwAuV6kQzkc2Xtr7eeCYbO9CiH+GM AD2aKteWlUzgh9uIu6JS9eJ86qaWiINKdTjPvEuvIKg+r6oxy8VtDnGCQSPhCWWeSkoQoAOZ XT4NLvy3JDGTZW0scqAIB21FSpv6b0JyXuDE5QrFYI4srf6Yl8LGCRmR/MmI5qsbTg7SjRm8 FT0mKKvjl4pid5InkH79kFYnvomXU9xTQosuc8qQxZ346gt37hY+/GBCg9yIxuFQRn4Jsqju JLQ5cVxcpIFQtoatCO317URNIbqJRUhpe2ri5/FdfwZR6nRMBBYHocj05ZDFcmvMIHijmwp4 pM063cQIjnnhdSuku5g3oDxnm6A5DUyffr8JzEat6uhv5G1aGIlEHAcHLyUzfEOnTC1FWQpl YnKTdRfs3Mm1Bg5a1d21wbOSAaZ2yVnFbqYSzfR2TEzx+3j3p/iumca8z0NHbhunqr8FK9tx i4vy60KpjVJ5ht5cfd7Nl65qItj9rYMR9FHMhrhII+sHfWQn+LS/WPhwS/XNAYy7CRkaDaB/ MTCGcK54svP+EpfBaUYvJwcR2KBiyXA1BCSbi0NBQ/7BQjnUF0IqcONTuH05MM0S99eX+IOu +rS2vJIs+o9B5hloV3D8ePbcY78TD7KcZJSTrKQ3gbYa5r0oYB8XJPTnYAP0Sxcb6YghxhCl GXEbk56mM6H+/aSu6KVcjuPXt/55MIfrP74dj3QSv6SFKJXdxrVDU/KFcIPjPfKoN7TrzmV7 hwKSrUhUB2Tx6J7f8xIDKdORjTtOUoc9e/QdPMFmdnRtC8MMLHtm84Ku6D52FajMPVsrxAvD gxIJSkZ4cDm+akPF+XrDyKDKo1yBAq9y7dVSCkpaVQUniUi1OlqTA1iw6ZGHKDCM4iwnCug5 9V+arPvSkzzYxS/BmzjxcpMdzsaM5XQO5KmZjZTZhduCSAm4Di5L+Biw2OdW+M7RVlYCI0Tw 7doRvqmNvMq+KfdAWxA7RnYBNJbw5rm7Om+b8i6YdehrJouKm2RoEVzj/2ybcY3qd1wL7yNL J9/S4EX6Wdw09t5E60v+eEEtFPz2UoRRb1PsLQwWLn2su5ST488KPunJSTmlRMwUxCqARLRk 6mP8AR5mSiKV7uAMkHacEUSM6lYH5hrqHm97Ci4iS2yaA0aVlKsVxiAa/T6jfWUPyeYlWTQt n9lPPAl/d2elGOxCkXLDXQ+biTjsZ/IdY5UeuJle0fB3CYq+ND+OJH5J8jCfbo7LEJkEQn4t PJRjYZt/Ll4ixaGrMF+FODcT4KBnWejy5KHhALIyiquv7WWlgBSeO2A3xljm8z37qqyzfLLr WWzsRXha2Rsh0XfbyO8RwDmPUwlHNrHv+aLeFyKgMxsFn07ZXL1rz19hY88Fh0pSJVknFnbl xULpHdzXfqM2OV1aVFscVqjn8mMxmAZxk7YBtyU/UMG5Wd5wCm6REkZrWvNRCuEJAM4mU0th F/ftQ16Iebi17RybCH3cnFDVOU4ZSbx9aswtkLBaG9p52jcc4yMr7jPLbF99Q2BGNO9UUGy0 Xru9Bzm+iZZtJdPRkhfC3oXFoRimUypdCTcelGg/rE10NYYETasFqpPU3E45I8LnGv5ulbpu g1kIhaqvUgPvXrffOY3AUrj0dbfeQ3ccmaKc9sbept/2HsLCDExOUHVnYfaE4YqCOaUr/Bb0 iTbjdk/8dr1nV+2I9g+l745vl1bjMptzMLAH0TGpSaMxKzzrl2X4qK0Bl0+GFgCiRvOVh8Kv pGTKnfWxg+DLtq3JTT1lnk6bWzXoK+OgWkAVhSaGsH5UEyCvBEje8yWiUhLg9gOe4VEXao/Y 3BURsuvG63of+tWaOKI1n4JU+9f8M2+1mBasbc5M+vaDQbZPHDt3jh7noQdppQm3O7sQcy3B j5yzYdDwWQOpSNlSv/EGeGcPeaBym4llX8FR/xLI0azkVzk2vRt5hQHOZi/C4zC2yfQUs1jk 9DH2mDW/LuhIKiTzXnN8aSPye7GG7iTcEdr91qPv9JLnlr79HTOA94/5Ccmb1baet52I6h8n ZWXV5vSkzvbMzwuMeT9iTZrkR2BLpk+CXMNb5F+wfzR3gLNEC1lyXaEC0LzxGMWOwf1PVzZr bXTldLlN6kn7prZ5QlaKO/oZJHw22gCkmo0TWHukm1BhNVNzHvM/1LabA2tmu8cawBz8+kco qk688RZBwd0ntj8VAbGusML8anGSZfxkSs4Tbw18+L/Pt9UBQCcIh6vmfFGxESU6ab8yCuLw INAZO85HlOuAJVxwWgClG/xBQT6W34G+haa8iRvD7oCtBWpMM6z4xgRSei4/1Jm74VeaKKig FtWgE1FZke9F7UmEceJqR5aj5GyhezjlhzJzkoWF25XM7MsHQ1+DYT4C5MUxAxqlQoP5PcmW 4oulQqXu3mJ4H1qGfrc2ctDk9qrkM/nuOBe11Ro/1upb1gQyyYNXuSs3pMIeAHK6yd16JqRK AePdQLxC2gzhVeL5fy1A8ftVlyvK8JGvvGmuTxEwVdHCy8m13FM7nBm3H6ouBBThv//fLGt2 juAXOpmggC+9x56aPf6XTJIXg+d2t0kUGAAAAHTD6N0EBpQIAAHLLv6zAgCQ6BxVscRn+wIA AAAABFla --------------000205000607070909000901 Content-Type: application/octet-stream; name="octave-3.6.4_7-fortran_patch-10.0-BETA4-amd64.log.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="octave-3.6.4_7-fortran_patch-10.0-BETA4-amd64.log.xz" /Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4JhBFs1dAB7oC4QaCGYOTmuKhGENhSsemLEGec41 p4xrA3fQN4iebhUzcWkRXuu+Kc42epDPQKWi4LJI48bJ7JbbIN5b49xA5al00l85q/Vynpb2 PaW8lYavsjdhZOzEQusuOk7Awnx042flp3yrsosvSzxSjdErYFCHkYAgWZzmtLcf8CG51ow+ hsq/bRCnGzkZW1AY41bDgS690WpOxowD0nGhCSoWm1KpgnS+TpCcV0iKvKlcbjUEtG5Q7NJ6 I/EIg9tflgSa2aFuEkSs/+8sFJPJ6li4QhrWEogKpLi4NXXe9V31oBVdYcktskeGfRnM0k6B Iy0AxhVmSFJ8cchkpLVz1Eo8sRX6okzAI5hs/AJkiGg3RlQMt/vM+TVR+ntpWfduaQfjJp2v IEGlAkDds8+zvUqUj3r4x4LbdLOMnrXW68AqiynxDq7wCDKXcl9yiecKhCdeALQgOl7sfUrx uP7uiIKOoSm0JnT2T+WpXNjyPnbEO1QaNWZ6+McbUPRIXJT3AHYj6K9WmGyRuxqTQ9w3lN1Z uc2Uo/tSqOi5Dh4nPS1Ocqc4VMp7AbntBsejdQgwCCsuW1qxn80L3dIJUCq42YLkvmpYCe0h AvsHLyNEjOPzT4gzgWJMwSz2spLJLv7/vAk/4D2oHCApvXUPnGLjhhUVZ3mdeMbXvTiLYLN5 oHJiy9FpruDz9bmZ5fZFR4kl7N4+qF5jXRKIqINFL2eQDRRVV2dVLYH7ddwuxGXqWtnbPHt8 r99PnaNjxJeCa8vFh064tnEZM6J57+yku/6qtGcQby9KhyJ8Tl7zEbKKc0tZM3gB1sXODQA2 xiXfDV8OBQiOXnovp/3/Vmezz5jC61Un5spBDP0/q4e+NjxCbdWfKnPJnPGVr0HVa9WFEvZO xBJDaNuDppc8MGVYHtihbXZynYsC8yyzILRepe92Ugx+vaD8H9YTVUasKq5C5alHM3Mycumc 0VC/bad/9IGkF948b5g85HeckEOr4whavzdvPf5YFVdWMbdMbkTVJn7Potsr3padtl7v1kAu gVkTbMnv6cPcaZItO2d8ofQppVBF748l3oQXt4aDpY7/9VKlZSTMZVM3oni/kQzeXcyHlAxx voIXxIrD/L4NRUTLMLUdFlmGMC9gr7hKQAmThOB3vRF7+sVB0cfixtHNP+Hrr1xsFKADlUdY nQH9YQ5TBMRIpzujFj17m6aJBeh5TOQjiR3zwyVGDSQBD/IdWg/Yymkrbw5kpjNpDvuUG9UL hRg3xeCV3ou4MrmbZ7+NmIaRptMddTe1sss4UpVc06D5uc2W6QP4WNSMKND3o/Rs+2An9FNV EWzVeABQp44xKNvKZfTxRa1lsfiv5S0gKZ2sDklg0CyMqQWSDmr0us7/oIte0gMdIphGrcC2 ncFjd4IPT9pVpb2S/vFFupvpDYa3y+FeiKDZkEcXUQDAvEkAQIAHfzW1Oe2sA5b96zGA7Mii 9/YZFQ+cEIGbwocwlJIaX6FcAkHQmR1avMJk4z/Luc4M5vCBVKogRZVmNcqzFIu1a5sDFmGl W6tOgoaqnKIdlVqGoiCeUCuG5JCj+CZvXKB+d1ro8g80LwdorVdaACgYUrmRWhQMasQabyVQ A1CHRwayFW2bIjrCJgKv7zCq0npaSle7ZB6WRYuvxciuEWI/kcZBTR8FKfjoYq2ddhsrwuUJ 521TPRCNpnQnVILnUCwCeC+Wc36d6zNYq3AF07hNhyPX7cOnZq2ZdClFh94pUVqGTsrSRAa9 nMtkECTkUTywiu6YmfqeOJz1nzGdAnUGR2WIIABA+IPOINNjB09B3o6CRQIwcU+C/U8+q0Aw zbEfomcdp9rFlXqDrggngDdVjcwoMsLwcDfoDxsbSpJ1dEX/N2vmmqvGJpGj5fqspdKF46Ia g3cjlLYHsObjbnRy4MnjQ2ke//xeXQh2ldqsFSEd8eGHAqzAYYzcZhnwSU+1B6pCC+NZCUTi Z1o2cObbYc4fLU2Pi4SVMmQwwW4C6XJK3bFL9QDnXC56Muu9XYkcSbnW6KANLmwXnWCJgFTA PWewyHBJQ8q4a3tAPGLzoO8xXG2e4frk4FB6s19MJxX+r+pAipFO0IKWZKGoyArjnRLDg6BB PHGpFgOBvUkFFTu78/oQ5/W+eVHjlIyU2wpO5CNIvTcHmBixO3SwUBVD89uQbAkQnS1VP2T+ ffoey6TVe0rrdmDTXQ4FWrtpTIwITcbYit9Wpsrx+qIiO+i8T96EpIs1aRZw4ILKzJ7cf6pB qxBIS7efXtP7Bt6joZofisaHAnl5Y3EDOxNekaGDkOWkzIgBrKm/2AaxH86oa1krUP1rrigX BaXL+W9i/ucmj4g6tP4His2YOXMcV4B370doA14jfLABY38gXhQWuIjsACM0MkLHWTzl7YUU j/VKM+CVccNOpA2nG1qSovhVJzJrz9c/cSoWILNFYn6550O3XsS5HeB2M6WHkwMRZ576qq+R nMJBHVyF/EOKjPlQQPX1JghIe8CnAwljAsN9pwm6AtYFTi+h/ztlx87Xiqfy66eAPoTg2/JS gcogPikpmR9GsDMAC++bIm9ILS+ScO382hmXuc5E52NQEL9CQqhuZL7lnyxTYm/jsYyz8bb3 imQHFjmr46fW1TjS3gMsKTvb8/AqoHA4G2DeLXaFu09hjZ9rYuPJVk1zL/WuXHfuj9lf1Pd7 Q1LCre0cpImxQd/64VtXRcIZyeKmaI4G3A68gDZbgWhuCsn8EAvjVOM+mPkleDxcveZi7T8G 5YuubdZsz/wQS/DKsDy0oIcmTIzGpb99zi7IMQXMRAE5vmI9oKDhR2kh23TS2ShIAQvpTxa4 1RWFcTaI7FSJ6pGhzhHxrVsdAH3Ngp6N1f/aAdlFJPw9ADq0cMbCmcBAzS5ce+bIsbmGSw0N Mv4O3jJRMSN60dBwxVQcO36Lkxztqi3ehjcoZODfK5Gt9qYvRctiZZ6OWGQTsdmNGRN68bD9 9lIOUia1xIiZfVTDJ3s4dqi6jgcCEZ9mUPB1YdqN3WdyHbclQeAK2+dNdhdF+cefyK32DZ7i Bd2UYY2PZcqKnNFb6bZHi8vXNuQ3xfd1EqtrG5/Lv6wDhJaU2+UBD4I1XfnaXfxMr5DjKQVp d+ck9iwgpGh2bFNxJQluO1cVW8xhlXVfJd8cmdErs42RmBPGqzDKxlRJdVSKgkCabJ2p7f/S 4W44kpZO5kBXp14Mk2l+GiBS0UqmoSE5ydI46SYAxMQEkYTrKepUTXrof0v311Cnu/W5+nBU NDemo+Z/mqw4MiGNiYqvfPmFwE9QC7i5jOe+RARJ7xXOL77h9I9sCyiuDIAQT00k+sQuNXe+ 3IJrQpv5/wzv5McsgTyYKfoKYzUfmpkAw0zcGJRqN4Kage+ShKvXaXHroQpgjdtaE7wh1tDp xPkJUEt0WcqkI6HsmAnRQ6F0sW38RuGnFOL8y4ev7gfvLn4fY1RRCMdqUIr6m8tagv1yDBq1 mnScqLHjNWZngZA+3q02O2/TlWRZo82zFnGl7Ch6jljQXd62TrrIMLcsAEO13oS3wAGI/OL7 AUP5ML+K5OP7Y4CIuGZHk6AFDq6mHX/oTpH5C1vmPfMr+5RrYgc9K6Ed/dG5A6XvNzNSyH0l fy8zlfTKDoMPvqfuAauLzNIzgGxQ3zbZTeOafhnEPKMV3zcBXb7R6pkObxc5jM9keyr+W362 pY0ifSgHUfdPLK+0DCFV2R4t6qG+S3f/lfyR1eH84VX/ko3Us/gH7Z/W/Zs7gGmVAVi9Dd8Z 2kBFuKysnUPRho4XTAW4NQ2uw1i+VxZ7T3H/aHPVnZKSFiTyNL3em9DucyPGYgqjtgugUKDZ 5sESIMsu5m59gKBnu2rqABHksx5xaodO89Lwa0xTOOwAVyNn5DWsf6w/KO3wXbS/jeHAUSum 5TmmO5QVj+L+CxrfMoQuyANlvVsk+Dl5Zclhdq2XsYBvNkLfm6u9iQTLnr31prgAeCwUIBXX FUVUEqoLnz3yFtZxnggdTKBJ4cTrm2v59LJCHun9L+SbfafXp61RsciIq+s1Clg2RbJyjzW+ qKHaZbr1Ib9pzVnZV5DFrtoXg5PPKfJx3UPLSyxbDZ8xe7Plp836naXAZdewP4zoW5GkXp/K nbJrQKUrV7GY66RV6dJRh3+7GD9M0W0yXdmM526c+LzDFuc7enXPDsj0yTMnRjhI5+NpyPvq lpJt1n3yX6wDtstW2Dlm5Bmm/Km87DlGXURtqeMU6kCKjE3MVaUXlOUPkfcDkexRXnhm7bHa hXuYx7vAgMS/iBYT/mwnEWNNP9R9Tw9aIfU1QT9/XiuezErBsbzgVeOq+p6WQXM12okwtTlu /pI4IlaAp8A5hyJv8osI77Mowr7c01kMOd7ZhJnpqC1GbCSks0Rnq+MgqkB+zIG081M4xaDM CnKvhoGdtZ+Jgxg7Ls5b3LvIpAae/Z8j2SNDt6lxW4rh0Eiyv3B7/jOpefUCpTAvVm9Y1os2 SxI5PssuQoYEwVchzKDJa5x47ShvpyRa7eiN8pVBIj0CnBKjk1ys1H/u1ptHz/UyBZDjXodc pyeK59IPObXvU5nPOJcAACq65Ww6PbzaWwnPe2rchvA/tUqsiPELSyLt3jNiK2b73a/aWGi0 wMQydmZbOb7gQKVgd5BbMbxTsWABMPT1atzYUdN0jeKShYKlGNaTyZv/o/KgfjXzMSl9ndnA 22wpZPBG1PwNKDrmEfzWIabtP9u4EwSuyMrvu+Eqf3zFO4qrFMi84Li7aLVDAMWzAXT9TOm8 bIrkpWtXuNQQVPCN3dJgjkTrb9dof41/6PQ1XXfqoPDo058qpagLU8hh7ddu7RJ4qnpEPABB G20JH9To4/aGTo85iglfLKJ/XGfmXzQZgfFmaHabil9jsON+nYB/NMrVLvQ29QkFuG00pwnV k2uM3jq2c/RULLvS6j+1XmfXQ31+IRe1yWVpq1FQYBtEEFMaJFA/8dZTK9aGP2FBFRmePiuA /Dp8HqYM/baSOX4eJhO4gO0AGbUGuXU+llu23CDoNxzJl0ks4vcHr85ie5qUUlcYa08bvMZy KWm4V4mb2ns9KbU7CvPt9UfsXsphOYPUnwPRCbKCWkhXwKvRQ7axxYMck33IQr9d2rFJUny6 uDcGfUTutxYE/mEnfXphUZDdg8jdAVIvdFanefKBRB1+jCqRKdWYzquNo7K+dr1KCR0MilFC +PCikSrykZ+sE9F2uZ1OKGLA1TWaRzi+2o4NQj01+h9kcYCHYcXztu0RPhT3itK/5vzn83ql 2ZWKiSUsklI/8qfSRtBg3Isljo3LulzfTWPHbsx4+E7KFRrW6UnnxUYSkmsBnlgigFpGNSPU HLK/M7KwK+iNJ+brmt6sOGIEuyfmmpF9INlMlTQ17NeFeeEVk1sGbZpFtOIiHl7IVzDfFJRo x8IqpdLCsrojOsiSPQpih58e6osUC43j6qFYzuWMgCno00J0b4AgyYuNasWNxUUZWFKtaQFn ir0+nK5esR/yXJUZG3j1ytuQXvITIMXuy6MCUQlTZDBA5etPF5yJfI22PhXmWm5oL4hMy2vd 1UlpX8u1JCCXgjMf4+gjDYjW/ix150S5RyFy9+vRdJ9eDORy0b6BcXdXTVFpGwarKMt6YlMy yf75pEL22ykhgMzjLEexfj2dfokQoM1W8krbrBQCdxdURW18iCge8wb2qSvTSM6RiT7Y5mNA G909L1H1oF8VSga+bZUKtVwwps0S66e0d9cBQ6loBEXOCxdXEP70+ylKROgl8sphdtGWKXMi ygNe9Wp8rKIEn/nee5KkUfwP2uqpRBa12xcNC+wRrJrf+zMJiP9WbSc9GefyOpEiboZw2sg9 4m5CP1ctiK96uGZjdvolRyIFgadViDg3rHH3tdMT25Omh0Ij/mGzemy1cygnS09QC6M64KDp so/bbj8N+Mc9A90Prsk9RN/d82t5q6gxmSpzgXbCDntvIxOMoaTxND9erHsRrHc5EJvH4S45 R9GgrHG9l3YCRVJQrN+9jS9j9UGAcJp5udJoDDf6zMyXP944kOJvwmUNS/DS+wFr+Hp5kN6v XnDWK6Y3B4hRdMThp8EcXZ17JjgqCDFAi4W0hn65GY0S7NUahjYcqs+YfpSIvfbVjEPqCMjf knyxAweucuRKVXQfZpxaCMDcQtPyYDWTB7E7y4NbCKsJoQy7Z4Uky58HpGghPCQV3GF3ONzf xbiAfeyGYK0IBNX3ljaG/tgno81tt1ME+FFjr4BTg4RN59dQAUcjXKDlc2CuoN4H8XfEw6xU XfNRhUyQReDB3Tr6p+nYtX/B82T01pXChEXQigLRp0dQIJEw71o6F0B5eu1pU5Nh1r3PhoCK G3NODYEVAdVc3tPTS4eo63sP0G8hTdZVnQW5Oxa6ydWWlToRSzXDXegNl4MFdGDdi85kbR8w wXAbvk5t02zBWZc2aI3A//cuu9RJtADoMUb19n1PJYzypFRyQEOVtmmcZ9KSNAfTZ2PMPIme l41RNca4UY/4NGvHP4Cm1wjKf6fl3a9BNFFZgJEl1U6qaw6lAuzlTRqGCxNiFEdjO4LBuFF/ x4TNxxeEv0M+dkbkpU9AW5f3lG0NwKaW5SDHItdkcNPm8nftL6a1wFeLqpCX5bvFpbmeG3VQ 4+ytjNGFJa9iTula+5BkjSUbp98Imnl1/LBJAQWVFofMvPT/HrumBREyMF+kSrVoHwSbGXUf 87z67tgoUq1Lnf8ZY9v1sVw9wzTDEJ1TAJUueYOYLichZD8PTDgA4bzl9bmpZOVdQdpKUMzk 5mNu9iyXY2ak+CGh6zLjvUpaBbLgpLG/zZ3wDQGnMFojB0XkYqQARIUrRF4/+Fqt9Y0jRagd YjjQU3iyj8kHlO4L9HrJQ5pMKHhHvuNTgVfSGafuq7X7CUzB45yn+S56kd9CL/UXQ+2fzjqS eJrhBprnasmbQKyd97XLiedHeBfh9eRK05qBGASR8+hD6t2ZDBkmoqKA6bJ2nbYwiTSLkVQe YP0W12aCxSEqsCTHSO9BIQaPITtDf+3OxVOAoQzxgDo82iy5Y98zeZgot/S4B9SdUwSqPo3/ dXGsOf3avVFn6LncHrHEumXppJG8yobtwuRHCsjid8G0N53wAtV6UCrlzp8I6W1jF0GrnPRX XQ/0B0vee6f9lSStVVQn1YFSpCXOCsVH7QNyBswrke5dEAos+g6gBe3SgXeWcHaaaIuHBBXJ LwmuUT3Jpn7VMYJ433zVo5kc+Ddre+SBcm1NhB/6OmUTi6IDRtOL2Wf9QtXsRRtZHEsj+pb1 PMCfr10PlZ7Z4LzT6kbk1V2O3F/mdmNfubeOJJIqHQiP/5ni0DwwsycvDMvQui5QqSjU+Bw7 uekDMYmthUMoPCzwGMQLpWUwxFNVAEhE4YV5nNNh04wwXBnc456fss/EDCqvV3BiaWePhezT Tt3yXA57vm10zrdMyYAjVIqoEDu1JBpNCkkjrajGkPPBVNNbDpCPIn9BqDZep8nW/kEo+dzr twu/hAKc0NfY/+Vyf9lSKl6LOdO6SCfwC6yW4lt4Qxec4IfIXyl/IJbC8OOcFhanChob0HsU IcMzszpoZdf3PfSRPxLGgFl+gafK9jjAG8AWLPhbs4hB7h+o9xnzdi5PapYubar6xytLC6y9 C9DvN6a4ScOh+NQeEEpH7Og9qGCGtNY3chVMWcnaEPGpDP1J8aavZA2F1FZu79XpOJ/uLB3r r2Qhef5by+eQqusW+nXrKzU2yibqZf/pvKvDbEl1xHgcJdr0AAAAAIu3Wydjp8pSAAHpLcKw AgA9z2PgscRn+wIAAAAABFla --------------000205000607070909000901 Content-Type: application/octet-stream; name="octave-3.6.4_6-orig-9.2-RELEASE-amd64.log.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="octave-3.6.4_6-orig-9.2-RELEASE-amd64.log.xz" /Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4T0UM4ZdAB7oC4QaCGYOTmuKhGENhSsemLEGc4UV p4xrA3fQN4iebhUzcWkRXuu+Kc42epDPQKWi4LJI48bJ7JbbIN5b49xA5al00l85q/Vynpb2 PaW8lYavsjdhZOzEQusuOk7Awnx042flp3yrsosvSzxSjdErYFCHkYAgWZzmtLcf8CG51ow+ hsq/bRCnGzkZW1AY41bDgS690WpOxowD0nGhCSoWm1KpgnS+TpCcV0iKvKlcbjUEtG5Q7NJ6 I/EIg9tflgSa2aFuEkSs/+8sFJPJ6li4QhrWEogKpLi4NXXe9V31oBVdYcktskd4lwz7oklE NQPDIN4dAq2N81OcUoQSFxW+JeaDTmRVbU/Gy9bIL5smeggNxftH8l9+n0x7mdqIRxyP06aA B7yu8JphY621bH+oBUiR8CDUHcRhgLmwut8JvK1rfOTZz+8m8IR9q8fVc6vF9aH6qkSU3WBJ AgQNP/nbYD5r/MPUYnVgUBGE4DdRby2C2pgroy8GqX954SOy7eJrBKbGjey1W9SLKiSTRcKO x/PK76wgtPobe1ZoiuLC33a2WX0TS4ZMev5w9uxfzVTWnBe7BEFX4qu1t7e7CN0xMPbhal54 fJMzqiCP8sfscJK9z4yvK8zCua7iHYeR82vezhdUm/O0IPAyHuNhiAjqb2tVKf11b6xvQOy9 0Qt8uNL74bkDB01rlKaG5p6nf1YSkQmZcobLa8HRjrQUWhSb9r+MJHy5oMW+mrN1QMsz20m8 S/GIOy9vVXVdTvPYY4PaTrClPL7h7JZbveMsZWEgBDF2z3Kw7ZbBy4BRMvryh1blNqGTy5zV qCKRxXTkXArT5gjvCqd7xjZ0lsX/d/7SzvJLdUai6qO9jVOHu4hG8rBZOFCwwB8+TaYB9mIP xdy3TC1f/EeIExJeAhKvx2/hpM0ITTikicbx+jaCap99blzT979gBFtQHyYGK9WJ/oPo0XQd Qxld5DspI44G2+MemXFZNJ7HmEaChfOqz3WPCS1km6cgKoR6xkL5njKksWkmLfLbTXbz9K/2 F3Vn+lcJss8aKkN2uYbM3RdMBiFf1gGlYjS5MldDynX7kB7do+EpHNMKoFwzfG8pR85P5XuY TQ5wa84XWmM2cWoy9KEvQ4R9kGJSAxpIUQn50w4gkHmRrqK5ap7KHzbyfym/PUBwCyWD1yOP I1EOOeCzjf+tmDUX0tMns2PHxSWm805suubMkD/P+0i+jckIOegm6yLJcUTcac4NHJbMvo/I iHh8TMDrtmnogLuhCK+yZ3iYSSZrrwONQKDzQokQqSmwdH2oNLxmLJ/giWIDkWUKDFnltsQS 1OCBNzFeBBUgYZ9LpXAHWVuD8oifydc5LW9/q+ePT2O1v67URY8dHONFVRXw5T9M3szFgOR1 ZzkSa/PYwrnwiMoqb6M2i+AZgoJnEo+uR87LH3yoTXhhSKoSLXLsNaQNzJBBG7P4f6rwnJ8i sFfmH/H+hTgWAcWvZ0Qo73rOvy5hGtf5/STuVEiuiuPPR1T/Hvred+4T19LlQGSL7ea5cWBP R3NVkseoyYiyfmKSv/M/d8GJ4GwxywoGGatpyumphHRxd/Ir9ohx8+qU9ROaY6FyEd2Tante CgxsU5A457angY2LAGsVH5dMHnPoHnrDRCkZjiC4i4ZlgZagEGOTq1EelLat4wbbF9VeY2dK h0hd8EA2iPIjGUGON7vqeyAs5WATIN83gZ0Ku+I95SSSqxBqu+vplsmE6BBa8y0Aq/+SL+sm 13GhRaziE/+ksE+9X5LDLg7qpDBF7Broh1GChT+ExWOoO10CRd6LnmoN7szb8MrLzYbCern4 xFffX+Yq7CiS/6ONnwCRA2GjHUko8EpAZNYjosQl/f1JkTcZF+Xz0knvgTFMXwQRg2W3+tRQ SJKnki6CMEAtkMaYMbQW8ijib8IA7HOFvlRJgZBLTOevX9jljLpYPmQU52232TJkOJOcqftg 82LW6bEbzWt4NFtnGvYjSy1dcy792oHeJuhHNOQQjP09cJB/WpN4XCRGHH5sFe/0h6+xBmuz AkJv39Mmt8QEbwhrVQYdgfaQp6kCsOftOlmgPwgbMXrq5pdaKpRfSXPq/QXXT+BQbgrWFxBl nUphwv+eARm0Up4c9ZQEuGVFIR1frqIiWfGnzZDcZY7WF/q30Jyc2SLsPjL7+BF3lwys+NQR OwVO0JW/HYi8opp4zrOBYCl7cBsr+7vnicU1Gv1jmPVbLYCf+LIbnjm44TSvv4PWawiH6YGL VKk86GfO4TSe//Jd0RzdcFzTt24pxvd8gfE+hE/ODr6k13AQ4tX1bwKAfjEdvOvkcM8FIbgv FhXoOX2E7LnI+NbM370xs9C53ao6RGArC7pCzSI5aqdbx0L60SIDRaBn3urIE8mePqXLe1xO TTBkAdfQ5oG6pQFgy2MUej/8s6vkWyhXVW1Q8LvcMr26ibsLYH6x8IwB9b3ShEn84oXLvQg1 ukcU39ILtbfQS/KZ0nGMzNubG1YGQykbGIgXbpQyDV6hlMt4FYPS7qC4OsqBYio2pPd6Ubps 0OuILb/P0b1TFdgYrkn7inpB75j8A8tJkQMMMA6Aog2KFBUvZzg/bi60cCosA6IVOjoY4Rkt 4phrfk8S7vgQiLiM7iHbV4LQ0CNquv+KqxF43kWHWMWL0vw80LrInzIENFQb+UCU/c89OVu7 mHb+GIjbj+VNS5PFjndyTQPoyAjZTlL1x6UDq8jCP3+c9K/ioQPGC6RvAOC17ZE9HYybwtwN nTLVvbP1pbFZeoZiciln+I1POvH/NeMjSE/qmbsyQxDxleJlr7Uk4/fZvQCo/8Hk3rKJRTIj cSF8U2SD1XF8CP/Uwb+c9tzcr6phKzC81bklNLIAdyR2cjV3wI+eTO1VYtC/2qBGfZngefWJ uaBPUP74r412kMQIoRESI1rPB3eSisUWGE2bvdNM4bRWU1TJDyzjJsE0x5phiOnV7lK592if WXqeMFC2/ph5WUfYburo1La/qDz83DEAArytqUj6DuRp9UImCx72bkx40J3JudoHmZHlFn1S 1X7s02R8dsvLEMD3zV3ZVryU+Cu6epK26DuWndUvF4WICC1iHpNg09MfT1HITLJHvUu9Ztka KUhu3AyZChBpWQVYr5XgaInCaM3pw3idi4ZXfbnIfjdyktOtvEJq8htbGb/QHEDxPOCr7oTL f6Xz63X95NFBukhjER2yTxlkm1O2TQfPDPCY4UUhkHGjKTbqxJ8MO1DolhcPkuKRz62tf851 GvHBm/3eYRxMEg+FKmnfCaMrEhSeDiG9vmdNamzDaJwQ3W4AsC/12oaQb/JjbOOJeLs9J+Mx iT6IpbwyCCZyovnzDPbGPXqRKQQvwWZ2Jx1hl1ODJXW/BDSLSyHiIsnc55THvYM3wbJkSyAS bn1qVPgkKay8TmK53UKCHUzxeEUCllVtzW2uLBCpfM5bLDEMKgMICQuH91zaqt/9As3IYZYv cjldGrV8WaSRyVBJ3QHJoo+T6Eclz1pfjqJ1c3am5+lCKqjnX1fvxr8P4B88YFu+ks5CtMfk hw7bdTnwl/YKLMXoTbFg2gEXCvi1j+czLF7g58yi+jdnDoBwgS8GopQx62Uz7F/0/tQJBeaw gP/G+yaIJuAgWwSomCx/BM0FO+Sl3yuBAb6XG5JvHjBDz3bseqiFaX4Agzw6SxzoKFmyIFPY 9yQSk9MPEuRmHbsUC6PivWKHZNi+TqqGKba16Q2hIvV7zWtPjOzB12urKK786f0igPbqTFHM ZqEEI2RpN92MyQAiqSApAh9Qhfj0L6VKy3ddUHzVIiBLY+IqixuXeRGa56LovGutK9X50hxl FuRpgi2WPm57pjv6FVS+T1U3ZZ3fz1KsUI8e3NPjSik8HVUeMyT6c9Tys18JX8RgeGnTtJSJ kPqhlceS549BufFovVTRIx6L7Fm5bYnnw48nDkVf08VOwkRrdLkp4Cc5e42bZ6ViAQaTxmyt 5P1BrK2s22TLQjbuh6bxkLAYm0y7pmAx15QRrWo+iKbbw7vzwEd7ug48uoUhT9DJB5eK5Uj7 B2UFtqwwOCfr4Ldy6AmKv9f/kK5iP0TvqRvcd9DXD1FKBPreA7IRA+YSRg5/mLrc20i3QI5c v6VhgRNsFmXhoJgJbXQ7SOrTIMJidZhvY3L/TOB8KqtGv3UnkkrV9BCiue3TvAnsLZkMQ6sW qqbcK5WagrZ9eDH0Y/svmyGswpATBGtXZuKKMC/wHI4mLZm3iXWHDy5MFLipeLNlG4xRjxhV WugzrcZVfERJZM4ehV5/2rqCEuKiaXAI1xPkQeyN9vr6xoNxWQ5yYc8fRbfbsgZ7tnzTtcHT D1H8Con6kqQ30k83GRrRiDTMc4tQ7Yhvxg6+db8mrxbXEt0JjyjwfNKpF1TDLznawO3JSORS 9cAGXOoWhJNE8AHWdksNvhdSrz5rCfN2fCFFYR1F0NFNZh8cXuKCxYE5XzyM0212hIJX2b0j bSXlwlgMhYOnTPp6dVj4YYkeeJ+RdeUgz+62wlb/9slw/LlCpM9m1kgySDqImiDgYXwVLhra wISQf3WoLlYWMrv3Oo9AqFy1hBbGcyv4TU+k2ZvtpBvXKIjjIqi16J8+bgbpvHsPCfouEktd 2/WfYDK+wU2lQwnYeDciVYkoUzeArmTjH3UgGIlbduyqAi4hmW6J3wCvHYF7XEvIyWjFbiA9 +Bo6duIdrfkKHam+qdgEZStwqqejhwbUpsveXLY0RKwOo2Lh7RQb9bgqg/Gdmq+bGgEsD9E1 eJVQBJ0XhavIJLOIcn3qDvZ0B26nyEIhShx/gFycUGYIql994q5xvf3V01uTks3QYjN/TBQ8 rL4ryu9/ilNjdK3PWOV/KaPiN5GVW+8q9COZt3GNw4KoaQpmcU9mtAKmzBS3+ZbYAO3FB3pB FtMEImI7R64K/iLlZsBoOLOO/2muGmbrj6qcwTjb5Fd7g0YliwB+i1i/Bbe68XytB0GyLoF4 DZKamiMvSABx3p3TMuuraMLjHJhQJkOgpAbiLWc9OmK+WXupy0trr7R+KU4jcu74yb1ICQW0 8+3Vcf3pXroTdZoO2mPUnv7GghOorPPm54ofvLNg5uRA1LJ9i1fQ6rDcCil+UuHZ1DDfZB+b HRNzF/DF6SaxAGH7z/pwsk3KeLs4j/0aGH+AVrOTRNcqnYqCZP908n9EuynmzOA0tgOGhEL3 lfrGWS5tEc4K1peBMFV69JInjsNNy2CvSmpfjTd7QJZt2PtkBvdxFkfHmvAMR1dWgMX2PPCS 02vb1fx4X7Ffu97nkYo+dJ6BKIpG0bhsUciDgWb1JdJ+lPQm4mGerb4Qyg4lsOYc0I6deN/d H9A1a7JhyPnCYhrs0mTHN6DMYEpNUcrUcmgkFvq5Jsd9uXIpJKVBA01bNxRMrfjywOydixQh LfwWkXoj96L6iUqfkFHoWVqyQvOLa6u0u6HfdtDrsTicpo1+naCf/0iuRKo7FE6t4uKFVEIF rx5lOLaawp3IpgtCfzVv+TomeYW6RtmldQ4sh4P3R4NDtinajKXkBckWfAURcDmWDkH+oIfg Tuk1HXAeMTRM+dDoPL3OZLUnM5LJvmQDqZQ2uVmznHsruYKHB47T9w/AKfL1IBCk1t8jshee smcRULDZ/fy8ed/BH+k2MfAb4loqaAETPS7r23uq2DdOOjMakh+2/P5TQ0RwXEDiLjbQbjRh VOuWsTybGOlRuJlsQztQUNmYAINYHBwJJdBlFUp1rpokml0JRyjGYDgz1PBV7P/7cJYk4Qva 6Dr1dTtFEhf6VWuy1mDSooBvjXvxPPTb2s9HT0XCw6im4dILiM1pNdd0QO2yRnDwZOhZ1aez oc/gTyQWwIW29+sSDKVnW60XO22qYNHuAPjjc46qsx5UG4uTPuR4gMY0NGcS5JxCdUFCxwjt 8Tew3cFLJ8RoOwiHyOESXb+rAeB4AMCGRBijXY+FigyttL8vOCi3IK3SyHwF+Im7yAc+eXIR tG205VfN4Wr1Sd95XyhHkHNqY5DjbISkAhfrnsm7xfrIUYN/D7FONzQH+kQj/of2eZGnIjsZ jl1TFNYKr/0EV2lDKOqnQHF/GJlqhyKlqDqh/Dqxs64oy8FHG8t7nq/sgmK0exkn7XlXz3pz yw9xw33/XyGaPgWIigm6Sgyk0yPZ2OwJRKk6sC2mNC70YsJ9Ql4T2TEoUNexmMWSQRoBuTYU aIJ9yUoqZgljNIrbSEjbhH4uK6ZI9xHiLWMM7GOIHl372lF0/YJJolf2CtTLJg/lRm5VVhG2 dtI7Tznk4H6rCXYPZOfAm1vqKngw8OL7Kvz6OisIJWEK4xnIVld7yfGe34ct+wLEoyzJOWt7 gJgAfB0/p2xtdDZOb40FO4E2jYrM229DcGTosUlGYw8L786lR/FAGvtac/01pTmNa0b+SBR6 2RKIkXPZGjF+yivJVbxA9hPWGTrYomEi1AjpXQz2WHY/inDAmNDKuexFjJHjGzVc7i5DQpNB dcbt6guVxFbZivOzTcnwXYoyyWKDPFNIEEKrCwfPvgo1DhgPp1da5F4QHDw2OZZRXLVV2uMJ pHNUTJMvlsWyG0a1bSTkDMmd28uaONHg4FmvTJsr4/mQ4RkjbjjCo4o6JBXkXQ7O/mPPRKCF QiRbphcv493SZFyAc9ewD266CLsYabqf5LJvzpDLL2fE8ZPnGdKtbja7P6rsqmiP1Thh9ojm 2Ujpj6pFVIt8SY3oMEnr+LEC+Fd3T8SKjCNp6ljHpwCjGpH5+piDHv3lwzNk6y2WXxXUYIl4 chvKPkvRup8ldRgqbgoVSwDW+gCcgnLdEdb8veEcbDGl8OyqxL2UcndJtgKVlOA+QQWt+PPf WKPFqZ7wHKzFrw1lXYuHu5Ltc6jZPUkLGIegi0mqlyZ/YqQZfeOQQN6Hc4uqeEE9h12GCP1p sYLBTpIxtFS65+nDCKXqiEF2Hwx2J13WGDpzqwmmYo+I8Aw7wnSVhobjhBImkeD4nML1L6dI EyaooTcQGOAIUHRTpr5hwZfyxHzYHlq/VxrWiif8mFAe7Hn+EjxF8fcugVfxHC8DrIw5m0KE xJiqybG3SMmLOZPvKXWXgI/QY+Q3vGPDDdwVE0CN4xbzPC0+XVPj7hhzE2PqnCPf9ZtumM9w +301lGtQIit+zChXzBJsf0Q+inCadPTalfPPEfr3rPpJb3y7RccvaMIffxnufMUUg2uT2ArU 2rMh9zSvPuTf7N2QPZCDkwZ8IyuWxFEqxQBjqyIq5M7UZeMiv5xezes+W63IfD4KExuN9mQk 1mDtEuWhN+2djeIiT61prrQTNlzyboAOg2/olFHrp5niHiL8m/hrLjdqoVkK13FWGvUt+q0E Fx+7AL9EtV0G4FwQBx3fjiTNJl63NPboNxp80UXCRlQfckzh6G3ngz/vOou4IWAjtulyBzr4 4DdWwXcqzNCddsTQGFlUdBVIPVH7OPdZxK/TXFGWZT43GqYo9t98nDQ/VWvSNXmELKFpxO1B Hq2bu2nBjFRW4e63lNe0mRO+1OgUyS8GfpA/IKcrC/E0YBiARwUW/EcrMwSODeaSmLt/fGIb h6FabA3E1peknS98dlSxi8yjjdzmT+NXBvBcGuA/lj8b5nSG9nFjeBqVluuvTWxupLs3o+XL PwBkrNmCs/NUD8EiVRYoPwUYpkidx+cXI035d78IfuB9h154kPqm68Hcrf3eF1NpvpnR+xyJ EkKwSnugm5k62GC4GMR81du+ILximJK4c8VTDY2O8FW9KGPbRXHWXNVzBRk5m2OjCd9XsT8V ZlTwlIaOzKtgp4+FDH8J8VGa5t8RdGaTf1thqir4nsN3RlFTxTJlDTNg++RFn+p3ZIdx3cDr BFVIHmuqOm+vlQ/gjNuk2gOam/VJkeAatiOSpfqDq7W1Q7kZmFkrD+S0kHNdKlIWo2ZFnGcE M4kzrP/QQK+wH6y5S47+EZpRujwTyWNGwKe33/vkI0n5+4YX5J5abSrW21db6FwaVyC8Nm9A imriGF0VEm5ianKO/Eykwc2opR18spwSg/NrRxmHsxaixRlzYzmAJBqMygv0S6FNMv7WQKpV qgbwkgwJDQQB5EnhsG/XwHuIS+1VXP7DYexSFst1Rnb7JPGrmKDq5Gpu89Lg9NEN826AU5Qz Kmw0MMWyxRu6G1TMFezsKwWzV4OnBtpdQtz9ru0OHrNMouXnlVySa0246tle5aDxDfYZ0q9P exoWhQVZPFRIXlOAysLKJ3Wn7jDKm72R6pSyIptBMBBJWSwpfBXB0Qxt2eQCNIIfNRmo1l5Z 2DtzQ1AukzXRdCbUsmLx+s7y8NRq9g6yboRzC+xdGhwh+tJC6wd3Qos46HorJ1Lm4TfLbs+m 0Gk/5hJ179Zw0NMhaftV2RcEtZONXizC58qO0WESdooqb5D8BQO42cNfBZCQ3nt5nUdcrODw 7yqqoXEGiIOQ0ZUJAH9gCYDt3BBKb9+YJ56aRrAz45pOvp86aFAguJkcFlaJCamrsvfHEWjQ XQDRwDUWRaEkbrJWU0llBhGm5BQ4oFqiBNkaqoDv5juZfbkokrQLpRr/YG6i0N8CuMElp6Dy 8crF+AnkDcf5LhMm2Y1RbVvQ3XpOn/d6Nbw4cghUPwbi2bHzoe7fCk+GaFR+BIcWkgDRv5fI 4HMGGV252FVzDIU2pmmNEEgMNojkry2k7lJ5x7DAWlPYOqtAyZ9JAI2afYy+IRj2ARsEQ9Wl 4krO76lsfo/GYlWg8Myz8nTgVumXdtmcFVkKZyNymIG36WXJmsQ8y0WwHVN+jgIwvLN/w2XB 8AD4N3p0j+KQHNtn5ZkWnSrPXDVvyUWkjSMHCQbjc8j6p4O0fX/9PCSs3+ECi/L8M8Zw5Uca KVj0f9YkZ9/dmWLyzWqtkfCnqOGVSNOxPE1UJXLZLm7jpRQrt/0fmyjpPEQ937rgrIeKN38H L2ncNZ0H6A3Qseu3xxZi4woJooi3Y0ci7+277JkYFZVSTBn8aOeyyLV1oFhXlNiLEnui7tfG Lq3HR3Xtj0EI2OF7C0F30i6f+0KzgCCsGiwq8tsM4f1a1UiD8ZenT6DAgyyX9CdudcMEzHNB YMDjxv9cf50iNOdnGLPRsDGVT8ePEwDQ1QzkV3KBolyLgU8EtRKGWHJwM+rPoZdhgv4VwIuk /dw8sPKGGQSmsWmi+luR5OGCBChnehOc5bl94UygiU1e5bihFVJ86WpGVxc/shF7Y+VYZEvX OwPtyB7cqI1imCkzC/DZVv8+mVCxTEi9M6nVBgL/Hj5z5qE69G7qO3eodZ3eMuCJfnyjDm7x UCMdWtWDoadfl6hNuJyc6MLmS9UIAhcyoThbW8nY+mE+Ra1D3EtecqHJoXM0YSRPdG9gEva3 9wj13ykujQTWpDau1sn4TYCaW/Qpk1w5eOThQ13EzXvELshjYf5KI2T30Oc5a3cm/cSorCbZ IAtGQxjsbKEMyVJgtRTTU69jNUd0OeAHzB/oA0OkIzZ97/hdGgBGVi0btoyC8IK4yVLcOsb7 6wzmZtqU9jQYmTcmpZIehhnWb4gzJyWKZzBpSwaVZuigrcOMI53PO/aE0DOPvwqZ/tn7hvLm /TcPdUd4MMBAnXhjlt4xAXOc27pcz9PtFmh1ZU0GIT+HTe2mBr/QiNjiLxWwP46nSGUuceIW JDXgFe6ulk/pDu7K6La+c6zsUWZJAaZLswkMVth5/jL3Id4CLqd/2N1Hsr30g5Zz7FkzPwtj xeioxmqieUnfvppTNXqeb4J82GoLK+ZY2kqM8zua4ejyXJbIq6iegCr0ltcVUuDF0lR231Um i6WO+n+OaGYly691PUwcVsPy82EDlF1pyI/tT+L3luVY/KsKYD0uoG7ElKXuGI1feeq9jJtf 8Ap94RSywchkmALUEnQ4vMXz+UihfYoYv2Hq/IL+yh0lKm8gJIk2VgpfL65y96T7XQNhLauD 2XDteC0dPQC7MNMlvojF+/h0IMUsaq14uPEcbDiianfc6EDE8U7ufb3qJ/I/n94E5EqmOtd6 33pvLLpqbd0kVmwSK9GI3l80zLBHlJ98UtlgqAUmw9dPBKW4c3CzVSNF+zbH5HWcjD9dT7/q PMrTwpNYcLaHuO/s7T8IS8VnduGlxRV739Sy+MW+B0+ekMEWlrjMLgNQXy7h4jgZWcfg6/th rajf5kg+axAgYUPm611XAkl6LKbgTnq0VSSCL1X0UuoX63Q1txC6NHzRaI6+f+QZF+MflsR5 L2dmk0RJnOT/brJJeNpN8b3F20C8uxcDlVwZoXk8GyaV60LdlZ1s7JlCuz1GRCmZKdr3RBer 4R86Mt6KYrSmvfwUJmaEqfstdYi5dexnn662juetSphY8vJXZgwkuQKF6UXj7AzZVjYNNCtL yvpuDD4DDYeRjeQfqnLEOj50Ktyjt2sGRG3/lJSslqR5/qpkzZInC/tBjHddbB8Cn3ZAD7x2 QIbNBf67vKxN+M/AQ+shEYkaLLtMMS/XwjltLA6pZZZg1E5l78xijU4aDimFgDnlt0jF0p4v r9bgPslO7UjnUEHFupkV0OSO2JPzO2EQOEX9DHH3Ysp0D/SsfZCgYcR34qcWXdUfNgS1rXr9 Chvj0HAB3AXmbeVLjjJij+q9dG9beK+nMrjQM0vPB/+3FQ7gyjdPQsWHllCcpW73Mj/7+wew WxAtGt3QmIQHHKIgnrNSiOpIWMv77DjsK1VPKtdz+zGpPK/RvJY2+sI7sqM2+rXUFx+ft0Wy fLA77vF7nVEwcW3qNEpP0y0/PuEFpuJb+RX7rc/+VyOD2hALq0YgAL/YA3Ugh0rF6jtBzEnV oL9CT2iWuJKyBGM1I4oB6/KqwHewyBqZocskzHofXaNZdXIoK90lssncHNeTYfZ3AvD/3nSE 7k4ct3UUvs+sedQzcsGbUQSzeLYNvlhEJHrqiD+4F2hibnUq+dXyWK7P1v8o8atWMSGMmIMW lKLCe2bKFbP4XNeM3sVu6easeJ2gtIA9yKcHEDIPJpI7O/ubjhiCSyC+Q/uoSxWbMcV8jYwm 01MNhXWwajOZMlI6KCdMZorpXys6ZkUl+yglscrteI6UluoB+1Ski1SupcdAGcgrVL5wGJ44 PHwnkcl804lF2d7UES5uNT7M0pfPp9Aj7GbtkXJ6zVMW1v/pBavgyt+++swKVkDDYcXakn5+ HBLjR5kc2f/fSVurOd1R0FS8G1wpTpoSeZ78okCLzcUuTnGCEc1wb7Km/zXEh6xhYquzkmDz xrSWAj6v1ZyNPMUbdxIrIBfgu8+GNDEtjQeYHx5fbffeGWu8vi1eBaavdYYHe/a+vWnqDoDo oTM3JLGzMdI6DZMOSfMEjadEqLEYTW9ZRvdvipbL/Aqj5Uvfc0Az6GB3rPIZv3876kte7dIo TzciA5MxdRxW0n10D56JkQwYdvoyQ00fSCAtITGfPIVaK4FeYA/PZV0frZzZuDhHI/jXREzc 1Q6sneyIhlT+nNEGuRZucBIvTjeSoDobU2MlNsAY3ZLOlzwqNokHhbpXeDvkTqY/YmgQpk6r 7bNWvdjsnlC2g4sy1glg3H/sE9MmlkTvcyy0ti27RDfdfNMSt1M+H5KeRzMSy53GgMx/d8cG 5tQOCdRb0O98nAmG1bO823c40LsSPmhaeQKcN5ElApkM5QrFW2xJBhirsPdn0pIZr3n9os1L 28YwwPH9JgnlD9yrskpWo0ux51QXeFBAZStmzDpbLvBed0OgLKclUc+J862SxtZ/mtF/5oew 8HHD2XcjyxCLth+Pix6ftZQ4vkd7nS4Ozwz9nNpky6xKbniz3aShaw8vU+/aqBBb+ZGCQRLD UbQO4jGwMqNJ3fTbWxci5tNsw3JMNh4i6qTyfkhq9Dmfydyr7RV+zDKB8EdiQqPAkHmKfJaJ /sf+n6AYAIsRM89ZHHsMO5Qlfv3cRAzvbpa+NKsV6ShqKts4raEaQBXpxO0m/KaSlnLirgA+ 7S0TiRkk3bN3cCCSx8Tq405SS5sWh6gdQIoSMDzHStshpC0ATRiNnAPikPYoNbRXbUzAFVCy 0xQ3gJj9lD1cKUaaKxCwHifSCJlyqcvyuOn42YRMcAdle9DkNmGY6DEAwMcMl36m2NKnU8fg dEbnT13kb/WOj+YwauQu/V9P7Rk5bJgoJYSKhUESaH2O0R3lvGQt/9aEcIFvEQreIOutzXVW fJBcupJTHxmGhZULmfq05w75AMN2HMeQqr2ZhirqyiBrZgOti8FmSju+t06K45M5YhCYXJND WAq1VFzVyy55CVe1G3LTklwqLDAwspzBH5y0Y8jsmhALdb9OiXzXXE2qLVBjZXf2YLSx8eJ8 V4+/qBj7Deq0skbMLDfMTdSYiygnYMVZEezG1yuxwm/thTiCqPfeLW079jJqMhG6hs+TjGET f4WxWnC5CLqdEH0LX+4RZGCCigcQLz2Kjn/m1MQhBgwR3PRKYOO/MLEOxw1ddzG7ekzqaszq dmoAzIuOEIp8i2jhzuuNihYQMmshFC9BLbXJvetVu+7y83NgIbMjbAxoKEOc2kQ/yj/rKTFi QP39sLbX7LiVHHeqTv10ZOsIPwXeam0ERME72QjMDtfhWap68rtQ3GpIEtBRMLnsFEsC+fSr 6HF0nBOr2qjo217pOFVMAcZujU5WErILAoUi6ktzC5jyLtH3dAG857A5t1GdDfWOv29LYN+v TCyTs74m5s4UajFXIMVM8ROox4qBEmTm4um2lLGJ8IIS1ah7uzNLP1ho30XggqxxW0Q3jReP yQCuVWarykPCNK4ISIDE4SgPk5PVFUMT7xk4B8Vbv1epxiPDehaK3W6cWUqY1X9GC6LKLNcP zNgAK17RCxdTa0ptGLqCga9S1gzz1wkAWjyZ/A3YapdxpJLbIBOKeC+z4hyQDea4N6qEUWeb XGQrJIFtwr81TAULmFQLPb6OGwk9/mFnA73w17zg2aifQLWIcXqVTNRwGRTwd5pdHzwIl4VI CjB1j0rSI4fWCgTFFyrpqbXPHzQ5Bc5QZ5pqGyxpzbTwB/nDB9/21ETFQua17qulXR0sHHes ZLNhkI7lpuoXZ5c86LBkqnQUaiYjCFNy4o50et26rFm+0aJVPsxdcxjF1ah6+03s4i/HmnEl 279AhdHTKAM2C/RAC4BFHshFFj82xO/S8YVo5M4D+j9E94/wrtsYOhX++EuO7nXFHzxeY6oU GKDl+ubsxaTK9B2Cq/IQ7ImbpiOtl0knqMHS/2czjYhDMvqVWbUpb8rDB3TqkMFkqAQ+XThP YLGkma7qKxwazrIfy6AeHLiHs9mBtZKakPd+XDjxZ4AdLTbPLXQE9xR2ta+ZzRhuz/LBTQD4 UaNrSFylmwF1yt+se0wVZr31eyHznGKPRbfaLFa3zaFcV3Usz0nW2JZKtItqpFJUaCaXFe6P 32do2ofM1uvkR2hbtkz5bKqvatyWG2OMKAgAeu6Q7A3vgqgyyGrwhn/UfJp620gZq82p7YE1 sYzbMfJBNk5nRzbqPpG3tB1APgQbOWth1z6qVXU374kx193aVA1Nqy7v20gTKvRn25EnCzaX mhISAMoUjlZbOsAg8xIFTp5g9/wsdxfcN22EkU5LNo11iB/CLNwwiHGVHVjyug6rKmRayLnV y0VhG3iGZ1qnNlKjB51Yd7ZFasm898je1CMoWlKzr4M6N1HYDq1RlHLrdgA4mD3OS4KWV5wk 0Xn4sWUcw44j80scVNclgnXxxxgjaK3uoIXcAJZ0wKqko9NnG+RXozXdl0BzJKeNZNVFhG/R g5FlPlyrfeuFI0a9eM2SZdwq7jIcHdyPZbBxAMFvg+NlkwO+smCUYp8uIugQQZpOElbuVEaX EoFoI4oBQ96n8jAg2Jx1fdJUGu6kmMGC/ZnVzvKJcGqSjTPWKMbvUesvf0TpDuV6Lbk51cDS 4aj4EWBAyyTmEa30UYG2v3VYuXY12Y9zLFk4kiyCE6e7wTVShxp95zQD61EDbUqL/5rnMrgV bRD/ZsRBAKJeeG9qQyO+2v0mB22cLzQqBYiliC6Xfo0hNARf7BOdrJNbAYGXnHW85F6zo87s UzswZ3GDj4iPRUNIUcZANcgB1QM8prdMkLkDNvZbdvxPKtEraUND8vtUhymnLJu0jJ3yjoor J0nIW2AJ4F4KNuQeK6JSb9VEhjHtOVOD+s7kRzwnij6zCLqu0KAwK4sJ5AZTgqmwO8y/fhds HpcjauL9snt+HOy7rZSpmstOuQG7wjDQ5wllPGSMnwjvStvc1VkhpTjLWLHgVXftt8qvkWCx ZxzjpwSO/IseQwvCwWMB9afA7ATTaVXjYsA5i+RHrjVti9cILzuFrdmhbH0NWz4BHhvUcM88 c6phl0QHhkQGBQADjjv13uaf7qgXb9dCVXwX/GjvWqnCMwBElxGmiWAELoG3vwJB4C2DNjw7 kUhU/MlSbPJxk6aNjc9oVfsMZYlnbu48AZeQJRj5z1NhrJJxAoKO+lrozLlHevqrlWvD+RYO 3voz3VH8Sv2E/8R+NXefqCaOB3sX/cylsP4q8JnGF4AZHP/bltjCMElGZ/DnsqOdXaoOGiYt OZhGDV5SaYEkQb6eXfn7kpZN32AdvvoAGMEL9kga1GIbDwI25NSePxgFIAKIqdeXXiFwqiTW K4/NMsQWV+/QGV4skCa/si2sybTq6meg03DiPZcYM00ZsFJADHMwLXCJkDEU4IA2TJja1kja hZsD8lx0Hbu+iZJ9DRQx67J48TdqJruGYImzkgply3qFDkSWqs68vco/rbT11+ZkjuoVfW8n idSsYXcB99zxnMEZ6h+OCCL8ilI4awcglF+tztRqXGHces5J+pUzUa89Pi8D25pwdTY5aYvc M9xVtYiKXSU0o3r0MSDn+0CE/pAemQz69gwMsIR9sxHcnFTBw6AEw94otWqcwN9rHt5FpXYG 76thbyoZYYeWcdKH+EZ+h53PvRKF8ZX3mkVV25E7Nso4rnpNwmobbWC3/blQ+arLRFaVelbb 0jHrLEUww5jNxH4FM5LBoe0pT3FMgrRVMPqEvgqvdwPOSyacJALU7fwCsjCZN+Hl8PeYysY8 aVbk5ogw6y9LtwW2/FW0+CaNV0lZh9wUyoNessMzxHakUAmP8pBOV672G0n9cA8yeMFQ6dHz cI5Jmf7a0/uuQZA5t9aplnOx905YWDFMfzAhnhhkB8dONCku9OQo5WydIRQfG1yCpSLfp+Bf REd3atvMzG40h++Jim9dJytB+Uuk+dEhEix+G89NviCWVT2y9cs74TVafP2HvwOORmJcgXgi yqKpxGmwDHwz+TL1FPtG3La2OSMsbLczIeAsosUHEJxFn65uZ+kft2RnA91MLUDf2zJd4R9x IciVHN/EzBN4IGDdsZfBTE2+sbq8H13sISuFi3s4xaFyH6hZLAFkOnsg76sn4ZqX1e9/Ghwt G9tupEw8L0htzuT/WQ/KjntBvh1ImIxoihgZuc6RsYHpSZtKsvJbU5EzxkX8+sT4aDBf/3Xn aaYl563QTM9Hy8VADhRXKO0cNqTeSB52cDBznAR+ZZBcE4q3NCDlANMgBLNPF08DmusFMJye 0sbZvKvRPMvnXmvtpiEVavS6i8U12hhjKJ7OV6PLWxk4XGRJGYRooPO2njbRDz06mRPfz/vD zOx48DoTlt/SzfXS4icP6VmIDjJnapjdMEMlAa3yleu1++PwkVnwi/Eo/q31YSE6G+nxpNrj bHHnW+Pp3JfedAcpGBn+I+RMWFpRNXGWKOnHx4q4nJ7VX3mJqHiJqLsXPvSkB7sFQDdD6KJm J8suA1h+zShnjmc2zFaVmtCqo870e9JtNffZKOUHuG7nGSYLKV3UbpimeBWh+pbcG4oIslx4 PI8WbtVyqwXmR/4UkurSxHqv7oFw4C5Rd8ZKpNKSj4b2sdB1z8aEz6Nlmm1dh5+sejs0ClrJ cVuEbL9mjPBfdYwkHFdRin+llGQjnDTzIJN78RamviA1/p99sTy8jXDha8/n8nQ0ZNZLu+qM YKX0DHCARQM2jlGXX1Kf4TgM/NamFXD864kqNTE2NfXVB4fsLpe43IrWx7ye0EMHCiTy7O3J MwYDz/+Ubb1UapgjaZK09Qyyzi46vFAfvg97eFgFLBTnyVxH3MJ32LP1+Js2KC86RYQAUa6k T+UqkWPnuxCseNRdhT4N8ld8ydH1Y7hAsEy1cfMEUeWqL1Lg3Yhjl7ickjS0GV7hhR9QCrTO OPRTRW1S7Bj8pZphryRzjU7/rUHxCdlb0B2+Ay/koOTp4Xor/VT0rqpc7qDeeV1r0+Kwbmxz 5aSnKqbd5Pnijrc8M1DGRgNBzTQPlZHxyqVMN2t8HFB5iEMDn71hve0dV4sX8mDcwn7NPLhv RRFR6X1ASXE8jaQKQAmr86FmCDSsMuUg2CZfWCiVZevgRheg+aFd4TI6fjdVsDs7iZIVSQGy Zbyg7MzlBn3H+9EqpzUtNpKTLZoI8tvko6A/h9qdKyVmlIZtcp0C3XzeL3SoivbgIByzlj7L woCPnRSGBey3UqJGzhdtsy8OSuDj7DEwOY02CNBEieplI5fGBE0+mA55XseepGOE53idLSLh dgPpI8iZDuJx5sBzT7o2T602bhsEOBKlLHdqd2pJuWw/5aCqqKOSmLgv3rODZWY+hv0iFjXq ltmTD3v4FznuTy1Q8EZ2Pt0+vX4S8BMfGRqZ0dHw5a7TupFE/SYV/3zhyK8slIAK74tQZpyF 5ZtgOuebpjPpegiaEdcFi08Ptql7L9aQhNsmLb2TPGSwk96yU+i2ZLRAVEIq2VHTSLbmA02I iVbbASNaV5VI/Ftpu41tr7UZ5UCm3VR2mlza5H1293tXjNi+KIGcPeX45RcvtQSMs00kas6b zbHc3ljNk4DzQXW2yhswK3JCQArvGh0HnGKanLV2EviqbUuA51of06+54FjwtcxNIBT6lsxP a5opR+Zw7O6TBBmvp0KDMtATmV4eZqwA/FDmeF0oRWxZjFQo2ZWI0ys+YBiE3fslbJnBKvLj T80BZaKlEbPemxatv43tVOIn91ktrsLIw02GeOcKBtTRmbWLYV4pQaDRBncn3ZACqX3KqSOE MeO9MDRea3erMDfBfmG+q2WBOi7umhDnDSoiJm94ZsijTEfjBlAkuGDe9g19zP9JylCrusYk /etrLd12jRr8Zi+wAEk4Tbm5Nc/eOYTe4MjTk2FIczy/fbkPLFW9oMflqH3bOYaQ2bEpRbko YaWhByXhLONxyknnr6d8mfPTPM0nkaH1fN697i2aLAcRP2JtBz2miaGmGjoHXC1jnAtw7rPO luMXo5Ay/ompqHNYowczSRzg/OAo2lqOZke9I35E2iJvyttfnDNseVE+rXPqOOG/jD+yDRjz OLQDU9nqxV2GIlZaX2/MOtD7KsyikmPVKzAlMjle5o62ej8ZbH+S/8YRpxnuHSeHzdTvby9J M6DKc0pH/v2CvjvvnQK7PaSmfhcE1wUc4fbED9U/cidcduAm6KsH0aH6CbmOejlxnqbWoeRc 8tOZLgAjPUBxJuMfJZi8sSaMKSSHgEJkilbmlXxZUav/Ng9fJpSgY6Q+W1S0AAAAW9Ne7hT2 /KMAAaJnlfoEAPHtMuqxxGf7AgAAAAAEWVo= --------------000205000607070909000901 Content-Type: application/octet-stream; name="octave-3.6.4_6-orig-10.0-BETA4-amd64.log.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="octave-3.6.4_6-orig-10.0-BETA4-amd64.log.xz" /Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4TsuMwtdAB7oC4QaCGYOTmuKhGENhSsemLEGc4UV p4xrA3fQN4iebhUzcWkRXuu+Kc42epDPQKWi4LJI48bJ7JbbIN5b49xA5al00l85q/Vynpb2 PaW8lYavsjdhZOzEQusuOk7Awnx042flp3yrsosvSzxSjdErYFCHkYAgWZzmtLcf8CG51ow+ hsq/bRCnGzkZW1AY41bDgS690WpOxowD0nGhCSoWm1KpgnS+TpCcV0iKvKlcbjUEtG5Q7NJ6 I/EIg9tflgSa2aFuEkSs/+8sFJPJ6li4QhrWEogKpLi4NXXe9V31oBVdYcktskd4lwz7oklE NQPDIN4dAq2N81OcUoQSFxW+JeaDTmRVbU/Gy9bIL5smeggNxftH8l9+n0x7mdqIRxyP06aA B7yu8JphY621bH+oBUiR8CDUHcRhgLmwut8JvK1rfOTZz+8m8IR9q8fVc6vF9aH6qkSU3WBJ AgQNP/nbYD5r/MPUYnVgUBGE4DdRby2C2pgroy8GqX954SOy7eJrBKbGjey1W9SLKiSTRcKO x/PK76wgtPobe1ZoiuLC33a2WX0TS4ZMev5w9uxfzVTWnBe7BEFX4qu1t7e7CN0xMPbhal54 fJMzqiCP8sfscJK9z4yvK8zCua7iHYeR82vezhdUrTfhrF5T6zu1oLi8TK7UjawT7GX7goun 7djw5jDVBsXCYTGhkH50W1NB/HLKyGlsD2PX0Wmpi2rcq+fsHT6CZHFUDCjAGg7upPXV2sLR 9sFGXN3s3PdoHvnRJMWu8Yem5nugatmagZfEirUANbwKz7vh0UvFRFJWP4PQ3UHsEM9IOQD/ EAbMTb7/VEDENX7RMuYiYsXXZr2bCcrzkGlzwBjIQM7O8SF2swrvARyyKGnRr1X7JviNZB3T AGQtdY9FzkNbCjcbZFXYxUZQmHZZ2YqEOLj3ACEaVe0FwMkIiGm7X4lNBBW14wVz3brOG/Pm 0+a/0bBBWAUE4HUKXRtr6cTphN+M6Ej1OubGnEVMhUgKOwAtz22AWWFaMPb85giSPblGw49o x6pnOKPNsgKk55QJWkbgIpyUXMfv0fYoeKKlyY/vRtm1w6TfT1/b0cBURyiy9WsiaU4w2Y0a vAnqQOtBLbxk2/xVN8JxEhQeMk7iblu/BgaWK85NlecVn2BNl27HZquk3WRGSy+ftDQb13ZR IvHEtcecOVzAeMjzAfqflYocg5PLg9xjX9X665/5AP0dqtiemU6BOz2TPsNmwtWPRiwO9ZA+ v5BeR52S9z9/Rzjsq0KMs8rkf446jLDnYkVVIAIyWIeXedm4n77SF+mUpbgIvI5p+/nDjKHE 1IV/GBdCIL3gCROUycD355/Dh6tzl9r2xev5JbpfAfuqiMMiz360sVteRT1HiZGj9oVvQY+g yNsIxLq1318iVvwXFGznw6LjeyRtK1HMRT4IqRhitwMbh98VAh0nc5QVYPSyERSL8rjD8p7y FSZ0Ip0aL6+BB0IpyLK//MWvBm9nwJW6E8sJDx5EEGucaqKIBASHbWYjjHR69P/u9ARxpgTi 5y+0bDsnrukioZrMtJtYCtvCdnf+TwuutjElE562UUajKQLHv5gMH1qxVDxlo7T+vFPt4lAf go8ZpOLMyP4a8JVqXkHGxaOiEuG+LLUq8nCD9Kmx83lhDu3vQNHhN5LQTQPIijBXk/EdBOrj MsYOADMd843YEijmOF0jLs6WAptpEUXLzxMGZq0aaPGHG9ZzmqKAYo1ouBrZQ6zWgM0mJHh+ dGrcVzyU/XZv+0cIGmfqKFZEh0rFL0Ij3cw1g8b7mzPpstW4n2opvRaNJAmHAwH9kQarVLI7 wSo0ycGctndzxqp5baKJid4o0R0d6f70iavXLr6yPBfhcJGb7eat7WZZWd9b+2W7P9aDdmXc BWkQopKmC+6vcmTS1DCv7XjyumoByYj3Bjs/P2tGLFMmc3Yf2DMzEGk9m8xyHVcrjh9s23n1 wZmcQRhLpHUl8KRWq9dWS3F10eSB1D+OK8wL60vUS7DkDAy7OJYoBZpwYh3R0E4TzXHBfPO+ AIe4Scw8Kje9uuCOyjvwSj8XcfJ/fjm2MQP5Vgy4Xy8fhFHjBNFP1vypdJMfAEtOwrB81cAf T4Cfg1mhgr+3bkjw6QdfKvayFCbWutiu+gKicw46jydyAPUuATMjOTBV7wwfTq3HlhipKu/G KSkJAqOKwo6FQ7tbcHI4aXRsul2301VuHZbt5uYgd4rnL5bucC/PlcePyjbr5Q5X6NmFo+4M Y378XVaXWEwsotjKEH2SroVxv4T7DhIJG0KxkPW0WVVRxULxykCeA/5V84IjGeuil+TZdgI2 Kvqh37DFk0b5ZFeYSsH+hHEHns2WD3BAdL69hoaAQcG/Sx/LXUrFTMFx9Ks6yoeR0ySXH15E wzy1kFB9FSLM09z5g3PzA+3Aixghbom1zrxl/TczOQI9YZdDLcCb98wqUVC6mO++yD5N+Ui8 IqbUIvdyDAKRRuU1zXIbcrJKwpXFRdeOFUNYWEAiSt+O5vDFhek4/C4j9tNCqrJParL9qFyS 8cNgl43vsjNS6hI2SqXl/W4G/HWhBNSIFv913/cL2rKIrJg6nl9Q5acOeQJIRdYgMMtU80/D PPHMr17IYaMvKR/JFPGgzZcmfKCqjZ4IKS136nGKXP1eGrUX/Xcygn3ZdUzWJBkSTewNu8Ko LvVzrFyWtGsqAwp+KoHum/v+fmCZxS4sbwV0SE1eZZuiIA/IIhWWbAO4Plv8jRyRlXp0kPnL qkLtnKTJg9ixwTlHVHX3MNOZMjTr9EiKmtugBCn9jqeDpWgSKHwZ1Zb6p6SArYY666U3sqez HTfYVng7uRAPMQ7XyS+dx+0Fyw6F+j93ToHiZiFFKoZx1GaEXCTU1Uef5zTzGy5gP6StztYl hW3IG4aRabgCGeUcAg8aGpn6c4gXWh+jirQ0IOwKEYErMy5Sr0tGq5c0MgHUVNxedBVkdFf0 r50LW2h9doF6hryYZ2tFtlIlaLX1ubYbN5cjBY5KTdo1lBAdmdi2yAWDVJjfwk4SAbTE5JSO NAi74i8y/E/8FgdDfrl74+F4mzSvjOqgZ741OGDYqwmIP6RYDWUIsy7wS760lhvEuz+3efWr CQdDEMvcu9K0J0HwYn8UW6/ADCJJOK//78mZVBMDNuQUmlQ8s4NCAzZ3OM2EI1a9Pv1TYh4Y TliT+q51HG05W9E/oI7pv1UwGScrMNfGQdWDagtoKiradDITYWe+aFkGa3F+jdJe0um+IiIZ SmGHfEYaW31AAfPJjYoBLBP1km0DaUnKxui0E/6kSAtEvow75gFuIZeqrlzB7LTqTtK1kHib gTfTfhW++uyGSIdwZtSpYPHPJFPx6jngDPhotV1Y42rt6ZAY2g5TYQ+Hxu1eh4NBG62Hs/J0 de32uWXNO19kUsMGkHDSD6+hYXqRiC1EL4jl4qLsOe7qcwsrBYKs0GIu0MyiVoQnycni+JwW +12Blqg/dZoQs/Ui24wswd4AC8/QGKLVaELfikVP1vrMRxta2+nAHZR3/d/AeQCK5FHZwSGm SGDQse7vHSoGSlzwDimCRqdZ8uFxSvqpXVTWIQJIaeelFDoUgZUgrfM+ubKjDcrdusl3AunC AfmPdw8u+S4RUa4Ti9IIVLut4xDk7sa6aKPe4zAWvmBvZWyzqo7tnBj1kmIz1yDGEBktPB7h 8nSa/nyoNhGclt3MZ59WuVWdaekK44Gp0PYINnMxWk8bpvyJ71m33Py+zJHLKKuZZzaizEcC OugX1i1YS2kz69iDOaoe0ptKuAZkUfaR+I33pXfBNPLs+WD3MuCxhWaLhs7maxWNgDLbnwED m04dTyjr3UelqhEOWFIry5sOHi7lpsRirNZB2WzBnZmBrhMR36B8CuNbFWXAI9GEvWXsXGop FJO8gDmYX1dYz707vLpVS5Ty+vsmMWNerR1l6HIjnSB0U4A95/VUFV8L78WmSdVdvpPdFmfz TXbCTL82NdEU2Jc+UuzZSz8Qwd1NVySUb+TUrWi+C1wq0jJdkoIPzt2c1Gk8P6lKYWR2Wj2D /Hh7ga6VQZXk/q6RFwgWMpwBUrcEQ6qn4ZXwQ2gsLQKhDgZSjH4P/fyZxWWcTdNYRveI9JXa ZktMfR4NmBr0DxULTbvmCNfV+2HzPMxPMnUvNxv9UZlPrRwG/KCutPLZhMUZQGnE/3XHgBks J2sHrme+sRxgw6r/7g12z0sjM0AGyGl56RzDu6q1qjRay9C/HmHJR7T9FGEM0fzTjC7Mqtcb QFSDFblJ7o32Dg/MyF/8U4bvG80QQdilPjuxwPXhurVZasMCrC2pr9SaYlMH0NOLZWABo5zJ U+WoHrSmNV4TZhc8zbOZa4rNq5n9LB59aFNFtQdtFpLr1iPBiDldzmDxLxCHsLtaRNic9vjv 7iReiHLGhIsPyEGHEhLDhOsek6Dkc/DO7d1Owi7RWwcSuwc/Z6xoQSkTBKyiz1VkJqS8jTVI 1T1IsjenAXUI7C87GSD4zPsDp82SIGeqJ4fi+9HD4iyHbjTi9tDT0D3edThvySteIbfheX07 kZBmZ/Qsrz87vNnabox0yHGnnfodBTM9MLN4L6ndly72aSdB7mmuzbJOsuAidLsegEYVBxx4 q3T4x0w4wj1rufJkGOB/GoeyrAAebDz4lZpCaJPYEGi371gFU+18GG/ago+KZ8t4iQo1Cp7t e3S+2xq8dWKwqZrDCmp9ghC0PdHXrgWCuLJ6ZmZqUApMfhIMNM00+BBdG1NgL8RfhwsxopAx CI1p3gDGY6JNuFVGO6Y1W3Nwv1VM6pYS/uYAO2LQNpYklNB1lowkD4BoSHH8zYI5mSN5a93H RqODdVPEq49FG5c4rOaiP986f+4u85Yj4QmuOvj0g2ri3XHAVfzqpElKRlhTuugwDSynSRtM 3p8LCdU63C/bIkF9bd2JEZ9xL690w9Y11iNMYH+oolVYb1MAQxWW4bvy+kiGszmno8neWHNn YN4oSVyp8PColrPTFihIyMZwZemPmjufk4Qp06fPfxkIeVuMLqycox9qi2ocNwLJ2tO7Zalf VobKSQSWWA4MjALdMoFVaa7nTSGHeWGmKw/pl0/fGiyuneT8FZB0yUSG2MH+T61CZp6vwFuW 2aV7zH+v52+PpybyiCMH4MRlKziL6GZIjn+FLjFCqVmj7x9XCMyDOHUlP6b51YDRbxxP9CjS bjnJzEA2T9+mOJc+ihwAxhYHGviJQa7TZkJRkp6mH80vBE5T03nL5l+GmOURJAT3s02oQMtv UzA5XA6TDE+Lq9xyxhcUgWGsCQTZJWOOXoeH0zmMhxGHIz6RXVDZ0/icsF3/xHRtJV1LHKm8 QEhldzwka0L8OUT4XbtCufQjjX8xEqRTxKnlkIgFVMKBcpb7R5T7FfSskouZPu/wD56ktNxz uQo1bfOg+C4Zp5RAs5hfS73wZyd2dZDvQ3OHIatTVdLhvXvIEsfHCmZSU/6CzmQq8W5iBiZs /wxiFt9jXBdthkoF/f3CJKaLz/5MeAltsIMlY3iEbamiugPhlwixwAXVNeGO+ysSko3bEskO aHT0Vn7GI67ilzEPu29PK75Im6kBT13Mmbp23BfRHumTWGmoRxw5TwYM7bfOdGugRhoXbtr6 yOMVTGFl048CdjReShoJiUnRRK6Cv3PBVg4hMYmSElX1aprpn1WJCLoo+3nv+0Bxd55ow+lR C72PlBYk7b1A8dFOgLDTiDK9A8nnveeAOIoHOokq8VXhijO4G9+43ybZsXGntGXUAXDEsg+l oH0sa/l2DN2n4GwmwREiK66eVUIvWWGKzGhwIS4w7iBR8lcjpBt0GbWpW/C25paxELpY/3bH 0CM66CgrXh2MYSIsHycWdzGttrhjBROpAwUPJaTieOgHEUQ6HtJM9bRW9jAg5INjKP2uV8EZ zWhkQA84cdUFZpuYmFlgtPBoBzXwroPzpAhuS0r4rZlEEFTM9A1Zb/NHbhKLJTM1R5L8NhGc BEAE6Rxs/7ePfiu7E2dlFl9eB0/cVfgmiYhWbBuIwkzSckM8Jx6+msP1Gm9RCCPGO/YdoEUl mrMkQKf03ST1xtISvMUp/Krm8rDd9lwQcH1xtEDTKGbBh2u3sD/dAPmavk0HuhMbhLohaPno 3Kfa6JmfnG69teyW4YKQ0osDUxWc299Lj2fBUI0EGkoh6QKAbgx1xGrgoBSgOf6DYec8iFfi H8FMtXyUMfVjzXPaJUEFVxva8LiDYFbG5yzp93HBSNB3igbVPZxnLHivqiPcRhDTrDv4Z2u8 A0RrVRfu65ytxDl3LEJ3QnvpQBE/8SDN0XIsSg35X2Jul+boj3lvle5uZywhFCRWehtTJ3SU amT0G0e6cIzt6wa5bIXx5D8pJ4HRnzgXZh/bw21rumTaAjPEEzwGu48LmwCZeBknUNmpOp1s uxgCGj/Hm45yrcd8/Ye8YdsmmW8zLazykui7qKE0hLvajZ2Iv5Lr/MsXGptGX4GoYDXWqcDF xIFyB5u8LHT+h6PSivsQYd0uBD4KJLKaI/7S15Nck8EeWMAViov3hLlk/VrhH0jAuGvcTFeR d8UnV13Yt8qzSTWI3VZGZLuLxgo3rPmV7K0VScYpvdCSQjYwKsWOy3qgcaKoLJjL/fpwYWVW BIBbORYUpZXAN9MSpZ2Fyu7E8rUxasS5bNi8vUAeXB3Imw4QJ8UiiZincS1Q7RJn0bx2nBgZ /zuAIsogmqmX3OKK9+pmenfZn/kStcztnWWgZWrVU3Y2jGlivPerpEQanBCgTlYbEeLsEbqZ PT7dv4dmGZqJFmGBm22UUgZ7LtI1VjMKVkO760c2g0tO5cA7U7Uxy0yJvytZMGTB8Ub+airt 1ArwvCRyIN4GAmuaDrKgVFGC6LzjqTtPWW2X0vSmJ21QTJEDOj4wAsaO7zh34EDXXY5O8jbi 7+nkcmqNnpaPPSvMLmxVhnQw40OWxPThTRYtzIZIAv++wtsZT4VR/MDlR6EAdsDzFYmxVnOB X6hvcNPNx3Ukf+HASS0lVbru6ebANc7JgK6T3qBG7NsnwyEduv6fpSN3moRRAOs7sAcjUzAs z/qa/GuahDm3mtY43vTrCwfxsHAbOnak0TpiACDABrq9LclQXHQmzjrIIZ8lxWqsvwW/KK5a 0UuPRXr5KUdoRQRaV3HH07fUDYCHjndu6MoT8FA3mCJ8lC+BwiS1IOyiwLF9GcSNtloxOBqt PdUDrhA9rb6830e1S/B6AICfd+UzCdKj3U4eA7EleswZI6wxQ4XPHP3YcUkc90WvOq0NR1G6 OA14Z4JuxBRIJXvy3typPrucIpWdvY8wvzME+8SYhRxxb4N3N0IJqysyXngfNz8N3JIVxubv tKGLsY8ZHlRRKd6U4cWU7QiYfmDRa61SS2XcOlqJhvdZ086Y06JS/vjlvBpf1qaNkXyqIf+r Fy9q33znmmdhz93KAESeIKV2ZDbJzO4KFZVL/pbtRzq8tiyfTQRnD9J2XV7oV1htohOq8f0p ZOZ+gKDP0sKr0giSrQ3xzdy29qWkAceFJ8sSOesTQ5qrdo9pnu76CiAAeJVz7HKZzbJzsc5y 4/uVEY4ZiJNNAk2pQEtWlaOde/Wt3LSwshrs7QHQY/+oBqTQt5eZucnIRDdnBxGRWxpSn6eO fRCJOu83NjoB/NNHUoT+sdwEZbG7bFmeLYI60dw/j4GlF1k3sMDdhuhd2Zbt21hKsyo9VxEw 1j3NkRF/FxS6Udj79/o3Dxyvjx5JxlD90qzTfmgy4YYAfZRWs9bVVQKOmX919e6BhMDVr6os tVJzWYU/txOFshZNaCRNHW8p7L2oWrb5v6AxWsDG5FYULnM0nY3NREmdHCUdzhvaAbeV3rBv TqwhNGhPGNBl91SGTtnQNaachU189v2uGQk50fGv3isWAmx5s6vzlXiQUbb79Bf7TPwZ4NWn AilaNmAC8mqAKroRnmyniMEZyumMtp5SP7LPqeE4cgM/urD5VmbWB/ho6Ru+a4yi8E3J1mjw Fs8jLhO0PibIBJWiDURKg79v57Pz2ugOYr8R1FbAAIRz/dUynSfmmrbebWWHGv1dD+3sQr7U 8Ji7RFMb5wm6F2nnEQnSxq9MxuxTEf4SJcnN3+o05Ha2m4h2kyuHPy70Lg26nTSOPJhF6BYG Ntfrmn8LwHDqwC0OIzyXrHOYmqwMm+Cfuh0svJrVWUBpMomqEmiQEdnEJZxp7zIUxSd5NxZ7 6qzo7qXNya6Fhk6hjOPxzXaSC89i2YWVc8Vr2nkrFMXgzUR138rhboCQupa+Qw3B/v08l09F wH80udNIE3puRi+03JG7X/WZdCcIwTVN8uMbj8IufZCn9Z8NTChdUTGxJCqBQ5jO/02DpGCf wXTT0LnlvHUdFM4PvteOfbF1t71KOFjfYS9i1DJtJ82GAdKOHu9jUFu0eCEYXiI2ouJfC726 M3/ryBr0b/e0wCgIE1UCogn29bIUDTteEbfpNBeD4zIaF7G8s1IkSYsgZ0Y5YvQE9ol03oAD v/84kZ9HNySAlqG9vVfxqrlJLeBYgkx6b+dEBXUezyDAmz1/3rL2RbPUUCw8lvFPh2ERXIFZ wQ0MLXPM23KCKDmkvDcC2TYKQ0TrctjetHa92HnOBO3GwjXDoo46T/KWXoLC39/wF4ThWzjM XwlCbTKp368McgEcohsMn3KXWjm3VhqhUduOL7l0qK9lTYns6ANzH5oglawjo4f6BIQwEDAM 4Q3ufTWc/WP2O0lGguXgOXYmJ9k6+kEWKNcRFzgt+YGzUAs7TgWkY0/aTjQ7tOI7oGCYZGt7 uMHtWqzMSYa/Ff80hJDvf/GdKNa+Z0gUhHPBumFZFxa+oEjA+X4KrLBfWtLEaU6UJL/EPuet fn60EECVAV+V7J2ysNxJPTT5N5ijUAZA0M03wYdxEGORPRW/FvTiH6Vsejgj0K4X1a3YAWo1 A5pxeUZu/298C0HFqhGc4XMUob2kt8JjtiIa8SronpZvWO695LzxtNt0i7xCBqQQVX24N/kX s6juWsi3yf4VABkUhY/xeCllkYRMGMNBBm69PAjEsh3GbYKPn2AXaoeG99Xu6C9sAJQ0UGNy QzeGw++y1gpfy6KCh9lJXIjE2EFThdqvMZ5tTf7DaS+EOLiwNN0zaO6guwfkpg3KlwQl997d gecFeYKZ3POpGB7cvcUGCCPIU7zpiED7vQOWkcjZ04EUDzN5qz575/EQ0IM+l0JVtSurAS59 bIVRVQATqRYOHH6L+W2HYJUPScFh17qx1hh2s+k5ZuegJfPL5jmkHToUHpL+bsWFt06oDTwf RbQ3iH4Cn37KxjsDkLqdiqxxwEkjmH7X/7j2nbHUboA2yu8ATP2J8vpx8vmfpA4BjPcmAZHy IwE87xehkY3LDHCYC13h/B3TAWv1zz7njAFRKYKhtkuBt12zWxnqZ5g1yFplV+7fTnoj0p8q Ly0Jlb3Y0zupH1xL2hq9kfTNbho3ZIscoejzySxteHmiyj5/zy6Z2Y6Ggq3DmL7BDHozSVAE wL1z6ZbyFJDAhzj4NGIWgtRdASe01G9Vhbu5CwsYCupf/XicTISPS2wRDELBtZclFRJzAY9l +uyqyQIRiwc/YO3xZB0OVfcY4n3HZB6YgsrFdetq/oVHRbzS4l1MLFgoSADJzGj8nUH3rftX 9vNNOeqN6O6+81mLuXl+mlAkTzoKz1Z4pskFjamc+ZKuuILqFYu5nUxx8h7ocPlneCrieQXQ 35B3LB7ScQ7++WzHjlZMOZRn9NrVr8ylQX8t7+HbkE7QVPAKJZR5+3PNYZze/KhYgcHIFP6V HXbko6Gxp6Z31EVEHWuuLyU3zd1eVzXHK4lzyEfoezO5x0acx3hoG7ifH491mCHWpTn69eC5 FmGn7V8Y+ddKO7u9aOCZW6FdV1FNG3jNop+SfxumCY/95K2MPQVODS7wkoNcYWK/snBI0UV2 MsRACMEWT6jv6A6lCkc+bhOh9XcH/DLe2IrZzX+rmir+u+36hTgrJNcFUKTfMwPfhf6EuH05 NVEFjAq/zWtcmFZ17dcUW5tJxXK/6hoOWW1YUpdib25Hlb0qSInL/vQa8g/5RNsnupKyksD3 +BbdK0HETYfUCtEfh19Yj55+Mh5GG3h7QfY9pFYVe7nDYi4OvoJ4aXkkVMw/gn0ycXOQUZiF 0oHpV1DYyK+suxLEsI/OC9ZA6+B8XUpNxKfSzUQsu1RMz/fE3qFQRXqDudwDoxBAJ8kEzUht CpXRGXA13udhDFP3GOdtxNByNVfrsvEKz+bBqs6p3blW/eW9K2ihZrh2mC2MnriRLjihaS4+ 6Y5TRBefM5zTJ4LobdeBfRW4uhDDN2LQQTP7f9YnRxBz9aquisqkGhEyvIMVG4IovKSEIlpR XC2nUzc8mMuKKcGohAROALSjZGW4GEc5CYEH7AH0A/qcEpVVQo69R101U+drkMFf7YRvFWFI mJkMi/Pf816nqkUBF3s2Foh3UEAT7xGM5xNF6BHOkqakJ/5twFA9GTzkFbYDAM3PEcqZPNoA unSrOW+p9RCq7OESRTJMrMfD1fAwuOua3chj/Y9jFii7/Vy6O+RcFfJWgJyiHw52VoiKY1rh 8v8KhrqH/bk7hG8wKtLgF7nmSwGkzuRO4k6VjTH9FXtif7juVyB3R/nDcH44Zlc5ml03UfkF FCjzuE661DoaUQGpm06I1/1mwj3sojF7mvCRiA+y/zYURiktR3uynHENUGs8uNSYJ/gM0Emc wXjN7yCpaMY82d9wGHjisT6jqgf+QyiSbXqGvdcVV08ha7MYs2huaeUWz+DMCRyH1arVJL/S 2peAKmIpa6mH8EDH9VHy9LfOho75Oz2EqF2qFt6kihl4n36j1slVzwOLHfBwi52gJZ9Ax3PI RcER3XGoJnkOTe7VjUhjbDobCg5DgL3BfttX55uthmglF/v3726IYbt5qEpTSMRyBrUFseDd w9Yx9qP6YeT7c+/elFpJxHxbkMo3ZVcy1QNbM6DXQsSK/g8L7BEV77X9r5cfsu1oqE30K8DL 4LLxTCbD2z/S1j1uUbym+OByC7e9W72KGNiE7pLhTF6VqsTz9EvL0gt0KI+ZtgQprlLrEMVr vosUcfoF2HdWJ0KQMq/eNQKyL6l23M1JCAZ0PE/2dJvDeI3oBiqhfIONxhn9u59NfwJWqrov jr9H+DWmnwUMQxXUwvaGtdGbucib+7QxLvrEO1ldAOKaKAhVLcSedqRGzP0WGQvLYWsORn0x Cksym+vMjQY0XKI9EZs2km4vVC/LaABkZYb+gTiRDm/DW97ccC2et8rG4P9prbOkFpK2iGcm wJjaICgiWxRjDQyJujHCNs7eNqqQUlndMX08mSGqFASI4CgjkTrL7IEYKSSsbW27F7DvOgHc DMjxlMNewJ14yY1Uq3k9lSiWKlYHRmin2wm7uez8AgtiMXPzGGVALHfOJ+c0QcAkoGKwZ8tO QYes7hOs7y+aXEOHJqKPQCLri2ZyrG3rS82S8G0XNVJ+i2njFy0nyGWbvzMA2fxzCjcHmM9t UXtkFFSP4Yk69jHEYlz6+AD7KewUUg0fUdNQFhFyYifpS2gSEbeL5nYSUuAZKyKTxC4QNA6N OOtoOwV5TwDjACSvt1ffWo5zT8RBU0AzTZ9rYKD7I4nVVfYeNFbGJNCCGk+lzkSOyoz8cZCs N3ZnvRhzzxS1fRKRR2lo/ZgIyU0uEkU313xe3Yzq3PvSiRpfW+XPnu/Hm37efpaRI3n07l3D su8vuA7t+aUWnb5bWgJHSzInsET3nvjCrPsa5gLO4G5AKWT84cx/JgzjGWP0oJS3w6w3KSLb UIBWANfVZbIHNaIXsPEyx7W2ZhwpCfyeByknZAWfPruIXJvawNhKpWLVhW6TgQXa8TOJYj65 zDGnrXHPr+asnunH5mW81ctKWvDDDiADQCO7bQwmSxgTOsa3k51j8f0S9nOJAgTDQvPsQnSV o6zdj0hJWcQ3PlFv+QZz/U5/EI/2h56Le5IqTvVp+udamo73WGxoUVNZai79jelCzpaqKdpY mYXZkPF0SXVhSSqYCOC3TpcoALlIPriMwjT8fQpx+KU3FGNB3Qfml4RpYTnAcx9lwmZa5K8L 7WN2pE3fOJE77MrJhEfQbmfbh6eYep4pfRM3BQig3CWDWVcAn5BEafeGH6zHnE72l6AMRpK3 +knGw+Da8TpDVnI8Vy6D6Bxfzt+9xsnf1ZH2ynkHCYgPKdblpF4Ak+tyaw/ayXPL6vq6t33g DqedBnwq4wbM/81mLrDwZCJ0Mwi/OdyxrgHEA3LK8RgF3KFRsnx1z3E7QnNZHVCaw4+k2tDE UDq0GtZlrDiTTVPyF8ugJv8jQeFi3CUDa7GRjjFLKgTv5lsYaH+pCPBaKC9TBVS/USlrz4UQ 47pfNH7QgN0JayeD7ak4jjruiMV6ntJk/L4oPM5fDfLrXShodQHJGLLmCHaGoWulXpiQKEFx MKTSMwrAKo90SCT+N1kND2xd9FZlMxUX+wK1HEZDIi3r3PjneTTTTRMRawht9Vq23eIULX78 e+pYP3jFAslF+/ApW9UJb4p5ZJNtyCBexXPhhHCK03G2XmfAssoJBJgyC3Smo2Wx4b/HUL1D jc0RDxdUNiBX0MhEkMF2JV9xiFGPmv1carWiVjQQZwZS2xhVJEGs/MCnoud85L1+LbPf8X9b 8dyq0iFTz2aNiK6xJ24ODnutZgAcboHHwyqAOs3qaIy52XzuJcWaqEC6IwXt+4DhMABv1WNH EmsXOgjd3OnnifLs66/EtoP00S0GkH70AupIayOHo9loBd9hFosuI/DIjEehpg0IQ7mx2gcW ABp5QP8vC7mPcmDBt46u4bIdzTZV+PvOOSEYSmlFne9ongqW6forTOxlG2SBAMll041Qnj4I 3xnkEeOqKGhtyYqDDdcI0exWKsm8vL7zE4rXKpBFA/KyfhgMg3vjDwc4ZjnDcNPa7UlxvKQa iaLwo4E2cXxXBJPGXmns+4wrGaVxRKrP76liAk2kpHMzwidochk/YrvJYkJj5IkKnOADYvhb yYWlQR5I3ZFcP2ga3vIGoGVl9r8ni7qKiHI3sV78dLTEv415ucwuy75HYlThAGmXfyFUcpI9 YyN8AutyJilQAJ/3v95mY1/3sKSaKY1KZ10txkdfMZ0RdMJiKtRfm6VTQh+RdnKAzs9ql6JI bGL+pkSYXEdPuEEiG4XkN45LiZ65EKbWdN9Wm+EARLHl0gNP3hXFDVmORtWcX4r5BMNpWixD Y60MKytjFnhEBt+Sz4Sch123ls9G2uRQ6w+2Ws3Eq3qFn+s1/T7QLeBaBIsSJ0Vqg/1GoOe5 STmb91b7LFilvApLLzCZkJLomMpcdb9WV2h7IUhwju/3EOPNjP4QDodXwABFOLKMSNOV2EQp FtBrViFLXRJZPU0P+Hb0fAy5AKAKiWJjy/uNfKSCcRMbKpVWkIsd9kCyW6dZ94TPmkqr+0+S 1m9ndZInF9yVrHWAd09+wWBKEfc7pNnTYLR4Tg2VNQ+OIQf62gxCRTPJxeAjf3i13ZZ+0OAF GTKT6TDZr+5qXgSNpYkhkywGLJIejs3ltvudoZ1pYlQkdFnxQv6KiF0BRkwMDljtyIAaMwZC MWOLXhYI06sTOgf+NzsUsGQu/zU266ulsNTcnLZbxmf1bGKdrXsP7cBjPj0AE78tkNMmPWwz 3956U7fj1GzgfD2fFTr9sZCnVyKPbQ5ShdTSRsmApcWwx6vyZJ44IPzz33akGQUwmV8YZgGF d4xwDQFGbQhNmKYF6rjHwl0nd9+vKOLUdgiHlNLWM5q3eDDxsZKG9gBCXACCGGoQgcK7ukKE W9ubKlYGn93xS1sZG6ltISeoK+3wBvhAPD0Yr5vp1AtwHd68tSZbfaQwTiQriex2n3+tr442 emevIRqivTHWC9SJoU6LVYmSUxuUpCZlny3SOU7s8mpFpHoZ7d0tnyjzGIKGmyNMJp6K8+y9 jCbzrQhWu4gRP+ERJMiDkIEi84Yf6J0azhFzvXW6s9yRCqvbf8nvn+GAfiF1CFgVTxhcVJnX VhqbOezFvpL7A4QcV3AkAsmPfc833T/Ved/Mp5UK2ZC7Q7WTivvps9M1XQVOMh4fFx/dmTfK VJwlUT8UFgLW5TaZwyKZuhVkCV7yVRwIIDgT0pg9XMaafNB83DUQz3epSmqkifM8JRVluXME sBDkoqmKNdxZX83JYeBa7z4A0VkUG1rM9XEiqM0Pq1kjyOfrtYd56hI9+dQTkWYKNwLK0TfA AVKl9OwCuBTvgto1hf5nFWEM4fhj2CIQa1Og36j6GUy98lxUr57qsHsd1X5DufgdYdtv1Ueg 2qLoF2mqaSMuJmtz4ZFYacygN158Q9U8A5d38S61a6Fp+xCqgRl3rjd2SZzu9Y0R0p4VqSnY E5XJnShRLX07B2rmcEMdAc5ON82ge5TtRgEKC3UDyS9uXQLFmInHYatMapvR/pw7FYiNZJz9 4cmLt6EQ0XExZO1/cPUKGv/zv9hL0tRZJFxqN0OC/9FQowkpLpdB+GE8jufvBWo00RJjYA5/ ImTws12tIZNfNFNrEQGsggOspCI5mjS+DZVZU0CbLMU8U/yy2w99YfgfQsBecgrPsHPwVbwv 8sVL1hzyRuvVgYfodKCho0bhMt1iypvRQdoDzk2mgZ6zYUPDx5uC3HrEeSHAeCXlpjJ0tGNm Ey+vCSKEz+6dLZXGxbtBiN8qHE1YomAB+CgcfKlR/w3bZv4Itf44mTMVo9vzHeLChPcSrrz6 9fCRfqpjbOoRKJNKGysMYurP8pA+NEbGg+F+GRszxth/2ALv29tP9jdYEPhNs0eU4JR9x+Qr Xm08X+m8yyHH/L29kkbaxCND4KVXowxCuil1srhbcvtMuYfgQbTV4dcp/np+a++UsiGnpBHT HeeOsg6ytbqIwD7jTh65cgAwl0RInwE4bIF+uxDj0S8L94FtQOM3nNiKz5H+tF8YeSAXi+nO MKgMrjURpWjxEXqHyuSRGmT1UqVFbIbVUQh5GBlf5rL2tYuhBJDA8rZ3/fWYkEeCdGyiEZUN waXTiURe6yFjWslmZnzy8o0OSrfXGUOKfLnkqdu1hAut3YiO8HfO9T5Bq6n8ue4st+j5CIYb icKIoOV9T8FxAgGET7vuklPo4j6OW757SRziT1TeX+w6SpoNuLIAH+j5lJs8JsPuM2enfz3c sRCko31v53XZL5ugux7PrUajMuDsnuANb1UbeZnxrw441p0n/BMTJcJGG9fkv+WtAM4LgZVW J5++CkAzdGypZutjI0f1aYdtDqTfr1gbA538FZ7F6J0Ayqumcl9c2Zx6IdbUuPqilmQDlgPf lLDquIp7++htDx58T4RyBl9ss3k9FwQUSMkpXYFphXq/inXkk1yWP2IZwZtE2QoTdK9gkinM iy44zYoHCIds6t5lGIA7LP5ak6i65e9EJYUL56HtZ0MxH9+DVNo2p1Ho/fwK3Sq6DihKNn01 g3Pd5c8qE0IsyiBHeRBxZx8zCNTt7v+4wKCtSYbNx1GA4fRSzmvAKCXfqINAiLi7POgqpXYC Qj+KscfGMPdVxXlDrycufA4obcdBhN0ZoiGaBW7+jKFgT2/AEbIieYcA/2yXDZ/64vk1Aulp kOgG5Zshkn2Z+SKqhl2hQ5cR8sbEMEl0Yo/+aTpblw5ZIj7wQrHGGXjIStOhbA1Ab0Yvo9Xa jh0qwqrMaSTxlHGMFRCunTcUffb2jOd2+qtg9aHI0fWvkxXoX5hH0lTvqk3PBhQ1ZV8U/z13 eKCvMwrOkwTrMj2MftfLP3fcrAu8QK1thGkIUiVH/Cc9S9SftRicXrZP5nqZ1nRQjQtYHG5k N8vquL917zmw3q4knOfsn26smn5mBNK1+GCShb/PrhgpK+RKmZXna6aIChHCfS75I/kxs+R9 moOB/nMXFudwAYj8wxnhmZoTzZH5KRSEs9yJFFqV0fIjckhEo66gcSgBcUEj9oYDRgUnmi5u yXdrjU3MlGhjOeDTKCbvTz/5mV7DBZ/8OVNeocN4nMRRdpvLFwFKJrCRHT7+ucL7xNfp7m7w JzAj4nZAWv8/fEHuLEmx1l6HdNIcfFqHhqDR6XY6poChzjs655HtoXsf4zIJCvEAw8SJwbMW GK6T8i7i4w5Z2iT+DfAvXCUHr/6S9SbGj3tI5EbJxd08+g51nEWJm22Pw4/W1TdcqIyUXfyG KiSMzGjiBF4mmHE25YYEDG/GAv/zbVn6+Gp4RQ4R/Pv7FYKg/KqYwFi+KYDWPSiJsm1GJma3 gukhWEiPnOdrP2XFjvs/Byswudln5SwDBC07RquBtfDG+eSC+Hul9lPsuOZKSFK1bCibBczu viK9N+VtZfxY30peUYXYwSeA+4jCblLEucWoHPFHDtIgPjhouhya7ORtU/s7UgviwXTfiJzh jjRMZnIUIeE2oTveOho+RXge3bCwVS0iSK56sTjyiq5syQrpo65mjf+9OfUkaW9MZGReUE91 yNXNayQLy9jLnJ6s6tnTYZU401Kelkpc29HSIouJ9aUgZIpnCpA9tDntMGLnlPrKr9UYBLh6 3SjsXrGl/eSRyXGsbAwoHcqiVzm2RZddn6GK8eCMUweUY3FVEhq+RWylfgA1fCHgaN3rnpIj zOp+JKNWnmXMG0gun02z80iRg2Y26ucKgTVvqX5b2/v+iCDwEr1qAYn7pLvGVNZfZJxFJNOw Dyv67EjTadCDVnbfKhhPVEIjaOQQ5dCbWCRJJw7q+KNuy1M46PP0n6ZiH2u9LhaAeOWXg0BA 2yo1m0O1fiMwcSovFCWW8TUJcvya4wYYASDh0Kf4b1XAzoXL4tCAVLpDpNaU/4WyQ5dnjtYF 9xZ0D923yDLc6zb7QGrg+TQ0BsVbSU4h1mz1DRDF//8E2sPBYiI20SlrFoOKSs4deMGUHLZz OwQatOGoCSIXABYXtsrCJSv5VDApemruW05fE+B/nT0/jKy7RDE9qmnXrwji1m+X9iS+kwjX AMTVg/0SENvXN33Szw/hEPRTK4BypgngVxnJboDLZ3nJro0KBqtz8YA08tlre7V99Nv80XCi jGaDjlvQEQ04F0hFFYI0UXvxBhQf/sdTI9ZJWBW1j/TXboA127pKYWqjmuj4RlkqNeTzFMdu QyfwVyLudqJQe7kupytgKiNf69jzffFWDfmNj1aWyNvBbqJ44B9txY4nt7Kr9oiEmT+UAoCF hCyjxqdVff7oySlAvbQKkJJ97lD40U5kdbyt5FvOkAWbIWFOlgmcd8QOBJeiRxMc3J4HMhYx 0b6ey54ksfEZEghKg6jqP8ARows8aC1RdZ3LxY+TBC3+MtklrfuRkgn3nLloPat5MWV0nnwP 4nTDyQpRzLY8opCsoZssOgGWhNAI5lENkKkGpGlEAAAEeTrBH2/nBwABp2av9gQAU7QTEbHE Z/sCAAAAAARZWg== --------------000205000607070909000901-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 20:54:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 143AC6BF; Tue, 3 Dec 2013 20:54:55 +0000 (UTC) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id 763DF1188; Tue, 3 Dec 2013 20:54:53 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAMxDnlJbs7dX/2dsb2JhbABagwc4uTuBGhd0giUBAQU6HCMQCxgJJQ8qHgaIGAEIwTcXjn4HhDMDmBOBMZBjgyo7 Received: from 87.183-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.183.87]) by relay.skynet.be with ESMTP; 03 Dec 2013 21:54:47 +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 rB3Ksj4U016611; Tue, 3 Dec 2013 21:54:46 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Tue, 3 Dec 2013 21:54:45 +0100 From: Tijl Coosemans To: Jan Henrik Sylvester Subject: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131203215445.68b9bc4e@kalimero.tijl.coosemans.org> In-Reply-To: <529E3E6A.2090107@janh.de> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> <529E3E6A.2090107@janh.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Maho Nakata , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:54:55 -0000 On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: > On 12/01/2013 15:06, Tijl Coosemans wrote: > > On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: > >> On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: > >>> Trying to migrate to 10, I would like to keep octave. Have you found > >>> anything new? Having build the port and all dependencies with standard > >>> options, octave is segfaulting for me, too. Anyhow, I can run octave with: > >>> > >>> env LD_PRELOAD=/usr/lib/libc++.so.1 octave > >>> > >>> Some very light testing indicates that it is working. Of course, this is > >>> not ideal. > >>> > >>> Maybe this gives a clue how to fix the octave port properly. > >> > >> I have a preliminary patch for math/octave that I wanted to test on > >> redports first, but it is down at the moment so here it is. > > > > The tests were successful: > > https://redports.org/buildarchive/20131201105316-94935/ (octave) > > https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) > > The octave logs also contain the results of running the regression-test > > target. The output is the same on all FreeBSD versions. > > > > The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means > > the C++ code in math/octave is compiled with gcc46/libstdc++ which > > does not work if dependencies have been built with clang/libc++. > > > > The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a > > new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler > > together with the base system C/C++ compiler. > > With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and > 10.0-BETA4/amd64 with: > > checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 > checking whether we are using the GNU Fortran 77 compiler... no > checking whether f77 accepts -g... no > checking how to get verbose linking output from f77... configure: > WARNING: compilation failed > > checking for Fortran 77 libraries of f77... > checking for dummy main to link with Fortran 77 libraries... none > checking for Fortran 77 name-mangling scheme... configure: error: in > `/usr/ports/math/octave/work/octave-3.6.4': > configure: error: cannot compile a simple Fortran program > > Full logs attached (each with and without your patch). > > In both cases, it tries to use f77, while the original port uses gfortran46. > > Any idea what is wrong on my system? Do you define FC in make.conf maybe? From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 21:37:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5A643CE; Tue, 3 Dec 2013 21:37:45 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6005A13D7; Tue, 3 Dec 2013 21:37:45 +0000 (UTC) Received: from nb981.math (p57AEF3E3.dip0.t-ipconnect.de [87.174.243.227]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MK8g5-1Vn8BG0lkb-001P9A; Tue, 03 Dec 2013 22:37:43 +0100 Message-ID: <529E4F1E.4050001@janh.de> Date: Tue, 03 Dec 2013 22:37:34 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: libc++ vs. libstdc++ usage in the ports tree References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> <529E3E6A.2090107@janh.de> <20131203215445.68b9bc4e@kalimero.tijl.coosemans.org> In-Reply-To: <20131203215445.68b9bc4e@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:oAGNAr/vYoghxyvYzbi36Nz56TC4WlTqgxPst4+mOzx PfSXLrc0mUQCtPotmonu8tlO54AggQ8rbu0pEKoaPYn7a90xL1 oCHBKgM06j8Fc9tEmnVLWF8wHtgNjFU8q/nglIDvoyzJ4e+Pvg lcrGgcWdsQq7vFL/r3HvOEMaRuc2Jr3RzI+TYc427p0R2X4idi v5JCRQl/+KTWPDQb55Cbw7Vbpv1aZ322VXSIzQlHobnq2Er9+z 3WlRHA29EvaGghqTR9n4RG0wQimL3nItLfJJ3VgV4zjXju50Vh TIXaBirA/D6AZdxbVww8lgYdc09gbg9jHCKIvBJUGcAO1a+Jg= = X-Mailman-Approved-At: Tue, 03 Dec 2013 22:44:08 +0000 Cc: Maho Nakata , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 21:37:46 -0000 On 12/03/2013 21:54, Tijl Coosemans wrote: > On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: >> On 12/01/2013 15:06, Tijl Coosemans wrote: >>> On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: >>>> On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: >>>>> Trying to migrate to 10, I would like to keep octave. Have you found >>>>> anything new? Having build the port and all dependencies with standard >>>>> options, octave is segfaulting for me, too. Anyhow, I can run octave with: >>>>> >>>>> env LD_PRELOAD=/usr/lib/libc++.so.1 octave >>>>> >>>>> Some very light testing indicates that it is working. Of course, this is >>>>> not ideal. >>>>> >>>>> Maybe this gives a clue how to fix the octave port properly. >>>> >>>> I have a preliminary patch for math/octave that I wanted to test on >>>> redports first, but it is down at the moment so here it is. >>> >>> The tests were successful: >>> https://redports.org/buildarchive/20131201105316-94935/ (octave) >>> https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) >>> The octave logs also contain the results of running the regression-test >>> target. The output is the same on all FreeBSD versions. >>> >>> The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means >>> the C++ code in math/octave is compiled with gcc46/libstdc++ which >>> does not work if dependencies have been built with clang/libc++. >>> >>> The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a >>> new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler >>> together with the base system C/C++ compiler. >> >> With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and >> 10.0-BETA4/amd64 with: >> >> checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 >> checking whether we are using the GNU Fortran 77 compiler... no >> checking whether f77 accepts -g... no >> checking how to get verbose linking output from f77... configure: >> WARNING: compilation failed >> >> checking for Fortran 77 libraries of f77... >> checking for dummy main to link with Fortran 77 libraries... none >> checking for Fortran 77 name-mangling scheme... configure: error: in >> `/usr/ports/math/octave/work/octave-3.6.4': >> configure: error: cannot compile a simple Fortran program >> >> Full logs attached (each with and without your patch). >> >> In both cases, it tries to use f77, while the original port uses gfortran46. >> >> Any idea what is wrong on my system? > > Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: WITH_PKGNG=yes WITH_NEW_XORG=yes TEX_DEFAULT=texlive Cheers, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Tue Dec 3 23:24:07 2013 Return-Path: Delivered-To: freebsd-current@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 9F2A4276; Tue, 3 Dec 2013 23:24:07 +0000 (UTC) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by mx1.freebsd.org (Postfix) with ESMTP id CFA401AEE; Tue, 3 Dec 2013 23:24:06 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoGAMJnnlJbs7dX/2dsb2JhbABagwc4uG1OgRoXdIIlAQEFViMQCxgJJQ8qHgYTCYd8AQjBSBeOfgeEMwOQMYdigTGLLYU2gyo7 Received: from 87.183-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.183.87]) by relay.skynet.be with ESMTP; 04 Dec 2013 00:23:58 +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 rB3NNvoC017400; Wed, 4 Dec 2013 00:23:57 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 4 Dec 2013 00:23:57 +0100 From: Tijl Coosemans To: Jan Henrik Sylvester Subject: Re: libc++ vs. libstdc++ usage in the ports tree Message-ID: <20131204002357.203ea09d@kalimero.tijl.coosemans.org> In-Reply-To: <529E4F1E.4050001@janh.de> References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> <529E3E6A.2090107@janh.de> <20131203215445.68b9bc4e@kalimero.tijl.coosemans.org> <529E4F1E.4050001@janh.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/kCilWNwDVtwlEXWkOXXHhZq" Cc: Maho Nakata , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:24:07 -0000 --MP_/kCilWNwDVtwlEXWkOXXHhZq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote: > On 12/03/2013 21:54, Tijl Coosemans wrote: >> On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: >>> On 12/01/2013 15:06, Tijl Coosemans wrote: >>>> The tests were successful: >>>> https://redports.org/buildarchive/20131201105316-94935/ (octave) >>>> https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) >>>> The octave logs also contain the results of running the regression-test >>>> target. The output is the same on all FreeBSD versions. >>>> >>>> The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means >>>> the C++ code in math/octave is compiled with gcc46/libstdc++ which >>>> does not work if dependencies have been built with clang/libc++. >>>> >>>> The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a >>>> new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler >>>> together with the base system C/C++ compiler. >>> >>> With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and >>> 10.0-BETA4/amd64 with: >>> >>> checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 >>> checking whether we are using the GNU Fortran 77 compiler... no >>> checking whether f77 accepts -g... no >>> checking how to get verbose linking output from f77... configure: >>> WARNING: compilation failed >>> >>> checking for Fortran 77 libraries of f77... >>> checking for dummy main to link with Fortran 77 libraries... none >>> checking for Fortran 77 name-mangling scheme... configure: error: in >>> `/usr/ports/math/octave/work/octave-3.6.4': >>> configure: error: cannot compile a simple Fortran program >>> >>> Full logs attached (each with and without your patch). >>> >>> In both cases, it tries to use f77, while the original port uses gfortran46. >>> >>> Any idea what is wrong on my system? >> >> Do you define FC in make.conf maybe? > > No, besides some options (*_SET / *_UNSET) for some unrelated ports, I > only have got this in make.conf: Hmm, apparently FC is defined by sys.mk. I've attached a new patch. --MP_/kCilWNwDVtwlEXWkOXXHhZq Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=octave-fortran.patch Index: math/octave/Makefile =================================================================== --- math/octave/Makefile (revision 335568) +++ math/octave/Makefile (working copy) @@ -3,7 +3,7 @@ PORTNAME= octave PORTVERSION= 3.6.4 -PORTREVISION= 6 +PORTREVISION= 7 CATEGORIES= math MASTER_SITES= ftp://ftp.gnu.org/gnu/octave/ \ ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/ @@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/ umfpack.1:${PORTSDIR}/math/suitesparse \ glpk:${PORTSDIR}/math/glpk -USES= charsetfix gmake perl5 pkgconfig +USES= charsetfix fortran gmake perl5 pkgconfig USE_BZIP2= yes USE_PERL5= build USE_TEX= dvipsk:build @@ -74,8 +74,6 @@ BLAS= -lptf77blas LAPACK= -lalapack -lptcblas .endif -USE_FORTRAN= yes - OCTAVE_VERSION= ${PORTVERSION} GNU_HOST= ${ARCH}-portbld-freebsd${OSREL} PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST} @@ -140,7 +138,8 @@ post-install: ${ECHO_CMD} @dirrm share/octave >> ${WRKDIR}/PLIST cd ${WRKDIR} ; ${SED} -i -e "/PLIST/ r PLIST" ${TMPPLIST} -check: +check: regression-test +regression-test: build (cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check) .include Index: math/octave/files/patch-configure =================================================================== --- math/octave/files/patch-configure (revision 0) +++ math/octave/files/patch-configure (working copy) @@ -0,0 +1,11 @@ +--- configure.orig 2013-02-21 21:21:49.000000000 +0100 ++++ configure 2013-11-22 20:34:49.000000000 +0100 +@@ -58248,7 +58248,7 @@ + main () + { + +- std::unordered_map m; ++ std::unordered_map m; + + ; + return 0; Property changes on: math/octave/files/patch-configure ___________________________________________________________________ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: math/octave/files/patch-libgnu-math.in.h =================================================================== --- math/octave/files/patch-libgnu-math.in.h (revision 0) +++ math/octave/files/patch-libgnu-math.in.h (working copy) @@ -0,0 +1,11 @@ +--- libgnu/math.in.h.orig 2013-02-21 21:21:17.000000000 +0100 ++++ libgnu/math.in.h 2013-11-22 12:35:47.000000000 +0100 +@@ -17,7 +17,7 @@ + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +-#ifndef _@GUARD_PREFIX@_MATH_H ++#if 1 + + #if __GNUC__ >= 3 + @PRAGMA_SYSTEM_HEADER@ Property changes on: math/octave/files/patch-libgnu-math.in.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: math/octave/files/patch-liboctave-eigs-base.cc =================================================================== --- math/octave/files/patch-liboctave-eigs-base.cc (revision 0) +++ math/octave/files/patch-liboctave-eigs-base.cc (working copy) @@ -0,0 +1,11 @@ +--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.000000000 +0100 ++++ liboctave/eigs-base.cc 2013-11-22 20:19:19.000000000 +0100 +@@ -3832,7 +3832,7 @@ + bool cholB = 0, int disp = 0, int maxit = 300); + #endif + +-#ifndef _MSC_VER ++#if !defined(_MSC_VER) && !defined(__clang__) + template static octave_idx_type + lusolve (const SparseMatrix&, const SparseMatrix&, Matrix&); + Property changes on: math/octave/files/patch-liboctave-eigs-base.cc ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: Mk/Uses/fortran.mk =================================================================== --- Mk/Uses/fortran.mk (revision 0) +++ Mk/Uses/fortran.mk (working copy) @@ -0,0 +1,31 @@ +# $FreeBSD$ +# +# Establish Fortran-capable compiler as a build dependency +# +# MAINTAINER: fortran@FreeBSD.org +# +# Feature: fortran +# Usage: USES=fortran +# Valid ARGS: does not require args + +.if !defined(_INCLUDE_USES_FORTRAN_MK) +_INCLUDE_USES_FORTRAN_MK= yes + +.if defined(fortran_ARGS) +IGNORE= USES=fortran does not require args +.endif + +BUILD_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc +RUN_DEPENDS+= gfortran46:${PORTSDIR}/lang/gcc + +USE_BINUTILS= yes + +F77= gfortran46 +FC= gfortran46 +FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 +LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc46 + +CONFIGURE_ENV+= F77="${F77}" FC="${FC}" FFLAGS="${FFLAGS}" +MAKE_ENV+= F77="${F77}" FC="${FC}" FFLAGS="${FFLAGS}" + +.endif Property changes on: Mk/Uses/fortran.mk ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property --MP_/kCilWNwDVtwlEXWkOXXHhZq-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 01:12:02 2013 Return-Path: Delivered-To: freebsd-current@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 8E93180A for ; Wed, 4 Dec 2013 01:12:02 +0000 (UTC) Received: from nm24-vm1.access.bullet.mail.bf1.yahoo.com (nm24-vm1.access.bullet.mail.bf1.yahoo.com [216.109.115.176]) by mx1.freebsd.org (Postfix) with SMTP id 03CF11247 for ; Wed, 4 Dec 2013 01:12:01 +0000 (UTC) Received: from [66.196.81.163] by nm24.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2013 01:05:01 -0000 Received: from [98.138.104.98] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2013 01:05:01 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 04 Dec 2013 01:05:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1386119101; bh=qQTU55B+FweGYa8RzqshlxgPJjpwUa1ZLXAffx8IEKE=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject:References; b=QN4kfuejyIY4ddTCIKyXQXUpOiQ0TcCjn0dM7mab1dwiM6j8Nb3c6+SijDzy8+ZzfBtUUGUb5EQHMUlogpy7UC5MEzfwV3SKypaPIJeBv65vGEsZNZpcFZfNAq4yWmEqFxAs5N/LG55Oe5AxJ65e8kxzSL/uofsXElHO+Dgfhfs= X-Yahoo-Newman-Id: 731412.31196.bm@smtp118.sbc.mail.ne1.yahoo.com Message-ID: <731412.31196.bm@smtp118.sbc.mail.ne1.yahoo.com> Date: Wed, 4 Dec 2013 01:05:01 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vJpRO4oVM1ltV_9SMHn3DjMljffkmoeA0VFE77cZ6IhCOR4 bi9Hjr6zJ4GjEXoKjS322fLo7Cn9c1POmKMrc5TLVTnbrmnHmAFV8j0nvwvg ApbrU_3P3pVWlKu3.qLcZk6dgSESrb_bHFM8W4mQ9.Z2CFAwcFmB4ydJoa.6 fYkJeWX3GGOw_cLX4O_wx17HixxANjB6_1DdnrPCX8mNUHm71dfqwD91HHb4 W895ZBxYlJFkNciMOZsz8JBzu5IzAGn96kh9wiMCvmZjynzF0GnXTuOFUrG9 wbscRzmJVcDWw_OgzC22hg2MXPsu_R9G1uXP9bBa3W0P3PSes1euPbsvh.RA cplO5QErNgtYW5z0PBnTZhOxHMDiBMtPvzAx8KZ9VlRLx4.WWw3e0CzBFrtY OJAgv7qL7RtNrc7jFDX5DL_BlpPiLIrtr1e4yZBa96MTD6UAabQTYO1JVfV9 09347.iqvK1J_.KpT38YMb96f8.TVI8WWFqdIl2pKyruZMAa2WikEZLdssRt osEWF4GRqehkL.eBIMCcGc7p.Bd4ePeS_BiUYfhQt1JtopOTj98YtsMGCmC8 Cnpg2.BDIOB._MyZ0Zj4- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@96.28.178.143 with ) by smtp118.sbc.mail.ne1.yahoo.com with SMTP; 04 Dec 2013 01:05:01 +0000 UTC From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: FreeBSD 10.0-BETA4 now available References: <20131203161711.GO85910@glenbarber.us> Cc: Glen Barber , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 01:12:02 -0000 from Glen Barber (excerpt): > Changes between -BETA3 and -BETA4 include: - Add preliminary support for RTL8106E, RTL8168G, RTL8168GU, RTL8411B, and RTL8168EP. - Enable fingerprint checking in pkg(8) for FreeBSD-provided binary packages. - Remove the WITH_LIBICONV_COMPAT build option. - Update nvi to 2.1.2. - Various iconv(3) fixes. - Fix mergemaster -U by forcing FreeBSD 9 compatiblity in mtree when mtree is nmtree. - Fix to freebsd-update(8) in generating the list of old files/directories versus new files/directories (FreeBSD-EN-13:05.freebsd-update). Would preliminary support for RTL8106E, RTL8168G etc be the re(4) driver? Would these changes be already in HEAD, so if it doesn't work in HEAD on my system, it won't work in 10.0-BETA4? I believe nvi has no -V or --version switch that tells the version without doing anything else (I looked and tried). I noticed NetBSD-current had upgraded nvi but find it very difficult to find latest versions online. Tom From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 01:23:46 2013 Return-Path: Delivered-To: freebsd-current@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 21869C77; Wed, 4 Dec 2013 01:23:46 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1B4612EF; Wed, 4 Dec 2013 01:23:45 +0000 (UTC) Received: from nb981.math (p57AEF3E3.dip0.t-ipconnect.de [87.174.243.227]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lj7Ag-1VAq9I3CUo-00dPbS; Wed, 04 Dec 2013 02:23:43 +0100 Message-ID: <529E841B.7020803@janh.de> Date: Wed, 04 Dec 2013 02:23:39 +0100 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: libc++ vs. libstdc++ usage in the ports tree References: <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> <5283CA3C.3080201@FreeBSD.org> <352D9465-9840-43F0-A3A9-327DC12B0967@FreeBSD.org> <20131114144555.GA22093@troutmask.apl.washington.edu> <52963A90.4000201@janh.de> <20131127204556.2974a3f5@kalimero.tijl.coosemans.org> <20131201150640.12ea18c8@kalimero.tijl.coosemans.org> <529E3E6A.2090107@janh.de> <20131203215445.68b9bc4e@kalimero.tijl.coosemans.org> <529E4F1E.4050001@janh.de> <20131204002357.203ea09d@kalimero.tijl.coosemans.org> In-Reply-To: <20131204002357.203ea09d@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:+8UwTMrl2/oBPKM150IlbMTC781xTXjjDQqDZ++lA0O DOMS89FuSmMvJmGcKlSCKHJh2++czYwZlQpm3mK1LnIBfxwYlt rw5kDu7gplAejakanbrbznDzbAkaKyVDXg8C0OWCXnoR//2i/U UMXjC2NojXp39jXGcSNWTaGS0epdepQRdlkJh8h0hzIFC8mVxD LljcywqoR/DklW50ZGimNxpoTEN8c/qrUonHnQaJ7o4DikjHoV tJ1RgsTNFiA7xwBb7hPgRcVKBBtqTPgt0TCGiet4O2LJ2mgur7 kBKk6xk9NkN9DBfcBVjbvwMYJv1C5sxy1QF+Dlq8g7l0yHsIQ= = Cc: Maho Nakata , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 01:23:46 -0000 On 12/04/2013 00:23, Tijl Coosemans wrote: > On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote: >> On 12/03/2013 21:54, Tijl Coosemans wrote: >>> On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: >>>> On 12/01/2013 15:06, Tijl Coosemans wrote: >>>>> The tests were successful: >>>>> https://redports.org/buildarchive/20131201105316-94935/ (octave) >>>>> https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) >>>>> The octave logs also contain the results of running the regression-test >>>>> target. The output is the same on all FreeBSD versions. >>>>> >>>>> The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means >>>>> the C++ code in math/octave is compiled with gcc46/libstdc++ which >>>>> does not work if dependencies have been built with clang/libc++. >>>>> >>>>> The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a >>>>> new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler >>>>> together with the base system C/C++ compiler. >>>> >>>> With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and >>>> 10.0-BETA4/amd64 with: >>>> >>>> checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 >>>> checking whether we are using the GNU Fortran 77 compiler... no >>>> checking whether f77 accepts -g... no >>>> checking how to get verbose linking output from f77... configure: >>>> WARNING: compilation failed >>>> >>>> checking for Fortran 77 libraries of f77... >>>> checking for dummy main to link with Fortran 77 libraries... none >>>> checking for Fortran 77 name-mangling scheme... configure: error: in >>>> `/usr/ports/math/octave/work/octave-3.6.4': >>>> configure: error: cannot compile a simple Fortran program >>>> >>>> Full logs attached (each with and without your patch). >>>> >>>> In both cases, it tries to use f77, while the original port uses gfortran46. >>>> >>>> Any idea what is wrong on my system? >>> >>> Do you define FC in make.conf maybe? >> >> No, besides some options (*_SET / *_UNSET) for some unrelated ports, I >> only have got this in make.conf: > > Hmm, apparently FC is defined by sys.mk. I've attached a new patch. Ok, with the new patch, it compiles and packages on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64. From the new packages, the octave binaries were able to do some simple math. Thanks, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 02:21:13 2013 Return-Path: Delivered-To: freebsd-current@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 AF016B9B for ; Wed, 4 Dec 2013 02:21:13 +0000 (UTC) Received: from ibgw01in.cba.com.au (igwx10.cba.com.au [140.168.71.11]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2627816D9 for ; Wed, 4 Dec 2013 02:21:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cba.com.au; i=@cba.com.au; q=dns/txt; s=CBAdkim-110609; t=1386123673; x=1701483673; h=date:from:to:subject:message-id:mime-version; bh=48abeC9F6USygYoDJY1L3IO2Mpq/3DgB1mbEETzE+xA=; b=ECqGUNSlZGco1OZkrMpg2QYqHd7zTk4xDHMXD9FmIOlyKSQW5jZerihZ bYF5MLaoHAoPLvKk8uJskP0FSalVdw==; X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,821,1378821600"; d="scan'208";a="47610231" Received: from unknown (HELO imr02in1.cba.com.au) ([10.248.46.10]) by ibgw01.cba.com.au with ESMTP; 04 Dec 2013 13:20:00 +1100 Received: from unknown (HELO margz.perth.internal) ([10.138.102.216]) by imr02in1.cba.com.au with SMTP; 04 Dec 2013 13:20:00 +1100 Date: Wed, 4 Dec 2013 10:19:49 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Subject: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289) Message-ID: <20131204021949.GD28250@margz.perth.internal> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organisation: Commonwealth Bank Australia X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 02:21:13 -0000 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 KERNCONF: include GENERIC options DDB options ALT_BREAK_TO_DEBUGGER options ROUTETABLES=6 options VIMAGE makeoptions DEBUG=-g device pf device pflog device pfsync device carp Backtrace: (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff808c03e4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff80346077 in db_panic (addr=, have_addr=, count=, modif=) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff80345c8d in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #5 0xffffffff80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #6 0xffffffff80348370 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #7 0xffffffff808f9563 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 #8 0xffffffff80cf0612 in trap_fatal (frame=0xfffffe085bdeba60, eva=) at /usr/src/sys/amd64/amd64/trap.c:877 #9 0xffffffff80cf0929 in trap_pfault (frame=0xfffffe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 #10 0xffffffff80cf00b6 in trap (frame=0xfffffe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 #11 0xffffffff80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #12 0xffffffff80aca5e3 in pfioctl (dev=0x2, cmd=, addr=0xfffff803ec438000 "", flags=, td=) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 #13 0xffffffff807b9d5f in devfs_ioctl_f (fp=0xfffff80014d474b0, com=3417850886, data=0xfffff803ec438000, cred=, td=0xfffff80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #14 0xffffffff80910a1e in kern_ioctl (td=0xfffff80014e50920, fd=, com=2) at file.h:319 #15 0xffffffff8091079f in sys_ioctl (td=0xfffff80014e50920, uap=0xfffffe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 #16 0xffffffff80cf0f47 in amd64_syscall (td=0xfffff80014e50920, traced=0) at subr_syscall.c:134 #17 0xffffffff80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x0000000800dbac2a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) Let me know if anyone needs more debug output. -Alex ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 05:33:04 2013 Return-Path: Delivered-To: freebsd-current@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 D852B239; Wed, 4 Dec 2013 05:33:04 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id A0A73124C; Wed, 4 Dec 2013 05:33:04 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=UbGOdjJMTOnDdlSKs4VLEv47Nwxh2hlhayjdFxkzNJk= c=1 sm=1 a=QgsPjQDEkS0A:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=RJqw_aPojKgVHQL1HsIA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=FTMk2kdAwOzgLk5G:21 a=d8rgHe_gOL_iVths:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 03 Dec 2013 22:32:57 -0700 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 5F98780; Tue, 3 Dec 2013 21:32:56 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.7/8.14.7) with ESMTP id rB45Wu6r005147; Tue, 3 Dec 2013 21:32:56 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201312040532.rB45Wu6r005147@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: tcl & tk ports on FreeBSD 10 amd64 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Dec 2013 21:32:56 -0800 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 05:33:05 -0000 Hi, Sorry for cross posting but this concerns both lists. Over the last month or so I've been upgrading my prod infrastructure from 9 to 10. It's mostly complete except for a number of issues. One issue, just solved today (circumvented is a better word), is exmh crashing 10.0 on amd64 while on i386 there are no issues with exmh. It appears that the tcl and tk ports (all three of them, 8.4, 8.5, and 8.6) will panic 10.0 on amd64 (but not i386) when the ports are built with threading support. I haven't had a chance to look at the dump yet but I had a hunch to test the ports without threading support enabled, making the panic go away. If I don't get to it in time, here is what I haveFatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff80957aeb stack pointer = 0x28:0xfffffe00f17f9980 frame pointer = 0x28:0xfffffe00f17f99a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (idle: cpu2) trap number = 9 timeout stopping cpus panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f17f9510 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00f17f95c0 panic() at panic+0x153/frame 0xfffffe00f17f9640 trap_fatal() at trap_fatal+0x3a2/frame 0xfffffe00f17f96a0 trap() at trap+0x7bf/frame 0xfffffe00f17f98c0 calltrap() at calltrap+0x8/frame 0xfffffe00f17f98c0 --- trap 0x9, rip = 0xffffffff80957aeb, rsp = 0xfffffe00f17f9980, rbp = 0xfffffe 00f17f99a0 --- cpu_idle_hlt() at cpu_idle_hlt+0x2b/frame 0xfffffe00f17f99a0 cpu_idle() at cpu_idle+0x93/frame 0xfffffe00f17f99c0 sched_idletd() at sched_idletd+0x1ee/frame 0xfffffe00f17f9a70 fork_exit() at fork_exit+0x9a/frame 0xfffffe00f17f9ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00f17f9ab0 --- trap 0, rip = 0, rsp = 0xfffffe00f17f9b70, rbp = 0 --- Uptime: 4m42s Dumping 522 out of 5932 MB:..4%..13%..22%..31%..43%..53%..62%..71%..83%..92% so far, Tcl/tk are tickling some bug somewhere. Before anyone suggests memory, I've been able to reproduce this on an Intel Core i3 machine with 6 GB and an AMD X2 5000+, also with 6 GB, both in amd64 mode. Both systems are dual (or multi) boot. The bug does not exhibit itself in i386 mode. It also doesn't exhibit itself when tcl/tk are built without thread support. The only application I know of which tickles the bug is mail/exmh2 (I'm the maintainer) when using a threaded tcl/tk. My 11-CURRENT partition on my laptop is still i386 so I haven't been able to reproduce it under 11 with amd64. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 05:47:31 2013 Return-Path: Delivered-To: freebsd-current@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 7D8174EF for ; Wed, 4 Dec 2013 05:47:31 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 F201512FC for ; Wed, 4 Dec 2013 05:47:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB45lSuW067563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Dec 2013 09:47:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB45lSaT067562 for freebsd-current@freebsd.org; Wed, 4 Dec 2013 09:47:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Dec 2013 09:47:28 +0400 From: Gleb Smirnoff To: freebsd-current@freebsd.org Subject: Re: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289) Message-ID: <20131204054728.GE48919@FreeBSD.org> References: <20131204021949.GD28250@margz.perth.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131204021949.GD28250@margz.perth.internal> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 05:47:31 -0000 On Wed, Dec 04, 2013 at 10:19:49AM +0800, Wilkinson, Alex wrote: W> 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 W> W> KERNCONF: W> W> include GENERIC W> W> options DDB W> options ALT_BREAK_TO_DEBUGGER W> W> options ROUTETABLES=6 W> options VIMAGE W> W> makeoptions DEBUG=-g W> W> device pf W> device pflog W> device pfsync W> device carp W> W> W> Backtrace: W> W> (kgdb) bt W> #0 doadump (textdump=1) at pcpu.h:219 W> #1 0xffffffff808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 W> #2 0xffffffff808c03e4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 W> #3 0xffffffff80346077 in db_panic (addr=, have_addr=, count=, modif=) at /usr/src/sys/ddb/db_command.c:482 W> #4 0xffffffff80345c8d in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 W> #5 0xffffffff80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 W> #6 0xffffffff80348370 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 W> #7 0xffffffff808f9563 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 W> #8 0xffffffff80cf0612 in trap_fatal (frame=0xfffffe085bdeba60, eva=) at /usr/src/sys/amd64/amd64/trap.c:877 W> #9 0xffffffff80cf0929 in trap_pfault (frame=0xfffffe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 W> #10 0xffffffff80cf00b6 in trap (frame=0xfffffe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 W> #11 0xffffffff80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 W> #12 0xffffffff80aca5e3 in pfioctl (dev=0x2, cmd=, addr=0xfffff803ec438000 "", flags=, td=) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 W> #13 0xffffffff807b9d5f in devfs_ioctl_f (fp=0xfffff80014d474b0, com=3417850886, data=0xfffff803ec438000, cred=, td=0xfffff80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 W> #14 0xffffffff80910a1e in kern_ioctl (td=0xfffff80014e50920, fd=, com=2) at file.h:319 W> #15 0xffffffff8091079f in sys_ioctl (td=0xfffff80014e50920, uap=0xfffffe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 W> #16 0xffffffff80cf0f47 in amd64_syscall (td=0xfffff80014e50920, traced=0) at subr_syscall.c:134 W> #17 0xffffffff80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 W> #18 0x0000000800dbac2a in ?? () W> Previous frame inner to this frame (corrupt stack?) W> Current language: auto; currently minimal W> (kgdb) W> W> Let me know if anyone needs more debug output. I'd like to take a look at the core+kernel. Alternatively, you can provide me with precise reproduce recipe. What arguments to pfctl cause the crash? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 05:50:23 2013 Return-Path: Delivered-To: freebsd-current@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 9AB2B67F for ; Wed, 4 Dec 2013 05:50:23 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 1BBCA133F for ; Wed, 4 Dec 2013 05:50:22 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB45oKwe067577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Dec 2013 09:50:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB45oKJ3067576 for freebsd-current@freebsd.org; Wed, 4 Dec 2013 09:50:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Dec 2013 09:50:20 +0400 From: Gleb Smirnoff To: freebsd-current@freebsd.org Subject: Re: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289) Message-ID: <20131204055020.GF48919@FreeBSD.org> References: <20131204021949.GD28250@margz.perth.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131204021949.GD28250@margz.perth.internal> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 05:50:23 -0000 On Wed, Dec 04, 2013 at 10:19:49AM +0800, Wilkinson, Alex wrote: W> 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 W> W> KERNCONF: W> W> include GENERIC W> W> options DDB W> options ALT_BREAK_TO_DEBUGGER W> W> options ROUTETABLES=6 W> options VIMAGE W> W> makeoptions DEBUG=-g W> W> device pf W> device pflog W> device pfsync W> device carp W> W> W> Backtrace: W> W> (kgdb) bt W> #0 doadump (textdump=1) at pcpu.h:219 W> #1 0xffffffff808c0005 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 W> #2 0xffffffff808c03e4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 W> #3 0xffffffff80346077 in db_panic (addr=, have_addr=, count=, modif=) at /usr/src/sys/ddb/db_command.c:482 W> #4 0xffffffff80345c8d in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 W> #5 0xffffffff80345a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 W> #6 0xffffffff80348370 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 W> #7 0xffffffff808f9563 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:656 W> #8 0xffffffff80cf0612 in trap_fatal (frame=0xfffffe085bdeba60, eva=) at /usr/src/sys/amd64/amd64/trap.c:877 W> #9 0xffffffff80cf0929 in trap_pfault (frame=0xfffffe085bdeba60, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:699 W> #10 0xffffffff80cf00b6 in trap (frame=0xfffffe085bdeba60) at /usr/src/sys/amd64/amd64/trap.c:463 W> #11 0xffffffff80cd6e52 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 W> #12 0xffffffff80aca5e3 in pfioctl (dev=0x2, cmd=, addr=0xfffff803ec438000 "", flags=, td=) at /usr/src/sys/netpfil/pf/pf_ioctl.c:1289 W> #13 0xffffffff807b9d5f in devfs_ioctl_f (fp=0xfffff80014d474b0, com=3417850886, data=0xfffff803ec438000, cred=, td=0xfffff80014e50920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 W> #14 0xffffffff80910a1e in kern_ioctl (td=0xfffff80014e50920, fd=, com=2) at file.h:319 W> #15 0xffffffff8091079f in sys_ioctl (td=0xfffff80014e50920, uap=0xfffffe085bdeca40) at /usr/src/sys/kern/sys_generic.c:702 W> #16 0xffffffff80cf0f47 in amd64_syscall (td=0xfffff80014e50920, traced=0) at subr_syscall.c:134 W> #17 0xffffffff80cd713b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 W> #18 0x0000000800dbac2a in ?? () W> Previous frame inner to this frame (corrupt stack?) W> Current language: auto; currently minimal W> (kgdb) W> W> Let me know if anyone needs more debug output. Does the panic go away if you remove VIMAGE from kernel config? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 07:21:12 2013 Return-Path: Delivered-To: freebsd-current@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 2659C22F for ; Wed, 4 Dec 2013 07:21:12 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A2C03186F for ; Wed, 4 Dec 2013 07:21:11 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id q8so9329210lbi.12 for ; Tue, 03 Dec 2013 23:21:09 -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:content-type; bh=HTNd71vQcGoGM2AAAYdDGN07LvSO7VaIz2nGRlMuD34=; b=cp2qiTLmsjxUEa6ld/EwdkDqv+vIoUNTKaViWlPE0xGDD6nIVvvcB4WLlEmC2fHnMk LA1eXdbGwbB2nBH1u0Vt+zUk+pVUY6NtEmSGdAocDbBOHhfEtk1E5+iSEWpcgeQC+7h8 hS23xpbEN9JAInFSvd7bYVPJxNMK84fDg0lMt5lFqkbAxXhmgdPqeSmcKr0v8ExhWEAl 15WfYyaoRph9IRDP49yEt28b/yk7PqI9XY+JxaEwE9jkHR+XG+O17SOzwuQKEyRsKr5z YZkLnPy+l/XEHByDJGRlcRWIAjA1zCfwzPCGgyVLuSnUPLqe6EELzChcEdwLf11xmLu7 t2vQ== MIME-Version: 1.0 X-Received: by 10.112.168.66 with SMTP id zu2mr16027lbb.60.1386141669516; Tue, 03 Dec 2013 23:21:09 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.114.181.101 with HTTP; Tue, 3 Dec 2013 23:21:09 -0800 (PST) In-Reply-To: <20131204021949.GD28250@margz.perth.internal> References: <20131204021949.GD28250@margz.perth.internal> Date: Tue, 3 Dec 2013 23:21:09 -0800 X-Google-Sender-Auth: Ly9E71PzdGMBrDyiL70e8XZkS2k Message-ID: Subject: Re: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289) From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 07:21:12 -0000 On Tue, Dec 3, 2013 at 6:19 PM, Wilkinson, Alex wrote: > 10.0-BETA4 FreeBSD 10.0-BETA4 #0 r258860 > > KERNCONF: > > options VIMAGE > > makeoptions DEBUG=-g > > device pf > device pflog > device pfsync > device carp > > How badly do you need VIMAGE in your kernel config? There are multiple known problems with VIMAGE + pf. See: http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-December/001787.html We need to fix all these problems in FreeBSD, of course, but someone needs to spend the time on it. -- Craig From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 08:14:26 2013 Return-Path: Delivered-To: freebsd-current@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 5F77F368 for ; Wed, 4 Dec 2013 08:14:26 +0000 (UTC) Received: from frv189.fwdcdn.com (frv189.fwdcdn.com [212.42.77.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1340A1CA7 for ; Wed, 4 Dec 2013 08:14:25 +0000 (UTC) Received: from [10.10.2.23] (helo=frv198.fwdcdn.com) by frv189.fwdcdn.com with esmtp ID 1Vo7bA-0006WW-LZ for freebsd-current@freebsd.org; Wed, 04 Dec 2013 10:14:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=MxFTDPKco6yzmagjJ7VLj7mlpHWq1lzto6GuniC1IfU=; b=uG1I3UYTUlrvsjJeyjjg81EwVFEt4qt+3YANnpszBc8U0lG1TwxrexKGo+O7/vdZH5Pe1xOZafrUUpd/PrlDXKaGWE4mVpODMsjlP7h/mW+bfctsRpQy0Yn88WAZm1bw91dBJCo+Q3fWNppGMCvP8pC91aubnqDV5OKjYFKiKS0=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv198.fwdcdn.com with smtp ID 1Vo7b1-000FLd-8D for freebsd-current@freebsd.org; Wed, 04 Dec 2013 10:14:11 +0200 Date: Wed, 04 Dec 2013 10:14:09 +0200 From: Vladimir Sharun Subject: Re[2]: pf reply-to malfunction after r258468 (seems r258479) To: freebsd-current Current X-Mailer: mail.ukr.net 5.0 Message-Id: <1386144773.817703167.ax4sc7i4@frv45.ukr.net> In-Reply-To: <20131203181400.GA48919@glebius.int.ru> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> <1386093248.507170714.54to5ae0@frv45.ukr.net> <20131203181400.GA48919@glebius.int.ru> MIME-Version: 1.0 Received: from atz@ukr.net by frv45.ukr.net; Wed, 04 Dec 2013 10:14:10 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:14:26 -0000 Dear Gleb, Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V> Dear Gleb, V> Unfortunately can't boot both revisions kernel, it hangs on "trying to mount root from ssdzfs"  (which is my zfs root). V> Vladimir, You can run the kernel that boots, but update only sys/netpfil/pf directory to suspected revision(s), if you think this is related to changes in pf. -- Totus tuus, Glebius. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 08:16:56 2013 Return-Path: Delivered-To: freebsd-current@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 228EC4C1; Wed, 4 Dec 2013 08:16:56 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 9F60D1CCE; Wed, 4 Dec 2013 08:16:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB48GqYF068380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Dec 2013 12:16:52 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB48GqKf068379; Wed, 4 Dec 2013 12:16:52 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Dec 2013 12:16:52 +0400 From: Gleb Smirnoff To: Craig Rodrigues Subject: Re: 10-BETA{3,4} - Consistent Kernel Panics (pf_ioctl.c:1289) Message-ID: <20131204081652.GH48919@FreeBSD.org> References: <20131204021949.GD28250@margz.perth.internal> 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-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:16:56 -0000 On Tue, Dec 03, 2013 at 11:21:09PM -0800, Craig Rodrigues wrote: C> > KERNCONF: C> > C> > options VIMAGE C> > C> > makeoptions DEBUG=-g C> > C> > device pf C> > device pflog C> > device pfsync C> > device carp C> > C> > C> How badly do you need VIMAGE in your kernel config? C> There are multiple known problems with VIMAGE + pf. See: C> http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-December/001787.html C> C> We need to fix all these problems in FreeBSD, of course, but someone C> needs to spend the time on it. Right now we've got some improvements in the projects/pf branch. As soon as Nikos finished his round of pf+vimage cleanups, I'll merge that to head. However, this particular bug report hasn't yet proved to be tied to vimage. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 08:18:41 2013 Return-Path: Delivered-To: freebsd-current@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 C8E455DD for ; Wed, 4 Dec 2013 08:18:41 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (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 4E48E1CE0 for ; Wed, 4 Dec 2013 08:18:40 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB48IdMp068394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Dec 2013 12:18:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB48IdwR068393; Wed, 4 Dec 2013 12:18:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Dec 2013 12:18:39 +0400 From: Gleb Smirnoff To: Vladimir Sharun Subject: Re: pf reply-to malfunction after r258468 (seems r258479) Message-ID: <20131204081839.GI48919@FreeBSD.org> References: <1386064346.472994192.rxxiq2ll@frv45.ukr.net> <20131203115859.GU48919@FreeBSD.org> <1386093248.507170714.54to5ae0@frv45.ukr.net> <20131203181400.GA48919@glebius.int.ru> <1386144773.817703167.ax4sc7i4@frv45.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1386144773.817703167.ax4sc7i4@frv45.ukr.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:18:41 -0000 On Wed, Dec 04, 2013 at 10:14:09AM +0200, Vladimir Sharun wrote: V> Dear Gleb, V> Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. That is strange. Ok, let's count issue as resolved if it doesn't show up again. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 13:42:25 2013 Return-Path: Delivered-To: freebsd-current@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 ADA8A5EB for ; Wed, 4 Dec 2013 13:42:25 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F29F117B for ; Wed, 4 Dec 2013 13:42:25 +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 2D34F21495 for ; Wed, 4 Dec 2013 08:42:24 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 04 Dec 2013 08:42:24 -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:subject:date:in-reply-to :references; s=smtpout; bh=imLDJIU/diEkSGxS30UdSyFHMAE=; b=W/BXp unPH6Qage9N6CwjjLBcnys2Wcr0T6g06pj/aodnANkpRsAMPfXmmtwrPXNE1sFSB /qcQupf02/IJpHqNfRLvxn1ok+iwpR7b18NrBKQYloJ0pUCC8WCSg6yYHxCjDWzE o57BZJ90/6uvRTMHucOS42fqDlew3J7+0y7l6o= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 1103E104491; Wed, 4 Dec 2013 08:42:24 -0500 (EST) Message-Id: <1386164544.25171.55411873.4F5A7BD4@webmail.messagingengine.com> X-Sasl-Enc: jLpvlaWzHwVbZYxB6sEsJSj+sueB2PuicdKJ7zAf9vaD 1386164544 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c99dcdd8 Subject: Re: making PANIC_REBOOT_WAIT_TIME a tunable Date: Wed, 04 Dec 2013 07:42:24 -0600 In-Reply-To: <529C4446.6020508@freebsd.org> References: <529C4446.6020508@freebsd.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:42:25 -0000 On Mon, Dec 2, 2013, at 2:26, Colin Percival wrote: > Hi all, > > It seems that PANIC_REBOOT_WAIT_TIME has been a compile-time setting > forever; > and I can't see any reason for this, but I assume there was one... at > some > point in the distant past. > > The attached patch makes it a loader tunable and sysctl. My reason for > wanting > this is to make EC2 images reboot faster after a panic (not that it > happens > very often, of course) -- there's no point waiting for a key press at the > console because the EC2 console is output-only. > > Any objections? > I tend to cheat this problem by using watchdog on my hardware servers. This sounds quite convenient as I can't use watchdog in VMs... From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 15:29:45 2013 Return-Path: Delivered-To: freebsd-current@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 B5271282; Wed, 4 Dec 2013 15:29: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 8A80518A2; Wed, 4 Dec 2013 15:29:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92DD6B98A; Wed, 4 Dec 2013 10:29:44 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Wed, 4 Dec 2013 10:01:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> In-Reply-To: <933AFE5F-295B-41E0-9D43-14926CC6480D@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201312041001.38447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Dec 2013 10:29:44 -0500 (EST) Cc: jb , David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:29:45 -0000 On Friday, November 29, 2013 6:16:01 am David Chisnall wrote: > > On 28 Nov 2013, at 15:13, jb wrote: > > > Luigi Rizzo iet.unipi.it> writes: > > > >> ... > >> But I don't understand why you find ksize()/malloc_usable_size() dangerous. > >> ... > > > > The original crime is commited when *usable size* (an implementation detail) > > is exported (leaked) to the caller. > > To be blunt, when a caller requests memory of certain size, and its request is > > satisfied, then it is not its business to learn details beyond that (and they > > should not be offered as well). > > The API should be sanitized, in kernel and user space. > > Otherwise, all kind of charlatans will try to play hair-raising games with it. > > If the caller wants to track the *requested size* programmatically, it is its > > business to do it and it can be done very easily. > > > > Some of these guys got it perfectly right: > > http://stackoverflow.com/questions/5813078/is-it-possible-to-find-the-memory-allocated-to-the-pointer-without-searching-fo > > I disagree. I've encountered several occasions where either locality > doesn't matter so much or I know the pointer is aliased, and I'd like > increase the size of a relatively large allocation. I have two choices: > > - Call realloc(), potentially copying a lot of data > - Call malloc(), and chain two (or more) allocations together. > > What I'd like to do is call realloc() if it's effectively free, or call > malloc() in other cases. > > The malloc_useable_size() API is wrong though. In the kernel, realloc() > already takes a flag and a M_DONTALLOCATE would make more sense, enlarging > the allocation if it can be done without doing the allocate-copy-free dance, > but returning NULL and leaving the allocation unmodified if not. This sounds sensible to me. There might be cases where you'd like to know how much you can grow an allocation by "for free", and M_DONTALLOCATE doesn't help you with that. In general, I don't like malloc_usable_size(). OTOH, this is C, not C# or Python. Foot-shooting is permitted. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 15:42:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278029C5 for ; Wed, 4 Dec 2013 15:42:44 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0: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 DAA9319E6 for ; Wed, 4 Dec 2013 15:42:43 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id hz11so11636617vcb.31 for ; Wed, 04 Dec 2013 07:42:43 -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=u07zXVaRVUUaFJliT2fTE9PM3wU6vRDLgrNQQwezsjU=; b=Jksc9I8eOGRoSenqU9Ukvb5sxdVwg08Wsfj1/S3okCO7v4Vk0iJYm41JwdjlPW5yAi 0nHdXa3+Cv4i9Gl130P32eO9iFdchfEvdg6Lomhv2JHAF0usa1mXJep60rei1NVAreD1 buHgGXTkT56ZYtAl7UHBi+hE6rG+tCOvhfZD6Fph21pFLBMlc4Wo7k9tjQaiFwpnfGU0 3LrVWCT06F280FOmvl8lutdh8xbNL126cbdPZNI/5E4MNgNVZMiaWEAc/G+xQNjDwoKw 2cvxZzjqEwbmZOL9ogmpdfMc4PHk4O2aLz1N/bAVEVkEOcc6J0Xb2z3rSsn625PvOLmz WNeg== MIME-Version: 1.0 X-Received: by 10.58.67.168 with SMTP id o8mr9645864vet.22.1386171763049; Wed, 04 Dec 2013 07:42:43 -0800 (PST) Received: by 10.58.37.135 with HTTP; Wed, 4 Dec 2013 07:42:42 -0800 (PST) Date: Wed, 4 Dec 2013 10:42:42 -0500 Message-ID: Subject: unbound is extremely slow From: Shawn Webb To: FreeBSD-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:42:44 -0000 So I have unbound running in a vnet jail. Doing a lookup with `host` is pretty responsive, but Chromium's lookups are extremely slow (taking around 30 seconds to resolve). I'm running pretty much a stock config. I've tried turning off DNSSEC, but that doesn't help any. I have num-threads set to 4, though I have 8 cores on this box. I've pasted my config below. Thanks, Shawn server: username: unbound directory: /var/unbound chroot: /var/unbound pidfile: /var/run/local_unbound.pid #auto-trust-anchor-file: /var/unbound/root.key logfile: /var/unbound/unbound.log log-time-ascii: yes log-queries: yes verbosity: 2 interface: 0.0.0.0 interface: ::0 access-control: 0.0.0.0/0 allow access-control: ::0/0 allow prefetch: yes num-threads: 4 include: /var/unbound/forward.conf From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 16:01:32 2013 Return-Path: Delivered-To: freebsd-current@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 6C0D710E; Wed, 4 Dec 2013 16:01:32 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 408751B2F; Wed, 4 Dec 2013 16:01:32 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id rB4G1UTE040663; Wed, 4 Dec 2013 11:01:30 -0500 (EST) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at mail.pix.net Message-ID: <529F51DA.1040703@pix.net> Date: Wed, 04 Dec 2013 11:01:30 -0500 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: FreeBSD-Current Subject: panic on sparc64 running 10-beta4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sparc64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:01:32 -0000 I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4 install image today. Installation went fine. I rebooted the machine, and then went to get a fresh ports tree, and the machine panic'd: root@host:/usr/ports # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Dec 3 19:06:18 EST 2013: 43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of 69 MB 3225 kBps 00m22s Extracting snapshot... done. Verifying snapshot integrity... panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 6m59s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x40000000: 1073741824 bytes ... ok chunk at 0x80000000: 1073741824 bytes ... ok chunk at 0xc0000000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... And then it panic'd again when attempting to run 'savecore'! (I typed a after it printed out the line about writing the core file, that's where the "load: 0.72 ..." line came from...) savecore: reboot after panic: trap: illegal instruction (kernel) Dec 4 10:49:45 host savecore: reboot after panic: trap: illegal instruction (kernel) savecore: writing core to /var/crash/vmcore.0 load: 0.72 cmd: savecore 906 [physrd] 13.66r 2.75u 2.31s 27% 3192k vmcore.0 6.5% panic: trap: fast data access mmu miss (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc08836d4 at trap+0x554 Uptime: 1m58s Dumping 4096 MB (4 chunks) chunk at 0: 1073741824 bytes ... ok chunk at 0x40000000: 1073741824 bytes ... ok chunk at 0x80000000: 1073741824 bytes ... ok chunk at 0xc0000000: 1073741824 bytes ... ok Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Something's rotten with the 10-beta4 binaries for sparc64. -Kurt From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 16:26:30 2013 Return-Path: Delivered-To: freebsd-current@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 59618B67 for ; Wed, 4 Dec 2013 16:26:30 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 2A3711DB0 for ; Wed, 4 Dec 2013 16:26:29 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rB4GQOrr012482 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 08:26:27 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <529F57AA.1000402@freebsd.org> Date: Thu, 05 Dec 2013 00:26:18 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Shawn Webb , FreeBSD-current Subject: Re: unbound is extremely slow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:26:30 -0000 On 12/4/13, 11:42 PM, Shawn Webb wrote: > So I have unbound running in a vnet jail. Doing a lookup with `host` is > pretty responsive, but Chromium's lookups are extremely slow (taking around > 30 seconds to resolve). I'm running pretty much a stock config. I've tried > turning off DNSSEC, but that doesn't help any. I have num-threads set to 4, > though I have 8 cores on this box. I've pasted my config below. get a Ktrace of the unbount process along with a a matching simultaneous tcpdump of whatever interface your packets are coming in through. by matching the incoming and outgoing packets with the socket activity, you should be able to isolate what component is taking all the time. > > Thanks, > > Shawn > > server: > username: unbound > directory: /var/unbound > chroot: /var/unbound > pidfile: /var/run/local_unbound.pid > #auto-trust-anchor-file: /var/unbound/root.key > logfile: /var/unbound/unbound.log > log-time-ascii: yes > log-queries: yes > verbosity: 2 > interface: 0.0.0.0 > interface: ::0 > access-control: 0.0.0.0/0 allow > access-control: ::0/0 allow > prefetch: yes > num-threads: 4 > > include: /var/unbound/forward.conf > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Dec 4 21:22:14 2013 Return-Path: Delivered-To: freebsd-current@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 076FA501; Wed, 4 Dec 2013 21:22:14 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C23D1239; Wed, 4 Dec 2013 21:22:13 +0000 (UTC) Received: from BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 21:22:05 +0000 Received: from BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.158]) by BL2PR03MB210.namprd03.prod.outlook.com ([169.254.1.158]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 21:22:05 +0000 From: "Abhishek Gupta (LIS)" To: "freebsd-current@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Hyper-V Drivers Not Included in i386 ISO Thread-Topic: Hyper-V Drivers Not Included in i386 ISO Thread-Index: AQHO73pU4qFQham3Nk6nuDQj6C//0ppBX/wAgAAAJTCAAAKigIAAAB4ggABF94CAARaIa4AADSgAgAAD/ICAAauDsIAAEnow Date: Wed, 4 Dec 2013 21:22:04 +0000 Message-ID: <4fa6849bbb18403f8d30d5ab3a3a1c9c@BL2PR03MB210.namprd03.prod.outlook.com> References: <0fb7339604164487a4b200c364724e20@BL2PR03MB210.namprd03.prod.outlook.com> <529CF178.1000500@freebsd.org> <529CF3CD.2030509@freebsd.org> <606ef6c4b4f24fe4bd39506efc5f54be@BL2PR03MB210.namprd03.prod.outlook.com>, <529D2E97.7000604@freebsd.org> <529E2346.8040209@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(83322001)(81686001)(56776001)(54316002)(90146001)(47446002)(56816005)(74502001)(81816001)(74706001)(53806001)(4396001)(2656002)(49866001)(76576001)(54356001)(77982001)(33646001)(77096001)(76796001)(59766001)(76786001)(87936001)(83072001)(74662001)(85852002)(31966008)(85306002)(69226001)(65816001)(80022001)(81542001)(85806002)(76482001)(79102001)(50986001)(81342001)(47976001)(47736001)(74366001)(80976001)(51856001)(63696002)(87266001)(74316001)(46102001)(74876001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB210.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Wed, 04 Dec 2013 22:03:40 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:22:14 -0000 --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, It appears that Hyper-V drivers are not part of the FreeBSD 10 i386 ISO by = default. Please could someone help us include the attached patch in FreeBSD= 10? This will save a lot of time and headache for FreeBSD 10 i386 users. W= e have built a private ISO and have tested the patch locally and it seems t= o work. Unfortunately we do not have a committed maintainer at our end so a= re looking for some help. Please let us know if someone could lend a hand. Thanks, Abhishek --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_ Content-Type: application/octet-stream; name="i386_patch.patch" Content-Description: i386_patch.patch Content-Disposition: attachment; filename="i386_patch.patch"; size=1927; creation-date="Wed, 04 Dec 2013 20:17:46 GMT"; modification-date="Wed, 04 Dec 2013 20:17:46 GMT" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9jb25mL2ZpbGVzLmkzODYKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2NvbmYvZmlsZXMu aTM4NgkocmV2aXNpb24gMjU4OTEyKQorKysgc3lzL2NvbmYvZmlsZXMuaTM4Ngkod29ya2luZyBj b3B5KQpAQCAtMjIxLDYgKzIyMSwxOCBAQAogZGV2L2h3cG1jL2h3cG1jX3Bwcm8uYwkJb3B0aW9u YWwgaHdwbWMKIGRldi9od3BtYy9od3BtY190c2MuYwkJb3B0aW9uYWwgaHdwbWMKIGRldi9od3Bt Yy9od3BtY194ODYuYwkJb3B0aW9uYWwgaHdwbWMKK2Rldi9oeXBlcnYvbmV0dnNjL2h2X25ldF92 c2MuYyAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgICAgICAgIGh5cGVydgorZGV2 L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMgICAgICAgICAgICAgICBvcHRp b25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L25ldHZzYy9odl9ybmRpc19maWx0ZXIuYyAg ICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAgICBoeXBlcnYKK2Rldi9oeXBlcnYvc3Rv cmRpc2VuZ2FnZS9odl9hdGFfcGNpX2Rpc2VuZ2FnZS5jICAgICAgICAgb3B0aW9uYWwgICAgICAg IGh5cGVydgorZGV2L2h5cGVydi9zdG9ydnNjL2h2X3N0b3J2c2NfZHJ2X2ZyZWVic2QuYyAgICAg ICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L3V0aWxpdGllcy9odl91 dGlsLmMgICAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAgICBoeXBlcnYKK2Rl di9oeXBlcnYvdm1idXMvaHZfY2hhbm5lbC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0 aW9uYWwgICAgICAgIGh5cGVydgorZGV2L2h5cGVydi92bWJ1cy9odl9jaGFubmVsX21nbXQuYyAg ICAgICAgICAgICAgICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2CitkZXYvaHlwZXJ2L3Zt YnVzL2h2X2Nvbm5lY3Rpb24uYyAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsICAgICAg ICBoeXBlcnYKK2Rldi9oeXBlcnYvdm1idXMvaHZfaHYuYyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgb3B0aW9uYWwgICAgICAgIGh5cGVydgorZGV2L2h5cGVydi92bWJ1cy9odl9yaW5n X2J1ZmZlci5jICAgICAgICAgICAgICAgICAgICAgICBvcHRpb25hbCAgICAgICAgaHlwZXJ2Citk ZXYvaHlwZXJ2L3ZtYnVzL2h2X3ZtYnVzX2Rydl9mcmVlYnNkLmMgICAgICAgICAgICAgICAgIG9w dGlvbmFsICAgICAgICBoeXBlcnYKIGRldi9pY2h3ZC9pY2h3ZC5jCQlvcHRpb25hbCBpY2h3ZAog ZGV2L2lmX25kaXMvaWZfbmRpcy5jCQlvcHRpb25hbCBuZGlzCiBkZXYvaWZfbmRpcy9pZl9uZGlz X3BjY2FyZC5jCW9wdGlvbmFsIG5kaXMgcGNjYXJkCkluZGV4OiBzeXMvaTM4Ni9jb25mL0dFTkVS SUMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc3lzL2kzODYvY29uZi9HRU5FUklDCShyZXZpc2lvbiAyNTg5MTIp CisrKyBzeXMvaTM4Ni9jb25mL0dFTkVSSUMJKHdvcmtpbmcgY29weSkKQEAgLTM0Niw2ICszNDYs OSBAQAogZGV2aWNlCQl2aXJ0aW9fc2NzaQkjIFZpcnRJTyBTQ1NJIGRldmljZQogZGV2aWNlCQl2 aXJ0aW9fYmFsbG9vbgkjIFZpcnRJTyBNZW1vcnkgQmFsbG9vbiBkZXZpY2UKIAorIyBIeXBlclYg ZHJpdmVycworZGV2aWNlICAgICAgICAgIGh5cGVydiAgICAgICAgICAjIEh5cGVyViBkcml2ZXJz CisKICMgWGVuIEhWTSBHdWVzdCBPcHRpbWl6YXRpb25zCiAjIE5PVEU6IFhFTkhWTSBkZXBlbmRz IG9uIHhlbnBjaS4gIFRoZXkgbXVzdCBiZSBhZGRlZCBvciByZW1vdmVkIHRvZ2V0aGVyLgogb3B0 aW9ucyAJWEVOSFZNCQkjIFhlbiBIVk0ga2VybmVsIGluZnJhc3RydWN0dXJlCg== --_002_4fa6849bbb18403f8d30d5ab3a3a1c9cBL2PR03MB210namprd03pro_-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 5 06:21:20 2013 Return-Path: Delivered-To: freebsd-current@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 BAB3924F; Thu, 5 Dec 2013 06:21:20 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B16A104B; Thu, 5 Dec 2013 06:21:20 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id v10so24112660pde.0 for ; Wed, 04 Dec 2013 22:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=P05zZko8db4pnU31AiurwEtSLKxWDSGgEnCheOzzHM8=; b=JaQBRSHfObDQcMby423i4C+h1JX8et0wwBdSwLuIi8iITZ7xlEAIzibVbmrI8P+SlK +Bg3beEVsPugxTtU2kvbqIJSasA4NCVDNULZTB6YI8dbXNP7U7vn6HBKAwDmwVRT9P9g 8GgHonEaXgtRx1vBlPz1UJUFT8Nb4y4d8sqzlc8Ip0els7RSlkrfocUxsCqKKQZ/MvGx 8xM3ipo+07GKRHvuwW/KSiJ4r0unByWAUzUOcIF9BH6012tiDVaPIkIWAOsP/fmIgQFs YkCTNA8NyOrAoRs7lBJXLGqB16GHuC6w6CHw8BPT8ILYqYj2Tlthqr+xPhdwNSGsYe/2 u0eQ== X-Received: by 10.66.13.138 with SMTP id h10mr22588163pac.148.1386224480066; Wed, 04 Dec 2013 22:21:20 -0800 (PST) Received: from zhabar.gateway.2wire.net (76-253-2-5.lightspeed.sntcca.sbcglobal.net. [76.253.2.5]) by mx.google.com with ESMTPSA id ef10sm163680886pac.1.2013.12.04.22.21.18 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 04 Dec 2013 22:21:19 -0800 (PST) Sender: Justin Hibbits Date: Wed, 4 Dec 2013 22:21:13 -0800 From: Justin Hibbits To: FreeBSD Current , FreeBSD PowerPC ML Subject: Request for testing an alternate branch Message-ID: <20131204222113.39fb23dd@zhabar.gateway.2wire.net> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; powerpc64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 06:21:20 -0000 I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. However, it does touch several drivers, turning them into "early drivers", such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't think that it would impact x86 at all (testing is obviously required), because the nexus is not an EARLY_DRIVER_MODULE, so all devices would be handled at the same pass. But, I do know the sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be impacted. Also, any comments are of course welcome. Technical concerns are obviously welcome, and I will try to address everything. Thanks, Justin From owner-freebsd-current@FreeBSD.ORG Thu Dec 5 21:30:15 2013 Return-Path: Delivered-To: freebsd-current@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 4F3ED907 for ; Thu, 5 Dec 2013 21:30:15 +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 066581DB6 for ; Thu, 5 Dec 2013 21:30:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VogUl-0006c0-Tq for freebsd-current@freebsd.org; Thu, 05 Dec 2013 22:30:06 +0100 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Dec 2013 22:30:03 +0100 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Dec 2013 22:30:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: jb Subject: Re: [RFC] how to get the size of a malloc(9) block ? Date: Thu, 5 Dec 2013 21:29:41 +0000 (UTC) Lines: 22 Message-ID: References: <52995C15.7010903@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 21:30:15 -0000 jb gmail.com> writes: > ... > So far, the options could be as follows: > - realloc_flags(p, s, option) > where option is one or a combination (where appropriate) of: > REALLOCF_ANY - default (move or no-move; regular > realloc()) Actually, the REALLOCF_ANY flag is not needed to be able to call default behavior, like in realloc_flags(p, s). > REALLOCF_NO_MOVE - no-move > REALLOCF_ELASTIC - combined with REALLOCF_NO_MOVE > REALLOCF_FORCE - combined with REALLOCF_NO_MOVE > REALLOCF_FALLBACK_ANY - combined with REALLOCF_NO_MOVE or its > derivatives like REALLOCF_ELASTIC, etc So, the REALLOCF_FALLBACK_ANY could be just renamed to REALLOCF_DEFAULT. This way we reduced the number of option tags to four :-) jb From owner-freebsd-current@FreeBSD.ORG Fri Dec 6 03:04:33 2013 Return-Path: Delivered-To: freebsd-current@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 67052F0; Fri, 6 Dec 2013 03:04:33 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7BF133A; Fri, 6 Dec 2013 03:04:32 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id eh20so39634lab.4 for ; Thu, 05 Dec 2013 19:04:29 -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=mm46h5ABagl0FCh8JpvgvRzoQH2L1l1AWnt4Tz+UZ3s=; b=FX2egA1tHxz2DbTswccBj2H9zS1iSgk2BW8PI4eK/xa2zMhDL8jvWRA0lPNf+sWsFD 8+cg15Xe/tNrLLAg0SNt9YIHnlMvzOWgpSIRWhGnbMqWNzKYKYoDBGJee4dFKRwkh6Uh trg1L5vy/2vFtnp6hPYPvv3SFLVWI5KeQlYVFoDPg8cOUGm6Oj8i/TSel1cDJVf8mMf4 0o1yGvAclB4x0NoXChxW0rAdASsFcy+RO6vSKVM0kiejyWcr58BDe/g15mCCLK0bPVlM dOOLBQinezRSfVCsO4HqwQHzW/V4Ov+YNGkpWlqwB8QKXM9QeXsdsLQCj/sFoxEHLR+Z PZ7w== MIME-Version: 1.0 X-Received: by 10.152.234.170 with SMTP id uf10mr238362lac.43.1386299069530; Thu, 05 Dec 2013 19:04:29 -0800 (PST) Received: by 10.114.166.163 with HTTP; Thu, 5 Dec 2013 19:04:29 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Fri, 6 Dec 2013 11:04:29 +0800 Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Sepherosa Ziehau To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 03:04:33 -0000 On Tue, Dec 3, 2013 at 5:41 AM, Adrian Chadd wrote: > > On 2 December 2013 03:45, Sepherosa Ziehau wrote: > > > > On Mon, Dec 2, 2013 at 1:02 PM, Adrian Chadd wrote: > > > >> Ok, so given this, how do you guarantee the UTHREAD stays on the given > >> CPU? You assume it stays on the CPU that the initial listen socket was > >> created on, right? If it's migrated to another CPU core then the > >> listen queue still stays in the original hash group that's in a netisr > >> on a different CPU? > > > > As I wrote in the above brief introduction, Dfly currently relies on the > > scheduler doing the proper thing (the scheduler does do a very good job > > during my tests). I need to export certain kind of socket option to make > > that information available to user space programs. Force UTHREAD binding in > > kernel is not helpful, given in reverse proxy application, things are > > different. And even if that kind of binding information was exported to > > user space, user space program still would have to poll it periodically (in > > Dfly at least), since other programs binding to the same addr/port could > > come and go, which will cause reorganizing of the inp localgroup in the > > current Dfly implementation. > > Right. I kinda gathered that. It's fine, I was conceptually thinking > of doing some thead pinning into this anyway. > > How do you see this scaling on massively multi-core machines? Like 32, > 48, 64, 128 cores? I had some vague handwav-y notion of maybe limiting We do have a 48 core box. It is mainly used for package building and other stuffs. I didn't run network stress tests on it. However, we do address some message passing problems on it which will not be unveiled on 8 cpu boxes. > the concept of pcbgroup hash / netisr threads to a subset of CPUs, or > have them be able to float between sockets but only have 1 (or n, Floating around may be good, but by pinning netisr to a specific CPU you could enjoy lockless per-cpu data. > maybe) per socket. Or just have a fixed, smaller pool. The idea then We used to have dedicated threads for UDP and TCP processing, but it turns out that one netisr per cpu works best in Dfly. You probably need to try and measure before deciding to move to 1 or N netisrs per cpu. Best Regards, sephe > is the scheduler would need to be told that a given userland > thread/process belongs to a given netisr thread, and to schedule them > on the same CPU when possible. > > Anyway, thanks for doing this work. I only wish that you'd do it for > FreeBSD. :-) > > > > -adrian -- Tomorrow Will Never Die From owner-freebsd-current@FreeBSD.ORG Fri Dec 6 03:50:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BF7C194; Fri, 6 Dec 2013 03:50:59 +0000 (UTC) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E0B21669; Fri, 6 Dec 2013 03:50:59 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id gc15so119188qeb.35 for ; Thu, 05 Dec 2013 19:50:58 -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=J41ZYyv2zM12gpm4hTJRsBZIJO9j6ai5ubyi0NvaAhQ=; b=bAT6sFNJnbcw8+8RESL27KPy3tmRymlOWsfAsiBp9OTBi1Hk6mjcJSnIp5KCUExQbk 6nkdztjH/VR2pXgLmwf194RU9HEVZFvKFfKYKcm3Xjt0ktE9W7VqHtQ7pz5ZQfvJYrOw pdCUziOT+7Jdt3Min6Hm+lJb33/fK0vF8q04oZeKPQ3ZRN6OCvtLB52DXZQ09j6WEEes LEfFGPothrY8eQy4cH4U0pv/nD3W4h4sW3bJCehQSon0e8FjTiHD9DAsQ1x8hm+zbfUU xyBO2D5FrCDKQW8wPDS/NyMEPjikV+f39LHz9mx867vrn6CsLXXiYgLqzRxScDP6LmK1 3jeA== MIME-Version: 1.0 X-Received: by 10.49.116.141 with SMTP id jw13mr2419321qeb.2.1386301858239; Thu, 05 Dec 2013 19:50:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Thu, 5 Dec 2013 19:50:58 -0800 (PST) In-Reply-To: References: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org> Date: Thu, 5 Dec 2013 19:50:58 -0800 X-Google-Sender-Auth: BJDVu1NITTCeRaUA2CYm0PA57Pw Message-ID: Subject: Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour From: Adrian Chadd To: Sepherosa Ziehau Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ermal_Lu=E7i?= , freebsd-net , Oleg Moskalenko , Tim Kientzle , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 03:50:59 -0000 I was thinking of n netisrs per m CPUs, where n < m; or maybe 1 netisr for m CPUs, where m is less than the total number. Having 48 cores contending on netisr stuff is a bit crazy. It's highly unlikely you need that many cores doing packet pushing. -a From owner-freebsd-current@FreeBSD.ORG Fri Dec 6 19:40:44 2013 Return-Path: Delivered-To: freebsd-current@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 03F6CBFA; Fri, 6 Dec 2013 19:40:44 +0000 (UTC) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008: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 68A0919CB; Fri, 6 Dec 2013 19:40:43 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id 6so462105bkj.24 for ; Fri, 06 Dec 2013 11:40:41 -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:content-type; bh=x+GF19EtDl338fl4rJ5X9FI6uDdzdZvt72n5UVwu8pQ=; b=dt3oiExMRjpTNn/kOAxEuUM9vMiUhXkhsGjwziAFhv52BsvNbmJNJz/I7akuq/cGm4 D4pc/3+fHuA4rF3ite05tFhVIyalllVB15mtRcwg25i6c8495rpl8xXDhf4LN5XdyBEv nlkaofuTpeY9bVpr/8+rx0DA0wXLICzh2LDOcUlPpNtZzpFQSduonI4STyachEcEtbQ2 N9tieTTytgLzhKXYbcUWcywiZOA+zmxN64nNsciQuK1CjAnib/vYLDDipz12s5RoNwLj v747qCUx7j213bCF2w0ugelxbEE5c6MKzsVFt449DrjzWG6qczaq4SJr5EUIfq3Bkhkp Z1pQ== MIME-Version: 1.0 X-Received: by 10.204.238.195 with SMTP id kt3mr241bkb.169.1386358841671; Fri, 06 Dec 2013 11:40:41 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.205.90.136 with HTTP; Fri, 6 Dec 2013 11:40:41 -0800 (PST) In-Reply-To: <20131204221956.07c27546@zhabar.gateway.2wire.net> References: <20131204221956.07c27546@zhabar.gateway.2wire.net> Date: Fri, 6 Dec 2013 11:40:41 -0800 X-Google-Sender-Auth: VJ8mCf7ImvEBsfcdUh7pK4bOjas Message-ID: Subject: Re: Request for testing an alternate branch From: Justin Hibbits To: FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:40:44 -0000 On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits wrote: > I've been working on the projects/pmac_pmu branch for some time now to > add suspend/resume as well as CPU speed change for certain PowerPC > machines, about a year since I created the branch, and now it's stable > enough that I want to merge it into HEAD, hence this request. However, > it does touch several drivers, turning them into "early drivers", such > that they can be initialized, and suspended and resumed at a different > time. Saying that, I do need testing from other architectures, to make > sure I haven't broken anything. > > The technical details: > > To get proper ordering, I've extended the bus_generic_suspend() and > bus_generic_resume() to do multiple passes. Devices which cannot be > enabled or disabled at the current pass level would return an EAGAIN. > This could possibly cause problems, since it's an addition to an > existing API rather than a new API to run along side it, so it needs a > great deal of testing. It works fine on PowerPC, but I don't have any > i386/amd64 or sparc64 hardware to test it on, so would like others who > do to test it. I don't thin > > Also, any comments are of course welcome. Technical concerns are > obviously welcome, and I will try to address everything. > > Thanks, > > Justin Thanks to hrs@, images are now available for the pmac_pmu project on allbsd for i386, amd64, sparc64, and ia64: https://pub.allbsd.org/FreeBSD-snapshots/ . - Justin From owner-freebsd-current@FreeBSD.ORG Fri Dec 6 20:10:10 2013 Return-Path: Delivered-To: current@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 D85D933E for ; Fri, 6 Dec 2013 20:10:10 +0000 (UTC) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id A29991CA3 for ; Fri, 6 Dec 2013 20:10:10 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id rB6KAAda043990 for ; Fri, 6 Dec 2013 12:10:10 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <52A22F21.3030102@rawbw.com> Date: Fri, 06 Dec 2013 12:10:09 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: current@freebsd.org Subject: [PATCH] Sync of libedit with upstream NetBSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:10:10 -0000 I created a patch for this. libedit hasn't been updated for 4+ years http://www.freebsd.org/cgi/query-pr.cgi?pr=184533 Please MFC to 10. Thanks, Yuri From owner-freebsd-current@FreeBSD.ORG Fri Dec 6 20:36:38 2013 Return-Path: Delivered-To: freebsd-current@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 A334E223; Fri, 6 Dec 2013 20:36:38 +0000 (UTC) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (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 66AFA1EA2; Fri, 6 Dec 2013 20:36:37 +0000 (UTC) Received: from p57bcc27a.dip0.t-ipconnect.de ([87.188.194.122] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vp0FH-0000X0-NG; Fri, 06 Dec 2013 19:35:23 +0100 Message-ID: <52A218EB.5010006@gwdg.de> Date: Fri, 06 Dec 2013 19:35:23 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current Subject: r259031 breaks build on CURRENT Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kevin Lo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:36:38 -0000 I just tried to build head (r259037) and it stops with the following messages. This is on amd64 with systems clang. Please let me know, if I should provide more info, thanks. [..snip..] ===> usb/run (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys/RHURLIN -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:6: error: invalid application of 'sizeof' to an incomplete type 'struct rt2870_txwi' sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid); ^ ~~~~~~~~~~~~~~~~~~~~ @/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN' __FUNCTION__ ,##__VA_ARGS__); \ ^ /usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:20: note: forward declaration of 'struct rt2870_txwi' sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid); ^ @/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN' __FUNCTION__ ,##__VA_ARGS__); \ ^ 1 error generated. *** Error code 1 Stop. make[5]: stopped in /usr/src/sys/modules/usb/run From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 10:14:06 2013 Return-Path: Delivered-To: current@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 5DC9313A; Sat, 7 Dec 2013 10:14:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32D261272; Sat, 7 Dec 2013 10:14:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB7ADxvO033094; Sat, 7 Dec 2013 05:13:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB7ADxGp033093; Sat, 7 Dec 2013 10:13:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Dec 2013 10:13:59 GMT Message-Id: <201312071013.rB7ADxGp033093@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 10:14:06 -0000 TB --- 2013-12-07 09:33:13 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-07 09:33:13 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-07 09:33:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-12-07 09:33:13 - cleaning the object tree TB --- 2013-12-07 09:33:13 - /usr/local/bin/svn stat /src TB --- 2013-12-07 09:33:35 - At svn revision 259053 TB --- 2013-12-07 09:33:36 - building world TB --- 2013-12-07 09:33:36 - CROSS_BUILD_TESTING=YES TB --- 2013-12-07 09:33:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-07 09:33:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-07 09:33:36 - SRCCONF=/dev/null TB --- 2013-12-07 09:33:36 - TARGET=sparc64 TB --- 2013-12-07 09:33:36 - TARGET_ARCH=sparc64 TB --- 2013-12-07 09:33:36 - TZ=UTC TB --- 2013-12-07 09:33:36 - __MAKE_CONF=/dev/null TB --- 2013-12-07 09:33:36 - cd /src TB --- 2013-12-07 09:33:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 7 09:33:44 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cat /src/libexec/rtld-elf/Symbol.map | cpp - - | awk -v vfile=/src/libexec/rtld-elf/../../lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/sparc64/rtld_start.S cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/sparc64/reloc.c cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/rtld.c cc1: warnings being treated as errors /src/libexec/rtld-elf/rtld.c: In function 'free_tls': /src/libexec/rtld-elf/rtld.c:4372: warning: passing argument 1 of 'free_aligned' makes pointer from integer without a cast /src/libexec/rtld-elf/rtld.c:4376: warning: passing argument 1 of 'free_aligned' makes pointer from integer without a cast *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/rtld-elf *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-07 10:13:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-07 10:13:59 - ERROR: failed to build world TB --- 2013-12-07 10:13:59 - 1713.94 user 355.76 system 2445.60 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 13:34:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5546F242 for ; Sat, 7 Dec 2013 13:34:44 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 162471E8C for ; Sat, 7 Dec 2013 13:34:44 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so1446129qen.33 for ; Sat, 07 Dec 2013 05:34:43 -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:content-type; bh=j9sRu038G8goX0nd6MsEy66DIgcfuM6HdQ6dLSa1bqo=; b=PilQ+G7RfxnanMdPALIsfaeq7NMTWyBOYlBGjQQclefw2LG1olVcpq96/OxSAsN3ss vWr5Enw13uq6Ey97EekeocwyTo/jfpofIYVWodfc+o02YK5EdFlY7hm+DANPdUoXP1fQ YOfCwDF14DSOPVhV26wP8BKGK82kOD9xGmtnV9S3PPNZt3U2PLCwCT8rzDUzANVAhr7O U/lESMdWxcvgLOWwW6gjw9xI9e8hR9maArTQL1+RvkZOqP6bTXAryqQZ0XuJdBobK9ut gkoEXi/XZhlCabGBAucAM9OUULHqlvx/wL3CSHI95uD5CFTUerH//OpWO/qE4xqcIW/0 tu4w== X-Received: by 10.49.131.164 with SMTP id on4mr16314453qeb.16.1386423283235; Sat, 07 Dec 2013 05:34:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.45.101 with HTTP; Sat, 7 Dec 2013 05:34:03 -0800 (PST) From: =?UTF-8?B?5LmU5qWa?= Date: Sat, 7 Dec 2013 21:34:03 +0800 Message-ID: Subject: Intel Centrino Wireless-N 1000 can't connect to AP To: Current FreeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 13:34:44 -0000 Today ,I upgrade my freebsd from 10-beta4 to current. Now, my freebsd can't connect to wireless AP. Wireless LAN strike. iwn0 in /var/log/message: Dec 7 08:02:00 x201i kernel: iwn0: mem 0xf2400000-0xf2401fff irq 16 at device 0.0 on pci2 Dec 7 08:02:00 x201i kernel: iwn0: attempting to allocate 1 MSI vectors (1 supported) Dec 7 08:02:00 x201i kernel: msi: routing MSI IRQ 266 to local APIC 0 vector 62 Dec 7 08:02:00 x201i kernel: iwn0: using IRQ 266 for MSI Dec 7 08:02:00 x201i kernel: iwn0: MIMO 1T2R, BGS, address 8c:a9:82:5a:41:58 Dec 7 08:02:00 x201i kernel: iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Dec 7 08:02:00 x201i kernel: iwn0: 1T2R Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 6.5Mbps - 65Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz SGI Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 7Mbps - 72Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz: Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 13.5Mbps - 135Mbps Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz SGI: Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 15Mbps - 150Mbps ...... Dec 7 08:02:00 x201i kernel: wlan0: Ethernet address: f0:de:f1:52:cf:16 Dec 7 08:02:00 x201i kernel: iwn0: iwn_intr: fatal firmware error Dec 7 08:02:00 x201i kernel: firmware error log: Dec 7 08:02:00 x201i kernel: error type = "SYSASSERT" (0x00000005) Dec 7 08:02:00 x201i kernel: program counter = 0x00018DBC Dec 7 08:02:00 x201i kernel: source line = 0x00000032 Dec 7 08:02:00 x201i kernel: error data = 0x0000000100000000 Dec 7 08:02:00 x201i kernel: branch link = 0x00018D6E00018D6E Dec 7 08:02:00 x201i kernel: interrupt link = 0x0000082600000000 Dec 7 08:02:00 x201i kernel: time = 1538064582 Dec 7 08:02:00 x201i kernel: driver status: Dec 7 08:02:00 x201i kernel: tx ring 0: qid=0 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 1: qid=1 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 2: qid=2 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 3: qid=3 cur=2 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 4: qid=4 cur=57 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 5: qid=5 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 6: qid=6 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 7: qid=7 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 8: qid=8 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 9: qid=9 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 10: qid=10 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 11: qid=11 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 12: qid=12 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 13: qid=13 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 14: qid=14 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 15: qid=15 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 16: qid=16 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 17: qid=17 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 18: qid=18 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: tx ring 19: qid=19 cur=0 queued=0-- Dec 7 08:02:00 x201i kernel: rx ring: cur=29 ...... Dec 7 08:02:01 x201i wpa_supplicant[667]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured Dec 7 08:02:01 x201i wpa_supplicant[667]: wlan0: Failed to initiate AP scan I do not know where the problem is? If necessary, I can tie debugging. From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 14:06:54 2013 Return-Path: Delivered-To: freebsd-current@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 2E03077B for ; Sat, 7 Dec 2013 14:06:54 +0000 (UTC) Received: from mail.s1.d2ux.org (static.209.96.9.5.clients.your-server.de [5.9.96.209]) by mx1.freebsd.org (Postfix) with ESMTP id DB9D61021 for ; Sat, 7 Dec 2013 14:06:53 +0000 (UTC) Received: from mail.s1.d2ux.org (mail [10.0.0.3]) by mail.s1.d2ux.org (Postfix) with ESMTP id 45B1A84F2612 for ; Sat, 7 Dec 2013 15:06:52 +0100 (CET) Received: from mail.s1.d2ux.org ([10.0.0.3]) by mail.s1.d2ux.org (mail.s1.d2ux.org [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id x1W6y0ZNpLZ2 for ; Sat, 7 Dec 2013 15:06:50 +0100 (CET) Received: from workstation.local (p579D3BBD.dip0.t-ipconnect.de [87.157.59.189]) by mail.s1.d2ux.org (Postfix) with ESMTPSA id 954C384F2609 for ; Sat, 7 Dec 2013 15:06:50 +0100 (CET) Message-ID: <52A32AB6.1040401@petermann-it.de> Date: Sat, 07 Dec 2013 15:03:34 +0100 From: Matthias Petermann User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Centrino Wireless N2230 support References: <20130913112427.Horde.Lr2e32AbzvcQIrrWuDh-dg1@d2ux.org> <001e01ceb064$80168220$80438660$@info> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 14:06:54 -0000 Hello Adrian, Am 04.11.2013 06:59, schrieb Adrian Chadd: > [snip] > > For what it's worth, I've started merging this stuff into -HEAD. > I've just installed 11.0-CURRENT r258208 on my Thinkpad E330 and the Wireless N2230 stuff is now in working condition. Thanks for your work - It's a pleasure to see that FreeBSD hardware driver availability is so close to Linux in these areas. Do you expect the changes to get introduced in a 10.1 release someday, or should users of N2230 track CURRENT for the next months? Kins regards Matthias -- Matthias Petermann | www.petermann-it.de GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 17:50:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87F65852; Sat, 7 Dec 2013 17:50:28 +0000 (UTC) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3480E1EAD; Sat, 7 Dec 2013 17:50:28 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id w7so1544164qeb.36 for ; Sat, 07 Dec 2013 09:50:27 -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:content-transfer-encoding; bh=BTXqNgzG+ZDJbf3yNgswtCmfqO8CTcUn7fRsWFLCg5Y=; b=O40s5llw7d84k8jFBRU0CA7kv2+1w/XIQ68+HWcrx5KbQQlkOSNaLKBCys7JtYs8Bp ZB4Y+PHhFqlIWoToFDlDVPkuE6/Be4RhYGTyVOnXq+56eKyf01KkBi8X8B+1PrSsXukG Dik44xpx5v0eibPe2oh5RbsbVURJXx/fh3OlIAnlKarm5J0p5bbNmRfqWD3iVC7V/ULI gFLY8OhcsqCpYcigGtAXvlTGSVLYQZicIXJFTrz9Ra4ggbI0P7i43PIEEflavgZYcwKp M6b3DXHyeND2o701m9Y9qo4QTc5+o8GzLiHiLdN1W8J/j1tK4wkAez/uWAWWC5U6Hiek 5xcg== MIME-Version: 1.0 X-Received: by 10.224.80.129 with SMTP id t1mr129461681qak.95.1386438627456; Sat, 07 Dec 2013 09:50:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sat, 7 Dec 2013 09:50:27 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Dec 2013 09:50:27 -0800 X-Google-Sender-Auth: rELkQJJ7sufJro5x0wmlLfAqtGg Message-ID: Subject: Re: Intel Centrino Wireless-N 1000 can't connect to AP From: Adrian Chadd To: =?UTF-8?B?5LmU5qWa?= , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 17:50:28 -0000 A lot of work has gone on in -current with the iwn driver. It's quite possible that the recent changes has broken things. Would you please do this: * recompile with IWN_DEBUG defined in your kernel cofig * sysctl dev.iwn.0.debug=3D0x13ff (That turns on command debugging, tx/rx debugging, interrupt debugging and calibration debugging.) If you do that for both 10b3 and -head I can compare the two. Also, please post the output of pciconf -lv. I'd like to see which centrino-100 you're using. I thought I had tested it out on the Centrino 100 (I have a couple here) but there may be more variants that I haven't yet tested on. Thanks! -a On 7 December 2013 05:34, =E4=B9=94=E6=A5=9A wrote: > Today ,I upgrade my freebsd from 10-beta4 to current. > Now, my freebsd can't connect to wireless AP. Wireless LAN strike. > > iwn0 in /var/log/message: > Dec 7 08:02:00 x201i kernel: iwn0: mem > 0xf2400000-0xf2401fff irq 16 at device 0.0 on pci2 > > Dec 7 08:02:00 x201i kernel: iwn0: attempting to allocate 1 MSI vectors = (1 > supported) > Dec 7 08:02:00 x201i kernel: msi: routing MSI IRQ 266 to local APIC 0 > vector 62 > Dec 7 08:02:00 x201i kernel: iwn0: using IRQ 266 for MSI > Dec 7 08:02:00 x201i kernel: iwn0: MIMO 1T2R, BGS, address > 8c:a9:82:5a:41:58 > Dec 7 08:02:00 x201i kernel: iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > Dec 7 08:02:00 x201i kernel: iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > Dec 7 08:02:00 x201i kernel: iwn0: 1T2R > Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz > Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 6.5Mbps - 65Mbps > Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 20MHz SGI > Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 7Mbps - 72Mbps > Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz: > Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 13.5Mbps - 135Mbps > Dec 7 08:02:00 x201i kernel: iwn0: 11ng MCS 40MHz SGI: > Dec 7 08:02:00 x201i kernel: iwn0: MCS 0-7: 15Mbps - 150Mbps > ...... > Dec 7 08:02:00 x201i kernel: wlan0: Ethernet address: f0:de:f1:52:cf:16 > Dec 7 08:02:00 x201i kernel: iwn0: iwn_intr: fatal firmware error > Dec 7 08:02:00 x201i kernel: firmware error log: > Dec 7 08:02:00 x201i kernel: error type =3D "SYSASSERT" (0x00000005= ) > Dec 7 08:02:00 x201i kernel: program counter =3D 0x00018DBC > Dec 7 08:02:00 x201i kernel: source line =3D 0x00000032 > Dec 7 08:02:00 x201i kernel: error data =3D 0x0000000100000000 > Dec 7 08:02:00 x201i kernel: branch link =3D 0x00018D6E00018D6E > Dec 7 08:02:00 x201i kernel: interrupt link =3D 0x0000082600000000 > Dec 7 08:02:00 x201i kernel: time =3D 1538064582 > Dec 7 08:02:00 x201i kernel: driver status: > Dec 7 08:02:00 x201i kernel: tx ring 0: qid=3D0 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 1: qid=3D1 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 2: qid=3D2 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 3: qid=3D3 cur=3D2 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 4: qid=3D4 cur=3D57 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 5: qid=3D5 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 6: qid=3D6 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 7: qid=3D7 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 8: qid=3D8 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 9: qid=3D9 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 10: qid=3D10 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 11: qid=3D11 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 12: qid=3D12 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 13: qid=3D13 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 14: qid=3D14 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 15: qid=3D15 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 16: qid=3D16 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 17: qid=3D17 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 18: qid=3D18 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: tx ring 19: qid=3D19 cur=3D0 queued=3D0-- > Dec 7 08:02:00 x201i kernel: rx ring: cur=3D29 > ...... > Dec 7 08:02:01 x201i wpa_supplicant[667]: ioctl[SIOCS80211, op=3D103, va= l=3D0, > arg_len=3D128]: Device not configured > Dec 7 08:02:01 x201i wpa_supplicant[667]: wlan0: Failed to initiate AP s= can > > I do not know where the problem is? > If necessary, I can tie debugging. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 17:52:14 2013 Return-Path: Delivered-To: freebsd-current@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 21A3D9A7; Sat, 7 Dec 2013 17:52:14 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C185C1EEC; Sat, 7 Dec 2013 17:52:13 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id ii20so1487071qab.1 for ; Sat, 07 Dec 2013 09:52:13 -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=xMAX5uxpGx/c06hpNQt4M0IFLEIrvopA3jNCg3q0IPY=; b=xsy9h0ru91WjfTLanHOYNe+51AH7Lo9QkFIr1bvqc5vCag8idycwq1hb/zp37Hi5+x ForTorerqxvVg/NX2fwDy0a79n/QOun33/6nszhTELfZ8hOGTPGCL1QANf+k9jrYItd/ s7by+IFYVQT0KUnfAMQmyvmBVLKDqOTxTkNg8gJWRqQStARYUoL7Y14lInY6ycfNWPjB HpMZ+e0PDqXcG8sl5Bx6vD4A5i850JuVc7oCf4W5YwQeJZvy+MxHpX/mAxG9+1U7/H4U IgOXGxHB/geeCjWpW89Y5bKNp1v9PsCuv620hHWxM3zEdFah3pes3T8Uk+2k5BubkSg0 xRPw== MIME-Version: 1.0 X-Received: by 10.49.131.5 with SMTP id oi5mr18395297qeb.38.1386438732916; Sat, 07 Dec 2013 09:52:12 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Sat, 7 Dec 2013 09:52:12 -0800 (PST) In-Reply-To: <52A32AB6.1040401@petermann-it.de> References: <20130913112427.Horde.Lr2e32AbzvcQIrrWuDh-dg1@d2ux.org> <001e01ceb064$80168220$80438660$@info> <52A32AB6.1040401@petermann-it.de> Date: Sat, 7 Dec 2013 09:52:12 -0800 X-Google-Sender-Auth: -__MlsV65fxIBQoXsXpSyZp7rw8 Message-ID: Subject: Re: Centrino Wireless N2230 support From: Adrian Chadd To: Matthias Petermann , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 17:52:14 -0000 Hi, I don't plan a backport of any of this just yet. I'd like to let the changes shake out a bit first. There's been some reports about things not working between 10.0 and 11.0 (eg, 5 minutes ago someone reported the centrino 100 doesn't work!) and I'd like to get those fixed before we consider a merge back. Thanks, -a On 7 December 2013 06:03, Matthias Petermann wrote: > Hello Adrian, > > Am 04.11.2013 06:59, schrieb Adrian Chadd: >> [snip] >> >> For what it's worth, I've started merging this stuff into -HEAD. >> > > I've just installed 11.0-CURRENT r258208 on my Thinkpad E330 and the > Wireless N2230 stuff is now in working condition. > > Thanks for your work - It's a pleasure to see that FreeBSD hardware > driver availability is so close to Linux in these areas. > > Do you expect the changes to get introduced in a 10.1 release someday, > or should users of N2230 track CURRENT for the next months? > > > Kins regards > > Matthias > > > -- > Matthias Petermann | www.petermann-it.de > GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 18:08:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8D94FF7 for ; Sat, 7 Dec 2013 18:08:21 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id 84F001FE7 for ; Sat, 7 Dec 2013 18:08:21 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id 0CAB910058F for ; Sat, 7 Dec 2013 19:08:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id D52748F2479 for ; Sat, 7 Dec 2013 19:08:56 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMfe-6JKfr4w for ; Sat, 7 Dec 2013 19:08:56 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 4CA818F1E4C for ; Sat, 7 Dec 2013 19:08:56 +0100 (CET) Message-ID: <52A36456.8000202@bitfrost.no> Date: Sat, 07 Dec 2013 19:09:26 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Current Subject: KGDB and kvm_write Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 18:08:21 -0000 Hi, Is there a particular reason that "set variable = value" is not implemented when using kgbd from the command prompt? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 19:06:11 2013 Return-Path: Delivered-To: freebsd-current@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 C0D94335 for ; Sat, 7 Dec 2013 19:06:11 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7F66B12BD for ; Sat, 7 Dec 2013 19:06:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 141153F622 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kibab.com; s=default; t=1386443164; bh=pqoK+lpxdkvtiGGn25ZHqr+C4C0HmZxY09VZDmZKG3Q=; h=Date:From:To:Subject; b=WDT5QOvI9vC+h1gxwRstulUtBtW5gFfzXv8G5d60mQ1i1JqWVLrgql1GbjBQRqet2 45tnaVddOEPYFoqoAdeadsTS09SsEeIM753Nki6g+cgyf79ZInHZj3+67XANz9MdHJ pHQiSUGsmUihN4c53gaIexEL1gZEMzLQG/669k/Y= Message-ID: <52A37198.1030506@kibab.com> Date: Sat, 07 Dec 2013 20:06:00 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: vtnet broken on -CURRENT when using VirtualBox Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lcnGfi12HdmRg6IuQ96MsdTJ86O2q0CBd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 19:06:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lcnGfi12HdmRg6IuQ96MsdTJ86O2q0CBd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi list, I'm observing a 100%-reproducible panic in the following setup: Host system: FreeBSD 9.1-RELEASE-p7 amd64 $ pkg info | grep virtualbox virtualbox-ose-4.2.18_1 A general-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.2.18 VirtualBox kernel module for FreeBSD System in a virtual machine: FreeBSD-CURRENT SVN rev 259064. Virtual machine is created with virtio host-only adapter. When trying to ssh into VM, the system in VM panics with the following message: panic: vtnet_txq_offload: mbuf 0xc309e900 TSO without checksum offload KDB: stack backtrace: db_trace_self_wrapper(c0b4fd4d,a6461,65393030,63333039,c13a29c0,...) at db_trace_self_wrapper+0x2d/frame 0xc23f85a0 kdb_backtrace(c0b4b145,c0c29a7c,c0b9b43d,c23f865c,c23f865c,...) at kdb_backtrace+0x30/frame 0xc23f8608 vpanic(c0c29918,100,c0b9b43d,c23f865c,c23f865c,...) at vpanic+0x80/frame 0xc23f862c kassert_panic(c0b9b43d,c0b9b466,c309e900,8b1,c0dad504,...) at kassert_panic+0xe9/frame 0xc23f8650 vtnet_txq_mq_start_locked(c2e02810,0,c0b9b369,8ea,c2e02810,...) at vtnet_txq_mq_start_locked+0x62b/frame 0xc23f8808 vtnet_txq_mq_start(c2cf7800,c309e900,6,c23f89e0,c23f8866,...) at vtnet_txq_mq_start+0x76/frame 0xc23f8834 ether_output(c2cf7800,c309e900,c23f89e0,c23f89d0,c36639d8,...) at ether_output+0x64b/frame 0xc23f8888 ip_output(c309e900,0,c23f89d0,0,0,...) at ip_output+0x173f/frame 0xc23f89= 38 tcp_output(c36665e0,c342f400,32c,1,c36639d8,...) at tcp_output+0x1cbf/frame 0xc23f8a9c tcp_usr_send(c3410d40,0,c342f400,0,0,...) at tcp_usr_send+0x346/frame 0xc23f8ad0 sosend_generic(c3410d40,0,c23f8c10,0,0,...) at sosend_generic+0x3b3/frame 0xc23f8b40 soo_write(c3142f50,c23f8c10,c2cf0d00,0,c3108620,...) at soo_write+0x5d/frame 0xc23f8b70 dofilewrite(c3142f50,c23f8c10,ffffffff,ffffffff,0,...) at dofilewrite+0x86/frame 0xc23f8ba8 kern_writev(c3108620,3,c23f8c10,0,28c4d608,...) at kern_writev+0x96/frame 0xc23f8bf0 sys_write(c3108620,c23f8cc8,c23f8c98,c076b3a4,c0c36e90,...) at sys_write+0x5c/frame 0xc23f8c40 syscall(c23f8d08) at syscall+0x2de/frame 0xc23f8cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xc23f8cfc --- syscall (4, FreeBSD ELF32, sys_write), eip =3D 0x2840dd77, esp =3D 0xbfbfb328, ebp =3D 0xbfbfb348 --- KDB: enter: panic [ thread pid 1570 tid 100065 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> Please help me to debug this. --=20 Regards, Ilya Bakulin --lcnGfi12HdmRg6IuQ96MsdTJ86O2q0CBd 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.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKjcZsACgkQo9vlj1oadwir8ACggj5NJhdAlAPF43YAj0q0lwIg HusAoPL2HkcMF3CmO0b5Ma9sTXyBF6Fb =7vmf -----END PGP SIGNATURE----- --lcnGfi12HdmRg6IuQ96MsdTJ86O2q0CBd-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 19:33:03 2013 Return-Path: Delivered-To: current@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 8B83A712 for ; Sat, 7 Dec 2013 19:33:03 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 526451423 for ; Sat, 7 Dec 2013 19:33:03 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7FF043EB51 for ; Sat, 7 Dec 2013 19:32:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id rB7JWuR7027326 for ; Sat, 7 Dec 2013 19:32:56 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org Subject: r259072 is not a happy camper... From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 07 Dec 2013 19:32:56 +0000 Message-ID: <27325.1386444776@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 19:33:03 -0000 I updated my "canary" machine to -current today and it's not a happy camper. Trying to run a buildworld on it I get the follwing reproducible panic: FreeBSD/amd64 (ni.freebsd.dk) (cuau0) login: lock order reversal: 1st 0xfffff8011641a9a0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_lookup.c:518 2nd 0xfffffe00e7858790 bufwait (bufwait) @ /freebsd/head/sys/ufs/ffs/ffs_vnops .c:262 3rd 0xfffff800b40ad5f0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0111361da0 kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe011120e9e0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe011120ea90 vpanic() at vpanic+0x126/frame 0xfffffe011120ead0 kassert_panic() at kassert_panic+0x136/frame 0xfffffe011120eb40 intr_event_handle() at intr_event_handle+0x11d/frame 0xfffffe011120eb90 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe011120ebc0 lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfffffe011120ebf0 Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfffffe011120ebf0 --- interrupt, rip = 0x11f7b11, rsp = 0x7fffffff8b50, rbp = 0x7fffffff8b80 --- KDB: enter: panic [ thread pid 72149 tid 100102 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 21:34:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8F19606 for ; Sat, 7 Dec 2013 21:34:55 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D19F1B06 for ; Sat, 7 Dec 2013 21:34:55 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id w5so1582543qac.0 for ; Sat, 07 Dec 2013 13:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=91j2eeya/Io5N77N1Ry4PI2xX6zcOWQQ/yZa0hX5EqM=; b=Ufk+kE00xHs8Nd4GNUZ4epKIh+GvU0z2kd+J8wNxdZ6RBL1SoQtaBX3S0ZAhaKmRnm okA7lgUv1cqSvU4K/vLaco1n8mOjaJ87951c16yqqETMfFWfffGVnJvi6w5usKlzQeKL FcgjxjpY3fJzUOQjR8G55q7/YjjWNtwGRNnlVFezlm6hWrsXahwabpCp6wsR4aHqN3ys csQlSo57Y8zjZFlM6TMJiX7HTnohN352GDK5VvRsNqx3UOe9co1dBVorD3I+BjX4BzJb XVd8B8lhUbmED44TBVd6Oxmm++Erlhvl5JeA+GE6rOgA8hf15fc11k2A9ZWA4XdXdvMs 43Pw== X-Received: by 10.224.75.9 with SMTP id w9mr19962873qaj.68.1386452094528; Sat, 07 Dec 2013 13:34:54 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPSA id x10sm12282717qas.5.2013.12.07.13.34.53 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 07 Dec 2013 13:34:53 -0800 (PST) Date: Sat, 7 Dec 2013 16:34:46 -0500 From: Alexander Kabaev To: Hans Petter Selasky Subject: Re: KGDB and kvm_write Message-ID: <20131207163446.3a0d9d9c@kan.dyndns.org> In-Reply-To: <52A36456.8000202@bitfrost.no> References: <52A36456.8000202@bitfrost.no> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2SF3KSCjvlTiwyV02j.ySf."; protocol="application/pgp-signature" Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 21:34:55 -0000 --Sig_/2SF3KSCjvlTiwyV02j.ySf. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 07 Dec 2013 19:09:26 +0100 Hans Petter Selasky wrote: > Hi, >=20 > Is there a particular reason that "set variable =3D value" is not=20 > implemented when using kgbd from the command prompt? >=20 > --HPS Just a thought: maybe you forgot -w on kgdb command line? --=20 Alexander Kabaev --Sig_/2SF3KSCjvlTiwyV02j.ySf. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iD8DBQFSo5R8Q6z1jMm+XZYRAgmjAKCEQHDzYm/OLXlG9+GwFje/ZzPz7QCg6/5e 0+m+45KK8PiZ33dEaKHD+Zg= =8mv8 -----END PGP SIGNATURE----- --Sig_/2SF3KSCjvlTiwyV02j.ySf.-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 22:25:12 2013 Return-Path: Delivered-To: current@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 2DA01FB1; Sat, 7 Dec 2013 22:25:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3A2A1E3D; Sat, 7 Dec 2013 22:25:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id rB7MPA47017156; Sat, 7 Dec 2013 17:25:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id rB7MPAY3017155; Sat, 7 Dec 2013 22:25:10 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 7 Dec 2013 22:25:10 GMT Message-Id: <201312072225.rB7MPAY3017155@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 22:25:12 -0000 TB --- 2013-12-07 21:45:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-12-07 21:45:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-12-07 21:45:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-12-07 21:45:47 - cleaning the object tree TB --- 2013-12-07 21:46:24 - /usr/local/bin/svn stat /src TB --- 2013-12-07 21:46:27 - At svn revision 259066 TB --- 2013-12-07 21:46:28 - building world TB --- 2013-12-07 21:46:28 - CROSS_BUILD_TESTING=YES TB --- 2013-12-07 21:46:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-12-07 21:46:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-12-07 21:46:28 - SRCCONF=/dev/null TB --- 2013-12-07 21:46:28 - TARGET=sparc64 TB --- 2013-12-07 21:46:28 - TARGET_ARCH=sparc64 TB --- 2013-12-07 21:46:28 - TZ=UTC TB --- 2013-12-07 21:46:28 - __MAKE_CONF=/dev/null TB --- 2013-12-07 21:46:28 - cd /src TB --- 2013-12-07 21:46:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Dec 7 21:46:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cat /src/libexec/rtld-elf/Symbol.map | cpp - - | awk -v vfile=/src/libexec/rtld-elf/../../lib/libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/sparc64/rtld_start.S cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/sparc64/reloc.c cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/../../lib/csu/common -I/src/libexec/rtld-elf/sparc64 -I/src/libexec/rtld-elf -fPIC -DPIC -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/rtld.c cc1: warnings being treated as errors /src/libexec/rtld-elf/rtld.c: In function 'free_tls': /src/libexec/rtld-elf/rtld.c:4372: warning: passing argument 1 of 'free_aligned' makes pointer from integer without a cast /src/libexec/rtld-elf/rtld.c:4376: warning: passing argument 1 of 'free_aligned' makes pointer from integer without a cast *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/rtld-elf *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-12-07 22:25:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-12-07 22:25:10 - ERROR: failed to build world TB --- 2013-12-07 22:25:10 - 1716.48 user 358.73 system 2363.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 7 23:15:07 2013 Return-Path: Delivered-To: freebsd-current@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 EFE4D29F for ; Sat, 7 Dec 2013 23:15:07 +0000 (UTC) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) (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 BD99D10E4 for ; Sat, 7 Dec 2013 23:15:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=vYxJTsePZqipFJg0mhHcRfbxoNyJl6KY+wM4XB3kyAw=; b=YlmfIuRHu80yqT09XsRmXBD5eqZg9a3nygYRM2NxKbYYmK8pc98Wu3TGjN+a57qfSdQNlD44IdmwNuUkC9ChhkJfq4685kgBO0QOfcFdsAcNWwJ0Kavq2uocC+Lhm+t9Cx8GhYEpgHg6g6TenHLZkrIjD8yjtrid5MmybxMsfCA=; Received: from cpe-72-182-93-216.austin.res.rr.com ([72.182.93.216]:29102 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1VpR5R-000Mge-TX for freebsd-current@freebsd.org; Sat, 07 Dec 2013 17:15:06 -0600 Date: Sat, 7 Dec 2013 17:14:54 -0600 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: [Newcons] EDID message every second or 2? Message-ID: <20131207231454.GA1456@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, URIBL_BLOCKED=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, URIBL_BLOCKED=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 23:15:08 -0000 I'm getting the following: error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 every second or 3 on vt0. Ideas? Here's the dmesg.boot: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #96 r259056: Sat Dec 7 10:12:48 CST 2013 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.54-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 65656315904 (62614 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard netmap: loaded module random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd9220000-0xd923ffff,0xd9200000-0xd921ffff irq 18 at device 0.0 on pci6 em0: Using an MSI interrupt em0: Ethernet address: 00:30:48:f2:29:9c 001.000010 netmap_attach [2849] success for em0 em1: port 0x2020-0x203f mem 0xd9260000-0xd927ffff,0xd9240000-0xd925ffff irq 19 at device 0.1 on pci6 em1: Using an MSI interrupt em1: Ethernet address: 00:30:48:f2:29:9d 001.000011 netmap_attach [2849] success for em1 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 vgapci0: port 0x3000-0x307f mem 0xd8000000-0xd8ffffff,0xc0000000-0xc7ffffff,0xc8000000-0xc9ffffff irq 16 at device 0.0 on pci8 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd9000000-0xd9003fff irq 17 at device 0.1 on pci8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 pcib11: irq 16 at device 0.0 on pci10 pci11: on pcib11 pcm0: port 0x4080-0x409f,0x4000-0x407f irq 16 at device 0.0 on pci11 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xd9600400-0xd96007ff irq 17 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib12: at device 30.0 on pci0 pci12: on pcib12 vgapci1: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xd9300000-0xd930ffff irq 18 at device 1.0 on pci12 drmn1: on vgapci1 info: [drm] RADEON_IS_PCI info: [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). info: [drm] register mmio base: 0xD9300000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:8:0:0, vendor=10de, device=104a info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xd0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800d0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) drmn1: info: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) drmn1: info: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 64bits SDR [TTM] Zone kernel: Available graphics memory: 33011934 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 16M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] PCI GART of 512M enabled (table at 0x000000000DD19000). drmn1: info: WB disabled drmn1: info: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0x0xfffff8000f407000 info: [drm] Loading R100 Microcode error: [drm:pid0:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware "radeonkmsfw_R100_cp" error: [drm:pid0:r100_cp_init] *ERROR* Failed to load firmware! drmn1: error: failed initializing CP (-2). drmn1: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon_device_init: Taking over the fictitious range 0xd0000000-0xd4000000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] VGA-1 info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 info: [drm] Encoders: info: [drm] CRT1: INTERNAL_DAC1 info: [drm] Connector 1: info: [drm] DVI-I-1 info: [drm] HPD2 info: [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c info: [drm] Encoders: info: [drm] CRT2: INTERNAL_DAC2 info: [drm] DFP2: INTERNAL_DVO1 error: [drm:pid0:r100_irq_set] *ERROR* Can't enable IRQ/MSI because no handler is installed error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 composite sync not supported composite sync not supported info: [drm] fb mappable at 0xD0040000 info: [drm] vram apper at 0xD0000000 info: [drm] size 2076672 info: [drm] fb depth is 8 info: [drm] pitch is 1920 fbd1 on drmn1 vt_allocate: Replace existing VT driver. info: [drm] Initialized radeon 2.29.0 20080528 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ichwd0 on isa0 orm0: at iomem 0xc0000-0xcafff on isa0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x3bf offMax=0x501 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm1: at nid 4 on hdaa0 pcm2: at nid 5 on hdaa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen3.1: at usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2: on usbus1 ugen0.1: at usbus0 uhub3: on usbus0 ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 ata0: DMA limited to UDMA33, controller found non-ATA66 cable ipmi0: Number of channels 8 ipmi0: Attached watchdog uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 5YD6FPLG ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number 5YDA1ZL4 ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: Serial Number 5YDA3PC5 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: quirks=0x1<4K> ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: Serial Number 5YD9Y0P4 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: quirks=0x1<4K> ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 3.x device ada4: Serial Number 5YDA1R5W ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4: quirks=0x1<4K> ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: Serial Number 5YD5RBS8 ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5: quirks=0x1<4K> ada5: Previously was known as ad14 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #6 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus3 uhub0: 6 ports with 6 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 ugen3.2: at usbus3 ukbd0: on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.2: at usbus0 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 ffclock reset: HPET (14318180 Hz), time = 1386436312.500000000 error: [drm:pid0:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 uhid0: on usbus3 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688