From owner-freebsd-current@freebsd.org Sun Sep 2 00:20:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CCDCFD4807; Sun, 2 Sep 2018 00:20:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 92D3C81F9C; Sun, 2 Sep 2018 00:20:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w820KkXC038753; Sat, 1 Sep 2018 17:20:46 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w820KkBG038752; Sat, 1 Sep 2018 17:20:46 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809020020.w820KkBG038752@pdx.rh.CN85.dnsmgr.net> Subject: Re: Failing to retrieve source tarballs for anything. In-Reply-To: To: Jonathan Chen Date: Sat, 1 Sep 2018 17:20:46 -0700 (PDT) CC: Alex McKeever , FreeBSD Stable , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 00:20:50 -0000 > On 2 September 2018 at 05:25, Alex McKeever wrote: > > After compiling PKG, when I go to ports to compile anything (my eMac can run FreeBSD but not modern Linux due to the version of the Radeon GPU) it fails to retrieve any of the source tarballs for any of the software, desktop environments etc. I would like help to fix this, as I?d like to run something current. > > > > How old is your ports tree? It it up to date? What sort of problems > are you seeing in fetching the port sources? > > Since no one else has reported any problems, it is most likely > something to do with your local environment. Can you fetch ANY ports items? Can you ping 8.8.8.8? As stated earlier, the exact error message(s) would probably be very informative and without them we are all kinda shooting in the dark as to what of a million different things could be wrong. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sun Sep 2 00:15:12 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 136CAFD44CB; Sun, 2 Sep 2018 00:15:12 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 180D781D5A; Sun, 2 Sep 2018 00:15:10 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.15.2/8.15.2) with ESMTPS id w8209X5w017671 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Sep 2018 17:09:33 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.15.2/8.15.2/Submit) id w8209WxM017670; Sat, 1 Sep 2018 17:09:32 -0700 (PDT) (envelope-from warlock) Date: Sat, 1 Sep 2018 17:09:32 -0700 From: John Kennedy To: Jonathan Chen Cc: Alex McKeever , FreeBSD Current , FreeBSD Stable Subject: Re: Failing to retrieve source tarballs for anything. Message-ID: <20180902000932.GA47243@phouka1.phouka.net> References: <826294696.2192772.1535822734294.ref@mail.yahoo.com> <826294696.2192772.1535822734294@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailman-Approved-At: Sun, 02 Sep 2018 01:42:53 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 00:15:12 -0000 On Sun, Sep 02, 2018 at 07:58:16AM +1200, Jonathan Chen wrote: > On 2 September 2018 at 05:25, Alex McKeever wrote: > > After compiling PKG, when I go to ports to compile anything (my eMac can run FreeBSD but not modern Linux due to the version of the Radeon GPU) it fails to retrieve any of the source tarballs for any of the software, desktop environments etc. I would like help to fix this, as I???d like to run something current. > > How old is your ports tree? It it up to date? What sort of problems > are you seeing in fetching the port sources? > > Since no one else has reported any problems, it is most likely > something to do with your local environment. Alex, despite what the documentation says, I wouldn't try to build too much using the regular make methods (or portmaster). There are a number of dependencies that are incompatible that you can skate by if you use packages, synth or poudriere. Unless you're going to heavily customize your options, I'd stick with the simplest, packages, until you have a reason not to. FreeBSD 11.2 is stable... what version are you running? If you're running something really old, packages may no longer be offered and you should try to upgrade, but that is a different problem. 11.1 and 10.4 still have some life. As Jonathan noted, having an up-to-date port tree is also important. If it's too old, you may be trying to grab tarballs that no longer exist. Have you looked at chapter 4 of the FreeBSD handbook? https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html One way to update the sources is via the portsnap fetch/extract/update: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html The "binary packages" method is described here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html If you're using packages, and you "pkg upgrade", you'll see something like: root@rpi3:~ # pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking for upgrades (1 candidates): 100% Processing candidates (1 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. My home ISP does something wonky with their DNS and I have some issues with connecting to some resources, but that is trivially solved by changing my DNS server. That typically manifests as unreachable sites or unresolvable hostnames, which might match your symptoms depending on the "fail." From owner-freebsd-current@freebsd.org Sun Sep 2 00:39:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F28CCFD5418 for ; Sun, 2 Sep 2018 00:39:49 +0000 (UTC) (envelope-from alex.mckeever@sbcglobal.net) Received: from sonic316-39.consmr.mail.gq1.yahoo.com (sonic316.consmr.mail.gq1.yahoo.com [98.137.69.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7AE82A55 for ; Sun, 2 Sep 2018 00:39:48 +0000 (UTC) (envelope-from alex.mckeever@sbcglobal.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1535848787; bh=cbSZYIavayfEJok0OwV5CGOmMGDG3bHNJYIK9CKtwus=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=H/E+pPDq0j8MtrUaCjl25UXiwLxKI4UhSF5okvNoxxIa/KOabQl5JFS5SugZ5i6jNlbaUiQa0LRUc04oa1Aj8A7qs3GAFDpIeg2oc2OX84Q2WmZKGFLRfzYb4IGbkmBilthDcw14lxbO9Yqta2487uy/QoCNuny9jNba6vnz4+3d8cC0BxyAdyeEpWiWot5i6yvt+P1PIUVggC2zSdgkAL1NyerzqUjHZr2Sjx/VwuoIsD9rxb6IjuDiMkNM5UXdv4nnxHBh4rXjySEK/tAICnV0t2Trvkj9V86GSNolzKwyQtlu/HZHB1G9ekXE9F8ZHOzb0LbO4RDp9tdyQfRzgQ== X-YMail-OSG: DirL.MQVM1nc0T0lggeBpPRk7z68lnqU2Mo9jCuouMf4pDfqlimmWyunmEeLF_h XCfAsEBgZ7_BXbTLl1QW9lCmHIeBNZYOQtunTJmWy_TaDb1_I8eJaDu3UF9aOUTLvyXWOIWab4Yg a9qIuiUYNI7NoP.lsBrRJJq4x5sJ0AU2vSosfHxEtc.1dQ8RSSjMhznoIdUiWBnvMTZn.GbJHAdh IRGLf5CE2dLRnOzlW.y9kurn4okCbsrJ5o2i8C20Oq3PS3pP__AdzET0KkAUk6fZ85TDlsXLTREA .vanvkaToBft3rDagMCsWlxchVEXYlnCi0Nji5Gy4xNJq3SnVnXVf3nc5OactjYECzZpxRBgA7eM nkJTZK9gDYm8a6ZTKhc3B1k9q_QkM6mTbbj_k2ccLkjvxGa57UthLJxnBX92mkwgPpfXCTrmjoiM HTIQDRFWPrxnfSymxrJrP45JsIzGB6V_d8WSxCqse7Kv5ihHaumh2_Es186EkuqGACKAM6k.212T c5bv9sz0.3v4m3ne5cQZk.CauW3m6G1V8UzqijLygCLVAIUyGQBjQU9NmWIF6bENx8lQ2Q_.fVhn 5dESEv3KuDTX1YquDWyz3yRTPO0wqc2kuoOw6fE1v._bC.nttd86P6yfdyFTlcDe8opbP2tMXUY. XXX2XhvRAEq5g0dnYGy7cQyoNncENR1H45hrZDQZ30KM2sZbVZ3HKTVHB1FApAJNz6ZZSPLOwqNV kOeMs92.DOfQ6cfbD0XcQ7NAbHshy.BJ1k7VQDUclR6l6CqgWrb6nfsmYzJmXPLkx1T5AIsL8yVd 3ehR3EeWV17eD.g4p6jBu8cy54V7sW05u9rRfznrd.b9lWDYkcJtmZgWVNurh5oydWPfrrbAPzoq F_F4NugTz4Tyxb.Q1VBoh6y0i0dnJQKHH3x4M.S_RKwkfX4WA.t2t8DD9mIBlaP7KhRUXTEyVP9l 4xTscdvEP9Di7nd9BlsJL5FuhVkbwLTq4WHOfAHq_Qc1QGoltQMCmW4qY_ho5f.wG8DMvRIKuo5F kr21udqbEBBdW_E1L_4W9PqrtNQxzsRbUs4XUY9.VIw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Sep 2018 00:39:47 +0000 Received: from 52.125.136.120 (EHLO mail.outlook.com) ([52.125.136.120]) by smtp404.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ab02bbe3b54674cc96cb7a9502629c0d; Sun, 02 Sep 2018 00:25:38 +0000 (UTC) Date: Sun, 2 Sep 2018 00:25:37 +0000 (UTC) From: Alex McKeever Sender: Alex McKeever To: John Kennedy , Jonathan Chen Cc: FreeBSD Current , FreeBSD Stable Message-ID: <2154F16E8C50A08C.36736E69-DDA8-42FD-8631-E86492151F49@mail.outlook.com> In-Reply-To: <20180902000932.GA47243@phouka1.phouka.net> References: <826294696.2192772.1535822734294.ref@mail.yahoo.com> <826294696.2192772.1535822734294@mail.yahoo.com> <20180902000932.GA47243@phouka1.phouka.net> Subject: Re: Failing to retrieve source tarballs for anything. MIME-Version: 1.0 X-Mailer: Outlook for iOS and Android X-Mailman-Approved-At: Sun, 02 Sep 2018 02:23:52 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 00:39:50 -0000 =20 =20 =20 =20 =20 =20 =09 =09I was running FreeBSD 11.1, as 11.2 has that stupid freezing on cryp= tosoft0 (or whatever that=E2=80=99s called). Will reload FreeBSD 11.1 from = the =E2=80=9CDVD=E2=80=9D when I get home (I am not at home to use it at th= e moment, will be home by sometime Monday.) I currently have a form of Ubun= tu 12.04 loaded on it. =09 =09Get Outlook for iOS =20 =20 On Sat, Sep 1, 2018 at 8:16 PM -0400, "John Kennedy" w= rote: On Sun, Sep 02, 2018 at 07:58:16AM +1200, Jonathan Chen wrote: > On 2 September 2018 at 05:25, Alex McKeever wrote: > > After compiling PKG, when I go to ports to compile anything (my eMac ca= n run FreeBSD but not modern Linux due to the version of the Radeon GPU) it= fails to retrieve any of the source tarballs for any of the software, desk= top environments etc. I would like help to fix this, as I???d like to run s= omething current. >=20 > How old is your ports tree? It it up to date? What sort of problems > are you seeing in fetching the port sources? >=20 > Since no one else has reported any problems, it is most likely > something to do with your local environment. Alex, despite what the documentation says, I wouldn't try to build too much using the regular make methods (or portmaster). There are a number of dependencies that are incompatible that you can skate by if you use package= s, synth or poudriere. Unless you're going to heavily customize your options, I'd stick with the simplest, packages, until you have a reason not to. FreeBSD 11.2 is stable... what version are you running? If you're running something really old, packages may no longer be offered and you should try = to upgrade, but that is a different problem. 11.1 and 10.4 still have some li= fe. As Jonathan noted, having an up-to-date port tree is also important. If it's too old, you may be trying to grab tarballs that no longer exist. Have you looked at chapter 4 of the FreeBSD handbook? https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html One way to update the sources is via the portsnap fetch/extract/update: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html The "binary packages" method is described here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html If you're using packages, and you "pkg upgrade", you'll see something like: =09root@rpi3:~ # pkg upgrade =09Updating FreeBSD repository catalogue... =09FreeBSD repository is up to date. =09All repositories are up to date. =09Checking for upgrades (1 candidates): 100% =09Processing candidates (1 candidates): 100% =09Checking integrity... done (0 conflicting) =09Your packages are up to date. My home ISP does something wonky with their DNS and I have some issues with connecting to some resources, but that is trivially solved by changing my DNS server. That typically manifests as unreachable sites or unresolvable hostnames, which might match your symptoms depending on the "fail." _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Sep 2 08:22:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC5BFE8AD9; Sun, 2 Sep 2018 08:22:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.20]) (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 96A1B8FAD4; Sun, 2 Sep 2018 08:22:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Sun, 2 Sep 2018 10:21:57 +0200 (CEST) From: Ronald Klop To: Alex McKeever , FreeBSD Stable , FreeBSD Current Message-ID: <102862689.39555.1535876517540@localhost> In-Reply-To: <294624069.2289978.1535835996261@mail.yahoo.com> Subject: Re: Failing to retrieve source tarballs for anything. MIME-Version: 1.0 X-Mailer: Realworks (422.9-265200) Importance: Normal X-Priority: 3 (Normal) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 08:22:01 -0000 First guess... Connect a network cable. Please copy-paste the error message in your mail. It helps people helping y= ou. Any relevant message in /var/log/messages?=20 Regards,=20 Ronald. Sorry for top posting, my mobile mail app does this. Van: Alex McKeever Datum: 01 september 2018 23:06 Aan: Ronald Klop , FreeBSD Stable , FreeBSD Current Onderwerp: Re: Failing to retrieve source tarballs for anything. >=20 >=20 >=20 > I simply changed directory to which thing I want to compile in /ports, ru= n the command make install, and after a short while it fails to retrieve th= e source archive (.tar.gz) >=20 >=20 > Sent from Yahoo Mail for iPhone >=20 >=20 > On Saturday, September 1, 2018, 4:56 PM, Ronald Klop wrote: >>=20 >> It helps a lot of you send the exact command you run with the error mess= age. Or all the significant output. >>=20 >>=20 >>=20 >>=20 >> Regards, >> Ronald >>=20 >>=20 >> Van: Alex McKeever >> Datum: 01 september 2018 19:50 >> Aan: FreeBSD Stable , FreeBSD Current >> Onderwerp: Failing to retrieve source tarballs for anything. >>=20 >>>=20 >>> After compiling PKG, when I go to ports to compile anything (my eMac ca= n run FreeBSD but not modern Linux due to the version of the Radeon GPU) it= fails to retrieve any of the source tarballs for any of the software, desk= top environments etc. I would like help to fix this, as I=E2=80=99d like to= run something current. >>>=20 >>>=20 >>> Sent from Yahoo Mail for iPhone >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From owner-freebsd-current@freebsd.org Sun Sep 2 12:17:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA8E5FEDFA0 for ; Sun, 2 Sep 2018 12:17:42 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9D376B52 for ; Sun, 2 Sep 2018 12:17:42 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0F035FEDF9F; Sun, 2 Sep 2018 12:17:42 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7813FEDF9D for ; Sun, 2 Sep 2018 12:17:41 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D88076B51 for ; Sun, 2 Sep 2018 12:17:40 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sun, 02 Sep 2018 14:17:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1535890651; bh=0D6Tazn5IHO1iULUbzRh5Z3eeEarRd8M5lMyB++EAPY=; h=Date:From:To:Subject; b=k/uJpUYIYWen3OEQauIqRjMD7aDIuPmk8RtiweyT/siHukRBcOuOVKrDIewEdZpuX lA0YHGs6xUlkOGI6243eB4kD/t3QglobQLV+fWrGSPiuY/4f4DbIT2q4Xly/mcQQeW In+SMGbCr4ujHafL27Qv7hFk6GazZQ8N+DWskCnyT6U54vK+BCsdWo1pUAc/qQgMhQ ZrTZNg8/chUscgnlTE9LI7WLAvK9xNfJfD/9pXUg7nfAa9SD5eU59qlKkg3InMEGXA aPXAO0DpcdJ+Fblc8MMYEBENzMXeymj6ygfJADljg+ypGMHXpWnuNG9mckC4aIZBon /oFwUZCjrML6A== Message-ID: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: page fault in ip6_output User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 12:17:42 -0000 Hi, -current at r338322 with manually applied r338372 (fix potential data corruption in iflib) and r338416 (re-compute arc size). What worries me a little bit about the validity of this report is the gdb 8.1.1 error when loading the dump/kernel: ---snip--- warning: kld_current_sos: Can't read filename: Unknown error: -1 inferior.c:311: internal-error: struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: . inferior.c:311: internal-error: struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from terminal] Abort trap (core dumped) ---snip--- kernel panic: ---snip--- Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 13 fault virtual address = 0x98 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8068cbf2 stack pointer = 0x28:0xfffffe0128caa510 frame pointer = 0x28:0xfffffe0128caa760 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1658 (isc-worker0003) trap number = 12 panic: page fault cpuid = 5 time = 1535835179 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0128caa1c0 vpanic() at vpanic+0x1a3/frame 0xfffffe0128caa220 panic() at panic+0x43/frame 0xfffffe0128caa280 trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0128caa2d0 trap_pfault() at trap_pfault+0x49/frame 0xfffffe0128caa330 trap() at trap+0x2ba/frame 0xfffffe0128caa440 calltrap() at calltrap+0x8/frame 0xfffffe0128caa440 --- trap 0xc, rip = 0xffffffff8068cbf2, rsp = 0xfffffe0128caa510, rbp = 0xfffffe0128caa760 --- ip6_output() at ip6_output+0xf82/frame 0xfffffe0128caa760 udp6_send() at udp6_send+0x702/frame 0xfffffe0128caa920 sosend_dgram() at sosend_dgram+0x346/frame 0xfffffe0128caa980 kern_sendit() at kern_sendit+0x170/frame 0xfffffe0128caaa10 sendit() at sendit+0x19e/frame 0xfffffe0128caaa60 sys_sendmsg() at sys_sendmsg+0x61/frame 0xfffffe0128caaac0 amd64_syscall() at amd64_syscall+0x254/frame 0xfffffe0128caabf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0128caabf0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x8015adf0a, rsp = 0x7fffdf9f7218, rbp = 0x7fffdf9f7250 --- Uptime: 22h37m4s Dumping 13174 out of 61352 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% ---snip--- I can not reproduce it at will, but it happens often enough (from once a day to several times after each reboot). Can this gdb be trusted? If yes, which frame do you want to see more detailed? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From owner-freebsd-current@freebsd.org Sun Sep 2 14:52:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FBF1FF0FF8 for ; Sun, 2 Sep 2018 14:52:18 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BB77E7B446 for ; Sun, 2 Sep 2018 14:52:17 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7D83DFF0FF7; Sun, 2 Sep 2018 14:52:17 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B8F0FF0FF6 for ; Sun, 2 Sep 2018 14:52:17 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 E50527B444 for ; Sun, 2 Sep 2018 14:52:16 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.0.6] (97-123-187-182.albq.qwest.net [97.123.187.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id A02C81AF510; Sun, 2 Sep 2018 07:19:18 +0000 (UTC) Subject: Re: page fault in ip6_output To: Alexander Leidinger , current@freebsd.org References: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> From: Sean Bruno Openpgp: preference=signencrypt Autocrypt: addr=sbruno@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFk+0UEBCADaf4bgxxKvMOhRV5NPoGWRCCGm49d6+1VFNlQ77WsY/+Zvf95TPULdRlnG w648KfxWt7+O3kdKhdRwnqlXWC7zA2Qt0dRE1yIqOGJ4jp4INvp/bcxWzgr0aoKOjrlnfxRV bh+s0rzdZt6TsNL3cVYxkC8oezjaUkHdW4mFJU249U1QJogkF8g0FeKNfEcjEkwJNX6lQJH+ EzCWT0NCk6J+Xyo+zOOljxPp1OUfdvZi3ulkU/qTZstGVWxFVsP8xQklV/y3AFcbIYx6iGJ4 5L7WuB0IWhO7Z4yHENr8wFaNYwpod9i4egX2BugbrM8pOfhN2/qqdeG1L5LMtXw3yyAhABEB AAHNN1NlYW4gQnJ1bm8gKEZyZWVCU0QgRGV2ZWxvcGVyIEtleSkgPHNicnVub0BmcmVlYnNk Lm9yZz7CwJQEEwEKAD4WIQToxOn4gDUE4eP0ujS95PX+ibX8tgUCWT7RQQIbAwUJBaOagAUL CQgHAwUVCgkICwUWAwIBAAIeAQIXgAAKCRC95PX+ibX8ttKTCACFKzRc56EBAlVotq02EjZP SfX+unlk6AuPBzShxqRxeK+bGYVCigrYd1M8nnskv0dEiZ5iYeND9HIxbpEyopqgpVTibA7w gBXaZ7SOEhNX1wXwg14JrralfSmPFMYni+sWegPMX/zwfAsn1z4mG1Nn44Xqo3o7CfpkMPy6 M5Bow2IDzIhEYISLR+urxs74/aHU35PLtBSDtu18914SEMDdva27MARN8mbeCDbuJVfGCPWy YHuy2t+9u2Zn5Dd+t3sBXLM9gpeaMm+4x6TNPpESygbVdh4tDdjVZ9DK/bWFg0kMgfZoaq6J l0jNsQXrZV3bzYNFbVw04pFcvA2GIJ7xzsBNBFk+0UEBCADIXBmQOaKMHGbc9vwjhV4Oj5aZ DdhNedn12FVeTdOXJvuTOusgxS29lla0RenHGDsgD08UiFpasBXWq/E+BhQ19d+iRbLLR17O KKc1ZGefoVbLARLXD68J5j4XAyK+6k2KqBLlqzAEpHTzsksM9naARkVXiEVcrt6ciw0FSm8n kuK3gDKKe93XfzfP+TQdbvvzJc7Fa+appLbXz61TM1aikaQlda8bWubDegwXbuoJdB34xU1m yjr/N4o+raL0x7QrzdH+wwgrTTo+H4S2c1972Skt5K5tbxLowfHicRl23V8itVQr3sBtlX4+ 66q+Apm7+R36bUS/k+G45Sp6iPpxABEBAAHCwHwEGAEKACYWIQToxOn4gDUE4eP0ujS95PX+ ibX8tgUCWT7RQQIbDAUJBaOagAAKCRC95PX+ibX8trrIB/9Pljqt/JGamD9tx4dOVmxSyFg9 z2xzgklTLuDgS73MM120mM7ao9AQUeWiSle/H0UCK7xPOzC/aeUC4oygDQKAfkkNbCNTo3+A qDjBRA8qx0e9a/QjDL+RFgD4L5kLT4tToY8T8HaBp8h03LBfk510IaI8oL/Jg7vpM3PDtJMW tUi2H+yNFmL3NfM2oBToWKLFsoP54f/eeeImrNnrlLjLHPzqS+/9apgYqX2Jwiv3tHBc4FTO GuY8VvF7BpixJs8Pc2RUuCfSyodrp1YG1kRGlXAH0cqwwr0Zmk4+7dZvtVQMCl6kS6q1+84q JwtItxS2eXSEA4NO0sQ3BXUywANh Message-ID: <53454938-96fc-a45a-9f3a-996024816bd7@freebsd.org> Date: Sun, 2 Sep 2018 08:52:11 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CVGemNnLlGyPw7LKSfniGC439LwlmN9Q6" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 14:52:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CVGemNnLlGyPw7LKSfniGC439LwlmN9Q6 Content-Type: multipart/mixed; boundary="FZIK4wQSdgIWl6SUCMLvYStEIffvSBTKe"; protected-headers="v1" From: Sean Bruno To: Alexander Leidinger , current@freebsd.org Message-ID: <53454938-96fc-a45a-9f3a-996024816bd7@freebsd.org> Subject: Re: page fault in ip6_output References: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> In-Reply-To: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> --FZIK4wQSdgIWl6SUCMLvYStEIffvSBTKe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/2/18 6:17 AM, Alexander Leidinger wrote: > Hi, >=20 > -current at r338322 with manually applied r338372 (fix potential data > corruption in iflib) and r338416 (re-compute arc size). >=20 > What worries me a little bit about the validity of this report is the > gdb 8.1.1 error when loading the dump/kernel: > ---snip--- > warning: kld_current_sos: Can't read filename: Unknown error: -1 >=20 > inferior.c:311: internal-error: struct inferior *find_inferior_pid(int)= : > Assertion `pid !=3D 0' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) [answered Y; input not from termi= nal] >=20 > This is a bug, please report it.=C2=A0 For instructions, see: > . >=20 > inferior.c:311: internal-error: struct inferior *find_inferior_pid(int)= : > Assertion `pid !=3D 0' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) [answered Y; input not from termina= l] > Abort trap (core dumped) > ---snip--- >=20 > kernel panic: > ---snip--- > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 5; apic id =3D 13 > fault virtual address=C2=A0=C2=A0 =3D 0x98 > fault code=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =3D supervisor read data, page not present > instruction pointer=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x20:0xffffffff8068cbf2= > stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe0128caa510 > frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =3D 0x28:0xfffffe0128caa760 > code segment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =3D base 0x0, limit 0xfffff, type 0x1b > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D DP= L 0, pres 1, long 1, def32 0, gran 1 > processor eflags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D interrup= t enabled, resume, IOPL =3D 0 > current process=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 165= 8 (isc-worker0003) > trap number=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =3D 12 > panic: page fault > cpuid =3D 5 > time =3D 1535835179 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0128caa1c0 > vpanic() at vpanic+0x1a3/frame 0xfffffe0128caa220 > panic() at panic+0x43/frame 0xfffffe0128caa280 > trap_fatal() at trap_fatal+0x35f/frame 0xfffffe0128caa2d0 > trap_pfault() at trap_pfault+0x49/frame 0xfffffe0128caa330 > trap() at trap+0x2ba/frame 0xfffffe0128caa440 > calltrap() at calltrap+0x8/frame 0xfffffe0128caa440 > --- trap 0xc, rip =3D 0xffffffff8068cbf2, rsp =3D 0xfffffe0128caa510, r= bp =3D > 0xfffffe0128caa760 --- > ip6_output() at ip6_output+0xf82/frame 0xfffffe0128caa760 > udp6_send() at udp6_send+0x702/frame 0xfffffe0128caa920 > sosend_dgram() at sosend_dgram+0x346/frame 0xfffffe0128caa980 > kern_sendit() at kern_sendit+0x170/frame 0xfffffe0128caaa10 > sendit() at sendit+0x19e/frame 0xfffffe0128caaa60 > sys_sendmsg() at sys_sendmsg+0x61/frame 0xfffffe0128caaac0 > amd64_syscall() at amd64_syscall+0x254/frame 0xfffffe0128caabf0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0128ca= abf0 > --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip =3D 0x8015adf0a, rsp = =3D > 0x7fffdf9f7218, rbp =3D 0x7fffdf9f7250 --- > Uptime: 22h37m4s > Dumping 13174 out of 61352 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > ---snip--- >=20 > I can not reproduce it at will, but it happens often enough (from once = a > day to several times after each reboot). >=20 > Can this gdb be trusted? If yes, which frame do you want to see more > detailed? >=20 > Bye, > Alexander. >=20 I think, you have hit this, no? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230950 --FZIK4wQSdgIWl6SUCMLvYStEIffvSBTKe-- --CVGemNnLlGyPw7LKSfniGC439LwlmN9Q6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE6MTp+IA1BOHj9Lo0veT1/om1/LYFAluL+RtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU4 QzRFOUY4ODAzNTA0RTFFM0Y0QkEzNEJERTRGNUZFODlCNUZDQjYACgkQveT1/om1 /LZLFQf/asLxDeJsKk5yZVY4Lk90Wlqlbmc2Afu/Y6S+aS+Vdi56w5QsSr5nS17b kGiZGlt95EvUpPr+flEw6XYd/SRnfVNnYNghEY2sEfDSZ/vm/O3WbV+Pm1/GkMLU +OSci/JR/2hNu9r/i/Aq8AwCa601iUWei2HESoHBGGgC7dq90vXAGTRAYUqoN557 Q1d7EdLYaz6M/dyB7Mdo2AWmZPZI6ERsTdmyan5dqTC5kUgsfB0PhlGid+PHfL+b 7EswMAhaBCkC0aT9HJjlCA3J1pzA1pffKSXbtpuToCPbn2Tn5kqMeiln5vO2GDDW jTMAwc5JMbfVIgO/OJFTI+rVaLUnRw== =zi8+ -----END PGP SIGNATURE----- --CVGemNnLlGyPw7LKSfniGC439LwlmN9Q6-- From owner-freebsd-current@freebsd.org Sun Sep 2 14:52:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5595FF1045 for ; Sun, 2 Sep 2018 14:52:50 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from gate.utahime.jp (ipq210.utahime.jp [183.180.29.210]) by mx1.freebsd.org (Postfix) with ESMTP id 63FF57B4CC for ; Sun, 2 Sep 2018 14:52:49 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) by gate.utahime.jp (Postfix) with ESMTP id 7BCEC1BA74; Sun, 2 Sep 2018 23:52:41 +0900 (JST) Received: from eastasia.home.utahime.org (localhost [127.0.0.1]) by localhost-backdoor.home.utahime.org (Postfix) with ESMTP id 02AC434093; Sun, 2 Sep 2018 23:52:41 +0900 (JST) Received: from localhost (rolling.home.utahime.org [192.168.174.11]) by eastasia.home.utahime.org (Postfix) with ESMTPSA id EE98034092; Sun, 2 Sep 2018 23:52:38 +0900 (JST) Date: Sun, 02 Sep 2018 23:51:45 +0900 (JST) Message-Id: <20180902.235145.884190297314863097.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Fatal trap 9 when rebooting after installkernel on VirtualBox VM From: Yasuhiro KIMURA X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 14:52:51 -0000 Hello. I'm tracking head with VirtualBox VM. Everytime new snapshot is released I update to same revision. So buildworld, buildkernel and installkernel always completes sucsessfully. But when rebooting system always crashes with 'Fatal trap 9: general protection fault while in kernel mode' message. And I closed VM window and restart VM, new kernel start up without any problem. https://www.utahime.org/FreeBSD/VirtualBox_FreeBSD_12.0-ALPHA3.png This is a screenshot of latest update (ALPHA3 -> ALPHA4). Does anyone else experienced it? Conditions about VM and host are following: VM: CPU: x4 Memory: 8GB Disk: 100GB SATA Host: CPU: Intel Core i7 4770S Memory: 16GB Disk: 2TB SATA OS: 64bit Windows 10 Enterprise 1803 Best Regards. --- Yasuhiro KIMURA From owner-freebsd-current@freebsd.org Sun Sep 2 18:22:12 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01288FF5C43 for ; Sun, 2 Sep 2018 18:22:12 +0000 (UTC) (envelope-from lrx337@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9361C8231E for ; Sun, 2 Sep 2018 18:22:11 +0000 (UTC) (envelope-from lrx337@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id h1-v6so12970608itj.4 for ; Sun, 02 Sep 2018 11:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vxzYdWH5vognXfnLOgQbTCTET1KLowqrTjcrn80eH4Q=; b=nyP2F+A4Flvjwy7x3THQNjMsQ2Fqr9ngatbaHm9L+v/1TRX1h0LHQN3ocC5u3bZYG3 jPiTGR8tdp8ttYxf/LdMHgUYavyXba+rKOeXuliqn/fR1KVTtCp+dPgmU5kPc45nTv6v Dh+oBVCeGUk2dgLea/Hq3EiUC+Y29dYn+v+X3TU2UNmX0nXq/spBFuZ7CyJ8WtdO+IZO bScF7t7/AdRSFH5+rnV9Jw0PXhvAvJDSE8ka9AApxiaFXxDhMHD4cCwjoehS9p8w33dv D+n1biwknJm1WYHzLBGQypIFakDbAPbtDhhgxj9b96N717N1GdOSoqPRCNdTh+cNStLi 0F9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vxzYdWH5vognXfnLOgQbTCTET1KLowqrTjcrn80eH4Q=; b=QKGUxpdX2dRtwPDcilAC3oPQD0wjm2hbcUwTmM2ANk2UknaZJ+ICC5VrUHOr95Y074 mUnr5/Vs85PeRPhaovB5J/X+ReNszamr+Ijos/ibksxGAV9lSVWPgIrJ6g0cZT/l2H12 G+4Ar8ZED+t7uHokwPWnoL5r9e1Yt6mI8gnq0gmKe9SPR38j7SEdpaylceGr5bRnykFe XEcLVpswETTiF5jHQYpsJd3KuG6KtGZQl99DXAhZWzfLzt9Au1LzwjWdGvaJ0+lqL2lf smxb6x9CjQgBOihknLIRxjvUiS5XA0P0N9pTUAaKJCXSjwYtHCX5xp22C25OmAmFWAdg cuvg== X-Gm-Message-State: APzg51C1EDmYJX9FBYGAv7YiY6rl5yYd25gr3jR0+OmzffYh7YWYuRQy KIb/kwZ+1KR+Qt2GFEPWFwi8bXF5yPqiCAxId9J4pL+b X-Google-Smtp-Source: ANB0VdaGBbipqo3ZJ+zW0OH4dMMkD5djAkrpr+FYX2NYIRsHO3YL3gykkPxMpPxrW+YCrXjQ4SBc2lPMasLW31EhRMQ= X-Received: by 2002:a02:9832:: with SMTP id t47-v6mr17956862jaj.137.1535912530552; Sun, 02 Sep 2018 11:22:10 -0700 (PDT) MIME-Version: 1.0 From: lr x Date: Sun, 2 Sep 2018 14:21:59 -0400 Message-ID: Subject: Kernel panic: Need help debugging To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 18:22:12 -0000 Hi! I can get the kernel to panic when I try to run virtualbox (selecting the amd64 ubuntu iso and attaching to virtual machine and starting it up.). The kernel: 12.0-ALPHA3 FreeBSD 12.0-ALPHA3 #0 r338359: Wed Aug 29 21:49:53 EDT 2018 someone@somebox:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Virtualbox was installed with pkg install virtualbox-ose I have access to the crash dump, but running with kgdb does not reveal more information. I found a reference to the panic string: https://reviews.freebsd.org/D4197 . I could find that the panic string is indeed printed in the malloc_dbg function in the /sys/kern/kern_malloc.c file. How can I trace this further to understand why the kernel lands in such a situation? Thanks! Here are the contents of the info.last file and kgdb invocation on the crash dump. # cat /var/crash/info.last Dump header from device: /dev/ada0p4 Architecture: amd64 Architecture Version: 2 Dump Length: 937099264 Blocksize: 512 Compression: none Dumptime: Sat Sep 1 22:50:57 2018 Hostname: somebox Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.0-ALPHA3 #0 r338359: Wed Aug 29 21:49:53 EDT 2018 someone@somebox:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Panic String: malloc: called with spinlock or critical section held Dump Parity: 274387030 Bounds: 3 Dump Status: good root@somebox:/usr/src # kgdb -n 3 <..snip..> Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x80a851ab8 fault code = supervisor read data, protection violation instruction pointer = 0x20:0xffffffff8354b2e4 stack pointer = 0x28:0xfffffe008ced1200 frame pointer = 0x28:0xfffffe008ced1200 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1792 (VirtualBox) Uptime: 48m52s (ada0:ahcich2:0:0:0): spin-down Dumping 893 out of 16221 MB:..2%..11%..22%..31%..42%..51%..61%..72%..81%..92% #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1383 1383 CPU_SET_ATOMIC(cpu, &stopped_cpus); (kgdb) bt #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1383 #1 0xffffffff811d1484 in ipi_nmi_handler () at /usr/src/sys/x86/x86/mp_x86.c:1341 #2 0xffffffff8105d889 in trap (frame=0xffffffff82057db0) at /usr/src/sys/amd64/amd64/trap.c:206 #3 0xffffffff8103baad in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:776 #4 0xffffffff811c1f76 in cpu_idle (busy=) at /usr/src/sys/x86/x86/cpu_machdep.c:489 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-current@freebsd.org Sun Sep 2 20:24:23 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD20EFF8DE4 for ; Sun, 2 Sep 2018 20:24:23 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73736862D9 for ; Sun, 2 Sep 2018 20:24:23 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sun, 02 Sep 2018 22:24:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1535919861; bh=4wvZybucday/cDfgwFPEiYLluc6mqV14tnMx3weT/JM=; h=Date:From:To:Subject:References:In-Reply-To; b=gAQS4qblrMJrztsZ740AQhz4QqBFxYh98xzEut1po8/3fO0GsZ08YVIMu7XkGSbJ4 +nsB9nI2YrkdoQ7lFbCrvA2hnqMkSCAxyKeRrcTt8kVVnDvZYnahf96UoyzW+4s+d8 XsMKO9y/333lUFq+Us+28iKB0c0lcmnIKs32CMpJHCWEhAn4Slq/rnk+C1qUtlQYdN ITzjdaig2bbjf4YO4cemMPMvoEGRwPneL4VsuHbBuZQxQIofTSsCcj9a1pT/g4oLQ6 KuHlztTt2yB43fX48ja1TTI5K7Z/KT47wafUCcgpPFeWqsb4pryDXpPwRjjuBpTlce 0yNCbL6k//URg== Message-ID: <20180902222402.Horde.3oamKcQPAXYZRsE8DNQXLuU@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-current@freebsd.org Subject: Re: page fault in ip6_output References: <20180902141713.Horde.K4sEjBr68eHohodvzTmRRp6@webmail.leidinger.net> <53454938-96fc-a45a-9f3a-996024816bd7@freebsd.org> In-Reply-To: <53454938-96fc-a45a-9f3a-996024816bd7@freebsd.org> User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 20:24:24 -0000 Quoting Sean Bruno (from Sun, 2 Sep 2018 08:52:11 -0600): > I think, you have hit this, no? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230950 Looks like it. I've added me to the CC list of the PR. Thanks, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From owner-freebsd-current@freebsd.org Mon Sep 3 17:41:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A02FEF80B for ; Mon, 3 Sep 2018 17:41:16 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD618D7CB for ; Mon, 3 Sep 2018 17:41:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x541.google.com with SMTP id h33-v6so1323397edb.5 for ; Mon, 03 Sep 2018 10:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=pI2+9rLOuaHvfRzakpqnBZQ9fpRNCym8TpDsWJ8f6fQ=; b=SIRAFKXP9k3YRirkac8F9Mw0rH6rAeyl8AIbP2adVj7gko8TwvrHgE/uSR0WlO1YWc DsU78oxy+keMh+MHjwdRTi9tUGo4Grr8p9nmvacAasMsIw7KfdjP0idIT+r7umU0uE12 tIX+jNYGpc3wSfIPttgLowuYY7wDygtd7QTAF8vIkvKYoT97qu5E5MLPxGnIv4D/2Z1u EWjzM8i4IlPGNkhXHoE22cZmUb7RGxhg+uD3YjaUm0UMZCknIaNLlB5TXM0+0HNLo2+V qzjlhMXzTYbIuXlGN7tKLtRLN4xPlAV2Q1O2Z0n2HqpxzRyjcR6zVja4WsNPbD36oeeh MnMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=pI2+9rLOuaHvfRzakpqnBZQ9fpRNCym8TpDsWJ8f6fQ=; b=phiXg8bO4Z2iCvO5qsk/lgrI3vEO0qFLQ3gAb4nCPPMs/lQa+IvwgQN3lUua5TFhzb pdUEZIYfUxfqIY2oWSD3au+4GLwShi+V9ckrnR+1VR6yoMpOIZ0EEPxg5uDFiNANjqo/ OcBnzPf8n7Isg0ggfMYZ+yq653DIzTCQfGQVsr44gRvxbWE++2LpISWhSqvarS/PuDgI C6ZTM85ZsZKV0b7y5x7mcwsUnNHb65SMerHmKQFIM+Ufp0qBJUhteYyr5U76NuzrXK6J BUHWbnsyGDYuL898rBTX8ZolgNPUVjOmVQ2mwaDWte5lDA/vn+DQASlKWvzFOSOYcTAX Y5Ow== X-Gm-Message-State: APzg51D6vL+l9HQjFghdCG+Jt9b/BssB9p1U+V7IDvt/79iPaH0IFWzq wQkgSxmgR0MB88yfn1zO3SOfVdVmW8TbXNbxhrW1GECWS5aWfSc0mUBUwPW2bYhbGMI/vR0FvV0 YZXVuUHgDWBwBBWJ6huqlzyqYRym//A6ug3Ub6xFPZ62GCM5x6iQRIWbDxafXutEE0uXewAcwBD fi49upTnQI/w== X-Google-Smtp-Source: ANB0VdYhCrg5qo/uyXq2cA+PEyNgZnGNmJ44jV1vE37kePdu3KycAEH3mZuxC9hY40BBfG99CDll7A== X-Received: by 2002:a50:91da:: with SMTP id h26-v6mr31975939eda.87.1535996474501; Mon, 03 Sep 2018 10:41:14 -0700 (PDT) Received: from mutt-hbsd (tollana.enn.lu. [85.248.227.164]) by smtp.gmail.com with ESMTPSA id e38-v6sm9276243eda.74.2018.09.03.10.41.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 10:41:13 -0700 (PDT) Date: Mon, 3 Sep 2018 13:40:16 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Subject: redzone catching a buffer overflow in swapoff_one Message-ID: <20180903174016.5ofc4p27vilkf2yk@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qjvjxznausameasf" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 17:41:17 -0000 --qjvjxznausameasf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm unsure whether this is a false positive or true positive, but it looks like there may be a buffer overflow in swapoff_one: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] REDZONE: Buffer overflow dete= cted. 16 bytes corrupted after 0xfffffe1fe0023248 (2237000 bytes allocated). Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Allocation backtrace: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e188e1 at redz= one_setup+0xe1 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac8007 at mall= oc+0x1d7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80b1f449 at blis= t_create+0x99 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1daa7 at swap= onsomething+0xe7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1c233 at sys_= swapon+0x413 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80fc0e5e at amd6= 4_syscall+0x29e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80f9dc9d at fast= _syscall_common+0x101 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Free backtrace: Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e18c28 at redz= one_check+0x2f8 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac85af at free= _dbg+0x5f Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80ac84aa at free= +0x1a Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1cae5 at swap= off_one+0x675 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1cc57 at swap= off_all+0xd7 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80b9991a at bufs= hutdown+0x2ca Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80aec36e at kern= _reboot+0x21e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #7 0xffffffff80aec0f9 at sys_= reboot+0x3a9 Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #8 0xffffffff80fc0e5e at amd6= 4_syscall+0x29e Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #9 0xffffffff80f9dc9d at fast= _syscall_common+0x101 Of course, I'm running HardenedBSD 12-CURRENT/amd64. I've synced with FreeBSD at this commit: https://github.com/freebsd/freebsd/commit/2f2449cc1cdfc19ae34b2317e792af489= 418a01a So my src tree is at this commit: https://github.com/HardenedBSD/hardenedBSD/commit/98f90fadab000b818a731be46= 50ac1a47144501c I've not yet studied the swap pager's code and plan to start learning it soon. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --qjvjxznausameasf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluNcfkACgkQaoRlj1JF bu5VFQ//QvBobvIgtfcZAj0QIOBjdijDCkerzBbZTfaPd1DXSf9pKo1IjGcIsuUr Uj9c69PdM/aFHjpb1CSxurpGJfYsEWCDUg+3LkJhtYGB5YdeB7ClfA3R9QU2ZDOo ZjK8dpKDJJP0a4fv/xLxugzP31UOe8z0jpwtGQJX1Agkg4Rf2ncyIsqwEaprNphY XzfIVr62k4kmA4LyQL6quYqDgdmi4AGLK9Qf3FW5d91l9ivQKIA1tKg40g8l4+xo sgdK+sbzxpnhXZusH1P592nWzdvxPcyu/K74s39BNEAaBdqZqNq8cg2YrEgkayC6 D2tkLQYAEKsZa9V4qw7oq8LrHuFDxfqEQ6VYyx1OV1jJ1MA4aTayAxh6B7N7cDEg Gyj7mZG0bUzxa8IV7O/CgnGJLGQH9vVDSfvNCXVEgRXZLWkVmOQlAl0NAT2qnGRF /O2A6iDiXi+To5oqPlVYRDzfjZMi5YEaRPpzCoo7y2OND/xh9yfcD8ezJJHHSZEC zGAX8Z7mGqu1+ln4ef2oSJgvkiZnu57SOLJZRqUH9XZGRnzRdZjOESoCooTeYAve 7ruUaQIWIkeL96DHV+TJ2aZmCGrwOwAfU3SOADjD4eb323jUmeSonkO7qL4leCuX yxCZWCSEn68J57schs5KqhbjH2ohdHQ1jzNrBCNVYd1TxXCy/04= =oXx/ -----END PGP SIGNATURE----- --qjvjxznausameasf-- From owner-freebsd-current@freebsd.org Mon Sep 3 18:51:39 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E3BBFF1E87 for ; Mon, 3 Sep 2018 18:51:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0834D7091E for ; Mon, 3 Sep 2018 18:51:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52d.google.com with SMTP id x26-v6so489877pge.12 for ; Mon, 03 Sep 2018 11:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=K46mgCjFRZY0PRumHf/6VfpySNA+SoQY00i0DKRNifc=; b=DKNI4KwBCtXPg6SlyTUD2Z4FjT45y1kvTPUc4HRJ4r5GntihA2mON1+BzTPzOLH+8S wjyD634MvVR9snQFIro+SH+cBjlH6W2KJdApIZ0v8LAblVwJCvblqY/wvBmV4GQfUt+6 SRAEvUjGLZKFvgeE1G5ruI27WRiEFDoc8KgrYfgOvf8YpJXG/zGK6rW/oYpZzhQ905U9 Q/N29PRb5u/rZae1LiVSknRMYkojZkJoL19agfdy10jtNT04MK2z6D/W9rrQOrxdHYjP mtuA6n79vqYw4hbBXi0Fmddx1BybK/o3V10t2+ALk/ucrzDxUD/J8aqKPwkX4++zO8mX Utqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=K46mgCjFRZY0PRumHf/6VfpySNA+SoQY00i0DKRNifc=; b=tbdRAuKt39OXk2y/kOpMktSw0ChRmyUPFgypWeWDZLOAApeZhMYjnlCMJK3DbBWRn5 U23aWYaoptSP/6WO2VEOT0H2Heq7y1t+/ZiPslJelcJLpm2q9JoOGcm7CHJKdGBxHodU yj+OL7LkUFwGcqVMS5r8LOvLT3Gwz4IKERuJb+aq4YE+UHHUnPyaQHWqvHcdiDJV4Q6F 6yx1zoXX+e28tjTgbKCe3fupR0WaLPtbZwZGHleNhPqnRfw9ycgOVxK0DmitcfHW1UcO ACmaKEIrxVcZroDEtdsEVyjIPcY9D8WLNVHIoGkb4+GIFMIX+0rFWkzSgIcCFjdko8M3 zhzQ== X-Gm-Message-State: APzg51D85E2pt96nDZElPaqUXcKF5TzJi0RDomWMp/zbFbD1h7O6MUkd Dni0oqBd3eUTq8wA13Fjho7WnMcw X-Google-Smtp-Source: ANB0VdYrLdp/BEaR0o+V+eIM2740h2IpL4TViiUzl4QIuN6Y1vox+U8sj//YbT24aB23WIwdqLm0Bg== X-Received: by 2002:a62:c0a:: with SMTP id u10-v6mr30974315pfi.43.1536000697764; Mon, 03 Sep 2018 11:51:37 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id g7-v6sm23646367pfi.175.2018.09.03.11.51.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 11:51:36 -0700 (PDT) Sender: Mark Johnston Date: Mon, 3 Sep 2018 14:51:34 -0400 From: Mark Johnston To: Shawn Webb Cc: freebsd-current@freebsd.org Subject: Re: redzone catching a buffer overflow in swapoff_one Message-ID: <20180903185134.GD2751@raichu> References: <20180903174016.5ofc4p27vilkf2yk@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180903174016.5ofc4p27vilkf2yk@mutt-hbsd> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 18:51:39 -0000 On Mon, Sep 03, 2018 at 01:40:16PM -0400, Shawn Webb wrote: > I'm unsure whether this is a false positive or true positive, but it > looks like there may be a buffer overflow in swapoff_one: > > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] REDZONE: Buffer overflow detected. 16 bytes corrupted after 0xfffffe1fe0023248 (2237000 bytes allocated). > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Allocation backtrace: > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e188e1 at redzone_setup+0xe1 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac8007 at malloc+0x1d7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80b1f449 at blist_create+0x99 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1daa7 at swaponsomething+0xe7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1c233 at sys_swapon+0x413 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80fc0e5e at amd64_syscall+0x29e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80f9dc9d at fast_syscall_common+0x101 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Free backtrace: > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e18c28 at redzone_check+0x2f8 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac85af at free_dbg+0x5f > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80ac84aa at free+0x1a > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1cae5 at swapoff_one+0x675 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1cc57 at swapoff_all+0xd7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80b9991a at bufshutdown+0x2ca > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80aec36e at kern_reboot+0x21e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #7 0xffffffff80aec0f9 at sys_reboot+0x3a9 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #8 0xffffffff80fc0e5e at amd64_syscall+0x29e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #9 0xffffffff80f9dc9d at fast_syscall_common+0x101 > > Of course, I'm running HardenedBSD 12-CURRENT/amd64. I've synced with > FreeBSD at this commit: > https://github.com/freebsd/freebsd/commit/2f2449cc1cdfc19ae34b2317e792af489418a01a > > So my src tree is at this commit: > https://github.com/HardenedBSD/hardenedBSD/commit/98f90fadab000b818a731be4650ac1a47144501c > > I've not yet studied the swap pager's code and plan to start learning > it soon. See PR 231116. From owner-freebsd-current@freebsd.org Mon Sep 3 20:09:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54F16FF4BBD for ; Mon, 3 Sep 2018 20:09:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E09CD749CE for ; Mon, 3 Sep 2018 20:09:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MN7FMNQVM1kSys9JEBc1Djb_MTP.KIIBf2qv8S915XQKi.ztU.0g.SIQxvOySuT lRT_Im1iN522WZmh96GKijjxkMdQPWSVXn14duF1H5BHUcrFq.dAcKLuhltGDOnO5y4TLdO5kfVs Vrmj_ZHlHuJBq4.bDy3ZtgK25wGKRm59.1tJq0EYGTHAUhUQRjBj4DOr9XRJxgfVKEKSMFrMvJ1x OvyZtTcgxA7Rqzne_2PJ6VnkCh0X1QgCaYdjqI35PnoAJvm_jTS__a6ONIjWDu0FbjKDwKrT5XG3 77ZZAmOLH0s1cvbNkvsgBdOIpogbOWNOo9_wfOq48zz6l47H.GhVZxN70EconaUnMecKyS7vvU3E tqcCs8e8Sar7dtAqFDD1mnjECvK4CnBfRz2SmmpSGK3KKv5KFd30iiwJzBjmGf.vprpKzjVEqPBD wS_O.LRMUZM15visu4alQqSPJ_U7K.9DiNcYaT9GVWmct3Tyfg9B86zY6ma5cty9UHg08vxQeNvC WTB5dRPfiEkzQxWpST.LSusmlUfTaDL5AYLMs2hmTY2HMWlDwOkpIspQJtEYhULOFDeiWh6ybgET yM6Mg1XbThD6yCs3hBmt.vBfr0NguZa.esvX2sne17H7Zi1LlGXBBP0skEY5RIwYrgzCqUZfRRu6 D3v8qnMdJ6.CLQEOjQPVuTT32nz9tNsqHkaEBuiz0RcsGhjLcn8jxnpcsJIqhWRXHBZx9tHOeQ50 HboaBRb5tp1U3SMz1NgRFuIcwvMN5v9H4lhsTwEs8Ek0zqSM5NwG8kpxR0wCtd1kWCa576TU5St6 _dcblbCx4ki5ZIdHlUAFGEf5Q5H_WPzb5L4dNzazUc8DADK_SApDOpB2j83L5kuEtKhYj4RA2PsZ 96krJb_Nhbln6wyUnlTmPSu_NK7d0CTnr5_jqKXK0JYI.uNFPd6R.LEqDp8L1QnaOwWBmo4txHzv _3KkxPDzjF9pM6KqKQ.p.fRUzGxfpCBHQtuIjnGrxjuuFDHUdZhLEZ8EGSl7gkH_Gz34JYHlefRv 2pxeKEt9NlYS3KZY4Zl1MR2XESIFdMPTNxtif Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Mon, 3 Sep 2018 20:09:44 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cca6ca55a93d0a3e9c66c37ced0f1d1b; Mon, 03 Sep 2018 20:09:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: redzone catching a buffer overflow in swapoff_one Message-Id: <74FA848C-A569-463A-810D-E19567A9616F@yahoo.com> Date: Mon, 3 Sep 2018 13:09:39 -0700 To: shawn.webb@ardenedbsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 20:09:45 -0000 Shawn Webb shawn.webb at hardenedbsd.org wrote on Mon Sep 3 17:41:17 UTC 2018 : > I'm unsure whether this is a false positive or true positive, but it > looks like there may be a buffer overflow in swapoff_one: >=20 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] REDZONE: Buffer overflow = detected. 16 bytes corrupted after 0xfffffe1fe0023248 (2237000 bytes = allocated). > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Allocation backtrace: > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e188e1 at = redzone_setup+0xe1 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac8007 at = malloc+0x1d7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80b1f449 at = blist_create+0x99 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1daa7 at = swaponsomething+0xe7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1c233 at = sys_swapon+0x413 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80fc0e5e at = amd64_syscall+0x29e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80f9dc9d at = fast_syscall_common+0x101 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] Free backtrace: > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #0 0xffffffff80e18c28 at = redzone_check+0x2f8 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #1 0xffffffff80ac85af at = free_dbg+0x5f > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #2 0xffffffff80ac84aa at = free+0x1a > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #3 0xffffffff80e1cae5 at = swapoff_one+0x675 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #4 0xffffffff80e1cc57 at = swapoff_all+0xd7 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #5 0xffffffff80b9991a at = bufshutdown+0x2ca > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #6 0xffffffff80aec36e at = kern_reboot+0x21e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #7 0xffffffff80aec0f9 at = sys_reboot+0x3a9 > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #8 0xffffffff80fc0e5e at = amd64_syscall+0x29e > Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #9 0xffffffff80f9dc9d at = fast_syscall_common+0x101 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231116 for "Out of bounds memory access in blist_create()" with a Mark Johnston patch in Comment #2. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Sep 3 20:58:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A130AFF6525 for ; Mon, 3 Sep 2018 20:58:33 +0000 (UTC) (envelope-from jake@jkchamp.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4219676600 for ; Mon, 3 Sep 2018 20:58:33 +0000 (UTC) (envelope-from jake@jkchamp.com) Received: by mail-qt0-x22d.google.com with SMTP id r37-v6so1845710qtc.0 for ; Mon, 03 Sep 2018 13:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkchamp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=h6Uh/AW/VZMl57Ki2B89MqO8HEOi30te2VOdfot7hG0=; b=xo1kXAroyq/hatKI0Bti1WC0LNon0juJFFQUObjuoI2l0iSyP03SmFrx21Q8v0sa7G zJgNs3xDxl/qH5N0/V6Xbqt1Xikh3+SCge8zNcd4RKeE4/3PMir3xZ/x8Sux10JLUVRx 6krMPXdGWAR4TsaV3SOrNk4kQ5xioYwGL6RcoijVGurO5oveoHbHNByBQG7qUpk8VQ2J 8oHFrgHhtPV2j0/sfcAVFiP/NtseetwTSoTahAVR/gpjpKKESqYI9wBaEF3wDb1TWGDK jjp0DiIkcWGsU1nnECTX16+1gInhbvbfl4nGXBduJYdgwTNNbcJmZAd8cGGKPVQx+Xuo czCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=h6Uh/AW/VZMl57Ki2B89MqO8HEOi30te2VOdfot7hG0=; b=lUNGXQLupgqMT4gTdonBveF5inN9hYem8roIS2VOefykgMhtEAWFOjZUL0TmQ5jc6k OOrmhxAVHChRveYvpOeoFazJx6EMuCHwmvk20ScWG1oe78iA89YqD6b7EjTuJJSh9kHz 8ua/nHBlO9zONxM6fIzRToXOCCrM+llGVnUOa0U/Cj9FqoE2S3H4j/Z329sO0QrNXRkR hnCdVhHZ6eYcEK0BJc1qsI+Kec1g1mE6YRh5LyvmOhPKEEgRb26sHRkrw5BtdRJKNI4F M/vaJI8pYqSs9m9S5iPBUIQpzDQMr9rk1zpB6ho1xmXyr8fhkkRCMKMY3mYUgIbYIHt0 ujhQ== X-Gm-Message-State: APzg51D9JScW8JFeR3hEyy9mHy0MJ2LAhF3FjIzjYyukWRuctLi4ChWf YWXYZ3Ok49u5gMWq0OBKEf1wuh7s/sTPs8GUcAh6EAvjCUk= X-Google-Smtp-Source: ANB0VdbBoxmT5/91ehV7aZzyUlngMyhKGVzG4JlZQiwq4rKip/bkiOspSkW3gN+lLE/z7mHB/dvOawt2n68BpLJ70Ho= X-Received: by 2002:ac8:6a05:: with SMTP id t5-v6mr27959622qtr.249.1536008312232; Mon, 03 Sep 2018 13:58:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:c502:0:0:0:0:0 with HTTP; Mon, 3 Sep 2018 13:58:31 -0700 (PDT) From: Jake Champlin Date: Mon, 3 Sep 2018 16:58:31 -0400 Message-ID: Subject: FreeBSD -CURRENT on AMD Ryzen5 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 20:58:33 -0000 Testing out various BSD's with a Huawei Matebook D, and FreeBSD -CURRENT is failing to boot from an installer image. No serial console, so unable to grab full boot output, any other info or boot flags that would help would be awesome. https://i.imgur.com/WAqwbza.jpg, shows where boot process hangs, and fails to move past. Thanks From owner-freebsd-current@freebsd.org Mon Sep 3 23:25:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47B1AFF9789 for ; Mon, 3 Sep 2018 23:25:30 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id D81DB7ACEB for ; Mon, 3 Sep 2018 23:25:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 8F307A66 for ; Tue, 4 Sep 2018 02:25:22 +0300 (MSK) Date: Tue, 4 Sep 2018 02:25:21 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1759359118.20180904022521@serebryakov.spb.ru> To: FreeBSD Current Subject: Re: Regression: ALPHA3 can not properly init diskless / nanobsd system (mdmfs or mknewfs or md is broken?) In-Reply-To: <606629823.20180901023912@serebryakov.spb.ru> References: <606629823.20180901023912@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 23:25:30 -0000 Hello Lev, Saturday, September 1, 2018, 2:39:12 AM, you wrote: > I have NanoBSD system built from and it works. It creates THREE memory > filesystems, as needed: > % mount | grep /dev/md > /dev/md0 on /etc (ufs, local) > /dev/md1 on /var (ufs, local) > /dev/md2 on /var/tmp (ufs, local) > % > But same system built from ALPHA3 sources (r338399 to be exact) doesn't > create /etc in-memory overlay, and can not copy SSHD keys and create > host.conf. After that sshd could not start. > New version doesn't properly create overlay for /etc: > % mount | grep /dev/md > /dev/md1 on /var (ufs, local) > /dev/md2 on /var/tmp (ufs, local) > % I've get log from boot, but it is not very informative: arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache random: read_random_uio unblock wait random: read_random_uio unblock wait random: unblocking device. mdmfs: mount exited with error code 1 cp: /etc/periodic/monthly/999.local and /conf/base/etc/periodic/monthly/999.local are identical (not copied). It fails for first time, but works after that (for /tmp and /var). My kernel doesn't have TMPFS compiled in. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 00:26:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47ECCFFAC35 for ; Tue, 4 Sep 2018 00:26:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id E028D7C522 for ; Tue, 4 Sep 2018 00:26:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 95271A84 for ; Tue, 4 Sep 2018 03:26:55 +0300 (MSK) Date: Tue, 4 Sep 2018 03:26:55 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1837992684.20180904032655@serebryakov.spb.ru> To: FreeBSD Current Subject: mdmfs fails for first time with md (Was: Regression: ALPHA3 can not properly init diskless / nanobsd system (mdmfs or mknewfs or md is broken?)) In-Reply-To: <1759359118.20180904022521@serebryakov.spb.ru> References: <606629823.20180901023912@serebryakov.spb.ru> <1759359118.20180904022521@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 00:26:57 -0000 Hello Lev, Tuesday, September 4, 2018, 2:25:21 AM, you wrote: > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > random: read_random_uio unblock wait > random: read_random_uio unblock wait > random: unblocking device. > mdmfs: mount exited with error code 1 > cp: /etc/periodic/monthly/999.local and > /conf/base/etc/periodic/monthly/999.local are identical (not copied). > It fails for first time, but works after that (for /tmp and /var). > My kernel doesn't have TMPFS compiled in. Looks like it is hardware-depended. It works on Atom D2500-based system and 100% fails on Celeron J3160 based one. How could I debug this? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 09:53:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D2BBFE9681 for ; Tue, 4 Sep 2018 09:53:45 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 941B49056D for ; Tue, 4 Sep 2018 09:53:44 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([141.89.154.175]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M50aI-1fg8hT0pTC-00zBUa for ; Tue, 04 Sep 2018 11:40:41 +0200 Date: Tue, 4 Sep 2018 11:40:39 +0200 From: "Hartmann, O." To: FreeBSD CURRENT Subject: r338446: network access freezing on em/igb NICs Message-ID: <20180904114039.689af1b2@hermann> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:LaJ5JxexDNuAYiNYYJOTrBBUzydi7kKOPFAZTjTbKKyDTyxYWNL PPppFh4jvThC/hD2q0Awpq4FSzUwuu2TQA3UKq3DsHGUcuZN0s0l9km1EZJy+s8U+rsU9fs g1tJHRHr21XZrYBHpl8G2VdCPrV0tFvTDYVc7PqEKzjiIwbYIALcE6SMZ9S8Pzx6ecXeOCn noiG6vGGiHDpTQ000QoDQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:PM+2JjXseIw=:0G0uNaf20teOOv9dupWZVP PMxj+EmXwmP4ELdQa0WRetv4j3Bc9pjUHv5I9w+q/Rxh4xKJ16NzwFruVfbzVLnLAWm1l6RRz ks5DD9ZJupwKcH76QPP03RFT0YzL/q2rcWMh/EitIHk09Tah6m+sl261HAa5ruQ0j4HI6gJtu o/g8hlK+ntXVggYtKCwdgP+WT/a3qew+7kQoWcFbRLr8QT1FFFt5wPRdJPpyaFfK4V0G8jLy0 flCDGEGd/eKbXcntabyYvba2KQcycS0Zneg9X1SnIWJ0aFhnu3aOtNFT3oiglnOXpnEHR3eSU bQ9suIk6EuCLY/sldjF86zC7L2QZh70ZwQ86ClCHj+oEsJokrnZJyNmoaUzc4do+P0jasDzAb e1dUpq25h+Ow0lovCULnBa7OwQuvz6/kNpw9Hm2iy7TlSGut28I2v7vhm09EfVRpIWbHO36Wy jiVIoXdlSZ1zaBbwMm6kRhjBY2RmtDfTt0B2Nvy41B6hOJ53YRHO9uQcoPGf1fgOSK+ES4003 zlqS/LX8yLcoQQfebs2sX18173CY2ooxvparLQpQwdIv/J0nqRcqPPx48cNA5zc2rEqKX9mT0 mTZhaeJMMXFaIINgaMfVa1IUMwSXFDqvhccuad5puf4lRctDKtSPt0KE208nnnjVZ9l3mV/CS iMF25xU7QjReFP1wnWm+0iMX59TK8xx+88oDg3yKcSbtPr8ahKOQAZuWKvJ89HKA14nVe/XlT QCEr2YKKHrXlL/m2I6/Dt4dEgENpuIHruEqVNPrfnckwXBhGhzmmvwgZTeBeN0ViIKWtDWmDu 4Q1cQox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 09:53:45 -0000 Running CURRENT (FreeBSD 12.0-ALPHA4 #19 r338446: Mon Sep 3 21:07:45 CEST 2018 amd64) on a PCengine APU2C4 (NIC is 3x Intel i210: [...] igb0@pci0:2:0:0: class=0x020000 card=0x00008086 chip=0x157b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe500000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x1000, size 32, disabled bar [1c] = type Memory, range 32, base 0xfe520000, size 16384, enabled [...] ) When connecting to the as router acting APU from inside my SoHo network from any machine or via serial console, there is no obvious problem so far detectable. Using top(1), which is my indicator for the problem, is sending normal output. The router has igb0 as tun0 and is spanning the network via vlans via igb1. Connecting to a host inside my network and havinf heavy net I/O doesn't reveal any problems so far. Direct access to the APU from outside is prohobited. When loggin into a host inside my private net from my department and then from there toward the router (APU) as a wheel-grouped user also doesn't reveal problems using top - but I have users restricted to see only there own ID and also there groups are limited via some bsd_see_others... sysctls. It gets funny when sudo su -'ing to root on the APU and then using top. Immediately the net traffic freezes forever! Kind regrads oh From owner-freebsd-current@freebsd.org Tue Sep 4 10:32:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE423FEACE6 for ; Tue, 4 Sep 2018 10:32:53 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 8A7A891F91 for ; Tue, 4 Sep 2018 10:32:53 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C03CF20DC6 for ; Tue, 4 Sep 2018 06:32:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 04 Sep 2018 06:32:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=YLo5W0kNSlkXWt5CVuoC35aEvxkqZyGieKAqvB4oGjg=; b=XB0ECOs4 1DEM2q3HsQro1KUkT3XmfAdC6RGkS+e6j7Xikn53l2/npNjFmHFZ25MCKaeWm8FI TX99T9l6LWR8kxFm2H+7SKnMuPCrcWe18bW3WPHxpb3DInmtS3gD7kTnbMTJOJ3n nulY2otVujp8Nr4fmJ+++ld1nilT5mEJ2gipw4IUtZDFqPFTTR3Rv2tZ3qA0pPDJ tJeZaTIutBnO8ZRy5TbDMSxtMO6SKctKnkO30lFeAzDxUNjKoWofKOwiDDqjjq3x QFe/26y7ZFE8rS1Or9KYF7X5BZ/wtWqpXJ4XEHwPYT7AZsM/BPcRAcidFOq+MgAK CaOoTMIUoyD80Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=YLo5W0kNSlkXWt5CVuoC35aEvxkqZ yGieKAqvB4oGjg=; b=ozw0aZze9/TbN8n6CvyNMc4C1aOF+uFrNyHk9AcFRE6VQ DKKYaKqu/5gdaDsZEmLAyLxGUYqgkm4NVg1SvTmYBxfKSYPHWKhkaKraBhdfy7TO XTFZjsnybm8l22JiLYvyrzCS8enSPc+g+89XHHNxLoUP3wjLAr36ZG9YMIU6GtiF y3VE7ldK3gvV7xnb92SBZoW9Ev4WnzeRCoJfFU8By5zec/bX5k0R+9mfUkRRs8Ky xb4bXBJWC0yr2ADVF03Fam2fV+P1sdUN31zcgMVEuY2dwGlVHvuRe1XBmx3SSs+M pCFXJvGyhVNLgT3o1RaO+0yUKDa0rd5f9b9pRndrQ== X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 26204E414A for ; Tue, 4 Sep 2018 06:32:46 -0400 (EDT) To: FreeBSD Current From: tech-lists Subject: github freebsd and svn freebsd Organization: none Message-ID: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> Date: Tue, 4 Sep 2018 11:32:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 10:32:54 -0000 Hello list, What's the difference between github freebsd and svn freebsd, other than one is on github and the other is on svn? How does one transcode or translate a git commit reference into a svn reference number? thanks, -- J. From owner-freebsd-current@freebsd.org Tue Sep 4 10:53:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6E21FEB47F for ; Tue, 4 Sep 2018 10:53:04 +0000 (UTC) (envelope-from pi@freebsd.org) 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 3AA2692994 for ; Tue, 4 Sep 2018 10:53:04 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fx8xC-000BDE-PN; Tue, 04 Sep 2018 12:53:02 +0200 Date: Tue, 4 Sep 2018 12:53:02 +0200 From: Kurt Jaeger To: tech-lists Cc: FreeBSD Current Subject: Re: github freebsd and svn freebsd Message-ID: <20180904105302.GD2118@home.opsec.eu> References: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 10:53:04 -0000 Hi! > What's the difference between github freebsd and svn freebsd, other than > one is on github and the other is on svn? The github repo isn't official, because there are still some consistency issues. The consistency problem is: If an repo-copy from svn to git is done, how can that repo-copy be done a second time and still keep the same commit ids (in the git repo) ? > How does one transcode or translate a git commit reference into a svn > reference number? That's a good question. There's a small team working on the github stuff: https://www.freebsd.org/administration.html#t-github-automation -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Tue Sep 4 15:08:47 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02713FF20F9 for ; Tue, 4 Sep 2018 15:08:47 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98178733F7 for ; Tue, 4 Sep 2018 15:08:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f176.google.com with SMTP id y12-v6so3217983ioj.13 for ; Tue, 04 Sep 2018 08:08:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=GHbjlG+ibReqJKYPYrbHm/S3NNb6I+sDAg3cVBVuXHY=; b=eFMQjYUohJPcP8WQiLho6sDGrbDxvrWC0yILV5NK1bOTMfi/E7ZM9VqSraTQn5PS2d SQXlg1yY38yd4QSh6pKbu0g8qFjRXtH0gKbMncBkwsXiGM9LzF1UGUOZyXmljGfNRcQz tHCspB7KXBxP5uaO7e64z/+APrsaD9VrSTB4r+hvH2O3IvZjuZVwkJkiB+J1qXbmksd7 H2lDOZAFVWpIeNYGykuwEl+WMyUnxh1h/svTRwvXNIEqO/jSKgZh2v79TbAtClvq/lu8 bnbu8oTKQZ14IZVk45nWEtxL7B6daSKbqfe7S3t4GJow/VMzKBLruAhPcxTD+h9wPdHc ZkYA== X-Gm-Message-State: APzg51DuW28lqTYpidytqqE9yhjoi4h3W63/l6qFmKX0mfcU9U2uLic6 gCZ7HY1SdLsPVm8Iv+tcFTKgP8AK X-Google-Smtp-Source: ANB0Vdbr4cBsdIrgV8DhTh+FPr78/nTgp8xG/QMxfI8cp01JWZhULBkorMqoWJH6reMiJZJiWPBcRg== X-Received: by 2002:a6b:680e:: with SMTP id d14-v6mr23494779ioc.82.1536073720457; Tue, 04 Sep 2018 08:08:40 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id r17-v6sm449382ioh.50.2018.09.04.08.08.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 08:08:40 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id n18-v6so3244581ioa.9 for ; Tue, 04 Sep 2018 08:08:40 -0700 (PDT) X-Received: by 2002:a6b:97c6:: with SMTP id z189-v6mr23329660iod.120.1536073720102; Tue, 04 Sep 2018 08:08:40 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:4f1b:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 08:08:39 -0700 (PDT) In-Reply-To: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> References: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> From: Conrad Meyer Date: Tue, 4 Sep 2018 08:08:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: github freebsd and svn freebsd To: tech-lists Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 15:08:47 -0000 On Tue, Sep 4, 2018 at 3:32 AM, tech-lists wrote: > Hello list, > > What's the difference between github freebsd and svn freebsd, other than one > is on github and the other is on svn? The github repository is read-only mirror -- new additions all come through SVN. > How does one transcode or translate a git commit reference into a svn > reference number? See https://wiki.freebsd.org/GitWorkflow and look for "notes." Best, Conrad From owner-freebsd-current@freebsd.org Tue Sep 4 16:19:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E406FF3CF7; Tue, 4 Sep 2018 16:19:46 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEE58757F1; Tue, 4 Sep 2018 16:19:45 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id q8-v6so4894987wmq.4; Tue, 04 Sep 2018 09:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WMQNCruZ72B+EyotYdj9JHfljJFpYqXsbRvgGEV7Azk=; b=P6KbNJQGpgYTqeIrpjoqC/s2N+Qt2AlsmBcpJEBPnYUm2Ov1thHWHEgzbRuQ8Q562K nI1foW+OXf3eodi5u9xZit7DdzipRUMIPwrC9sM4L4cdzSflYireu7vDJ+QjFnPpSL4K 9W4exisAaS4pIbZgFrZrjZRnALLbrWAVH9HQYFUxl1M0jzUZnNWsGQtiIKuZHaCio48O w+AX87d32DH8jDuQZRBIvdv0/y9b6YuHXqIrbIE7FIk1OGMOnym1/E1KB/gx0YR0mZ1K HYZPFp1N/o3nbfRNj8NiJmSg6IEG1lBlosdP0qZfpeIVSXYxsQqEmZJ94/ijqxQoPHhV vi2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WMQNCruZ72B+EyotYdj9JHfljJFpYqXsbRvgGEV7Azk=; b=Hc0a17wJ22kLZSkHDxsI8dXCdqxkHPvDg7sKysjg1jrI319dPRLW5Huntq5vwfXeEZ qjJfZu07gO0EligIxlun8d6H8HSamuOyrKU72dUTSntym9ODYut5Yx1Ax7iXoXzLUBMi QKdsTvHFqoWgQpHtV25Ww6RLCoI/Xiy0p939exEGu3/u5msX5r5EkFNOTvMYTYr5jpZd nx/Y9wV2NNo0ZeOFFAwkHNkl/9TGo3w4A+WrJiSIqf0H7n0XI595ptlzAezJfeOXshpD adkbimbbh0sSVspIZqdWPVrrw3Y4+3zfcTJcpdc7ar3/OxNNeiVAl2wdfKKm41INN19k oPHQ== X-Gm-Message-State: APzg51Dp4OitC2WI+gywy4VggszpgHThv/13CqikyTyXXzTurW79GJ91 s7CBTfXwPTFxB4YtYrQCZUxb9pSlm9cu+U9/RuwYDQ== X-Google-Smtp-Source: ANB0VdaRSQqUd71p+SIAxXeIUfmJ6tC1gzUCJ4K7gcYp2HNe+pYAOa0fcKEnzvPnkC/KccJCwAavKEPANDnH/ou+gfg= X-Received: by 2002:a1c:8e90:: with SMTP id q138-v6mr1324631wmd.1.1536077984738; Tue, 04 Sep 2018 09:19:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rajesh Kumar Date: Tue, 4 Sep 2018 21:49:32 +0530 Message-ID: Subject: Re: FreeBSD -CURRENT on AMD Ryzen5 To: jake@jkchamp.com Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 04 Sep 2018 16:39:57 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:19:46 -0000 Hi Jake, Please try setting hw.pci.mcfg=0 from the boot loader and see if it helps. On Tue, Sep 4, 2018 at 2:34 AM Jake Champlin wrote: > Testing out various BSD's with a Huawei Matebook D, and FreeBSD -CURRENT is > failing to boot from an installer image. No serial console, so unable to > grab full boot output, any other info or boot flags that would help would > be awesome. > https://i.imgur.com/WAqwbza.jpg, shows where boot process hangs, and fails > to move past. > > Thanks > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Sep 4 18:13:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 107B5FF7525 for ; Tue, 4 Sep 2018 18:13:05 +0000 (UTC) (envelope-from jake@jkchamp.com) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A30F97A611 for ; Tue, 4 Sep 2018 18:13:04 +0000 (UTC) (envelope-from jake@jkchamp.com) Received: by mail-yw1-xc2a.google.com with SMTP id z143-v6so1618371ywa.7 for ; Tue, 04 Sep 2018 11:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkchamp-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=E9rHL9WtWMHUIj1ycbjwxz/syTBDM33cP1a625FkTl8=; b=VTVn2GTY9tu/q0ldxgyZDGdUhqfnV0vCzdKfIGJsnAAKLsLO3PE1MQQUk7V7M8q5d1 29uZ9O2cQU8PSgmigkntjnbQFrA59xedP2LwskHokcU/BqOfTo+GOPEGKFFqeGSo6YNn EPrcYTB809FKcZxDQfh6BjPf+7SKh7wVlQEX2cY/dGpukjj+lsfjUxusylbnnxRdXTjl DS7RtIVx4Ye+vAw/BKQ+LR5whO5cDZhSe96V4FayTJaIgIPjJFBMe8r8ZEpwTmhZKjOp q0G2pDhiJqiBxQdAfP/bCmxvqgOrH/kSDh+aeDSdkEWGj2JQFZtjQEZ1wp+H+aVK7xbW 9B0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=E9rHL9WtWMHUIj1ycbjwxz/syTBDM33cP1a625FkTl8=; b=AL3PCNb5MjWkw0xxP6Fodpz9WWEZkGS3YKfvUwz5NVI5vO6LQwru20VvldAYHfGKAi wOJeBGf5rmAEviS0g50Wvw47LV6SWc16hIHqO1wKgjznRWxkyPDDYQ3MxXU/EgwtYXuz EXjEWl/plXVulP583Lmc+TzmvotyfXaRh9Gd0sTBE+djSnCYckygkrg/TixzuVTYMrHv q3bVxXXkdooN7bOVod/emUXftYTLQLaDbuakCONrFUcdfx4vXtgRufu4a7hphG6TRHtm YVDpMD8r5BkgcxhTq6uRZYmjjNdmZmoQbwxbq0hg/g/tIKCiui+687vnA6RpMtZ7/yRE NHhA== X-Gm-Message-State: APzg51AetWT5Z4LeTBEAYBCXYh3umZDloJHeo+cgJYbXaxxi+gw3AOJg FLb1iSg4j4ayqKINHxzyIsymmg== X-Google-Smtp-Source: ANB0VdbkJJALJrksaNQRHIJ9vrI3DtdRa/mMcn54qsKeZ4F1C431t4GXpyWDd1kVdFqWzDHoc2oYog== X-Received: by 2002:a81:6a06:: with SMTP id f6-v6mr19295380ywc.294.1536084783838; Tue, 04 Sep 2018 11:13:03 -0700 (PDT) Received: from [192.168.0.205] (c-68-54-132-188.hsd1.in.comcast.net. [68.54.132.188]) by smtp.gmail.com with ESMTPSA id z125-v6sm17894360ywg.57.2018.09.04.11.13.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 11:13:03 -0700 (PDT) Date: Tue, 4 Sep 2018 14:12:03 -0400 From: Jake Champlin To: Rajesh Kumar Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: FreeBSD -CURRENT on AMD Ryzen5 Message-ID: <20180904181203.nx2r4bhuy24mxsuz@pancakes> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/20180203-neo (FreeBSD/amd64) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 18:13:05 -0000 On Tue, Sep 04, 2018 at 09:49:32PM +0530, Rajesh Kumar wrote: > Hi Jake, > > Please try setting hw.pci.mcfg=0 from the boot loader and see if it helps. > > On Tue, Sep 4, 2018 at 2:34 AM Jake Champlin wrote: > > > Testing out various BSD's with a Huawei Matebook D, and FreeBSD -CURRENT is > > failing to boot from an installer image. No serial console, so unable to > > grab full boot output, any other info or boot flags that would help would > > be awesome. > > https://i.imgur.com/WAqwbza.jpg, shows where boot process hangs, and fails > > to move past. > > > > Thanks > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > Works to boot the laptop, but no wireless at that point :) Thanks though. From owner-freebsd-current@freebsd.org Tue Sep 4 20:08:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2E89FFA5E8; Tue, 4 Sep 2018 20:08:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6954D7F3FF; Tue, 4 Sep 2018 20:08:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id DAC0DBB5; Tue, 4 Sep 2018 23:08:20 +0300 (MSK) Date: Tue, 4 Sep 2018 23:08:20 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <609400979.20180904230820@serebryakov.spb.ru> To: FreeBSD Current , freebsd-fs@FreeBSD.org Subject: newfs silently fails if random is not ready (?) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:08:22 -0000 Hello FreeBSD, I have problems with diskless install when kernel doesn't have tmpfs and random device takes long time to unlock. Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail to create FS. I've added '-XL' options to mdmfs and it looks like this: da0: quirks=0x2 arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache *** Figure out our NFS root path *** *** handle_remount /conf *** *** templates are base default *** *** handle_remount /conf/base/etc *** *** handle_remount /conf/base/var *** *** handle_remount /conf/default/etc *** *** handle_remount /conf/default/var *** *** create_md etc with size 20480 *** DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B DEBUG: running: /sbin/newfs -U /dev/md0 random: read_random_uio unblock wait random: read_random_uio unblock wait random: unblocking device. DEBUG: running: /sbin/mount /dev/md0 /etc mount: /dev/md0: No such file or directory mdmfs: mount exited with error code 1 "/dev/md0" is here, but it is empty, without any FS. I could run "/sbin/newfs -U /dev/md0" later by hands and it works. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 20:44:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C24DFFB3F9; Tue, 4 Sep 2018 20:44:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id E170F806FA; Tue, 4 Sep 2018 20:44:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 653BBBC3; Tue, 4 Sep 2018 23:44:14 +0300 (MSK) Date: Tue, 4 Sep 2018 23:44:14 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <93104614.20180904234414@serebryakov.spb.ru> To: FreeBSD Current , freebsd-hackers@freebsd.org Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowest setting) forever and can not lower frequency without Tuebo mode MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:44:16 -0000 Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz even if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 20:46:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C39A5FFB512; Tue, 4 Sep 2018 20:46:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62AB180901; Tue, 4 Sep 2018 20:46:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id h23-v6so6620215ita.5; Tue, 04 Sep 2018 13:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=UzeyLKnZo9N56ajtMvjP5A8BmYfJptEP9kxmENU0ajA=; b=bD3NvAPHo0dDVotaT+Epx/6sqnFwSjJg5xWDpWbqP/zih0HuYa97ZmSccFnterlABW GwC8goutPFENBfRPwn9gfie2HSvJMpW72OJ2GArpH5G0X7G4WCQhH422RriZqiT17MfZ ttjYYLhoAE2keg5RvPn9XO9uef2/JBG5byyxids97R7zvfJzM7sc9iE3HxrovF8ziEND KmhZBz14rpLVyS3oAG2TMuzkZFRHNJSmbBA3h9MYuKHW057jphEw2c8EwcIzr2ZgYIOS 63/eNWKLndhr0ZOcbPmPWFRPcDjeFTIZyyeA1RENEt8roBps2jcUd8wk8V+ijBVppH/r Pysg== X-Gm-Message-State: APzg51Ba1Nw7mrinp3UkIPAWyn3LDOVAeeXte1p7IzFw2u+x/vkw3FNP YUd7pYyf1QsbVShTNfPakonU3IAb X-Google-Smtp-Source: ANB0VdaIsCyEzY7Wo/aFxyfut9c6cFba1QbQ5dVW7ipzBy1zUSt4UArQ95aalmb1snLA24kIpBADfg== X-Received: by 2002:a24:17c7:: with SMTP id 190-v6mr8490839ith.99.1536093480490; Tue, 04 Sep 2018 13:38:00 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id d65-v6sm9847857iof.46.2018.09.04.13.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 13:38:00 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id v14-v6so4175094iob.4; Tue, 04 Sep 2018 13:38:00 -0700 (PDT) X-Received: by 2002:a6b:97c6:: with SMTP id z189-v6mr24320774iod.120.1536093480015; Tue, 04 Sep 2018 13:38:00 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 13:37:59 -0700 (PDT) In-Reply-To: <609400979.20180904230820@serebryakov.spb.ru> References: <609400979.20180904230820@serebryakov.spb.ru> From: Conrad Meyer Date: Tue, 4 Sep 2018 13:37:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: lev@freebsd.org Cc: FreeBSD Current , freebsd-fs , Xin LI Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:46:08 -0000 Hi Lev, Newfs just uses arc4random(3) to generate its FSID and generation numbers. arc4random(3) is seeded from getentropy(3) -> getrandom(2) -> read_random_uio(9), which is what produces the "random: read_random_uio unblock wait" messages. Is newfs tripping on a raise()/abort() in arc4random(3) / getentropy(3)? Is your program that runs newfs checking for non-zero exit status? Do you see any newfs cores when this happens? Thanks, Conrad On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov wrote: > Hello FreeBSD, > > I have problems with diskless install when kernel doesn't have tmpfs and > random device takes long time to unlock. > > Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail > to create FS. > > I've added '-XL' options to mdmfs and it looks like this: > > da0: quirks=0x2 > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache > *** Figure out our NFS root path *** > *** handle_remount /conf *** > *** templates are base default *** > *** handle_remount /conf/base/etc *** > *** handle_remount /conf/base/var *** > *** handle_remount /conf/default/etc *** > *** handle_remount /conf/default/var *** > *** create_md etc with size 20480 *** > DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B > DEBUG: running: /sbin/newfs -U /dev/md0 > random: read_random_uio unblock wait > random: read_random_uio unblock wait > random: unblocking device. > DEBUG: running: /sbin/mount /dev/md0 /etc > mount: /dev/md0: No such file or directory > mdmfs: mount exited with error code 1 > > "/dev/md0" is here, but it is empty, without any FS. > > I could run "/sbin/newfs -U /dev/md0" later by hands and it works. > > -- > Best regards, > Lev mailto:lev@FreeBSD.org > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Sep 4 20:55:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 584A0FFBA6D; Tue, 4 Sep 2018 20:55:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id E8BE481000; Tue, 4 Sep 2018 20:55:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id CD42ABCC; Tue, 4 Sep 2018 23:55:14 +0300 (MSK) Date: Tue, 4 Sep 2018 23:55:14 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <1942661439.20180904235514@serebryakov.spb.ru> To: Conrad Meyer CC: FreeBSD Current , freebsd-fs , Xin LI Subject: Re: newfs silently fails if random is not ready (?) In-Reply-To: References: <609400979.20180904230820@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 20:55:16 -0000 Hello Conrad, Tuesday, September 4, 2018, 11:37:59 PM, you wrote: > Newfs just uses arc4random(3) to generate its FSID and generation > numbers. arc4random(3) is seeded from getentropy(3) -> getrandom(2) ->> read_random_uio(9), which is what produces the "random: > read_random_uio unblock wait" messages. > Is newfs tripping on a raise()/abort() in arc4random(3) / > getentropy(3)? Nope, it is silently does nothing > Is your program that runs newfs checking for non-zero > exit status? It is not "my" program, it is system mdmfs(8), and it checks exit statuses, as far as I can see from source code. > Do you see any newfs cores when this happens? It is very first step in diskless boot, so no cores are possible, but I don't see "core dumped" messages too. > Thanks, > Conrad > On Tue, Sep 4, 2018 at 1:08 PM, Lev Serebryakov wrote: >> Hello FreeBSD, >> >> I have problems with diskless install when kernel doesn't have tmpfs and >> random device takes long time to unlock. >> >> Looks like newfs used to create in-memory /etc (on /dev/md0) silently fail >> to create FS. >> >> I've added '-XL' options to mdmfs and it looks like this: >> >> da0: quirks=0x2 >> arc4random: no preloaded entropy cache >> arc4random: no preloaded entropy cache >> *** Figure out our NFS root path *** >> *** handle_remount /conf *** >> *** templates are base default *** >> *** handle_remount /conf/base/etc *** >> *** handle_remount /conf/base/var *** >> *** handle_remount /conf/default/etc *** >> *** handle_remount /conf/default/var *** >> *** create_md etc with size 20480 *** >> DEBUG: running: /sbin/mdconfig -a -t swap -s 10485760B >> DEBUG: running: /sbin/newfs -U /dev/md0 >> random: read_random_uio unblock wait >> random: read_random_uio unblock wait >> random: unblocking device. >> DEBUG: running: /sbin/mount /dev/md0 /etc >> mount: /dev/md0: No such file or directory >> mdmfs: mount exited with error code 1 >> >> "/dev/md0" is here, but it is empty, without any FS. >> >> I could run "/sbin/newfs -U /dev/md0" later by hands and it works. >> >> -- >> Best regards, >> Lev mailto:lev@FreeBSD.org >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 21:05:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF194FFBEF3; Tue, 4 Sep 2018 21:05:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF0D8165B; Tue, 4 Sep 2018 21:05:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id h1-v6so6695456itj.4; Tue, 04 Sep 2018 14:05:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PypNyxxUwRBszqw2G4nACmW0LX58vdtyH9xCNyrpAn4=; b=mwd8D1BF6su5Sy7q+3ULO2Av8C+LacdK0ed7P93WSykNnAEl6yh5/s9B7N2KUbOVCR FGoqvmLkcsQqhgk8zqWCPROMH1fdMuFGPaZr/D3npDQU3lqQN8fgBOlXlnh+ebhCB1+U PHJ+L1/XkkUvPqT9+l0g4TW8Cwa+tU17ZiEpo+FxVpZ/y/x3gxkfl7rwmocD4Dr6oN/M tt2wd4b1PYYUk5Lsekdsqw2fAMOHU2CoTlM/MNR/v8R1qtHE+drWE+COE0dInG5xgUqw /wbRUCda3b5zy9yh1rZ1hwHC7Dey5QQ7LjoMlc4ePVX190I93vGpPPX+tnirjj5Bp7dU TqBw== X-Gm-Message-State: APzg51CtgQXf1edBbGTK8Do+wMLzpGPKuFlMD4vwBX0fDz3AwYOg+gxV mlQeh32tP8xhdgo05W89HoaUebeL X-Google-Smtp-Source: ANB0VdbA5FbNlKJQ0Tvevvn5Zy4Fm4A+33qws1nCoON37HMnKZTewm98dO3ILFYxtDpkn7dTCy36Xg== X-Received: by 2002:a02:7123:: with SMTP id n35-v6mr24646358jac.91.1536095144576; Tue, 04 Sep 2018 14:05:44 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id i139-v6sm14093349ioa.26.2018.09.04.14.05.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 14:05:44 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id h20-v6so6703275itf.2; Tue, 04 Sep 2018 14:05:44 -0700 (PDT) X-Received: by 2002:a24:44d7:: with SMTP id o206-v6mr1654384ita.66.1536095144075; Tue, 04 Sep 2018 14:05:44 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 14:05:43 -0700 (PDT) In-Reply-To: <1942661439.20180904235514@serebryakov.spb.ru> References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> From: Conrad Meyer Date: Tue, 4 Sep 2018 14:05:43 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Xin LI Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:05:46 -0000 Hi Lev, On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: > Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >> Is newfs tripping on a raise()/abort() in arc4random(3) / >> getentropy(3)? > Nope, it is silently does nothing I think it is tripping on raise/abort() in one of these routines, but nothing is printing that information. See below. >> Is your program that runs newfs checking for non-zero >> exit status? > It is not "my" program, it is system mdmfs(8), and it checks exit > statuses, as far as I can see from source code. Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) the same as programs that exit with success. This is a (major) problem and the reason raise/abort is not visible. Best, Conrad From owner-freebsd-current@freebsd.org Tue Sep 4 21:07:57 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AD6EFFBFC3 for ; Tue, 4 Sep 2018 21:07:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 1236B81782 for ; Tue, 4 Sep 2018 21:07:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 0A919BD6 for ; Wed, 5 Sep 2018 00:07:55 +0300 (MSK) Date: Wed, 5 Sep 2018 00:07:55 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1155442880.20180905000755@serebryakov.spb.ru> To: FreeBSD Current Subject: sh(1) and more(1) hangs on serial terminal at [ttydcd] state. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:07:57 -0000 Hello FreeBSD, When I use serial console (configured as console + "getty std.115200 xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. If I hit ^T system shows that locked process is in "[ttydcd]" state. ^C kills locked process. What do I have misconfigured? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 21:10:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEC35FFC0F6; Tue, 4 Sep 2018 21:10:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 730CF818B2; Tue, 4 Sep 2018 21:10:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 8361FBD8; Wed, 5 Sep 2018 00:10:35 +0300 (MSK) Date: Wed, 5 Sep 2018 00:10:35 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <774228883.20180905001035@serebryakov.spb.ru> To: Conrad Meyer CC: FreeBSD Current , freebsd-fs , Xin LI Subject: Re: newfs silently fails if random is not ready (?) In-Reply-To: References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:10:37 -0000 Hello Conrad, Wednesday, September 5, 2018, 12:05:43 AM, you wrote: > On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: >> Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >>> Is newfs tripping on a raise()/abort() in arc4random(3) / >>> getentropy(3)? >> Nope, it is silently does nothing > I think it is tripping on raise/abort() in one of these routines, but > nothing is printing that information. See below. Maybe, it should be fixed? One second after that random is ready to use and newfs works as intended. It is, really, some race between early init script (rc.initdiskless) and kernel. I don't think, that newfs must be killed/aborted in such situation, it could wait! >>> Is your program that runs newfs checking for non-zero >>> exit status? >> It is not "my" program, it is system mdmfs(8), and it checks exit >> statuses, as far as I can see from source code. > Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. > It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) > the same as programs that exit with success. This is a (major) > problem and the reason raise/abort is not visible. And it is another problem. But if it will be fixed, it doesn't help to init system properly in my case, only diagnostic will be better. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Tue Sep 4 21:20:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74C8FFFC705 for ; Tue, 4 Sep 2018 21:20:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 00AB6820C4 for ; Tue, 4 Sep 2018 21:20:47 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 5e14d7c7-b088-11e8-a747-09a40681ccbf X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 5e14d7c7-b088-11e8-a747-09a40681ccbf; Tue, 04 Sep 2018 21:20:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w84LKbE8029818; Tue, 4 Sep 2018 15:20:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1536096037.1351.3.camel@freebsd.org> Subject: Re: sh(1) and more(1) hangs on serial terminal at [ttydcd] state. From: Ian Lepore To: lev@FreeBSD.org, FreeBSD Current Date: Tue, 04 Sep 2018 15:20:37 -0600 In-Reply-To: <1155442880.20180905000755@serebryakov.spb.ru> References: <1155442880.20180905000755@serebryakov.spb.ru> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:20:48 -0000 On Wed, 2018-09-05 at 00:07 +0300, Lev Serebryakov wrote: > Hello FreeBSD, > >  When I use serial console (configured as console + "getty std.115200 > xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. > If I hit > ^T system shows that locked process is in "[ttydcd]" state. ^C kills > locked > process. > >  What do I have misconfigured? > Change the std.115200 to 3wire.115200 so that it ignores modem-control signals. -- Ian From owner-freebsd-current@freebsd.org Tue Sep 4 21:27:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BB0FFFCACE; Tue, 4 Sep 2018 21:27:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0F4B826C9; Tue, 4 Sep 2018 21:27:27 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id j198-v6so15076975ita.0; Tue, 04 Sep 2018 14:27:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=tTJD9sq6mta4u4FctQgnsX6w6gCliPb2+jUnDaDLMl0=; b=PCTzf5rMtbBcz60ZzJru1qFgxU3zIdBv7dNNOlfVsy/Vej+Aq2DV4Z0qqIkp08qNF3 Wsk9ljbM/6U7e+Iux7OUWH2Ev+HfQyKJ0AyzIUMJSHCLHP+HvJvbF48hf8F0Z18NqpQp UsV8UmGetH5xymkLU4Wsf3K6Ux97+rzlaGufRgafRvn2J/n68MM4ab9xLU7EKCuQGxks K9wTeubbhdBuGjiPLh+y+vTKkFtyAQCJkmKsvXDhio2FcMBt7UEpNCN7oJPSHfwVTaG1 UlmtWzlGYuRNiA5fVOanANIIvFrsZz2hQno5nBS2oc57YtT36pQ0oBAw7Vlaz3bIpLcz aajw== X-Gm-Message-State: APzg51BURlV2/zTWMzgA9DDh04+bxYkv16gZhPiJoh3F5068tDvo08i9 lVJ0jiKKHD8Vliw1+u9w+dC3t3FD X-Google-Smtp-Source: ANB0VdbQ/+UN9kCfGoFC2hGturqx1RFfTPNuiEyQEWsdqq2RrmIpIoTpnhFb0AFruNo7mxLyRuJKVA== X-Received: by 2002:a24:2848:: with SMTP id h69-v6mr9444920ith.63.1536096447221; Tue, 04 Sep 2018 14:27:27 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com. [209.85.223.173]) by smtp.gmail.com with ESMTPSA id 68-v6sm215245itx.19.2018.09.04.14.27.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 14:27:27 -0700 (PDT) Received: by mail-io0-f173.google.com with SMTP id e12-v6so4240902iok.12; Tue, 04 Sep 2018 14:27:26 -0700 (PDT) X-Received: by 2002:a5e:9615:: with SMTP id a21-v6mr23473349ioq.53.1536096446818; Tue, 04 Sep 2018 14:27:26 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 14:27:26 -0700 (PDT) In-Reply-To: <774228883.20180905001035@serebryakov.spb.ru> References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> From: Conrad Meyer Date: Tue, 4 Sep 2018 14:27:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Xin LI Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:27:28 -0000 On Tue, Sep 4, 2018 at 2:10 PM, Lev Serebryakov wrote: > Wednesday, September 5, 2018, 12:05:43 AM, you wrote: >> I think it is tripping on raise/abort() in one of these routines, but >> nothing is printing that information. See below. > > Maybe, it should be fixed? Yes, it should. > One second after that random is ready to use and > newfs works as intended. It is, really, some race between early init script > (rc.initdiskless) and kernel. I don't think, that newfs must be > killed/aborted in such situation, it could wait! I agree. It looks like it is waiting, in fact, but then Something Bad Happens when the random device is unblocked. >> Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. >> It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) >> the same as programs that exit with success. This is a (major) >> problem and the reason raise/abort is not visible. > > And it is another problem. But if it will be fixed, it doesn't help to init > system properly in my case, only diagnostic will be better. Yep. Best, Conrad From owner-freebsd-current@freebsd.org Wed Sep 5 00:12:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B893FCE5B3; Wed, 5 Sep 2018 00:12:34 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B41D687605; Wed, 5 Sep 2018 00:12:33 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id xLQqfOddrWppDxLQsfE2eD; Tue, 04 Sep 2018 18:12:31 -0600 X-Authority-Analysis: v=2.3 cv=YIcrNiOx c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=JBFolyDoGHsA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=3wjhRfM0uK7mgZkuOOgA:9 a=U71AKJWxvcEvPGBw:21 a=K9KLIFWJcOiMJcJ3:21 a=CjuIK1q_8ugA:10 a=GcEYk62rrkShtTW58HoA:9 a=jzOQwq5GuToFHS0J:21 a=M2SWCdOrNOtDTiRc:21 a=d797vBKxxELuQQ5z:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.169.146.149] (unknown [24.114.45.103]) by spqr.komquats.com (Postfix) with ESMTPSA id 0C127109A; Tue, 4 Sep 2018 17:13:19 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode Date: Tue, 4 Sep 2018 17:12:34 -0700 To: "lev@FreeBSD.org" , FreeBSD Current , "freebsd-hackers@freebsd.org" Message-Id: <20180905001320.0C127109A@spqr.komquats.com> X-CMAE-Envelope: MS4wfFrnuXFgeGk6OIzihCWacsKIrGRxDh0XogWNX01EXdoYT9raZsVe5A86xvPD+Pxs1vrgqsuYR5i/vLozQUIx4Q5moCSQcoqAmPPElBziM1b+3gBx8R82 w69Kt25UpJNXBllbSB0aKiSrTxygkrnCNerRY+hXCXQ8u6dynAQQTleA/ZM0RTI8LL1HlBacBpe1mLzCUMAoLsGxOS3rDHxPniwuRve415uJXcQrvzgduMCk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 00:12:34 -0000 Are you running powers? Do you use c-states? What happens if you boot in (instead of switch to) turbo mode? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Lev Serebryakov Sent: 04/09/2018 13:50 To: FreeBSD Current; freebsd-hackers@freebsd.org Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetti= ng) forever and can not lower frequency without Tuebo mode Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz eve= n if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. --=20 Best regards, Lev mailto:lev@FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Sep 5 00:41:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8125AFCF546; Wed, 5 Sep 2018 00:41:07 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F1D4788DE5; Wed, 5 Sep 2018 00:41:06 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id xLsPf8HjjwyxUxLsQfZrN6; Tue, 04 Sep 2018 18:40:59 -0600 X-Authority-Analysis: v=2.3 cv=NPJhBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=JBFolyDoGHsA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=0NjysZD-ljNUMpFw8akA:9 a=Kpp3NU_WHmIzZenv:21 a=ZZyehYkHG4WZlBZe:21 a=CjuIK1q_8ugA:10 a=I0YjrFIYp15_colGeKsA:9 a=BhuSvu0nqPCqU8NT:21 a=eF8zOnaYKK7S4KRM:21 a=x3FNdPKTjNitdyiB:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [192.168.1.102] (S0106002401cb186f.gv.shawcable.net [70.67.125.17]) by spqr.komquats.com (Postfix) with ESMTPSA id 142101109; Tue, 4 Sep 2018 17:41:50 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mod Date: Tue, 4 Sep 2018 17:41:04 -0700 To: "lev@FreeBSD.org" , FreeBSD Current , "freebsd-hackers@freebsd.org" Message-Id: <20180905004150.142101109@spqr.komquats.com> X-CMAE-Envelope: MS4wfBPLBy7DPgu9doLSd0vYgDNtSrQmXv/S1trsNhZtO6GRKRRO5N/oWvagCBe/JjLBetStgysEotEwqqxAnGngo5pXwPbQYl5ZCBXUwBybogX0Xe+RwHRK qQieffuLViZkX5Y1sjaDY1AFG/yWnk8OnGUbrsGi3PofvQzSFU6k6ZGUOSIUrbU8Lrw7VWTV/8dfRfO/tNksP0Gx9SNaLL4deVI+lAwV7jh4Le1tF0m7RxUL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 00:41:07 -0000 Powers s/b powers (autocorrect). --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Cy Schubert Sent: 04/09/2018 17:15 To: lev@FreeBSD.org; FreeBSD Current; freebsd-hackers@freebsd.org Subject: RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestse= tting) forever and can not lower frequency without Tuebo mode Are you running powers? Do you use c-states? What happens if you boot in (instead of switch to) turbo mode? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Lev Serebryakov Sent: 04/09/2018 13:50 To: FreeBSD Current; freebsd-hackers@freebsd.org Subject: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetti= ng) forever and can not lower frequency without Tuebo mode Hello FreeBSD, I'm installing latest 12-ALPHA4 on new MiniPC with Celeron J3160 CPU. It is 1.6GHz CPU with Turbo up to 2.somethingGHz. If I enable Turbo mode, after booting to FreeBSD it locks at 480MHz according to dev.cpu.0.freq, and simple "openssl" test confirms it. If I disable Turbo mode, after booting to FreeBSD it locks at 1600MHz eve= n if powerd is running. It looks like some bug in interaction between cpufreq and Turbo mode of this CPU. --=20 Best regards, Lev mailto:lev@FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Sep 5 03:13:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9158DFE0BC6; Wed, 5 Sep 2018 03:13:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 323318E058; Wed, 5 Sep 2018 03:13:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id 139-v6so7681258itf.0; Tue, 04 Sep 2018 20:13:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=afY1+KdvF0mIZrGupKYbJbDiULwpIROjdW15VeYOVZM=; b=tMApxOD1rLRqTzgBUFj3U5vjcboauemRlS1429JHYTN9sXobHj9xaY/d5OHHEu1Y8A wvovthN2uQeedNR9RTX69JIWJPt1FA3FI1APy4zl7oej4cEbD8ZaJDpxOLLUhfyGRb0G /fWntpmIFBU6K+144cG8dasT5uMSO3Y+hT+3kwcUuAxcA0vIpoHICuR3QRlDKsYAwgzD uFoiKbefriGj6JW+y1wD2EePVsyk3MkuVYiFlzX98ZhJFngUiO9NflC0S0xMUASeDtXG sIx7OlOSFFD430Iv8RY9N3Frr+DlFtlKz972URazKzEZk7iXUV/kaNMtetp1P84hiOto G1yw== X-Gm-Message-State: APzg51DqRJ3G8I+4yZ+f8DwW5NFuuT2SWxy4UD059jEIDDFF5d/1VP9F ih3IZtVemFT1vE7LeK1B08VlmgAV X-Google-Smtp-Source: ANB0VdZw1jGc5hMsLD9vnHaJ8zbV+tpRFEuyBIBum4IFMMaApmTbjIqnQbdm8lVhn3KaAvHRjJYYPw== X-Received: by 2002:a24:4a83:: with SMTP id k125-v6mr10011627itb.121.1536117223274; Tue, 04 Sep 2018 20:13:43 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id 137-v6sm476719itl.39.2018.09.04.20.13.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 20:13:42 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id w11-v6so4828456iob.2; Tue, 04 Sep 2018 20:13:42 -0700 (PDT) X-Received: by 2002:a6b:254e:: with SMTP id l75-v6mr23753191iol.47.1536117222414; Tue, 04 Sep 2018 20:13:42 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 20:13:41 -0700 (PDT) In-Reply-To: <774228883.20180905001035@serebryakov.spb.ru> References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> From: Conrad Meyer Date: Tue, 4 Sep 2018 20:13:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Xin LI Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 03:13:45 -0000 Hi Lev, I took a first attempt at reproducing this problem on a fast desktop-class system. First steps, give us a way to revert back to unseeded status: --- a/sys/dev/random/fortuna.c +++ b/sys/dev/random/fortuna.c @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); #ifdef _KERNEL #include +#include #include #include #include @@ -384,6 +385,17 @@ random_fortuna_pre_read(void) return; } + /* + * When set, pretend we do not have enough entropy to reseed yet. + */ + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, { + if (RETURN_VALUE != 0) { + RANDOM_RESEED_UNLOCK(); + return; + } + }); + + #ifdef _KERNEL fortuna_state.fs_lasttime = now; #endif @@ -442,5 +454,11 @@ bool random_fortuna_seeded(void) { + /* When set, act as if we are not seeded. */ + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, { + if (RETURN_VALUE != 0) + fortuna_state.fs_counter = UINT128_ZERO; + }); + return (!uint128_is_zero(fortuna_state.fs_counter)); } Second step, enable the failpoints and launch repro program: $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)' debug.fail_point.random_fortuna_pre_read: off -> return(1) $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)' debug.fail_point.random_fortuna_seeded: off -> return(1) $ cat ./blocked_random_poc.c #include #include #include int main(int argc, char **argv) { printf("%x\n", arc4random()); return (0); } $ ./blocked_random_poc ... Third step, I looked at what that process was doing: Curiously, it is not in getrandom() at all, but instead the ARND sysctl fallback. I probably need to rebuild world (libc) to test this (new libc arc4random based on Chacha). $ procstat -kk 1196 PID TID COMM TDNAME KSTACK 1196 100435 blocked_random_poc - read_random+0x3d sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89 sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b amd64_syscall+0x940 fast_syscall_common+0x101 When I unblocked the failpoints, it completed successfully: $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off' debug.fail_point.random_fortuna_pre_read: return(1) -> off $ sudo sysctl debug.fail_point.random_fortuna_seeded=off debug.fail_point.random_fortuna_seeded: return(1) -> off ... 9e5eb30f Best, Conrad From owner-freebsd-current@freebsd.org Wed Sep 5 04:46:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27D62FE2E6F; Wed, 5 Sep 2018 04:46:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f68.google.com (mail-it0-f68.google.com [209.85.214.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A351E7089D; Wed, 5 Sep 2018 04:46:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f68.google.com with SMTP id j81-v6so8213709ite.0; Tue, 04 Sep 2018 21:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=OoWhYAHctVTxe05zzMqXe8eCxjffx2Ls5rIvvSc2eng=; b=hXzoDPyYLAwbPUzu5PPw7FfDeqK8YXv8zDNu50JKc31Nube0R4otMYaTwP1QU9NOiQ c4osuVQsLq/DF2EeirZVD2X77YHVGTVngV716cPh4mhrEJPQFpsimVbbLTOL9zy4Mm7T xHM53vQO75WwGMcO0dQwebb34zPo00fOOsoWqHqunLBy2Y1kwmb5wCS2x7CpWGdpptfX CTRxfkBYNTlSMClMGlUDAzNeTzPX5lFvAMISyZlUqpfe4UJh7AfsSBwHKchla96CooeW Slse5+psZLZ/+G9VKw5CQ4ABk3sX+H/V/SBlN/C2TXb5vneg47BKv4lMiXr8rJ+jBvRM VVBA== X-Gm-Message-State: APzg51DLv7SA8nGS423TDpqEJRYMIYDw5AlRWfcrytn1aoozfH2MMUxA RiKVCmp0OfvmdjiK+YZnNxCjUoQR X-Google-Smtp-Source: ANB0VdanrQjIRa9uAPEQJKoWDImHXIScYfZByDgepI4dhy0Nmg2BwJOgkeupulboKIUGwWykq5bHGA== X-Received: by 2002:a02:39a:: with SMTP id e26-v6mr25422749jae.135.1536122349172; Tue, 04 Sep 2018 21:39:09 -0700 (PDT) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com. [209.85.214.45]) by smtp.gmail.com with ESMTPSA id b129-v6sm639178ioa.75.2018.09.04.21.39.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Sep 2018 21:39:08 -0700 (PDT) Received: by mail-it0-f45.google.com with SMTP id p129-v6so7847513ite.3; Tue, 04 Sep 2018 21:39:08 -0700 (PDT) X-Received: by 2002:a24:41cd:: with SMTP id b74-v6mr2516930itd.85.1536122348375; Tue, 04 Sep 2018 21:39:08 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Tue, 4 Sep 2018 21:39:07 -0700 (PDT) In-Reply-To: References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> From: Conrad Meyer Date: Tue, 4 Sep 2018 21:39:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Xin LI Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 04:46:08 -0000 With current libc, I instead see: load: 0.10 cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s 0% 2328k (SIGINFO) $ procstat -kk 1668 PID TID COMM TDNAME KSTACK 1668 100609 blocked_random_poc - mi_switch+0xd3 sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272 read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940 fast_syscall_common+0x101 and: $ truss ./blocked_random_poc ... getrandom(0x7fffffffd340,40,0) ERR#35 'Resource temporarily unavailable' thr_self(0x7fffffffd310) = 0 (0x0) thr_kill(100609,SIGKILL) = 0 (0x0) SIGNAL 9 (SIGKILL) code=SI_NOINFO So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN after we have already slept until random was seeded. This bubbles up to getentropy(3) -> arc4random(3), which sees a surprising failure from getentropy(3) and raises KILL against the program. I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout condition. This may be sufficient to fix the problem: --- a/sys/dev/random/randomdev.c +++ b/sys/dev/random/randomdev.c @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock) error = tsleep(&random_alg_context, PCATCH, "randseed", hz/10); if (error == ERESTART || error == EINTR) break; + /* Squash hz/10 timeout condition */ + if (error == EWOULDBLOCK) + error = 0; + KASSERT(error == 0, ("unexpected %d", error)); } if (error == 0) { read_rate_increment((uio->uio_resid + sizeof(uint32_t))/sizeof(uint32_t)); Best, Conrad On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer wrote: > Hi Lev, > > I took a first attempt at reproducing this problem on a fast > desktop-class system. First steps, give us a way to revert back to > unseeded status: > > --- a/sys/dev/random/fortuna.c > +++ b/sys/dev/random/fortuna.c > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); > > #ifdef _KERNEL > #include > +#include > #include > #include > #include > @@ -384,6 +385,17 @@ random_fortuna_pre_read(void) > return; > } > > + /* > + * When set, pretend we do not have enough entropy to reseed yet. > + */ > + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, { > + if (RETURN_VALUE != 0) { > + RANDOM_RESEED_UNLOCK(); > + return; > + } > + }); > + > + > #ifdef _KERNEL > fortuna_state.fs_lasttime = now; > #endif > @@ -442,5 +454,11 @@ bool > random_fortuna_seeded(void) > { > > + /* When set, act as if we are not seeded. */ > + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, { > + if (RETURN_VALUE != 0) > + fortuna_state.fs_counter = UINT128_ZERO; > + }); > + > return (!uint128_is_zero(fortuna_state.fs_counter)); > } > > > Second step, enable the failpoints and launch repro program: > > $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)' > debug.fail_point.random_fortuna_pre_read: off -> return(1) > $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)' > debug.fail_point.random_fortuna_seeded: off -> return(1) > > $ cat ./blocked_random_poc.c > #include > #include > #include > > int > main(int argc, char **argv) > { > printf("%x\n", arc4random()); > return (0); > } > > > $ ./blocked_random_poc > ... > > > Third step, I looked at what that process was doing: > > Curiously, it is not in getrandom() at all, but instead the ARND > sysctl fallback. I probably need to rebuild world (libc) to test this > (new libc arc4random based on Chacha). > > $ procstat -kk 1196 > PID TID COMM TDNAME KSTACK > 1196 100435 blocked_random_poc - read_random+0x3d > sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89 > sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b > amd64_syscall+0x940 fast_syscall_common+0x101 > > > When I unblocked the failpoints, it completed successfully: > > $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off' > debug.fail_point.random_fortuna_pre_read: return(1) -> off > $ sudo sysctl debug.fail_point.random_fortuna_seeded=off > debug.fail_point.random_fortuna_seeded: return(1) -> off > > ... > 9e5eb30f > > > Best, > Conrad From owner-freebsd-current@freebsd.org Wed Sep 5 05:00:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C161FE338E; Wed, 5 Sep 2018 05:00:43 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12D8570F70; Wed, 5 Sep 2018 05:00:43 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from odin.corp.delphij.net (unknown [IPv6:2601:646:8882:37a:a954:32ec:5043:1ba5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: delphij/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5A45111168; Wed, 5 Sep 2018 05:00:42 +0000 (UTC) (envelope-from delphij@FreeBSD.org) To: cem@freebsd.org, Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Mark R V Murray , re@FreeBSD.org References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> From: Xin Li Openpgp: preference=signencrypt Autocrypt: addr=delphij@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFJNzwQBEACuPNSJjL/AD8oHFuG72vtx5P7Q6dpiEbFABgw/IohS65yDZDd3qFH9ssQv AsFafwB/ofsk6t7dx6zIC05dv5qjhGIOKSJxFC4U1HAot9+QpeUG+8boTKZiiycrMruItj2U JANlv+gN5h0mAsL5f9eNzhRM43kdjN8cQnBIujhO54Derjnrnqz6cQtoonV6SvvVJZUQGxHK 5R1XYJ6wiTuvoEuRYnNObJmPFWZyYOaGZz0qqD6Qe1BhkZuRzv2bZxwJc3Raap/GF6Pm9J/c hlYHUmm2QLaXvmoP8WNosNjla1fup0tgYQE+7MTtHFVxmVj9ZTihN3rEL5IkeEKjQAqcpe1n Db8X2o4K262LRpFl8WtVMW2TfN5Avpj+knZMl3tkYGvYK/nfadCr6Af4co9mkhX6QYgkerg2 mXEGaQzSD/omnsxHCfqMgdphaX3B3eoY2Fv36BMpjSdHmm0rmwqjqZaqlZn89vQ/I6ATvLyx JsdHwTbrj57audl/RKC+OpREOJPaVULp1L+9zdBXslILO8MJaT6YEw1T29bEj5jvLm03Y4rF u/YTruHcMPpsGbpJckDKiy6ISAbMtPvz7/KR91xPHS6KExGiIakIX9xpIXIDKgq+ecEWwkFK PogoKqO6K0/GYkTRoKdXGzsILvIurtbPqSFqWzbRIyNOa82jowARAQABzRZYaW4gTGkgPGRA ZGVscGhpai5uZXQ+wsF9BBMBCgAnBQJTQvBFAhsjBQkJZgGABQsJCAcDBRUKCQgLBRYCAwEA Ah4BAheAAAoJEJW2GBstM+nsha4P/2Roa/REjZLZlIG1TKOxEDqmwc3fynX4w2g7/FXA7f7Z YO5N4vnnnQdJbDZDt4TJtiP1NHHdheQ5+loJrrCXVlU31LuJv1ebM2Ajsuo/0l3tfulEf6Ki GoozmaNZAhwiGJkQVg9DSKsea5xIA31lPnFH4T0SKn8Q6F4HYienmJJtlKVTADvYXA+DRmv0 rNOyVe+V/AuTFuelKg3Ua5a+dY3oqtrQQvFS4n7iIrNjEMUBVx0XTrYLddnF+YjXDg5Phf0D pV/2yJOXiTGiZMK6i7vwHZkJvarACoTSrUrr6OBuZv5Gf87VgifZKLr2Fuf+FePiVCoZTQiL 0hPQyABMzeWa32P6BY2LBMMMFvFiyL5pN5k6nJ0nx4skl8UxZ5ay4yyVg2u3f4aI3+m0XlZ+ iixrjmCTGi1s+d/n6E3eFXdJUUbSOXLZaU4qrbXRzTYCZmZViryv7ibtOHXnG6oWy7BFEHuT rUW6OBvsQDTp5iQ6opENJ5/ZzSA3c5p1WS9Ezv4Bpdqcm7LTQX2j6kXikj8YqICtDF2rkKZ2 Ynjm9se9B0h/T1SOaSpbtRg05UKjsinDq2x8EeX21yFs3UyvwePLrGoNKL45EJM0xwxrnlfr M0ayKJNLoYysY78d54hg7XMmkQD/oZz9I+k4fN6CmZ2i5WGH2BgYs0313JMHxSg7zsFNBFJN zwQBEADPtS+nfTKM6PwgSWLDGVgUYQ/RLaKzCcpQAf4ryLBugXpx3s2BBT1bixX7CpsLXKQi +RRETgSFzDaBL9SEs2ZDV2YT+zGp08aijK/Yl9+RIeezAukI3c+XMHuo8ktUWJmo5/1DX07q G30ckG7uFuTnt31sFzwhh/ZeSuLFyel/fWF48KExLDIVa8DyEUJaYvE9Vfph4T/3LkKuzVTy +iwUBLiSLj5G5N70A+4usbL3eKyYrJqCSaLfrP99/nlgBhMAHVcKcv0uqSuiaH9OMqg1VjQs N8j6NDQug9QrbBTM6U7oZWF/AK+CdFoe+leq5MZfzwCevs0BQgxWm4SHMpXL2vtly67QSPMY dl96fOzw8YbKHv1o0ixhCvc37cI9oUVuSJLXKhEEAvWvLuusiuNeoz+6aPlELvD8h5txJqui tVOzctvJ7ktGZTNiz73tKYVdkKaQVyo8QJFLCNLnUulrQ5wXwteYPg6mrpBxu9VqgDrMp7eB T2kaZ4GRBoMWXXPYSIEe5PM5hhNCsSUfqrKj34UZPijPe+HiWoFJ4S5vIpzutiae11Ctki7u XzeLAhOJQB2raraIqDlFP9I9Zj9JOAZhmiKSEWKfOooCNxQYGiUdPrdYnAe+m7FXRomjF0OO gSepNIESt2gOEIbE5cMxQ0gAueNJc58eHCjWhsNJIwARAQABwsFlBBgBCgAPBQJSTc8EAhsM BQkJZgGAAAoJEJW2GBstM+nsh8EP/1sxZpkJelu+smmqaqdrGHlNrFVLOmeN5yr2IGHBUbmF htjr7fVoU8T0mUnlUU724aKPla4nWhMb4NMu+VxRRFGaT2TYpyR6VIxaStycyUdMGjdXV0Pz TGmxFXhNZXKEITXH9sIxuONBp1czl4AgwN7AAl1MKyV13AaLIyajs58mYmuXtyFn/O+4lxh5 nl2Fa3L9YkL9O7QU2p6WAnDky+L3PgUWp1AzJGfYlLZ8XXCi+KK+pnta+f9yKHt/Oqd/s7OC W4mXgFkBrfuSZZofa4eZckh5u0yBYW3OnEJhClgxRbuOhyYwqQr5oxPrQtjtbMiBzbrOkHhy NnrVCFd9EqlojREGDefHo3V+ZlUOc6OoN3CAYnNa2uLEOm5DCuqOE4z5atBCih5EyITPp7JP J2disEP6ddipcilqbnJdP+TyRQwSv5qRNy8cHahD1Cg9XJJHiC3qr+W3eOtqPkJxhU5biPEr 7dljaLS1Ij771brzqO/x5zW1L9py7muXzYBsW8+keKj8LOYs2242KgjI5Og9YhIJGBFBNddQ wxKBKQpytKQOiXwjhk4Nj77U796bsCd/jIS0r0ZUKBEptPyKso7ncfrm163aEmSaDUkiIjyp 9CEOVT87D+VAVh9PyLGP1niQzWEWFSK36tRGZlF0odP1ZB6wub9zq2DxFouSjHgH Organization: The FreeBSD Project Subject: Re: newfs silently fails if random is not ready (?) Message-ID: Date: Tue, 4 Sep 2018 22:00:34 -0700 User-Agent: Thunderbird MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="duU4at2AbwwH2ZisV9lm5ZIdFCMgF6cyK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 05:00:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --duU4at2AbwwH2ZisV9lm5ZIdFCMgF6cyK Content-Type: multipart/mixed; boundary="nbL0vslebR2my3jPF7fmlKUq0uf8jsbOq"; protected-headers="v1" From: Xin Li To: cem@freebsd.org, Lev Serebryakov Cc: FreeBSD Current , freebsd-fs , Mark R V Murray , re@FreeBSD.org Message-ID: Subject: Re: newfs silently fails if random is not ready (?) References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> In-Reply-To: --nbL0vslebR2my3jPF7fmlKUq0uf8jsbOq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/4/18 21:39, Conrad Meyer wrote: > With current libc, I instead see: >=20 > load: 0.10 cmd: blocked_random_poc 1668 [randseed] 1.27r 0.00u 0.00s > 0% 2328k (SIGINFO) >=20 > $ procstat -kk 1668 > PID TID COMM TDNAME KSTACK > 1668 100609 blocked_random_poc - mi_switch+0xd3 > sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x12 _sleep+0x272 > read_random_uio+0xb3 sys_getrandom+0xa3 amd64_syscall+0x940 > fast_syscall_common+0x101 >=20 > and: >=20 > $ truss ./blocked_random_poc > ... > getrandom(0x7fffffffd340,40,0) ERR#35 'Resource > temporarily unavailable' > thr_self(0x7fffffffd310) =3D 0 (0x0) > thr_kill(100609,SIGKILL) =3D 0 (0x0) > SIGNAL 9 (SIGKILL) code=3DSI_NOINFO >=20 > So getrandom(2) (via READ_RANDOM_UIO) is returning a bogus EAGAIN > after we have already slept until random was seeded. This bubbles up > to getentropy(3) -> arc4random(3), which sees a surprising failure > from getentropy(3) and raises KILL against the program. >=20 > I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout > condition. This may be sufficient to fix the problem: >=20 > --- a/sys/dev/random/randomdev.c > +++ b/sys/dev/random/randomdev.c > @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock) > error =3D tsleep(&random_alg_context, PCATCH, "randseed= ", hz/10); > if (error =3D=3D ERESTART || error =3D=3D EINTR) > break; > + /* Squash hz/10 timeout condition */ > + if (error =3D=3D EWOULDBLOCK) > + error =3D 0; > + KASSERT(error =3D=3D 0, ("unexpected %d", error)); > } > if (error =3D=3D 0) { > read_rate_increment((uio->uio_resid + > sizeof(uint32_t))/sizeof(uint32_t)); +markm, re I think the proposed change is reasonable (note that I think the same theory applies to the tsleep_sbt() case below as well, which should be handled similarly). > Best, > Conrad >=20 >=20 > On Tue, Sep 4, 2018 at 8:13 PM, Conrad Meyer wrote: >> Hi Lev, >> >> I took a first attempt at reproducing this problem on a fast >> desktop-class system. First steps, give us a way to revert back to >> unseeded status: >> >> --- a/sys/dev/random/fortuna.c >> +++ b/sys/dev/random/fortuna.c >> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); >> >> #ifdef _KERNEL >> #include >> +#include >> #include >> #include >> #include >> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void) >> return; >> } >> >> + /* >> + * When set, pretend we do not have enough entropy to reseed y= et. >> + */ >> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, { >> + if (RETURN_VALUE !=3D 0) { >> + RANDOM_RESEED_UNLOCK(); >> + return; >> + } >> + }); >> + >> + >> #ifdef _KERNEL >> fortuna_state.fs_lasttime =3D now; >> #endif >> @@ -442,5 +454,11 @@ bool >> random_fortuna_seeded(void) >> { >> >> + /* When set, act as if we are not seeded. */ >> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, { >> + if (RETURN_VALUE !=3D 0) >> + fortuna_state.fs_counter =3D UINT128_ZERO; >> + }); >> + >> return (!uint128_is_zero(fortuna_state.fs_counter)); >> } >> >> >> Second step, enable the failpoints and launch repro program: >> >> $ sudo sysctl debug.fail_point.random_fortuna_pre_read=3D'return(1)' >> debug.fail_point.random_fortuna_pre_read: off -> return(1) >> $ sudo sysctl debug.fail_point.random_fortuna_seeded=3D'return(1)' >> debug.fail_point.random_fortuna_seeded: off -> return(1) >> >> $ cat ./blocked_random_poc.c >> #include >> #include >> #include >> >> int >> main(int argc, char **argv) >> { >> printf("%x\n", arc4random()); >> return (0); >> } >> >> >> $ ./blocked_random_poc >> ... >> >> >> Third step, I looked at what that process was doing: >> >> Curiously, it is not in getrandom() at all, but instead the ARND >> sysctl fallback. I probably need to rebuild world (libc) to test this= >> (new libc arc4random based on Chacha). >> >> $ procstat -kk 1196 >> PID TID COMM TDNAME KSTACK >> 1196 100435 blocked_random_poc - read_random+0x3d >> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89 >> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b >> amd64_syscall+0x940 fast_syscall_common+0x101 >> >> >> When I unblocked the failpoints, it completed successfully: >> >> $ sudo sysctl debug.fail_point.random_fortuna_pre_read=3D'off' >> debug.fail_point.random_fortuna_pre_read: return(1) -> off >> $ sudo sysctl debug.fail_point.random_fortuna_seeded=3Doff >> debug.fail_point.random_fortuna_seeded: return(1) -> off >> >> ... >> 9e5eb30f >> >> >> Best, >> Conrad --nbL0vslebR2my3jPF7fmlKUq0uf8jsbOq-- --duU4at2AbwwH2ZisV9lm5ZIdFCMgF6cyK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJbj2L3AAoJEJW2GBstM+nsxVwP/jIyR53g2isbfBVdaseuiiCs Ql9eS1x1xzpIxAHPAndb4bPdROmpZzIgeocZZ1wRM1h/A6Z3isS8AJmtww4D6+W7 Hwm+r1nyGDBv7wgUMqMavQs1JIMpimv/pDScbXD43chlB7n5p1BdSdAcQuu4d3Aq eVrm1eIaVzTldmA5TVS9lBtqkXI9RCx0fwDccDujPB2DNxZoHcp+1h7rNkL31yRg UzF8PtaMLgN1LeDT0BXtYsjtUCZgZtJSZ9PzZWFCjGYVitBYIHYrdrXKbLBjDE00 HEVD/Eyb9dhBhJqFQ9kIprcFJujoY9pAjaDL/qIA8ZPCvyUDt7hbIuaWjxZaC2ep RCAAB5btM9KTRpNAsqt0MhSJC+I/dFmWcgheG4+XOEMSUFlluoIfxVeTFDjgOzt8 OUjc2oLyn8uPCsJQg4q48WwrUGH4hDv8hccFJ1WH7rhfMcR8/51jQHvWt7ObKcx+ mHZUoYBgusePhD1OO/XasBcSwmABviXzpWk/Q6UaFbnFa8BX0uYwFH3dNEeIOmBO Y6ZkoWL2Bg3fdyTHYWe1pnysdQ2DowCxyS8RL1HQgoOAOULnkIHK6MKhNGYVJYn7 bK08/nczyKXz1a2vujPboYLwGfTcyYZb0tLwApRnvnU74jao+nuQO06oZ2TU17uB szrA1pupCukN9iedsogh =auFP -----END PGP SIGNATURE----- --duU4at2AbwwH2ZisV9lm5ZIdFCMgF6cyK-- From owner-freebsd-current@freebsd.org Wed Sep 5 07:57:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D57B4FE6F75; Wed, 5 Sep 2018 07:57:40 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (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 66C897620B; Wed, 5 Sep 2018 07:57:40 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxSh0-00064g-M2; Wed, 05 Sep 2018 08:57:38 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_BFFD48EF-4EA4-4154-B13C-6C02B2D6201C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: newfs silently fails if random is not ready (?) From: Mark R V Murray In-Reply-To: Date: Wed, 5 Sep 2018 08:57:37 +0100 Cc: Lev Serebryakov , FreeBSD Current , freebsd-fs , Xin LI Message-Id: <4637985A-28EF-4A6B-B8A6-764A86005E6B@FreeBSD.org> References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> To: cem@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 07:57:41 -0000 --Apple-Mail=_BFFD48EF-4EA4-4154-B13C-6C02B2D6201C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Nice catch! Thanks :-) M > On 5 Sep 2018, at 04:13, Conrad Meyer wrote: > > Hi Lev, > > I took a first attempt at reproducing this problem on a fast > desktop-class system. First steps, give us a way to revert back to > unseeded status: > > --- a/sys/dev/random/fortuna.c > +++ b/sys/dev/random/fortuna.c > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); > > #ifdef _KERNEL > #include > +#include > #include > #include > #include > @@ -384,6 +385,17 @@ random_fortuna_pre_read(void) > return; > } > > + /* > + * When set, pretend we do not have enough entropy to reseed yet. > + */ > + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, { > + if (RETURN_VALUE != 0) { > + RANDOM_RESEED_UNLOCK(); > + return; > + } > + }); > + > + > #ifdef _KERNEL > fortuna_state.fs_lasttime = now; > #endif > @@ -442,5 +454,11 @@ bool > random_fortuna_seeded(void) > { > > + /* When set, act as if we are not seeded. */ > + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, { > + if (RETURN_VALUE != 0) > + fortuna_state.fs_counter = UINT128_ZERO; > + }); > + > return (!uint128_is_zero(fortuna_state.fs_counter)); > } > > > Second step, enable the failpoints and launch repro program: > > $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)' > debug.fail_point.random_fortuna_pre_read: off -> return(1) > $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)' > debug.fail_point.random_fortuna_seeded: off -> return(1) > > $ cat ./blocked_random_poc.c > #include > #include > #include > > int > main(int argc, char **argv) > { > printf("%x\n", arc4random()); > return (0); > } > > > $ ./blocked_random_poc > ... > > > Third step, I looked at what that process was doing: > > Curiously, it is not in getrandom() at all, but instead the ARND > sysctl fallback. I probably need to rebuild world (libc) to test this > (new libc arc4random based on Chacha). > > $ procstat -kk 1196 > PID TID COMM TDNAME KSTACK > 1196 100435 blocked_random_poc - read_random+0x3d > sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89 > sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b > amd64_syscall+0x940 fast_syscall_common+0x101 > > > When I unblocked the failpoints, it completed successfully: > > $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off' > debug.fail_point.random_fortuna_pre_read: return(1) -> off > $ sudo sysctl debug.fail_point.random_fortuna_seeded=off > debug.fail_point.random_fortuna_seeded: return(1) -> off > > ... > 9e5eb30f > > > Best, > Conrad > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Mark R V Murray --Apple-Mail=_BFFD48EF-4EA4-4154-B13C-6C02B2D6201C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAluPjHEACgkQQlsJDh9C UqBdHwgAg+abT1fvBHrfDw1OvTYLA//1b3KRVkdYTUjMrdzm8g68y5ZThM9L14U3 yDeGszrDCIdnVJ9bBxGjxDeqSPY/3m+0SY2qdCT9Ly3r3t4o08WKbLqXjhooaVQE D5Ag72Q2ehWsR+/squ/Z6+3PQWkgWRE/RxTbwjOOJdZoBdJdArV/wSwOTTmcKEwG kZtxcthHbptf1RGeL+3vlVCXR4L5OoJhTym/DIdkE5rQek6cU+16nUwxNZ1NUxwf EZ07pB6pdQCfwwrh23823/zIW9CXeAxzuAf3U4M1v2EiMcgsO1TmzEVWShygNR64 X3YtB2gi3UkuXWa4TXjA77vzz5M+GA== =mSJR -----END PGP SIGNATURE----- --Apple-Mail=_BFFD48EF-4EA4-4154-B13C-6C02B2D6201C-- From owner-freebsd-current@freebsd.org Wed Sep 5 09:35:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D2E1FEA2DF; Wed, 5 Sep 2018 09:35:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 361487985F; Wed, 5 Sep 2018 09:35:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:99c6:bbf1:45c9:c9cf]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 049D6C89; Wed, 5 Sep 2018 12:35:56 +0300 (MSK) Date: Wed, 5 Sep 2018 12:35:56 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <1963289672.20180905123556@serebryakov.spb.ru> To: Cy Schubert , FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode In-Reply-To: <20180905001320.0C127109A@spqr.komquats.com> References: <20180905001320.0C127109A@spqr.komquats.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 09:35:59 -0000 Hello Cy, Wednesday, September 5, 2018, 3:12:34 AM, you wrote: > Are you running powers? powerd? yes. With "adaptive" strategy" > Do you use c-states? Oops. My fault. I've forgot to set cx_lowest to C3 on all cores. BTW, these four settings in rc.conf(5) performance_cx_lowest performance_cpu_freq economy_cx_lowest economy_cpu_freq do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! > What happens if you boot in (instead of switch to) turbo mode? Sorry? I could only turn Turbo mode on/off in BIOS before boot. BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but gives only 1601 Mhz, not 2240MHz max: TURBO ON: dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 TURBO OFF: dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 But I could live with that :-) -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Wed Sep 5 11:42:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5DF3FECE13; Wed, 5 Sep 2018 11:42:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 896CA7D333; Wed, 5 Sep 2018 11:42:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 6C690CB0; Wed, 5 Sep 2018 14:42:21 +0300 (MSK) Date: Wed, 5 Sep 2018 14:42:19 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <532863197.20180905144219@serebryakov.spb.ru> To: Conrad Meyer CC: freebsd-fs , FreeBSD Current , Xin LI Subject: Re: newfs silently fails if random is not ready (?) In-Reply-To: References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 11:42:29 -0000 Hello Conrad, Wednesday, September 5, 2018, 7:39:07 AM, you wrote: > I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout > condition. This may be sufficient to fix the problem: > --- a/sys/dev/random/randomdev.c > +++ b/sys/dev/random/randomdev.c > @@ -156,6 +156,10 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock) > error = tsleep(&random_alg_context, PCATCH, "randseed", hz/10); > if (error == ERESTART || error == EINTR) > break; > + /* Squash hz/10 timeout condition */ > + if (error == EWOULDBLOCK) > + error = 0; > + KASSERT(error == 0, ("unexpected %d", error)); > } > if (error == 0) { > read_rate_increment((uio->uio_resid + > sizeof(uint32_t))/sizeof(uint32_t)); Fantastic! Thanks! -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Wed Sep 5 12:43:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAE04FEEFB3; Wed, 5 Sep 2018 12:43:30 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (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 77AEF7F873; Wed, 5 Sep 2018 12:43:30 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 307D256482; Wed, 5 Sep 2018 07:43:29 -0500 (CDT) Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode To: lev@FreeBSD.org, Cy Schubert , FreeBSD Current , "freebsd-hackers@freebsd.org" References: <20180905001320.0C127109A@spqr.komquats.com> <1963289672.20180905123556@serebryakov.spb.ru> From: Eric van Gyzen Message-ID: <43d68d5a-d8b7-965d-52a6-3eff6cdae1b6@vangyzen.net> Date: Wed, 5 Sep 2018 07:43:28 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1963289672.20180905123556@serebryakov.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 12:43:31 -0000 On 9/5/18 4:35 AM, Lev Serebryakov wrote: > BTW, these four settings in rc.conf(5) > > performance_cx_lowest > performance_cpu_freq > economy_cx_lowest > economy_cpu_freq > > do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! They are used by /etc/rc.d/power_profile, but not in a way that grep can find. > BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but > gives only 1601 Mhz, not 2240MHz max: > > TURBO ON: > dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 > > TURBO OFF: > dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 1601 is not the actual frequency. That is just how it is reported. It is almost certainly running much higher than 1601. Eric From owner-freebsd-current@freebsd.org Wed Sep 5 12:53:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23C26FEF60D; Wed, 5 Sep 2018 12:53:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5967FF6E; Wed, 5 Sep 2018 12:53:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id xXJ1fZ1DYp5A1xXJ2fkDPH; Wed, 05 Sep 2018 06:53:13 -0600 X-Authority-Analysis: v=2.3 cv=JLKPTPCb c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=JBFolyDoGHsA:10 a=D3aUqHbKAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=MTVuH1_HWQHdM4k58OgA:9 a=CjuIK1q_8ugA:10 a=46e8-uGIe74A:10 a=cMCrhCMO5xpCME3_Hjt_:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 6509C743; Wed, 5 Sep 2018 05:54:04 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w85CrAEI022476; Wed, 5 Sep 2018 05:53:10 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w85CrAX3022473; Wed, 5 Sep 2018 05:53:10 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201809051253.w85CrAX3022473@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Eric van Gyzen cc: lev@FreeBSD.org, Cy Schubert , FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode In-Reply-To: Message from Eric van Gyzen of "Wed, 05 Sep 2018 07:43:28 -0500." <43d68d5a-d8b7-965d-52a6-3eff6cdae1b6@vangyzen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Sep 2018 05:53:10 -0700 X-CMAE-Envelope: MS4wfHz1hGJh7XKLBkcEyZR+gA7H6A+8P0ShhMgb+3BPbNAF8uzCwGRQ//G3NNhwp2+8AMiPXx7hedwI1fFLNRG+HXRWeAEkFJIZtvdXjxc4bFjh6YUftPqj gqf2hl0ZFxJMu4oLRZjDDZFrJrkatz8mcBdAtkRcBMBfkrTYaCaUt09Xmvk36vNpEzFfV9yCeBS/hgCMTvrn9sIburoc9zSC3Q7hdaoVe8BTxqJJ1pLqmyh5 YIHp9W+4KHp2zR67qdTUfZjYmTFxtX+DXGpIUHCQr8A= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 12:53:16 -0000 In message <43d68d5a-d8b7-965d-52a6-3eff6cdae1b6@vangyzen.net>, Eric van Gyzen writes: > On 9/5/18 4:35 AM, Lev Serebryakov wrote: > > BTW, these four settings in rc.conf(5) > > > > performance_cx_lowest > > performance_cpu_freq > > economy_cx_lowest > > economy_cpu_freq > > > > do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5! > > They are used by /etc/rc.d/power_profile, but not in a way that grep can > find. > > > BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but > > gives only 1601 Mhz, not 2240MHz max: > > > > TURBO ON: > > dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 12 > 80/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/ > 800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 > > > > TURBO OFF: > > dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 12 > 00/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 560/70 > 0 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75 > > 1601 is not the actual frequency. That is just how it is reported. It > is almost certainly running much higher than 1601. We don't know this until we can independently verify it. Do you mind running some benchmarks with and without turbo mode? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Wed Sep 5 13:45:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A96C4FF0645; Wed, 5 Sep 2018 13:45:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 2786581772; Wed, 5 Sep 2018 13:45:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 6E1B5CC7; Wed, 5 Sep 2018 16:45:50 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode To: Cy Schubert , Eric van Gyzen Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" References: <201809051253.w85CrAX3022473@slippy.cwsent.com> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <0770c5f2-a5d9-4cd4-1421-72006465ffba@FreeBSD.org> Date: Wed, 5 Sep 2018 16:45:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <201809051253.w85CrAX3022473@slippy.cwsent.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 13:45:52 -0000 On 05.09.2018 15:53, Cy Schubert wrote: >> 1601 is not the actual frequency. That is just how it is reported. It >> is almost certainly running much higher than 1601. > > We don't know this until we can independently verify it. Do you mind > running some benchmarks with and without turbo mode? What could be adequate benchmarks for this? Something likje "openssl speed aes128-cbc" or I need more specific one? -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Wed Sep 5 14:05:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5182FF1130; Wed, 5 Sep 2018 14:05:09 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1761E825EE; Wed, 5 Sep 2018 14:05:09 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-lf1-x134.google.com with SMTP id h64-v6so6086792lfi.10; Wed, 05 Sep 2018 07:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SYiJ4UFamiWU0/ZAzUyHRat24KWTcNJKf+KMjcoJU3k=; b=EOacOsNI2wJJ5cOqGHdbg4wD93WtHDGWAetSfCk4C2gwZOBziixzhYT8B3tu2m2WAT kmxRLgcSG/GnCVrEs9CxC8aaLku3aoCWhR+uBx9QkWnthz6cpdIA7+k6Pvi4rUvA0ZvL uV51LBH7L5ZieM3c7HoobuqB+bT1wk4P2jlizn11Giyr8oy9S0Klj9xLqn1Z/NpGyfjK MBbn7K1omnlAbB4GAsADLWj/pcniBRIhgwcgRvxbNdtk1jXROOigdbGzmtW5BaCTjZyc unN0AQkUELJiC21GWuBKqzSoWW+rslt6U6X/2ggrUpmFxuxEwcuzL8yqok/RQFL2TU3v M2hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SYiJ4UFamiWU0/ZAzUyHRat24KWTcNJKf+KMjcoJU3k=; b=MmZw9OY97jVXiWoVaAWoeRuATGDdYmwlwz/2XnEvi2I6MqbqJMU6+Qv6NbHBxad6bt BBH3lEPhJtdgGSd5yStumgK+HlY4aDam40ut1oTw79rW6dS55srCfCQDkChT9O6sO6QJ E3UbbFQ5jsHqv8NbDR6C2dHvXt+SxAiaUgZb0IaQonNI9fr5xhpPcqqXOFGs0wPMWLQ6 sO4Ild5U7o+fakDtBzDmQEeJuLpxGjLyRaIBeh2NgdpqiGLdcg48vgekxPTw9feeT1pl sZR9E03HghA/kNssSAasPqTZhwws2poqaAurwIq6iuToD/6g6GWzVdLKG9JNF+Aff7hD D9dQ== X-Gm-Message-State: APzg51BeGT6idtImQFPsesPbz7ktaQ8Yu0AGuOgWVi3rIyTBu7xkv5/r oWU7LZeDuT3wAiGSFRtdpTe9hk/H39sMg5cnGmGVhc8h X-Google-Smtp-Source: ANB0Vdbb7e7nhRo22QxFjbaSeEZBXlkKfHQ9EQXAY8qbbj0Xr3AiEtDiBmwD6Hcf5QDesM21XAsHnoUI9KuKkn90M/Q= X-Received: by 2002:a19:a915:: with SMTP id s21-v6mr24625868lfe.92.1536156307583; Wed, 05 Sep 2018 07:05:07 -0700 (PDT) MIME-Version: 1.0 From: Subbsd Date: Wed, 5 Sep 2018 17:04:56 +0300 Message-ID: Subject: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: freebsd-current Current , freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 14:05:09 -0000 Hi, I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 to latest revision (r338466 the moment) and related to ARC. I can not say which revision was before except that the newver.sh pointed to ALPHA3. Problems are observed if you try to limit ARC. In my case: vfs.zfs.arc_max="128M" I know that this is very small. However, for two years with this there were no problems. When i send SIGINFO to process which is currently working with ZFS, i see "arc_reclaim_waiters_cv": e.g when i type: /bin/csh I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k same story with find or any other commans: load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k this problem goes away after increasing vfs.zfs.arc_max From owner-freebsd-current@freebsd.org Wed Sep 5 14:50:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0C3FF27E4; Wed, 5 Sep 2018 14:50:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 841588440D; Wed, 5 Sep 2018 14:50:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id k19-v6so3621572pfi.1; Wed, 05 Sep 2018 07:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Oi8f3AoRcxGoLa8AqgNxVvYRZW3eQDYx2AwcFskK5QE=; b=BBOlbdn+k12VLuGu8/txuh3S21OTbNKoNm31YXKz0imPp9mZ+HlpSO67h3crbmMAv5 nRYRH8kj94BoRjnq7orNaS3dhP3HYAGpUVgQvhBwGDzKxjeaQ4363rKBOOJlmD3Csee+ tP8NSOIvTC9KNzfGV8tIQiutBtLsgzdiCFWA1W3LzXt5nd5VuKPJb3RHFtmHc6XuGmZP USJtBZGrgga6b3a0G3qM0QWkukPR0mYpAn2ZKtPUmDzDPPAUsR8DrN3tdkQQKUiBO1eX KQyGRA6ZxUBQwDD6winKqXmLnmd7/p8ZO43A2IEOqs/FWaf6W8HDmLRwfhcRGR8mUlaG 1xNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Oi8f3AoRcxGoLa8AqgNxVvYRZW3eQDYx2AwcFskK5QE=; b=QEZYA42TAAEKe54LzzLzMRcU4OxilGR7GMtqX/6DQ4RBMaC1ueovDLHlIDiFq1Fcs8 6R4TUkbIaww46ZQNdNUNbckFjtu6/lAajzRoiOC4WVMCYGH4oeHlGx2VWR4jcqlY4RB8 xXi0N7SXXEwYtBDkTQZLBZGkRVxUXxfP5vhh5A/UZpzS+xzjZlkf6xnvGay3R+kYIPMY Hf4St5kl6bcOxhBItP8kgx0Nh7ldXGWCHlrwDKUZ6k1bPDg50oVGZZ6OmWXACD3EqzwE iBAllamgzldGFlVA1kkLYZNKBP5yEiYFj9Z967oNtZPsUutp/Cya0nUYYYSS7KcIYFe3 WIJA== X-Gm-Message-State: APzg51DGy41e0S0Ryt88XGrXX4UgZyVRhSGVOhxx8U+EUVGyegDCQ8dh jFyRRqgiYodGu/S2WDqCmTazv/iy X-Google-Smtp-Source: ANB0VdYKprZurHWGHd/5aa7x0zJDpPnx2dAwXbCPzMAxAz3WxnYvIVdmA6CgPF+WqaiNf02DWsHJlQ== X-Received: by 2002:a62:2483:: with SMTP id k3-v6mr41373058pfk.195.1536159051560; Wed, 05 Sep 2018 07:50:51 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id d22-v6sm8055727pfm.48.2018.09.05.07.50.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 07:50:50 -0700 (PDT) Sender: Mark Johnston Date: Wed, 5 Sep 2018 10:50:45 -0400 From: Mark Johnston To: Subbsd Cc: freebsd-current Current , freebsd-fs@freebsd.org Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Message-ID: <20180905145045.GA37268@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 14:50:53 -0000 On Wed, Sep 05, 2018 at 05:04:56PM +0300, Subbsd wrote: > Hi, > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > to latest revision (r338466 the moment) and related to ARC. > > I can not say which revision was before except that the newver.sh > pointed to ALPHA3. Could you please try reverting r338416 to see if that fixes the problem? > Problems are observed if you try to limit ARC. In my case: > > vfs.zfs.arc_max="128M" > > I know that this is very small. However, for two years with this there > were no problems. Two years on -CURRENT? How often did you update? From owner-freebsd-current@freebsd.org Wed Sep 5 14:51:30 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9667DFF283F; Wed, 5 Sep 2018 14:51:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EE9E84541; Wed, 5 Sep 2018 14:51:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id xZ9SfC6mNwyxUxZ9TfbD9e; Wed, 05 Sep 2018 08:51:28 -0600 X-Authority-Analysis: v=2.3 cv=NPJhBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=JBFolyDoGHsA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=_uEbwowO2kFx1PbUkXEA:9 a=Ypc4Va6Qucodk2n7:21 a=pI3jl5RWgkI84chF:21 a=QEXdDO2ut3YA:10 a=jzIEFZtlbfXkqaKsQYQA:9 a=0zxpfZ4lRSgPi4L5:21 a=OcxlicyLCjbCvRhh:21 a=UPsbyySxWYGTLuwl:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.101.253] (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 6593F83F; Wed, 5 Sep 2018 07:52:19 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode Date: Wed, 5 Sep 2018 07:51:28 -0700 To: "lev@FreeBSD.org" , Eric van Gyzen CC: FreeBSD Current , "freebsd-hackers@freebsd.org" Message-Id: <20180905145219.6593F83F@spqr.komquats.com> X-CMAE-Envelope: MS4wfB0QNIKUdgOcP14nYkOZPowwHD22IgPebiVlmLKlO1/R1xzkcGH4P5AQoM3WuDspRNpDCvycNUGlFOo9kahEM1iIUGMSsZfXn9cFM4q13nf6WhszdWQB a7aekmWbEa6qLUQ/qt5w07aZnJEUruC9Xo0otoMV59eFpbm+T/p2puzIjZpDF2pOimrNrWpbeTUD2M4lDExRQ+gdQgARLkHu5ISQm0/ltcgjeL2MeBDlQ2gg KHdpK6W+ZJZ9ea3RWXoMbkbl7Lb1SEpxeYoSoJ21BdM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 14:51:30 -0000 I don't think you need something accurate. We don't know whether it is implemented through ACPI or similar to the old = turbo jumper on the MB, which increased the clock rate and sometimes the vo= ltage ( required to maintain stability when increasing the clock rate). We = don't know how your MB manufacturer implemented this. My guess is it's probably through ACPI but you don't know until you have so= me rough measurements. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Lev Serebryakov Sent: 05/09/2018 06:46 To: Cy Schubert; Eric van Gyzen Cc: FreeBSD Current; freebsd-hackers@freebsd.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestse= tting) forever and can not lower frequency without Tuebo mode On 05.09.2018 15:53, Cy Schubert wrote: >> 1601 is not the actual frequency. That is just how it is reported. It= =20 >> is almost certainly running much higher than 1601. >=20 > We don't know this until we can independently verify it. Do you mind=20 > running some benchmarks with and without turbo mode? What could be adequate benchmarks for this? Something likje "openssl speed aes128-cbc" or I need more specific one? --=20 // Lev Serebryakov From owner-freebsd-current@freebsd.org Wed Sep 5 14:54:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E425FF2CB4 for ; Wed, 5 Sep 2018 14:54:42 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 9F6ED849F4 for ; Wed, 5 Sep 2018 14:54:41 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 239D21D38B for ; Wed, 5 Sep 2018 14:54:40 +0000 (UTC) To: freebsd-current@freebsd.org References: From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Message-ID: Date: Wed, 5 Sep 2018 10:54:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7zBeATgR61BbcOzwawR91adYyBSQekAnN" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 14:54:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7zBeATgR61BbcOzwawR91adYyBSQekAnN Content-Type: multipart/mixed; boundary="hMUDOWnqlhCxhScvf4riWXfBPMk5mtVUC"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 References: In-Reply-To: --hMUDOWnqlhCxhScvf4riWXfBPMk5mtVUC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-09-05 10:04, Subbsd wrote: > Hi, >=20 > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > to latest revision (r338466 the moment) and related to ARC. >=20 > I can not say which revision was before except that the newver.sh > pointed to ALPHA3. >=20 > Problems are observed if you try to limit ARC. In my case: >=20 > vfs.zfs.arc_max=3D"128M" >=20 > I know that this is very small. However, for two years with this there > were no problems. >=20 > When i send SIGINFO to process which is currently working with ZFS, i > see "arc_reclaim_waiters_cv": >=20 > e.g when i type: >=20 > /bin/csh >=20 > I have time (~5 seconds) to press several times 'ctrl+t' before csh is = executed: >=20 > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0%= 3512k > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0%= 3512k > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0%= 4156k >=20 > same story with find or any other commans: >=20 > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0= % 2676k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0= % 2680k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0= % 2684k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0= % 2704k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0= % 2716k > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0= % 2760k >=20 > this problem goes away after increasing vfs.zfs.arc_max > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Previously, ZFS was not actually able to evict enough dnodes to keep your arc_max under 128MB, it would have been much higher based on the number of open files you had. A recent improvement from upstream ZFS (r337653 and r337660) was pulled in that fixed this, so setting an arc_max of 128MB is much more effective now, and that is causing the side effect of "actually doing what you asked it to do", in this case, what you are asking is a bit silly. If you have a working set that is greater than 128MB, and you ask ZFS to use less than that, it'll have to constantly try to reclaim memory to keep under that very low bar. --=20 Allan Jude --hMUDOWnqlhCxhScvf4riWXfBPMk5mtVUC-- --7zBeATgR61BbcOzwawR91adYyBSQekAnN 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.22 (MingW32) iQIcBAEBAgAGBQJbj+4vAAoJEBmVNT4SmAt+sOwQALRaxWcOi75oPRj6k29S5/ob 0QKww9YwFaFwESKuceMl39ZIioqyzQuOQISsklKqKYekc5LY0qF8opZlWA9XHnI/ t35uklgGIyeBf2sXbNv4/Q20l2iQhZy8v29QKVQ2XiHGWVH499YwLU9fKVAlp1LJ lndB+1TjusMoy46AvCWWKzQFJT6Udm4hIdNSoLHoe1yk6gSiVgn7E9x+WHNMbTFu PUOD+hs0u6Qnrf6Hw/wB1iZ0SostXtpiRKWseDZFTp++ZblWcazfe438Gp1gCeeq Wa+O9FNJ+xE58jYaeRuoWTAGMnjlKG9lRyTAK60Ps2rB7Oht/D+ggBGQYWAUuXjr nRHvadpApnUSANUqomdq3RDRrsAc4a/LWJJSiwRr1QFZf7fQxQy3ScfJast/9wVy OAdBQSgW6Qz95LhyxWMtuGpAvOvVPoAIYjp+eKCqJrv9KGzEUvEBPSWXSJ5+jj4I 1k+E5/MWce7axAb+GXkIobVAWtNzKrEVJKx9/Pzb8Gzf6MAwuBCzIdjJOGzPQmjU Aq9o8kw8AbLDNVhcC/4/TsRSUX1NOP1PMUgyLHzkGW4pkIpDMdExkZtAs7FDAm6L M8+ZewBpeoKM8nIXM+jF8vKNfvX6WGnWXleBtb7THVRqb1Ob6FBJAdh/cFKjD/5f dFl36nOmKUnsZJXzdhWg =eqrU -----END PGP SIGNATURE----- --7zBeATgR61BbcOzwawR91adYyBSQekAnN-- From owner-freebsd-current@freebsd.org Wed Sep 5 15:40:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FD84FF433A; Wed, 5 Sep 2018 15:40:20 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15C3B86658; Wed, 5 Sep 2018 15:40:20 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f50.google.com with SMTP id d10-v6so10490158itj.5; Wed, 05 Sep 2018 08:40:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=kmLFZdjiIxRY/wZ5aRNWlLrgbE5CuZc0Mn8ocFx3My4=; b=hnI5G8VCvyRCTj3EUv/cGkTCJZk23zPVFZ3t0yx7Q/s3AzMZNaD/Tv21AiiYzefXiz radSli4iVY1KblhtwnkbNGP/bCiWwVgKtjbLN/lGAeaIPL5E1yE4e7Q8kY1NmBah/gsr +5LKxtzbHAx4uLb5P8Cfp30h5ZIhcCckxMC947P5IRJjEvaqdEkKCUtEu0YigX8bbrIP Wve7UJq0i4CQjnd47PdZlBX0Eqd2LOF4stAfQ1hTLDdw/i+dH5PiMDLWOvTCUD4/3brU w4AVk/PPVaocgnieN/R96saP6MPIOdVAkUSWLVTKqV2i7TrEyNcJsX5RmIcYLXEM0Snf fgtA== X-Gm-Message-State: APzg51BxfT0uKvYhvhysY+RNexbW0sQ/tZah0XeEzOVOhyl1md+6XdFu 7RL1c4v7KJes6g/vBiQUiPV/VIVL X-Google-Smtp-Source: ANB0VdYyEgl0cj3dy83KGbIad7mVKPg57gBJT93Qk4sobJN8KvlNgCf/Fk0+DDy65TkbxeRf6wAhlg== X-Received: by 2002:a02:cd0:: with SMTP id 77-v6mr26904077jan.67.1536162019146; Wed, 05 Sep 2018 08:40:19 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id g198-v6sm7093744itg.4.2018.09.05.08.40.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 08:40:18 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id 139-v6so10042996itf.0; Wed, 05 Sep 2018 08:40:18 -0700 (PDT) X-Received: by 2002:a24:db09:: with SMTP id c9-v6mr834254itg.92.1536162018500; Wed, 05 Sep 2018 08:40:18 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:9542:0:0:0:0:0 with HTTP; Wed, 5 Sep 2018 08:40:17 -0700 (PDT) In-Reply-To: <4637985A-28EF-4A6B-B8A6-764A86005E6B@FreeBSD.org> References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> <774228883.20180905001035@serebryakov.spb.ru> <4637985A-28EF-4A6B-B8A6-764A86005E6B@FreeBSD.org> From: Conrad Meyer Date: Wed, 5 Sep 2018 08:40:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs silently fails if random is not ready (?) To: FreeBSD Current Cc: freebsd-fs Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:40:20 -0000 Differential up here: https://reviews.freebsd.org/D17049 for any lurkers I didn't manage to tag in the review. Best, Conrad On Wed, Sep 5, 2018 at 12:57 AM, Mark R V Murray wrote: > Nice catch! Thanks :-) > > M > > >> On 5 Sep 2018, at 04:13, Conrad Meyer wrote: >> >> Hi Lev, >> >> I took a first attempt at reproducing this problem on a fast >> desktop-class system. First steps, give us a way to revert back to >> unseeded status: >> >> --- a/sys/dev/random/fortuna.c >> +++ b/sys/dev/random/fortuna.c >> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$"); >> >> #ifdef _KERNEL >> #include >> +#include >> #include >> #include >> #include >> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void) >> return; >> } >> >> + /* >> + * When set, pretend we do not have enough entropy to reseed yet. >> + */ >> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, { >> + if (RETURN_VALUE != 0) { >> + RANDOM_RESEED_UNLOCK(); >> + return; >> + } >> + }); >> + >> + >> #ifdef _KERNEL >> fortuna_state.fs_lasttime = now; >> #endif >> @@ -442,5 +454,11 @@ bool >> random_fortuna_seeded(void) >> { >> >> + /* When set, act as if we are not seeded. */ >> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, { >> + if (RETURN_VALUE != 0) >> + fortuna_state.fs_counter = UINT128_ZERO; >> + }); >> + >> return (!uint128_is_zero(fortuna_state.fs_counter)); >> } >> >> >> Second step, enable the failpoints and launch repro program: >> >> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)' >> debug.fail_point.random_fortuna_pre_read: off -> return(1) >> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)' >> debug.fail_point.random_fortuna_seeded: off -> return(1) >> >> $ cat ./blocked_random_poc.c >> #include >> #include >> #include >> >> int >> main(int argc, char **argv) >> { >> printf("%x\n", arc4random()); >> return (0); >> } >> >> >> $ ./blocked_random_poc >> ... >> >> >> Third step, I looked at what that process was doing: >> >> Curiously, it is not in getrandom() at all, but instead the ARND >> sysctl fallback. I probably need to rebuild world (libc) to test this >> (new libc arc4random based on Chacha). >> >> $ procstat -kk 1196 >> PID TID COMM TDNAME KSTACK >> 1196 100435 blocked_random_poc - read_random+0x3d >> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89 >> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b >> amd64_syscall+0x940 fast_syscall_common+0x101 >> >> >> When I unblocked the failpoints, it completed successfully: >> >> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off' >> debug.fail_point.random_fortuna_pre_read: return(1) -> off >> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off >> debug.fail_point.random_fortuna_seeded: return(1) -> off >> >> ... >> 9e5eb30f >> >> >> Best, >> Conrad >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > -- > Mark R V Murray > From owner-freebsd-current@freebsd.org Wed Sep 5 15:43:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4993AFF4570; Wed, 5 Sep 2018 15:43:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id C196C86A35; Wed, 5 Sep 2018 15:43:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 9F4E9CF2; Wed, 5 Sep 2018 18:43:04 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode To: Cy Schubert , Eric van Gyzen Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" References: <20180905145219.6593F83F@spqr.komquats.com> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <55393e81-f520-7c7c-4e1a-b64bb908ba4e@FreeBSD.org> Date: Wed, 5 Sep 2018 18:43:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180905145219.6593F83F@spqr.komquats.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:43:06 -0000 On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. 1.6GHz and 2.48Ghz.. Maybe... I i'm trying now. > We don't know whether it is implemented through ACPI or similar to the > old turbo jumper on the MB, which increased the clock rate and sometimes > the voltage ( required to maintain stability when increasing the clock > rate). We don't know how your MB manufacturer implemented this. I thought, it could be implemented only in one? official, way, as it is Intel's official technology, and not MoBo's one. -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Wed Sep 5 16:27:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F7FCFF59D2; Wed, 5 Sep 2018 16:27:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0D988BB5; Wed, 5 Sep 2018 16:27:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 4433BD02; Wed, 5 Sep 2018 19:27:07 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode To: Cy Schubert , Eric van Gyzen Cc: FreeBSD Current , "freebsd-hackers@freebsd.org" References: <20180905145219.6593F83F@spqr.komquats.com> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: Date: Wed, 5 Sep 2018 19:27:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180905145219.6593F83F@spqr.komquats.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 16:27:09 -0000 On 05.09.2018 17:51, Cy Schubert wrote: > I don't think you need something accurate. Ok, here is results. I'm working in single-user mode. TL;DR "Turbo" mode make "openssl" much slower (x3.5)! I can not properly interpret this result. But "turbostat" properly detect Turbo/No-Turbo mode, so it is not mistake in BIOS. (1) Trubo ENABLED, powerd IS NOT started dev.cpu.0.freq=480 no matter what. turbostat shows DIFFERENT speeds, like this (I've removed IRQ-related fields to fit in one line): Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - - - 2 0.30 1359 1600 6.18 0.00 93.52 31 0 0 0 2 0.36 863 1600 0.08 0.00 99.56 31 0 1 1 4 0.47 1462 1600 24.56 0.00 74.96 31 1 0 2 2 0.22 1670 1600 0.05 0.00 99.72 29 1 1 3 2 0.14 1792 1600 0.02 0.00 99.84 29 "openssl speed aes-256-cbc": type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 5653.98k 6159.49k 6356.31k 17271.70k 17517.23k (2) Trubo ENABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1601 under load. turbostat shows same values, but at idle Bzy_MHz drops low. openssl is the same type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 5580.78k 6155.97k 6349.23k 17273.51k 17511.77k (3) Trubo DISABLED, powerd IS NOT started dev.cpu.0.freq=1600 no matter what. turbostat shows higher numbers: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - - - 2 0.21 1807 1600 1.44 0.00 98.35 38 0 0 0 3 0.28 1764 1600 0.06 0.00 99.66 38 0 1 1 3 0.24 2052 1600 1.72 0.00 98.03 38 1 0 2 1 0.09 1629 1600 0.02 0.00 99.89 36 1 1 3 2 0.22 1664 1600 3.94 0.00 95.84 36 "openssl speed aes-256-cbc": type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 18939.95k 20638.71k 21281.24k 57836.36k 58736.39k (3.5 times faster that with Turbo ENABLED!) (4) Trubo DISABLED, powerd IS started dev.cpu.0.freq shows different values, from 60 in idle to 1600 under load. turbostat shows very low Bzy_MHz on idle, but high (suspiciously high) under load: Package Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz CPU%c1 CPU%c3 CPU%c6 - - - 1475 92.22 2666 1600 1.66 0.00 6.12 41 0 0 0 1475 92.22 2666 1600 1.62 0.00 6.16 41 0 1 1 1475 92.21 2666 1600 1.41 0.00 6.38 41 1 0 2 1475 92.21 2666 1600 1.78 0.00 6.01 38 1 1 3 1476 92.24 2666 1600 1.84 0.00 5.92 38 openssl is almost the same type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 16277.18k 20620.71k 21272.10k 57998.35k 58687.83k -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Wed Sep 5 20:14:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E79CFFBC8B for ; Wed, 5 Sep 2018 20:14:55 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6CD37180A; Wed, 5 Sep 2018 20:14:54 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-lf1-x131.google.com with SMTP id z11-v6so7082179lff.9; Wed, 05 Sep 2018 13:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sqCvDFhkhh9LKzvVEgONsMrU8vl2aglrx+oji0cvTKQ=; b=NtC2p1bN4nwOv+7oKd5n+IpSFut4q9cbfXGkfEPufwWgWdunGL23agHzkicAQ1sEXX er3iL3YiDol7/o6Uq/k0IzuMuce/mAicStzs/uP/KCJodssqyXoq40GZUkn664+sCWyo FYbZRJ+4qmBgv7KQXCuCN70iABpPwUSgXpfc+lIbZ6nCKNUWEObDU3aqqmnezi3kGLpO CjqOyResbuzXqoHAhF6mU/dx5sxrn34LTmKurZ+WOWz3BMKGPSA5FNhdJ5OtbXK2nJYI KMtjAHB1zlDnSADmbE1k496UbWKyAPnNoXpMN6wohMhQTF+cE0ZOAKgE0MlLmvFhkhxi syNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sqCvDFhkhh9LKzvVEgONsMrU8vl2aglrx+oji0cvTKQ=; b=ipESBMOEQVASzK0uF6nx+41WuWC3vl94yk+Rsx1g8SNvHqwaUcWMbeOHseBZ0FNSx5 ye36/eBBeo8NfuAiOw5ZNYU9LcHWXk5xysuxaxDzBxJhGsBYSCuNV7So6SK0k8HuQ5SB m07Zs2e5KiKrfAKhDdiLjoyMt+lYCbnUMLqfnWKFiWaGvY3g8SAdcFGHWSByZVKGvpuj OZ0crxB+AwMTdNXpm8PoYAdgvfLKVXxEEGX6SvH4/Y63rWj8PL7+eFmOHRLIq2E4TaIc VXn/KgCOdPWQR3cHSlRt2Bh0SuhdGxb4cnlx3W10prSkVtOvmorxuEiAMMHK4RKTerNl OaqQ== X-Gm-Message-State: APzg51ABd5XI22ozLI5+X74yEXEGkaR3FmYwgTv8xF8Sl+68fuwSfntS EcTyOsOKSE4zcJYanBDG2NLe47HD6/xeCyckItBg5UVQ X-Google-Smtp-Source: ANB0VdYwq6gEn9Ft/N0J+1mO/Et4cXMGy7A6ffpUjKRj6pXIpFB90WQK/p0OUAt0bdMqsUllrVPOAPOz633RqhfGo5U= X-Received: by 2002:a19:6d12:: with SMTP id i18-v6mr19206747lfc.72.1536178493140; Wed, 05 Sep 2018 13:14:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Subbsd Date: Wed, 5 Sep 2018 23:15:03 +0300 Message-ID: Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: allanjude@freebsd.org Cc: freebsd-current Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 20:14:55 -0000 On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: > > On 2018-09-05 10:04, Subbsd wrote: > > Hi, > > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > > to latest revision (r338466 the moment) and related to ARC. > > > > I can not say which revision was before except that the newver.sh > > pointed to ALPHA3. > > > > Problems are observed if you try to limit ARC. In my case: > > > > vfs.zfs.arc_max="128M" > > > > I know that this is very small. However, for two years with this there > > were no problems. > > > > When i send SIGINFO to process which is currently working with ZFS, i > > see "arc_reclaim_waiters_cv": > > > > e.g when i type: > > > > /bin/csh > > > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: > > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k > > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k > > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k > > > > same story with find or any other commans: > > > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k > > > > this problem goes away after increasing vfs.zfs.arc_max > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > Previously, ZFS was not actually able to evict enough dnodes to keep > your arc_max under 128MB, it would have been much higher based on the > number of open files you had. A recent improvement from upstream ZFS > (r337653 and r337660) was pulled in that fixed this, so setting an > arc_max of 128MB is much more effective now, and that is causing the > side effect of "actually doing what you asked it to do", in this case, > what you are asking is a bit silly. If you have a working set that is > greater than 128MB, and you ask ZFS to use less than that, it'll have to > constantly try to reclaim memory to keep under that very low bar. > > -- > Allan Jude > Hi, Thanks for comments. Mark was right when he pointed to r338416 ( https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 ). Commenting aggsum_value returns normal speed regardless of the rest of the new code from upstream. I would like to repeat that the speed with these two lines is not just slow, but _INCREDIBLY_ slow! Probably, this should be written in the relevant documentation for FreeBSD 12+ From owner-freebsd-current@freebsd.org Wed Sep 5 22:38:07 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 121D3FFEFA0; Wed, 5 Sep 2018 22:38:07 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 5AA2F76998; Wed, 5 Sep 2018 22:38:05 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-3fdff70000005b2e-2e-5b905997606b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 46.14.23342.899509B5; Wed, 5 Sep 2018 18:32:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w85MWpxS019165; Wed, 5 Sep 2018 18:32:52 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w85MWkac001650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2018 18:32:49 -0400 Date: Wed, 5 Sep 2018 17:32:46 -0500 From: Benjamin Kaduk To: Lev Serebryakov Cc: Cy Schubert , Eric van Gyzen , FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode Message-ID: <20180905223246.GH73164@kduck.kaduk.org> References: <20180905145219.6593F83F@spqr.komquats.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT0Z0ZOSHaYM9Xdoue0zUWEw9mW8x5 84HJYvvmf4wWvas2sjqwejw5+YnFY8an+Swe7cs+MgUwR3HZpKTmZJalFunbJXBl7D5ZUHCf reLx8SVMDYzrWbsYOTkkBEwkbsxewAxiCwksZpJo2qPcxcgFZG9glFiw4y0zhHOFSeLJwQNs IFUsAioSnct72UFsNiC7ofsyWLeIgKrEu//v2UEamAWuMUp8ndnDAuIIC3QxSuzoWAnWwQu0 78ujHSwQ+3IkZhx/xgwRF5Q4OfMJWJxZQEvixr+XTF2MHEC2tMTyfxwgYU4Be4n/bW1g5aIC yhJ7+w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmunlZpbopaaU bmIEh7KL8g7Gl33ehxgFOBiVeHh/XOiPFmJNLCuuzD3EKMnBpCTKK+MBFOJLyk+pzEgszogv Ks1JLT7EKMHBrCTC2/4eKMebklhZlVqUD5OS5mBREud1OtcaLSSQnliSmp2aWpBaBJOV4eBQ kuD1iJgQLSRYlJqeWpGWmVOCkGbi4AQZzgM0/Gc4UA1vcUFibnFmOkT+FKMxx6nmnknMHH/e T53ELMSSl5+XKiXOuwhknABIaUZpHtw0UDqSyN5f84pRHOg5Yd5lIFU8wFQGN+8V0ComoFVL DvSArCpJREhJNTCqdqesil/LJeTSGG+VV2vJPGexTsMzsY5TbpUOWkG8ad1FS2/dl1rkEsm6 7o32SXaPL6GnRXtC/mtqT/3Sf+3gAq7Dhg4Zm82P3ZGeIx3rWPXtdEtvygGPDW+Et18/H3wr 5/J6W+E5TWxlApxy6pvvSXDMFcnR+LBt9jPFwJr1qyxYNNefP6bEUpyRaKjFXFScCADtI4yJ IgMAAA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 22:38:07 -0000 On Wed, Sep 05, 2018 at 07:27:06PM +0300, Lev Serebryakov wrote: > On 05.09.2018 17:51, Cy Schubert wrote: > > > I don't think you need something accurate. > Ok, here is results. I'm working in single-user mode. > > TL;DR "Turbo" mode make "openssl" much slower (x3.5)! > > I can not properly interpret this result. You need to say more about what openssl is doing (i.e., how it was configured, what architecture it's on, etc.). In particular, there was for a time an AVX2 implementation for some primitives, that ended up being a net loss, since heavy use of those instructions would cause overheating and throttling. OpenSSL has a lot of custom assembly for these common primitves, with some logic to select among them both at configuration time and at runtime, so results such as this may or may not be widely transferrable. -Ben From owner-freebsd-current@freebsd.org Thu Sep 6 00:02:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB220FCE0AC; Thu, 6 Sep 2018 00:02:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7D97A874; Thu, 6 Sep 2018 00:02:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8437:602b:8ba:5268]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id C7C7BD9F; Thu, 6 Sep 2018 03:02:29 +0300 (MSK) Date: Thu, 6 Sep 2018 03:02:29 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <499689041.20180906030229@serebryakov.spb.ru> To: Benjamin Kaduk CC: Cy Schubert , Eric van Gyzen , FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode In-Reply-To: <20180905223246.GH73164@kduck.kaduk.org> References: <20180905145219.6593F83F@spqr.komquats.com> <20180905223246.GH73164@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 00:02:33 -0000 Hello Benjamin, Thursday, September 6, 2018, 1:32:46 AM, you wrote: >> > I don't think you need something accurate. >> Ok, here is results. I'm working in single-user mode. >> >> TL;DR "Turbo" mode make "openssl" much slower (x3.5)! >> >> I can not properly interpret this result. > You need to say more about what openssl is doing (i.e., how it was > configured, what architecture it's on, etc.). In particular, there > was for a time an AVX2 implementation for some primitives, that ended up > being a net loss, since heavy use of those instructions would cause > overheating and throttling. OpenSSL has a lot of custom assembly for these > common primitves, with some logic to select among them both at > configuration time and at runtime, so results such as this may or may not > be widely transferrable. It is system (very fresh ALPHA4) openssl, built with default settings. Simple single run with one thread, without AES-NI: openssl speed aes-256-cbc It is as simple as that. -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-current@freebsd.org Thu Sep 6 00:28:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2A88FCEEE3 for ; Thu, 6 Sep 2018 00:28:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47BBE7B6BF; Thu, 6 Sep 2018 00:28:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x443.google.com with SMTP id k19-v6so4332342pfi.1; Wed, 05 Sep 2018 17:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZDZ/2qwDu3VgVQl0rA/CbcIXxHJZvYHHnKF4e3UZrXg=; b=piY25T/vFvQyYGmRolxamIZ58ehR5FDBZtd8ebfFWgB32vhUCrXKPFtNLprqZVF7Bb FhtcOBwq4jT6sDZDwqsifzndZ32BLGZO8HoJIwsITbK1uMZ/AaLMazSo9rbevPmfHNPx di0vl90FxexFEM0gzKAeYuQKKQLOjce/lfjfISooO6g+oq05n1jncG5Bwg7lF9haCyw6 w0J48HwHqHQ6LAOnG2LSBRhkQV/5Q9L7Nak310Yk4tPjvTfEhrURdMueUP2gmhbV/ngD B5Dp2aN7Q6x15UlyjObcxa9UV/3I2EgvceoEahjTCI9PLPFAh9fnkOswf4vpkTIsbuCu dHAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=ZDZ/2qwDu3VgVQl0rA/CbcIXxHJZvYHHnKF4e3UZrXg=; b=asoocK8Ls/jQSJ18/8HcOYhJuXhRbZMvs3kwFy1X1SfmSZzPPFjRRJaTxap+6q2b7J QYyyEfeLUTLEeXmgvSMd5tu9A5qThl9MTQbY96oGLfwRJ6asK5avlRKrSZ6jrTzlmxnZ 4lHFTE1/cdGTxz85J+dILBFyKEfGStbpEtTQcpEinKlGsxJ8ggtBcqn/PNn8dwOXfqkZ GaDWfJZsUW1kS61jiKaq/Tl7QgIrRpz+BG1q6snNJ+WG9wBFT7DkNYOZu6QBBA90DI8C DQKtD4H6wtmvu9kRGHgjcHInI0i0xljyZetIlzKX0TcHmzmjh+YvuwifgB32iGh8l6JG /HxA== X-Gm-Message-State: APzg51AiTZsOZZe/TPnFNNJwGR8kTIDwKOl9QVx/1bVYzuI96phw2496 5BXXmIwlcJeHBue4VIzE3zK2AMKx X-Google-Smtp-Source: ANB0VdbHBhANBrNQrvJRl+9RKuCuvJF81ojSahtzmOE3yVDJhloEvCtSBK4WFLc9qQyzj1nayh6Lhg== X-Received: by 2002:a63:1316:: with SMTP id i22-v6mr267094pgl.86.1536193709330; Wed, 05 Sep 2018 17:28:29 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id h4-v6sm6170622pfe.49.2018.09.05.17.28.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 17:28:28 -0700 (PDT) Sender: Mark Johnston Date: Wed, 5 Sep 2018 20:28:25 -0400 From: Mark Johnston To: Subbsd Cc: allanjude@freebsd.org, freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Message-ID: <20180906002825.GB77324@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 00:28:31 -0000 On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: > > > > On 2018-09-05 10:04, Subbsd wrote: > > > Hi, > > > > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > > > to latest revision (r338466 the moment) and related to ARC. > > > > > > I can not say which revision was before except that the newver.sh > > > pointed to ALPHA3. > > > > > > Problems are observed if you try to limit ARC. In my case: > > > > > > vfs.zfs.arc_max="128M" > > > > > > I know that this is very small. However, for two years with this there > > > were no problems. > > > > > > When i send SIGINFO to process which is currently working with ZFS, i > > > see "arc_reclaim_waiters_cv": > > > > > > e.g when i type: > > > > > > /bin/csh > > > > > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: > > > > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k > > > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k > > > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k > > > > > > same story with find or any other commans: > > > > > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k > > > > > > this problem goes away after increasing vfs.zfs.arc_max > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > > Previously, ZFS was not actually able to evict enough dnodes to keep > > your arc_max under 128MB, it would have been much higher based on the > > number of open files you had. A recent improvement from upstream ZFS > > (r337653 and r337660) was pulled in that fixed this, so setting an > > arc_max of 128MB is much more effective now, and that is causing the > > side effect of "actually doing what you asked it to do", in this case, > > what you are asking is a bit silly. If you have a working set that is > > greater than 128MB, and you ask ZFS to use less than that, it'll have to > > constantly try to reclaim memory to keep under that very low bar. > > > > Thanks for comments. Mark was right when he pointed to r338416 ( > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > ). Commenting aggsum_value returns normal speed regardless of the rest > of the new code from upstream. > I would like to repeat that the speed with these two lines is not just > slow, but _INCREDIBLY_ slow! Probably, this should be written in the > relevant documentation for FreeBSD 12+ Could you please retest with the patch below applied, instead of reverting r338416? diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c index 2bc065e12509..9b039b7d4a96 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c @@ -538,7 +538,7 @@ typedef struct arc_state { */ int zfs_arc_meta_prune = 10000; unsigned long zfs_arc_dnode_limit_percent = 10; -int zfs_arc_meta_strategy = ARC_STRATEGY_META_BALANCED; +int zfs_arc_meta_strategy = ARC_STRATEGY_META_ONLY; int zfs_arc_meta_adjust_restarts = 4096; /* The 6 states: */ From owner-freebsd-current@freebsd.org Thu Sep 6 01:20:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B74C8FD59A4; Thu, 6 Sep 2018 01:20:51 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 3F9887DFF4; Thu, 6 Sep 2018 01:20:51 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-ea5ff70000001af6-90-5b907fbfd058 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B6.4E.06902.FBF709B5; Wed, 5 Sep 2018 21:15:43 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w861Ffe6025364; Wed, 5 Sep 2018 21:15:42 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w861FaGQ006734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2018 21:15:38 -0400 Date: Wed, 5 Sep 2018 20:15:36 -0500 From: Benjamin Kaduk To: Lev Serebryakov Cc: Cy Schubert , Eric van Gyzen , FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode Message-ID: <20180906011536.GL73164@kduck.kaduk.org> References: <20180905145219.6593F83F@spqr.komquats.com> <20180905223246.GH73164@kduck.kaduk.org> <499689041.20180906030229@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499689041.20180906030229@serebryakov.spb.ru> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrLu/fkK0wdfZqhY9p2ssJh7Mtpjz 5gOTxfbN/xgteldtZHVg9Xhy8hOLx4xP81k82pd9ZApgjuKySUnNySxLLdK3S+DKmH9/BmPB Ge6K60s/sDYwdnJ2MXJySAiYSOz//IGpi5GLQ0hgMZNE/9MD7BDOBkaJcx/XskE4V5gk9v6/ ywLSwiKgIrG09wYTiM0GZDd0X2YGsUUEVCXe/X8P1s0scI1R4uvMHhYQR1igi1FiR8dKdpAq XqCFn75uYYEYe5xR4vek5ywQCUGJkzOfgNnMAloSN/69BFrBAWRLSyz/xwES5hSwkth38j3Y NlEBZYm9fYfYJzAKzELSPQtJ9yyE7gWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0 UlNKNzGCA1qSdwfjv7tehxgFOBiVeHh/XOiPFmJNLCuuzD3EKMnBpCTKK+MBFOJLyk+pzEgs zogvKs1JLT7EKMHBrCTC6149IVqINyWxsiq1KB8mJc3BoiTOq5YIlBJITyxJzU5NLUgtgsnK cHAoSfD21gFlBYtS01Mr0jJzShDSTBycIMN5gIa7gdTwFhck5hZnpkPkTzEac5xq7pnEzPHn /dRJzEIsefl5qVLivEIgpQIgpRmleXDTQElJInt/zStGcaDnhHkfgFTxABMa3LxXQKuYgFYt OdADsqokESEl1cAYc7OvtL9a/n/lHuNYZocFiT2VHb9eydVyOl1X71i/6f2a8odhj6cuWGas HPq8wkxESLJkecHcE5mZTm718c78Z7hKrrlvDcprs2SrDa9WjIvQ1vKYJfOiSOCHg4b0x8ap 6z4UL3h7zM7g8IZ7/t8OH9Hl2mpmtUXTov4u3yEZ/eh/EVc2FCqxFGckGmoxFxUnAgDqKmX0 JQMAAA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 01:20:52 -0000 On Thu, Sep 06, 2018 at 03:02:29AM +0300, Lev Serebryakov wrote: > Hello Benjamin, > > Thursday, September 6, 2018, 1:32:46 AM, you wrote: > > >> > I don't think you need something accurate. > >> Ok, here is results. I'm working in single-user mode. > >> > >> TL;DR "Turbo" mode make "openssl" much slower (x3.5)! > >> > >> I can not properly interpret this result. > > > You need to say more about what openssl is doing (i.e., how it was > > configured, what architecture it's on, etc.). In particular, there > > was for a time an AVX2 implementation for some primitives, that ended up > > being a net loss, since heavy use of those instructions would cause > > overheating and throttling. OpenSSL has a lot of custom assembly for these > > common primitves, with some logic to select among them both at > > configuration time and at runtime, so results such as this may or may not > > be widely transferrable. > > It is system (very fresh ALPHA4) openssl, built with default settings. > Simple single run with one thread, without AES-NI: > > openssl speed aes-256-cbc > > It is as simple as that. Okay, "system openssl" and the FreeBSD version is enough to nail down the code and configuration, and I see the processor type is in the subject line. I guess posting the CPU features bits from dmesg might save whoever tries to track down the codepaths being used some time (unless that was posted already and I missed it?). -Ben From owner-freebsd-current@freebsd.org Thu Sep 6 10:33:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE6BAFF61AB for ; Thu, 6 Sep 2018 10:33:41 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 58DE7702B0 for ; Thu, 6 Sep 2018 10:33:41 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxrbY-000KOi-8v for freebsd-current@FreeBSD.org; Thu, 06 Sep 2018 12:33:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eV7Lq/X0BE3e69M6nQ8RaURclvnNoZastPmx+UFMryo=; b=IuBmAj4RjNvH43zmz80RX3CtqV 1IDN3WrkV62KJxm6eLurIeBYIp90HfeWJZEvdcX/aEtXEj8VdMTeOc1qwEGnWutG+oSVhsA9n2yWL Bqd3maRjiycW4Bk9a37vkuBQCTCJD/rvQos26eJLx6WgtqB8HH3+zVthmdayk0NY6PiU92yLeTLtM ygUNcmR1G32XIaC44MkrVaoZQaSmbnIfqOZhfK5J1cBsD+NFwJb9pGNVRfHbWjx4VY5z2TxH1QLsu nzrFs76x5yUVqpR5FzfmywiVYGfu+vOkQPYlfVpYplk6iUIBVDrr9TT4ac+21gc6mq2sTZh5QMs/A qi69NtPw==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxrbX-0001IK-PL for freebsd-current@FreeBSD.org; Thu, 06 Sep 2018 12:33:39 +0200 To: FreeBSD Current From: Jakob Alvermark Subject: SD card reader only works after a suspend/resume Message-ID: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> Date: Thu, 6 Sep 2018 12:33:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 10:33:42 -0000 Hi, I discovered this by chance. The SD card reader in my laptop has never worked, but now I noticed it does after suspending and resuming. The controller is probed and attached on boot: sdhci_acpi1: iomem 0x90a00000-0x90a00fff irq 47 on acpi0 But nothing happens if I put a card in. Unless I suspend and resume: mmc1: on sdhci_acpi1 mmcsd0: 32GB at mmc1 50.0MHz/4bit/65535-block Then I can remove and replug cards and it seems to work just fine. Jakob From owner-freebsd-current@freebsd.org Thu Sep 6 11:32:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91DE2FF7D36; Thu, 6 Sep 2018 11:32:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2C07249E; Thu, 6 Sep 2018 11:32:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 4E5E5DFA; Thu, 6 Sep 2018 14:32:30 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode To: Benjamin Kaduk Cc: Cy Schubert , Eric van Gyzen , FreeBSD Current , "freebsd-hackers@freebsd.org" References: <20180905145219.6593F83F@spqr.komquats.com> <20180905223246.GH73164@kduck.kaduk.org> <499689041.20180906030229@serebryakov.spb.ru> <20180906011536.GL73164@kduck.kaduk.org> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <478feeae-8840-176f-463b-c58aa73dd2a1@FreeBSD.org> Date: Thu, 6 Sep 2018 14:32:29 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180906011536.GL73164@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 11:32:33 -0000 On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). I'll post it tonight, but I don't think it is very openssl-specific or thermal throttling. I've monitored temperatures, of course, and monitored frequencies with turbostat. With Turbo enabled freuqnces jumps wildly and were lower than with Turbo disabled. And anyway, even frequencies jumps were not large enough to explain x3.5 difference. Another thing which puzzles me, that with Turbo disabled (!) I see frequencies 2666MHz accroding to turbostat, which seems impossible, as it is higher than official Turbo frequency (!). I don't know how to explain this. Maybe, turbostat fails? -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Thu Sep 6 13:41:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9302FFFB929; Thu, 6 Sep 2018 13:41:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 14B10774FD; Thu, 6 Sep 2018 13:41:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 0429CE27; Thu, 6 Sep 2018 16:41:27 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode To: Benjamin Kaduk Cc: Cy Schubert , Eric van Gyzen , FreeBSD Current , "freebsd-hackers@freebsd.org" References: <20180905145219.6593F83F@spqr.komquats.com> <20180905223246.GH73164@kduck.kaduk.org> <499689041.20180906030229@serebryakov.spb.ru> <20180906011536.GL73164@kduck.kaduk.org> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <0e830475-df4c-f491-1c4d-a8390cffbc36@FreeBSD.org> Date: Thu, 6 Sep 2018 16:41:27 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180906011536.GL73164@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 13:41:29 -0000 On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). CPU: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (1600.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406c4 Family=0x6 Model=0x4c Stepping=4 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics And here are two outputs of turbostat with additional settings: turbostat, Turbo DISABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, No-TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu3: MSR_IA32_MISC_ENABLE: 0x4000850089 (TCC EIST No-MWAIT PREFETCH No-TURBO) CPUID(7): No-SGX cpu3: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu3: MSR_IA32_POWER_CTL: 0x00000000 (C1E auto-promotion: DISabled) cpu3: MSR_TURBO_RATIO_LIMIT: 0x00000000 cpu3: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a0000 (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a0000 (90 C) turbostat, Turbo ENABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH TURBO) CPUID(7): No-SGX cpu1: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu1: MSR_IA32_POWER_CTL: 0x00000000 (C1E auto-promotion: DISabled) cpu1: MSR_TURBO_RATIO_LIMIT: 0x00000000 cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a0000 (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a0000 (90 C) -- // Lev Serebryakov From owner-freebsd-current@freebsd.org Thu Sep 6 22:41:11 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BECBFE7FE5 for ; Thu, 6 Sep 2018 22:41:11 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C028FC71 for ; Thu, 6 Sep 2018 22:41:10 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id w86Mf8UX089986 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Sep 2018 00:41:09 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id w86Mf895089985; Fri, 7 Sep 2018 00:41:08 +0200 (CEST) (envelope-from marius) Date: Fri, 7 Sep 2018 00:41:08 +0200 From: Marius Strobl To: Jakob Alvermark Cc: FreeBSD Current Subject: Re: SD card reader only works after a suspend/resume Message-ID: <20180906224108.GA65506@alchemy.franken.de> References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (alchemy.franken.de [0.0.0.0]); Fri, 07 Sep 2018 00:41:09 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 22:41:11 -0000 On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: > Hi, > > > I discovered this by chance. > > The SD card reader in my laptop has never worked, but now I noticed it > does after suspending and resuming. > > The controller is probed and attached on boot: > > sdhci_acpi1: iomem > 0x90a00000-0x90a00fff irq 47 on acpi0 > > But nothing happens if I put a card in. Unless I suspend and resume: > > mmc1: on sdhci_acpi1 > mmcsd0: 32GB at mmc1 > 50.0MHz/4bit/65535-block > > Then I can remove and replug cards and it seems to work just fine. I believe that making SD card insertion/removal with the integrated SDHCI controlers of newer Intel SoCs work out-of-the-box requires support for ACPI GPE interrupts and ACPI GPIO events respectively to be added to FreeBSD. Otherwise insertion/removal interrutps/events aren't reported and polling the card present state doesn't generally work as a workaround with these controllers either, unfortunately. I'm not aware of anyone working on the former, though. Polling the card present state happens to work one time after SDHCI initialization with these controllers which is why a card will be attached when inserted as part of a suspend/resume cycle (resume of mmc(4) had some bugs until some months ago, which probably explains why that procedure hasn't worked as a workaround for you in the past). Inserting the card before boot, unloading/loading sdhci_acpi.ko or triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow to attach a card, too. Marius From owner-freebsd-current@freebsd.org Thu Sep 6 23:47:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADF7EFE963A for ; Thu, 6 Sep 2018 23:47:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8D171973; Thu, 6 Sep 2018 23:47:33 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x234.google.com with SMTP id j81-v6so18342345ite.0; Thu, 06 Sep 2018 16:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hE7LLSbQHvtUTsvFeYlB/YT3lK2R9u9WS876XCtbnQM=; b=S07HyHBfJ6JZQFuk4m/2rGXuotWjKrX5b8OSIBq1H3R3ETk+sspHN+NHk8y5hgW+Jn C11g91t8qzE6nxKQ1vDbo8CFPpqdkArvM2vWxBruFJCCFOFmDSnvEQvL1nySYWFB0SA1 /ZyBfkmXQsCyr+39lMnmZ18Bptt6pyYxZTV6UFkowwIgeaumz3Biy9XvN82Q+uKx4xZo EHPUsiYeNT7nWmYcmZMJ/MJd+hnQR4ivXGRYkWmTYqSwlhIMnCACwQn0SyBDLUZ0lpql E4UVWz4IWrDb5ljmH21PL5tc1l30kkoimrYVsjhD2oWFB9qO3kIGBnIlgFkdF+jCShmV kV1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hE7LLSbQHvtUTsvFeYlB/YT3lK2R9u9WS876XCtbnQM=; b=hdisOcJImi5MJWsp2pmwa8E34ut7i7BNoj/6SPUt7NMYF7UzZcIs9Pw1avT7uMc5Me 0Rtue8TN+6WDwIX7oq5ZEz/ETxV0EFB7WQqnEbWxrR08pWIVoGq33l7/ZpQMeAuNrEmk 8XJrIx5JfMRsxt6SVw19aGEVV1b9GJuhm5+joAAv1xXSmtItYShQRnno2W4i6+1Bfy8c lEq+S21QIw+ovkGK1/LlVZlmnkm5mTPVTCin5g07C73qvmXV+WwWg85NwbvUfTYMS0D+ eKgjvij8QvC+6BlfWJ2RA7pBeU2lsow8Sp+0Z2qTNo+GGjxXjgstmje5vXhgGfRR3E1P qE0w== X-Gm-Message-State: APzg51Dl8tVFNnYaSGnEViCYd250+d7NT8WcAJuzMCEksS1Qfe8zECq1 fvmByLppTrL4XeeYFesOIF1IX8cBWnxF8ogO588UJw== X-Google-Smtp-Source: ANB0VdYCBgDD+oKeVwRX/E7ilGFBLmuNNtPUimicmVio63huSvbs/V/XhfEBMgy12/p5GE3Wz91eHRuTHj4ecpcBnQ4= X-Received: by 2002:a24:e9c6:: with SMTP id f189-v6mr4551530ith.118.1536277652448; Thu, 06 Sep 2018 16:47:32 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:b603:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 16:47:11 -0700 (PDT) In-Reply-To: <20180904105302.GD2118@home.opsec.eu> References: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> <20180904105302.GD2118@home.opsec.eu> From: Ed Maste Date: Thu, 6 Sep 2018 19:47:11 -0400 X-Google-Sender-Auth: eT48ubxkvSi2VfKivcuLKN2mPQs Message-ID: Subject: Re: github freebsd and svn freebsd To: FreeBSD Current Cc: tech-lists , Kurt Jaeger Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 23:47:33 -0000 On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > The github repo isn't official, because there are still some > consistency issues. The consistency problem is: If an repo-copy > from svn to git is done, how can that repo-copy be done a second > time and still keep the same commit ids (in the git repo) ? Restarting a svn->git conversion from scratch will usually generate the same commit hashes. However, there's an unfortunate point where the svn mirroring messed up [1] that resulted in bogus metadata on the manufactured git commit, and all hashes from that point on are broken. (Ironically this was from a bug in the svn mirroring process, not the svn->git conversion or git itself.) Assuming we're confident the issue in the svn mirroring process is fixed and will not recur we can redo the conversion, with a one-time change to all hashes from the offending commit on, and they would not change again in the future. [1] https://github.com/freebsd/freebsd/commit/c5e8194f33abf05314599d63c1e00d01aa354f47 From owner-freebsd-current@freebsd.org Fri Sep 7 00:20:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76B77FEA5A0 for ; Fri, 7 Sep 2018 00:20:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0750E72A2F for ; Fri, 7 Sep 2018 00:20:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id j198-v6so21411469ita.0 for ; Thu, 06 Sep 2018 17:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1KJ+Kr/LIxlz0Gbsl4GgVsiw7ua2iTUuvcrE1VBIHMc=; b=1GcOH7Ddfy1gJtC4507k+zNyT1JbGcgXvEYn1VtlJ+Bl1WjGkHoiDKyu9+3HgPoyCS kZbZ1T1KH0zYlKtb3Sl3L4sUunr0l+0M0p1om3XB1DsbeshKb1VpRwE8DNr/ZRx2WYXg 9t9Fckt8B9KUCWBgO4khmqYsvi2SDLrPu5ijvB5dCBfLdb229PioVhfO0bCyZf+l7FMp qBSH9VNqB2vL+jBNfeBGr5nmeu0CpfEHwqzB2uHVACzFK4B/la2lIRwMpb05wFrcWBta GxCMERb8cgf1Mp18wNugT4nN8XydSSZ+l0YRBycwMuCZGqqjhv64dFURL09VUzQLmAQd zsog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1KJ+Kr/LIxlz0Gbsl4GgVsiw7ua2iTUuvcrE1VBIHMc=; b=f4XfbIrfIBOy/FqpnBti22oQR6EyJ9uI9pQLhZ7+QkKqVkjQqDejHYnAvEG2et/i37 CWLZdHxLHUff1c++Ng1acXDDu3WiVmQSPAom30xIXuwWl7hvlzjjMW4FDAWTswjiLa1q mEa+kPQhxNGLfC54AINMtu7+R5Ju5JERzUdXu9ZOeCpo4HagyutG0ONMX1oHgm/cyDlI 1UL0DyP5j1mlwBcgGRFberD8WKZBVMFdbVkR0spd243kdg+hAL9klDI6YlJlJsv/Dc/C 67Wq3yeMv2/61pj53WITTwKowbVsl//uTmRgfHaIzRnUHqEdTdOCD8Ze+Ymhp0MfQ44o UV2Q== X-Gm-Message-State: APzg51BuT0wumFyb5hBxluXYu53JWlVWfZAIgpuaeNNbj9Yz+lpTeY7D V8mmBjAUZCZlzzkB+IFSVRVAJgYE1g7PfAWJbj4JNg== X-Google-Smtp-Source: ANB0VdY+K+poSW8BAgR/hR0FJz6LX2/uyVFcmiCsaLn2PTcAbOcdcy3JWHv0limarYdIEdW5rL+aDJJzTUvp6Kum+Xc= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr4567956ite.39.1536279627249; Thu, 06 Sep 2018 17:20:27 -0700 (PDT) MIME-Version: 1.0 References: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> <20180904105302.GD2118@home.opsec.eu> In-Reply-To: From: Warner Losh Date: Thu, 6 Sep 2018 18:11:26 -0600 Message-ID: Subject: Re: github freebsd and svn freebsd To: Ed Maste Cc: FreeBSD Current , tech-lists , Kurt Jaeger Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 00:20:28 -0000 On Thu, Sep 6, 2018, 5:49 PM Ed Maste wrote: > On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > > > The github repo isn't official, because there are still some > > consistency issues. The consistency problem is: If an repo-copy > > from svn to git is done, how can that repo-copy be done a second > > time and still keep the same commit ids (in the git repo) ? > > Restarting a svn->git conversion from scratch will usually generate > the same commit hashes. However, there's an unfortunate point where > the svn mirroring messed up [1] that resulted in bogus metadata on the > manufactured git commit, and all hashes from that point on are broken. > (Ironically this was from a bug in the svn mirroring process, not the > svn->git conversion or git itself.) > > Assuming we're confident the issue in the svn mirroring process is > fixed and will not recur we can redo the conversion, with a one-time > change to all hashes from the offending commit on, and they would not > change again in the future. > > [1] > https://github.com/freebsd/freebsd/commit/c5e8194f33abf05314599d63c1e00d01aa354f47 What is the upgrade story for current users? How do they cut over? We need a how to or something in the handbook. Warner > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Sep 7 00:45:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 670F9FEB3AA for ; Fri, 7 Sep 2018 00:45:27 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E320B73945 for ; Fri, 7 Sep 2018 00:45:26 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x530.google.com with SMTP id z27-v6so10286661edb.10 for ; Thu, 06 Sep 2018 17:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=i7fNWgGj/v8/fN/vtnGDq7sUE5uMDY0oWVVrEXypDiw=; b=VsPMkBsQF+NR7/F2lpPOg9RyKH68nvAbdD4xIRonNeq0FBdtY44PMW32bHYU7XnDUm T/6SbV0/cL9EHY72uRFlLKHv66RkvCnw7PmvarpQXW0k+ek9xX6G6uhJo8nFzedB01L3 JK2s+6Q+vpMhd3LQnMZZej/J/NMpC9h1iyHkubonwK9USLjbju1qSSbFoXIIDmb3b7ao pCd0N2iCfa9mwdukrUlW2AKs8hGQLPo/2jSUMUaoQesUDz3gXY44NIoKIA8VQnT1kwjd +cVA8OmkfuVQSaJZzTrWcaVHxGX67C/a4SALjBhDEP3ryEdX2ewstEuUUXFatOQVeO96 BHlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=i7fNWgGj/v8/fN/vtnGDq7sUE5uMDY0oWVVrEXypDiw=; b=gntHLmn67W94mHy6T6VmTcpMMP03XU4kvU6f5XvFeeq+HleQjrXCozV7GFl0P1C6P4 uJ858B+yDq4nHUIpHNs5fovvhoY+nQ4Iv12Kq63+9VY+mfTBEFQVexHBGRxi2D2ptF4q pr5ySJQeIeSGCM6ProF60rqOTab2SH2yzkQgsBuSxQX77bGUc4V0IIU7LqFxsBIqnn9s C6L0Ld+32SCff23SUSXfv96QLh2P87P4EZzWmkwdTs+4DmjuThThTBPmh5ar1kTWfOJ1 5Clq3rRTHjRnhRzEYiJknavGP1stSSZsLhwgB1bkbjaGcq8W4wZOpPQgjKjmx9oYaVZB DSUQ== X-Gm-Message-State: APzg51AiD2foWwsEHWF1fMLGLoslYvxnD40bsx1xrl2o/vKEpaEbFWiS ON1rdApR4V5i4t2BA1uDkf+Qhc0ZbovzIKZDpxvwUWy9DMY/Vlc2U2qq4ClNh3SfAs8Lgnf4Na8 YUXxEkxOgB3pJHwtD+vb2c5mQJioQnkXw3WpBtL4c8CHCmmzr8/XKmVMMjnddzNihAlWNl6ijXP zrCicqPYaiyQ== X-Google-Smtp-Source: ANB0Vdau30d3GjiKiNfSVPE3TYUKktqVp8+rgc/+s7WjN3HNTf+2Gl0EfTM33NST+ffJ76BsydKfhQ== X-Received: by 2002:aa7:c881:: with SMTP id p1-v6mr6167172eds.295.1536281125248; Thu, 06 Sep 2018 17:45:25 -0700 (PDT) Received: from mutt-hbsd (exit1.ipredator.se. [197.231.221.211]) by smtp.gmail.com with ESMTPSA id w2-v6sm4104961edw.83.2018.09.06.17.45.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 17:45:24 -0700 (PDT) Date: Thu, 6 Sep 2018 20:44:25 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Subject: Reviewer needed for D17067 Message-ID: <20180907004425.gayupxyrzlhgmoab@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m7worx5cwi5lkg4k" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 00:45:27 -0000 --m7worx5cwi5lkg4k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD recently introduced a new ELF auxiliary vector, AT_EHDRFLAGS. procstat(1) needs to be updated to reflect the new auxvec. Patch is up for review here: https://reviews.freebsd.org/D17067 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --m7worx5cwi5lkg4k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluRyeQACgkQaoRlj1JF bu5lUA/8CKoGf7hodnYvYf2kiFBI6VtZvZrQRvfF8n++q4U6w8qxP0hLW58QdVld fnVjNuM0w/YaSPPC19WlSex8Yyh3iYvnJ5HjYnrY3aKChT0rmXD8waLFdK/NkkS2 c2s1zd+pUUZg4WlgcCXT/rdJvXSMRBhUTrVv85G1KVp0XrMvLJAN1okRtASQ92yE OsA8s4trVN3CEizGF/zbiQdIhWJI611m8NoCwMujgH1NF0fo4ty5Q3odarAU8R1l Jxiyn4gxfBH877QGVFUq2ZnXQni4jw2Evy4km02O63kRBGnMpyPinfX8WtZUGEIW 6PDnIIOvdsY4HEUHookjlKytIRb4GQqvDHOSy1KHOyddQ1kI/kccAnwUMDizbB86 kzgpxRCsYqZus0eSDeSsoBmzxsnWtEQL1O4pRVaJ2cLzeZaB7bp10ISo8rFR7UUx g3T1PRhpDoNII6PxYJKjtDg5ceXkn09MVXvABOtQeiP7K1rWdFq1jlaI13+MIqWB U8n+J/UDej6xqWR3Mz3wbwh5OVP+Wvl8s1amAAvhwA6WHl/gEsq1zWBy/2U4Zcml 93nkLoUU4wDfe7kms9zbmQh4q/0+Dt2vuV61/DPKkg8zj6wN+mQkTIGCRcqVgxc6 avvI4dBddzX5GLAuHXwe0HnPZgYgMtX2fDOU1VIEAfoGQnitLEc= =Xfx2 -----END PGP SIGNATURE----- --m7worx5cwi5lkg4k-- From owner-freebsd-current@freebsd.org Fri Sep 7 01:02:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C4E2FEB9A8 for ; Fri, 7 Sep 2018 01:02:32 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D77EA74233; Fri, 7 Sep 2018 01:02:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-xd36.google.com with SMTP id y10-v6so296569ioa.10; Thu, 06 Sep 2018 18:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jCe2QSzMmAzmea/2W+oZp7SlWK9hwL6M8A7zUKhgC4k=; b=TXUYsPUWx8DnkXND/wguzz45HKIBarhqZHPTRtbYRBOkDrg8x1kCLCnyBRMU89zOj6 evd4MajC4Pi3QktRyMcUzy3HetYQnkBspFekmXNzvedYgeP7HrxtRc+RHPaHgbjMYMTu +PFkDXGK9rLYyoBW/Wnf1Da5wIxN9YmQiTzla7V8CCKJxaweklsboM5g6SrH8nnoclaB OA699oKrVo38LtzB6FhpwztLxzfAGUsx2Abt6Ljnd3E/oRWSiPtrl50BuOJA0cCDnquq sgcZAHq3UzJB3M70HmImw3Fixd0MCfvWyW78X98On1Nv/YfKtu2dlNPoXcMW+NiF0Sfa DmzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jCe2QSzMmAzmea/2W+oZp7SlWK9hwL6M8A7zUKhgC4k=; b=jOvdfIsClHQaV/0Ad9kf3rWnL+CCeL4+MlOCF2X8U3LZM9BjY6VaosUUkYp8sSIEa/ k2b9FwvYYYt7OuLkq8JR8+k3Omle/byAp0oDVFThBf61erSIjz86kk33gRJ4Scg8JW61 sZhhQiftPATjkj2gelz7fXAdl2eTRPcGWPklWvgRs7X9R9MSKMbw0hMmg999nr7yxm/M FZCD32iCgI/oJrh9LLvoXiTZiQI+i5+3tVqKPs1VW4AKdL8T4yHLRcRqt6Z+mjYnl9Xb GBQSGdyTGb45Vzwkmh1tsK7+abf5MSEnJUF8HsWR1oMNy7T9TMwZiNw5Xe9H/y6qcJTJ 35ZA== X-Gm-Message-State: APzg51CtcrSZ+DxPUIAN35dZiL/sWyfIM2PESG4r3YYwn/7ZNaMUljME uHAbMDW3i+H18b4PA4ubBe8wwQeHeIQtMbcK6prliw== X-Google-Smtp-Source: ANB0VdbJZMLU6WLUBZY/qOI7nSujsUQzaHOqXW8L0bOcrKnq7/6OgLYXojR2EtIFfZv+LEoGj/RCWXpusy+zzVBLOJI= X-Received: by 2002:a6b:e716:: with SMTP id b22-v6mr4361431ioh.239.1536282151233; Thu, 06 Sep 2018 18:02:31 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 2002:a6b:b603:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 18:02:10 -0700 (PDT) In-Reply-To: References: <18a5abcc-afbc-41c3-75ed-e33607e70c8f@zyxst.net> <20180904105302.GD2118@home.opsec.eu> From: Ed Maste Date: Thu, 6 Sep 2018 21:02:10 -0400 X-Google-Sender-Auth: y6tHM1XedmUuZRZ_U2hiwf5kT7s Message-ID: Subject: Re: github freebsd and svn freebsd To: Warner Losh Cc: FreeBSD Current , tech-lists , Kurt Jaeger Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 01:02:32 -0000 On 6 September 2018 at 20:11, Warner Losh wrote: > >> Assuming we're confident the issue in the svn mirroring process is >> fixed and will not recur we can redo the conversion, with a one-time >> change to all hashes from the offending commit on, and they would not >> change again in the future. > > What is the upgrade story for current users? How do they cut over? We need a > how to or something in the handbook. Yes, we'd need to have a fully documented migration process, and we should be able to have both 'old' and 'new' branches exist in parallel for some time. One way we could handle the mechanics of the migration itself is: * Create an alias for the current master branch - say, master-gen1 * Continue running the existing conversion * Start running a fixed svn-git conversion which pushes to master-gen2 * Document the process for migrating downstream work from one to the other * Switch master to master-gen2 * Deprecate master-gen1 after a suitable period Because of the way git works the additional branch would result in only a nominal increase in repository size. From owner-freebsd-current@freebsd.org Fri Sep 7 11:14:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B63D6FF824B for ; Fri, 7 Sep 2018 11:14:56 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4E66185776 for ; Fri, 7 Sep 2018 11:14:56 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7E76A21F00 for ; Fri, 7 Sep 2018 07:14:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 07 Sep 2018 07:14:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=eWO1bG8HTB8dwEtMSwgN4PjLsxRHBoyLezvOn4W+sMw=; b=sauPOnsj wczWQDSphG+QuMb8QE7ks+qR5v0z7dD6IpDuJWfsZirv6vAPoq6gvOUAHI2o5Hpf i9Cclms0RBwopZ8iaNT2h6sbrfinDF6Lrg5HERvaoHLwlgzYeQ4dfAEtZn39XVbi JTSSlh/H+sPNml0EuazBbW6ec3Aoibcgp5tlvps+YZP2Z2KaLo7S0BOcqHkNMswp 8bVdNQk26wwxZd3wqoA69hVwUZ5ynJq1IeTU9pEruxo23df9U3JMdWLm6wUN8KOo HuQXuWy/zJR8mnOQtdub4Ke4IHKl3bXY8w/sMlNZHZdxDWFrJC+GLiYejPR6zwWl 2pRYh+LgcJmuiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=eWO1bG8HTB8dwEtMSwgN4PjLsxRHB oyLezvOn4W+sMw=; b=qjXlvVMkjtFRP5lRORnpPj7mRXBPBgXWfLgIfmVsGib45 FOs4PBcTFhC2ksDkknPf9nNOefM5Y49cQW4y45TliBDdeks7y9hNJECVqzpgIVH+ 5XsDkL1zBnXU8himtGyBGQruUHlbQE3chCXVf4ZNujNoZfgXj5lV/JxXEJbqYu7o gQImDssGXEwxhOWE5FG9EXm91+pZyg/9k7isNGRHzSl5AeIidq835tyriQgOJsgX 7/oqCoi273AV6pwncfLn/tGfQVpTNEZS1nIakuo9bTtAQPvkv2315N/7Bv9nXFW4 /4Mj8ZmIX3uh8bT9CLa0XCiUOTiyunTOi/q8Sv9TA== X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [62.183.126.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 80C7910294 for ; Fri, 7 Sep 2018 07:14:54 -0400 (EDT) To: freebsd-current From: Yuri Pankov Subject: MacBook Pro SPI-attached keyboard/touchpad Message-ID: <9729105d-bfc4-0161-3ae9-84416bcf265b@yuripv.net> Date: Fri, 7 Sep 2018 14:14:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 11:14:56 -0000 Hi, I'm trying to run -current on MacBook Pro 2017, and with recent fixes to EFIRT, there's a hope. The problem is that nothing essential works, and while I can live with usb wifi adapter, getting internal keyboard/touchpad to work would be really nice. It has been extensively discussed on linux lists suggesting that those are connected via SPI in these models: https://bugzilla.kernel.org/show_bug.cgi?id=99891 https://bugzilla.kernel.org/show_bug.cgi?id=108331 There's also a WIP linux driver for those and touchbar: https://github.com/roadrunner2/macbook12-spi-driver Just wondering if anyone already working on it and/or can provide some initial guidance before starting my clumsy attempts at porting it. From owner-freebsd-current@freebsd.org Fri Sep 7 13:34:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB8BAFFB2EC for ; Fri, 7 Sep 2018 13:34:36 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26B8C8A0EA; Fri, 7 Sep 2018 13:34:36 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-lj1-x242.google.com with SMTP id l15-v6so12299090lji.6; Fri, 07 Sep 2018 06:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cNGFHBx8rRz96mWHXu9Vcr0rM7Ib6+HiesGPM/LB8Mk=; b=I/LF6Y5ZpGuXaWv1jMoMzNvg/LUMHzc0R1JJ3gvyW43nYdBm+2/CQJ9Sc8XgtBLUsV nafjnIj4iUi+WcZmV470BmrUnvCCIUB7iUapY1K0I3kxG1+OSbxKmvqXTQfF2vRvBh04 fO2dM7fAsZWCjpLUXGx008sehl/bojjgEIQYkj/enXV8Oc0LDOJsxqCPjpL/PS/mSnBR kw3YxnW1SGNl+2MWWe03RmzD2kiGSBwergO5DS6z1/MHSh6uLy7ABWlo2LvLgKt/Bdhn YjOCInfnGwZ0SbNxMVXcI0BPsii/EAo0mbyg4ESvDz6euLsOOcNA3eTmXOTB3IDXmnM3 8cnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cNGFHBx8rRz96mWHXu9Vcr0rM7Ib6+HiesGPM/LB8Mk=; b=XMadNI0+UDi5XjJcCWhGHJMgqHa5DGSZ+tJdyuJqA978erO7rIy/tCSNCS4E+VJ2Tv gAAzajDRWebSuDRxmuVJbqsiCDHHyqA1cihUvXq7dpiI0qclhwEJwwg2+C4NeVy1EoMP 0BmJ/iZXWr2mxAYAfo8MRh3ppnefhQASGVj00js/YBIvU1dX6i5gIrGJ59RerPNJvtzs iaz7GmrwYBmwjuHj9xkaL8zf8jwzdPGPulI3pm/EShwAlPh5rgiYfL4aeT8VHy6iOptE wBmARErCjNiYA/Yc3mKT7U36w0jFwnFChu2PdFjy5gUwwm2oFH2vNozpvo63qgGIVura d4ug== X-Gm-Message-State: APzg51Asu4zhxk8uDtQOCQ3Ka+4dTVrM+sk0e8RQuX/bkgw38pFj/KuB SiamnNvw3uoW2xbLJ//DKlC665dvTUyojyl74LgFWjcM X-Google-Smtp-Source: ANB0VdbBW8Qdl7hiXD8D/9rkxbV7YClxiFFjtGCMNmcQjkDLLZcYzl9hUzoDZZ07qwis/CdS6bjwP9f1Gut2AyshGks= X-Received: by 2002:a2e:811:: with SMTP id 17-v6mr5312642lji.140.1536327274730; Fri, 07 Sep 2018 06:34:34 -0700 (PDT) MIME-Version: 1.0 References: <20180906002825.GB77324@raichu> In-Reply-To: <20180906002825.GB77324@raichu> From: Subbsd Date: Fri, 7 Sep 2018 16:34:23 +0300 Message-ID: Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: markj@freebsd.org Cc: allanjude@freebsd.org, freebsd-current Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 13:34:37 -0000 On Thu, Sep 6, 2018 at 3:28 AM Mark Johnston wrote: > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > > On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: > > > > > > On 2018-09-05 10:04, Subbsd wrote: > > > > Hi, > > > > > > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > > > > to latest revision (r338466 the moment) and related to ARC. > > > > > > > > I can not say which revision was before except that the newver.sh > > > > pointed to ALPHA3. > > > > > > > > Problems are observed if you try to limit ARC. In my case: > > > > > > > > vfs.zfs.arc_max="128M" > > > > > > > > I know that this is very small. However, for two years with this there > > > > were no problems. > > > > > > > > When i send SIGINFO to process which is currently working with ZFS, i > > > > see "arc_reclaim_waiters_cv": > > > > > > > > e.g when i type: > > > > > > > > /bin/csh > > > > > > > > I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: > > > > > > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k > > > > load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > > > load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k > > > > load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k > > > > > > > > same story with find or any other commans: > > > > > > > > load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k > > > > load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k > > > > > > > > this problem goes away after increasing vfs.zfs.arc_max > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > > Previously, ZFS was not actually able to evict enough dnodes to keep > > > your arc_max under 128MB, it would have been much higher based on the > > > number of open files you had. A recent improvement from upstream ZFS > > > (r337653 and r337660) was pulled in that fixed this, so setting an > > > arc_max of 128MB is much more effective now, and that is causing the > > > side effect of "actually doing what you asked it to do", in this case, > > > what you are asking is a bit silly. If you have a working set that is > > > greater than 128MB, and you ask ZFS to use less than that, it'll have to > > > constantly try to reclaim memory to keep under that very low bar. > > > > > > > Thanks for comments. Mark was right when he pointed to r338416 ( > > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > > ). Commenting aggsum_value returns normal speed regardless of the rest > > of the new code from upstream. > > I would like to repeat that the speed with these two lines is not just > > slow, but _INCREDIBLY_ slow! Probably, this should be written in the > > relevant documentation for FreeBSD 12+ > > Could you please retest with the patch below applied, instead of > reverting r338416? > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > index 2bc065e12509..9b039b7d4a96 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > @@ -538,7 +538,7 @@ typedef struct arc_state { > */ > int zfs_arc_meta_prune = 10000; > unsigned long zfs_arc_dnode_limit_percent = 10; > -int zfs_arc_meta_strategy = ARC_STRATEGY_META_BALANCED; > +int zfs_arc_meta_strategy = ARC_STRATEGY_META_ONLY; > int zfs_arc_meta_adjust_restarts = 4096; > > /* The 6 states: */ Unfortunately, I can not conduct sufficiently serious regression tests right now (e.g through benchmark tools, with statistics via PMC(3), etc.). However, I can do a very surface comparison - for example with find. tested revision: 338520 loader.conf settings: vfs.zfs.arc_max="128M" meta strategy ARC_STRATEGY_META_BALANCED result: % time find /usr/ports -type f > /dev/null 0.495u 6.912s 7:20.88 1.6% 34+172k 289594+0io 0pf+0w meta strategy ARC_STRATEGY_META_ONLY: % time find /usr/ports -type f > /dev/null 0.721u 7.184s 4:57.18 2.6% 34+171k 300910+0io 0pf+0w So the difference in ~183 seconds. Both test started after a full boot OS cycle. Interestingly, despite the limit, ARC size by top(1) was constantly increasing and at the time of the end of the test it looked like this: ARC: 1161M Total, 392M MFU, 118M MRU, 32K Anon, 7959K Header, 643M Other 101M Compressed, 411M Uncompressed, 4.07:1 Ratio Swap: 16G Total, 16G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 8413 root 1 20 0 11M 3024K arc_re 4 0:07 1.49% find From owner-freebsd-current@freebsd.org Fri Sep 7 13:41:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A6E7FFB512 for ; Fri, 7 Sep 2018 13:41:02 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 9C6648A397; Fri, 7 Sep 2018 13:41:01 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyH0H-000Lpz-LA; Fri, 07 Sep 2018 15:40:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FHd0Ty1KEuNmsJ8CbLCqbGrdl4j5hTO2x2oIyNXiRIU=; b=xoqI37v4+sFveu0Nfcb6FQ6xjW pAhPV9+GKlGLH9FPXWbKnmeaAR4v+JEdZlGThxCIecehBgyB4YM2ByxpSYRvGPcfed1JEF1i5fbcU lRe2611ixtcwLq6Wj7FsWVRexkA+APvAs2fmKDywAFjMD3pnJ/Zn7bRjklBTTmprEVAXMwI2VNF2X Zo1czXFT5Fbw7UrlvVI1pj1Op+ulb+R4+lcEldS2PeAEDfo9YYEmMtJV+eSV+fFu5pCuWPWubV8sC XLGsFmq4w9gL/Ag+utwb92medUIeptbD8Ec3GLxGXcBf717ZmYILp8cFeUBuKddHZPi7T3EcAzaAZ eStTFtiQ==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyH0G-0007EW-VB; Fri, 07 Sep 2018 15:40:52 +0200 Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: Mark Johnston , Subbsd Cc: allanjude@freebsd.org, freebsd-current Current References: <20180906002825.GB77324@raichu> From: Jakob Alvermark Message-ID: <26c0f87e-2dd5-b088-8edb-0790b6b01ef0@alvermark.net> Date: Fri, 7 Sep 2018 15:40:52 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180906002825.GB77324@raichu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 13:41:02 -0000 On 9/6/18 2:28 AM, Mark Johnston wrote: > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: >>> On 2018-09-05 10:04, Subbsd wrote: >>>> Hi, >>>> >>>> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 >>>> to latest revision (r338466 the moment) and related to ARC. >>>> >>>> I can not say which revision was before except that the newver.sh >>>> pointed to ALPHA3. >>>> >>>> Problems are observed if you try to limit ARC. In my case: >>>> >>>> vfs.zfs.arc_max="128M" >>>> >>>> I know that this is very small. However, for two years with this there >>>> were no problems. >>>> >>>> When i send SIGINFO to process which is currently working with ZFS, i >>>> see "arc_reclaim_waiters_cv": >>>> >>>> e.g when i type: >>>> >>>> /bin/csh >>>> >>>> I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: >>>> >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k >>>> load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k >>>> load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k >>>> >>>> same story with find or any other commans: >>>> >>>> load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k >>>> >>>> this problem goes away after increasing vfs.zfs.arc_max >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>> Previously, ZFS was not actually able to evict enough dnodes to keep >>> your arc_max under 128MB, it would have been much higher based on the >>> number of open files you had. A recent improvement from upstream ZFS >>> (r337653 and r337660) was pulled in that fixed this, so setting an >>> arc_max of 128MB is much more effective now, and that is causing the >>> side effect of "actually doing what you asked it to do", in this case, >>> what you are asking is a bit silly. If you have a working set that is >>> greater than 128MB, and you ask ZFS to use less than that, it'll have to >>> constantly try to reclaim memory to keep under that very low bar. >>> >> Thanks for comments. Mark was right when he pointed to r338416 ( >> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 >> ). Commenting aggsum_value returns normal speed regardless of the rest >> of the new code from upstream. >> I would like to repeat that the speed with these two lines is not just >> slow, but _INCREDIBLY_ slow! Probably, this should be written in the >> relevant documentation for FreeBSD 12+ Hi, I am experiencing the same slowness when there is a bit of load on the system (buildworld for example) which I haven't seen before. I have vfs.zfs.arc_max=2G. Top is reporting ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M Other      105M Compressed, 281M Uncompressed, 2.67:1 Ratio Should I test the patch? Jakob > Could you please retest with the patch below applied, instead of > reverting r338416? > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > index 2bc065e12509..9b039b7d4a96 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > @@ -538,7 +538,7 @@ typedef struct arc_state { > */ > int zfs_arc_meta_prune = 10000; > unsigned long zfs_arc_dnode_limit_percent = 10; > -int zfs_arc_meta_strategy = ARC_STRATEGY_META_BALANCED; > +int zfs_arc_meta_strategy = ARC_STRATEGY_META_ONLY; > int zfs_arc_meta_adjust_restarts = 4096; > > /* The 6 states: */ > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Sep 7 14:39:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C8CDFFC920 for ; Fri, 7 Sep 2018 14:39:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1D018BF94 for ; Fri, 7 Sep 2018 14:39:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x231.google.com with SMTP id t5-v6so16450989qtn.3 for ; Fri, 07 Sep 2018 07:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EgwA9hJck+p9Wl4bMKw0NuYNnxvj5dkv5lQo6eil9KE=; b=Ho57TGT1oW3nGOzE4Erys+Q3ZttnEitjeWbEPuiUmqCc8wPxHqqpvmy8Lu7rVIGsJ1 iGKtHASPzSABXlvQfAUw7lsRLEN0mrNWvSw6EMOgdHdWJWWUfaoccn21LZyzIExb5R7s QhvZeVRHdGfBvywmp1dOC68btiO+3tImJxcpTQzGaA07+JPu94hCJhW7P3v8RBuolFE2 joJnkx5w9uRvig+LCPo59prliFrs+ZIAztQd4IgZ/fhuZA33AqzH3KR8aPQE5XC9rqQx n/6syBmQfhH36osLmZq16e3T7eNxTuBADB+Z/gEUFNImBpNC6/onh/inRHhjvotgfxYs oMcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EgwA9hJck+p9Wl4bMKw0NuYNnxvj5dkv5lQo6eil9KE=; b=c4oFAaNfTzJ3FUF4SjQD2uHgXwlUFos9LBGpZmt9ns/NfHvvEzvnHFysSaY1U9hrTb 8niz//zWWZ9zTZd0KfiFmwvCozxszsNTopyRXgGnHOQFw6jli6Utyw7lwofsJXfUgdME 8fKRzwlQ8v6NEAOiuBM1dTONfPkeHyYoRC/UWxLWEHN/KuNCKtKNH3HEHa7HT2j96fFH BZJ1Vc+ZbT0hieheLm1PCCT5BeZQguS9uzPc80lVcsUxOPwkcpsYkPKaxEqjE9lmLICR tTw8ZofS3V0kaCuC1kJGbxrhVmu8ip/ykFUW1JxH7VJ3ThJd805tkc64Ju4g59muTani frtQ== X-Gm-Message-State: APzg51DXTmab4eetfSlymEzYi9i2V6RuduBHAsz/U4xCvfvS1ilsFVbw 4dHZgAgJjZHVOslqqwkVZFbCFMIp+E3zEhUNyQbmH8B+/LqRQp1j0vdwrVuTIefE9gFdViiwqum gI5eD7uGkzcuMk8LF9eD94en3PkhFb8vNeHoWTvB/s0P2tyhCXUd7d2yKTW0vOMr3QOO8BlTv+w lld8a2eM7qiw== X-Google-Smtp-Source: ANB0Vdbk3MLboqPlz/jj3X+EA0/1wgxxUn1JZG2+VBmt5hOW0Tmxc1lWibMpgFaxSCMf2I97taPmiQ== X-Received: by 2002:a0c:e490:: with SMTP id n16-v6mr5979164qvl.119.1536331164086; Fri, 07 Sep 2018 07:39:24 -0700 (PDT) Received: from mutt-hbsd ([5.199.130.127]) by smtp.gmail.com with ESMTPSA id h10-v6sm4114286qtm.48.2018.09.07.07.39.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 07:39:23 -0700 (PDT) Date: Fri, 7 Sep 2018 10:38:23 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Subject: Re: ifnet use after free Message-ID: <20180907143823.m6ek7adw27e5u3nk@mutt-hbsd> References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ysli7rp2ut2dj6ul" Content-Disposition: inline In-Reply-To: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 14:39:25 -0000 --ysli7rp2ut2dj6ul Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 24, 2018 at 06:19:55PM -0400, Shawn Webb wrote: > Hey All, >=20 > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out > which commit introduced the breakage. Attached is the core.txt (which > seems nonsensical because the dump is reporting on a different > thread). If the core.txt gets scrubbed, I've posted it here: > https://gist.github.com/796ea88cec19a1fd2a85f4913482286a >=20 > I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a. >=20 > FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4 > 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT > 2018 > shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 New core.txt: https://gist.github.com/d1ee63e578c09f35d40c977093b402d6 I'm not sure if it's the same issue, but at least I'm getting a proper backtrace. I wonder if ifp or ifp->if_xname is already freed by the time ifunit_ref is called. FreeBSD hbsd-dev-laptop 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #6 a581146ba17(har= dened/current/master)-dirty: Mon Sep 3 12:51:49 EDT 2018 shawn@hbsd-de= v-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 panic: vm_fault_hold: fault on nofault entry, addr: 0xfffffe0000685000 GNU gdb (GDB) 8.1.1 [GDB v8.1.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/de= bug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: [12101] panic: vm_fault_hold: fault on nofault entry, addr: 0xfffffe0000685= 000 [12101] cpuid =3D 3 [12101] time =3D 1536281241 [12101] __HardenedBSD_version =3D 1200058 __FreeBSD_version =3D 1200083 [12101] version =3D FreeBSD 12.0-ALPHA4 #6 a581146ba17(hardened/current/ma= ster)-dirty: Mon Sep 3 12:51:49 EDT 2018 [12101] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC [12101] KDB: stack backtrace: [12101] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff= e1fef53d1c0 [12101] vpanic() at vpanic+0x1a8/frame 0xfffffe1fef53d220 [12101] panic() at panic+0x43/frame 0xfffffe1fef53d280 [12101] vm_fault_hold() at vm_fault_hold+0x1faf/frame 0xfffffe1fef53d3d0 [12101] vm_fault() at vm_fault+0x60/frame 0xfffffe1fef53d410 [12101] trap_pfault() at trap_pfault+0x188/frame 0xfffffe1fef53d460 [12101] trap() at trap+0x560/frame 0xfffffe1fef53d570 [12101] calltrap() at calltrap+0x8/frame 0xfffffe1fef53d570 [12101] --- trap 0xc, rip =3D 0xffffffff80bd5455, rsp =3D 0xfffffe1fef53d64= 0, rbp =3D 0xfffffe1fef53d640 --- [12101] strncmp() at strncmp+0x15/frame 0xfffffe1fef53d640 [12101] ifunit_ref() at ifunit_ref+0x51/frame 0xfffffe1fef53d680 [12101] ifioctl() at ifioctl+0x7bd/frame 0xfffffe1fef53d750 [12101] kern_ioctl() at kern_ioctl+0x2c0/frame 0xfffffe1fef53d7b0 [12101] sys_ioctl() at sys_ioctl+0x16e/frame 0xfffffe1fef53d880 [12101] amd64_syscall() at amd64_syscall+0x29e/frame 0xfffffe1fef53d9b0 [12101] fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe1f= ef53d9b0 [12101] --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x3c2595b7f8a, = rsp =3D 0x7461b1772838, rbp =3D 0x7461b17728a0 --- [12101] Uptime: 3h21m41s [12101] Dumping 8310 out of 65330 MB:..1%..11%..21%..31%..41%..51%..61%..71= %..81%..91% __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:368 #2 0xffffffff80aec5b6 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff80aeca08 in vpanic (fmt=3D, ap=3D0xfffffe1fef5= 3d260) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80aec763 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:801 #5 0xffffffff80e285cf in vm_fault_hold (map=3D0xfffff80005001000,=20 vaddr=3D, fault_type=3D1 '\001', fault_flags=3D,=20 m_hold=3D0x0) at /usr/src/sys/vm/vm_fault.c:585 #6 0xffffffff80e265d0 in vm_fault (map=3D0xfffff80005001000,=20 vaddr=3D, fault_type=3D1 '\001', fault_flags=3D0) at /usr/src/sys/vm/vm_fault.c:536 #7 0xffffffff80fc0648 in trap_pfault (frame=3D0xfffffe1fef53d580,=20 usermode=3D) at /usr/src/sys/amd64/amd64/trap.c:829 #8 0xffffffff80fbfcd0 in trap (frame=3D0xfffffe1fef53d580) at /usr/src/sys/amd64/amd64/trap.c:441 #9 #10 0xffffffff80bd5455 in strncmp (s1=3D0xfffffe1fef53d7d0 "epair5b",=20 s2=3D0xfffffe0000685b28 , n=3D16) at /usr/src/sys/libkern/strncmp.c:44 #11 0xffffffff80be9c11 in ifunit_ref (name=3D0xfffffe1fef53d7d0 "epair5b") at /usr/src/sys/net/if.c:2419 #12 0xffffffff80bea4bd in ifioctl (so=3D0xfffff804c8cbc368, cmd=3D322334953= 6,=20 data=3D0xfffffe1fef53d7d0 "epair5b", td=3D0xfffff8006298d580) at /usr/src/sys/net/if.c:3076 #13 0xffffffff80b58ee0 in fo_ioctl (fp=3D, com=3D,=20 active_cred=3D0x0, td=3D, data=3D) at /usr/src/sys/sys/file.h:330 #14 kern_ioctl (td=3D0xfffff8006298d580, fd=3D3, com=3D,=20 data=3D0x10 ) at /usr/src/sys/kern/sys_generic.c:800 #15 0xffffffff80b58b9e in sys_ioctl (td=3D0xfffff8006298d580,=20 uap=3D0xfffff8006298d948) at /usr/src/sys/kern/sys_generic.c:712 #16 0xffffffff80fc0e5e in syscallenter (td=3D0xfffff8006298d580) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #17 amd64_syscall (td=3D0xfffff8006298d580, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:1043 #18 #19 0x000003c2595b7f8a in ?? () Backtrace stopped: Cannot access memory at address 0x7461b1772838 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --ysli7rp2ut2dj6ul Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluSjVoACgkQaoRlj1JF bu4cCw//UvZoz6R+gH5P9EIaF82NQYjJI0kjyYN57miEWzaA9q2Ay2BnA5E6z3zv N6oiUXV0vT2nGnlPb3bD1l1gsT4rBnVuxa/0dD2RbKM2v5FOOosiaOVKj3y5GQlw WLQwEdLU+stXvrv0MztuBSRyYG/N6NHHXfklHaoXB8eF1qq98G3wD1EhvzSziaCK RRQ6c4yWLOEe9y1YWnNxA0QMJWmMVpLZj99+1qPpcy5sSpnzxKgoy4tZynANDT38 3DQaBINp/fY8i1bJhJU2TpG7fGz4PBH58/DOip+yUPBlxb+7mqfqQdG4Y3AWv5OX 5crYSshmnuVj4bV7xjZXVHcT8Q8xL8U8+sIeHaacHcfXIUATgkd4fzDD82rRZNJV YtCJagOJydVjyXNcUn572MwYvzS77nH34QDUbQUIHE5rORePWSlysXpxLpc+OGKs VZdwMccpcvdT7u3g77m9OMbOC6MVJdiMA2UJIZjI4ruyEJsNcVodZAWfoeGgDP9J nevoFOWysj0z4Qgjdse8lKxJDSzGzJOOKCLdRD6nbToBpC8s4+Uf4xIKpUl4coVE p9hYaQm9mpba72nM0cnD5eEznnik3WPg9j2ps+/g5UZioNXC8cIfRrhunVMytrDx RRNuScdpn2KOHeffQBgWlrheIInIosqjXZfj4BaK9H8QsDxepgs= =R/5K -----END PGP SIGNATURE----- --ysli7rp2ut2dj6ul-- From owner-freebsd-current@freebsd.org Fri Sep 7 14:52:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0D5BFFCF98 for ; Fri, 7 Sep 2018 14:52:15 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4A98A8C975; Fri, 7 Sep 2018 14:52:14 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyI7J-000LsX-Mg; Fri, 07 Sep 2018 16:52:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0n4yJcDKAyenm06zewLHSN3A1PyjDPXzdpJBKdQsFvo=; b=GBO0oDTAwYN85o4I9lW/ja/RAg dItvvg6/COGwae0ujpUJubgTBBWPUpwazH4FX9foGCj0u5Lo/fiZcVxC0JMa76vCkxDqJMZImwE1e nOj06lYB0sV/v8cl4HJQC2BOuMhJv5wKFsCYoXbMqH7TZpxP8uZzllSM4KiHs/CRJdPy2Y9vlRFnA IJoYj+knpbOdNfK1ueIhwSrSzHDgzSz9GqG6Z0kYL+opNMZxyrPjCzPkOUnigYXvWm2wQWG7L7dIk YFOho3r+BhQmF1Z9gWirAfzi2m5KxGhmc4DStudMyDBLF2S7BBbzAz7gw3K8nzX6HCH8ktdnEglvF nev1neFQ==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyI7J-000Hnz-5n; Fri, 07 Sep 2018 16:52:13 +0200 Subject: Re: SD card reader only works after a suspend/resume To: Marius Strobl Cc: FreeBSD Current References: <34659383-981f-e627-dfaa-d486685a11f5@alvermark.net> <20180906224108.GA65506@alchemy.franken.de> From: Jakob Alvermark Message-ID: <3a219e6e-0e27-00d7-50ff-e6671f717bc6@alvermark.net> Date: Fri, 7 Sep 2018 16:52:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180906224108.GA65506@alchemy.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 14:52:16 -0000 On 9/7/18 12:41 AM, Marius Strobl wrote: > On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: >> Hi, >> >> >> I discovered this by chance. >> >> The SD card reader in my laptop has never worked, but now I noticed it >> does after suspending and resuming. >> >> The controller is probed and attached on boot: >> >> sdhci_acpi1: iomem >> 0x90a00000-0x90a00fff irq 47 on acpi0 >> >> But nothing happens if I put a card in. Unless I suspend and resume: >> >> mmc1: on sdhci_acpi1 >> mmcsd0: 32GB at mmc1 >> 50.0MHz/4bit/65535-block >> >> Then I can remove and replug cards and it seems to work just fine. > I believe that making SD card insertion/removal with the integrated > SDHCI controlers of newer Intel SoCs work out-of-the-box requires > support for ACPI GPE interrupts and ACPI GPIO events respectively to > be added to FreeBSD. Otherwise insertion/removal interrutps/events > aren't reported and polling the card present state doesn't generally > work as a workaround with these controllers either, unfortunately. > I'm not aware of anyone working on the former, though. > > Polling the card present state happens to work one time after SDHCI > initialization with these controllers which is why a card will be > attached when inserted as part of a suspend/resume cycle (resume of > mmc(4) had some bugs until some months ago, which probably explains > why that procedure hasn't worked as a workaround for you in the past). > Inserting the card before boot, unloading/loading sdhci_acpi.ko or > triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow > to attach a card, too. If a card is inserted before booting it is not detected. Removing and inserting card after boot is not detected unless I suspend and resume. After I have suspended and resumed once, cards are detected. Removals and insertions are detected as they happen. Jakob From owner-freebsd-current@freebsd.org Fri Sep 7 16:05:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26081FFE9C0 for ; Fri, 7 Sep 2018 16:05:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94CF48F2D0; Fri, 7 Sep 2018 16:05:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x634.google.com with SMTP id ba4-v6so6791637plb.11; Fri, 07 Sep 2018 09:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=siqUhPf2dHPsQb6rUsMMqRAcPWvJvCF73NCY5fgDEcU=; b=iYcGr/czZtM+xo/SX182kI4d9bRCjZVQ9gfvTeqaGtN/GcoiMMTfuY9IO+thRkDLGO Wegb0kWJSogfBAEg8lnC+PuMSjCyREJBykDTeKLbW7jaNs7WA1PgBS5qa2V9SlmCxrjM w4MFEHPoSuc1n5v63De9mD73+8sFuFa2gjzkDUf9D+xeV9dkHRz1ChfqTCCNikDZBm7p 0065SqmRq4VydzuI/ijcFOj6JDr9J4fFwfGzEL/ZpCd2NwT144NPiQePfJSSq5AP926p bxORWDgtW5MySHIa9C0GqmVh7gByt17kg6nRcbu8R0IZ9itMcET/0p0xhLZENxq5FJj0 SBGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=siqUhPf2dHPsQb6rUsMMqRAcPWvJvCF73NCY5fgDEcU=; b=iunM+56ejcpyrQBRNrdOQaiwvKX7cRGQoUSYwyLPabPQ1bTSm8AMf4R0P/ztMT+r3s 5WiUmEp3llVedKCajs/f8tu9EA/vwNdqnCpuy8633t6K1CoDgBU//1BNz3kzrEG0ODSj Uj1RJAwQkAwxtAxSWiZUaFAD5xyvhCVm19kDyOlfDE2s3M7+36wASbkD43UL/2YbqfoG Pqj+E7WVeKu0O90Y5xWP++HFVYDgl1QZ7GKVSbRrdApo0ebUiRbue3Fhh+upOa5fidnn wRQcfe1yMsqnRdHNi3Lx/ynTifUEnGtgc6sWL+wZFNtSGnF6LlVI35NZRPElT3Cq2yr7 L+JA== X-Gm-Message-State: APzg51C7fHdfkkBnVRjCSuzxFCp2ggaglHY8EMVML5dndfb0BoYtOvPv b1uu1ZdiKKMt1kbGxyn0JIk= X-Google-Smtp-Source: ANB0VdZhUSw3Ga50e8gfZk0Fi5fOgLaPOwRYyGVaESnCtp1UWNKhkowoX7KAu+tGiPpO3L5ZFLeWNg== X-Received: by 2002:a17:902:6b0b:: with SMTP id o11-v6mr8669805plk.214.1536336327584; Fri, 07 Sep 2018 09:05:27 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id b64-v6sm11142762pfg.66.2018.09.07.09.05.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 09:05:26 -0700 (PDT) Sender: Mark Johnston Date: Fri, 7 Sep 2018 12:05:23 -0400 From: Mark Johnston To: Subbsd Cc: allanjude@freebsd.org, freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Message-ID: <20180907160523.GC63224@raichu> References: <20180906002825.GB77324@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 16:05:29 -0000 On Fri, Sep 07, 2018 at 04:34:23PM +0300, Subbsd wrote: > > > > On 2018-09-05 10:04, Subbsd wrote: > > > > > Hi, > > > > > > > > > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > > > > > to latest revision (r338466 the moment) and related to ARC. > > > > > > Unfortunately, I can not conduct sufficiently serious regression tests > right now (e.g through benchmark tools, with statistics via PMC(3), > etc.). However, I can do a very surface comparison - for example with > find. > tested revision: 338520 > loader.conf settings: vfs.zfs.arc_max="128M" > > meta strategy ARC_STRATEGY_META_BALANCED result: > > % time find /usr/ports -type f > /dev/null > 0.495u 6.912s 7:20.88 1.6% 34+172k 289594+0io 0pf+0w > > meta strategy ARC_STRATEGY_META_ONLY: > % time find /usr/ports -type f > /dev/null > 0.721u 7.184s 4:57.18 2.6% 34+171k 300910+0io 0pf+0w > > So the difference in ~183 seconds. > Both test started after a full boot OS cycle. Seems like a pretty substantial difference. Is this roughly the same performance that you had before the upgrade to -ALPHA4? From owner-freebsd-current@freebsd.org Fri Sep 7 16:07:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34624FFEA26 for ; Fri, 7 Sep 2018 16:07:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4A128F3C3; Fri, 7 Sep 2018 16:06:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pl1-x641.google.com with SMTP id t19-v6so6793300ply.13; Fri, 07 Sep 2018 09:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ujuLF+il8wMf0gBstv5eTMcqjp31MHkLR1nOUSELa6A=; b=QT6Wirg1sgu7QW50sx/QdO3vK6tBTffvG7RDtstZWv21hOY7Q94UcB2+jd6wNVyOcQ 8jFziFQeMQw0aD+lwTOJlwValJlvPcWLOT8iGVodhGpeIOPT+uwDPnJn4GNGTnKiUWdg UuaT2CpW0NYoqWCtuGWkpU/3TuoratLTv+WBOI8+Z6xkJ0oi7/80QQEgIvFTSzpJzUVj cgEWhrnUGCXKAyqJeJfqDcNL8JOKBa80VpHOidT5IUeOZm8TFxARJ61htZaLUzm6fUUn wiV671bK/gHAmXDnBO0kM2xfaQ/xbF7DzloVP1siy6Mgsei1TEYUcCqzwxXFQOMkkCc+ MXdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ujuLF+il8wMf0gBstv5eTMcqjp31MHkLR1nOUSELa6A=; b=GOi2mob1RrhBcS6+8dKLz6IqiKW3hWLMe76x/jbJmSa5wL0aXk+kNp2aNZ6IdY+nss I9LzLZopl7iUqNbd5hOByCsbE/Xe5MBOGxwAThbAiXDXK7ZrKl64jQrtUTqPktGmC01/ T/1rvgPZm0ll3xmsZ0tT0N1kM7BNuzhZ06X7juKrqW33e1LMc+kEqpyMMvpAczqYjrpb GUKEGa/UitgRl09fsnbsklFHzqX9sjZos6ithN0+cp3JfjNFT5UEE3rRqNo/0XxuGIww vn6VZhqk1ih/0P6lXWH1KpXd3nlwpFEv5m4oeVz8fQLJ1V6J2jWpk5qCG/GYKACrJ14j PB/w== X-Gm-Message-State: APzg51DIcDCw1hDZ3z/Vbch/5FjknYzX9AnPhvWadGbDAPhYV1UsFAmz yoodDI1+bp03bSsyZ4LFs+AumSzjhnE= X-Google-Smtp-Source: ANB0VdarS4dkfj1ZL0VNdObObJrMKZgq2ic5+3bUjcHUyPLIxSZXA95OJxlP7vUUni9whjPcED5ZUA== X-Received: by 2002:a17:902:7c8c:: with SMTP id y12-v6mr8779221pll.283.1536336418497; Fri, 07 Sep 2018 09:06:58 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id x24-v6sm10648422pfh.67.2018.09.07.09.06.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 09:06:57 -0700 (PDT) Sender: Mark Johnston Date: Fri, 7 Sep 2018 12:06:54 -0400 From: Mark Johnston To: Jakob Alvermark Cc: Subbsd , allanjude@freebsd.org, freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Message-ID: <20180907160654.GD63224@raichu> References: <20180906002825.GB77324@raichu> <26c0f87e-2dd5-b088-8edb-0790b6b01ef0@alvermark.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26c0f87e-2dd5-b088-8edb-0790b6b01ef0@alvermark.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 16:07:00 -0000 On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: > On 9/6/18 2:28 AM, Mark Johnston wrote: > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: > >>> On 2018-09-05 10:04, Subbsd wrote: > >>>> Hi, > >>>> > >>>> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > >>>> to latest revision (r338466 the moment) and related to ARC. > >>>> > >>>> I can not say which revision was before except that the newver.sh > >>>> pointed to ALPHA3. > >>>> > >>>> Problems are observed if you try to limit ARC. In my case: > >>>> > >>>> vfs.zfs.arc_max="128M" > >>>> > >>>> I know that this is very small. However, for two years with this there > >>>> were no problems. > >>>> > >>>> When i send SIGINFO to process which is currently working with ZFS, i > >>>> see "arc_reclaim_waiters_cv": > >>>> > >>>> e.g when i type: > >>>> > >>>> /bin/csh > >>>> > >>>> I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: > >>>> > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k > >>>> load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k > >>>> load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k > >>>> > >>>> same story with find or any other commans: > >>>> > >>>> load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k > >>>> > >>>> this problem goes away after increasing vfs.zfs.arc_max > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >>>> > >>> Previously, ZFS was not actually able to evict enough dnodes to keep > >>> your arc_max under 128MB, it would have been much higher based on the > >>> number of open files you had. A recent improvement from upstream ZFS > >>> (r337653 and r337660) was pulled in that fixed this, so setting an > >>> arc_max of 128MB is much more effective now, and that is causing the > >>> side effect of "actually doing what you asked it to do", in this case, > >>> what you are asking is a bit silly. If you have a working set that is > >>> greater than 128MB, and you ask ZFS to use less than that, it'll have to > >>> constantly try to reclaim memory to keep under that very low bar. > >>> > >> Thanks for comments. Mark was right when he pointed to r338416 ( > >> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > >> ). Commenting aggsum_value returns normal speed regardless of the rest > >> of the new code from upstream. > >> I would like to repeat that the speed with these two lines is not just > >> slow, but _INCREDIBLY_ slow! Probably, this should be written in the > >> relevant documentation for FreeBSD 12+ > > Hi, > > I am experiencing the same slowness when there is a bit of load on the > system (buildworld for example) which I haven't seen before. Is it a regression following a recent kernel update? > I have vfs.zfs.arc_max=2G. > > Top is reporting > > ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M Other >      105M Compressed, 281M Uncompressed, 2.67:1 Ratio > > Should I test the patch? I would be interested in the results, assuming it is indeed a regression. From owner-freebsd-current@freebsd.org Fri Sep 7 17:27:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF99310072B3 for ; Fri, 7 Sep 2018 17:27:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4600971C64; Fri, 7 Sep 2018 17:27:57 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id yKXqfjbt7WppDyKXsfNbxS; Fri, 07 Sep 2018 11:27:50 -0600 X-Authority-Analysis: v=2.3 cv=YIcrNiOx c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=JBFolyDoGHsA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=5R4wDWXbYSEQHXC5hsYA:9 a=1GIGVPUOJR0cIUBz:21 a=kV9XivK--J73BiRn:21 a=wPNLvfGTeEIA:10 a=rkHIVglFI-3vNNMI_WsA:9 a=wijcN7gyilmvY5eC:21 a=j0QCUOnUCc-NYdUK:21 a=LJZpL5zafY3ct8uS:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.168.101.95] (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 38609A00; Fri, 7 Sep 2018 10:28:43 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 Date: Fri, 7 Sep 2018 10:27:49 -0700 To: Mark Johnston , Jakob Alvermark CC: Subbsd , "allanjude@freebsd.org" , freebsd-current Current Message-Id: <20180907172843.38609A00@spqr.komquats.com> X-CMAE-Envelope: MS4wfFqcFk16wTWoFwWvQg7vmz4QafBqmq03nGAOpOgrK7wn2lt73V5Xtmb5cM5EqQxhxMD71GnV9fieClDTONVRx5Lzg1gzchVSf61uBxgNogkAOduOxJSD hn2Id2a8vjkctU0O4U/ZBAoyaSfNYMtSiOrbsVIod74hKR2xf7zXpUMeexFfbhT0dsnTz5kA7LaEU9Ec9Jq/wwUkOde9LYzVfMq9ZB5BJCRESHuDMWUDUQRC wWGZBKfxPsAtmImraySEfR4ThyFHDFCdcTJDC/7LTVuRRIVrCJy/zA7+OidkfPAm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 17:27:59 -0000 I'd be interested in seeing systat -z output. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Mark Johnston Sent: 07/09/2018 09:09 To: Jakob Alvermark Cc: Subbsd; allanjude@freebsd.org; freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: > On 9/6/18 2:28 AM, Mark Johnston wrote: > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrot= e: > >>> On 2018-09-05 10:04, Subbsd wrote: > >>>> Hi, > >>>> > >>>> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 > >>>> to latest revision (r338466 the moment) and related to ARC. > >>>> > >>>> I can not say which revision was before except that the newver.sh > >>>> pointed to ALPHA3. > >>>> > >>>> Problems are observed if you try to limit ARC. In my case: > >>>> > >>>> vfs.zfs.arc_max=3D"128M" > >>>> > >>>> I know that this is very small. However, for two years with this the= re > >>>> were no problems. > >>>> > >>>> When i send SIGINFO to process which is currently working with ZFS, = i > >>>> see "arc_reclaim_waiters_cv": > >>>> > >>>> e.g when i type: > >>>> > >>>> /bin/csh > >>>> > >>>> I have time (~5 seconds) to press several times 'ctrl+t' before csh = is executed: > >>>> > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s= 0% 3512k > >>>> load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > >>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s= 0% 3512k > >>>> load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s= 0% 4156k > >>>> > >>>> same story with find or any other commans: > >>>> > >>>> load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00= s 0% 2676k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00= s 0% 2680k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00= s 0% 2684k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00= s 0% 2704k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00= s 0% 2716k > >>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00= s 0% 2760k > >>>> > >>>> this problem goes away after increasing vfs.zfs.arc_max > >>>> _______________________________________________ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebs= d.org" > >>>> > >>> Previously, ZFS was not actually able to evict enough dnodes to keep > >>> your arc_max under 128MB, it would have been much higher based on the > >>> number of open files you had. A recent improvement from upstream ZFS > >>> (r337653 and r337660) was pulled in that fixed this, so setting an > >>> arc_max of 128MB is much more effective now, and that is causing the > >>> side effect of "actually doing what you asked it to do", in this case= , > >>> what you are asking is a bit silly. If you have a working set that is > >>> greater than 128MB, and you ask ZFS to use less than that, it'll have= to > >>> constantly try to reclaim memory to keep under that very low bar. > >>> > >> Thanks for comments. Mark was right when he pointed to r338416 ( > >> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/= common/fs/zfs/arc.c?r1=3D338416&r2=3D338415&pathrev=3D338416 > >> ). Commenting aggsum_value returns normal speed regardless of the rest > >> of the new code from upstream. > >> I would like to repeat that the speed with these two lines is not just > >> slow, but _INCREDIBLY_ slow! Probably, this should be written in the > >> relevant documentation for FreeBSD 12+ >=20 > Hi, >=20 > I am experiencing the same slowness when there is a bit of load on the=20 > system (buildworld for example) which I haven't seen before. Is it a regression following a recent kernel update? > I have vfs.zfs.arc_max=3D2G. >=20 > Top is reporting >=20 > ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M Other > =A0=A0=A0=A0 105M Compressed, 281M Uncompressed, 2.67:1 Ratio >=20 > Should I test the patch? I would be interested in the results, assuming it is indeed a regression. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Sep 8 10:40:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A718FFEFCB0 for ; Sat, 8 Sep 2018 10:40:10 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4314F8F81D; Sat, 8 Sep 2018 10:40:10 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyaet-000Mz6-PT; Sat, 08 Sep 2018 12:40:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID :From:References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OMMpJ+zI1S2cU0oesdu3OEiz1+9TMNqC+XxYHOgGxQE=; b=r7c6fs+lDJP0XWmh1X7qvkbO9m TS+LDB3WkPxhHiZwDEgSPACb7WLLb7oFa3HfVYmigwVR9cNQyRVPuTw3HtINhs542bSRvRg92VzAG yd7Pu1PBn3HdU4xWjzxVe/1vML2dwBRIS3ZE5qHJtrpSD7HUAuwXp9X38mv608BNUy7egWX3Icry3 4cM+GUO3sjlvDdBGn7px7+sD6xNW1ITK/LS5Gwwq6s/iw6KOcomK3zZ8E+Z0ZmB9leB++MJWNA141 FBFJFTEoUmxrN+tFHGpXeBGY+cbGOveWVAYxceOQngVqwAv3SIn2VFhjH8VywdHgag2JD1ZSof3v5 ARmFf5VQ==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fyaeq-000CBB-R5; Sat, 08 Sep 2018 12:40:05 +0200 Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: Cy Schubert , Mark Johnston Cc: Subbsd , "allanjude@freebsd.org" , freebsd-current Current References: <20180907172843.38609A00@spqr.komquats.com> From: Jakob Alvermark Message-ID: Date: Sat, 8 Sep 2018 12:40:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180907172843.38609A00@spqr.komquats.com> Content-Language: en-US Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 10:40:10 -0000                        Total     MFU     MRU    Anon     Hdr L2Hdr   Other      ZFS ARC            667M    186M    168M     13M   3825K 0K    295M                                 rate    hits  misses   total hits total misses      arcstats                  : 99%   65636     605 167338494      9317074      arcstats.demand_data      : 57%     431     321 13414675      2117714      arcstats.demand_metadata  : 99%   65175     193 152969480      5344919      arcstats.prefetch_data    :  0%       0      30 3292       401344      arcstats.prefetch_metadata: 32%      30      61 951047      1453097      zfetchstats               :  9%     119    1077 612582     55041789      arcstats.l2               :  0%       0       0 0            0      vdev_cache_stats          :  0%       0       0 0            0 This is while a 'make -j8 buildworld' (it has 8 cores) is going. SSH'ing to the machine while the buildworld is going it takes 40-60 seconds to get to the shell! Hitting ^T while waiting: load: 1.06  cmd: zsh 45334 [arc_reclaim_waiters_cv] 56.11r 0.00u 0.10s 0% 5232k I will test the patch below and report back. Jakob On 9/7/18 7:27 PM, Cy Schubert wrote: > I'd be interested in seeing systat -z output. > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > ------------------------------------------------------------------------ > From: Mark Johnston > Sent: 07/09/2018 09:09 > To: Jakob Alvermark > Cc: Subbsd; allanjude@freebsd.org; freebsd-current Current > Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 > > On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: > > On 9/6/18 2:28 AM, Mark Johnston wrote: > > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > > >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude > wrote: > > >>> On 2018-09-05 10:04, Subbsd wrote: > > >>>> Hi, > > >>>> > > >>>> I'm seeing a huge loss in performance ZFS after upgrading > FreeBSD 12 > > >>>> to latest revision (r338466 the moment) and related to ARC. > > >>>> > > >>>> I can not say which revision was before except that the newver.sh > > >>>> pointed to ALPHA3. > > >>>> > > >>>> Problems are observed if you try to limit ARC. In my case: > > >>>> > > >>>> vfs.zfs.arc_max="128M" > > >>>> > > >>>> I know that this is very small. However, for two years with > this there > > >>>> were no problems. > > >>>> > > >>>> When i send SIGINFO to process which is currently working with > ZFS, i > > >>>> see "arc_reclaim_waiters_cv": > > >>>> > > >>>> e.g when i type: > > >>>> > > >>>> /bin/csh > > >>>> > > >>>> I have time (~5 seconds) to press several times 'ctrl+t' before > csh is executed: > > >>>> > > >>>> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u > 0.00s 0% 3512k > > >>>> load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > >>>> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u > 0.01s 0% 3512k > > >>>> load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u > 0.01s 0% 4156k > > >>>> > > >>>> same story with find or any other commans: > > >>>> > > >>>> load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u > 0.00s 0% 2676k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u > 0.00s 0% 2680k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u > 0.00s 0% 2684k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u > 0.00s 0% 2704k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u > 0.00s 0% 2716k > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u > 0.00s 0% 2760k > > >>>> > > >>>> this problem goes away after increasing vfs.zfs.arc_max > > >>>> _______________________________________________ > > >>>> freebsd-current@freebsd.org mailing list > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >>>> To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > >>>> > > >>> Previously, ZFS was not actually able to evict enough dnodes to keep > > >>> your arc_max under 128MB, it would have been much higher based > on the > > >>> number of open files you had. A recent improvement from upstream ZFS > > >>> (r337653 and r337660) was pulled in that fixed this, so setting an > > >>> arc_max of 128MB is much more effective now, and that is causing the > > >>> side effect of "actually doing what you asked it to do", in this > case, > > >>> what you are asking is a bit silly. If you have a working set > that is > > >>> greater than 128MB, and you ask ZFS to use less than that, it'll > have to > > >>> constantly try to reclaim memory to keep under that very low bar. > > >>> > > >> Thanks for comments. Mark was right when he pointed to r338416 ( > > >> > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > > >> ). Commenting aggsum_value returns normal speed regardless of the > rest > > >> of the new code from upstream. > > >> I would like to repeat that the speed with these two lines is not > just > > >> slow, but _INCREDIBLY_ slow! Probably, this should be written in the > > >> relevant documentation for FreeBSD 12+ > > > > Hi, > > > > I am experiencing the same slowness when there is a bit of load on the > > system (buildworld for example) which I haven't seen before. > > Is it a regression following a recent kernel update? > > > I have vfs.zfs.arc_max=2G. > > > > Top is reporting > > > > ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M > Other > >       105M Compressed, 281M Uncompressed, 2.67:1 Ratio > > > > Should I test the patch? > > I would be interested in the results, assuming it is indeed a > regression. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sat Sep 8 11:56:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ACFDFF130D for ; Sat, 8 Sep 2018 11:56:10 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 853BC91745; Sat, 8 Sep 2018 11:56:09 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fybqR-000N1u-Tm; Sat, 08 Sep 2018 13:56:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KveEU/VXtjvkLeO6d3+a2gPcNv0ec9XPT8gmwOEt29w=; b=CJCPGJBQ6+lKeh4GmuCseiHE+D 7HEqOvHrAql54skVcGA63M/GAEysSfAAEfhcFwdafi+ZM26t3fdbZh03sYgxMGYKOOVviT8v+oBWS XvaNHTsgp2W/COV6PfYNrrGOX5gK6K7jBZYjjp3Ab1GpbybgIcUtTfyQjhHzHvlEG1fxyjLCgRTli o1Wr+7G2qM6/3vDp1mc4yfhqP3M6hnehq0i9ySP+BYLm3kn5A+AV9wXAPXYjHfy49JpvAh3lni9kX XDOsNzDKeKuwK2B/16vpu79nrHEUiIDSadJzI4xsRqppzmj6LAfrQm+6EwyBta7sZD93cwzLAEEv1 Xa0n7zUA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fybqR-000GyB-1i; Sat, 08 Sep 2018 13:56:07 +0200 Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 To: Mark Johnston Cc: Subbsd , allanjude@freebsd.org, freebsd-current Current References: <20180906002825.GB77324@raichu> <26c0f87e-2dd5-b088-8edb-0790b6b01ef0@alvermark.net> <20180907160654.GD63224@raichu> From: Jakob Alvermark Message-ID: <79f45d61-da93-af24-1b29-9c5db92b5b85@alvermark.net> Date: Sat, 8 Sep 2018 13:56:06 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180907160654.GD63224@raichu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 11:56:10 -0000 On 9/7/18 6:06 PM, Mark Johnston wrote: > On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: >> On 9/6/18 2:28 AM, Mark Johnston wrote: >>> On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: >>>> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote: >>>>> On 2018-09-05 10:04, Subbsd wrote: >>>>>> Hi, >>>>>> >>>>>> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12 >>>>>> to latest revision (r338466 the moment) and related to ARC. >>>>>> >>>>>> I can not say which revision was before except that the newver.sh >>>>>> pointed to ALPHA3. >>>>>> >>>>>> Problems are observed if you try to limit ARC. In my case: >>>>>> >>>>>> vfs.zfs.arc_max="128M" >>>>>> >>>>>> I know that this is very small. However, for two years with this there >>>>>> were no problems. >>>>>> >>>>>> When i send SIGINFO to process which is currently working with ZFS, i >>>>>> see "arc_reclaim_waiters_cv": >>>>>> >>>>>> e.g when i type: >>>>>> >>>>>> /bin/csh >>>>>> >>>>>> I have time (~5 seconds) to press several times 'ctrl+t' before csh is executed: >>>>>> >>>>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k >>>>>> load: 0.70 cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k >>>>>> load: 0.70 cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k >>>>>> load: 0.73 cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k >>>>>> >>>>>> same story with find or any other commans: >>>>>> >>>>>> load: 0.34 cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k >>>>>> load: 0.34 cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k >>>>>> >>>>>> this problem goes away after increasing vfs.zfs.arc_max >>>>>> _______________________________________________ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>>> >>>>> Previously, ZFS was not actually able to evict enough dnodes to keep >>>>> your arc_max under 128MB, it would have been much higher based on the >>>>> number of open files you had. A recent improvement from upstream ZFS >>>>> (r337653 and r337660) was pulled in that fixed this, so setting an >>>>> arc_max of 128MB is much more effective now, and that is causing the >>>>> side effect of "actually doing what you asked it to do", in this case, >>>>> what you are asking is a bit silly. If you have a working set that is >>>>> greater than 128MB, and you ask ZFS to use less than that, it'll have to >>>>> constantly try to reclaim memory to keep under that very low bar. >>>>> >>>> Thanks for comments. Mark was right when he pointed to r338416 ( >>>> https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 >>>> ). Commenting aggsum_value returns normal speed regardless of the rest >>>> of the new code from upstream. >>>> I would like to repeat that the speed with these two lines is not just >>>> slow, but _INCREDIBLY_ slow! Probably, this should be written in the >>>> relevant documentation for FreeBSD 12+ >> Hi, >> >> I am experiencing the same slowness when there is a bit of load on the >> system (buildworld for example) which I haven't seen before. > Is it a regression following a recent kernel update? Yes. > >> I have vfs.zfs.arc_max=2G. >> >> Top is reporting >> >> ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M Other >>      105M Compressed, 281M Uncompressed, 2.67:1 Ratio >> >> Should I test the patch? > I would be interested in the results, assuming it is indeed a > regression. This gets more interesting. Kernel + world was at r338465 I was going to test the patch, but since I had updated the src tree to r338499 I built it first without your patch. Now, at r338499, without the patch, it doesn't seem to hit the performance problem. vfs.zfs.arc_max is still set to 2G ARC display in top is around 1000M total, haven't seen go above about 1200M, even if I stress it. From owner-freebsd-current@freebsd.org Sat Sep 8 18:02:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32262FF999F for ; Sat, 8 Sep 2018 18:02:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DD7B73038; Sat, 8 Sep 2018 18:02:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id yhWJfDU4b5HxqyhWKfTItY; Sat, 08 Sep 2018 11:59:47 -0600 X-Authority-Analysis: v=2.3 cv=BMcHU2YG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=JBFolyDoGHsA:10 a=m1GS6RFLAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Iy63gnXmQfHMbYiDbx8A:9 a=o7kgYuBm0nd7SqLG:21 a=w-NpbNvDMz7NcBA_:21 a=wPNLvfGTeEIA:10 a=ZkTy8bY4UdX7Fe4buJt1:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id CF91A22BB; Sat, 8 Sep 2018 11:00:41 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w88HxgO2059092; Sat, 8 Sep 2018 10:59:42 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w88HxenJ059089; Sat, 8 Sep 2018 10:59:41 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201809081759.w88HxenJ059089@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jakob Alvermark cc: Cy Schubert , Mark Johnston , Subbsd , "allanjude@freebsd.org" , freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 In-Reply-To: Message from Jakob Alvermark of "Sat, 08 Sep 2018 12:40:04 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 08 Sep 2018 10:59:40 -0700 X-CMAE-Envelope: MS4wfN/SzmGnHRASTpMmV/kwQOm2C+Ix+CuEp0jJUHZyyvwUBSNwT8gtLrI4BlvRA4SktNJbA39QsoDR6TTRGLDgFG3xmm4PDrbLDV6C7KtVzgZEt3Fbofxe gSDJtPR/q7SVSCqRWpL73zHZDtmQe5gijjQfnK8sC7ErbPb84SxitgF0ff2Cm4Jyr64W3G6weXAFrSTPYciEdnib03OhqPtro0Ueim2w9jCfGxlAzOQteF6W 1SU8uJi93PQO5SEf0DkAbVEB9P2XQAzbDtdn4OYEmkxuN9Rt9GotBWe+jvme7d+y X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 18:02:37 -0000 In message , Jakob Alvermar k writes: > >                        Total     MFU     MRU    Anon     Hdr L2Hdr   Other >      ZFS ARC            667M    186M    168M     13M   3825K 0K    295M > >                                 rate    hits  misses   total hits total > misses >      arcstats                  : 99%   65636     605 167338494      9317074 >      arcstats.demand_data      : 57%     431     321 13414675      2117714 >      arcstats.demand_metadata  : 99%   65175     193 152969480      5344919 >      arcstats.prefetch_data    :  0%       0      30 3292       401344 >      arcstats.prefetch_metadata: 32%      30      61 951047      1453097 >      zfetchstats               :  9%     119    1077 612582     55041789 >      arcstats.l2               :  0%       0       0 0            0 >      vdev_cache_stats          :  0%       0       0 0            0 > > > > > This is while a 'make -j8 buildworld' (it has 8 cores) is going. Overall you have a 94% hit ratio. slippy$ bc scale=4 167338494/(167338494+9317074) .9472 slippy$ It could be better. Why is your ZFS ARC so small? Before I answer this I will discuss my experience first. My machines are seeing something similar to this: Total MFU MRU Anon Hdr L2Hdr Other ZFS ARC 4274M 2329M 1394M 17M 82M 0K 445M rate hits misses total hits total misses arcstats : 97% 614 13 866509066 51853442 arcstats.demand_data :100% 96 0 107658733 3101522 arcstats.demand_metadata : 97% 516 13 755890353 48080146 arcstats.prefetch_data : 0% 0 0 327613 225688 arcstats.prefetch_metadata:100% 2 0 2632367 446086 zfetchstats : 6% 6 80 2362709 294731645 arcstats.l2 : 0% 0 0 0 0 vdev_cache_stats : 0% 0 0 0 0 This is what you should see. This is with -CURRENT built two days ago. cwsys$ uname -a FreeBSD cwsys 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #51 r338520M: Thu Sep 6 17:44:35 PDT 2018 root@cwsys:/export/obj/opt/src/svn-current/amd64.a md64/sys/BREAK amd64 cwsys$ Top reports: CPU: 0.3% user, 89.9% nice, 9.5% system, 0.3% interrupt, 0.0% idle Mem: 678M Active, 344M Inact, 175M Laundry, 6136M Wired, 168M Buf, 598M Free ARC: 4247M Total, 2309M MFU, 1386M MRU, 21M Anon, 86M Header, 446M Other 3079M Compressed, 5123M Uncompressed, 1.66:1 Ratio Swap: 20G Total, 11M Used, 20G Free This is healthy. It's running a poudriere build. My laptop: Total MFU MRU Anon Hdr L2Hdr Other ZFS ARC 3175M 1791M 872M 69M 165M 0K 277M rate hits misses total hits total misses arcstats : 99% 3851 26 89082984 5101207 arcstats.demand_data : 99% 345 2 6197930 340186 arcstats.demand_metadata : 99% 3506 24 81391265 4367755 arcstats.prefetch_data : 0% 0 0 11507 30945 arcstats.prefetch_metadata: 0% 0 0 1482282 362321 zfetchstats : 2% 12 576 113185 38564546 arcstats.l2 : 0% 0 0 0 0 vdev_cache_stats : 0% 0 0 0 0 Similar results after working on a bunch of ports in four VMs last night, testing various combinations of options while Heimdal in base is private, hence the large ARC remaining this morning. Currently on the laptop top reports: CPU: 0.2% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.8% idle Mem: 376M Active, 1214M Inact, 5907M Wired, 464M Buf, 259M Free ARC: 3175M Total, 1863M MFU, 803M MRU, 69M Anon, 160M Header, 280M Other 2330M Compressed, 7881M Uncompressed, 3.38:1 Ratio Swap: 22G Total, 22G Free This is also healthy. Now for questions: Do you have any UFS filesystems? Top will report buf. What is that at? Some background: My /, /usr, and /var are UFS (these are old installations which when I install a new machine I dump | rsh new-machine restore, change a couple of entries in rc.conf and fstab, rsync ports (/usr/local, /var/db...) and boot (I'm terribly impatient). Hence the legacy. I have noticed that when writing a lot to UFS, increasing the size of the UFS buffer cache, my ARC will reduce to 1 GB or even less. But this is during a -j8 installworld to /, a test partition, an i386 partition and a number of VMs on UFS on a zpool and other VMs using ZFS on the same zpool. My ARC drops rapidly when the UFS filesystems are actively being written to. UFS and ZFS on the same server will impact performance unless one or the other is sparsely used. To repeat, do you have any UFS on the system? Do you write to UFS? Is it actively being written to at the time? How many MB is used by UFS buffers? How much RAM is installed on this machine? What is the scan rate? > > SSH'ing to the machine while the buildworld is going it takes 40-60 > seconds to get to the shell! Then your iostat or systat -v should show that you're hammering your disks. Or, you may be using a lot of swap. > > Hitting ^T while waiting: load: 1.06  cmd: zsh 45334 > [arc_reclaim_waiters_cv] 56.11r 0.00u 0.10s 0% 5232k Load might be low because processes are waiting for disk I/O. Processes waiting on I/O are not in the run queue and therefore don't affect load average. Disk I/O will kill performance worse than CPU load. Back in the days when I was an MVS systems programmer (IBM mainframe), I did a fair bit of tuning MVS at the time (Z/OS today). The rule of thumb then was machine instructions took nanoseconds whereas disk I/O took milliseconds and interrupting a process to gain control of the CPU the scheduler took nanoseconds because that's how long instructions took. You cannot interrupt I/O. You have to wait for the current I/O operation to complete before inserting a new I/O into the queue and with tagged queuing you have to wait for the disk to complete its work before scheduling new work. Now you're waiting multiples of milliseconds instead of a few nanoseconds. I/O kills performance. Look at iostat or systat -v. I think your answer lies there and since your ARC is small we need to find out why. > > I will test the patch below and report back. Agreed, though IMO your workload and your environment need to be understood first. What concerns me about the patch is what impact will it have on other workloads. Not evicting data and only metadata could impact buildworld -DNO_CLEAN for example. I do a -DNO_CLEAN buildworlds, sometimes -DWORLDFAST. Adjusting vfs.zfs.arc_meta_limit to the same value as vfs.zfs.arc_max improved my buildworld/installworld performance. In addition disabling atime for the ZFS dataset containing /usr/obj also improved buildworld/installworld performance by reducing unnecessary (IMO) metadata writes. I think evicting metadata only might cause a new set of problems for different workloads. (Maybe this should be a sysctl?) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > > Jakob > > On 9/7/18 7:27 PM, Cy Schubert wrote: > > I'd be interested in seeing systat -z output. > > > > --- > > Sent using a tiny phone keyboard. > > Apologies for any typos and autocorrect. > > Also, this old phone only supports top post. Apologies. > > > > Cy Schubert > > or > > The need of the many outweighs the greed of the few. > > --- > > ------------------------------------------------------------------------ > > From: Mark Johnston > > Sent: 07/09/2018 09:09 > > To: Jakob Alvermark > > Cc: Subbsd; allanjude@freebsd.org; freebsd-current Current > > Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 > > > > On Fri, Sep 07, 2018 at 03:40:52PM +0200, Jakob Alvermark wrote: > > > On 9/6/18 2:28 AM, Mark Johnston wrote: > > > > On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote: > > > >> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude > > wrote: > > > >>> On 2018-09-05 10:04, Subbsd wrote: > > > >>>> Hi, > > > >>>> > > > >>>> I'm seeing a huge loss in performance ZFS after upgrading > > FreeBSD 12 > > > >>>> to latest revision (r338466 the moment) and related to ARC. > > > >>>> > > > >>>> I can not say which revision was before except that the newver.sh > > > >>>> pointed to ALPHA3. > > > >>>> > > > >>>> Problems are observed if you try to limit ARC. In my case: > > > >>>> > > > >>>> vfs.zfs.arc_max="128M" > > > >>>> > > > >>>> I know that this is very small. However, for two years with > > this there > > > >>>> were no problems. > > > >>>> > > > >>>> When i send SIGINFO to process which is currently working with > > ZFS, i > > > >>>> see "arc_reclaim_waiters_cv": > > > >>>> > > > >>>> e.g when i type: > > > >>>> > > > >>>> /bin/csh > > > >>>> > > > >>>> I have time (~5 seconds) to press several times 'ctrl+t' before > > csh is executed: > > > >>>> > > > >>>> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u > > 0.00s 0% 3512k > > > >>>> load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k > > > >>>> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u > > 0.01s 0% 3512k > > > >>>> load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u > > 0.01s 0% 4156k > > > >>>> > > > >>>> same story with find or any other commans: > > > >>>> > > > >>>> load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u > > 0.00s 0% 2676k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u > > 0.00s 0% 2680k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u > > 0.00s 0% 2684k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u > > 0.00s 0% 2704k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u > > 0.00s 0% 2716k > > > >>>> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u > > 0.00s 0% 2760k > > > >>>> > > > >>>> this problem goes away after increasing vfs.zfs.arc_max > > > >>>> _______________________________________________ > > > >>>> freebsd-current@freebsd.org mailing list > > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > >>>> To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > >>>> > > > >>> Previously, ZFS was not actually able to evict enough dnodes to keep > > > >>> your arc_max under 128MB, it would have been much higher based > > on the > > > >>> number of open files you had. A recent improvement from upstream ZFS > > > >>> (r337653 and r337660) was pulled in that fixed this, so setting an > > > >>> arc_max of 128MB is much more effective now, and that is causing the > > > >>> side effect of "actually doing what you asked it to do", in this > > case, > > > >>> what you are asking is a bit silly. If you have a working set > > that is > > > >>> greater than 128MB, and you ask ZFS to use less than that, it'll > > have to > > > >>> constantly try to reclaim memory to keep under that very low bar. > > > >>> > > > >> Thanks for comments. Mark was right when he pointed to r338416 ( > > > >> > > https://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/commo > n/fs/zfs/arc.c?r1=338416&r2=338415&pathrev=338416 > > > >> ). Commenting aggsum_value returns normal speed regardless of the > > rest > > > >> of the new code from upstream. > > > >> I would like to repeat that the speed with these two lines is not > > just > > > >> slow, but _INCREDIBLY_ slow! Probably, this should be written in the > > > >> relevant documentation for FreeBSD 12+ > > > > > > Hi, > > > > > > I am experiencing the same slowness when there is a bit of load on the > > > system (buildworld for example) which I haven't seen before. > > > > Is it a regression following a recent kernel update? > > > > > I have vfs.zfs.arc_max=2G. > > > > > > Top is reporting > > > > > > ARC: 607M Total, 140M MFU, 245M MRU, 1060K Anon, 4592K Header, 217M > > Other > > >       105M Compressed, 281M Uncompressed, 2.67:1 Ratio > > > > > > Should I test the patch? > > > > I would be interested in the results, assuming it is indeed a > > regression. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Sat Sep 8 18:07:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5953FF9C67 for ; Sat, 8 Sep 2018 18:07:52 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4203073272; Sat, 8 Sep 2018 18:07:52 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject; s=201508; t=1536430062; bh=94SlDDF0 Afftr60hJNj6QG15fdYCBQJP2f9nDRg63d0=; b=W2ERh66xSUZ2qEqBxSKq1I9V zn7dST8bYrsWm4WraUKn/18LDLMmK2oreLRV7zYarCc6JIjHLfPl9SM0fIgG36IC RGcltH+H8NeMxJSAgmeb54gm+DbLxK7fIrtMSNxBjYynfdFg/HoVkWn5BNPh8Dys 6CnrtNcGC37K3mbralo= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 0F15B7F14; Sat, 8 Sep 2018 14:07:42 -0400 (EDT) Subject: Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted' To: Konstantin Belousov Cc: John Baldwin , Ian FREISLICH , freebsd-current References: <524214ac-e3ca-53cd-aee3-dac9212e9800@capeaugusta.com> <0aa35f96-9f62-bfca-c04a-f6ddcb1ce738@FreeBSD.org> <8ed7961e-e12a-9267-2bd0-a9bcbe383c7f@protected-networks.net> <20180831052805.GP2340@kib.kiev.ua> From: Michael Butler Openpgp: preference=signencrypt Message-ID: <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> Date: Sat, 8 Sep 2018 14:07:41 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180831052805.GP2340@kib.kiev.ua> Content-Type: text/plain; charset=koi8-r Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 18:07:52 -0000 On 8/31/18 1:28 AM, Konstantin Belousov wrote: > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: [ .. snip .. ] >> I see another problem after using Ian's workaround of moving the #ifdef >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >> machine with only 512MB of RAM: >> >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed > > What is the kernel revision for "now". What was the previous revision > where the kstack allocation failures did not happen. > > Also, what is the workload ? Sorry for the delay. Any version at or after SVN r338360 would either a) not boot at all or b) crash shortly after boot with a swarm of messages as above. It was stable before that. Unfortunately, this machine is remote and, being as old as it is, has no remote console facility. 'nextboot' has been my savior ;-) It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a router/firewall with few actual applications running. As another data point, I manually reversed both SVN r338360 and r338415 (a related change) and it is now stable running at SVN r338520, imb From owner-freebsd-current@freebsd.org Sat Sep 8 19:43:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01875FFC32E for ; Sat, 8 Sep 2018 19:43:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 692CF76010; Sat, 8 Sep 2018 19:43:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w88JhGo0044543 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Sep 2018 22:43:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w88JhGo0044543 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w88JhG5d044542; Sat, 8 Sep 2018 22:43:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Sep 2018 22:43:16 +0300 From: Konstantin Belousov To: Michael Butler Cc: John Baldwin , Ian FREISLICH , freebsd-current Subject: Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted' Message-ID: <20180908194316.GI3161@kib.kiev.ua> References: <524214ac-e3ca-53cd-aee3-dac9212e9800@capeaugusta.com> <0aa35f96-9f62-bfca-c04a-f6ddcb1ce738@FreeBSD.org> <8ed7961e-e12a-9267-2bd0-a9bcbe383c7f@protected-networks.net> <20180831052805.GP2340@kib.kiev.ua> <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 19:43:29 -0000 On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: > On 8/31/18 1:28 AM, Konstantin Belousov wrote: > > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: > > [ .. snip .. ] > > >> I see another problem after using Ian's workaround of moving the #ifdef > >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) > >> machine with only 512MB of RAM: > >> > >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed > > > > What is the kernel revision for "now". What was the previous revision > > where the kstack allocation failures did not happen. > > > > Also, what is the workload ? > > Sorry for the delay. Any version at or after SVN r338360 would either a) > not boot at all or b) crash shortly after boot with a swarm of messages > as above. It was stable before that. > > Unfortunately, this machine is remote and, being as old as it is, has no > remote console facility. 'nextboot' has been my savior ;-) > > It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, > local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an > OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a > router/firewall with few actual applications running. > > As another data point, I manually reversed both SVN r338360 and r338415 > (a related change) and it is now stable running at SVN r338520, It is very unprobable. I do not see how could r338360 affect KVA allocation. Double-check that you booted right kernels. From owner-freebsd-current@freebsd.org Sat Sep 8 20:45:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 817A7FFD97A for ; Sat, 8 Sep 2018 20:45:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E21D779EE; Sat, 8 Sep 2018 20:45:00 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject; s=201508; t=1536439498; bh=hHTuT6BN HZqObG6zmTyZ/VsUv6LFQ7/ZArHXPCawnFQ=; b=h6nsi9Mshd+uY+uGubqDHzya jl3MAT+6TXGdOFHixoedd8LfoPgt+WFg68vdidiRqCZG62wmhJBwQVOLjTYqArXV 7isewXRsHZ6g07k8USUYEutnDVwf9Lb/Odz1iI1vdwXNf2KYwbY3eD73M5EEBVX3 50tRM4HhkCOLC8kckbU= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 88885A6C6; Sat, 8 Sep 2018 16:44:58 -0400 (EDT) Subject: Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted' To: Konstantin Belousov Cc: John Baldwin , Ian FREISLICH , freebsd-current References: <524214ac-e3ca-53cd-aee3-dac9212e9800@capeaugusta.com> <0aa35f96-9f62-bfca-c04a-f6ddcb1ce738@FreeBSD.org> <8ed7961e-e12a-9267-2bd0-a9bcbe383c7f@protected-networks.net> <20180831052805.GP2340@kib.kiev.ua> <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> <20180908194316.GI3161@kib.kiev.ua> From: Michael Butler Openpgp: preference=signencrypt Message-ID: Date: Sat, 8 Sep 2018 16:44:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180908194316.GI3161@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 20:45:01 -0000 On 9/8/18 3:43 PM, Konstantin Belousov wrote: > On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: >> On 8/31/18 1:28 AM, Konstantin Belousov wrote: >>> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: >> >> [ .. snip .. ] >> >>>> I see another problem after using Ian's workaround of moving the #ifdef >>>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >>>> machine with only 512MB of RAM: >>>> >>>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed >>> >>> What is the kernel revision for "now". What was the previous revision >>> where the kstack allocation failures did not happen. >>> >>> Also, what is the workload ? >> >> Sorry for the delay. Any version at or after SVN r338360 would either a) >> not boot at all or b) crash shortly after boot with a swarm of messages >> as above. It was stable before that. >> >> Unfortunately, this machine is remote and, being as old as it is, has no >> remote console facility. 'nextboot' has been my savior ;-) >> >> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, >> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an >> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a >> router/firewall with few actual applications running. >> >> As another data point, I manually reversed both SVN r338360 and r338415 >> (a related change) and it is now stable running at SVN r338520, > > It is very unprobable. I do not see how could r338360 affect KVA allocation. > Double-check that you booted right kernels. > FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 r338520M: Thu Sep 6 21:35:31 EDT 2018 'svn diff' reports the only changes being the two reversals I noted above, imb From owner-freebsd-current@freebsd.org Sat Sep 8 23:13:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2ABD106B87E for ; Sat, 8 Sep 2018 23:13:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DEF37BE6C; Sat, 8 Sep 2018 23:13:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id ymPofZv2VwyxUymPpfmxL2; Sat, 08 Sep 2018 17:13:23 -0600 X-Authority-Analysis: v=2.3 cv=NPJhBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=JBFolyDoGHsA:10 a=xfDLHkLGAAAA:8 a=YxBL1-UpAAAA:8 a=m1GS6RFLAAAA:8 a=6I5d2MoRAAAA:8 a=MyJtD5Qd0gigxvGbRnoA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=IfaqVvZgccqrtc8gcwf2:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=ZkTy8bY4UdX7Fe4buJt1:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id ED236260E; Sat, 8 Sep 2018 16:14:19 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w88NDJNF059298; Sat, 8 Sep 2018 16:13:19 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w88NDH3T059295; Sat, 8 Sep 2018 16:13:17 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201809082313.w88NDH3T059295@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Matthew Macy cc: Cy Schubert , Jakob Alvermark , Mark Johnston , Subbsd , "allanjude@freebsd.org" , freebsd-current Current Subject: Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4 In-Reply-To: Message from Matthew Macy of "Sat, 08 Sep 2018 12:49:31 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Sep 2018 16:13:17 -0700 X-CMAE-Envelope: MS4wfDVGMBIp8/7ZxHqB0awy10bFcPTvR2qU0uriSjmuo3eik06IzUHGBtzP9Tkoqimr1d33H/EV32C/pweU05gA97FkO9fqOmJAVhrTjMiz+dHohx/PDSQH 7FS0sGCKqwqxLKv27nQ6VsoyfdziwDIhwO5EGq+r04WBKwLbdjCiRUUaguwaxdO0Z8RFcq+aITQ+LNwtaoo0dUC7ajRsD2rjUQdfTjl+9qKudXz8QBhVI7Eh ubuibRUC7YOIq0ufcJlVyaK/38QCOwIjFIPy8q35N+k+9zAh/bfDSWdNbrI4rYeMTjE+SbFVn9+wOkawk0AbZA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 23:13:25 -0000 In message , Matthew Macy writes: > > On Sat, Sep 8, 2018 at 11:03 Cy Schubert wrote: > > > In message , Jakob > > Alvermar > > k writes: > > > > > > I will test the patch below and report back. > > > > Agreed, though IMO your workload and your environment need to be > > understood first. What concerns me about the patch is what impact will > > it have on other workloads. Not evicting data and only metadata could > > impact buildworld -DNO_CLEAN for example. I do a -DNO_CLEAN > > buildworlds, sometimes -DWORLDFAST. Adjusting vfs.zfs.arc_meta_limit to > > the same value as vfs.zfs.arc_max improved my buildworld/installworld > > performance. In addition disabling atime for the ZFS dataset containing > > /usr/obj also improved buildworld/installworld performance by reducing > > unnecessary (IMO) metadata writes. I think evicting metadata only might > > cause a new set of problems for different workloads. (Maybe this should > > be a sysctl?) > > > > Mark's suggested change would just restore the default behavior from before > balanced pruning was imported. Balanced pruning is dependent on code that > didn't exist in FreeBSD - unfortunately when I did the import I did not > pull in all the dependencies. Mid freeze, the least disruptive path is to > disable the new behavior. Post branch we can restore it as a default, > possibly contingent on the amount of memory in the system. There is > precedent for this with prefetch. Ok. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.