From owner-freebsd-stable@FreeBSD.ORG Sun Jan 18 12:11:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5710F1C for ; Sun, 18 Jan 2015 12:11:20 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72155217 for ; Sun, 18 Jan 2015 12:11:20 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t0ICBG8H066120 for ; Sun, 18 Jan 2015 13:11:16 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 520D0986; Sun, 18 Jan 2015 13:11:16 +0100 (CET) Message-ID: <54BBA2E3.5070401@omnilan.de> Date: Sun, 18 Jan 2015 13:11:15 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: sonewconn: pcb =?UTF-8?B?MHjigKY6IExpc3RlbiBxdWV1ZSBvdmVyZmxvdyBb?= =?UTF-8?B?V2FzOiBSZTogbGFnZyg4KSBjYXVzZXMgZ2hvc3QgcXVldWUgd2l0aCBpZ2IoNCk=?= =?UTF-8?B?XQ==?= References: <54B962A3.9010308@omnilan.de> In-Reply-To: <54B962A3.9010308@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB21CC374DF34460FAA42599" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sun, 18 Jan 2015 13:11:16 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 12:11:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB21CC374DF34460FAA42599 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Harald Schmalzbauer's Nachricht vom 16.01.2015 20:12 (localtime): > Hi all, > > while investigating a watchdog timeout problem (on FreeBSD-10.1-stable > r276295) I noticed "ghost" queues consuming interrupts with > igb(4)[82576] if igb(4) is member of lagg(4) (laggproto loadbalance > lagghash l2). Mysteriously only sometimes (1 of 2 runs). > > Sending machine has only one ssh session open, where I do the following= : > 'dd if=3D/dev/zero | nc vegashare 3333' (of course on vegashare is a > listener [nc -l vegashare 3333 > /dev/null]) > > I'm transfering 123.5*10^6 Bytes/sec and on the sender, systat reports:= > 2682 igb0:que 0 (1 of 4 queues causes moderate irq load hw.igb.aim=3D1,= > otherhise it were 16k irqs/s, nothing on the other 3 queues) > > But roughly every second run, I see a another queue consuming much more= > irqs/s while transferring exactly the same at exactly the same speed: > 7740 igb0:que 0 > 2640 igb0:que 3 > > Here's again one queue with 2.6k irqs/s, but another one with 7.7k > irqs/s which I can't understand what this is doing. It's useless for > sure, because with only one queue I get the same payload transported on= > the same hardware with the same speed and 3 queues idle=E2=80=A6 I noticed another mysterium, at least for me. I'd highly appreciate if somebody could give me a hint how I can understand the following lines sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already in queue awaiting acceptance (1 occurrences) sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already in queue awaiting acceptance (220 occurrences) I have never seen them before and I guess it's related to my other queue mysterium. They occured not during tests, so not during artificial (high) load, but regular low avarage load. Thanks in advance, -Harry --------------enigDB21CC374DF34460FAA42599 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlS7ouMACgkQLDqVQ9VXb8jl2wCgkdntdxgfNqTmlXLAiGrkmfSN F4YAni7QGhDwzZBaPgzpcI+VdFpxUCHc =ga9+ -----END PGP SIGNATURE----- --------------enigDB21CC374DF34460FAA42599-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 18 12:20:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EDD418F for ; Sun, 18 Jan 2015 12:20:05 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C72F0283 for ; Sun, 18 Jan 2015 12:20:04 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t0ICK2pD066142 for ; Sun, 18 Jan 2015 13:20:02 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B3DA2989; Sun, 18 Jan 2015 13:20:02 +0100 (CET) Message-ID: <54BBA4F2.4010904@omnilan.de> Date: Sun, 18 Jan 2015 13:20:02 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: sonewconn: pcb =?UTF-8?B?MHjigKY6IExpc3RlbiBxdWV1ZSBvdmVyZmxv?= =?UTF-8?B?dyBbV2FzOiBSZTogbGFnZyg4KSBjYXVzZXMgZ2hvc3QgcXVldWUgd2l0aCBpZ2I=?= =?UTF-8?B?KDQpXQ==?= References: <54B962A3.9010308@omnilan.de> <54BBA2E3.5070401@omnilan.de> In-Reply-To: <54BBA2E3.5070401@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2323ED26D3C713F43EBA69E6" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sun, 18 Jan 2015 13:20:02 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 12:20:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2323ED26D3C713F43EBA69E6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Harald Schmalzbauer's Nachricht vom 18.01.2015 13:11 (localtime): > Bez=C3=BCglich Harald Schmalzbauer's Nachricht vom 16.01.2015 20:12 > (localtime): >> Hi all, >> >> while investigating a watchdog timeout problem (on FreeBSD-10.1-stable= >> r276295) I noticed "ghost" queues consuming interrupts with >> igb(4)[82576] if igb(4) is member of lagg(4) (laggproto loadbalance >> lagghash l2). Mysteriously only sometimes (1 of 2 runs). >> >> Sending machine has only one ssh session open, where I do the followin= g: >> 'dd if=3D/dev/zero | nc vegashare 3333' (of course on vegashare is a >> listener [nc -l vegashare 3333 > /dev/null]) >> >> I'm transfering 123.5*10^6 Bytes/sec and on the sender, systat reports= : >> 2682 igb0:que 0 (1 of 4 queues causes moderate irq load hw.igb.aim=3D1= , >> otherhise it were 16k irqs/s, nothing on the other 3 queues) >> >> But roughly every second run, I see a another queue consuming much mor= e >> irqs/s while transferring exactly the same at exactly the same speed: >> 7740 igb0:que 0 >> 2640 igb0:que 3 >> >> Here's again one queue with 2.6k irqs/s, but another one with 7.7k >> irqs/s which I can't understand what this is doing. It's useless for >> sure, because with only one queue I get the same payload transported o= n >> the same hardware with the same speed and 3 queues idle=E2=80=A6 > I noticed another mysterium, at least for me. I'd highly appreciate if > somebody could give me a hint how I can understand the following lines > > sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already i= n > queue awaiting acceptance (1 occurrences) > sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already i= n > queue awaiting acceptance (220 occurrences) > > I have never seen them before and I guess it's related to my other queu= e > mysterium. Sorry, I should have asked someone to type that into a internet search portal for me before posting here ;-) The pcb address is a unix domain socket, so completely unrelated to my igb(4) queue mysterium! Please excuse, thanks, -Harry --------------enig2323ED26D3C713F43EBA69E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlS7pPIACgkQLDqVQ9VXb8jxhACeJZXo3YoMEhNjt0rlgZEI6UM1 FvMAoKW0H2/BvKuq5N5h/aec0CjYN43I =xfS/ -----END PGP SIGNATURE----- --------------enig2323ED26D3C713F43EBA69E6-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 18 12:21:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64286292 for ; Sun, 18 Jan 2015 12:21:48 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 1FA2E352 for ; Sun, 18 Jan 2015 12:21:48 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YCorS-000L6b-0k; Sun, 18 Jan 2015 13:21:46 +0100 Date: Sun, 18 Jan 2015 13:21:45 +0100 From: Kurt Jaeger To: Harald Schmalzbauer Subject: Re: sonewconn: pcb 0x???: Listen queue overflow [Was: Re: lagg(8) causes ghost queue with igb(4)] Message-ID: <20150118122145.GW44537@home.opsec.eu> References: <54B962A3.9010308@omnilan.de> <54BBA2E3.5070401@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BBA2E3.5070401@omnilan.de> Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 12:21:48 -0000 Hi! > I noticed another mysterium, at least for me. I'd highly appreciate if > somebody could give me a hint how I can understand the following lines > > sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already in > queue awaiting acceptance (1 occurrences) You have a socket open in the LISTEN state. Incoming connections must be accept()'ed. If the process that LISTENs is too busy to accept, the so-called 'listen-queue' is growing. I have found kern.ipc.soacceptqueue: 128 and I assume that this is the max. number of incoming connections waiting for accept before the next incoming connection will cause that error (and is not successful any more). I do not know how to match the pcb (protocol control block) back to the process/LISTEN in question, but maybe someone else knows this ? -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Jan 18 12:25:01 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48D513A4 for ; Sun, 18 Jan 2015 12:25:01 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACB0436C for ; Sun, 18 Jan 2015 12:25:00 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t0ICOwSL066201; Sun, 18 Jan 2015 13:24:58 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 29BB798D; Sun, 18 Jan 2015 13:24:58 +0100 (CET) Message-ID: <54BBA619.5030702@omnilan.de> Date: Sun, 18 Jan 2015 13:24:57 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: sonewconn: pcb 0x???: Listen queue overflow [Was: Re: lagg(8) causes ghost queue with igb(4)] References: <54B962A3.9010308@omnilan.de> <54BBA2E3.5070401@omnilan.de> <20150118122145.GW44537@home.opsec.eu> In-Reply-To: <20150118122145.GW44537@home.opsec.eu> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6F07AAC60289CA2BBBD3F4B" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sun, 18 Jan 2015 13:24:58 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 12:25:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6F07AAC60289CA2BBBD3F4B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kurt Jaeger's Nachricht vom 18.01.2015 13:21 (localtime): > Hi! > >> I noticed another mysterium, at least for me. I'd highly appreciate if= >> somebody could give me a hint how I can understand the following lines= >> >> sonewconn: pcb 0xfffff801b85907a8: Listen queue overflow: 151 already = in >> queue awaiting acceptance (1 occurrences) > You have a socket open in the LISTEN state. Incoming connections > must be accept()'ed. If the process that LISTENs is too busy > to accept, the so-called 'listen-queue' is growing. > > I have found > > kern.ipc.soacceptqueue: 128 > > and I assume that this is the max. number of incoming connections waiti= ng > for accept before the next incoming connection will cause that error > (and is not successful any more). > > I do not know how to match the pcb (protocol control block) back > to the process/LISTEN in question, but maybe someone else knows this ? Thanks for your help!!! I guess after the socket was closed, it's not possible anymore. 'netstat -An' and greping will do it while active I guess. Thanks, -Harry --------------enigF6F07AAC60289CA2BBBD3F4B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlS7phkACgkQLDqVQ9VXb8jI1ACgtBsrbmvBfjrIsMCQFQzhdZyn bUgAoMjGHN9qtKfJstJ6avhgP1jjfUK4 =slcX -----END PGP SIGNATURE----- --------------enigF6F07AAC60289CA2BBBD3F4B-- From owner-freebsd-stable@FreeBSD.ORG Sun Jan 18 15:00:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4A1436A for ; Sun, 18 Jan 2015 15:00:00 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A766823 for ; Sun, 18 Jan 2015 15:00:00 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.15.1/8.15.1) with ESMTPS id t0IETlHb061910 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Jan 2015 09:29:47 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) Received: from PAIMAIL.pai.local ([::1]) by PAIMAIL.pai.local ([::1]) with mapi; Sun, 18 Jan 2015 09:29:47 -0500 From: Michael Jung To: Kurt Jaeger , Harald Schmalzbauer Date: Sun, 18 Jan 2015 09:29:45 -0500 Subject: RE: sonewconn: pcb 0x???: Listen queue overflow [Was: Re: lagg(8) causes ghost queue with igb(4)] Thread-Topic: sonewconn: pcb 0x???: Listen queue overflow [Was: Re: lagg(8) causes ghost queue with igb(4)] Thread-Index: AdAzGVisJ/stVg54R3e7BoaywseTTQAEYFdw Message-ID: <9C91F97841BC4347910F206618BAA3BB04F0EAD25A@PAIMAIL.pai.local> References: <54B962A3.9010308@omnilan.de> <54BBA2E3.5070401@omnilan.de> <20150118122145.GW44537@home.opsec.eu> In-Reply-To: <20150118122145.GW44537@home.opsec.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 15:00:00 -0000 -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd= .org] On Behalf Of Kurt Jaeger I do not know how to match the pcb (protocol control block) back to the process/LISTEN in question, but maybe someone else knows this ? I am sure there is a cleaner way but sysutils/lsof will get you there. # lsof | grep LIST named 59168 bind 20u IPv4 0xfffffe0002df23d0 0t0 = TCP ns4.confluentasp.com:domain (LISTEN) named 59168 bind 21u IPv4 0xfffffe007a44ab70 0t0 = TCP localhost:domain (LISTEN) named 59168 bind 22u IPv4 0xfffffe0002df1b70 0t0 = TCP localhost:rndc (LISTEN) named 59168 bind 23u IPv6 0xfffffe0002cbab70 0t0 = TCP localhost:rndc (LISTEN) sshd 97636 root 3u IPv6 0xfffffe0002df27a0 0t0 = TCP *:ssh (LISTEN) sshd 97636 root 4u IPv4 0xfffffe007a424000 0t0 = TCP *:ssh (LISTEN) sendmail 97650 root 4u IPv4 0xfffffe0002b9f3d0 0t0 = TCP *:smtp (LISTEN) sendmail 97650 root 5u IPv6 0xfffffe0002b9e3d0 0t0 = TCP *:smtp (LISTEN) sendmail 97650 root 6u IPv4 0xfffffe0002df17a0 0t0 = TCP *:submission (LISTEN) GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 00:47:47 2015 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 910B260D for ; Mon, 19 Jan 2015 00:47:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 794D96E2 for ; Mon, 19 Jan 2015 00:47:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0J0llGk089113 for ; Mon, 19 Jan 2015 00:47:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 193367] [panic] sleeping thread Date: Mon, 19 Jan 2015 00:47:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sasamotikomi@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: rea@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 00:47:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367 --- Comment #17 from sasamotikomi@gmail.com --- (In reply to Eygene Ryabinkin from comment #16) Yes, I use 10.1-RELEASE now and KMS+VT (also I soon switch to STABLE because it's has AGP support). -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 12:52:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 049C4894 for ; Mon, 19 Jan 2015 12:52:11 +0000 (UTC) Received: from eu1sys200aog128.obsmtp.com (eu1sys200aog128.obsmtp.com [207.126.144.178]) (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 5764B895 for ; Mon, 19 Jan 2015 12:52:09 +0000 (UTC) Received: from mail-wi0-f181.google.com ([209.85.212.181]) (using TLSv1) by eu1sys200aob128.postini.com ([207.126.147.11]) with SMTP ID DSNKVLz95FjEOfoHUNAjxV5PmnPbZqUMMbs9@postini.com; Mon, 19 Jan 2015 12:52:10 UTC Received: by mail-wi0-f181.google.com with SMTP id fb4so3701805wid.2 for ; Mon, 19 Jan 2015 04:51:47 -0800 (PST) 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:reply-to; bh=56rXmqLQIBlaJjBaRG5lMxo3SF28KIY0cQfDiUYMfVs=; b=MW5mHqUdVaA6IELQ+PLyeu+o1yuUAvgohGx+Wu11IjLSwliXaUxBvC1YGp+j20DaiJ WOo1ZT/yvKck6fPBur+LjP+8W+nu8TxEUbSUjPl2iWcxlYxLNa/gE9Rx/E4Pjmqu8BKu TSD4CAO3wTBBoi21RGYTLVsR27gt28NjF69ySxEDHMZMsqmwwoS0ZTr4EFbXU3WloC9V DFIGUtXd25i41YLTPqW9W9uvGrs6R/vtUoqaBkeLz75glpmvTQLk978knucthrkB5zP6 oYpk+nYj+s9kl4bn5fncjmQ1emQSUSdRw3Dmayi1/zJ0PXbznuQkhBoSPUHbJLdTYLxq OBsA== X-Received: by 10.194.175.102 with SMTP id bz6mr55605096wjc.120.1421656823871; Mon, 19 Jan 2015 00:40:23 -0800 (PST) X-Gm-Message-State: ALoCoQkLTSaopMXVMStehT1dxPyat0Oqw5IxPR4VewPxgnTR0McoYkXe6IaZ4zptX3fimceu/HOoBPGAxw3u5lAHy0be4+Oj5GLtfrHXCKLxZBttDM+kFtYEAPdYcqm/HawkFO5CxLL4LSimzbZ2pLpeBRwolTPmcA== X-Received: by 10.194.175.102 with SMTP id bz6mr55605084wjc.120.1421656823770; Mon, 19 Jan 2015 00:40:23 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id hz9sm16377532wjb.17.2015.01.19.00.40.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 00:40:23 -0800 (PST) Date: Mon, 19 Jan 2015 00:40:23 -0800 (PST) X-Google-Original-Date: Mon, 19 Jan 2015 08:40:21 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t0J8eLKN046378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 08:40:22 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t0J8eLtW046377; Mon, 19 Jan 2015 08:40:21 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201501190840.t0J8eLtW046377@mech-as221.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: old bug: mount_nfs path/name is limited to 88 chars Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 12:52:11 -0000 This bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 is a show stopper for me. The path/name length is beyond my control, so I cannot make it shorter. This discussion seems inconclusive: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html Is there no easy solution to this PR? Or is there no interest in fixing the issue? Thanks Anton From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 15:33:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C7D3CB0; Mon, 19 Jan 2015 15:33:54 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B66B3D16; Mon, 19 Jan 2015 15:33:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAIgivVSDaFve/2dsb2JhbABbDoNKXIMCwzYMhSVKAoFlAQEBAQF9hAwBAQEDAQEBASArIAsFFhgCAg0ZAikBCSYOBwQBGgIEiAMIDbsClAMBAQEBAQEEAQEBAQEBAQEagSGOAAcBARs0BxaCUoFBBYl1iCuDMoNoiFCIECKDMVsgMQEGfAkXIn4BAQE X-IronPort-AV: E=Sophos;i="5.09,427,1418101200"; d="scan'208";a="184802784" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Jan 2015 10:32:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B573F3CE1D; Mon, 19 Jan 2015 10:32:44 -0500 (EST) Date: Mon, 19 Jan 2015 10:32:44 -0500 (EST) From: Rick Macklem To: mexas@bris.ac.uk Message-ID: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> In-Reply-To: <201501190840.t0J8eLtW046377@mech-as221.men.bris.ac.uk> Subject: Re: old bug: mount_nfs path/name is limited to 88 chars MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:33:54 -0000 Anton Shterenlikht wrote: > This bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 > > is a show stopper for me. The path/name length is > beyond my control, so I cannot make it shorter. > > This discussion seems inconclusive: > http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html > > Is there no easy solution to this PR? > Or is there no interest in fixing the issue? > Well, the "easy" solution is to just increase the value of NNAMELEN and rebuild everything from sources to use the modified sys/mount.h. (If you can run a modified system built entirely from sources, I think you can do this.) However, this can't be done in -current because it breaks the statfs(2) syscall API, etc. There is a patch in projects/ino64 to try and change ino_t to 64bits and I think it also included changes for this. - It would need a new statfs(2) syscall and versioned library routines for everything that uses statfs(2) in libc, etc. So, for -current the answer is "it is not easy". There was a patch floating around that truncated the path to 64bits, so that the mounts are allowed but not reported correctly via statfs(2). You can probably find that patch and use it, if a broken statfs(2) isn't a problem for you. rick > Thanks > > Anton > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 16:22:19 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D9A1916 for ; Mon, 19 Jan 2015 16:22:19 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B3D3316 for ; Mon, 19 Jan 2015 16:22:19 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id c9so5168526qcz.7 for ; Mon, 19 Jan 2015 08:22:18 -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=y+RWCZ9PYia0qYPPHfmegci3iTMUgjGCxIx0NBlOi5s=; b=qsBm//6yx8NqT86YryXXKBVoHeS3vXlEyhl/lWrZDwLsbxraN5XYkFKFM+MWsAdT+z OMbsJZBE/YJ/EW/ia4dM3T6g11baWHJmI/I+oKfEDm9ldcvUu2cEcM3f0FM5rfFraRcK MDy/VF5x10/1A6NQLUAPROvJHXGEIYSwafhC85hpQp+KV219VBnRryA7Dga3Vn/O0+eO M9b9RkHu4TpjF5eZCwqJz+l+pPQfZKxHQubicp4BQkC2dK098cK5hrQ9vrsPU8gRmfxk AA0hlkAQ9AoxyJDEhABvvBD6ImQaMwA990XsrAvUcqT99J2mQB6rPpyxaprUlzOcOsoY wMgw== MIME-Version: 1.0 X-Received: by 10.140.83.100 with SMTP id i91mr45489256qgd.97.1421684538142; Mon, 19 Jan 2015 08:22:18 -0800 (PST) Received: by 10.140.20.194 with HTTP; Mon, 19 Jan 2015 08:22:17 -0800 (PST) In-Reply-To: References: <54B7F769.40605@gmail.com> <20150115175927.GA19071@zxy.spb.ru> <54B8C7E9.3030602@gmail.com> <20150116221344.GA72201@pit.databus.com> <54B999C6.2090909@gmail.com> <54B99DA1.2000001@multiplay.co.uk> Date: Mon, 19 Jan 2015 09:22:17 -0700 Message-ID: Subject: Re: Poor performance on Intel P3600 NVME driver From: Jim Harris To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Mihai-Alexandru Vintila , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:22:19 -0000 On Sat, Jan 17, 2015 at 6:29 AM, Oliver Pinter < oliver.pinter@hardenedbsd.org> wrote: > Added Jim to thread, as he is the nvme driver's author. > Thanks Oliver. Hi Mihai-Alexandru, Can you start by sending me the following? pciconf -lc nvme0 pciconf -lc nvme1 nvmecontrol identify nvme0 nvmecontrol identify nvme0ns1 nvmecontrol identify nvme1 nvmecontrol identify nvme1ns1 nvmecontrol logpage -p 1 nvme0 nvmecontrol logpage -p 1 nvme1 nvmecontrol logpage -p 2 nvme0 nvmecontrol logpage -p 2 nvme1 I see mention of a FW update, but it wasn't clear if you have run nvmecontrol perftest after the FW update? If not, could you run those same nvmecontrol perftest runs again? Thanks, -Jim > On Sat, Jan 17, 2015 at 10:26 AM, Mihai-Alexandru Vintila > wrote: > > Trim is already disabled as you can see in previous mail > > > > Best regards, > > Mihai Vintila > > > >> On 17 ian. 2015, at 01:24, Steven Hartland > wrote: > >> > >> Any difference if you disable trim? > >> > >>> On 16/01/2015 23:07, Mihai Vintila wrote: > >>> I've remade the test with atime=off. Drive has 512b physical, but I've > created it with 4k gnop anyway. Results are similar with atime > >>> Processor cache line size set to 32 bytes. > >>> File stride size set to 17 * record size. > >>> random random bk wd record stride > >>> KB reclen write rewrite read reread read write > re ad rewrite read fwrite frewrite fread freread > >>> 1048576 4 74427 0 101744 0 93529 47925 > >>> 1048576 8 39072 0 64693 0 61104 25452 > >>> > >>> I've also tried to increase vfs.zfs.vdev.aggregation_limit and ended > up with a crash (screenshot attached) > >>> > >>> I'm attaching zfs tunables: > >>> sysctl -a|grep vfs.zfs > >>> vfs.zfs.arc_max: 34359738368 > >>> vfs.zfs.arc_min: 4294967296 > >>> vfs.zfs.arc_average_blocksize: 8192 > >>> vfs.zfs.arc_meta_used: 5732232 > >>> vfs.zfs.arc_meta_limit: 8589934592 > >>> vfs.zfs.l2arc_write_max: 8388608 > >>> vfs.zfs.l2arc_write_boost: 8388608 > >>> vfs.zfs.l2arc_headroom: 2 > >>> vfs.zfs.l2arc_feed_secs: 1 > >>> vfs.zfs.l2arc_feed_min_ms: 200 > >>> vfs.zfs.l2arc_noprefetch: 1 > >>> vfs.zfs.l2arc_feed_again: 1 > >>> vfs.zfs.l2arc_norw: 1 > >>> vfs.zfs.anon_size: 32768 > >>> vfs.zfs.anon_metadata_lsize: 0 > >>> vfs.zfs.anon_data_lsize: 0 > >>> vfs.zfs.mru_size: 17841664 > >>> vfs.zfs.mru_metadata_lsize: 858624 > >>> vfs.zfs.mru_data_lsize: 13968384 > >>> vfs.zfs.mru_ghost_size: 0 > >>> vfs.zfs.mru_ghost_metadata_lsize: 0 > >>> vfs.zfs.mru_ghost_data_lsize: 0 > >>> vfs.zfs.mfu_size: 4574208 > >>> vfs.zfs.mfu_metadata_lsize: 465408 > >>> vfs.zfs.mfu_data_lsize: 4051456 > >>> vfs.zfs.mfu_ghost_size: 0 > >>> vfs.zfs.mfu_ghost_metadata_lsize: 0 > >>> vfs.zfs.mfu_ghost_data_lsize: 0 > >>> vfs.zfs.l2c_only_size: 0 > >>> vfs.zfs.dedup.prefetch: 1 > >>> vfs.zfs.nopwrite_enabled: 1 > >>> vfs.zfs.mdcomp_disable: 0 > >>> vfs.zfs.dirty_data_max: 4294967296 > >>> vfs.zfs.dirty_data_max_max: 4294967296 > >>> vfs.zfs.dirty_data_max_percent: 10 > >>> vfs.zfs.dirty_data_sync: 67108864 > >>> vfs.zfs.delay_min_dirty_percent: 60 > >>> vfs.zfs.delay_scale: 500000 > >>> vfs.zfs.prefetch_disable: 1 > >>> vfs.zfs.zfetch.max_streams: 8 > >>> vfs.zfs.zfetch.min_sec_reap: 2 > >>> vfs.zfs.zfetch.block_cap: 256 > >>> vfs.zfs.zfetch.array_rd_sz: 1048576 > >>> vfs.zfs.top_maxinflight: 32 > >>> vfs.zfs.resilver_delay: 2 > >>> vfs.zfs.scrub_delay: 4 > >>> vfs.zfs.scan_idle: 50 > >>> vfs.zfs.scan_min_time_ms: 1000 > >>> vfs.zfs.free_min_time_ms: 1000 > >>> vfs.zfs.resilver_min_time_ms: 3000 > >>> vfs.zfs.no_scrub_io: 0 > >>> vfs.zfs.no_scrub_prefetch: 0 > >>> vfs.zfs.metaslab.gang_bang: 131073 > >>> vfs.zfs.metaslab.fragmentation_threshold: 70 > >>> vfs.zfs.metaslab.debug_load: 0 > >>> vfs.zfs.metaslab.debug_unload: 0 > >>> vfs.zfs.metaslab.df_alloc_threshold: 131072 > >>> vfs.zfs.metaslab.df_free_pct: 4 > >>> vfs.zfs.metaslab.min_alloc_size: 10485760 > >>> vfs.zfs.metaslab.load_pct: 50 > >>> vfs.zfs.metaslab.unload_delay: 8 > >>> vfs.zfs.metaslab.preload_limit: 3 > >>> vfs.zfs.metaslab.preload_enabled: 1 > >>> vfs.zfs.metaslab.fragmentation_factor_enabled: 1 > >>> vfs.zfs.metaslab.lba_weighting_enabled: 1 > >>> vfs.zfs.metaslab.bias_enabled: 1 > >>> vfs.zfs.condense_pct: 200 > >>> vfs.zfs.mg_noalloc_threshold: 0 > >>> vfs.zfs.mg_fragmentation_threshold: 85 > >>> vfs.zfs.check_hostid: 1 > >>> vfs.zfs.spa_load_verify_maxinflight: 10000 > >>> vfs.zfs.spa_load_verify_metadata: 1 > >>> vfs.zfs.spa_load_verify_data: 1 > >>> vfs.zfs.recover: 0 > >>> vfs.zfs.deadman_synctime_ms: 1000000 > >>> vfs.zfs.deadman_checktime_ms: 5000 > >>> vfs.zfs.deadman_enabled: 1 > >>> vfs.zfs.spa_asize_inflation: 24 > >>> vfs.zfs.txg.timeout: 5 > >>> vfs.zfs.vdev.cache.max: 16384 > >>> vfs.zfs.vdev.cache.size: 0 > >>> vfs.zfs.vdev.cache.bshift: 16 > >>> vfs.zfs.vdev.trim_on_init: 0 > >>> vfs.zfs.vdev.mirror.rotating_inc: 0 > >>> vfs.zfs.vdev.mirror.rotating_seek_inc: 5 > >>> vfs.zfs.vdev.mirror.rotating_seek_offset: 1048576 > >>> vfs.zfs.vdev.mirror.non_rotating_inc: 0 > >>> vfs.zfs.vdev.mirror.non_rotating_seek_inc: 1 > >>> vfs.zfs.vdev.max_active: 1000 > >>> vfs.zfs.vdev.sync_read_min_active: 32 > >>> vfs.zfs.vdev.sync_read_max_active: 32 > >>> vfs.zfs.vdev.sync_write_min_active: 32 > >>> vfs.zfs.vdev.sync_write_max_active: 32 > >>> vfs.zfs.vdev.async_read_min_active: 32 > >>> vfs.zfs.vdev.async_read_max_active: 32 > >>> vfs.zfs.vdev.async_write_min_active: 32 > >>> vfs.zfs.vdev.async_write_max_active: 32 > >>> vfs.zfs.vdev.scrub_min_active: 1 > >>> vfs.zfs.vdev.scrub_max_active: 2 > >>> vfs.zfs.vdev.trim_min_active: 1 > >>> vfs.zfs.vdev.trim_max_active: 64 > >>> vfs.zfs.vdev.aggregation_limit: 131072 > >>> vfs.zfs.vdev.read_gap_limit: 32768 > >>> vfs.zfs.vdev.write_gap_limit: 4096 > >>> vfs.zfs.vdev.bio_flush_disable: 0 > >>> vfs.zfs.vdev.bio_delete_disable: 0 > >>> vfs.zfs.vdev.trim_max_bytes: 2147483648 > >>> vfs.zfs.vdev.trim_max_pending: 64 > >>> vfs.zfs.max_auto_ashift: 13 > >>> vfs.zfs.min_auto_ashift: 9 > >>> vfs.zfs.zil_replay_disable: 0 > >>> vfs.zfs.cache_flush_disable: 0 > >>> vfs.zfs.zio.use_uma: 1 > >>> vfs.zfs.zio.exclude_metadata: 0 > >>> vfs.zfs.sync_pass_deferred_free: 2 > >>> vfs.zfs.sync_pass_dont_compress: 5 > >>> vfs.zfs.sync_pass_rewrite: 2 > >>> vfs.zfs.snapshot_list_prefetch: 0 > >>> vfs.zfs.super_owner: 0 > >>> vfs.zfs.debug: 0 > >>> vfs.zfs.version.ioctl: 4 > >>> vfs.zfs.version.acl: 1 > >>> vfs.zfs.version.spa: 5000 > >>> vfs.zfs.version.zpl: 5 > >>> vfs.zfs.vol.mode: 1 > >>> vfs.zfs.trim.enabled: 0 > >>> vfs.zfs.trim.txg_delay: 32 > >>> vfs.zfs.trim.timeout: 30 > >>> vfs.zfs.trim.max_interval: 1 > >>> > >>> And nvm: > >>> ev.nvme.%parent: > >>> dev.nvme.0.%desc: Generic NVMe Device > >>> dev.nvme.0.%driver: nvme > >>> dev.nvme.0.%location: slot=0 function=0 handle=\_SB_.PCI0.BR3A.D08A > >>> dev.nvme.0.%pnpinfo: vendor=0x8086 device=0x0953 subvendor=0x8086 > subdevice=0x370a class=0x010802 > >>> dev.nvme.0.%parent: pci4 > >>> dev.nvme.0.int_coal_time: 0 > >>> dev.nvme.0.int_coal_threshold: 0 > >>> dev.nvme.0.timeout_period: 30 > >>> dev.nvme.0.num_cmds: 811857 > >>> dev.nvme.0.num_intr_handler_calls: 485242 > >>> dev.nvme.0.reset_stats: 0 > >>> dev.nvme.0.adminq.num_entries: 128 > >>> dev.nvme.0.adminq.num_trackers: 16 > >>> dev.nvme.0.adminq.sq_head: 12 > >>> dev.nvme.0.adminq.sq_tail: 12 > >>> dev.nvme.0.adminq.cq_head: 8 > >>> dev.nvme.0.adminq.num_cmds: 12 > >>> dev.nvme.0.adminq.num_intr_handler_calls: 7 > >>> dev.nvme.0.adminq.dump_debug: 0 > >>> dev.nvme.0.ioq0.num_entries: 256 > >>> dev.nvme.0.ioq0.num_trackers: 128 > >>> dev.nvme.0.ioq0.sq_head: 69 > >>> dev.nvme.0.ioq0.sq_tail: 69 > >>> dev.nvme.0.ioq0.cq_head: 69 > >>> dev.nvme.0.ioq0.num_cmds: 811845 > >>> dev.nvme.0.ioq0.num_intr_handler_calls: 485235 > >>> dev.nvme.0.ioq0.dump_debug: 0 > >>> dev.nvme.1.%desc: Generic NVMe Device > >>> dev.nvme.1.%driver: nvme > >>> dev.nvme.1.%location: slot=0 function=0 handle=\_SB_.PCI0.BR3B.H000 > >>> dev.nvme.1.%pnpinfo: vendor=0x8086 device=0x0953 subvendor=0x8086 > subdevice=0x370a class=0x010802 > >>> dev.nvme.1.%parent: pci5 > >>> dev.nvme.1.int_coal_time: 0 > >>> dev.nvme.1.int_coal_threshold: 0 > >>> dev.nvme.1.timeout_period: 30 > >>> dev.nvme.1.num_cmds: 167 > >>> dev.nvme.1.num_intr_handler_calls: 163 > >>> dev.nvme.1.reset_stats: 0 > >>> dev.nvme.1.adminq.num_entries: 128 > >>> dev.nvme.1.adminq.num_trackers: 16 > >>> dev.nvme.1.adminq.sq_head: 12 > >>> dev.nvme.1.adminq.sq_tail: 12 > >>> dev.nvme.1.adminq.cq_head: 8 > >>> dev.nvme.1.adminq.num_cmds: 12 > >>> dev.nvme.1.adminq.num_intr_handler_calls: 8 > >>> dev.nvme.1.adminq.dump_debug: 0 > >>> dev.nvme.1.ioq0.num_entries: 256 > >>> dev.nvme.1.ioq0.num_trackers: 128 > >>> dev.nvme.1.ioq0.sq_head: 155 > >>> dev.nvme.1.ioq0.sq_tail: 155 > >>> dev.nvme.1.ioq0.cq_head: 155 > >>> dev.nvme.1.ioq0.num_cmds: 155 > >>> dev.nvme.1.ioq0.num_intr_handler_calls: 155 > >>> dev.nvme.1.ioq0.dump_debug: 0 > >>> > >>> Best regards, > >>> Vintila Mihai Alexandru > >>> > >>>> On 1/17/2015 12:13 AM, Barney Wolff wrote: > >>>> I suspect Linux defaults to noatime - at least it does on my rpi. I > >>>> believe the FreeBSD default is the other way. That may explain some > >>>> of the difference. > >>>> > >>>> Also, did you use gnop to force the zpool to start on a 4k boundary? > >>>> If not, and the zpool happens to be offset, that's another big hit. > >>>> Same for ufs, especially if the disk has logical sectors of 512 but > >>>> physical of 4096. One can complain that FreeBSD should prevent, or > >>>> at least warn about, this sort of foot-shooting. > >>>> > >>>>> On Fri, Jan 16, 2015 at 10:21:07PM +0200, Mihai-Alexandru Vintila > wrote: > >>>>> @Barney Wolff it's a new pool with only changes recordsize=4k and > >>>>> compression=lz4 . On linux test is on ext4 with default values. > Penalty is > >>>>> pretty high. Also there is a read penalty for read as well between > ufs and > >>>>> zfs. Even on nvmecontrol perftest you can see the read penalty it's > not > >>>>> normal to have same result for both write and read > >>> > >>> _______________________________________________ > >>> freebsd-stable@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 16:42:29 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0C77E33 for ; Mon, 19 Jan 2015 16:42:28 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68A0F783 for ; Mon, 19 Jan 2015 16:42:28 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so32402372wes.4 for ; Mon, 19 Jan 2015 08:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OT1dVWbSnj0B0v7tb/7MlwdXTQmijoLOXDGduuMAs7I=; b=xPR73jkgEGyQqnWUkXYQaPVM1sDm/yVVKhSs/Ndw71OVuecEpaQ6uDplyPpWi3gtg7 zDshtBQtf4jlNVlyOTX3FmoCCmGYN7J0oEawk6b/L60lIDtO2qBxIKisi8s/OUdK8JDt Dbxxfs9Q7S8spGFp35gctzKcADI4/UFV9fTFyqbFiMCXCOqC4UxXvARiG4y4M3mw6dkh EH4D9epQT5f1lsREbHYgk8DBeQLdAH540dmq1OZSfyB4s0zwTdvFkMTN7pC1dPx71dJA UjgqB7YFDPmszRjsxOTPSVDWEVBRIfuuJTm/Fky6kaucjMJlEnaMoGSEvOOLeSfpklks iqeA== X-Received: by 10.181.8.193 with SMTP id dm1mr36422462wid.55.1421685746523; Mon, 19 Jan 2015 08:42:26 -0800 (PST) Received: from [192.168.3.105] ([193.148.0.35]) by mx.google.com with ESMTPSA id cm7sm14843888wib.6.2015.01.19.08.42.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 08:42:25 -0800 (PST) Message-ID: <54BD33F0.6090008@gmail.com> Date: Mon, 19 Jan 2015 18:42:24 +0200 From: Mihai Vintila User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: Re: Poor performance on Intel P3600 NVME driver References: <54B7F769.40605@gmail.com> <20150115175927.GA19071@zxy.spb.ru> <54B8C7E9.3030602@gmail.com> <20150116221344.GA72201@pit.databus.com> <54B999C6.2090909@gmail.com> <54B99DA1.2000001@multiplay.co.uk> 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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:42:29 -0000 As an update to this, same test on FreeBSD 9.3p5 gives slight decrease in write performance and twice for read performance: Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 1048576 4 62698 0 195086 0 172387 41217 1048576 8 30737 0 132207 0 118155 21746 Best regards, Vintila Mihai Alexandru On 1/17/2015 11:26 AM, Mihai-Alexandru Vintila wrote: > Trim is already disabled as you can see in previous mail > > Best regards, > Mihai Vintila > >> On 17 ian. 2015, at 01:24, Steven Hartland wrote: >> >> Any difference if you disable trim? >> >>> On 16/01/2015 23:07, Mihai Vintila wrote: >>> I've remade the test with atime=off. Drive has 512b physical, but I've created it with 4k gnop anyway. Results are similar with atime >>> Processor cache line size set to 32 bytes. >>> File stride size set to 17 * record size. >>> random random bk wd record stride >>> KB reclen write rewrite read reread read write re ad rewrite read fwrite frewrite fread freread >>> 1048576 4 74427 0 101744 0 93529 47925 >>> 1048576 8 39072 0 64693 0 61104 25452 >>> >>> I've also tried to increase vfs.zfs.vdev.aggregation_limit and ended up with a crash (screenshot attached) >>> >>> I'm attaching zfs tunables: >>> sysctl -a|grep vfs.zfs >>> vfs.zfs.arc_max: 34359738368 >>> vfs.zfs.arc_min: 4294967296 >>> vfs.zfs.arc_average_blocksize: 8192 >>> vfs.zfs.arc_meta_used: 5732232 >>> vfs.zfs.arc_meta_limit: 8589934592 >>> vfs.zfs.l2arc_write_max: 8388608 >>> vfs.zfs.l2arc_write_boost: 8388608 >>> vfs.zfs.l2arc_headroom: 2 >>> vfs.zfs.l2arc_feed_secs: 1 >>> vfs.zfs.l2arc_feed_min_ms: 200 >>> vfs.zfs.l2arc_noprefetch: 1 >>> vfs.zfs.l2arc_feed_again: 1 >>> vfs.zfs.l2arc_norw: 1 >>> vfs.zfs.anon_size: 32768 >>> vfs.zfs.anon_metadata_lsize: 0 >>> vfs.zfs.anon_data_lsize: 0 >>> vfs.zfs.mru_size: 17841664 >>> vfs.zfs.mru_metadata_lsize: 858624 >>> vfs.zfs.mru_data_lsize: 13968384 >>> vfs.zfs.mru_ghost_size: 0 >>> vfs.zfs.mru_ghost_metadata_lsize: 0 >>> vfs.zfs.mru_ghost_data_lsize: 0 >>> vfs.zfs.mfu_size: 4574208 >>> vfs.zfs.mfu_metadata_lsize: 465408 >>> vfs.zfs.mfu_data_lsize: 4051456 >>> vfs.zfs.mfu_ghost_size: 0 >>> vfs.zfs.mfu_ghost_metadata_lsize: 0 >>> vfs.zfs.mfu_ghost_data_lsize: 0 >>> vfs.zfs.l2c_only_size: 0 >>> vfs.zfs.dedup.prefetch: 1 >>> vfs.zfs.nopwrite_enabled: 1 >>> vfs.zfs.mdcomp_disable: 0 >>> vfs.zfs.dirty_data_max: 4294967296 >>> vfs.zfs.dirty_data_max_max: 4294967296 >>> vfs.zfs.dirty_data_max_percent: 10 >>> vfs.zfs.dirty_data_sync: 67108864 >>> vfs.zfs.delay_min_dirty_percent: 60 >>> vfs.zfs.delay_scale: 500000 >>> vfs.zfs.prefetch_disable: 1 >>> vfs.zfs.zfetch.max_streams: 8 >>> vfs.zfs.zfetch.min_sec_reap: 2 >>> vfs.zfs.zfetch.block_cap: 256 >>> vfs.zfs.zfetch.array_rd_sz: 1048576 >>> vfs.zfs.top_maxinflight: 32 >>> vfs.zfs.resilver_delay: 2 >>> vfs.zfs.scrub_delay: 4 >>> vfs.zfs.scan_idle: 50 >>> vfs.zfs.scan_min_time_ms: 1000 >>> vfs.zfs.free_min_time_ms: 1000 >>> vfs.zfs.resilver_min_time_ms: 3000 >>> vfs.zfs.no_scrub_io: 0 >>> vfs.zfs.no_scrub_prefetch: 0 >>> vfs.zfs.metaslab.gang_bang: 131073 >>> vfs.zfs.metaslab.fragmentation_threshold: 70 >>> vfs.zfs.metaslab.debug_load: 0 >>> vfs.zfs.metaslab.debug_unload: 0 >>> vfs.zfs.metaslab.df_alloc_threshold: 131072 >>> vfs.zfs.metaslab.df_free_pct: 4 >>> vfs.zfs.metaslab.min_alloc_size: 10485760 >>> vfs.zfs.metaslab.load_pct: 50 >>> vfs.zfs.metaslab.unload_delay: 8 >>> vfs.zfs.metaslab.preload_limit: 3 >>> vfs.zfs.metaslab.preload_enabled: 1 >>> vfs.zfs.metaslab.fragmentation_factor_enabled: 1 >>> vfs.zfs.metaslab.lba_weighting_enabled: 1 >>> vfs.zfs.metaslab.bias_enabled: 1 >>> vfs.zfs.condense_pct: 200 >>> vfs.zfs.mg_noalloc_threshold: 0 >>> vfs.zfs.mg_fragmentation_threshold: 85 >>> vfs.zfs.check_hostid: 1 >>> vfs.zfs.spa_load_verify_maxinflight: 10000 >>> vfs.zfs.spa_load_verify_metadata: 1 >>> vfs.zfs.spa_load_verify_data: 1 >>> vfs.zfs.recover: 0 >>> vfs.zfs.deadman_synctime_ms: 1000000 >>> vfs.zfs.deadman_checktime_ms: 5000 >>> vfs.zfs.deadman_enabled: 1 >>> vfs.zfs.spa_asize_inflation: 24 >>> vfs.zfs.txg.timeout: 5 >>> vfs.zfs.vdev.cache.max: 16384 >>> vfs.zfs.vdev.cache.size: 0 >>> vfs.zfs.vdev.cache.bshift: 16 >>> vfs.zfs.vdev.trim_on_init: 0 >>> vfs.zfs.vdev.mirror.rotating_inc: 0 >>> vfs.zfs.vdev.mirror.rotating_seek_inc: 5 >>> vfs.zfs.vdev.mirror.rotating_seek_offset: 1048576 >>> vfs.zfs.vdev.mirror.non_rotating_inc: 0 >>> vfs.zfs.vdev.mirror.non_rotating_seek_inc: 1 >>> vfs.zfs.vdev.max_active: 1000 >>> vfs.zfs.vdev.sync_read_min_active: 32 >>> vfs.zfs.vdev.sync_read_max_active: 32 >>> vfs.zfs.vdev.sync_write_min_active: 32 >>> vfs.zfs.vdev.sync_write_max_active: 32 >>> vfs.zfs.vdev.async_read_min_active: 32 >>> vfs.zfs.vdev.async_read_max_active: 32 >>> vfs.zfs.vdev.async_write_min_active: 32 >>> vfs.zfs.vdev.async_write_max_active: 32 >>> vfs.zfs.vdev.scrub_min_active: 1 >>> vfs.zfs.vdev.scrub_max_active: 2 >>> vfs.zfs.vdev.trim_min_active: 1 >>> vfs.zfs.vdev.trim_max_active: 64 >>> vfs.zfs.vdev.aggregation_limit: 131072 >>> vfs.zfs.vdev.read_gap_limit: 32768 >>> vfs.zfs.vdev.write_gap_limit: 4096 >>> vfs.zfs.vdev.bio_flush_disable: 0 >>> vfs.zfs.vdev.bio_delete_disable: 0 >>> vfs.zfs.vdev.trim_max_bytes: 2147483648 >>> vfs.zfs.vdev.trim_max_pending: 64 >>> vfs.zfs.max_auto_ashift: 13 >>> vfs.zfs.min_auto_ashift: 9 >>> vfs.zfs.zil_replay_disable: 0 >>> vfs.zfs.cache_flush_disable: 0 >>> vfs.zfs.zio.use_uma: 1 >>> vfs.zfs.zio.exclude_metadata: 0 >>> vfs.zfs.sync_pass_deferred_free: 2 >>> vfs.zfs.sync_pass_dont_compress: 5 >>> vfs.zfs.sync_pass_rewrite: 2 >>> vfs.zfs.snapshot_list_prefetch: 0 >>> vfs.zfs.super_owner: 0 >>> vfs.zfs.debug: 0 >>> vfs.zfs.version.ioctl: 4 >>> vfs.zfs.version.acl: 1 >>> vfs.zfs.version.spa: 5000 >>> vfs.zfs.version.zpl: 5 >>> vfs.zfs.vol.mode: 1 >>> vfs.zfs.trim.enabled: 0 >>> vfs.zfs.trim.txg_delay: 32 >>> vfs.zfs.trim.timeout: 30 >>> vfs.zfs.trim.max_interval: 1 >>> >>> And nvm: >>> ev.nvme.%parent: >>> dev.nvme.0.%desc: Generic NVMe Device >>> dev.nvme.0.%driver: nvme >>> dev.nvme.0.%location: slot=0 function=0 handle=\_SB_.PCI0.BR3A.D08A >>> dev.nvme.0.%pnpinfo: vendor=0x8086 device=0x0953 subvendor=0x8086 subdevice=0x370a class=0x010802 >>> dev.nvme.0.%parent: pci4 >>> dev.nvme.0.int_coal_time: 0 >>> dev.nvme.0.int_coal_threshold: 0 >>> dev.nvme.0.timeout_period: 30 >>> dev.nvme.0.num_cmds: 811857 >>> dev.nvme.0.num_intr_handler_calls: 485242 >>> dev.nvme.0.reset_stats: 0 >>> dev.nvme.0.adminq.num_entries: 128 >>> dev.nvme.0.adminq.num_trackers: 16 >>> dev.nvme.0.adminq.sq_head: 12 >>> dev.nvme.0.adminq.sq_tail: 12 >>> dev.nvme.0.adminq.cq_head: 8 >>> dev.nvme.0.adminq.num_cmds: 12 >>> dev.nvme.0.adminq.num_intr_handler_calls: 7 >>> dev.nvme.0.adminq.dump_debug: 0 >>> dev.nvme.0.ioq0.num_entries: 256 >>> dev.nvme.0.ioq0.num_trackers: 128 >>> dev.nvme.0.ioq0.sq_head: 69 >>> dev.nvme.0.ioq0.sq_tail: 69 >>> dev.nvme.0.ioq0.cq_head: 69 >>> dev.nvme.0.ioq0.num_cmds: 811845 >>> dev.nvme.0.ioq0.num_intr_handler_calls: 485235 >>> dev.nvme.0.ioq0.dump_debug: 0 >>> dev.nvme.1.%desc: Generic NVMe Device >>> dev.nvme.1.%driver: nvme >>> dev.nvme.1.%location: slot=0 function=0 handle=\_SB_.PCI0.BR3B.H000 >>> dev.nvme.1.%pnpinfo: vendor=0x8086 device=0x0953 subvendor=0x8086 subdevice=0x370a class=0x010802 >>> dev.nvme.1.%parent: pci5 >>> dev.nvme.1.int_coal_time: 0 >>> dev.nvme.1.int_coal_threshold: 0 >>> dev.nvme.1.timeout_period: 30 >>> dev.nvme.1.num_cmds: 167 >>> dev.nvme.1.num_intr_handler_calls: 163 >>> dev.nvme.1.reset_stats: 0 >>> dev.nvme.1.adminq.num_entries: 128 >>> dev.nvme.1.adminq.num_trackers: 16 >>> dev.nvme.1.adminq.sq_head: 12 >>> dev.nvme.1.adminq.sq_tail: 12 >>> dev.nvme.1.adminq.cq_head: 8 >>> dev.nvme.1.adminq.num_cmds: 12 >>> dev.nvme.1.adminq.num_intr_handler_calls: 8 >>> dev.nvme.1.adminq.dump_debug: 0 >>> dev.nvme.1.ioq0.num_entries: 256 >>> dev.nvme.1.ioq0.num_trackers: 128 >>> dev.nvme.1.ioq0.sq_head: 155 >>> dev.nvme.1.ioq0.sq_tail: 155 >>> dev.nvme.1.ioq0.cq_head: 155 >>> dev.nvme.1.ioq0.num_cmds: 155 >>> dev.nvme.1.ioq0.num_intr_handler_calls: 155 >>> dev.nvme.1.ioq0.dump_debug: 0 >>> >>> Best regards, >>> Vintila Mihai Alexandru >>> >>>> On 1/17/2015 12:13 AM, Barney Wolff wrote: >>>> I suspect Linux defaults to noatime - at least it does on my rpi. I >>>> believe the FreeBSD default is the other way. That may explain some >>>> of the difference. >>>> >>>> Also, did you use gnop to force the zpool to start on a 4k boundary? >>>> If not, and the zpool happens to be offset, that's another big hit. >>>> Same for ufs, especially if the disk has logical sectors of 512 but >>>> physical of 4096. One can complain that FreeBSD should prevent, or >>>> at least warn about, this sort of foot-shooting. >>>> >>>>> On Fri, Jan 16, 2015 at 10:21:07PM +0200, Mihai-Alexandru Vintila wrote: >>>>> @Barney Wolff it's a new pool with only changes recordsize=4k and >>>>> compression=lz4 . On linux test is on ext4 with default values. Penalty is >>>>> pretty high. Also there is a read penalty for read as well between ufs and >>>>> zfs. Even on nvmecontrol perftest you can see the read penalty it's not >>>>> normal to have same result for both write and read >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 16:43:51 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3A58F71 for ; Mon, 19 Jan 2015 16:43:51 +0000 (UTC) Received: from eu1sys200aog123.obsmtp.com (eu1sys200aog123.obsmtp.com [207.126.144.155]) (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 0B59079B for ; Mon, 19 Jan 2015 16:43:50 +0000 (UTC) Received: from mail-wg0-f48.google.com ([74.125.82.48]) (using TLSv1) by eu1sys200aob123.postini.com ([207.126.147.11]) with SMTP ID DSNKVL00KKDlksKIe6qW/jHEUd/uZDt19X4C@postini.com; Mon, 19 Jan 2015 16:43:51 UTC Received: by mail-wg0-f48.google.com with SMTP id x12so4338892wgg.7 for ; Mon, 19 Jan 2015 08:43:20 -0800 (PST) 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=uLxEH5gZKkQiG0ubkpNIPNitqdX30K3K77ARhESEA1k=; b=JFnG6fGw0fcQI0vfLYvnqnx/HfriK2MSw36hUipcxPsvEDhq3TubD9KTfDiKH+Fg/3 sBed727pXFIN+Nt1Nn2oFuYC+/AERjsE7botdNhYlEZKAzW+Ol5vX9usFIw9+t40AvmU +AiPs0lMPLxmAIlI839fy5U6P7PWfaCwVkJWCjyU02upCWQdlH9nlPHKEwM5zje3Dy44 3apbnnORdkB6ArAuyrR0k4N/i5BOi7VJxQnOANwVzSBqmvCh4e4XD9izaLzuG5v2M9+t BzIf1hP6AXGO2wZQTQNpst0iQ4alUwK/73ooPGgdRGslNSDd1xYMCb8QENmHDF3SE9AF H/JA== X-Received: by 10.194.93.194 with SMTP id cw2mr61372676wjb.21.1421682267739; Mon, 19 Jan 2015 07:44:27 -0800 (PST) X-Gm-Message-State: ALoCoQnPJrP01RmnAOyrXQaRLjiTMLtyEGMj2JEv1KqNprMfsa0KTvFMp+MH+Yb/gJONBIdToTGE+D1OpJis9N541CGAfJo4IP63hgVKlOgp0AmcpUdO8wR2FBbwOe3mr6a4X5/TR6A3YW5atYHdZqNl7TN0+VjiGw== X-Received: by 10.194.93.194 with SMTP id cw2mr61372659wjb.21.1421682267598; Mon, 19 Jan 2015 07:44:27 -0800 (PST) Received: from mech-as221.men.bris.ac.uk (mech-as221.men.bris.ac.uk. [137.222.187.221]) by mx.google.com with ESMTPSA id gl11sm17714192wjc.40.2015.01.19.07.44.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 07:44:26 -0800 (PST) Date: Mon, 19 Jan 2015 07:44:26 -0800 (PST) X-Google-Original-Date: Mon, 19 Jan 2015 15:44:25 GMT Received: from mech-as221.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9) with ESMTP id t0JFiP9r027957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas@mech-as221.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as221.men.bris.ac.uk (8.14.9/8.14.9/Submit) id t0JFiP7O027952; Mon, 19 Jan 2015 15:44:25 GMT (envelope-from mexas) From: Anton Shterenlikht Message-Id: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> To: mexas@bris.ac.uk, rmacklem@uoguelph.ca Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Reply-To: mexas@bris.ac.uk In-Reply-To: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:43:51 -0000 >From rmacklem@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html >> >> Is there no easy solution to this PR? >> Or is there no interest in fixing the issue? >> >Well, the "easy" solution is to just increase the value >of NNAMELEN and rebuild everything from sources to use >the modified sys/mount.h. (If you can run a modified >system built entirely from sources, I think you can do >this.) I can do this on several 10.1-stable systems, but I understood from the email trail that there is no guarantee that nothing will be broken by such change. I know there is never a guarantee, but.. >However, this can't be done in -current because it breaks >the statfs(2) syscall API, etc. Even on 10.1-stable I see in statfs(2): #define MNAMELEN 88 /* size of on/from name bufs */ So perhaps changing MNAMELEN will break statfs(2) on -stable too? Anton From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 16:47:01 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9434205; Mon, 19 Jan 2015 16:47:01 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2117E0; Mon, 19 Jan 2015 16:47:01 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id x12so4354429wgg.7; Mon, 19 Jan 2015 08:46:58 -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=1TXqEoqHQ9LNf1/uPnum6o0Ph51eOFeal0xweSWxa44=; b=c7JjShL4ul3WGPL9t/sehuJ/FV6zgyf4Pay4lqMni7GdZ5V6+3NCbIsdyw76wDW3k8 BMXrymOX+x7ukhRv+TyMi3quuThjwWu92cJsCYZn4RQn2KcmaQ6iE7dvUMQ9uNn1j+Ov LM4Jdyilptmhi79O4scb/lMOsbu8kxwzLgb5F/e7e1TCOPQzaJN7465p+pqXkmAHW59o PNGkFO8ztPRPG4GtJhFwY13A96/Ynm0ba3fAkvuFUyc+4kykqF8YzWj5p3jCjtyRH9Jd /P2eNqzlyOYqHM65+8PpgKr6SF5M5ZeXD2Fw2tVBBaggRapUVejkyEwboJwvNkU5YLij 3ung== MIME-Version: 1.0 X-Received: by 10.180.83.5 with SMTP id m5mr1497361wiy.74.1421686017235; Mon, 19 Jan 2015 08:46:57 -0800 (PST) Received: by 10.216.69.193 with HTTP; Mon, 19 Jan 2015 08:46:57 -0800 (PST) In-Reply-To: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> Date: Mon, 19 Jan 2015 11:46:57 -0500 Message-ID: Subject: Re: old bug: mount_nfs path/name is limited to 88 chars From: Brandon Allbery To: mexas@bris.ac.uk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:47:01 -0000 On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht wrote: > So perhaps changing MNAMELEN will break statfs(2) on > -stable too? > I believe the context there is not so much "-current is special", as "changing it for everyone is bad news" (and this would necessarily need to originate in -current). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Mon Jan 19 21:20:42 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB51C1CB; Mon, 19 Jan 2015 21:20:41 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B095BAA0; Mon, 19 Jan 2015 21:20:41 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id ft15so9464277pdb.11; Mon, 19 Jan 2015 13:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IeUYPoeiGvVMNUppWcIStopwEqYZ9NJQOR4rqOAhuQI=; b=BrgSQ6ZditGzG5B6/w6DB7tJjKgfykAQ3TrYwsHPgYdN0XgK0M5t2EgCRNOo7EyuTy +QPhlJL02eYfQrPSXa8hRzMfCVofcyy7Yjxq8bk7p/nXjEGdpzrMQOAvpRvVcBzLUs5+ WZhTHwtgJLdpRGDTzE6wio3Z5BEvraW+SN2e+M7mNFnit3dMVo2S1/Akv53x723sbaVP OxSvcXs3Hp/LHaYzuU0FUQ3x4elt1gkeWNY53T5FWaaekoEB/vL1WQuw+vvJcFgyaBhe FEB6ka20uNTONb5aKjGjXMVJkSpX/Xa/FU3oFcTjvzoAhzgVQ824Grpon0ovLAhNm12y VrUA== X-Received: by 10.66.118.109 with SMTP id kl13mr21694274pab.19.1421702441264; Mon, 19 Jan 2015 13:20:41 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:4d37:1619:da3a:156a? ([2601:8:ab80:7d6:4d37:1619:da3a:156a]) by mx.google.com with ESMTPSA id ig1sm951742pbc.41.2015.01.19.13.20.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 13:20:40 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: old bug: mount_nfs path/name is limited to 88 chars From: Garrett Cooper In-Reply-To: Date: Mon, 19 Jan 2015 13:20:39 -0800 Message-Id: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> To: Brandon Allbery X-Mailer: Apple Mail (2.1878.6) Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 21:20:42 -0000 --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 19, 2015, at 8:46, Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht = > wrote: >=20 >> So perhaps changing MNAMELEN will break statfs(2) on >> -stable too? >>=20 >=20 > I believe the context there is not so much "-current is special", as > "changing it for everyone is bad news" (and this would necessarily = need to > originate in -current). A compat layer needs to be created for all of the affected syscalls, and = the change needs to be made. That=92s it in a nutshell. Doing it in 11 makes sense since there is a compat layer for 10 now=85 = if I knew all of the steps I would happily do them as annoys me from = time to time as well with the path length issue. Thanks! --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9 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 - https://gpgtools.org iQEcBAEBCgAGBQJUvXUnAAoJEMZr5QU6S73esE0H/02cg9lmsG+DMq4JDMDkydly H8uD7AHgOQ7HxaY59BEGGnsqVHRznlu3j/dYm3qX9ifCRUAMA2bkXy/8JeVlcRLv 4kcsL+8B1w7EeLnwwW1PXwe2NR5NN+4+flRGWdu3ICJfS3uLFdqObz9s7q88tSv9 OcGIr8aHS++UEAeiDIU9OP6KviXyN6ULpL+YOCOMPOU5XjJI9FXsqrwr96/xeLPp 4LP0inacr6ASl+79pFq5lYU7tnuYCWcqzlzdl0lFEvDFKKK46NtGovWUCA6ZDvYp 8a4QgKdEF5XqxsHI3a+pNP0hjz8jMUi7vTuZHCa0ZRczIZj1xzbWS0eMmozuPzM= =jxOM -----END PGP SIGNATURE----- --Apple-Mail=_C506EFA9-23ED-4FB7-9DC2-4588573C3CF9-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 00:19:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46C42D8C; Tue, 20 Jan 2015 00:19:54 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 01237F10; Tue, 20 Jan 2015 00:19:53 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 5887E16A409; Tue, 20 Jan 2015 01:19:49 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHT-oeDDwK5Y; Tue, 20 Jan 2015 01:14:48 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id D7F0F16A408; Tue, 20 Jan 2015 01:14:48 +0100 (CET) Message-ID: <54BD9DF6.8060402@digiware.nl> Date: Tue, 20 Jan 2015 01:14:46 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 00:19:54 -0000 On 19-1-2015 22:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected syscalls, > and the change needs to be made. That’s it in a nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 now… > if I knew all of the steps I would happily do them as annoys me from > time to time as well with the path length issue. Well after this the next problem you'll be running into is: #define PATH_MAX 1024 /* max bytes in pathname */ Which I already did inf find(1) because the paths in backups of big filesystems already bit in like 2011. Talked about it with Jilles, and got more or less the same answer: You can up the value, but expect things to break. Which it did when I only fixed the size in find. It would break in the program that got the path fed. Never dared to just up the value, compile kernel/world, install and reboot. And then see what comes of it. So IMHO if possible this would need to be extended as well... --WjW From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 01:05:35 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A126CB; Tue, 20 Jan 2015 01:05:35 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA389617; Tue, 20 Jan 2015 01:05:34 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B182A266C; Mon, 19 Jan 2015 17:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1421715933; x=1421730333; bh=BuhBwC5RnOIR/gfHROfzE1pBsc1aK+DL8X1kEpzOJb0=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=t9j0ru/YoUgeeDDWopbvfGW/xaWTPWYNHLhZT6chBYsfwm8Ofgv3b6D/z/aJwTrdF +vYTwxCh+s5dtihibpA4SYD4s6dpMlWdBcbspSusN3aHU34F1Jpk2SEZRds0IfOh2L EoBBNiCWqa1HW/9pB25+dOCHb+JrGzb+ndUVB2Z4= Message-ID: <54BDA9DD.5040608@delphij.net> Date: Mon, 19 Jan 2015 17:05:33 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> In-Reply-To: <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:05:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/19/15 13:20, Garrett Cooper wrote: > On Jan 19, 2015, at 8:46, Brandon Allbery > wrote: > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht >> wrote: >> >>> So perhaps changing MNAMELEN will break statfs(2) on -stable >>> too? >>> >> >> I believe the context there is not so much "-current is special", >> as "changing it for everyone is bad news" (and this would >> necessarily need to originate in -current). > > A compat layer needs to be created for all of the affected > syscalls, and the change needs to be made. That’s it in a > nutshell. > > Doing it in 11 makes sense since there is a compat layer for 10 > now… if I knew all of the steps I would happily do them as annoys > me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. I personally think we probably better create a new API and keep the existing one for (limited) compatibility. For instance, it may be sensible to make f_mntfromname and f_mntonname fields variable length and have the caller pass a pointer and their length. If we set an arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some time. BTW. If someone wants to change statfs(2), please make sure to create reverse-compatibility shims at the same time (see lib/libc/sys/fcntl.c for an example). The statfs(2) API is used in a lot of places, especially fts(3), and breaking it either way (running new world with old kernel, or running old world with new kernel) would be a big pain to recover from. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM PiOk31dmRfQB+3mqZ+Oj =a3fA -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 01:35:43 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09DC5BF2 for ; Tue, 20 Jan 2015 01:35:43 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BED2C900 for ; Tue, 20 Jan 2015 01:35:42 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id x69so8952035oia.10 for ; Mon, 19 Jan 2015 17:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=83nZpel6QCdFKJeaAblZS0IZ5uPJCWNwgRBDsQ+alYA=; b=ivU2kEB/Hb1jDiTIS16LhNUAYUSNfrINLIX3lHHiL+gIDk4/d3vHa1KB7CbnV31ztc yS798pe5YUZMHB2euR3dzCWb37qytxMACrGWdMs1rDZ1+YdOL1CqJqk09G5Rznrc+Qqr oP4GWfVKCJYloLSfwCexuBfLq72NUjJvGm9CZKK5SgWpEc6lcJ6fTGlBo4HifuhQaCRx 3tDZdo/CHymQi6s/3RP/YSG7RQnjVCSgv9naYi9LyPxiHzpFCPhBnd5a1nrz/kaXvL3b J3QNU/02qNoEzcye9lfXyAZ7fIfHSJKY7HKCWLFMuERSO4wj6s3Oo9QG1Oa1cQpn4jdX L/8g== X-Received: by 10.202.180.70 with SMTP id d67mr18647994oif.119.1421717742116; Mon, 19 Jan 2015 17:35:42 -0800 (PST) Received: from [10.10.0.103] (c-98-199-208-177.hsd1.tx.comcast.net. [98.199.208.177]) by mx.google.com with ESMTPSA id s71sm1047386oie.24.2015.01.19.17.35.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 17:35:41 -0800 (PST) Message-ID: <54BDB10D.4000603@gmail.com> Date: Mon, 19 Jan 2015 19:36:13 -0600 From: Yass Amed User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Keep -STABLE updated! Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:35:43 -0000 Hello, I'd like to clarify a certain info regarding FreeBSD -STABLE. Currently, I am running 10-STABLE and need to know if it is mandatory to rebuild kernel and world every time I sync the source using "# svn up /usr/src"? Thank You, @youngunix -- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 01:53:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ED9BDB5; Tue, 20 Jan 2015 01:53:30 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D5AEFA8E; Tue, 20 Jan 2015 01:53:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMSzvVSDaFve/2dsb2JhbABcg1hYBIMCwzcGhXUCgWEBAQEBAX2EDAEBAQMBI1YFFhgCAg0ZAiM2GRoBh30DCQi5fo9zDYQcAQEBAQEBBAEBAQEBAQEXBIEhjC6BUgEJGgEzB4ItOxGBMAWJdYw3gliCfIYKgh+FcSKCAR2BbiAxgQMBHyJ+AQEB X-IronPort-AV: E=Sophos;i="5.09,431,1418101200"; d="scan'208";a="186795194" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Jan 2015 20:53:22 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EAAF03CE1D; Mon, 19 Jan 2015 20:53:21 -0500 (EST) Date: Mon, 19 Jan 2015 20:53:21 -0500 (EST) From: Rick Macklem To: d@delphij.net Message-ID: <1162721475.16794258.1421718801948.JavaMail.root@uoguelph.ca> In-Reply-To: <54BDA9DD.5040608@delphij.net> Subject: Re: old bug: mount_nfs path/name is limited to 88 chars MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: mexas@bris.ac.uk, freebsd current , freebsd-stable , Brandon Allbery , Garrett Cooper X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:53:30 -0000 Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 01/19/15 13:20, Garrett Cooper wrote: > > On Jan 19, 2015, at 8:46, Brandon Allbery > > wrote: > >=20 > >> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht > >> wrote: > >>=20 > >>> So perhaps changing MNAMELEN will break statfs(2) on -stable > >>> too? > >>>=20 > >>=20 > >> I believe the context there is not so much "-current is special", > >> as "changing it for everyone is bad news" (and this would > >> necessarily need to originate in -current). > >=20 > > A compat layer needs to be created for all of the affected > > syscalls, and the change needs to be made. That=E2=80=99s it in a > > nutshell. > >=20 > > Doing it in 11 makes sense since there is a compat layer for 10 > > now=E2=80=A6 if I knew all of the steps I would happily do them as anno= ys > > me from time to time as well with the path length issue. >=20 > Compat layer may break applications in other funny ways and we > probably have to return e.g. ENAMETOOLONG for legacy applications if > the names are too long to fit into the buffer, but I don't see any > easy solution either: I wish we have bumped it in 2003 when the > struct > receives its first big revamp by bumping all statistic fields to > 64-bit. >=20 > I personally think we probably better create a new API and keep the > existing one for (limited) compatibility. For instance, it may be > sensible to make f_mntfromname and f_mntonname fields variable length > and have the caller pass a pointer and their length. If we set an > arbitrary limit, no matter it's 88, 256 or 4096, one will hit it some > time. >=20 > BTW. If someone wants to change statfs(2), please make sure to create > reverse-compatibility shims at the same time (see > lib/libc/sys/fcntl.c > for an example). The statfs(2) API is used in a lot of places, > especially fts(3), and breaking it either way (running new world with > old kernel, or running old world with new kernel) would be a big pain > to recover from. >=20 Solaris has statvfs(), which might be a starting point for a new API. statfs(2) would have to be retained for compatibility with older binaries a= nd I think there would still be some breakage for cases where the mount path does exceed MNAMELEN. All I can think of is that the mount path would have to be truncated for the compatibility code. (I don't know what kind of truncation would be preferred? Just chop it at 88 or do something like /sub1/.../mnt or 0 length?) I think a lot of things will bump up against PATH_MAX, so making the length that might be ok, although I like the new API having the buffer and its length being passed in as arguments, so at least the syscall API doesn't need to change again. Some variant of doing all this is in projects/ino64 I think, since it ends up changing assorted syscalls like stat(2) as well, along with versioning the libc functions affected by the syscall changes. (I'd guess fts(3) is one of them, but haven't looked.) I doubt these changes could be MFC'd (others mention doing this for FreeBSD11). What could be done and maybe MFC'd is to simply allow mounts with paths greater than 88, but truncate it to 88 for statfs(2). { I think this truncation will end up happening for the compatibility syscall code anyhow, even if a new statfs(2) is added, so maybe just let it happen, even if no new syscall is available. } There was a patch floating around for this and doing this would only impact mounts with paths > MNAMELEN. (mount_nfs could print a warning for paths > MNAMELEN instead of failing the mount.) Does this sound reasonable as a stop gap (and could it be MFC'd?)? rick > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.1.1 (FreeBSD) >=20 > iQIcBAEBCgAGBQJUvanaAAoJEJW2GBstM+nsgoQP/0+Ulfmmmj9n9cWA0h1NxD3O > a59aZXxbFtRu2SkIZprzFOL4TLnmyKEthFGmUgRSm7SH3GuaWVPBsgHTjSddYA/f > vD3fBei780akT/higazmSENKR0eWqL0zENG8HJndQ0XLLcv8eeHZEFFhbUlYA4JU > 4ArzoKEwsxiQ4jKB+KSFRU4QR4Raarljx6m4gQyXO6QAPEcyO035YH+bJlMSPjYg > wcJZiZXmsRYsjZMhKDGeO5tIiD8R/UwOcMKsaQ/O+bwCgWtHFe5gLDKxGjMlLc9c > NuhXE2/xlyBdAf3OHTlgr61dPmArQl0pyLXDUfd8K0s05FQ22bGHaSCT0FyNNG0J > 55rnr30iDczVjQV1rTk9AwvsTJzACyaRrCV3zXGpxr86XwGFRta4ebMYZNuRXhdZ > sLsTZWpIc3gnvOH4CiZHPmr1mbHoAY1RN9G23T5ENu2zYNJVozXhJ4NkoZkKzxUj > b19qox4aKtG9QT7h5HU7R7Q64Sz2dYty8VD4OZ/azQrLGjVdI+2KUq6M3SAIRBro > IAmGY62OQyz8aDVhr/Ap/N7GnV4suCZf08kgg3+oREU0a8QAxEHCDnNH4MJ9xz6v > +2GpYWp0AuCFJ77XQC7IB6va1hK+PZnuOZ9yNVKTTadEwSk4GK2fQv6YwLjiyYKM > PiOk31dmRfQB+3mqZ+Oj > =3Da3fA > -----END PGP SIGNATURE----- >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 01:54:25 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1014FA3 for ; Tue, 20 Jan 2015 01:54:25 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54BC7AA5 for ; Tue, 20 Jan 2015 01:54:25 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id z12so995156wgg.3 for ; Mon, 19 Jan 2015 17:54:23 -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=ACLgMJEe408LM/E+aOclRn1703sOrgeL/JIr1YjOek0=; b=UMPMrsF6+4ZlRC+QH42NeKkA/+XaOUY8LPTHa5KtEJgUbi6QNRQBI3AJOrPLBbOb/J XeKdYnyuJA5ESKfV/SyHe+s03GEL9bT6iDr7e6NP699GnrX+vsrwZzKux70bXpv7UgHC VlMOwFh+tYw3OfnLGi3UvkbK2p/8x+aSWZ3A3hNrtrHffQVzIn2RoxAk0L0NL3B2/ffn 1NbbGxcvSelfiaG7fcI9p3kgNhTqbJg8NODiK+ufEmZrpjAKH5lJnK6CzyQwQon3WaRo x8p0Q4My4RkBrsBJz0gXEVRjbB2BQemj41868ZSG6K/mjYTUX/EjKKfj0GWTMXryPWTD 5Yww== MIME-Version: 1.0 X-Received: by 10.180.210.174 with SMTP id mv14mr468336wic.80.1421718863839; Mon, 19 Jan 2015 17:54:23 -0800 (PST) Received: by 10.216.69.193 with HTTP; Mon, 19 Jan 2015 17:54:23 -0800 (PST) In-Reply-To: <54BDB10D.4000603@gmail.com> References: <54BDB10D.4000603@gmail.com> Date: Mon, 19 Jan 2015 20:54:23 -0500 Message-ID: Subject: Re: Keep -STABLE updated! From: Brandon Allbery To: Yass Amed Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:54:25 -0000 On Mon, Jan 19, 2015 at 8:36 PM, Yass Amed wrote: > I'd like to clarify a certain info regarding FreeBSD -STABLE. > Currently, I am running 10-STABLE and need to know if it is mandatory to > rebuild kernel and world every time I sync the source using "# svn up > /usr/src"? > A running FreeBSD system never needs /usr/src. But if you are running STABLE (or CURRENT), sometimes you will want to look at the source to something in the running system (usually because it just did something unexpected...) and so it's helpful to have /usr/src match the running system. So, not necessary but often a good idea. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 02:03:59 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A61816F for ; Tue, 20 Jan 2015 02:03:59 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 970B7B84 for ; Tue, 20 Jan 2015 02:03:58 +0000 (UTC) Received: from ppp14-2-13-162.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.13.162]) by ipmail06.adl6.internode.on.net with ESMTP; 20 Jan 2015 12:33:50 +1030 Message-ID: <54BDB783.5070003@ShaneWare.Biz> Date: Tue, 20 Jan 2015 12:33:47 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yass Amed , freebsd-stable@freebsd.org Subject: Re: Keep -STABLE updated! References: <54BDB10D.4000603@gmail.com> In-Reply-To: <54BDB10D.4000603@gmail.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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 02:03:59 -0000 On 20/01/2015 12:06, Yass Amed wrote: > Hello, > > I'd like to clarify a certain info regarding FreeBSD -STABLE. > Currently, I am running 10-STABLE and need to know if it is mandatory to > rebuild kernel and world every time I sync the source using "# svn up > /usr/src"? > > Thank You, > > @youngunix > No it isn't mandatory, but you may want to rebuild kernel and world from time to time so you are using the new code changes. svn up will only bring in new source code changes to /usr/src, you won't be running any of these changes until you rebuild. If you run svn up everyday then rebuilding everyday would be overkill, if you see an update that may effect you then you will need to rebuild to test it. You may want to rebuild weekly or monthly to help test or take advantage of changes made. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 02:13:51 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B24F2DB for ; Tue, 20 Jan 2015 02:13:51 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FA58C5E for ; Tue, 20 Jan 2015 02:13:51 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id vb8so5553222obc.10 for ; Mon, 19 Jan 2015 18:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Py1YbB5sEcjFOmk7LSLBiWKhgEwyZpoVFOkW1gyyns=; b=0tEBvB6K4eazpPl4gW3oh8hxsx2HIpYAewt1Cr5slD+uRVqGlSQiMD1WlAPiaT0b+C PrsQOsLDIwgilFqJTzl3ilbQ5ouVOuB9wUr0E1Krvuqh65N18KhM/VQRbWR3TG4AeR/7 bn5xFcHHSgFcR6m0+ptOeIeRQw2ungBVOeIHEowSqr2PSjqy+8kSqO4DjeyzeLiP4Tx3 g1L0WJ76aOIc4nCl4p5BhlzEe2KXehXh8yJsyekcYWWA3GSUoM5hwWamaDTSUqCMn0pV PHANmpuKn3H3gJgF5SAb1uZd3A/Ykgw2Mmi3kNbi7YTiZThiAqxpilujA27qyqa8ewr6 o1dA== MIME-Version: 1.0 X-Received: by 10.60.134.114 with SMTP id pj18mr8877214oeb.33.1421720030297; Mon, 19 Jan 2015 18:13:50 -0800 (PST) Received: by 10.182.247.74 with HTTP; Mon, 19 Jan 2015 18:13:50 -0800 (PST) In-Reply-To: <54BDB10D.4000603@gmail.com> References: <54BDB10D.4000603@gmail.com> Date: Mon, 19 Jan 2015 18:13:50 -0800 Message-ID: Subject: Re: Keep -STABLE updated! From: jungle Boogie To: Yass Amed Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 02:13:51 -0000 Hi Yass, On 19 January 2015 at 17:36, Yass Amed wrote: > Hello, > > I'd like to clarify a certain info regarding FreeBSD -STABLE. > Currently, I am running 10-STABLE and need to know if it is mandatory to > rebuild kernel and world every time I sync the source using "# svn up > /usr/src"? > Good, helpful tutorial here: http://www.bsdnow.tv/tutorials/stable-current If you only want to look at code, I suggest the website so you can diff files a little easier: https://svnweb.freebsd.org/base/stable/10/ (or whatever version you're following) If you want to update to the latest, then you need to rebuild after you svn up /usr/src. That's the part that can take hours on older systems. > Thank You, > > @youngunix > > -- > -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 04:23:06 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68399593 for ; Tue, 20 Jan 2015 04:23:06 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.155]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C023C7A for ; Tue, 20 Jan 2015 04:23:05 +0000 (UTC) Received: from workbox.Home (184-100-124-78.mpls.qwest.net [184.100.124.78]) by mx.zohomail.com with SMTPS id 1421727777269150.43013607298417; Mon, 19 Jan 2015 20:22:57 -0800 (PST) Date: Mon, 19 Jan 2015 22:22:54 -0600 From: Bigby James To: freebsd-stable@freebsd.org Subject: Re: Keep -STABLE updated! Message-ID: <20150120042254.GA1191@workbox.Home> References: <54BDB10D.4000603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BDB10D.4000603@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:23:06 -0000 On 01/19, Yass Amed wrote: > Hello, > > I'd like to clarify a certain info regarding FreeBSD -STABLE. > Currently, I am running 10-STABLE and need to know if it is mandatory to > rebuild kernel and world every time I sync the source using "# svn up > /usr/src"? Just the opposite is the case, actually---the only time you ever need to update the local source repo is when you're about to rebuild world and the kernel. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 04:49:01 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95200AD5; Tue, 20 Jan 2015 04:49:01 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4A0FE65; Tue, 20 Jan 2015 04:49:00 +0000 (UTC) X-AuditID: 1209190e-f799e6d000000cfe-39-54bddd07fdda Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.DA.03326.70DDDB45; Mon, 19 Jan 2015 23:43:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t0K4hoOU015991; Mon, 19 Jan 2015 23:43:51 -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 t0K4hmMV022483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jan 2015 23:43:50 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0K4hl9V014970; Mon, 19 Jan 2015 23:43:47 -0500 (EST) Date: Mon, 19 Jan 2015 23:43:47 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2014 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixG6nrstxd2+IwUN/i13XTrNbzHnzgcli ++Z/jBaHm4UcWDxmfJrPEsAYxWWTkpqTWZZapG+XwJXxbOVz9oJLR1kq5n/aydTA+OUocxcj J4eEgInEjUefWCFsMYkL99azdTFycQgJLGaSuHFtDzuEs5FRYv3zbiaQKiGBQ0wS0x5nQCQa GCWurpgP1MLBwSKgLfF+fzlIDZuAmsTjvc1QUxUlNp+axAxSIiIgL7HgvD1ImFnAWmLuuvVg JcICdhKTv75jB7F5BRwlelYsAjtOVEBHYvX+KSwQcUGJkzOfsED0Bkr0rJvDNIFRYBaS1Cwk KQhbR2LKxBWMELa2xP2bbWwLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5i BAUypyTfDsavB5UOMQpwMCrx8L5YtTdEiDWxrLgy9xCjJAeTkihvzU2gEF9SfkplRmJxRnxR aU5q8SFGCQ5mJRHeo5eAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxK ErxnbwM1ChalpqdWpGXmlCCkmTg4QYbzAA3fAlLDW1yQmFucmQ6RP8VoyfHk5O6ZTBz7LoLI vo0HZzIJseTl56VKiUM0CIA0ZJTmwc2EJaZXjOJALwrzBt8BquIBJjW4qa+AFjIBLRTbtQdk YUkiQkqqgXGpnZt9mPysVZ1zRUNeCNsIKbtkH/15cjuThuCxmkmvN18X1/v7geGjED9PxgW5 ZTnGrqa2Z3b0vFy+s/2za2nYIebdr+UmXGd+ZLSxJF5afFFHyu8ZJ03Wz65g2Hg/v0330XLm hKc+tWnHD/wziYw75fhL7QJTnpHBhccXdzvtWv/trFe30w8lluKMREMt5qLiRACMR5P1JwMA AA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:49:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: October - December 2014 This report covers FreeBSD-related projects between October and December 2014. This is the last of four reports planned for 2014. The fourth quarter of 2014 included a number of significant improvements to the FreeBSD system. In particular, compatibility with other systems was enhanced. This included significant improvements to the Linux compatibility layer, used to run Linux binaries on FreeBSD, and the port of WINE, used to run Windows applications. Hypervisor support improved, with FreeBSD gaining the ability to run as domain 0 on Xen's new high-performance PVH mode, bhyve gaining AMD support, and new tools for creating FreeBSD VM images arriving. This quarter was also an active time for the toolchain, with numerous improvements to the compiler, debugger, and other components, including initial support for C++14, which should be complete by FreeBSD 10.2. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from January to March 2015 is April 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * bhyve * Clang, llvm, and lldb Updated to 3.5.0 * External Toolchain * FreeBSD on Google Cloud * FreeBSD on the Acer C720 Chromebook * Git Integration * Jenkins Continuous Integration for FreeBSD * Migration to ELF Tool Chain Tools * pkg(8) Kernel * FreeBSD Xen * Linux Emulation Layer, the Linuxulator * PCI SR-IOV Infrastructure * Process Management * Secure Boot * Timer Function Support for Linuxulator * Updating OpenCrypto Architectures * FreeBSD on POWER8 * FreeBSD/arm64 Userland Programs * libxo: Generate Text, XML, JSON, and HTML Output * mandoc(1) Support Ports * GNOME on FreeBSD * KDE on FreeBSD * Linux Emulation Ports * The Graphics Stack on FreeBSD * Wine/FreeBSD * Xfce Documentation * More Michael Lucas Books * New Translators Mailing List Miscellaneous * Creating Vagrant Images with Packer * FreeBSD Forum Software Migration * The FreeBSD Foundation __________________________________________________________________ FreeBSD Release Engineering Team 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. The FreeBSD 10.1-RELEASE cycle completed on November 14th, marking the second official release point from the stable/10 branch, just short of three weeks later than the original schedule anticipated. Work to produce virtual machine images for platforms not currently supported has continued, with focus aimed primarily at Amazon EC2, Google Compute Engine, and Openstack. With huge thanks to Ian Lepore and Warner Losh, new ports exist for FreeBSD/arm where u-boot is required. Work has been in progress since late December to migrate the existing FreeBSD/arm release build tools to utilize the new ports. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q4 the ports tree holds more than 24,000 ports, and the PR count is just over 1,400. As during the previous quarter the tree saw a sustained activity with almost 6,000 commits and more than 1,600 ports PRs closed! In Q4, five new developers were granted a ports commit bit (gordon@, jmg@, jmmv@, bofh@, truckman@) and six were taken in for safekeeping (sylvio@, pclin@, flz@, jsa@, anders@, motoyuki@). On the management side, miwi@ decided to step down from his portmgr duties in November. No other changes were made to the team during Q4. This quarter also saw the release of the fourth quarterly branch, namely 2014Q4. On the QA side, 39 exp-runs were performed to validate sensitive updates or cleanups. Open tasks: 1. A tremendous work was done on the PR front in Q4 and we would be very pleased to see committers dedicate themselves to closing as many as possible in 2015 as well! 2. 2014 is the year that saw the highest number of commits in all of our ports tree's history! As for the PR front and to keep our beloved tree in good shape, we would love to see the same commitment from our developers next year! __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. During the fourth quarter of 2014, the FreeBSD Core team saw the culmination of a long-running project to rebuild the FreeBSD Forums. The chosen solution was to license XenForo; core would like to thank the FreeBSD Foundation for paying the licensing costs of this software. Much discussion ensued concerning the "New Support Model" following Core's meeting at EuroBSDCon in September. It was recognised that trying to change the model immediately before 10.1-RELEASE was far too late, and the change will be targeted at 11.0-RELEASE. In order to ensure that 10.1-RELEASE shipped with support for up-to-date X Window Systems and KDE4, core approved the switch to 'new Xorg' as the default in time for building the packages for that release. Git was officially promoted from beta to an officially supported version control system. Git is available as a read-only resource for downstream consumers and contains an exported copy from SVN, the primary and only read-write repository. The FreeBSD git repositories (exported from the master SVN version control) will shortly be available at https://git.freebsd.org/, and core has been active in ensuring that there is a sufficient body of Git administrators available with access to appropriate documentation in order to maintain a good git service. Core mediated in disputes between a number of committers over some updates to system sources, and fielded complaints about code quality of some other work in critical areas. While such disagreements will occasionally occur, core is promoting the routine use of the Phabricator service in order to review work before committal. Catching problems early is in the project's best interests, and discussion of changes in an open review context should minimize confrontational demands for immediate back-out of changes. Core is working on a charter for a proposed new QA team, to encompass members of the Release Engineering and Security teams, as well as committers with interests in standards compliance. It is envisioned that the QA team will take responsibility for merging code from HEAD into the STABLE branches, run integration testing against those updates and handle merging patches and bug-fixes submitted to the FreeBSD project from third parties. During this quarter, core issued two new commit bits, and also took two commit bits into safe-keeping. __________________________________________________________________ bhyve URL: http://www.bhyve.org Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. Support for AMD processors was committed to -CURRENT in October 2014. This has also been merged to 10-STABLE and will be included in the 10.2 release. A bhyve status update presentation was given at the FreeBSD Vendor Summit in Nov 2014. The slides are available at http://people.freebsd.org/~neel/bhyve/bhyve_update_vendor_summit_2014.pd= f . A number of improvements have been made to bhyve this quarter: * OpenBSD/i386 guests are now able to boot with multiple vcpus. * NetBSD/amd64 guests are now fully supported. * Improvements to the AHCI emulation to be more resilient under heavy load. * Various improvements to PIC emulation to be able to boot legacy guests. * A fully featured RTC device emulation that allows date/time changes by the guest and supports periodic and alarm interrupts. * Consolidate all timer emulations in vmm.ko. This enables the use of a single clocksource for all timer emulations. * Allow tracing of every exception incurred by a guest. This is useful when debugging guest double and triple faults. * Emulate platform-specific MSRs accessed by recent Linux guests. * Various bug fixes to grub-bhyve to boot OpenBSD/i386 and Centos 4.x guests. * grub-bhyve is now able to connect to an nmdm(4) console using the --cons-dev option. Open tasks: 1. Improve documentation. 2. bhyveucl is a script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl . 3. CSM BIOS boot support for non UEFI-aware guests. 4. Add support for virtio-scsi. 5. Improve virtio-net, add offload features, support multiple queues. 6. Implement Intel 82580 and e1000 NIC emulation. 7. Netmap support. 8. Flexible networking backend: wanproxy, vhost-net. 9. Move to a single process model, instead of bhyveload + bhyve. 10. Support running bhyve as non-root. 11. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 12. Implement an abstraction layer for video (no X11 or SDL in base system). 13. Support for VNC as a video output. 14. Suspend/resume support. 15. Live Migration. 16. Nested VT-x support (bhyve in bhyve). 17. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, and lldb Updated to 3.5.0 URL: http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html URL: http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Just before the end of the year, we updated clang, llvm, and lldb in the base system to 3.5.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This is the first release that requires C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. In the near future, more components from llvm.org will be updated in base, with libc++ and libcompiler-rt most likely being the first to be updated. Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits, and Antoine Brodin for their invaluable help with this import. Open tasks: 1. While most ports that were impacted by this update have already been fixed, there are still a few that do not work with the clang 3.5.0 update. In most cases, this is due to relatively simple issues, such as new warnings, or slightly stricter error checking (primarily for C++ programs). Fixing those issues should not take too much work. 2. There are still some open issues with the ARM, PowerPC, and Sparc64 architectures, and any help in this area is very much appreciated. __________________________________________________________________ External Toolchain URL: https://wiki.freebsd.org/ExternalToolchain Contact: Baptiste Daroussin Contact: Warner Losh Contact: Brooks Davis The main goal of the external toolchain project is to be able to build world and kernel with a non-default toolchain. It can be helpful to: * Prepare a migration to a newer version of toolchain components. * Port FreeBSD to a new architecture * Upgrade from a FreeBSD that ships with GCC 4.2 to a version that ships with clang 3.5+ (which needs a more modern toolchain than GCC 4.2 to bootstrap). The initial external toolchain work only supported clang. It has been extended to support recent GCC (4.9.1 has been tested) and recent binutils (2.24 and 2.25). A large number of fixes have been committed to HEAD to support incompatible behaviour changes between ld(1) from binutils 2.17.50 (the version in base) and binutils 2.24+. A large number of warnings have been deactivated when building the kernel to make sure it is possible to build the kernel with recent GCC (first 4.6 and then 4.9.1) The build system has been changed to build libc++ as the C++ standard library implementation when a recent enough GCC (4.6+) is used to build world. To simplify using an external toolchain, the following pre-seeded configurations have been added to the ports tree: * amd64-xtoolchain-gcc * powerpc64-xtoolchain-gcc * sparc64-xtoolchain-gcc Those packages will depend on special versions of GCC (minimalistic cross-built ready GCC) and on binutils. To use them, run: make CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 As a result of this effort, it is possible to successfully build and run a kernel and world built with GCC 4.9.1 and binutils 2.24 on sparc64, amd64 (with minor tweaks), powerpc and powerpc64. Open tasks: 1. Patch GCC 4.9 to support FreeBSD mips, arm and aarch64 and submit the patches to upstream. 2. Adapt and upstream the aarch64 patches for binutils 2.25. 3. Add more pre-seeded configurations. __________________________________________________________________ FreeBSD on Google Cloud URL: https://github.com/swills/FreeBSD-gcloud URL: https://plus.google.com/112202779615695172291/posts/eYajb8JKerY Contact: Steve Wills Google Cloud is a cloud computing platform that allows users to run hosted services and servers in a cloud maintained by Google. The goal of this project is to provide an easy way to create and manage FreeBSD installations running on Google Cloud. The good news: FreeBSD 10.1 runs fine. You can create an image and start it up and login via standard ssh, via the gcloud command or via the web console (ssh in a web browser window). More details on how to do all this can be found in the links. Basically, you should be able to gcutil addimage freebsd-101-release-amd64-20150101032704 gs://swills-test-bucket/FreeBSD-10.1-RELEASE-amd64-20150101032704.tar.gz Then spin up an image using gcloud compute instances create --zone us-central1-b --image freebsd-101-release-amd64-20150101032704 --boot-disk-size 20GB gtest1 These commands are part of the google-cloud-sdk port, which contains all the commands to interact with Google Cloud. There is also a google-daemon port which is used in running instances to create users and set them up and a google-startup-scripts port which handles running startup/shutdown scripts as specified in node metadata. Additionally, the firstboot-growfs port has been brought back so that new instances will grow their root filesystem. (Thanks to Colin Percival for having created that port initially.) There is also a firstboot-freebsd-update port which can be used to update a system on first boot but is currently disabled (see below). Similarly, the firstboot-pkgs port/scripts will install specified packages on first boot. Overall, Google Cloud Compute is quite nice; instances spin up in about 60 seconds and it is very reasonably priced with automatic discounts for longer term usage. There is a $300 credit for first time users that also makes it free to try out. That credit covers quite a lot of time, and the instances are pretty fast, as well, even the ones without SSDs. The bad news: Google does not make sharing non-official images as easy as AWS, so you have to create your own using my public tar file. The tar file was created using the script in the links section. That script can be used to produce customized images, even though there are no official image (nor will there be any time soon). There are some issues running FreeBSD on Google Cloud, listed in the tasks section. Open tasks: 1. The 8 and 16 cpu instances seem to reboot randomly. 2. Repeated UFS panics that Google folks have reported, but I do not think those are particular to Google Cloud. The panic message is "ffs_valloc dup alloc". 3. Running freebsd-update causes the system to become unbootable, so updates do not work. (Reboots work fine otherwise.) 4. There is no gcimagebundle command in the Ports Collection so you cannot easily create an image from a running machine. 5. There are a few minor issue with the startup script that is supposed to regenerate ssh keys (for when you create an image from an existing system). 6. 10.1 works, but 10.0 does not boot; other versions remain untested. 7. The kern.vm_guest sysctl node does not detect that it is in a guest. 8. The vtnet driver needs wq disabled on 16 cpu boxes, but it is just disabled everywhere for now since that is easier. 9. There is work needed for the Google safe_format_and_mount command which formats and mounts newly attached disks, but this is just a nicety really. 10. I need to look into irq affinity for vtnet. 11. We need to support virtualized clocks; bryanv@ is working on this. In fact, all his ongoing work in the virtualization area would probably make things work better. 12. It would be nice if there was the ability to disable the spinner before the loader, which clutters up the console log. The ability to disable it is in HEAD; hopefully it will be MFCd to 10-STABLE before 10.2. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook URL: http://blog.grem.de/pages/c720.html Contact: Michael Gmelin The Acer C720 Chromebook is a powerful but inexpensive laptop designed to run Google's Chrome OS. This project aims to bring FreeBSD to the C720, providing an easy way for people to experience FreeBSD on hardware which is widely available and inexpensive. As of this update, most system features work, including the keyboard, WiFi, sound, VESA graphics, touchpad, and USB. The battery life is a reasonable 5 to 6 hours (compare to the published 8.5 hour lifetime for Chrome OS. Open tasks: 1. Streamline patches and merge them into HEAD. 2. Make suspend/resume work (depends on Haswell support). __________________________________________________________________ Git Integration URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git URL: https://www.kernel.org/pub/software/scm/git/docs/git-svn.html URL: https://github.com/git/git/commit/83c9433e679635f8fbf8961081ea3581c= 93ca778 URL: https://wiki.freebsd.org/GitWorkflow URL: https://github.com/freebsd/freebsd URL: https://bugs.freebsd.org/bugzilla Contact: Git discussion list Several FreeBSD developers have expressed interest in improving the tools and documentation to facilitate the use of the Git source code management (SCM) system when working with FreeBSD code. Some highlights of the work in this area include the following: * At Alfred Perlstein's request, a new mailing list freebsd-git@FreeBSD.org was created for discussion of git use in the FreeBSD project. * Alfred Perlstein submitted a patch to git. This patch allows a developer to work on a source code tree in git and use git-svn to push changes from this tree directly to a Subversion repository and set Subversion properties. Before this patch, git-svn did not properly set Subversion properties. This is important for FreeBSD developers because the FreeBSD Subversion repo will block commits which do not properly set certain Subversion properties. The git project accepted this change in changeset 83c9433. * Alfred Perlstein updated the Git Workflow wiki document to include information for using git-svn to commit to the FreeBSD Subversion repository. * Bartek Rutkowski wrote a script which integrates Github and FreeBSD Bugzilla. When a user files a Github pull request against the FreeBSD source code tree on Github, this script will open a new PR in FreeBSD Bugzilla. This will allow users to contribute code and patches via Github pull requests, and have the request tracked by FreeBSD developers in Bugzilla. Github pull requests cannot currently be directly merged into the FreeBSD source tree on Github, because the main source code repository is currently Subversion. The FreeBSD source code tree on Github is a read-only mirror of the FreeBSD Subversion repository. Craig Rodrigues coordinated with Bartek Rutkowski and bugmeister@FreeBSD.org to move forward on this, and provide Bartek Rutkowski with enough access to Bugzilla to open PR's via a script. Open tasks: 1. The Github integration script is not deployed yet and is not active for all pull requests against the FreeBSD source tree on Github. Bartek Rutkowski and bugmeister@FreeBSD.org need to work out the final details for deploying this script into production. The script must be accessible via HTTP POST requests because it uses the Github REST API. Bartek Rutkowski and bugmeister@FreeBSD.org need to reach agreement on where this script lives, and do a security audit. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testin= g URL: https://wiki.freebsd.org/201411DevAndVendorSummit?action=3DAttachFi= le&do=3Dview&target=3Dkyua_jenkins.pdf URL: https://issues.jenkins-ci.org/browse/JENKINS-21507 URL: https://issues.jenkins-ci.org/browse/JENKINS-24521 URL: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide URL: http://www.freshports.org/textproc/igor/ URL: https://jenkins.freebsd.org/job/FreeBSD_Doc-igor URL: https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/ URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-November/0= 00609.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2014-December/0= 00697.html URL: https://lists.freebsd.org/pipermail/svn-src-all/2014-October/092212= =2Ehtml URL: http://lists.freebsd.org/pipermail/freebsd-testing/2015-January/000= 713. html URL: https://github.com/Homebrew/homebrew/pull/32346 URL: https://github.com/freebsd/freebsd-ci/pull/3 URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0723.html URL: https://lists.freebsd.org/pipermail/freebsd-testing/2015-January/00= 0722.html Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing Since the last status report, many people have contributed help in various areas to help with Continuous Integration and Testing in FreeBSD. Some of the highlights include: * The Jenkins project mentioned on their blog how FreeBSD is using Jenkins and kyua to run OS-level tests. * Craig Rodrigues submitted patches to upgrade Jenkins to use JNA 4.1.0. The Jenkins project accepted these patches [JENKINS-24521] in the Jenkins 1.586 release. This fixed problems with PAM authentication support in Jenkins on FreeBSD [JENKINS-21507]. * Craig Rodrigues gave a presentation "Kyua and Jenkins Testing Framework" for BSD at the Developer and Vendor summit on November 3, 2014 in San Jose, California. In the presentation, Craig Rodrigues described how, for every commit to the FreeBSD source tree, nearly 3000 tests are run using kyua inside a bhyve virtual machine. The kyua test results are exported to JUnit XML format, which is then used by Jenkins to generate web-based test reports with graphs. * Li-Wen Hsu set up a Jenkins build named FreeBSD_Doc-igor to run the Igor tool written by Warren Block. Igor proofreads FreeBSD documentation and reports various errors. * Craig Rodrigues set up a Jenkins build named FreeBSD_HEAD_sparc64 to build the FreeBSD HEAD branch for the sparc64 architecture * Garrett Cooper imported more tests from NetBSD. After this import, there are now over 3000 tests in the /usr/tests directory. * Susan Stanziano from Xinuous ran kyua tests and provided feedback about test errors, running the tests in a bhyve VM. * Andy Zhang from Microsoft ran kyua tests and provided feedback about test errors running in a Hyper-V 2012R2 VM. * Steve Wills ran the FreeBSD tests in Google Compute Engine and provided the test results. * Craig Rodrigues submitted a formula to create a package for kyua in the Homebrew packaging system on OS X. The Homebrew project accepted this. Now, kyua can easily be installed on OS X via a Homebrew package. Hopefully this will make it easier to share more test infrastructure and scripts with OS X. * Craig Rodrigues submitted to the Debian project a kyua package. Approval for this is still pending. A package will make it much easier to install kyua on Linux distributions which use Debian packages such as Debian, Ubuntu, and Linux Mint. Hopefully this will make it easier to share more test infrastructure and scripts with Linux. * Brian Gardner submitted scripts to run the Regression Test Harness for OpenJDK (jtreg). The test results are in JUnit XML format, which can be natively imported into Jenkins. * Ahmed Kamal, an experienced devops expert and past contributor to the Ubuntu project, offered to help Craig Rodrigues with improving the automation and deployment of Jenkins nodes in the FreeBSD cluster using the Saltstack automation framework. Ahmed is interested in helping the FreeBSD project. * Craig Rodrigues worked with Adrian Chadd to set up Jenkins builds of MIPS targets. The next step will be to get kyua tests running inside a QEMU MIPS VM. Open tasks: 1. Set up more builds based on different architectures. 2. Improve the maintenance of nodes in the Jenkins cluster using devops frameworks such as Saltstack. 3. Get feedback for improving the Kyua Quickstart Guide. 4. People interested in helping out should join the freebsd-testing@FreeBSD.org list. __________________________________________________________________ Migration to ELF Tool Chain Tools 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. It started as part of FreeBSD but has moved to a standalone project to encourage wider participation from others in the open-source developer community. FreeBSD's libelf and libdwarf are now imported from upstream sources in contrib/elftoolchain. ELF Tool Chain provides a set of tools equivalent to the GNU Binutils suite. This project's goal is to import these tools into the FreeBSD base system so that we have a set of up-to-date and maintained tools that also provide support for new CPU architectures of interest, such as arm64. The following tools have now been imported and are available by setting the src.conf knob WITH_ELFTOOLCHAIN_TOOLS=3Dyes: * addr2line * nm * size * strings * strip (elfcopy) A ports exp-run uncovered some bugs in these tools. The bugs are being fixed in the FreeBSD source tree and are in the process of being committed to the upstream project. ELF Tool Chain's readelf will be enabled as well once some missing functionality in ELF note parsing is added. ELF Tool Chain's elfcopy provides equivalent functionality to Binutils' objcopy, and accepts the same command-line arguments. For it to be a viable replacement for all uses of objcopy in the base system, it must gain support for writing portable exectuable (PE) format binaries, which are used by UEFI boot code. The ELF Tool Chain project does not currently provide replacements for as, ld, and objdump. For FreeBSD these tools will likely be obtained from the LLVM project. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Import readelf. 2. Add missing functionality to readelf. 3. Add missing functionality to elfcopy and migrate the base system build. 4. Fix issues found by fuzzing inputs to the tools. 5. Switch the default to WITH_ELFTOOLCHAIN_TOOLS. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg Contact: The pkg team The package development team has released pkg(8) 1.4. This release fixes lots of bugs and adds some new features: * Stricter checking of paths passed via the plist * Change the ABI string to be closer to MACHINE_ARCH * Add three-way merge functionality * Add conservative upgrade support for multi repository configurations * Multirepository priority An important part of the development direction for the 1.4 release was stabilizing the existing features and improving the pkg(8) experience on small/embedded machines (reducing memory usage and speeding up operations). pkg(8) is not only the FreeBSD Package Manager, but also the Package Manager for DragonflyBSD. Support has been added to build pkg(8) on OS X and Linux. This work will allow other Operating Systems the option of adopting pkg(8) to manage their packages and bring new developers into the project. Open tasks: 1. Add more regression tests. 2. Package the FreeBSD base system. 3. Allow using mtree as a plist when creating a package. 4. Implement flexible dependencies. 5. Test the development branch. 6. More developers are needed, check the Issues on Github. __________________________________________________________________ FreeBSD Xen URL: http://wiki.xen.org/wiki/FreeBSD_PVH URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Contact: Roger Pau Monn=E9 Contact: Justin T. Gibbs During this quarter almost all pending Xen changes have been committed, enabling FreeBSD to be used as Dom0 under the new PVH mode. The set of features supported by FreeBSD is still limited, but it should allow for basic usage of FreeBSD as Dom0. Support for booting Xen from the FreeBSD boot loader will be committed very soon to HEAD. Apart from testing on a variety of hardware, work has now shifted to improve PVH support in Xen itself in order to have feature parity with a traditional PV Dom0 and to declare the PVH ABI as stable. Regarding guest improvements (running FreeBSD as a DomU), there is also ongoing work to add unmapped IO support to Xen blkfront, which is blocked pending some modifications to the generic bounce buffer code. This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation. Open tasks: 1. Test on different hardware. 2. Improve the performance of the netback and blkback backends. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve generic bounce buffer code for unmapped bios in order to support blkfront alignment requirements. __________________________________________________________________ Linux Emulation Layer, the Linuxulator URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ URL: https://reviews.freebsd.org/differential/query/i9Ua2XMYQtNX/ Contact: Dmitry Chagin The main goal of the Linux emulation layer project is the execution on FreeBSD of multithreaded Linux applications that require the glibc library version 2.20 or later to be available. Glibc 2.20 requires a Linux kernel (or emulation thereof) of version 2.6.32 or later. The main obstacle preventing this is that the current Linuxulator uses native FreeBSD processes for emulating Linux threads. This leads to several problems, including problems with process reparenting and dethreading, wait() and signal handling. It would be much better to reuse the FreeBSD kernel code for thread management than to create a completely new codebase for pseudothread management in the Linuxulator. At present, the linux emulation layer project has implemented all of the necessary system calls for supporting glibc 2.20, and more, bringing the emulated Linux kernel version to 2.6.32: * Using native threads for emulating Linux threads * Implemented VDSO support, including DWARF for signal trampolines, which are needed for stack unwinding in pthread_cancel() * Implemented the "vsyscall hack", used by some Linux-based distributions, including CentOS 6 * Implemented the epoll() system call emulation * Added support for x86_64 * Many bugs were fixed The project's code is located in the FreeBSD Project's Subversion repository at base/user/dchagin/lemul (a little bit old). To facilitate merging the improvements back to head, several patches have been placed on reviews.FreeBSD.org with the tag #lemul. Nearly half of the patches have already been approved by Ed Maste and Edward Tomasz Napierala. Open tasks: 1. Review and merge the lemul branch to head within the next month or two. 2. Implement native and Linuxulator inotify() system calls. 3. Implement the ptrace() system call for the x86_64 Linuxulator. 4. Implement the signalfd() and timerfd() system calls for the Linuxulator. 5. Implement Priority Inheritance Futexes for the Linuxulator. 6. Extend xucred support, required for many Linux applications. __________________________________________________________________ PCI SR-IOV Infrastructure URL: https://github.com/rysto32/freebsd/commits/iov_ixl Contact: Ryan Stone PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the PCIe standard that provides hardware acceleration for the virtualization of PCIe devices. When SR-IOV is in use, a function in a PCI device (known as a Physical Function, or PF) will present multiple Virtual PCI Functions (VF) on the PCI bus. These VFs are fully independent PCI devices that have access to the resources of the PF. For example, on a network interface card, VFs could transmit and receive packets independently of the PF. The most obvious use case for SR-IOV is virtualization. A hypervisor like bhyve could instantiate a VF for every VM and use PCI passthrough to assign the VFs to the VMs. This would allow multiple VMs to share access to the PCI device without having to do any expensive communication with the hypervisor, greatly increasing the performance of I/O within a VM. Work on the core PCI infrastructure is complete and undergoing review. Currently it is planned to commit the PCI infrastructure to head by the end of January. In addition to the PCI infrastructure, individual PCI drivers must be extended to implement SR-IOV. An SR-IOV implementation is in progress for the ixl(4) driver, which supports the Intel XL710 family of 40G and 10G NICs. Currently it is planned to have this in review by the end of January. An implementation for ixgbe(4) is also in progress, but there is no timeline for completion. This project is sponsored by Sandvine Inc.. __________________________________________________________________ Process Management Contact: Konstantin Belousov Contact: Peter Holm There were several improvements made to FreeBSD's process management last quarter. The Reaper facility was added, allowing a process to reliably track the running and exiting state of the whole subtree of its processes. It is intended to improve tools like timeout(1) or poudriere, by making it impossible for a runaway grandchild to escape the controlling process. The feature was designed based on similar facilities in DragonFlyBSD and Linux, with some references to Solaris contracts. Committed to HEAD in r275800. The FreeBSD suspension code does not ensure that the system, both software and hardware, is in a steady and consistent state. One aspect is usermode process activity, which is not yet stopped, continuing to making requests to the hardware. It is not realistic to expect drivers to be able to correctly handle the calls after SUSPEND_CHILD. We developed a facility to stop usermode threads at safe points, where they are known to not own and to not wait for kernel resources, in particular, not waiting for device requests finishing. It is based on the existing single-threading code, but extending it to allow external thread to put some processes into stopped state. Also, a facility to sync filesystems before suspend was added, to ensure that consistent metadata and as much as possible of the cached user data are on stable storage, to minimize the damage that could be caused by a failed resume. The code stressed some parts of the system and has led to discovery of a number of bugs in different areas, including process management, buffer cache, and syscall handlers. The bugs were fixed, and the fixes and features commmitted by a series culminating in r275745. During the work described above, it was noted that process spinlock duties are significantly overloaded (the same is true for the process lock). The spinlock was split into per-feature locks in r275121. As a result, it was also possible to eliminate recursion on it in r275372. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Secure Boot URL: https://wiki.freebsd.org/SecureBoot Contact: Edward Tomasz Napiera=B3a UEFI Secure Boot is a mechanism that requires boot drivers and operating system loaders to be cryptographically signed by an authorized key. It will refuse to execute any software that is not correctly signed, and is intended to secure boot drivers and operating system loaders from malicious tampering or replacement. This project will deliver the initial phase of secure boot support for FreeBSD and consists of: * creating ports/packages of the gnu-efi toolchain, Matthew Garrett's shim loader, and sbsigntools * extending the shim to provide an API for boot1.efi to load and verify binaries signed by keys known to the shim * writing uefisign(8), a BSD-licensed utility to sign EFI binaries using Authenticode, as mandated by the UEFI specification. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Ensure that the signature format properly matches UEFI spec requirements. 2. Verify that correctly signed, incorrectly signed, and unsigned loader components are handled properly. 3. Investigate signed kernel ELF objects (including modules). __________________________________________________________________ Timer Function Support for Linuxulator Contact: Bjoern A. Zeeb Since 2006, initial support for Linux timer function compatibility support was present but untested. This update corrects the initial implementation and makes it available to the 32-bit Linuxulator on amd64, not just on i386. Starting with FreeBSD 10.1, this enables users to run another FPGA high-level synthesis toolchain and emulation platform on a FreeBSD system. This project is sponsored by DARPA, and AFRL. __________________________________________________________________ Updating OpenCrypto URL: https://svnweb.freebsd.org/changeset/base/r275732 URL: http://freebsdfoundation.blogspot.com/2014/08/freebsd-foundation-an= nounces-ipsec.html Contact: John-Mark Gurney The project adds support for AES-GCM and AES-CTR modes to the OpenCrypto framework. Both software and AES-NI accelerated versions are functional, working and committed. Ermal Lu=E7i (eri@) is working on adding support for the additional modes to IPsec. This project is sponsored by The FreeBSD Foundation, and Netgate. Open tasks: 1. Commit the port that provides the NIST KAT vectors so that the tests committed can run. __________________________________________________________________ FreeBSD on POWER8 URL: https://wiki.freebsd.org/POWER8 URL: http://www.tyan.com/campaign/openpower/ Contact: Nathan Whitehorn Contact: Justin Hibbits Contact: Adrian Chadd IBM and the OpenPOWER Foundation are pushing for a wider software and hardware ecosystem for POWER8-based systems. Beginning January 3, we have been doing bringup work on a Tyan GN70-BP010 POWER8 server, a quad-core 3 GHz system with 32 hardware threads. The main target for the port is the PowerKVM hypervisor provided on OpenPOWER hardware. This uses the same software interfaces as the PowerVM hypervisor already supported on earlier POWER hardware. The target is to have this operation mode fully supported by FreeBSD 10.2. FreeBSD currently runs under the hypervisor when using a mass storage driver other than the built-in virtualized SCSI; the issues with the SCSI driver should be solved shortly. The longer-term goal is to also operate on the bare system. This requires interaction with the OPAL system firmware and the development of device drivers for the on-board PCI, console, and interrupt controller hardware. As of January 4, the FreeBSD kernel had printed initial messages to the console. This project is sponsored by FreeBSD Foundation . Open tasks: 1. Fix virtualized SCSI driver in PowerKVM. 2. Write OPAL drivers. 3. Integrate loader(8) with petitboot bootloader. __________________________________________________________________ FreeBSD/arm64 URL: https://wiki.freebsd.org/arm64 URL: https://github.com/FreeBSDFoundation/freebsd/tree/arm64-dev Contact: Andrew Turner Contact: Ed Maste Contact: Zbigniew Bodek There is growing interest in ARM's 64-bit architecture. Officially named AArch64, it is also known as ARMv8 and arm64. Andrew Turner started initial work on the FreeBSD/arm64 port at the end of 2012. The FreeBSD Foundation is now collaborating with ARM, Cavium, the Semihalf team, and Andrew Turner to port FreeBSD to arm64, and significant progress was made on the port over the last quarter of 2014. As of the end of the year, FreeBSD boots to single-user mode on arm64, executing both static and dynamic applications. Patches in review allow FreeBSD to boot to multi-user mode, and these are expected to be merged soon. This includes implementing many stub functions in userland and the kernel. With this, FreeBSD has booted to multi-user mode on both the ARM Foundation Model and the QEMU full system emulation. Cavium has supplied a software simulator of their Thunder X hardware. Bringup of FreeBSD has started on this including writing new drivers for the ARM Generic Interrupt Controller v3 (GICv3) and a preliminary driver for the PCIe root complex. With these, FreeBSD is able to boot on this simulator in preparation for testing on hardware. Further work is progressing to add full PCIe bringup and to add support for the GICv3 Interrupt Translation Services (ITS) for MSI-X. Further improvements have been made to the loader to allow it to take the Flattened Device Tree data from UEFI and pass it to the kernel. In the kernel, busdma, CPU identification, and improvements to interrupt handling have been made, along with preliminary KDB support. Hardware for testing the port will be installed in the FreeBSD Test Cluster hosted by Sentex Communications. The first reference platform, Cavium's ThunderX, is expected to arrive in the cluster in mid-January. This project is sponsored by The FreeBSD Foundation, ARM, and Cavium. Open tasks: 1. Bring up and test kernel support on real hardware. 2. Implement the remaining userland libraries and binaries. 3. Produce installable images. __________________________________________________________________ libxo: Generate Text, XML, JSON, and HTML Output URL: http://juniper.github.io/libxo/libxo-manual.html Contact: Marcel Moolenaar Many FreeBSD utilities provide insight into the operational state of a running FreeBSD system and as such are used regularly to monitor the system. These utilities provide their output in a human readable form and sometimes even optimized for the limited width of traditional terminals. Often times these utilities are used by other programs that want to present the output in different ways or as part of other user interfaces. For such use cases, it is infinitely better to work with machine-readable output instead of human-readable output. Juniper Networks has created a library called libxo, which makes it easy for utilities to emit output in various formats. By default, text output is emitted, but with the introduction of the --libxo option this can be changed to XML, JSON, and HTML. The FreeBSD project has imported this library into the base system and is in the process of rewriting utilities to use libxo. Related to this, FreeBSD now also has the xo utility that allows scripts to grow the same capabilities. Instead of using echo or printf in scripts, output can be done using the xo utility. The df, w, and wc utilities have been converted to use libxo. The netstat utility is in the process of being converted and others are planned. Open tasks: 1. FreeBSD contains a lot of utilities that could benefit from having the ability to emit various output formats, too many for a few people to convert in time for FreeBSD 11.0-RELEASE. If you or your company would like to see a particular utility converted, consider learning about libxo and trying to perform the conversion of said utility to help out. __________________________________________________________________ mandoc(1) Support URL: http://mdocml.bsd.lv Contact: Baptiste Daroussin Contact: Ulrich Spoerlein Contact: The Documentation Team mandoc(1) has been made the default manual page formatter on HEAD -- man(1) will use mandoc(1) to format manual pages by default, then fall back to groff(1) if it fails. This change also fixes an issue with the FreeBSD man(1) command not being able to properly deal with ".so" in gzipped manual pages. The documentation team has spent a lot of time fixing issues reported by mandoc(1) in the FreeBSD manual pages. This greatly improves the quality of our manual pages. Most manual pages with remaining issues are from contrib/, for which changes should be reported and fixed upstream. The "manlint" target has also been switched to use mandoc -Tlint, which results in the target being more useful when working on manual pages. Some groff(1) versus mandoc(1) formatting differences have been spotted and reported to mandoc's upstream developers. Open tasks: 1. Switch makewhatis(1) to the version shipped with mandoc(1). 2. Figure out a way to detect mandoc(1)-unfriendly manpages in ports and create catpages with groff(1) for them. 3. Remove groff(1) from the base system. __________________________________________________________________ GNOME on FreeBSD URL: http://www.freebsd.org/gnome URL: https://github.com/freebsd/freebsd-ports-gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD 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 was an exciting time for the GNOME Team. We imported GNOME 3.14.0 and CINNAMON 2.2.16 into the ports tree. At the same time, we removed the old GNOME 2.32 desktop. And two weeks later we updated GNOME to 3.14.2 and CINNAMON to 2.4.2, which was collected while the preparation for the initial GNOME 3.14.0 import was under way. We moved our development repo to GitHub. The repo is structured as follows: the master branch is vanilla FreeBSD Ports, and we have theme branches for topics such as the porting of MATE 1.9 (the mate-1.10 branch) and GNOME 3.15 (the gnome-3.16 branch). The GNOME 3.14 branch (gnome-3.14) is not used or updated any more because the content has been committed to ports, but is kept around for the history. Open tasks: 1. The GNOME website is stale. Work is starting on updating the development section. We could use some help here. 2. MATE 1.10 porting is under way; the latest 1.9 releases are available in the mate-1.10 branch. 3. GNOME 3.16 porting is under way, and is available in the gnome-3.16 branch. __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: http://portscout.freebsd.org/kde@freebsd.org.html 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. As mentioned last quarter, Alonso Schaich (alonso@) became a committer and since then has made good progress helping his mentors Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@) maintain all Qt and KDE-related ports. This quarter, Qt 5.3 was finally committed to the ports tree. Extensive work was required, including cleaning up and/or changing a lot of the Qt5 ports infrastructure to make it both easier to maintain the Qt ports as well as finally make it possible to build newer versions when older ones are already installed on the system. We have also updated KDE in our experimental area51 repository and committed several updates to other ports such as KDevelop and KDE Telepathy. Overall, we have worked on the following releases: * CMake 3.1.0 (in area51, exp-run in progress for it to be committed to the ports tree) * Calligra 2.8.6 (in area51) * KDE 4.14.2 (committed to ports), 4.14.3 (in area51) * KDE Telepathy 0.8.0 (committed to ports) * KDevelop 4.7.0 (committed to ports) * Qt 5.3.2 (committed to ports) Tobias Berner has contributed patches to update QtCreator to 3.3.0 as well as KDE Frameworks 5 ports which are under review for inclusion in our experimental area51 repository. Open tasks: 1. Update Qt5 to 5.4.0. 2. Try to contribute to the work on getting rid of HAL on FreeBSD, which seems to be gaining more traction recently. 3. Add KDE Frameworks 5 ports to our experimental repository. __________________________________________________________________ Linux Emulation Ports URL: https://github.com/allanjude/linux-ports URL: https://github.com/vassilisl/freebsd-linux_base-f20 URL: https://svnweb.freebsd.org/base/user/dchagin/lemul/ Contact: Johannes Meixner Contact: Allan Jude Contact: Vassilis Laganakos The Linux emulation stack in the ports collection was upgraded to include CentOS 6.6 on November 11. After smoothing out several bugs that had been introduced, we were able to bump the default version of the Linux userland from Fedora 10 to CentOS 6.6 on December 9th. Providing a more modern Linux userland and support libraries allows a large number of Linux applications to be run on FreeBSD. The goal behind providing an updated Fedora-based userland is to support more desktop-oriented applications, which require newer libraries than are provided by CentOS 6. Providing 64-bit versions of the CentOS userland will allow applications that are only available in 64-bit form, such as a number of scientific and math related applications, to be run on FreeBSD. Support for 64-bit binaries also requires the 64-bit Linux kernel emulation layer from the lemul branch, which requires more testing and review before being merged into HEAD. This project is sponsored by Perceivon Hosting Inc., and ScaleEngine Inc.. Open tasks: 1. Update Allan Jude's 64-bit Linux ports to CentOS 6.6. 2. Add Fedora 20 base/userland ports to ports/head. 3. Refactor Mk/bsd.linux-*.mk to facilitate the above additions. 4. Promote testing and merging of Dmitry Chagin's lemul branch. (Updated Linux kernel emulation, and 64-bit support) __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://blogs.freebsdish.org/graphics/ URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team Mesa was upgraded to 10.3, then 10.4 for FreeBSD 10.1-RELEASE and 11-CURRENT. We test release candidates and therefore this port is now usually updated shortly after a new release. Mesa 10.x brings huge improvements in terms of OpenGL standards support, performance and stability, especially for Radeon owners. Mesa 9.1 is kept for FreeBSD 9.x, but we have plans to fix this; see below. graphics/gbm and devel/libclc are new ports used by Mesa to implement OpenCL. The next step is to finish the port for Mesa's libOpenCL.so, named Clover. This will permit users to run OpenCL programs on Radeon GPUs for now. xserver was upgraded from 1.12 to 1.14. This is the last version of xserver supporting Mesa 9.1. Changes are described in an article on the blog. The most noticeable one is the switch from the input device detection back-end based on HAL to the one based on devd(8). hald(8) is still required by many desktop environments, but the X.Org server itself is free from it. xserver was the last port supporting the WITH_NEW_XORG knob. The knob is now completely removed. This was the occasion to add WITH_NEW_XORG and WITH_KMS to the list of deprecated knobs to help people clean up their make.conf. At the same time, the new-xorg alternate pkg repository was deprecated. After discussion, two options were enabled by default: * TEXTURE_FLOAT in graphics/dri, which allows Mesa to advertise the support for OpenGL 3.0+; * LCD_FILTERING in print/freetype2, which enables the subpixel rendering engine, improving font anti-aliasing. These two packages now provide a better user experience out-of-the-box. Users who are uncomfortable with the options may unset them and rebuild the ports. There is no need to rebuild anything else. On the kernel side, Tijl Coosemans added AGP support back to the TTM memory manager and therefore to the Radeon driver. His work was merged back to stable/10 and will be available in FreeBSD 10.2-RELEASE. We migrated our Ports development tree to Git and GitHub. Tracking changes in the official Ports tree and preparing patches is much easier. Furthermore, we can accept pull requests. All of the reasons behind this change are detailed on the blog and the workflow is described on the wiki. The XDC 2014 (X Developer's Conference) was a great conference. Reviving the relationship with the developers of the graphics stack was a success! A report is available on the blog. Our next items on the roadmap are: 1. Provide FreeBSD 10.1-RELEASE's i915 driver to FreeBSD 9.x users through a new port. This is a work in progress, but it would allow us to remove Mesa 9.1 and make Mesa 10.4 available everywhere. 2. Once Mesa 9.1 is gone, we can update xserver to 1.16. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org Contact: Gerald Pfeifer Contact: David Naylor Contact: Kris Moore The Wine on FreeBSD project has been steadily forging ahead for the past three quarters and has updated the ports for the following versions: * Stable releases: 1.6.2 (3 port revisions) * Development releases: 1.7.16 through 1.7.33 The ports have packages built for amd64 (available through the ports emulators/i386-wine and i386-wine-devel) for FreeBSD 8.4, 9.1+, 10.0+, and CURRENT. Accomplishments include: * Upstreaming 33 patches to fix Wine on FreeBSD -- many thanks to Gerald for this work. * Migrating to the USES framework. * Building Wine with the X compositing extension. * Adding support for MPG123 and V4L. * Backporting changes made to the -devel ports to the stable ones and fixing minutiae here and there. * Creating a new Wine port for the Compholio patches. * Changing i386-wine(-devel) to set the LD_LIBRARY_PATH_RPATH variable. * Improving library bundling for i386-wine(-devel). * Various improvements to the patch-nvidia.sh script for i386-wine(-devel). * Various smaller changes. We would like to thank all the volunteers who contributed feedback or even patches. We would also like to welcome kmoore@ to the Wine team. He has been extensively involved in bringing wine-compholio to the Ports Collection. Future development on Wine will focus on: * Creating a 64-bit capable port of Wine (aka Wine64). * Creating a WoW64 capable port of Wine (aka Wine + Wine64). * Fixing directory listing on FreeBSD 8 and 9. Maintaining and improving Wine is a major undertaking that directly impacts end-users on FreeBSD, including many gamers. If you are interested in helping, please contact us. We will happily accept patches, suggest areas of focus, or have a chat. Open tasks: 1. Open Tasks and Known Problems (see the Wine wiki page). 2. FreeBSD/amd64 integration (see the i386-Wine wiki page). 3. Porting WoW64 and Wine64. __________________________________________________________________ Xfce URL: https://wiki.freebsd.org/Xfce 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: * misc/xfce4-weather-plugin 0.8.5 * science/xfce4-equake-plugin 1.3.6 * sysutils/xfce4-netload-plugin 1.2.4 * sysutils/xfce4-systemload-plugin 1.1.2 * www/midori 0.5.9 * x11/xfce4-taskmanager 1.1.0 * x11/xfce4-whiskermenu-plugin 1.4.2 * x11-wm/xfce4-desktop 4.10.3 Two new ports have also been added (taken from our repository): * deskutils/xfce4-volumed-pulse * x11/xfce4-dashboard Moreover, we are working on the next stable release, with these ports being updated: * sysutils/xfce4-power-manager 1.4.2 * x11/xfce4-dashboard 0.3.4 * x11-wm/xfce4-session 4.11.1 We sent some patches to upstream. * bug #11104, to keep 'wallpaper settings' in Ristretto with xfdesktop >=3D 4.11 * bug #11249, add 'Hidden' option in desktop item editor (refused) * bug #11413, to use sysctl(3) and acpi_video(4) for backlight support A FAQ is being written D1305. Open tasks: 1. Find a workaround for when acpi_video(4) is not functional (panel crashes); OpenBSD seems to have same problem. 2. Clean up patch in order to add new panel plugin in ports tree. 3. Continue to work on documentation, especially the Porter's Handbook. __________________________________________________________________ More Michael Lucas Books URL: https://www.michaelwlucas.com/nonfiction/freebsd-mastery-storage-es= sentials URL: http://blather.michaelwlucas.com Contact: Michael Lucas The first small FreeBSD Book, "FreeBSD Mastery: Storage Essentials" is available. Lucas is moving on to FreeBSD books on ZFS, Specialty Filesystems, and jails. They will hopefully be available by BSDCan 2015. Get status updates on his blog, or follow @mwlauthor on Twitter. Open tasks: 1. Push BSDCan out to June, so he has more time to write the new books. __________________________________________________________________ New Translators Mailing List Contact: FreeBSD Translators Mailing List A new mailing list has been created for people translating FreeBSD documents and programs from English into other languages. Discussions can include methods, tools, and techniques. Existing translators are encouraged to join so there is a single point of contact. New translators and those who wish to help with translation are welcome. New members are asked to introduce themselves and mention the languages they are interested in translating. Open tasks: 1. Encourage existing translators to join. 2. Welcome and educate new volunteers. 3. Work on implementing newer and easier translation systems and tools. __________________________________________________________________ Creating Vagrant Images with Packer URL: http://blogs.freebsdish.org/brd/2014/12/22/freebsd-packer-vagrant/ URL: https://github.com/so14k/packer-freebsd Contact: Brad Davis We have developed a recipe to use Packer to create FreeBSD Vagrant images to run on VMware and VirtualBox. Packer is a tool for creating identical machine images for multiple platforms from a single source configuration. Vagrant is a tool to create and configure lightweight, reproducible, and portable development environments. To get started, clone the Git repo and follow the directions in the README. More information is available from the Packer and Vagrant websites. __________________________________________________________________ FreeBSD Forum Software Migration Contact: FreeBSD Forums Administration Team With funding from the FreeBSD Foundation, the FreeBSD forums were migrated to XenForo software. The new software is far more capable and easy to use. While the entire forum team contributed, Daniel Gerzo did an excellent job importing existing users and messages and bringing back the often-requested "Thanks" feature. The upgrade was completed in time to be ready for the influx of new users from the release of FreeBSD 10.1, and we have already seen an increase in usage. Developers with an @FreeBSD.org address can contact forum administrators to obtain the highly-desired "@" suffix on their forum user name along with a Developer flag. We want to thank the Foundation for making this possible, and the users for their patience and continued presence on the forums! This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Encourage more developers and users to try the new forums. 2. Continue getting feedback from users for tuning and improvements. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ 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. Most of the funding is used to support FreeBSD development projects, conferences, and developer summits; purchase equipment to grow and improve the FreeBSD infrastructure; and provide legal support for the Project. We ended the year exceeding our fundraising goal, by raising over $2,372,132, from 1670 donors! Thank you to everyone who made a donation in 2014. We produced issues five and six of the FreeBSD Journal, ending the year with over 6300 subscribers, exceeding our first-year goal of 5000 subscribers. We also added the desktop/digital edition, so people can read the magazine from their browsers. We also hosted a meeting with the Journal Editorial Board and worked out the editorial calendar for the next two years. This includes topics and articles for the future issues. We were a gold sponsor of EuroBSDCon 2014, and a sponsor of the preceding Developer Summit. A few of our team members attended, which allowed us to have an informal face-to-face board meeting, with a focus on supporting the European region. Kirk McKusick gave a two-day FreeBSD tutorial and Erwin Lansing helped run the Developer Summit. We sponsored 5 FreeBSD contributors to attend the conference. We were a sponsor of the Grace Hopper Conference. Dru Lavigne gave an "introduction to FreeBSD" presentation, that was well attended. We also sponsored Shteryana Shopova to represent FreeBSD, along with Dru, at our booth. We were a sponsor of MeetBSD. Most of our team members attended this conference. Kirk McKusick gave a talk on BSD history. We also had a booth, and raised over $2,200 in donations. We sponsored one person to attend this conference. George organized and ran the two-day Silicon Valley Vendor and Developer Summit following MeetBSD. A lot of work gets started and accomplished at these summits, for example, Kirk worked with various folks to get the ino64 (64-bit inode numbers) project moving. It started in 2011 as a Summer of Code project and has sputtered since getting pushed into the system. In addition to the above conferences, we helped promote FreeBSD at the following conferences: * All Things Open * Ohio Linux Fest * LISA LISA had a great turnout for Dru Lavigne's FreeBSD BoF talk. We visited a few large FreeBSD users in the Bay Area to discuss their use of FreeBSD, plans, and needs, and help facilitate collaboration between them and the Project. Cheryl Blain joined our board, bringing a strong background in business development and fundraising. We received the largest donation in our history, and our treasurer put together an endowment strategy for us to follow. We increased our FreeBSD marketing efforts to help promote and advocate for FreeBSD, as well as educate people on FreeBSD. Some our FreeBSD marketing highlights include: * Created the FreeBSD 10 brochure * Created the Get Involved brochure for recruiting * Created a testimonial flyer to encourage more companies to write FreeBSD testimonials for us. These flyers are available on the FreeBSD Foundation site for FreeBSD advocates to promote FreeBSD at conferences around the world. We also put ads for the Foundation and FreeBSD in the FreeBSD Journal and USENIX ;login: magazine. We are producing a monthly newsletter to highlight what we did the previous month to support the FreeBSD Project. We also produced our December semi-annual newsletter. We redesigned and launched phase 1 of our website. It should be easier to navigate and find the information you need to get help from or to help the Foundation. Glen Barber visited the Microsoft main campus and worked with Microsoft Hyper-V developers to resolve outstanding issues with providing FreeBSD images for the Microsoft Azure platform. Glen also visited the NYI colocation facility to install and configure new servers purchased by the Foundation. We finished the 10.1-RELEASE cycle. Our project development staff and contractors have been working on various projects to add features to and improve FreeBSD. Some of their reports are included in this overall report. Some projects that were worked on this quarter were adding support for 64-bit ARM architecture to FreeBSD, integration work on the vt(4) updated console and UEFI boot support, Secure Boot, refining the in-kernel iSCSI target and initiator stack, an autofs-based automount daemon, migrating to the ELF Tool Chain, and implementing modern AES modes in FreeBSD's cryptographic framework. To read more about how we helped support the FreeBSD Project and community, read our semi-annual newsletter. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJUvdl5AAoJECjZpvNk63USvm4MIONtg7ZxQXtS6ebzHtKSyYxe fbj0bThjJBQwvgxuM8sqAI2tCmDI/BCKh5KsNGYQLs8kVYtFE+N8AWitLlx+fxT1 iOge5UTL2GK2jZObON20jqojJU5waYZvEDyu+cLZFBl92IA/Q1iBbtyhpMOS02Fc sLsMZv/mNmmw8xQbvVjOFFO98DeK67ulgj0g1in6iSiM+FWBPDm/aGbOVGhUmtFS OjmX4SnZlmOrm6WVpI84TAb7XqGXqJ09BbVKWaPK4nug+BrNH3k9LjAkMZGKtMmF Jls34T6JdxM+cSDik2VqkiAlr+k7nJUjKe8TnFrIBgCjq+5tRfTiq4Laly2/U25L 3GEYeoaAgColqVx3vDSKukbyaBOeDy79dtlqnCPS3Tjv1+Kob2w3zz6W7WfMX3cj Hg5ZfUivTPq2CI5+tVe3SM8eBP+BerxU4GXFWE+a6uWUS+L/Zxyu864z2bk6noNI Rd4aZkihamW2nzxqa/+pJMFq88y5afWgLFvHGwl9T092Pgc=3D =3DVGnI -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 10:36:16 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAA7FEBC for ; Tue, 20 Jan 2015 10:36:16 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01ADD95E for ; Tue, 20 Jan 2015 10:36:15 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so20471464wiv.3 for ; Tue, 20 Jan 2015 02:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=YOLa1oInAQA3YGLrHNqUs7GC+lA7WICmRxAHRObs4nE=; b=uHsdukxkPGNbYC3FAFf/3qE2zUL2Z58BJoFkWRReyiTCA2BziWo5rPDmq/libpoAuZ 0zgD+W0db2tuT97h3XZbckzMJGDKPgH/OesXz8JdASdn0voWrC2jdWrvgSJfMDCDvjEr rYp2mP3yO/53+nsXI2rRb6bjbr49EXUCwBvbdxAsAyY0b4D1lP8Or9O5rqVsgDQoIZrN YNcOgx1GNesGPn+DU0RiPUvMerk+6dsw358vTNajV10MJ2c9wUh5/nZf9e7VQknsxptT iaxEpWpoK7vRG+H6urK7UmhsPxiEU93iQvFUIxz6EmqCACNHje2Z2I8pbjLobTP5ArBK qHqQ== X-Received: by 10.180.73.170 with SMTP id m10mr45992648wiv.72.1421750173665; Tue, 20 Jan 2015 02:36:13 -0800 (PST) Received: from [192.168.3.105] ([193.148.0.35]) by mx.google.com with ESMTPSA id a14sm2432171wib.22.2015.01.20.02.36.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 02:36:12 -0800 (PST) Message-ID: <54BE302F.1090302@gmail.com> Date: Tue, 20 Jan 2015 12:38:39 +0200 From: Mihai Vintila User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Harris , "freebsd-stable@freebsd.org" Subject: Re: Poor performance on Intel P3600 NVME driver References: <54B7F769.40605@gmail.com> <20150115175927.GA19071@zxy.spb.ru> <54B8C7E9.3030602@gmail.com> <20150116221344.GA72201@pit.databus.com> <54B999C6.2090909@gmail.com> <54B99DA1.2000001@multiplay.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 10:36:16 -0000 I've recreated the tests on FreeBSD 9.3 and 10.1 after re-installing everything: Things to note for Jim: - firmware upgrade for SSD saved me from errors - bios ASPM disabled saved me from nvme controller disappearing - bios force on x16 saved me from nvme lock - driver is stable now, but i've posted requested information, I'll appreciate it if you can take a look and confirm there isn't a hardware configuration issue. Now both 9.3 and 10.1 seem stable with default settings for nvme. But i've found where the 50x penalty for read between FreeBSD 9.3 ZFS and ZoL and FreeBSD 10.1 appeared : Basically: Pool created with compression=lz4, atime=off recordsize=4k , trim disabled On FreeBSD 9.3 p5 |||Command line used: iozone -Rb /root/output.wks -O -i ||0| |-i ||1| |-i ||2| |-e -+n -r4K -r 8K -s 1G| |||Time Resolution = ||0.000001| |seconds.| |||Processor cache size set to ||1024| |Kbytes.| |||Processor cache line size set to ||32| |bytes.| |||File stride size set to ||17| |* record size.| |||random random bkwd record stride| |||KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread| |||1048576| |4| |61142| |0| |209444| |0| |180129| |41660| |||1048576| |8| |30643| |0| |118759| |0| |102781| |24244 !!!! Same pool imported on FreeBSD 10.1 | |Command line used: iozone -Rb /root/output.wks -O -i ||0| |-i ||1| |-i ||2| |-e -+n -r4K -r 8K -s 1G| |Time Resolution = ||0.000001| |seconds.| |Processor cache size set to ||1024| |Kbytes.| |Processor cache line size set to ||32| |bytes.| |File stride size set to ||17| |* record size.| |||random random bkwd record stride| |||KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread| |||1048576| |4| |66777| |0| |184234| |0| |154268| |48701| |||1048576| |8| |34338| |0| |143999| |0| |124259| |26672 Same pool imported but this time upgraded (embedded_data added) FreeBSD 10.1|| ||Command line used: iozone -Rb /root/output.wks -O -i ||0| |-i ||1| |-i ||2| |-e -+n -r4K -r 8K -s 1G| |Time Resolution = ||0.000001| |seconds.| |Processor cache size set to ||1024| |Kbytes.| |Processor cache line size set to ||32| |bytes.| |File stride size set to ||17| |* record size.| |||random random bkwd record stride| |||KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread| |1048576| |4| |72048| |0| |103035| |0| |92246| |45885| |1048576| |8| |39076| |0| |63655| |0| |59997| |24857| For Jim, data requested: Perftest FreeBSD 9.3p5 |nvmecontrol perftest -n ||32| |-o read -s ||4096| |-t30 nvme1ns1| |Threads: ||32| |Size: ||4096| |READ Time: ||30| |IO/s: ||220880| |MB/s: ||862| |||nvmecontrol perftest -n ||32| |-o write -s ||4096| |-t30 nvme1ns1| |Threads: ||32| |Size: ||4096| |WRITE Time: ||30| |IO/s: ||193949| |MB/s: ||757 Perftest FreeBSD 10.1 nvmecontrol perftest -n 32 -o read -s 4096 -t30 nvme1ns1 Threads: 32 Size: 4096 READ Time: 30 IO/s: 218798 MB/s: 854 root@nvme:~ # nvmecontrol perftest -n 32 -o write -s 4096 -t30 nvme1ns1 Threads: 32 Size: 4096 WRITE Time: 30 IO/s: 212680 MB/s: 830 | I don't think that the driver is the issue as i get same performance on ZFS on Linux, but if you can spot some hardware configuration issues. pciconf -lc nvme0 pciconf -lc nvme1 nvmecontrol identify nvme0 nvmecontrol identify nvme0ns1 nvmecontrol identify nvme1 nvmecontrol identify nvme1ns1 nvme0@pci0:4:0:0: class=0x010802 card=0x370a8086 chip=0x09538086 rev=0x01 hdr=0x00 cap 01[40] = powerspec 3 supports D0 D3 current D0 nvmecontrol logpage -p 1 nvme0 cap 11[50] = MSI-X supports 32 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x3000] cap 10[60] = PCI-Express 2 endpoint max data 256(256) FLR link x4(x4) speed 8.0(8.0) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[150] = VC 1 max VC0 ecap 0004[180] = Power Budgeting 1 ecap 000e[190] = ARI 1 ecap 0003[270] = Serial 1 55cd2e404bce7951 ecap 0019[2a0] = PCIe Sec 1 lane errors 0 nvmecontrol logpage -p 1 nvme1 root@nvme:~ # pciconf -lc nvme1 nvmecontrol logpage -p 2 nvme0 nvme1@pci0:5:0:0: class=0x010802 card=0x370a8086 chip=0x09538086 rev=0x01 hdr=0x00 cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 11[50] = MSI-X supports 32 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x3000] cap 10[60] = PCI-Express 2 endpoint max data 256(256) FLR link x4(x4) speed 8.0(8.0) ASPM disabled(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[150] = VC 1 max VC0 ecap 0004[180] = Power Budgeting 1 ecap 000e[190] = ARI 1 ecap 0003[270] = Serial 1 55cd2e404bce8781 ecap 0019[2a0] = PCIe Sec 1 lane errors 0 nvmecontrol logpage -p 2 nvme1root@nvme:~ # nvmecontrol identify nvme0 Controller Capabilities/Features ================================ Vendor ID: 8086 Subsystem Vendor ID: 8086 Serial Number: CVMD427400562P0JGN Model Number: INTEL SSDPE2ME020T4 Firmware Version: 8DV10110 Recommended Arb Burst: 0 IEEE OUI Identifier: e4 d2 5c Multi-Interface Cap: 00 Max Data Transfer Size: 131072 Admin Command Set Attributes ============================ Security Send/Receive: Not Supported Format NVM: Supported Firmware Activate/Download: Supported Abort Command Limit: 4 Async Event Request Limit: 4 Number of Firmware Slots: 1 Firmware Slot 1 Read-Only: No Per-Namespace SMART Log: No Error Log Page Entries: 64 Number of Power States: 1 NVM Command Set Attributes ========================== Submission Queue Entry Size Max: 64 Min: 64 Completion Queue Entry Size Max: 16 Min: 16 Number of Namespaces: 1 Compare Command: Not Supported Write Uncorrectable Command: Supported Dataset Management Command: Supported Volatile Write Cache: Not Present root@nvme:~ # nvmecontrol identify nvme0ns1 Size (in LBAs): 3907029168 (3726M) Capacity (in LBAs): 3907029168 (3726M) Utilization (in LBAs): 3907029168 (3726M) Thin Provisioning: Not Supported Number of LBA Formats: 7 Current LBA Format: LBA Format #00 LBA Format #00: Data Size: 512 Metadata Size: 0 LBA Format #01: Data Size: 512 Metadata Size: 8 LBA Format #02: Data Size: 512 Metadata Size: 16 LBA Format #03: Data Size: 4096 Metadata Size: 0 LBA Format #04: Data Size: 4096 Metadata Size: 8 LBA Format #05: Data Size: 4096 Metadata Size: 64 LBA Format #06: Data Size: 4096 Metadata Size: 128 root@nvme:~ # nvmecontrol identify nvme1 Controller Capabilities/Features ================================ Vendor ID: 8086 Subsystem Vendor ID: 8086 Serial Number: CVMD427400AY2P0JGN Model Number: INTEL SSDPE2ME020T4 Firmware Version: 8DV10110 Recommended Arb Burst: 0 IEEE OUI Identifier: e4 d2 5c Multi-Interface Cap: 00 Max Data Transfer Size: 131072 Admin Command Set Attributes ============================ Security Send/Receive: Not Supported Format NVM: Supported Firmware Activate/Download: Supported Abort Command Limit: 4 Async Event Request Limit: 4 Number of Firmware Slots: 1 Firmware Slot 1 Read-Only: No Per-Namespace SMART Log: No Error Log Page Entries: 64 Number of Power States: 1 NVM Command Set Attributes ========================== Submission Queue Entry Size Max: 64 Min: 64 Completion Queue Entry Size Max: 16 Min: 16 Number of Namespaces: 1 Compare Command: Not Supported Write Uncorrectable Command: Supported Dataset Management Command: Supported Volatile Write Cache: Not Present root@nvme:~ # nvmecontrol identify nvme1ns1 Size (in LBAs): 3907029168 (3726M) Capacity (in LBAs): 3907029168 (3726M) Utilization (in LBAs): 3907029168 (3726M) Thin Provisioning: Not Supported Number of LBA Formats: 7 Current LBA Format: LBA Format #00 LBA Format #00: Data Size: 512 Metadata Size: 0 LBA Format #01: Data Size: 512 Metadata Size: 8 LBA Format #02: Data Size: 512 Metadata Size: 16 LBA Format #03: Data Size: 4096 Metadata Size: 0 LBA Format #04: Data Size: 4096 Metadata Size: 8 LBA Format #05: Data Size: 4096 Metadata Size: 64 LBA Format #06: Data Size: 4096 Metadata Size: 128 root@nvme:~ # nvmecontrol logpage -p 1 nvme0 Error Information Log ===================== Entry 01 ========= Error count: 165 Submission queue ID: 2 Command ID: 125 Status: Phase tag: 0 Status code: 128 Status code type: 2 More: 1 DNR: 0 Error location: 0 LBA: 1953514256 Namespace ID: 1 Vendor specific info: 0 root@nvme:~ # nvmecontrol logpage -p 1 nvme1 Error Information Log ===================== Entry 01 ========= Error count: 50 Submission queue ID: 9 Command ID: 127 Status: Phase tag: 0 Status code: 194 Status code type: 0 More: 1 DNR: 0 Error location: 16384 LBA: 0 Namespace ID: 1 Vendor specific info: 0 root@nvme:~ # nvmecontrol logpage -p 2 nvme0 SMART/Health Information Log ============================ Critical Warning State: 0x00 Available spare: 0 Temperature: 0 Device reliability: 0 Read only: 0 Volatile memory backup: 0 Temperature: 296 K, 22.85 C, 73.13 F Available spare: 100 Available spare threshold: 10 Percentage used: 0 Data units (512 byte) read: 0x0000000000000000000000000cfcb16b Data units (512 byte) written: 0x0000000000000000000000004d0a48e9 Host read commands: 0x00000000000000000000000005c2bf55 Host write commands: 0x000000000000000000000000057e69a8 Controller busy time (minutes): 0x00000000000000000000000000000004 Power cycles: 0x00000000000000000000000000000139 Power on hours: 0x0000000000000000000000000000001d Unsafe shutdowns: 0x0000000000000000000000000000018a Media errors: 0x00000000000000000000000000000000 No. error info log entries: 0x00000000000000000000000000000024 root@nvme:~ # nvmecontrol logpage -p 2 nvme1 SMART/Health Information Log ============================ Critical Warning State: 0x00 Available spare: 0 Temperature: 0 Device reliability: 0 Read only: 0 Volatile memory backup: 0 Temperature: 295 K, 21.85 C, 71.33 F Available spare: 100 Available spare threshold: 10 Percentage used: 0 Data units (512 byte) read: 0x0000000000000000000000000968863e Data units (512 byte) written: 0x00000000000000000000000074092691 Host read commands: 0x00000000000000000000000004d40e0d Host write commands: 0x000000000000000000000000057c45f5 Controller busy time (minutes): 0x00000000000000000000000000000004 Power cycles: 0x000000000000000000000000000000a5 Power on hours: 0x0000000000000000000000000000000c Unsafe shutdowns: 0x00000000000000000000000000000101 Media errors: 0x00000000000000000000000000000000 No. error info log entries: 0x0000000000000000000000000000002f Best regards, Vintila Mihai Alexandru On 1/19/2015 6:22 PM, Jim Harris wrote: > > > On Sat, Jan 17, 2015 at 6:29 AM, Oliver Pinter > > > wrote: > > Added Jim to thread, as he is the nvme driver's author. > > > Thanks Oliver. > > Hi Mihai-Alexandru, > > Can you start by sending me the following? > > pciconf -lc nvme0 > pciconf -lc nvme1 > nvmecontrol identify nvme0 > nvmecontrol identify nvme0ns1 > nvmecontrol identify nvme1 > nvmecontrol identify nvme1ns1 > nvmecontrol logpage -p 1 nvme0 > nvmecontrol logpage -p 1 nvme1 > nvmecontrol logpage -p 2 nvme0 > nvmecontrol logpage -p 2 nvme1 > > I see mention of a FW update, but it wasn't clear if you have run > nvmecontrol perftest after the FW update? If not, could you run those > same nvmecontrol perftest runs again? > > Thanks, > > -Jim > > > > > On Sat, Jan 17, 2015 at 10:26 AM, Mihai-Alexandru Vintila > > wrote: > > Trim is already disabled as you can see in previous mail > > > > Best regards, > > Mihai Vintila > > > >> On 17 ian. 2015, at 01:24, Steven Hartland > > wrote: > >> > >> Any difference if you disable trim? > >> > >>> On 16/01/2015 23:07, Mihai Vintila wrote: > >>> I've remade the test with atime=off. Drive has 512b physical, > but I've created it with 4k gnop anyway. Results are similar with > atime > >>> Processor cache line size set to 32 bytes. > >>> File stride size set to 17 * record size. > >>> random random bk wd record stride > >>> KB reclen write rewrite read reread read > write re ad rewrite read fwrite frewrite fread freread > >>> 1048576 4 74427 0 101744 0 93529 > 47925 > >>> 1048576 8 39072 0 64693 0 61104 > 25452 > >>> > >>> I've also tried to increase vfs.zfs.vdev.aggregation_limit and > ended up with a crash (screenshot attached) > >>> > >>> I'm attaching zfs tunables: > >>> sysctl -a|grep vfs.zfs > >>> vfs.zfs.arc_max: 34359738368 > >>> vfs.zfs.arc_min: 4294967296 > >>> vfs.zfs.arc_average_blocksize: 8192 > >>> vfs.zfs.arc_meta_used: 5732232 > >>> vfs.zfs.arc_meta_limit: 8589934592 > >>> vfs.zfs.l2arc_write_max: 8388608 > >>> vfs.zfs.l2arc_write_boost: 8388608 > >>> vfs.zfs.l2arc_headroom: 2 > >>> vfs.zfs.l2arc_feed_secs: 1 > >>> vfs.zfs.l2arc_feed_min_ms: 200 > >>> vfs.zfs.l2arc_noprefetch: 1 > >>> vfs.zfs.l2arc_feed_again: 1 > >>> vfs.zfs.l2arc_norw: 1 > >>> vfs.zfs.anon_size: 32768 > >>> vfs.zfs.anon_metadata_lsize: 0 > >>> vfs.zfs.anon_data_lsize: 0 > >>> vfs.zfs.mru_size: 17841664 > >>> vfs.zfs.mru_metadata_lsize: 858624 > >>> vfs.zfs.mru_data_lsize: 13968384 > >>> vfs.zfs.mru_ghost_size: 0 > >>> vfs.zfs.mru_ghost_metadata_lsize: 0 > >>> vfs.zfs.mru_ghost_data_lsize: 0 > >>> vfs.zfs.mfu_size: 4574208 > >>> vfs.zfs.mfu_metadata_lsize: 465408 > >>> vfs.zfs.mfu_data_lsize: 4051456 > >>> vfs.zfs.mfu_ghost_size: 0 > >>> vfs.zfs.mfu_ghost_metadata_lsize: 0 > >>> vfs.zfs.mfu_ghost_data_lsize: 0 > >>> vfs.zfs.l2c_only_size: 0 > >>> vfs.zfs.dedup.prefetch: 1 > >>> vfs.zfs.nopwrite_enabled: 1 > >>> vfs.zfs.mdcomp_disable: 0 > >>> vfs.zfs.dirty_data_max: 4294967296 > >>> vfs.zfs.dirty_data_max_max: 4294967296 > >>> vfs.zfs.dirty_data_max_percent: 10 > >>> vfs.zfs.dirty_data_sync: 67108864 > >>> vfs.zfs.delay_min_dirty_percent: 60 > >>> vfs.zfs.delay_scale: 500000 > >>> vfs.zfs.prefetch_disable: 1 > >>> vfs.zfs.zfetch.max_streams: 8 > >>> vfs.zfs.zfetch.min_sec_reap: 2 > >>> vfs.zfs.zfetch.block_cap: 256 > >>> vfs.zfs.zfetch.array_rd_sz: 1048576 > >>> vfs.zfs.top_maxinflight: 32 > >>> vfs.zfs.resilver_delay: 2 > >>> vfs.zfs.scrub_delay: 4 > >>> vfs.zfs.scan_idle: 50 > >>> vfs.zfs.scan_min_time_ms: 1000 > >>> vfs.zfs.free_min_time_ms: 1000 > >>> vfs.zfs.resilver_min_time_ms: 3000 > >>> vfs.zfs.no_scrub_io: 0 > >>> vfs.zfs.no_scrub_prefetch: 0 > >>> vfs.zfs.metaslab.gang_bang: 131073 > >>> vfs.zfs.metaslab.fragmentation_threshold: 70 > >>> vfs.zfs.metaslab.debug_load: 0 > >>> vfs.zfs.metaslab.debug_unload: 0 > >>> vfs.zfs.metaslab.df_alloc_threshold: 131072 > >>> vfs.zfs.metaslab.df_free_pct: 4 > >>> vfs.zfs.metaslab.min_alloc_size: 10485760 > >>> vfs.zfs.metaslab.load_pct: 50 > >>> vfs.zfs.metaslab.unload_delay: 8 > >>> vfs.zfs.metaslab.preload_limit: 3 > >>> vfs.zfs.metaslab.preload_enabled: 1 > >>> vfs.zfs.metaslab.fragmentation_factor_enabled: 1 > >>> vfs.zfs.metaslab.lba_weighting_enabled: 1 > >>> vfs.zfs.metaslab.bias_enabled: 1 > >>> vfs.zfs.condense_pct: 200 > >>> vfs.zfs.mg_noalloc_threshold: 0 > >>> vfs.zfs.mg_fragmentation_threshold: 85 > >>> vfs.zfs.check_hostid: 1 > >>> vfs.zfs.spa_load_verify_maxinflight: 10000 > >>> vfs.zfs.spa_load_verify_metadata: 1 > >>> vfs.zfs.spa_load_verify_data: 1 > >>> vfs.zfs.recover: 0 > >>> vfs.zfs.deadman_synctime_ms: 1000000 > >>> vfs.zfs.deadman_checktime_ms: 5000 > >>> vfs.zfs.deadman_enabled: 1 > >>> vfs.zfs.spa_asize_inflation: 24 > >>> vfs.zfs.txg.timeout: 5 > >>> vfs.zfs.vdev.cache.max: 16384 > >>> vfs.zfs.vdev.cache.size: 0 > >>> vfs.zfs.vdev.cache.bshift: 16 > >>> vfs.zfs.vdev.trim_on_init: 0 > >>> vfs.zfs.vdev.mirror.rotating_inc: 0 > >>> vfs.zfs.vdev.mirror.rotating_seek_inc: 5 > >>> vfs.zfs.vdev.mirror.rotating_seek_offset: 1048576 > >>> vfs.zfs.vdev.mirror.non_rotating_inc: 0 > >>> vfs.zfs.vdev.mirror.non_rotating_seek_inc: 1 > >>> vfs.zfs.vdev.max_active: 1000 > >>> vfs.zfs.vdev.sync_read_min_active: 32 > >>> vfs.zfs.vdev.sync_read_max_active: 32 > >>> vfs.zfs.vdev.sync_write_min_active: 32 > >>> vfs.zfs.vdev.sync_write_max_active: 32 > >>> vfs.zfs.vdev.async_read_min_active: 32 > >>> vfs.zfs.vdev.async_read_max_active: 32 > >>> vfs.zfs.vdev.async_write_min_active: 32 > >>> vfs.zfs.vdev.async_write_max_active: 32 > >>> vfs.zfs.vdev.scrub_min_active: 1 > >>> vfs.zfs.vdev.scrub_max_active: 2 > >>> vfs.zfs.vdev.trim_min_active: 1 > >>> vfs.zfs.vdev.trim_max_active: 64 > >>> vfs.zfs.vdev.aggregation_limit: 131072 > >>> vfs.zfs.vdev.read_gap_limit: 32768 > >>> vfs.zfs.vdev.write_gap_limit: 4096 > >>> vfs.zfs.vdev.bio_flush_disable: 0 > >>> vfs.zfs.vdev.bio_delete_disable: 0 > >>> vfs.zfs.vdev.trim_max_bytes: 2147483648 > >>> vfs.zfs.vdev.trim_max_pending: 64 > >>> vfs.zfs.max_auto_ashift: 13 > >>> vfs.zfs.min_auto_ashift: 9 > >>> vfs.zfs.zil_replay_disable: 0 > >>> vfs.zfs.cache_flush_disable: 0 > >>> vfs.zfs.zio.use_uma: 1 > >>> vfs.zfs.zio.exclude_metadata: 0 > >>> vfs.zfs.sync_pass_deferred_free: 2 > >>> vfs.zfs.sync_pass_dont_compress: 5 > >>> vfs.zfs.sync_pass_rewrite: 2 > >>> vfs.zfs.snapshot_list_prefetch: 0 > >>> vfs.zfs.super_owner: 0 > >>> vfs.zfs.debug: 0 > >>> vfs.zfs.version.ioctl: 4 > >>> vfs.zfs.version.acl: 1 > >>> vfs.zfs.version.spa: 5000 > >>> vfs.zfs.version.zpl: 5 > >>> vfs.zfs.vol.mode: 1 > >>> vfs.zfs.trim.enabled: 0 > >>> vfs.zfs.trim.txg_delay: 32 > >>> vfs.zfs.trim.timeout: 30 > >>> vfs.zfs.trim.max_interval: 1 > >>> > >>> And nvm: > >>> ev.nvme.%parent: > >>> dev.nvme.0.%desc: Generic NVMe Device > >>> dev.nvme.0.%driver: nvme > >>> dev.nvme.0.%location: slot=0 function=0 > handle=\_SB_.PCI0.BR3A.D08A > >>> dev.nvme.0.%pnpinfo: vendor=0x8086 device=0x0953 > subvendor=0x8086 subdevice=0x370a class=0x010802 > >>> dev.nvme.0.%parent: pci4 > >>> dev.nvme.0.int_coal_time: 0 > >>> dev.nvme.0.int_coal_threshold: 0 > >>> dev.nvme.0.timeout_period: 30 > >>> dev.nvme.0.num_cmds: 811857 > >>> dev.nvme.0.num_intr_handler_calls: 485242 > >>> dev.nvme.0.reset_stats: 0 > >>> dev.nvme.0.adminq.num_entries: 128 > >>> dev.nvme.0.adminq.num_trackers: 16 > >>> dev.nvme.0.adminq.sq_head: 12 > >>> dev.nvme.0.adminq.sq_tail: 12 > >>> dev.nvme.0.adminq.cq_head: 8 > >>> dev.nvme.0.adminq.num_cmds: 12 > >>> dev.nvme.0.adminq.num_intr_handler_calls: 7 > >>> dev.nvme.0.adminq.dump_debug: 0 > >>> dev.nvme.0.ioq0.num_entries: 256 > >>> dev.nvme.0.ioq0.num_trackers: 128 > >>> dev.nvme.0.ioq0.sq_head: 69 > >>> dev.nvme.0.ioq0.sq_tail: 69 > >>> dev.nvme.0.ioq0.cq_head: 69 > >>> dev.nvme.0.ioq0.num_cmds: 811845 > >>> dev.nvme.0.ioq0.num_intr_handler_calls: 485235 > >>> dev.nvme.0.ioq0.dump_debug: 0 > >>> dev.nvme.1.%desc: Generic NVMe Device > >>> dev.nvme.1.%driver: nvme > >>> dev.nvme.1.%location: slot=0 function=0 > handle=\_SB_.PCI0.BR3B.H000 > >>> dev.nvme.1.%pnpinfo: vendor=0x8086 device=0x0953 > subvendor=0x8086 subdevice=0x370a class=0x010802 > >>> dev.nvme.1.%parent: pci5 > >>> dev.nvme.1.int_coal_time: 0 > >>> dev.nvme.1.int_coal_threshold: 0 > >>> dev.nvme.1.timeout_period: 30 > >>> dev.nvme.1.num_cmds: 167 > >>> dev.nvme.1.num_intr_handler_calls: 163 > >>> dev.nvme.1.reset_stats: 0 > >>> dev.nvme.1.adminq.num_entries: 128 > >>> dev.nvme.1.adminq.num_trackers: 16 > >>> dev.nvme.1.adminq.sq_head: 12 > >>> dev.nvme.1.adminq.sq_tail: 12 > >>> dev.nvme.1.adminq.cq_head: 8 > >>> dev.nvme.1.adminq.num_cmds: 12 > >>> dev.nvme.1.adminq.num_intr_handler_calls: 8 > >>> dev.nvme.1.adminq.dump_debug: 0 > >>> dev.nvme.1.ioq0.num_entries: 256 > >>> dev.nvme.1.ioq0.num_trackers: 128 > >>> dev.nvme.1.ioq0.sq_head: 155 > >>> dev.nvme.1.ioq0.sq_tail: 155 > >>> dev.nvme.1.ioq0.cq_head: 155 > >>> dev.nvme.1.ioq0.num_cmds: 155 > >>> dev.nvme.1.ioq0.num_intr_handler_calls: 155 > >>> dev.nvme.1.ioq0.dump_debug: 0 > >>> > >>> Best regards, > >>> Vintila Mihai Alexandru > >>> > >>>> On 1/17/2015 12:13 AM, Barney Wolff wrote: > >>>> I suspect Linux defaults to noatime - at least it does on my > rpi. I > >>>> believe the FreeBSD default is the other way. That may > explain some > >>>> of the difference. > >>>> > >>>> Also, did you use gnop to force the zpool to start on a 4k > boundary? > >>>> If not, and the zpool happens to be offset, that's another > big hit. > >>>> Same for ufs, especially if the disk has logical sectors of > 512 but > >>>> physical of 4096. One can complain that FreeBSD should > prevent, or > >>>> at least warn about, this sort of foot-shooting. > >>>> > >>>>> On Fri, Jan 16, 2015 at 10:21:07PM +0200, Mihai-Alexandru > Vintila wrote: > >>>>> @Barney Wolff it's a new pool with only changes > recordsize=4k and > >>>>> compression=lz4 . On linux test is on ext4 with default > values. Penalty is > >>>>> pretty high. Also there is a read penalty for read as well > between ufs and > >>>>> zfs. Even on nvmecontrol perftest you can see the read > penalty it's not > >>>>> normal to have same result for both write and read > >>> > >>> _______________________________________________ > >>> freebsd-stable@freebsd.org > mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >>> To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org > " > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org > mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org > " > > _______________________________________________ > > freebsd-stable@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org > " > > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 11:46:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8295717C; Tue, 20 Jan 2015 11:46:11 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 10C0D14E; Tue, 20 Jan 2015 11:46:10 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 7C2AF16A40B; Tue, 20 Jan 2015 12:45:57 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4UoEo7xHbEK; Tue, 20 Jan 2015 12:45:35 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e] (unknown [IPv6:2001:4cb8:3:1:6455:2a07:d7dc:ef6e]) by smtp.digiware.nl (Postfix) with ESMTP id 0DD9F16A405; Tue, 20 Jan 2015 12:45:35 +0100 (CET) Message-ID: <54BE3FDC.9030904@digiware.nl> Date: Tue, 20 Jan 2015 12:45:32 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: d@delphij.net, Garrett Cooper , Brandon Allbery Subject: Re: old bug: mount_nfs path/name is limited to 88 chars References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> <54BDA9DD.5040608@delphij.net> In-Reply-To: <54BDA9DD.5040608@delphij.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mexas@bris.ac.uk, rmacklem@uoguelph.ca, freebsd-stable , freebsd current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 11:46:11 -0000 On 2015-01-20 2:05, Xin Li wrote: >> Doing it in 11 makes sense since there is a compat layer for 10 >> now… if I knew all of the steps I would happily do them as annoys >> me from time to time as well with the path length issue. > > Compat layer may break applications in other funny ways and we > probably have to return e.g. ENAMETOOLONG for legacy applications if > the names are too long to fit into the buffer, but I don't see any > easy solution either: I wish we have bumped it in 2003 when the struct > receives its first big revamp by bumping all statistic fields to 64-bit. On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > > Especially with ZFS, I find I have a lot more mounts now, under longer > and longer path names, and then I have > .zfs/snapshots/snapshotnamehere/path/to/file > > etc. > > Definitely a +1 for "this is something we need for 11" +1 Well to be honest: Things are already broken for me ATM. I do have paths that are too long, and tools trip over it. Things like building the locate database just don't have everything. Which is a pain, especially for finding things fast in backups of ZFS, where the path is even more convoluted that what Allan suggests So whether being bitten by the cat of the dog: it still hurts. Perhaps it is an intermediate solution to add new settings which are going to be used for userspace programs, like USER_MNAMELEN and USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves systemcalls. But then a lot of the other tool stuff would just function. --WjW From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 13:38:59 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31F782A0 for ; Tue, 20 Jan 2015 13:38:59 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05CE6EFF for ; Tue, 20 Jan 2015 13:38:58 +0000 (UTC) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 9ADD8340; Tue, 20 Jan 2015 08:30:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Keep -STABLE updated! From: Paul Mather In-Reply-To: Date: Tue, 20 Jan 2015 08:30:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54BDB10D.4000603@gmail.com> To: Brandon Allbery X-Mailer: Apple Mail (2.1878.6) Cc: Yass Amed , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 13:38:59 -0000 On Jan 19, 2015, at 8:54 PM, Brandon Allbery = wrote: > On Mon, Jan 19, 2015 at 8:36 PM, Yass Amed = wrote: >=20 >> I'd like to clarify a certain info regarding FreeBSD -STABLE. >> Currently, I am running 10-STABLE and need to know if it is mandatory = to >> rebuild kernel and world every time I sync the source using "# svn up >> /usr/src"? >>=20 >=20 > A running FreeBSD system never needs /usr/src. But if you are running > STABLE (or CURRENT), sometimes you will want to look at the source to > something in the running system (usually because it just did something > unexpected...) and so it's helpful to have /usr/src match the running > system. So, not necessary but often a good idea. It's correct that, once built and running, a FreeBSD system never needs = /usr/src. However, a -STABLE or -CURRENT FreeBSD system will need = /usr/src to apply any security advisories or errata (as happened = recently, re: OpenSSL). Unlike -RELEASE branches, -STABLE and -CURRENT = don't get updates via freebsd-update. Also, it's handy to have /usr/src and rebuild if ever there is a feature = MFC'd that you'd like to have available on your -STABLE system (e.g., = the bhyve support for AMD processors that was MFC'd not so long ago). = That's usually the main reason for running -STABLE, actually. Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 13:57:08 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD9B56C4 for ; Tue, 20 Jan 2015 13:57:08 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 768E6183 for ; Tue, 20 Jan 2015 13:57:08 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 341B520902 for ; Tue, 20 Jan 2015 08:57:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 20 Jan 2015 08:57:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= x-sasl-enc:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=4l5jEYbGy8ZUw1iDn9QvcuRI6Ag=; b=kDXVE5oyl7XPcg4CK5 u8Ee2wyGnRMJPnFvjXqUaHuj4LApXenvOUDKku819cn1T41T7JkPe1JIQZ3NbjNJ 3TyaMYE+TD9Za1ml/CZEW0D8Kt0CeSCbGFWX0vVrIDyyQrfm/ei8dozZSUi8ErEw +921wpzFo7lw61OLxf2aa2W7g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:date:from:to:subject :message-id:in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=4l5jEYbGy8ZUw1iDn9Qvcu RI6Ag=; b=QHigMh/mGDmb/kIlqB/G3WELLF8E22os1Kjgv0LZDOKkbL4A1mfTRO +vA5Az6/dFTcQUt5s3tUwmYok+tyNoAU4MU4B6zL/ksaRBv/f6K8QasFenFX4E52 4P5BqEjbQVkTy1+bsryLAKUuK//HT0BPiFmYEmHKz6LRlUJlM9FzU= X-Sasl-enc: IR4ohm+RGhm/PYRrOk4lfGhKScYnJ9YXztpAL2oNWUjP 1421762226 Received: from alonso-desktop.sodgeit.de (unknown [46.237.203.179]) by mail.messagingengine.com (Postfix) with ESMTPA id BE9146800FD for ; Tue, 20 Jan 2015 08:57:06 -0500 (EST) Date: Tue, 20 Jan 2015 14:57:04 +0100 From: "Schaich, Alonso" To: freebsd-stable@freebsd.org Subject: Re: Keep -STABLE updated! Message-Id: <20150120145704.9882c30b83455d2dff9ed98a@fastmail.fm> In-Reply-To: References: <54BDB10D.4000603@gmail.com> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) 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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 13:57:08 -0000 On Tue, 20 Jan 2015 08:30:16 -0500 Paul Mather wrote: > On Jan 19, 2015, at 8:54 PM, Brandon Allbery wrote: > > > On Mon, Jan 19, 2015 at 8:36 PM, Yass Amed wrote: > > > >> I'd like to clarify a certain info regarding FreeBSD -STABLE. > >> Currently, I am running 10-STABLE and need to know if it is mandatory to > >> rebuild kernel and world every time I sync the source using "# svn up > >> /usr/src"? > >> > > > > A running FreeBSD system never needs /usr/src. But if you are running > > STABLE (or CURRENT), sometimes you will want to look at the source to > > something in the running system (usually because it just did something > > unexpected...) and so it's helpful to have /usr/src match the running > > system. So, not necessary but often a good idea. > > > It's correct that, once built and running, a FreeBSD system never needs /usr/src. However, a -STABLE or -CURRENT FreeBSD system will need /usr/src to apply any security advisories or errata (as happened recently, re: OpenSSL). Unlike -RELEASE branches, -STABLE and -CURRENT don't get updates via freebsd-update. > > Also, it's handy to have /usr/src and rebuild if ever there is a feature MFC'd that you'd like to have available on your -STABLE system (e.g., the bhyve support for AMD processors that was MFC'd not so long ago). That's usually the main reason for running -STABLE, actually. > > Cheers, > > Paul. Also, nvidia, VirtualBox and some other packages contains kernel modules, which require a kernel source code and your setup might be affected by more updates of those ports than the system is affected by security erratas. Alonso From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 13:58:36 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFCD77D9 for ; Tue, 20 Jan 2015 13:58:36 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 6B1301AE for ; Tue, 20 Jan 2015 13:58:36 +0000 (UTC) Received: from fortune.joker.local (180-198-138-192.nagoya1.commufa.jp [180.198.138.192]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id t0KDGAx1010303 for ; Tue, 20 Jan 2015 22:16:10 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 20 Jan 2015 22:16:09 +0900 From: Tomoaki AOKI To: freebsd-stable@freebsd.org Subject: Re: Keep -STABLE updated! Message-Id: <20150120221609.8a039aaaa29c7d3e7a719550@dec.sakura.ne.jp> In-Reply-To: <54BDB10D.4000603@gmail.com> References: <54BDB10D.4000603@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) 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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 13:58:36 -0000 If you're using something require kernel src (such as nvidia-driver), you need keeping sync with running kernel and its src. Just as Bigby James noted, you should update src only when you want to update running FreeBSD }(kernel / userland). Don't forget to rebuild ALL softwares requiring kernel src. If you want src of different revision, I recommend to keep it somewhere other than /usr/src. On Mon, 19 Jan 2015 19:36:13 -0600 Yass Amed wrote: > Hello, > > I'd like to clarify a certain info regarding FreeBSD -STABLE. > Currently, I am running 10-STABLE and need to know if it is mandatory to > rebuild kernel and world every time I sync the source using "# svn up > /usr/src"? > > Thank You, > > @youngunix > > -- > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Tomoaki AOKI junchoon@dec.sakura.ne.jp From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 15:40:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD51D25D for ; Tue, 20 Jan 2015 15:40:04 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 3F8D2F32 for ; Tue, 20 Jan 2015 15:40:04 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id em10so6439732wid.1 for ; Tue, 20 Jan 2015 07:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=G53p8M/vdvfNVFQB1llrReNC++wIoBLIjhIJbbdPykc=; b=aXzGJlz7KMQY33xdDKvH1AOSAiTYwbNX5SZ9fstylPvmRHBWxELhBCTKCfI6Pf67bI d2fooflQDVI/oKjTGvhSr9VSxtRQ8Y5NnB/918+WV5c0sekpNTkuhsFknes5dT5hm3UO u34uQDy04kbzhgWahAMMlPgxqMLRuLBhzYzetTihMJ5m3VMeaNC+u57fMmJWoc8QJisW /fk+o8BWlkfAj5TpxCBAD4uqmyWT4AjumxbnvpLiExs01aMwcyotfgfKgJNUm7EOV7PI BozLHslpHacTA7goZu1ZBIbz74ccYPZGGZ0TQ8KzNCwY7LaYnC1nzKswzb8YqdXEdT7P +E1g== X-Received: by 10.194.10.68 with SMTP id g4mr14621077wjb.5.1421768402299; Tue, 20 Jan 2015 07:40:02 -0800 (PST) Received: from [192.168.1.145] (static-228-200-167-83.thenetworkfactory.nl. [83.167.200.228]) by mx.google.com with ESMTPSA id jp3sm3493425wid.9.2015.01.20.07.40.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 07:40:01 -0800 (PST) Message-ID: <54BE76CC.5020901@gmail.com> Date: Tue, 20 Jan 2015 16:39:56 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: installworld fails Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:40:04 -0000 Hello all. I use to do a weekly buildworld on my 10 stable system, today was no exception. But during installworld I get the following error. mtree -deU -f /usr/src/include/../etc/mtree/BSD.include.dist -p /usr/include /lib/libthr.so.3: Undefined symbol "__set_error_selector" *** Error code 1 Stop. make[4]: stopped in /usr/src/include *** 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 svn info gives me the following. Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 277418 Node Kind: directory Schedule: normal Last Changed Author: hselasky Last Changed Rev: 277409 Last Changed Date: 2015-01-20 06:12:30 +0100 (Tue, 20 Jan 2015) uname -a FreeBSD beasty.schavemaker2.local 10.1-STABLE FreeBSD 10.1-STABLE #0 r277055: Mon Jan 12 11:05:33 CET 2015 root@beasty.schavemaker2.local:/usr/obj/usr/src/sys/KRNL amd64 my /etc/src.conf WITHOUT_BLUETOOTH= yes WITHOUT_CALENDAR= yes WITHOUT_DICT= yes WITHOUT_GAMES= yes WITHOUT_HTML= yes WITHOUT_I4B= yes WITHOUT_IPFILTER= yes WITHOUT_IPX= yes WITHOUT_LPR= yes WITHOUT_PROFILE= yes WITHOUT_SENDMAIL= yes WITHOUT_SHAREDOCS= yes WITHOUT_WIRELESS= yes # SSH None cipher WITH_OPENSSH_NONE_CIPHER= yes WITHOUT_LIB32= yes /etc/make.conf CPUTYPE?=core2 KERNCONF=KRNL BATCH_DELETE_OLD_FILES= yes WITH_PKGNG=yes WANT_SASL=yes CUPS_OVERWRITE_BASE=yes MAKE_JOBS_UNSAFE=yes Can somebody tell me what I can do to resolv this issue. This same error happened to me when I tried to update a 10.1 stable machine to HEAD. I did not payed to much attention because I thought it was a to big step so I installed HEAD from cd. regards Johan From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 15:44:14 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61FFB3D8 for ; Tue, 20 Jan 2015 15:44:14 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 E874E73 for ; Tue, 20 Jan 2015 15:44:13 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id fb4so18571507wid.2 for ; Tue, 20 Jan 2015 07:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=3oROVd0vkFgx2oCMqEhf4ZMwlb3VY0hBmvcCf3Oig+Y=; b=uokwD3F/EX+ktK4y5Mrmeeh3VysFOfX9abpmheb/Vh1JZGb1GYDIB/P4yeT6JSI4ZA 6VaBCCla7aVt1MNwJCLoWS4/p5tJ/2Hus9Ru1QvmH8YEXfVKys7TymBMmlkwKYVbJgX9 wd2APqxpX3O00wduzG3jiBYK0pc64Ds5m7rntPI7OoL4ylGeEce5SB0yv9RPnjzdVzxF 7xz9hMdeCCTulVzzMvg+0TBbxrfVL1KFQZXjBPkH42T/WVDT4QIxZoZcwTGZSjjAkcjP 6DlZCX2YC7C8uGhHPCCx8/BzosgaXHGroYvwHOCsMYvsHsXhPVOwCYe69yRbO0eoqscG B69A== X-Received: by 10.180.216.36 with SMTP id on4mr46862503wic.27.1421768651969; Tue, 20 Jan 2015 07:44:11 -0800 (PST) Received: from MARC-THINKPAD.queenland (AOrleans-656-1-23-170.w90-20.abo.wanadoo.fr. [90.20.238.170]) by mx.google.com with ESMTPSA id s9sm3506293wiz.12.2015.01.20.07.44.10 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 20 Jan 2015 07:44:11 -0800 (PST) Date: Tue, 20 Jan 2015 16:44:09 +0100 From: =?UTF-8?B?TcOkcms=?= Owen To: freebsd-stable@freebsd.org Subject: NFS "mount system call failed" Message-ID: <20150120164409.49403c6e@MARC-THINKPAD.queenland> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) 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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:44:14 -0000 Hi everyone, I'm using FreeBSD 10.1 to share a ZFS pool (mounted at /media/storage) through NFS to Linux clients (Debian 7). I don't seem to get any errors when the nfs services start on FreeBSD but I can't mount the shares on the clients, all I get is: mount.nfs4: mount system call failed (Tried as NFSv3 and NFSv4, same result). I'm really frustrated here since It worked barely an hour ago and I have absolutely no idea why I getting this error now. Anyway, here are my /etc/rc.conf and /etc/exports files from the server: /etc/rc.conf ... ## ZFS zfs_enable="YES" ## NFSv4 Server nfs_server_enable="YES" nfsv4_server_enable="YES" rpcbind_enable="YES" mountd_enable="YES" mountd_flags="-r" #rpc_lockd_enable="YES" #rpc_statd_enable="YES" /etc/exports (I tried both as NFSv3 and NFSv4, here are the two options) -NFSv3: /media/storage/data -ro -alldirs -network 192.168.1.0 -mask 255.255.255.0 -NFSv4: V4:/media/storage -network 192.168.1.0 -mask 255.255.255.0 /media/storage/data -ro -alldirs -network 192.168.1.0 -mask 255.255.255.0 On the clients I use the following commands to try to mount the share: - NFSv3: mount -t nfs -o nolock server-ip:/media/storage/data /mnt/tmp - NFSv4: mount -t nfs4 server-ip:/data /mnt/tmp Thank you for reading and I hope that someone will be able to help me. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 15:54:11 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91FFB824 for ; Tue, 20 Jan 2015 15:54:11 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 202891D8 for ; Tue, 20 Jan 2015 15:54:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0KFs6TJ088446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 17:54:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0KFs6TJ088446 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0KFs6kE088445; Tue, 20 Jan 2015 17:54:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Jan 2015 17:54:06 +0200 From: Konstantin Belousov To: Johan Hendriks Subject: Re: installworld fails Message-ID: <20150120155406.GG42409@kib.kiev.ua> References: <54BE76CC.5020901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE76CC.5020901@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 15:54:11 -0000 On Tue, Jan 20, 2015 at 04:39:56PM +0100, Johan Hendriks wrote: > Hello all. > > I use to do a weekly buildworld on my 10 stable system, today was no > exception. > But during installworld I get the following error. > > mtree -deU -f /usr/src/include/../etc/mtree/BSD.include.dist -p > /usr/include > /lib/libthr.so.3: Undefined symbol "__set_error_selector" > *** Error code 1 Your installed libc is older than your libthr. I have no idea how you get into this state. Also, the ld-elf.so.1 error message about missed symbol from libthr.so cannot come from an attempt to run mtree, since mtree does not link to libthr.so. I cannot help you with your issues, but to get working libc/libthr, if you successfully built the world, do cd /usr/src/lib/libc && make install Depending on the amount of brokeness, you might also need to do cd /usr/src/libexec/rtld-elf && make install From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 16:01:41 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF0C4A36 for ; Tue, 20 Jan 2015 16:01:41 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C4A3254 for ; Tue, 20 Jan 2015 16:01:41 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x3so4949915wes.5 for ; Tue, 20 Jan 2015 08:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UF50EehqSb3yXtJpYayfEuqY+/ScbKPAt72Ik+3r0T4=; b=Pns2wCU6cYw5dzud+29700JCyhKSOASjhc1mXh4U/hJNr7PINWqUeVxOKxlIZgR7im 2pEU3Hp1YxTTbixUnqwUM4uzxz0yyoUhaADrvGPj4zxCOUvnRm6+5t22mfjkfdtQoeuK AuqzDqR4wyaUwt6WXkU93DTyNVxyQbBE+qsIFvzldMpHuaqgYDQjll7BgyK+UxAjiq89 dzMDklq/vQVzBjg7eIx6jNWTrQlCHKtIWKUAUomZgDm9Vlqfq1G9fnCRFVwGQPaywWcr tW9Ywl4qWbj0yOTtXD+oJtddKrfG2ydvL0X5POHPJO/UiVh1mpgvhxJU7jT2DCR+p+2F 5BEw== X-Received: by 10.194.24.195 with SMTP id w3mr70429302wjf.135.1421769699924; Tue, 20 Jan 2015 08:01:39 -0800 (PST) Received: from [192.168.1.145] (static-228-200-167-83.thenetworkfactory.nl. [83.167.200.228]) by mx.google.com with ESMTPSA id bb2sm10108164wjc.43.2015.01.20.08.01.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jan 2015 08:01:39 -0800 (PST) Message-ID: <54BE7BE3.8020207@gmail.com> Date: Tue, 20 Jan 2015 17:01:39 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: installworld fails References: <54BE76CC.5020901@gmail.com> <20150120155406.GG42409@kib.kiev.ua> In-Reply-To: <20150120155406.GG42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:01:42 -0000 Thanks, Your solution did work, thank you very much. I do the same routine as always. The buildworld and build kernel went fine. cd /usr/src/ make cleanworld make buildworld make kernel mergemaster -p make installworld mergemaster -iU Your solution did work, thank you very much. Op 20-01-15 om 16:54 schreef Konstantin Belousov: > On Tue, Jan 20, 2015 at 04:39:56PM +0100, Johan Hendriks wrote: >> Hello all. >> >> I use to do a weekly buildworld on my 10 stable system, today was no >> exception. >> But during installworld I get the following error. >> >> mtree -deU -f /usr/src/include/../etc/mtree/BSD.include.dist -p >> /usr/include >> /lib/libthr.so.3: Undefined symbol "__set_error_selector" >> *** Error code 1 > Your installed libc is older than your libthr. I have no idea how you > get into this state. Also, the ld-elf.so.1 error message about missed > symbol from libthr.so cannot come from an attempt to run mtree, since > mtree does not link to libthr.so. > > I cannot help you with your issues, but to get working libc/libthr, if > you successfully built the world, do > cd /usr/src/lib/libc && make install > Depending on the amount of brokeness, you might also need to do > cd /usr/src/libexec/rtld-elf && make install From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 16:28:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 184AF5A6 for ; Tue, 20 Jan 2015 16:28:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9997C822 for ; Tue, 20 Jan 2015 16:28:53 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0KGSijs096258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2015 18:28:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0KGSijs096258 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0KGSiRZ096257; Tue, 20 Jan 2015 18:28:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Jan 2015 18:28:44 +0200 From: Konstantin Belousov To: Johan Hendriks Subject: Re: installworld fails Message-ID: <20150120162844.GH42409@kib.kiev.ua> References: <54BE76CC.5020901@gmail.com> <20150120155406.GG42409@kib.kiev.ua> <54BE7BE3.8020207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE7BE3.8020207@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:28:54 -0000 On Tue, Jan 20, 2015 at 05:01:39PM +0100, Johan Hendriks wrote: > Thanks, Your solution did work, thank you very much. > > > I do the same routine as always. > The buildworld and build kernel went fine. > > cd /usr/src/ > make cleanworld > make buildworld > make kernel > mergemaster -p > make installworld > mergemaster -iU I doubt it, really. Installation procedure installs libc before libthr. Your libc was built from sources before r277317, while libthr was at r277317 or after. Also, as I said, the mere complain about libthr during installworld is a red mark, since no install-time tools are multithreaded, AFAIK. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 20:47:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E701F913 for ; Tue, 20 Jan 2015 20:47:21 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1D8F9C8 for ; Tue, 20 Jan 2015 20:47:21 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id y10so5615885pdj.7 for ; Tue, 20 Jan 2015 12:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=f4FcfUa7BP+BR8FJvStOt1Z5JPxsHRJJK3CBqms0wmU=; b=EDJtBAgHJwTlaMbtU21BJ4iyd6RYPM+K1zg/WLSfbSaT1JaOvZjvrN0nLQZnfOwnp2 sAJ6n3HLmX0AEooJhM6zKFKGS9qG4zVsrwu+p+0ZCqevdoxNb16v3GR1tBcdQflmeLuY iMKMVij5cD2m/k0eKBwxGC5YbpDiVYnYdWoMcJd77h5dodgNinsJRJzrUywa99yZJ0lA bP+/1EukX+Fz1aDjyXCBn91hY6gepPPIVZ8ZBsQIf1Jnj96QloR34quPlZgRKTQldHLY 1zDPDi/2zi+GYwCoHZr2h53nZsbqHTL85kDuwZEcQL6DyAcx/lMCay3dramb0VPfPKg7 XGkA== MIME-Version: 1.0 X-Received: by 10.68.163.196 with SMTP id yk4mr56441784pbb.143.1421786841372; Tue, 20 Jan 2015 12:47:21 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.66.253.37 with HTTP; Tue, 20 Jan 2015 12:47:21 -0800 (PST) In-Reply-To: <20150120162844.GH42409@kib.kiev.ua> References: <54BE76CC.5020901@gmail.com> <20150120155406.GG42409@kib.kiev.ua> <54BE7BE3.8020207@gmail.com> <20150120162844.GH42409@kib.kiev.ua> Date: Tue, 20 Jan 2015 12:47:21 -0800 X-Google-Sender-Auth: 7znIOqueA8MRIkIicWdFVZcITKY Message-ID: Subject: Re: installworld fails From: Kevin Oberman To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Johan Hendriks , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 20:47:22 -0000 On Tue, Jan 20, 2015 at 8:28 AM, Konstantin Belousov wrote: > On Tue, Jan 20, 2015 at 05:01:39PM +0100, Johan Hendriks wrote: > > Thanks, Your solution did work, thank you very much. > > > > > > I do the same routine as always. > > The buildworld and build kernel went fine. > > > > cd /usr/src/ > > make cleanworld > > make buildworld > > make kernel > > mergemaster -p > > make installworld > > mergemaster -iU > I doubt it, really. Installation procedure installs libc before libthr. > Your libc was built from sources before r277317, while libthr was at > r277317 or after. > > Also, as I said, the mere complain about libthr during installworld is > a red mark, since no install-time tools are multithreaded, AFAIK. > Also, a minor, but occasionally significant deviation from the recommended procedure is that you need to do "mergemaster -p" before the "make kernel". If you check the man page on mergemaster you will note that it is intended to be run even before buildworld, but it's pretty unlikely that a buildworld will fail because of it. There was one update back four or five years ago that depended on a user or group to do the kernel and lots of reports of a broken kernel install came in. Rare, but very annoying. Also, I prefer F to U and use -P as an aded safety factor. As was pointed out to me a wile back, -U has an inherent race that can bite you in a couple of ways. Again, unlikely to bite you, but not impossible.There is a warning in the man page for mergemaster.. Also, a reboot to single user between "make kernel" and "make installworld" is a really, really good idea. If you installworld and your kernel is bad (and this happens once in a while), you have a real mess on your hands. With remote systems with no OOB access to the console skipping the reboot this is almost a necessity, but make sure that you have done an identical upgrade on a local system before trying it Finally, buildworld does a cleanworld, so a separate "make cleanworld" is a waste of time. There are cases when the clean (in either way) is inadequate, so I do "rm -r /usr/obj/*" and add "-DNO_CLEAN" to both buildworld and kernel (or buildkernel). If you have multiple CPUs, -jN (where 'N' is a bit greater than the number of cores) is a big time saver in buildworld and buidlkernel. Yes, this stuff is a bit paranoid, but costs little, so I recommend it. Several years of engineering a critical high performance (currently up to 340 Gbps) international network makes me very conservative. Making a mistake that cuts off the data flow from the Large Hadron Collider in Europe to the US is a really bad idea. ;-) At 100 Gbps, it only takes a very short hit to blow away a .9999 reliability and my organization wanted 5 9s. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jan 20 23:34:37 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5922B887 for ; Tue, 20 Jan 2015 23:34:37 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1D982E41 for ; Tue, 20 Jan 2015 23:34:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EALXlvlSDaFve/2dsb2JhbABbg1hYBIMDwyYKhSdKAoFhAQEBAQF9hAwBAQEDAQEBASAEJyALBRYYAgINGQIpAQkmBggHBAEcBIgDCA28DZRfAQEBAQEBBAEBAQEBAQEBGoEhjgcBAQYVNAeCaIFBBYl1iCuDMoMyNoUGi1oihAwgMQd9CBcifgEBAQ X-IronPort-AV: E=Sophos;i="5.09,437,1418101200"; d="scan'208";a="185151118" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 20 Jan 2015 18:34:15 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9CC37AEA34; Tue, 20 Jan 2015 18:34:15 -0500 (EST) Date: Tue, 20 Jan 2015 18:34:15 -0500 (EST) From: Rick Macklem To: =?utf-8?B?TcOkcms=?= Owen Message-ID: <2096124637.17646377.1421796855627.JavaMail.root@uoguelph.ca> In-Reply-To: <20150120164409.49403c6e@MARC-THINKPAD.queenland> Subject: Re: NFS "mount system call failed" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 23:34:37 -0000 Mark Owen wrote: > Hi everyone, > > I'm using FreeBSD 10.1 to share a ZFS pool (mounted at > /media/storage) > through NFS to Linux clients (Debian 7). I don't seem to get any > errors > when the nfs services start on FreeBSD but I can't mount the shares > on > the clients, all I get is: mount.nfs4: mount system call failed > (Tried > as NFSv3 and NFSv4, same result). > > I'm really frustrated here since It worked barely an hour ago and I > have absolutely no idea why I getting this error now. > Well, here's a couple of comments: 1 - Look in /var/log/messages for any errors generated by mountd or nfsd on the FreeBSD server. 2 - Make sure the daemons (mountd and nfsd) are running, via "ps axHl". 3 - It appears you have exported the file system "read-only", but are trying to mount it read/write. (I'm not sure this would produce an error at mount time or just if/when the client tries to write to the file server?) 4 - If nothing above helps, use "tcpdump -s 0 -w xxx.pcap host " on the server to capture packets during a mount attempt and then look at xxx.pcap in wireshark (since it understands NFS). This will show you what interaction is going on between client<->server and may give you the hint as to what is broken. rick > Anyway, here are my /etc/rc.conf and /etc/exports files from the > server: > > /etc/rc.conf > ... > ## ZFS > zfs_enable="YES" > ## NFSv4 Server > nfs_server_enable="YES" > nfsv4_server_enable="YES" > rpcbind_enable="YES" > mountd_enable="YES" > mountd_flags="-r" > #rpc_lockd_enable="YES" > #rpc_statd_enable="YES" > > /etc/exports (I tried both as NFSv3 and NFSv4, here are the two > options) > -NFSv3: > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > 255.255.255.0 > > -NFSv4: > V4:/media/storage -network 192.168.1.0 -mask 255.255.255.0 > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > 255.255.255.0 > > > On the clients I use the following commands to try to mount the > share: > - NFSv3: mount -t nfs -o nolock server-ip:/media/storage/data > /mnt/tmp > - NFSv4: mount -t nfs4 server-ip:/data /mnt/tmp > > Thank you for reading and I hope that someone will be able to help > me. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 21 10:28:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA23A75A for ; Wed, 21 Jan 2015 10:28:00 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D751A45 for ; Wed, 21 Jan 2015 10:28:00 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t0LARuQ3099244; Wed, 21 Jan 2015 11:27:56 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 51C923E2; Wed, 21 Jan 2015 11:27:56 +0100 (CET) Message-ID: <54BF7F2B.2070600@omnilan.de> Date: Wed, 21 Jan 2015 11:27:55 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?M=E4rk_Owen?= Subject: Re: NFS "mount system call failed" References: <20150120164409.49403c6e@MARC-THINKPAD.queenland> In-Reply-To: <20150120164409.49403c6e@MARC-THINKPAD.queenland> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4BF3F93106D0AD2C6CEE5DE4" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 21 Jan 2015 11:27:56 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:28:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4BF3F93106D0AD2C6CEE5DE4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich M=E4rk Owen's Nachricht vom 20.01.2015 16:44 (localtime): > Hi everyone, > > I'm using FreeBSD 10.1 to share a ZFS pool (mounted at /media/storage) > through NFS to Linux clients (Debian 7). I don't seem to get any errors= > when the nfs services start on FreeBSD but I can't mount the shares on > the clients, all I get is: mount.nfs4: mount system call failed (Tried > as NFSv3 and NFSv4, same result). > > I'm really frustrated here since It worked barely an hour ago and I > have absolutely no idea why I getting this error now. > > Anyway, here are my /etc/rc.conf and /etc/exports files from the server= : > > /etc/rc.conf > ... > ## ZFS > zfs_enable=3D"YES" > ## NFSv4 Server > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" > rpcbind_enable=3D"YES" > mountd_enable=3D"YES" > mountd_flags=3D"-r" > #rpc_lockd_enable=3D"YES" > #rpc_statd_enable=3D"YES" > > /etc/exports (I tried both as NFSv3 and NFSv4, here are the two options= ) > -NFSv3: > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > 255.255.255.0 > > -NFSv4: > V4:/media/storage -network 192.168.1.0 -mask 255.255.255.0 > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > 255.255.255.0 For the nfs4 case it seems 'nfsuserd_enable=3D"YES"' is missing in your rc.conf (and on the client?). If your clients don't share the same domain suffix in their fqdn, you'll also want to set 'nfsuserd_flags=3D"-domain your.upper.tld"' -Harry --------------enig4BF3F93106D0AD2C6CEE5DE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlS/fysACgkQLDqVQ9VXb8ihqQCgnAi7GkOdxP6SLu3dJ2u3QObp nNQAn15JTHYownBzTMOjCYjvp/bIDheE =ZPVt -----END PGP SIGNATURE----- --------------enig4BF3F93106D0AD2C6CEE5DE4-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 21 14:22:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37BC41AA for ; Wed, 21 Jan 2015 14:22:05 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 B99E3901 for ; Wed, 21 Jan 2015 14:22:04 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id em10so15215239wid.1 for ; Wed, 21 Jan 2015 06:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=aRET4FQiqXni17gLtJvyeHBdvX+XrtP2FTah7Ri1RSI=; b=RiGJsiqWUM73Q9P+SP+QvJp0DJwBaEXKKywqC7j5fx3xMKyx7I/AZ8JNizqrRKQcio eLl/6J62LyhRToXao55e+R3Xy9hu0p2c6Eq5qLnOZEmDL7ADsUl0QoUXA7h7ebX7GNeD DHWQf0Q5rEuajwRavGdjqmKetKQ2lpOxmI3UZ/DuUS0+BTx54UCieGLYLfTqC2hcSGtv NcbNJb4I6aGlcv6X2yJZDC4qojNBjEkcazvSk0+4OGUMXA2Q+4VX0Bugvnq9/xqb2vZn HdRA0YMFSMazGE20nJUpwQo4ty42B/xDR9kX53WEHtK2M5pbk0qbRytmbQcGrvFChNVX 9u9A== X-Received: by 10.180.207.211 with SMTP id ly19mr57596738wic.73.1421850122559; Wed, 21 Jan 2015 06:22:02 -0800 (PST) Received: from MARC-THINKPAD.queenland (AOrleans-656-1-23-170.w90-20.abo.wanadoo.fr. [90.20.238.170]) by mx.google.com with ESMTPSA id hz9sm25731507wjb.17.2015.01.21.06.22.01 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 21 Jan 2015 06:22:01 -0800 (PST) Date: Wed, 21 Jan 2015 15:22:00 +0100 From: =?UTF-8?B?TcOkcms=?= Owen Cc: freebsd-stable@freebsd.org Subject: Re: NFS "mount system call failed" Message-ID: <20150121152200.707d6361@MARC-THINKPAD.queenland> In-Reply-To: <2096124637.17646377.1421796855627.JavaMail.root@uoguelph.ca> References: <20150120164409.49403c6e@MARC-THINKPAD.queenland> <2096124637.17646377.1421796855627.JavaMail.root@uoguelph.ca> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) 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.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:22:05 -0000 On Tue, 20 Jan 2015 18:34:15 -0500 (EST) Rick Macklem wrote: > Mark Owen wrote: > > Hi everyone, > > > > I'm using FreeBSD 10.1 to share a ZFS pool (mounted at > > /media/storage) > > through NFS to Linux clients (Debian 7). I don't seem to get any > > errors > > when the nfs services start on FreeBSD but I can't mount the shares > > on > > the clients, all I get is: mount.nfs4: mount system call failed > > (Tried > > as NFSv3 and NFSv4, same result). > > > > I'm really frustrated here since It worked barely an hour ago and I > > have absolutely no idea why I getting this error now. > > > Well, here's a couple of comments: > 1 - Look in /var/log/messages for any errors generated by mountd or > nfsd on the FreeBSD server. > 2 - Make sure the daemons (mountd and nfsd) are running, via "ps > axHl". 3 - It appears you have exported the file system "read-only", > but are trying to mount it read/write. (I'm not sure this would > produce an error at mount time or just if/when the client tries to > write to the file server?) > 4 - If nothing above helps, use "tcpdump -s 0 -w xxx.pcap host > " on the server to capture packets during a mount > attempt and then look at xxx.pcap in wireshark (since it understands > NFS). This will show you what interaction is going on between > client<->server and may give you the hint as to what is broken. > > rick > > > Anyway, here are my /etc/rc.conf and /etc/exports files from the > > server: > > > > /etc/rc.conf > > ... > > ## ZFS > > zfs_enable="YES" > > ## NFSv4 Server > > nfs_server_enable="YES" > > nfsv4_server_enable="YES" > > rpcbind_enable="YES" > > mountd_enable="YES" > > mountd_flags="-r" > > #rpc_lockd_enable="YES" > > #rpc_statd_enable="YES" > > > > /etc/exports (I tried both as NFSv3 and NFSv4, here are the two > > options) > > -NFSv3: > > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > > 255.255.255.0 > > > > -NFSv4: > > V4:/media/storage -network 192.168.1.0 -mask 255.255.255.0 > > /media/storage/data -ro -alldirs -network 192.168.1.0 -mask > > 255.255.255.0 > > > > > > On the clients I use the following commands to try to mount the > > share: > > - NFSv3: mount -t nfs -o nolock server-ip:/media/storage/data > > /mnt/tmp > > - NFSv4: mount -t nfs4 server-ip:/data /mnt/tmp > > > > Thank you for reading and I hope that someone will be able to help > > me. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Thu Jan 22 13:28:35 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CF679D for ; Thu, 22 Jan 2015 13:28:35 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 203E3372 for ; Thu, 22 Jan 2015 13:28:34 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEHnU-00057F-00 for freebsd-stable@freebsd.org; Thu, 22 Jan 2015 14:28:31 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Thu, 22 Jan 2015 14:27:42 +0100 Subject: mmap on tmpfs not updating mtime MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: 9090f8a1960d7f777b94d17b6f36e747 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:28:35 -0000 Hello, Tested on 10.1-STABLE/amd64 and 11-CURRENT/arm. I spotted this because rrdtool didn't update mtime of the database files so they were not backuped by my rsync scripts. I remembered and found these mails from November 2014 about mtime+mmap on ZFS. https://lists.freebsd.org/pipermail/freebsd-stable/2014-November/081138.html which resulted in https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081184.html My tests with the test program in the November mails result in: On 10.1-STABLE/ZFS its OK: $ 14:18:08 ronald@sjakie [~/test] ls -lT mdata; /tmp/a.out mdata; ls -lT mdata -rw------- 1 ronald staff 1024 Jan 22 14:18:08 2015 mdata -rw------- 1 ronald staff 1024 Jan 22 14:18:10 2015 mdata On 11/UFS its OK: $ 14:16:16 ronald@sheeva [~/test] ls -lT mdata; /tmp/a.out mdata; ls -lT mdata -rw------- 1 ronald staff 1024 Jan 22 14:16:16 2015 mdata -rw------- 1 ronald staff 1024 Jan 22 14:16:21 2015 mdata On 11/tmpfs it fails: (same on 10.1-STABLE/tmpfs) $ 14:15:44 ronald@sheeva [/tmp] ls -lT mdata; /tmp/a.out mdata; ls -lT mdata -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata Should a similar patch as ZFS got be applied to tmpfs? Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 22 16:57:34 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDB0465A for ; Thu, 22 Jan 2015 16:57:34 +0000 (UTC) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9379CFBE for ; Thu, 22 Jan 2015 16:57:34 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so133119pdj.12 for ; Thu, 22 Jan 2015 08:57:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:message-id:date:to:mime-version; bh=qJ9xLYNZ0Nd4PCaV7vN7O6AZg0WFezBtMsfsh+qHPsw=; b=QUUzbYT3rtGGNrJ9AlRt16v2A2npHjoMAEcY5XREQJvUGg+6lJrXAPyMQrXLw3BcVM X/1VsbmquFsuZ4UFEuHJ7QxdbOnWlufn4mMqvdKSTnjUKvp17B8/aJ5Kd/kBQRorsb0O oanTulrUXsgWnmp2LySJDhUI3lEFqYCNVFHL6FdsUIT56kaGTLT9mIunYGaEZmcN3aE4 0+jLGIKAaD9OQH0utQpdTYB714yw5xgj0a3SexWeUzj2TiYmA/qkMSzNIC6J/SoFrkqx hf602vGQzSyYu4iSmqQrUk+6bYBFcFcSKeatc2vT4ahA3YdMCQzJ9ffr05qCkugzDm52 WI0g== X-Gm-Message-State: ALoCoQkrMZGhMNrn6d6SZMs64QINX/gHkd/Sc8DG9VpLg1zG2RebSoDweEvQpyK7l66fi//cFUPj X-Received: by 10.70.123.166 with SMTP id mb6mr3609394pdb.95.1421945847907; Thu, 22 Jan 2015 08:57:27 -0800 (PST) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id rn15sm9804495pab.10.2015.01.22.08.57.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 08:57:27 -0800 (PST) Sender: Warner Losh From: Warner Losh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: If you use MCA devices, please let me know Message-Id: <2659453B-8F3B-496C-828C-19A59AC93806@bsdimp.com> Date: Thu, 22 Jan 2015 09:57:26 -0700 To: FreeBSD Stable , FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:57:34 -0000 Greetings, I=E2=80=99m wondering if there are any people out there using MCA = machines under FreeBSD. If so, please let me know. It would be great to know the model and FreeBSD = version. Thanks! Warner From owner-freebsd-stable@FreeBSD.ORG Thu Jan 22 18:52:22 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25157DCB; Thu, 22 Jan 2015 18:52:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 150B6333; Thu, 22 Jan 2015 18:52:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 96BA6391; Thu, 22 Jan 2015 18:52:22 +0000 (UTC) Date: Thu, 22 Jan 2015 18:52:21 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, gjb@FreeBSD.org, brueffer@FreeBSD.org, hselasky@FreeBSD.org Message-ID: <1362273858.0.1421952742360.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_9 #625 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:52:22 -0000 See Changes: [gjb] MFC r277216: Evaluate running userland/kernel version in daily periodic(8) run, taken from uname(1) '-U' and '-K' flags. Sponsored by: The FreeBSD Foundation [hselasky] MFC r276892: Add support for USB device side mode to the USB modem driver. [hselasky] MFC r276825 and r277372: Allow a block size of zero to mean 512 bytes, which is the most common block size for USB disks. This fixes support for "Action Cam SJ4000". [brueffer] MFH: r277085 Fix a typo in the FFS maxbpg option, it was erroneously spelled maxbpf. The error has been reported to and fixed in the NetBSD upstream version as well. PR: 196598 Submitted by: Dan McGregor ------------------------------------------ Started by an SCM change Building on master in workspace Updating svn://svn.freebsd.org/base/stable/9 at revision '2015-01-22T18:49:05.153 +0000' U etc/defaults/periodic.conf AU etc/periodic/daily/510.status-world-kernel U etc/periodic/daily/Makefile U etc C share/man/man5/periodic.conf.5 U share/man/man5 U sys/cam/scsi/scsi_da.c U sys/dev/usb/serial/umodem.c U sys/dev U sys U usr.sbin/makefs At revision 277534 [FreeBSD_stable_9] $ /bin/sh -xe /tmp/hudson3747153912161689301.sh + make -j 4 buildworld make: don't know how to make buildworld. Stop Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Thu Jan 22 22:50:31 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 126C09DF; Thu, 22 Jan 2015 22:50:31 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id E0E39A0; Thu, 22 Jan 2015 22:50:30 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 22 Jan 2015 14:53:31 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id t0MMoLFf017112; Thu, 22 Jan 2015 14:50:21 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id t0MMoKkH017111; Thu, 22 Jan 2015 14:50:20 -0800 (PST) (envelope-from ambrisko) Date: Thu, 22 Jan 2015 14:50:20 -0800 From: Doug Ambrisko To: Willem Jan Withagen Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Message-ID: <20150122225020.GA13161@ambrisko.com> References: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca> <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> <99F7DA1A-66EB-4F69-BAFA-0D72E4207248@gmail.com> <54BDA9DD.5040608@delphij.net> <54BE3FDC.9030904@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE3FDC.9030904@digiware.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd current , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 22:50:31 -0000 On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote: | On 2015-01-20 2:05, Xin Li wrote: | >>Doing it in 11 makes sense since there is a compat layer for 10 | >>now? if I knew all of the steps I would happily do them as annoys | >>me from time to time as well with the path length issue. | > | >Compat layer may break applications in other funny ways and we | >probably have to return e.g. ENAMETOOLONG for legacy applications if | >the names are too long to fit into the buffer, but I don't see any | >easy solution either: I wish we have bumped it in 2003 when the struct | >receives its first big revamp by bumping all statistic fields to 64-bit. | | On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > | > Especially with ZFS, I find I have a lot more mounts now, under longer | > and longer path names, and then I have | > .zfs/snapshots/snapshotnamehere/path/to/file | > | > etc. | > | > Definitely a +1 for "this is something we need for 11" | | +1 | | Well to be honest: Things are already broken for me ATM. | I do have paths that are too long, and tools trip over it. | | Things like building the locate database just don't have everything. | Which is a pain, especially for finding things fast in backups of ZFS, | where the path is even more convoluted that what Allan suggests | | So whether being bitten by the cat of the dog: it still hurts. | | Perhaps it is an intermediate solution to add new settings which are | going to be used for userspace programs, like USER_MNAMELEN and | USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves | systemcalls. But then a lot of the other tool stuff would just function. I have a patch at: http://www.ambrisko.com/doug/mount/latest.patch for -current (Nov). It should work with most file systems, that is I tried to cover them all. I haven't tested with ZFS but it should work. I left some debug "HELLO's" in there just to make sure mounting looked right. They can be safely deleted. If someone wants to test it and report issues (with a simple test case) I can fix it and add it to my test script. This code won't be going into FreeBSD now since the 64 bit inode will negate the need for it since the size will be a lot larger. Thanks, Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 07:26:24 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5A2A4CA for ; Fri, 23 Jan 2015 07:26:23 +0000 (UTC) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE4B962 for ; Fri, 23 Jan 2015 07:26:22 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20150123072615.YWKM17495.nskntmtas04p.mx.bigpond.com@nskntcmgw08p> for ; Fri, 23 Jan 2015 07:26:15 +0000 Received: from hermes.heuristicsystems.com.au ([203.41.22.114]) by nskntcmgw08p with BigPond Outbound id jKSE1p00x2ThMyb01KSE3G; Fri, 23 Jan 2015 07:26:15 +0000 X-Authority-Analysis: v=2.0 cv=D6DF24tj c=1 sm=1 a=tBIanQelQkU72CJWnm+MWA==:17 a=XD52yEjQpfAA:10 a=IkcTkHD0fZMA:10 a=GHIR_BbyAAAA:8 a=YNv0rlydsVwA:10 a=KCVDyJLnMtNk6gBZWloA:9 a=QEXdDO2ut3YA:10 a=tBIanQelQkU72CJWnm+MWA==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id t0N7OrEH025732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 23 Jan 2015 18:25:02 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <54C1F73C.6070100@heuristicsystems.com.au> Date: Fri, 23 Jan 2015 18:24:44 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org >> FreeBSD Stable Mailing List" Subject: Unable to build /rescue using today's 10.1Stable with undefined __libc_interposing Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 07:26:24 -0000 Just updated /usr/src on FreeBSD 10.1Stable and rebuilt /usr/src/rescue with the following result on Xeon (amd64). ... cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo ping6.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lgeom -lbsdxml -lkiconv -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lmd -lm nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x640): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/obj/usr/src/rescue/rescue/../librescue/system.o: In function `system': /usr/src/rescue/librescue/../../lib/libc/stdlib/system.c:(.text.system[system]+0x7): undefined reference to `__libc_interposing' /usr/bin/ld: rescue: hidden symbol `__libc_interposing' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 Is anyone else seeing this? I'm sorry to be asking but I thought that Jenkins detected build failures and I must've missed it. My last successful build/installworld was 29th Dec. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 08:46:52 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78D0F52C for ; Fri, 23 Jan 2015 08:46:52 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0B6615F for ; Fri, 23 Jan 2015 08:46:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0N8kjK4094234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 10:46:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0N8kjK4094234 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0N8kju6094233; Fri, 23 Jan 2015 10:46:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 10:46:45 +0200 From: Konstantin Belousov To: Ronald Klop Subject: Re: mmap on tmpfs not updating mtime Message-ID: <20150123084645.GE42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:46:52 -0000 On Thu, Jan 22, 2015 at 02:27:42PM +0100, Ronald Klop wrote: > Hello, > > Tested on 10.1-STABLE/amd64 and 11-CURRENT/arm. > > I spotted this because rrdtool didn't update mtime of the database files > so they were not backuped by my rsync scripts. > > I remembered and found these mails from November 2014 about mtime+mmap on > ZFS. > https://lists.freebsd.org/pipermail/freebsd-stable/2014-November/081138.html > which resulted in > https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081184.html > > My tests with the test program in the November mails result in: > On 10.1-STABLE/ZFS its OK: > $ 14:18:08 ronald@sjakie [~/test] > ls -lT mdata; /tmp/a.out mdata; ls -lT mdata > -rw------- 1 ronald staff 1024 Jan 22 14:18:08 2015 mdata > -rw------- 1 ronald staff 1024 Jan 22 14:18:10 2015 mdata > > On 11/UFS its OK: > $ 14:16:16 ronald@sheeva [~/test] > ls -lT mdata; /tmp/a.out mdata; ls -lT mdata > -rw------- 1 ronald staff 1024 Jan 22 14:16:16 2015 mdata > -rw------- 1 ronald staff 1024 Jan 22 14:16:21 2015 mdata > > On 11/tmpfs it fails: (same on 10.1-STABLE/tmpfs) > $ 14:15:44 ronald@sheeva [/tmp] > ls -lT mdata; /tmp/a.out mdata; ls -lT mdata > -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata > -rw------- 1 ronald wheel 1024 Jan 22 14:15:37 2015 mdata > > Should a similar patch as ZFS got be applied to tmpfs? In what way patch for tmpfs would be similar to zfs one ? Tmpfs architecturally makes it impossible or relatively hard to detect modifications to the pages of the tmpfs file through mmaping. The reason is that tmpfs files for VM look exactly like anonymous shared mappings. This is progress comparing with the initial tmpfs port, where mmaped data was double-copied. The detection of modifications could be done, e.g. by utilizing syncer to make a pass over all active vnodes and converting OBJ_MIGHTBEDIRTY flag for the backing vm object into mtime update. Of course, VM must be modified to also set the flag or its analog (OBJT_MIGHTBEDIRTYTMPFS ?) for tmpfs vm objects. This is what I mean above as 'relatively hard'. I will review (and commit) the patch along these lines. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 10:29:42 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC5DB5FC for ; Fri, 23 Jan 2015 10:29:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B909E13 for ; Fri, 23 Jan 2015 10:29:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0NATaAc016641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 12:29:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0NATaAc016641 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0NATaoZ016640; Fri, 23 Jan 2015 12:29:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 12:29:36 +0200 From: Konstantin Belousov To: Ronald Klop Subject: Re: mmap on tmpfs not updating mtime Message-ID: <20150123102936.GF42409@kib.kiev.ua> References: <20150123084645.GE42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150123084645.GE42409@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:29:42 -0000 On Fri, Jan 23, 2015 at 10:46:45AM +0200, Konstantin Belousov wrote: > The detection of modifications could be done, e.g. by utilizing syncer > to make a pass over all active vnodes and converting OBJ_MIGHTBEDIRTY > flag for the backing vm object into mtime update. Of course, VM must be > modified to also set the flag or its analog (OBJT_MIGHTBEDIRTYTMPFS ?) > for tmpfs vm objects. This is what I mean above as 'relatively hard'. > > I will review (and commit) the patch along these lines. Ok, it is even more complicated due to the interaction with the fast path in the fault handler, which ignored calls to vm_object_set_dirty() for tmpfs vnodes. Below is the prototype. It is on par with e.g. UFS, which only update mtime for writes through mapped regions when syncer finds such dirty pages. diff --git a/sys/fs/tmpfs/tmpfs.h b/sys/fs/tmpfs/tmpfs.h index 445bf61..b077489 100644 --- a/sys/fs/tmpfs/tmpfs.h +++ b/sys/fs/tmpfs/tmpfs.h @@ -398,6 +398,7 @@ int tmpfs_alloc_vp(struct mount *, struct tmpfs_node *, int, void tmpfs_free_vp(struct vnode *); int tmpfs_alloc_file(struct vnode *, struct vnode **, struct vattr *, struct componentname *, char *); +void tmpfs_check_mtime(struct vnode *); void tmpfs_dir_attach(struct vnode *, struct tmpfs_dirent *); void tmpfs_dir_detach(struct vnode *, struct tmpfs_dirent *); void tmpfs_dir_destroy(struct tmpfs_mount *, struct tmpfs_node *); diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c index d0d9a15..c1930f1 100644 --- a/sys/fs/tmpfs/tmpfs_subr.c +++ b/sys/fs/tmpfs/tmpfs_subr.c @@ -1415,6 +1415,31 @@ retry: return (0); } +void +tmpfs_check_mtime(struct vnode *vp) +{ + struct tmpfs_node *node; + struct vm_object *obj; + + ASSERT_VOP_ELOCKED(vp, "check_mtime"); + if (vp->v_type != VREG) + return; + node = VP_TO_TMPFS_NODE(vp); + obj = vp->v_object; + KASSERT((obj->flags & (OBJ_TMPFS_NODE | OBJ_TMPFS)) == + (OBJ_TMPFS_NODE | OBJ_TMPFS), ("non-tmpfs obj")); + /* unlocked read */ + if ((obj->flags & OBJ_TMPFS_DIRTY) != 0) { + VM_OBJECT_WLOCK(obj); + if ((obj->flags & OBJ_TMPFS_DIRTY) != 0) { + obj->flags &= ~OBJ_TMPFS_DIRTY; + node = VP_TO_TMPFS_NODE(vp); + node->tn_status |= TMPFS_NODE_MODIFIED; + } + VM_OBJECT_WUNLOCK(obj); + } +} + /* * Change flags of the given vnode. * Caller should execute tmpfs_update on vp after a successful execution. diff --git a/sys/fs/tmpfs/tmpfs_vfsops.c b/sys/fs/tmpfs/tmpfs_vfsops.c index f389f1c..2942e5a 100644 --- a/sys/fs/tmpfs/tmpfs_vfsops.c +++ b/sys/fs/tmpfs/tmpfs_vfsops.c @@ -33,10 +33,10 @@ /* * Efficient memory file system. * - * tmpfs is a file system that uses NetBSD's virtual memory sub-system - * (the well-known UVM) to store file data and metadata in an efficient - * way. This means that it does not follow the structure of an on-disk - * file system because it simply does not need to. Instead, it uses + * tmpfs is a file system that uses FreeBSD's virtual memory + * sub-system to store file data and metadata in an efficient way. + * This means that it does not follow the structure of an on-disk file + * system because it simply does not need to. Instead, it uses * memory-specific data structures and algorithms to automatically * allocate and release resources. */ @@ -50,6 +50,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -418,11 +419,45 @@ tmpfs_statfs(struct mount *mp, struct statfs *sbp) static int tmpfs_sync(struct mount *mp, int waitfor) { + struct vnode *vp, *mvp; + struct vm_object *obj; if (waitfor == MNT_SUSPEND) { MNT_ILOCK(mp); mp->mnt_kern_flag |= MNTK_SUSPEND2 | MNTK_SUSPENDED; MNT_IUNLOCK(mp); + } else if (waitfor == MNT_LAZY) { + /* + * Handle lazy updates of mtime from writes to mmaped + * regions. Use MNT_VNODE_FOREACH_ALL instead of + * MNT_VNODE_FOREACH_ACTIVE, since unmap of the + * tmpfs-backed vnode does not call vinactive(), due + * to vm object type is OBJT_SWAP. + */ + MNT_VNODE_FOREACH_ALL(vp, mp, mvp) { + if (vp->v_type != VREG) { + VI_UNLOCK(vp); + continue; + } + obj = vp->v_object; + KASSERT((obj->flags & (OBJ_TMPFS_NODE | OBJ_TMPFS)) == + (OBJ_TMPFS_NODE | OBJ_TMPFS), ("non-tmpfs obj")); + + /* + * Unlocked read, avoid taking vnode lock if + * not needed. Lost update will be handled on + * the next call. + */ + if ((obj->flags & OBJ_TMPFS_DIRTY) == 0) { + VI_UNLOCK(vp); + continue; + } + if (vget(vp, LK_EXCLUSIVE | LK_RETRY | LK_INTERLOCK, + curthread) != 0) + continue; + tmpfs_check_mtime(vp); + vput(vp); + } } return (0); } diff --git a/sys/fs/tmpfs/tmpfs_vnops.c b/sys/fs/tmpfs/tmpfs_vnops.c index c811b9a..65c5f82 100644 --- a/sys/fs/tmpfs/tmpfs_vnops.c +++ b/sys/fs/tmpfs/tmpfs_vnops.c @@ -505,6 +505,7 @@ tmpfs_fsync(struct vop_fsync_args *v) MPASS(VOP_ISLOCKED(vp)); + tmpfs_check_mtime(vp); tmpfs_update(vp); return 0; @@ -1222,16 +1223,16 @@ tmpfs_readlink(struct vop_readlink_args *v) static int tmpfs_inactive(struct vop_inactive_args *v) { - struct vnode *vp = v->a_vp; - + struct vnode *vp; struct tmpfs_node *node; + vp = v->a_vp; node = VP_TO_TMPFS_NODE(vp); - if (node->tn_links == 0) vrecycle(vp); - - return 0; + else + tmpfs_check_mtime(vp); + return (0); } int diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index e62410b..71c6d84 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -358,11 +358,13 @@ RetryFault:; (fault_flags & (VM_FAULT_CHANGE_WIRING | VM_FAULT_DIRTY)) == 0 && /* avoid calling vm_object_set_writeable_dirty() */ ((prot & VM_PROT_WRITE) == 0 || - fs.first_object->type != OBJT_VNODE || + (fs.first_object->type != OBJT_VNODE && + (fs.first_object->flags & OBJ_TMPFS_NODE) == 0) || (fs.first_object->flags & OBJ_MIGHTBEDIRTY) != 0)) { VM_OBJECT_RLOCK(fs.first_object); if ((prot & VM_PROT_WRITE) != 0 && - fs.first_object->type == OBJT_VNODE && + (fs.first_object->type == OBJT_VNODE || + (fs.first_object->flags & OBJ_TMPFS_NODE) != 0) && (fs.first_object->flags & OBJ_MIGHTBEDIRTY) == 0) goto fast_failed; m = vm_page_lookup(fs.first_object, fs.first_pindex); diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 21c15dc..63127c0 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -2199,8 +2199,13 @@ vm_object_set_writeable_dirty(vm_object_t object) { VM_OBJECT_ASSERT_WLOCKED(object); - if (object->type != OBJT_VNODE) + if (object->type != OBJT_VNODE) { + if ((object->flags & OBJ_TMPFS_NODE) != 0) { + KASSERT(object->type == OBJT_SWAP, ("non-swap tmpfs")); + vm_object_set_flag(object, OBJ_TMPFS_DIRTY); + } return; + } object->generation++; if ((object->flags & OBJ_MIGHTBEDIRTY) != 0) return; diff --git a/sys/vm/vm_object.h b/sys/vm/vm_object.h index ab3c7d3..d80b1d8 100644 --- a/sys/vm/vm_object.h +++ b/sys/vm/vm_object.h @@ -187,6 +187,7 @@ struct vm_object { #define OBJ_PIPWNT 0x0040 /* paging in progress wanted */ #define OBJ_MIGHTBEDIRTY 0x0100 /* object might be dirty, only for vnode */ #define OBJ_TMPFS_NODE 0x0200 /* object belongs to tmpfs VREG node */ +#define OBJ_TMPFS_DIRTY 0x0400 /* dirty tmpfs obj */ #define OBJ_COLORED 0x1000 /* pg_color is defined */ #define OBJ_ONEMAPPING 0x2000 /* One USE (a single, non-forked) mapping flag */ #define OBJ_DISCONNECTWNT 0x4000 /* disconnect from vnode wanted */ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 11:57:25 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E9C4BBC for ; Fri, 23 Jan 2015 11:57:25 +0000 (UTC) Received: from cpsmtpb-ews09.kpnxchange.com (cpsmtpb-ews09.kpnxchange.com [213.75.39.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE9F98F for ; Fri, 23 Jan 2015 11:57:24 +0000 (UTC) Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews09.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 23 Jan 2015 12:56:11 +0100 Received: from CPSMTPM-CMT101.kpnxchange.com ([195.121.3.17]) by cpsps-ews12.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 23 Jan 2015 12:56:11 +0100 Received: from donald.offrom.nl ([77.170.60.162]) by CPSMTPM-CMT101.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(7.0.6002.18264); Fri, 23 Jan 2015 12:56:11 +0100 Received: from squid (squid.vpn.offrom.nl [10.168.0.72]) by donald.offrom.nl (8.14.9/8.14.9) with ESMTP id t0NBtw0S086918 for ; Fri, 23 Jan 2015 12:56:01 +0100 (CET) (envelope-from Willy@Offermans.Rompen.nl) Received: from willy by squid with local (Exim 4.80) (envelope-from ) id 1YEcq8-0007dx-D6 for freebsd-stable@FreeBSD.ORG; Fri, 23 Jan 2015 12:55:52 +0100 Date: Fri, 23 Jan 2015 12:55:52 +0100 From: Willy Offermans To: freebsd-stable@FreeBSD.ORG Subject: Recommended PCIe Wireless Card for FBSD as Access Point Message-ID: <20150123115552.GD5032@vpn.offrom.nl> Reply-To: Willy@Offermans.Rompen.nl MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on donald.offrom.nl X-OriginalArrivalTime: 23 Jan 2015 11:56:11.0640 (UTC) FILETIME=[94E7E780:01D03703] X-RcptDomain: FreeBSD.ORG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 11:57:25 -0000 Dear FreeBSD friends, I can proudly announce that I'm running FreeBSD 10.1-STABLE on a HP Proliant Gen8 micro server for a couple of weeks now. I'm very satisfied with the services of the system. The micro server has a free empty PCIe2 x16(8,4,1) slot. I want to mount a PCIe wireless card into this slot and add Access Point as an extra service to this machine. I'm aware of chapter 31.3.6. with title FreeBSD Host Access Points out of the FreeBSD handbook. So next to fit into the slot and to be supported by FreeBSD 10+ generally, the card should also be able to support HOSTAP. Can someone recommend me a wireless card that would fulfill the requirements? I would very much appreciate your advice. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel ************************************* W.K. Offermans From owner-freebsd-stable@FreeBSD.ORG Fri Jan 23 13:55:06 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7F60D33 for ; Fri, 23 Jan 2015 13:55:06 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94F4790C for ; Fri, 23 Jan 2015 13:55:06 +0000 (UTC) Received: from [192.168.2.123] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by webmail2.jnielsen.net (8.15.1/8.14.9) with ESMTPSA id t0NDsHFS085165 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 06:54:23 -0700 (MST) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105] claimed to be [192.168.2.123] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Recommended PCIe Wireless Card for FBSD as Access Point From: John Nielsen X-Mailer: iPhone Mail (12B440) In-Reply-To: <20150123115552.GD5032@vpn.offrom.nl> Date: Fri, 23 Jan 2015 06:54:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150123115552.GD5032@vpn.offrom.nl> To: "Willy@Offermans.Rompen.nl" Cc: "freebsd-stable@FreeBSD.ORG" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:55:06 -0000 Anything based on an Atheros "n" card should be fine. AR9280, for example, i= s fairly common and well-supported.=20 > On Jan 23, 2015, at 4:55 AM, Willy Offermans w= rote: >=20 > Dear FreeBSD friends, >=20 > I can proudly announce that I'm running FreeBSD 10.1-STABLE on a HP > Proliant Gen8 micro server for a couple of weeks now. I'm very=20 > satisfied with the services of the system. >=20 > The micro server has a free empty PCIe2 x16(8,4,1) slot. I want to mount a= > PCIe wireless card into this slot and add Access Point as an extra service= =20 > to this machine. I'm aware of chapter 31.3.6. with title FreeBSD Host=20 > Access Points out of the FreeBSD handbook. So next to fit into the slot an= d > to be supported by FreeBSD 10+ generally, the card should also be able to > support HOSTAP. >=20 > Can someone recommend me a wireless card that would fulfill the > requirements? I would very much appreciate your advice. >=20 > --=20 > Met vriendelijke groeten, > With kind regards, > Mit freundlichen Gruessen, > De jrus wah, >=20 > Wiel >=20 > ************************************* > W.K. Offermans > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 11:47:47 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9B5C9E5 for ; Sat, 24 Jan 2015 11:47:47 +0000 (UTC) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Cryptonomicore CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BE66794 for ; Sat, 24 Jan 2015 11:47:47 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A1CD015FCC1; Sat, 24 Jan 2015 11:47:44 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Recommended PCIe Wireless Card for FBSD as Access Point From: Stefan Bethke In-Reply-To: <20150123115552.GD5032@vpn.offrom.nl> Date: Sat, 24 Jan 2015 12:47:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <279C7A33-F402-40E1-9B8E-B98454351399@lassitu.de> References: <20150123115552.GD5032@vpn.offrom.nl> To: Willy@Offermans.Rompen.nl X-Mailer: Apple Mail (2.1993) Cc: freebsd-stable@FreeBSD.ORG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 11:47:47 -0000 The micro server has a free empty PCIe2 x16(8,4,1) slot. I want to mount = a > PCIe wireless card into this slot and add Access Point as an extra = service=20 > to this machine. I'm aware of chapter 31.3.6. with title FreeBSD Host=20= > Access Points out of the FreeBSD handbook. So next to fit into the = slot and > to be supported by FreeBSD 10+ generally, the card should also be able = to > support HOSTAP. >=20 > Can someone recommend me a wireless card that would fulfill the > requirements? I would very much appreciate your advice. I haven=E2=80=99t tried it in AP mode, but I=E2=80=99m otherwise very = happy with the TP-Link TL-WN881ND PCIe card (168c:002d, AR9227, about 14 = Euros). TP-Link seems to use Atheros chips predominantly, so it=E2=80=99s= always a good bet. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 11:49:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27DF6AD4; Sat, 24 Jan 2015 11:49:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 096C77BA; Sat, 24 Jan 2015 11:49:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D8FD7104C; Sat, 24 Jan 2015 11:49:04 +0000 (UTC) Date: Sat, 24 Jan 2015 11:49:03 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, gjb@FreeBSD.org, brueffer@FreeBSD.org, delphij@FreeBSD.org, ngie@FreeBSD.org, hselasky@FreeBSD.org Message-ID: <1114746932.0.1422100144706.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_9 #625 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 11:49:04 -0000 See Changes: [ngie] MFC r277272: Don't call abort on usage errors; print out the usage message instead PR: 196793 Sponsored by: EMC / Isilon Storage Division [ngie] MFC r276804: Fix 'make depend' before infiniband headers have been installed to build host by removing space between -I and the header directory Sponsored by: EMC / Isilon Storage Division [ngie] MFC r276806: Remove unnecessary .include of bsd.own.mk Sponsored by: EMC / Isilon Storage Division [delphij] MFC r276577: MFV r276568: Update file to 5.22. [gjb] MFC r277216: Evaluate running userland/kernel version in daily periodic(8) run, taken from uname(1) '-U' and '-K' flags. Sponsored by: The FreeBSD Foundation [hselasky] MFC r276892: Add support for USB device side mode to the USB modem driver. [hselasky] MFC r276825 and r277372: Allow a block size of zero to mean 512 bytes, which is the most common block size for USB disks. This fixes support for "Action Cam SJ4000". [brueffer] MFH: r277085 Fix a typo in the FFS maxbpg option, it was erroneously spelled maxbpf. The error has been reported to and fixed in the NetBSD upstream version as well. PR: 196598 Submitted by: Dan McGregor ------------------------------------------ Started by user rodrigc Building on master in workspace Updating svn://svn.freebsd.org/base/stable/9 at revision '2015-01-24T11:47:57.127 +0000' U contrib/file/magic/Localstuff U contrib/file/magic/Makefile.in U contrib/file/magic/Magdir/jpeg U contrib/file/magic/Magdir/images U contrib/file/magic/Magdir/filesystems A contrib/file/magic/Magdir/qt U contrib/file/magic/Magdir/cafebabe U contrib/file/magic/Makefile.am U contrib/file/configure U contrib/file/python/Makefile.in U contrib/file/Makefile.in U contrib/file/ChangeLog U contrib/file/src/elfclass.h U contrib/file/src/softmagic.c U contrib/file/src/funcs.c U contrib/file/src/file.c U contrib/file/src/file.h U contrib/file/src/file_opts.h U contrib/file/src/Makefile.in U contrib/file/src/readelf.c U contrib/file/src/magic.c U contrib/file/src/magic.h U contrib/file/src/getline.c U contrib/file/src/apprentice.c U contrib/file/src/magic.h.in U contrib/file/src/compress.c U contrib/file/README U contrib/file/tests/Makefile.in U contrib/file/configure.ac U contrib/file/doc/file.man U contrib/file/doc/magic.man U contrib/file/doc/libmagic.man U contrib/file/doc/Makefile.in U contrib/file/missing U contrib/file/aclocal.m4 U contrib/file U contrib/ofed/management/opensm/osmtest/main.c U contrib/ofed/Makefile U contrib/ofed/usr.lib/libibcm/Makefile U contrib AU etc/periodic/daily/510.status-world-kernel U etc/periodic/daily/Makefile U etc/defaults/periodic.conf U etc C lib/libmagic/config.h U lib/libmagic C share/man/man5/periodic.conf.5 U share/man/man5 U sys/cam/scsi/scsi_da.c U sys/dev/usb/serial/umodem.c U sys/dev U sys U usr.sbin/makefs U . At revision 277641 [FreeBSD_stable_9] $ /bin/sh -xe /tmp/hudson1387020064012228904.sh + make -j 4 buildworld make: don't know how to make buildworld. Stop Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 17:31:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFF0BC13 for ; Sat, 24 Jan 2015 17:31:00 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84E9B990 for ; Sat, 24 Jan 2015 17:31:00 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id z20so2395672igj.4 for ; Sat, 24 Jan 2015 09:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=diJmgd0++ytdXt0dEgv+S33vZ4flwbjgw4wceAW8zjU=; b=slWkyMMF8J5nD4A06pqNsYfxg8MKqYaO8mV3Jl3iUWXVY9Ic/xzAWI7rbEsM1QI/le S2GMC1+z4NaiXrHZ3jex12yZVdvnjBmPrmiOhCfqz78ChQuRmC5u5xdwKXy7BhhsweB+ wpEQMxY+uAWa0MZ1SkbyrB5XbovZFBDkKIDBLAlg/TK8OEfYq8EzVeUik44As9y/OJ2A vqPKTV5R+Js+OKutqj+kLYeOrcuhJY1JoyvXroVZbdhmnXEkYQ9U9R1uc+y3lff4XW1i qv/Ke/u4hd6nlOBxqf8b0inFk/VSFFSrY4vG6IVSqKVmGPd7UWOA4jNq9gsMXj7cMIUF ebwg== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr2437552igx.32.1422120660038; Sat, 24 Jan 2015 09:31:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 09:30:59 -0800 (PST) In-Reply-To: <279C7A33-F402-40E1-9B8E-B98454351399@lassitu.de> References: <20150123115552.GD5032@vpn.offrom.nl> <279C7A33-F402-40E1-9B8E-B98454351399@lassitu.de> Date: Sat, 24 Jan 2015 09:30:59 -0800 X-Google-Sender-Auth: WSluibA-xpxQ6hz1nm67RlOjWsE Message-ID: Subject: Re: Recommended PCIe Wireless Card for FBSD as Access Point From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 17:31:00 -0000 On 24 January 2015 at 03:47, Stefan Bethke wrote: > The micro server has a free empty PCIe2 x16(8,4,1) slot. I want to mount = a >> PCIe wireless card into this slot and add Access Point as an extra servi= ce >> to this machine. I'm aware of chapter 31.3.6. with title FreeBSD Host >> Access Points out of the FreeBSD handbook. So next to fit into the slot = and >> to be supported by FreeBSD 10+ generally, the card should also be able t= o >> support HOSTAP. >> >> Can someone recommend me a wireless card that would fulfill the >> requirements? I would very much appreciate your advice. > > I haven=E2=80=99t tried it in AP mode, but I=E2=80=99m otherwise very hap= py with the TP-Link TL-WN881ND PCIe card (168c:002d, AR9227, about 14 Euros= ). TP-Link seems to use Atheros chips predominantly, so it=E2=80=99s alway= s a good bet. Ugh, can someone please keep hitting me (gently) until I commit something to force a full reset after the NF calibration fails? That'll work around the issues in hostap mode with the AR9227/AR9287 going deaf.. :( Thanks, -a From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 20:17:03 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A33AD38 for ; Sat, 24 Jan 2015 20:17:03 +0000 (UTC) Received: from babel.karthauser.co.uk (212-13-197-151.karthauser.co.uk [212.13.197.151]) by mx1.freebsd.org (Postfix) with ESMTP id 23170B83 for ; Sat, 24 Jan 2015 20:17:02 +0000 (UTC) Received: from dspam (212-13-197-151.karthauser.co.uk [212.13.197.151]) by babel.karthauser.co.uk (Postfix) with SMTP id E2FA2813 for ; Sat, 24 Jan 2015 20:09:51 +0000 (UTC) Received: from unnamed-72.karthauser.co.uk (unnamed-72.karthauser.co.uk [90.155.77.72]) (Authenticated sender: joemail@tao.org.uk) by babel.karthauser.co.uk (Postfix) with ESMTPSA id 34358811; Sat, 24 Jan 2015 20:09:48 +0000 (UTC) Subject: Re: Creating a bootable ZFS disk? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Dr Josef Karthauser In-Reply-To: <54A59FE8.2070008@multiplay.co.uk> Date: Sat, 24 Jan 2015 20:09:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3235C789-E677-4FA0-91CA-4C8F5DF17F99@tao.org.uk> References: <54a048f2.45c1c20a.6ffd.ffffe6d7SMTPIN_ADDED_BROKEN@mx.google.com> <54A062FE.6020500@multiplay.co.uk> <54A067D0.4050606@multiplay.co.uk> <349F0A87-5F85-4367-9A5C-E77DBFA16588@karthauser.co.uk> <7E1DA790-822F-4253-A3F6-1E5F5EFFEE04@karthauser.co.uk> <54A1129F.3040004@multiplay.co.uk> <54A18986.4000002@multiplay.co.uk> <5AFFE5CE-ABC7-4D9C-B8E7-0AC9C3327D6B@tao.org.uk> <54A2D3FA.6000404@multiplay.co.uk> <18C4C5D1-04D8-46B3-9E6F-FDAEB49BED1A@tao.org.uk> <54A59FE8.2070008@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1993) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Jan 24 20:09:51 2015 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 54c3fc0f26841255615320 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 20:17:03 -0000 > On 1 Jan 2015, at 19:28, Steven Hartland = wrote: >=20 > On 01/01/2015 17:18, Dr Josef Karthauser wrote: >> On 30 Dec 2014, at 16:34, Steven Hartland = wrote: >>> This is strengthened by the fact that ATI's previous generation HW = (SB600) had MSI disabled by r245875 due to a very similar issue. >>>=20 >>> So given all the evidence so far ahci.0.msi=3D1 may well be the fix. >>>=20 >> Is there any benefit to also trying with mdi > 1 < 8? > Nope as the ahci(4) details there's only 3 settings: > 0 =3D MSI disabled > 1 =3D Single MSI vector used, if supported > 2 =3D Multiple MSI vectors used, if supported (default) >=20 > If setting it to 1 does fix it, I've got a patch which provides a = quirk we can use to make that the default for this HW. Finally got the machine into a state I can test it - sorry for the = delay. I=E2=80=99ve set it in boot.loader: $ cat /boot/loader.conf=20 zfs_load=3D=E2=80=9CYES" ahci.0.msi=3D1 However, it=E2=80=99s still allocating all 8 vectors: $ dmesg | grep MSI [cut] ahci0: attempting to allocate 8 MSI vectors (8 supported) msi: routing MSI IRQ 263 to local APIC 0 vector 64 msi: routing MSI IRQ 264 to local APIC 0 vector 65 msi: routing MSI IRQ 265 to local APIC 0 vector 66 msi: routing MSI IRQ 266 to local APIC 0 vector 67 msi: routing MSI IRQ 267 to local APIC 0 vector 68 msi: routing MSI IRQ 268 to local APIC 0 vector 69 msi: routing MSI IRQ 269 to local APIC 0 vector 70 msi: routing MSI IRQ 270 to local APIC 0 vector 71 ahci0: using IRQs 263-270 for MSI [cut] This is with: $ uname -a FreeBSD my.machine.and.domain 10.1-RELEASE FreeBSD 10.1-RELEASE #0 = r274401: Tue Nov 11 21:02:49 UTC 2014 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 So, that=E2=80=99s confusing - I was expecting it to only route a single = vector. That sysctl isn=E2=80=99t exposed as a read variable: $ sysctl -a | grep ahci.0 dev.ahci.0.%desc: AMD SB7x0/SB8x0/SB9x0 AHCI SATA controller dev.ahci.0.%driver: ahci dev.ahci.0.%location: slot=3D17 function=3D0 handle=3D\_SB_.PCI0.SATA dev.ahci.0.%pnpinfo: vendor=3D0x1002 device=3D0x4391 = subvendor=3D0x103c subdevice=3D0x1609 class=3D0x010601 dev.ahci.0.%parent: pci0 Is it only in -current perchance? Thanks, Joe From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 20:54:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A927D6B for ; Sat, 24 Jan 2015 20:54:46 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE0C9EF9 for ; Sat, 24 Jan 2015 20:54:45 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id n3so3355353wiv.1 for ; Sat, 24 Jan 2015 12:54:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0Cs492Wlrs14sV2tA/IuU+xyxDJ59KLyNXpZyRxi0bE=; b=ROC5gtIh4MnZKWxzDXYFh2kvvzgYWksW3hDNPT338RtQ9psU1FGZXUDqHkU8Vgw8ih 3bP3GB+HLp7wfBgoca1A0TFhtnxeQ2WdsVhVRp3x5+usT/KS+brhtm0dMwEA11dJwzSr nPN7wVaIxDj7k/dG2h3Cvk9ee1egFkocie1J7/472a0WrlpvUyiiw21rLaA8LimBsINm J8Xr6UeLKssh0eWx3jM/aKryDSBRUg+4W+ZR72X8oc9HmLFmrCUHnZBay9kSbgQ7kjU8 /nzcOMN2S6b4s8ii8QARVjw0e122ClGqgoEj05/NyQNL4dmmQMIJuJteLDhU8zbbEqZr tVOg== X-Gm-Message-State: ALoCoQl9kbZcTBvER+m7RoOjqGix/zGdEOO64rDTae13mx3GRQpcO5S6mr60zVHFZIMZBefgCMSz X-Received: by 10.194.191.227 with SMTP id hb3mr28244081wjc.79.1422132481024; Sat, 24 Jan 2015 12:48:01 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id z6sm6730629wix.20.2015.01.24.12.47.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 12:48:00 -0800 (PST) Message-ID: <54C40571.50303@multiplay.co.uk> Date: Sat, 24 Jan 2015 20:49:53 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dr Josef Karthauser Subject: Re: Creating a bootable ZFS disk? References: <54a048f2.45c1c20a.6ffd.ffffe6d7SMTPIN_ADDED_BROKEN@mx.google.com> <54A062FE.6020500@multiplay.co.uk> <54A067D0.4050606@multiplay.co.uk> <349F0A87-5F85-4367-9A5C-E77DBFA16588@karthauser.co.uk> <7E1DA790-822F-4253-A3F6-1E5F5EFFEE04@karthauser.co.uk> <54A1129F.3040004@multiplay.co.uk> <54A18986.4000002@multiplay.co.uk> <5AFFE5CE-ABC7-4D9C-B8E7-0AC9C3327D6B@tao.org.uk> <54A2D3FA.6000404@multiplay.co.uk> <18C4C5D1-04D8-46B3-9E6F-FDAEB49BED1A@tao.org.uk> <54A59FE8.2070008@multiplay.co.uk> <3235C789-E677-4FA0-91CA-4C8F5DF17F99@tao.org.uk> In-Reply-To: <3235C789-E677-4FA0-91CA-4C8F5DF17F99@tao.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 20:54:46 -0000 On 24/01/2015 20:09, Dr Josef Karthauser wrote: >> On 1 Jan 2015, at 19:28, Steven Hartland wrote: >> >> On 01/01/2015 17:18, Dr Josef Karthauser wrote: >>> On 30 Dec 2014, at 16:34, Steven Hartland wrote: >>>> This is strengthened by the fact that ATI's previous generation HW (SB600) had MSI disabled by r245875 due to a very similar issue. >>>> >>>> So given all the evidence so far ahci.0.msi=1 may well be the fix. >>>> >>> Is there any benefit to also trying with mdi > 1 < 8? >> Nope as the ahci(4) details there's only 3 settings: >> 0 = MSI disabled >> 1 = Single MSI vector used, if supported >> 2 = Multiple MSI vectors used, if supported (default) >> >> If setting it to 1 does fix it, I've got a patch which provides a quirk we can use to make that the default for this HW. > Finally got the machine into a state I can test it - sorry for the delay. > > I’ve set it in boot.loader: > > $ cat /boot/loader.conf > zfs_load=“YES" > ahci.0.msi=1 > Your missing hint. your should have: hint.achi.0.msi="1" Regards Steve From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 21:05:49 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 654FD48E for ; Sat, 24 Jan 2015 21:05:49 +0000 (UTC) Received: from babel.karthauser.co.uk (212-13-197-151.karthauser.co.uk [212.13.197.151]) by mx1.freebsd.org (Postfix) with ESMTP id 23585FDA for ; Sat, 24 Jan 2015 21:05:48 +0000 (UTC) Received: from dspam (212-13-197-151.karthauser.co.uk [212.13.197.151]) by babel.karthauser.co.uk (Postfix) with SMTP id A8C7186E for ; Sat, 24 Jan 2015 21:05:37 +0000 (UTC) Received: from unnamed-72.karthauser.co.uk (unnamed-72.karthauser.co.uk [90.155.77.72]) (Authenticated sender: joemail@tao.org.uk) by babel.karthauser.co.uk (Postfix) with ESMTPSA id 7529986C; Sat, 24 Jan 2015 21:05:33 +0000 (UTC) Subject: Re: Creating a bootable ZFS disk? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Dr Josef Karthauser In-Reply-To: <54C40571.50303@multiplay.co.uk> Date: Sat, 24 Jan 2015 21:05:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BBD317F-AE7F-4D78-896F-DE35125A4FD1@tao.org.uk> References: <54a048f2.45c1c20a.6ffd.ffffe6d7SMTPIN_ADDED_BROKEN@mx.google.com> <54A062FE.6020500@multiplay.co.uk> <54A067D0.4050606@multiplay.co.uk> <349F0A87-5F85-4367-9A5C-E77DBFA16588@karthauser.co.uk> <7E1DA790-822F-4253-A3F6-1E5F5EFFEE04@karthauser.co.uk> <54A1129F.3040004@multiplay.co.uk> <54A18986.4000002@multiplay.co.uk> <5AFFE5CE-ABC7-4D9C-B8E7-0AC9C3327D6B@tao.org.uk> <54A2D3FA.6000404@multiplay.co.uk> <18C4C5D1-04D8-46B3-9E6F-FDAEB49BED1A@tao.org.uk> <54A59FE8.2070008@multiplay.co.uk> <3235C789-E677-4FA0-91CA-4C8F5DF17F99@tao.org.uk> <54C40571.50303@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1993) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Jan 24 21:05:37 2015 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 54c4092126841923894079 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 21:05:49 -0000 On 24 Jan 2015, at 20:49, Steven Hartland = wrote: >=20 > On 24/01/2015 20:09, Dr Josef Karthauser wrote: >>> On 1 Jan 2015, at 19:28, Steven Hartland = wrote: >>>=20 >>> If setting it to 1 does fix it, I've got a patch which provides a = quirk we can use to make that the default for this HW. >> Finally got the machine into a state I can test it - sorry for the = delay. >>=20 >> I=E2=80=99ve set it in boot.loader: >>=20 >> $ cat /boot/loader.conf >> zfs_load=3D=E2=80=9CYES" >> ahci.0.msi=3D1 >>=20 > Your missing hint. your should have: > hint.achi.0.msi=3D=E2=80=9C1" Ah! :) (hint.ahci.0.msi, of course!) That appears to work: ahci0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 263 to local APIC 0 vector 58 I=E2=80=99m doing a scrub of the pool now - it was a resilvering = activity that caused it to crash and burn before, so I=E2=80=99m hoping = that scrub should emulate the same load. I=E2=80=99ll report back when = it=E2=80=99s finished. Joe From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 21:48:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFB1D10A; Sat, 24 Jan 2015 21:48:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ACA0E607; Sat, 24 Jan 2015 21:48:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3AAE49A7; Sat, 24 Jan 2015 21:48:58 +0000 (UTC) Date: Sat, 24 Jan 2015 21:48:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, gjb@FreeBSD.org, brueffer@FreeBSD.org, delphij@FreeBSD.org, ngie@FreeBSD.org, pfg@FreeBSD.org, hselasky@FreeBSD.org Message-ID: <1687850904.5.1422136138214.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1114746932.0.1422100144706.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1114746932.0.1422100144706.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_9 #626 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_9 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 21:48:57 -0000 See Changes: [pfg] MFC r277301: ext2: cosmetical issues Minor sorting and note when the cases are expected to fall through. ------------------------------------------ Started by an SCM change Building on master in workspace Updating svn://svn.freebsd.org/base/stable/9 at revision '2015-01-24T21:48:29.240 +0000' U sys/fs/ext2fs/ext2_hash.c U sys/fs U sys At revision 277662 [FreeBSD_stable_9] $ /bin/sh -xe /tmp/hudson4448652085626278648.sh + make -j 4 buildworld make: don't know how to make buildworld. Stop Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sat Jan 24 21:54:02 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE7173D8; Sat, 24 Jan 2015 21:54:01 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3DA06C2; Sat, 24 Jan 2015 21:54:01 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so4125804pab.12; Sat, 24 Jan 2015 13:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=M4ODS0ZEMs9ctsn8tYQceYPdrsAvhFloAYoIZW5h3gs=; b=0CnvrugHJARK7ozb4kLfFL+oa+gjjsMeAox01S0pQICIuHxQg1jTT2DFk03bO31dnb gFIYjn18qoq2WzGa0ZMlYwN+Mek1jLqFQSfZHHLR4U9lDXoGYOnjg6OQlBDNHAGJeSiF Uub8cqFZjqMNufpAVqnfxK987OYZAB3yg/RQqqufasxS/B0XspEx4a38pEFS5Y9o3xUB 1U04UK1YKyKOxU7r/kp7JTp0zLdPtOZsc/aWQBZaGs4PVbayB+PLxpl7K3W2yWPn7Fk+ lQNBQk6TEzE4sbCuUQS8CMOii5vKJLdoMPZVdulNX/VV70ZO7eZYT1L7/tghzOOI4jWy QjVA== X-Received: by 10.66.142.131 with SMTP id rw3mr22247818pab.35.1422136441043; Sat, 24 Jan 2015 13:54:01 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:d4ec:854d:6b4d:4d67? ([2601:8:ab80:7d6:d4ec:854d:6b4d:4d67]) by mx.google.com with ESMTPSA id jw8sm1971896pbc.73.2015.01.24.13.54.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 13:54:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E0665A58-A2ED-4FAD-9279-F1B92795F161"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Build failed in Jenkins: FreeBSD_stable_9 #626 From: Garrett Cooper In-Reply-To: <1687850904.5.1422136138214.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Sat, 24 Jan 2015 13:53:59 -0800 Message-Id: <28D4CD25-C5A6-40E3-8B0F-049F30686645@gmail.com> References: <1114746932.0.1422100144706.JavaMail.jenkins@jenkins-9.freebsd.org> <1687850904.5.1422136138214.JavaMail.jenkins@jenkins-9.freebsd.org> To: jenkins-admin@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org, hselasky@FreeBSD.org, gjb@FreeBSD.org, pfg@FreeBSD.org, delphij@FreeBSD.org, brueffer@FreeBSD.org, ngie@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 21:54:02 -0000 --Apple-Mail=_E0665A58-A2ED-4FAD-9279-F1B92795F161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 24, 2015, at 13:48, jenkins-admin@freebsd.org wrote: > See >=20 > Changes: >=20 > [pfg] MFC r277301: > ext2: cosmetical issues >=20 > Minor sorting and note when the cases are expected to fall through. >=20 > ------------------------------------------ > Started by an SCM change > Building on master in workspace = > Updating svn://svn.freebsd.org/base/stable/9 at revision = '2015-01-24T21:48:29.240 +0000' > U sys/fs/ext2fs/ext2_hash.c > U sys/fs > U sys > At revision 277662 > [FreeBSD_stable_9] $ /bin/sh -xe /tmp/hudson4448652085626278648.sh > + make -j 4 buildworld > make: don't know how to make buildworld. Stop > Build step 'Execute shell' marked build as failure Hi Jenkins admins! It looks like the stable/9 checkout got whacked somehow =97 = could the CI scripts be changed to do an svn revert -R, then an svn up = (this should fix the issue)? Thanks! --Apple-Mail=_E0665A58-A2ED-4FAD-9279-F1B92795F161 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 - https://gpgtools.org iQEcBAEBCgAGBQJUxBR3AAoJEMZr5QU6S73e6VEH/2f9qQRSKeqKIA1nYa9YlVSm w7uu3vER+suI5hpOXDAgQeJBsujhpglaSA+rFAFGVlEqihOPTBXadUjrsoeVvhMd bf9P6x409RkMvybqIhfw6UAuV6oO56NU4qpcg1ZKXTKXd0mjd1xpipWV/JpXh2AT vsu49L3MC4jSwLcYSeOJuUDxee2X8r7nZWAKHuI21ro2lfPIfWbOkcNh/X0Ymqk8 F+/y17T/0UdQZDKxfrRVtfRjFGTUqnYPVasAVj7NEZwsABG4qUEMvzlD4rO6+5QO fd3GdMs5xuafbHsNBXEYUzF14esbdw5n6EJ+e/kRdDZ2kJZ6u79jqF4vnT0l3f8= =Ywnk -----END PGP SIGNATURE----- --Apple-Mail=_E0665A58-A2ED-4FAD-9279-F1B92795F161--