From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 11:37:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AE5F414 for ; Sun, 8 Feb 2015 11:37:11 +0000 (UTC) Received: from mail.uugrn.org (mail.uugrn.org [IPv6:2a03:2500:1:6:b::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1582FE0E for ; Sun, 8 Feb 2015 11:37:10 +0000 (UTC) Received: from rabe.uugrn.org (root@rabe.uugrn.lan [10.253.1.25]) by mail.uugrn.org (8.14.5/8.14.5) with ESMTP id t18BavtL008181 for ; Sun, 8 Feb 2015 12:37:07 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (rabe@rabe.uugrn.lan [10.253.1.25]) by rabe.uugrn.org (8.14.5/8.14.5) with ESMTP id t18Bavbq008177 for ; Sun, 8 Feb 2015 12:36:57 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (localhost [127.0.0.1]) by rabox.fritz.box (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id t18BaviR014076 for ; Sun, 8 Feb 2015 12:36:57 +0100 Received: (from rabe@localhost) by rabox.fritz.box (8.14.4/8.14.4/Submit) id t18BauT4014075 for freebsd-stable@freebsd.org; Sun, 8 Feb 2015 12:36:56 +0100 X-Authentication-Warning: rabox.fritz.box: rabe set sender to rabe@uugrn.org using -f Date: Sun, 8 Feb 2015 12:36:56 +0100 From: Raphael Eiselstein To: freebsd-stable@freebsd.org Subject: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default Message-ID: <20150208113656.GE3395@lan.sigsys.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 11:37:11 -0000 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, I recently installed a fresh 10.1-RELEASE (amd64) using bsdinstalls zfs-setup on two mirrored disks. As I wanted to move zroot/usr/home to zroot/home I noticed that everything from /usr and /var is in the "/" mount (zroot/ROOT/default) The "mountpoint" property of zroot/var and zroot/usr seems correct but in fact it is not mounted there. See http://sigsys.de/files/freebsd_101_zfs_root_fail_screenshot.jpg (sorry, had no networking at this moment, so just a regular screenshot) Is this a known bug?=20 How can this be circumvented? How can I "fix" this? Best Regards Raphael --=20 Raphael Eiselstein =20 PGP 4E63 5307 6F6A 036D 518D 3C4F 75EE EA14 F625 DB4E =2E........|.........|.........|.........|.........|.........|.........|.. --47eKBCiAZYFK5l32 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJU10pYAAoJEHXu6hT2JdtOu9IQAI31RFFPEzeh4BZAPHZ9fQBg 8iULRNIWYt4M0e/MRdbQO3JrZuu4p/6YL79tt0vrRxcwvhtIdaPd+8RQ1qvZPgcb 8vAW5zG6A0gl703CdtTcASd1khYXztxXqN2xTS8MNR5JFJQT5u3vxR/GAXiQUWMG GsySE7Zbl3QxBJ/qa/xZlQ3kT7xKYul+idzm3ppInxblumpbp6o9OvUXVFNvgZH6 3osWk7gUHV/sl4OYpq/VCOCA1fjq4Xm/eXpZ7OcZ77SqRiBknNnq3TTDHbptFEtA Jm7d0vFSOGXt61vubl/BjloIqSOfnkvvElH9hLU57AoFczZk6R60oTHWv4qfiiab ljaxEHM1ziejR65kMDx7VEOj5oJYJlcLOqnmz8a44NRmlFVHeoWC8eTX6D9sfxlV SkzPGjqkY/KBosylrg4zZz8RrmSDHp6eIbVOhCeycW3N5Cpdw+okZImKun9xeHHL PTwhRBQqFiY7btuXu15bXBkwi2Jp+EpExNc3xjCjFHDlUm9fAJw/b/SBOjlv0thY alcGNEicz0ePCwc3k2LRiAV/mE2ajk8To64SeLoCEA89sOY0O11yB9i65tl62/3L aJGWvlCDss4OwAwb/GyuWgcxYOP8i5i6C732/VXMIsiJQ/BXLs1kllRZNlzJOLbd llSZqMg3nhOYUFTA6dN/ =WY99 -----END PGP SIGNATURE----- --47eKBCiAZYFK5l32-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 12:29:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83ED6E5C for ; Sun, 8 Feb 2015 12:29:53 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A66B320 for ; Sun, 8 Feb 2015 12:29:52 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id x13so1781526wgg.12 for ; Sun, 08 Feb 2015 04:29:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vZz/T4imDUjdqNz81Yqa9G9Lw2AmXcu9ZpX3KbBuPxs=; b=RgoVyrMDZRhNvo2gWgBgPL4vNLwt6svOWq7tRqnTypVn4IBa5YEtM55SWb8+zH88TR GGPFF6T4tL+I8Kx6VyFGIu0hNini7DuZ/Cx1KkJEPAPnqEKZNlrar8JlLXklpZ2TpdfF jhNr22g5FKq0vj0+wEJ9f8+Cl6cXnjXJOZsWtCVVqvat7qwkIrvY0wObZvBLsN8fqGpq QsBj6+EEtidA3zkOurYhovuO8GCW7D2X53g+CJ6fUj6al+r8pANglb12LHh0R1kbNqLw mcGo+gPqF5ZzEFqKu+sXmE8cUyrEKBju9YQvQGLLDBLXCQynAELcjtMFoJodfpmAvzRy hK8A== X-Gm-Message-State: ALoCoQlqtSLSkMo9qOssImmNZNzZ/HctlEE+busida7hBTvQ5KiPRhX5CZpiK9wSDcbZEdF0/JFg X-Received: by 10.194.179.194 with SMTP id di2mr29189896wjc.4.1423398584750; Sun, 08 Feb 2015 04:29:44 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bo3sm11699587wjb.44.2015.02.08.04.29.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 04:29:43 -0800 (PST) Message-ID: <54D756B1.3000103@multiplay.co.uk> Date: Sun, 08 Feb 2015 12:29:37 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default References: <20150208113656.GE3395@lan.sigsys.de> In-Reply-To: <20150208113656.GE3395@lan.sigsys.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 12:29:53 -0000 That's odd I don't have a install done by zfs-setup but I do have a number of similarly setup boxes and the output displays correctly. What does a straight df -h show and what if anything is in your /etc/fstab? Regards Steve On 08/02/2015 11:36, Raphael Eiselstein wrote: > Hi everyone, > > I recently installed a fresh 10.1-RELEASE (amd64) using bsdinstalls > zfs-setup on two mirrored disks. > > As I wanted to move zroot/usr/home to zroot/home I noticed that > everything from /usr and /var is in the "/" mount (zroot/ROOT/default) > > The "mountpoint" property of zroot/var and zroot/usr seems correct but > in fact it is not mounted there. > > See http://sigsys.de/files/freebsd_101_zfs_root_fail_screenshot.jpg > (sorry, had no networking at this moment, so just a regular screenshot) > > Is this a known bug? > How can this be circumvented? > How can I "fix" this? > > Best Regards > Raphael > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 12:36:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77326191 for ; Sun, 8 Feb 2015 12:36:50 +0000 (UTC) Received: from vps.markoturk.info (vps.markoturk.info [95.154.208.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3F99E3EC for ; Sun, 8 Feb 2015 12:36:49 +0000 (UTC) Received: by vps.markoturk.info (Postfix, from userid 1001) id 1D3CE273C7; Sun, 8 Feb 2015 13:35:31 +0100 (CET) Date: Sun, 8 Feb 2015 13:35:31 +0100 From: Marko Turk To: Raphael Eiselstein Subject: Re: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default Message-ID: <20150208123531.GA15549@vps.markoturk.info> References: <20150208113656.GE3395@lan.sigsys.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20150208113656.GE3395@lan.sigsys.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 12:36:50 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 08, 2015 at 12:36:56PM +0100, Raphael Eiselstein wrote: > Hi everyone, >=20 > I recently installed a fresh 10.1-RELEASE (amd64) using bsdinstalls > zfs-setup on two mirrored disks. >=20 > As I wanted to move zroot/usr/home to zroot/home I noticed that > everything from /usr and /var is in the "/" mount (zroot/ROOT/default) >=20 > The "mountpoint" property of zroot/var and zroot/usr seems correct but > in fact it is not mounted there. >=20 > See http://sigsys.de/files/freebsd_101_zfs_root_fail_screenshot.jpg > (sorry, had no networking at this moment, so just a regular screenshot) >=20 > Is this a known bug?=20 > How can this be circumvented? > How can I "fix" this? >=20 Hi, what is the output of zfs get canmount zroot/usr ? BR, Marko --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU11gTAAoJEDcRe7P/w1sjTxwP/j84F53ipA5qmVo2eGo+6UIq 1LsrMVCN3h9eKzUWRP70BDHS6rWH8kjYUARiM+d6afkOOJdjIm5bdoi5BBrFLRDl 0y6LHz+ooMdkYOtch6SjIhOkAwlXgkWDfjVkEOrnQzZtqEFaW2IzRdsCMVecJmwS jJKgdOyzmT8AaIIysPh8YehhUXJQcEFcAwlg2t2XvVGmX5CMcYY0PtMxGW1fAdmo E+5gf9DXUz/OxlR56RDQYC8nzKNbZcLGOPIBJj4jOj+prDOBZ5AxyWf6aC3TJuFy 1EEnQ1mTmcORallWmwGEHgPzsPC95aFtudpvK7RR2CwQK8QT1QXtkfgIwEbc7u65 HH95MIv9DCCXPA9GnYsl2+UX9i6GIdcRGvF6kdpS19z41bnGQEgzTHQUjOYzWrVY oxp5j0aHUpQnXe43iEOiA+E3FiU/EUTGoLDPquxLo2nHlICpEbTDuNoi6MukX8qf RoM3lsQaV+AjYnQIUezpVVrFpiqWdvFSL1q7OKqyCyasNwwbwlu3WUTz4xyWpwbb FjdJPLVoAgLYp7A1zZhjPOowd3Ro3OwHOAOp3RR/U9vuaOMSle1wS/PVy6pAxa1E 9IDMb9BNZOz0+ERG+LvmJHjrLpISBEtAGLU8muTAbWkWf7GgmMYwr4fpkWIYY8lS oOJZTMdSUOBwSZuMK5xR =U+Un -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 19:42:04 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 434B593 for ; Sun, 8 Feb 2015 19:42:04 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id 04FAEF7 for ; Sun, 8 Feb 2015 19:42:03 +0000 (UTC) Received: from [10.10.10.104] (h71n10-th-c-d4.ias.bredband.telia.com [81.234.63.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id ADAD7B0591 for ; Sun, 8 Feb 2015 20:33:12 +0100 (CET) From: Joel Dahl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: freebsd-update and hang during reboot Message-Id: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> Date: Sun, 8 Feb 2015 20:41:57 +0100 To: freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 19:42:04 -0000 Hi, Just about every machine I have seems to hang after running = freebsd-update and doing a reboot. The last message on the screen is = "All buffers synced=E2=80=9D and it just freezes. This happens when doing a freebsd-update and going from 10.0 to 10.1, = but also when doing a fresh 10.1 install and using freebsd-update to get = the latest -pX security patches. As soon as I reboot the machine, it = hangs. I=E2=80=99ve tried it on several different HP ProLiant models, on Intel = NUCs and on VMware virtual machines. Same phenomenon everywhere. It=E2=80=99= s really easy to trigger: just install 10.1, use default settings = everywhere, freebsd-update fetch/install, shutdown -r now and BOOM. It = hangs. I think I=E2=80=99ve seen it on =1E=1E=1E=1E=1E30 servers or so = now. Everything works like it should after the initial hang tough - no matter = how many times I reboot it completes the reboot cycle just fine. I=E2=80=99ve seen several people (mostly on IRC) mention this problem, = but no solution. Is anyone working on fixing this? =E2=80=94 Joel= From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 19:52:15 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30DF621C for ; Sun, 8 Feb 2015 19:52:15 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC10A1E2 for ; Sun, 8 Feb 2015 19:52:14 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm9so1664245wib.3 for ; Sun, 08 Feb 2015 11:52:13 -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=uwcQaqIi3PljVGdzXkqahNF103yLlw2JDbNubI8YO6Y=; b=FULjyIIyDkw4wd2hrhL1B2xMGovhb1XWHYuEvbodHP7Fot86AsV0GUVFQ33gCPK2PY tqtXePTHL6s3as5cd4qN22FN01h8+DJSeb4piK2+XthalYzgMpwHSaMpYLkyxJ/sBlh/ qHj35Z2GOEmkaPtYyHY1KpCdVIRtG9XpuAt7b7dNm3HNeCx+uFqKeMbqQphUW9ugqB8F O2UbcD+47fyBhNDv/+XYknam+ZMCBYBxpbEIR4OAIT/JFST0Ur6kRNT+A1Ma76MYqLw8 VEWFQpisNLwZ7eroCvlgnXEoK0UdrB1Lsi0zV74Jtyqf5jpfBei0UnWa5vLdyX/awitm uYcg== MIME-Version: 1.0 X-Received: by 10.180.210.203 with SMTP id mw11mr28170102wic.53.1423425133352; Sun, 08 Feb 2015 11:52:13 -0800 (PST) Received: by 10.217.150.72 with HTTP; Sun, 8 Feb 2015 11:52:13 -0800 (PST) In-Reply-To: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> Date: Sun, 8 Feb 2015 14:52:13 -0500 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Brandon Allbery To: Joel Dahl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 19:52:15 -0000 On Sun, Feb 8, 2015 at 2:41 PM, Joel Dahl wrote: > Is anyone working on fixing this? People are still trying to figure out wtf is going on so they *can* fix it. Several things have been tried and found not to be related. As much information as possible about the machine and kernel configuration on the machines where it happens would be helpful. (note that I am not one of the people working --- or able to work --- on it, so don't send it to me personally. I've just been following it.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 21:03:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67C45DDA for ; Sun, 8 Feb 2015 21:03:00 +0000 (UTC) Received: from x-art.ru (charibdis.x-art.ru [80.70.228.55]) by mx1.freebsd.org (Postfix) with ESMTP id 130CEB22 for ; Sun, 8 Feb 2015 21:02:59 +0000 (UTC) Received: from gw-old.x-art.ru (gw-old.x-art.ru [192.168.172.252]) by mta.x-art.ru (Postfix) with ESMTP id E92BA1BF237; Sun, 8 Feb 2015 23:54:13 +0300 (MSK) Date: Sun, 8 Feb 2015 23:54:12 +0300 (MSK) From: Antony Uspensky X-X-Sender: aiu@gw-old.x-art.ru To: freebsd-stable@freebsd.org Subject: Re: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default In-Reply-To: <20150208113656.GE3395@lan.sigsys.de> Message-ID: References: <20150208113656.GE3395@lan.sigsys.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Raphael Eiselstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 21:03:00 -0000 On Sun, 8 Feb 2015, Raphael Eiselstein wrote: > Hi everyone, > > I recently installed a fresh 10.1-RELEASE (amd64) using bsdinstalls > zfs-setup on two mirrored disks. > > As I wanted to move zroot/usr/home to zroot/home I noticed that > everything from /usr and /var is in the "/" mount (zroot/ROOT/default) > > The "mountpoint" property of zroot/var and zroot/usr seems correct but > in fact it is not mounted there. > > See http://sigsys.de/files/freebsd_101_zfs_root_fail_screenshot.jpg > (sorry, had no networking at this moment, so just a regular screenshot) > > Is this a known bug? > How can this be circumvented? > How can I "fix" this? This is not a bug and you should not fix it: this setup uses boot environments and /var and /usr with content belongs to particular BE. If/when you will fork BE with, say, CURRENT, it will need different files, hierarchies and filesets in /usr and /var. On the other hand, /home, /var/log, /tmp, /var/tmp et cetera live outside of any BE. Good news: booting into single user you may use vi or mc :) A. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 21:11:58 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8997A73 for ; Sun, 8 Feb 2015 21:11:58 +0000 (UTC) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 449D6C49 for ; Sun, 8 Feb 2015 21:11:58 +0000 (UTC) Received: by mail-yh0-f41.google.com with SMTP id f10so5899134yha.0 for ; Sun, 08 Feb 2015 13:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=h/VnYDDE5RicTJkE7TjBFdYfC4c8xaML8GBnyIMCsCU=; b=rZr/zflG+iqM8SAes33Pp0pY8yYS5cU7nby48DJhifzdG3T0EijyEiEWzqBNVC5IoU QnWnjzn7LWYL+t5KM9+t3MGb/xY/GlDSs6uGcAehZxoigTfBFM9nyheS3lRWYmezBI67 IS3nvzeSdwzaMZvuxzpgMi5HIlSlN9rjmNZk00Zq+tBLxdla8uWWxOOkFcdcq9jiPVm2 y/4PDNXzqiitYgZ//vYTVD9twEVqWq6E1Ugr28VyuMxI3uSpM1yd7QRoTyHNLU/3fa54 86wtsUqvWhfhQjEyBmm+iKUlv8g+o563O7w5ncaDW3mfbz0x4XBnex3eBhR2CyXgz9/E 1aHA== X-Received: by 10.236.40.79 with SMTP id e55mr4771076yhb.110.1423429917508; Sun, 08 Feb 2015 13:11:57 -0800 (PST) Received: from k8-bsd.hsd1.ga.comcast.net ([2601:0:4600:611:2ed0:5aff:fe78:91ca]) by mx.google.com with ESMTPSA id 35sm6171083yhu.32.2015.02.08.13.11.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 13:11:57 -0800 (PST) Date: Sun, 8 Feb 2015 16:12:29 -0500 From: R0B_ROD To: freebsd-stable@freebsd.org Subject: Good Report Message-ID: <20150208211229.GA19210@k8-bsd.hsd1.ga.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 21:11:58 -0000 AMD64 E-300 4GB Ram HP 2B19WM Laptop Custom Kernel FreeBSD 10.1-STABLE Astonished at the power of my machine with FreeBSD. I am a new user and am very grateful to all people who made this happen. I have ran other versions of BSD and Linux with bhyve with some success but I rather contiunue borking my system. VirtualBox continues to work as always expected. I have installed/partitioned my laptop many many times. I love installing it and configuring it. It wokrs like a charm. I my many installs I chose between ports or pkgs. I love building. It took 13hrs to build all my desired apps. I enjoy the quick and easy pkg route as well, for quick up running functionality. Once again thanks to all for making this amazing OS. Thanks. PS Planning on rewritting the entire Handbook just cuz I think it could be better. I will be using Eric S. Raymond's Art of UNIX Programming as guide. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 23:00:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A4F2367 for ; Sun, 8 Feb 2015 23:00:50 +0000 (UTC) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA08C8E8 for ; Sun, 8 Feb 2015 23:00:49 +0000 (UTC) Received: by lams18 with SMTP id s18so4229681lam.11 for ; Sun, 08 Feb 2015 15:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=TNyqByZnD/LapOz0BORk45ewbmZnKg7RyovzleBywQI=; b=sOFePsH/ue5lR+z/gyEujwCI0jJ6faHqA9svpmBDQJkwndWexUNigh7R33zo4yZ7aG 2KjnPMSdJXIQlDCOUEX3yn5/dm/pA8mQft9atkb+b5cw07bkaSujF5iBmXrvmldpTz10 FDH8ZPvJ/HGVHcJn4DhlHMso32Uh1U5UdxHYdrNTYdEoV3YfTnXeZgWGMPRoLzIi1LrC UNWSCv0il9e6ryQl1khhV256G/lJ5hdEpiEnWwSHgSYOlQhQk26wj3KJ/WkXNVAY/M3n n//3jR6mWYedNdAh7QPbTu5e81vcGpoBv3r7jvcdA+nvzENScbspjQ4T8bVSzY6C4GIv sYnA== MIME-Version: 1.0 X-Received: by 10.112.189.225 with SMTP id gl1mr13485779lbc.111.1423436447653; Sun, 08 Feb 2015 15:00:47 -0800 (PST) Received: by 10.25.76.131 with HTTP; Sun, 8 Feb 2015 15:00:47 -0800 (PST) In-Reply-To: References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> Date: Sun, 8 Feb 2015 15:00:47 -0800 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Nick Rogers Cc: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:00:50 -0000 On Sun, Feb 8, 2015 at 11:52 AM, Brandon Allbery wrote: > On Sun, Feb 8, 2015 at 2:41 PM, Joel Dahl wrote: > > > Is anyone working on fixing this? > I've been noticing this as well. FWIW here is a link to the PR and ongoing discussion. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195458 > > > People are still trying to figure out wtf is going on so they *can* fix it. > Several things have been tried and found not to be related. As much > information as possible about the machine and kernel configuration on the > machines where it happens would be helpful. > > (note that I am not one of the people working --- or able to work --- on > it, so don't send it to me personally. I've just been following it.) > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b@gmail.com > ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 23:26:38 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 233AB351 for ; Sun, 8 Feb 2015 23:26:38 +0000 (UTC) Received: from mail.uugrn.org (mail.uugrn.org [IPv6:2a03:2500:1:6:b::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAA2CBF9 for ; Sun, 8 Feb 2015 23:26:37 +0000 (UTC) Received: from rabe.uugrn.org (root@rabe.uugrn.lan [10.253.1.25]) by mail.uugrn.org (8.14.5/8.14.5) with ESMTP id t18NQONK042490 for ; Mon, 9 Feb 2015 00:26:34 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (rabe@rabe.uugrn.lan [10.253.1.25]) by rabe.uugrn.org (8.14.5/8.14.5) with ESMTP id t18NQOsJ042486 for ; Mon, 9 Feb 2015 00:26:24 +0100 (CET) (envelope-from rabe@uugrn.org) Received: from rabox.fritz.box (localhost [127.0.0.1]) by rabox.fritz.box (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id t18NQNf8006329 for ; Mon, 9 Feb 2015 00:26:23 +0100 Received: (from rabe@localhost) by rabox.fritz.box (8.14.4/8.14.4/Submit) id t18NQNx4006328 for freebsd-stable@freebsd.org; Mon, 9 Feb 2015 00:26:23 +0100 X-Authentication-Warning: rabox.fritz.box: rabe set sender to rabe@uugrn.org using -f Date: Mon, 9 Feb 2015 00:26:23 +0100 From: Raphael Eiselstein To: freebsd-stable@freebsd.org Subject: FreeBSD ZFS with Boot Environments (Was: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default) Message-ID: <20150208232623.GA5255@lan.sigsys.de> References: <20150208113656.GE3395@lan.sigsys.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:26:38 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 08, 2015 at 11:54:12PM +0300, Antony Uspensky wrote: > On Sun, 8 Feb 2015, Raphael Eiselstein wrote: > >As I wanted to move zroot/usr/home to zroot/home I noticed that > >everything from /usr and /var is in the "/" mount (zroot/ROOT/default) > >The "mountpoint" property of zroot/var and zroot/usr seems correct but > >in fact it is not mounted there. > This is not a bug and you should not fix it: > this setup uses boot environments and /var and /usr with content This was not obvious (for me). I use ZFS since 8.x with FreeBSD=20 (with manual setup of zroot / gptzfs-bootloader etc) and with Debian=20 wheezy for a while so I'm not "new" to ZFS. Having a BE is cool stuff I guess, but it lacks some documentation (at least in FreeBSD handbook). I found just a side note about "boot environments" in the "FreeBSD handbook": https://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html Is there some "official" documentation about boot environments? Searching the web for 'site:freebsd.org zfs "boot environment"' I found https://forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662/=20 So is this "official" or mainstream or just a experimental hack or a poc? Regards Raphael --=20 Raphael Eiselstein =20 PGP 4E63 5307 6F6A 036D 518D 3C4F 75EE EA14 F625 DB4E =2E........|.........|.........|.........|.........|.........|.........|.. --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJU1/CfAAoJEHXu6hT2JdtOZjcP/1oXnWlgfieYCHm9kt5SIoyC KgPZNBAbp4hTOIhK/vH/i85zTmMPTb+SUEHIyTZx5JZ0S8B2fXMQmEHYaHJ3J/3K ujOWD32gOTpgtkuBEC9rjOXzj4aOlYC0E2/nPS9Fdt1q0yj1ujQN5IhSfzbNcvVH OMntDunCnMqlTInq5l9DTo4aRV4VPVH7qQ6xfDVuz5FaI/xnzsjYy4tc5yBGHuNK m8XLy7CMpiv8u9n1+6UtVvoEkiLLc6sfXt/mIFuVbbfb4TxmVf3o+gXkNQbPtnq4 Gxol7rsLCmnZSxUL0QTs/hxdxLW+/rOxe8srlVl1RL93Ev5dhAgvGuwWISVHpwx4 e83tdnesGWRKM6YP2IwNVLDBWCz8ABqt+2xhWUa0Pnm6aC4f5JeSe1uQDz93uXn2 Gh3loZYenO1TGSv88k35pfoi5eXbnXLOx3AuSZv0Vm8+PznYoIEpOGtPJCoJsUNK 4wzacPbmF10EW1UezpzjziVo2ibMoigwl9KtDVBARusYVK1/VpohVPLj1U7sjgZG xVlmBS8JyXFBtAC+abNks1eTdHleDL7UIdgNIz1JaHk4RJsLOcjWxu6rPo0XlD06 1srZRVIErZIG/S0sVlNFdBtBDA1jFuFaGtn0nQAUjg/K4YLv1dLMRRejSziIJb4y Mdp8m9hBFiMFvuXpzosM =VhrE -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 23:52:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6603649 for ; Sun, 8 Feb 2015 23:52:57 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E4F2E2E for ; Sun, 8 Feb 2015 23:52:57 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id F05E62842B; Mon, 9 Feb 2015 00:45:46 +0100 (CET) Received: from illbsd.quip.test (ip-89-177-50-74.net.upcbroadband.cz [89.177.50.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 733D928429; Mon, 9 Feb 2015 00:45:45 +0100 (CET) Message-ID: <54D7F529.4030103@quip.cz> Date: Mon, 09 Feb 2015 00:45:45 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: Raphael Eiselstein , freebsd-stable@freebsd.org Subject: Re: FreeBSD ZFS with Boot Environments (Was: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default) References: <20150208113656.GE3395@lan.sigsys.de> <20150208232623.GA5255@lan.sigsys.de> In-Reply-To: <20150208232623.GA5255@lan.sigsys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:52:57 -0000 Raphael Eiselstein wrote on 02/09/2015 00:26: [...] > Having a BE is cool stuff I guess, but it lacks some documentation (at > least in FreeBSD handbook). > > I found just a side note about "boot environments" in the "FreeBSD > handbook": https://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html > > Is there some "official" documentation about boot environments? > > Searching the web for 'site:freebsd.org zfs "boot environment"' I found > https://forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662/ > So is this "official" or mainstream or just a experimental hack or a poc? BE is heavily used by PC-BSD, so you can try to look for some documentation on pcbsd.org. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sun Feb 8 23:59:55 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85E41773 for ; Sun, 8 Feb 2015 23:59:55 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 57401E5E for ; Sun, 8 Feb 2015 23:59:55 +0000 (UTC) Received: from gromit.chumby.lan (c-71-63-94-21.hsd1.va.comcast.net [71.63.94.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id C1A3AA28; Sun, 8 Feb 2015 18:59:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD ZFS with Boot Environments (Was: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default) From: Paul Mather In-Reply-To: <54D7F529.4030103@quip.cz> Date: Sun, 8 Feb 2015 18:59:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4483B8DB-D7C6-4337-A264-8125003CB7BD@gromit.dlib.vt.edu> References: <20150208113656.GE3395@lan.sigsys.de> <20150208232623.GA5255@lan.sigsys.de> <54D7F529.4030103@quip.cz> To: Miroslav Lachman <000.fbsd@quip.cz> X-Mailer: Apple Mail (2.1878.6) Cc: Raphael Eiselstein , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:59:55 -0000 On Feb 8, 2015, at 6:45 PM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Raphael Eiselstein wrote on 02/09/2015 00:26: >=20 > [...] >=20 >> Having a BE is cool stuff I guess, but it lacks some documentation = (at >> least in FreeBSD handbook). >>=20 >> I found just a side note about "boot environments" in the "FreeBSD >> handbook": = https://www.freebsd.org/doc/handbook/bsdinstall-partitioning.html >>=20 >> Is there some "official" documentation about boot environments? >>=20 >> Searching the web for 'site:freebsd.org zfs "boot environment"' I = found >> https://forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662/ >> So is this "official" or mainstream or just a experimental hack or a = poc? >=20 > BE is heavily used by PC-BSD, so you can try to look for some = documentation on pcbsd.org. See, also, the sysutils/beadm port for how to create and use boot = environments under FreeBSD. I don't know if the bsdinstall ZFS partitioning option is compatible = with sysutils/beadm boot environments, but, from what I've seen in this = thread, it looks like it is. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 07:41:01 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10BB3588 for ; Mon, 9 Feb 2015 07:41:01 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB23C648 for ; Mon, 9 Feb 2015 07:41:00 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.100]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t197epZE026367 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 9 Feb 2015 07:40:53 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t197epZE026367 Authentication-Results: smtp.infracaninophile.co.uk/t197epZE026367; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <54D86477.8000709@FreeBSD.org> Date: Mon, 09 Feb 2015 07:40:39 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD ZFS with Boot Environments (Was: 10.1-RELEASE: bsdinstall on zfs: /var and /usr on zroot/ROOT/default) References: <20150208113656.GE3395@lan.sigsys.de> <20150208232623.GA5255@lan.sigsys.de> <54D7F529.4030103@quip.cz> <4483B8DB-D7C6-4337-A264-8125003CB7BD@gromit.dlib.vt.edu> In-Reply-To: <4483B8DB-D7C6-4337-A264-8125003CB7BD@gromit.dlib.vt.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MAXgoPoswROTg5LaWNriioB3kNilukK73" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 07:41:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MAXgoPoswROTg5LaWNriioB3kNilukK73 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/02/2015 23:59, Paul Mather wrote: > See, also, the sysutils/beadm port for how to create and use boot > environments under FreeBSD. beadm is great. I keep meaning to contribute a 'beadm chroot BOOTENV' verb, which would mount the BE, mount a devfs filesystem inside it and chroot to the BE -- and then undo all that once you exit from the BE. Some day... > I don't know if the bsdinstall ZFS partitioning option is compatible > with sysutils/beadm boot environments, but, from what I've seen in > this thread, it looks like it is. I find the bsdinstall layout is /close/ to what I like to use for a setup with Boot Environments, but needs some tweaking. * Use /home as a separate ZFS directly rather than symlinking from /usr/home (It's not clear to me why this isn't the default. Everything treats home directories as '/home/username' and with ZFS there's no need to make .../home a child of /usr because of partitioning or space usage considerations.) * Create an overlay /var (ie. with canmount=3Dno) to act as a mount point for /var/log, /var/tmp, /var/crash *outside* the boot environments. * Ditto with /usr or /usr/local for some special use directory heirarchies under /usr -- eg. /usr/local/pgsql for Postgresql servers. Otherwise the BE consists of all of /, /usr and /var. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --MAXgoPoswROTg5LaWNriioB3kNilukK73 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.20 (Darwin) iQJ8BAEBCgBmBQJU2GSDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATvA4P/iMwzGc50A5crhu9WfHVBMMF PMHqIM4VS4nMOYs8WY0qWXRiIzc2Rc53Tq2wVk6rK2jASdm6/WrLIN/E/ICjILmY +OMaexrYczWd4cTqYIOjrSfN1Fo84dVzq/WzkOmkTusRukRHp5sW7lDpjr6Zavek nosn3QSDrexGQb0tylFkgH1GS78rTv1SvOf7SaXW5HRsMFYEXf1uqxw5nuJqYbkl k1YvPpjYUeBvtqPhBUmzsoq5fzEgGvwj9O+iL8hly2QuJP8bc0eHqH1U01VfEaJG VUgxc3JqgHKTACf1k0NqyvUqApo5jQTlwBv37rIReVq3MLyl1L12vbOokidcaO0A yz/NtYImiwgMP6iYAY5Naom811ODP0z88MfdNRzdB8z0AVRQS0N2WWw8TuUbAaa8 u9WsoAN97iihaiHxP+01bO2YdVuTzMS340LiIeVaz4GwBJkWtJGw5huAGJfQNP7f 0EGPwNyo+OzKyUmzq/iZSyLGAaWugTnMTkvHHv7+/sOKpN29liavLaZHsOAA8pmq 3qGQJMDYLs5s4N5Bh65npHGI/noO4KSrBndy1AUsi15SLEJmp1jKhprNoIL+8+7w YphHTNIgVluwhOExdYDBqaQaqDNMMsYc4Mx35OIeDb6kT/50IR9cw2ODxPXkqn9Z JZbGLbVaVsnY0mYEUBid =FfFz -----END PGP SIGNATURE----- --MAXgoPoswROTg5LaWNriioB3kNilukK73-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 16:41:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 097F5CDD for ; Mon, 9 Feb 2015 16:41:40 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6006B55 for ; Mon, 9 Feb 2015 16:41:39 +0000 (UTC) Received: from torb.pix.net (verizon.pix.net [71.178.232.3]) (authenticated bits=0) by hydra.pix.net (8.15.1/8.15.1) with ESMTPA id t19Gfbau089057; Mon, 9 Feb 2015 11:41:38 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host verizon.pix.net [71.178.232.3] claimed to be torb.pix.net Message-ID: <54D8E341.101@pix.net> Date: Mon, 09 Feb 2015 11:41:37 -0500 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and hang during reboot References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> In-Reply-To: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:41:40 -0000 Joel wrote: > Hi, > > Just about every machine I have seems to hang after running freebsd-update and doing a reboot. The last message on the screen is "All buffers synced” and it just freezes. > > This happens when doing a freebsd-update and going from 10.0 to 10.1, but also when doing a fresh 10.1 install and using freebsd-update to get the latest -pX security patches. As soon as I reboot the machine, it hangs. > > I’ve tried it on several different HP ProLiant models, on Intel NUCs and on VMware virtual machines. Same phenomenon everywhere. It’s really easy to trigger: just install 10.1, use default settings everywhere, freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I think I’ve seen it on > > > > > 30 servers or so now. > > Everything works like it should after the initial hang tough - no matter how many times I reboot it completes the reboot cycle just fine. > > I’ve seen several people (mostly on IRC) mention this problem, but no solution. > > Is anyone working on fixing this? I ran into this problem in spades when upgrading a set of servers from FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung at the same place, after printing the "All buffers synced" message. I ultimately determined that if I did the following, rather than just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", it would consistently AVOID the hang: sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" Your mileage may vary, but you don't have a lot to lose by trying it. -Kurt From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 18:03:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3CD4584 for ; Mon, 9 Feb 2015 18:03:51 +0000 (UTC) Received: from smtp6.ore.mailhop.org (smtp6.ore.mailhop.org [54.149.35.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4C437B4 for ; Mon, 9 Feb 2015 18:03:51 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp6.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YKrpI-0007dV-Qo; Mon, 09 Feb 2015 17:08:49 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t19H8eK7073067; Mon, 9 Feb 2015 10:08:40 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18oQlXoseMcenmegtoB6FGW Message-ID: <1423501720.16794.18.camel@freebsd.org> Subject: Re: freebsd-update and hang during reboot From: Ian Lepore To: Kurt Lidl Date: Mon, 09 Feb 2015 10:08:40 -0700 In-Reply-To: <54D8E341.101@pix.net> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:03:52 -0000 On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: > Joel wrote: > > Hi, > > > > Just about every machine I have seems to hang after running freebsd-update and doing a reboot. The last message on the screen is "All buffers synced and it just freezes. > > > > This happens when doing a freebsd-update and going from 10.0 to 10.1, but also when doing a fresh 10.1 install and using freebsd-update to get the latest -pX security patches. As soon as I reboot the machine, it hangs. > > > > Ive tried it on several different HP ProLiant models, on Intel NUCs and on VMware virtual machines. Same phenomenon everywhere. Its really easy to trigger: just install 10.1, use default settings everywhere, freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I think Ive seen it on > > > > > > > > > > 30 servers or so now. > > > > Everything works like it should after the initial hang tough - no matter how many times I reboot it completes the reboot cycle just fine. > > > > Ive seen several people (mostly on IRC) mention this problem, but no solution. > > > > Is anyone working on fixing this? > > I ran into this problem in spades when upgrading a set of servers from > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung > at the same place, after printing the "All buffers synced" message. > > I ultimately determined that if I did the following, rather than > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", > it would consistently AVOID the hang: > > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" > > Your mileage may vary, but you don't have a lot to lose by trying it. > > -Kurt > That is just bad advice. sync(1) does not g'tee that all data has been written, no matter how many times you type it. shutdown -n tells the system to abandon unwritten data. All in all, this is a recipe for silent filesystem corruption. Using it after an update is just asking to have a mix of old and new files on the system after the reboot. A more robust workaround would be to "mount -r" on all filesystems before invoking the shutdown (even a shutdown -n should be safe after everything has been remounted readonly). If the mount -r hangs on one of the filesystems, then you've probably got a clue as to where a normal shutdown is hanging. -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 20:46:07 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E778DF7; Mon, 9 Feb 2015 20:46:07 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A948C4C; Mon, 9 Feb 2015 20:46:07 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id fb1so21126348pad.8; Mon, 09 Feb 2015 12:46: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=92dcAcOeqfxJE6ftjM5JyaOczVtHFkwIJ/qfOZQhw3g=; b=UeogdyDloq9iW9B45gNOJotzeHcvzKekuoxyXNSSO7z/pBdZyxDbydWpyE8N1e+01X fZRYKceIvxijneHqXlpR4JZ8rtoxX3g62u/U+YrGHpEgRIUxIKOvoWn0QMSoedhnQo0t Cl9ELGljb1+UNdgXQDyD6UFSb+snHzCOAUwyyT1Hoq/KbdKkYOysTFFYrYJIptQmBqaM Zmibui1nuJ6JlvTdDtG8Yhg72yQauNwpP6AldWwJTEMQVsCAgZELpvjOiABrLgird0d8 wOOVUfE+sOSzyDH8KIVwWUXBbcKdkqnLLQkxanFocjMx+m0gJFITfXef56NaBAoeLGWI 1qCg== MIME-Version: 1.0 X-Received: by 10.66.138.46 with SMTP id qn14mr25504440pab.86.1423514766739; Mon, 09 Feb 2015 12:46:06 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.22.231 with HTTP; Mon, 9 Feb 2015 12:46:06 -0800 (PST) In-Reply-To: <1423501720.16794.18.camel@freebsd.org> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> Date: Mon, 9 Feb 2015 12:46:06 -0800 X-Google-Sender-Auth: DcREUYR6wm9k5g8LLQlAJ6TCW0s Message-ID: Subject: Re: freebsd-update and hang during reboot From: Kevin Oberman To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-STABLE Mailing List , Kurt Lidl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:46:07 -0000 On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote: > On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: > > Joel wrote: > > > Hi, > > > > > > Just about every machine I have seems to hang after running > freebsd-update and doing a reboot. The last message on the screen is "All > buffers synced=E2=80=9D and it just freezes. > > > > > > This happens when doing a freebsd-update and going from 10.0 to 10.1, > but also when doing a fresh 10.1 install and using freebsd-update to get > the latest -pX security patches. As soon as I reboot the machine, it hang= s. > > > > > > I=E2=80=99ve tried it on several different HP ProLiant models, on Int= el NUCs > and on VMware virtual machines. Same phenomenon everywhere. It=E2=80=99s = really > easy to trigger: just install 10.1, use default settings everywhere, > freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I think > I=E2=80=99ve seen it on > > > > > > > > > > > > > > > 30 servers or so now. > > > > > > Everything works like it should after the initial hang tough - no > matter how many times I reboot it completes the reboot cycle just fine. > > > > > > I=E2=80=99ve seen several people (mostly on IRC) mention this problem= , but no > solution. > > > > > > Is anyone working on fixing this? > > > > I ran into this problem in spades when upgrading a set of servers from > > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, > > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung > > at the same place, after printing the "All buffers synced" message. > > > > I ultimately determined that if I did the following, rather than > > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", > > it would consistently AVOID the hang: > > > > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" > > > > Your mileage may vary, but you don't have a lot to lose by trying it. > > > > -Kurt > > > > That is just bad advice. sync(1) does not g'tee that all data has been > written, no matter how many times you type it. shutdown -n tells the > system to abandon unwritten data. All in all, this is a recipe for > silent filesystem corruption. Using it after an update is just asking > to have a mix of old and new files on the system after the reboot. > > A more robust workaround would be to "mount -r" on all filesystems > before invoking the shutdown (even a shutdown -n should be safe after > everything has been remounted readonly). If the mount -r hangs on one > of the filesystems, then you've probably got a clue as to where a normal > shutdown is hanging. > > -- Ian I agree, Ian. This is especially true for any system running an active database. By the way, the purpose of typing "sync" three times was to spend the time typing it. Putting it on a single line completely eliminates the advantage of three "sync"s. I have had success with a different method: # shutdown now Wait 30 seconds # reboot This has always worked for my to this point, but I can't promise anything. I have only one system running a RELEASE these days. I'd be far more certain if I still had the 20-30 systems I had when I retired. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 9 21:29:13 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 991AF4EE for ; Mon, 9 Feb 2015 21:29:13 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B02B157 for ; Mon, 9 Feb 2015 21:29:13 +0000 (UTC) Received: from torb.pix.net (verizon.pix.net [71.178.232.3]) (authenticated bits=0) by hydra.pix.net (8.15.1/8.15.1) with ESMTPA id t19LTBQK091550; Mon, 9 Feb 2015 16:29:11 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host verizon.pix.net [71.178.232.3] claimed to be torb.pix.net Message-ID: <54D926A7.8060806@pix.net> Date: Mon, 09 Feb 2015 16:29:11 -0500 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: freebsd-update and hang during reboot References: <1423501720.16794.18.camel@freebsd.org> In-Reply-To: <1423501720.16794.18.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:29:13 -0000 Ian Lepore wrote: >> I ran into this problem in spades when upgrading a set of servers from >> FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, >> but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung >> at the same place, after printing the "All buffers synced" message. >> >> I ultimately determined that if I did the following, rather than >> just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", >> it would consistently AVOID the hang: >> >> sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" >> >> Your mileage may vary, but you don't have a lot to lose by trying it. >> >> -Kurt >> > > That is just bad advice. sync(1) does not g'tee that all data has been > written, no matter how many times you type it. shutdown -n tells the > system to abandon unwritten data. All in all, this is a recipe for > silent filesystem corruption. Using it after an update is just asking > to have a mix of old and new files on the system after the reboot. I didn't specify that I was using ZFS, but I was. And this comment in the ZFS code (zfs_vfsops.c, line 170): /* * Sync all ZFS filesystems. This is what happens when you * run sync(1M). Unlike other filesystems, ZFS honors the * request by waiting for all pools to commit all dirty data. */ spa_sync_allpools(); Says that sync() won't return until the dirty data is flushed. For my use case, I believe it was perfectly safe. -Kurt From owner-freebsd-stable@FreeBSD.ORG Tue Feb 10 21:37:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20A2B145; Tue, 10 Feb 2015 21:37:40 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8031BBF1; Tue, 10 Feb 2015 21:37:39 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id u10so25565780lbd.7; Tue, 10 Feb 2015 13:37:37 -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=bFCC9pQhxTeJptAMsfdmHzj2ZDOPeJbEZjuAKdgV3FE=; b=N86hPGrCmCA2eGdwp+ltqEKkgHeOsoG7XTiWd5qLWq/+cBvYKq8E55XE6uF9RkQskl OCxAn2LwvvC+rv1+E9Yh0D1YyC1oyKA0oXrQxxH/w3Cez1GEaS74ac0QUSsndrBzLzYD qRnoO9trnJw2m062PqE3PybObiTZcDVV6Bk4MEPBDnch8jh4I0I7fB+8w/3Mpvk+5qUO K76L/cWOloyuhVvzIj8WNBH16c1qFiiG16LYNoKROw69Gg2su78XDpUq8uHYfTvYmGo+ YJGvaQtg2TWQ5dUl6IAof+eADT2ukQgep98JD0HklVvJv3bvYos95NBymHFkVt2PrKrJ SWcA== MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr25039824lbb.82.1423604257331; Tue, 10 Feb 2015 13:37:37 -0800 (PST) Received: by 10.25.76.131 with HTTP; Tue, 10 Feb 2015 13:37:37 -0800 (PST) In-Reply-To: <1423501720.16794.18.camel@freebsd.org> References: <2F9DC176-912C-40C0-BAB7-DB66BD572ABA@vnode.se> <54D8E341.101@pix.net> <1423501720.16794.18.camel@freebsd.org> Date: Tue, 10 Feb 2015 13:37:37 -0800 Message-ID: Subject: Re: freebsd-update and hang during reboot From: Nick Rogers To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD STABLE , Kurt Lidl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 21:37:40 -0000 On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote: > On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote: > > Joel wrote: > > > Hi, > > > > > > Just about every machine I have seems to hang after running > freebsd-update and doing a reboot. The last message on the screen is "All > buffers synced=E2=80=9D and it just freezes. > > > > > > This happens when doing a freebsd-update and going from 10.0 to 10.1, > but also when doing a fresh 10.1 install and using freebsd-update to get > the latest -pX security patches. As soon as I reboot the machine, it hang= s. > > > > > > I=E2=80=99ve tried it on several different HP ProLiant models, on Int= el NUCs > and on VMware virtual machines. Same phenomenon everywhere. It=E2=80=99s = really > easy to trigger: just install 10.1, use default settings everywhere, > freebsd-update fetch/install, shutdown -r now and BOOM. It hangs. I think > I=E2=80=99ve seen it on > > > > > > > > > > > > > > > 30 servers or so now. > > > > > > Everything works like it should after the initial hang tough - no > matter how many times I reboot it completes the reboot cycle just fine. > > > > > > I=E2=80=99ve seen several people (mostly on IRC) mention this problem= , but no > solution. > > > > > > Is anyone working on fixing this? > > > > I ran into this problem in spades when upgrading a set of servers from > > FreeBSD 9.0 to 9.1. I happened consistently. Normal reboots worked, > > but when going from 9.0 to 9.1, it *ALWAYS* hung, and it always hung > > at the same place, after printing the "All buffers synced" message. > > > > I ultimately determined that if I did the following, rather than > > just a "reboot" or "shutdown -r now 'FreeBSD 9.1-RELEASE upgrade'", > > it would consistently AVOID the hang: > > > > sync ; sync ; sync ; shutdown -o -n -r now "FreeBSD 9.1 install" > > > > Your mileage may vary, but you don't have a lot to lose by trying it. > > > > -Kurt > > > > That is just bad advice. sync(1) does not g'tee that all data has been > written, no matter how many times you type it. shutdown -n tells the > system to abandon unwritten data. All in all, this is a recipe for > silent filesystem corruption. Using it after an update is just asking > to have a mix of old and new files on the system after the reboot. > > A more robust workaround would be to "mount -r" on all filesystems > before invoking the shutdown (even a shutdown -n should be safe after > everything has been remounted readonly). If the mount -r hangs on one > of the filesystems, then you've probably got a clue as to where a normal > shutdown is hanging. > FWIW mount -r on the root filesystem hangs for me. If I disable softupdates-journaling on the root filesystem before the upgrade process, the system no longer hangs on the last reboot after userland upgrade. However, the root filesystem still comes up dirty with an incorrect free block count during fsck. > -- Ian > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 01:22:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8294B761 for ; Wed, 11 Feb 2015 01:22:40 +0000 (UTC) Received: from maul.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F08E882 for ; Wed, 11 Feb 2015 01:22:39 +0000 (UTC) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YLK0w-000PpN-8C; Tue, 10 Feb 2015 17:14:42 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.9/8.14.9) with ESMTP id t1ANEgBc000745; Tue, 10 Feb 2015 17:14:42 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.9/8.14.9/Submit) id t1ANEfQA000744; Tue, 10 Feb 2015 17:14:41 -0600 (CST) (envelope-from bob) Date: Tue, 10 Feb 2015 17:14:41 -0600 From: Bob Willcox To: John-Mark Gurney Message-ID: <20150210231440.GB471@rancor.immure.com> Reply-To: Bob Willcox References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150203003307.GG27103@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 10.1.132.9 X-SA-Exim-Mail-From: bob@immure.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maul.immure.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: top, fixed buffer length in utils.c X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on maul.immure.com) Cc: Erich Dollansky , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:22:40 -0000 On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 +0800: > > int can be 64 bits on a amd64 machine. Why is the author of this code > > so sure that we will never cross the 32 bit boundary? > > Per others, int is currently 32bits on all platforms we support... > > I guess adding: > CTASSERT(sizeof(int) <= 4); > > would help fix your concern? at least now the expectation is codified > and if it breaks, the build will break.. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > If/when the size of an int ever changes from being 32 bits, top will be the least of our worries! Bob -- Bob Willcox | You climb to reach the summit, but once bob@immure.com | there, discover that all roads lead down. Austin, TX | -- Stanislaw Lem, "The Cyberiad" From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 16:55:23 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DCCDD09 for ; Wed, 11 Feb 2015 16:55:23 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 881F3B5A for ; Wed, 11 Feb 2015 16:55:22 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1BGtI0P057265; Wed, 11 Feb 2015 17:55:18 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 54391A86; Wed, 11 Feb 2015 17:55:18 +0100 (CET) Message-ID: <54DB8975.2030001@omnilan.de> Date: Wed, 11 Feb 2015 17:55:17 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jack Vogel Subject: Re: igb(4) watchdog timeout, lagg(4) fails References: <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <54B10432.8050909@omnilan.de> In-Reply-To: <54B10432.8050909@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52B9373E4462A86CE9ABD566" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 11 Feb 2015 17:55:18 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:55:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52B9373E4462A86CE9ABD566 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Harald Schmalzbauer's Nachricht vom 10.01.2015 11:51 (localtime): > Bez=FCglich Jack Vogel's Nachricht vom 09.01.2015 18:46 (localtime): >> The tuneable interrupt rate code is not mine, and looking at it I'm no= t >> entirely >> sure it works. Why are you focused on the interrupt rate anyway, do yo= u have >> some reason to tie it to the watchdog? >> >> You could turn AIM off (enable_aim) and see if that changed anything? >> >> It seems most the time problems show up they involve the use of lagg, = if you >> take it out of the mix does the problem go away? =85 > Is there a way to reset the interface without rebooting the machine? Th= e > watchdog doesn't really reset the device, it's in non-operating state > afterwards. I need to 'ifconfig down' it for bringin lagg(4) back into > operational state. > Some kind of D3D0-state switch for a single address? kldunloading would= > destroy the remaining interface too=85 I could isolate the igb watchdog timeout problem a bit. It only happens on nics which take the PCH-PCIe route. Nics that are connected to the CPU's PCIe root complex never show this issue. Currently, I suffer from one unresponsible nic which shows the following states: dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 dev.igb.1.%driver: igb dev.igb.1.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PE70.S1F0 dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 subdevice=3D0xa03c class=3D0x020000 dev.igb.1.%parent: pci11 dev.igb.1.nvm: -1 dev.igb.1.enable_aim: 1 dev.igb.1.fc: 3 dev.igb.1.rx_processing_limit: 250 dev.igb.1.link_irq: 848 ^^^^^^^^^^^^^^ 848??? dev.igb.1.dropped: 0 dev.igb.1.tx_dma_fail: 0 dev.igb.1.rx_overruns: 0 dev.igb.1.watchdog_timeouts: 414 dev.igb.1.device_control: 1488978497 dev.igb.1.rx_control: 67272738 dev.igb.1.interrupt_mask: 4 dev.igb.1.extended_int_mask: 2147483655 dev.igb.1.tx_buf_alloc: 0 dev.igb.1.rx_buf_alloc: 0 dev.igb.1.fc_high_water: 47488 dev.igb.1.fc_low_water: 47472 dev.igb.1.queue0.interrupt_rate: 0 dev.igb.1.queue0.txd_head: 0 dev.igb.1.queue0.txd_tail: 0 dev.igb.1.queue0.no_desc_avail: 2520 dev.igb.1.queue0.tx_packets: 43894 dev.igb.1.queue0.rxd_head: 0 dev.igb.1.queue0.rxd_tail: 0 dev.igb.1.queue0.rx_packets: 1918054 dev.igb.1.queue0.rx_bytes: 0 dev.igb.1.queue0.lro_queued: 0 dev.igb.1.queue0.lro_flushed: 0 dev.igb.1.queue1.interrupt_rate: 0 dev.igb.1.queue1.txd_head: 0 dev.igb.1.queue1.txd_tail: 0 dev.igb.1.queue1.no_desc_avail: 17 dev.igb.1.queue1.tx_packets: 36813 dev.igb.1.queue1.rxd_head: 0 dev.igb.1.queue1.rxd_tail: 0 dev.igb.1.queue1.rx_packets: 63738 dev.igb.1.queue1.rx_bytes: 0 dev.igb.1.queue1.lro_queued: 0 dev.igb.1.queue1.lro_flushed: 0 =85 dev.igb.1.interrupts.asserts: 5890499 dev.igb.1.interrupts.rx_pkt_timer: 2103707 dev.igb.1.interrupts.rx_abs_timer: 0 dev.igb.1.interrupts.tx_pkt_timer: 0 dev.igb.1.interrupts.tx_abs_timer: 1983448 dev.igb.1.interrupts.tx_queue_empty: 50493 dev.igb.1.interrupts.tx_queue_min_thresh: 0 dev.igb.1.interrupts.rx_desc_min_thresh: 0 dev.igb.1.interrupts.rx_overrun: 0 The dev.igb.1.link_irq value doesn't really make sense, does it? The rest isn't unusual, just shows the watchdog timeout problem becaus of dev.igb.1.queue0.no_desc_avail I guess. I manually adjusted: hw.igb.num_queues: 2 hw.igb.rx_process_limit: 250 hw.igb.rxd: 4096 hw.igb.txd: 4096 Like mentioned, the nics not going through PCH-PCIe don't show this problem, falsified. This is the regular timeout interval for the last 24h (~3 minutes): Feb 11 17:26:53 vega kernel: igb1: Watchdog timeout -- resetting Feb 11 17:26:53 vega kernel: igb1: Queue(911600000) tdh =3D 2068077355, h= w tdt =3D 397078446 Feb 11 17:26:53 vega kernel: igb1: TX(911600000) desc avail =3D 0,Next TX= to Clean =3D 0 Feb 11 17:26:53 vega kernel: igb1: link state changed to DOWN Feb 11 17:26:56 vega kernel: igb1: link state changed to UP Feb 11 17:26:56 vega devd: Executing '/etc/rc.d/dhclient quietstart igb1'= Feb 11 17:30:10 vega kernel: igb1: Watchdog timeout -- resetting Feb 11 17:30:10 vega kernel: igb1: Queue(911600000) tdh =3D 2068077355, h= w tdt =3D 397078446 Feb 11 17:30:10 vega kernel: igb1: TX(911600000) desc avail =3D 0,Next TX= to Clean =3D 0 Feb 11 17:30:10 vega kernel: igb1: link state changed to DOWN Feb 11 17:30:13 vega kernel: igb1: link state changed to UP But these resets don't bring the interface back into a working state :-( "Queue" value remains constant, but "tdh" and "tdt" vary from time to time, for example: igb1: Queue(911600000) tdh =3D -337225283, hw tdt =3D 398180458 Unfortunately I don't know what they stand for. Is there an explanation for people who don't just look for it in the drivers code? Any idea where the problem could be? Thanks, -Harry --------------enig52B9373E4462A86CE9ABD566 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTbiXUACgkQLDqVQ9VXb8jktgCgxQgBLy0fLL1lIRhwHEHcS6NA OKUAoKE3Unzf0vukXjy7N/oJWA+h3KH1 =Rw5U -----END PGP SIGNATURE----- --------------enig52B9373E4462A86CE9ABD566-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 17:31:09 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D4BB8D1 for ; Wed, 11 Feb 2015 17:31:09 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7C6BED1 for ; Wed, 11 Feb 2015 17:31:08 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id q59so4958302wes.1 for ; Wed, 11 Feb 2015 09:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3FejLpDMHt38V6CGkT4oWkcjP/sCju87UePygT9HJhU=; b=ZaFnQ7RIcx068xPTk/2D47QfgGnHob9NLetqg9uXYQq1B1jtGBWKqBG2weuyj54+Ea z0o2LKjh5EXzFjlsnPTY4F8oh9b57peKvQ7ldSoVfau00fObNlfJ+R16MiQREAvxhHMh g/jGh1IrPP1hm/tk/Q5SznskmQduQhr7GsPFIGHuk1r0fXZvrlDlt63F2chns23PJg/w sf6yDTGtPFiHlCe0d3+/9ICDOS/aisbY9GIDl0iQHOY+SChe9lPS5rlv7Zc7A3BpnaPm BIr9fIqRI6N88i1X/qSintP0vEUBbvzpYD9GhpD6So6YZtMI2ipZd/Tw3jE8wq4cfYyE dgoA== MIME-Version: 1.0 X-Received: by 10.194.5.168 with SMTP id t8mr65630113wjt.150.1423675866812; Wed, 11 Feb 2015 09:31:06 -0800 (PST) Received: by 10.194.101.106 with HTTP; Wed, 11 Feb 2015 09:31:06 -0800 (PST) In-Reply-To: <54DB8975.2030001@omnilan.de> References: <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <54B10432.8050909@omnilan.de> <54DB8975.2030001@omnilan.de> Date: Wed, 11 Feb 2015 09:31:06 -0800 Message-ID: Subject: Re: igb(4) watchdog timeout, lagg(4) fails From: Jack Vogel To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:31:09 -0000 tdh and tdt mean the head and tail indices of the ring, and these values are obviously severely borked :) I'm buried with some other issues, but I'll try and find some time to look at this a bit more. Jack On Wed, Feb 11, 2015 at 8:55 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Bez=FCglich Harald Schmalzbauer's Nachricht vom 10.01.2015 11:51 > (localtime): > > Bez=FCglich Jack Vogel's Nachricht vom 09.01.2015 18:46 (localtime): > >> The tuneable interrupt rate code is not mine, and looking at it I'm no= t > >> entirely > >> sure it works. Why are you focused on the interrupt rate anyway, do yo= u > have > >> some reason to tie it to the watchdog? > >> > >> You could turn AIM off (enable_aim) and see if that changed anything? > >> > >> It seems most the time problems show up they involve the use of lagg, > if you > >> take it out of the mix does the problem go away? > ... > > > Is there a way to reset the interface without rebooting the machine? Th= e > > watchdog doesn't really reset the device, it's in non-operating state > > afterwards. I need to 'ifconfig down' it for bringin lagg(4) back into > > operational state. > > Some kind of D3D0-state switch for a single address? kldunloading would > > destroy the remaining interface too... > > I could isolate the igb watchdog timeout problem a bit. > It only happens on nics which take the PCH-PCIe route. Nics that are > connected to the CPU's PCIe root complex never show this issue. > > Currently, I suffer from one unresponsible nic which shows the following > states: > dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0 > dev.igb.1.%driver: igb > dev.igb.1.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PE70.S1F0 > dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 > subdevice=3D0xa03c class=3D0x020000 > dev.igb.1.%parent: pci11 > dev.igb.1.nvm: -1 > dev.igb.1.enable_aim: 1 > dev.igb.1.fc: 3 > dev.igb.1.rx_processing_limit: 250 > dev.igb.1.link_irq: 848 > ^^^^^^^^^^^^^^ 848??? > dev.igb.1.dropped: 0 > dev.igb.1.tx_dma_fail: 0 > dev.igb.1.rx_overruns: 0 > dev.igb.1.watchdog_timeouts: 414 > dev.igb.1.device_control: 1488978497 > dev.igb.1.rx_control: 67272738 > dev.igb.1.interrupt_mask: 4 > dev.igb.1.extended_int_mask: 2147483655 > dev.igb.1.tx_buf_alloc: 0 > dev.igb.1.rx_buf_alloc: 0 > dev.igb.1.fc_high_water: 47488 > dev.igb.1.fc_low_water: 47472 > dev.igb.1.queue0.interrupt_rate: 0 > dev.igb.1.queue0.txd_head: 0 > dev.igb.1.queue0.txd_tail: 0 > dev.igb.1.queue0.no_desc_avail: 2520 > dev.igb.1.queue0.tx_packets: 43894 > dev.igb.1.queue0.rxd_head: 0 > dev.igb.1.queue0.rxd_tail: 0 > dev.igb.1.queue0.rx_packets: 1918054 > dev.igb.1.queue0.rx_bytes: 0 > dev.igb.1.queue0.lro_queued: 0 > dev.igb.1.queue0.lro_flushed: 0 > dev.igb.1.queue1.interrupt_rate: 0 > dev.igb.1.queue1.txd_head: 0 > dev.igb.1.queue1.txd_tail: 0 > dev.igb.1.queue1.no_desc_avail: 17 > dev.igb.1.queue1.tx_packets: 36813 > dev.igb.1.queue1.rxd_head: 0 > dev.igb.1.queue1.rxd_tail: 0 > dev.igb.1.queue1.rx_packets: 63738 > dev.igb.1.queue1.rx_bytes: 0 > dev.igb.1.queue1.lro_queued: 0 > dev.igb.1.queue1.lro_flushed: 0 > ... > dev.igb.1.interrupts.asserts: 5890499 > dev.igb.1.interrupts.rx_pkt_timer: 2103707 > dev.igb.1.interrupts.rx_abs_timer: 0 > dev.igb.1.interrupts.tx_pkt_timer: 0 > dev.igb.1.interrupts.tx_abs_timer: 1983448 > dev.igb.1.interrupts.tx_queue_empty: 50493 > dev.igb.1.interrupts.tx_queue_min_thresh: 0 > dev.igb.1.interrupts.rx_desc_min_thresh: 0 > dev.igb.1.interrupts.rx_overrun: 0 > > The dev.igb.1.link_irq value doesn't really make sense, does it? > > The rest isn't unusual, just shows the watchdog timeout problem becaus > of dev.igb.1.queue0.no_desc_avail I guess. > > I manually adjusted: > hw.igb.num_queues: 2 > hw.igb.rx_process_limit: 250 > hw.igb.rxd: 4096 > hw.igb.txd: 4096 > > Like mentioned, the nics not going through PCH-PCIe don't show this > problem, falsified. > > This is the regular timeout interval for the last 24h (~3 minutes): > Feb 11 17:26:53 vega kernel: igb1: Watchdog timeout -- resetting > Feb 11 17:26:53 vega kernel: igb1: Queue(911600000) tdh =3D 2068077355, h= w > tdt =3D 397078446 > Feb 11 17:26:53 vega kernel: igb1: TX(911600000) desc avail =3D 0,Next TX > to Clean =3D 0 > Feb 11 17:26:53 vega kernel: igb1: link state changed to DOWN > Feb 11 17:26:56 vega kernel: igb1: link state changed to UP > Feb 11 17:26:56 vega devd: Executing '/etc/rc.d/dhclient quietstart igb1' > Feb 11 17:30:10 vega kernel: igb1: Watchdog timeout -- resetting > Feb 11 17:30:10 vega kernel: igb1: Queue(911600000) tdh =3D 2068077355, h= w > tdt =3D 397078446 > Feb 11 17:30:10 vega kernel: igb1: TX(911600000) desc avail =3D 0,Next TX > to Clean =3D 0 > Feb 11 17:30:10 vega kernel: igb1: link state changed to DOWN > Feb 11 17:30:13 vega kernel: igb1: link state changed to UP > > But these resets don't bring the interface back into a working state :-( > "Queue" value remains constant, but "tdh" and "tdt" vary from time to > time, for example: > igb1: Queue(911600000) tdh =3D -337225283, hw tdt =3D 398180458 > > Unfortunately I don't know what they stand for. Is there an explanation > for people who don't just look for it in the drivers code? > Any idea where the problem could be? > > Thanks, > > -Harry > > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 19:19:06 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09589E55 for ; Wed, 11 Feb 2015 19:19:06 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9AF9D3C for ; Wed, 11 Feb 2015 19:19:05 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1BJCSUA073839 for ; Wed, 11 Feb 2015 11:12:28 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD STABLE" From: "Chris H" Subject: nfe0: watchdog timeout Date: Wed, 11 Feb 2015 11:12:28 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <126f19356ae6eaf1681262b8ef805dcc@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:19:06 -0000 Had a power outage at home last night. I fsck'd the disks, and after bring it back up, I was without network, and the: nfe0: watchdog timeout just keeps repeating. tail /var/log/messages nfe0: watchdog timeout nfe0: link state changed to DOWN nfe0: link state changed to UP nfe0: watchdog timeout .. just keeps repeating. I examined rc.conf(5), and all looks good. ifconfig(8) shows active, and nothing different or unusual. /etc/rc.d/netif restart was of no help. Nothing changed in the BIOS settings. I'm out of ideas. Anyone care to venture a guess? This is on RELENG_9 custom kernel built on Oct, 30 2014. nForce MCP61 irq 20 at device 7.0 at pci0 attempting to allocate 8 MSI vectors (8 supported) using IRQs 257-264 for MSI using 8 MSI messages on nfe0 Thanks! --Chris -- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 19:39:43 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92C1139C for ; Wed, 11 Feb 2015 19:39:43 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2537EF41 for ; Wed, 11 Feb 2015 19:39:43 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id a1so5669957wgh.5 for ; Wed, 11 Feb 2015 11:39:41 -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=v9dMY+987Bp84Qqi138caUXPE8d9Stu8vlQDNbteUkw=; b=eMRG+13jKIw/hM0Sxav3PJjnr322reTp7CEtt7IvJj/n4dlDkOltwCm1mXlMPN9sPG soxTZGMQ8jKT5qoxDdfq/gcWMMpE3ui1A/WT/8Gvhj6Mnal3y3HAPVwfZszy/jlVuiyy TDvMZVvWPRpCNd7dOgCsAe7MI2DPOi6bVB1QRhfzLpEGtVqhHlodFSSrNd68YE7yadSM mXtrTlem5RZFrxp4iWm1wFWqpFnnbAPtbsq3y7SYB7z6kjbJP0qEA/xxxyhLG1SnI8Lb GCgV1U64IwF7uOy3abQtk3er8ECsItP7h36JZlcJtZRfV1usWwkEdhIJ3x4xWX9R55bW XdSA== MIME-Version: 1.0 X-Received: by 10.180.207.110 with SMTP id lv14mr59456374wic.41.1423683581468; Wed, 11 Feb 2015 11:39:41 -0800 (PST) Received: by 10.216.234.74 with HTTP; Wed, 11 Feb 2015 11:39:41 -0800 (PST) In-Reply-To: <126f19356ae6eaf1681262b8ef805dcc@ultimatedns.net> References: <126f19356ae6eaf1681262b8ef805dcc@ultimatedns.net> Date: Wed, 11 Feb 2015 14:39:41 -0500 Message-ID: Subject: Re: nfe0: watchdog timeout From: Brandon Allbery To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:39:43 -0000 On Wed, Feb 11, 2015 at 2:12 PM, Chris H wrote: > Had a power outage at home last night. > I fsck'd the disks, and after bring it back up, I was > without network, and the: > nfe0: watchdog timeout > just keeps repeating. > Seeing that after a power outage, I'd be testing the NIC in another machine or etc. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 19:48:09 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870B456E for ; Wed, 11 Feb 2015 19:48:09 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F8D46A for ; Wed, 11 Feb 2015 19:48:08 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1BJm7jJ058471; Wed, 11 Feb 2015 20:48:07 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A41B3115; Wed, 11 Feb 2015 20:48:06 +0100 (CET) Message-ID: <54DBB1F5.1090601@omnilan.de> Date: Wed, 11 Feb 2015 20:48:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jack Vogel Subject: Re: igb(4) watchdog timeout, lagg(4) fails References: <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <54B10432.8050909@omnilan.de> <54DB8975.2030001@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBCE487D69772C77491500C3D" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 11 Feb 2015 20:48:07 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBCE487D69772C77491500C3D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Jack Vogel's Nachricht vom 11.02.2015 18:31 (localtime): > tdh and tdt mean the head and tail indices of the ring, and these > values are > obviously severely borked :) > > I'm buried with some other issues, but I'll try and find some time to l= ook > at this a bit more. Highly appreciated, thanks in advance! For the records: Rebooting the machine (ESXi guest-only!) brought the stalled igb1 back to operation. The guest has 2 igb (kawela) ports, one from a NIC(Intel ET Dual Port 82576)@CPU-PCIe and the second port from an identical NIC, but connected via PCH-PCIe. The watchdog timeout problem only occurs with the port from the PCH-PCIe-connected NIC (falisfied)! After the reboot the suspicious "dev.igb.1.link_irq=3D848" turned into: dev.igb.0.link_irq: 3 dev.igb.1.link_irq: 4 Thanks, -Harry > > On Wed, Feb 11, 2015 at 8:55 AM, Harald Schmalzbauer > > wrote: > > Bez=FCglich Harald Schmalzbauer's Nachricht vom 10.01.2015 11:51 > (localtime): > > Bez=FCglich Jack Vogel's Nachricht vom 09.01.2015 18:46 (localtim= e): > >> The tuneable interrupt rate code is not mine, and looking at it > I'm not > >> entirely > >> sure it works. Why are you focused on the interrupt rate anyway,= > do you have > >> some reason to tie it to the watchdog? > >> > >> You could turn AIM off (enable_aim) and see if that changed > anything? > >> > >> It seems most the time problems show up they involve the use of > lagg, if you > >> take it out of the mix does the problem go away? > =85 > > > Is there a way to reset the interface without rebooting the > machine? The > > watchdog doesn't really reset the device, it's in non-operating s= tate > > afterwards. I need to 'ifconfig down' it for bringin lagg(4) back= > into > > operational state. > > Some kind of D3D0-state switch for a single address? kldunloading= > would > > destroy the remaining interface too=85 > > I could isolate the igb watchdog timeout problem a bit. > It only happens on nics which take the PCH-PCIe route. Nics that ar= e > connected to the CPU's PCIe root complex never show this issue. > > Currently, I suffer from one unresponsible nic which shows the > following > states: > dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.4= =2E0 > dev.igb.1.%driver: igb > dev.igb.1.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PE70= =2ES1F0 > dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8= 086 > subdevice=3D0xa03c class=3D0x020000 > dev.igb.1.%parent: pci11 > dev.igb.1.nvm: -1 > dev.igb.1.enable_aim: 1 > dev.igb.1.fc: 3 > dev.igb.1.rx_processing_limit: 250 > dev.igb.1.link_irq: 848 > ^^^^^^^^^^^^^^ 848??? > dev.igb.1.dropped: 0 > dev.igb.1.tx_dma_fail: 0 > dev.igb.1.rx_overruns: 0 > dev.igb.1.watchdog_timeouts: 414 > dev.igb.1.device_control: 1488978497 > dev.igb.1.rx_control: 67272738 > dev.igb.1.interrupt_mask: 4 > dev.igb.1.extended_int_mask: 2147483655 > dev.igb.1.tx_buf_alloc: 0 > dev.igb.1.rx_buf_alloc: 0 > dev.igb.1.fc_high_water: 47488 > dev.igb.1.fc_low_water: 47472 > dev.igb.1.queue0.interrupt_rate: 0 > dev.igb.1.queue0.txd_head: 0 > dev.igb.1.queue0.txd_tail: 0 > dev.igb.1.queue0.no_desc_avail: 2520 > dev.igb.1.queue0.tx_packets: 43894 > dev.igb.1.queue0.rxd_head: 0 > dev.igb.1.queue0.rxd_tail: 0 > dev.igb.1.queue0.rx_packets: 1918054 > dev.igb.1.queue0.rx_bytes: 0 > dev.igb.1.queue0.lro_queued: 0 > dev.igb.1.queue0.lro_flushed: 0 > dev.igb.1.queue1.interrupt_rate: 0 > dev.igb.1.queue1.txd_head: 0 > dev.igb.1.queue1.txd_tail: 0 > dev.igb.1.queue1.no_desc_avail: 17 > dev.igb.1.queue1.tx_packets: 36813 > dev.igb.1.queue1.rxd_head: 0 > dev.igb.1.queue1.rxd_tail: 0 > dev.igb.1.queue1.rx_packets: 63738 > dev.igb.1.queue1.rx_bytes: 0 > dev.igb.1.queue1.lro_queued: 0 > dev.igb.1.queue1.lro_flushed: 0 > =85 > dev.igb.1.interrupts.asserts: 5890499 > dev.igb.1.interrupts.rx_pkt_timer: 2103707 > dev.igb.1.interrupts.rx_abs_timer: 0 > dev.igb.1.interrupts.tx_pkt_timer: 0 > dev.igb.1.interrupts.tx_abs_timer: 1983448 > dev.igb.1.interrupts.tx_queue_empty: 50493 > dev.igb.1.interrupts.tx_queue_min_thresh: 0 > dev.igb.1.interrupts.rx_desc_min_thresh: 0 > dev.igb.1.interrupts.rx_overrun: 0 > > The dev.igb.1.link_irq value doesn't really make sense, does it? > > The rest isn't unusual, just shows the watchdog timeout problem bec= aus > of dev.igb.1.queue0.no_desc_avail I guess. > > I manually adjusted: > hw.igb.num_queues: 2 > hw.igb.rx_process_limit: 250 > hw.igb.rxd: 4096 > hw.igb.txd: 4096 > > Like mentioned, the nics not going through PCH-PCIe don't show this= > problem, falsified. > > This is the regular timeout interval for the last 24h (~3 minutes):= > Feb 11 17:26:53 vega kernel: igb1: Watchdog timeout -- resetting > Feb 11 17:26:53 vega kernel: igb1: Queue(911600000) tdh =3D > 2068077355, hw > tdt =3D 397078446 > Feb 11 17:26:53 vega kernel: igb1: TX(911600000) desc avail =3D > 0,Next TX > to Clean =3D 0 > Feb 11 17:26:53 vega kernel: igb1: link state changed to DOWN > Feb 11 17:26:56 vega kernel: igb1: link state changed to UP > Feb 11 17:26:56 vega devd: Executing '/etc/rc.d/dhclient > quietstart igb1' > Feb 11 17:30:10 vega kernel: igb1: Watchdog timeout -- resetting > Feb 11 17:30:10 vega kernel: igb1: Queue(911600000) tdh =3D > 2068077355, hw > tdt =3D 397078446 > Feb 11 17:30:10 vega kernel: igb1: TX(911600000) desc avail =3D > 0,Next TX > to Clean =3D 0 > Feb 11 17:30:10 vega kernel: igb1: link state changed to DOWN > Feb 11 17:30:13 vega kernel: igb1: link state changed to UP > > But these resets don't bring the interface back into a working > state :-( > "Queue" value remains constant, but "tdh" and "tdt" vary from time = to > time, for example: > igb1: Queue(911600000) tdh =3D -337225283, hw tdt =3D 398180458 > > Unfortunately I don't know what they stand for. Is there an > explanation > for people who don't just look for it in the drivers code? > Any idea where the problem could be? > > Thanks, > > -Harry > > --------------enigBCE487D69772C77491500C3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTbsfYACgkQLDqVQ9VXb8j82QCghhxH3sIzDK1+YH1x5F5DPXkz dnQAn2BLQOSnyUN+xtg1VCgkz1RgZakI =brzu -----END PGP SIGNATURE----- --------------enigBCE487D69772C77491500C3D-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 20:21:31 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EE73D2B for ; Wed, 11 Feb 2015 20:21:31 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1554D617 for ; Wed, 11 Feb 2015 20:21:30 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1BKLULu085513; Wed, 11 Feb 2015 12:21:30 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Brandon Allbery In-Reply-To: References: <126f19356ae6eaf1681262b8ef805dcc@ultimatedns.net>, From: "Chris H" Subject: Re: nfe0: watchdog timeout Date: Wed, 11 Feb 2015 12:21:30 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:21:31 -0000 On Wed, 11 Feb 2015 14:39:41 -0500 Brandon Allbery wrote > On Wed, Feb 11, 2015 at 2:12 PM, Chris H wrote: > > > Had a power outage at home last night. > > I fsck'd the disks, and after bring it back up, I was > > without network, and the: > > nfe0: watchdog timeout > > just keeps repeating. > > > > Seeing that after a power outage, I'd be testing the NIC in another machine > or etc. Thanks for the reply, Brandon. That's a no op. It's an onboard NIC. So unless I get out the exacto knife, or de-solder it. It's not going to happen. ;) On the up-side. I pulled the power from the PSU, and pulled a PCI NIC of the shelf, and shoved into a spare slot. My intention was to force IRQ reassignment, in case the (onboard) NIC was forced into sharing an IRQ for some strange reason. Anyway, plugged in the power cord, and booted the box, and *viola* the nfe0 NIC was back online. Don't know whether it was completely removing the power, the additional NIC, or both. But in the end; all is good. Thanks again, Brandon, for taking the time to respond. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --Chris -- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 20:27:27 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A60AAF65 for ; Wed, 11 Feb 2015 20:27:27 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 353A2652 for ; Wed, 11 Feb 2015 20:27:27 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id h11so3358107wiw.1 for ; Wed, 11 Feb 2015 12:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=15mVjoqHDY3DH/W1aPEcvQcw8kbFi+yRAA175Jmg7qE=; b=nltUMf0N85mWk5sGJf6klM1279lYGc1lRj1ztZMUX9uz97R0GRTJayIDLAzmNfqLo4 sqSgaXnYT4YZjh/IamdGayBMCtmEAiWUgXkNuMOxX5jnNNvLfA7hLaMD9eIqj2qx7DUx lAET+t39CiGSnJC9cQ76TW8nQ9OhH5ncYVejxMNEBaocM3UCgza5vnt3zNrI6tqZR5EE hagAtPCnZCNzlEUqJ9EiMIAhyqZIn/w0KKuR9/0XTMuJkkBiL0qn16bhxsfbCbjqhxic 2m/MYs1EGAa7/dzkq+PPhraWxO70pu0xtYB/MzlVq7AScGfcw3Ls9aGP/zFLO5kD/gIC WFdQ== MIME-Version: 1.0 X-Received: by 10.180.86.201 with SMTP id r9mr53599428wiz.56.1423686445614; Wed, 11 Feb 2015 12:27:25 -0800 (PST) Received: by 10.216.234.74 with HTTP; Wed, 11 Feb 2015 12:27:25 -0800 (PST) In-Reply-To: <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net> References: <126f19356ae6eaf1681262b8ef805dcc@ultimatedns.net> <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net> Date: Wed, 11 Feb 2015 15:27:25 -0500 Message-ID: Subject: Re: nfe0: watchdog timeout From: Brandon Allbery To: Chris H Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:27:27 -0000 On Wed, Feb 11, 2015 at 3:21 PM, Chris H wrote: > > Seeing that after a power outage, I'd be testing the NIC in another > machine > > or etc. > Thanks for the reply, Brandon. > That's a no op. It's an onboard NIC. So unless I get out > the exacto knife, or de-solder it. It's not going to happen. ;) > That was why the "or etc.". I keep various OSes on USB keys for tests of integrated devices --- if it is throwing fits in FreeBSD and it also does so when I boot from a Linux live key, it's a good bet that there's hardware issues. And yes, fully removing power can also help --- often power coming back on is far from clean (may start with an undervoltage or a series of brief "pulses" of power before coming on for real), and integrated devices often get some amount of power even when the machine is "off". (This was also included in "or etc."; there's a number of "standard" things worth trying when a hardware-related failure follows a power event.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:03:56 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A025DF6 for ; Wed, 11 Feb 2015 22:03:56 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACCC385 for ; Wed, 11 Feb 2015 22:03:55 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5A85E56467 for ; Wed, 11 Feb 2015 16:03:54 -0600 (CST) Message-ID: <54DBD1C2.4000108@vangyzen.net> Date: Wed, 11 Feb 2015 17:03:46 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: ssh known_hosts in 10.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:03:56 -0000 -stable: I just updated my workstation from 10.0 to 10.1. Now, ssh is prompting me to accept host keys that I accepted long ago. ssh is looking for the host key in known_hosts using the name given on the command line; it previously used the FQDN. ssh-keygen -F confirms that known_hosts has the same key for the FQDN. If I recall correctly, using the FQDN in known_hosts was a FreeBSD customization. Did this get dropped during the OpenSSH update? Thanks in advance. Eric From owner-freebsd-stable@FreeBSD.ORG Wed Feb 11 22:49:27 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97EF383F for ; Wed, 11 Feb 2015 22:49:27 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 273D09B9 for ; Wed, 11 Feb 2015 22:49:27 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.100]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t1BMnL5R054054 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 11 Feb 2015 22:49:21 GMT (envelope-from matthew@FreeBSD.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t1BMnL5R054054 Authentication-Results: smtp.infracaninophile.co.uk/t1BMnL5R054054; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral Message-ID: <54DBDC70.1080609@FreeBSD.org> Date: Wed, 11 Feb 2015 22:49:20 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ssh known_hosts in 10.1 References: <54DBD1C2.4000108@vangyzen.net> In-Reply-To: <54DBD1C2.4000108@vangyzen.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="psXR5q74eCO3sClfOlbWPDEl9CVt5n386" X-Virus-Scanned: clamav-milter 0.98.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:49:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --psXR5q74eCO3sClfOlbWPDEl9CVt5n386 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/02/2015 22:03, Eric van Gyzen wrote: > I just updated my workstation from 10.0 to 10.1. Now, ssh is prompting= > me to accept host keys that I accepted long ago. ssh is looking for th= e > host key in known_hosts using the name given on the command line; it > previously used the FQDN. ssh-keygen -F confirms that known_hosts has > the same key for the FQDN. >=20 > If I recall correctly, using the FQDN in known_hosts was a FreeBSD > customization. Did this get dropped during the OpenSSH update? It's a different type of SSH key. The new default in 10.1 is to use ECDSA keys (identified typically as ecdsa-sha2-nistp256 in known_hosts), when available, and it's those that SSH is prompting you about. As distinct from the DSA and RSA keys you'll have had in your known_hosts for donkey's years. You can suppress the prompts about new keys by adding appropriate SSHFP records to your DNS, although you should be running with DNSSEC enabled if you choose to do that. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --psXR5q74eCO3sClfOlbWPDEl9CVt5n386 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.20 (Darwin) iQJ8BAEBCgBmBQJU29xxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATHhUP/3rjIVy+sT+dXTbTpwMiM7TC tGaca7bp81NIvZhPCliaZqVTCBgVZ5jrWYu0fK+w1l3mf/MJbl6XY06zJ8w34JUW EW84/FsihLI9sixqJYolB60xPnBPQTYXD5EmNWVoyGNEQHTT0R0CY/fb9jrL6Qz0 5f3L4zWEKyg5PI5+sFn8lQzSqpRm9EUPTFeMdXjKlXZK3ELaTsl5McKeJ+ANIiu6 nMOmwZNbJg44eIGp3FhB69neomZCbLfVBSyQseuDZHkBS0mhaRwvAifAC+tRYD3w QKEt3cH1jebdcJqmdDDy18lYcJKfu3or7bJKbhVf8auBsvjqUGLmesGgQQiffMYN wRxyQY8ims5lOE7x2lfY8VMqWTv11+RZmgCGFGz52QiMFERVsF2FFoRBvGR5WTWX DoLzoeCMbk0Fp4eoFMDjhdM5RPm1YTiBXtOfyWM6NXEMQX26YNvearbG6IV4LYeJ LOXVFW10w0pE9iAEvJRzvJgNftewlfyRyUFPjqwZmvOwPfefKKuTbIbYo4TAntrS U6hzMyci/goRwAyNPJa6PL3r35I1Glt8R/RPw4tJ4P3jAM43qbWYnoLBsJ9I95Fk issdJHCqs+5eoQ8NP4rM/q4vgTw5Q/TeUv/9kD/pNP0Sk17B7643UC/Ctl9hmTJw HiBS9jczDG2+Q76fkiPu =qWh4 -----END PGP SIGNATURE----- --psXR5q74eCO3sClfOlbWPDEl9CVt5n386-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 01:13:43 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0F28D25 for ; Thu, 12 Feb 2015 01:13:43 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 984FCA86 for ; Thu, 12 Feb 2015 01:13:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=KMQ2Ff57wXaq5+OEHIogZ/0QtGOKABA6M+sqXI9Lhzw=; b=xEZKGk6ebOqjayeg2x/W51l17koVE6iPVOR5luKZkAwW0U07uxH0d90l1r5+eEwGxbpY6KGOMEASKzPiIKv8BcOmai47Mtkees95dsLlBesyM1hZUckHkBWeFsre5wlYMO6mDBI9p7VedaXxMBfk76lKUCaXFKn3g488Mfj9l8c=; Received: from [114.124.26.148] (port=19029 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YLiLX-001s23-4k; Wed, 11 Feb 2015 18:13:36 -0700 Date: Thu, 12 Feb 2015 09:13:23 +0800 From: Erich Dollansky To: Bob Willcox Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212091323.245485ba@B85M-HD3-0.alogt.com> In-Reply-To: <20150210231440.GB471@rancor.immure.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: John-Mark Gurney , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:13:43 -0000 Hi, On Tue, 10 Feb 2015 17:14:41 -0600 Bob Willcox wrote: > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > +0800: > > > int can be 64 bits on a amd64 machine. Why is the author of this > > > code so sure that we will never cross the 32 bit boundary? > > > > Per others, int is currently 32bits on all platforms we support... > > > > I guess adding: > > CTASSERT(sizeof(int) <= 4); > > > > would help fix your concern? at least now the expectation is > > codified and if it breaks, the build will break.. > > > > -- > > John-Mark Gurney Voice: +1 415 225 > > 5579 > > > > If/when the size of an int ever changes from being 32 bits, top will > be the least of our worries! > if all dubious statements have asserts in place, nothing will be a worry until then. It is a very bad idea to assume a size for any type when the size can change between compilers. If you want, just read the old discussion regarding time_t. Erich From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 01:36:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4A0EF78 for ; Thu, 12 Feb 2015 01:36:44 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 635B7C93 for ; Thu, 12 Feb 2015 01:36:44 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id w62so7009960wes.9 for ; Wed, 11 Feb 2015 17:36:42 -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=YlQkoVBlW3XoBMPmbd6DNVMOOCK2tlneuKsAL+aiKuQ=; b=GDmEYIFsYYPs+7HtSuz1MEcrNRlaCb07avj5uEIphWGfJYzBjkXBXCgBrcCGVN7oKH TmJDvG8/W/+7I8hePHdIcdhrA2lDjJTT/m8RLemMTOKAlz701S2m/Kl0Nw7YVe08oXxb 6mVv+JA+rdX2MbGqs36dBtV3bzvNH8aF36V3wUYwF5+r8WmLNZ9BpOxt2dz4V5hphofk AjN7S2xdmd7j7xqMoXg4oOM9KpRqHN9+PNtao8l7e8iGS/CTVSXqEfrdnfZT0CFA1SKw MC08rjN51dyO5nQL5fX4UtH2BwiemXrahSwKyzdGlwQrGmUYueazoosZtJ9ittbYUmQT 67gg== MIME-Version: 1.0 X-Received: by 10.180.126.102 with SMTP id mx6mr1522930wib.12.1423705002859; Wed, 11 Feb 2015 17:36:42 -0800 (PST) Received: by 10.216.234.74 with HTTP; Wed, 11 Feb 2015 17:36:42 -0800 (PST) In-Reply-To: <20150212091323.245485ba@B85M-HD3-0.alogt.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> Date: Wed, 11 Feb 2015 20:36:42 -0500 Message-ID: Subject: Re: top, fixed buffer length in utils.c From: Brandon Allbery To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: John-Mark Gurney , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:36:45 -0000 On Wed, Feb 11, 2015 at 8:13 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > It is a very bad idea to assume a size for any type when the size can > change between compilers. > > If you want, just read the old discussion regarding time_t. > I keep feeling like we should have learned *something* in the past 30+ years, instead of rehashing arguments used in the PDP11, and later the 8088, days. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 01:47:39 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08C261A6 for ; Thu, 12 Feb 2015 01:47:39 +0000 (UTC) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDBFDD70 for ; Thu, 12 Feb 2015 01:47:38 +0000 (UTC) Received: by pdno5 with SMTP id o5so8350072pdn.8 for ; Wed, 11 Feb 2015 17:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=EbvlSj+srQWT+pDy7aJx3boOC2q7qruwgvrDz4MAsdw=; b=YPB9azvyf/BoYJYIwNq/iX3nDIR6xSzvtnbg0rz5PlV9KVwBiR+uUzDm71QheAI1Hb 3mFROKD8I6lovB0Op/57oRQbmctXkL/lRIiOIn2uzoBp6Aa3GnOliBeltpOJ/lx7/nkh X8505zWP9akMpX7WFVQ+Ryws9fdSYJBq3fzuD/fhX5r6+g+fsb2DIP/0p792l2O9IGgV JP+e0/bgZ/eYUC1UtMKWfU9nFB7U54FP/C2ARlTrVafaamboq7yrpKwYLcdVE6OOOuTk E82hoPY1T8wKF6a/PVFvh79zbBEZzCUrO8uDB1hBMN+v+bKHvMuUGzDVml9lTauZi72Y +giQ== X-Received: by 10.68.69.108 with SMTP id d12mr2045828pbu.137.1423705657614; Wed, 11 Feb 2015 17:47:37 -0800 (PST) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id j16sm1973896pdm.90.2015.02.11.17.47.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Feb 2015 17:47:36 -0800 (PST) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 12 Feb 2015 10:47:27 +0900 Date: Thu, 12 Feb 2015 10:47:27 +0900 To: Chris H Subject: Re: nfe0: watchdog timeout Message-ID: <20150212014727.GA4152@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD STABLE , Brandon Allbery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 01:47:39 -0000 On Wed, Feb 11, 2015 at 12:21:30PM -0800, Chris H wrote: > On Wed, 11 Feb 2015 14:39:41 -0500 Brandon Allbery wrote > > > On Wed, Feb 11, 2015 at 2:12 PM, Chris H wrote: > > > > > Had a power outage at home last night. > > > I fsck'd the disks, and after bring it back up, I was > > > without network, and the: > > > nfe0: watchdog timeout > > > just keeps repeating. > > > > > > > Seeing that after a power outage, I'd be testing the NIC in another machine > > or etc. > Thanks for the reply, Brandon. > That's a no op. It's an onboard NIC. So unless I get out > the exacto knife, or de-solder it. It's not going to happen. ;) > > On the up-side. I pulled the power from the PSU, and pulled > a PCI NIC of the shelf, and shoved into a spare slot. My > intention was to force IRQ reassignment, in case the (onboard) > NIC was forced into sharing an IRQ for some strange reason. > Anyway, plugged in the power cord, and booted the box, and > *viola* the nfe0 NIC was back online. Don't know whether it > was completely removing the power, the additional NIC, or > both. But in the end; all is good. > Due to lack of publicly available documentation, nfe(4) heavily relies on power-on default H/W configurations(e.g. PHY or power saving related thing). Some of those register configurations are sticky so they shall survive from power cycling. The vendor surely knows the correct sequence to reprogram those registers but the required information is not available to open source driver writers. Cold-boot will always perform full H/W initialization and it will put the controller into known good state. So it's good idea to unplug power cord and wait tens of seconds before boot when you encounter power lost or unexpected watchdog timeouts. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 02:05:19 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC806410; Thu, 12 Feb 2015 02:05:19 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 9F654F25; Thu, 12 Feb 2015 02:05:19 +0000 (UTC) Received: from coconut.local (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 850A756467; Wed, 11 Feb 2015 20:05:18 -0600 (CST) Message-ID: <54DC0A58.6090102@vangyzen.net> Date: Wed, 11 Feb 2015 21:05:12 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matthew Seaman , freebsd-stable@freebsd.org Subject: Re: ssh known_hosts in 10.1 References: <54DBD1C2.4000108@vangyzen.net> <54DBDC70.1080609@FreeBSD.org> In-Reply-To: <54DBDC70.1080609@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:05:19 -0000 On 2/11/15 5:49 PM, Matthew Seaman wrote: > On 11/02/2015 22:03, Eric van Gyzen wrote: >> I just updated my workstation from 10.0 to 10.1. Now, ssh is prompting >> me to accept host keys that I accepted long ago. ssh is looking for the >> host key in known_hosts using the name given on the command line; it >> previously used the FQDN. ssh-keygen -F confirms that known_hosts has >> the same key for the FQDN. >> >> If I recall correctly, using the FQDN in known_hosts was a FreeBSD >> customization. Did this get dropped during the OpenSSH update? > It's a different type of SSH key. The new default in 10.1 is to use > ECDSA keys (identified typically as ecdsa-sha2-nistp256 in known_hosts), > when available, and it's those that SSH is prompting you about. As > distinct from the DSA and RSA keys you'll have had in your known_hosts > for donkey's years. I'm afraid that's not the case. I have scads of ECDSA keys in my known_hosts file. Specifically, the hosts I'm connecting to already have the exact same ECDSA key in known_hosts, with the only difference being the host name (short versus FQDN). ED25519 host keys were added in 10.1. Perhaps you're thinking of those? > You can suppress the prompts about new keys by adding appropriate SSHFP > records to your DNS, although you should be running with DNSSEC enabled > if you choose to do that. I would love to, but I'm only a user (luser?) in this environment, not an admin. Thanks for the reply, Eric From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 02:15:47 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B125774 for ; Thu, 12 Feb 2015 02:15:47 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A32A7D for ; Thu, 12 Feb 2015 02:15:47 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t1C2FkEn047012; Wed, 11 Feb 2015 18:15:47 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Yonghyeon PYUN In-Reply-To: <20150212014727.GA4152@michelle.fasterthan.com> References: <2ea9dbbfc43fbe632dabf8681323ebc9@ultimatedns.net>, <20150212014727.GA4152@michelle.fasterthan.com> From: "Chris H" Subject: Re: nfe0: watchdog timeout Date: Wed, 11 Feb 2015 18:15:47 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD STABLE , Brandon Allbery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:15:47 -0000 On Thu, 12 Feb 2015 10:47:27 +0900 Yonghyeon PYUN wrote > On Wed, Feb 11, 2015 at 12:21:30PM -0800, Chris H wrote: > > On Wed, 11 Feb 2015 14:39:41 -0500 Brandon Allbery > > wrote > > > On Wed, Feb 11, 2015 at 2:12 PM, Chris H wrote: > > > > > > > Had a power outage at home last night. > > > > I fsck'd the disks, and after bring it back up, I was > > > > without network, and the: > > > > nfe0: watchdog timeout > > > > just keeps repeating. > > > > > > > > > > Seeing that after a power outage, I'd be testing the NIC in another > > > machine or etc. > > Thanks for the reply, Brandon. > > That's a no op. It's an onboard NIC. So unless I get out > > the exacto knife, or de-solder it. It's not going to happen. ;) > > > > On the up-side. I pulled the power from the PSU, and pulled > > a PCI NIC of the shelf, and shoved into a spare slot. My > > intention was to force IRQ reassignment, in case the (onboard) > > NIC was forced into sharing an IRQ for some strange reason. > > Anyway, plugged in the power cord, and booted the box, and > > *viola* the nfe0 NIC was back online. Don't know whether it > > was completely removing the power, the additional NIC, or > > both. But in the end; all is good. > > > > Due to lack of publicly available documentation, nfe(4) heavily > relies on power-on default H/W configurations(e.g. PHY or power > saving related thing). Some of those register configurations are > sticky so they shall survive from power cycling. The vendor surely > knows the correct sequence to reprogram those registers but the > required information is not available to open source driver > writers. > Cold-boot will always perform full H/W initialization and it will > put the controller into known good state. So it's good idea to > unplug power cord and wait tens of seconds before boot when you > encounter power lost or unexpected watchdog timeouts. Good call, and thanks for confirming that. I *knew* it ust have been one, or the other. As it would actually communicate a few packets periodically. So I was left with either IRQ's arbitrarily moving (suspected video) because of the intermittent packet activity. Or simply a need to drain the caps, to force a cold post. Anyway, thanks for taking the time to reply. Greatly appreciated! > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --Chris -- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 03:14:05 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 765613F0 for ; Thu, 12 Feb 2015 03:14:05 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 59B0C9C3 for ; Thu, 12 Feb 2015 03:14:05 +0000 (UTC) Received: from coconut.local (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 913EB56467 for ; Wed, 11 Feb 2015 21:14:04 -0600 (CST) Message-ID: <54DC1A78.9010500@vangyzen.net> Date: Wed, 11 Feb 2015 22:14:00 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: stable@freebsd.org Subject: Re: ssh known_hosts in 10.1 References: <54DBD1C2.4000108@vangyzen.net> In-Reply-To: <54DBD1C2.4000108@vangyzen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 03:14:05 -0000 On 2/11/15 5:03 PM, Eric van Gyzen wrote: > -stable: > > I just updated my workstation from 10.0 to 10.1. Now, ssh is prompting > me to accept host keys that I accepted long ago. ssh is looking for the > host key in known_hosts using the name given on the command line; it > previously used the FQDN. ssh-keygen -F confirms that known_hosts has > the same key for the FQDN. > > If I recall correctly, using the FQDN in known_hosts was a FreeBSD > customization. Did this get dropped during the OpenSSH update? As it turns out, OpenSSH 6.5 or 6.6 added a hostname canonicalization feature that--as I understand--should make FreeBSD's customization obsolete. Based on the description in ssh_config, the following should behave as ssh did in 10.0: ssh -o 'CanonicalizeHostname yes' -o 'CanonicalizeFallbackLocal yes' short-name However, it doesn't find the host key, because it's looking for the short-name, not the FQDN: The authenticity of host 'short-name (192.0.2.42)' can't be established. Can anyone else confirm this behavior? Eric From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 03:39:33 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62F66A49 for ; Thu, 12 Feb 2015 03:39:33 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20B4BC6E for ; Thu, 12 Feb 2015 03:39:32 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1C3dOpu070040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 19:39:24 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1C3dOYe070039; Wed, 11 Feb 2015 19:39:24 -0800 (PST) (envelope-from jmg) Date: Wed, 11 Feb 2015 19:39:24 -0800 From: John-Mark Gurney To: Erich Dollansky Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212033924.GB1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212091323.245485ba@B85M-HD3-0.alogt.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 11 Feb 2015 19:39:25 -0800 (PST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 03:39:33 -0000 Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 09:13 +0800: > On Tue, 10 Feb 2015 17:14:41 -0600 > Bob Willcox wrote: > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > > +0800: > > > > int can be 64 bits on a amd64 machine. Why is the author of this > > > > code so sure that we will never cross the 32 bit boundary? > > > > > > Per others, int is currently 32bits on all platforms we support... > > > > > > I guess adding: > > > CTASSERT(sizeof(int) <= 4); > > > > > > would help fix your concern? at least now the expectation is > > > codified and if it breaks, the build will break.. > > > > > > -- > > > John-Mark Gurney Voice: +1 415 225 > > > 5579 > > > > > > > If/when the size of an int ever changes from being 32 bits, top will > > be the least of our worries! > > > if all dubious statements have asserts in place, nothing will be a > worry until then. Feel free to submit a patch eliminating the size assumption... I'll review and commit it if/when you do... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 04:33:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44188B6D for ; Thu, 12 Feb 2015 04:33:40 +0000 (UTC) Received: from maul.immure.com (108-84-10-9.lightspeed.austtx.sbcglobal.net [108.84.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EAC5208 for ; Thu, 12 Feb 2015 04:33:39 +0000 (UTC) Received: from rancor.immure.com ([10.1.132.9]) by maul.immure.com with esmtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YLlSr-0004f9-UB; Wed, 11 Feb 2015 22:33:31 -0600 Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.9/8.14.9) with ESMTP id t1C4XLta006113; Wed, 11 Feb 2015 22:33:21 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.9/8.14.9/Submit) id t1C4XLow006112; Wed, 11 Feb 2015 22:33:21 -0600 (CST) (envelope-from bob) Date: Wed, 11 Feb 2015 22:33:21 -0600 From: Bob Willcox To: Erich Dollansky Message-ID: <20150212043321.GD840@rancor.immure.com> Reply-To: Bob Willcox References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212091323.245485ba@B85M-HD3-0.alogt.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 10.1.132.9 X-SA-Exim-Mail-From: bob@immure.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maul.immure.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: top, fixed buffer length in utils.c X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on maul.immure.com) Cc: John-Mark Gurney , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 04:33:40 -0000 On Thu, Feb 12, 2015 at 09:13:23AM +0800, Erich Dollansky wrote: > Hi, > > On Tue, 10 Feb 2015 17:14:41 -0600 > Bob Willcox wrote: > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > > +0800: > > > > int can be 64 bits on a amd64 machine. Why is the author of this > > > > code so sure that we will never cross the 32 bit boundary? > > > > > > Per others, int is currently 32bits on all platforms we support... > > > > > > I guess adding: > > > CTASSERT(sizeof(int) <= 4); > > > > > > would help fix your concern? at least now the expectation is > > > codified and if it breaks, the build will break.. > > > > > > -- > > > John-Mark Gurney Voice: +1 415 225 > > > 5579 > > > > > > > If/when the size of an int ever changes from being 32 bits, top will > > be the least of our worries! > > > if all dubious statements have asserts in place, nothing will be a > worry until then. > > It is a very bad idea to assume a size for any type when the size can > change between compilers. > > If you want, just read the old discussion regarding time_t. Oh, I've been around since ints were 8 bits (on really old stuff) and appreciate the issues. However my point wasn't that assuming the size is good, but that when ints change we will have lots more serious breakage is all. Bob -- Bob Willcox | You climb to reach the summit, but once bob@immure.com | there, discover that all roads lead down. Austin, TX | -- Stanislaw Lem, "The Cyberiad" From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 06:48:16 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D97A3F7C for ; Thu, 12 Feb 2015 06:48:16 +0000 (UTC) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF41FFE for ; Thu, 12 Feb 2015 06:48:16 +0000 (UTC) Received: by labhs14 with SMTP id hs14so7709965lab.1 for ; Wed, 11 Feb 2015 22:48:08 -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=zi5L8PLOY5e8flOC75PVjmZXosGUbRxyxODZAzSlXjU=; b=gBBH6EqaapEk3GTpyCFb+9uHaZA43NvCwdmesES/xGhUP8aWTq+hm5ty+Es8QuZXKX GGUVDS2UQEdL/XkkT7XAB+WsyrTWeqjUXR/xlTb3RPEhmoc3CJwuc+jHylsTdrsh/YtY 9mc/CLiEG+xKuqP7ZWWfnRg/+oD87cAEc3JoR8V0JaTFF+B/C/sJen2pxsTFQy8XB7kt XwjZTbPL0ovaPoNFvxTKl+TgCn5BhX5YFocA5bVOnBfeKr87IovHQ3toHfyfl/lemMnZ pXPFTKw9J68C6QCNUhcgIP47qIoLqMXQE6vdQ7SoWY5aC7nimndYfFF+uswoN3YjTMKa dJFg== MIME-Version: 1.0 X-Received: by 10.112.40.65 with SMTP id v1mr1977258lbk.26.1423723688427; Wed, 11 Feb 2015 22:48:08 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.28.40 with HTTP; Wed, 11 Feb 2015 22:48:08 -0800 (PST) Received: by 10.112.28.40 with HTTP; Wed, 11 Feb 2015 22:48:08 -0800 (PST) In-Reply-To: <54D3AE68.6040003@shrew.net> References: <20150205130234.3fcbabfb@efreet.mimar.rs> <54D37932.7010808@madpilot.net> <20150205154743.GO88387@mail0.byshenk.net> <3552828A-536D-41AB-B56D-F47AA4164A79@gromit.dlib.vt.edu> <54D3AE68.6040003@shrew.net> Date: Wed, 11 Feb 2015 22:48:08 -0800 X-Google-Sender-Auth: QEBfVXkL2mZ-D-MUM-QVZvPNTIU Message-ID: Subject: Re: push a few config files to dozen or so servers From: Craig Rodrigues To: Matthew Grooms Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 06:48:16 -0000 On Feb 5, 2015 10:14 AM, "Matthew Grooms" wrote: > > > http://saltstack.com/community/ > http://www.freshports.org/sysutils/py-salt/ +1 on Saltstack. I've started using it for basic configuration mgmt and orchestration in the jenkins.freebsd.org cluster and like it. It is easy to install from ports and works great. Ahmed Kamal has been improving FreeBSD support: https://github.com/saltstack/salt/issues/19795 The Saltstack community is super friendly and easy to work with. -- Craig From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 08:12:03 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED019EDC for ; Thu, 12 Feb 2015 08:12:03 +0000 (UTC) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id AC376B36 for ; Thu, 12 Feb 2015 08:12:03 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 8034567917; Thu, 12 Feb 2015 09:11:54 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id EdHN7qbMydqC; Thu, 12 Feb 2015 09:11:53 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 38E65679A6; Thu, 12 Feb 2015 09:11:53 +0100 (CET) Received: from pcadmin2.incore (pcadmin2.incore [192.168.0.149]) by mail.local.incore (Postfix) with ESMTPSA id 2C936508AE; Thu, 12 Feb 2015 09:11:53 +0100 (CET) Message-ID: <54DC6048.2060902@dssgmbh.de> Date: Thu, 12 Feb 2015 09:11:52 +0100 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Eric van Gyzen , stable@freebsd.org Subject: Re: ssh known_hosts in 10.1 References: <54DBD1C2.4000108@vangyzen.net> <54DC1A78.9010500@vangyzen.net> In-Reply-To: <54DC1A78.9010500@vangyzen.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:12:04 -0000 Am 12.02.2015 um 04:14 schrieb Eric van Gyzen: > On 2/11/15 5:03 PM, Eric van Gyzen wrote: >> -stable: >> >> I just updated my workstation from 10.0 to 10.1. Now, ssh is >> prompting me to accept host keys that I accepted long ago. ssh >> is looking for the host key in known_hosts using the name given >> on the command line; it previously used the FQDN. ssh-keygen -F >> confirms that known_hosts has the same key for the FQDN. >> >> If I recall correctly, using the FQDN in known_hosts was a >> FreeBSD customization. Did this get dropped during the OpenSSH >> update? > > As it turns out, OpenSSH 6.5 or 6.6 added a hostname > canonicalization feature that--as I understand--should make > FreeBSD's customization obsolete. Based on the description in > ssh_config, the following should behave as ssh did in 10.0: > > ssh -o 'CanonicalizeHostname yes' -o 'CanonicalizeFallbackLocal > yes' short-name > > However, it doesn't find the host key, because it's looking for > the short-name, not the FQDN: > > The authenticity of host 'short-name (192.0.2.42)' can't be > established. > > Can anyone else confirm this behavior? > > Eric _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable To > unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" Yes, I can confirm this. I'm able to use my old known_hosts after adding two options to /etc/ssh/ssh_config: ... CanonicalizeHostname yes CanonicalDomains xx yy zz ... where xx, yy, zz are the various domains of the destination hosts. HTH Sincerely, Alfred Bartsch Data-Service GmbH From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 08:40:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16B7466E for ; Thu, 12 Feb 2015 08:40:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D90BEDDD for ; Thu, 12 Feb 2015 08:39:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=FIzO3k+Z+gJhrIigRw/Xr40Vn6xmwf7b8sAI4t5CT+U=; b=VxU++UtDU8XpkGVxdiUoz8mQPxPqyFCkFU45MalhS9JzyKJTYq2IIBvTJv8V7NRRI47DkFXLPiwZgk9bedcieHlWHw3G+Grxnevu1QnJj2FNDEdqFbpup5RrIE8uE367qgAJnWwJAPANX0ZQ8xgs3lh3csQrIce1lltzeG9RhiQ=; Received: from [114.124.26.148] (port=57265 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YLpJV-001px0-Jy; Thu, 12 Feb 2015 01:39:58 -0700 Date: Thu, 12 Feb 2015 16:39:45 +0800 From: Erich Dollansky To: John-Mark Gurney Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212163945.36aa9971@B85M-HD3-0.alogt.com> In-Reply-To: <20150212033924.GB1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212033924.GB1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:40:00 -0000 Hi, On Wed, 11 Feb 2015 19:39:24 -0800 John-Mark Gurney wrote: > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 09:13 > +0800: > > On Tue, 10 Feb 2015 17:14:41 -0600 > > Bob Willcox wrote: > > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > > > +0800: > > > > > > > > I guess adding: > > > > CTASSERT(sizeof(int) <= 4); > > > > > Feel free to submit a patch eliminating the size assumption... I'll > review and commit it if/when you do... > did you add CTASSERT(sizeof(int) <= 4); already? This would do as a message will popup when the problem finally arises. Erich From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 10:02:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CD24A34 for ; Thu, 12 Feb 2015 10:02:46 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A130950 for ; Thu, 12 Feb 2015 10:02:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=UH41TKtz/nUF7Lsba2Htee9RIBqmIVN2gFWdzOjKZig=; b=q+VFU89wDkahT1r8fZkPhbqyMRn5CGrZuUmRAtPNc23M/4BFa+SZkxnnKZj5cAr3Qjy/58P5a00ecSvhfnSz0OG6mXCQosnK1Y6xSBOX8A4nquLXIGu9UQqNdI3KZZEVCrl/AfzjE7RwnDgmGBiYuVe50zVf/nM0RXbl4lzKYH8=; Received: from [114.124.26.148] (port=51600 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YLqbb-002dTB-GT; Thu, 12 Feb 2015 03:02:44 -0700 Date: Thu, 12 Feb 2015 18:02:31 +0800 From: Erich Dollansky To: kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> In-Reply-To: <20150212052058.GB77578@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: John-Mark Gurney , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 10:02:46 -0000 Hi, On Thu, 12 Feb 2015 00:20:58 -0500 kpneal@pobox.com wrote: > On Wed, Feb 11, 2015 at 10:33:21PM -0600, Bob Willcox wrote: > > On Thu, Feb 12, 2015 at 09:13:23AM +0800, Erich Dollansky wrote: > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > Bob Willcox wrote: > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney > > > > wrote: > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at > > > > > 17:51 +0800: > > > If you want, just read the old discussion regarding time_t. > > > > Oh, I've been around since ints were 8 bits (on really old stuff) > > and appreciate the issues. However my point wasn't that assuming > > the size is good, but that when ints change we will have lots more > > serious breakage is all. > > But time_t is not a fundamental type. So time_t changing size is much > less of an issue than int changing size. > time_t was introduced some time to avoid the problem of changing data sizes. Wasn't time of the type long before and wasn't it assumed to be 32 bit? > If int changed size we'd need a new type to replace it. Otherwise it'd > be darn near impossible to access memory in 32 byte chunks in anything > resembling a natural way. > I think the original idea behind data types like int or long is that the compiler should use what seems the best fit for a machine. If the program needs a given size, the programmer should use something like int32 etc to avoid all problems when compilers change. > And I submit that the days of int changing with the compiler are long > past. It causes too much havoc. The Amiga had two different sizes of > int based on the two major vendor compilers, and when Commodore > ported the BSD sockets API they had to change all ints to longs. > > Just look at how many POSIX APIs use ints. If int were to change with > the compiler, and so different compilers on the same target were > different, then _every_ _single_ int used by POSIX would need to be > changed. You think a bot too much of staying on the same platform. FreeBSD runs on several platforms. As a consequence, int can be of different size and the POSIX API will not cause a problem. > > Who thinks that's likely? > > Why on Earth would any vendor do something so costly? And why would > the rest of the standards bodies (including POSIX) go along with it? > What says POSIX about the size of int? POSIX just follows the size the compiler uses on a platform. > No, when the day int changes size comes it will be due to computers > being changed in some way that is so fundamental that we may not even > recognize it as a computer. Perhaps it will be organic, or perhaps it > will be a quantum computer. > > Can we please put this issue to rest already? Hopefully. Erich From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 15:51:26 2015 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0685A1FB for ; Thu, 12 Feb 2015 15:51:26 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DBFAE367 for ; Thu, 12 Feb 2015 15:51:25 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 735F456469; Thu, 12 Feb 2015 09:51:19 -0600 (CST) Message-ID: <54DCCBEC.9040104@vangyzen.net> Date: Thu, 12 Feb 2015 10:51:08 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alfred Bartsch , stable@freebsd.org, =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: ssh known_hosts in 10.1 References: <54DBD1C2.4000108@vangyzen.net> <54DC1A78.9010500@vangyzen.net> <54DC6048.2060902@dssgmbh.de> In-Reply-To: <54DC6048.2060902@dssgmbh.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 15:51:26 -0000 On 02/12/2015 03:11, Alfred Bartsch wrote: > Am 12.02.2015 um 04:14 schrieb Eric van Gyzen: >> On 2/11/15 5:03 PM, Eric van Gyzen wrote: >>> -stable: >>> >>> I just updated my workstation from 10.0 to 10.1. Now, ssh is >>> prompting me to accept host keys that I accepted long ago. ssh >>> is looking for the host key in known_hosts using the name given >>> on the command line; it previously used the FQDN. ssh-keygen -F >>> confirms that known_hosts has the same key for the FQDN. >>> >>> If I recall correctly, using the FQDN in known_hosts was a >>> FreeBSD customization. Did this get dropped during the OpenSSH >>> update? >> As it turns out, OpenSSH 6.5 or 6.6 added a hostname >> canonicalization feature that--as I understand--should make >> FreeBSD's customization obsolete. Based on the description in >> ssh_config, the following should behave as ssh did in 10.0: >> >> ssh -o 'CanonicalizeHostname yes' -o 'CanonicalizeFallbackLocal >> yes' short-name >> >> However, it doesn't find the host key, because it's looking for >> the short-name, not the FQDN: >> >> The authenticity of host 'short-name (192.0.2.42)' can't be=20 >> established. >> >> Can anyone else confirm this behavior? > Yes, I can confirm this. > > I'm able to use my old known_hosts after adding two options to > /etc/ssh/ssh_config: > ... > CanonicalizeHostname yes > CanonicalDomains xx yy zz > ... > > where xx, yy, zz are the various domains of the destination hosts. That works for me, too, but it would be quite unfortunate if I had to visit all the machines on which I use the ssh client and copy the search path from /etc/resolv.conf into my ssh config (or the system's) just to preserve the behavior that has been the default for 12 years. It would seem that the intent of CanonicalizeFallbackLocal is to implement behavior similar to FreeBSD's customization of using the FQDN in known_hosts. However, ports/security/openssh-portable--currently at version 6.7p1--still has a patch for this behavior. So, perhaps the patch is still needed, but got dropped from 10.1 by the OpenSSH upgrade. This would seem plausible, since there would have been a merge conflict in that area, due to the new CanonicalizeHostname feature.=20 Applying the patch from the port to the base ssh does restore the behavio= r. Dag-Erling: The update to OpenSSH 6.5p1 (r261320) removed FreeBSD's customization to use the canonical hostname (FQDN) in the known_hosts file. Was this intentional? Could it be restored? Conveniently, patch-ssh.c from security/openssh-portable applies cleanly to releng/10.1 (and to head, I expect). Kind regards, Eric From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 20:22:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ABF68D5 for ; Thu, 12 Feb 2015 20:22:48 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EC0276A for ; Thu, 12 Feb 2015 20:22:48 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1CKMjpT080212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 12:22:46 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1CKMjXx080211; Thu, 12 Feb 2015 12:22:45 -0800 (PST) (envelope-from jmg) Date: Thu, 12 Feb 2015 12:22:45 -0800 From: John-Mark Gurney To: Erich Dollansky Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212202245.GE1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212033924.GB1953@funkthat.com> <20150212163945.36aa9971@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212163945.36aa9971@B85M-HD3-0.alogt.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 12 Feb 2015 12:22:46 -0800 (PST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 20:22:48 -0000 Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 16:39 +0800: > Hi, > > On Wed, 11 Feb 2015 19:39:24 -0800 > John-Mark Gurney wrote: > > > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 09:13 > > +0800: > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > Bob Willcox wrote: > > > > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney wrote: > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at 17:51 > > > > > +0800: > > > > > > > > > > I guess adding: > > > > > CTASSERT(sizeof(int) <= 4); > > > > > > > Feel free to submit a patch eliminating the size assumption... I'll > > review and commit it if/when you do... > > > did you add > > CTASSERT(sizeof(int) <= 4); > > already? > > This would do as a message will popup when the problem finally arises. Similar... https://svnweb.freebsd.org/changeset/base/278560 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Thu Feb 12 23:21:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69AC7B1D for ; Thu, 12 Feb 2015 23:21:48 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E41EC8A for ; Thu, 12 Feb 2015 23:21:47 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1CNLjsB081431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 15:21:45 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1CNLjDX081430; Thu, 12 Feb 2015 15:21:45 -0800 (PST) (envelope-from jmg) Date: Thu, 12 Feb 2015 15:21:45 -0800 From: John-Mark Gurney To: Erich Dollansky Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150212232145.GG1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 12 Feb 2015 15:21:45 -0800 (PST) Cc: freebsd-stable@freebsd.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 23:21:48 -0000 Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 18:02 +0800: > On Thu, 12 Feb 2015 00:20:58 -0500 > kpneal@pobox.com wrote: > > > On Wed, Feb 11, 2015 at 10:33:21PM -0600, Bob Willcox wrote: > > > On Thu, Feb 12, 2015 at 09:13:23AM +0800, Erich Dollansky wrote: > > > > On Tue, 10 Feb 2015 17:14:41 -0600 > > > > Bob Willcox wrote: > > > > > On Mon, Feb 02, 2015 at 04:33:07PM -0800, John-Mark Gurney > > > > > wrote: > > > > > > Erich Dollansky wrote this message on Sun, Feb 01, 2015 at > > > > > > 17:51 +0800: > > > > If you want, just read the old discussion regarding time_t. > > > > > > Oh, I've been around since ints were 8 bits (on really old stuff) > > > and appreciate the issues. However my point wasn't that assuming > > > the size is good, but that when ints change we will have lots more > > > serious breakage is all. > > > > But time_t is not a fundamental type. So time_t changing size is much > > less of an issue than int changing size. > > > time_t was introduced some time to avoid the problem of changing data > sizes. Wasn't time of the type long before and wasn't it assumed to be > 32 bit? Sadly, it looks like we may have to introduce a new i386 "platform"/ABI in order to deal w/ the fact that time_t is only 32bits to address the 2038 problem.. > > If int changed size we'd need a new type to replace it. Otherwise it'd > > be darn near impossible to access memory in 32 byte chunks in anything > > resembling a natural way. > > > I think the original idea behind data types like int or long is that > the compiler should use what seems the best fit for a machine. If the > program needs a given size, the programmer should use something like > int32 etc to avoid all problems when compilers change. It wasn't till C99 that int32_t and friends were standardized... So, lots of programming was done long before sized types were standard... Before then people were rolling their own, or simply assuming the sizes... Though as standards go, Microsoft still refeses to add these standard types, causing all sorts of problems.. > > And I submit that the days of int changing with the compiler are long > > past. It causes too much havoc. The Amiga had two different sizes of > > int based on the two major vendor compilers, and when Commodore > > ported the BSD sockets API they had to change all ints to longs. > > > > Just look at how many POSIX APIs use ints. If int were to change with > > the compiler, and so different compilers on the same target were > > different, then _every_ _single_ int used by POSIX would need to be > > changed. > > You think a bot too much of staying on the same platform. FreeBSD runs > on several platforms. As a consequence, int can be of different size > and the POSIX API will not cause a problem. I don't know of any int size other than 32bit for all supported FreeBSD platforms.. All platforms are either ILP32 or LP64 as far as I know.. > > Who thinks that's likely? > > > > Why on Earth would any vendor do something so costly? And why would > > the rest of the standards bodies (including POSIX) go along with it? > > > What says POSIX about the size of int? POSIX just follows the size the > compiler uses on a platform. > > > No, when the day int changes size comes it will be due to computers > > being changed in some way that is so fundamental that we may not even > > recognize it as a computer. Perhaps it will be organic, or perhaps it > > will be a quantum computer. > > > > Can we please put this issue to rest already? > > Hopefully. Just adding color/history... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 05:16:55 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC3CE730 for ; Fri, 13 Feb 2015 05:16:55 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 497DA403 for ; Fri, 13 Feb 2015 05:16:55 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so14490398wgh.0 for ; Thu, 12 Feb 2015 21:16:53 -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=K0dW394ivxnrLlLoYqLA1GZakPozE4jGYETPpKkRKes=; b=gWupIGLS0bdxhp3LH+T9JVWv4fAsppg/PN0LrGadZm02jClir3NKJEWoUcHnb8rDaX Azh3uEmT2dBVeWcl3r5r6qDIguMTvZEYByKHe+cHsz51eM7z/R7Eq/BbE3bJJPpo5TTR f9iHpnlSCdmK2g0MvaX1vXmlo7OLlQ62v/NQ4EsDJyF1R1oU8xafVFXErloMG1DsMmWj poAFP7SKK/YnSL4k9US1fj2SqLChVrfyVlRa5kNpXcXQu8czNNRqKkpDdjkexvE2sRRj Uf8k/tdmL1qFof5kvz12ETEviucirgVVfVkBieSpqQI6MEdq715CqVhMBX+ORq0H/SB8 eYCQ== MIME-Version: 1.0 X-Received: by 10.194.61.51 with SMTP id m19mr14611583wjr.39.1423804613491; Thu, 12 Feb 2015 21:16:53 -0800 (PST) Received: by 10.216.234.74 with HTTP; Thu, 12 Feb 2015 21:16:53 -0800 (PST) In-Reply-To: <20150213035002.GA68549@neutralgood.org> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> <20150213035002.GA68549@neutralgood.org> Date: Fri, 13 Feb 2015 00:16:53 -0500 Message-ID: Subject: Re: top, fixed buffer length in utils.c From: Brandon Allbery To: kpneal@pobox.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Erich Dollansky , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 05:16:55 -0000 On Thu, Feb 12, 2015 at 10:50 PM, wrote: > The case where int varies in size between platforms is distinct from the > case where int varies in size between compilers on the same platform. If > you reread what I wrote you'll see that I was addressing the latter case. > C++ at least defines platform ABIs starting with C++11. If ANSI C does not now, I suspect it will --- interoperability issues have come up before (for example, in the early x86 days there were differences between how C compilers packed structs. And in the *very* early x86 days there were differences between compilers in the exact details of (int) and (long) and pointer types in different memory models) and the result is that these days there is usually (but not always) a de facto ABI for a platform. It's not quite as wild-west as you make it sound. People *do* occasionally learn from past mistakes. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 05:31:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E5D38D5 for ; Fri, 13 Feb 2015 05:31:30 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E81757AB for ; Fri, 13 Feb 2015 05:31:29 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id i50so11743131qgf.2 for ; Thu, 12 Feb 2015 21:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hd4ixtzNu+FxkKsSPC98h8CzgcFVNRH62IcT5yXd7Rk=; b=xSBDw07due4L/6G05n2uL+2wdtrAyCEF45RBLVR/S0aXBBuE6WX/8wD3VxUDzEUBoC PqxZlNEXHxaSwLDGsAG0+m0Unn3/KzZu9LhAJNxIu003lMzZbIljsE0spWpe36up6Twl eNLaeY8YtUoVCjFEP9leQfC6jTw1zRyXEl6mHYtx99XIzk7VJ6CtQKPH/rMqIIzcov9M hy8/0xYYAuxDWm5EnW02WZOkmMvsGSOIUcrqAAm6BMtbtZ7NFDFX3jNTTIWF6GUaJ1bC tNuU7vhI5vxIy9PUT2Xe35kL69ICv3qSYwTurUcu94jI0PtnWVmTtjmgGnB+/uUPLu9D 7IGA== MIME-Version: 1.0 X-Received: by 10.140.22.234 with SMTP id 97mr18505801qgn.21.1423805488848; Thu, 12 Feb 2015 21:31:28 -0800 (PST) Sender: geeohgeegeeoh@gmail.com Received: by 10.96.76.199 with HTTP; Thu, 12 Feb 2015 21:31:28 -0800 (PST) Date: Fri, 13 Feb 2015 15:31:28 +1000 X-Google-Sender-Auth: pz0ciwm2R6nenDRpevhp_wW7qxo Message-ID: Subject: freebsd-update 10.0p5 ->10.1 hits chflags or other problems on libc.so and init From: George Michaelson To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 05:31:30 -0000 Whats the right path out, when freebsd-update barfs on chflags for files? I've been hit by libc.so and /sbin/init being barfed. This is possibly the second time. I have about 15 hosts to do, holding off the rest until I understand the risks. (simple searches don't show a fix, but do show back history of freebsd-update sometimes coming unstuck on this kind of thing) -G From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 07:40:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEC1B3AB for ; Fri, 13 Feb 2015 07:40:46 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A22F76DC for ; Fri, 13 Feb 2015 07:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=5iqzwtZKrsv/ThZE5Fg1I3uAgPwR3a/UHPRRLUlIUwo=; b=W75r1qb0ZTg1J278rr7Ap1WBVKb557dGbE2J8kZezzzkhNThDwxe6DtU+69482+b+Kynk0HPNuRrFkmQtcy7oB8Xj88zEFdjIq2Blcn2ra9+2lVMmrAhTm+qtrlLx8eyHTshgXm7v6kBYSG0B3XLiYClCQ0JHaHIbHQ1XtLmVek=; Received: from [114.124.26.58] (port=55206 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YMAre-000sY2-2I; Fri, 13 Feb 2015 00:40:39 -0700 Date: Fri, 13 Feb 2015 15:40:30 +0800 From: Erich Dollansky To: John-Mark Gurney Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150213154030.00a03e81@B85M-HD3-0.alogt.com> In-Reply-To: <20150212232145.GG1953@funkthat.com> References: <20150201175159.7fa88d16@B85M-HD3-0.alogt.com> <20150203003307.GG27103@funkthat.com> <20150210231440.GB471@rancor.immure.com> <20150212091323.245485ba@B85M-HD3-0.alogt.com> <20150212043321.GD840@rancor.immure.com> <20150212052058.GB77578@neutralgood.org> <20150212180231.737ea2ba@B85M-HD3-0.alogt.com> <20150212232145.GG1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 07:40:47 -0000 Hi, On Thu, 12 Feb 2015 15:21:45 -0800 John-Mark Gurney wrote: > Erich Dollansky wrote this message on Thu, Feb 12, 2015 at 18:02 > +0800: > > On Thu, 12 Feb 2015 00:20:58 -0500 > > kpneal@pobox.com wrote: > > > But time_t is not a fundamental type. So time_t changing size is > > > much less of an issue than int changing size. > > > > > time_t was introduced some time to avoid the problem of changing > > data sizes. Wasn't time of the type long before and wasn't it > > assumed to be 32 bit? > > Sadly, it looks like we may have to introduce a new i386 > "platform"/ABI in order to deal w/ the fact that time_t is only > 32bits to address the 2038 problem.. we are in a real hurry then ... > > > > If int changed size we'd need a new type to replace it. Otherwise > > > it'd be darn near impossible to access memory in 32 byte chunks > > > in anything resembling a natural way. > > > > > I think the original idea behind data types like int or long is that > > the compiler should use what seems the best fit for a machine. If > > the program needs a given size, the programmer should use something > > like int32 etc to avoid all problems when compilers change. > > It wasn't till C99 that int32_t and friends were standardized... So, I know. As I was used to develop hardware plus the software to run it, I was forced from the beginning to make sure that a data type matches 100% the hardware. > lots of programming was done long before sized types were standard... > Before then people were rolling their own, or simply assuming the > sizes... Though as standards go, Microsoft still refeses to add these > standard types, causing all sorts of problems.. > It seems that I am lucky there. > > You think a bot too much of staying on the same platform. FreeBSD > > runs on several platforms. As a consequence, int can be of > > different size and the POSIX API will not cause a problem. > > I don't know of any int size other than 32bit for all supported > FreeBSD platforms.. All platforms are either ILP32 or LP64 as far as > I know.. > I do not know. I am just allergic against all potential problems. Why allow a problem to come in quietly if we can easily avoid it. Irony is that one of my own programs has had a solution I did not like. When I saw top running, I realised that top must have a code similar to my code. So, I started to dig and found this by chance. I did not think at all that the discussion will get out of scale like this. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 08:33:39 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A17D7E0 for ; Fri, 13 Feb 2015 08:33:39 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02C39D08 for ; Fri, 13 Feb 2015 08:33:38 +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 t1D8XPkI036074; Fri, 13 Feb 2015 00:33:29 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201502130833.t1D8XPkI036074@gw.catspoiler.org> Date: Fri, 13 Feb 2015 00:33:25 -0800 (PST) From: Don Lewis Subject: Re: top, fixed buffer length in utils.c To: allbery.b@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: erichsfreebsdlist@alogt.com, freebsd-stable@FreeBSD.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 08:33:39 -0000 On 13 Feb, Brandon Allbery wrote: > On Thu, Feb 12, 2015 at 10:50 PM, wrote: > >> The case where int varies in size between platforms is distinct from the >> case where int varies in size between compilers on the same platform. If >> you reread what I wrote you'll see that I was addressing the latter case. >> > > C++ at least defines platform ABIs starting with C++11. If ANSI C does not > now, I suspect it will --- interoperability issues have come up before (for > example, in the early x86 days there were differences between how C > compilers packed structs. And in the *very* early x86 days there were > differences between compilers in the exact details of (int) and (long) and > pointer types in different memory models) and the result is that these days > there is usually (but not always) a de facto ABI for a platform. At least that's somewhat sane. My first real exposure to C was on a machine where int was 24 bits. I think short was as well. Long, float, and double were all 48 bits as I recall. Char was 8 bits, so having three chars in a word made char * arithmetic interesting. At least it could use ASCII. Porting "normal" software to that machine was lots of fun. If it would have had 6-bit characters like a machine that I used in my pre-C days would have made pointer arithmetic easier because four characters would have fit in a word, but that machine actually had 36-bit words. So far as I know, it never got a C compiler. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 11:48:56 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C960E52; Fri, 13 Feb 2015 11:48:56 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC2B2272; Fri, 13 Feb 2015 11:48:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1DBmdfI061924; Fri, 13 Feb 2015 22:48:40 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 13 Feb 2015 22:48:39 +1100 (EST) From: Ian Smith To: Don Lewis Subject: Re: top, fixed buffer length in utils.c In-Reply-To: <201502130833.t1D8XPkI036074@gw.catspoiler.org> Message-ID: <20150213215013.B38620@sola.nimnet.asn.au> References: <201502130833.t1D8XPkI036074@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: erichsfreebsdlist@alogt.com, freebsd-stable@freebsd.org, allbery.b@gmail.com, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 11:48:56 -0000 On Fri, 13 Feb 2015 08:33:25 -0800, Don Lewis wrote: > On 13 Feb, Brandon Allbery wrote: > > On Thu, Feb 12, 2015 at 10:50 PM, wrote: > > > >> The case where int varies in size between platforms is distinct from the > >> case where int varies in size between compilers on the same platform. If > >> you reread what I wrote you'll see that I was addressing the latter case. > >> > > > > C++ at least defines platform ABIs starting with C++11. If ANSI C does not > > now, I suspect it will --- interoperability issues have come up before (for > > example, in the early x86 days there were differences between how C > > compilers packed structs. And in the *very* early x86 days there were > > differences between compilers in the exact details of (int) and (long) and > > pointer types in different memory models) and the result is that these days > > there is usually (but not always) a de facto ABI for a platform. > > At least that's somewhat sane. My first real exposure to C was on a > machine where int was 24 bits. I think short was as well. Long, float, > and double were all 48 bits as I recall. Char was 8 bits, so having > three chars in a word made char * arithmetic interesting. At least it > could use ASCII. Porting "normal" software to that machine was lots of > fun. > > If it would have had 6-bit characters like a machine that I used in my > pre-C days would have made pointer arithmetic easier because four > characters would have fit in a word, but that machine actually had > 36-bit words. So far as I know, it never got a C compiler. I'm finding this drawn-out speculation kind of amusing. My first real systems programming job was converting hundreds of data files from NCR 315 to IBM S/360|370 format for $largemultinational in Sydney C. 1971. The NCR315 was a 12-bit machine (32k 12-bit 'slabs' of real core memory) and the shiny new IBM S/370-145 (64k of 32-bit, DTL|TTL tech IIRC) where the NCR used 6 bit chars (uppercase only), 2 per slab and numbers were all BCD, 3 per slab, to the IBM's 8-bit EBCDIC chars and mostly BCD numbers, no floats at least in the data files these subsidiaries used. What was most fun was that the NCR wrote 7-track paper or mag tape, the standard IBM used 9-track mag or paper tape, so we had to dig up and write (what we would call) drivers for a 7-track paper tape reader and some fairly generic file format conversion programs, some of which had to be postproccessed to newer formats. Data file conversion took many months, longer than connversion/rewriting of mostly COBOL programs, most having a goodly number of added assembler fixes in their 'patch area'. The highest level language on the S/370 was then PL/I. If there was anything happening in C for those machines, I never heard about it; systems programming was macro assembly language all the way. I even left keeping an assembler listing of the /370's (what we would call) kernel, over 2 inches of 15-inch fanfold paper, but it got eaten by rainforest moulds and bugs in the late '70s. I still kinda miss it! Off-topic? I expect it's almost de rigeur for this thread .. <&^}= cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 13 22:04:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C578B1E; Fri, 13 Feb 2015 22:04:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3C57C10A; Fri, 13 Feb 2015 22:04:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 78E9849F; Fri, 13 Feb 2015 22:03:58 +0000 (UTC) Date: Fri, 13 Feb 2015 22:03:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, dim@FreeBSD.org, ngie@FreeBSD.org Message-ID: <58403023.46.1423865037882.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_9 #665 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:04:00 -0000 See Changes: [ngie] Regen src.conf(5) [ngie] MFstable/10 r278556: r278556: MFC r277725: r277725: Add MK_HAST knob for building and installing hastd(8), et al Sponsored by: EMC / Isilon Storage Division [ngie] MFC r278717: r278717: MFC r277678: r277678: Add MK_CCD knob for building and installing ccd(4), ccdconfig, etc Sponsored by: EMC / Isilon Storage Division [dim] MFC r271931: Add a few missing llvm/clang patches, update the other ones to be able to apply with the same patch options onto a fresh upstream llvm/clang 3.4.1 checkout, and use approximately the same header tempate for them. [ngie] MFC r278713: r278713: MFC r277677: r277677: Add MK_BSDINSTALL knob for building and installing bsdinstall Sponsored by: EMC / Isilon Storage Division [ngie] MFstable/10 r278710: r278710: MFC r277676: r277676: Add MK_TALK knob for building the talk and talkd Sponsored by: EMC / Isilon Storage Division [dim] MFC r271025, r271029, r271030 (by sbruno): MFV: Only emit movw on ARMv6T2 Building for the FreeBSD default target ARMv6 was emitting movw ASM on certain test cases (found building qmake4/5 for ARM). Don't do that, moreover, the AS in base doesn't understand this instruction for this target. One would need to use --integrated-as to get this to build if desired. http://llvm.org/viewvc/llvm-project?view=revision&revision=216989 Submitted by: ian Reviewed by: dim Obtained from: llvm.org ------------------------------------------ [...truncated 2825 lines...] ===> usr.sbin/makefs (cleandir) ===> usr.bin/systat (cleandir) ===> usr.sbin/lpr/lp (cleandir) ===> usr.sbin/makemap (cleandir) ===> usr.sbin/lpr/lpc (cleandir) ===> usr.sbin/lpr/lpd (cleandir) ===> usr.bin/tabs (cleandir) ===> usr.sbin/lpr/lpq (cleandir) ===> usr.bin/tail (cleandir) ===> usr.sbin/memcontrol (cleandir) ===> usr.sbin/manctl (cleandir) ===> usr.sbin/lpr/lpr (cleandir) ===> usr.bin/talk (cleandir) ===> usr.bin/tar (cleandir) ===> usr.bin/tcopy (cleandir) ===> usr.sbin/lpr/lprm (cleandir) ===> usr.sbin/mergemaster (cleandir) ===> usr.sbin/mfiutil (cleandir) ===> usr.bin/tee (cleandir) ===> usr.sbin/lpr/lptest (cleandir) ===> usr.bin/telnet (cleandir) ===> usr.sbin/mixer (cleandir) ===> usr.sbin/lpr/pac (cleandir) ===> usr.bin/tftp (cleandir) ===> usr.sbin/lpr/filters (cleandir) ===> usr.bin/time (cleandir) ===> usr.sbin/mld6query (cleandir) ===> usr.sbin/lpr/filters.ru (cleandir) ===> usr.sbin/mlxcontrol (cleandir) ===> usr.bin/tip (cleandir) ===> usr.sbin/mount_nwfs (cleandir) ===> usr.bin/tip/tip (cleandir) ===> usr.sbin/lpr/filters.ru/koi2alt (cleandir) ===> usr.bin/top (cleandir) rm -f koi2alt koi2alt.o ===> usr.bin/touch (cleandir) rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin/lpr/filters.ru/koi2855 (cleandir) ===> usr.sbin/mount_portalfs (cleandir) ===> usr.sbin/mount_smbfs (cleandir) rm -f koi2855 koi2855.o rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/tput (cleandir) ===> usr.bin/tr (cleandir) ===> usr.bin/true (cleandir) ===> usr.sbin/mountd (cleandir) ===> usr.bin/truncate (cleandir) ===> usr.sbin/moused (cleandir) ===> usr.sbin/mptable (cleandir) ===> usr.bin/truss (cleandir) ===> usr.sbin/mptutil (cleandir) ===> usr.bin/tset (cleandir) ===> usr.bin/tsort (cleandir) ===> usr.sbin/mtest (cleandir) ===> usr.sbin/mtree (cleandir) ===> usr.bin/tty (cleandir) ===> usr.sbin/named (cleandir) ===> usr.bin/ul (cleandir) ===> usr.bin/uname (cleandir) ===> usr.bin/unexpand (cleandir) ===> usr.sbin/named-checkconf (cleandir) ===> usr.bin/unifdef (cleandir) ===> usr.sbin/named-checkzone (cleandir) ===> usr.bin/uniq (cleandir) ===> usr.sbin/named-journalprint (cleandir) ===> usr.sbin/ndiscvt (cleandir) ===> usr.bin/units (cleandir) ===> usr.bin/unvis (cleandir) ===> usr.sbin/ndp (cleandir) ===> usr.sbin/newsyslog (cleandir) ===> usr.bin/unzip (cleandir) ===> usr.bin/usbhidaction (cleandir) ===> usr.sbin/nfscbd (cleandir) ===> usr.sbin/nfsd (cleandir) ===> usr.sbin/nfsdumpstate (cleandir) ===> usr.bin/usbhidctl (cleandir) ===> usr.bin/users (cleandir) ===> usr.sbin/nfsrevoke (cleandir) ===> usr.bin/uudecode (cleandir) ===> usr.sbin/nfsuserd (cleandir) ===> usr.sbin/ngctl (cleandir) ===> usr.bin/uuencode (cleandir) ===> usr.sbin/nghook (cleandir) ===> usr.bin/vacation (cleandir) ===> usr.bin/vgrind (cleandir) ===> usr.sbin/nmtree (cleandir) ===> usr.bin/vi (cleandir) ===> usr.sbin/nologin (cleandir) ===> usr.sbin/nscd (cleandir) ===> usr.bin/vis (cleandir) ===> usr.bin/vmstat (cleandir) ===> usr.sbin/nsec3hash (cleandir) ===> usr.bin/w (cleandir) ===> usr.sbin/ntp (cleandir) ===> usr.bin/wall (cleandir) ===> usr.sbin/ntp/libopts (cleandir) ===> usr.sbin/pc-sysinstall (cleandir) ===> usr.sbin/pciconf (cleandir) ===> usr.sbin/ntp/libntp (cleandir) ===> usr.sbin/pc-sysinstall/backend (cleandir) ===> usr.bin/wc (cleandir) ===> usr.bin/what (cleandir) ===> usr.sbin/pc-sysinstall/backend-partmanager (cleandir) ===> usr.sbin/periodic (cleandir) ===> usr.sbin/pc-sysinstall/backend-query (cleandir) ===> usr.bin/whereis (cleandir) ===> usr.bin/which (cleandir) ===> usr.sbin/pc-sysinstall/conf (cleandir) ===> usr.sbin/pkg (cleandir) ===> usr.sbin/pc-sysinstall/doc (cleandir) ===> usr.sbin/ntp/libparse (cleandir) ===> usr.bin/who (cleandir) ===> usr.sbin/pc-sysinstall/examples (cleandir) ===> usr.bin/whois (cleandir) ===> usr.sbin/pkg_install (cleandir) ===> usr.sbin/ntp/ntpd (cleandir) ===> usr.sbin/pc-sysinstall/pc-sysinstall (cleandir) ===> usr.sbin/pkg_install/lib (cleandir) ===> usr.bin/write (cleandir) ===> usr.bin/wtmpcvt (cleandir) ===> usr.sbin/pmcannotate (cleandir) ===> usr.sbin/pkg_install/add (cleandir) ===> usr.bin/xargs (cleandir) ===> usr.sbin/ntp/ntpdc (cleandir) ===> usr.bin/xinstall (cleandir) ===> usr.sbin/pkg_install/create (cleandir) ===> usr.sbin/pmccontrol (cleandir) ===> usr.bin/xlint (cleandir) ===> usr.sbin/ntp/ntpq (cleandir) ===> usr.sbin/pkg_install/delete (cleandir) ===> usr.bin/xlint/lint1 (cleandir) ===> usr.bin/xstr (cleandir) ===> usr.sbin/ntp/ntpdate (cleandir) ===> usr.sbin/pkg_install/info (cleandir) ===> usr.sbin/pmcstat (cleandir) ===> usr.bin/xlint/lint2 (cleandir) ===> usr.sbin/ntp/ntptime (cleandir) ===> usr.sbin/pkg_install/updating (cleandir) ===> usr.bin/xlint/xlint (cleandir) ===> usr.bin/xz (cleandir) ===> usr.sbin/pkg_install/version (cleandir) ===> usr.sbin/ntp/ntp-keygen (cleandir) ===> usr.bin/xlint/llib (cleandir) ===> usr.sbin/ntp/sntp (cleandir) ===> usr.bin/xzdec (cleandir) ===> usr.sbin/portsnap (cleandir) ===> usr.sbin/powerd (cleandir) ===> usr.bin/yacc (cleandir) ===> usr.sbin/portsnap/portsnap (cleandir) ===> usr.sbin/ntp/doc (cleandir) ===> usr.sbin/portsnap/make_index (cleandir) ===> usr.bin/yes (cleandir) ===> usr.bin/ypcat (cleandir) ===> usr.sbin/portsnap/phttpget (cleandir) ===> usr.sbin/ppp (cleandir) ===> usr.sbin/pppctl (cleandir) ===> usr.bin/ypmatch (cleandir) ===> usr.sbin/praliases (cleandir) ===> usr.bin/ypwhich (cleandir) ===> usr.sbin/praudit (cleandir) ===> usr.sbin/procctl (cleandir) ===> usr.sbin/pstat (cleandir) ===> usr.sbin/pw (cleandir) ===> usr.sbin/pwd_mkdb (cleandir) ===> usr.sbin/quot (cleandir) ===> usr.sbin/quotaon (cleandir) ===> usr.sbin/rarpd (cleandir) ===> usr.sbin/repquota (cleandir) ===> usr.sbin/rip6query (cleandir) ===> usr.sbin/rmt (cleandir) ===> usr.sbin/rndc (cleandir) ===> usr.sbin/rndc-confgen (cleandir) ===> usr.sbin/route6d (cleandir) ===> usr.sbin/rpc.lockd (cleandir) ===> usr.sbin/rpc.statd (cleandir) ===> usr.sbin/rpc.umntall (cleandir) ===> usr.sbin/rpc.yppasswdd (cleandir) ===> usr.sbin/rpc.ypupdated (cleandir) ===> usr.sbin/rpc.ypxfrd (cleandir) ===> usr.sbin/rpcbind (cleandir) ===> usr.sbin/rrenumd (cleandir) ===> usr.sbin/rtadvctl (cleandir) ===> usr.sbin/rtadvd (cleandir) ===> usr.sbin/rtprio (cleandir) ===> usr.sbin/rtsold (cleandir) ===> usr.sbin/rwhod (cleandir) ===> usr.sbin/sa (cleandir) ===> usr.sbin/sade (cleandir) ===> usr.sbin/sendmail (cleandir) ===> usr.sbin/service (cleandir) ===> usr.sbin/services_mkdb (cleandir) ===> usr.sbin/setfib (cleandir) ===> usr.sbin/setfmac (cleandir) ===> usr.sbin/setpmac (cleandir) ===> usr.sbin/sicontrol (cleandir) ===> usr.sbin/smbmsg (cleandir) ===> usr.sbin/snapinfo (cleandir) ===> usr.sbin/spkrtest (cleandir) ===> usr.sbin/spray (cleandir) ===> usr.sbin/sysinstall (cleandir) ===> usr.sbin/syslogd (cleandir) ===> usr.sbin/sysrc (cleandir) ===> usr.sbin/tcpdchk (cleandir) ===> usr.sbin/tcpdmatch (cleandir) ===> usr.sbin/tcpdrop (cleandir) ===> usr.sbin/tcpdump (cleandir) ===> usr.sbin/tcpdump/tcpdump (cleandir) ===> usr.sbin/timed (cleandir) ===> usr.sbin/traceroute (cleandir) ===> usr.sbin/timed/timed (cleandir) ===> usr.sbin/traceroute6 (cleandir) ===> usr.sbin/trpt (cleandir) ===> usr.sbin/tzsetup (cleandir) ===> usr.sbin/timed/timedc (cleandir) ===> usr.sbin/uathload (cleandir) ===> usr.sbin/ugidfw (cleandir) ===> usr.sbin/uhsoctl (cleandir) ===> usr.sbin/usbconfig (cleandir) ===> usr.sbin/usbdump (cleandir) ===> usr.sbin/utxrm (cleandir) ===> usr.sbin/vidcontrol (cleandir) ===> usr.sbin/vipw (cleandir) ===> usr.sbin/wake (cleandir) ===> usr.sbin/watch (cleandir) ===> usr.sbin/watchdogd (cleandir) ===> usr.sbin/wlandebug (cleandir) ===> usr.sbin/wpa (cleandir) ===> usr.sbin/yp_mkdb (cleandir) ===> usr.sbin/wpa/wpa_supplicant (cleandir) ===> usr.sbin/ypbind (cleandir) ===> usr.sbin/yppoll (cleandir) ===> usr.sbin/yppush (cleandir) ===> usr.sbin/ypserv (cleandir) ===> usr.sbin/ypset (cleandir) ===> usr.sbin/zic (cleandir) ===> usr.sbin/zzz (cleandir) ===> usr.sbin/zic/zic (cleandir) ===> usr.sbin/zic/zdump (cleandir) ===> usr.sbin/wpa/wpa_cli (cleandir) ===> usr.sbin/wpa/wpa_passphrase (cleandir) ===> usr.sbin/wpa/hostapd (cleandir) ===> usr.sbin/wpa/hostapd_cli (cleandir) ===> usr.sbin/wpa/ndis_events (cleandir) 1 error *** [_cleanobj] Error code 2 1 error *** [buildworld] Error code 2 1 error Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 07:30:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 552B0E70; Sat, 14 Feb 2015 07:30:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 42DD4C80; Sat, 14 Feb 2015 07:30:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A8E04554; Sat, 14 Feb 2015 07:30:17 +0000 (UTC) Date: Sat, 14 Feb 2015 07:29:30 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, dim@FreeBSD.org, ngie@FreeBSD.org Message-ID: <1693883392.49.1423899013014.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <58403023.46.1423865037882.JavaMail.jenkins@jenkins-9.freebsd.org> References: <58403023.46.1423865037882.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_9 #666 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 07:30:21 -0000 See From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 15:07:49 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D7AE119 for ; Sat, 14 Feb 2015 15:07:49 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6488EAB7 for ; Sat, 14 Feb 2015 15:07:49 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YMeJu-0006gT-AX for freebsd-stable@freebsd.org; Sat, 14 Feb 2015 15:07:46 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YMeJu-000JU0-8Z for freebsd-stable@freebsd.org; Sat, 14 Feb 2015 15:07:46 +0000 To: freebsd-stable@freebsd.org Subject: Unable to read manpages (even after installing groff) Message-Id: From: Pete French Date: Sat, 14 Feb 2015 15:07:46 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 15:07:49 -0000 Updated to stable yesterday, now when I trype (for example) 'man man' I get this: This manpage needs groff(1) to be rendered First install groff(1): pkg install groff Surprised, as I expect manpages to be readable on a default nstall, but more sirprised when I followed the istructions and isnatlled groff, and I still get the message! Did manpages break somehow ? -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 15:40:34 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1642B8A6 for ; Sat, 14 Feb 2015 15:40:34 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94F6EDA4 for ; Sat, 14 Feb 2015 15:40:32 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t1EFeOqu076407; Sat, 14 Feb 2015 07:40:24 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t1EFeODf076406; Sat, 14 Feb 2015 07:40:24 -0800 (PST) (envelope-from david) Date: Sat, 14 Feb 2015 07:40:24 -0800 From: David Wolfskill To: Pete French Subject: Re: Unable to read manpages (even after installing groff) Message-ID: <20150214154024.GW1256@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Pete French , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7eB2J0nPHAYIuy9R" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 15:40:34 -0000 --7eB2J0nPHAYIuy9R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 14, 2015 at 03:07:46PM +0000, Pete French wrote: > Updated to stable yesterday, now when I trype (for example) 'man man' > I get this: >=20 > This manpage needs groff(1) to be rendered > First install groff(1):=20 > pkg install groff=20 >=20 > Surprised, as I expect manpages to be readable on a default > nstall, but more sirprised when I followed the istructions > and isnatlled groff, and I still get the message! >=20 > Did manpages break somehow ? > .... Fixed by r278693; ref. . A workaround for this specific isue is: # sed -i "" -e 's/groff2/groff/' /usr/bin/man Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --7eB2J0nPHAYIuy9R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJU32xoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7fhAP+gIPmpObaKF4edDZD+99W6FP gciTIdi070cm9aBMxJBIPKibwtr41MJOx/Cz+WHoClFhiPlkaQ8IHjobOIwiTGTs vkeDDslKZOF9HACekXHEUfKpBrtybpN8+xYWoCGMP0KsR6l9MJOjedC2wqLGTLm2 VyfhXNemKxwdy7hSWAXWDJFIa4wdYrTRHK9M+atdrB+UV6U/9asDSSbgm69VcuxJ FfvdZbQJ54evL0hkNyNBsaOTHBZa1kbyQgkpedsa2aJ6SOTwS94TKS+qwyC2/mbe nYjaBN5eeDQoAOWMQNwTaJVUaGSn6DJEkcoY4J9hAmdrd/3IM5WMMAQ/+h1IOmBX DwxxD0ICDWyZm8B9g1XbypHR1UfS13aYmsmsVWQLbNJdorJoty/evJG7IKHcgtwc lyn/Gis5XAp601mDe90S8KLc38kCPc/rWsWdRwW573cl+hlb7eyMh8DUIS8rgvZc bl+q1pmPyQW34id3Qp84NoIpq0BmSagyilzq+LwzZB9RsjioGRGhS2EQYrwaDean 7BTOUCYylMiEE1EIExF1YJbjlrMhuryvg4q/jU/ytNvbr0HycEPUHwkHka65VmKT HIkLX5aqzGG2XskZ0dOZs3Jxu+p5TePgxenUQ8O2XT40JV0wGXng6136tlPS7i9R R2GX/mkgIkQaOGhelVl6 =+shY -----END PGP SIGNATURE----- --7eB2J0nPHAYIuy9R-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 14 23:02:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 526FB8B4; Sat, 14 Feb 2015 23:02:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4064018C; Sat, 14 Feb 2015 23:02:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4BC3D7CC; Sat, 14 Feb 2015 23:02:40 +0000 (UTC) Date: Sat, 14 Feb 2015 23:02:09 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, luigi@FreeBSD.org, loos@FreeBSD.org, hrs@FreeBSD.org Message-ID: <625594216.61.1423954959749.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #1213 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:02:40 -0000 See Changes: [loos] MFC r274642, 274643: Remove unnecessary code. After r273566, the gpiobus version of bus_print_child() also works on FDT systems. Fix gpiobus_child_location_str() to return a real string with the mapped pins. Make gpiobus_print_pins() static again. [loos] MFC r274638: Add basic interrupt management code to gpiobus and ofw_gpiobus. This is the general support to allow the use of GPIO pins as interrupt sources for direct gpiobus children. The use of GPIO pins as generic interrupt sources (for an ethernet driver for example) will only be possible when arm/intrng is complete. Then, most of this code will need to be rewritten, but it works for now, is better than what we have and will allow further developments. [loos] MFC r273917, r273926: Fix the gpiobus locking by using a more sane model where it isn't necessary hold the gpiobus lock between the gpio calls. gpiobus_acquire_lock() now accepts a third parameter which tells gpiobus what to do when the bus is already busy. When GPIOBUS_WAIT wait is used, the calling thread will be put to sleep until the bus became free. With GPIOBUS_DONTWAIT the calling thread will receive EWOULDBLOCK right away and then it can act upon. This fixes the gpioiic(4) locking issues that arises when doing multiple concurrent access on the bus. Fix the build of non-FDT systems by moving the gpiobusvar.h header outside the FDT #ifdef. While here remove a few unused headers. [loos] MFC r273799: Make the GPIO children attach to the first unit available and not only to unit 0. This fix a bug where a GPIO controller could fail to attach its children (gpioc and gpiobus) if another GPIO driver attach first. [loos] MFC r273566, r273569: Provide a working GPIOBUS_IVAR() macro for FDT systems. Move the duplicated code to a single function. No functional changes. [luigi] sync the code with the version in head. which the exception of svn 275358 (M_FLOWID deprecation, only a couple of lines) which cannot be merged. if_lem_netmap.h, if_re_netmap.h: - use the same (commented out) function to update the stat counters as in HEAD. This is a no-op here netmap.c - merge 274459 (support for private knote lock) and minor changes on nm_config and comments netmap_freebsd.c - merge 274459 (support for private knote lock) - merge 274354 (initialize color if passed as argument) netmap_generic.c - fix a comment netmap_kern.h - revise the lock macros, using sx locks; merge 274459 (private knote lock) netmap_monitor.c - use full memory barriers netmap_pipe.c - use full memory barriers, use length from the correct queue (mostly cosmetic, since the queues typically have the same size) [loos] MFC: r273264, r274409, r278212, r278213: Add a workaround needed to fix a bug of Arasan Host Controller where it may lose the contents of consecutive writes (that happens within two SD card clock cycles). This fixes the causes of instability during the SD card detection and identification on Raspberry Pi (which happens at 400 kHz and so was much more vulnerable to this issue). Remove the previous workaround which clearly can't provide the same effect. Remove stale comments about the issues with HS mode. Remove a previous workaround to limit the minimum sdhci frequency that isn't needed anymore. Remove some duplicate calls to bus_release_resource() and destroy the mutex on error cases. While here remove unnecessary includes. [luigi] sync with the version in head (r274338): fix one comment, and return kernel-supplied error if available. no API changes. [hrs] MFC r273999: Do not try to create a /dev/log symlink in a jail. PR:=09179828 [loos] MFC r276298, r276303: Remove the '#undef DEBUG' that should not be committed. Removes unused and duplicate headers. Bring the wait limit on mailbox write to a more sane value. Fix a off-by-one bug on wait time limit. Remove extra blank line. [loos] MFC r276296, r277207: Make consistent use of the correct debug macros across the file. Fix the C -> K temperature conversion for the dev.cpu.0.temperature sysctl. Remove the unused temperature conversion macros. ------------------------------------------ [...truncated 282584 lines...] --- ataserverworks.ko.symbols --- objcopy --only-keep-debug ataserverworks.ko.debug ataserverworks.ko.symbols --- all_subdir_ath --- ctfconvert -L VERSION -g ar2413.o --- all_subdir_bxe --- --- bxe_debug.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I/builds/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_= OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable= _10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-o= mit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/= obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunus= ed-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qua= l -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -f= diagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-b= ody -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe/bxe_debug.c --- all_subdir_ata --- --- ataserverworks.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dataserverworks.ko.symbols atase= rverworks.ko.debug ataserverworks.ko =3D=3D=3D> ata/atapci/chipsets/atasiliconimage (all) --- ata-siliconimage.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/ata/atapci/chipsets/atasi= liconimage/../../../../../dev/ata/chipsets/ata-siliconimage.c --- all_subdir_bridgestp --- =3D=3D=3D> bridgestp (all) --- bridgestp.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/bridgestp/../../net/bridg= estp.c --- all_subdir_bxe --- ctfconvert -L VERSION -g bxe_debug.o --- all_subdir_ath --- --- ar2425.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5212/ar2425.c --- all_subdir_bxe --- --- bxe_elink.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I/builds/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_= OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable= _10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-o= mit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/= obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunus= ed-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qua= l -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -f= diagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-b= ody -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe/bxe_elink.c --- all_subdir_ata --- ctfconvert -L VERSION -g ata-siliconimage.o --- atasiliconimage.ko.debug --- ld -d -warn-common -r -d -o atasiliconimage.ko.debug ata-siliconimage.o ctfmerge -L VERSION -g -o atasiliconimage.ko.debug ata-siliconimage.o :> export_syms awk -f /builds/FreeBSD_stable_10/sys/conf/kmod_syms.awk atasiliconimage.ko.= debug export_syms | xargs -J% objcopy % atasiliconimage.ko.debug --- atasiliconimage.ko.symbols --- objcopy --only-keep-debug atasiliconimage.ko.debug atasiliconimage.ko.symbo= ls --- atasiliconimage.ko --- objcopy --strip-debug --add-gnu-debuglink=3Datasiliconimage.ko.symbols atas= iliconimage.ko.debug atasiliconimage.ko =3D=3D=3D> ata/atapci/chipsets/atasis (all) --- all_subdir_bridgestp --- ctfconvert -L VERSION -g bridgestp.o --- all_subdir_ata --- --- ata-sis.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/ata/atapci/chipsets/atasi= s/../../../../../dev/ata/chipsets/ata-sis.c --- all_subdir_bridgestp --- --- bridgestp.ko.debug --- ld -d -warn-common -r -d -o bridgestp.ko.debug bridgestp.o ctfmerge -L VERSION -g -o bridgestp.ko.debug bridgestp.o --- all_subdir_ath --- ctfconvert -L VERSION -g ar2425.o --- all_subdir_bridgestp --- :> export_syms awk -f /builds/FreeBSD_stable_10/sys/conf/kmod_syms.awk bridgestp.ko.debug = export_syms | xargs -J% objcopy % bridgestp.ko.debug --- all_subdir_ath --- --- ar5413.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5212/ar5413.c --- all_subdir_bridgestp --- --- bridgestp.ko.symbols --- objcopy --only-keep-debug bridgestp.ko.debug bridgestp.ko.symbols --- all_subdir_ata --- ctfconvert -L VERSION -g ata-sis.o --- all_subdir_bridgestp --- --- bridgestp.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dbridgestp.ko.symbols bridgestp.= ko.debug bridgestp.ko --- all_subdir_ata --- --- atasis.ko.debug --- ld -d -warn-common -r -d -o atasis.ko.debug ata-sis.o --- evgpeblk.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I/builds/FreeBSD_stable_10/sys -I/builds/FreeBS= D_stable_10/sys/contrib/altq -I/builds/FreeBSD_stable_10/sys/contrib/libfdt= -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-fr= ame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -Werror /builds/FreeBSD_st= able_10/sys/contrib/dev/acpica/components/events/evgpeblk.c --- modules-all --- ctfmerge -L VERSION -g -o atasis.ko.debug ata-sis.o :> export_syms awk -f /builds/FreeBSD_stable_10/sys/conf/kmod_syms.awk atasis.ko.debug ex= port_syms | xargs -J% objcopy % atasis.ko.debug --- evgpeblk.o --- ctfconvert -L VERSION -g evgpeblk.o --- modules-all --- --- atasis.ko.symbols --- objcopy --only-keep-debug atasis.ko.debug atasis.ko.symbols --- all_subdir_ath --- ctfconvert -L VERSION -g ar5413.o --- all_subdir_ata --- --- atasis.ko --- objcopy --strip-debug --add-gnu-debuglink=3Datasis.ko.symbols atasis.ko.deb= ug atasis.ko --- all_subdir_bxe --- --- ecore_sp.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I/builds/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_= OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable= _10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-o= mit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/= obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunus= ed-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qua= l -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -f= diagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-b= ody -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe/eco--- all_subdir_ata --- =3D=3D=3D> ata/atapci/chipsets/atavia (all) --- all_subdir_bxe --- re_sp.c --- all_subdir_ata --- --- ata-via.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/ata/atapci/chipsets/atavi= a/../../../../../dev/ata/chipsets/ata-via.c --- all_subdir_ath --- --- ah_eeprom_v14.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ah_eeprom_v14.c --- all_subdir_ata --- ctfconvert -L VERSION -g ata-via.o --- all_subdir_ath --- ctfconvert -L VERSION -g ah_eeprom_v14.o --- all_subdir_ata --- --- atavia.ko.debug --- ld -d -warn-common -r -d -o atavia.ko.debug ata-via.o ctfmerge -L VERSION -g -o atavia.ko.debug ata-via.o --- all_subdir_ath --- --- ah_eeprom_v4k.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ah_eeprom_v4k.c --- all_subdir_ata --- :> export_syms awk -f /builds/FreeBSD_stable_10/sys/conf/kmod_syms.awk atavia.ko.debug ex= port_syms | xargs -J% objcopy % atavia.ko.debug --- atavia.ko.symbols --- objcopy --only-keep-debug atavia.ko.debug atavia.ko.symbols --- atavia.ko --- objcopy --strip-debug --add-gnu-debuglink=3Datavia.ko.symbols atavia.ko.deb= ug atavia.ko --- all_subdir_ath --- --- ar5416_ani.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_ani= .c --- ah_eeprom_v4k.o --- ctfconvert -L VERSION -g ah_eeprom_v4k.o --- evgpeinit.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=3Dc99 -g -Wall -Wredundant-decl= s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmi= ssing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compa= re -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -nostdinc -I. -I/builds/FreeBSD_stable_10/sys -I/builds/FreeBS= D_stable_10/sys/contrib/altq -I/builds/FreeBSD_stable_10/sys/contrib/libfdt= -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-fr= ame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -Werror /builds/FreeBSD_st= able_10/sys/contrib/dev/acpica/components/events/evgpeinit.c --- modules-all --- --- all_subdir_bxe --- ctfconvert -L VERSION -g ecore_sp.o --- all_subdir_bwi --- =3D=3D=3D> bwi (all) --- bwimac.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/bwi/../../dev/bwi/bwimac.= c --- evgpeinit.o --- ctfconvert -L VERSION -g evgpeinit.o --- modules-all --- --- all_subdir_bwn --- =3D=3D=3D> bwn (all) --- if_bwn.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -Wno-error-sometimes-uninitialized -c /builds/FreeBSD_stable_10/sy= s/modules/bwn/../../dev/bwn/if_bwn.c --- all_subdir_ath --- --- ar5416_ani.o --- ctfconvert -L VERSION -g ar5416_ani.o --- ar5416_attach.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_att= ach.c --- all_subdir_bwi --- ctfconvert -L VERSION -g bwimac.o --- bwiphy.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/bwi/../../dev/bwi/bwiphy.= c --- all_subdir_ath --- ctfconvert -L VERSION -g ar5416_attach.o --- ar5416_beacon.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_bea= con.c ctfconvert -L VERSION -g ar5416_beacon.o --- ar5416_btcoex.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_btc= oex.c ctfconvert -L VERSION -g ar5416_btcoex.o --- all_subdir_bwi --- ctfconvert -L VERSION -g bwiphy.o --- all_subdir_ath --- --- ar5416_cal.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_cal= .c --- all_subdir_bwi --- --- bwirf.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/bwi/../../dev/bwi/bwirf.c --- all_subdir_ath --- ctfconvert -L VERSION -g ar5416_cal.o --- all_subdir_bxe --- --- bxe_elink.o --- ctfconvert -L VERSION -g bxe_elink.o --- all_subdir_ath --- --- ar5416_cal_iq.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_cal= _iq.c ctfconvert -L VERSION -g ar5416_cal_iq.o --- all_subdir_bxe --- --- 57710_init_values.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I/builds/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_= OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable= _10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-o= mit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/= obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunus= ed-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qua= l -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -f= diagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-b= ody -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe/57710_init_values.c --- all_subdir_ath --- --- ar5416_cal_adcgain.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_cal= _adcgain.c ctfconvert -L VERSION -g ar5416_cal_adcgain.o --- ar5416_cal_adcdc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_cal= _adcdc.c ctfconvert -L VERSION -g ar5416_cal_adcdc.o --- all_subdir_bwi --- ctfconvert -L VERSION -g bwirf.o --- all_subdir_ath --- --- ar5416_eeprom.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_eep= rom.c --- all_subdir_bwi --- --- if_bwi.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/bui= lds/FreeBSD_stable_10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fn= o-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/= FreeBSD_stable_10/obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-a= vx -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asy= nchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -std=3Di= so9899: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 -Wmissi= ng-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-fu= nction -c /builds/FreeBSD_stable_10/sys/modules/bwi/../../dev/bwi/if_bwi.= c --- all_subdir_ath --- ctfconvert -L VERSION -g ar5416_eeprom.o --- ar5416_gpio.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_gpi= o.c ctfconvert -L VERSION -g ar5416_gpio.o --- ar5416_interrupts.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I. -I/builds/FreeBSD_stable_10/sys/modules/ath/../../dev/ath -I/builds/= FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal -I. -I/builds/FreeB= SD_stable_10/sys/modules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_O= PTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable_= 10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/o= bj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkerne= l -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-ta= bles -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunuse= d-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual= -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd= iagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-bo= dy -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/ath/../../dev/ath/ath_hal/ar5416/ar5416_int= errupts.c --- all_subdir_bxe --- ctfconvert -L VERSION -g 57710_init_values.o --- 57711_init_values.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I/builds/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe -DHAVE_KERNEL_= OPTION_HEADERS -include /builds/FreeBSD_stable_10/obj/builds/FreeBSD_stable= _10/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -g -fno-o= mit-frame-pointer -mno-omit-leaf-frame-pointer -I/builds/FreeBSD_stable_10/= obj/builds/FreeBSD_stable_10/sys/GENERIC -mno-aes -mno-avx -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fstack-protector -gdwarf-2 -std=3Diso9899:1999 -Qunus= ed-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -W= strict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qua= l -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -f= diagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-b= ody -Wno-error-parentheses-equality -Wno-error-unused-function -c /build= s/FreeBSD_stable_10/sys/modules/bxe/../../dev/bxe/57711_init_values.c --- all_subdir_ath --- ctfconvert -L VERSION -g ar5416_interrupts.o --- ar5416_keycache.o --- FATAL: java.io.IOException: Unexpected reader termination hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected re= ader termination =09at hudson.remoting.Request.abort(Request.java:295) =09at hudson.remoting.Channel.terminate(Channel.java:814) =09at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(Synchron= ousCommandTransport.java:76) =09at ......remote call to jenkins-10.freebsd.org(Native Method) =09at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) =09at hudson.remoting.Request.call(Request.java:171) =09at hudson.remoting.Channel.call(Channel.java:751) =09at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandle= r.java:179) =09at com.sun.proxy.$Proxy48.join(Unknown Source) =09at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:979) =09at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) =09at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) =09at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) =09at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) =09at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBui= ld.java:770) =09at hudson.model.Build$BuildExecution.build(Build.java:199) =09at hudson.model.Build$BuildExecution.doRun(Build.java:160) =09at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.j= ava:533) =09at hudson.model.Run.execute(Run.java:1759) =09at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) =09at hudson.model.ResourceController.execute(ResourceController.java:89) =09at hudson.model.Executor.run(Executor.java:240) Caused by: java.io.IOException: Unexpected reader termination =09at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(Synchron= ousCommandTransport.java:76) Caused by: java.lang.OutOfMemoryError: PermGen space =09at sun.misc.Unsafe.defineClass(Native Method) =09at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63) =09at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.jav= a:399) =09at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.jav= a:396) =09at java.security.AccessController.doPrivileged(Native Method) =09at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.= java:395) =09at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(= MethodAccessorGenerator.java:113) =09at sun.reflect.ReflectionFactory.newConstructorForSerialization(Reflecti= onFactory.java:331) =09at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClas= s.java:1376) =09at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72) =09at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493) =09at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468) =09at java.security.AccessController.doPrivileged(Native Method) =09at java.io.ObjectStreamClass.(ObjectStreamClass.java:468) =09at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365) =09at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:602) =09at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162= 2) =09at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517) =09at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1= 771) =09at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) =09at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) =09at hudson.remoting.Command.readFrom(Command.java:92) =09at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(Abs= tractSynchronousByteArrayCommandTransport.java:34) =09at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(Synchron= ousCommandTransport.java:48)