From owner-freebsd-stable@freebsd.org Sun Jan 31 20:19:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C74CA7410D for ; Sun, 31 Jan 2016 20:19:21 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 BCD80B02 for ; Sun, 31 Jan 2016 20:19:20 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by mail-wm0-x22d.google.com with SMTP id l66so44501736wml.0 for ; Sun, 31 Jan 2016 12:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bris-ac-uk.20150623.gappssmtp.com; s=20150623; h=date:from:message-id:to:subject:cc:reply-to:in-reply-to; bh=pDG81zih5hZAeJ+7S07E+Lo4JBpY0KB+wm/1pnvz2GA=; b=zkZzy3fcsEzQzMNNH1pfh4ubE86R6iKnMsenxrXKxNgUVtnymTI844peoMTO8lLCWv g9G795EZPguEbwBrrYeqAN+Xz03SZCxWoeEaz94+EPiz99wmDCp/pU5+RC+orLSJZO23 C+lm9yxiHQBLfMEfolOCbBr7MhHTCXFuKJUZhvRSiutmlE3/hpDcayBuuTmePMDJ/fE/ G+2Yos7IREjJa8FJ7j/WC3KhiEy7iQPSyuIqWTjQ3n9FyFIGnukUuLk3qBanJffGkhXt n95VbPuyoi+qC7GK/ux/xRqnA2pL/EhKIXDTKIIi88AEj0rWa5sQADR6E/kYfCeoRDbo 0gTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=pDG81zih5hZAeJ+7S07E+Lo4JBpY0KB+wm/1pnvz2GA=; b=ImqQAzocdIg7uida5cj8DZofpZeddIZD1dZDBUQHTlI0nBwU/BiWt5mvef8urpaOOH ep0gx4B+b9T/Hrk8XRjQxqbeIsMpfhRQuMRMI/847XqQA1ur7qui9W84J5oL/865q0zI 0uW1Ihy2LBr08Li11R3zSCqZE8AqToKjnRclI1UbuH/FPk/EcGKgptFjB5/XxETHU0kB LaXXc2PFLCx1LYi8QvCbCbd6Ge89PQdi1yHcLQV94KYYw/cumbVUOWSDwXQVBqadfPsU WhxDW6IOhCSeanN4iiGx+ovc/oDbaQZCR3FB5rAjU6IXeJwfVuDygaym+DjWO+vO/D2l lD9A== X-Gm-Message-State: AG10YOT8Z6XCsmplqav6tsC/LEPtSEXVGyBFl9rSRlzC6ITxKiRceMFEO166xd1VGuZqWCt8 X-Received: by 10.194.103.2 with SMTP id fs2mr22708344wjb.36.1454271558876; Sun, 31 Jan 2016 12:19:18 -0800 (PST) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id k130sm8192561wmg.6.2016.01.31.12.19.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2016 12:19:17 -0800 (PST) Date: Sun, 31 Jan 2016 12:19:17 -0800 (PST) X-Google-Original-Date: Sun, 31 Jan 2016 20:19:16 GMT Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id u0VKJHX4027461; Sun, 31 Jan 2016 20:19:17 GMT (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id u0VKJGLV027460; Sun, 31 Jan 2016 20:19:16 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201601312019.u0VKJGLV027460@mech-as222.men.bris.ac.uk> To: freebsd-ia64@freebsd.org, john@baldwin.cx, mexas@bris.ac.uk Subject: Re: ia64 10-stable about r292594: rescue crunchide *.lo unknown executable format Cc: freebsd-stable@freebsd.org Reply-To: mexas@bris.ac.uk In-Reply-To: <4051652.ADtJilLzSM@ralph.baldwin.cx> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 31 Jan 2016 20:19:21 -0000 >From john@baldwin.cx Sat Jan 30 02:00:53 2016 > >While ia64 is mostly abandoned, this build failure was fixed a few weeks ago: > >------------------------------------------------------------------------ >r292885 | emaste | 2015-12-29 12:36:11 -0800 (Tue, 29 Dec 2015) | 4 lines > >crunchide: Restore IA-64 support accidentally lost in r292421 mismerge > >Reported by: ngie John, thank you, but I think it's time to say goodbye to FreeBSD/ia64 for me. Thanks Anton From owner-freebsd-stable@freebsd.org Mon Feb 1 22:11:37 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A87F3A98A47 for ; Mon, 1 Feb 2016 22:11:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B547110E for ; Mon, 1 Feb 2016 22:11:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u11MBZnQ092192 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2016 17:11:35 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u11MBX4S008203; Mon, 1 Feb 2016 17:11:33 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap) To: Marius Strobl References: <201601272231.u0RMV8LW019394@repo.freebsd.org> <56ABAA92.5050901@sentex.net> <56ABB291.5040305@omnilan.de> <56ABCE95.3030807@sentex.net> <20160130012358.GY15359@alchemy.franken.de> <56ACE917.80502@sentex.net> <20160130172618.GA15359@alchemy.franken.de> Cc: FreeBSD-STABLE Mailing List From: Mike Tancsa Organization: Sentex Communications Message-ID: <56AFD811.1030706@sentex.net> Date: Mon, 1 Feb 2016 17:11:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160130172618.GA15359@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 01 Feb 2016 22:11:37 -0000 On 1/30/2016 12:26 PM, Marius Strobl wrote: > > Ah, okay, that at least makes sense. Can you please verify that with > the attached patch applied, you have a setup that works out of the > box? > Hi, The patch does not apply cleanly # patch < em_tso_gig_only_10.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/e1000/if_em.c |=================================================================== |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c (working copy) -------------------------- Patching file sys/dev/e1000/if_em.c using Plan A... Hunk #1 failed at 1377. 1 out of 1 hunks failed--saving rejects to sys/dev/e1000/if_em.c.rej done # cat sys/dev/e1000/if_em.c.rej @@ -1377,8 +1377,15 @@ ifp->if_hwassist = 0; if (ifp->if_capenable & IFCAP_TXCSUM) ifp->if_hwassist |= (CSUM_TCP | CSUM_UDP); - if (ifp->if_capenable & IFCAP_TSO4) - ifp->if_hwassist |= CSUM_TSO; + /* + ** There have proven to be problems with TSO when not + ** at full gigabit speed, so disable the assist automatically + ** when at lower speeds. -jfv + */ + if (ifp->if_capenable & IFCAP_TSO4) { + if (adapter->link_speed == SPEED_1000) + ifp->if_hwassist |= CSUM_TSO; + } /* Configure for OS presence */ em_init_manageability(adapter); -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Mon Feb 1 22:28:00 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4912A7614D for ; Mon, 1 Feb 2016 22:28:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 815821DAB for ; Mon, 1 Feb 2016 22:28:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u11MRu2M037607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2016 23:27:57 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u11MRu9b037606; Mon, 1 Feb 2016 23:27:56 +0100 (CET) (envelope-from marius) Date: Mon, 1 Feb 2016 23:27:56 +0100 From: Marius Strobl To: Mike Tancsa Cc: FreeBSD-STABLE Mailing List Subject: Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap) Message-ID: <20160201222756.GE15359@alchemy.franken.de> References: <201601272231.u0RMV8LW019394@repo.freebsd.org> <56ABAA92.5050901@sentex.net> <56ABB291.5040305@omnilan.de> <56ABCE95.3030807@sentex.net> <20160130012358.GY15359@alchemy.franken.de> <56ACE917.80502@sentex.net> <20160130172618.GA15359@alchemy.franken.de> <56AFD811.1030706@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AFD811.1030706@sentex.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Mon, 01 Feb 2016 23:27:57 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 01 Feb 2016 22:28:01 -0000 On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote: > On 1/30/2016 12:26 PM, Marius Strobl wrote: > > > > Ah, okay, that at least makes sense. Can you please verify that with > > the attached patch applied, you have a setup that works out of the > > box? > > > Hi, > The patch does not apply cleanly Hrm, it does here on stable/10. If your checkout is unaltered, the only thing I can think of is that the patch got corrupted when sent by e-mail. I've put it online: https://people.freebsd.org/~marius/em_tso_gig_only_10.diff marius@alchemy:/home/marius/co/10/src/sys/dev/e1000 > svn info Path: . Working Copy Root Path: /usr/home/marius/co/10/src URL: svn+ssh://svn.freebsd.org/base/stable/10/sys/dev/e1000 Relative URL: ^/stable/10/sys/dev/e1000 Repository Root: svn+ssh://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295130 Node Kind: directory Schedule: normal Last Changed Author: marius Last Changed Rev: 294958 Last Changed Date: 2016-01-27 23:31:08 +0100 (Wed, 27 Jan 2016) marius@alchemy:/home/marius/co/10/src/sys/dev/e1000 > patch < ~/em_tso_gig_only_10.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/e1000/if_em.c |=================================================================== |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c (working copy) -------------------------- Patching file if_em.c using Plan A... Hunk #1 succeeded at 1377. done From owner-freebsd-stable@freebsd.org Mon Feb 1 22:35:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A5A7A76491 for ; Mon, 1 Feb 2016 22:35:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3CAD36C for ; Mon, 1 Feb 2016 22:35:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u11MZJTn094204 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2016 17:35:19 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u11MZ1pg008306; Mon, 1 Feb 2016 17:35:18 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap) To: Marius Strobl References: <201601272231.u0RMV8LW019394@repo.freebsd.org> <56ABAA92.5050901@sentex.net> <56ABB291.5040305@omnilan.de> <56ABCE95.3030807@sentex.net> <20160130012358.GY15359@alchemy.franken.de> <56ACE917.80502@sentex.net> <20160130172618.GA15359@alchemy.franken.de> <56AFD811.1030706@sentex.net> <20160201222756.GE15359@alchemy.franken.de> Cc: FreeBSD-STABLE Mailing List From: Mike Tancsa Organization: Sentex Communications Message-ID: <56AFDD92.2020106@sentex.net> Date: Mon, 1 Feb 2016 17:34:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160201222756.GE15359@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 01 Feb 2016 22:35:21 -0000 On 2/1/2016 5:27 PM, Marius Strobl wrote: > On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote: >> On 1/30/2016 12:26 PM, Marius Strobl wrote: >>> >>> Ah, okay, that at least makes sense. Can you please verify that with >>> the attached patch applied, you have a setup that works out of the >>> box? >>> >> Hi, >> The patch does not apply cleanly > > Hrm, it does here on stable/10. If your checkout is unaltered, the > only thing I can think of is that the patch got corrupted when sent > by e-mail. I've put it online: > https://people.freebsd.org/~marius/em_tso_gig_only_10.diff Much better, thanks :) 0(vinyl3)# fetch https://people.freebsd.org/~marius/em_tso_gig_only_10.diff em_tso_gig_only_10.diff 100% of 780 B 8385 kBps 00m00s 0(vinyl3)# patch < em_tso_gig_only_10.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/e1000/if_em.c |=================================================================== |--- sys/dev/e1000/if_em.c (revision 294962) |+++ sys/dev/e1000/if_em.c (working copy) -------------------------- Patching file sys/dev/e1000/if_em.c using Plan A... Hunk #1 succeeded at 1377. done 0(vinyl3)# -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Tue Feb 2 01:50:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EB79A98946 for ; Tue, 2 Feb 2016 01:50:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 102F7108; Tue, 2 Feb 2016 01:50:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5F5FDCC7; Tue, 2 Feb 2016 01:50:25 +0000 (UTC) Date: Tue, 2 Feb 2016 01:50:24 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1438405110.59.1454377824645.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #53 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 01:50:26 -0000 See From owner-freebsd-stable@freebsd.org Tue Feb 2 07:56:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E08E9A98AF6 for ; Tue, 2 Feb 2016 07:56:12 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C81BBAE3 for ; Tue, 2 Feb 2016 07:56:12 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: by mailman.ysv.freebsd.org (Postfix) id C4D5BA98AF5; Tue, 2 Feb 2016 07:56:12 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C46AEA98AF4 for ; Tue, 2 Feb 2016 07:56:12 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79BB0AE1; Tue, 2 Feb 2016 07:56:12 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u127u5mH048454 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Feb 2016 16:56:06 +0900 (JST) (envelope-from ume@mahoroba.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mahoroba.org; s=20081103; t=1454399766; bh=n2+iOfG6XT3Qm4rPX9fC+DaYdhrpHSIQjvF9V0r+jF4=; h=Date:From:To:Subject; b=0QfCuNNac0eJ2RchuUJgEIJi0/Avfqa2nPyZR3eywSjWCmrcSTCOHt7DpWWCn0aFx 81R+ZqoH02sg7Mw08Ql0K/08Uysf2wzI8XVcAopAaK3Mrge+6GDp62e2Ef+d7Jb2US UTT/btb47tt+9STZoOTnWrijrK5pcaUn/biARY9U= Date: Tue, 02 Feb 2016 16:55:46 +0900 Message-ID: From: Hajimu UMEMOTO To: stable@FreeBSD.org, mckusick@FreeBSD.org Subject: 10-STABLE hangups frequently User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-PRERELEASE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6a2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 02 Feb 2016 16:56:06 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 07:56:13 -0000 Hi, I'm disturbed by a frequent hangup of my 10-STABLE boxes since this year. It seems occur during running the periodic daily scripts. I've narrowed which commit causes this problem. It seems r292895 causes it. I see many `Resource temporarily unavailable' message just before hangup occurs. Any idea? Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@freebsd.org Tue Feb 2 08:53:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AB69A97020 for ; Tue, 2 Feb 2016 08:53:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 F13661BF for ; Tue, 2 Feb 2016 08:53:58 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x235.google.com with SMTP id r129so106882592wmr.0 for ; Tue, 02 Feb 2016 00:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=JSarTsfXNeXVLjhwHcS1H+xcnHuSTQhDzCU/n5mfoMI=; b=de7QGXX8s1y9HWvWY/iYsQ18NwQI/TO0hSzHpX5M7h0XDXe67PPTR94OE3hYnpF7H2 wUG7YjP2NjebJqvSZof1t4B9usf73mZ8Oor1HW6HIRAU29r6ByIrim7iuEN66Dqm1hWW 5M5v3sXt04ebwC7RZR1Dej8u+BPE7zDuzcKNUYk78i+XHT8wgIKUNoY4UT9GCj0Fs5oI DSk37XeH88AtBzc0mUJ28xQCyORJKIf+krN+Sf5r480aKFcOu1WNdO8mE4HLl6hzYonU LVvGaxDj171IBb2aRSg4yPj1z6m3zow8AxR3TQh8BKH69MXBc4IQ13atWBSJd6zo3iTb 7xoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=JSarTsfXNeXVLjhwHcS1H+xcnHuSTQhDzCU/n5mfoMI=; b=SvQZDHw/xaGLbOV9CmaZjNDG0OyuD8nA4oQ3GnuwaA4XMJuOdU1oym4DWQmgdhBAvE lAJ3F/6F7vogV6ULmQmDLBtaKpjNE5I7dcfDYXJqtsSyT8C04OlcBqj0l8ab3RlD0g1W mNbkiL6V7bFf/9okJF2Esh/GgHmDAgHCh+L9+9jgrXbvfwy6FKRzscSlGeK0ep0aq3Zk GSjI+/pxB2Pin+TduyLMXCJ5hRgUqovzouJY5Xz0+uO8iuIk2NQ8ptXCP9aXedPtOInU jfq6DhhiLbLEc39xScXWSteYC/IwaXFTEd7akTpCNxLlmNglEsGD9o5l+433ETa3kaau ch3g== X-Gm-Message-State: AG10YOQ4H1bQziL91rQrSKWb0Ili117/I5sMy1yNf1uDuAaF68gipzlWVcf4jURNSvoecjn5 X-Received: by 10.28.142.8 with SMTP id q8mr16154059wmd.47.1454403237050; Tue, 02 Feb 2016 00:53:57 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id az10sm374407wjc.28.2016.02.02.00.53.55 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 00:53:55 -0800 (PST) Subject: Re: 10-STABLE hangups frequently To: freebsd-stable@freebsd.org References: From: Steven Hartland Message-ID: <56B06EB9.2090406@multiplay.co.uk> Date: Tue, 2 Feb 2016 08:54:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 08:53:59 -0000 Some more information about your enviroment would be helpful: 1. What revision of stable/10 are you running? 2. What workloads are you running? 3. What's the output of procstat -k -k when this happens (assuming its possible to run)? 4. What's the output of sysctl -a |grep vnode, usually and when this happens? Regards Steve On 02/02/2016 07:55, Hajimu UMEMOTO wrote: > Hi, > > I'm disturbed by a frequent hangup of my 10-STABLE boxes since this > year. It seems occur during running the periodic daily scripts. > I've narrowed which commit causes this problem. It seems r292895 > causes it. I see many `Resource temporarily unavailable' message just > before hangup occurs. > Any idea? > > Sincerely, > > -- > Hajimu UMEMOTO > ume@mahoroba.org ume@FreeBSD.org > http://www.mahoroba.org/~ume/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Feb 2 09:29:27 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1732A97EA5 for ; Tue, 2 Feb 2016 09:29:27 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34E8E10FD for ; Tue, 2 Feb 2016 09:29:26 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u129TI5e035566 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Feb 2016 18:29:19 +0900 (JST) (envelope-from ume@mahoroba.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mahoroba.org; s=20081103; t=1454405359; bh=cIc0zjNtvOGDfmc+XbpU9JjaWWkDY+0w0XAPmp4jNhU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=HlZCpF30hUcRAI5bBhUg4957Q2t528jFznesCWQC8HRBK2iAF81SMc4b8cfsuZaX/ 13On7Vmc13HmY06E1HZY4nyEQRG2GiUkx+ydJBqeH5g3648VivjmYCMr0Ym7Ya+XaR ftLcydyDE470lBByU2Ez3b2yUsfg3RZ8gjyx0b2A= Date: Tue, 02 Feb 2016 18:28:58 +0900 Message-ID: From: Hajimu UMEMOTO To: Steven Hartland Cc: freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently In-Reply-To: <56B06EB9.2090406@multiplay.co.uk> References: <56B06EB9.2090406@multiplay.co.uk> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-PRERELEASE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6a2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 02 Feb 2016 18:29:19 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 09:29:27 -0000 Hi, >>>>> On Tue, 2 Feb 2016 08:54:17 +0000 >>>>> Steven Hartland said: killing> Some more information about your enviroment would be helpful: killing> 1. What revision of stable/10 are you running? It occurs on r292895 and later. killing> 2. What workloads are you running? Apache, Cyrus IMAPd, BIND and mpd5. However, traffic is almost nothing without running the periodic daily scripts. killing> 3. What's the output of procstat -k -k when this happens (assuming its killing> possible to run)? I could not get it. killing> 4. What's the output of sysctl -a |grep vnode, usually and when this killing> happens? The following is usual case: kern.maxvnodes: 400000 kern.minvnodes: 100000 Syncing disks, vnodes remaining...0 0 0 0 0 done Syncing disks, vnodes remaining...0 0 0 0 0 0 done vm.stats.vm.v_vnodepgsout: 129 vm.stats.vm.v_vnodepgsin: 836656 vm.stats.vm.v_vnodeout: 101 vm.stats.vm.v_vnodein: 90562 vfs.freevnodes: 39680 vfs.wantfreevnodes: 100000 vfs.vnodes_created: 141735 vfs.numvnodes: 59118 debug.sizeof.vnode: 472 Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@freebsd.org Tue Feb 2 12:52:45 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 191EFA76E1F for ; Tue, 2 Feb 2016 12:52:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 9115913E5 for ; Tue, 2 Feb 2016 12:52:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12Cqcv1079064 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 14:52:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12Cqcv1079064 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12CqbYv079063; Tue, 2 Feb 2016 14:52:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 14:52:37 +0200 From: Konstantin Belousov To: Hajimu UMEMOTO Cc: Steven Hartland , freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160202125237.GS91220@kib.kiev.ua> References: <56B06EB9.2090406@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 12:52:45 -0000 On Tue, Feb 02, 2016 at 06:28:58PM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 2 Feb 2016 08:54:17 +0000 > >>>>> Steven Hartland said: > > killing> Some more information about your enviroment would be helpful: > killing> 1. What revision of stable/10 are you running? > > It occurs on r292895 and later. > > killing> 2. What workloads are you running? > > Apache, Cyrus IMAPd, BIND and mpd5. However, traffic is almost > nothing without running the periodic daily scripts. > > killing> 3. What's the output of procstat -k -k when this happens (assuming its > killing> possible to run)? > > I could not get it. > > killing> 4. What's the output of sysctl -a |grep vnode, usually and when this > killing> happens? > > The following is usual case: > > kern.maxvnodes: 400000 > kern.minvnodes: 100000 > Syncing disks, vnodes remaining...0 0 0 0 0 done > Syncing disks, vnodes remaining...0 0 0 0 0 0 done > vm.stats.vm.v_vnodepgsout: 129 > vm.stats.vm.v_vnodepgsin: 836656 > vm.stats.vm.v_vnodeout: 101 > vm.stats.vm.v_vnodein: 90562 > vfs.freevnodes: 39680 > vfs.wantfreevnodes: 100000 > vfs.vnodes_created: 141735 > vfs.numvnodes: 59118 > debug.sizeof.vnode: 472 Please gather the information listed at https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html From owner-freebsd-stable@freebsd.org Tue Feb 2 13:34:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07537A9812F for ; Tue, 2 Feb 2016 13:34:57 +0000 (UTC) (envelope-from freebsd@lidstrom.eu) Received: from ch-p-mailout01.sth.basefarm.net (ch-p-owweb-vips.sth.basefarm.net [164.40.177.54]) (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 B8037107F for ; Tue, 2 Feb 2016 13:34:56 +0000 (UTC) (envelope-from freebsd@lidstrom.eu) Received: from c83-251-49-235.bredband.comhem.se ([83.251.49.235]:61487 helo=zimbra01.henriklidstrom.se) by ch-p-mailout01.sth.basefarm.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1aQb5G-00095j-4x for freebsd-stable@freebsd.org; Tue, 02 Feb 2016 14:33:33 +0100 Received: from localhost (localhost [127.0.0.1]) by zimbra01.henriklidstrom.se (Postfix) with ESMTP id 9999A12051C for ; Tue, 2 Feb 2016 14:33:29 +0100 (CET) Received: from zimbra01.henriklidstrom.se ([127.0.0.1]) by localhost (zimbra01.henriklidstrom.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id k25TIobdp_Uy for ; Tue, 2 Feb 2016 14:33:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra01.henriklidstrom.se (Postfix) with ESMTP id 02EE712053C for ; Tue, 2 Feb 2016 14:33:28 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra01.henriklidstrom.se Received: from zimbra01.henriklidstrom.se ([127.0.0.1]) by localhost (zimbra01.henriklidstrom.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q2R5T5iHeA15 for ; Tue, 2 Feb 2016 14:33:27 +0100 (CET) Received: from [192.168.226.114] (unknown [83.255.229.1]) by zimbra01.henriklidstrom.se (Postfix) with ESMTPSA id CEB6712051C for ; Tue, 2 Feb 2016 14:33:27 +0100 (CET) Subject: Re: 10-STABLE hangups frequently To: freebsd-stable@freebsd.org References: <56B06EB9.2090406@multiplay.co.uk> From: =?UTF-8?Q?Henrik_Lidstr=c3=b6m?= Message-ID: <56B0B027.5020900@lidstrom.eu> Date: Tue, 2 Feb 2016 14:33:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B06EB9.2090406@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 83.251.49.235 X-Scan-Result: No virus found in message 1aQb5G-00095j-4x. X-Scan-Signature: ch-p-mailout01.sth.basefarm.net 1aQb5G-00095j-4x 97679d1430a58d2de2e58d827cf9a579 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 13:34:57 -0000 Just want to chip in that I also experience the same issue. This is my home firewall running squid/unbound/isc-bind/isc-dhcpd/pf/zfs. Have a couple of tmpfs and NFSv4 mounts. Was about to order new hardware since I thought it might be failing, lol. Haven't had time to hook up a monitor/console, but generate some load on the machine after a day or so of uptime and it feels as IO has just stuck and a reboot is necessery. Actually managed to update it yesterday, after a pre-reboot procedure. I have noticed vfs.numvnodes constanly rising to maxvnodes, so I bump that a bit. # uname -a FreeBSD brand.henriklidstrom.se 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #15 r295126M: Mon Feb 1 22:16:50 CET 2016 root@brand.henriklidstrom.se:/usr/obj/usr/src/sys/BRAND amd64 # sysctl -a | grep vnodes kern.maxvnodes: 300000 kern.minvnodes: 75000 vfs.freevnodes: 226235 vfs.wantfreevnodes: 75000 vfs.vnodes_created: 1129810 vfs.numvnodes: 250043 # fstat -m | wc -l 2740 # /Henrik On 02/02/16 09:54, Steven Hartland wrote: > Some more information about your enviroment would be helpful: > 1. What revision of stable/10 are you running? > 2. What workloads are you running? > 3. What's the output of procstat -k -k when this happens (assuming its > possible to run)? > 4. What's the output of sysctl -a |grep vnode, usually and when this > happens? > > Regards > Steve > > On 02/02/2016 07:55, Hajimu UMEMOTO wrote: >> Hi, >> >> I'm disturbed by a frequent hangup of my 10-STABLE boxes since this >> year. It seems occur during running the periodic daily scripts. >> I've narrowed which commit causes this problem. It seems r292895 >> causes it. I see many `Resource temporarily unavailable' message just >> before hangup occurs. >> Any idea? >> >> Sincerely, >> >> -- >> Hajimu UMEMOTO >> ume@mahoroba.org ume@FreeBSD.org >> http://www.mahoroba.org/~ume/ >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Tue Feb 2 13:49:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FE62A9875A for ; Tue, 2 Feb 2016 13:49:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A4FEE18D7 for ; Tue, 2 Feb 2016 13:49:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12DnKL2098989 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 15:49:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12DnKL2098989 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12DnKJe098988; Tue, 2 Feb 2016 15:49:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Feb 2016 15:49:20 +0200 From: Konstantin Belousov To: Henrik Lidstr??m Cc: freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160202134920.GY91220@kib.kiev.ua> References: <56B06EB9.2090406@multiplay.co.uk> <56B0B027.5020900@lidstrom.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B0B027.5020900@lidstrom.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 13:49:29 -0000 On Tue, Feb 02, 2016 at 02:33:27PM +0100, Henrik Lidstr??m wrote: > Just want to chip in that I also experience the same issue. This is my The same ? So did you diagnosed the problem and can explain, from the evidence provided by you and Hajimu, what is the cause and why the issues are the same ? > home firewall running squid/unbound/isc-bind/isc-dhcpd/pf/zfs. > Have a couple of tmpfs and NFSv4 mounts. > Was about to order new hardware since I thought it might be failing, > lol. Haven't had time to hook up a monitor/console, but generate some > load on the machine after a day or so of uptime and it feels as IO has > just stuck and a reboot is necessery. Actually managed to update it > yesterday, after a pre-reboot procedure. > > I have noticed vfs.numvnodes constanly rising to maxvnodes, so I bump > that a bit. This is how the things are supposed to work. > > # uname -a > FreeBSD brand.henriklidstrom.se 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE > #15 r295126M: Mon Feb 1 22:16:50 CET 2016 > root@brand.henriklidstrom.se:/usr/obj/usr/src/sys/BRAND amd64 > # sysctl -a | grep vnodes > kern.maxvnodes: 300000 > kern.minvnodes: 75000 > vfs.freevnodes: 226235 > vfs.wantfreevnodes: 75000 > vfs.vnodes_created: 1129810 > vfs.numvnodes: 250043 > # fstat -m | wc -l > 2740 > # From owner-freebsd-stable@freebsd.org Tue Feb 2 14:50:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DF0FA99E92 for ; Tue, 2 Feb 2016 14:50:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 64C9C1C6A for ; Tue, 2 Feb 2016 14:50:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u12Eo5Lg053275 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Feb 2016 09:50:05 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u12Eo4G9013202; Tue, 2 Feb 2016 09:50:04 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap) To: Marius Strobl References: <201601272231.u0RMV8LW019394@repo.freebsd.org> <56ABAA92.5050901@sentex.net> <56ABB291.5040305@omnilan.de> <56ABCE95.3030807@sentex.net> <20160130012358.GY15359@alchemy.franken.de> <56ACE917.80502@sentex.net> <20160130172618.GA15359@alchemy.franken.de> Cc: FreeBSD-STABLE Mailing List From: Mike Tancsa Organization: Sentex Communications Message-ID: <56B0C217.1070706@sentex.net> Date: Tue, 2 Feb 2016 09:49:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160130172618.GA15359@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 14:50:07 -0000 On 1/30/2016 12:26 PM, Marius Strobl wrote: > On Sat, Jan 30, 2016 at 11:47:19AM -0500, Mike Tancsa wrote: >> On 1/29/2016 8:23 PM, Marius Strobl wrote: >>> On Fri, Jan 29, 2016 at 03:41:57PM -0500, Mike Tancsa wrote: >>>> >>>> No multi queue. Stock GENERIC kernel with a couple of things removed. >>>> hw.em are just the defaults. I will try without TSO >>>> >>>> % ifconfig em0 >>>> em0: flags=8843 metric 0 mtu 1500 >>>> >>>> options=4209b >>>> >>> >>> Hrm, that's strange, TSO4 should be enabled by default so apparently >>> you are already disabling it; what is the behavior if you turn it on? >>> Do you use a < Gigabit link? >> >> Hi Marius, >> Thanks for looking. The ifconfig output was after I turned off tso as >> Harry suggested to try. Its been 24hrs and I have not seen any resets. >> I will wait another 36hrs or so and then turn it back on to see if the >> problem comes back. >> >> this link is 100Mb. > > Ah, okay, that at least makes sense. Can you please verify that with > the attached patch applied, you have a setup that works out of the > box? Hi, Should the nic come up with TSO disabled by default ? After reboot, I see # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:9c:59:f0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Tue Feb 2 17:12:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA84EA99BAF; Tue, 2 Feb 2016 17:12:36 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from mx09.uni-tuebingen.de (mx09.uni-tuebingen.de [134.2.5.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtpserv.uni-tuebingen.de", Issuer "Global-UNITUE-CA 01" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46B1A1C99; Tue, 2 Feb 2016 17:12:35 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from webmail2.uni-tuebingen.de (webmail2.uni-tuebingen.de [134.2.5.195]) by mx09.uni-tuebingen.de (8.14.3/8.14.3) with ESMTP id u12H6XH6013302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 18:06:33 +0100 Received: from webmail2.uni-tuebingen.de (localhost [127.0.0.1]) by webmail2.uni-tuebingen.de (Postfix) with ESMTPS id 44F1492CB2; Tue, 2 Feb 2016 18:06:33 +0100 (CET) Received: from roceehbwz.rue23.uni-tuebingen.de (roceehbwz.rue23.uni-tuebingen.de [134.2.216.135]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Tue, 02 Feb 2016 18:06:33 +0100 Date: Tue, 02 Feb 2016 18:06:33 +0100 Message-ID: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> From: Zara Kanaeva To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: LSI SAS 3108 RAID Controller User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 17:12:36 -0000 Dear list, I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI SAS 3108 RAID Controller is supported by the mpr driver (https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on this server I can make partitions, but I can not write install files on the disks (better to say RAID5 virtual drive) without errors. The erorrs are: mfi0 failed to get command mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS By the installations I see my virtual drive as device with mfi0 as identifier. My questions are: 1) Why I see the virtual drive as device with mfi0 as identifier. I would expect that my virtual drive has identifier mpr0 or something like this. 2) Why I can install FreeBSD on one of the disks connected to LSI SAS 3108 RAID Controller, if the disks do not build any virtual drive (no matter which RAID level). Is that possible because mpr driver supports the LSI SAS 3108 RAID Controller as SCSI Controller and not as RAID Controller (see Kernel configuration)? Thanks in advance, Z. Kanaeva. -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kanaeva@geographie.uni-tuebingen.de ------- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. From owner-freebsd-stable@freebsd.org Tue Feb 2 17:22:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AB0BA99F58 for ; Tue, 2 Feb 2016 17:22:51 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 CD7F6385 for ; Tue, 2 Feb 2016 17:22:50 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22e.google.com with SMTP id r129so128465299wmr.0 for ; Tue, 02 Feb 2016 09:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=xltA8ebmw8DKbvU5WCJe+5GsGpNkLy43p/917ppe8Jo=; b=R+TGpMhge/HdjB1nKLReayiL5ZYAlN5HBdbjeeLPvnVimN4ph/+26FV/GK1he3V748 aOpR5113NVwNMaTKl/MG8/jbZphdCKxt1GpNTx4oKY/drUfnrXV8iCBdyRfiTC20f45G yAUPUw0mfesD3Z8qgb6Ajy4e0pqq8u4RBvLc+IlPv5umgE4UUFSP0t4Z0gc9F9nWwEJg oZb7qv58uRT/5or3tzQStJc6kd0Va0lwh+7M/2Hkl5zrfTIXaIc41B/R7WHfKwlj+/gi ztO34xK1TIAO6VZIfBMaEQn6r4KrvyQehPucDLELIZJ2hLN46QRJfPiDQE5k3J2+1g33 MuZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xltA8ebmw8DKbvU5WCJe+5GsGpNkLy43p/917ppe8Jo=; b=FXCSz4C88TvdVuBauhQJuB3YV9kKNApLeXKDCZ1CXUWa4xsyz53p8RTEh1hoUIXW5Y X34T6uBznyaop9uOmgZ7DYbXRm+NmEzd0bLPWZ3rOrASFq+7KBe7hion7C8ilk8kB26D 3S7fB+ExVGNHkhtpwfVVdzLYrBJ6uKoDhRavGmMbfJBCQuOTQ4Bz53mWs9W//TD7tBpe 3MuPOLc4TLxEXuyiPJn8fBvNzz3UfJOY9060UAIcioCW9QQf6VjOyRhYXRHeksgtyBQS PG7fFenszyYbFXUzKzZeevHilbobJTDZy68ns8lXGaeSwN9F7wOGdKTK1Fsukmq0hMpe tKTw== X-Gm-Message-State: AG10YOQA8Y5Bk55hVjeuxhvCH0x8kTGqg7hk/sZ0mENPhdK82JYeo1yzLKSg8fQLrPYcNow2 X-Received: by 10.28.194.136 with SMTP id s130mr2434774wmf.23.1454433769086; Tue, 02 Feb 2016 09:22:49 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id c136sm11117206wmd.3.2016.02.02.09.22.47 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 09:22:47 -0800 (PST) Subject: Re: LSI SAS 3108 RAID Controller To: freebsd-stable@freebsd.org References: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> From: Steven Hartland Message-ID: <56B0E5FD.90201@multiplay.co.uk> Date: Tue, 2 Feb 2016 17:23:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 17:22:51 -0000 Try adding this to /boot/loader.conf: hw.mfi.mrsas_enable="1" Regards Steve On 02/02/2016 17:06, Zara Kanaeva wrote: > Dear list, > > I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI > SAS 3108 RAID Controller is supported by the mpr driver > (https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). > If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on > this server I can make partitions, but I can not write install files > on the disks (better to say RAID5 virtual drive) without errors. > The erorrs are: > mfi0 failed to get command > mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS > > By the installations I see my virtual drive as device with mfi0 as > identifier. > > My questions are: > 1) Why I see the virtual drive as device with mfi0 as identifier. I > would expect that my virtual drive has identifier mpr0 or something > like this. > 2) Why I can install FreeBSD on one of the disks connected to LSI SAS > 3108 RAID Controller, if the disks do not build any virtual drive (no > matter which RAID level). Is that possible because mpr driver supports > the LSI SAS 3108 RAID Controller as SCSI Controller and not as RAID > Controller (see Kernel configuration)? > > Thanks in advance, Z. Kanaeva. > From owner-freebsd-stable@freebsd.org Tue Feb 2 18:39:20 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21E45A99C47 for ; Tue, 2 Feb 2016 18:39:20 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 066B01729 for ; Tue, 2 Feb 2016 18:39:20 +0000 (UTC) (envelope-from thierry@pompo.net) Received: by mailman.ysv.freebsd.org (Postfix) id 041EFA99C46; Tue, 2 Feb 2016 18:39:20 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03B95A99C45 for ; Tue, 2 Feb 2016 18:39:20 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mx1b.lautre.net (mx1b.lautre.net [80.67.160.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.lautre.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B44D81726; Tue, 2 Feb 2016 18:39:19 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry@pompo.net) by mx1b.lautre.net (Postfix) with ESMTPSA id CE0387E2B4; Tue, 2 Feb 2016 19:39:14 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id 453933AEA90; Tue, 2 Feb 2016 19:39:14 +0100 (CET) Date: Tue, 2 Feb 2016 19:39:14 +0100 From: Thierry Thomas To: Hajimu UMEMOTO Cc: stable@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160202183913.GG8270@graf.pompo.net> Mail-Followup-To: Hajimu UMEMOTO , stable@FreeBSD.org, mckusick@FreeBSD.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.3-PRERELEASE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xF1C516B3C8359753 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 18:39:20 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le mar 2 f=E9v 16 =E0 8:55:46 +0100, Hajimu UMEMOTO =E9crivait=A0: > Hi, Hello, > I'm disturbed by a frequent hangup of my 10-STABLE boxes since this > year. It seems occur during running the periodic daily scripts. > I've narrowed which commit causes this problem. It seems r292895 > causes it. I see many `Resource temporarily unavailable' message just > before hangup occurs. > Any idea? Not exactly the same problem, but it is also occuring during periodic daily: and also: I'm also experiencing problems during daily periodic on a -STABLE box, but no kernel panics: the machine is frozen, and no login is possible, I have to hard reboot it. For the time being, I have commented out almost every entry in periodic.conf, and I'm trying to find the culprit. Regards, --=20 Th. Thomas. --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJWsPfQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFNTM2QkU4NTM4NTM5OUQwMEI2RkFBNzZG MUM1MTZCM0M4MzU5NzUzAAoJEPHFFrPINZdTmdUP/3MMmXQZTLZB3xLON1GNaIl6 mEGyuomMJ8pPH1gWVE/Se6S+kSe27GfzfTBTUz+oReYHX4eY5EnoMPihLqmYPOBv yIpjEltmQxi3dek4asXmBhrmJt734+pL4HYAk65JgYumCWbwPDQl2FvJYQJPaEts 0ZAh+UNUGQQDxbh0QYoA/9zK2jUtCyyV1FsPTVWqZPPUpjO+qNwxW6bm3C5I0UHp rpxyrsHBCUv5RjYViELr6AV/+i0FYOiOjiNYSlpp6LFsVqnOxiy0OCB0OEWwlMI7 2AOrEmHIKeB15IS/+vCDX7J1LTZKEAc545ok2IpINSZP/Mhs/+F4xt7UxKH9F89H Slhwm5n3V945G4p43ZEy6JuGfYC4FHKs6mlFJpROv4IFNF/X0Fx4NZOZPG7c+WHk RWNa6vW4pz4wgdene4ewXTLoKWnWUyR1OEXamtf4I48dg69cHdDOYYsm4wXv4mUO lO86ZC40jUlnjb67KKm1cBHRf3C1bH8uU/Z3cVTtX6hF5u8nOmOwalwCEp62j4Ek h0xMOHEAv3I7xQ19Zoc0kC3GnSUzh6MSuy7UOmTh78UWFPy51F9uR+bWDz6UZpLf Al0E3QdDZb+AhjbA2eCPjCHcETeQNU2RgDsSow4EUhkqrgmEwSl/EM8+w1mgxTjl 3aI5GRdFQ0bKzwooLjP8 =NUVW -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-stable@freebsd.org Tue Feb 2 19:25:56 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74C89A98E74; Tue, 2 Feb 2016 19:25:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4F8F10BA; Tue, 2 Feb 2016 19:25:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u12JPsL0083417 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 14:25:54 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u12JPr1s016856; Tue, 2 Feb 2016 14:25:53 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: LSI SAS 3108 RAID Controller To: Zara Kanaeva , freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> From: Mike Tancsa X-Enigmail-Draft-Status: N1110 Organization: Sentex Communications Message-ID: <56B102BC.8020502@sentex.net> Date: Tue, 2 Feb 2016 14:25:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 19:25:56 -0000 On 2/2/2016 12:06 PM, Zara Kanaeva wrote: > Dear list, > > I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI > SAS 3108 RAID Controller is supported by the mpr driver Try and attach the mrsas driver to the card. I had a similar problem with an onboard variant. Either compile the kernel without the mfi driver, or force the kernel to assign the mrsas driver to it instead of the mfi driver. hw.mfi.mrsas_enable=1 in /boot/loader.conf # pciconf -lv mrsas0 mrsas0@pci0:1:0:0: class=0x010400 card=0x080915d9 chip=0x005d1000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS-3 3108 [Invader]' class = mass storage subclass = RAID ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Tue Feb 2 20:07:55 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A2EA99D09 for ; Tue, 2 Feb 2016 20:07:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8904D10E7 for ; Tue, 2 Feb 2016 20:07:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: by mailman.ysv.freebsd.org (Postfix) id 86AC0A99D05; Tue, 2 Feb 2016 20:07:55 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C8CAA99D04 for ; Tue, 2 Feb 2016 20:07:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (unknown [IPv6:2001:388:f000::349d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B73010E5; Tue, 2 Feb 2016 20:07:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u12K7iZO041829 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Feb 2016 07:07:51 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u12K7dGW062876 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Feb 2016 07:07:39 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u12K7cNn062875; Wed, 3 Feb 2016 07:07:38 +1100 (AEDT) (envelope-from peter) Date: Wed, 3 Feb 2016 07:07:38 +1100 From: Peter Jeremy To: Hajimu UMEMOTO Cc: stable@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160202200738.GA78969@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Wed, 03 Feb 2016 07:07:51 +1100 (AEDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 20:07:55 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Feb-02 16:55:46 +0900, Hajimu UMEMOTO wrote: >I'm disturbed by a frequent hangup of my 10-STABLE boxes since this >year. It seems occur during running the periodic daily scripts. >I've narrowed which commit causes this problem. It seems r292895 >causes it. I see many `Resource temporarily unavailable' message just >before hangup occurs. >Any idea? As others have said, you need to provide lots more detail on your configuration. That said, I'm seeing something potentially similar on a Google Compute Engine f1-micro instance (1 vCPU, 0.6GB RAM) that is running FreeBSD 10-stable/amd64 with ZFS but basically idle. (Yes, I realize that's very little RAM for ZFS but I previously had no problems with things like buildworld). There were no problems at r290231 but after I upgraded to r295005, I started seeing "out of swap" errors and hangs during the periodic daily runs. I'm not seeing this on 1GB instances - though they are all running UFS. Some experimentation suggested that just "find /" was enough to wedge my system. I did some experimenting and found that the following loader config was enough to prevent it hanging: vfs.zfs.arc_max=3D"128M" vfs.zfs.arc_meta_limit=3D"50M" vfs.zfs.arc_min=3D"25M" (previously, I had no ZFS tuning at all). One odditity was that I would semi-regularly see: kernel: pid 67431 (ntpd), uid 0, was killed: out of swap space I haven't worked out why the OOM killer preferred ntpd to anything else - it didn't seem to be bigger. And I didn't see any signs that swap space was being consumed (though I haven't done a scientific examination). (Note that swap is on a raw partition). The behaviour is definitely a regression and my initial suspicion is ZFS, though I haven't identified any smoking gun. Unfortunately, GCE only offers read access to the console, so I can't use DDB to poke around after it wedges. --=20 Peter Jeremy --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWsQyKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0b80QAJJuXHGlnlpnAmKoh9X3Tejt 0jZuhQ9zHwQJJAJ1c8eZsROZXsrJSMyAaLoUXsp+t0vFT/3VHZ9+vBC0XyaO3ScW wcFbZvCCjoPg0EdqgDJ0oibscJBYMxJUtK5tsoH9pDL0rOsi9/vjnCU1jH60mubA O+Knrt/fTdbrn5B+gbxAz4Nlsl3j3u5FuHJWX0u45PpEOHi6yKkCBhd56QqhtyuC itZ289sC7c3ddZKGejMf8o+Yt0yYMljXY14Eb5N7bAzSEdvLGySX8Nn40bN/UBce cv1QPOuq0y8UKGdofxzhgpmFzKi/wGKTkY/MJfDW027M3gLP2pYFGuAoUCP+cviX +7b5C3LgQxMNBNkat9L4vapkDE23iWwIwukqh2r9Pdi4h3UQfEuRbVgDcoZQatg0 slundqkP4qk/XBKCirfK8ij2Yj1QylC/rdpggoECJM+2q1nkuG8gR50KMRwTj32u zpPHcRN+iTWRfcFqvFelxv3qYJ+4tVTZRjI+TxlKZLoLzoutq56NznzGfqzp+Kqm SB7ScvCHwIzBsmzKWzVQ2E2IGkxkotXAD6+WFcIzQdQpzpJEN05qZzfBmyMEKnw8 +j994kx6iC0GoIAxVte5kmEHfPTBtNR5IIx5oCUlWepRIz69dWH7jWvwqKDRnpH9 /EmuA3vhk4x8E+CfJWMC =M0kL -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-stable@freebsd.org Tue Feb 2 20:44:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EC93A98BC9 for ; Tue, 2 Feb 2016 20:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3A960B17 for ; Tue, 2 Feb 2016 20:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 3A2F9A98BC8; Tue, 2 Feb 2016 20:44:53 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39C7AA98BC7 for ; Tue, 2 Feb 2016 20:44:53 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 EDBC0B16 for ; Tue, 2 Feb 2016 20:44:52 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aQhod-0000cc-6E; Tue, 02 Feb 2016 23:44:47 +0300 Date: Tue, 2 Feb 2016 23:44:47 +0300 From: Slawa Olhovchenkov To: Luigi Rizzo Cc: Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160202204446.GQ88527@zxy.spb.ru> References: <20151018185639.GF42243@zxy.spb.ru> <20151018210049.GT6469@zxy.spb.ru> <20151022163519.GF6469@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 20:44:53 -0000 On Thu, Oct 22, 2015 at 11:24:53AM -0700, Luigi Rizzo wrote: > On Thu, Oct 22, 2015 at 11:12 AM, Adrian Chadd wrote: > > On 22 October 2015 at 09:35, Slawa Olhovchenkov wrote: > >> On Sun, Oct 18, 2015 at 07:45:52PM -0700, Adrian Chadd wrote: > >> > >>> Heh, file a bug with luigi; it should be defined better inside netmap itself. > >> > >> I am CC: luigi. > >> > >> Next question: do kevent RX/TX sync? > >> In my setup I am need to manual NIOCTXSYNC/NIOCRXSYNC. > > > > Hi, > > > > Nope. kqueue() doesn't do the implicit sync like poll() does; it's > > just the notification path. > > actually not. When the file descriptor is registered there > is an implicit sync, and there is another one when an event > is posted for the file descriptor. > > unless there are bugs, of course. I found strange behaivor: 1. open netmap and register in main thread 2. kevent register in different thread 3. result: got event by kevent but no ring sinc (all head,tail,cur still 0). Is this normal? Or is this bug? open and registering netmap in same thread as kevent resolve this. From owner-freebsd-stable@freebsd.org Tue Feb 2 22:09:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39866A99C13 for ; Tue, 2 Feb 2016 22:09:29 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oitsec.umn.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B63939 for ; Tue, 2 Feb 2016 22:09:28 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id DB27E5C80C for ; Tue, 2 Feb 2016 16:09:19 -0600 (CST) X-Virus-Scanned: amavisd-new at oitsec.umn.edu Received: from mail.oitsec.umn.edu ([127.0.0.1]) by mail.oitsec.umn.edu (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7knDhq7JaJNk for ; Tue, 2 Feb 2016 16:09:19 -0600 (CST) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [134.84.23.1]) (Authenticated sender: amesbury) by mail.oitsec.umn.edu (Postfix) with ESMTPSA id 7BDE45C80A for ; Tue, 2 Feb 2016 16:09:19 -0600 (CST) From: Alan Amesbury Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1? Message-Id: Date: Tue, 2 Feb 2016 16:09:19 -0600 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 22:09:29 -0000 First off.... Yes, I know 9.1-RELEASE is deprecated. I want to run = something newer, but circumstances require I can't for now. Traditionally in FreeBSD -STABLE (as in 9-STABLE) referred to the APIs = as being stable, i.e., stuff compiled within the same major release = would generally run on versions within that release... or so I recall. = I have an instance where I have a need to run 9.1-RELEASE, but my = package building infrastructure is all centered around 9.3-RELEASE or = later. Based on my (possibly incorrect) understanding of How Things = Are[tm], I think packages built for 9.3-RELEASE will generally run on = 9.1-RELEASE. Does this sound generally correct, or am I totally off = base here? Any major pitfalls I should know of? --=20 Alan Amesbury University Information Security http://umn.edu/lookup/amesbury From owner-freebsd-stable@freebsd.org Tue Feb 2 22:16:17 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44D56A99E53 for ; Tue, 2 Feb 2016 22:16:17 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 30CDACCF for ; Tue, 2 Feb 2016 22:16:17 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:c76:2f7d:b92b:76e4]) by elvis.mu.org (Postfix) with ESMTPSA id 99E92345A947 for ; Tue, 2 Feb 2016 14:16:16 -0800 (PST) Subject: Re: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1? To: freebsd-stable@freebsd.org References: From: Alfred Perlstein Message-ID: <56B12AB0.5090503@mu.org> Date: Tue, 2 Feb 2016 14:16:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 22:16:17 -0000 On 2/2/16 2:09 PM, Alan Amesbury wrote: > First off.... Yes, I know 9.1-RELEASE is deprecated. I want to run something newer, but circumstances require I can't for now. > > Traditionally in FreeBSD -STABLE (as in 9-STABLE) referred to the APIs as being stable, i.e., stuff compiled within the same major release would generally run on versions within that release... or so I recall. I have an instance where I have a need to run 9.1-RELEASE, but my package building infrastructure is all centered around 9.3-RELEASE or later. Based on my (possibly incorrect) understanding of How Things Are[tm], I think packages built for 9.3-RELEASE will generally run on 9.1-RELEASE. Does this sound generally correct, or am I totally off base here? Any major pitfalls I should know of? > > It's possible they may work, but that is not guaranteed. Packages built on 9.1 should work on 9.3. Packages built on 9.3 may work on 9.1, but that would only be by chance. -Alfred From owner-freebsd-stable@freebsd.org Tue Feb 2 22:51:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50DECA99638 for ; Tue, 2 Feb 2016 22:51:24 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "erg.verweg.com", Issuer "Verweg Dot Com CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D56521762 for ; Tue, 2 Feb 2016 22:51:23 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from [IPv6:2001:980:4ffa:1:a5ec:f53:f82e:2d02] ([IPv6:2001:980:4ffa:1:a5ec:f53:f82e:2d02]) (authenticated bits=0) by erg.verweg.com (8.15.2/8.14.9) with ESMTPSA id u12MpJp1009226 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Feb 2016 22:51:19 GMT (envelope-from ruben@verweg.com) From: Ruben van Staveren X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_1EB1D9D1-F4F2-4AC7-8250-A3D2721E0CFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: restore zfs pool using original devices? Date: Tue, 2 Feb 2016 23:51:17 +0100 Message-Id: <0B08A730-0648-4AFD-8043-FE3A843CC8A1@verweg.com> To: "freebsd-stable@FreeBSD.org Stable" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (erg.verweg.com [IPv6:2a02:898:96:0:0:0:5e8e:f508]); Tue, 02 Feb 2016 22:51:19 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 02 Feb 2016 22:51:24 -0000 --Apple-Mail=_1EB1D9D1-F4F2-4AC7-8250-A3D2721E0CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi list, Recently I decided to grow my zfs pool from 1TB to 6TB by replacing my = 1TB dell rebranded toshiba disk with an HGST Deskstar NAS 6 TB one. system was running 10.2 to make things easier, I decided to do a zpool replace on both the = unencrypted boot and encrypted (as per = https://www.dan.me.uk/blog/2012/05/06/full-disk-encryption-with-zfs-root-f= or-freebsd-9-x/) system pool zpool replace system gpt/boot diskid/DISK-NAHRVZDXp2 zpool replace system gpt/system.eli diskid/DISK-NAHRVZDXp3.eli The system ran fine for a while until I rebooted it: https://ruben.is.verweg.com/stuff/IMG_5734.jpg a panic during mounting root panic: solaris assert: nvlist_lookup_uint64(configs[i], = ZPOOL_CONFIG_POOL_TXG, &txg) =3D=3D 0: file = src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c= :4040 I tried to recover diskid/DISK-NAHRVZDXp2 by creating a new boot pool on = a rescue nanobsd image, so I could recover the encryption keys. No I = didn=E2=80=99t make an off system backup of those with zpool create -R = /path/to/temp/root-for-boot zboot /dev/diskid/DISK-NAHRVZDXp2. first it complained the disk was part of the original boot pool, so I = used -f. upon inspection I found the disk to be empty, so it looks like = that action destroyed some important metadata. should it do that = actually? I wanted to restore that data so I used dd if=3D/dev/gpt/boot = of=3D/dev/diskid/DISK-NAHRVZDXp2 bs=3D64k but the contents is not = restored. a cat of /dev/gpt/boot show various data is still there, but not seen = anymore by zfs. given zfs replace actually involves a temporarily mirror in where the = old vdev is removed, it should be pretty much possible to re attach this = vdev to any pool to see its contents again ? what are my chances to create a functional new pool using old devices? Best Regards, Ruben --Apple-Mail=_1EB1D9D1-F4F2-4AC7-8250-A3D2721E0CFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaxMuYACgkQZ88+mcQxRw0BigCggg5OP0dN909N4bkEfdDhFH+M xE8AnRGlcNvDdi67bEW9Ou8DBzrvDwGs =53zX -----END PGP SIGNATURE----- --Apple-Mail=_1EB1D9D1-F4F2-4AC7-8250-A3D2721E0CFA-- From owner-freebsd-stable@freebsd.org Wed Feb 3 01:04:11 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8117AA9AB0E for ; Wed, 3 Feb 2016 01:04:11 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 67F1E1DB4 for ; Wed, 3 Feb 2016 01:04:11 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: by mailman.ysv.freebsd.org (Postfix) id 652BEA9AB0D; Wed, 3 Feb 2016 01:04:11 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AD48A9AB0C for ; Wed, 3 Feb 2016 01:04:11 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8901DB3; Wed, 3 Feb 2016 01:04:10 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ume@ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (user=ume mech=CRAM-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u1313wwb000827 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 10:04:03 +0900 (JST) (envelope-from ume@mahoroba.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mahoroba.org; s=20081103; t=1454461443; bh=oMUh9kT5stYlcEJ301llMjpoXMVzgs/97DjmMhSz1EM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=STpnjfrLQgn6h+2gnOqx0RGv0TlWAlMm8fdv3MvzAFQtTB7T9rHWY62B8LG0rocJW H4ulTeLp62JX9yfV7zBrQxCL5T+PA4UJVUF72zzY9sPU3phlKTChG1vdqbiS4fFYYK Uny295gU6SfUuTBOXh6KvZdIJLAfsUTu8ocUSHRA= Date: Wed, 03 Feb 2016 10:03:58 +0900 Message-ID: From: Hajimu UMEMOTO To: Peter Jeremy Cc: stable@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: 10-STABLE hangups frequently In-Reply-To: <20160202200738.GA78969@server.rulingia.com> References: <20160202200738.GA78969@server.rulingia.com> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-PRERELEASE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6a2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 03 Feb 2016 10:04:03 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 01:04:11 -0000 Hi, >>>>> On Wed, 3 Feb 2016 07:07:38 +1100 >>>>> Peter Jeremy said: peter> As others have said, you need to provide lots more detail on your peter> configuration. CPU: AMD Athlon(tm) 64 Processor 3500+ Memory: 4GB HDD: 3TB I'm using ZFS only setup. peter> There were no problems at r290231 but after I upgraded to r295005, I peter> started seeing "out of swap" errors and hangs during the periodic peter> daily runs. I'm not seeing this on 1GB instances - though they are peter> all running UFS. r292875 runs well: FreeBSD asuka.mahoroba.org 10.2-STABLEFreeBSD 10.2-STABLE #5 r292875: Tue Feb 2 07:08:29 JST 2016 root@asuka.mahoroba.org:/usr/obj/usr/src/sys/ASUKA amd6 r292895 hangs: FreeBSD asuka.mahoroba.org 10.2-STABLE FreeBSD 10.2-STABLE #6 r292895: Tue Feb 2 10:17:28 JST 2016 root@asuka.mahoroba.org:/usr/obj/usr/src/sys/ASUKA amd64 I tried latest stable (r295137) with the sys/kern/vfs_subr.c part of r292895 reverted, and it seems running well, here: FreeBSD asuka.mahoroba.org 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #0 r295137M: Tue Feb 2 20:39:11 JST 2016 root@asuka.mahoroba.org:/usr/obj/usr/src/sys/ASUKA amd64 peter> Some experimentation suggested that just "find /" was enough to wedge peter> my system. I did some experimenting and found that the following peter> loader config was enough to prevent it hanging: peter> vfs.zfs.arc_max="128M" peter> vfs.zfs.arc_meta_limit="50M" peter> vfs.zfs.arc_min="25M" peter> (previously, I had no ZFS tuning at all). I had ZFS tuning before. However, after this problem was occur, I removed all of ZFS tuning. The FS related setting is only kern.maxvnodes=400000, now. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@freebsd.org Wed Feb 3 07:58:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB985A99BFE for ; Wed, 3 Feb 2016 07:58:24 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BC3C1160E for ; Wed, 3 Feb 2016 07:58:24 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: by mailman.ysv.freebsd.org (Postfix) id B96B1A99BFD; Wed, 3 Feb 2016 07:58:24 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B90ACA99BFC for ; Wed, 3 Feb 2016 07:58:24 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE1B160D; Wed, 3 Feb 2016 07:58:23 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-70-178.lns20.adl6.internode.on.net (HELO leader.local) ([121.45.70.178]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Feb 2016 18:23:14 +1030 Subject: Re: 10-STABLE hangups frequently To: Hajimu UMEMOTO , stable@FreeBSD.org, mckusick@FreeBSD.org References: <20160202183913.GG8270@graf.pompo.net> From: Shane Ambler Message-ID: <56B1B1E9.2090707@ShaneWare.Biz> Date: Wed, 3 Feb 2016 18:23:13 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160202183913.GG8270@graf.pompo.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 07:58:24 -0000 On 03/02/2016 05:09, Thierry Thomas wrote: > Le mar 2 fév 16 à 8:55:46 +0100, Hajimu UMEMOTO > écrivait : > >> Hi, > > Hello, > >> I'm disturbed by a frequent hangup of my 10-STABLE boxes since this >> year. It seems occur during running the periodic daily scripts. >> I've narrowed which commit causes this problem. It seems r292895 >> causes it. I see many `Resource temporarily unavailable' message just >> before hangup occurs. >> Any idea? > > Not exactly the same problem, but it is also occuring during periodic > daily: > > > and also: > > > I'm also experiencing problems during daily periodic on a -STABLE box, > but no kernel panics: the machine is frozen, and no login is possible, I > have to hard reboot it. > > For the time being, I have commented out almost every entry in > periodic.conf, and I'm trying to find the culprit. > > Regards, > Any chance you get high wired allocations? Sometimes several times in a day I see the wired amount shown in top rise to over 6GB (of 8GB) bringing the system to a crawl. When wired gets over 7GB the system rarely recovers. I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS This is my everyday desktop running xfce and a variety of gui apps. I use a small script to allocate several GB of ram that gives the pressure needed to start releasing some wired, provided I can get in early enough. Not sure how to gather any helpful info for this. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@freebsd.org Wed Feb 3 11:41:55 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8389A9A5EE for ; Wed, 3 Feb 2016 11:41:54 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.5.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtpserv.uni-tuebingen.de", Issuer "Global-UNITUE-CA 01" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77DD419F9 for ; Wed, 3 Feb 2016 11:41:54 +0000 (UTC) (envelope-from zara.kanaeva@ggi.uni-tuebingen.de) Received: from webmail1.uni-tuebingen.de (webmail1.uni-tuebingen.de [134.2.5.194]) by mx08.uni-tuebingen.de (8.14.3/8.14.3) with ESMTP id u13Beu3s029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2016 12:40:56 +0100 Received: from webmail1.uni-tuebingen.de (localhost [127.0.0.1]) by webmail1.uni-tuebingen.de (Postfix) with ESMTPS id 4BDF91117A7F0 for ; Wed, 3 Feb 2016 12:40:56 +0100 (CET) Received: from roceehbwz.rue23.uni-tuebingen.de (roceehbwz.rue23.uni-tuebingen.de [134.2.216.135]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Wed, 03 Feb 2016 12:40:56 +0100 Date: Wed, 03 Feb 2016 12:40:56 +0100 Message-ID: <20160203124056.Horde.dqYrbya4IhUg-uSNWUr9u9K@webmail.uni-tuebingen.de> From: Zara Kanaeva To: freebsd-stable@freebsd.org Subject: Re: LSI SAS 3108 RAID Controller In-Reply-To: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 11:41:55 -0000 Thank you for all responds. set hw.mfi.mrsas_enable=1 in Loader prompt did the work. The useful information for this problem can be found here: http://lists.dragonflybsd.org/pipermail/users/2014-July/128703.html Regards, Z.K. Zitat von Zara Kanaeva : > Dear list, > > I have one Fujitsu server with LSI SAS 3108 RAID Controller. These > LSI SAS 3108 RAID Controller is supported by the mpr driver > (https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). > If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 > on this server I can make partitions, but I can not write install > files on the disks (better to say RAID5 virtual drive) without errors. > The erorrs are: > mfi0 failed to get command > mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS > > By the installations I see my virtual drive as device with mfi0 as > identifier. > > My questions are: > 1) Why I see the virtual drive as device with mfi0 as identifier. I > would expect that my virtual drive has identifier mpr0 or something > like this. > 2) Why I can install FreeBSD on one of the disks connected to LSI > SAS 3108 RAID Controller, if the disks do not build any virtual > drive (no matter which RAID level). Is that possible because mpr > driver supports the LSI SAS 3108 RAID Controller as SCSI Controller > and not as RAID Controller (see Kernel configuration)? > > Thanks in advance, Z. Kanaeva. > > -- > Dipl.-Inf. Zara Kanaeva > Heidelberger Akademie der Wissenschaften > Forschungsstelle "The role of culture in early expansions of humans" > an der Universität Tübingen > Geographisches Institut > Universität Tübingen > Ruemelinstr. 19-23 > 72070 Tuebingen > > Tel.: +49-(0)7071-2972132 > e-mail: zara.kanaeva@geographie.uni-tuebingen.de > ------- > - Theory is when you know something but it doesn't work. > - Practice is when something works but you don't know why. > - Usually we combine theory and practice: > Nothing works and we don't know why. -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kanaeva@geographie.uni-tuebingen.de ------- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. From owner-freebsd-stable@freebsd.org Wed Feb 3 14:20:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F777A9A244; Wed, 3 Feb 2016 14:20:36 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 BB338CC6; Wed, 3 Feb 2016 14:20:35 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id r129so167347532wmr.0; Wed, 03 Feb 2016 06:20:35 -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=AYo/oRj/C/TS1wMDGooKA84g1c090c187f7dU5bSY0M=; b=a1lwRso9ZNCXzDh9uu9WaV5ZTnF2FI3Jv7AoduWvqc0WhQ6Kqn9YJSVt1j4f3cj3V+ WO7+GWJ0pN4uHn4wHLBhIb3jO8wi+aAAC2NysRP/NZ1+iuX3mcg3X7FZIwSJz2GCEMX9 5Xo4+T/rfltJmLYp8wzBUvEh/lVi7Qp3Oqpy0Z5GzKTlLmajdk7LLB/LLfwbhzkZpVUl yu0sIRdAgG9MEMzm86VyA6xbCpE68FjBpFj0m4wd3Lq6tQMvBNfhMsMV3yoJmcK8E0jb tVi+4SXYv8Z7JWjIvzu3aUofcXTH/xbTFW1L7AoCAYTtqqJSCsI9aPDicX47zcwLESDk GcMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AYo/oRj/C/TS1wMDGooKA84g1c090c187f7dU5bSY0M=; b=JDzgLHLe5u490Gl3ZNbQboMJcE3u/YWgvgJPaaql73FHuzOwRAwQ4vDT3CymgcmnlI xn+UFzVsFE0+QFBpfZSyPFK6fdE3UdNlXSgJgES7bPqx6jRCHiq0fRkmBmRSg6yPWwzp i4OiEMTHmFXg4qb7Dw3CP6iPG53fLyR9xomupY2ic3qganE1cdKxGTCtxIR3ecMMrI0t Ms+pkA4O8ohXdI2GRRZxxdO1NUGhEArNax+dnVRLyalwF94lMIwuuvqHIVoAwStBLfQk SDxs8W4nWASUrHvTk3e64917EwkfvOS19+UCNBgkrVtu9p1ATdjqnT2vZmqnnn0+Ila2 ZLbw== X-Gm-Message-State: AG10YOQQzi0ZsiTIcY68D0XbFhVizqLyJX/qjIO1HOU06XYdsGK6Xey9hMdV5vYHlXurJ6mDSauRlHP+8a6xWA== MIME-Version: 1.0 X-Received: by 10.194.202.135 with SMTP id ki7mr2456880wjc.81.1454509234128; Wed, 03 Feb 2016 06:20:34 -0800 (PST) Received: by 10.28.55.132 with HTTP; Wed, 3 Feb 2016 06:20:34 -0800 (PST) In-Reply-To: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> References: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> Date: Wed, 3 Feb 2016 14:20:34 +0000 Message-ID: Subject: Re: LSI SAS 3108 RAID Controller From: krad To: Zara Kanaeva Cc: freebsd-stable , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 14:20:36 -0000 Just a sanity check 1st. Are you going to be using zfs or ufs? If zfs you probably want the reflash the card the the relevant HBA firmware rather the the raid firmware. This will expose the disks nativly which is best for zfs. Sorry if this isn't appropriate for you but I would thought I would check as it might save you a whole load of pain going in a direction you don't need to. On 2 February 2016 at 17:06, Zara Kanaeva wrote: > Dear list, > > I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI SA= S > 3108 RAID Controller is supported by the mpr driver ( > https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). > If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on > this server I can make partitions, but I can not write install files on t= he > disks (better to say RAID5 virtual drive) without errors. > The erorrs are: > mfi0 failed to get command > mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS > > By the installations I see my virtual drive as device with mfi0 as > identifier. > > My questions are: > 1) Why I see the virtual drive as device with mfi0 as identifier. I would > expect that my virtual drive has identifier mpr0 or something like this. > 2) Why I can install FreeBSD on one of the disks connected to LSI SAS 310= 8 > RAID Controller, if the disks do not build any virtual drive (no matter > which RAID level). Is that possible because mpr driver supports the LSI S= AS > 3108 RAID Controller as SCSI Controller and not as RAID Controller (see > Kernel configuration)? > > Thanks in advance, Z. Kanaeva. > > -- > Dipl.-Inf. Zara Kanaeva > Heidelberger Akademie der Wissenschaften > Forschungsstelle "The role of culture in early expansions of humans" > an der Universit=C3=A4t T=C3=BCbingen > Geographisches Institut > Universit=C3=A4t T=C3=BCbingen > Ruemelinstr. 19-23 > 72070 Tuebingen > > Tel.: +49-(0)7071-2972132 > e-mail: zara.kanaeva@geographie.uni-tuebingen.de > ------- > - Theory is when you know something but it doesn't work. > - Practice is when something works but you don't know why. > - Usually we combine theory and practice: > Nothing works and we don't know why. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://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 3 16:28:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FE44A9A406 for ; Wed, 3 Feb 2016 16:28:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0CC639F for ; Wed, 3 Feb 2016 16:28:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u13GSRfj080864 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2016 11:28:27 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u13GSQh2023000; Wed, 3 Feb 2016 11:28:26 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: possible em regression (was Re: svn commit: r294958 - in stable/10: share/man/man4 sys/dev/e1000 sys/dev/ixgb sys/dev/netmap) To: Marius Strobl References: <201601272231.u0RMV8LW019394@repo.freebsd.org> <56ABAA92.5050901@sentex.net> <56ABB291.5040305@omnilan.de> <56ABCE95.3030807@sentex.net> <20160130012358.GY15359@alchemy.franken.de> <56ACE917.80502@sentex.net> <20160130172618.GA15359@alchemy.franken.de> <56AFD811.1030706@sentex.net> <20160201222756.GE15359@alchemy.franken.de> Cc: FreeBSD-STABLE Mailing List From: Mike Tancsa Organization: Sentex Communications Message-ID: <56B22AA2.3030000@sentex.net> Date: Wed, 3 Feb 2016 11:28:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160201222756.GE15359@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 16:28:29 -0000 On 2/1/2016 5:27 PM, Marius Strobl wrote: > On Mon, Feb 01, 2016 at 05:11:29PM -0500, Mike Tancsa wrote: >> On 1/30/2016 12:26 PM, Marius Strobl wrote: >>> >>> Ah, okay, that at least makes sense. Can you please verify that with >>> the attached patch applied, you have a setup that works out of the > by e-mail. I've put it online: > https://people.freebsd.org/~marius/em_tso_gig_only_10.diff So far so good. I have been running it on a couple of boxes and no watchdog resets # ifconfig em0 em0: flags=8943 metric 0 mtu 1500 options=4219b media: Ethernet autoselect (100baseTX ) status: active # pciconf -lvcb em0 em0@pci0:5:0:0: class=0x020000 card=0x348d8086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xea180000, size 131072, enabled bar [14] = type Memory, range 32, base 0xea100000, size 524288, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) RO NS link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffff2e31ad and # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4219b media: Ethernet autoselect (100baseTX ) status: active # pciconf -lcvb em0 em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xe8a00000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x5000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) RO NS link x1(x1) speed 2.5(2.5) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 003048ffff9c59f0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Wed Feb 3 16:47:46 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE94FA9AC48 for ; Wed, 3 Feb 2016 16:47:45 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D375B15B7 for ; Wed, 3 Feb 2016 16:47:45 +0000 (UTC) (envelope-from thierry@pompo.net) Received: by mailman.ysv.freebsd.org (Postfix) id D2CD4A9AC47; Wed, 3 Feb 2016 16:47:45 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D269DA9AC46 for ; Wed, 3 Feb 2016 16:47:45 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mx1a.lautre.net (eyra.lautre.net [80.67.160.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lautre.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 96C8F15B6; Wed, 3 Feb 2016 16:47:44 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry@pompo.net) by mx1a.lautre.net (Postfix) with ESMTPSA id 5A9B7413A4; Wed, 3 Feb 2016 17:47:41 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id D168C50E88D; Wed, 3 Feb 2016 17:47:40 +0100 (CET) Date: Wed, 3 Feb 2016 17:47:40 +0100 From: Thierry Thomas To: Shane Ambler Cc: Hajimu UMEMOTO , stable@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160203164740.GO8270@graf.pompo.net> Mail-Followup-To: Shane Ambler , Hajimu UMEMOTO , stable@FreeBSD.org, mckusick@FreeBSD.org References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4zI0WCX1RcnW9Hbu" Content-Disposition: inline In-Reply-To: <56B1B1E9.2090707@ShaneWare.Biz> X-Operating-System: FreeBSD 10.3-PRERELEASE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xF1C516B3C8359753 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 16:47:46 -0000 --4zI0WCX1RcnW9Hbu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le mer 3 f=E9v 16 =E0 8:53:13 +0100, Shane Ambler =E9crivait=A0: > Any chance you get high wired allocations? >=20 > Sometimes several times in a day I see the wired amount shown in top > rise to over 6GB (of 8GB) bringing the system to a crawl. When wired > gets over 7GB the system rarely recovers. >=20 > I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS > This is my everyday desktop running xfce and a variety of gui apps. >=20 > I use a small script to allocate several GB of ram that gives the > pressure needed to start releasing some wired, provided I can get in > early enough. >=20 > Not sure how to gather any helpful info for this. I don't think so: this box has 16 GB of RAM, and everything is usually fine, even during high activity (e.g. poudriere build). The problem occurs only at daily periodic time. It's not repetable on demand, that's why I've not yet identified the task... --=20 Th. Thomas. --4zI0WCX1RcnW9Hbu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJWsi8rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFNTM2QkU4NTM4NTM5OUQwMEI2RkFBNzZG MUM1MTZCM0M4MzU5NzUzAAoJEPHFFrPINZdTNy8P/0UlqZdfRuNU8Oh0gzlFCzht XOulReVOqXpJV/0BeeE6wGMGUv8dSl4O2BUU/8Oy8KGo5I1IsQnW8HnVsoa8jyAt Tbw1WhJJYhguUZqv06CyFFgr5ccc0xOMpZeT6D9UhTpHKDu1Nf9hocLDB5EbZQjT prsIrsKAaW11gJtmAcf7iY11Yc3iSk3d3FG5LGGWnclMFmnYcoGZSu6OVzdCcpDk nk+Dfeka5DnbyHTGn6cDgjSHUsermJhmvUGT2EWmpQ78Ng0m6lb6Reu+ulc7ZezF huFwfPoFjHrmzTmx9TaHAt4nij6jgPhjbTL9Xkf7oQWOC+DDpHeD85xhHOxS5ztN VWfvavCFGsGjo56j7hd9JL/cqBq2i+gciZuawTC4Iz7z7OmDEmlBUuZ2AC4OHohD r89oPQki54Xl7f7SvYmHUAATrLALXrxgK0AIWCERsotap0n60Ho6TKy021kqsvK6 T7HAvysGpYwSPTfH0OkvVtdUKTLM1G5UaQnXMD02L/fRo/WOnpL8pQ6cGMDQ++6h wwEyzNWsdLqON3ppTBNwIVjpt6xw3UFjU0RPM9Q9+pmsja6ro2VnjBWx3UzlMo5m xe5D8lNcG672jWmUIDOVzvWOQhFUTotvGxqtYS/R1w43naq8gN3XShc8QGOQDi2B S1Sh8p1Iz7qQd/TKyeNh =619N -----END PGP SIGNATURE----- --4zI0WCX1RcnW9Hbu-- From owner-freebsd-stable@freebsd.org Wed Feb 3 17:01:32 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 914ABA99222 for ; Wed, 3 Feb 2016 17:01:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 5F4E01FB4 for ; Wed, 3 Feb 2016 17:01:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 61BC1228B6E for ; Wed, 3 Feb 2016 10:55:53 -0600 (CST) Subject: Re: 10-STABLE hangups frequently To: freebsd-stable@freebsd.org References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> <20160203164740.GO8270@graf.pompo.net> From: Karl Denninger Message-ID: <56B230E7.9050107@denninger.net> Date: Wed, 3 Feb 2016 10:55:03 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160203164740.GO8270@graf.pompo.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080207030109050604080902" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 17:01:32 -0000 This is a cryptographically signed message in MIME format. --------------ms080207030109050604080902 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable (Whistling.....) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 (see if that helps you) On 2/3/2016 10:47, Thierry Thomas wrote: > Le mer 3 f=E9v 16 =E0 8:53:13 +0100, Shane Ambler > =E9crivait : > >> Any chance you get high wired allocations? >> >> Sometimes several times in a day I see the wired amount shown in top >> rise to over 6GB (of 8GB) bringing the system to a crawl. When wired >> gets over 7GB the system rarely recovers. >> >> I am now running 10.2-STABLE r292646 on corei7 with 8GB and ZFS FS >> This is my everyday desktop running xfce and a variety of gui apps. >> >> I use a small script to allocate several GB of ram that gives the >> pressure needed to start releasing some wired, provided I can get in >> early enough. >> >> Not sure how to gather any helpful info for this. > I don't think so: this box has 16 GB of RAM, and everything is usually > fine, even during high activity (e.g. poudriere build). The problem > occurs only at daily periodic time. > > It's not repetable on demand, that's why I've not yet identified the > task... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080207030109050604080902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMDMxNjU1MDNaME8GCSqGSIb3DQEJBDFCBECH hlx/iH+1BXgBTud9mylJ2m4wWQPunboaZ7XzDpTvOHLtSryYxSmBlXlyz2B90Vs4gbghjw3v oi1DhnVspCV9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAc7WMXvPs JaIzVSP8p9LLrZGe2+cXybXP7KRtwSHyQ6tb3hc5kocu/xad8o9Q0BHJO2ghJfZ8+tklgGu3 2StAZ6rGgmH+rmAIIYjuYmhurZu+JbTj9sipOC7y3QYa1dFdC1jVNKzjnVHGVb4c7FVvdgIT 8/d5GWJQ13vD2YIV5EbV5zdhP4FNmXMFC15vzFIV8ou+vzpdZrYHA/e4iw7Haj2AHkfICMyd BWfvtPoPvhHq7UG35whbvb5TwGgoPIILSeF/zcKN3vYWxKnGR9BJ+uygJMl35ACko7x6ldro 8R9k43EPRt/IkjwqBuxaDJeu1EQneML4wK6OSZvv9ihG38HYYFNU0WuglIArQ93Q1FinHbP1 oSPUNYN8jLrgiUzW7uSFYhkzTKf8RCD3TpUEo+s8Ab68D2ZPBfi+TFGgJjjUCO76TyWtwxZa 1HgzXO0KyFSwe7I9VgV2AT0vaeZs5g4IeaC+E/4lvACiawFqvxFgNsDTecc6BHaFws0vvVXk zvWYJ4+ub/lAC1mHq+qLE1w1XrikAO0mmMaMK6YjFM1ubM9L7naIDyK2NQxx1UBX+lU8QZAM LeNlbk9dA+tEgKA1knMGWrqBwE9rkOUI/8FOs0OJXzBbEN8aM4s5IU3GUyZ018vOPBHDnMZO KvnUpGiGmV8noVo9wRt+qULKJJIAAAAAAAA= --------------ms080207030109050604080902-- From owner-freebsd-stable@freebsd.org Wed Feb 3 18:12:31 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A845A97EB5; Wed, 3 Feb 2016 18:12:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 31206E4F; Wed, 3 Feb 2016 18:12:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id u13ICUAB093944 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Feb 2016 13:12:30 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c] ([IPv6:2607:f3e0:0:4:5c30:ed1b:e203:c55c]) by lava.sentex.ca (8.14.9/8.14.9) with ESMTP id u13ICTv1023477; Wed, 3 Feb 2016 13:12:29 -0500 (EST) (envelope-from mike@sentex.net) Subject: Re: LSI SAS 3108 RAID Controller To: krad , Zara Kanaeva References: <20160202180633.Horde.XX1o8RUHQB-jhWuJls7E7KO@webmail.uni-tuebingen.de> Cc: freebsd-current@freebsd.org, freebsd-stable From: Mike Tancsa Organization: Sentex Communications Message-ID: <56B24305.8010402@sentex.net> Date: Wed, 3 Feb 2016 13:12:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 18:12:31 -0000 On 2/3/2016 9:20 AM, krad wrote: > > If zfs you probably want the reflash the card the the relevant HBA firmware > rather the the raid firmware. This will expose the disks nativly which is > best for zfs. The version of card I have allows you to expose the individual disks as JBODs out of the box. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@freebsd.org Wed Feb 3 19:03:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECA7EA9A1DE for ; Wed, 3 Feb 2016 19:03:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D2198C47 for ; Wed, 3 Feb 2016 19:03:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: by mailman.ysv.freebsd.org (Postfix) id CEECAA9A1DD; Wed, 3 Feb 2016 19:03:40 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE771A9A1DC for ; Wed, 3 Feb 2016 19:03:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (unknown [IPv6:2001:388:f000::349d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD29C46 for ; Wed, 3 Feb 2016 19:03:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u13J3Us8048456 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Feb 2016 06:03:36 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u13J3Osh099060 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Feb 2016 06:03:24 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u13J3NIB099059; Thu, 4 Feb 2016 06:03:23 +1100 (AEDT) (envelope-from peter) Date: Thu, 4 Feb 2016 06:03:23 +1100 From: Peter Jeremy To: Shane Ambler Cc: stable@FreeBSD.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160203190323.GC78969@server.rulingia.com> References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline In-Reply-To: <56B1B1E9.2090707@ShaneWare.Biz> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Thu, 04 Feb 2016 06:03:37 +1100 (AEDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 19:03:41 -0000 --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Feb-03 18:23:13 +1030, Shane Ambler wrote: >Any chance you get high wired allocations? A high wired allocation is normal for ZFS - ARC shows up as "wired" memory. >Sometimes several times in a day I see the wired amount shown in top >rise to over 6GB (of 8GB) bringing the system to a crawl. When wired >gets over 7GB the system rarely recovers. The ARC limit defaults to 1GB less than physical RAM so 6GB wired on an 8GB system isn't unexpected (my home system currently has 30GB wired out of 32GB). If this is causing problems for your workload, it sounds like you may need to explicitly reduce vfs.zfs.arc_max (note that this is a soft limit). You might like to install sysutils/zfs-stats and do some ZFS tunung. --=20 Peter Jeremy --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWsk77XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0NEcP/Avhw4QEDAYmKkg04RndIlGH mpms0ZF9wl7i82vzrtKK+JrpTEzzkzLBYRqLiDV34nkPa0A4Md766JWpe80GCT29 asQmn9XyrM30c6EP0sEgP44xekyH8gZrFSZ6oP9cS3kgyh76S2hkHW5KWvB+6Yl5 kqIVvIx2CajWAbXAlx9FdtzfvnxoxfwIG+dMyhxpj9raAMmWc2EGPS0QcfAy6COs k/rMvcKMQk09TLVDJ5DpOVdnB6yYslnfEfNzUwPGeERlkd36kOken5j3PRxlUVCK s0rMcdcTPMtsFbeHMXSENUnTsEjLS/r33qd6sXwctGCHckBadmB7NZg74v8UMjxT VaWuDAohKNogkctZ94t/uan4CpGvhFjwFLObmdpmTwnzYBYjhqetYYHBZRVS3rAw F2i3Ms5fdd3lRnAOhpWQZ6YHLCh6kee3eIhoz35CY0Wl6U9VqsKWQiu04nIUbFbv InXvAgz+r5llSaYfMN4w7eCeMecfpURAwWXGuG2WahQ5rrj0Zatbc29qYYclIjcS LPr0D84w3sKq+m71tJD+HfJIeHC0Fqj7LtJ+GuTR2tEKcEKpphxTnlteZCq5xLnE pYff8DGOKGyXMUPFHM50i6daNMQSRyfGtxLq7RgqUzGbUwEcGhQuYV6z4+YTys3G ElC0/ChpI+eTagnqCJ0X =SjVW -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye-- From owner-freebsd-stable@freebsd.org Wed Feb 3 20:10:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCF10A9B6D5 for ; Wed, 3 Feb 2016 20:10:33 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oitsec.umn.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B64E6145E for ; Wed, 3 Feb 2016 20:10:33 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id 4C77E5C80C for ; Wed, 3 Feb 2016 14:10:29 -0600 (CST) X-Virus-Scanned: amavisd-new at oitsec.umn.edu Received: from mail.oitsec.umn.edu ([127.0.0.1]) by mail.oitsec.umn.edu (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjaEor-HndBV for ; Wed, 3 Feb 2016 14:10:28 -0600 (CST) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [134.84.23.1]) (Authenticated sender: amesbury) by mail.oitsec.umn.edu (Postfix) with ESMTPSA id 9B26A5C80A for ; Wed, 3 Feb 2016 14:10:28 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1? From: Alan Amesbury In-Reply-To: Date: Wed, 3 Feb 2016 14:10:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 20:10:34 -0000 Alfred Perlstein said: > It's possible they may work, but that is not guaranteed. >=20 > Packages built on 9.1 should work on 9.3. >=20 > Packages built on 9.3 may work on 9.1, but that would only be by = chance. OK, it sounds like testing is in order to make sure, but the probability = is greater than zero. It also sounds like I may be at least partially = sane. Thanks! --=20 Alan Amesbury University Information Security http://umn.edu/lookup/amesbury From owner-freebsd-stable@freebsd.org Wed Feb 3 23:15:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11954A9B939; Wed, 3 Feb 2016 23:15:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 DAFAA1C03; Wed, 3 Feb 2016 23:15:21 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id u13MsL71064482; Wed, 3 Feb 2016 16:54:21 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.48.132] (67-198-50-4.static.grandenetworks.net [67.198.50.4]) by mail.shrew.net (Postfix) with ESMTPSA id C270218C848; Wed, 3 Feb 2016 16:54:15 -0600 (CST) Message-ID: <56B285B0.8010306@shrew.net> Date: Wed, 03 Feb 2016 16:56:48 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: 10.2-RELEASE-p12 pf+GRE crashing Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Wed, 03 Feb 2016 16:54:21 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 03 Feb 2016 23:15:22 -0000 All, I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that I could avoid the local patching required to keep it up and running. Unfortunately, it crashes whenever I reload my pf firewall rule set. If I remove the GRE tunnel configurations from rc.conf, it happily reloads the rule set all day long. The kernel config is mostly GENERIC with the following additions ... # Packet Filter device pf # PF OpenBSD packet-filter firewall device pflog # Logging support interface for PF device pfsync # Synchronization interface for PF device carp # Common Address Redundancy Protocol # IPsec device crypto device enc options IPSEC The crash is easy to reproduce as pfctl -f /etc/pf.conf does it every time. I should also mention that I tried with and without the following additional commits applied, but get the same result ... https://svnweb.freebsd.org/base?view=revision&revision=272695 https://svnweb.freebsd.org/base?view=revision&revision=288529 I'm also a bit confused as to why these patches haven't made it into 10 STABLE yet. The former doesn't mention an MFC and the latter has an MFC of 1 week, but was never done. In any case, here is the output from kgdb ... [root@fw2 /var/crash]# kgdb /boot/kernel/kernel vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4a4 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff809c07f4 stack pointer = 0x28:0xfffffe0000233b30 frame pointer = 0x28:0xfffffe0000233b40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1990 (pfctl) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff808048c0 at kdb_backtrace+0x60 #1 0xffffffff807c8596 at vpanic+0x126 #2 0xffffffff807c8463 at panic+0x43 #3 0xffffffff80bdc10b at trap_fatal+0x36b #4 0xffffffff80bdc40d at trap_pfault+0x2ed #5 0xffffffff80bdbaaa at trap+0x47a #6 0xffffffff80bc1fa2 at calltrap+0x8 #7 0xffffffff809a91f4 at pf_empty_pool+0x44 #8 0xffffffff809ab3e5 at pfioctl+0x805 #9 0xffffffff806b5659 at devfs_ioctl_f+0x139 #10 0xffffffff8081b805 at kern_ioctl+0x255 #11 0xffffffff8081b500 at sys_ioctl+0x140 #12 0xffffffff80bdca27 at amd64_syscall+0x357 #13 0xffffffff80bc228b at Xfast_syscall+0xfb Uptime: 1m1s Dumping 156 out of 2025 MB:..11%..21%..31%..42%..52%..62%..72%..83%..93% Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/if_gre.ko.symbols...done. Loaded symbols for /boot/kernel/if_gre.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h Any help in resolving this would be greatly appreciated. -Matthew From owner-freebsd-stable@freebsd.org Thu Feb 4 00:47:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AB76A9B96F; Thu, 4 Feb 2016 00:47:36 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 2EA9E114A; Thu, 4 Feb 2016 00:47:35 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id u140ivuS065863; Wed, 3 Feb 2016 18:44:57 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.48.132] (67-198-50-4.static.grandenetworks.net [67.198.50.4]) by mail.shrew.net (Postfix) with ESMTPSA id E6C0018C85D; Wed, 3 Feb 2016 18:44:51 -0600 (CST) Message-ID: <56B29FA0.4080000@shrew.net> Date: Wed, 03 Feb 2016 18:47:28 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: 10.2-RELEASE-p12 pf+GRE crashing References: <56B285B0.8010306@shrew.net> In-Reply-To: <56B285B0.8010306@shrew.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Wed, 03 Feb 2016 18:44:57 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 00:47:36 -0000 On 2/3/2016 4:56 PM, Matthew Grooms wrote: > All, > > I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that > I could avoid the local patching required to keep it up and running. > Unfortunately, it crashes whenever I reload my pf firewall rule set. > If I remove the GRE tunnel configurations from rc.conf, it happily > reloads the rule set all day long. The kernel config is mostly GENERIC > with the following additions ... > > # Packet Filter > device pf # PF OpenBSD packet-filter firewall > device pflog # Logging support interface for PF > device pfsync # Synchronization interface for PF > device carp # Common Address Redundancy Protocol > > # IPsec > device crypto > device enc > options IPSEC > > The crash is easy to reproduce as pfctl -f /etc/pf.conf does it every > time. I should also mention that I tried with and without the > following additional commits applied, but get the same result ... > > https://svnweb.freebsd.org/base?view=revision&revision=272695 > https://svnweb.freebsd.org/base?view=revision&revision=288529 > > I'm also a bit confused as to why these patches haven't made it into > 10 STABLE yet. The former doesn't mention an MFC and the latter has an > MFC of 1 week, but was never done. In any case, here is the output > from kgdb ... This turned out to be another issue that was patched in head but not back ported to stable. I can't explain why it didn't get tripped when GRE tunnels were disabled. With the patch applied, I can reload my rule sets again without crashing ... https://svnweb.freebsd.org/base?view=revision&revision=264689 (kgdb) bt #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff807c81f2 in kern_reboot (howto=260) at ../../../kern/kern_shutdown.c:451 #2 0xffffffff807c85d5 in vpanic (fmt=, ap=) at ../../../kern/kern_shutdown.c:758 #3 0xffffffff807c8463 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:687 #4 0xffffffff80bdc10b in trap_fatal (frame=, eva=) at ../../../amd64/amd64/trap.c:851 #5 0xffffffff80bdc40d in trap_pfault (frame=0xfffffe0000233a80, usermode=) at ../../../amd64/amd64/trap.c:674 #6 0xffffffff80bdbaaa in trap (frame=0xfffffe0000233a80) at ../../../amd64/amd64/trap.c:440 #7 0xffffffff80bc1fa2 in calltrap () at ../../../amd64/amd64/exception.S:236 #8 0xffffffff809c07f4 in pfr_detach_table (kt=0x0) at ../../../netpfil/pf/pf_table.c:2047 #9 0xffffffff809a91f4 in pf_empty_pool (poola=0xffffffff813c3d68) at ../../../netpfil/pf/pf_ioctl.c:354 #10 0xffffffff809ab3e5 in pfioctl (dev=, cmd=, addr=0xfffff8005eaf6800 "", flags=, td=) at ../../../netpfil/pf/pf_ioctl.c:2189 #11 0xffffffff806b5659 in devfs_ioctl_f (fp=0xfffff8000a2927d0, com=3295691827, data=0xfffff8005eaf6800, cred=, td=0xfffff8000a25f000) at ../../../fs/devfs/devfs_vnops.c:785 #12 0xffffffff8081b805 in kern_ioctl (td=0xfffff8000a25f000, fd=, com=2) at file.h:320 #13 0xffffffff8081b500 in sys_ioctl (td=0xfffff8000a25f000, uap=0xfffffe0000234b40) at ../../../kern/sys_generic.c:718 #14 0xffffffff80bdca27 in amd64_syscall (td=0xfffff8000a25f000, traced=0) at subr_syscall.c:134 #15 0xffffffff80bc228b in Xfast_syscall () at ../../../amd64/amd64/exception.S:396 #16 0x0000000800dd9fda in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal -Matthew From owner-freebsd-stable@freebsd.org Thu Feb 4 01:22:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75956A9A667 for ; Thu, 4 Feb 2016 01:22:34 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 659839F5 for ; Thu, 4 Feb 2016 01:22:34 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: by mailman.ysv.freebsd.org (Postfix) id 6295FA9A666; Thu, 4 Feb 2016 01:22:34 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 620A0A9A665 for ; Thu, 4 Feb 2016 01:22:34 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 013E19F1 for ; Thu, 4 Feb 2016 01:22:33 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-70-178.lns20.adl6.internode.on.net (HELO leader.local) ([121.45.70.178]) by ipmail04.adl6.internode.on.net with ESMTP; 04 Feb 2016 11:45:59 +1030 Subject: Re: 10-STABLE hangups frequently To: Peter Jeremy References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> <20160203190323.GC78969@server.rulingia.com> Cc: stable@FreeBSD.org From: Shane Ambler Message-ID: <56B2A64C.3050107@ShaneWare.Biz> Date: Thu, 4 Feb 2016 11:45:56 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160203190323.GC78969@server.rulingia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 01:22:34 -0000 On 04/02/2016 05:33, Peter Jeremy wrote: > On 2016-Feb-03 18:23:13 +1030, Shane Ambler wrote: >> Any chance you get high wired allocations? > > A high wired allocation is normal for ZFS - ARC shows up as "wired" > memory. > >> Sometimes several times in a day I see the wired amount shown in top >> rise to over 6GB (of 8GB) bringing the system to a crawl. When wired >> gets over 7GB the system rarely recovers. > > The ARC limit defaults to 1GB less than physical RAM so 6GB wired on > an 8GB system isn't unexpected (my home system currently has 30GB > wired out of 32GB). If this is causing problems for your workload, it > sounds like you may need to explicitly reduce vfs.zfs.arc_max (note > that this is a soft limit). I have vfs.zfs.arc_max=2G - and now realise I also had set vfs.zfs.arc_min=500M some time ago. Don't recall where I got it but I also have vfs.zfs.dirty_data_max=200M Going by figures shown in top, ARC is usually in the 1500M to 2000M range but when wired gets over 6GB I often see ARC drop to 500MB which I now realise matches arc_min. When wired gets over 6GB apps start to stop responding, I then try to push out some wired by running a script that allocates 4G, 9 times out of 10 this drops wired to under 4GB and everything keeps working. If I notice wired over 7GB there's usually no recover. I don't always get to see the figures before it totally locks up. On desktop1 I leave a terminal running top and another ready to run my script to allocate some ram. When an app stops responding I go to desktop1 and depending on what I see I manually allocate some ram to flush things out. Currently I have an uptime of 9 days 9 hours - I have manually allocated 4GB 30 times in that time. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@freebsd.org Thu Feb 4 04:35:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65FA0A9B88B; Thu, 4 Feb 2016 04:35:44 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 61844B68; Thu, 4 Feb 2016 04:35:42 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-bfbff70000000a40-28-56b2d51659a8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 4A.63.02624.615D2B65; Wed, 3 Feb 2016 23:35:34 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u144ZXbu010626; Wed, 3 Feb 2016 23:35:34 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u144ZTMJ000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2016 23:35:33 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u144ZSTS007434; Wed, 3 Feb 2016 23:35:28 -0500 (EST) Date: Wed, 3 Feb 2016 23:35:28 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2015 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrSt2dVOYwcZ5Oha7rp1mt5jz5gOT xfbN/xgtDjcLObB4zPg0nyWAMYrLJiU1J7MstUjfLoErY/arhWwF645wVPRteMvawPjuElsX IyeHhICJRPuDo0xdjFwcQgJtTBKfbx2BcjYwSlw7sZ4NwjnIJDFh2R4mkBYhgXqJz5eegdks AloSvxu72UFsNgE1icd7m1khxipKbD41ibmLkYNDREBeYsF5e5Aws4C1xNx168FKhAXsJN51 /wW7glfAUWLzqv8sILaogI7E6v1TWCDighInZz5hgegNkNh84BLrBEb+WUhSs5CkIGwdiSkT VzBC2NoS92+2sS1gZFnFKJuSW6Wbm5iZU5yarFucnJiXl1qka66Xm1mil5pSuokRFLTsLio7 GJsPKR1iFOBgVOLhbfDcFCbEmlhWXJl7iFGSg0lJlDf1GFCILyk/pTIjsTgjvqg0J7X4EKME B7OSCG/IbqAcb0piZVVqUT5MSpqDRUmc14gfKCWQnliSmp2aWpBaBJOV4eBQkuCVvwKUFSxK TU+tSMvMKUFIM3FwggznARo++TLI8OKCxNzizHSI/ClGRSlx3qsgCQGQREZpHlwvOKnsZlJ9 xSgO9IowrzvICh5gQoLrfgU0mAlo8Gy+9SCDSxIRUlINjP35BsoXXCO82MJeFX3VFxV+ctzY UWgr29p9gjN/7hDbJirV+UllxoSr20tXpEmVdb4yfvT2Xnri3FWxqcsPrtqh9Oh6M4+zoW37 Biul5m2SogtU34mIrubvmPdHPI/X+e22mlnfMtbfOzld7+qOWfEnJiw5Inf3gORZ+zb2eesY X01cwbTptb0SS3FGoqEWc1FxIgAEFFpPBQMAAA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 04:35:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: October - December 2015 The fourth quarter of 2015 saw a great deal of activity for FreeBSD. This is now the third quarter running for which I can say that this is the largest report yet published! Many thanks to everyone who proactively submitted topics and entries -- it is great to have more complete coverage of ongoing development for the community to learn about in these reports. An experimental new Triage Team was formed this quarter to create a new way for community members to participate, and to improve issue management and productivity in general. Making more effective use of automation and tooling can help to increase developer productivity and the quality of FreeBSD, just as the adoption of Jenkins and continual integration tooling catches regressions quickly and maintains the high standards for the system. Efforts to bring our BSD high standards to new architectures continue, with impressive work on arm64 leading to its promotion to Tier-2 status and a flurry of work bringing up the new RISC-V hardware architecture. Software architecture is also under active development, including system startup and service management. A handful of potential init system replacements are mentioned in this report: launchd, relaunchd, and nosh. Architectural changes originating both from academic research (multipath TCP) and from the realities of industry (sendfile(2) improvements) are also under way. It is heartening to see how FreeBSD provides a welcoming platform for contributions from both research and industry. To all the readers, whether from academia or industry, hobbyist or professional: I hope you are as excited as I am to read about all of the progress and projects covered in this report, and the future of FreeBSD! --Ben Kaduk __________________________________________________________________ The deadline for submissions covering the period from January to March 2016 is April 7, 2016. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Issue Tracking (Bugzilla) * The FreeBSD Core Team * The FreeBSD Issue Triage Team Projects * CAM I/O Scheduler * Encrypted Kernel Crash Dumps * Jenkins Continuous Integration for FreeBSD * Mellanox iSCSI Extensions for RDMA (iSER) Support * MIPS: Ralink/Mediatek Support * Multipath TCP for FreeBSD * OpenBSM * Raspberry Pi: VideoCore Userland Application Packaging * RCTL Disk IO Limits * Root Remount * Routing Stack Update * The Graphics Stack on FreeBSD * The nosh Project * UEFI Boot and Framebuffer Support Kernel * Chelsio iSCSI Offload Driver (Initiator and Target) * FreeBSD Integration Services (BIS) * FreeBSD Xen * Improvements to the QLogic HBA Driver * iMX.6 Video Output Support * ioat(4) Driver Enhancements * Kernel Vnode Cache Tuning * Mellanox Drivers * Minimal Kernel with PNP-Based Autoloading * MMC Stack Under CAM Framework * ntb_hw(4)/if_ntb(4) Driver Synced up to Linux * Out of Memory Handler Rewrite * sendfile(2) Improvements * sysctl Enhancements * Touchscreen Support for Raspberry Pi and Beaglebone Black Architectures * armv6 Hard Float Default ABI * FreeBSD on Marvell Armada38x * FreeBSD on Newer ARM Boards * FreeBSD on SoftIron Overdrive 3000 * FreeBSD/arm64 * FreeBSD/RISC-V * Improvements for ARMv6/v7 Support Userland Programs * Base System Build Improvements * ELF Tool Chain Tools * The LLDB Debugger * Updates to GDB Ports * Bringing GitLab into the Ports Collection * GNOME on FreeBSD * IPv6 Promotion Campaign * KDE on FreeBSD * Linux Kernel as a Library Added to the Ports Collection * LXQt on FreeBSD * New Tools to Enhance the Porting Experience * Node.js Modules * Ports Collection * Supporting Variants in the Ports Framework * Xfce on FreeBSD Documentation * "FreeBSD Mastery: Specialty Filesystems" Early Access Version Now Available * style(9) Enhanced to Allow C99 bool Miscellaneous * HardenedBSD * NanoBSD Modernization * relaunchd * System Initialization and Service Management * The FreeBSD Foundation __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 10.3-RELEASE schedule URL: https://www.freebsd.org/releases/10.3R/schedule.html FreeBSD Development Snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. During the last quarter of 2015, the Release Engineering team added support for three additional FreeBSD/arm systems: BANANAPI, CUBIEBOARD, and CUBIEBOARD2. In addition to regular development snapshot builds for FreeBSD 11.0-CURRENT and FreeBSD 10.2-STABLE, several changes and enhancements were made to the release build code. Of note, the release build code no longer produces MD5 checksums, in favor of SHA512. Toward the end of the year, focus was primarily centered on the upcoming FreeBSD 10.3 release cycle, which will begin in January 2016. As always, help testing development snapshot builds is crucial to producing quality releases, and we encourage testing development snapshots whenever possible. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Issue Tracking (Bugzilla) Links Bugzilla Home Page URL: https://bugs.freebsd.org/bugzilla/ Contact: Bugmeisters Contact: Kubilay Kocak Contact: Mahdi Mokhtari The bugmeister team has gained a new member, Mahdi Mokhtari (mokhi64@gmail.com). Mahdi has been contributing to the FreeBSD Project for just over one month. After getting started by creating ports for Chef-Server and MySQL 5.7 (with Bernard Spil's help), an introduction to Kubilay Kocak led to guidance on appropriate projects, such as Bugzilla development to help Bugmeister, the Bugzilla Triage team, Developers, and the community by making issue tracking better. This is how things are going so far: Issue Tracking can be either "Defect Tracking for Systems" or "Bug-Tracking for Systems". System Defect Tracking is to allow individual or groups of developers to keep track of outstanding issues in their product effectively. We use Bugzilla to manage issues for the FreeBSD project. We are pleased to announce some developments on our issue management systems: * We have made improvements to the AutoAssigner module (not yet deployed) that was previously developed by Marcus von Appen to assign port bugs to their maintainers by default, such as: + Improvements and bugfixes to port detection in the Summary: field of issues, for automatic assignment to their maintainers in a better way. + Refactoring code to make future development easier and faster in a more modular way. * We have developed a new module (FBSDAttachment), which automates setting maintainer-approval flag values on attachments under most conditions. This will improve time to resolution, consistency of triage, and reduce manual effort by triagers and maintainers. * We reported and upstreamed a number of bugs in Bugzilla, working with the upstream Bugzilla developers. Open tasks: 1. Major improvements to templates for usability and simplicity. 2. Further improvements to automation (for example, additional processing of commit logs). __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team Two major issues have occupied much of core's attention during the last quarter: the reorganisation of the Security Team and the question of whether to import GPLv3 licensed code into the source repository. 1. The idea of reorganizing the Security team was first proposed to Core during a meeting at BSDCan this year by Gleb Smirnoff -- core member and newly-appointed deputy Security Officer (SO). The "Security Team", which previously could contain several people (a varying number over time, but more than two) has been refashioned into just two roles: Security Officer and Deputy Security Officer. Accordingly, the role of the SO team has been redefined to be the controller of the distribution of security sensitive information into and within the project: they are responsible for interfacing with external bodies and individuals reporting security problems to the project, and connecting those reports to the appropriate individuals within the project with the technical expertise to address the identified concerns. These changes will improve the project's responsiveness to security alerts, help maintain security on privileged information received in confidence before general publication and, not least, reduce the work load on the security officer. The SO team will continue to benefit from liasons with the Core, Cluster Administration, and Release Engineering teams, and will be assisted by a secretary; they will also be able to obtain input and assistance in drafting security advisories from former and potential future (Deputy) Security Officers. Core would particularly like to thank the former members of the Security Team group for their past contributions, now that the Security Team role has been merged into the Security Officer's responsibilities. 2. The other large question concerning Core is how to provide a modern toolchain for all supported achitectures. Tier 1 architectures are required to ship with a toolchain unencumbered by onerous license terms. This is currently provided for i386 and arm64 by the LLVM suite, including the Clang compiler, LLD and LLDB. However LLVM support for other (Tier 2 or below) architectures is not yet of sufficient quality to be viable, and the older but pre-existing GPLv2 toolchain cannot support some of the interesting new architectures such as arm64 and RISC-V. Pragmatically, in order for the project to support these architectures, until LLVM support arrives we must turn to the GNU project's GPLv3 licenced toolchain. The argument here is whether to import GPLv3 licensed code into the FreeBSD src repository with all of the obligations on patent terms and source code redistribution that would entail, not only for the FreeBSD project itself but for numerous downstream consumers of FreeBSD code. Not having a toolchain readily available is a big impediment to working on a new architecture. One potential solution is to create a range of "GPLv3 toolchain" base-system packages out of a completely separate source code repository, for instance within the FreeBSD area on Github. These would be distributed equivalently to the other base system binary packages when that mechanism is introduced. Core recognises that this is a decision with wide-ranging consequences and will be producing a position paper for circulation amongst all interested parties in order to judge community opinion on the matter. Core welcomes feedback from all interested parties on the subject. Beyond these two big questions, Core has handled a number of other items: * Core approved the formation of a wiki-admin team to take over managing the Wiki, to curate the Wiki content and work on navigation and organization of existing technical content and to evaluate new Wiki software with the aim of opening up the Wiki to contributions from the public. * An external review board has been assembled to look at the Code of Conduct, including a mixture of project members and experts from external groups. The review process is getting under way and Core is awaiting their report. * The standard documentation license was found to be unfit for its purpose, and the doceng group had temporarily reverted to the previous license while a new replacement was drafted. This new license is now the default for new documentation submissions. However, one factor emerging from this review was the difficulty of maintaining correct authorial attributions for sections of documentation, some of which may only be a few words long. Unlike source code, blocks of documentation are frequently moved around within individual files, or even between files. Consequently, Core would like to introduce a Voluntary Contribution Agreement along the lines of the one operated by the Apache Foundation. With this, copyrights are signed over to the FreeBSD Foundation, with individual contributions being recognised by recording names in a general "Authors" file. This will be another alternative alongside the existing copyright mechanisms used in the project. Core is interested to hear any opinions on the subject. * Core approved the formation of a new "dev-announce" mailing list, which all FreeBSD committers should be members of. This will be a low-traffic moderated list to contain important announcements, heads-ups, warnings of code freezes, changes in policy and notifications of events that affect the project as a whole. * Around eight years ago, an attempt was made to import the OpenBSD sensors framework. This was rejected at the time as potentially blocking the development of a better designed framework. However, no such development has occurred in the intervening time whilst the sensors framework has been in use successfully by both OpenBSD and FreeNAS. Despite some concerns about the efficiency of the framework and potential impacts on power consumption and hence battery lifetime, core is minded to approve the import, but wants to consult with interested developers first. * Core is exploring the legal ramifications for the project of the "Right to Be Forgotten" established by the European Court of Justice. * Core is also seeking an alternative means for holding their regular monthly conference calls. The current, paid-for, service has less than satisfactory sound quality and reliability, and Core would like to switch to a free video conferencing solution. This quarter also saw a particularly large influx of new commit bit requests, with on occasion, four votes running simultaneously. Please welcome Kurt Lidl, Svatopluk Kraus, Michal Meloun, Jonathan Looney (Juniper), Daisuke Aoyama, Phil Shafer (Juniper), Ravi Pokala (Panasas), Anish Gupta and Mark Bloch (Mellanox) to the ranks of src committers. In addition, core was delighted to restore commit privileges for Eric Melville after a hiatus of many years. No commit bits were taken in during the quarter. A non-committer account was approved for Kevin Bowling of LimeLight Networks. Kevin will be doing systems administration work with clusteradm, with particular interest in the parts of the cluster that are now hosted in LLNW's facilities. Deb Goodkin of the FreeBSD Foundation was added to the developers mailing list: she was one of the few members of the Foundation Board not already on the list, and having awareness of what is going on in the developer community will help her to support the project more effectively. __________________________________________________________________ The FreeBSD Issue Triage Team Contact: Bugmeister Contact: Kubilay Kocak Contact: Vladimir Krstulja Contact: Rodrigo N. Hernandez By the end of the Q4 2015 period, Kubilay Kocak (koobs@) started an initiative to form an experimental Bugzilla Triage Team. The main goals of the team are to increase community involvement (addition/training of new triagers) and enhance current procedures and tools, among others. This experiment was started with the participation of Vladimir (blackflow on irc/freenode) and Rodrigo (DanDare on irc/freenode), who approached koobs@ with a desire to contribute and get more involved with the FreeBSD Project. This experimental pilot project has the task of setting up procedures for enhanced Issue (Problem Report) management that include better classification and prioritization, eventually leading to faster resolution of issues. We are now happy to report on the progress of this experimental team: * The #FreeBSD-bugs IRC channel has been set up on Freenode and we are successfully using it to exchange information about triage processes, ask for help, propose changes and discuss related topics. * We have identified the primary role of an Issue Triage Team to be that of classification of problem reports of all kinds (currently limited mostly to ports and obvious src issues) and facilitation of issue assignment, which is making sure that the reported issues are explained well, contain all the appropriate information (or as much of it as possible), and are brought to attention of the people who can act upon them. * Vladimir and Rodrigo are successfully training in bug triage as well as porting processes (Vladimir is also taking maintainership of some ports). * This experiment is benefiting from the introduction of newcomers to issue tracking. It naturally resulted in a entire review of the tracking process from its very elementary aspects. This "fresh eyes" participation spotted minor details during the process, giving the opportunity to scrutinize actual procedures on a number of smaller points, followed by proposals on how to improve the overall Issue Tracking and Management. The new ideas include both organizational and technical ideas and solutions, such as new or modified keywords or flags for better classification, the triage workflow, and Bugzilla technical improvements, among others. * An important goal is producing documentation about best practices for using Bugzilla and issue management workflow. This documentation should be aimed not only at people directly engaged in issue triage tasks, but also at general users. Another relevant point is that feedback from the triage team can be used to improve Bugzilla in terms of adjusting existing features to best fit FreeBSD's needs, and the development of new features (please see Mahdi "Magic" Mokhtari's report on "Bugzilla improvements"). * We are still collating ideas in preparation of setting up a Wiki namespace for the overall topic of issue management, containing information for all the parties involved in issue tracking: from users (reporters) to maintainers and committers. The unorganized brainstorming document is linked in this report. Since the Issue Triage Team is very young, we expect more information be available and more actions to be reported in the next status report. Open tasks: 1. Set up the Wiki namespace and organize the brainstorming document into a meaningful set of documents. 2. We are actively recruiting to grow our FreeBSD Triage Team. If you are interested in participating and contributing to one of the most important community-facing areas of the FreeBSD project, join #freebsd-bugs on the freenode IRC and let us know! Experience with issue tracking is desirable, but not required. No prior internal project knowledge or technical skills are required, just bring your communication skills and awesome attitude. Training is provided. __________________________________________________________________ CAM I/O Scheduler Links BSDCan Paper URL: https://people.FreeBSD.org/~imp/bsdcan2015/iosched-v3.pdf Phabricator Review URL: https://reviews.FreeBSD.org/D4609 Contact: Warner Losh Reviews have begun on the CAM I/O scheduler that I wrote for Netflix. It is anticipated that this process will be done in time for the FreeBSD 11 branch. Details about this work can be found in the linked BSDcan paper from last year. Briefly, the scheduler allows one to differentiate I/O types and limit I/O based on the type and characteristics of the I/Os (including the latency of recent requests relative to historical averages). This is most useful when tuning system loads to SSD performance. Both a simple default scheduler, the same that we use today in FreeBSD, as well as a scheduler that can be well-tuned for system loads related to video streaming will be included. This project is sponsored by Netflix, Inc. __________________________________________________________________ Encrypted Kernel Crash Dumps Links Technical Details URL: https://lists.FreeBSD.org/pipermail/freebsd-security/2015-December= /008780.html Patch Review URL: https://reviews.FreeBSD.org/D4712 Contact: Konrad Witaszczyk Kernel crash dumps contain information about currently running processes. This can include sensitive data, for example passwords kept in memory by a browser when a kernel panic occurred. An entity that can read data from a dump device or a crash directory can also extract this information from a core dump. To prevent this situation, the core dump should be encrypted before it is stored on the dump device. This project allows a kernel to encrypt a core dump during a panic. A user can configure the kernel for encrypted dumps and save the core dump after reboot using the existing tools, dumpon(8) and savecore(8). A new tool decryptcore(8) was added to decrypt the core files. A patch has been uploaded to Phabricator for review. The patch is currently being updated to address the review comments, and should be committed as soon as it is accepted. For more technical details, please visit the FreeBSD-security mailing list archive or see the Phabricator review. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD Links The Jenkins CI Server in the FreeBSD Cluster URL: https://jenkins.FreeBSD.org Portest Script URL: https://github.com/Ultima1252/portest Jenkins Workflow Plugin URL: https://github.com/jenkinsci/workflow-plugin Cloudbees URL: https://cloudbees.com Jenkins Phabricator Plugin URL: https://github.com/uber/phabricator-jenkins-plugin Phabricator Plugin Fixes URL: https://github.com/uber/phabricator-jenkins-plugin/pull/110 Durable Task Plugin Fixes URL: https://github.com/jenkinsci/durable-task-plugin/pull/14 Clang Scanbuild Plugin Fixes URL: https://github.com/jenkinsci/clang-scanbuild-plugin/commits/master Multiple SCMs Plugin Fixes URL: https://github.com/jenkinsci/multiple-scms-plugin/commits/master SCM Sync Configuration Plugin Fixes URL: https://github.com/jenkinsci/scm-sync-configuration-plugin/commits= /master Porting Jobs to the Workflow Plugin URL: https://lists.FreeBSD.org/pipermail/freebsd-testing/2016-January/0= 01285.html Akuma Fixes for FreeBSD URL: https://github.com/kohsuke/akuma/pull/9 Kyua Fix for Invalid Characters URL: https://github.com/jmmv/kyua/pull/148 Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing The Jenkins Continuous Integration and Testing project has been helping to improve the quality of FreeBSD. Since the last status report, we have quickly found commits that caused build breakage or test failures. FreeBSD developers saw these problems and quickly fixed them. Some of the highlights include: * Ricky Gallagher wrote a script named portest, which can take a patch to the FreeBSD ports tree as input, and can generate a sequence of commands to check out the ports tree from Subversion, apply the patch, and then invoke poudriere to build the affected part of the ports tree. Ricky consulted with Torsten Z=FChlsdorff during its development. This script will be used later to test changes to the ports tree. * Craig Rodrigues converted some Jenkins builds to use the Workflow plugin. Workflow is a plugin written by Jesse Glick and other developers at Cloudbees, the main company providing commercial support for Jenkins. With this plugin, a Jenkins job can be written in a Domain Specific Language (DSL) which is written in the Groovy scripting language. Workflow scripts are meant to provide sophisticated access to Jenkins functionality, in a simple scripting language. As Jenkins jobs get more complicated and have more interdependencies, using a DSL is easier for maintainability instead of creating Jenkins jobs via menus. Craig Rodrigues worked with Jesse Glick to identify and fix a problem with the Durable Task plugin used by the workflow plugin. This problem seemed to show up mostly on non-Linux platforms such as OS X and FreeBSD. * Eitan Adler worked with Craig Rodrigues to test a Jenkins plugin written by Aiden Scandella at Uber which integrates Phabricator and Jenkins. With this plugin, if someone submits a code review with Phabricator's Differential tool, a Jenkins build with this code change will be triggered. The Phabricator code review would then be updated with the result of the build. Eitan Adler and Craig Rodrigues had some initial success testing this plugin using the FreeBSD docs repository, but this plugin still has a lot of hardcoded dependencies specific to Uber's environment which make it difficult to use out-of-the-box for FreeBSD. Alexander Yerenkow submitted some patches upstream to fix some of these problems, but this plugin still needs more work. Craig Rodrigues thinks that it might be better to write a workflow script to call Phabricator commands directly. * Craig Rodrigues pushed fixes upstream to several plugins including: + SCM Sync configuration plugin + NodeLabel parameter plugin + Subversion plugin + Multiple SCMs plugin + Clang Scanbuild plugin Craig Rodrigues was granted commit access to the SCM Sync configuration plugin, Multiple SCMs plugin, and Clang Scanbuild plugin. * Li-Wen Hsu set up multiple builds using jails on machines located at NYI and administered by the FreeBSD Cluster Administrators. One of these builds targets 64-bit ARM. * Michael Zhilin fixed the Akuma library for FreeBSD. The Akuma library is used by Jenkins to determine what command-line arguments were passed to a running process. To fix it, Michael invoked an FreeBSD-specific sysctl() with KERN_PROC_ARGS to determine the arguments for a running pid. This fix allows a running Jenkins instance to restart itself after new plugins are installed. * Julio Merino accepted a fix for Kyua from Craig Rodrigues to fix writing out XML characters to test report files. Open tasks: 1. Work more on using the workflow plugin for various builds. 2. Set up a build to test bmake's meta-mode. 3. Finish off integration with Phabricator. 4. People interested in helping out should join the freebsd-testing@FreeBSD.org list. __________________________________________________________________ Mellanox iSCSI Extensions for RDMA (iSER) Support Links GitHub repository URL: https://github.com/sagigrimberg/iser-FreeBSD Contact: Max Gurtovoy Contact: Sagi Grimberg Building on the new in-kernel iSCSI initiator stack released in FreeBSD 10.0 and the recently added iSCSI offload interface, Mellanox Technologies has developed iSCSI extensions for RDMA (iSER) initiator support to enable efficient data movement using the hardware offload capabilities of Mellanox's 10, 40, 56, and 100 Gigabit Infiniband (IB)/Ethernet adapters. Remote Direct Memory Access (RDMA) has been shown to have great value for storage applications. RDMA infrastructure provides benefits such as zero-copy, CPU offload, reliable transport, fabric consolidation, and many more. The iSER protocol eliminates some of the bottlenecks in the traditional iSCSI/TCP stack, provides low latency and high throughput, and is well suited for latency aware workloads. This work includes a new ICL module that implements the iSER initiator. The iSCSI stack is slightly modified to support some extra features such as asynchronous IO completions, unmapped data buffers, and data-transfer offloads. The user will be able to choose iSER as the iSCSI transport with iscsictl. The project is in the process of being merged to FreeBSD 11-CURRENT and is expected to ship with FreeBSD 11.0. This project is sponsored by Mellanox Technologies. __________________________________________________________________ MIPS: Ralink/Mediatek Support Links Github Branch With Work in Progress URL: https://github.com/sgalabov/FreeBSD/tree/local/sgalabov_mtk Contact: Stanislav Galabov This project is aimed at adding FreeBSD support for Ralink/Mediatek's family of WiFi router system-on-chip (SoC) devices based on MIPS processors. These SoCs are commonly found in embedded network devices such as WiFi routers. Having support for these SoCs would allow FreeBSD to run on a number of additional low-cost devices, which could help spread FreeBSD's popularity in the embedded systems world. The project currently aims to support the following Ralink/Mediatek chipsets: RT3050, RT3052, RT3350, RT3352, RT3662, RT3883, RT5350, RT6855, RT6856, MT7620, MT7621, MT7628 and MT7688. The following functionality (where applicable) is currently planned to be supported: Interrupt controller, UART, GPIO, USB, PCI/PCIe, Ethernet, and SPI. This project is sponsored by Smartcom - Bulgaria AD. Open tasks: 1. Help with adding WiFi driver support (possibly to ral(4)) for the above SoCs would be greatly appreciated. 2. Help with refactoring if_rt(4) to be usable on all of the above SoCs would be appreciated. 3. Help wth testing target boards (e.g., WiFi routers) would be appreciated. __________________________________________________________________ Multipath TCP for FreeBSD Links MPTCP for FreeBSD Repository URL: https://bitbucket.org/nw-swin/caia-mptcp-freebsd/ MPTCP for FreeBSD Project Website URL: http://caia.swin.edu.au/urp/newtcp/mptcp/ Contact: Nigel Williams Multipath TCP (MPTCP) is an extension to TCP that allows for the use of multiple network interfaces on a standard TCP session. The addition of new addresses and scheduling of data across these occurs transparently from the perspective of the TCP application. The goal of this project is to deliver an MPTCP kernel patch that interoperates with the reference MPTCP implementation, along with additional enhancements to aid network research. A v0.51 release has been tagged in our repository, with some minor improvements over v0.5. We have now removed much of the MPTCP code that was inside the functions tcp_do_segment, tcp_output, and other code used for standard TCP connections. The goal of this is to restrict the added MPTCP code to just MPTCP connections, leaving regular TCP connections using the existing code. We are currently in the process of implementing a subflow socket buffer upcall and event processing. These will handle changes in subflow socket state, MP-signalling, and incoming data segments. This also requires some re-working of the MP option processing, particularly how incoming DSN maps are parsed and stored for use during MP-layer reassembly. We are also looking at how our changes might take advantage of the new TCP stack modularisation enhancements to create subflow-specific TCP functions. This project is sponsored by The Cisco University Research Program Fund at Community Foundation Silicon Valley, and The FreeBSD Foundation. Open tasks: 1. Complete the implementations of subflow event processing and new option parsing. 2. Update documentation and task lists. __________________________________________________________________ OpenBSM Links OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation URL: http://www.openbsm.org OpenBSM on GitHub URL: https://github.com/openbsm/openbsm FreeBSD Audit Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/audit.h= tml Contact: Christian Brueffer Contact: Robert Watson Contact: TrustedBSD audit mailing list OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the user-space side of the CAPP Audit implementations in FreeBSD and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux. Progress has been slow but steady this quarter, culminating in OpenBSM 1.2 alpha 4, the first release in three years. It features various bug fixes and documentation improvements; the complete list of changes is documented in the NEWS file on GitHub. The release was imported into FreeBSD head and merged to FreeBSD 10-STABLE. As such, it will be part of FreeBSD 10.3-RELEASE. Open tasks: 1. Test the new release on different versions of FreeBSD, Mac OS X, and Linux. In particular, testing on Mac OS X 10.9 (Mavericks) and newer would be greatly appreciated. 2. Fix problems that have been reported via GitHub and the FreeBSD bug tracker. 3. Implement features mentioned in the TODO list on GitHub. __________________________________________________________________ Raspberry Pi: VideoCore Userland Application Packaging Contact: Mika=EBl Urankar Contact: Oleksandr Tymoshenko The Raspberry Pi SoC consists of two parts: ARM and GPU (VideoCore). Many interesting features like OpenGL, video playback, and HDMI controls are implemented on the VideoCore side and can be accessed from the OS through libraries provided by Broadcom (userland repo). These libraries were ported to FreeBSD some time ago, so Mika=EBl created the port misc/raspberrypi-userland for them. He also created a port for omxplayer (a low-level video player that utilizes VideoCore APIs) and is working on a port for Kodi (formerly XBMC), a more user-firendly media player software with Raspberry Pi support. __________________________________________________________________ RCTL Disk IO Limits Contact: Edward Tomasz Napierala An important missing piece of the RCTL resource limits mechanism was the ability to limit disk throughput. This project aims to fill that hole by making it possible to add RCTL rules for read bytes per second (BPS), write BPS, read I/O operations per second (IOPS), and write IOPS. It also adds a new throttling mechanism to delay process execution when a limit is reached. The project is at the late implementation stage. The major piece of work left apart from testing is to integrate it with ZFS. The project is expected to ship with FreeBSD 11.0. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Root Remount Links Commit to Head URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290548 reboot(8) Manual Page Changes URL: https://svnweb.freebsd.org/base/head/sbin/reboot/reboot.8?r1=3D290= 548&r2=3D290547&pathrev=3D290548 Contact: Edward Tomasz Napierala One of the long-missing features of FreeBSD was the ability to boot up with a temporary rootfs, configure the kernel to be able to access the real rootfs, and then replace the temporary root with the real one. In Linux, this functionality is known as pivot_root. The reroot projects provides similar functionality in a different, slightly more user-friendly way: rerooting. Simply put, from the user point of view it looks like the system performs a partial shutdown, killing all processes and unmounting the rootfs, and then partial bringup, mounting the new rootfs, running init, and running the startup scripts as usual. The project is finished. All the relevant code has been committed to FreeBSD 11-CURRENT and is expected to ship with FreeBSD 11.0. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Routing Stack Update Links Initial Proposal URL: http://wiki.freebsd.org/ProjectsRoutingProposal Contact: Alexander Chernikov The projects/routing Subversion branch is a FreeBSD routing system rework aimed at providing performance, scalability and the ability to add advanced features to the routing stack. The current packet output path suffers from excessive locking. Acquiring and releasing four distinct contested locks is required to convert a packet to a frame suitable to put on the wire. The first project goal is to reduce the number of locks needed to just two rmlock(9)s for the output path, which permits close-to-linear scaling. Since September, one of the locks (used to protect link-level entries) has been completely eliminated from the packet data path. A new routing API was introduced, featuring better scalability and hiding routing internals. Most of the consumers of the old routing API were converted to use the new API. __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics Stack Roadmap and Supported Hardware Matrix URL: https://wiki.FreeBSD.org/Graphics Ports Development Tree on GitHub URL: https://github.com/FreeBSD/freebsd-ports-graphics Contact: FreeBSD Graphics team Several important ports were updated: Mesa to 11.0.8, the X.Org server to 1.17.4, libdrm to 2.4.65, as well as many applications and libraries. The latest release of the X.Org server, 1.18, is being tested in our Ports development tree. On the kernel side, the i915 update is almost ready to land. There are a couple known regressions for currently supported GPUs that we want to fix before committing. We started a discussion on the FreeBSD-x11@ mailing list to organize future contributions to the kernel drivers. We have already received some valuable comments. We are confident that future updates will happen at a faster pace, thanks to several motivated people! FOSDEM is held in Brussels on the 30th and 31st of January. We will attend this conference. It will be a perfect time to see people again from FreeBSD and from the XDC. On Sunday, we will give a talk about how to contribute to the Graphics Stack. Our blog is currently down because the service was discontinued. We hope to get a dump of our data to put it back online elsewhere. Unfortunately, there is no ETA for this item. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ The nosh Project Links Introduction URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh.html FreeBSD binary packages URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh/freebsd-binary-packages.html Installation How-To URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh/timorous-admin-installation-how-to.html Roadmap URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh/roadmap.html Commands URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh/commands.html A Slightly Outdated User Guide URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/no= sh/guide/index.html The Supervision Mailing List URL: https://www.mail-archive.com/supervision@list.skarnet.org/ Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems, and for managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d system, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It comprises a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. Since the last status report, in October 2015, the project has seen: the complete replacement of its event-handling subsystem on Linux; the introduction of tools for exporting cyclog/multilog logs via RFC 5426 to remote log handlers (such as logstash); and the switching of the user-mode virtual terminal subsystem on BSD to using USB devices directly, a more powerful device interface than sysmouse et al. because it permits directly positioning touch devices for mice and other things (thus permitting "mouse integration" under VirtualBox for those who run PC-BSD/FreeBSD on VirtualBox virtual machines), but sysmouse et al. can still be used if desired. In version 1.24, released shortly before publication of this report, there are extensive additions for supporting a purely-ZFS system with an empty /etc/fstab (as the PC-BSD 10.2 system installer creates), and the ability to convert systemd unit files' process priority settings to BSD's rtprio/idprio. Version 1.24 also sees a large chunk taken out of the remainder of the on-going project to create enough native service bundles and ancillary utilities to entirely supplant the rc.d system. The progress of this project has been open from the start, and can be followed on the nosh roadmap web page. As of version 1.24, there are a mere 27 items remaining out of the original target list of 157, with a 28th and a 29th (from PC-BSD 10.2) added. Items crossed off by version 1.24 include (amongst others) mfs support for /tmp, static ARP and networking, persistent entropy for the randomness subsystem, pefs, and hald. The remaining items in the task list are mostly aimed at making the overall system integration cleaner and friendlier to modern systems. We are also interested in receiving suggestions, bug reports, and other feedback from users. Try following the how-to guide and see how things go! Open tasks: 1. Add kernel support for passing a -b option to PID 1, and support for a boot_bare variable in the loader, to allow "emergency" (where no shell dotfiles are loaded) and "rescue" mode bootstraps, akin to Linux. (History: the -b mechanism and idea date back to version 2.57d of Miquel van Smoorenburg's System 5 init clone, dated 1995-12-03, and was already known as "emergency boot" by 1997.) 2. Add support to FreeBSD's fsck(8) for outputting machine-readable progress reports to a designated file descriptor, so that nosh can provide progress bars for multiple fscks running in parallel. nosh already provides this functionality on Linux, where fsck(8) does provide machine-readable output. 3. Identify when the configuration import system needs to be triggered, such as when bsdconfig alters configuration files, and create the necessary hooks to import external configuration changes into nosh. __________________________________________________________________ UEFI Boot and Framebuffer Support Contact: Ed Maste A number of UEFI bug fixes were committed over the last quarter, further improving compatibility with different UEFI implementations. Specifically: on some implementations, FreeBSD failed to boot with an "ExitBootServices() returned 0x8000000000000002" error. This has been fixed with a retry loop (as required by UEFI) in r292515 and r292338. UEFI improvements from other developers have recently been committed or are in progress. These include support for environment variables set on the EFI loader command line, improved text console mode setting, support for nvram variables, and root-on-ZFS support. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Test FreeBSD-CURRENT snapshots on a variety of UEFI implementations. 2. Merge UEFI changes to stable/10 for FreeBSD 10.3-RELEASE. __________________________________________________________________ Chelsio iSCSI Offload Driver (Initiator and Target) Links Commit Adding Hardware Acceleration Support URL: https://svnweb.freebsd.org/changeset/base/292740 Contact: Navdeep Parhar A new driver, cxgbei, enabling hardware accelerated iSCSI with Chelsio's T5- and T4-based offload-capable cards, has been committed to head. Both Initiator and Target are supported. The wire traffic is standard iSCSI (SCSI over TCP as per RFC 3720, etc.) so an Initiator/Target using this driver will interoperate with all other standards-compliant implementations. Hardware assistance provided by the T5 and T4 ASICs includes: * Complete TCP processing. * iSCSI PDU identification and extraction from the byte oriented TCP stream. * Header and/or data digest generation and verification. * Zero copy support for both transmit and receive. This project is sponsored by Chelsio Communications. Open tasks: 1. The cxgbei(4) man page is missing but will be committed shortly. 2. The driver is in advanced stage QA and will see some bugfixes and performance enhancements in the very near future. MFC is possible as soon as the QA cycle completes. __________________________________________________________________ FreeBSD Integration Services (BIS) Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Linux and FreeBSD Virtual Machines on Hyper-V URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Dexuan Cui Contact: Hongjiang Zhang When FreeBSD virtual machines (VMs) run on Hyper-V, using Hyper-V synthetic devices is recommended to get the best network and storage performance and make full use of all the benefits that Hyper-V provides. The collection of drivers that are required to run Hyper-V synthetic devices in FreeBSD are known as FreeBSD Integration Services (BIS). Some of the BIS drivers (like network and storage drivers) have existed in FreeBSD 9.x and 10.x for years, but there are still some performance and stability issues and bugs. Compared with Windows and Linux VMs, the current BIS lacks some important features, such as virtual Receive Side Scaling (vRSS) support in the Hyper-V network driver and support for UEFI VM (boot from UEFI), among others. We are now working more on the issues and performance tuning to make FreeBSD VMs run better on Hyper-V and the Hyper-V based cloud platform Azure. Our work during 2015Q4 is documented below: * Optimizing the VMBus driver and Hyper-V network driver for performance: + Sent out patches to enable INTR_MPSAFE for the interrupt handling thread, speed up relid-to-channel lookup in the thread by map table, and optimize the VMBus ringbuffer writable notification to the host. + Developing a patch to enable the virtual Receive Side Scaling (vRSS) for Hyper-V network device driver. This will greatly improve the network performance for SMP virtual machine (VM). + Sent out a patch to enable the Hyper-V timer, which will improve the accuracy of timekeeping when FreeBSD VMs run on Hyper-V. * Fixing bugs and cleaning up the code: + Fixed a bug in checksum offloading (PR 203630 -- [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver) in the Hyper-V network driver, making FreeBSD VM based NAT gateways work more reliably. + Fixed a serialization issue in the initialization of VMBus devices, fixing PR 205156 ([Hyper-V] NICs' (hn0, hn1) MAC addresses can appear in an uncertain way across reboot). + Fixed a KVP (Key-Value Pair) issue (retrieving a key's value can hang for an uncertain period of time). + Added ioctl support for SIOCGIFMEDIA for the Hyper-V network driver, fixing PR 187006 ([Hyper-V] dynamic address (DHCP) obtaining does not work on HYPER-V OS 2012 R2). + Sent out patches to add an interrupt counter for Hyper-V VMBus interrupts (so the user can easily get statistical information about VMBus interrupts), and fix the KVP daemon's poll timeout (so the daemon will avoid unnecessary polling every 100 milliseconds. + Identified a TSC calibration issue: the i8254 PIT timer emulation of Hyper-V is not fully reliable, so the Hyper-V time counter should be used to calibrate the TSC. A patch was drafted. With the patch, it looks the warning kernel message (e.g., "calcru: runtime went backwards from 46204978 usec to 23362331 usec for pid 0 (kernel)") will go away, and the time-based tracing of Dtrace will be more accurate. * We plan to add support for UEFI VMs (Hyper-V Generation-2 VMs). Currently some issues and to-do items were identified. For example, we cannot use the i8254 PIT to calibrate the TSC because the i8254 PIT does not exist in a UEFI VM, and we need to add support for the Hyper-V synthetic keyboard/mouse/framebuffer device. * We are working on a disk detection issue: when a FreeBSD VM runs on a Windows Server 2016 Technical Preview host, the VM will detect 16 disks when only one disk is configured for the VM. VMs running on these hosts can fail to boot. A workaround patch was created and we are trying to make a formal fix. * We are tidying up some internal BIS test cases and plan to publish them on github. This project is sponsored by Microsoft. __________________________________________________________________ FreeBSD Xen Links FreeBSD PVH DomU Wiki Page URL: http://wiki.xen.org/wiki/FreeBSD_PVH FreeBSD PVH Dom0 Wiki Page URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 FreeBSD/Xen HVMlite Implementation URL: http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Ds= hortlog;h=3Drefs/heads/new_entry_point_v5 Contact: Roger Pau Monn=E9 Contact: Wei Liu Xen is a hypervisor using a microkernel design, providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen support for FreeBSD on x86 as a guest was introduced in version 8, and ARM support is currently being worked on. Support for running FreeBSD as an amd64 Xen host (Dom0) is available in head. The x86 work done during this quarter has been focused on rewriting the PVH implementation inside of Xen, into what is now being called HVMlite to differentiate it with the previous PVH implementation. The Xen side of patches have already been committed to the Xen source tree, and will be available in Xen 4.7, the next version. Work has also begun on implementing HVMlite Dom0 support, although no patches have yet been published. HVMlite support for FreeBSD has not yet been committed, although an initial implementation is available in a personal git repository. The plan is to completely replace PVH with HVMlite on FreeBSD as soon as HVMlite supports Dom0 mode. Apart from this, Wei Liu is working on improving netfront performance on FreeBSD. Initial patches have been posted to the FreeBSD review system. The x86 unmapped bounce buffer code has also been improved, and unmapped IO support has been added to the blkfront driver. This project is sponsored by Citrix Systems R&D. Open tasks: 1. Finish HVMlite Dom0 support inside of Xen. 2. Deprecate and remove PVH support from Xen. 3. Remove PVH support from FreeBSD and switch to HVMlite. 4. Generalize the event channel code so it can be used on ARM. 5. Improve the performance of the various backends (netback, blkback). __________________________________________________________________ Improvements to the QLogic HBA Driver Contact: Alexander Motin The QLogic HBA driver, isp(4), received a substantial set of changes. The primary goal was to make the Fibre Channel target role work well with CTL, but many other things were also fixed/improved: * Added support for modern 16Gbps 26xx FC cards. * The firmware in ispfw(4) were updated to the latest versions. * Target role support was fixed and tested for all FC cards from ancient 1Gbps 22xx to modern 16Gbps 26xx. * Port database handling was unified for target and initiator roles, allowing an HBA port to play both roles at the same time. * The maximal number of ports was increased from 256 to 1024. * Multi-ID (NPIV) functionality was fixed/implemented, allowing 24xx and above cards to provide up to 255 virtual FC ports per physical port. * Added support for 8-byte LUNs for 24xx and above cards. The code is committed to FreeBSD head and stable/10 branches. This project is sponsored by iXsystems, Inc.. Open tasks: 1. NVRAM data reading is hackish and requires rework. 2. FCoE support for 26xx cards was not tested yet. __________________________________________________________________ iMX.6 Video Output Support Links Commit Adding Basic Video Support URL: https://svnweb.FreeBSD.org/changeset/base/292574 Contact: Oleksandr Tymoshenko iMX.6 is a family of SoC used in multiple hobbyist ARM boards such as the Hummingboard, RIoTboard, and Cubox. Most of these products have HDMI output, but until recently, FreeBSD did not benefit from it. As of r292574, there is basic video output support so you can use the console on iMX6-based boards and probably run Xorg (not yet tested). Due to the lack of some kernel functionality (see open tasks), the only supported mode is 1024x768. Open tasks: 1. Proper pixel clock initialization (relies on a clock framework). 2. More flexible video output path (support multiple IPUs and DIs). __________________________________________________________________ ioat(4) Driver Enhancements Links Wikipedia on I/OAT URL: https://en.wikipedia.org/wiki/I/O_Acceleration_Technology Last quarter's ioat(4) report URL: https://www.FreeBSD.org/news/status/report-2015-07-2015-09.html#io= at%284%29-Driver-Import Contact: Conrad Meyer I/OAT DMA engines are bulk memory operation offload engines built into some Intel Server/Storage platform CPUs. Several enhancements were made to the driver. It now avoids memory allocation in locked paths, which should avoid deadlocking in memory pressure scenarios. Support for Broadwell-EP devices has been added. The "blockfill" operation and a non-contiguous 8 KB copy operation have been added to the API. The driver can recover from various programming errors by resetting the hardware. This project is sponsored by EMC / Isilon Storage Division. Open tasks: 1. XOR and other advanced ("RAID") operation support. __________________________________________________________________ Kernel Vnode Cache Tuning Links MFC to stable/10 URL: https://reviews.FreeBSD.org/rS292895 Contact: Kirk McKusick Contact: Bruce Evans Contact: Konstantin Belousov Contact: Peter Holm Contact: Mateusz Guzik This completed project includes changes to better manage the vnode freelist and to streamline the allocation and freeing of vnodes. Vnode cache recycling was reworked to meet free and unused vnode targets. Free vnodes are rarely completely free; rather, they are just ones that are cheap to recycle. Usually they are for files which have been stat'd but not read; these usually have inode and namecache data attached to them. The free vnode target is the preferred minimum size of a sub-cache consisting mostly of such files. The system balances the size of this sub-cache with its complement to try to prevent either from thrashing while the other is relatively inactive. The targets express a preference for the best balance. "Above" this target there are 2 further targets (watermarks) related to the recyling of free vnodes. In the best-operating case, the cache is exactly full, the free list has size between vlowat and vhiwat above the free target, and recycling from the free list and normal use maintains this state. Sometimes the free list is below vlowat or even empty, but this state is even better for immediate use, provided the cache is not full. Otherwise, vnlru_proc() runs to reclaim enough vnodes (usually non-free ones) to reach one of these states. The watermarks are currently hard-coded as 4% and 9% of the available space. These, and the default of 25% for wantfreevnodes, are too large if the memory size is large. For example, 9% of 75% of MAXVNODES is more than 566000 vnodes to reclaim whenever vnlru_proc() becomes active. The vfs.vlru_alloc_cache_src sysctl is removed. The new code frees namecache sources as the last chance to satisfy the highest watermark, instead of selecting source vnodes randomly. This provides good enough behavior to keep vn_fullpath() working in most situations. Filesystem layouts with deep trees, where the removed knob was required, are thus handled automatically. As the kernel allocates and frees vnodes, it fully initializes them on every allocation and fully releases them on every free. These are not trivial costs: it starts by zeroing a large structure, then initializes a mutex, a lock manager lock, an rw lock, four lists, and six pointers. Looking at vfs.vnodes_created, these operations are being done millions of times an hour on a busy machine. As a performance optimization, this code update uses the uma_init and uma_fini routines to do these initializations and cleanups only as the vnodes enter and leave the vnode zone. With this change, the initializations are done kern.maxvnodes times at system startup, and then only rarely again. The frees are done only if the vnode zone shrinks, which never happens in practice. For those curious about the avoided work, look at the vnode_init() and vnode_fini() functions in sys/kern/vfs_subr.c to see the code that has been removed from the main vnode allocation/free path. __________________________________________________________________ Mellanox Drivers Links Hardware Information URL: http://www.mellanox.com/page/ethernet_cards_overview Commit Adding the Driver URL: https://svnweb.FreeBSD.org/changeset/base/290650 Contact: Hans Petter Selasky The Mellanox FreeBSD team is proud to announce support for the ConnectX-4 series of network cards in FreeBSD 11-current and FreeBSD 10-stable. These devices deliver top performance, with up to 100GBit/s of raw transfer capacity, and support both Ethernet and Infiniband. Currently, the Ethernet driver is ready for use and the Infiniband support for ConnectX-4 is making good progress. We hope that it will be complete before FreeBSD 11.0 is released. For more technical information, refer to the mlx5en(4) manual page in 11-current. The new driver for ConnectX-4 cards is called mlx5 and is put under /sys/dev and not under /sys/ofed as was done for the previous mlx4 driver. The mlx5en(4) kernel module is compiled by default in GENERIC kernels. This project is sponsored by Mellanox Technologies. __________________________________________________________________ Minimal Kernel with PNP-Based Autoloading Links Blog Post URL: http://bsdimp.blogspot.com/2016/01/details-on-coming-automatic-mod= ule.html Contact: Warner Losh Work on automatically loading modules based on the plug-and-play data from devices that are scanned and found to not already have a driver attached is in progress. Digging this information out from kernel modules, as well as tagging relevant bits of driver tables, has been committed. PC Card, USB, and some PCI devices now have these markings. This data is stored in a file that the kernel, boot loader, and userland processes all can access. When complete, a user will be able to run a minimal kernel (currently checked in as the MINIMAL config). Devices necessary for booting will be loaded by loader(8). Other devices may be loaded there, or early in the boot (depending on which gives better performance). Users will still be able to run more monolithic; configurations, as well as limit which kernel modules are available as can be done today, though without the convenience that automatic loading will provide. This work remains ongoing. Open tasks: 1. Go through all the simplebus drivers and add plug-and-play information there. Some additional minor simplebus functionality is needed. There is some work in progress for this. 2. Go through all the PCI drivers and add plug-and-play information to them. Unlike PC Card or USB, the PCI bus does not have a stylized table of PCI IDs, so each driver invents its own method, meaning that the semi-mechanical conversion that was done with PC Card and USB will not be possible. Instead, customized code for each driver will be needed. Since a large number of drivers have their own device tables, the work will be primarily writing a description of the current table style. 3. Run-time parsing and loading is still needed. __________________________________________________________________ MMC Stack Under CAM Framework Links Project Information URL: https://bakulin.de/freebsd/mmccam.html Source Code URL: https://github.com/kibab/FreeBSD/tree/mmccam Patch for Review URL: https://reviews.FreeBSD.org/D4761 Contact: Ilya Bakulin The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debug features. It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface. The first version of the code was uploaded to Phabricator for review. The new stack is able to attach to the SD card and bring it to an operational state so it is possible to read and write to the card. The only supported SD controller driver is ti_sdhci, which is used on the BeagleBone Black. Modifying other SDHCI-compliant drivers should not be difficult. Open tasks: 1. Rework bus/target/LUN enumeration and the locking model. I do not really understand the CAM locking and am likely to do it incorrectly. 2. Modify the SDHCI driver on at least one x86 platform. This will make development and collaboration easier. 3. Begin implementing SDIO-specific bits. __________________________________________________________________ ntb_hw(4)/if_ntb(4) Driver Synced up to Linux Links Jon Mason's NTB wiki URL: https://github.com/jonmason/ntb/wiki Intel NTB whitepaper URL: https://www-ssl.intel.com/content/dam/www/public/us/en/documents/w= hite-papers/xeon-c5500-c3500-non-transparent-bridge-paper.pdf Contact: Conrad Meyer ntb_hw(4) is now up-to-date with the Linux NTB driver as of the work-in-progress 4.4 kernel (and actually, contains some fixes that haven't landed in the mainline Linux tree yet but will land in 4.5). Only Back-to-back ("B2B") configurations are supported at this time. Going forward, newer hardware may only support the B2B configuration. if_ntb(4) is mostly up-to-date with the Linux NTB netdevice driver. Notably absent is support for changing the MTU at runtime. This project is sponsored by EMC / Isilon Storage Division. Open tasks: 1. Improving if_ntb(4) to avoid using the entire Base Address Register (BAR) when very large BAR sizes are configured (e.g., 512 GB). 2. Improving pmap_mapdev(9) to somehow allocate only superpage mappings for large BARs, on platforms that support superpages. (NTB BARs can be as large as 512 GB.) __________________________________________________________________ Out of Memory Handler Rewrite Contact: Konstantin Belousov The Out of Memory (OOM) code is intended to handle the situation where the system needs free memory to make progress, but no memory can be reused. Most often, the situation is that to free memory, the system needs more free memory. Consider a case where the system needs to page-out dirty pages, but needs to allocate structures to track the writes. OOM "solves" the problem by killing some selection of user processes. In other words, it trades away system deadlock by suffering a partial loss of user data. The assumption is that it is better to kill a process and recover data in other processes than to lose everything. Free memory in the FreeBSD Virtual Memory (VM) system appears from two sources. One is the voluntary reclamation of pages used by a process, for example unmapping private anonymous regions, or the last unlink of an otherwise unreferenced file with cached pages. Another source is the pagedaemon, which forcefully frees pages which carry data, of course after the data is moved to some other storage, like swap or file blocks. OOM is triggered when the pagedaemon definitely cannot free memory to satisfy the requests. The old criteria to trigger the OOM action was a combination of low free swap space and a low count of free pages (the latter is expressed precisely with the paging targets constants, but this is not relevant to the discussion). That test is mostly incorrect. For example, a low free page state might be caused by a greedy consumer allocating all pages freed by the page daemon in the current pass, but this does not preclude the page daemon from producing more pages. Also, since page-outs are asynchronous, the previous page daemon pass might not immmediately produce any free pages, but they would appear some short time later. More seriously, low swap space does not necessarily indicate that we are in trouble: lots of pages might not require swap allocations to be freed, like clean pages or pages backed by files. The last notion is serious, since swap-less systems were considered as having full swap. Instead of trying to deduce the deadlock from looking at the current VM state, the new OOM handler tracks the history of page daemon passes. Only when several consecutive passes failed to meet the paging target is an OOM kill considered necessary. The count of consequent failed passes was selected empirically, by testing on small (32M) and large (512G) machines. Auto-tuning of the counter is possible, but requires some more architectural changes to the I/O subsystem. Another issue was identified with the algorithm which selects a victim process for OOM kill. It compared the counts of pages mapping entries (PTEs) installed into the machine paging structures. For different reasons, the machine-dependent VM code (pmap) may remove the pte for a memory-resident page. Under some circumstances related to other measures to prevent low memory deadlock, very large processes which consume all system memory could have few or no ptes. The old OOM selector ignored the process which caused the deadlock, killing unrelated processes. A new function, vm_pageout_oom_pagecount(), was written which applies a reasonable heuristic to estimate the number of pages freed by killing the given process. This eliminates the effect of selecting small unrelated processes for OOM kill. The rewrite was committed to head in r290917 and r290920. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ sendfile(2) Improvements Links Commit to Head URL: https://svnweb.FreeBSD.org/base?view=3Drevision&revision=3D293439 Slides URL: http://www.slideshare.net/facepalmtarbz2/new-sendfile-in-english Presentation (in Russian) URL: https://events.yandex.ru/lib/talks/2682/ Contact: Gleb Smirnoff The sendfile(2) system call was introduced in 1998 as an alternative to a traditional read(2)/write(2) loop, speeding up server performance by a factor of ten at the time. Since it was adopted by all major operating systems, it is now used by any serious web server software. Wherever there is high traffic, there is sendfile(2) under the hood. Now, with FreeBSD 11, we are making the next revolutinary step in serving traffic. sendfile(2) no longer blocks waiting on disk I/O. Instead, it immediately returns control to the application, performing the necessary I/O in the background. The original sendfile(2) waited for the disk read operation to complete and then put the data that was read into the socket, then returned to userspace. If a web server served thousands of clients with thousands of requests, it was forced to spawn extra contexts from which to run sendfile(2) to avoid stalls. Alternatively, it could use special tricks like the SF_NODISKIO flag that forces sendfile(2) to serve only content that is cached in memory. Now, these tricks are in the past, and a web server can simply use sendfile(2) as it would use write(2), without any extra care. The new sendfile cuts out the overhead of extra contexts, short writes, and extra syscalls to prepopulate the cache, bringing performance to a new level. The new syscall is built on top of two newly-introduced kernel features. The first is an asynchronous VM pager interface and the corresponding VOP_GETPAGES_ASYNC() file system method for UFS. The second is the concept of "not ready" data in sockets. When sendfile(2) is called, first VOP_GETPAGES_ASYNC() is called, which dispatches I/O requests for completion. Buffers with pages to be populated are put into the socket buffer, but flagged as not-yet-ready. Control immediately returns to the application. When the I/O is finished, the buffers are marked as ready, and the socket is activated to continue transmission. Additional features of the new sendfile are new flags that provide the application with extra control over the transmitted content. Now it is possible to prevent caching of content in memory, which is useful when it is known that the content is unlikely to be reused any time soon. In such cases, it is better to let the associated storage be freed, rather than putting the data in cache. It is also possible to specify a readahead with every syscall, if the application can predict client behavior. The new sendfile(2) is a drop-in replacement, API and ABI compatible with the old one. Applications do not even need to recompile to benefit from the new implementation. This work is a joint effort between two companies: NGINX, Inc., and Netflix. There were many people involved in the project. At its initial stage, before code was written, the idea of such an asynchronous drop-in replacement was discussed amongst Gleb Smirnoff, Scott Long, Konstantin Belousov, Adrian Chadd, and Igor Sysoev. The initial prototype was coded by Gleb under the supervision of Kostik on the VM parts of the patch, and under constant pressure from Igor, who demanded that nginx be capable of running with the new sendfile(2) with no modifications. The prototype demonstrated good performance and stability and quickly went into Netflix production in late 2014. During 2015, the code matured and continued serving production traffic at Netflix. Scott Long, Randall R. Stewart, Maksim Yevmenkin, and Andrew Gallatin added their contributions to the code. Now we are releasing the code behind our success to the FreeBSD community, making it available to all FreeBSD users worldwide! This project is sponsored by Netflix, and NGINX, Inc.. Open tasks: 1. SSL_sendfile() -- an extension to the new sendfile(2) that allows uploading session keys to the kernel, and then using sendfile(2) on an SSL-enabled socket. __________________________________________________________________ sysctl Enhancements Links Wikipedia Entry on C99 Fixed-Width Integer Types URL: https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_typ= es sysctl(8) -t Submission PR URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D203918 Contact: Conrad Meyer Contact: Ravi Pokala Contact: Marcelo Araujo Support was added for fixed-width sysctls (signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers). The new KPIs are documented in the sysctl(9) manual page. The sysctl(8) command line tool supports all of the new types. sysctl(8) gained the -t flag, which prints sysctl type information (the original patch was submitted by Yoshihiro Ota). This support includes the newly added fixed-width types. This project is sponsored by EMC / Isilon Storage Division. __________________________________________________________________ Touchscreen Support for Raspberry Pi and Beaglebone Black Links Beaglebone Black with 4DCAPE-43T Demo URL: http://kernelnomicon.org/?p=3D534 Input Stack Plans URL: https://wiki.FreeBSD.org/201510DevSummit/GraphicsStack evdev Port URL: https://wiki.FreeBSD.org/SummerOfCode2014/evdev_Touchscreens Contact: Oleksandr Tymoshenko There are two working proof-of-concept drivers for the AM335x touchscreen and for the official Raspberry Pi's touchscreen LCD. Proper touchscreen support would consist of a userland event reading API, a kernel event reporting API, and kernel hardware drivers for specific devices. There is an ongoing effort to port the Linux evdev API to FreeBSD so applications that use libraries like libinput or tslib could be used without any major changes. Since it is not yet complete, I created a naive evdev-like API for both kernel and tslib and was able to run a demo on a Beaglebone Black with 4DCAPE-43T. Once evdev makes it into the tree, both hardware drivers can be modified to include "report events" portions and committed. __________________________________________________________________ armv6 Hard Float Default ABI Links Blog Entry URL: http://bsdimp.blogspot.com/2015/12/hard-float-api-coming-soon-by-d= efault.html Contact: Warner Losh Work on moving armv6 from a "soft float" ABI (but still using hardware floating point) to a fully "hardware float" API moves forward. The ability to have both soft and hard ABI libraries on the same system is now functional. All armv6 and armv7 systems we support have hardware floating point capabilities. We currently use the floating-point hardware, but with a slightly un-optimal ABI, for compatibility with older versions of FreeBSD. The ABI differences are only at the userspace level -- the kernel does not care what floating-point ABI is used, and both types of binaries can run at the same time. The run-time linker now knows if a binary uses the hardware float ABI or the software float ABI by examining some fields in the ELF header. The linker uses different paths and config files for hard versus soft binaries. The rc system has been enhanced to load the software float paths. ldconfig now understands soft libraries in much the same way that it understands 32-bit libraries on 64-bit systems. No additional kernel support was necessary for this, apart from a minor patch to pass the ELF header information to the binary, which has been in the tree since last summer. The experimental armv6hf MACHINE_ARCH will be retired after a transition period. It will cease to mean anything different from armv6 after the build system changes go in. Support for building soft-float ABI libraries will remain in the tree, to support the WITH_LIBSOFT build option. Open tasks: 1. Complete documentation needs to be written. 2. Hooks into the FreeBSD build system to generate soft float and transition to hard float after a flag day need to be polished up and committed. 3. A number of different upgrade/coexistence scenarios need to be tested, and a full package run needs to be done to assess the latest state of the ports tree. This work should be completed by the end of January. __________________________________________________________________ FreeBSD on Marvell Armada38x Contact: Marcin Wojtas Contact: Michal Stanek Contact: Bartosz Szczepanek Contact: Jan Dabros FreeBSD has been ported to run on the Marvell Armada38x platform. This SoC family boasts single/dual high-performance ARM Cortex-A9 CPUs. The multi-user SMP system is fully working and has been tested on Marvell DB-88F6288-GP and SolidRun ClearFog development boards. The root filesystem can be hosted on a USB 3.0/2.0 drive or via NFS using a PCIe network card. Experimental support is available for on-chip Gigabit Ethernet (NETA). Additional features: * GIC+MPIC cascaded interrupts courtesy of INTRNG * CESA dual-channel cryptographic engine * USB 3.0 and 2.0 * PCIe 2.0 * I2C * GPIO * Watchdog * RTC The port is under community review and will be integrated into head soon. This project is sponsored by Stormshield, and Semihalf. Open tasks: 1. Optimize performance of NETA and prepare for submission. __________________________________________________________________ FreeBSD on Newer ARM Boards Links FreeBSD on Odroid-C1 URL: https://wiki.FreeBSD.org/FreeBSD/arm/Odroid-C1 Commit Adding Glue Driver URL: https://svnweb.FreeBSD.org/changeset/base/291683 Contact: John Wehle Contact: Ganbold Tsagaankhuu We made the changes required to support the Amlogic Meson Ethernet controller on the Hardkernel ODROID-C1 board, which has an Amlogic aml8726-m8b SoC. The main effort needed was to write a glue driver for the Ethernet controller -- the Amlogic Meson Ethernet controller is compatible with Synopsys DesignWare 10/100/1000 Ethernet MAC (if_dwc). __________________________________________________________________ FreeBSD on SoftIron Overdrive 3000 Links SoftIron Website URL: http://softiron.co.uk/products/ Contact: Andrew Turner The SoftIron Overdrive 3000 is an ARMv8 based server with an 8-core AMD Opteron A1100 processor. The Overdrive 3000 has two 10Gbase-T Ethernet ports, two PCI Express ports, and eight SATA ports. FreeBSD has been updated to be able to boot on this hardware. Support for the SATA device was added to the ahci(4) driver. Unlike on x86, this is a Memory Mapped (mmio) device, and not on the PCI bus. To support this, a new ahci mmio driver attachment has been added. The generic PCIe driver has been updated to improve interrupt handling. This includes supporting the interrupt-map devicetree property, and supporting MSI and MSI-X interrupts on arm64. Support for MSI and MSI-X interrupts has been added to the ARM Generic Interrupt Controller v2 (gicv2) driver. This allows devices to use these interrupts. This has been tested with a collection of PCIe NIC hardware. This project is sponsored by SoftIron Inc.. Open tasks: 1. Write a driver for the 10Gbase-T NIC. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 Wiki Entry URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Contact: Konstantin Belousov Contact: Ed Maste Contact: Ed Schouten Support was added for kernel modules. This included adding the needed relocation types to the in-kernel relocator, and updating the build logic to build modules for arm64. CTF data is currently not generated for modules due to a linker bug. Shared page support was added. This allows gettimeofday(2) to be implemented in userland by directly accessing the timer register. This reduces the overhead of these calls as we no longer need to call into the kernel. This also moves the signal trampoline code away from the stack, allowing for the stack to become non-executable. CloudABI support for arm64 was added. This included moving the machine-independent code into a separate file to be shared among all architectures. An issue in the arm64 kernel was found and fixed thanks to the CloudABI test suite. Self-hosted poudriere package builds have been tested. These complement the previous build strategy of using qemu usermode emulation. With this combination of self-hosted and qemu usermode building, many ports that used to be broken on arm64 have been fixed, resulting in over 17,000 ports building for the architecture. The machine-dependent portion of kernel support for single-stepping userland binaries has been started. This will allow debuggers like lldb to step through an application while debugging. Many small fixes have been made to FreeBSD/arm64. These include fixing stack tracing through exceptions, printing more information about "data abort" kernel panics, cleaning up the atomic functions, supporting multi-pass driver attachment, fixing userland stack alignment, cleaning up early page table creation, fixing asynchronous software trap handling, and enabling interrupts in exception handlers. This project is sponsored by The FreeBSD Foundation, and ABT Systems Ltd. __________________________________________________________________ FreeBSD/RISC-V Links Project Wiki URL: https://wiki.FreeBSD.org/riscv Contact: Ruslan Bukin Contact: Ed Maste Contact: Arun Thomas We have begun work on support for the RISC-V architecture. RISC-V is a new ISA designed to support computer architecture research and education that is now set to become a standard open architecture for industry implementations. A minimal set of changes needed to compile the kernel toolchain has been committed, along with machine headers, run-time linker (rtld-elf) support, and libc/libstand. All development has been happening in a separate branch, with a goal of moving development to head in a few weeks. At present, FreeBSD/RISC-V boots to multiuser in the Spike simulator. This project is sponsored by DARPA, AFRL, and HEIF5. Open tasks: 1. We plan to commit the rest of userspace (i.e., libc), kernel support, etc., in a few weeks. __________________________________________________________________ Improvements for ARMv6/v7 Support Contact: Dominik Ermel Contact: Wojciech Macek Contact: Zbigniew Bodek Numerous improvements for the ARMv6/v7 kernel and tools have been developed by the Semihalf team. Those include: * Fixes for KGDB support. * Support for branch instructions in ptrace single stepping. * Fixes for kernel minidumps. * Improvements for LIBUSBBOOT. * Support for Exynos EHCI in the loader. * A fix for instruction single stepping in DDB. * Support for hardware watchpoints, including watchpoints on SMP systems. * Single stepping using the ARM Debug Architecture. * Support for gzip-compressed kernel modules in kldload. * Backport of the new pmap VM code to FreeBSD 10-STABLE (not yet sent to upstream). Most of the introduced changes have been committed to head and more are on the way. This project is sponsored by Juniper Networks Inc., and Semihalf. Open tasks: 1. Finish upstreaming the hardware watchpoints support. __________________________________________________________________ Base System Build Improvements Links FreeBSD-Arch Post Describing Plans URL: https://lists.FreeBSD.org/pipermail/freebsd-arch/2015-December/017= 571.html BSDCan 2014 META_MODE Presentation URL: http://www.bsdcan.org/2014/schedule/events/460.en.html WITH_FAST_DEPEND Details URL: https://svnweb.FreeBSD.org/base?view=3Drevision&revision=3D290433 WITH_CCACHE_BUILD Details URL: https://svnweb.FreeBSD.org/base?view=3Drevision&revision=3D290526 Contact: Bryan Drewery Bryan Drewery (bdrewery@) has been working to improve the build framework as well as buildworld build times. The build system has been largely untouched by large-scale changes for many years. Most of the effort has been on improving the recent META_MODE merge that was presented at BSDCan 2014. This is a new build system that is not currently enabled by default but brings many benefits. Beyond that, some highlights of the work changing buildworld are: * WITH_FAST_DEPEND, which avoids calling "mkdep" during the make depend phase and instead generates dependency files during compilation. The old scheme was pre-processing all source files twice. The new version saves 16-35% in build times. * WITH_CCACHE_BUILD adds built-in ccache support, avoiding many of the historical pitfalls of changing CC in make.conf to use ccache. * Many improvements for parallelization of the build. * LIBADD improvements to ensure proper usage of this tool to replace duplicate LDADD and DPADD statements. Further work is under way to reduce overlinking. * A lot of cleanup of improper framework usage. * Ensuring that installing files from the build tree fails if the destination directory is missing, rather than installing a file as the directory name. This project is sponsored by EMC / Isilon Storage Division. Open tasks: 1. See the FreeBSD-arch mail for more information on planned work. __________________________________________________________________ ELF Tool Chain Tools Links ELF Tool Chain Website URL: http://elftoolchain.sourceforge.net Contact: Ed Maste The ELF Tool Chain project provides BSD-licensed implementations of compilation tools and libraries for building and analyzing ELF objects. The project began as part of FreeBSD but later became an independent project in order to encourage wider participation from others in the open-source developer community. In the last quarter of 2015 the ELF Tool Chain tools were updated to a snapshot of upstream Subversion revision 3272. Improvements include better input file validation, RISC-V support, support for Xen ELF notes, additional MIPS and ARM relocations, better performance, and bug fixes. The ELF Tool Chain project is planning a new release in the first quarter of 2016, which will facilitate wider testing and use by projects in addition to FreeBSD. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Add missing functionality (PE/COFF support) to elfcopy and migrate the base system build. 2. Fix issues found by fuzzing inputs to the tools. 3. Add automatic support for separate debug files. __________________________________________________________________ The LLDB Debugger Links FreeBSD LLDB Wiki Page URL: https://wiki.FreeBSD.org/lldb Contact: Ed Maste LLDB is the debugger from the LLVM family of projects. Originally developed for Mac OS X, it now also supports FreeBSD, NetBSD, Linux, Android, and Windows. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler. LLDB in the FreeBSD base system was upgraded to version 3.7.0 as part of the Clang and LLVM upgrade, and it will similarly be upgraded again to 3.8.0 for FreeBSD 11.0-RELEASE. LLDB is now enabled by default on the amd64 and arm64 platforms. It is now a functional basic debugger on arm64, after a number of fixes were made in the last quarter to both LLDB and the FreeBSD kernel. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Rework the LLDB build to use LLVM and Clang shared libraries. 2. Port a remote debugging stub to FreeBSD. 3. Add support for local and core file kernel debugging. 4. Improve support on architectures other than amd64 and arm64. __________________________________________________________________ Updates to GDB Links New 1:1-Only Thread Target for FreeBSD URL: https://github.com/bsdjhb/gdb/tree/freebsd-threads Contact: John Baldwin The KGDB option is now on by default in the devel/gdb port. Changes to support cross-debugging of crashdumps in libkvm were committed to head in r291406. A new thread target for FreeBSD that is suitable for merging upstream has been written and lightly tested. However, it is not yet available as an option in the port. This thread target uses ptrace(2) directly rather than libthread_db and as such supports threads on all ABIs (such as FreeBSD/i386 binaries on FreeBSD/amd64 and possibly Linux binaries, though that is not yet tested). It also requires less-invasive changes in the MD targets in GDB compared to the libthread_db-based target. Open tasks: 1. Add a port option for the new 1:1-only thread target. 2. Test the new 1:1-only thread target. 3. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 4. Add support for more platforms (arm, mips, aarch64) to upstream gdb for both userland and kgdb. 5. Add support for debugging powerpc vector registers. __________________________________________________________________ Bringing GitLab into the Ports Collection Links PR for the New Port URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=3D202468 Installation Guide URL: https://github.com/t-zuehlsdorff/gitlabhq/blob/8-3-docu/doc/instal= l/installation-freebsd.md Upstream GitLab website URL: https://github.com/gitlabhq/gitlabhq/ Contact: Torsten Z=FChlsdorff GitLab is a web-based Git repository manager with many features that is used by more than 100,000 organizations including NASA and Alibaba. It also is a very long-standing entry on the "Wanted Ports" list of the FreeBSD Wiki. In the last quarter, there was steady progress in the project itself and the porting. The current release of GitLab 8.3 is now based on Rails 4.2, which obsoletes the need for around 50 new ports. Now there are only 5 dependencies left to be committed! While the new version of GitLab 8.3 eases the porting, there are big changes since the last working port of GitLab 7.14. Nonetheless, it could be expected to see the next working port in the first quarter of 2016. This project is sponsored by anyMOTION GRAPHICS GmbH, D=FCsseldorf, Germany. Open tasks: 1. Update the patches from GitLab 7.14 to 8.3. 2. Update the documentation. 3. Provide an updated patch. __________________________________________________________________ GNOME on FreeBSD Links FreeBSD Gnome Website URL: http://www.FreeBSD.org/gnome Devel Repository URL: https://github.com/FreeBSD/freebsd-ports-gnome Upstream Build Bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook= /using-gnome.html Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter, due to limited available time there was not much progress. This began to change in December, when work started on porting MATE 1.12 and CINNAMON 2.8 to FreeBSD. Open tasks: 1. The FreeBSD GNOME website is stale. Work is under way to improve it. 2. Continue working on investigating the issues blocking GNOME 3.18. __________________________________________________________________ IPv6 Promotion Campaign Links Wiki Page URL: https://wiki.FreeBSD.org/IPv6PortsTODO Contact: Torsten Z=FChlsdorff There are more and more machines on the internet that only support IPv6. I manage some of them, and was regularly hit by missing IPv6 support when fetching the distfiles needed for building ports. I did some research into the impact of missing IPv6 support on the ports tree. The results are that 10,308 of 25,522 ports are not fetchable when using IPv6. This renders, through dependencies, a total of 17,715 ports unbuildable from IPv6-only systems. All you can do then is wait and hope that distcache.FreeBSD.org caches the distfile. But this will take some time, which might not be a luxury available when a piece of software in use is hit by a security issue. Based on the research, a promotion campaign for IPv6 was started. Some volunteers will contact the relevant system administrators and try to convince them to support IPv6. This will start in January 2016 and will hopefully create some progress soon. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD Website URL: https://FreeBSD.kde.org/ Experimental KDE Ports Staging Area URL: https://FreeBSD.kde.org/area51.php KDE on FreeBSD Wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD Mailing List URL: https://mail.kde.org/mailman/listinfo/kde-FreeBSD Development Repository for Integrating KDE Frameworks 5 and Plasma 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure that the experience of KDE and Qt on FreeBSD is as good as possible. The team kept busy during the last quarter of 2015. Quite a few big updates were committed to the ports tree, and a few more are being worked on in our experimental repository. As in previous quarters, we would like to thank several people who have contributed with machines, patches, and general help. Tobias Berner, Guido Falsi (madpilot@), Adriaan de Groot, Ralf Nolden, Steve Wills (swills@), and Josh Paetzel (jpaetzel@) have been essential to our work. The following big updates landed in the ports tree this quarter. In many cases, we have also contributed patches to the upstream projects. * CMake 3.4.0 and 3.4.1 * Calligra 2.9.1, the latest release of the integrated work applications suite. Calligra had last been updated in the ports tree at the end of 2013! * PyQt4 4.11.4, QScintilla2 2.9.1 and SIP 4.17. * PyQt5 5.5.1. Thanks to the work spearheaded by Guido Falsi and Tobias Berner in the previous quarter, the PyQt5 ports have finally been committed to the ports tree. Not only was this long-awaited on its own, it allows other ports to be updated to their latest versions. * QtCreator 3.5.1 and 3.6.0. * A couple of Qt5 packaging bugs were fixed: it should now be more straightforward to use the Qt5 ports to build software outside the ports tree, and it is now possible to build ports that require a C++11 compiler and Qt5 on FreeBSD 9.x. Work on updating the Qt5 ports to their latest version, as well as porting KDE Frameworks 5 and Plasma 5 to FreeBSD, is well under way in our experimental area51 repository. At the moment, it contains Qt5 5.5.1, KDE Frameworks 5.17.0, Plasma 5.5.1 and KDE Applications 15.12.0. Users interested in testing those ports are encouraged to follow the instructions in our website and report their results to our mailing list. Qt5 5.5.1 is in our "qt-5.5" branch, and Plasma 5 and the rest is in the "plasma5" branch (which also contains Qt 5.5.1). Open tasks: 1. Commit the Qt5 5.5.1 update. 2. Land the KDE Frameworks 5 and Plasma 5 ports in the tree. 3. Investigate what needs to be done to make QtWebEngine, the Chromium-based replacement for QtWebKit, work on FreeBSD. __________________________________________________________________ Linux Kernel as a Library Added to the Ports Collection Links Upstream LKL Github repository URL: https://github.com/lkl/linux Contact: Conrad Meyer LKL ("Linux Kernel as a Library") is a special "architecture" of the full Linux kernel that builds as a userspace library on various platforms, including FreeBSD. One application of such a library is using Linux filesystem drivers to implement a FUSE backend. fusefs-lkl's lklfuse binary is such a FUSE filesystem. It can mount ext4/3/2, XFS, and BTRFS read-write, using the native drivers from Linux. sysutils/fusefs-lkl can now be installed either from packages or ports, providing access to these filesystems on FreeBSD via FUSE. __________________________________________________________________ LXQt on FreeBSD Links FreeBSD LXQt Project URL: https://wiki.FreeBSD.org/LXQt LXQt Devel Repository URL: https://www.assembla.com/spaces/lxqt/subversion/source Contact: Olivier Duchateau LXQt is the Qt port of and the upcoming version of LXDE, the Lightweight Desktop Environment. It is the product of the merge between the LXDE-Qt and the Razor-qt projects. The porting effort remains very much a work in progress: it needs some components of Plasma 5, the new major KDE workspace. Currently, only the 0.10 branch is functional. See our wiki page for a complete list of applications. We also sent updates for some components of LXDE, required for the LXQt desktop: * x11/menu-cache 1.0.1 * x11/lxmenu-data 0.1.4 Binary packages are available (only for test purposes) which are regularly tested with the KDE development repository. Open tasks: 1. Port libsysstat to BSD systems. 2. Fix some issues that need to be resolved, especially the shutdown and reboot commands. __________________________________________________________________ New Tools to Enhance the Porting Experience Links pytoport: Generate FreeBSD Ports from Python modules on PyPI URL: https://github.com/FreeBSD/pytoport bandar: Create Development Overlays for the Ports Tree URL: https://github.com/bbqsrc/bandar skog: Generate Visual Dependency Trees for FreeBSD Ports URL: https://github.com/bbqsrc/skog-python spdx-lookup: SPDX License List Query Tool URL: https://github.com/bbqsrc/spdx-lookup-python Contact: Brendan Molloy When I starting working on ports for FreeBSD in the last couple of weeks, I found that my workflow was not as efficient as it could be using just the available tools, so I made a few that could be useful to the development community at large. All of these have been or will soon be added to the Ports tree, so you can play with them today! pytoport is a command-line application that generates a skeleton port for a given PyPI package name. It attempts to generate the correct dependencies, makes a good attempt at guessing the license using spdx-lookup, and generates a pkg-descr. This made generating the fifteen or so ports I was working on a complete breeze. While doing this, however, I noticed that some ports were bringing in dependencies that I did not expect, and I needed some way to visualise this. skog builds a dependency tree from the depends lists output by the Ports framework, and displays it on the command line (with extra shiny output if you are using UTF-8). No more pesky example and documentation dependencies being dragged in when you clearly toggled that OPTION as far off as it would go. While doing all of this, I found it cumbersome to be copying ports back and forth between my small development tree living in git and the larger upstream SVN tree I was using in poudriere. I built a tool called bandar that takes advantage of the FUSE version of unionfs to easily overlay my dev tree on the upstream tree, run lint checks, poudriere, and generate archives with ease. I am very impressed with how easy it was to build more tooling for FreeBSD. I hope some of these tools will be of some use to you, and as always, I'd love to hear your feedback! Open tasks: 1. Improve skog to support searching a tree for a certain port. 2. Get the bandar port completed. 3. Continue to improve pytoport, adding trove support and better dependency handling. 4. Patches welcome for all of the above! __________________________________________________________________ Node.js Modules Links Node.js Modules Repository URL: https://www.assembla.com/spaces/cozycloud/subversion/source Contact: Olivier Duchateau Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient -- perfect for data-intensive real-time applications that run across distributed devices. The goal of this project is to make it easy to install the modules available in the npm package registry. Currently, the repository contains slightly fewer than 300 new ports, in particular: * Socket.IO, a library for realtime web applications * Jison, a JavaSript parser generator We have improved the USES framework: * Users can define which version of Node.js will be installed through /etc/make.conf. * node-gyp is now well-integrated into the USES framework, via the build argument. * The pkg-plist is now automatically generated to make portlint happy. Each port is up-to-date. Open tasks: 1. Update the pre-draft documentation. 2. Bring in grunt.js (and modules), the JavaScript task runner. __________________________________________________________________ Ports Collection Links Ports Collection Landing Page URL: http://www.FreeBSD.org/ports/ Contributor's Guide URL: https://www.freebsd.org/doc/en/articles/contributing/ports-contrib= uting.html Ports Monitoring Service URL: http://portsmon.FreeBSD.org/index.html Ports Management Team Website URL: http://www.FreeBSD.org/portmgr/index.html Portmgr on Facebook URL: http://www.facebook.com/portmgr Contact: Frederic Culot Contact: Frederic Culot Contact: FreeBSD Ports Management Team As of the end of the fourth quarter, the ports tree holds a bit more than 25,000 ports, and the PR count is around 2,000. The activity on the ports tree remains steady, with about 7,000 commits performed by almost 120 active committers. On the problem reports front, figures show an encouraging trend, with a significant increase in the number of PRs fixed during Q4. Indeed, almost 1,800 reports were fixed, which makes an increase of about 20% compared to Q3. In Q4, eight commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (lioux, lippe, simon, jhay, max, sumikawa, alexey, sperber). Three new developers were granted a ports commit bit (Kenji Takefu, Carlos Puga Medina, and Ian Lepore), and one returning committer (miwi) had his commit bit reinstated. Also related to the management of ports commit bits, nox's grants were revoked, since the FreeBSD developers learned that Juergen Lock had passed away. On the management side, no changes were made to the portmgr team during Q4. On QA side 33 exp-runs were performed to validate sensitive updates or cleanups. Amongst those noticeable changes are the update to GCC 4.9, CMake to 3.4.1, PostgreSQL to 9.4, and ruby-gems to 2.5.0. Some infrastructure changes included the usage of a WRKSRC different from WRKDIR when NO_WRKSUBDIR is set, the removal of bsd.cpu.mk from sys.mk, and the move of QT_NONSTANDARD to bsd.qt.mk. Open tasks: 1. We would like to remind everyone that the ports tree is built and run by volunteers, and any help is greatly appreciated. While Q4 saw a significant increase in the number of problem reports fixed, we encourage all ports committers to have a look at the issues reported by our users and try to fix as many as possible. Many thanks to all who made a contribution during Q4, and keep up the good work in 2016! __________________________________________________________________ Supporting Variants in the Ports Framework Links Poudriere PoC with Variants URL: https://github.com/bbqsrc/poudriere/compare/master...feature/varia= nts Ports Makefile PoC with Examples URL: https://gist.github.com/bbqsrc/e7e3a54d84706485aa3a Contact: Brendan Molloy I recently became involved with FreeBSD (as in, the last 2-3 weeks), and found myself quickly involved with Ports development. What struck me immediately was the difficulty in providing a Python package that was depended upon by multiple versions of Python. As it turns out, poudriere can currently only generate one package per port, meaning that a Python version-neutral (compatible with 2.x and 3.x) port cannot simultaneously be packaged for each variant at the same time. I discussed the issue with Kubilay Kocak, who suggested that I look into implementing a "variants protocol" within the Ports framework and the necessary changes to poudriere to allow a port to generate more than one package. Support for variants is strongly needed in Ports and provides significant benefits. * It would allow Python and other languages to provide packages for dependencies for multiple language versions from the same port. * It alleviates the need for so-called "slave ports", as a single port could now have multiple generated packages from a single port. * It would have a very small impact on the greater Ports ecosystem: adding only two new variables, VARIANT and VARIANTS. * It would provide a more consistent approach between different packaging teams for handling variations. For a simple example, editors/vim-lite could be folded into the editors/vim port, while still generating a vim and vim-lite package. For Python, VARIANTS can be derived from the already used USES flags and generate compatible packages. py27-foobar and py34-foobar could now be consistently generated by poudriere without issue. Fortunately, this is not a wishful thinking piece. I dug in my heels and have implemented a proof-of-concept implementation of variants in the Ports framework, including the necessary modifications to poudriere in order to support it. It was mildly upsettling to find that poudriere is mostly written in Bourne shell scripts, but I pressed on nonetheless. I started with the prototype made by Baptiste Daroussin as a base, and built from there. The poudriere PoC aims to limit changes as much as possible to merely adding support for the new variants flags, while also at the request of Kubilay Kocak making the logging output more package-centric (as opposed to port-centric) as a result of these changes. This is a work in progress, and I would love to hear your feedback. I have enjoyed my first few weeks working on FreeBSD, and I hope to stay here for quite some time. Open tasks: 1. Any constructive feedback on the implementation would be very welcome! 2. Hopefully the code will be of sufficient quality to be considered for formal review in the coming months. __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce FreeBSD Xfce Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * audio/xfce4-pulseaudio-plugin 0.2.4 * multimedia/xfce4-parole 0.8.1 * x11/xfce4-whiskermenu-plugin 1.5.2 We also follow the unstable releases (available in our experimental repository) of: * x11/xfce4-dashboard 0.5.4 Open tasks: 1. Propose a patch to upstream to fix Xfdashboard with our version of OpenGL (it currently coredumps). __________________________________________________________________ "FreeBSD Mastery: Specialty Filesystems" Early Access Version Now Available Links Book site URL: https://www.michaelwlucas.com/nonfiction/fmsf Early access version URL: https://www.tiltedwindmillpress.com/?product=3Dfmspf Contact: Michael Lucas FreeBSD Mastery: Specialty Filesystems is now in copyediting. The ebook should be available by the end of January at all major vendors, and the print in February. The book covers everything from removable media, to FUSE, NFSv4 ACLs, iSCSI, CIFS, and more. If you act really quickly, you can get the electronic early access version at a 10% discount. You will get the final ebook when it comes out as well. (This offer evaporates when the final version comes out.) __________________________________________________________________ style(9) Enhanced to Allow C99 bool Links Bruce's Email Requesting bool be Added to style(9) URL: https://lists.FreeBSD.org/pipermail/svn-src-head/2015-December/079= 671.html Differential Revision for the Change URL: https://reviews.FreeBSD.org/D4384 Contact: Bruce Evans Contact: Conrad Meyer Use of bool is now allowed. It was allowed previously, as well, but now it is really allowed. Party like it's 1999! This project is sponsored by EMC / Isilon Storage Division. Open tasks: 1. Specify style(9)'s opinion on iso646.h. 2. Fix intmax_t to be 128-bit on platforms where __int128_t is used. __________________________________________________________________ HardenedBSD Links HardenedBSD Website URL: https://hardenedbsd.org/ Introducing HardenedBSD's New Binary Updater URL: https://hardenedbsd.org/article/shawn-webb/2015-12-31/introducing-= hardenedbsds-new-binary-updater secadm Beta Published URL: https://hardenedbsd.org/article/shawn-webb/2015-11-22/introducing-= secadm-030-beta-01 New Package Building Server URL: https://hardenedbsd.org/article/admin/2015-11-22/new-package-build= ing-server secadm URL: https://github.com/HardenedBSD/secadm HardenedBSD Haswell Support URL: https://github.com/HardenedBSD/hardenedBSD-playground/tree/hardene= d/experimental/master-i915 Nightly Builds for HardenedBSD Haswell Support URL: http://jenkins.hardenedbsd.org/builds/HardenedBSD-CURRENT-i915kms-= amd64-LATEST/ Contact: Shawn Webb Contact: Oliver Pinter HardenedBSD has been hard at work improving the performance and stability of our security enhancements. Security flags are now per-thread instead of per-process, removing some locking overhead. ASLR for mmap(MAP_32BIT) requests has been refactored, but lib32 is now disabled by default. We have developed a new binary update utility, hbsd-update, akin to freebsd-update. In addition to normal OS installs, it can also update jails and ZFS Boot Environments (ZFS BEs). Updates are signed using X.509 certificates. secadm 0.3-beta has landed. It has been rewritten from scratch to be more efficient. As part of the rewrite, the rule syntax has changed and users must update their rulesets as described in the README. Thanks to generous donations of a server from G2, Inc and hosting from Automated Tendencies, we can now do full package builds in just 35 hours, down from 75 hours. This machine will also provide weekly binary updates for the kernel and base system. Owing partly to the needs of the developers, we have an experimental branch that includes the work Jean-S=E9bastien P=E9dron has under way fo= r Haswell graphics support, on top of FreeBSD 11-current. Binary updates are also provided for this branch. Unfortunately, in order to focus our efforts on improving HardenedBSD, we have had to pull back from submitting our ASLR patches to FreeBSD. The past two years' efforts to address comments on the submission have taken their toll, and the effort is no longer sustainable. We are proud to be based on FreeBSD and believe that the whole community could benefit from the security technologies we are developing. We hope that someone else will be able to step forward and finish off the task of integrating ASLR into FreeBSD. This project is sponsored by Automated Tendencies, G2, Inc, and SoldierX. __________________________________________________________________ NanoBSD Modernization Contact: Warner Losh This quarter's NanoBSD updates target three main areas. First, building a NanoBSD image required root privileges. Second, building for embedded platforms required detailed knowledge of the format required to boot. Third, the exact image sizes needed to be known to produce an image. When NanoBSD was written, FreeBSD's build system required root privileges for the install step and onward. NanoBSD added to this by creating a md(4) device in which to construct the image. Some configurations of NanoBSD added further to this by creating a chroot in which to cleanly build packages. NanoBSD solves the first problem using the new NO_ROOT build option to create a meta file. NanoBSD also augments this record as files are created and removed. The meta file is then fed into makefs(8) to create a UFS image with the proper permissions. The UFS image, and sometimes a DOS FAT partition, are then passed to mkimg(1) to create the final SD image. The mtree manipulation has been written as a separate script to allow it to move into the base system where it could assist with other build orchestration tools (though the move has not happened yet). The detailed knowledge of how to build each embedded image (as well as some of the base images for qemu) has always been hard to enshrine. Crochet puts this knowledge into its builds. The FreeBSD release system puts it into its system. NanoBSD, prior to the current work, provided no way to access its knowledge of how to build images. The current state of this project allows the user to set a simple image type and have NanoBSD deal with all of the details needed to create that image type. This includes using the u-boot ports and installing the right files into a FAT partition so that FreeBSD can boot with ubldr(8), creating the right boot1.elf file for powerpc64 qemu booting, or the more familiar (though needlessly complicated) x86 setup. Previous versions of NanoBSD required too much specialized knowledge from the user. This work aims to concentrate the knowledge into a set of simple scripts for any build orchestration system to use. Finally, NanoBSD images in the past have needed very specific knowledge of the target device. Part of this is a legacy of the BIOS state-of-the-art a decade ago, which required very careful matching of the image to the actual device in the deployed system. Although relevant at the time, such systems are now vanishingly rare. Support for them will be phased out (though given the flexibility of NanoBSD, it can be moved to the few remaining examples in the tree and also partially covered by the generic image scripts). Today, the typical use case is to create an SD or microSD card image, and have the image resize itself on boot. NanoBSD now supports that workflow. In addition to these items, a number of minor improvements have been made: * Support for CPUTYPE-specialized builds. This includes both NanoBSD support as well as important bug fixes in the base system. * Support for marking MBR partitions as active. * Support for more partition types. Open tasks: 1. mkimg(8) needs to be augmented to create images for the i.MX6 and Allwinner (and others) SoCs. These SoCs require a boot image to be written after the MBR, but before the first partition starts. 2. The chroot functionality of some NanoBSD configurations has not yet been migrated for non-privileged builds. 3. The functionality to manipulate mtree(8) files should be moved into the base system for use by other build orchestration tools. 4. The script to create a bootable image from one or more trees of files, as well as some creation of those trees, should be moved into the base system for use with other build orchestration tools. 5. The growfs functionality works great for single images growing to the whole disk. However, NanoBSD would prefer that the boot FS/partition grow to approximately 1/2 the size of the media and another identical (or close) partition be created for the ping-ponging upgrades that NanoBSD is setup for. This needs to be implemented in the growfs rc.d(8) script. __________________________________________________________________ relaunchd Links Development tree on GitHub URL: https://github.com/mheily/relaunchd Contact: Mark Heily The relaunchd project provides a service management daemon that is similar to the original launchd introduced in Apple OS X. It is not limited to the original features of launchd, however: interesting work is being done to add support for launching programs in jails, passing socket descriptors from the host to a jail, and launching programs within a preconfigured capsicum(4) sandbox. Additionally, relaunchd uses UCL for its configuration files, so jobs can be defined in JSON or other formats supported by UCL. While there is still work to be done, most of the important features of the original launchd have been implemented, and relaunchd has been made available in the FreeBSD Ports Collection. It should still be considered experimental and not ready for production use, but everyone is welcome to try it, report issues, and contribute code or ideas for improvement. Open tasks: 1. Add support for restarting jobs if they crash. 2. Implement the cron(8) emulation feature. 3. Add support for monitoring files and directories for changes and launching jobs when changes are detected. 4. Finish things that are incomplete, such as support for jails and passing open socket descriptors to child processes. 5. Improve the documentation and provide more examples of usage. __________________________________________________________________ System Initialization and Service Management Links A Comparison of init(8) and rc(8) Replacements URL: http://www.daemonspawn.org/2016/01/a-comparison-of-alternatives-to= -init8.html Contact: Mark Heily Contact: Jonathan de Boyne Pollard Contact: Jordan Hubbard There are three active projects to provide an alternative to the traditional init(8) and rc(8) subsystems that manage the boot process and system services. There are a number of reasons driving the desire for change, including: * Faster boot times, made possible by launching services in parallel * Greater reliability, by ensuring that services are automatically restarted if they terminate unexpectedly * Simplified dependency management, using socket activation and similar techniques * The ability to launch services "on demand", and have them self-terminate when idle * Improved security, by removing the need to start common daemons as the root user Two of the projects, launchd and relaunchd, are based on the launchd(8) API introduced by Apple in Mac OS X. The NextBSD project has ported the original Apple source code by writing a Mach compatibility layer that allows launchd to run on FreeBSD. The relaunchd project started from scratch with the goal of creating a more modular, lightweight, and portable implementation of the launchd API. The third project, nosh, is a unique creation that borrows concepts from launchd, systemd, and several other Unix operating systems. While the FreeBSD Project has not made a decision to replace the current init(8) and rc(8) subsystems, the existence and active development of alternatives will continue to drive innovation in this space. Jordan Hubbard is the contact point for the NextBSD launchd, Jonathan de Boyne Pollard is the contact point for nosh, and Mark Heily is the contact point for relaunchd. __________________________________________________________________ The FreeBSD Foundation Links Foundation Website URL: http://www.FreeBSDFoundation.org/ FreeBSD Journal URL: http://FreeBSDJournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: On the advocacy front, the Foundation attended and sponsored EuroBSDcon, which took place Oct 1-4 (https://2015.eurobsdcon.org/) in Stockholm, Sweden. Two days prior, during the developer summit, Deb Goodkin ran a session on Recruiting to FreeBSD. The Foundation was also very active during the event itself; in addition to Deb, we had Dru Lavigne, Kirk McKusick, Erwin Lansing, Ed Maste, Hiroki Sato, Benedict Reuschling, and Edward Tomasz Napiera=B3a attend the conference. Deb and Ed gave a presentation on how the Foundation supports a BSD project. Kirk gave a presentation on "a Brief History of the BSD Fast File System," and he taught the two-day tutorial "Introduction to the FreeBSD Open-Source Operating System." Deb then attended the 2015 Grace Hopper Conference that was held in Houston, TX, October 14-16. The conference is for women in computing and most of the attendees were female computer science majors, female software developers, and college professors. The Foundation was proud to be a Silver Sponsor. The conference was very successful for us. Our presence allowed us to raise awareness of the Project, help recruit more women, and get more professors to include FreeBSD in their curriculum. George V. Neville-Neil traveled to Bangkok, Thailand to present talks on DTrace, FreeBSD, and teaching with DTrace. The talks were presented at Chulalongkorn University, which is the largest University in Thailand with the largest engineering school. The first talk was the practitioner's introduction to DTrace in which the technology, history and usage is explained without diving into all the kernel subsystems. The second was the sales pitch for teaching with Dtrace and with FreeBSD. The pitch was well received and there were some very good points made by the audience. The facts that the course materials are both open source and hosted on github were also well received. Kirk McKusick completed a 10-hour tutorial about FreeBSD for Pearson Education in their "Live Lesson" program. In particular, there is a great free snippet from that course comparing FreeBSD against Linux here: http://youtu.be/dTpqALCwQ1Y?a. Find out more about the whole session at: http://click.linksynergy.com/fs-bin/click?id=3DNZS3W7D*uS0&subid=3D&offe= rid=3D163217.1&type=3D10&tmpid=3D3559&RD_PARM1=3Dhttp%253A%252F%252Fwww.inf= ormit.com%252Fstore%252Fintroduction-to-the-freebsd-open-source-operating-s= ystem-9780134305868. Anne Dickison resumed the Faces of FreeBSD series with interviews featuring Michael Dexter and Erin Clark. She also continued to produce and distribute FreeBSD materials for conferences, as well as advocating for FreeBSD over our social channels. George V. Neville-Neil headed up the latest Silicon Valley Vendor and Developer Summit, November 2-3, at the NetApp campus in Sunnyvale, California. Topics of discussion ranged over new developments in persistent memory, the use of FreeBSD by a company that builds rackscale systems, developments in our compiler and tool suite, as well as others. Additional Foundation Board and Staff attending the summit included: Deb Goodkin, Glen Barber, Justin T. Gibbs, Kirk McKusick, Ed Maste, and Hiroki Sato. The complete schedule, and some of the slides, are available on the FreeBSD Wiki https://wiki.freebsd.org/201511VendorDevSummit . Notes from the always lively "Have/Need/Want session" are available at https://wiki.freebsd.org/201511VendorDevSummit/HaveNeedWant . While in the Bay Area, some Foundation members visited commercial users of FreeBSD to help understand their needs, update them on the work the Foundation is doing, and facilitate collaboration between them and the Project. We were a sponsor of the 2015 OpenZFS Developer Summit, which took place October 19-20, in San Francisco, CA. Justin T. Gibbs and Kirk McKusick attended the conference. Justin T. Gibbs continued his semester long class teaching Intro to Computer Science using FreeBSD at a middle school. Ed Maste, Edward Tomasz Napiera=B3a, and Konstantin Belousov continue to make progress on Foundation funded development projects. More specifically: * Ed Worked on a number of items relating to the tool chain: LLD linker, ELF Tool Chain components, and LLDB debugger, and tested, integrated, and merged outstanding UEFI work. * Edward finished work on the reroot project as well as spending some time on a certificate-transparency port. He also implemented a prototype to support disk IO limit in RCTL. * Konstantin rewrote the out of memory killer logic, which, in particular, fixed FreeBSD operation on systems without swap, especially systems with very little memory. The latter are becoming more and more common with the popularity of embedded ARM platforms where FreeBSD runs, but it also affects large systems which are usually configured without swap. He also finalized and committed the shared page support for the ARMv7 and ARMv8 systems. This allows for a non-executable stack on ARMv7, and a much faster userspace gettimeofday(2) for both, similar to x86. Ed Maste presented a FreeBSD/arm64 talk and a hands-on demo at ARM Techcon, which took place November 10-12, 2015, in Santa Clara, CA. We continued publishing our monthly newsletters and acquiring new company testimonials about using FreeBSD, including from Verisign and Nginx. Anne Dickison, Dru Lavigne, and Glen Barber represented the Foundation at USENIX LISA '15, which took place November 3-8, in Washington D.C.. The Foundation had a booth in the Expo Hall and participated in a BoF. Besides connecting with current community members, we spoke with attendees who were interested in getting involved with the Project and helped set them on the correct path. We also took the opportunity to remind those who had not used FreeBSD in a while what they were missing. Glen also attended the USENIX Release Engineering Summit, which was co-located with LISA '15. We published the Sept/Oct and Nov/Dec issues of the FreeBSD Journal. George V. Neville-Neil and Robert Watson announced the release of their TeachBSD initiative: http://teachbsd.org/. TeachBSD offers a set of open source reusable course materials designed to allow others to teach both university students and software practitioners FreeBSD operating system fundamentals. The Foundation is proud to have partly sponsored their efforts to teach the initial graduate level course on operating systems with tracing at the University of Cambridge. Deb Goodkin invited a representative from the Outreachy program to talk at the Ottawa FreeBSD Developer Summit about the program and how we can get involved. Deb also started discussions with CS professors from the University of Colorado, Boulder to offer some Intro to FreeBSD workshops. Glen Barber continued wearing many hats to support to the Project. For Release Engineering: * Added support for building BANANAPI, CUBIEBOARD, and CUBIEBOARD2 arm images. * Deprecated the use of MD5 checksums for verifying installation media downloaded from the FreeBSD Project mirrors. * Various miscellaneous updates and fixes to release build code. * Continued providing regular development snapshot builds. Under Systems Administration: * Assisted the Admins team with migrating various services to two new colocation facilities near Sunnyvale, generously provided by RootBSD and LimeLight Networks. * Moved email services for the Foundation to a new server. Ed Maste attended the Reproducible Builds World Summit, which took place in Athens, Greece, December 1-3, 2015. We wrapped up our 2015 fundraising efforts with our End-of-Year fundraising campaign by participating in #GivingTuesday, and continuing with weekly email and social media requests for support of the Foundation. Final fundraising numbers will be available in Q1 2016. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJWstP3AAoJECjZpvNk63USG3wMHArdbptYhXljtbfGKDUWPJjs ip1eIqDxywocb8P0VZ/NqSdASyuWXyHZGPxjFhE9BIAvUKeTCJPsJLWPqZyiv2Qj 856dYOTyOnzkMbGaN9dPTdH2ymrsfRqQKVr1DP+7la6IdFpvlUZ2RwxBX7qPs73/ yMy640tfC+8VVuKt3EjZdbN6hBbeSoiZ0b8pJ+GP42CKhwSYW86wrtMSudjNRZzZ lBYSJJ9RPh76Z6Qjcv8mBioEEl+XZyadzErM7rDNpiIRV4Ucr3ez24sUiGl30+4G SpniAKmXBL+6wWm9jhWfm6obOQJecTc7ydc5zT0Qb8rXIBPsYGxOYxujM1zqWbqt 4TjAqnzkanTqOfZDMzvpMj8dBk9gUxjHloQ66pfNx6UeV0cCbSh6k/vIQdTbvGAn NknGKyYQ8n0AQCHht3sXdOcGCca0gHq0uDEWR71woqTReXAjCdAEHNSE+XnnHWYa lCgsuNe5PWtSfYuyMu95X863us7mShf8277hQzNlft8ILTY=3D =3D7aRE -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Thu Feb 4 10:39:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F498A9C2BC for ; Thu, 4 Feb 2016 10:39:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (unknown [IPv6:2001:388:f000::349d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 307881E66 for ; Thu, 4 Feb 2016 10:39:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u14Aclpe051409 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Feb 2016 21:38:54 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u14AcgQn003700 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Feb 2016 21:38:42 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u14Acfj4003699; Thu, 4 Feb 2016 21:38:41 +1100 (AEDT) (envelope-from peter) Date: Thu, 4 Feb 2016 21:38:41 +1100 From: Peter Jeremy To: Konstantin Belousov Cc: freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160204103841.GA3630@server.rulingia.com> References: <56B06EB9.2090406@multiplay.co.uk> <20160202125237.GS91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20160202125237.GS91220@kib.kiev.ua> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Thu, 04 Feb 2016 21:38:54 +1100 (AEDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 10:39:01 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Feb-02 14:52:37 +0200, Konstantin Belousov wr= ote: >Please gather the information listed at >https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern= eldebug-deadlocks.html Interestingly, as soon as I enable INVARIANTS, my kernel will no longer boo= t. All the other options listed there are OK. The console output ends: TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1150026690 Hz quality 800 hwpc_core: unknown PMC architecture: 0 hwpmc: SOFT/16/64/0x67 init_KVMCLOCK_tc: 0x0000000b KVM-style paravirtualized clock detected. Timecounter "KVMCLOCK" frequency 1000000000 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from zfs:zroot []... <> Unfortunately, I don't have write access to the console so I can't do anything other than reboot at this point. (This is 10-stable/amd64 r295088). If I have some spare time, I'll try reproducing this in a local VBox over the next few days. --=20 Peter Jeremy --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWsyoxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0YrcP/RNDfkwkW1rWYFWpYRWKOess khBG/d269qEvt/ElWfwlLRGlgWe8AnlPLjgXPcxwtQ5erED36qor/RC+fcTfT3Cz ON1WxUmbpHSVO182pZBvLA7pJgJjyLS4Ea8vHmfpgy6NBIJ0t0xr+fw8/RZJ8WD1 aI4oYGakV2DcFahJgMTVdbCxORrrx0pyL8yN01AgBL2OCu3zyWyrq1XZzhq6p1Ay tc8om7l+nNmS3ZYNK+Yo4UD7NJtd2h370f59qNbgrZNBs8+T2k0PbOOCbrerS8yQ jkvv7jTsw/6CcayvG2ZCIZXIknHnkIOoMEvWrdyiEsF3DxX1iQFCMlocr3jl2eqp ZvRJCUMRfA3pndKP/LxXYwclo8PZOLGipcHeDv1YZcA0KLjlgo0B64uQ7zbBC/vS O5PqKJy01sHIj0MDtSXBz9qRloOaatL4PhMWWQj247gkXOHpnGY9JKgZNAipCYYG H9/WxCvBN+bRbFiYqqhqet79rDC9I/g474IL0a011PJJnySbMafmBS+aze76qhzq ruU+W5f/fxI6unZw2D09IvKMYTSDoyOTHyDbDFeEcGZ15H2/wofydAGB57hrpIrU ywsxIEQNaONLPb7YZofZVHM5TTZVfYkPHDuS/4sgK2FC/IQkBVnN28JAPeWOwL+o rnNGlRbAwHRl15nM1J40 =mquW -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-stable@freebsd.org Thu Feb 4 10:42:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FE0CA9C509 for ; Thu, 4 Feb 2016 10:42:34 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 757CB663 for ; Thu, 4 Feb 2016 10:42:34 +0000 (UTC) (envelope-from peter@rulingia.com) Received: by mailman.ysv.freebsd.org (Postfix) id 74195A9C508; Thu, 4 Feb 2016 10:42:34 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73AD8A9C507 for ; Thu, 4 Feb 2016 10:42:34 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (unknown [IPv6:2001:388:f000::349d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB539661 for ; Thu, 4 Feb 2016 10:42:32 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u14AgNq1051419 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Feb 2016 21:42:30 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u14AgH8k003761 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Feb 2016 21:42:17 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u14AgFrE003760; Thu, 4 Feb 2016 21:42:15 +1100 (AEDT) (envelope-from peter) Date: Thu, 4 Feb 2016 21:42:15 +1100 From: Peter Jeremy To: Shane Ambler Cc: stable@FreeBSD.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160204104215.GA115@server.rulingia.com> References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> <20160203190323.GC78969@server.rulingia.com> <56B2A64C.3050107@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <56B2A64C.3050107@ShaneWare.Biz> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Thu, 04 Feb 2016 21:42:30 +1100 (AEDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 10:42:34 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Feb-04 11:45:56 +1030, Shane Ambler wrote: >Going by figures shown in top, ARC is usually in the 1500M to 2000M >range but when wired gets over 6GB I often see ARC drop to 500MB which >I now realise matches arc_min. That's definitely abnormal. You might like to run "vmstat -mz" when the system is running normally and as the non-ARC wired memory increases to identify where the RAM is going. --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWsysHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0IrIP/0woBcaSxI+kL/8qo3IkX6Cl Nh15iUt2RCEzaaz7QL7NiVQw6nZ24XKJr5Q4kAqDpQAykk3jKYoRO/YdvxreGTAr /iN60YJbBOJoCYmmjhGcCmWAj+hkpggSSc0cUYeXSEVfvB2jdUezpN9Sigdy9Ati /6uVSi0gXq1E7fAC73n3AkIYCp53C2bj12nNCt9WnChbl4daZhgclloRKLSVkD0O VA9TcwQ8CNh5pU3nkgt+b7dl338/E+HIYHAvtj6mEw3wD0uE8MpYytkVfqxd0bdC 8b0Qz3+QN/3puxcBqJ6T1mhzrLBnIZw20yZepX4430dHTMyZDDQIol/TlG4LW6Iy aZ+C9v5sWZRJBP2A6sJIPy58RlzmkljN7/8hYP4a2JylQbBU/ikw7KsvwyDQWk0V axwclS8ZaAsXOmOB3LOY4vlME1kry/pwbc5gzJhDx3EeeDy3livarZQHBvs9BAVR zJvOuFCawwol/N3tF5DzZpsz/xpWAkMMFFhORGwVa863XSvQ7ObfdTtTdveAc0Ut zVUYzfBY8MDeR7yedcioAsg0mEeHshmsls+vgOHmgBD5z5HWBKr+rTZS3Lni5Cxo pP/Nye6v5p0Wu1fCN6rbOm/py0xaV0E4woWYdscuT/1Bu0+1bWOkFXurp10AgxnW t0uxn4eBhabO6glwRKds =UZyy -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@freebsd.org Thu Feb 4 13:00:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88789A9B43F for ; Thu, 4 Feb 2016 13:00:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC16619 for ; Thu, 4 Feb 2016 13:00:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 6AB9FA9B43E; Thu, 4 Feb 2016 13:00:35 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50E11A9B43D for ; Thu, 4 Feb 2016 13:00:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 11F25618 for ; Thu, 4 Feb 2016 13:00:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aRJWQ-0009E3-3z; Thu, 04 Feb 2016 16:00:30 +0300 Date: Thu, 4 Feb 2016 16:00:30 +0300 From: Slawa Olhovchenkov To: Luigi Rizzo Cc: Adrian Chadd , "stable@freebsd.org" Subject: Re: 82576 + NETMAP + VLAN Message-ID: <20160204130029.GC88527@zxy.spb.ru> References: <20151018185639.GF42243@zxy.spb.ru> <20151018210049.GT6469@zxy.spb.ru> <20151022163519.GF6469@zxy.spb.ru> <20160202204446.GQ88527@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160202204446.GQ88527@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 13:00:35 -0000 On Tue, Feb 02, 2016 at 11:44:47PM +0300, Slawa Olhovchenkov wrote: > On Thu, Oct 22, 2015 at 11:24:53AM -0700, Luigi Rizzo wrote: > > > On Thu, Oct 22, 2015 at 11:12 AM, Adrian Chadd wrote: > > > On 22 October 2015 at 09:35, Slawa Olhovchenkov wrote: > > >> On Sun, Oct 18, 2015 at 07:45:52PM -0700, Adrian Chadd wrote: > > >> > > >>> Heh, file a bug with luigi; it should be defined better inside netmap itself. > > >> > > >> I am CC: luigi. > > >> > > >> Next question: do kevent RX/TX sync? > > >> In my setup I am need to manual NIOCTXSYNC/NIOCRXSYNC. > > > > > > Hi, > > > > > > Nope. kqueue() doesn't do the implicit sync like poll() does; it's > > > just the notification path. > > > > actually not. When the file descriptor is registered there > > is an implicit sync, and there is another one when an event > > is posted for the file descriptor. > > > > unless there are bugs, of course. > > I found strange behaivor: > > 1. open netmap and register in main thread > 2. kevent register in different thread > 3. result: got event by kevent but no ring sinc (all head,tail,cur > still 0). > > Is this normal? Or is this bug? > > open and registering netmap in same thread as kevent resolve this. Also, kevent+netmap deadlocked for me: PID TID COMM TDNAME KSTACK 1095 100207 addos - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_timedwait_sig+0x10 _sleep+0x238 kern_nanosleep+0x10e sys_nanosleep+0x51 amd64_syscall+0x40f Xfast_syscall+0xfb 1095 100208 addos worker#0 mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb 1095 100209 addos worker#1 mi_switch+0xe1 turnstile_wait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_notify+0x55 netmap_pipe_txsync+0x156 netmap_poll+0x400 netmap_knrw+0x6e kqueue_register+0x799 kern_kevent+0x158 sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb 1095 100210 addos worker#2 mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb 1095 100211 addos worker#NOIP mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb 1095 100212 addos balancer mi_switch+0xe1 turnstile_wait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_notify+0x2a netmap_pipe_rxsync+0x54 netmap_poll+0x774 netmap_knrw+0x6e kern_kevent+0x5cc sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb From owner-freebsd-stable@freebsd.org Thu Feb 4 15:09:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 186B9A99118 for ; Thu, 4 Feb 2016 15:09:41 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 DEB15BEF for ; Thu, 4 Feb 2016 15:09:40 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) 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.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aRLXO-0003Tl-2s for freebsd-stable@FreeBSD.ORG; Thu, 04 Feb 2016 15:09:38 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aRLXO-0009T0-0s for freebsd-stable@FreeBSD.ORG; Thu, 04 Feb 2016 15:09:38 +0000 To: freebsd-stable@FreeBSD.ORG Subject: Recent -STABLE crashes out of swap at 3am every day Message-Id: From: Pete French Date: Thu, 04 Feb 2016 15:09:38 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 15:09:41 -0000 I recently updates a system to -STABLE, which ahdnt been updates in 9 months or so. It started locking up at 3am every day. I have updated to -STABLE form this mornign and verified that this still happens. The porobel is the 'periodic daily' process. I have veriied this by running it by hand. What happens is that Swap space starts to fill up. Wathcing in top, however, there are no large processes running. I also start to see these messages during the run... Feb 4 14:57:07 toybox kernel: sonewconn: pcb 0xfffff8000eee6000: Listen queue overflow: 31 already in queue awaiting acceptance (1 occurrences) Feb 4 14:58:07 toybox kernel: sonewconn: pcb 0xfffff8000eee6000: Listen queue overflow: 31 already in queue awaiting acceptance (26 occurrences) Feb 4 14:59:07 toybox kernel: sonewconn: pcb 0xfffff8000eee6000: Listen queue overflow: 31 already in queue awaiting acceptance (193 occurrences) The systems is mainly ZFS, booting from a small UFS partition for /. It has 2GB of RAM only, but the ARC is limited to 512 meg. It primarttily runs exim/clamav/spamd/mailman - these are failmy memory hungry I realise, and the machine usually runs with a few hundred meg swapped out, but iit has been very reliable until the most recent upgrade. I dont knwo preciusely what the periodc scripts do, but I underrstand the use a substantial amount of ;find' and it is this pricess which shows up when runing, usually in the state zio->io_ which is what I would expect. The find process is not using a lot of memory, however. I dont see this on any other achines runnign the most recemt -STABLE, but then again this is my only machine with so little memory in it. What can I do to tracve anmd fix this ? My obvious intiail move is to disable the daily periopdic run, but thats hardly a solution! help? -pete. From owner-freebsd-stable@freebsd.org Thu Feb 4 16:58:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 679AEA9BAD3; Thu, 4 Feb 2016 16:58:10 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 219B5113E; Thu, 4 Feb 2016 16:58:09 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id u14GtUax077373; Thu, 4 Feb 2016 10:55:31 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 8C88218C859; Thu, 4 Feb 2016 10:55:25 -0600 (CST) Subject: Re: 10.2-RELEASE-p12 pf+GRE crashing To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org References: <56B285B0.8010306@shrew.net> <56B29FA0.4080000@shrew.net> From: Matthew Grooms Message-ID: <56B38313.8070004@shrew.net> Date: Thu, 4 Feb 2016 10:57:55 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B29FA0.4080000@shrew.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Thu, 04 Feb 2016 10:55:31 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 16:58:10 -0000 On 2/3/2016 6:47 PM, Matthew Grooms wrote: > This turned out to be another issue that was patched in head but not > back ported to stable. I can't explain why it didn't get tripped when > GRE tunnels were disabled. With the patch applied, I can reload my > rule sets again without crashing ... > > https://svnweb.freebsd.org/base?view=revision&revision=264689 > I wanted to clarify in case another user runs into this issue and searches the mailing list history for a solution: The patch I applied to fix this particular kernel crash wasn't 264689, it was ... https://svnweb.freebsd.org/base?view=revision&revision=264915 Sorry for the misinformation. I cut and pasted the wrong link. -Matthew > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:219 > #1 0xffffffff807c81f2 in kern_reboot (howto=260) at > ../../../kern/kern_shutdown.c:451 > #2 0xffffffff807c85d5 in vpanic (fmt=, ap= optimized out>) > at ../../../kern/kern_shutdown.c:758 > #3 0xffffffff807c8463 in panic (fmt=0x0) at > ../../../kern/kern_shutdown.c:687 > #4 0xffffffff80bdc10b in trap_fatal (frame=, > eva=) at ../../../amd64/amd64/trap.c:851 > #5 0xffffffff80bdc40d in trap_pfault (frame=0xfffffe0000233a80, > usermode=) at ../../../amd64/amd64/trap.c:674 > #6 0xffffffff80bdbaaa in trap (frame=0xfffffe0000233a80) > at ../../../amd64/amd64/trap.c:440 > #7 0xffffffff80bc1fa2 in calltrap () at > ../../../amd64/amd64/exception.S:236 > #8 0xffffffff809c07f4 in pfr_detach_table (kt=0x0) at > ../../../netpfil/pf/pf_table.c:2047 > #9 0xffffffff809a91f4 in pf_empty_pool (poola=0xffffffff813c3d68) > at ../../../netpfil/pf/pf_ioctl.c:354 > #10 0xffffffff809ab3e5 in pfioctl (dev=, > cmd=, > addr=0xfffff8005eaf6800 "", flags=, td= optimized out>) > at ../../../netpfil/pf/pf_ioctl.c:2189 > #11 0xffffffff806b5659 in devfs_ioctl_f (fp=0xfffff8000a2927d0, > com=3295691827, > data=0xfffff8005eaf6800, cred=, > td=0xfffff8000a25f000) > at ../../../fs/devfs/devfs_vnops.c:785 > #12 0xffffffff8081b805 in kern_ioctl (td=0xfffff8000a25f000, fd= optimized out>, > com=2) at file.h:320 > #13 0xffffffff8081b500 in sys_ioctl (td=0xfffff8000a25f000, > uap=0xfffffe0000234b40) > at ../../../kern/sys_generic.c:718 > #14 0xffffffff80bdca27 in amd64_syscall (td=0xfffff8000a25f000, traced=0) > at subr_syscall.c:134 > #15 0xffffffff80bc228b in Xfast_syscall () at > ../../../amd64/amd64/exception.S:396 > #16 0x0000000800dd9fda in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > -Matthew > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Feb 4 18:47:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81D3DA9B9E3 for ; Thu, 4 Feb 2016 18:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 60B4385A for ; Thu, 4 Feb 2016 18:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5DF31A9B9E2; Thu, 4 Feb 2016 18:47:21 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D7DEA9B9E1 for ; Thu, 4 Feb 2016 18:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 269F2859 for ; Thu, 4 Feb 2016 18:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id rs20so22428940igc.0 for ; Thu, 04 Feb 2016 10:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gbC9ionT2WzSQTneJAckqoVoSNsU1e4ZuDzadkL7Jj4=; b=lWXZ0tZM2XaKYfoQiTefr/fZPx1b89xS0v3DiDTcKvoQ62i1voB09pyg9sn6A89bty YLSMK//IiYj2Ge/39SoHAgnCxKCUSVOt/JYonC1QBkrvxbVfrF8bvhBuQsyNg4gCdVR0 VjzwXHBcDI4uP/+11KvVsO+8hMqh0hgWonRhAHRXYE7vBavJd+CDNDgnNmeu6V+2Lh+0 6BEt/jgSgv0jvjBFcE6E6esbYMHKmNMn0LWEg8J+bCf99g2f2qtxH6gtLQfFjXLPS+Sb ALGUqKGzOy0PLULfs1ek1OgZ6V/Fx0p1AR9NYR5Mxa4+UIKdaT00+IL1gF3OzdClTHhU 9S0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gbC9ionT2WzSQTneJAckqoVoSNsU1e4ZuDzadkL7Jj4=; b=eu/791cdHLf2eZ2RaFCCN8HxIBqi1NiUJsbGBtdBmwx2qp7Pa/jAN5J/MGyNehI0s2 EwkHxYUXTmQ6A0qx6IAW2g0dDFdlnjqD9+cvojHeIrHK2AjyYObzfQ4A4Ui+jPrQyv9s qlBLZfAkeJZREPnE8cDVfH7Z4ceksueXqCRX1h7JMVJ8Sxa2towU09DqFFQdud5+cMA2 nTzdB4Oy8tvD1jxBBhdappizRWw+mkBMUpqoZwLJE/zEfP4s62NMt8HbC9/iFaObacdq aQkKyrC1cKRxmsqOyJvJsj3xKKqd7GwJBz2qgpk73bC7bLG2PC70nS1fX9tmrZgbTDLW 6nXA== X-Gm-Message-State: AG10YOTGOhGbAVbVBWZQv0fB1luXPnPuGMvZInfewUs2oggr+JACKG/pq8BBQzGCDbvvba9tbmijtKgtCaCFrQ== MIME-Version: 1.0 X-Received: by 10.50.178.178 with SMTP id cz18mr11139015igc.37.1454611640560; Thu, 04 Feb 2016 10:47:20 -0800 (PST) Received: by 10.36.14.19 with HTTP; Thu, 4 Feb 2016 10:47:20 -0800 (PST) In-Reply-To: <20160204130029.GC88527@zxy.spb.ru> References: <20151018185639.GF42243@zxy.spb.ru> <20151018210049.GT6469@zxy.spb.ru> <20151022163519.GF6469@zxy.spb.ru> <20160202204446.GQ88527@zxy.spb.ru> <20160204130029.GC88527@zxy.spb.ru> Date: Thu, 4 Feb 2016 10:47:20 -0800 Message-ID: Subject: Re: 82576 + NETMAP + VLAN From: Adrian Chadd To: Slawa Olhovchenkov Cc: Luigi Rizzo , "stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 18:47:21 -0000 I've no time to help with this, I'm sorry :( -a On 4 February 2016 at 05:00, Slawa Olhovchenkov wrote: > On Tue, Feb 02, 2016 at 11:44:47PM +0300, Slawa Olhovchenkov wrote: > >> On Thu, Oct 22, 2015 at 11:24:53AM -0700, Luigi Rizzo wrote: >> >> > On Thu, Oct 22, 2015 at 11:12 AM, Adrian Chadd wrote: >> > > On 22 October 2015 at 09:35, Slawa Olhovchenkov wro= te: >> > >> On Sun, Oct 18, 2015 at 07:45:52PM -0700, Adrian Chadd wrote: >> > >> >> > >>> Heh, file a bug with luigi; it should be defined better inside net= map itself. >> > >> >> > >> I am CC: luigi. >> > >> >> > >> Next question: do kevent RX/TX sync? >> > >> In my setup I am need to manual NIOCTXSYNC/NIOCRXSYNC. >> > > >> > > Hi, >> > > >> > > Nope. kqueue() doesn't do the implicit sync like poll() does; it's >> > > just the notification path. >> > >> > actually not. When the file descriptor is registered there >> > is an implicit sync, and there is another one when an event >> > is posted for the file descriptor. >> > >> > unless there are bugs, of course. >> >> I found strange behaivor: >> >> 1. open netmap and register in main thread >> 2. kevent register in different thread >> 3. result: got event by kevent but no ring sinc (all head,tail,cur >> still 0). >> >> Is this normal? Or is this bug? >> >> open and registering netmap in same thread as kevent resolve this. > > Also, kevent+netmap deadlocked for me: > > PID TID COMM TDNAME KSTACK > 1095 100207 addos - mi_switch+0xe1 sleepq_catc= h_signals+0xab sleepq_timedwait_sig+0x10 _sleep+0x238 kern_nanosleep+0x10e = sys_nanosleep+0x51 amd64_syscall+0x40f Xfast_syscall+0xfb > 1095 100208 addos worker#0 mi_switch+0xe1 sleepq_catc= h_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keven= t+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb > 1095 100209 addos worker#1 mi_switch+0xe1 turnstile_w= ait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_n= otify+0x55 netmap_pipe_txsync+0x156 netmap_poll+0x400 netmap_knrw+0x6e kque= ue_register+0x799 kern_kevent+0x158 sys_kevent+0x12a amd64_syscall+0x40f Xf= ast_syscall+0xfb > 1095 100210 addos worker#2 mi_switch+0xe1 sleepq_catc= h_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keven= t+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb > 1095 100211 addos worker#NOIP mi_switch+0xe1 sleepq_catc= h_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keven= t+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb > 1095 100212 addos balancer mi_switch+0xe1 turnstile_w= ait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_n= otify+0x2a netmap_pipe_rxsync+0x54 netmap_poll+0x774 netmap_knrw+0x6e kern_= kevent+0x5cc sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb From owner-freebsd-stable@freebsd.org Thu Feb 4 18:47:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 578D2A9BA03 for ; Thu, 4 Feb 2016 18:47:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 35A57999 for ; Thu, 4 Feb 2016 18:47:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 34DA1A9BA01; Thu, 4 Feb 2016 18:47:35 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34687A9BA00 for ; Thu, 4 Feb 2016 18:47:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 F07E1997 for ; Thu, 4 Feb 2016 18:47:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x231.google.com with SMTP id 5so67240386igt.0 for ; Thu, 04 Feb 2016 10:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5e3DrHPVfPwGxbigtV8ktAIVfXt8TKGekud/hAL+3AY=; b=lLAMdd2y28B0ISDCx0EPSuGNm85BaP7R2cHlVFo+WvJ4E4mGD0YlD2uaGyOkI8mGQo xO27cMtTDW9L771SDR0NyIKgRIyvEMYnba1/usCnr66mzwJoO4yHZZ3PQ9bw8jbuskez FmHicM4DqXGRY65JU8wJfaJH82YVkZgmPderG2x2rSKlCHb1GhLkq7a9pmM6xp0IngyX ao3rDuZNDxaeA2UGaeH9DLHQ/Jc3q160qbPK1eB/sbRP2k9Y0EaoGJxP3G06am1eEsSP opH8zdUJCrC7PVJGUTVvHWqni6TJ8YNWVH4QjqgLLKcP3SbtzAsAEY8WTBzeeqX7U4EP zy6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5e3DrHPVfPwGxbigtV8ktAIVfXt8TKGekud/hAL+3AY=; b=G8Brhs9CTUOgDjI7QlbD8a5mRQ9tkF3Qe8RgfQRRdays0ootJhvRXNNZxFtIKPsfbc o2sa+7KOd888m6h7v+PUxdK5MP8oME7r556XL1Bc4yLzRxbYuVw5hBILdTZKEH+c9Ll7 UgOi8UtS48njpC8sGGuAHI54vI5IKEqUqbbc5ldrwZWCxN6zAGG7jMgWmFx7LtDffaCF nMZpCn15YsOwCeTtxo6cu33lYX0x5QrfzQ1qLPB4VSlvJwX1TzgzHA7ElLj25Ws7c/Uq Js2FGhEDhKLGpzh+bgfs/Hr0VbLhnlHBwK0nYuci25ynX9w6pyyL99z+P6OWTm404Mfa AxXw== X-Gm-Message-State: AG10YOTfOawlv507dzyQc7WHVOgmV5cQo9d7sNv5BEwcRlVneIBZn6HWDz5wJLtfPh3eNsDIHb/cT6/vj0+8fA== MIME-Version: 1.0 X-Received: by 10.50.171.225 with SMTP id ax1mr5288334igc.61.1454611654448; Thu, 04 Feb 2016 10:47:34 -0800 (PST) Received: by 10.36.14.19 with HTTP; Thu, 4 Feb 2016 10:47:34 -0800 (PST) In-Reply-To: References: <20151018185639.GF42243@zxy.spb.ru> <20151018210049.GT6469@zxy.spb.ru> <20151022163519.GF6469@zxy.spb.ru> <20160202204446.GQ88527@zxy.spb.ru> <20160204130029.GC88527@zxy.spb.ru> Date: Thu, 4 Feb 2016 10:47:34 -0800 Message-ID: Subject: Re: 82576 + NETMAP + VLAN From: Adrian Chadd To: Slawa Olhovchenkov Cc: Luigi Rizzo , "stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 18:47:35 -0000 .. but if it does, can you enable witness and see what it reports as lock order violations? -a On 4 February 2016 at 10:47, Adrian Chadd wrote: > I've no time to help with this, I'm sorry :( > > > -a > > > On 4 February 2016 at 05:00, Slawa Olhovchenkov wrote: >> On Tue, Feb 02, 2016 at 11:44:47PM +0300, Slawa Olhovchenkov wrote: >> >>> On Thu, Oct 22, 2015 at 11:24:53AM -0700, Luigi Rizzo wrote: >>> >>> > On Thu, Oct 22, 2015 at 11:12 AM, Adrian Chadd wrote: >>> > > On 22 October 2015 at 09:35, Slawa Olhovchenkov wr= ote: >>> > >> On Sun, Oct 18, 2015 at 07:45:52PM -0700, Adrian Chadd wrote: >>> > >> >>> > >>> Heh, file a bug with luigi; it should be defined better inside ne= tmap itself. >>> > >> >>> > >> I am CC: luigi. >>> > >> >>> > >> Next question: do kevent RX/TX sync? >>> > >> In my setup I am need to manual NIOCTXSYNC/NIOCRXSYNC. >>> > > >>> > > Hi, >>> > > >>> > > Nope. kqueue() doesn't do the implicit sync like poll() does; it's >>> > > just the notification path. >>> > >>> > actually not. When the file descriptor is registered there >>> > is an implicit sync, and there is another one when an event >>> > is posted for the file descriptor. >>> > >>> > unless there are bugs, of course. >>> >>> I found strange behaivor: >>> >>> 1. open netmap and register in main thread >>> 2. kevent register in different thread >>> 3. result: got event by kevent but no ring sinc (all head,tail,cur >>> still 0). >>> >>> Is this normal? Or is this bug? >>> >>> open and registering netmap in same thread as kevent resolve this. >> >> Also, kevent+netmap deadlocked for me: >> >> PID TID COMM TDNAME KSTACK >> 1095 100207 addos - mi_switch+0xe1 sleepq_cat= ch_signals+0xab sleepq_timedwait_sig+0x10 _sleep+0x238 kern_nanosleep+0x10e= sys_nanosleep+0x51 amd64_syscall+0x40f Xfast_syscall+0xfb >> 1095 100208 addos worker#0 mi_switch+0xe1 sleepq_cat= ch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keve= nt+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb >> 1095 100209 addos worker#1 mi_switch+0xe1 turnstile_= wait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_= notify+0x55 netmap_pipe_txsync+0x156 netmap_poll+0x400 netmap_knrw+0x6e kqu= eue_register+0x799 kern_kevent+0x158 sys_kevent+0x12a amd64_syscall+0x40f X= fast_syscall+0xfb >> 1095 100210 addos worker#2 mi_switch+0xe1 sleepq_cat= ch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keve= nt+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb >> 1095 100211 addos worker#NOIP mi_switch+0xe1 sleepq_cat= ch_signals+0xab sleepq_wait_sig+0xf _sleep+0x27d kern_kevent+0x401 sys_keve= nt+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb >> 1095 100212 addos balancer mi_switch+0xe1 turnstile_= wait+0x42a __mtx_lock_sleep+0x26b knote+0x38 freebsd_selwakeup+0x8b netmap_= notify+0x2a netmap_pipe_rxsync+0x54 netmap_poll+0x774 netmap_knrw+0x6e kern= _kevent+0x5cc sys_kevent+0x12a amd64_syscall+0x40f Xfast_syscall+0xfb From owner-freebsd-stable@freebsd.org Thu Feb 4 19:53:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2D79A9C319 for ; Thu, 4 Feb 2016 19:53:09 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mx1b.lautre.net (etna.lautre.net [80.67.160.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.lautre.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B724A1085 for ; Thu, 4 Feb 2016 19:53:09 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry@pompo.net) by mx1b.lautre.net (Postfix) with ESMTPSA id 8DD357E0EB; Thu, 4 Feb 2016 20:53:06 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id 9291853A8EB; Thu, 4 Feb 2016 20:53:05 +0100 (CET) Date: Thu, 4 Feb 2016 20:53:05 +0100 From: Thierry Thomas To: Karl Denninger Cc: freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160204195305.GX8270@graf.pompo.net> Mail-Followup-To: Karl Denninger , freebsd-stable@freebsd.org References: <20160202183913.GG8270@graf.pompo.net> <56B1B1E9.2090707@ShaneWare.Biz> <20160203164740.GO8270@graf.pompo.net> <56B230E7.9050107@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56B230E7.9050107@denninger.net> X-Operating-System: FreeBSD 10.3-PRERELEASE amd64 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xF1C516B3C8359753 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Feb 2016 19:53:10 -0000 Le mer 3 fév 16 à 17:55:03 +0100, Karl Denninger écrivait : > (Whistling.....) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 > > (see if that helps you) Thanks, I'll check it! -- Th. Thomas. From owner-freebsd-stable@freebsd.org Fri Feb 5 08:39:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90621A4740D for ; Fri, 5 Feb 2016 08:39:48 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (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 5DAF41861 for ; Fri, 5 Feb 2016 08:39:48 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 834D2AF32 for ; Fri, 5 Feb 2016 09:39:45 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from iron.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id C3F57AF2C for ; Fri, 5 Feb 2016 09:39:44 +0100 (CET) Date: Fri, 5 Feb 2016 09:37:13 +0100 From: Daniel Bilik To: freebsd-stable@freebsd.org Subject: Re: stf(4) on 10-stable Message-Id: <20160205093713.1c1453f9b5d06a6b366c44db@neosystem.cz> In-Reply-To: <20160114104937.57e14705ea345ad877db2ed5@neosystem.cz> References: <20151216170418.3c2ec09dfb87e9d09a026efd@neosystem.cz> <20160113091730.381f94e94fa5cb2b90960111@neosystem.cz> <20160114104937.57e14705ea345ad877db2ed5@neosystem.cz> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 05 Feb 2016 08:39:48 -0000 On Thu, 14 Jan 2016 10:49:37 +0100 Daniel Bilik wrote: >> Should I create PR for this? > Created: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206231 Seems that 10-stable has just entered beta1, so unless some effort is put into fixing this, 10.3-release is probably gonna ship with broken 6to4 connectivity. -- Dan From owner-freebsd-stable@freebsd.org Fri Feb 5 08:57:25 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 911A6A47D83 for ; Fri, 5 Feb 2016 08:57:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 245F6272 for ; Fri, 5 Feb 2016 08:57:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.d.allbsd.org ([IPv6:2400:402e:a012:6300:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u158vAqH032023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Fri, 5 Feb 2016 17:57:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org (alph.allbsd.org [192.168.0.10]) (authenticated bits=56) by mail.d.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u158vAHX086536 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Feb 2016 17:57:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id u158v948086533; Fri, 5 Feb 2016 17:57:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 05 Feb 2016 17:56:56 +0900 (JST) Message-Id: <20160205.175656.1868199482111652846.hrs@allbsd.org> To: ddb@neosystem.org Cc: freebsd-stable@freebsd.org Subject: Re: stf(4) on 10-stable From: Hiroki Sato In-Reply-To: <20160205093713.1c1453f9b5d06a6b366c44db@neosystem.cz> References: <20160113091730.381f94e94fa5cb2b90960111@neosystem.cz> <20160114104937.57e14705ea345ad877db2ed5@neosystem.cz> <20160205093713.1c1453f9b5d06a6b366c44db@neosystem.cz> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb__5_17_56_56_2016_668)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 05 Feb 2016 17:57:22 +0900 (JST) X-Spam-Status: No, score=-99.9 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 05 Feb 2016 08:57:25 -0000 ----Security_Multipart(Fri_Feb__5_17_56_56_2016_668)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Daniel Bilik wrote in <20160205093713.1c1453f9b5d06a6b366c44db@neosystem.cz>: dd> On Thu, 14 Jan 2016 10:49:37 +0100 dd> Daniel Bilik wrote: dd> dd> >> Should I create PR for this? dd> > Created: dd> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206231 dd> dd> Seems that 10-stable has just entered beta1, so unless some effort is dd> put into fixing this, 10.3-release is probably gonna ship with broken 6to4 dd> connectivity. I am sorry for not taking care of this in a timely manner. I will do this weekend. -- Hiroki ----Security_Multipart(Fri_Feb__5_17_56_56_2016_668)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAla0Y9gACgkQTyzT2CeTzy3/8gCguX76udAx1lBWQ+6e/LXp7d28 nIAAoKP8h3l22QG0DnTCl4aC3UjyYeiV =q3+x -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb__5_17_56_56_2016_668)---- From owner-freebsd-stable@freebsd.org Fri Feb 5 21:55:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 092EEA9EEE3 for ; Fri, 5 Feb 2016 21:55:18 +0000 (UTC) (envelope-from scott.otis@tandemcal.com) Received: from Filter01.GreenHouseData.com (outmail.fchosted.com [205.234.75.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "filter.greenhousedata.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E07E265A for ; Fri, 5 Feb 2016 21:55:17 +0000 (UTC) (envelope-from scott.otis@tandemcal.com) X-ASG-Debug-ID: 1454709316-0a955c0aa817e7590001-BIHDGU Received: from mail.fchosted.com (mailflow.greenhousedata.com [10.36.251.68]) by Filter01.GreenHouseData.com with ESMTP id DHmjcQnMm3pLRGpm (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 05 Feb 2016 13:55:16 -0800 (PST) X-Barracuda-Envelope-From: scott.otis@tandemcal.com Received: from EVT01FEVWEXA001.fchosted.com ([10.10.2.130]) by sea02fevwexa001 ([10.10.2.131]) with mapi id 14.03.0266.001; Fri, 5 Feb 2016 13:55:16 -0800 From: Scott Otis To: "freebsd-stable@freebsd.org" Subject: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes Thread-Topic: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes X-ASG-Orig-Subj: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes Thread-Index: AdFgXh+MGR2ZakJhS8y7lHqrkKi5uw== Date: Fri, 5 Feb 2016 21:55:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.19.233.47] MIME-Version: 1.0 X-Barracuda-Connect: mailflow.greenhousedata.com[10.36.251.68] X-Barracuda-Start-Time: 1454709316 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://Filter.GreenHouseData.com:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 12891 X-Virus-Scanned: by bsmtpd at GreenHouseData.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.26781 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 05 Feb 2016 21:55:18 -0000 Been trying to get a FreeBSD VM server running on Azure on a "Standard DS" = size VM (so I have access to SSD storage for PostgreSQL). The "Standard DS= " series of VMs also have faster/newer CPUs than the original "Standard A" = series of VMs. I am using the image of FreeBSD from here: https://vmdepot.= msopentech.com/Vhd/Show?vhdId=3D56718&version=3D61117 . After setting up t= he VM it started rebooting every hour or so. Initially I thought this was = an Azure issue and Azure was forcibly rebooting the VM because it wasn't ge= tting health reports back. But I don't' believe this is the case anymore a= nd I think FreeBSD is crashing. (Note: I have setup a FreeBSD VM with a "S= tandard A" series VM and that seems to be running fine - though it looks li= ke it might have crashed after about 38 hours which is much better than cra= shing after 1 hour). Here is the "last" log from the last two days: [--redacted--] pts/2 [--redacted--] Fri Feb 5 21:10 still logged in [--redacted--] pts/1 [--redacted--] Fri Feb 5 21:10 still logged in [--redacted--] pts/0 [--redacted--] Fri Feb 5 20:58 - 21:10 (00:12) boot time Fri Feb 5 20:53 [--redacted--] pts/1 [--redacted--] Fri Feb 5 04:59 - crash (15:54) [--redacted--] pts/0 [--redacted--] Fri Feb 5 04:59 - 04:59 (00:00) boot time Fri Feb 5 04:41 boot time Fri Feb 5 02:16 [--redacted--] pts/1 [--redacted--] Fri Feb 5 00:36 - crash (01:40) [--redacted--] pts/0 [--redacted--] Fri Feb 5 00:36 - 00:36 (00:00) boot time Fri Feb 5 00:29 shutdown time Thu Feb 4 09:33 boot time Thu Feb 4 08:47 [--redacted--] pts/0 [--redacted--] Thu Feb 4 07:25 - crash (01:21) boot time Thu Feb 4 07:00 boot time Thu Feb 4 05:03 boot time Thu Feb 4 02:45 [--redacted--] pts/0 [--redacted--] Thu Feb 4 01:08 - crash (01:36) boot time Thu Feb 4 00:58 There are boot times without previous shutdown times - and there is that "c= rash" text (which is why I'm thinking it is a crash). It looks by default the OS is setup to NOT save crash dumps sudo dumpon -v -l kernel dumps on /dev/null If that is the case - do I add this to /etc/rc.conf? dumpdev=3D"AUTO" dumpdir=3D"/var/crash" Is there anything I need to adjust there? Does that only take affect after a reboot? Do I need to set anything with dumpon(8)? Here is the info on the swapfile: sudo swapinfo -h Device 512-blocks Used Avail Capacity /dev/gpt/swapfs 2097152 0B 1.0G 0% Is that enough space for a kernel crash dump? Thanks for all your help with this. Regards, Scott Otis CTO & Co-Founder Tandem www.tandemcal.com From owner-freebsd-stable@freebsd.org Sat Feb 6 00:45:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C255FA9E5C0 for ; Sat, 6 Feb 2016 00:45:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 8EA991D31 for ; Sat, 6 Feb 2016 00:45:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id 5so25503373igt.0 for ; Fri, 05 Feb 2016 16:45:43 -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:content-transfer-encoding; bh=M6s/D1/r7uJ2Rc5b3hFK8/N5lkH+TWRI+3jIW+N0SYo=; b=yFvHL3UmqKhYzz5cUAsqRZp9BQL5EdecGhB2ubUjdKhSBJ5if3ra2IGh6nxZYlVGlP 77JMnFbninHjTqur3dUXg67hu7047PPTup2Tx9mw1vwg8FJp51Xs0RKJE6Z8x69kai8C w7ez+U/iiI4Mv0cZ6N81qDkNDgN24b1QnZfu0ZZpecorBtlXD9xpwHYXP4yUDr7FEbCB P/Evo/EUs2mgHn9PqwBHLSmddNVS9KPPIVZNQSUcwsInE9elLpUqhp6xceKZfKXSJ/fW Rs0ECC3k2Pxv7owcjQ+GP3DsbjYc55thyNYQmLRjwcy0aQTTyRRI7NZjOBT0ighXVtWA 7+VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M6s/D1/r7uJ2Rc5b3hFK8/N5lkH+TWRI+3jIW+N0SYo=; b=chcbNXGsDCTaQ/3/cgZ2pDU0WkzuDUJ9J6a1IFfwSAcRr7PbAPREZo0wuLaxPjEAXp eRaiQ/M8ds3UOANjRjtDO3UQ09LKnp9B4/jpe19QAziNIKAjnpWiIg1be80ENc3+Uexp EdG107EvM2EcWbhxK3/pu1qKn8xtajY3ajiB1abdw7s74rNuyIdFH5PHdIn5ItYTro3B 54mTUy3j4SM7OdCbtHwpww0qE06pCfnlLrS+szFCk9WRO4cwm6TOhjOyIN8POSqxZDzW 8xbwKIbO0WWQ1HH7amvP0CGgLhvbxhHdSpopTKC29DiLxcK/9e1b532jMaNaSE6pME5x umkQ== X-Gm-Message-State: AG10YOQFTm65KhIt9G0n+WoC7RO1uHlzGgwStK0Ok698pRo7M+JCNp1ExY52It3NE6MU8/y3KGNVjaFqpsPBQA== MIME-Version: 1.0 X-Received: by 10.50.93.36 with SMTP id cr4mr17465721igb.22.1454719543045; Fri, 05 Feb 2016 16:45:43 -0800 (PST) Received: by 10.36.14.19 with HTTP; Fri, 5 Feb 2016 16:45:42 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 16:45:42 -0800 Message-ID: Subject: Re: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes From: Adrian Chadd To: Scott Otis Cc: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 00:45:43 -0000 hiya, how much RAM does the VM have? Yes, you need to either run dumpon or reboot once you update /etc/rc.conf . -a On 5 February 2016 at 13:55, Scott Otis wrote: > Been trying to get a FreeBSD VM server running on Azure on a "Standard DS= " size VM (so I have access to SSD storage for PostgreSQL). The "Standard = DS" series of VMs also have faster/newer CPUs than the original "Standard A= " series of VMs. I am using the image of FreeBSD from here: https://vmdepo= t.msopentech.com/Vhd/Show?vhdId=3D56718&version=3D61117 . After setting up= the VM it started rebooting every hour or so. Initially I thought this wa= s an Azure issue and Azure was forcibly rebooting the VM because it wasn't = getting health reports back. But I don't' believe this is the case anymore= and I think FreeBSD is crashing. (Note: I have setup a FreeBSD VM with a = "Standard A" series VM and that seems to be running fine - though it looks = like it might have crashed after about 38 hours which is much better than c= rashing after 1 hour). > > Here is the "last" log from the last two days: > > [--redacted--] pts/2 [--redacted--] Fri Feb 5 21:10 still logged = in > [--redacted--] pts/1 [--redacted--] Fri Feb 5 21:10 still logged = in > [--redacted--] pts/0 [--redacted--] Fri Feb 5 20:58 - 21:10 (00:12= ) > boot time Fri Feb 5 20:53 > [--redacted--] pts/1 [--redacted--] Fri Feb 5 04:59 - crash (15:54= ) > [--redacted--] pts/0 [--redacted--] Fri Feb 5 04:59 - 04:59 (00:00= ) > boot time Fri Feb 5 04:41 > boot time Fri Feb 5 02:16 > [--redacted--] pts/1 [--redacted--] Fri Feb 5 00:36 - crash (01:40= ) > [--redacted--] pts/0 [--redacted--] Fri Feb 5 00:36 - 00:36 (00:00= ) > boot time Fri Feb 5 00:29 > shutdown time Thu Feb 4 09:33 > boot time Thu Feb 4 08:47 > [--redacted--] pts/0 [--redacted--] Thu Feb 4 07:25 - crash (01:21= ) > boot time Thu Feb 4 07:00 > boot time Thu Feb 4 05:03 > boot time Thu Feb 4 02:45 > [--redacted--] pts/0 [--redacted--] Thu Feb 4 01:08 - crash (01:36= ) > boot time Thu Feb 4 00:58 > > There are boot times without previous shutdown times - and there is that = "crash" text (which is why I'm thinking it is a crash). > > It looks by default the OS is setup to NOT save crash dumps > > > sudo dumpon -v -l > > kernel dumps on /dev/null > > > If that is the case - do I add this to /etc/rc.conf? > > > > dumpdev=3D"AUTO" > > dumpdir=3D"/var/crash" > > > > Is there anything I need to adjust there? > > Does that only take affect after a reboot? > > Do I need to set anything with dumpon(8)? > > > > Here is the info on the swapfile: > > > > sudo swapinfo -h > > Device 512-blocks Used Avail Capacity > > /dev/gpt/swapfs 2097152 0B 1.0G 0% > > > > Is that enough space for a kernel crash dump? > > > > Thanks for all your help with this. > > Regards, > > Scott Otis > CTO & Co-Founder > Tandem > www.tandemcal.com > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat Feb 6 05:16:33 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96D65A9EA0B for ; Sat, 6 Feb 2016 05:16:33 +0000 (UTC) (envelope-from scott.otis@tandemcal.com) Received: from Filter02.GreenHouseData.com (outmail.fchosted.com [205.234.75.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "filter.greenhousedata.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A3A1FE2 for ; Sat, 6 Feb 2016 05:16:33 +0000 (UTC) (envelope-from scott.otis@tandemcal.com) X-ASG-Debug-ID: 1454735561-0a955d7333177e930001-BIHDGU Received: from mail.fchosted.com (mailflow.greenhousedata.com [10.36.251.68]) by Filter02.GreenHouseData.com with ESMTP id hAjpSFCGQWu0KH7O (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 05 Feb 2016 21:12:41 -0800 (PST) X-Barracuda-Envelope-From: scott.otis@tandemcal.com Received: from EVT01FEVWEXA001.fchosted.com ([10.10.2.130]) by sea02fevwexa001 ([10.10.2.131]) with mapi id 14.03.0266.001; Fri, 5 Feb 2016 21:12:41 -0800 From: Scott Otis To: Adrian Chadd CC: "freebsd-stable@freebsd.org" Subject: RE: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes Thread-Topic: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes X-ASG-Orig-Subj: RE: 10.2 Release seems to be crashing on Azure with "Standard DS" VM sizes Thread-Index: AdFgXh+MGR2ZakJhS8y7lHqrkKi5uwAXKNQAAAhAj7A= Date: Sat, 6 Feb 2016 05:12:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.19.233.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: mailflow.greenhousedata.com[10.36.251.68] X-Barracuda-Start-Time: 1454735561 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://Filter.GreenHouseData.com:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 9560 X-Virus-Scanned: by bsmtpd at GreenHouseData.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.26795 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 05:16:33 -0000 QWRyaWFuLA0KDQozLjUgR0Igb2YgUkFNLg0KDQpIZXJlIGlzIHRoZSBsaXN0IGZyb20gZG1zZWcg aWYgdGhhdCBoZWxwczoNCg0KQ29weXJpZ2h0IChjKSAxOTkyLTIwMTUgVGhlIEZyZWVCU0QgUHJv amVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwg MTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJlZUJTRCBpcyBhIHJl Z2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uDQpGcmVlQlNEIDEw LjItUkVMRUFTRSAjMCByMjg2NjY2OiBXZWQgQXVnIDEyIDE1OjI2OjM3IFVUQyAyMDE1DQogICAg cm9vdEByZWxlbmcxLm55aS5mcmVlYnNkLm9yZzovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklD IGFtZDY0DQpGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy40LjEgKHRhZ3MvUkVMRUFTRV8zNC9kb3Qx LWZpbmFsIDIwODAzMikgMjAxNDA1MTINCkNQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgRTUtMjY2 MCAwIEAgMi4yMEdIeiAoMTEwOS43NC1NSHogSzgtY2xhc3MgQ1BVKQ0KICBPcmlnaW49IkdlbnVp bmVJbnRlbCIgIElkPTB4MjA2ZDcgIEZhbWlseT0weDYgIE1vZGVsPTB4MmQgIFN0ZXBwaW5nPTcN CiAgRmVhdHVyZXM9MHhmODNmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgs QVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRSxTU0UyLFNT Pg0KICBGZWF0dXJlczI9MHg5ZTk4MjIwMzxTU0UzLFBDTE1VTFFEUSxTU1NFMyxDWDE2LFNTRTQu MSxTU0U0LjIsUE9QQ05ULEFFU05JLFhTQVZFLE9TWFNBVkUsQVZYLEhWPg0KICBBTUQgRmVhdHVy ZXM9MHgyMDEwMDgwMDxTWVNDQUxMLE5YLExNPg0KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPg0K ICBYU0FWRSBGZWF0dXJlcz0weDE8WFNBVkVPUFQ+DQpIeXBlcnZpc29yOiBPcmlnaW4gPSAiTWlj cm9zb2Z0IEh2Ig0KcmVhbCBtZW1vcnkgID0gMzc1ODA5NjM4NCAoMzU4NCBNQikNCmF2YWlsIG1l bW9yeSA9IDM1MTUxNDIxNDQgKDMzNTIgTUIpDQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkg NDAwDQpBQ1BJIEFQSUMgVGFibGU6IDxWUlRVQUwgTUlDUk9TRlQ+DQppb2FwaWMwOiBDaGFuZ2lu ZyBBUElDIElEIHRvIDANCmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVy Ym9hcmQNCnJhbmRvbTogPFNvZnR3YXJlLCBZYXJyb3c+IGluaXRpYWxpemVkDQprYmQxIGF0IGti ZG11eDANCnZtYnVzMDogPFZtYnVzIERldmljZXM+IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogPFZS VFVBTCBNSUNST1NGVD4gb24gbW90aGVyYm9hcmQNCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVk KQ0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAw eDQwLTB4NDMgaXJxIDAgb24gYWNwaTANClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwDQpFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgy IEh6IHF1YWxpdHkgMTAwDQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4 NzEgaXJxIDggb24gYWNwaTANCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBx dWFsaXR5IDANClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1 YWxpdHkgOTAwDQphY3BpX3RpbWVyMDogPDMyLWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9y dCAweDQwOC0weDQwYiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9y dCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCmlz YWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMA0KaXNhMDogPElTQSBi dXM+IG9uIGlzYWIwDQphdGFwY2kwOiA8SW50ZWwgUElJWDQgVURNQTMzIGNvbnRyb2xsZXI+IHBv cnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBk ZXZpY2UgNy4xIG9uIHBjaTANCmF0YTA6IDxIeXBlci1WIEFUQSBzdG9yYWdlIGRpc2VuZ2FnZSBk cml2ZXI+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kwDQphdGExOiA8QVRBIGNoYW5uZWw+IGF0IGNo YW5uZWwgMSBvbiBhdGFwY2kwDQpwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNy4zIChubyBkcml2 ZXIgYXR0YWNoZWQpDQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4Zjgw MDAwMDAtMHhmYmZmZmZmZiBpcnEgMTEgYXQgZGV2aWNlIDguMCBvbiBwY2kwDQp2Z2FwY2kwOiBC b290IHZpZGVvIGRldmljZQ0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g cG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwDQprYmQwIGF0IGF0a2JkMA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0KcHNt MDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20wOiBbR0lBTlQtTE9DS0VEXQ0K cHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlIEV4cGxvcmVyLCBkZXZpY2UgSUQgNA0KdWFydDA6IDwx NjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24g YWNwaTANCnVhcnQwOiBjb25zb2xlICgxMTUyMDAsbiw4LDEpDQp1YXJ0MTogPDE2NTUwIG9yIGNv bXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTANCmZkYzA6IDxmbG9wcHkg ZHJpdmUgY29udHJvbGxlciAoRkRFKT4gcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEg MiBvbiBhY3BpMA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDANCm9y bTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0weGNiZmZmIG9uIGlzYTANCnNj MDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYg dmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+DQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpwcGMwOiBj YW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQ0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4w MDAgbXNlYw0KcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4NClRpbWVjb3VudGVyICJUU0MiIGZy ZXF1ZW5jeSAxMTA5NzQ0ODA2IEh6IHF1YWxpdHkgODAwDQpUaW1lY291bnRlciAiSHlwZXItViIg ZnJlcXVlbmN5IDEwMDAwMDAwIEh6IHF1YWxpdHkgMTAwMDAwMDANCnN0b3J2c2MwIG9uIHZtYnVz MA0Kc3RvcnZzYzEgb24gdm1idXMwDQpoeXBlcnYtdXRpbHMwIG9uIHZtYnVzMA0KaHlwZXJ2LXV0 aWxzMDogSHlwZXItViBTZXJ2aWNlIGF0dGFjaGluZzogSHlwZXItViBIZWFydGJlYXQgU2Vydmlj ZQ0KDQpoeXBlcnYtdXRpbHMxIG9uIHZtYnVzMA0KaHlwZXJ2LXV0aWxzMTogSHlwZXItViBTZXJ2 aWNlIGF0dGFjaGluZzogSHlwZXItViBLVlAgU2VydmljZQ0KDQpoeXBlcnYtdXRpbHMyIG9uIHZt YnVzMA0KaHlwZXJ2LXV0aWxzMjogSHlwZXItViBTZXJ2aWNlIGF0dGFjaGluZzogSHlwZXItViBT aHV0ZG93biBTZXJ2aWNlDQoNCmh5cGVydi11dGlsczMgb24gdm1idXMwDQpoeXBlcnYtdXRpbHMz OiBIeXBlci1WIFNlcnZpY2UgYXR0YWNoaW5nOiBIeXBlci1WIFRpbWUgU3luY2ggU2VydmljZQ0K DQpkYTAgYXQgYmxrdnNjMCBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDANCmhuMDogPFN5bnRo ZXRpYyBOZXR3b3JrIEludGVyZmFjZT4gb24gdm1idXMwDQpkYTA6IDxNc2Z0IFZpcnR1YWwgRGlz ayAxLjA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU1BDLTIgU0NTSSBkZXZpY2UNCmRhMDogMzAwLjAw ME1CL3MgdHJhbnNmZXJzDQpkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KZGEwOiAyMTUw NU1CICg0NDA0MjI0MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI3NDFDKQ0KaG4wOiB1 bmtub3duIHN0YXR1cyAxMDczODcyOTAyIHJlY2VpdmVkDQpobjA6IHVua25vd24gc3RhdHVzIDEw NzM4NzI5MDIgcmVjZWl2ZWQNCmhuMDogaHYgc2VuZCBvZmZsb2FkIHJlcXVlc3Qgc3VjY2VlZGVk DQpobjA6IFVzaW5nIGRlZmF1bHRzIGZvciBUU086IDY1NTE4LzM1LzIwNDgNCmhuMDogRXRoZXJu ZXQgYWRkcmVzczogMDA6MGQ6M2E6MzE6N2U6OWUNCnN0b3J2c2MyIG9uIHZtYnVzMA0KZGExIGF0 IGJsa3ZzYzEgYnVzIDAgc2NidXMyIHRhcmdldCAxIGx1biAwDQpkYTE6IDxNc2Z0IFZpcnR1YWwg RGlzayAxLjA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU1BDLTIgU0NTSSBkZXZpY2UNCnN0b3J2c2Mz IG9uIHZtYnVzMA0KZGExOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMNCmRhMTogQ29tbWFuZCBRdWV1 ZWluZyBlbmFibGVkDQpkYTE6IDcxNjhNQiAoMTQ2ODAwNjQgNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCA5MTNDKQ0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9ncHQvcm9v dGZzIFtyd10uLi4NCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQpjYWxj cnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSAzNzM3IHVzZWMgdG8gMTg4OSB1c2VjIGZv ciBwaWQgMjcyIChkaGNsaWVudCkNCmNhbGNydTogcnVudGltZSB3ZW50IGJhY2t3YXJkcyBmcm9t IDk3MjQ0IHVzZWMgdG8gNDkxNzEgdXNlYyBmb3IgcGlkIDI3MiAoZGhjbGllbnQpDQpjYWxjcnU6 IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSA0NzA1MiB1c2VjIHRvIDQ0MzM5IHVzZWMgZm9y IHBpZCAxNiAoc2gpDQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSA1OTUgdXNl YyB0byA0MTAgdXNlYyBmb3IgcGlkIDUgKHBhZ2VkYWVtb24pDQpjYWxjcnU6IHJ1bnRpbWUgd2Vu dCBiYWNrd2FyZHMgZnJvbSAxOCB1c2VjIHRvIDkgdXNlYyBmb3IgcGlkIDQgKHNjdHBfaXRlcmF0 b3IpDQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSA4OTMyIHVzZWMgdG8gNDU2 OSB1c2VjIGZvciBwaWQgMyAoZmRjMCkNCmNhbGNydTogcnVudGltZSB3ZW50IGJhY2t3YXJkcyBm cm9tIDcwMjc4NiB1c2VjIHRvIDM2ODc4OCB1c2VjIGZvciBwaWQgMiAoY2FtKQ0KY2FsY3J1OiBy dW50aW1lIHdlbnQgYmFja3dhcmRzIGZyb20gNzY2MiB1c2VjIHRvIDY5NTcgdXNlYyBmb3IgcGlk IDE0IChyYW5kX2hhcnZlc3RxKQ0KY2FsY3J1OiBydW50aW1lIHdlbnQgYmFja3dhcmRzIGZyb20g ODk0OSB1c2VjIHRvIDQ1MjUgdXNlYyBmb3IgcGlkIDEzIChnZW9tKQ0KY2FsY3J1OiBydW50aW1l IHdlbnQgYmFja3dhcmRzIGZyb20gMzg0MDE0NjAgdXNlYyB0byAzMjc1MzQ1OCB1c2VjIGZvciBw aWQgMTEgKGlkbGUpDQpjYWxjcnU6IHJ1bnRpbWUgd2VudCBiYWNrd2FyZHMgZnJvbSAxODkxMzkg dXNlYyB0byA5NTY2NiB1c2VjIGZvciBwaWQgMSAoaW5pdCkNCmNhbGNydTogcnVudGltZSB3ZW50 IGJhY2t3YXJkcyBmcm9tIDEwNzg0NjUgdXNlYyB0byA1NDU2OTYgdXNlYyBmb3IgcGlkIDAgKGtl cm5lbCkNCg0KU2NvdHQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRy aWFuIENoYWRkIFttYWlsdG86YWRyaWFuLmNoYWRkQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXks IEZlYnJ1YXJ5IDUsIDIwMTYgNDo0NiBQTQ0KVG86IFNjb3R0IE90aXMgPHNjb3R0Lm90aXNAdGFu ZGVtY2FsLmNvbT4NCkNjOiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZw0KU3ViamVjdDogUmU6 IDEwLjIgUmVsZWFzZSBzZWVtcyB0byBiZSBjcmFzaGluZyBvbiBBenVyZSB3aXRoICJTdGFuZGFy ZCBEUyIgVk0gc2l6ZXMNCg0KaGl5YSwNCg0KaG93IG11Y2ggUkFNIGRvZXMgdGhlIFZNIGhhdmU/ DQoNClllcywgeW91IG5lZWQgdG8gZWl0aGVyIHJ1biBkdW1wb24gb3IgcmVib290IG9uY2UgeW91 IHVwZGF0ZSAvZXRjL3JjLmNvbmYgLg0KDQoNCi1hDQoNCg0KT24gNSBGZWJydWFyeSAyMDE2IGF0 IDEzOjU1LCBTY290dCBPdGlzIDxzY290dC5vdGlzQHRhbmRlbWNhbC5jb20+IHdyb3RlOg0KPiBC ZWVuIHRyeWluZyB0byBnZXQgYSBGcmVlQlNEIFZNIHNlcnZlciBydW5uaW5nIG9uIEF6dXJlIG9u IGEgIlN0YW5kYXJkIERTIiBzaXplIFZNIChzbyBJIGhhdmUgYWNjZXNzIHRvIFNTRCBzdG9yYWdl IGZvciBQb3N0Z3JlU1FMKS4gIFRoZSAiU3RhbmRhcmQgRFMiIHNlcmllcyBvZiBWTXMgYWxzbyBo YXZlIGZhc3Rlci9uZXdlciBDUFVzIHRoYW4gdGhlIG9yaWdpbmFsICJTdGFuZGFyZCBBIiBzZXJp ZXMgb2YgVk1zLiAgSSBhbSB1c2luZyB0aGUgaW1hZ2Ugb2YgRnJlZUJTRCBmcm9tIGhlcmU6IGh0 dHBzOi8vdm1kZXBvdC5tc29wZW50ZWNoLmNvbS9WaGQvU2hvdz92aGRJZD01NjcxOCZ2ZXJzaW9u PTYxMTE3IC4gIEFmdGVyIHNldHRpbmcgdXAgdGhlIFZNIGl0IHN0YXJ0ZWQgcmVib290aW5nIGV2 ZXJ5IGhvdXIgb3Igc28uICBJbml0aWFsbHkgSSB0aG91Z2h0IHRoaXMgd2FzIGFuIEF6dXJlIGlz c3VlIGFuZCBBenVyZSB3YXMgZm9yY2libHkgcmVib290aW5nIHRoZSBWTSBiZWNhdXNlIGl0IHdh c24ndCBnZXR0aW5nIGhlYWx0aCByZXBvcnRzIGJhY2suICBCdXQgSSBkb24ndCcgYmVsaWV2ZSB0 aGlzIGlzIHRoZSBjYXNlIGFueW1vcmUgYW5kIEkgdGhpbmsgRnJlZUJTRCBpcyBjcmFzaGluZy4g IChOb3RlOiBJIGhhdmUgc2V0dXAgYSBGcmVlQlNEIFZNIHdpdGggYSAiU3RhbmRhcmQgQSIgc2Vy aWVzIFZNIGFuZCB0aGF0IHNlZW1zIHRvIGJlIHJ1bm5pbmcgZmluZSAtIHRob3VnaCBpdCBsb29r cyBsaWtlIGl0IG1pZ2h0IGhhdmUgY3Jhc2hlZCBhZnRlciBhYm91dCAzOCBob3VycyB3aGljaCBp cyBtdWNoIGJldHRlciB0aGFuIGNyYXNoaW5nIGFmdGVyIDEgaG91cikuDQo+DQo+IEhlcmUgaXMg dGhlICJsYXN0IiBsb2cgZnJvbSB0aGUgbGFzdCB0d28gZGF5czoNCj4NCj4gWy0tcmVkYWN0ZWQt LV0gICBwdHMvMiAgICBbLS1yZWRhY3RlZC0tXSBGcmkgRmViICA1IDIxOjEwICAgc3RpbGwgbG9n Z2VkIGluDQo+IFstLXJlZGFjdGVkLS1dICAgcHRzLzEgICAgWy0tcmVkYWN0ZWQtLV0gRnJpIEZl YiAgNSAyMToxMCAgIHN0aWxsIGxvZ2dlZCBpbg0KPiBbLS1yZWRhY3RlZC0tXSAgIHB0cy8wICAg IFstLXJlZGFjdGVkLS1dIEZyaSBGZWIgIDUgMjA6NTggLSAyMToxMCAgKDAwOjEyKQ0KPiBib290 IHRpbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJpIEZlYiAgNSAyMDo1Mw0K PiBbLS1yZWRhY3RlZC0tXSAgIHB0cy8xICAgIFstLXJlZGFjdGVkLS1dIEZyaSBGZWIgIDUgMDQ6 NTkgLSBjcmFzaCAgKDE1OjU0KQ0KPiBbLS1yZWRhY3RlZC0tXSAgIHB0cy8wICAgIFstLXJlZGFj dGVkLS1dIEZyaSBGZWIgIDUgMDQ6NTkgLSAwNDo1OSAgKDAwOjAwKQ0KPiBib290IHRpbWUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJpIEZlYiAgNSAwNDo0MQ0KPiBib290IHRp bWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJpIEZlYiAgNSAwMjoxNg0KPiBb LS1yZWRhY3RlZC0tXSAgIHB0cy8xICAgIFstLXJlZGFjdGVkLS1dIEZyaSBGZWIgIDUgMDA6MzYg LSBjcmFzaCAgKDAxOjQwKQ0KPiBbLS1yZWRhY3RlZC0tXSAgIHB0cy8wICAgIFstLXJlZGFjdGVk LS1dIEZyaSBGZWIgIDUgMDA6MzYgLSAwMDozNiAgKDAwOjAwKQ0KPiBib290IHRpbWUgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJpIEZlYiAgNSAwMDoyOQ0KPiBzaHV0ZG93biB0 aW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGh1IEZlYiAgNCAwOTozMw0KPiBib290 IHRpbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGh1IEZlYiAgNCAwODo0Nw0K PiBbLS1yZWRhY3RlZC0tXSAgIHB0cy8wICAgIFstLXJlZGFjdGVkLS1dIFRodSBGZWIgIDQgMDc6 MjUgLSBjcmFzaCAgKDAxOjIxKQ0KPiBib290IHRpbWUgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGh1IEZlYiAgNCAwNzowMA0KPiBib290IHRpbWUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGh1IEZlYiAgNCAwNTowMw0KPiBib290IHRpbWUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGh1IEZlYiAgNCAwMjo0NQ0KPiBbLS1yZWRhY3RlZC0tXSAg IHB0cy8wICAgIFstLXJlZGFjdGVkLS1dIFRodSBGZWIgIDQgMDE6MDggLSBjcmFzaCAgKDAxOjM2 KQ0KPiBib290IHRpbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGh1IEZlYiAg NCAwMDo1OA0KPg0KPiBUaGVyZSBhcmUgYm9vdCB0aW1lcyB3aXRob3V0IHByZXZpb3VzIHNodXRk b3duIHRpbWVzIC0gYW5kIHRoZXJlIGlzIHRoYXQgImNyYXNoIiB0ZXh0ICh3aGljaCBpcyB3aHkg SSdtIHRoaW5raW5nIGl0IGlzIGEgY3Jhc2gpLg0KPg0KPiBJdCBsb29rcyBieSBkZWZhdWx0IHRo ZSBPUyBpcyBzZXR1cCB0byBOT1Qgc2F2ZSBjcmFzaCBkdW1wcw0KPg0KPg0KPiBzdWRvIGR1bXBv biAtdiAtbA0KPg0KPiBrZXJuZWwgZHVtcHMgb24gL2Rldi9udWxsDQo+DQo+DQo+IElmIHRoYXQg aXMgdGhlIGNhc2UgLSBkbyBJIGFkZCB0aGlzIHRvIC9ldGMvcmMuY29uZj8NCj4NCj4NCj4NCj4g ZHVtcGRldj0iQVVUTyINCj4NCj4gZHVtcGRpcj0iL3Zhci9jcmFzaCINCj4NCj4NCj4NCj4gSXMg dGhlcmUgYW55dGhpbmcgSSBuZWVkIHRvIGFkanVzdCB0aGVyZT8NCj4NCj4gRG9lcyB0aGF0IG9u bHkgdGFrZSBhZmZlY3QgYWZ0ZXIgYSByZWJvb3Q/DQo+DQo+IERvIEkgbmVlZCB0byBzZXQgYW55 dGhpbmcgd2l0aCBkdW1wb24oOCk/DQo+DQo+DQo+DQo+IEhlcmUgaXMgdGhlIGluZm8gb24gdGhl IHN3YXBmaWxlOg0KPg0KPg0KPg0KPiBzdWRvIHN3YXBpbmZvIC1oDQo+DQo+IERldmljZSAgICAg ICAgICA1MTItYmxvY2tzICAgICBVc2VkICAgIEF2YWlsIENhcGFjaXR5DQo+DQo+IC9kZXYvZ3B0 L3N3YXBmcyAgICAyMDk3MTUyICAgICAgIDBCICAgICAxLjBHICAgICAwJQ0KPg0KPg0KPg0KPiBJ cyB0aGF0IGVub3VnaCBzcGFjZSBmb3IgYSBrZXJuZWwgY3Jhc2ggZHVtcD8NCj4NCj4NCj4NCj4g VGhhbmtzIGZvciBhbGwgeW91ciBoZWxwIHdpdGggdGhpcy4NCj4NCj4gUmVnYXJkcywNCj4NCj4g U2NvdHQgT3Rpcw0KPiBDVE8gJiBDby1Gb3VuZGVyDQo+IFRhbmRlbQ0KPiB3d3cudGFuZGVtY2Fs LmNvbTxodHRwOi8vd3d3LnRhbmRlbWNhbC5jb20vPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9y ZyBtYWlsaW5nIGxpc3QgDQo+IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9mcmVlYnNkLXN0YWJsZQ0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAi ZnJlZWJzZC1zdGFibGUtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-stable@freebsd.org Sat Feb 6 06:43:37 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B669A9E691 for ; Sat, 6 Feb 2016 06:43:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 15B39A48; Sat, 6 Feb 2016 06:43:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u166hYMZ028934 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Feb 2016 07:43:34 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u166hYvB028933; Sat, 6 Feb 2016 07:43:34 +0100 (CET) (envelope-from marius) Date: Sat, 6 Feb 2016 07:43:34 +0100 From: Marius Strobl To: freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 10.3-BETA1 Now Available Message-ID: <20160206064334.GK15359@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zPXeIxDajdrcF2en" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Sat, 06 Feb 2016 07:43:34 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 06:43:37 -0000 --zPXeIxDajdrcF2en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The first BETA build of the 10.3-RELEASE release cycle is now available. Installation images are available for: o amd64 GENERIC o i386 GENERIC o powerpc GENERIC o powerpc64 GENERIC64 o sparc64 GENERIC o armv6 BEAGLEBONE o armv6 CUBOX-HUMMINGBOARD o armv6 GUMSTIX o armv6 PANDABOARD o armv6 RPI-B o armv6 WANDBOARD Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. A list of changes since 10.2-RELEASE are available on the stable/10 release notes: https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 10.3-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-BETA1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-c01c35aa us-west-1 region: ami-976214f7 us-west-2 region: ami-425abc22 sa-east-1 region: ami-d737b7bb eu-west-1 region: ami-9ca110ef eu-central-1 region: ami-6ca2ba00 ap-northeast-1 region: ami-2451544a ap-northeast-2 region: ami-67f03e09 ap-southeast-1 region: ami-e996588a ap-southeast-2 region: ami-8996b2ea === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-10.3-BETA1 % vagrant up --provider vmware_desktop === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 10.3-BETA1 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 9.x. Alternatively, the user can install misc/compat9x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 10.3-BETA1 amd64 GENERIC: SHA512 (FreeBSD-10.3-BETA1-amd64-bootonly.iso) = 8b93fac77edd82ab55c914a511c7e23f2e24de68025dff6bc896ee5e53ac659ffc71c37f81d1533486bebf503deda589201fa7d2c588ade2472aa65ac7735e6c SHA512 (FreeBSD-10.3-BETA1-amd64-bootonly.iso.xz) = 9b242a7fb28f200f27a8f8491ace27a07528a45d8d7bf3980e996f5c13d37de08b3c1202d54226f4ce4b36f7b45e900c01e94efbdaf225903c571d752fdbfca5 SHA512 (FreeBSD-10.3-BETA1-amd64-disc1.iso) = 2424179c754d5514754fe75ab470c03c6a0efafd24425cc5b17d98b2e779b5588fa7e746f820e6ad01c86f1d3b4c4244333fa0f46196163c83feb48fe878fd2e SHA512 (FreeBSD-10.3-BETA1-amd64-disc1.iso.xz) = 9cba1bf33de5f85dbe6033feb1a1bb47a88cf1504c0b9229120960761697a71e80f88caf97c45331409aacad28db0c62b0c6ba83db6f667c284bc7a2bed35b36 SHA512 (FreeBSD-10.3-BETA1-amd64-dvd1.iso) = f45520f9d12d7bead6d3647c080c18542ad2977da9a4d6827de27f93ab154d5c435cb491cad459a888825cd2b03c81ecc76a49625a00c812a21e6f8ebb5b3660 SHA512 (FreeBSD-10.3-BETA1-amd64-dvd1.iso.xz) = 959a34237d76dd428162a8b84f0c99c78e55abc4459cf57977d7f9bd13b6b4fbbaa49c504448a96787490fd84864c5b32f183dec16b813709cdd427b0727b87e SHA512 (FreeBSD-10.3-BETA1-amd64-memstick.img) = 294fff16d3d6e927497bcf0a5c89058c76d39fe27d12f8763d9306c7fcc7ea3a2737f1cf860f5fc67809bd41883a04c14124b87fdf9fb29bf8338b23ba06a851 SHA512 (FreeBSD-10.3-BETA1-amd64-memstick.img.xz) = 7836248971b0463d50e7d808d9bd2aa24fd42e57788f1f2764dc270d5889b5dc0eecbc216029d8cbbea71d3fbc148e09952ebfbf45d70557387edfc25b965a0c SHA512 (FreeBSD-10.3-BETA1-amd64-mini-memstick.img) = 6df05071c06924a2df06fbf2c3f6b9b2f9a1b5f7f0370dc08606b7821b2c221ed4c1dcb58038f99567246765459ae9a43cbee2ab94edf1e045259738a4a396b2 SHA512 (FreeBSD-10.3-BETA1-amd64-mini-memstick.img.xz) = dc4ab8401345ae33c34e98ff388a615a03f9160c89cb1a570d0a38812cbd0d3f61527ccfa9b214d819a484106dbb206092c351aa3a9c6fba8b4ec78bda09bdb7 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-bootonly.iso) = b442b9ce439613130a26176e01f88eeb434cfffc55ee89419070bfd234d0c8b51521cc1aacf4c2c38166cd111a3271aec5e46371bd080c1ad6efb5fe18414ae5 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-bootonly.iso.xz) = 5eaca3e4951774db1bd841b8f50ec84617a36190f6fee59e3616a7413d3c6b8b9ceb6602ff2fe5d12c8d89b24e19ba1f45e0101615eb7fe95373ceca60577513 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-disc1.iso) = f3b09dae31b5c465570d4fa89aabd4b70e203f03ec1b23c1b300c40e97508404506bebd03cdc3c7317718fb4c1953729a0c73fa104a2a8ec677d8e4f3b42b90d SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-disc1.iso.xz) = 531757c2c7d396ad98f2ed70fe9120eb88c508b19e794ba6529a2fb3eff19f6c042142f23c7cfd893dc5b34ecf9315a897e2695f58efa27a709245da82016a63 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-dvd1.iso) = 7950e0c63baa7ee6878ccb7e2f62a3823113a11705fe1821354bab1d622cf46ad6e59e41e26e10da095b7d676b0bd4fedf81fa3d8d0e36c46541eef714e0390d SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-dvd1.iso.xz) = f3c9f8c426d90c137d013e6043b1c5a711bed4be599ba64865bafd0dd78eaf6e32e9a0699c2120eab97a7591d5ae1c631b64dd6d9f5db6304eaff6ffa1513cbb SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-memstick.img) = 7218b6a8cce100535b3f922f23dd488d04508060921a6ec32a76c09890d36962b5b08934a0ccdf8323d2716c3a1dfa4ef489907a180d255fae37d1c6bfb3416e SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-memstick.img.xz) = 688500a90a9d69a2725e27afaae4af7f469c5daf31deea7a38140c0d4c4c5d987c567b3462bcb0e67d3f0a4327ca529bf88fdcc9ca2b35f163f4fefceec12544 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-mini-memstick.img) = fef40b2f0ce37f547de09c8fe3cb8d327c60480fd81972a51bfa21d696ea5d665e9629470182825718cf616178e81841daf6d15322e7197715fc66dafa6900a4 SHA512 (FreeBSD-10.3-BETA1-amd64-uefi-mini-memstick.img.xz) = 9af0a0d79279891c76a0a38f3567276479c2ee86ec8a04e3b069fa4731321804e6db284b4f003bc1a1a08a06f34dbd9b3b1a0f2422893d1795bcd4c21ad1f413 SHA256 (FreeBSD-10.3-BETA1-amd64-bootonly.iso) = d4b498d90c6703f4ecadcc654ab842a121bcf446585bb4f942d6acfa446c5804 SHA256 (FreeBSD-10.3-BETA1-amd64-bootonly.iso.xz) = 05f3b94dec92359f2084315b0f4866943880a399fae1098784b49e96e30a89f8 SHA256 (FreeBSD-10.3-BETA1-amd64-disc1.iso) = d49fb12c7564fc28c539dae20c8355701f492566f84c2cdf1da270cd654f1ecb SHA256 (FreeBSD-10.3-BETA1-amd64-disc1.iso.xz) = 7fc8698fa1efc5300b6681157ed7c3d8ea6a6d9f657326555da7493447522840 SHA256 (FreeBSD-10.3-BETA1-amd64-dvd1.iso) = 10e25cae672991cc289ce9fa4fca6d9c3944064f04962f876a9ed86189c4a1fb SHA256 (FreeBSD-10.3-BETA1-amd64-dvd1.iso.xz) = 3ef087cbf2a9418fb1cfb75648b0bec339d6ab36233af70d78635d475e140afe SHA256 (FreeBSD-10.3-BETA1-amd64-memstick.img) = 5e7e5d202d57559fd47b5780a8b8bc382f749d1238353dd68bfe619928ef4cb3 SHA256 (FreeBSD-10.3-BETA1-amd64-memstick.img.xz) = c6fdb95136157adb6fc23f9931ac3a610ac77045d784f0bbe0cb89549aaa10ee SHA256 (FreeBSD-10.3-BETA1-amd64-mini-memstick.img) = 32f43b7bef9690457bfdec4df0fad61c83fd3fd054189e46cb7f35c95d32eb07 SHA256 (FreeBSD-10.3-BETA1-amd64-mini-memstick.img.xz) = 5f90d128a8dfeb195de2302d6ff31162ceedcef6757a83d36da4ac2bd81cd033 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-bootonly.iso) = 30dfcf070a9f5b05215b73b53e7399a7f8b5e9808a7e181600a33c4001c0d9da SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-bootonly.iso.xz) = 57654ce1aba37ce44ab9a7f4ece29610a99e90ddd870e47ff96b3058b086dd0f SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-disc1.iso) = f09b731ef9cb7d713070439160055f68a82b5562981e321c41e4820e75d3cb29 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-disc1.iso.xz) = ef8f2fdd3bbaf786c4c637194ca086dacc310bf29f60b3c0093c218423ef146d SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-dvd1.iso) = 5df5322ab2a6376ec79800eeb66958d6f740b1364e52724d93aeb2aba98537b2 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-dvd1.iso.xz) = e602e97056dc3094598b31fb3c597050cb7a130a06098dec41a9425f2b6cc455 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-memstick.img) = e265d012069f294d66a47b21fb470c1e03833433214b41b2b1687e951b0c3646 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-memstick.img.xz) = 310bddd117562a9ff77155a69327ba93322b65354b94b229ea98e673179b7bb5 SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-mini-memstick.img) = b04ecd6d05bad1422cbae2e6807bb46045aca8e10ddea5719215c6839cb38ede SHA256 (FreeBSD-10.3-BETA1-amd64-uefi-mini-memstick.img.xz) = b93b5987be72a9ae1a3c735f950865e15770784f575a3985560a623d1ef66af6 o 10.3-BETA1 i386 GENERIC: SHA512 (FreeBSD-10.3-BETA1-i386-bootonly.iso) = daafecdfaaeb82313891ce89a15be37bb046ea8a0912e7b7da544224c2511d936a579e9d353ccc48432728ecbea93307d6dd5ca7b8e8346663711eaeaedd1762 SHA512 (FreeBSD-10.3-BETA1-i386-bootonly.iso.xz) = a22c32debc77248973e0fd69c2bb172bbeb30fc807cd843b79a373ef34dc6507b5b44d22f18e89a1a072a49c0133e14f106cd8240bb4fff2f8e88726b3cc0d38 SHA512 (FreeBSD-10.3-BETA1-i386-disc1.iso) = e4ad76294a572460414010eadfd2508725621e2c77552b40467f652bd40d8a911a17a9e3a3e70ccb5d89d51fcea39867542d09e1baa4196e949ea36705f9662a SHA512 (FreeBSD-10.3-BETA1-i386-disc1.iso.xz) = 71953ee7ed8a58f4dd2c0765a76392a33338be0cc225b2312e09ff641370bcd1ce33cd003b2e4bcdf65c2ecbf00a1dabce39444dded9eb360b8936c742599a70 SHA512 (FreeBSD-10.3-BETA1-i386-dvd1.iso) = bdd29959e0deac3f1c6af4e5a22228969f83dec0863e651b6183d2ca0af9af964e3807c14f0fdc1302ee4d97acb6dd1b25cf4688e89a54b0367547b8ba467bfb SHA512 (FreeBSD-10.3-BETA1-i386-dvd1.iso.xz) = 783c9d712d5f23e9a694ff038b523dba630b5eba0a33379be45c7a9a788b8e165e44fe8a9388291bb2cefc232100394c6882ddf2df8b78831f8ceba29838ecf6 SHA512 (FreeBSD-10.3-BETA1-i386-memstick.img) = 3977f26436a786f4f980dbdd80a3cf43c380a667e876f4f4e326c9029c5ffeb32e5fe690fba66d2ebd6320f916fdb9ac969bcd589b17de9f67dc57c2bff2b8f2 SHA512 (FreeBSD-10.3-BETA1-i386-memstick.img.xz) = fa934202ad03b9a8c4e9902f0a70bee1002dd9870287dec481362788b41dc7af815fe25a9856c95b64de609e1a5c002dca9963ccc27d8af2b65c7d92b24590c0 SHA512 (FreeBSD-10.3-BETA1-i386-mini-memstick.img) = b92ca16dcadcac0448ac91edb7b603a594ea5e725bd153e63a7bfbbee092e160c3517680ab27785aae772c44359055ae02fa30f568b0b75eddba761964f17183 SHA512 (FreeBSD-10.3-BETA1-i386-mini-memstick.img.xz) = 728f78f934bfb7755928ed6596e46a07972e9a2b7a9a45068a74f127818457da6659eaff4549f42d0abbf838255cc9b6e2528e8235c88badf5ad6fc2cd25eda0 SHA256 (FreeBSD-10.3-BETA1-i386-bootonly.iso) = a581fe4d75f517f4ab21ce13a7b5faba0fc0324ad8c78455a52978c10e149f6e SHA256 (FreeBSD-10.3-BETA1-i386-bootonly.iso.xz) = 436d55fe56558ffbf8064576428a4c0e23f0589a2e9d348146cb1194b3d9b8d1 SHA256 (FreeBSD-10.3-BETA1-i386-disc1.iso) = 8aede16331c39bfe696052a68873a1416d149075daa2afa5e55936511cdb8d7d SHA256 (FreeBSD-10.3-BETA1-i386-disc1.iso.xz) = fb0903bb912b08596c5a793e9bed91ce278047ac092481c5157e3b0939676092 SHA256 (FreeBSD-10.3-BETA1-i386-dvd1.iso) = aa3168d8987e790c30447f72918d19e8a803587784b2852ddc7ddca4c5b75f54 SHA256 (FreeBSD-10.3-BETA1-i386-dvd1.iso.xz) = f917208ad5238323c8e276c07892f890b69786386ec74afffcdd37246f6010b5 SHA256 (FreeBSD-10.3-BETA1-i386-memstick.img) = 9e4646bf5500a9d896138a139950ed50b6ae31ef1facf63967a070927c9c9c96 SHA256 (FreeBSD-10.3-BETA1-i386-memstick.img.xz) = f3dc6beb9304d10bc638cd8159e826eaa5de9de91da5fa76d1f0284b35c68aab SHA256 (FreeBSD-10.3-BETA1-i386-mini-memstick.img) = b5ded5d948e919c7522bcbcfcdbb50cc3726a87d940c212e0eb27a9a0ec56e74 SHA256 (FreeBSD-10.3-BETA1-i386-mini-memstick.img.xz) = 132e979280fb8608a6a9012ddcf2b564408f18bedb98e004bc8480c1e8b74cfe o 10.3-BETA1 powerpc GENERIC: SHA512 (FreeBSD-10.3-BETA1-powerpc-bootonly.iso) = edc9669ad8d84dcf47bfd887171a7b700fed15445725c74cc8a858588eeadab1563c3854621585369c8e312c5ded3eb8c17dd2166a65e3281e703a049adbd097 SHA512 (FreeBSD-10.3-BETA1-powerpc-bootonly.iso.xz) = c351836a68fc98fdd0493e548659fb86f0811c42cdca0d317bdfb475fda13e8119ff882e0fa113041277b9f04853633a380a95dd1b95a5a36053646a6a92a264 SHA512 (FreeBSD-10.3-BETA1-powerpc-disc1.iso) = 36276c1de7073859f4b1ba55f4977333d9b7d23e41801a1063d7d175817e8a5d304209da699104089abdf54eeafc2e3530cead1eeb6fb0847904c513bcc43dad SHA512 (FreeBSD-10.3-BETA1-powerpc-disc1.iso.xz) = ce7c2896c362a534a6e9ff66744f06c095e7f56744e2c9807b8710e39ad6453883e377a5ac61e2098ebf54c72cb114a3acfbf6e005912798fa1c8ed40cefa72f SHA512 (FreeBSD-10.3-BETA1-powerpc-memstick.img) = 242ec459c1370bf7aebb8921b6c62e784ba6fa2a30d7353ef74edc9685d816fa451f288f1d35bdc6dfb0b05ad312dc88b9c6de4dccc4f51fcc137ff16c939f5e SHA512 (FreeBSD-10.3-BETA1-powerpc-memstick.img.xz) = 7bb9ec851bfd2635bd099783742362a1d7c2c9bff545823239438938252f81ddb17b2611807b3908190c27a9b8eac6ba1fce6c40939872065931b75da3316608 SHA512 (FreeBSD-10.3-BETA1-powerpc-mini-memstick.img) = a48f5000c5943c80ffb4e5179163539737385b524365c71d312ff8ba177c4aabe6aaed4711a099eaf052af0824e8cdc4c1e015e2ff02eef6eff83d493d14bfde SHA512 (FreeBSD-10.3-BETA1-powerpc-mini-memstick.img.xz) = 2a221fd917eff89916947793a8cada94180a4176f900f3d7b4752f73ed882757c8ca7509e12fbb2413d21fb84ab3be7a41d0b2d201d9dccdd002d4d2354dc092 SHA256 (FreeBSD-10.3-BETA1-powerpc-bootonly.iso) = cd3d6e45eceab53ebb950aec592c6df6747b75551821fee7d46a2c31064c9ed2 SHA256 (FreeBSD-10.3-BETA1-powerpc-bootonly.iso.xz) = 5cb966e8896757401a3ef1ab7bb4fe47e96054d972a1510ed7c957b045e04d9d SHA256 (FreeBSD-10.3-BETA1-powerpc-disc1.iso) = 41bed72a95d9f602f9e08264a1234e44a3623d400f6c14d018fcb58db9d615b1 SHA256 (FreeBSD-10.3-BETA1-powerpc-disc1.iso.xz) = dc83adcd388e53a041336de61ec2eb6c4b60d4e203d8bdc07d33222739a01bd5 SHA256 (FreeBSD-10.3-BETA1-powerpc-memstick.img) = e616b831012033340b96698ea0295b5a4fb912f40eb8d02da8a54f8aec83cf77 SHA256 (FreeBSD-10.3-BETA1-powerpc-memstick.img.xz) = 6b2a45391d63bf7a3689daaf414140a569831d2b2b71fa90a8926c05988f7beb SHA256 (FreeBSD-10.3-BETA1-powerpc-mini-memstick.img) = 29e4852250bb38d9ae06d78ef15402755fe058197ecb575de215e94213b32686 SHA256 (FreeBSD-10.3-BETA1-powerpc-mini-memstick.img.xz) = 3f074b8cb04cba141a0f1be390b6879824f451a84f759657371b8165d3ddd7f1 o 10.3-BETA1 powerpc64 GENERIC64: SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-bootonly.iso) = 6abfc3781496a2fe245cb0bb6a8f63a1d9f2391de53ef0e2f8e9c42e2f6889485e12e402fe5422c4a6d8a017cb9085022a4214ceaf54b5fb893d13dc400cb1be SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-bootonly.iso.xz) = 18d55b79c39b5834b76011bb3cc40eb5f823caf5101dd5443e63ba11edf03e650ef65d5eef305a8efeb35aa6f6dc60082c91afbe4d3568013946306dfc224654 SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-disc1.iso) = 2cc029e0bc99dd1b805a6a954fdcaf1fdb7326f8b245c770b8afa6e030dd03b6d627048bd50714a218fdedc1137232904979f575179acf1544bd398dbe801997 SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-disc1.iso.xz) = bac7f988db8e1a7ffae7c059e9622d2ec86a4fafb6c924a85b6896705e57ea35026554a60664ce29c9b15dc968787120281044f39c968ffdefc7c6d227eb10d2 SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-memstick.img) = 487ef1cd6adaa054b32c2df68246396a7379cfcf13625deb228f61b7a4e24e7e57829e2dfe0eb070aa0548b69e9cae93664c0ba8bfd2756a1b2a8b3edce5a14a SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-memstick.img.xz) = 457eda7d3e1fe395ed90efc7dd9d007195e4ad19dea3b7216865b004217328731f75efe88be2791a7f908bd674441a22f76b791c6cdd444f65e9ae78ae9542e4 SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-mini-memstick.img) = d516d0cb96225b567baa010f9bab1bae898481a637d7e960be64acaa216ba141badabbb8181e6a3ee4ae1a0255e09d6bb918dbc7732d21931d561e2695844f68 SHA512 (FreeBSD-10.3-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = 9a7dd0344de74f89f74239add0e5da517baf30fb9b6f78ea95d28a63464e8eeead27bd35983b3bc3bb190bf7a3d796ccefa6dcd078a5a0c2ca3586ce2e38eb23 SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-bootonly.iso) = 05bb9ee806c01998c3d76228891401a9f4aab9fda449d45c0c38a2dddbfcaa2b SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-bootonly.iso.xz) = 0b3b1bca9c01ac289b1a0ec8d66219f202c5cebd405eed32be7cc633c785a60d SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-disc1.iso) = 7c80407194ef619440b9b4ab8224e4c7a6744d58f1a9bf0f4d47386569f39d49 SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-disc1.iso.xz) = 8b6002bbe202b296b67d63a5b5b3f4618d1059d00af96bc257018a8f5f2d6a02 SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-memstick.img) = 2b7fe6f7ee3b5be0790b8517fcc6101db61cd1494edc6b493ff43cc88191faef SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-memstick.img.xz) = 08f62e07292ee863017f9005bd9594000f83d11f2bfd1f38dc5ce5d854d48ce2 SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-mini-memstick.img) = f9cac1c87e9fb736f52f810898fc7840c9ec05ce4bea013b518d8001eaae8ba2 SHA256 (FreeBSD-10.3-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = f97ceddd280c9b62ac9c04a93e3ac83024de5e5bdb5d4280bc8a8485e96e59b9 o 10.3-BETA1 sparc64 GENERIC: SHA512 (FreeBSD-10.3-BETA1-sparc64-bootonly.iso) = a26054c1f8939055ef98b00f084fd926d9716ed638c7c54246bb61fd0f7acee90855eddc67011ef8fe65e4f10fb0b68e70d576f065fd7812143098be0856d0da SHA512 (FreeBSD-10.3-BETA1-sparc64-bootonly.iso.xz) = 7eac7013b2ca4313875f7989ce3f62242b1af0d36452b801d76f9051cd45ec85fd9c2acb1a57abe9ee3358dffa87dace9549ea6533e6e6881d8ef80912e01336 SHA512 (FreeBSD-10.3-BETA1-sparc64-disc1.iso) = 56c6a26c414eff4e31c11ce9bcf0414a027752f9a234649b92d323a847dd1040b6e54ea6802c252d323b3e7450af6d77e393ef8e4d0910cbf8417502ac56f047 SHA512 (FreeBSD-10.3-BETA1-sparc64-disc1.iso.xz) = 1b8bdad6105e86267cda2b74891532d1f2cb93fd0528c9a571501a5bcb5ac2d7670f23c860c10643ddebc03b34e9ef4eb74b35c943a1c64016432228301ed957 SHA256 (FreeBSD-10.3-BETA1-sparc64-bootonly.iso) = 98bb83f691ed53d010cc5edace0a069989a6e3dca6728cee351af98f3c4b06ac SHA256 (FreeBSD-10.3-BETA1-sparc64-bootonly.iso.xz) = eb3156a9f0b49c1a3bdf56563934a9da90db2cba59548ac10ff6fa0ca8b83241 SHA256 (FreeBSD-10.3-BETA1-sparc64-disc1.iso) = 6d7b54417a43e8884f733c6f675e13b23801ae05835e4afa33ac676ab25cd764 SHA256 (FreeBSD-10.3-BETA1-sparc64-disc1.iso.xz) = eb22e1919caa590c09abab355bfa6b2ffff92ec7f6d3ef674b8a1a58642c9f60 o 10.3-BETA1 armv6 BEAGLEBONE: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-BEAGLEBONE.img.xz) = 07e373f40b92d073443074fad48c589a5dfcdf613762cd72891be3843fe4452dd9685dba628a0f2016a2bee570fd8394c6237c0fb0e2a87b02365e6cff335cf4 SHA256 (FreeBSD-10.3-BETA1-arm-armv6-BEAGLEBONE.img.xz) = d401ea33a643ceb84a8d7eac473ca410f3d0d42b4ee6c2aeca8bb6f504229426 o 10.3-BETA1 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = b8d7029d3286af7edcd7e95bf509f21450b86e754eea41014cadfd914f02c41412737eca71ae6561b156a54ff4f97b8986655d4d547268549009195c4a76dd54 SHA256 (FreeBSD-10.3-BETA1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 970a1555dc59513823e96fc76e3c14e2aba06479b14896f0c15684aeff5789b3 o 10.3-BETA1 armv6 GUMSTIX: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-GUMSTIX.img.xz) = b099bc7345ec67f15c9b6f67822214704ce356575d0d27e78e7af718fa77d5e916c5bce518a92b17e0eec8709bbfe301f318271323c55c5897dfe93ba077235a SHA256 (FreeBSD-10.3-BETA1-arm-armv6-GUMSTIX.img.xz) = 818bfec4a68df6095a4953b89889de54f3d928b42e8c037671ed9f1e0b556b12 o 10.3-BETA1 armv6 RPI-B: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-RPI-B.img.xz) = 157bf65982a75c284684d53c378838a9b0df4bada59d3b698305aa99ce84e86a6f42b381f88d74dd9d0fd13a8d364fca6a24d6edbda6254674eb34881376c241 SHA256 (FreeBSD-10.3-BETA1-arm-armv6-RPI-B.img.xz) = 3aa4b60fe4d254eb6aaeffc4ff7826521b4ccc75e85e7bb4df7cab3583753b52 o 10.3-BETA1 armv6 PANDABOARD: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-PANDABOARD.img.xz) = 0e98bfcb049b63ef50670179dc993c41601bca8af6da36d72d84af8cbff231b2f97e413482d0f385a6b49026e9a79a3f9b735aa84dc21e1b1998f2aad5e4cd3d SHA256 (FreeBSD-10.3-BETA1-arm-armv6-PANDABOARD.img.xz) = 328de97edc75e60d9d670358d04909c8c989c186266eda8ef7312101407fe720 o 10.3-BETA1 armv6 WANDBOARD: SHA512 (FreeBSD-10.3-BETA1-arm-armv6-WANDBOARD.img.xz) = 5abe99a5d29ab5a563205b04ba22ea56297147905791b38f2764104cdc20820e81fe568e62f42113308dcd81c4f7b4d3c38ad7c6398641b4923c64426f79c36c SHA256 (FreeBSD-10.3-BETA1-arm-armv6-WANDBOARD.img.xz) = 988c81a754f2fd1039e7fce189d7262280158b7be4d679d45924ac6aff6996e6 == VM IMAGE CHECKSUMS == o 10.3-BETA1 amd64: SHA512 (FreeBSD-10.3-BETA1-amd64.qcow2.xz) = 5f341ca978a6094e8a7aaf48605ff23f0ae8dd0a8e58af0a52402c411f7f8c676e9f633c989a06359204e51064de02665d78ce210a0a03f3a4edaa4f795d5320 SHA512 (FreeBSD-10.3-BETA1-amd64.raw.xz) = 606bf6f84baea7f3969e30212c626c32875691e4c15952018dcc5e1d9e68e706cc5dd5af7b42fd9d93e6af4385b6746a328f1e7f99c3bcb76beb9cb46bab8994 SHA512 (FreeBSD-10.3-BETA1-amd64.vhd.xz) = f8a020c1906ca06937758f8ee3a1966c90f150a8d397ba6bbd7b0d532445e75b46bcf861dc1a9640e98e3fb2d64689cd90248cfd0118a742be934bb08f9a350f SHA512 (FreeBSD-10.3-BETA1-amd64.vmdk.xz) = 265d46ee040160c298ff5c99d1b330999dbe2f698a7f67c1c832d4eb81c0d9014fcd402ea67a3bbd41fd0ddf73b07dfbf3c263f6bb0e7cc4c1eec8506a261a42 SHA256 (FreeBSD-10.3-BETA1-amd64.qcow2.xz) = bd71f2238d2c868946ce804f7ea6ab8c4ac7305e6609a79d737ea4c65d6894a5 SHA256 (FreeBSD-10.3-BETA1-amd64.raw.xz) = 8b2a7199f6692847b67ebdb06a055abdcbacf7353a92501bcb9437a87c076905 SHA256 (FreeBSD-10.3-BETA1-amd64.vhd.xz) = 87d16f7a2bdeaddc934764eb9dc524f73a0d3ddc7ccb96302cc11837cf4d22ef SHA256 (FreeBSD-10.3-BETA1-amd64.vmdk.xz) = fb31fbbe30557dfbca63683a8da232c8c9bb826b8a6a2c20a17691f829d8dad4 o 10.3-BETA1 i386: SHA512 (FreeBSD-10.3-BETA1-i386.qcow2.xz) = 41cecfdf6b923fa77a76c45762c06aabc60e05632aaf70e95a2650a5ccacc1e2819120918266095cc700bd241a866dae4f9bcd018f31756927c2181906388771 SHA512 (FreeBSD-10.3-BETA1-i386.raw.xz) = 3e9677396a5b0821f83c3bfcc64ffa83d34ee2c08fa1a7cd130b0fbb600b41ff732b2edb1b43b91c6f83b2e729c34e150e757778748e2c6e77aacb328986b228 SHA512 (FreeBSD-10.3-BETA1-i386.vhd.xz) = 1730940f448c4a17a2150f9354ec0a173c474aade85ee6c0306ffdeb1e3d4acac80d6f3f36e8ce128df31957444538f2db2a3ec06bbda1b3cdda80f111ce86bf SHA512 (FreeBSD-10.3-BETA1-i386.vmdk.xz) = 58d9cbd86ec1c5c9bf67bfbf53647cffb7bc1e24a283fcd14e11b6426055e593712ed2feb78684d150b9bd398aa513a29a476430819aea4535d7cf88d4fef093 SHA256 (FreeBSD-10.3-BETA1-i386.qcow2.xz) = a9da1845afece99672270ac7780526d1cdf2b51a3a64479ca1426fa9056b8b6e SHA256 (FreeBSD-10.3-BETA1-i386.raw.xz) = 0dd6521c712005e273ffa220b9f6a4725d3cf8f4fd6f93bf67f1d4cead8beba8 SHA256 (FreeBSD-10.3-BETA1-i386.vhd.xz) = 3350c24da11562697d02c409bc4ba9e15336dfe2e2c28822dd0e486947698cd0 SHA256 (FreeBSD-10.3-BETA1-i386.vmdk.xz) = dc0a464bb475545a4b9172b48ba507772e000d8d687ef4099412b4cdf8903a25 Regards Marius --zPXeIxDajdrcF2en Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWtZYWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5Pv1MP/0HhKnCQpgP757aor6esbxxE dkLrp1LnckamcY78/DLDaBZElbKUtonYgzpKGAN+6us9k6T/fRuA+ebJc/3k/TW9 PeqJIPGxnQoLYGiaa5sL8YfgkaixhBk9jJAsjYIo4Ncj5jY4seb6GpqxXK0o1z8E X+cJZWx7IymWTq1YxOVOvX15GksIRAJiLdTw4ebB5wJl+nyhhv1H6wdQVeFqbl/R YdMtCFlFD250cfki9nFcnNl/ugJta9KNkSu3gxqOrItjXifGNUlTDXT1vumX1Ops Dl6f8H2CGwYel67jlb6Y4YKDwfY6tzyT3tU5D8nAzDHpSrXsB/Tr51z6sG98OzJY zEP5605yFf5kLmjHEnzXRSYePelz+4eWAzsFzTw/+EbwD13Svt0H6rX3pPSrIOMb 4QDk5QIi7R2S71FhgBQNOfmY6g6wCXO0IDogaCFfGGl9lF1/Xwm3jtye6LoSTeBE 2qdfODjJTavBCK+i4x1aYHvVvHEPQTvvp/0S0pxUbYXGKDchA0ktFR+0nZ2ueTrn 2har2rCp5hFcBCZrlqz1xKHvciCOS7gkLOxv0Htfs94MFqoGW/bPlGLBP3W80jjq 68c2g2An1J9IKz5giKbg2ArSNq2L1wrcTrUQ261iNahSWgFd8/Tdvb24OSMtJV3R PQEcGnPtQSiAnSU+xxps =zIvL -----END PGP SIGNATURE----- --zPXeIxDajdrcF2en-- From owner-freebsd-stable@freebsd.org Sat Feb 6 11:13:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E458A9FA66 for ; Sat, 6 Feb 2016 11:13:35 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (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 1B5D519EE for ; Sat, 6 Feb 2016 11:13:35 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) 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.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aS0ny-000CGn-OV for freebsd-stable@FreeBSD.ORG; Sat, 06 Feb 2016 11:13:30 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aS0ny-0004Id-M2 for freebsd-stable@FreeBSD.ORG; Sat, 06 Feb 2016 11:13:30 +0000 To: freebsd-stable@FreeBSD.ORG Subject: Re: Recent -STABLE crashes out of swap at 3am every day Message-Id: From: Pete French Date: Sat, 06 Feb 2016 11:13:30 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 11:13:35 -0000 Followgin up my own porst - I did some investigaing, and this is caused by the security scriots, which are now increasing wired pages a lot. This appears to push normal procsses out into swap until swap fills. Disabling the secuiryt scripts and the system no longer crashes. So, what changes between June last year and now which would make wired pages behave like this ? Am a bit uncomfortable with the fact that upgrading the OS makes a system go from working fine to runnng out of memory, that doesnt seem right. Did the kernel memory allocator for ZFS chnage during the last 9 months (when did it move the UMA?) -pete. From owner-freebsd-stable@freebsd.org Sat Feb 6 14:21:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06D1FA9F5BF for ; Sat, 6 Feb 2016 14:21:06 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 C0696FA7 for ; Sat, 6 Feb 2016 14:21:04 +0000 (UTC) (envelope-from jim@ohlste.in) Received: by mail-qk0-x22b.google.com with SMTP id s68so44542077qkh.3 for ; Sat, 06 Feb 2016 06:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ohlste-in.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=WJOqktsmmyGQzBBpB3rnDsfxD4t4ku1Dlr1/BXpUmls=; b=Y/aYNIVHUoHKy4mtgQdLFucvpvaFJMY025AIbdqH+BxH1glSslhEztEVZ0rC/vjqq4 MfWuAlTEBb7V3wa+x3DSEeKt7VMvtgCrWLUJeU7n/UT4kD9xBXJ3GF7kOvQK9qouBFfh LDHvkwUFeD6MUMh8ydv61COeoNJLiij5G4/TUZFcbHjl5k/HYoXFWWGc6+JKsHIEoSjQ QilvWZxHzwg/AnEYp0MBec4h7Ud/ubfCXESPeOBo1lWJxQZ1TJoMVm4DCxlRe0SQo9bQ nGJD6hCR0web+PVX6RbsQCvn8mWGWdhqrPk9jj7eMEjZ4MJTony+Xx5u7xgsCjJtDq5n gFEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=WJOqktsmmyGQzBBpB3rnDsfxD4t4ku1Dlr1/BXpUmls=; b=mSJiTV7BeQEOt24ds14HTLZxOIfZ57FynvKH3QjxjayiNvEqi8OONs2RfQWHyxBf5M AqTzJ2DvHXzoh+Z9y0S/iDtzO/DoneOnUNEdHKi9nX3iuIqgJ/Q+AMVlzAK14c0I/VXz 0+V5ZqY26v6AickwOwg8uZx3S27amWmkz5EvfGBBJ13/lvwMKNpxQnt1MuMY+Om33e32 F5/dBPVSDaWzRA7WgNtEHr9tFC+um1rG+6RgaIcagC9sFVL0MhF/+5LZvsDixMcqiE3G VJ9KeoRUrQjHL6CMhT4KKeYM0TRBUyVEo3I+Fp9bqaTT5xUhaC1wfTpmU21cIMIf27WS /5XQ== X-Gm-Message-State: AG10YOTChmhxNTRBTkK95P9fKrs77W8GY3aavAnZGyskDlFrE55jetESWlakEgP7YRwEeQ== X-Received: by 10.55.73.199 with SMTP id w190mr23015130qka.77.1454768463622; Sat, 06 Feb 2016 06:21:03 -0800 (PST) Received: from [192.168.1.18] (pool-96-249-243-37.nrflva.fios.verizon.net. [96.249.243.37]) by smtp.googlemail.com with ESMTPSA id e127sm10171098qkb.34.2016.02.06.06.21.02 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Feb 2016 06:21:03 -0800 (PST) To: freebsd-stable stable From: Jim Ohlstein Subject: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE Message-ID: <56B6014D.9090602@ohlste.in> Date: Sat, 6 Feb 2016 09:21:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 14:21:06 -0000 Hello, First noticed: root@rubicon:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295341 Node Kind: directory Schedule: normal Last Changed Author: marius Last Changed Rev: 295289 Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016) Still present: root@rubicon:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295351 Node Kind: directory Schedule: normal Last Changed Author: wblock Last Changed Rev: 295350 Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016) root@rubicon:/usr/src # make clean && make buildworld [snip] cc -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /usr/src/lib/libfetch/common.c -o common.o /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL' [-Werror,-Wunused-parameter] fetch_ssl(conn_t *conn, const struct url *URL, int verbose) ^ 1 error generated. *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libfetch *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src I had several options enabled in /etc/src.conf but "WITHOUT_OPENSSL=TRUE" is the culprit. World builds fine as long as that is commented. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain From owner-freebsd-stable@freebsd.org Sat Feb 6 14:41:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1885A9FD6B for ; Sat, 6 Feb 2016 14:41:26 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 331351BE2 for ; Sat, 6 Feb 2016 14:41:25 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id u16EfEP5072078 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sat, 6 Feb 2016 23:41:17 +0900 (JST) (envelope-from ume@mahoroba.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mahoroba.org; s=20081103; t=1454769678; bh=xJQFthRHPK3Ln8FR13wBY5EvT2TXH6/+R6kHXf8cl1Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=B0kJt+tnsFoJ35vbr4qgdLF4wk+M36TAh6Zg22I4U3CLB4B+Kqev2B5py8rwACk7N EMZMRWqisHbKGnHOkkEOU2bE2nAgrkmme57ilvB51fXU05F6e3Nr45geBEd7Axi6Sm /jM1/CcfRfG+9isBWyZ7NcdxnVO21Jw6xHQYKIYg= Date: Sat, 06 Feb 2016 23:40:50 +0900 Message-ID: From: Hajimu UMEMOTO To: Konstantin Belousov Cc: Steven Hartland , freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently In-Reply-To: <20160202125237.GS91220@kib.kiev.ua> References: <56B06EB9.2090406@multiplay.co.uk> <20160202125237.GS91220@kib.kiev.ua> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.3-BETA1 X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6a2 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 06 Feb 2016 23:41:18 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 14:41:26 -0000 Hi, >>>>> On Tue, 2 Feb 2016 14:52:37 +0200 >>>>> Konstantin Belousov said: kostikbel> Please gather the information listed at kostikbel> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html I tried the instruction. But, the debugging kernel hang-upped during boot. Therefore I cannot get information. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@freebsd.org Sat Feb 6 15:04:42 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 412F6A9F77F for ; Sat, 6 Feb 2016 15:04:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 C6F295E2 for ; Sat, 6 Feb 2016 15:04:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u16F4ZQY013683 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 6 Feb 2016 17:04:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u16F4ZQY013683 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u16F4YNo013682; Sat, 6 Feb 2016 17:04:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Feb 2016 17:04:34 +0200 From: Konstantin Belousov To: Hajimu UMEMOTO Cc: Steven Hartland , freebsd-stable@freebsd.org Subject: Re: 10-STABLE hangups frequently Message-ID: <20160206150434.GV91220@kib.kiev.ua> References: <56B06EB9.2090406@multiplay.co.uk> <20160202125237.GS91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Feb 2016 15:04:42 -0000 On Sat, Feb 06, 2016 at 11:40:50PM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 2 Feb 2016 14:52:37 +0200 > >>>>> Konstantin Belousov said: > > kostikbel> Please gather the information listed at > kostikbel> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > I tried the instruction. But, the debugging kernel hang-upped during > boot. Therefore I cannot get information. Where did it hang ? Provide the verbose dmesg log of the hung boot. Are you able to enter ddb after the hang ?