From owner-freebsd-current@freebsd.org Sun Nov 26 09:31:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 173E1DB9F66 for ; Sun, 26 Nov 2017 09:31:13 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 72E7365166 for ; Sun, 26 Nov 2017 09:31:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.11.0]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWSwU-1ecFh92sRe-00Xd1H for ; Sun, 26 Nov 2017 10:25:57 +0100 Date: Sun, 26 Nov 2017 10:25:50 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: LLVM: CommandLine Error: Option 'enable-value-profiling' registered more than once! Message-ID: <20171126102550.2bd2b99d@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Dnt6sSMwG3X7Y6n6B45na3H"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:vVg4Ix/2cChWo+dMLf3Mtyj87QhqfUoFpVNmoJt4rRofiMrpymm YWsUJCptRobOxS5RnPDNa/b9tRibtHbV8sUR+umw3WwSHTXR4xpwFr++OZ+jLW25hhlkt1E uZl6//0NwGq+SzOabUrDnhEp+80mkqgZjylU1JkQKCDjyXG918NlmAO0E7JQoNJ7/FjdIJT Od1rV2KvVYap7nBzvHRqA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3ALLWZaOpTc=:ERR5W56QoMGoHYoYnpWm3h ieWlgamLrCvnKYX6F6A49tBTCcE8muna7vGZF8wQUTkojhmMdArRATY9+EojR6Ov7UnnZBn5n CRnwxctk7D59zoBQnwCRRT3K/kWb9tmLbNJdQ9FdtS7Kf/4XQmJAf+QuEiR6DZ/jHCDVimVjZ ouY4rllvtmmiX46FILHA3ZjlwTDHD2/OkZxB3NAlbY/jUijHha5y3UiE5DRegn9CyWwufyNDK 94Hd4b5QrK7jq+eNARN2vTarqlEQUvwUZGam0q/3tHCuMMBrDNj4ufZU6qAQzhjVtFGfIEmhN IpCn3PcR8c6SVq7Isse1aOPoWzUqREDWBR1zTqVdsdbgm/rynjUWs6nC3F3TVk7ca9EMt+blh IWDuEo/4AHVO0pUzLFjsBAv+/UcNwMJnCg5NxlBF13rWiDQQgMJcDpJ92BmH8aDDFEJpLAvtK qtojZAoWVjef4TdI5v2qpyUV9vM/Hi40xHBzLyiEFad5UQxanZmcXmq6njBkuoLB9Dei8I7fW M4lcGROJmb4/UPtnpxSeo0ExiDaKZgEa+sNjMcC9kpbgbOUXLNNspDslpKP/RyOezBsyZYiTC LQx0GzpHkMYNFR0rZP01+bWW6VD5/ydLMHA8BtvMlSHbkEqQmGcby3GqQPoJXGJFpL5R0ZdVK 1EfNLPzZlJGjH6NmqIrcHWkb2GuSGHC0JmA3YRfALQ86vFprB6rvXAju9AaxQEgcOoQ5XXFn+ mifuaJbRVmW5Wb2917XkT4QxpdEXQFFgOsAAVeW/qflL7v8ci3xLOvw/5nSM2ZNHY5HxB9nO9 va0/uxcj0TuGA0F8lyBrxQUef7XRw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Nov 2017 09:31:13 -0000 --Sig_/Dnt6sSMwG3X7Y6n6B45na3H Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With devel/llvm40 and lang/clang40 installed on recent CURRENT (as well as = 11-STABLE), graphics/blender (with option for OpenCL) and software compiled with lang/p= ocl fail/crash with something similar like [...] : CommandLine Error: Option 'enable-value-profiling' registered more than o= nce! LLVM ERROR: inconsistency in registered CommandLine options [...] In all cases, beignet and mesa-lib has been installed in parallel to pocl o= r pocl in parallel to the ports needed by blender, so I think this bug report on the = LLVM list reflects the problem: http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html I have no clue how to workaround this. graphics/blender doesn't work anymor= e and any POCL software (for OpenCL code on FreeBSD utilising CPUs) doesn't work either. Is there a solution present? --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/Dnt6sSMwG3X7Y6n6B45na3H Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWhqIngAKCRDS528fyFhY lPljAf0db/marA4/YToCh9Ta4GmA7UC0g8TlbAjBOt8N7T2yk++MfCfqu9cWXRck CHogXBfeMffHK91ji0pIEDrJxXgxAf9EkOnFsGPLtqcgfncXbSVixMUHtpwcf5Pa 7QkMqOiWK7xyROu25lXxiAxFKKM5nMquS6IWPn7OqKmhWeKV8h77 =KwLM -----END PGP SIGNATURE----- --Sig_/Dnt6sSMwG3X7Y6n6B45na3H-- From owner-freebsd-current@freebsd.org Tue Nov 28 03:26:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A61CDF6234 for ; Tue, 28 Nov 2017 03:26:08 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1869D730F6 for ; Tue, 28 Nov 2017 03:26:07 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id m1so35275715lfj.9 for ; Mon, 27 Nov 2017 19:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=EdRo9Ni1yuQhIY10c6m39HBzSwzagN3PoEEdw8uLRLU=; b=R9E7hl4bIEx1p1xAPZobWpjWN19KGKzjFuVBGSk2BxgD0hOyq9IXBGe3NW6ao1EUJO P98jTzOQmbjI5KjCgtIWjqGbxy6hm9BjvGwc1NeMZb/Ka2ikT7eI9uDBPzRY64G1wXdW klb4R9txvxCViSLkiwMrOaIXT8czzRPSM9aysS90uhzhF8t2lgG9r830YpnC149ORlIf APwXWWfACiRQ3XLEGXJCR5kkswU+n19HaZl+WxlwkWSFWt8U9i/4Qkcp2Cc2nj0RpZSD uVcAG6fEtCqccl5Rlj1vibR/ai2tLT6LaBmQibI40xa7l53x7D95/ct4x+jnvAYP5gek 26Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=EdRo9Ni1yuQhIY10c6m39HBzSwzagN3PoEEdw8uLRLU=; b=sWi0EFzOCo0lI2ZnA3rermHwPCPTDP2UEFTOQr+aXy1WONm3Y8KQCQeNHmAPVXFQjh p349jTeagYpoqLrVi+YgcRlCqZsc9yLhdtdEVo1S4LzcvkhAnbICuFHPATfNCvRftYQu gLtTyg5F9t7trkse3AKnJ95RuiTbmep57YNu4b0WbhgnvbrBJK7MBB5hCTBRSEtUW6Al qw4rIyhUr42Yw5pUX5dEgl45zJOYcFNXu0rgETzh3MxcUyVb5gxBJ6rTt4zGQXG1sjzx 4hsJeV0Q9vtnF0LvDLeQcOXs6JjXATXLO2gGDj+libbElRpCFsHB6qQzfSJvwquoOsYR vJPA== X-Gm-Message-State: AJaThX6npZl2n1C0RNen6ieWuREfu2Pjzhbc5FsOgx9jgOp2bpBJrXtr BjTKdzJakKAFmBNj0DycP6Cv1w== X-Google-Smtp-Source: AGs4zMYmbGwVt2+08N6fYMjE82CHGklkKpdMy/1DBgOc76/kJJBJ4X382oqx1BaaCpZC5WSPmqLEyw== X-Received: by 10.46.91.217 with SMTP id m86mr15830220lje.166.1511839565024; Mon, 27 Nov 2017 19:26:05 -0800 (PST) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id z64sm3364287lfa.34.2017.11.27.19.26.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 19:26:03 -0800 (PST) To: FreeBSD Current From: "Alex V. Petrov" Subject: head r326286 trouble with powerd++ Message-ID: Date: Tue, 28 Nov 2017 10:26:01 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 03:26:08 -0000 Some time ago, powerd++ ends with an error: Nov 28 04:51:05 alex kernel: hwpstate0: set freq failed, err 6 Before this was not. 12.0-CURRENT #0 r326286 amd64 CPU: AMD FX-8370 Eight-Core Processor -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Nov 28 03:37:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3C87DF6CAF for ; Tue, 28 Nov 2017 03:37:50 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C2B73907 for ; Tue, 28 Nov 2017 03:37:50 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id i14so35318999lfc.1 for ; Mon, 27 Nov 2017 19:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=vCuV0LjP4q3DN8AwyTT7d4Ifil9EFkrzga44GwRsjss=; b=aszK23Arx1alSa1kUmBKXNMURDKtu+Y5MwfsdPSqgkKm/jWAMXw97Ku2nvDYVugrd/ tiWabacrmwvOydRkgsef2PSQysEEOUspRKqUeUUGOLAMMK0W7hm5HrGu75WbSPfRAX6z aZsIfyq8VFvu/Gl3l1lPmo7MOXNZDofyyqHrN/Ot8g/lAvZ5ErXHMpaGNJr4ovXxio2d XGc9ikk76v1YrOHXDLW8AX3EERx226daA8wlMfPAe0hzQFtZ3uaToq8H1AMRyvtqlRE6 Z5RDUJA2HFCSPAMA0AJ8CfzR+duxBZM6UggvBbE3u1SvExupsDHHAhwqLR41eSF0OOGh g9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=vCuV0LjP4q3DN8AwyTT7d4Ifil9EFkrzga44GwRsjss=; b=CYbAMWTKSFqiI7/4V/o8YDVWLau0BhKDipKldXC7a8VRBmFrbFhXiVHs7Y2Ku1G0gO OmYKQ7EYHxgWGUcZ/8U4qFnFr7xqDKHOMuRKat/FLzld3Dr9bUE6D0iJGD44qndTMxSK BE/vKr5A4NeD6U3d/9KN4kyt/KU0eqV1C/T8gXlWjELzYMf2HcG5wCMMMlZtHQpXzhbM nRhsYtQ1uOZD9na1rm70SQximlvPTEHfVbe6QXk6xv40ZJNkolKicJgAQ4vLP5rhyy+A wgXae9nqM2sJ73HXUfpJ6GDoGiVegSH/qGSdS4SnNvxhspRsirK6JyFGppX0QwZAiGOk NccA== X-Gm-Message-State: AJaThX7GEcInexv635Iu48cNaqwBMtMUbQ4BwdYS0cgX87CCrEj72vhM gxjPb/RPS0eRURaUE8xI3pVmtg== X-Google-Smtp-Source: AGs4zMad+LY7wcjt2w/83zwK3VK/c+ZzHi0pr2grlU1zF4h/QoAubJgxG8V5aRH85ycqQ2S9J49I3w== X-Received: by 10.46.41.150 with SMTP id p22mr14621459ljp.5.1511840267985; Mon, 27 Nov 2017 19:37:47 -0800 (PST) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id m127sm3722147lfm.82.2017.11.27.19.37.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 19:37:47 -0800 (PST) To: FreeBSD Current From: "Alex V. Petrov" Subject: CURRENT: core dumped no process name Message-ID: Date: Tue, 28 Nov 2017 10:37:45 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 03:37:50 -0000 SUBJ: Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) It was a thunerbird 12.0-CURRENT #0 r326286 kernel GENERIC-NODEBUG -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Nov 28 08:29:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7123FDFDA2F for ; Tue, 28 Nov 2017 08:29:20 +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 07DAD7B479 for ; Tue, 28 Nov 2017 08:29:19 +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 vAS8TEps084600 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 10:29:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vAS8TEps084600 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vAS8TEsS084599; Tue, 28 Nov 2017 10:29:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 10:29:14 +0200 From: Konstantin Belousov To: "Alex V. Petrov" Cc: FreeBSD Current Subject: Re: CURRENT: core dumped no process name Message-ID: <20171128082914.GJ2272@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 08:29:20 -0000 On Tue, Nov 28, 2017 at 10:37:45AM +0700, Alex V. Petrov wrote: > SUBJ: > Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) > It was a thunerbird > > > 12.0-CURRENT #0 r326286 > kernel GENERIC-NODEBUG The format strings is following: "pid %d (%s), uid %d: exited on signal %d%s\n" In other words, your line misses whole prefix, I suppose that '1001:' part is uid printout. Where do you see this line ? Is it from /var/log/messages, remote syslog service, console ? From owner-freebsd-current@freebsd.org Tue Nov 28 10:13:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC87BE510D9 for ; Tue, 28 Nov 2017 10:13:15 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8D27E9E6 for ; Tue, 28 Nov 2017 10:13:15 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id i14so36317278lfc.1 for ; Tue, 28 Nov 2017 02:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fUtsJrLlZjHz7c9aYImsNHFLE07ojrwrho1K8ZRap8k=; b=qno9ec6bb3Yq3T9uiOrCP3py0/HDFTZha7qmlXFYDjyBm6MrKaKgxZGFkj3RgnER66 UYMDRN+SxjR/iyTuwIXALmrFUmxGxkt91pT5sl5hY/SaZSXTZi4KfbiWFgh1nJOdTEBT B5EH9AT6++gwYNVfcy6Mh9llfiKDoSIXFqGmAyM9dIV05vbcEo6xYYoga+fr9EzVtX4+ bagLI+CiFWENU6z7QojJDHI6Reye1QihzutaOWlkIZOTuA/XCFvOCyD46mMB+TicQqpI Fklpkwwkb7d5eVDFe3wOVU5yAT1dhxXphu2Jhi0yMoxR7Escp+ePTAHGKce8ebxmGYJD xLFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fUtsJrLlZjHz7c9aYImsNHFLE07ojrwrho1K8ZRap8k=; b=t1jVG2QlER+jxAkjZBjAkVPzdFO5Mxz5WOn3+peDM9Q1L0A0cP+9xve2araW/IBlH6 Q8xs7NteHCLjtFqPU7vIYAlvEironcC773aP88kI7np0SwuNcAXK0JtJn02z6iX48Ynb KfEyLcwLzrs7v6b+9MzaYYQA2CGjrm0zgO9Dmv9tD0Xxr1Ann20XgWpdnyOK33LuHqcb 1OvjX0H5Y84kTp8/t4/fPa4226UG8ohhPefmutn6WZmUJaQ0GThHJC8nvLpL4ojk9QZY JaiaxkIAWtqktwJQtPl9TXxYsWue2hGmMAQytNwjVxJBd4IwocTOo6KcpmRnh7z0kTJo 4vPg== X-Gm-Message-State: AJaThX5SciUqYQjgDIOqWm8aoUPbFHTJqaALss8dyqfHjaIzCwoRNTlr Ri+yLmK5tFwcTBd7a/g3WJVwjw== X-Google-Smtp-Source: AGs4zMYPJDbOp4hN18xszuToWyAYzYmFca9UyFrgZ0lMvFLYbRCHVnd0k6WSICJcExbBhBeE5mMWqQ== X-Received: by 10.25.150.213 with SMTP id y204mr2231340lfd.124.1511863992923; Tue, 28 Nov 2017 02:13:12 -0800 (PST) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id d1sm6472539ljf.66.2017.11.28.02.13.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 02:13:12 -0800 (PST) Subject: Re: CURRENT: core dumped no process name To: Konstantin Belousov Cc: FreeBSD Current References: <20171128082914.GJ2272@kib.kiev.ua> From: "Alex V. Petrov" Message-ID: <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> Date: Tue, 28 Nov 2017 17:13:10 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171128082914.GJ2272@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 10:13:15 -0000 from /var/log/messages # grep core /var/log/messages Nov 21 06:26:56 alex kernel: 1001: exited on signal 11 (core dumped) Nov 22 00:46:31 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 22 16:01:32 alex kernel: 1001: exited on signal 11 (core dumped) Nov 23 08:14:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 24 04:32:17 alex kernel: 1001: exited on signal 11 (core dumped) Nov 24 04:41:44 alex kernel: 1001: exited on signal 11 (core dumped) Nov 24 04:48:03 alex kernel: 1001: exited on signal 11 (core dumped) Nov 24 04:49:55 alex kernel: 1001: exited on signal 11 (core dumped) Nov 24 11:33:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 26 02:50:35 alex kernel: 1001: exited on signal 11 (core dumped) Nov 26 03:47:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 26 12:05:01 alex kernel: 1001: exited on signal 11 (core dumped) Nov 26 14:16:26 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 26 14:27:05 alex kernel: 0: exited on signal 6 (core dumped) Nov 26 23:49:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 26 23:50:26 alex kernel: 0: exited on signal 6 (core dumped) Nov 27 12:13:02 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 27 15:28:11 alex kernel: 0: exited on signal 6 (core dumped) Nov 27 15:50:54 alex kernel: 0: exited on signal 6 (core dumped) Nov 27 16:34:02 alex kernel: 0: exited on signal 6 (core dumped) Nov 28 03:07:42 alex kernel: 0: exited on signal 6 (core dumped) Nov 28 04:20:03 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 28 04:51:08 alex kernel: 0: exited on signal 6 (core dumped) Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) Nov 28 15:55:42 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) Nov 28 17:05:35 alex kernel: 0: exited on signal 6 (core dumped) 28.11.2017 15:29, Konstantin Belousov пишет: > On Tue, Nov 28, 2017 at 10:37:45AM +0700, Alex V. Petrov wrote: >> SUBJ: >> Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) >> It was a thunerbird >> >> >> 12.0-CURRENT #0 r326286 >> kernel GENERIC-NODEBUG > > The format strings is following: > "pid %d (%s), uid %d: exited on signal %d%s\n" > In other words, your line misses whole prefix, I suppose that '1001:' part > is uid printout. > > Where do you see this line ? Is it from /var/log/messages, remote syslog > service, console ? > -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Nov 28 10:38:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D1D8E5184D for ; Tue, 28 Nov 2017 10:38:15 +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 0A3227F4C6 for ; Tue, 28 Nov 2017 10:38:14 +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 vASAc9l3014824 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 12:38:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vASAc9l3014824 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vASAc9ZE014823; Tue, 28 Nov 2017 12:38:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 12:38:09 +0200 From: Konstantin Belousov To: "Alex V. Petrov" Cc: FreeBSD Current Subject: Re: CURRENT: core dumped no process name Message-ID: <20171128103809.GM2272@kib.kiev.ua> References: <20171128082914.GJ2272@kib.kiev.ua> <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 10:38:15 -0000 On Tue, Nov 28, 2017 at 05:13:10PM +0700, Alex V. Petrov wrote: > from /var/log/messages > > # grep core /var/log/messages > Nov 21 06:26:56 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 22 00:46:31 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 22 16:01:32 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 23 08:14:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 24 04:32:17 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 24 04:41:44 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 24 04:48:03 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 24 04:49:55 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 24 11:33:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 26 02:50:35 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 26 03:47:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 26 12:05:01 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 26 14:16:26 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 26 14:27:05 alex kernel: 0: exited on signal 6 (core dumped) > Nov 26 23:49:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 26 23:50:26 alex kernel: 0: exited on signal 6 (core dumped) > Nov 27 12:13:02 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 27 15:28:11 alex kernel: 0: exited on signal 6 (core dumped) > Nov 27 15:50:54 alex kernel: 0: exited on signal 6 (core dumped) > Nov 27 16:34:02 alex kernel: 0: exited on signal 6 (core dumped) > Nov 28 03:07:42 alex kernel: 0: exited on signal 6 (core dumped) > Nov 28 04:20:03 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 28 04:51:08 alex kernel: 0: exited on signal 6 (core dumped) > Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 28 15:55:42 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 28 17:05:35 alex kernel: 0: exited on signal 6 (core dumped) > Do you use syslogd after r325558 ? If yes, try to revert it. From owner-freebsd-current@freebsd.org Tue Nov 28 10:41:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9EB3E51B11; Tue, 28 Nov 2017 10:41:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8C027F85E; Tue, 28 Nov 2017 10:41:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 6c33a164; Tue, 28 Nov 2017 11:41:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; s=mail; bh=wQ41Mb8MapTzKaga6r19wBGQb 2I=; b=Q64oZ0OeZhJrR3iiReQafsrg1z3CtUfv/zddobO1QmtDw/pa6FMJvG7jE ixDWyqIg9wsrSOaTp42OnmeaJEMfR+aM6F/wNAeBBGh+OuFm8Zf8Kjgt6pDPiTJ+ eGFH38ZfmvFs10cTWFTWhF7XpQu5rD9te48vkLr0bT/2tXKEe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=mIzuZvxiEQuD1WS5r/l KNHKuu6Zyzb6vN4u9y0/XrHggu87l54F0sSU4yro6DZIaqxfA1mKBNALehTitnGC 9q3bi5wxe9qrvn3OatJViY7lEKeveO8Bh9opuDMkL0YqbbcSHVU9ZzMFCJ76W8+9 7WJ0h/qdEx8Rx929EC5oE8WY= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 741b79b9 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 28 Nov 2017 11:41:37 +0100 (CET) Date: Tue, 28 Nov 2017 11:41:36 +0100 From: Emmanuel Vadot To: FreeBSD Current , freebsd-fs@freebsd.org Cc: Rick Macklem Subject: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-Id: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 10:41:41 -0000 Hello, I would like to switch the vfs.nfsd.issue_delegations sysctl to a tunable. The reason behind it is recent problem at work on some on our filer related to NFS. We use NFSv4 without delegation as we never been able to have good performance with FreeBSD server and Linux client (we need to do test again but that's for later). We recently see all of our filers with NFS enabled perform pourly, resulting in really bad performance on the service. After doing some analyze with pmcstat we've seen that we spend ~50% of our time in lock delay, called by nfsrv_checkgetattr (See [1]). This function is only usefull when using delegation, as it search for some write delegations issued to client, but it's called anyway when there so no delegation and cause a lot of problem when having a lot of activities. We've patched the kernel with the included diff and now everything is fine (tm) (See [2]). The problem for upstreaming this patch is that since issue_delegations is a sysctl we cannot know if the checkgetattr called is needed, hence the question to switch it to a TUNABLE. Also maybe some other code path could benefit from it, I haven't read all the source of nfsserver yet. Note that I won't MFC the changes as it would break POLA. Cheers, [1] https://people.freebsd.org/~manu/m8.svg [2] https://people.freebsd.org/~manu/m8-new.svg >From 0cba277f406d3ccf3c9e943a3d4e17b529e31c89 Mon Sep 17 00:00:00 2001 From: Emmanuel Vadot Date: Fri, 24 Nov 2017 11:17:18 +0100 Subject: [PATCH 2/4] Do not call nfsrv_checkgetttr if delegation isn't enable. Signed-off-by: Emmanuel Vadot --- sys/fs/nfsserver/nfs_nfsdserv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c index 8102c5810a9..8daf0142360 100644 --- a/sys/fs/nfsserver/nfs_nfsdserv.c +++ b/sys/fs/nfsserver/nfs_nfsdserv.c @@ -54,6 +54,7 @@ extern struct timeval nfsboottime; extern int nfs_rootfhset; extern int nfsrv_enable_crossmntpt; extern int nfsrv_statehashsize; +extern int nfsrv_issuedelegs; #endif /* !APPLEKEXT */ static int nfs_async = 0; @@ -240,7 +241,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int isdgram, if (nd->nd_flag & ND_NFSV4) { if (NFSISSET_ATTRBIT(&attrbits, NFSATTRBIT_FILEHANDLE)) nd->nd_repstat = nfsvno_getfh(vp, &fh, p); - if (!nd->nd_repstat) + if (nd->nd_repstat == 0 && nfsrv_issuedelegs == 1) nd->nd_repstat = nfsrv_checkgetattr(nd, vp, &nva, &attrbits, nd->nd_cred, p); if (nd->nd_repstat == 0) { -- 2.14.2 -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Nov 28 11:04:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55383E52418; Tue, 28 Nov 2017 11:04:35 +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 CCBCB80350; Tue, 28 Nov 2017 11:04:34 +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 vASB4Sga020537 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 13:04:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vASB4Sga020537 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vASB4Srw020536; Tue, 28 Nov 2017 13:04:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 13:04:28 +0200 From: Konstantin Belousov To: Emmanuel Vadot Cc: FreeBSD Current , freebsd-fs@freebsd.org, Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-ID: <20171128110428.GN2272@kib.kiev.ua> References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 11:04:35 -0000 On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > Hello, > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > tunable. > The reason behind it is recent problem at work on some on our filer > related to NFS. > We use NFSv4 without delegation as we never been able to have good > performance with FreeBSD server and Linux client (we need to do test > again but that's for later). We recently see all of our filers with NFS > enabled perform pourly, resulting in really bad performance on the > service. > After doing some analyze with pmcstat we've seen that we spend ~50% > of our time in lock delay, called by nfsrv_checkgetattr (See [1]). > This function is only usefull when using delegation, as it search for > some write delegations issued to client, but it's called anyway when > there so no delegation and cause a lot of problem when having a lot of > activities. > We've patched the kernel with the included diff and now everything is > fine (tm) (See [2]). > The problem for upstreaming this patch is that since issue_delegations > is a sysctl we cannot know if the checkgetattr called is needed, hence > the question to switch it to a TUNABLE. Also maybe some other code path > could benefit from it, I haven't read all the source of nfsserver yet. > > Note that I won't MFC the changes as it would break POLA. Perhaps make nodeleg per-mount flag ? The you can check it safely by dereferencing vp->v_mount->mnt_data without acquiring any locks, while the vnode lock is owned and the vnode is not reclaimed. > > Cheers, > > [1] https://people.freebsd.org/~manu/m8.svg > [2] https://people.freebsd.org/~manu/m8-new.svg > > >From 0cba277f406d3ccf3c9e943a3d4e17b529e31c89 Mon Sep 17 00:00:00 2001 > From: Emmanuel Vadot > Date: Fri, 24 Nov 2017 11:17:18 +0100 > Subject: [PATCH 2/4] Do not call nfsrv_checkgetttr if delegation isn't > enable. > > Signed-off-by: Emmanuel Vadot > --- > sys/fs/nfsserver/nfs_nfsdserv.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c > b/sys/fs/nfsserver/nfs_nfsdserv.c index 8102c5810a9..8daf0142360 100644 > --- a/sys/fs/nfsserver/nfs_nfsdserv.c > +++ b/sys/fs/nfsserver/nfs_nfsdserv.c > @@ -54,6 +54,7 @@ extern struct timeval nfsboottime; > extern int nfs_rootfhset; > extern int nfsrv_enable_crossmntpt; > extern int nfsrv_statehashsize; > +extern int nfsrv_issuedelegs; > #endif /* !APPLEKEXT */ > > static int nfs_async = 0; > @@ -240,7 +241,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int > isdgram, if (nd->nd_flag & ND_NFSV4) { > if (NFSISSET_ATTRBIT(&attrbits, > NFSATTRBIT_FILEHANDLE)) nd->nd_repstat = nfsvno_getfh(vp, &fh, p); > - if (!nd->nd_repstat) > + if (nd->nd_repstat == 0 && nfsrv_issuedelegs > == 1) nd->nd_repstat = nfsrv_checkgetattr(nd, vp, > &nva, &attrbits, nd->nd_cred, p); > if (nd->nd_repstat == 0) { > -- > 2.14.2 > > > -- > Emmanuel Vadot > _______________________________________________ > 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 Nov 28 11:09:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99E6FE527BA for ; Tue, 28 Nov 2017 11:09:21 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE8880831 for ; Tue, 28 Nov 2017 11:09:21 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id f134so36443434lfg.8 for ; Tue, 28 Nov 2017 03:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Pn25yNnsVgU9URl3CHQVVtYSKbaWFtc92cc2Y7iYxlM=; b=UNa+vk+2tdAVG/pYRRRb9Enhnt4yBA4NFE4clBF3livCFuz8M8K0nQQIzF8TZchGoR N5K7Qdrwiyg6AE4ORzJt8aTRfawJwgMkkjMuWd1XEBphrIpWfzLiBk8WRNc/E3rStaPv /Ypv+bRx0VogQprzRpniBp6MtbBc204ah8nNb5b/flbaSiLIG4ZiSCsSR/0+4JN9SiaM V6HH30NpFT1rTr2aZdXJQZJy2KBoJdyXIve66Dht2Jzg+6NvITaSzyemRiPAPaoJJjsv KNd5foZg7Qqe/T0VBfIv1CV/gzMFrdmx8kLpb2ZisFiuoe1g3wwjtxv9siloPP/fz8NG 90og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Pn25yNnsVgU9URl3CHQVVtYSKbaWFtc92cc2Y7iYxlM=; b=dpzIlthdqqTYuBpWM73PT4mtu111qFl0qiRSQisDSLxT5jBKTHvNFeBBo/vIGBlJj7 AyV2IViL7l2svvlwXTOmjgAp/dKVyC0v9inuolDf2qq7Z8jJ87Pwq84NjPEMbSdNZFxz tk9S5GYfIM8b0sdZiBKMoqZYcjtRicv1+xz7dyCtAe9REwVGG8vvUGnDAfUf/7JjHBrI kNXqvktHHJXOhwlsdHq0Y5Ir7ObynzD5PIK6tlwidg+NSvtLxg2FKfRaPyTmfoK9k6Yr qKEgQN7Nkj17xK/acxsRzPlq/lwlFK7dGaId3s1kW34aOXnmNuCL5fkSBPgEwu+FVbg3 gbIw== X-Gm-Message-State: AJaThX68JyUCtpnTlFHiLBIAhipicrfccnNGaCSgCzViQrSmKtEt57E5 xsj0XVHE7Bu5nEdAoAUNp1CCCA== X-Google-Smtp-Source: AGs4zMYc5FIgRnUmbRVeVFGE1mVRNVzTjiuS8znoYtb56k2c0ADiaCJ+RUSKAL5Kf7n6V1EhzMhsZw== X-Received: by 10.46.29.151 with SMTP id w23mr15220920lje.66.1511867359126; Tue, 28 Nov 2017 03:09:19 -0800 (PST) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id j28sm6480287ljb.50.2017.11.28.03.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 03:09:18 -0800 (PST) Subject: Re: CURRENT: core dumped no process name To: Konstantin Belousov Cc: FreeBSD Current References: <20171128082914.GJ2272@kib.kiev.ua> <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> <20171128103809.GM2272@kib.kiev.ua> From: "Alex V. Petrov" Message-ID: Date: Tue, 28 Nov 2017 18:09:16 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171128103809.GM2272@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 11:09:21 -0000 You were right. After revert to r325188 worked: Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 (core dumped) 28.11.2017 17:38, Konstantin Belousov пишет: > On Tue, Nov 28, 2017 at 05:13:10PM +0700, Alex V. Petrov wrote: >> from /var/log/messages >> >> # grep core /var/log/messages >> Nov 21 06:26:56 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 22 00:46:31 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 22 16:01:32 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 23 08:14:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 24 04:32:17 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 24 04:41:44 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 24 04:48:03 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 24 04:49:55 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 24 11:33:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 26 02:50:35 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 26 03:47:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 26 12:05:01 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 26 14:16:26 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 26 14:27:05 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 26 23:49:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 26 23:50:26 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 27 12:13:02 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 27 15:28:11 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 27 15:50:54 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 27 16:34:02 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 28 03:07:42 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 28 04:20:03 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 28 04:51:08 alex kernel: 0: exited on signal 6 (core dumped) >> Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) >> Nov 28 15:55:42 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) >> Nov 28 17:05:35 alex kernel: 0: exited on signal 6 (core dumped) >> > Do you use syslogd after r325558 ? If yes, try to revert it. > > -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Nov 28 11:14:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3748BE52A9F for ; Tue, 28 Nov 2017 11:14:59 +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 BA71780C6E; Tue, 28 Nov 2017 11:14:58 +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 vASBErZm022842 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 13:14:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vASBErZm022842 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vASBErkK022841; Tue, 28 Nov 2017 13:14:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 13:14:53 +0200 From: Konstantin Belousov To: "Alex V. Petrov" Cc: FreeBSD Current , glebius@freebsd.org Subject: Re: CURRENT: core dumped no process name Message-ID: <20171128111453.GO2272@kib.kiev.ua> References: <20171128082914.GJ2272@kib.kiev.ua> <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> <20171128103809.GM2272@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 11:14:59 -0000 On Tue, Nov 28, 2017 at 06:09:16PM +0700, Alex V. Petrov wrote: > You were right. > After revert to r325188 worked: > Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 > (core dumped) Thank you for confirming. Adding the committer. > > 28.11.2017 17:38, Konstantin Belousov ÐÉÛÅÔ: > > On Tue, Nov 28, 2017 at 05:13:10PM +0700, Alex V. Petrov wrote: > >> from /var/log/messages > >> > >> # grep core /var/log/messages > >> Nov 21 06:26:56 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 22 00:46:31 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 22 16:01:32 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 23 08:14:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 24 04:32:17 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 24 04:41:44 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 24 04:48:03 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 24 04:49:55 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 24 11:33:45 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 26 02:50:35 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 26 03:47:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 26 12:05:01 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 26 14:16:26 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 26 14:27:05 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 26 23:49:56 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 26 23:50:26 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 27 12:13:02 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 27 15:28:11 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 27 15:50:54 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 27 16:34:02 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 28 03:07:42 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 28 04:20:03 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 28 04:51:08 alex kernel: 0: exited on signal 6 (core dumped) > >> Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) > >> Nov 28 15:55:42 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > >> Nov 28 17:05:35 alex kernel: 0: exited on signal 6 (core dumped) > >> > > Do you use syslogd after r325558 ? If yes, try to revert it. > > > > > > -- > ----- > Alex. From owner-freebsd-current@freebsd.org Tue Nov 28 13:26:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFC71E56953; Tue, 28 Nov 2017 13:26:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC8A764AA8; Tue, 28 Nov 2017 13:26:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 3b2b6b5e; Tue, 28 Nov 2017 14:26:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=uQh2t/8+hXQh6T6SHB5qna9PjpM=; b=DqQFFgEOH8S3DsSWOhMvq5PZVa/E 6vOnCovRWEypmRoczT94wmLuYPVJMhoeqqXEBzaDEKCaQysU/Kx/naJZahEN6w6h LSmLH60J6G1qDydc8/oX8rpdWe9qwZYqmDGF+qTFOruP4/AZSOSjnrKVq0YiTiMG i9kNoIq3Z/X/kIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=SYdzurtAJVfP4R0oSW52QDpyUzqFkn6FEcmK4xFCY1+YGz2CBaTOpjIb zoRVrhXiSEw1spgxdMdfIKEu4oKvLRIH5sIUyBQMdRjHpaT87Ys6CDM9XQ8hnn3r AG3hyZCF/kQZ804miXHWlB36mw5Z03eEboqagk5Tt4Ry8Jgjyks= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1130363c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 28 Nov 2017 14:26:11 +0100 (CET) Date: Tue, 28 Nov 2017 14:26:10 +0100 From: Emmanuel Vadot To: Konstantin Belousov Cc: FreeBSD Current , freebsd-fs@freebsd.org, Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-Id: <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> In-Reply-To: <20171128110428.GN2272@kib.kiev.ua> References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 13:26:21 -0000 On Tue, 28 Nov 2017 13:04:28 +0200 Konstantin Belousov wrote: > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > > > Hello, > > > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > > tunable. > > The reason behind it is recent problem at work on some on our filer > > related to NFS. > > We use NFSv4 without delegation as we never been able to have good > > performance with FreeBSD server and Linux client (we need to do test > > again but that's for later). We recently see all of our filers with NFS > > enabled perform pourly, resulting in really bad performance on the > > service. > > After doing some analyze with pmcstat we've seen that we spend ~50% > > of our time in lock delay, called by nfsrv_checkgetattr (See [1]). > > This function is only usefull when using delegation, as it search for > > some write delegations issued to client, but it's called anyway when > > there so no delegation and cause a lot of problem when having a lot of > > activities. > > We've patched the kernel with the included diff and now everything is > > fine (tm) (See [2]). > > The problem for upstreaming this patch is that since issue_delegations > > is a sysctl we cannot know if the checkgetattr called is needed, hence > > the question to switch it to a TUNABLE. Also maybe some other code path > > could benefit from it, I haven't read all the source of nfsserver yet. > > > > Note that I won't MFC the changes as it would break POLA. > Perhaps make nodeleg per-mount flag ? > The you can check it safely by dereferencing vp->v_mount->mnt_data without > acquiring any locks, while the vnode lock is owned and the vnode is not > reclaimed. That won't work with current code. Currently if you have delegation enabled and connect one client to a mountpoint, then disable delegation, the current client will still have delegation while new ones will not. I have not tested restarting nfsd in this situation but I suspect that client will behave badly. This is a another +1 for making it a tunable I think. > > > > Cheers, > > > > [1] https://people.freebsd.org/~manu/m8.svg > > [2] https://people.freebsd.org/~manu/m8-new.svg > > > > >From 0cba277f406d3ccf3c9e943a3d4e17b529e31c89 Mon Sep 17 00:00:00 2001 > > From: Emmanuel Vadot > > Date: Fri, 24 Nov 2017 11:17:18 +0100 > > Subject: [PATCH 2/4] Do not call nfsrv_checkgetttr if delegation isn't > > enable. > > > > Signed-off-by: Emmanuel Vadot > > --- > > sys/fs/nfsserver/nfs_nfsdserv.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c > > b/sys/fs/nfsserver/nfs_nfsdserv.c index 8102c5810a9..8daf0142360 100644 > > --- a/sys/fs/nfsserver/nfs_nfsdserv.c > > +++ b/sys/fs/nfsserver/nfs_nfsdserv.c > > @@ -54,6 +54,7 @@ extern struct timeval nfsboottime; > > extern int nfs_rootfhset; > > extern int nfsrv_enable_crossmntpt; > > extern int nfsrv_statehashsize; > > +extern int nfsrv_issuedelegs; > > #endif /* !APPLEKEXT */ > > > > static int nfs_async = 0; > > @@ -240,7 +241,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int > > isdgram, if (nd->nd_flag & ND_NFSV4) { > > if (NFSISSET_ATTRBIT(&attrbits, > > NFSATTRBIT_FILEHANDLE)) nd->nd_repstat = nfsvno_getfh(vp, &fh, p); > > - if (!nd->nd_repstat) > > + if (nd->nd_repstat == 0 && nfsrv_issuedelegs > > == 1) nd->nd_repstat = nfsrv_checkgetattr(nd, vp, > > &nva, &attrbits, nd->nd_cred, p); > > if (nd->nd_repstat == 0) { > > -- > > 2.14.2 > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > 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" > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Nov 28 13:40:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BDC7E56EA1; Tue, 28 Nov 2017 13:40:20 +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 9F098651DF; Tue, 28 Nov 2017 13:40:19 +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 vASDe9Gu056890 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 15:40:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vASDe9Gu056890 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vASDe9sj056888; Tue, 28 Nov 2017 15:40:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 15:40:09 +0200 From: Konstantin Belousov To: Emmanuel Vadot Cc: FreeBSD Current , freebsd-fs@freebsd.org, Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-ID: <20171128134009.GQ2272@kib.kiev.ua> References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 13:40:20 -0000 On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: > On Tue, 28 Nov 2017 13:04:28 +0200 > Konstantin Belousov wrote: > > > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > > > > > Hello, > > > > > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > > > tunable. > > > The reason behind it is recent problem at work on some on our filer > > > related to NFS. > > > We use NFSv4 without delegation as we never been able to have good > > > performance with FreeBSD server and Linux client (we need to do test > > > again but that's for later). We recently see all of our filers with NFS > > > enabled perform pourly, resulting in really bad performance on the > > > service. > > > After doing some analyze with pmcstat we've seen that we spend ~50% > > > of our time in lock delay, called by nfsrv_checkgetattr (See [1]). > > > This function is only usefull when using delegation, as it search for > > > some write delegations issued to client, but it's called anyway when > > > there so no delegation and cause a lot of problem when having a lot of > > > activities. > > > We've patched the kernel with the included diff and now everything is > > > fine (tm) (See [2]). > > > The problem for upstreaming this patch is that since issue_delegations > > > is a sysctl we cannot know if the checkgetattr called is needed, hence > > > the question to switch it to a TUNABLE. Also maybe some other code path > > > could benefit from it, I haven't read all the source of nfsserver yet. > > > > > > Note that I won't MFC the changes as it would break POLA. > > Perhaps make nodeleg per-mount flag ? > > The you can check it safely by dereferencing vp->v_mount->mnt_data without > > acquiring any locks, while the vnode lock is owned and the vnode is not > > reclaimed. > > That won't work with current code. Why ? > Currently if you have delegation enabled and connect one client to a > mountpoint, then disable delegation, the current client will still have > delegation while new ones will not. I have not tested restarting nfsd in > this situation but I suspect that client will behave badly. This is a > another +1 for making it a tunable I think. It is up to the filesystem to handle remount, in particular, fs can disable changing mount options on mount upgrade if the operation is not supported. In other words, you would do mount -o nodeleg ... /mnt and mount -u -o nonodeleg ... /mnt needs to return EINVAL. > > > > > > > Cheers, > > > > > > [1] https://people.freebsd.org/~manu/m8.svg > > > [2] https://people.freebsd.org/~manu/m8-new.svg > > > > > > >From 0cba277f406d3ccf3c9e943a3d4e17b529e31c89 Mon Sep 17 00:00:00 2001 > > > From: Emmanuel Vadot > > > Date: Fri, 24 Nov 2017 11:17:18 +0100 > > > Subject: [PATCH 2/4] Do not call nfsrv_checkgetttr if delegation isn't > > > enable. > > > > > > Signed-off-by: Emmanuel Vadot > > > --- > > > sys/fs/nfsserver/nfs_nfsdserv.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c > > > b/sys/fs/nfsserver/nfs_nfsdserv.c index 8102c5810a9..8daf0142360 100644 > > > --- a/sys/fs/nfsserver/nfs_nfsdserv.c > > > +++ b/sys/fs/nfsserver/nfs_nfsdserv.c > > > @@ -54,6 +54,7 @@ extern struct timeval nfsboottime; > > > extern int nfs_rootfhset; > > > extern int nfsrv_enable_crossmntpt; > > > extern int nfsrv_statehashsize; > > > +extern int nfsrv_issuedelegs; > > > #endif /* !APPLEKEXT */ > > > > > > static int nfs_async = 0; > > > @@ -240,7 +241,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int > > > isdgram, if (nd->nd_flag & ND_NFSV4) { > > > if (NFSISSET_ATTRBIT(&attrbits, > > > NFSATTRBIT_FILEHANDLE)) nd->nd_repstat = nfsvno_getfh(vp, &fh, p); > > > - if (!nd->nd_repstat) > > > + if (nd->nd_repstat == 0 && nfsrv_issuedelegs > > > == 1) nd->nd_repstat = nfsrv_checkgetattr(nd, vp, > > > &nva, &attrbits, nd->nd_cred, p); > > > if (nd->nd_repstat == 0) { > > > -- > > > 2.14.2 > > > > > > > > > -- > > > Emmanuel Vadot > > > _______________________________________________ > > > 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" > > _______________________________________________ > > 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" > > > -- > Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Nov 28 14:12:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E039AE57BED; Tue, 28 Nov 2017 14:12:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0078.outbound.protection.outlook.com [104.47.40.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D16E662CF; Tue, 28 Nov 2017 14:12:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2171.CANPRD01.PROD.OUTLOOK.COM (52.132.46.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 14:12:38 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 14:12:38 +0000 From: Rick Macklem To: Konstantin Belousov , Emmanuel Vadot CC: FreeBSD Current , "freebsd-fs@freebsd.org" , Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyo= Date: Tue, 28 Nov 2017 14:12:38 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com>, <20171128134009.GQ2272@kib.kiev.ua> In-Reply-To: <20171128134009.GQ2272@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2171; 6:ix74uNI1SocEsUxRJU+8XuYUKYqxzilCzO3DXT4Si2RPKRvF5szOjimqYCmXzh+F3tNvXg+bd4bSma2EX5xaZFux6EEjvIrhhjXNbBJREY9f0FvUYIifJhB3/9EOP63pMnzEywSjSYzPzdtVjGgCCGJcKgGjObJcS3+ZnaDl9369XhO8i9bCPRMO1jB6GgRUy4WGE1OjWFC/bg8UmAErUchj1u/6zq/h/cALgUxDHKxsa2KvimBcOMAANq84XMPik3TBfGFI05Kj91pBcjvho4M1MHikY/3GACi3bFGhebRDvkv8rEwlGWA6yvr2HIURXUR+oeyi1u2Oc6jMLv2vIIHKCE+jEJXFwHKMjJ/OiL0=; 5:iERIKJKB16qwB2o3QhLxcAPrvcsdMeEXN8qsIEb52Fr+k7rPKuCxyg1Z9wLpAS5ji1pYnrBf0f8yhRy3WgjCWKlHvP8OzruOgltEjhhZWql3cu/FB0NRSLkkKQb+u/vJytD0VLAsSoQYjur3OaeQgCPrOp4MKwmRMUmJ8KZYLVU=; 24:R5LNBBN8LPw/vsNeo0pcl0+J/E0jJcxWluXtXrjVTYj0Jyjqs7PbW1EKIL5AzrUEJ355vn4CdyxK/RcqCmLzSxbElXqwDwf9OKDRo4x+gUs=; 7:vd8n8oukPMNBUqJ0hg+oEcW9F7YVzZvGVrGSzTzMuW9bg047GbxbtDKaOZRD8hvwJniQRT7/h7J47jWmln4gIa9y+cr928CPLhkc8i4CIT88KT0kkQXEMWp9BdHmaejU8MZ8341TiVWQhtjYpBlk9lu5sihJQ/c3smeTvY1WF+JLi7YRj2mQwoYUA7q7j+5IwtGr8fELfWqmfORS57Gdy1RqbERPHhbjCOsdxoXU6+xLqxffdYaR+mUZmAjRd8zO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5caea99f-8e08-4fdd-4d13-08d5366a14c3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603258); SRVR:YTOPR0101MB2171; x-ms-traffictypediagnostic: YTOPR0101MB2171: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:YTOPR0101MB2171; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2171; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(366004)(24454002)(189002)(199003)(316002)(25786009)(786003)(5250100002)(478600001)(110136005)(86362001)(55016002)(54906003)(68736007)(97736004)(7696005)(74316002)(4326008)(8676002)(3280700002)(189998001)(305945005)(81156014)(9686003)(81166006)(5660300001)(3660700001)(2950100002)(93886005)(105586002)(2900100001)(14454004)(2906002)(39060400002)(8936002)(33656002)(76176999)(102836003)(229853002)(74482002)(54356999)(99286004)(6246003)(53936002)(106356001)(50986999)(6436002)(6506006)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2171; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 5caea99f-8e08-4fdd-4d13-08d5366a14c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 14:12:38.4632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2171 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 14:12:41 -0000 Konstantin Belousov wrote: >On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: >> On Tue, 28 Nov 2017 13:04:28 +0200 >> Konstantin Belousov wrote: >> >> > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: >> > > >> > > Hello, >> > > >> > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a >> > > tunable. Since it defaults to "disabled", I don't see why a tunable would be necessa= ry? (Just do nothing and delegations don't happen. If you want the server to issue delegations, then use the sysctl to turn them on. If you want to = turn them off again at the server, reboot the server without setting the sysctl= .) > > > The reason behind it is recent problem at work on some on our filer > > > related to NFS. > > > We use NFSv4 without delegation as we never been able to have good > > > performance with FreeBSD server and Linux client (we need to do test > > > again but that's for later). Delegations are almost never useful, especially with Linux clients. [stuff snipped] > > Perhaps make nodeleg per-mount flag ? The sysctl vfs.nfsd.issue_delegations only affects the server. If you have a FreeBSD client that is mounting a delegations enabled server = and does not want delegations, just don't run the "nfscbd" daemon on the client= . The only time you want the "nfscbd" daemon running is for delegations and pNFS layouts. (I suppose there is the case of a client using NFSv4.1/pNFS a= gainst a server with delegations enabled, but since delegations aren't very useful= , I'd just disable delegations on the server for this case.) Having a per-mount version of this would be overkill, I think. It would hav= e to disable callbacks on the mount point, since there is no way for a client to= say "don't give me delegations" except disabling callbacks, which the server requires for delegation issue. [stuff snipped] The case where there has never been delegations issued will result in an empty delegation queue. Maybe this case can be handled without acquiring the "global NFSv4 state lock", which is what sounds like is causing the performance issue. Maybe a global counter of how many delegations are issued that is handled by atomic ops. --> If it is 0, nfsrv_checkgetattr() can just return without acquiring the = lock. I'll take a look at this, rick= From owner-freebsd-current@freebsd.org Tue Nov 28 15:38:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07C68DB9DFB; Tue, 28 Nov 2017 15:38:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45A7669371; Tue, 28 Nov 2017 15:38:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4219a0a8; Tue, 28 Nov 2017 16:38:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=DFMtGTwnA+GslL9YwFlfrZ1cOxg=; b=KuyGXYZ9yKjp/v7xZDLap7a5C6MO Jre68EvRCLcnRm++XLoND05858y0C0WgPscV53ddZ0FNvbP8bn7I/iHz0VIlSwBE 3cCD69wQk7Chg13VAS9AfAo63N+TBz3cpPuQJuHcfcx2CSh3ObCOKgm7pJeCTuXv 2rL/9xsLWf8OWns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=KNnFRi0IqesS0s/Xq33+dQ5mr34o8+t83lNNyaWx6gLdebYhs1h3TENZ +6hiVq5/TmLSK3DCFyadmflBFBCLqXdyNq/xk45Ji2MPvd+1S4/TEKxvqlbPfMJ1 gAHJlH1IKv4qNTg/htEBvxHw33b/Lc1YIaTVVB8slCezMDd8nGk= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 836f99d3 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 28 Nov 2017 16:38:34 +0100 (CET) Date: Tue, 28 Nov 2017 16:38:33 +0100 From: Emmanuel Vadot To: Konstantin Belousov Cc: FreeBSD Current , freebsd-fs@freebsd.org, Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-Id: <20171128163833.696c04c8dfc7dd9fc183d2df@bidouilliste.com> In-Reply-To: <20171128134009.GQ2272@kib.kiev.ua> References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 15:38:38 -0000 On Tue, 28 Nov 2017 15:40:09 +0200 Konstantin Belousov wrote: > On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: > > On Tue, 28 Nov 2017 13:04:28 +0200 > > Konstantin Belousov wrote: > > > > > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > > > > > > > Hello, > > > > > > > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > > > > tunable. > > > > The reason behind it is recent problem at work on some on our filer > > > > related to NFS. > > > > We use NFSv4 without delegation as we never been able to have good > > > > performance with FreeBSD server and Linux client (we need to do test > > > > again but that's for later). We recently see all of our filers with NFS > > > > enabled perform pourly, resulting in really bad performance on the > > > > service. > > > > After doing some analyze with pmcstat we've seen that we spend ~50% > > > > of our time in lock delay, called by nfsrv_checkgetattr (See [1]). > > > > This function is only usefull when using delegation, as it search for > > > > some write delegations issued to client, but it's called anyway when > > > > there so no delegation and cause a lot of problem when having a lot of > > > > activities. > > > > We've patched the kernel with the included diff and now everything is > > > > fine (tm) (See [2]). > > > > The problem for upstreaming this patch is that since issue_delegations > > > > is a sysctl we cannot know if the checkgetattr called is needed, hence > > > > the question to switch it to a TUNABLE. Also maybe some other code path > > > > could benefit from it, I haven't read all the source of nfsserver yet. > > > > > > > > Note that I won't MFC the changes as it would break POLA. > > > Perhaps make nodeleg per-mount flag ? > > > The you can check it safely by dereferencing vp->v_mount->mnt_data without > > > acquiring any locks, while the vnode lock is owned and the vnode is not > > > reclaimed. > > > > That won't work with current code. > Why ? > > > Currently if you have delegation enabled and connect one client to a > > mountpoint, then disable delegation, the current client will still have > > delegation while new ones will not. I have not tested restarting nfsd in > > this situation but I suspect that client will behave badly. This is a > > another +1 for making it a tunable I think. > It is up to the filesystem to handle remount, in particular, fs can disable > changing mount options on mount upgrade if the operation is not supported. > In other words, you would do > mount -o nodeleg ... /mnt > and > mount -u -o nonodeleg ... /mnt > needs to return EINVAL. You are talking about client here while I'm talking about server. > > > > > > > > > > Cheers, > > > > > > > > [1] https://people.freebsd.org/~manu/m8.svg > > > > [2] https://people.freebsd.org/~manu/m8-new.svg > > > > > > > > >From 0cba277f406d3ccf3c9e943a3d4e17b529e31c89 Mon Sep 17 00:00:00 2001 > > > > From: Emmanuel Vadot > > > > Date: Fri, 24 Nov 2017 11:17:18 +0100 > > > > Subject: [PATCH 2/4] Do not call nfsrv_checkgetttr if delegation isn't > > > > enable. > > > > > > > > Signed-off-by: Emmanuel Vadot > > > > --- > > > > sys/fs/nfsserver/nfs_nfsdserv.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c > > > > b/sys/fs/nfsserver/nfs_nfsdserv.c index 8102c5810a9..8daf0142360 100644 > > > > --- a/sys/fs/nfsserver/nfs_nfsdserv.c > > > > +++ b/sys/fs/nfsserver/nfs_nfsdserv.c > > > > @@ -54,6 +54,7 @@ extern struct timeval nfsboottime; > > > > extern int nfs_rootfhset; > > > > extern int nfsrv_enable_crossmntpt; > > > > extern int nfsrv_statehashsize; > > > > +extern int nfsrv_issuedelegs; > > > > #endif /* !APPLEKEXT */ > > > > > > > > static int nfs_async = 0; > > > > @@ -240,7 +241,7 @@ nfsrvd_getattr(struct nfsrv_descript *nd, int > > > > isdgram, if (nd->nd_flag & ND_NFSV4) { > > > > if (NFSISSET_ATTRBIT(&attrbits, > > > > NFSATTRBIT_FILEHANDLE)) nd->nd_repstat = nfsvno_getfh(vp, &fh, p); > > > > - if (!nd->nd_repstat) > > > > + if (nd->nd_repstat == 0 && nfsrv_issuedelegs > > > > == 1) nd->nd_repstat = nfsrv_checkgetattr(nd, vp, > > > > &nva, &attrbits, nd->nd_cred, p); > > > > if (nd->nd_repstat == 0) { > > > > -- > > > > 2.14.2 > > > > > > > > > > > > -- > > > > Emmanuel Vadot > > > > _______________________________________________ > > > > 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" > > > _______________________________________________ > > > 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" > > > > > > -- > > Emmanuel Vadot > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Nov 28 15:41:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4378CDBA2DC; Tue, 28 Nov 2017 15:41:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 330BD69788; Tue, 28 Nov 2017 15:41:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id e27b0ab0; Tue, 28 Nov 2017 16:41:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=QTIfWcGWeCrF/MOyhkEvMjwA8/s=; b=bt9yCPrzgk0ZXmDXGfYRblqyrEpc Ra0hUg8knck229h8oeyfawdSliPMsXujvPanJzZUbjbY1TnV2wTnElX/JRVdgMiW aViELFAxi8BYEo//t5jev7ygLb3pevVRthWS11zstnYfILy7Nh4LrmzYX8GQYACq xi2VbVzQcm3WylQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gStvohJrRckZG+Qfa3F5ux/8362dj2I53ZbsZGnDR3xcs3Ky7hr5f6hu 5uD0gMBxosZY6jU8nNmluCatVBBxmeVvH8eSnPbcKAqNdf5+Dif3XnrWed6yKP/p LCKu1JbIWeieIQALg2aSLulq2V1UiuV167g/kRf5BLtdQY3VlrQ= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 602eac22 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 28 Nov 2017 16:41:32 +0100 (CET) Date: Tue, 28 Nov 2017 16:41:32 +0100 From: Emmanuel Vadot To: Rick Macklem Cc: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" , Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-Id: <20171128164132.290bf07218b16164db613242@bidouilliste.com> In-Reply-To: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 15:41:38 -0000 On Tue, 28 Nov 2017 14:12:38 +0000 Rick Macklem wrote: > Konstantin Belousov wrote: > >On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: > >> On Tue, 28 Nov 2017 13:04:28 +0200 > >> Konstantin Belousov wrote: > >> > >> > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > >> > > > >> > > Hello, > >> > > > >> > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > >> > > tunable. > Since it defaults to "disabled", I don't see why a tunable would be necessary? > (Just do nothing and delegations don't happen. If you want the server > to issue delegations, then use the sysctl to turn them on. If you want to turn > them off again at the server, reboot the server without setting the sysctl.) If you need to reboot to make things working again without delegation this shouldn't be a sysctl. > > > > The reason behind it is recent problem at work on some on our filer > > > > related to NFS. > > > > We use NFSv4 without delegation as we never been able to have good > > > > performance with FreeBSD server and Linux client (we need to do test > > > > again but that's for later). > Delegations are almost never useful, especially with Linux clients. Can you elaborate ? Reading what delegation are I see that this is exactly what I'm looking for to have better performance with NFS for my workload (I only have one client per mount point). > [stuff snipped] > > > Perhaps make nodeleg per-mount flag ? > The sysctl vfs.nfsd.issue_delegations only affects the server. > If you have a FreeBSD client that is mounting a delegations enabled server and > does not want delegations, just don't run the "nfscbd" daemon on the client. > The only time you want the "nfscbd" daemon running is for delegations and > pNFS layouts. (I suppose there is the case of a client using NFSv4.1/pNFS against > a server with delegations enabled, but since delegations aren't very useful, > I'd just disable delegations on the server for this case.) > > Having a per-mount version of this would be overkill, I think. It would have to > disable callbacks on the mount point, since there is no way for a client to say > "don't give me delegations" except disabling callbacks, which the server > requires for delegation issue. > [stuff snipped] > The case where there has never been delegations issued will result in an > empty delegation queue. Maybe this case can be handled without acquiring > the "global NFSv4 state lock", which is what sounds like is causing the > performance issue. Maybe a global counter of how many delegations are > issued that is handled by atomic ops. > --> If it is 0, nfsrv_checkgetattr() can just return without acquiring the lock. > > I'll take a look at this, rick > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Nov 28 16:37:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CE6FDE3401 for ; Tue, 28 Nov 2017 16:37:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FB0B6D4D2 for ; Tue, 28 Nov 2017 16:37:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id vASGbjZp040961 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 08:37:45 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id vASGbimC040960; Tue, 28 Nov 2017 08:37:44 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 28 Nov 2017 08:37:44 -0800 From: Gleb Smirnoff To: "Alex V. Petrov" Cc: Konstantin Belousov , FreeBSD Current Subject: Re: CURRENT: core dumped no process name Message-ID: <20171128163744.GN1063@FreeBSD.org> References: <20171128082914.GJ2272@kib.kiev.ua> <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> <20171128103809.GM2272@kib.kiev.ua> 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 16:37:46 -0000 Hi Alex, On Tue, Nov 28, 2017 at 06:09:16PM +0700, Alex V. Petrov wrote: A> You were right. A> After revert to r325188 worked: A> Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 A> (core dumped) Can you please send over to me the syslogd binary and syslogd.core? -- Gleb Smirnoff From owner-freebsd-current@freebsd.org Tue Nov 28 18:47:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A60EADEB273 for ; Tue, 28 Nov 2017 18:47:28 +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 3AF0E732F8; Tue, 28 Nov 2017 18:47: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 vASIlNBu029118 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 20:47:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vASIlNBu029118 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vASIlNt6029117; Tue, 28 Nov 2017 20:47:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Nov 2017 20:47:23 +0200 From: Konstantin Belousov To: Gleb Smirnoff Cc: "Alex V. Petrov" , FreeBSD Current Subject: Re: CURRENT: core dumped no process name Message-ID: <20171128184723.GT2272@kib.kiev.ua> References: <20171128082914.GJ2272@kib.kiev.ua> <37361d1d-72a2-52ba-f028-87c896d78a97@gmail.com> <20171128103809.GM2272@kib.kiev.ua> <20171128163744.GN1063@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128163744.GN1063@FreeBSD.org> User-Agent: Mutt/1.9.1 (2017-09-22) 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.25 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, 28 Nov 2017 18:47:28 -0000 On Tue, Nov 28, 2017 at 08:37:44AM -0800, Gleb Smirnoff wrote: > Hi Alex, > > On Tue, Nov 28, 2017 at 06:09:16PM +0700, Alex V. Petrov wrote: > A> You were right. > A> After revert to r325188 worked: > A> Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 > A> (core dumped) > > Can you please send over to me the syslogd binary and syslogd.core? Syslogd does not crash, it removes part of the kernel message which it perceives as the host name. Read the whole thread. From owner-freebsd-current@freebsd.org Tue Nov 28 19:09:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 211A0DEBB16; Tue, 28 Nov 2017 19:09:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0086.outbound.protection.outlook.com [104.47.32.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B749373F58; Tue, 28 Nov 2017 19:09:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2170.CANPRD01.PROD.OUTLOOK.COM (52.132.46.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 19:09:51 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 19:09:51 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" , Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPob Date: Tue, 28 Nov 2017 19:09:51 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> , <20171128164132.290bf07218b16164db613242@bidouilliste.com> In-Reply-To: <20171128164132.290bf07218b16164db613242@bidouilliste.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2170; 6:6P5l40wMw0G7+elFo+SE/zuOwWEr1RYUlHsn1FwowPdxXx8AEcIlVVJQh/P9na1oM5GbrL4+XZL+wQKIpHuLgUnB8UuKEFcgG1SwfSglSc4vG6RUoUR2g3NHiHYY4TY5mbqvT4PrKh6hH45pWOsHDptOgAOX5usJyjO7+RKjx6arDjszX587tmLYwIX+kVsEKs1t5OVGr3X1VIjCluhxFDM/do5emIRWp+ckFKvHRdQb6+7TDz5fBifu1sN1ew8dxF5JQEtI0H1QZpbmB8RGBtrcCa88oDCLknoP7/6IIz862DWf+e5KX06kb7PDIF3HAxJIVKV4WPk6AhmjKgpBA5H+NXUQSPVpaGUL5wkBXFQ=; 5:nT1mQmh6CCcOrdFzC2ZhxI5jcf2gk+IprlrhzgoSzp70cZW0gS2TShWZq6MwI7I075Vucho+gZ9feZUi6skVWlzn1pOx8fRFjluvx9/55aHH6r7AZvSAcuw4IoKC/8O4BZ0mr9qFPSF5kBAohiZrFpj03AY2mAxRB1cB+dh8S3U=; 24:KHuhjr61DDGwuZuJXFIztjb9noqX0oVJWdkYAvYuFhif+W1YTVCFmX/1P+GNRKVEKTQOmwUe9MkKy7FI1Huc7YZKo7IYmfbZz6fBnHM7hGs=; 7:BzNKDNFmpXOqBj3rqwTivgEZZ2/6Va8VKrryNTEeMUkN06Gw+1yVRnXKpVozWuWMpWhYvD3Atb8O9zKZhwRvvrPXBsit9aHmwatsAdtoviojLCD5pCrkr1nXudc+AK2PYBVjWEgyAF9Ol18QGbYfVuQZxJ5PlOj/HrlYdMsmVhJHWHUWFS/0YVLAYkrjCJBwz6bAMw1tYjwDtfbKuJZpa6bYr6QNB64URvOGg1CsauWWfGGGzYtvY0L2N4HTob4P x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8ffe4927-c342-4077-954c-08d536939a38 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603258); SRVR:YTOPR0101MB2170; x-ms-traffictypediagnostic: YTOPR0101MB2170: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:YTOPR0101MB2170; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2170; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(189002)(24454002)(199003)(68736007)(105586002)(54906003)(2906002)(229853002)(81166006)(53936002)(81156014)(33656002)(8676002)(305945005)(5250100002)(55016002)(478600001)(97736004)(4326008)(316002)(8936002)(76176999)(101416001)(9686003)(2900100001)(6506006)(102836003)(786003)(3660700001)(3280700002)(54356999)(6436002)(50986999)(6916009)(2950100002)(86362001)(14454004)(106356001)(7696005)(99286004)(39060400002)(74482002)(6246003)(74316002)(189998001)(5660300001)(93886005)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2170; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 8ffe4927-c342-4077-954c-08d536939a38 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:09:51.7660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2170 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 19:09:54 -0000 Emmanuel Vadot wrote: >I wrote: >> Since it defaults to "disabled", I don't see why a tunable would be nece= ssary? >> (Just do nothing and delegations don't happen. If you want the server >> to issue delegations, then use the sysctl to turn them on. If you want = to turn >> them off again at the server, reboot the server without setting the sys= ctl.) > >If you need to reboot to make things working again without delegation >this shouldn't be a sysctl. Turning them off without rebooting doesn't break anything. I just wrote it that way since you seemed to want to use a tunable, which implied rebooting was your preference. > > > > The reason behind it is recent problem at work on some on our file= r > > > > related to NFS. > > > > We use NFSv4 without delegation as we never been able to have good > > > > performance with FreeBSD server and Linux client (we need to do tes= t > > > > again but that's for later). > Delegations are almost never useful, especially with Linux clients. Emmanuel Vadot wrote: >Can you elaborate ? Reading what delegation are I see that this is >exactly what I'm looking for to have better performance with NFS for my >workload (I only have one client per mount point). Delegations allow the client to do Opens locally without contacting the server. Unless, the delegation is a write delegation, this only applied to read-only delegations. Also, since most implementors couldn`t agree on how to check permissions via the delegation, most client implementations still do an Access check at open, which is almost as much overhead as the Open RPC. (For example, Solaris servers always specified an empty ACE in th= e delegation, forcing the client to do an Access. I have no idea what the current Linux server=E9client does. If you capture packets when a Linux client is mounted with delegations enabled, you could look for RPCs like Ac= cess when are Opened multiple times. If you see them, then delegations aren`t saving = RPCs. Also, they are `per file`, so are only useful if the client is Opening the same file multiple times. Further, if another client Opens the same file and the first client got a W= rite delegation, then the write delegation must be recalled, which is a lot of overhead and one of the few cases where the FreeBSD server must exclusively lock the state lists, forcing all other RPCs related to Open, Close to wait= . They sounded good in theory and might have worked well if the implementors had agreed to do them, but that didn=E8t happen. (Companies pay for servers= , but the clients don=E8t get funded so delegation support in the clients are lacking= . I tried to make them useful in the FreeBSD client, but I=E8m not sure I succeeded.) > [stuff snipped] If I understood your original post, you have a performance problem caused by lock contention, where the server grabs the state lock to check for dele= gations for every Getattr from a client. As below, I think the fix is to add code to check for no delegations issued= that does not require acquisition of the state lock. Btw, large numbers of Getattrs will not perform well with delegations. (Again, the client should be able to do Getattr operations locally in the client when it has a delegation for the file, but if the client is not doi= ng that...) I wrote: > > Having a per-mount version of this would be overkill, I think. It would h= ave to > disable callbacks on the mount point, since there is no way for a client = to say > "don't give me delegations" except disabling callbacks, which the server > requires for delegation issue. > [stuff snipped] > The case where there has never been delegations issued will result in an > empty delegation queue. Maybe this case can be handled without acquiring > the "global NFSv4 state lock", which is what sounds like is causing the > performance issue. Maybe a global counter of how many delegations are > issued that is handled by atomic ops. > --> If it is 0, nfsrv_checkgetattr() can just return without acquiring th= e lock. > > I'll take a look at this, rick >=20 rick= From owner-freebsd-current@freebsd.org Tue Nov 28 19:53:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2744DECDCA for ; Tue, 28 Nov 2017 19:53:41 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6733775A53 for ; Tue, 28 Nov 2017 19:53:40 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from firewall.mikej.com (f [162.230.214.65]) by mx2.paymentallianceintl.com (8.15.2/8.15.2) with ESMTPS id vASJk4VC012934 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 28 Nov 2017 14:46:05 -0500 (EST) (envelope-from mikej@mikej.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 mx2.paymentallianceintl.com vASJk4VC012934 Authentication-Results: mx2.paymentallianceintl.com; sender-id=pass header.from=mikej@mikej.com; spf=pass smtp.mfrom=mikej@mikej.com X-Authentication-Warning: mx2.paymentallianceintl.com: Host f [162.230.214.65] claimed to be firewall.mikej.com Received: from mail.mikej.com (firewall [192.168.6.63]) by firewall.mikej.com (8.15.2/8.15.2) with ESMTP id vASJk4BM040977 for ; Tue, 28 Nov 2017 14:46:04 -0500 (EST) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewall.mikej.com: Host firewall [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_59860c679f9477fadac6373721f3fcd1" Date: Tue, 28 Nov 2017 14:46:03 -0500 From: Michael Jung To: freebsd-current@freebsd.org Subject: witness_lock_list_get: witness exhausted Message-ID: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 19:53:41 -0000 --=_59860c679f9477fadac6373721f3fcd1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi! I've recently up'd my processor count on our poudriere box and have started noticing the error "witness_lock_list_get: witness exhausted" on the console. The kernel *DOES NOT* crash but I thought the report may be useful to someone. $ uname -a FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov 19 18:41:20 EST 2017 mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 The machine is pretty busy running four poudriere build instances. last pid: 76584; load averages: 115.07, 115.96, 98.30 up 6+07:32:59 14:44:03 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other 25G Compressed, 32G Uncompressed, 1.24:1 Ratio Let me know what additional information I might supply. Thanks! --mikej --=_59860c679f9477fadac6373721f3fcd1 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=witness.debug.txt Content-Disposition: attachment; filename=witness.debug.txt; size=14057 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMi4wLUNVUlJFTlQgIzEgcjMyNTk5OTogU3VuIE5v diAxOSAxODo0MToyMCBFU1QgMjAxNwogICAgbWlrZWpAcG91ZHJpZXJlOi91c3Ivb2JqL3Vzci9z cmMvYW1kNjQuYW1kNjQvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDUu MC4wICh0YWdzL1JFTEVBU0VfNTAwL2ZpbmFsIDMxMjU1OSkgKGJhc2VkIG9uIExMVk0gNS4wLjBz dm4pCldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZv cm1hbmNlLgpWVCh2Z2EpOiB0ZXh0IDgweDI1CkNQVTogSW50ZWwoUikgWGVvbihSKSBDUFUgRTct IDQ4NTAgIEAgMi4wMEdIeiAoMTk5NS4wMC1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2Vu dWluZUludGVsIiAgSWQ9MHgyMDZmMiAgRmFtaWx5PTB4NiAgTW9kZWw9MHgyZiAgU3RlcHBpbmc9 MgogIEZlYXR1cmVzPTB4MWZhM2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENY OCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsRFRTLE1NWCxGWFNSLFNTRSxT U0UyLFNTLEhUVD4KICBGZWF0dXJlczI9MHg4M2I4MjIwMzxTU0UzLFBDTE1VTFFEUSxTU1NFMyxD WDE2LFNTRTQuMSxTU0U0LjIseDJBUElDLFBPUENOVCxUU0NETFQsQUVTTkksSFY+CiAgQU1EIEZl YXR1cmVzPTB4MjgxMDA4MDA8U1lTQ0FMTCxOWCxSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0w eDE8TEFIRj4KICBTdHJ1Y3R1cmVkIEV4dGVuZGVkIEZlYXR1cmVzPTB4MjxUU0NBREo+CiAgVFND OiBQLXN0YXRlIGludmFyaWFudApIeXBlcnZpc29yOiBPcmlnaW4gPSAiVk13YXJlVk13YXJlIgpy ZWFsIG1lbW9yeSAgPSA5NjYzNjc2NDE2MCAoOTIxNjAgTUIpCmF2YWlsIG1lbW9yeSA9IDkzODcz Nzg2ODgwICg4OTUyNSBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDYwMApBQ1BJIEFQ SUMgVGFibGU6IDxQVExURCAgCSBBUElDICA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBT eXN0ZW0gRGV0ZWN0ZWQ6IDYwIENQVXMKRnJlZUJTRC9TTVA6IDYgcGFja2FnZShzKSB4IDEwIGNv cmUocykKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KTUFEVDogRm9yY2luZyBhY3RpdmUtbG93 IHBvbGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZvciBTQ0kKaW9hcGljMCA8VmVyc2lvbiAxLjE+ IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApTTVA6IEFQIENQVSAjNDYgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMxNiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzcgTGF1bmNoZWQhClNNUDogQVAgQ1BV ICM1MSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIwIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTUg TGF1bmNoZWQhClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNDggTGF1bmNo ZWQhClNNUDogQVAgQ1BVICMyMyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzI3IExhdW5jaGVkIQpT TVA6IEFQIENQVSAjMTIgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpTTVA6IEFQ IENQVSAjNTUgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxNyBMYXVuY2hlZCEKU01QOiBBUCBDUFUg IzUyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTggTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzOSBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzExIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNDEgTGF1bmNo ZWQhClNNUDogQVAgQ1BVICM1OCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNN UDogQVAgQ1BVICMyNiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzM3IExhdW5jaGVkIQpTTVA6IEFQ IENQVSAjNDUgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM0MCBMYXVuY2hlZCEKU01QOiBBUCBDUFUg IzM1IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNTMgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM1MCBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzQ0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMzQgTGF1bmNo ZWQhClNNUDogQVAgQ1BVICMzMCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMxIExhdW5jaGVkIQpT TVA6IEFQIENQVSAjNDcgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxMyBMYXVuY2hlZCEKU01QOiBB UCBDUFUgIzI4IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNDkgTGF1bmNoZWQhClNNUDogQVAgQ1BV ICM1NCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzggTGF1bmNoZWQhClNNUDogQVAgQ1BVICM1NyBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzI5IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNCBMYXVuY2hl ZCEKU01QOiBBUCBDUFUgIzI0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMzMgTGF1bmNoZWQhClNN UDogQVAgQ1BVICMzOCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzU5IExhdW5jaGVkIQpTTVA6IEFQ IENQVSAjOSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzQyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAj NSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM0MyBMYXVu Y2hlZCEKU01QOiBBUCBDUFUgIzE0IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTkgTGF1bmNoZWQh ClNNUDogQVAgQ1BVICMxMCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzI1IExhdW5jaGVkIQpTTVA6 IEFQIENQVSAjNTYgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzNiBMYXVuY2hlZCEKU01QOiBBUCBD UFUgIzIyIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMzIgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMy MSBMYXVuY2hlZCEKcmFuZG9tOiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UKbmV0 bWFwOiBsb2FkZWQgbW9kdWxlClthdGhfaGFsXSBsb2FkZWQKbW9kdWxlX3JlZ2lzdGVyX2luaXQ6 IE1PRF9MT0FEICh2ZXNhLCAweGZmZmZmZmZmODBmOTVjMjAsIDApIGVycm9yIDE5CmtiZDEgYXQg a2JkbXV4MApuZXh1czAKdnR2Z2EwOiA8VlQgVkdBIGRyaXZlcj4gb24gbW90aGVyYm9hcmQKY3J5 cHRvc29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiA8SU5URUwg NDQwQlg+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpocGV0MDog PEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYg b24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5 IDk1MApjcHUwOiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDAgb24gYWNwaTAKY3B1MTogPEFDUEkg Q1BVPiBudW1hLWRvbWFpbiA1IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4g NSBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDUgb24gYWNwaTAKY3B1NDog PEFDUEkgQ1BVPiBudW1hLWRvbWFpbiA1IG9uIGFjcGkwCmNwdTU6IDxBQ1BJIENQVT4gbnVtYS1k b21haW4gNSBvbiBhY3BpMApjcHU2OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDUgb24gYWNwaTAK Y3B1NzogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiA1IG9uIGFjcGkwCmNwdTg6IDxBQ1BJIENQVT4g bnVtYS1kb21haW4gNSBvbiBhY3BpMApjcHU5OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDUgb24g YWNwaTAKY3B1MTA6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gNSBvbiBhY3BpMApjcHUxMTogPEFD UEkgQ1BVPiBudW1hLWRvbWFpbiA0IG9uIGFjcGkwCmNwdTEyOiA8QUNQSSBDUFU+IG51bWEtZG9t YWluIDQgb24gYWNwaTAKY3B1MTM6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gNCBvbiBhY3BpMApj cHUxNDogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiA0IG9uIGFjcGkwCmNwdTE1OiA8QUNQSSBDUFU+ IG51bWEtZG9tYWluIDQgb24gYWNwaTAKY3B1MTY6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gNCBv biBhY3BpMApjcHUxNzogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiA0IG9uIGFjcGkwCmNwdTE4OiA8 QUNQSSBDUFU+IG51bWEtZG9tYWluIDQgb24gYWNwaTAKY3B1MTk6IDxBQ1BJIENQVT4gbnVtYS1k b21haW4gNCBvbiBhY3BpMApjcHUyMDogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiA0IG9uIGFjcGkw CmNwdTIxOiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDMgb24gYWNwaTAKY3B1MjI6IDxBQ1BJIENQ VT4gbnVtYS1kb21haW4gMyBvbiBhY3BpMApjcHUyMzogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAz IG9uIGFjcGkwCmNwdTI0OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDMgb24gYWNwaTAKY3B1MjU6 IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMyBvbiBhY3BpMApjcHUyNjogPEFDUEkgQ1BVPiBudW1h LWRvbWFpbiAzIG9uIGFjcGkwCmNwdTI3OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDMgb24gYWNw aTAKY3B1Mjg6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMyBvbiBhY3BpMApjcHUyOTogPEFDUEkg Q1BVPiBudW1hLWRvbWFpbiAzIG9uIGFjcGkwCmNwdTMwOiA8QUNQSSBDUFU+IG51bWEtZG9tYWlu IDMgb24gYWNwaTAKY3B1MzE6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMiBvbiBhY3BpMApjcHUz MjogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAyIG9uIGFjcGkwCmNwdTMzOiA8QUNQSSBDUFU+IG51 bWEtZG9tYWluIDIgb24gYWNwaTAKY3B1MzQ6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMiBvbiBh Y3BpMApjcHUzNTogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAyIG9uIGFjcGkwCmNwdTM2OiA8QUNQ SSBDUFU+IG51bWEtZG9tYWluIDIgb24gYWNwaTAKY3B1Mzc6IDxBQ1BJIENQVT4gbnVtYS1kb21h aW4gMiBvbiBhY3BpMApjcHUzODogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAyIG9uIGFjcGkwCmNw dTM5OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDIgb24gYWNwaTAKY3B1NDA6IDxBQ1BJIENQVT4g bnVtYS1kb21haW4gMiBvbiBhY3BpMApjcHU0MTogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAxIG9u IGFjcGkwCmNwdTQyOiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDEgb24gYWNwaTAKY3B1NDM6IDxB Q1BJIENQVT4gbnVtYS1kb21haW4gMSBvbiBhY3BpMApjcHU0NDogPEFDUEkgQ1BVPiBudW1hLWRv bWFpbiAxIG9uIGFjcGkwCmNwdTQ1OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDEgb24gYWNwaTAK Y3B1NDY6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMSBvbiBhY3BpMApjcHU0NzogPEFDUEkgQ1BV PiBudW1hLWRvbWFpbiAxIG9uIGFjcGkwCmNwdTQ4OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDEg b24gYWNwaTAKY3B1NDk6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMSBvbiBhY3BpMApjcHU1MDog PEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAxIG9uIGFjcGkwCmNwdTUxOiA8QUNQSSBDUFU+IG51bWEt ZG9tYWluIDAgb24gYWNwaTAKY3B1NTI6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4gMCBvbiBhY3Bp MApjcHU1MzogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAwIG9uIGFjcGkwCmNwdTU0OiA8QUNQSSBD UFU+IG51bWEtZG9tYWluIDAgb24gYWNwaTAKY3B1NTU6IDxBQ1BJIENQVT4gbnVtYS1kb21haW4g MCBvbiBhY3BpMApjcHU1NjogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAwIG9uIGFjcGkwCmNwdTU3 OiA8QUNQSSBDUFU+IG51bWEtZG9tYWluIDAgb24gYWNwaTAKY3B1NTg6IDxBQ1BJIENQVT4gbnVt YS1kb21haW4gMCBvbiBhY3BpMApjcHU1OTogPEFDUEkgQ1BVPiBudW1hLWRvbWFpbiAwIG9uIGFj cGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAwIG9uIGFjcGkwClRp bWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkV2ZW50IHRp bWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAxMDAKYXRydGMwOiA8QVQg cmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCmF0cnRjMDogcmVn aXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrLCByZXNvbHV0aW9uIDEuMDAwMDAwcwpFdmVu dCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwClRpbWVjb3VudGVyICJB Q1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFjcGlfdGltZXIwOiA8 MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0weDEwMGIgb24gYWNwaTAK cGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApw Y2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQppc2Fi MDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+ IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJvbGxlcj4gcG9ydCAw eDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDEwNjAtMHgxMDZmIGF0IGRldmlj ZSA3LjEgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFwY2kw CmF0YTE6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBjaTAKcGNpMDogPGJyaWRn ZT4gYXQgZGV2aWNlIDcuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp2Z2FwY2kwOiA8VkdBLWNvbXBh dGlibGUgZGlzcGxheT4gcG9ydCAweDEwNzAtMHgxMDdmIG1lbSAweGU4MDAwMDAwLTB4ZWZmZmZm ZmYsMHhmZTAwMDAwMC0weGZlN2ZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMTUuMCBvbiBwY2kwCnZn YXBjaTA6IEJvb3QgdmlkZW8gZGV2aWNlCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDE3LjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2liMzog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMS4wIG9uIHBjaTAKcGNpYjM6IFtHSUFO VC1MT0NLRURdCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCm1wdDA6IDxMU0lMb2dpYyBT QVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4NDAwMC0weDQwZmYgbWVtIDB4ZmQ1ZWMwMDAtMHhmZDVl ZmZmZiwweGZkNWYwMDAwLTB4ZmQ1ZmZmZmYgaXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpMwpt cHQwOiBNUEkgVmVyc2lvbj0xLjUuMC4wCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDIxLjEgb24gcGNpMApwY2liNDogW0dJQU5ULUxPQ0tFRF0KcGNpYjU6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjEuMiBvbiBwY2kwCnBjaWI1OiBbR0lBTlQtTE9DS0VE XQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMS4zIG9uIHBjaTAKcGNp YjY6IFtHSUFOVC1MT0NLRURdCnBjaWI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDIxLjQgb24gcGNpMApwY2liNzogW0dJQU5ULUxPQ0tFRF0KcGNpYjg6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMjEuNSBvbiBwY2kwCnBjaWI4OiBbR0lBTlQtTE9DS0VEXQpwY2li OTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMS42IG9uIHBjaTAKcGNpYjk6IFtH SUFOVC1MT0NLRURdCnBjaWIxMDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMS43 IG9uIHBjaTAKcGNpYjEwOiBbR0lBTlQtTE9DS0VEXQpwY2liMTE6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMjIuMCBvbiBwY2kwCnBjaWIxMTogW0dJQU5ULUxPQ0tFRF0KcGNpNDog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjExCnZteDA6IDxWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBB ZGFwdGVyPiBwb3J0IDB4NTAwMC0weDUwMGYgbWVtIDB4ZmQ0ZmMwMDAtMHhmZDRmY2ZmZiwweGZk NGZkMDAwLTB4ZmQ0ZmRmZmYsMHhmZDRmZTAwMC0weGZkNGZmZmZmIGlycSAxOSBhdCBkZXZpY2Ug MC4wIG9uIHBjaTQKdm14MDogRXRoZXJuZXQgYWRkcmVzczogMDA6NTA6NTY6OTA6MGU6NTEKcGNp YjEyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIyLjEgb24gcGNpMApwY2liMTI6 IFtHSUFOVC1MT0NLRURdCnBjaWIxMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy Mi4yIG9uIHBjaTAKcGNpYjEzOiBbR0lBTlQtTE9DS0VEXQpwY2liMTQ6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMjIuMyBvbiBwY2kwCnBjaWIxNDogW0dJQU5ULUxPQ0tFRF0KcGNp YjE1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIyLjQgb24gcGNpMApwY2liMTU6 IFtHSUFOVC1MT0NLRURdCnBjaWIxNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy Mi41IG9uIHBjaTAKcGNpYjE2OiBbR0lBTlQtTE9DS0VEXQpwY2liMTc6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMjIuNiBvbiBwY2kwCnBjaWIxNzogW0dJQU5ULUxPQ0tFRF0KcGNp YjE4OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIyLjcgb24gcGNpMApwY2liMTg6 IFtHSUFOVC1MT0NLRURdCnBjaWIxOTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy My4wIG9uIHBjaTAKcGNpYjE5OiBbR0lBTlQtTE9DS0VEXQpwY2k1OiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMTkKdm14MTogPFZNd2FyZSBWTVhORVQzIEV0aGVybmV0IEFkYXB0ZXI+IHBvcnQgMHg2 MDAwLTB4NjAwZiBtZW0gMHhmZDNmYzAwMC0weGZkM2ZjZmZmLDB4ZmQzZmQwMDAtMHhmZDNmZGZm ZiwweGZkM2ZlMDAwLTB4ZmQzZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpNQp2bXgx OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDo1MDo1Njo5MDpjYjo0MQpwY2liMjA6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjMuMSBvbiBwY2kwCnBjaWIyMDogW0dJQU5ULUxPQ0tFRF0K cGNpYjIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIzLjIgb24gcGNpMApwY2li MjE6IFtHSUFOVC1MT0NLRURdCnBjaWIyMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyMy4zIG9uIHBjaTAKcGNpYjIyOiBbR0lBTlQtTE9DS0VEXQpwY2liMjM6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjMuNCBvbiBwY2kwCnBjaWIyMzogW0dJQU5ULUxPQ0tFRF0K cGNpYjI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIzLjUgb24gcGNpMApwY2li MjQ6IFtHSUFOVC1MT0NLRURdCnBjaWIyNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyMy42IG9uIHBjaTAKcGNpYjI1OiBbR0lBTlQtTE9DS0VEXQpwY2liMjY6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjMuNyBvbiBwY2kwCnBjaWIyNjogW0dJQU5ULUxPQ0tFRF0K cGNpYjI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI0LjAgb24gcGNpMApwY2li Mjc6IFtHSUFOVC1MT0NLRURdCnBjaWIyODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyNC4xIG9uIHBjaTAKcGNpYjI4OiBbR0lBTlQtTE9DS0VEXQpwY2liMjk6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjQuMiBvbiBwY2kwCnBjaWIyOTogW0dJQU5ULUxPQ0tFRF0K cGNpYjMwOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI0LjMgb24gcGNpMApwY2li MzA6IFtHSUFOVC1MT0NLRURdCnBjaWIzMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyNC40IG9uIHBjaTAKcGNpYjMxOiBbR0lBTlQtTE9DS0VEXQpwY2liMzI6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjQuNSBvbiBwY2kwCnBjaWIzMjogW0dJQU5ULUxPQ0tFRF0K cGNpYjMzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI0LjYgb24gcGNpMApwY2li MzM6IFtHSUFOVC1MT0NLRURdCnBjaWIzNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmlj ZSAyNC43IG9uIHBjaTAKcGNpYjM0OiBbR0lBTlQtTE9DS0VEXQphY3BpX2FjYWQwOiA8QUMgQWRh cHRlcj4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9y dCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9u IGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMv MiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9k ZWwgSW50ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMwphY3BpX3N5c2NvbnRhaW5lcjA6IDxTeXN0ZW0g Q29udGFpbmVyPiBvbiBhY3BpMApmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQg MHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmQwOiA8MTQ0MC1LQiAzLjUi IGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAKb3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0g MHhjMDAwMC0weGM3ZmZmLDB4YzgwMDAtMHhjOWZmZiwweGNhMDAwLTB4Y2FmZmYsMHhjYjAwMC0w eGNiZmZmLDB4ZGMwMDAtMHhkZmZmZiwweGUwMDAwLTB4ZTdmZmYgb24gaXNhMAp2Z2EwOiA8R2Vu ZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBv biBpc2EwClpGUyBmaWxlc3lzdGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9u OiBmZWF0dXJlcyBzdXBwb3J0ICg1MDAwKQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAg bXNlYwp1c2JfbmVlZHNfZXhwbG9yZV9hbGw6IG5vIGRldmNsYXNzCmRhMCBhdCBtcHQwIGJ1cyAw IHNjYnVzMiB0YXJnZXQgMCBsdW4gMApkYTA6IDxWTXdhcmUgVmlydHVhbCBkaXNrIDEuMD4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlCmRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJz CmRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMDogNDA5NjAwTUIgKDgzODg2MDgwMCA1 MTIgYnl0ZSBzZWN0b3JzKQpkYTA6IHF1aXJrcz0weDE0MDxSRVRSWV9CVVNZLFNUUklDVF9VTk1B UD4KZGExIGF0IG1wdDAgYnVzIDAgc2NidXMyIHRhcmdldCAxIGx1biAwCmRhMTogPFZNd2FyZSBW aXJ0dWFsIGRpc2sgMS4wPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UKZGExOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGExOiAx MzEwNzJNQiAoMjY4NDM1NDU2IDUxMiBieXRlIHNlY3RvcnMpCmRhMTogcXVpcmtzPTB4MTQwPFJF VFJZX0JVU1ksU1RSSUNUX1VOTUFQPgpjZDAgYXQgYXRhMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAg bHVuIDAKY2QwOiA8TkVDVk1XYXIgVk13YXJlIElERSBDRFIxMCAxLjAwPiBSZW1vdmFibGUgQ0Qt Uk9NIFNDU0kgZGV2aWNlCmNkMDogU2VyaWFsIE51bWJlciAxMDAwMDAwMDAwMDAwMDAwMDAwMQpj ZDA6IDMzLjMwME1CL3MgdHJhbnNmZXJzIChVRE1BMiwgQVRBUEkgMTJieXRlcywgUElPIDY1NTM0 Ynl0ZXMpCmNkMDogQXR0ZW1wdApjZDA6IHF1aXJrcz0weDQwPFJFVFJZX0JVU1k+CldBUk5JTkc6 IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpUcnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp6cm9vdC9ST09UL2RlZmF1bHQgW10uLi4KVk13YXJl IG1lbW9yeSBjb250cm9sIGRyaXZlciBpbml0aWFsaXplZAp2bXgwOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVAKdm14MTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmxvY2sgb3JkZXIgcmV2ZXJz YWw6CiAxc3QgMHhmZmZmZjgwMWViOGVjN2M4IHpmcyAoemZzKSBAIC91c3Ivc3JjL3N5cy9rZXJu L3Zmc19tb3VudC5jOjg1MgogMm5kIDB4ZmZmZmY4MDFjNDk2OTlhMCBkZXZmcyAoZGV2ZnMpIEAg L3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyNjA2CnN0YWNrIGJhY2t0cmFjZToKIzAgMHhm ZmZmZmZmZjgwYWNmOTMzIGF0IHdpdG5lc3NfZGVidWdnZXIrMHg3MwojMSAweGZmZmZmZmZmODBh Y2Y3YjIgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4ZTAyCiMyIDB4ZmZmZmZmZmY4MGE0MWFiZSBh dCBsb2NrbWdyX2xvY2tfZmFzdF9wYXRoKzB4MWFlCiMzIDB4ZmZmZmZmZmY4MTA5NDMwOSBhdCBW T1BfTE9DSzFfQVBWKzB4ZDkKIzQgMHhmZmZmZmZmZjgwYjRhYjY2IGF0IF92bl9sb2NrKzB4NjYK IzUgMHhmZmZmZmZmZjgwYjM5NWQyIGF0IHZnZXQrMHg4MgojNiAweGZmZmZmZmZmODA5MzZmZGQg YXQgZGV2ZnNfYWxsb2N2KzB4Y2QKIzcgMHhmZmZmZmZmZjgwOTM2YWUzIGF0IGRldmZzX3Jvb3Qr MHg0MwojOCAweGZmZmZmZmZmODBiMzAxNDQgYXQgdmZzX2Rvbm1vdW50KzB4MTFmNAojOSAweGZm ZmZmZmZmODBiMmVmMjIgYXQgc3lzX25tb3VudCsweDcyCiMxMCAweGZmZmZmZmZmODBmMTZkMmIg YXQgYW1kNjRfc3lzY2FsbCsweDc5YgojMTEgMHhmZmZmZmZmZjgwZWY1YWFiIGF0IFhmYXN0X3N5 c2NhbGwrMHhmYgpsb2NrIG9yZGVyIHJldmVyc2FsOgogMXN0IDB4ZmZmZmY4MDNiN2QyMzVmMCBz eW5jZXIgKHN5bmNlcikgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIxNTYKIDJuZCAw eGZmZmZmODAyZGJmODgyNDAgemZzICh6ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIu YzoyNjA2CnN0YWNrIGJhY2t0cmFjZToKIzAgMHhmZmZmZmZmZjgwYWNmOTMzIGF0IHdpdG5lc3Nf ZGVidWdnZXIrMHg3MwojMSAweGZmZmZmZmZmODBhY2Y3YjIgYXQgd2l0bmVzc19jaGVja29yZGVy KzB4ZTAyCiMyIDB4ZmZmZmZmZmY4MGE0MWFiZSBhdCBsb2NrbWdyX2xvY2tfZmFzdF9wYXRoKzB4 MWFlCiMzIDB4ZmZmZmZmZmY4MTA5NDMwOSBhdCBWT1BfTE9DSzFfQVBWKzB4ZDkKIzQgMHhmZmZm ZmZmZjgwYjRhYjY2IGF0IF92bl9sb2NrKzB4NjYKIzUgMHhmZmZmZmZmZjgwYjM5NWQyIGF0IHZn ZXQrMHg4MgojNiAweGZmZmZmZmZmODBiM2I2NTYgYXQgdmZzX21zeW5jKzB4YTYKIzcgMHhmZmZm ZmZmZjgwYjQwMzY2IGF0IHN5bmNfZnN5bmMrMHhjNgojOCAweGZmZmZmZmZmODEwOTMyNzkgYXQg Vk9QX0ZTWU5DX0FQVisweGQ5CiM5IDB4ZmZmZmZmZmY4MGIzZTMxNCBhdCBzY2hlZF9zeW5jKzB4 M2M0CiMxMCAweGZmZmZmZmZmODBhMmQ1ODQgYXQgZm9ya19leGl0KzB4ODQKIzExIDB4ZmZmZmZm ZmY4MGVmNWQzZSBhdCBmb3JrX3RyYW1wb2xpbmUrMHhlCmxvY2sgb3JkZXIgcmV2ZXJzYWw6CiAx c3QgMHhmZmZmZjgxNTQzNTRiOGUwIGZpbGVkZXNjIHN0cnVjdHVyZSAoZmlsZWRlc2Mgc3RydWN0 dXJlKSBAIC91c3Ivc3JjL3N5cy9rZXJuL3N5c19nZW5lcmljLmM6MTU2NQogMm5kIDB4ZmZmZmY4 MDM3YzQwNjQxOCBkZXZmcyAoZGV2ZnMpIEAgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3BzLmM6 MTUyNApzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MGFjZjkzMyBhdCB3aXRuZXNzX2Rl YnVnZ2VyKzB4NzMKIzEgMHhmZmZmZmZmZjgwYWNmN2IyIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisw eGUwMgojMiAweGZmZmZmZmZmODBhNDFhYmUgYXQgbG9ja21ncl9sb2NrX2Zhc3RfcGF0aCsweDFh ZQojMyAweGZmZmZmZmZmODEwOTQzMDkgYXQgVk9QX0xPQ0sxX0FQVisweGQ5CiM0IDB4ZmZmZmZm ZmY4MGI0YWI2NiBhdCBfdm5fbG9jaysweDY2CiM1IDB4ZmZmZmZmZmY4MGI0OTk2YiBhdCB2bl9w b2xsKzB4M2IKIzYgMHhmZmZmZmZmZjgwOTNhMjdkIGF0IGRldmZzX3BvbGxfZisweGNkCiM3IDB4 ZmZmZmZmZmY4MGFkNjhkNSBhdCBrZXJuX3BvbGwrMHgzODUKIzggMHhmZmZmZmZmZjgwYWQ2NTQw IGF0IHN5c19wb2xsKzB4NTAKIzkgMHhmZmZmZmZmZjgwZjE2ZDJiIGF0IGFtZDY0X3N5c2NhbGwr MHg3OWIKIzEwIDB4ZmZmZmZmZmY4MGVmNWFhYiBhdCBYZmFzdF9zeXNjYWxsKzB4ZmIKd2l0bmVz c19sb2NrX2xpc3RfZ2V0OiB3aXRuZXNzIGV4aGF1c3RlZAo= --=_59860c679f9477fadac6373721f3fcd1-- From owner-freebsd-current@freebsd.org Tue Nov 28 23:17:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8C58DF1C03; Tue, 28 Nov 2017 23:17:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0048.outbound.protection.outlook.com [104.47.38.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68AF77CF6B; Tue, 28 Nov 2017 23:17:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2171.CANPRD01.PROD.OUTLOOK.COM (52.132.46.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 23:17:13 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 23:17:13 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" , Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPobgABJSsw= Date: Tue, 28 Nov 2017 23:17:13 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> , <20171128164132.290bf07218b16164db613242@bidouilliste.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2171; 6:M1ZckBEATmcErrjwqZv99OTOb+074e4lV++P1f5Rar2Mg+IDfMb9l2yW435gJ6tfeVymd+kX67Mv0NSGiFqcB2CfXhQTJBp+7DaCt5wA8sT0iPuzx+6HuT+zQBQLQyfpBlI/lCL3IqXp/d0bWz8ktEXkfpUz3agz4cwZ4x9N6C7EAp2kfDMffMGBqInlPgf8DNhIDw5Rp6OCPlerWIC5AYy1Bmdtpy2itdNBtprEagmLEf2KSVdJm9m254i3zloixuOo4njyj6HrSE8FnFyS+bbGrFAsPqU5YOdesM9LiS7NWD/2AnsbzI9ip6YeRaLCAG45q9azOJioH/bkU94y1rUXHam5iYUNCHtguGyrYGI=; 5:Y0E6MhBF4B2ebz6+I0YlLx4SdzWz5hOUY0YtAI+bLpVtYifWlG56ttoqkst4yVhP/PrAxFlnwMmfH+xM6d17QqAEkf9YT0hwjfAMLN5nXh6tIeF/U/e2yPJ2GqMgZi/WXG/7jq6PSQzit0tfDkkHis18B+T3C/yChiwhhnSvEgw=; 24:yHrycrDN0C/yibGarjiS7wna39fVmVHnqa4yHyy+r1h1ivspyVgURUEVlvtwB0TkYaKtuUv/xGv9Sg/GXXQ+LPhEyut4vI92De6vm92bpbk=; 7:AjZ0KRU4FvAwpe2ZaIFnWV8jwxWvvIA+0PkgHFL15QUoUMm02KL1ratazp1IJhfGr98bhUOsHnwv3nC+71k7XBAzAnBr15o9MP4hPVJxCZLJdlp2Tv22Ai6N38Hw3ywg6UpNXN2a2UsPT3hNqStgB50EDZFBLZxJ36V5EPvBtZF137ti0L0ChyI0NjoSrnnc30CLzfK3OZt7U4IftRDaSZUcuUPo8Fav79/0+4aeksX7Kq/RhsxmcT9g2H/wXhoX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 412b0a5f-9dd5-4b57-e7d9-08d536b628c7 x-microsoft-antispam: UriScan:(18154293887054); BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603261); SRVR:YTOPR0101MB2171; x-ms-traffictypediagnostic: YTOPR0101MB2171: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18154293887054); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:YTOPR0101MB2171; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2171; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(366004)(24454002)(189002)(199003)(5890100001)(25786009)(316002)(786003)(76176999)(5250100002)(189998001)(478600001)(86362001)(55016002)(54906003)(53546010)(68736007)(2940100002)(4326008)(3280700002)(8676002)(97736004)(7696005)(74316002)(305945005)(81156014)(81166006)(9686003)(3660700001)(5660300001)(2950100002)(14454004)(6916009)(105586002)(2900100001)(93886005)(39060400002)(2906002)(33656002)(8936002)(106356001)(229853002)(74482002)(102836003)(54356999)(99286004)(6246003)(53936002)(6436002)(101416001)(50986999)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2171; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 412b0a5f-9dd5-4b57-e7d9-08d536b628c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 23:17:13.7368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2171 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 23:17:17 -0000 I think the attached patch should fix your performance problem. It simply checks for nfsrv_delegatecnt !=3D 0 before doing all the locking stuff in nfsrv_checkgetattr(). If this fixes your performance problem (with delegations disabled), I'll probably add a separate counter for write delegations and use atomics to increment/decrement it so that it is SMP safe without acquiring any lock. If you can test this, please let me know how it goes? rick ________________________________________ From: Rick Macklem Sent: Tuesday, November 28, 2017 2:09:51 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org; Rick Mack= lem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Emmanuel Vadot wrote: >I wrote: >> Since it defaults to "disabled", I don't see why a tunable would be nece= ssary? >> (Just do nothing and delegations don't happen. If you want the server >> to issue delegations, then use the sysctl to turn them on. If you want = to turn >> them off again at the server, reboot the server without setting the sys= ctl.) > >If you need to reboot to make things working again without delegation >this shouldn't be a sysctl. Turning them off without rebooting doesn't break anything. I just wrote it that way since you seemed to want to use a tunable, which implied rebooting was your preference. > > > > The reason behind it is recent problem at work on some on our file= r > > > > related to NFS. > > > > We use NFSv4 without delegation as we never been able to have good > > > > performance with FreeBSD server and Linux client (we need to do tes= t > > > > again but that's for later). > Delegations are almost never useful, especially with Linux clients. Emmanuel Vadot wrote: >Can you elaborate ? Reading what delegation are I see that this is >exactly what I'm looking for to have better performance with NFS for my >workload (I only have one client per mount point). Delegations allow the client to do Opens locally without contacting the server. Unless, the delegation is a write delegation, this only applied to read-only delegations. Also, since most implementors couldn`t agree on how to check permissions via the delegation, most client implementations still do an Access check at open, which is almost as much overhead as the Open RPC. (For example, Solaris servers always specified an empty ACE in th= e delegation, forcing the client to do an Access. I have no idea what the current Linux server=E9client does. If you capture packets when a Linux client is mounted with delegations enabled, you could look for RPCs like Ac= cess when are Opened multiple times. If you see them, then delegations aren`t saving = RPCs. Also, they are `per file`, so are only useful if the client is Opening the same file multiple times. Further, if another client Opens the same file and the first client got a W= rite delegation, then the write delegation must be recalled, which is a lot of overhead and one of the few cases where the FreeBSD server must exclusively lock the state lists, forcing all other RPCs related to Open, Close to wait= . They sounded good in theory and might have worked well if the implementors had agreed to do them, but that didn=E8t happen. (Companies pay for servers= , but the clients don=E8t get funded so delegation support in the clients are lacking= . I tried to make them useful in the FreeBSD client, but I=E8m not sure I succeeded.) > [stuff snipped] If I understood your original post, you have a performance problem caused by lock contention, where the server grabs the state lock to check for dele= gations for every Getattr from a client. As below, I think the fix is to add code to check for no delegations issued= that does not require acquisition of the state lock. Btw, large numbers of Getattrs will not perform well with delegations. (Again, the client should be able to do Getattr operations locally in the client when it has a delegation for the file, but if the client is not doi= ng that...) I wrote: > > Having a per-mount version of this would be overkill, I think. It would h= ave to > disable callbacks on the mount point, since there is no way for a client = to say > "don't give me delegations" except disabling callbacks, which the server > requires for delegation issue. > [stuff snipped] > The case where there has never been delegations issued will result in an > empty delegation queue. Maybe this case can be handled without acquiring > the "global NFSv4 state lock", which is what sounds like is causing the > performance issue. Maybe a global counter of how many delegations are > issued that is handled by atomic ops. > --> If it is 0, nfsrv_checkgetattr() can just return without acquiring th= e lock. > > I'll take a look at this, rick > rick From owner-freebsd-current@freebsd.org Tue Nov 28 23:19:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7830DF1DDE; Tue, 28 Nov 2017 23:19:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0042.outbound.protection.outlook.com [104.47.32.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3927D29F; Tue, 28 Nov 2017 23:19:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2171.CANPRD01.PROD.OUTLOOK.COM (52.132.46.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 23:18:59 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 23:18:57 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" , Rick Macklem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPobgABJSsyAAAEe3g== Date: Tue, 28 Nov 2017 23:18:57 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> , <20171128164132.290bf07218b16164db613242@bidouilliste.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2171; 6:kqoz5f9CHPgWAMFJyzcl5A+3GStgDFV9rEe/BdspUneWbRWr0anaEe0jbBs+x5q42dfA+8ozUockrgnf0aY9t0CV4+fC5vDwuRCdOedY13mPjOlVOWiFQma/g2dgHKuWoUjiFtbbB6uFtn7RVaQsuDAGjIH3Lv19PB5wVnksA0BHYCS5/VMFDrRZQuVteBQvmndLhHXil0kRclf0xQlly7VQ6CyrJY7xvMEuhoXXTmACYEpRldwiw/7rMNe2mtiZ72Ii6+vqZLuV7Cx9+knmQx7FJaXGegLvFjHjubqhAO1y166VfzPVUktdvfCwGiZX2dOaO0CtRNwtFScuqryw/v3TQeATAf01iCipdVYk5Ro=; 5:5bhncfadejoejFRnow/FMLCpNU1kwpQOObVCN5YW5WTuiQHRL9q7Kf58GjVCdmRGrsAI/ytbCChN+EK4qvA35pJJY0hO1FofVwsrKnPfqRe5nBT2K2UJUAQMCheMyaP1fs2BkrzlUnTjkH/XThll25qLpKbxdD/tssPv27zDy2I=; 24:Y87QWcn6vYx6tq9E22giMehLFRK0CAhEjaZ+JUIdgeMqqcxDZ6NVVPuXxuR9p1ml6/iLNHJN11dTnXBGuCXOv5vXRAI+ePB9NTEmUYf97IQ=; 7:VjQ2K4+zpyTuKWX3frij7Xd0ZGy7j/S84j78cDweaWoaByddLojaWPlKJx8WMcsaMBSenQAwfVRZHHKflyEYXX6XH3tFLJg9bKa0UBuwx89Bkt1J4xhLeNj5PMZha2QRRAa5M8M7O+QK16ZR5R3nuSpspfllk7QWj2HBr0hiISuwWEtowszf3q0uFe+P2+1wMuXkPHtAQwBMzOPQi96scH71E6FR0I9V83odKzT8onGLIv8RDRlnk/8909IcqOdf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 59445177-2c8c-4f87-b52a-08d536b666bb x-microsoft-antispam: UriScan:(18154293887054); BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603261)(49563074); SRVR:YTOPR0101MB2171; x-ms-traffictypediagnostic: YTOPR0101MB2171: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18154293887054); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:YTOPR0101MB2171; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2171; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(366004)(24454002)(189002)(199003)(5890100001)(25786009)(316002)(786003)(76176999)(5250100002)(189998001)(478600001)(86362001)(55016002)(54906003)(53546010)(68736007)(2940100002)(4326008)(3280700002)(8676002)(97736004)(7696005)(74316002)(305945005)(81156014)(81166006)(9686003)(3660700001)(5660300001)(2950100002)(14454004)(6916009)(105586002)(2900100001)(93886005)(39060400002)(2906002)(33656002)(8936002)(106356001)(229853002)(74482002)(102836003)(54356999)(99936001)(99286004)(6246003)(53936002)(6436002)(101416001)(50986999)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2171; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTOPR0101MB21721E82EF605249D38064A1DD3A0YTOPR0101MB2172_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 59445177-2c8c-4f87-b52a-08d536b666bb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 23:18:57.7537 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2171 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Nov 2017 23:19:02 -0000 --_002_YTOPR0101MB21721E82EF605249D38064A1DD3A0YTOPR0101MB2172_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Did my usual and forgot to attach it. Here's the patch, rick ________________________________________ From: Rick Macklem Sent: Tuesday, November 28, 2017 6:17:13 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org; Rick Mack= lem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? I think the attached patch should fix your performance problem. It simply checks for nfsrv_delegatecnt !=3D 0 before doing all the locking stuff in nfsrv_checkgetattr(). If this fixes your performance problem (with delegations disabled), I'll probably add a separate counter for write delegations and use atomics to increment/decrement it so that it is SMP safe without acquiring any lock. If you can test this, please let me know how it goes? rick ________________________________________ From: Rick Macklem Sent: Tuesday, November 28, 2017 2:09:51 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org; Rick Mack= lem Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Emmanuel Vadot wrote: >I wrote: >> Since it defaults to "disabled", I don't see why a tunable would be nece= ssary? >> (Just do nothing and delegations don't happen. If you want the server >> to issue delegations, then use the sysctl to turn them on. If you want = to turn >> them off again at the server, reboot the server without setting the sys= ctl.) > >If you need to reboot to make things working again without delegation >this shouldn't be a sysctl. Turning them off without rebooting doesn't break anything. I just wrote it that way since you seemed to want to use a tunable, which implied rebooting was your preference. > > > > The reason behind it is recent problem at work on some on our file= r > > > > related to NFS. > > > > We use NFSv4 without delegation as we never been able to have good > > > > performance with FreeBSD server and Linux client (we need to do tes= t > > > > again but that's for later). > Delegations are almost never useful, especially with Linux clients. Emmanuel Vadot wrote: >Can you elaborate ? Reading what delegation are I see that this is >exactly what I'm looking for to have better performance with NFS for my >workload (I only have one client per mount point). Delegations allow the client to do Opens locally without contacting the server. Unless, the delegation is a write delegation, this only applied to read-only delegations. Also, since most implementors couldn`t agree on how to check permissions via the delegation, most client implementations still do an Access check at open, which is almost as much overhead as the Open RPC. (For example, Solaris servers always specified an empty ACE in th= e delegation, forcing the client to do an Access. I have no idea what the current Linux server=E9client does. If you capture packets when a Linux client is mounted with delegations enabled, you could look for RPCs like Ac= cess when are Opened multiple times. If you see them, then delegations aren`t saving = RPCs. Also, they are `per file`, so are only useful if the client is Opening the same file multiple times. Further, if another client Opens the same file and the first client got a W= rite delegation, then the write delegation must be recalled, which is a lot of overhead and one of the few cases where the FreeBSD server must exclusively lock the state lists, forcing all other RPCs related to Open, Close to wait= . They sounded good in theory and might have worked well if the implementors had agreed to do them, but that didn=E8t happen. (Companies pay for servers= , but the clients don=E8t get funded so delegation support in the clients are lacking= . I tried to make them useful in the FreeBSD client, but I=E8m not sure I succeeded.) > [stuff snipped] If I understood your original post, you have a performance problem caused by lock contention, where the server grabs the state lock to check for dele= gations for every Getattr from a client. As below, I think the fix is to add code to check for no delegations issued= that does not require acquisition of the state lock. Btw, large numbers of Getattrs will not perform well with delegations. (Again, the client should be able to do Getattr operations locally in the client when it has a delegation for the file, but if the client is not doi= ng that...) I wrote: > > Having a per-mount version of this would be overkill, I think. It would h= ave to > disable callbacks on the mount point, since there is no way for a client = to say > "don't give me delegations" except disabling callbacks, which the server > requires for delegation issue. > [stuff snipped] > The case where there has never been delegations issued will result in an > empty delegation queue. Maybe this case can be handled without acquiring > the "global NFSv4 state lock", which is what sounds like is causing the > performance issue. Maybe a global counter of how many delegations are > issued that is handled by atomic ops. > --> If it is 0, nfsrv_checkgetattr() can just return without acquiring th= e lock. > > I'll take a look at this, rick > rick --_002_YTOPR0101MB21721E82EF605249D38064A1DD3A0YTOPR0101MB2172_ Content-Type: application/octet-stream; name="checkgetattr.patch" Content-Description: checkgetattr.patch Content-Disposition: attachment; filename="checkgetattr.patch"; size=393; creation-date="Tue, 28 Nov 2017 23:18:53 GMT"; modification-date="Tue, 28 Nov 2017 23:18:53 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHN0YXRlLmMuc2F2CTIwMTctMTEtMjggMDk6NTY6Mjcu NzA4NTk5MDAwIC0wNTAwCisrKyBmcy9uZnNzZXJ2ZXIvbmZzX25mc2RzdGF0ZS5jCTIwMTctMTEt MjggMDk6NTc6MzEuMTEzMTYzMDAwIC0wNTAwCkBAIC01Mjk4LDcgKzUyOTgsNyBAQCBuZnNydl9j aGVja2dldGF0dHIoc3RydWN0IG5mc3J2X2Rlc2NyaXB0CiAJdV9xdWFkX3QgZGVsZWdmaWxlcmV2 OwogCiAJTkZTQ0JHRVRBVFRSX0FUVFJCSVQoYXR0cmJpdHAsICZjYmJpdHMpOwotCWlmICghTkZT Tk9OWkVST19BVFRSQklUKCZjYmJpdHMpKQorCWlmICghTkZTTk9OWkVST19BVFRSQklUKCZjYmJp dHMpIHx8IG5mc3J2X2RlbGVnYXRlY250ID09IDApCiAJCWdvdG8gb3V0OwogCiAJLyoK --_002_YTOPR0101MB21721E82EF605249D38064A1DD3A0YTOPR0101MB2172_-- From owner-freebsd-current@freebsd.org Wed Nov 29 11:56:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 261A6E512D9 for ; Wed, 29 Nov 2017 11:56:44 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 84A6F71035 for ; Wed, 29 Nov 2017 11:56:42 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([78.52.117.12]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MId0S-1eHp7a3Mme-002GH7 for ; Wed, 29 Nov 2017 12:56:34 +0100 Date: Wed, 29 Nov 2017 12:56:33 +0100 From: "Hartmann, O." To: FreeBSD CURRENT Subject: CURRENT: kernel crash r326347: Cannot access memory at address 0x65657246 Message-ID: <20171129125628.42aa4c99@hermann> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nxVJbmND4PVqdNSblc5C9sO00iJJpvUj+p0HQOwks9dg3P3ST1X NQAuNkILciNiLBNDZa6iWofXUbF9zRdjiHyjC6cCUhfJkyNpPJc3oYh3HxK7HZdU0fOy9qT FNKr/Z8Xg6QCIAsl5/NsrjefToQln/JavDkLNLr88tt7J66EwDTmMBfY3dG0QPENGO3dzOb tcjSGGrFTboh6rOUZYx9A== X-UI-Out-Filterresults: notjunk:1;V01:K0:vudkYri214M=:5I1TTRIACAL3shNNSqkxTP 4c7+H92M27FoxM6KwctVAvTFD+8vddRRS+iCihSiEHXgkmNAvBsUitRGdSQzqdQwTP5T3miyM bELfq/SepqPI1HqeIuBaZOfAlN17Sfkvlh4D+06rx0V6Pv/0MHojpq0Fh7q7r863KbdKFFwau YUz+UBx+9oFwBrTmp41d/IafdzrDl21gOvqcZS+KakS4ZMBgKPUKooA0FFSos9ds3tPArpMx1 8WqSBMsOlfhW5SEM8Drp6i3V8L/YbDQVLFF9l+EPGMpQrY8whTtbwTUx5VIxkX38WPDOeF4Ig iF4mJY1jiDhhGI44UOvxJmzpQ7ZCTOhfMFmjIZq2PGL2QGtMCfg1ym9QBy92ZD7ILCo9ugFgU qCmDMZkS1N+UXufKbuSC4VKCqHROCro5auDP2htl+/+g7EVKboeCDynwlcGZ5ksK85BiANUyE OeDuyX3JgXYmgFMu5CjNfsgSaDAVeXlOtePbSMi2IjQxwQeD/DUd5ThEeiEIrjyZmaIlApbVW ra9DxizNE4hfu9qc+fANRxbtnbNuncA6xhZUAZKANnI538/MQbKJLZIYAc3V/ej4pZvKDzLmu RiIhxYRnn7jG1MXVQZetFr18G3FHoC0sEkqq8nws4fZZ4IQNFGelqJupV+vKdJWn/HWwiGvQ3 YDXxgT86CK1AxScvF4+Jp65l0nmMr71MlgM1IstUAdIwbiRhD4UCC2eB2Qwb+TVj9LK27dwam RtjFKRXn+pSg6jZnWeMD+Mise86BbpbUqJ8+kCeSt23ztndQNqn74g3ybpB0ixLDy89PlN2i7 i3i6b9hZ4TjXEDa86iqH/k0S1bBpWBPxBJXWQJV3RX90/9j1bkbNaUqHpLOwUHKG//YMyCw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Nov 2017 11:56:44 -0000 Since yesterday's CURRENT update, I face worse and nasty problems on all of our CURRENT systems! Most recent CURRENT, as with r326363, crashes on booting the kernel, in another case the kernel is stuck and freezing after initialising the USB subsystem (the last thing I see on screen, keyboard fully functional, but no ACPI shutdown any more). Another box is now two days in row after subsequent updates of CURRENT multiple times a day crashing on load on ZFS filesystem. The last known half-ways good kernel is 12.0-CURRENT #157 r326347: Wed Nov 29 01:02:47 CET 2017 amd64. When performing buildworld/buildkernel/relaese/package or poudriere on a ZFS filessystem, I can now bring down the system almost in a reproducable way. Last error seen when core is dumped is: /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 From owner-freebsd-current@freebsd.org Wed Nov 29 12:40:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 138B6E52F60 for ; Wed, 29 Nov 2017 12:40:28 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa02x.plala.or.jp (msa02.plala.or.jp [IPv6:2400:7800:0:5010::2]) by mx1.freebsd.org (Postfix) with ESMTP id 906947293A for ; Wed, 29 Nov 2017 12:40:27 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc01.plala.or.jp ([172.23.12.31]) by msa01y.plala.or.jp with ESMTP id <20171129123732.GERH9031.msa01y.plala.or.jp@msc01.plala.or.jp> for ; Wed, 29 Nov 2017 21:37:32 +0900 Received: from localhost ([126.74.209.183]) by msc01.plala.or.jp with ESMTP id <20171129123732.MNMV19170.msc01.plala.or.jp@localhost> for ; Wed, 29 Nov 2017 21:37:32 +0900 Date: Wed, 29 Nov 2017 21:37:25 +0900 (JST) Message-Id: <20171129.213725.810459586021929184.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: panic r326359 From: Masachika ISHIZUKA X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa01m; Wed, 29 Nov 2017 21:37:32 +0900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Nov 2017 12:40:28 -0000 After updating r326359, kernel panic has occure. ( I can boot up but panics within a few minutes.) It was good working up to r325887. # cat /var/crash/info.6 Dump header from device: /dev/gpt/fbswap Architecture: amd64 Architecture Version: 2 Dump Length: 505135104 Blocksize: 512 Compression: none Dumptime: Wed Nov 29 20:22:32 2017 Hostname: carrot.ish.org Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.0-CURRENT #2 r326359: Wed Nov 29 19:06:12 JST 2017 ishizuka@carrot.ish.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Panic String: Lock if_lagg rmlock not read locked @ /usr/src/sys/net/if_lagg.c:1655 Dump Parity: 971727379 Bounds: 6 Dump Status: good I put vmcore.6.bz2(157mb) in the following. https://www.ish.org/files/vmcore.6.bz2 -- Masachika ISHIZUKA From owner-freebsd-current@freebsd.org Wed Nov 29 13:40:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D55E5453B; Wed, 29 Nov 2017 13:40:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D9CB74AD0; Wed, 29 Nov 2017 13:40:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 579ada15; Wed, 29 Nov 2017 14:40:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=8XLQth92F4LHfNI9F26nkLXTVBs=; b=qi7wstgRGgxferEn32iV0FRs9YhR sTj/3n9wvtdRvpmEDVL9SZbFeDIAkvEIbFwGUr6O0TSPP77FnCUcPQ22lS8hnNEf kp5GckE0zSyWUmTiAP0Hkw1NAW/B1mstbKpdRtgAZd0IeZQTbIDX1cq5dqYDjQrl uPFEOZQOnKZAKWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=ncUxWbBPUsLkXbkIds6zwfKGdBJ6aKtKfLFk71u3wXkKARVrSoSjNo7C Ou5py8cV06zElfLrkTKnVvtXlfaiEL6qyz3SmYK+NEgdeRAHtV/jm7GYRcJtDIzo lqxnTGUVhjTon5S2zLl5S6jmOfmk/U8rUfKF0hG2ledeZDbWnGs= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 4f704a56 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 29 Nov 2017 14:40:41 +0100 (CET) Date: Wed, 29 Nov 2017 14:40:40 +0100 From: Emmanuel Vadot To: Rick Macklem Cc: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Message-Id: <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com> In-Reply-To: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> <20171128164132.290bf07218b16164db613242@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Nov 2017 13:40:51 -0000 Hello Rick, On Tue, 28 Nov 2017 23:18:57 +0000 Rick Macklem wrote: > Did my usual and forgot to attach it. Here's the patch, rick >=20 > ________________________________________ > From: Rick Macklem > Sent: Tuesday, November 28, 2017 6:17:13 PM > To: Emmanuel Vadot > Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org; Rick Ma= cklem > Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? >=20 > I think the attached patch should fix your performance problem. > It simply checks for nfsrv_delegatecnt !=3D 0 before doing all the > locking stuff in nfsrv_checkgetattr(). >=20 > If this fixes your performance problem (with delegations disabled), > I'll probably add a separate counter for write delegations and > use atomics to increment/decrement it so that it is SMP safe without > acquiring any lock. >=20 > If you can test this, please let me know how it goes? rick I haven't test by I can say that it will work, I actually wondered at first doing that. The problem with this patch is what I tried to describe in my first and following mails, since you can turn on and off delegation you can still have delegation (so nfsrv_delegatecnt > 0) even if the sysctl is =3D=3D 0. That's why I went to the tunable way, seems cleaner to me as disabling delegation doesn't really disable them for current client. > ________________________________________ > From: Rick Macklem > Sent: Tuesday, November 28, 2017 2:09:51 PM > To: Emmanuel Vadot > Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org; Rick Ma= cklem > Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? >=20 > Emmanuel Vadot wrote: > >I wrote: > >> Since it defaults to "disabled", I don't see why a tunable would be ne= cessary? > >> (Just do nothing and delegations don't happen. If you want the server > >> to issue delegations, then use the sysctl to turn them on. If you wan= t to turn > >> them off again at the server, reboot the server without setting the s= ysctl.) > > > >If you need to reboot to make things working again without delegation > >this shouldn't be a sysctl. > Turning them off without rebooting doesn't break anything. > I just wrote it that way since you seemed to want to use a tunable, which > implied rebooting was your preference. > > > > > The reason behind it is recent problem at work on some on our fi= ler > > > > > related to NFS. > > > > > We use NFSv4 without delegation as we never been able to have go= od > > > > > performance with FreeBSD server and Linux client (we need to do t= est > > > > > again but that's for later). > > Delegations are almost never useful, especially with Linux clients. > Emmanuel Vadot wrote: > >Can you elaborate ? Reading what delegation are I see that this is > >exactly what I'm looking for to have better performance with NFS for my > >workload (I only have one client per mount point). > Delegations allow the client to do Opens locally without contacting the > server. Unless, the delegation is a write delegation, this only applied > to read-only delegations. Also, since most implementors couldn`t agree > on how to check permissions via the delegation, most client implementatio= ns > still do an Access check at open, which is almost as much overhead as the > Open RPC. (For example, Solaris servers always specified an empty ACE in = the > delegation, forcing the client to do an Access. I have no idea what the > current Linux server=E9client does. If you capture packets when a Linux > client is mounted with delegations enabled, you could look for RPCs like = Access when > are Opened multiple times. If you see them, then delegations aren`t savin= g RPCs. > Also, they are `per file`, so are only useful if the client is Opening the > same file multiple times. > Further, if another client Opens the same file and the first client got a= Write > delegation, then the write delegation must be recalled, which is a lot of > overhead and one of the few cases where the FreeBSD server must exclusive= ly > lock the state lists, forcing all other RPCs related to Open, Close to wa= it. >=20 > They sounded good in theory and might have worked well if the implementors > had agreed to do them, but that didn=E8t happen. (Companies pay for serve= rs, but the > clients don=E8t get funded so delegation support in the clients are lacki= ng. I tried > to make them useful in the FreeBSD client, but I=E8m not sure I succeeded= .) >=20 > > [stuff snipped] > If I understood your original post, you have a performance problem caused > by lock contention, where the server grabs the state lock to check for de= legations > for every Getattr from a client. >=20 > As below, I think the fix is to add code to check for no delegations issu= ed that > does not require acquisition of the state lock. >=20 > Btw, large numbers of Getattrs will not perform well with delegations. > (Again, the client should be able to do Getattr operations locally in the > client when it has a delegation for the file, but if the client is not d= oing that...) >=20 > I wrote: > > > > Having a per-mount version of this would be overkill, I think. It would= have to > > disable callbacks on the mount point, since there is no way for a clien= t to say > > "don't give me delegations" except disabling callbacks, which the server > > requires for delegation issue. > > [stuff snipped] > > The case where there has never been delegations issued will result in an > > empty delegation queue. Maybe this case can be handled without acquiring > > the "global NFSv4 state lock", which is what sounds like is causing the > > performance issue. Maybe a global counter of how many delegations are > > issued that is handled by atomic ops. > > --> If it is 0, nfsrv_checkgetattr() can just return without acquiring = the lock. > > > > I'll take a look at this, rick > > > rick --=20 Emmanuel Vadot From owner-freebsd-current@freebsd.org Wed Nov 29 17:28:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A76FE5E968; Wed, 29 Nov 2017 17:28:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0078.outbound.protection.outlook.com [104.47.42.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 366C07D2AB; Wed, 29 Nov 2017 17:28:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM (52.132.40.149) by YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM (52.132.40.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 17:28:05 +0000 Received: from YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM ([fe80::937:f79d:d224:f68c]) by YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM ([fe80::937:f79d:d224:f68c%13]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 17:28:05 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPobgABJSsyAAAEe3oAA8S4AgAA7/Xs= Date: Wed, 29 Nov 2017 17:28:05 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> <20171128164132.290bf07218b16164db613242@bidouilliste.com> , <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com> In-Reply-To: <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR0101MB2174; 6:X+KElzgTxw2koNR9Tk/TXXxcHJLyz5TanBBE9POSJHsb8MZ1Ed+BpHyfE1YEnENL6TbcDIdGq6a+g2idHtEBrMkdHLGnLeqOneChJv0UxLAYp/1GjJ8N+VPXKS3ftuDj2VrKwQd8wcirL0LVXyBBPI1cNkeNfj1G/UsmVLSEJ4o+wCkEW9SZc60hlQngZW99a8V2lUF5iCODYfMs8naLrNJsbM4ljWwHOEwZxiGRmAhuEevmGsbR9BBCJNY8h2T8+NphV3wrvvfzrycJWS/MB3/sQ60lvsqvFSVHI03ImwNKWDUVH01JRT4Oh8/F0LQx2TnoIh0MwKeG/BXpAbhcYLuaOxGbo+htgI46drNuEH4=; 5:l+fhTLQf4g4HHGlwuZX5dq6iI/oFugNMfoAOADhWnKAekh0A1JiVvXqabpMTi//mxss0H+jdfoKw+DvuwgZIYap/pWrRLufKK2WMRFKxAALqYD8RA8uyJSBJsQCpz71uDq4XEzjgfZSQXNa5W7RyduC5h5habxfA+zlKOmUCKOQ=; 24:2aBVIMwPeqdRJ3SqwwdI8iUoh5XT1Clfs3kcBJqehG7b5M/LzxRecXMa9zv3bIswrf+dvPM3o462r4x1Yigs0MQdq4oNwgkPakp7OWiPEbY=; 7:22dDdENp5S7eDkO4pAA8rYawG2m8F4jgNa1e9DQeTm2oM+sK7dngQ02IwCu+qH8YyLLQH8cfF+mt7kyBAIZhsLPy7ak1hCG4LDoNwZNUQjYAWiQVeFFO0ejSkRhddQu16W5pm9gTKrE/lYfj8OUSSz/Ad3g3hcJeXRfvsMILBuDYgkqJjUGzrmZ/I5sOLIbxDTfBQvx2R7Mv5uctvK3+7rch5qF98ZLgdozH3RHW8FajqjS+0D3rNq/l3IB6+lpx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fcb76366-f35a-4eb2-b302-08d5374e8cc7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603273); SRVR:YTXPR0101MB2174; x-ms-traffictypediagnostic: YTXPR0101MB2174: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:YTXPR0101MB2174; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTXPR0101MB2174; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39830400002)(366004)(346002)(199003)(24454002)(189002)(9686003)(2900100001)(86362001)(2950100002)(5250100002)(33656002)(5660300001)(39060400002)(93886005)(6916009)(189998001)(105586002)(101416001)(106356001)(478600001)(102836003)(4326008)(7696005)(8936002)(2906002)(305945005)(14454004)(8676002)(81166006)(53936002)(74482002)(99286004)(97736004)(81156014)(55016002)(3280700002)(3660700001)(6246003)(786003)(54906003)(229853002)(74316002)(68736007)(6506006)(25786009)(6436002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR0101MB2174; H:YTXPR0101MB2174.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: fcb76366-f35a-4eb2-b302-08d5374e8cc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 17:28:05.0417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB2174 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Nov 2017 17:28:06 -0000 Emmanuel Vadot wrote: [stuff snipped] > I haven't test by I can say that it will work, I actually wondered at >first doing that. The problem with this patch is what I tried to >describe in my first and following mails, since you can turn on and off >delegation you can still have delegation (so nfsrv_delegatecnt > 0) >even if the sysctl is =3D=3D 0. That's why I went to the tunable way, seem= s >cleaner to me as disabling delegation doesn't really disable them for >current client. Yes, if you have delegations enabled and then disable them, there will be delegations issued for a "while". During that time, the code in nfsrv_checkgetattr() does need to check for them. Since no new delegations will be issued, the outstanding ones will go away when the client chooses to return them. (You can force this on the client by doing a dismount/mount, at least for the FreeBSD client.) Alternately, rebooting the server forces the clients to "recover" delegatio= ns and, if they are disabled, that fails. (Actually the recover succeeds, but = with a flag set that tells the client it must return them asap.) All the tunable does is make it impossible to disable them without rebooting, but otherwise the effect is the same. I have a patch that keeps a separate counter for write delegations (which are the ones you care about) using atomics to maintain the value. (That will be similar but somewhat better than what this patch does.= ) rick [lots more snipped]= From owner-freebsd-current@freebsd.org Wed Nov 29 17:47:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50B48E5F0DF for ; Wed, 29 Nov 2017 17:47:36 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 1A6427E225 for ; Wed, 29 Nov 2017 17:47:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4EB952602F2; Wed, 29 Nov 2017 18:47:33 +0100 (CET) Subject: Re: panic r326359 To: Masachika ISHIZUKA , freebsd-current@freebsd.org References: <20171129.213725.810459586021929184.ish@amail.plala.or.jp> From: Hans Petter Selasky Message-ID: Date: Wed, 29 Nov 2017 18:44:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171129.213725.810459586021929184.ish@amail.plala.or.jp> 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.25 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, 29 Nov 2017 17:47:36 -0000 On 11/29/17 13:37, Masachika ISHIZUKA wrote: > After updating r326359, kernel panic has occure. ( I can boot up > but panics within a few minutes.) > It was good working up to r325887. > > # cat /var/crash/info.6 > Dump header from device: /dev/gpt/fbswap > Architecture: amd64 > Architecture Version: 2 > Dump Length: 505135104 > Blocksize: 512 > Compression: none > Dumptime: Wed Nov 29 20:22:32 2017 > Hostname: carrot.ish.org > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 12.0-CURRENT #2 r326359: Wed Nov 29 19:06:12 JST 2017 > ishizuka@carrot.ish.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > Panic String: Lock if_lagg rmlock not read locked @ /usr/src/sys/net/if_lagg.c:1655 > > Dump Parity: 971727379 > Bounds: 6 > Dump Status: good > > I put vmcore.6.bz2(157mb) in the following. > https://www.ish.org/files/vmcore.6.bz2 > Try to set: kern.smp.disabled=1 from loader or in /boot/loader.conf Does it still panic? --HPS From owner-freebsd-current@freebsd.org Wed Nov 29 19:58:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 607FEDBA31A for ; Wed, 29 Nov 2017 19:58:36 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 247322FA2 for ; Wed, 29 Nov 2017 19:58:36 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id f69so3245253oig.10 for ; Wed, 29 Nov 2017 11:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RQJ8lfeMylyvaiFi4yUHnrOfn4Fx4TZAjR/oAHOzhp8=; b=IkrZ9L0YanV0CxXRM4MWNamhACsCSDdOYOiCtLIvVvZGTTKHv6SwJGj+cprfrLw/qP F1bFOfQTKpEoYg59hwsguLaH0EDNLD7NuBsDR20EganOfzyKcnFHFgmpwec28ina2BBA 4V8osUBjO8T5/3FsQg7v4nsCom6OUs2osGM+4PNW/JbG/yWNtQJnBfMf2yoALQe14PtU uphD8hU67S2RlAUb+XieZfC2GBZGfmo7VWMDeXXZApjmczDHQhFoDzxqujYtpiWcPthf OdVmk579uEPlLypEHgPyNibO9DJJBKivLEH7FOmrq3A7EHJiXpLXQh6+xv3BvsNdhqnt msyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RQJ8lfeMylyvaiFi4yUHnrOfn4Fx4TZAjR/oAHOzhp8=; b=g/2IjzzVnUAYHubmsVOI/boRJ5eRKo2AXsGtgpHsepoMK9I4xc4VGOzPHi8cE828gC AKyFSUMV4ssLTEwNKbQevzcFYyvXow4CYBRb6dxykj7lBNP97KbOytWWdN+w644hcyso VxTeKH7GrKRvI6esGtvdygle+LPdrDM4dYiXcbFLYt01rZ9HaSVjndLW9A0RuQyqBgOU JcwXiQyFB4zeMughhfqdSPuMAMAmeLpeQShH9f23XL7JcwMe7wj7P8If4fIEXAavjhuh F6FX2c+9VuRp7tVPiYqLlPXTXW0WcdcwAb7YnW5Fyy1lT9qfDN5PpjX2TtpYptC4T1K8 0sIg== X-Gm-Message-State: AJaThX6xgWDEke9WuB5FReWFcRtlzO8AQl0CEil2NkqSWpYtM+dnsAmc Tl8ZBQWY07S0mvh+ct/uzCAfEj5Wsfg7TyLEPKIu4g== X-Google-Smtp-Source: AGs4zMYWo0ut62V5Ef/ctTdkPqM+jyyj3bpuSe6lwrVvIgD5Z4jhpbNsP0mByBUhoSDPvCE6C4Zrfulri6splmLjBLY= X-Received: by 10.202.80.138 with SMTP id e132mr2678487oib.172.1511985515371; Wed, 29 Nov 2017 11:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.150.17 with HTTP; Wed, 29 Nov 2017 11:58:34 -0800 (PST) In-Reply-To: <20171129125628.42aa4c99@hermann> References: <20171129125628.42aa4c99@hermann> From: Subbsd Date: Wed, 29 Nov 2017 19:58:34 +0000 Message-ID: Subject: Re: CURRENT: kernel crash r326347: Cannot access memory at address 0x65657246 To: "Hartmann, O." Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Nov 2017 19:58:36 -0000 The same problem started the last week. The problem arises when on the CPU + I/O load - also when I recompile ports. I'm not completely sure but apparently I see a problem on the server ( with the same revision ) with SSDs only: on slow HDD disk still did not hang, while the server with SSD dies within 10-15 minutes after poudriere launching OS: FreeBSD 12.0-CURRENT amd64 r326361 real memory = 68719476736 (65536 MB) CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (3408.17-MHz K8-class CPU) FS: ZFS On Wed, Nov 29, 2017 at 11:56 AM, Hartmann, O. wrote: > Since yesterday's CURRENT update, I face worse and nasty problems on > all of our CURRENT systems! > > Most recent CURRENT, as with r326363, crashes on booting the kernel, in > another case the kernel is stuck and freezing after initialising the > USB subsystem (the last thing I see on screen, keyboard fully > functional, but no ACPI shutdown any more). > > Another box is now two days in row after subsequent updates of CURRENT > multiple times a day crashing on load on ZFS filesystem. The last > known half-ways good kernel is 12.0-CURRENT #157 r326347: Wed Nov 29 > 01:02:47 CET 2017 amd64. When performing > buildworld/buildkernel/relaese/package or poudriere on a ZFS > filessystem, I can now bring down the system almost in a reproducable > way. > > Last error seen when core is dumped is: > > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > _______________________________________________ > 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 Thu Nov 30 00:21:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EA2ADEDD8E for ; Thu, 30 Nov 2017 00:21:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02A646A9BF for ; Thu, 30 Nov 2017 00:21:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x234.google.com with SMTP id d15so6763174qte.4 for ; Wed, 29 Nov 2017 16:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=PMPwl70WYvmLG1mRyr6BL6rJpQPcugQXqdKu32seC/s=; b=eN6B7UCoZKY+Pg2P8sYYhfSycLduBorEEiYsEEAt02XHbfn/Bni1xWcuvGQOKtX4Ml IUwEqzjkud3++LD7K/f34m3BwZE0/cA875Y/VC7ANGHoiWf2Jw+tC1mFgIZHoPBb305A Z9kwQH1FktZLyEByb5WOv3kIUFSappNOrlt0swcnKrzy4M/XskDWqqmRDkM7uYxNkudV Hwdii2eVC5BE/s/3P85Bh3B/vrTGNua908COB6UvgBwiZ3LmV3frICyb+LR7D4mMKmsx mdAumYQmKffRzfaNqqgi14SpZjXbUElkfrEp80GuMKSD/HO7Ntd0vtrtYKlB9X9bZP2T FcRg== 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=PMPwl70WYvmLG1mRyr6BL6rJpQPcugQXqdKu32seC/s=; b=oYn1x0afRQah6TtiSwC59j7Sm+5nKUSbdEytNcF9FKZPNeU5JdPPlrPxv436KI4/FA Dvj5zjbTHogSAokLPKMhZGJu/JPj0DBjOdbcchMTDHG2B8Vitp8vMM+Y4i/qISu4cKnX L+T8KgezV22BN7hyUMrV3qprw+P0by790KRQiC/th377lW6PWdKpmIDhZfTXR+nt2+vJ UuYU9dywzllFVMn6mqjgNazVQlptdGmJWwDuThdKu1UI/cAOjnKwV7QYAt0cIvYhG/TM IEmoTAavY7ECOdbwf6p3T4fBYzVVOnMOTiKEyuzr9qsDwh/SNxv0tOS6M0lpLS/klzhm 4rHw== X-Gm-Message-State: AKGB3mInFbTWKLvETospVRl4BnienQZR923aLS/PeMQjiPHxZI6Lw8VK nu5D9YgwqUtl9bfPP39oSDivYX/6Tbo= X-Google-Smtp-Source: AGs4zMY8GTr/lQvngeojXNCT2JuPoa9j/zUw2uU5VBtn98eZpvxbs4kE5wReY+DKo1MCh/sR78CrHA== X-Received: by 10.200.63.125 with SMTP id w58mr1150085qtk.82.1512001308054; Wed, 29 Nov 2017 16:21:48 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id x52sm2127193qta.26.2017.11.29.16.21.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:21:47 -0800 (PST) Date: Wed, 29 Nov 2017 19:21:35 -0500 From: Shawn Webb To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fxivhl56ughxifsu" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:21:49 -0000 --fxivhl56ughxifsu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to this line: Using DTB provided by EFI at 0x801fe00000. Then all output stops. I'm in the process of building a custom install ISO that has DEBUG turned on in the fdt code. I hope to report back soon-ish, unless anyone else has any ideas as to what could be wrong. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --fxivhl56ughxifsu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofTwwACgkQaoRlj1JF bu7MDg//WN1HKBlxEGtm5IZLxFm+268ZABFV50fVLix3E97a4D1M1+VJuq61bkC8 dqFBcvPpEIM7LxCXjSOXR9gIzhPNrVt2u27QcpPvIkCjXYB44wHB1dbcceC5rqMw xUhvBPX86dPRp0z8qxpWC3QlXoVEv9RgeWMzYwY/H/cYztcVbfDTljsxiZ7dF9pE lX3y1gFMuBqNag18sTgLoo0Filmw/UYGPLoEajmdBjxOXhFS5zb+dUOti5m7wiyf empux/McfjIWmExZO+F7CSmymIT9X882TeTUicis4DZcPtLbUIU1RxjG/74LYybl VzUzr3pIA33T5eCxuhrdH/yopXY7Pwt0KNUzjRcaHdyL5wPpjTahkIauOEkLpsjX X+t4RLk6oUruiDPahyeUlElFtunSgvZ5MViwfy5Gqaw+UeFaGnLEwSFrrT9gmcHA SbrpMTvceZ+VMZhNLflh8Bw6HOt2XmdUdU/oJRGEUdng6W2VqD3SMvtqYcWvMeis zA7KoIPYTzVW+EAIbGce4grDDd2GeboS9U/qBS1OzMtEuPhCOJzIf+mrqpuWxPNW JSFZybtVywNZFuXJ3U/lhCqgZqCVuyfBU2UdVOgLhKB+KaHmE/pfntHBMBVVS1yu tnRQM+P8iGhHkjaCPkxF+Vc0MvHnFtLkQqoNB2mXeGRPL/KqQO4= =E7xM -----END PGP SIGNATURE----- --fxivhl56ughxifsu-- From owner-freebsd-current@freebsd.org Thu Nov 30 00:33:48 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A335DEE82F for ; Thu, 30 Nov 2017 00:33:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48A406B677 for ; Thu, 30 Nov 2017 00:33:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id e204so5676245iof.12 for ; Wed, 29 Nov 2017 16:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=z2gIB7V5Pl2227RCbzpYJanHSyMag/rx8+k4p+qkcuk=; b=qx2tR5nmXaHgHX0ZBnq/GwhMXc5arvPnpVpvU8uzQwl1zMFKrQ7cwmTvNz5TILJpVf 806wDpKATihtP/2I6k/bLpKjdQKFz4p2jpbUwLZGM3igWWD49O7Q0XS1mqxAVvYeKEW9 qFUdRri2wGxvlXA2aS3OeLoo2jeI1T0dgP0xmUcdnYtXD05OPnopbQgmkKmnZZHVBvuz 5zWQoti4ZtDZvR1OhcxWltT0Ns13IplMUgBencCXyzPzAiZwTJXpYMvimC2Kz5E52X6R 08XS9yPkX1WC51p067v9wYd9j6lhbwpKLw04OqysMEU6Yy9OuMO1nmsOMAHGXhoCBYBc JXIg== 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=z2gIB7V5Pl2227RCbzpYJanHSyMag/rx8+k4p+qkcuk=; b=nToQVKr+fneGJxTeuGVtLQ/0emPTtvvXrE2wSefhjsEVXY/uSdsRVsW7NQMJ6qmIfC 9wFn8XZOW+enJHnkTs9vEKADkHsenCy47FteLeB3hVk9uLJvHljUjxyX8LE9t+PCWBqC 2nJjKxwldIQnqoClc45nha0g8AbsVhhAM9Kqq0znVQIrJykx1HFHa6/y5s3oUD32/0d0 BFL4zniizTBWzlU2tMyIA2tiuQzVkzZkcTXHssgYTORw4502sIxxbVd0hMP+qlTUzuGQ A2Q5nJ5UzIo8OxuZlA2kmICkrBdfBdF3Z9/1jYbHg/vrWwadJ6Qi6oZ+Zdg8DcakGQnu fFDA== X-Gm-Message-State: AKGB3mJT81YmmS9xE7ocOFktpq5Q4WmUWoU9lgKs4Zi5YZXBrFQSFPNL HoCwixLG+heTs1M+5Dhhce0M+9CueBkdjtBmwrcK6A== X-Google-Smtp-Source: AGs4zMZ0/RJR+FIe96xBtF9SCn5BtWBjfERk+VN+v/pAtHEHYN7w8f3yge2xKGZGyXF2Y139vYH28pjnDi6mdmyLsx8= X-Received: by 10.107.52.140 with SMTP id b134mr2106940ioa.291.1512002027427; Wed, 29 Nov 2017 16:33:47 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:33:46 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:33:46 -0700 X-Google-Sender-Auth: tYEcAb85_Pt7uDa2GOxC4JkuclY Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:33:48 -0000 On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb wrote: > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > this line: > > Using DTB provided by EFI at 0x801fe00000. Which snapshot is that? Boot1 was broken until recently. Warner From owner-freebsd-current@freebsd.org Thu Nov 30 00:35:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10431DEE9B5 for ; Thu, 30 Nov 2017 00:35:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B81E26B87D for ; Thu, 30 Nov 2017 00:35:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22a.google.com with SMTP id d66so6887967qkg.1 for ; Wed, 29 Nov 2017 16:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ltoSGPEtDXSFR9psuV7qBalnoqhiZx5GWN94dyH8fyo=; b=xuYn/On/xaCpQGdzAit7ZLI5cVseSHdaNZMzYr1TvtsutNQ/Tkpm80G4P7733QPGyT nR5cCFKp7FqDC7v3xtUqZ/xuv9v6aapulqW9yP2LPxPEe9dEjYWlkcwS9nXNFrcZ4PO6 QfJWlIs7uWZMn5hs0ltDME9zx5/gna1S50W9gSbiwgEEGweBVU1cZhgu4bXrSer+rw8D UgGPHK5tsY/rRFH8TI6BJL74D++SxZsYSUhpzRHsmpiMSBOK21Mk0+NrVTB19w62yz4c +qAh+dTpXispT2jtKoF5zzeADRNIP8HfYqCfZRqeSI6O6fJIn7PtimlMX6xh+zEqtzx3 PlAA== 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=ltoSGPEtDXSFR9psuV7qBalnoqhiZx5GWN94dyH8fyo=; b=hZJ9ovZNaRfmDCdxmcc5AC6gq6ZlKS1pKonbM852PTul/O3YTpI44Ddvk8WHbiIGYC ZT8NzhofOYjhFrq09HZmekoTmb1bWCnN1IVBusf5TTsmUfGvsCjTqlo7F44b/4ZRYoZs 6EChWaosUzeoX85afkgbXsCFNCh4lTxtmMVtzYlq9Zal1fobYeEJJdZutdKApHwHiLIq IETMNUmYlO22XUmE+um/p+rrKzXrxGjqWKm3YGkTan3yevcdW79QbjnljsB4xgNarCjs OevgBJLjDMGmrttIyHgSltDcwwRh08IRGlh98Lh+stL9P+5qWFF96Pu5yBy1XHRaXMNG ba5g== X-Gm-Message-State: AKGB3mJcb4ObBQNWu/303undQSDpDLuBL4hSLwAlbD4xWx3zmVxWDw/2 hGwWnyDW9EgLmZIeZHEknnJpYhVz4MI= X-Google-Smtp-Source: AGs4zMYbOC4Wr8U10GZFWGGsy6cZxhtr14W3seh0E+K2GwdErzXxd00u48hP+5RIYKSSBbCU7pJF1w== X-Received: by 10.55.183.132 with SMTP id h126mr348538qkf.259.1512002110599; Wed, 29 Nov 2017 16:35:10 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id y135sm2079741qka.48.2017.11.29.16.35.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:35:10 -0800 (PST) Date: Wed, 29 Nov 2017 19:34:58 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oraptaq7mf35otmx" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:35:12 -0000 --oraptaq7mf35otmx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > wrote: >=20 > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > this line: > > > > Using DTB provided by EFI at 0x801fe00000. >=20 >=20 > Which snapshot is that? Boot1 was broken until recently. FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img It also happens on latest HEAD, so it would appear to still be broken. --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --oraptaq7mf35otmx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofUi8ACgkQaoRlj1JF bu7fnBAAwBzLtPIH7qjgvQwtKOr/L1AOhnjItXrmR8zvcSWYskZ788m96mpeJmEL 3q3PZdtNRfo6wNfuLdWWnxizgAY+tWRTvIew2e8IeflXUr84JYobj+LNap/YXEkV 1pR88hzWC0JUo/6UaapdQHeGQIREMbmlB0ih5wvj+t/yxjxoc6+9PLavQoYpMAwP c2BGXX3tzXSu5YHTxkC0AZxDw0UoSELuG63haHTzv/NUUi/QSYEGs+G+Q2zmiBIg BxV8Hm6rEvPNJOq9Ur+NJnnFutbaMVLkHVrBw65iPJ5R6HdDXHgkDA22Ej+nFc89 HxyPGrMi5/zUdMTe3J2bxDAjKGnAtWC98hDRQ55FCpk/Bbct1iphriH/s94DFuPh ouEi9qp19AxA7p0QEjOKaBd/ifaRduSf//DtkrL6qo8N1KBE6pPb276pKxRRcuTg yMpibR3xCkhryuEaFnOo8po2pvE8qOW3nvA+FZ8FdYVBWLHmnAezRMWK5Ga1MWXL Na+Sz/YUVAD4a0/udYYNQf7pi52SL9CIKptoJK1fNav9SBmkCDbOtTlbmGC+0NNf HLo4tTOx6c8nEfMEs18M59/8TBKvzxWT1JmrN8cPxet0xDMhyCTI1rVWo1JR1mNl nD1imqgWSvHz1YiYslCf1ASZd2fJ3ozk2ypdGjpXZO3X4NbM/N8= =U+r1 -----END PGP SIGNATURE----- --oraptaq7mf35otmx-- From owner-freebsd-current@freebsd.org Thu Nov 30 00:42:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 021B5DEED5B for ; Thu, 30 Nov 2017 00:42:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B41A36BD08 for ; Thu, 30 Nov 2017 00:42:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id q15so5725442ioh.2 for ; Wed, 29 Nov 2017 16:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5W/eDdLol7FAXbzSjld2e5w6aMrQ0gEYBBWAw9TjKpM=; b=Ib//RFwOOZkY+0ID4Uk0rdRsSjmLS9soSuVqN7EVQSSzLrjkYve70A/yHmeCW6Kk0Y AjcrsgtHzxmZ3JH4j6JL8uJF3HCCC8/xzDE/DVBSWYbEzyIvV5Xv173CrIxYpX3rzA5l 36Kz5FrApvp3eo1CrjVlBlzkIWGDp9mxc4XKNfTy20F84GzGlVJAf3npRg/CbbhfcJSn kLlRuWbBzIwVke3OLPQAd0WXS1zRQXIqJ+y32EdLEf+WKoEC6mttM6vKtqB0Lo8GiqI7 CHGOnzYQAbhzda2VTaOH5zQxUgFb646ZNwhqI/Ki4V49rIxVWNj8FYCgUuuP2l58BCHi JMxg== 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=5W/eDdLol7FAXbzSjld2e5w6aMrQ0gEYBBWAw9TjKpM=; b=ZrjsBomJCqwu2Fws0V4MOqofbQ5MS63/L0Q0BhRC5gkprG0vkFik30AAGZRxDREQjW C1rDPEzFkz8aAMbqRLGxdJf+jZcrDGdNOhWjebJdqzizeDcNSQA9xbk+0M7N14Yb94+k 5zHTZ2MjjahF7Er0baAoLseJzUIkEX3dxBXCVAsHwes1NuiohaPZrt98Pq2VYH9Ksyml yKThqA7ApC9jrjiy+bzYlLCUIvZKyPI08apCheA863uMx/sL4XUHGJrVocPNCAo1E5zW ORohfcG0QjbcwT4Oug2B4kn5p1TaIKRGZFwPEBAqFTIWjG06dRhKffTid6ZSgibHkOoQ /bgg== X-Gm-Message-State: AJaThX7DPakhbYE0Sp3hQijRJjIZoBSn9mfQvlaVOEFzh9LfhcylfE5i w6nLqct8FZptmaiXW02iDnZDJigio+f/RnDdbjg1Rg== X-Google-Smtp-Source: AGs4zMbXHBkuLGsIM1ZRtrUsvK0fSupBMaHvjOhZ5duCf1YhZTF9I6Nvis7hKiAurS2jMoMG1GkYw8PGQDNX7onDypE= X-Received: by 10.107.48.197 with SMTP id w188mr5826163iow.301.1512002572924; Wed, 29 Nov 2017 16:42:52 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:42:52 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:42:52 -0700 X-Google-Sender-Auth: dLQYSl1cNULwlotnr4o17iV2Kwo Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:42:54 -0000 On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > wrote: > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > this line: > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > Which snapshot is that? Boot1 was broken until recently. > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > It also happens on latest HEAD, so it would appear to still be broken. Is this boot1.efi producing the output, or loader.efi? I'm guessing the latter, but wanted to make sure. If so, then we're past the point where boot1.efi would have failed (besides, it was fixed before that snapshot). Warner From owner-freebsd-current@freebsd.org Thu Nov 30 00:44:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AD8EDEEEEA for ; Thu, 30 Nov 2017 00:44:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B21A56BED8 for ; Thu, 30 Nov 2017 00:44:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x22d.google.com with SMTP id z203so6875707qkb.5 for ; Wed, 29 Nov 2017 16:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=O3yEJQQPbkT0JYWRtkJg74AElJNmyhfF2tBxJym4K58=; b=ktP/XbZCLupD4b5EgdDXI2tG7boOQECwIyYAxLl0oSvKQuBufsxVy+vMrgzm0U65QB ZRISl0js7scfhzjiJ/+O0i+gXlImgx2hgZCITRUYG5M/5W/c7J7XMPXp/v4ZRCGpU0l1 zhuHn/Im1bjSgsG/x6LCdn3m0+kOCLDTz501WBr3YAh3szqvkJN3bADFYMKWTdhfvcxX xuWXIrZeEy58YlHbUVxDHvIJ1zL8pirPJ3ZlAnihHolvLM/WsJNWWJBbQEpS8CFwc78q UTIoueuXTSnjdIH1vtMwg9bhjm/5Ca+0RCQsahm8FMhORNE/MlNpIZPO3UMR9d4KdX22 LWNQ== 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=O3yEJQQPbkT0JYWRtkJg74AElJNmyhfF2tBxJym4K58=; b=VCgyKb83M7XRAOiSht+sVqeMFV7bIZBZQCGpe+ndSIzmGryLllQN7ly8Xby7wNRF2L GFnvRGmXHdJYRggKKbbKfyEkyh0qsbdygBsgPSKxESo7kuKXkpv5IWGMRy+GyKYNu0k4 P+9kcYEJSX0FHn3St0ysi5yYFVgUOuSfLgBelMVOm47Uy5XH0RFkYEkQqLqkHmHNfOTq bYBXW0zqxsssNiXzWKy6YnoMibMbrHv5DltTCy4BXkyYokFKuwHTHmZHY1fn0cfYxvfF Z81IT4aAHTLWmVTTqUf3pRScj/qTTwvoZo+LjiQSfoJmriQiaMIikg9QZmNox6fhS7vZ 3njA== X-Gm-Message-State: AKGB3mJAfLNav8ZQid3EnGUsfAOwqWX+dLxRVs/03yHKGqMiYAazmOiI 082vfV0zsV/8ZM+FueiEkdpLpw== X-Google-Smtp-Source: AGs4zMZlGTWu0Xjf2u3PTDrdedn8RMWL7SScfghXNB3nyUkBOwD1GYq7Q+PZH/GXPCVAiuiNreUfsw== X-Received: by 10.55.134.195 with SMTP id i186mr378275qkd.261.1512002650675; Wed, 29 Nov 2017 16:44:10 -0800 (PST) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id s27sm2145904qtj.42.2017.11.29.16.44.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 Nov 2017 16:44:10 -0800 (PST) Date: Wed, 29 Nov 2017 19:43:58 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171130004358.usia2jrvman4cvvz@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e3qipk7wfsn3ujwm" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:44:12 -0000 --e3qipk7wfsn3ujwm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > wrote: >=20 > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > > wrote: > > > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > > this line: > > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > Which snapshot is that? Boot1 was broken until recently. > > > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > > It also happens on latest HEAD, so it would appear to still be broken. >=20 >=20 > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > latter, but wanted to make sure. If so, then we're past the point where > boot1.efi would have failed (besides, it was fixed before that snapshot). With DEBUG turned on for stand/fdt: Booting [/boot/kernel/kernel]... =20 fdt_copy(): fdt_copy va 0x01208000 fdt_setup_fdtp(): fdt_setup_fdtp() fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) Using DTB provided by EFI at 0x801fe00000. Loaded the platform dtb: 0x81f56f1630. fdt_fixup(): fdt_fixup() ^ hangs after that message --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --e3qipk7wfsn3ujwm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlofVE0ACgkQaoRlj1JF bu5AqQ//eWoXYVh12ZhH1017CCBXTG17WTjSj7vqU/OV6Gn5oy4ZKqQMjQpVvxeb m5I7Bo9MfTHWYTAV7H1Ii4C0dwjMuyGcFAxGcRx4hj6SbQY4mhuap/UowN7Tf3AW l0LpmzLLm0RXqQH6R+hdwyRKsYRslu9pY+YBmrsn2mk3G+LGL8I3nWKRDhPMklcy St5fGCWgkeJwg8aaO3XJQDpQCGg7iMwTJH/BFXfEx2sQlkIAljC7C5leUN8x3op+ X/j9jHlPWZwT7j3PXRC7kJJfZoEdaryz3M3lArBZRUU/amMtWAL6FUgH4aCckkrV Kxm2FqGdnsNvHTUnD/p47NPuHjaTfLdkaVFvjBK0/90LwQcO/FQzREedVKxlkNpC QP86LtMJRC6s3wTerhoaR82ZG9NR0FT6E3gvjS2zpjdb3wA/TrZPKnvj6mxhHzAM DryBUwHB2n3kwOpngnH+DoIsNfuCSMJl6OHW1oQPZhMJLOenTCixeaiyz2ZA+TGa o3jdT9Hdht/bV0fIL48cqEIKUUreSw+JIx3LQanttBqpV4M6+nNPyxMJXbOikm1p n5EBYJlXYHUITg4zyy2KKKw1vlZKFNe6hO49uogXRN8ewLhcgE6xhOUY+l7T9rEv HfEnH25uc+f/qfmtVxg1Dm4ytLmtTmbq/ju9tFKJd/yci/oIx+U= =El1d -----END PGP SIGNATURE----- --e3qipk7wfsn3ujwm-- From owner-freebsd-current@freebsd.org Thu Nov 30 00:54:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E194DEF32B for ; Thu, 30 Nov 2017 00:54:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 609BF6C527 for ; Thu, 30 Nov 2017 00:54:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id h12so5741206iof.6 for ; Wed, 29 Nov 2017 16:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QLMSAF9nLX8GKcendxGFBkU4afXy2lfIuGl7C8y9lFw=; b=txKGW12oR5WZ4K7hzBzsn3F9Jluy+KQAh/IV162hn3kt9Kph+EPbrBSpBSnsOKrLrK xoknvJOwg10lBWkHw2vdxYD4WkMp9AkVPx6zQcQp+N36Hksm+nctZVGoZjyQOBMTIwuP PxWmzNGAC5y0nGM5qPdaoGDbc/nPVWZy4UuajiuuzHkQWgQYwVLfxph0AOLBSNxlYVLo bt/mLfrp14gCeZC4mPlDI1Zsl0SiYlVVj836Z/Tx5PJh0pAAT6bI4donMMwfwx2rEcHn 1yOlvFrrbTeIAUGZLtOJoijmnK6Kyw4XBpnZgK6ceC1h1o2Op+s5k2EhA3UaJz2ojXa2 CCkA== 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=QLMSAF9nLX8GKcendxGFBkU4afXy2lfIuGl7C8y9lFw=; b=dmR4EA1f9kV4D7P9bjdz5/y/TUVSkBWf0s/yjYb9DX3+T9hNSmrhcDcP0E68uMBL0R Rn6hy2Ok0wbxd5NqOmi1SxMO54S3eLENXcjyzNFlPeR/uA8sW6UoM5rocaUvd9gKL2lP A+Pn77wUxpA6hZZN/tiuGPm7kKiONMpriKSPHmgI0BUjsASlloO/rG8XrvcABimqJL7y uoJYmKYmRDBoUxa3ha4rSeNU06G7zOg67iBqZ+6xL4jKcXQfGUP9+542cIaTiHgLdFxR N6kGUUMxssPM5Y4ex1x7u2R0jwYpPuYCpI3HRk8uDPGAR8j/6tFuBCZnUVS+EOVF2+gG Rzaw== X-Gm-Message-State: AJaThX5no7ehWObJq/e1E1rMtu/FFIFqq7MrGanskiHOmr6rDLPKtunn Vw3N1lv9VApqu583S/eCdsqX2/dtU86/RKkQptuwlQ== X-Google-Smtp-Source: AGs4zMb1mrLE8yhDuyCEp5pRjH3Q09rau7iJjxeHFN2zqnxeOTQI8UEEQkpYdRrnD069lOxM70l2Z3olR93GmHI4+uA= X-Received: by 10.107.104.18 with SMTP id d18mr5311566ioc.136.1512003265699; Wed, 29 Nov 2017 16:54:25 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 16:54:25 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171130004358.usia2jrvman4cvvz@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 17:54:25 -0700 X-Google-Sender-Auth: bndQhTjws8JqDaHqpehAC7sQyHs Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 00:54:26 -0000 On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > wrote: > > > > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > shawn.webb@hardenedbsd.org> > > > > wrote: > > > > > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > > > > this line: > > > > > > > > > > Using DTB provided by EFI at 0x801fe00000. > > > > > > > > > > > > Which snapshot is that? Boot1 was broken until recently. > > > > > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > > > > > It also happens on latest HEAD, so it would appear to still be broken. > > > > > > Is this boot1.efi producing the output, or loader.efi? I'm guessing the > > latter, but wanted to make sure. If so, then we're past the point where > > boot1.efi would have failed (besides, it was fixed before that snapshot). > > With DEBUG turned on for stand/fdt: > > Booting [/boot/kernel/kernel]... > fdt_copy(): fdt_copy va 0x01208000 > fdt_setup_fdtp(): fdt_setup_fdtp() > fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > Using DTB provided by EFI at 0x801fe00000. > Loaded the platform dtb: 0x81f56f1630. > fdt_fixup(): fdt_fixup() > > ^ hangs after that message That doesn't sound like anything I've changed, but it could well be... I think to find this breakage, you may need to bisect backwards along stand / sys/boot until we find the spot where it broke. Warner From owner-freebsd-current@freebsd.org Thu Nov 30 01:25:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB961DEFF02 for ; Thu, 30 Nov 2017 01:25:58 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa02y.plala.or.jp (msa02.plala.or.jp [58.93.240.2]) by mx1.freebsd.org (Postfix) with ESMTP id 315856D454 for ; Thu, 30 Nov 2017 01:25:57 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc02.plala.or.jp ([172.23.12.32]) by msa02y.plala.or.jp with ESMTP id <20171130012555.UXAM6311.msa02y.plala.or.jp@msc02.plala.or.jp> for ; Thu, 30 Nov 2017 10:25:55 +0900 Received: from localhost ([2400:4050:9320:7a00::8]) by msc02.plala.or.jp with ESMTP id <20171130012555.NDWQ6556.msc02.plala.or.jp@localhost> for ; Thu, 30 Nov 2017 10:25:55 +0900 Date: Thu, 30 Nov 2017 10:25:48 +0900 (JST) Message-Id: <20171130.102548.289362648662158746.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: Re: panic r326359 From: Masachika ISHIZUKA In-Reply-To: References: <20171129.213725.810459586021929184.ish@amail.plala.or.jp> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa02m; Thu, 30 Nov 2017 10:25:55 +0900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 01:25:58 -0000 >> After updating r326359, kernel panic has occure. ( I can boot up >> but panics within a few minutes.) >> It was good working up to r325887. > > Try to set: > kern.smp.disabled=1 > from loader or in /boot/loader.conf Thank you for reply, HPS. It seems good working by 'set kern.smp.disabled=1' on loader prompt. # Another panic has occure: # Panic String: ufs_dirbad: /: bad dir ino 4334201 at offset 5120: mangled entry # # I think that had damaged internal SSD at last panic. # I repaired SSD by fsdb according to # http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/ # and now work well. -- Masachika ISHIZUKA From owner-freebsd-current@freebsd.org Thu Nov 30 02:31:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B418ADF2607 for ; Thu, 30 Nov 2017 02:31:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 750326F909 for ; Thu, 30 Nov 2017 02:31:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id q15so5930283ioh.2 for ; Wed, 29 Nov 2017 18:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t0zM1Ly+b6FMoO2miBpGpDkALNhPf+yrrjYzzUbUG6k=; b=YT/TsXwXIq7TlzDPI9ijhEzHHYqL1ZI52YmOgT5zEZxehhWIsulaFZYzQ2A/TPSZMX kGwpBAFWv4nb0BB4NI+zbEt2tJBQwIz8WxafSVR/8yc6tzlHRFOylNGS3MqLulP+Id+s iB1Qx2GACWn9z+OBjrN01yka0RjZvQVYzB9tXcGzXyApd0fTIWzaCtXhCgp4oDtp+QTu uRNtaWkTug5q+dWT1BNjOF28k4mSUe6ERmXxOAOTaRoowicKDoF7TCnNZ3TJ9B1njjng fEubI+3TWJ/ebxZjUTWw/wQxZmOCiqFfnk94gVyNuSSLh9CwL87KwCktz1Q2mZ3Sp0MN Vgrw== 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=t0zM1Ly+b6FMoO2miBpGpDkALNhPf+yrrjYzzUbUG6k=; b=EYjI+MNu2y9oZiKJEMIsxoESkQVOcmiEx9C/sUeDwQ0S/M4pkQDO8FgGjQQYeQDKVh 8prlBhJNEdSdj1lBnMpXOJWti31tnnMYjWFWZCXHadO4yW7duZOWFE+x35LU44UEXpbm bDwXMsEmDu3nN1FMhVqfHpHzxEDA9PH13gkscZ3JIrn3GGBhmPGyWWP+/tnqoTYoVViy TqzqEjcT2CdjoOTXa/ZSeiXXDfToJJtcJ6vvlrOJQGbvAyrh6lQGhC+f+81lcwxq/6aA Kdi8o4WuTpBUc/2Bc8dchZaOtSWmHdCS9F1zqLGyCfIUcnsdTpLBh1CVhuxo0IkpVAuD UrtQ== X-Gm-Message-State: AJaThX42dBZrLqwEtVW5tAEMPl3jwSqMDZZKNeHS9vM/0BPNTLV55GNB NeF+4cvAMsgmBTvKm12d/hUlpfUMbYnZM3Jvnooaig== X-Google-Smtp-Source: AGs4zMbJm0gF17ersF1ewY9u3bIF+fktM/SYHVG8/E6bl9ABxxfjyIkcwjk0SlhX3GkJaVfTpUCTT/c2r3g3Hfevmeo= X-Received: by 10.107.81.24 with SMTP id f24mr5841036iob.63.1512009078633; Wed, 29 Nov 2017 18:31:18 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 29 Nov 2017 18:31:17 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> From: Warner Losh Date: Wed, 29 Nov 2017 19:31:17 -0700 X-Google-Sender-Auth: DycRMVjGxUxf7RZ6dh0eK5QDm0U Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 02:31:19 -0000 On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb > wrote: > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > >> > wrote: >> > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < >> shawn.webb@hardenedbsd.org> >> > > > wrote: >> > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up >> to >> > > > > this line: >> > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. >> > > > >> > > > >> > > > Which snapshot is that? Boot1 was broken until recently. >> > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img >> > > >> > > It also happens on latest HEAD, so it would appear to still be broken. >> > >> > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing the >> > latter, but wanted to make sure. If so, then we're past the point where >> > boot1.efi would have failed (besides, it was fixed before that >> snapshot). >> >> With DEBUG turned on for stand/fdt: >> >> Booting [/boot/kernel/kernel]... >> fdt_copy(): fdt_copy va 0x01208000 >> fdt_setup_fdtp(): fdt_setup_fdtp() >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) >> Using DTB provided by EFI at 0x801fe00000. >> Loaded the platform dtb: 0x81f56f1630. >> fdt_fixup(): fdt_fixup() >> >> ^ hangs after that message > > > That doesn't sound like anything I've changed, but it could well be... I > think to find this breakage, you may need to bisect backwards along stand / > sys/boot until we find the spot where it broke. > There's been several conversations on IRC about how others are hitting a scheduler bug, at least on x86. hps' fix seems to do the trick for their issues. Author: hselasky Date: Wed Nov 29 23:28:40 2017 +0000 The sched_add() function is not only used when the thread is initially started, but also by the turnstiles to mark a thread as runnable for all locks, for instance sleepqueues do: setrunnable()->sched_wakeup()->sched_add() In r326218 code was added to allow booting from non-zero CPU numbers by setting the ts_cpu field inside the ULE scheduler's sched_add() function. This had an undesired side-effect that prior sched_pin() and sched_bind() calls got disregarded. This patch fixes the initialization of the ts_cpu field for the ULE scheduler to only happen once when the initial thread is constructed during system init. Forking will then later on ensure that a valid ts_cpu value gets copied to all children. Reviewed by: jhb, kib Discussed with: nwhitehorn MFC after: 1 month Differential revision: https://reviews.freebsd.org/D13298 Sponsored by: Mellanox Technologies git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f is the fix.... But the bug it fixes post-dates the snapshot, so maybe this isn't the same thing... Warner From owner-freebsd-current@freebsd.org Thu Nov 30 05:26:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E850FDF8374 for ; Thu, 30 Nov 2017 05:26:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-153.reflexion.net [208.70.210.153]) (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 9A0BB7538A for ; Thu, 30 Nov 2017 05:26:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16273 invoked from network); 30 Nov 2017 05:25:55 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Nov 2017 05:25:55 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 30 Nov 2017 00:25:55 -0500 (EST) Received: (qmail 12395 invoked from network); 30 Nov 2017 05:25:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Nov 2017 05:25:55 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 70F1AEC8EFB; Wed, 29 Nov 2017 21:25:54 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: poudriere bulk -a ended up in a "all STOP" status. . . Turns out to be: /usr/bin/nohup in background vs. tty output issue Message-Id: <8D4E08D3-17B3-4F22-9330-16123EA4DAD2@dsl-only.net> Date: Wed, 29 Nov 2017 21:25:53 -0800 To: FreeBSD Current , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 05:26:03 -0000 I attempted the experiment of building all ports via poudriere (run via "/usr/bin/nohup . . . &" and watched via tail -f nohup.out ). It got to: [16:06:54] [14] [00:03:00] Finished net-mgmt/icinga-core | = icinga-core-1.13.3_1: Success [16:06:57] [14] [00:00:01] Building devel/elixir-crontab | = elixir-crontab-1.1.2 [16:06:58] [08] [00:03:38] Finished archivers/php71-zlib | = php71-zlib-7.1.11: Success [16:07:00] [08] [00:00:00] Building mail/p5-Mail-IMAPTalk | = p5-Mail-IMAPTalk-4.04 [16:07:10] [26] [00:08:01] Finished devel/geany-plugin-commander | = geany-plugin-commander-1.31: Success [16:07:12] [26] [00:00:00] Building net/spread | spread-3.17.4_5 and then seemed to hang before whatever would have been the next message, not that I noticed it at that time. (Other things seem to be working fine.) top showed most everything in a STOP state. It had built 7014 ports. Context: head -r326192 inside a Windows 10 Pro Hyper-V virtual machine. dmesg -a shows a couple of lines with a type of message that I've not seen before: sonewconn: pcb 0xfffff811e2da6570: Listen queue overflow: 1 already in = queue awaiting acceptance (1 occurrences) sonewconn: pcb 0xfffff8175d260cb0: Listen queue overflow: 1 already in = queue awaiting acceptance (2 occurrences) (The machine is basically dedicated to this build and my monitoring of it.) But I do not know the relative timing of those 2 messages or just what they were tied to. they could be some independent issue for all I know. Turns out that the following started things going again: ^C the tail -f nohup.out and fg the background process. This resulted in the following text: ^C [1] + Stopped (tty output) /usr/bin/nohup poudriere bulk -j = FBSDFSSDjail -w -C -a # fg /usr/bin/nohup poudriere bulk -j FBSDFSSDjail -w -C -a Then things were no longer in the STOP state. No visible tty output appeared after the fg-command material shown above, despite supposedly being stopped for "tty output". Looking separately at the nohup.out file, it continued with: . . . [16:07:10] [26] [00:08:01] Finished devel/geany-plugin-commander | = geany-plugin-commander-1.31: Success [16:07:12] [26] [00:00:00] Building net/spread | spread-3.17.4_5 [16:51:28] [23] [00:48:53] Finished = multimedia/gstreamer1-plugins-gnonlin | = gstreamer1-plugins-gnonlin-1.4.0: Success [16:51:34] [23] [00:00:00] Building devel/p5-MooseX-App-Cmd | = p5-MooseX-App-Cmd-0.32 . . . So I have an upper bound how long it was STOP'd before I noticed. Looks like: /usr/bin/nohup poudriere bulk -j FBSDFSSDjail -w -C -a & is currently a bad idea. Next time I will omit the "&". =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Nov 30 08:28:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6384DFCC35 for ; Thu, 30 Nov 2017 08:28:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 AEB777B6ED for ; Thu, 30 Nov 2017 08:28:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 125D02603A1; Thu, 30 Nov 2017 09:28:32 +0100 (CET) Subject: Re: panic r326359 To: Masachika ISHIZUKA , freebsd-current@freebsd.org References: <20171129.213725.810459586021929184.ish@amail.plala.or.jp> <20171130.102548.289362648662158746.ish@amail.plala.or.jp> From: Hans Petter Selasky Message-ID: <73623cb8-fd62-7064-3915-8b8efba3df61@selasky.org> Date: Thu, 30 Nov 2017 09:25:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171130.102548.289362648662158746.ish@amail.plala.or.jp> 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.25 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, 30 Nov 2017 08:28:36 -0000 On 11/30/17 02:25, Masachika ISHIZUKA wrote: >>> After updating r326359, kernel panic has occure. ( I can boot up >>> but panics within a few minutes.) >>> It was good working up to r325887. >> >> Try to set: >> kern.smp.disabled=1 >> from loader or in /boot/loader.conf > > Thank you for reply, HPS. > > It seems good working by 'set kern.smp.disabled=1' on loader prompt. > > # Another panic has occure: > # Panic String: ufs_dirbad: /: bad dir ino 4334201 at offset 5120: mangled entry > # > # I think that had damaged internal SSD at last panic. > # I repaired SSD by fsdb according to > # http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/ > # and now work well. > Issue should be fixed by: https://svnweb.freebsd.org/changeset/base/326376 --HPS From owner-freebsd-current@freebsd.org Thu Nov 30 11:45:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1AD0E53781 for ; Thu, 30 Nov 2017 11:45:35 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa02y.plala.or.jp (msa02.plala.or.jp [58.93.240.2]) by mx1.freebsd.org (Postfix) with ESMTP id 76AF618DE for ; Thu, 30 Nov 2017 11:45:34 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc01.plala.or.jp ([172.23.12.31]) by msa02y.plala.or.jp with ESMTP id <20171130114532.YNEM6311.msa02y.plala.or.jp@msc01.plala.or.jp> for ; Thu, 30 Nov 2017 20:45:32 +0900 Received: from localhost ([2400:4050:9320:7a00::8]) by msc01.plala.or.jp with ESMTP id <20171130114532.NFII19170.msc01.plala.or.jp@localhost> for ; Thu, 30 Nov 2017 20:45:32 +0900 Date: Thu, 30 Nov 2017 20:45:27 +0900 (JST) Message-Id: <20171130.204527.891215391547679196.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: Re: panic r326359 From: Masachika ISHIZUKA In-Reply-To: <73623cb8-fd62-7064-3915-8b8efba3df61@selasky.org> References: <20171130.102548.289362648662158746.ish@amail.plala.or.jp> <73623cb8-fd62-7064-3915-8b8efba3df61@selasky.org> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa02m; Thu, 30 Nov 2017 20:45:32 +0900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 11:45:36 -0000 >>>> After updating r326359, kernel panic has occure. ( I can boot up >>>> but panics within a few minutes.) >>>> It was good working up to r325887. >>> >>> Try to set: >>> kern.smp.disabled=1 >>> from loader or in /boot/loader.conf >> Thank you for reply, HPS. >> It seems good working by 'set kern.smp.disabled=1' on loader prompt. > > Issue should be fixed by: > https://svnweb.freebsd.org/changeset/base/326376 Thank you, HPS. I updated r326384 and it is good working. -- Masachika ISHIZUKA From owner-freebsd-current@freebsd.org Thu Nov 30 22:51:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E970DEBBFF for ; Thu, 30 Nov 2017 22:51:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-125.reflexion.net [208.70.210.125]) (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 148F57A1F5 for ; Thu, 30 Nov 2017 22:51:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19654 invoked from network); 30 Nov 2017 21:04:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Nov 2017 21:04:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 30 Nov 2017 16:04:29 -0500 (EST) Received: (qmail 3999 invoked from network); 30 Nov 2017 21:04:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Nov 2017 21:04:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F133DEC9591; Thu, 30 Nov 2017 13:04:28 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: dmesg -a shows "Failed to fully fault in a core file segment at VA" examples, anything to worry about? Message-Id: <4D8DB370-AC0F-40F8-B5FC-213D5A3409FD@dsl-only.net> Date: Thu, 30 Nov 2017 13:04:28 -0800 To: FreeBSD Current , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 30 Nov 2017 22:51:11 -0000 Basic context: # uname -apKU FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M amd64 = amd64 1200054 1200054 During an experiment with a "poudriere bulk -a" I've noticed the following 2 message sequences: > Failed to fully fault in a core file segment at VA 0x80064b000 with = size 0x1000 to be written at offset 0x2e000 for process conftest > pid 26417 (conftest), uid 0: exited on signal 11 (core dumped) > Nov 30 03:37:25 FBSDHUGE kernel: Failed to fully fault in a core file = segment at VA 0x80064b000 with size 0x1000 to be written at offset = 0x2e000 for process conftest and: > Failed to fully fault in a core file segment at VA 0x80064c000 with = size 0x1000 to be written at offset 0x2d000 for process a.out > pid 65189 (a.out), uid 0: exited on signal 11 (core dumped) > Nov 30 04:58:23 FBSDHUGE kernel: Failed to fully fault in a core file = segment at VA 0x80064c000 with size 0x1000 to be written at offset = 0x2d000 for process a.out (The console only shows the two non-timestampted "Failed to . . ." messages.) I note that VA+offset =3D=3D 0x800679000 in both cases. This suggests a common cause associated with that spot in some way. The messages seem to be considered non-fatal at the system level, although the processes are getting signal 11. It is not clear to me if the signal 11's are consequences, causes, or just happen to be associated. So far I've only had the 2 examples as of: # poudriere status SET PORTS JAIL BUILD STATUS QUEUE BUILT = FAIL SKIP IGNORE REMAIN TIME LOGS - default FBSDFSSDjail 2017-11-29_03h45m33s parallel_build 27777 14609 = 156 2015 136 10861 33:09:51 = /usr/local/poudriere/data/logs/bulk/FBSDFSSDjail-default/2017-11-29_03h45m= 33s More context: FreeBSD is running under a Windows 10 Pro Hyper-V virtual machine. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Dec 1 07:53:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25CA6DEF0FC; Fri, 1 Dec 2017 07:53:03 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCDAC750F0; Fri, 1 Dec 2017 07:53:02 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f54.google.com with SMTP id f18so10714801lfg.8; Thu, 30 Nov 2017 23:53:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GLZUVxOEDKVCCpqyxSvojZQwJrDB8VdXbktkBa1QxoI=; b=B8PxrjN4FmvRJc5WqPPh5rfXLOW3UQcUqZAxniPobSHgqFlT8RF31ALc8kxUcZJgkb X4BNEZNYyPqX9jylwQdmI4O5dy0lPukNmK6+qJnqC8Cy7lQszd2orSUD/wrN3xJKg14M 65nR/r+Sh3pfl86zjcEr1toBEm8ZIxrB10Z2N3B+hciA/YR4ONYm8ODTe678ZeZf8toR 4DX4jZZRzp304fTIVG6uRusXNsj7jIIptHlXpAYSwSh6aTn4YZopKknuSqCdjJ2WtWp+ 6/ap19UJ8cxG7nKgt1IYl5/oBZaSO0gQoi438LmrOu80k6Z8zgG49slGAqCJQ2fht5j2 n6+Q== X-Gm-Message-State: AJaThX7gudVVRpOjjnzQy1B71uC8+/d2UojaonxWUUDX+TC6fHRGcMxj VtHKYs1dnxw8UIGjxYPVoweDKDK/QnI= X-Google-Smtp-Source: AGs4zMY/1zXKPfMDCM043B5/26d5nRUZ0YINZJrus1R8ZyG65LC8NNl8z8UmJflINWSOcNDmxUVmNg== X-Received: by 10.46.2.197 with SMTP id y66mr4430199lje.113.1512114281788; Thu, 30 Nov 2017 23:44:41 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id x20sm1165813ljd.88.2017.11.30.23.44.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 23:44:40 -0800 (PST) Subject: Re: dmesg -a shows "Failed to fully fault in a core file segment at VA" examples, anything to worry about? To: Mark Millard , FreeBSD Current , freebsd-hackers References: <4D8DB370-AC0F-40F8-B5FC-213D5A3409FD@dsl-only.net> From: Andriy Gapon Message-ID: Date: Fri, 1 Dec 2017 09:44:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <4D8DB370-AC0F-40F8-B5FC-213D5A3409FD@dsl-only.net> 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.25 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, 01 Dec 2017 07:53:03 -0000 On 30/11/2017 23:04, Mark Millard wrote: > The messages seem to be considered non-fatal at the system > level, although the processes are getting signal 11. It is > not clear to me if the signal 11's are consequences, causes, > or just happen to be associated. The messages are produced if there is a problem while writing a core file. So, they can appear only if (after) a process crashed. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri Dec 1 13:51:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32A18E56A32 for ; Fri, 1 Dec 2017 13:51:57 +0000 (UTC) (envelope-from prvs=50180d265=roger.pau@citrix.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFFE30F8 for ; Fri, 1 Dec 2017 13:51:57 +0000 (UTC) (envelope-from prvs=50180d265=roger.pau@citrix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1C3BAE56A31; Fri, 1 Dec 2017 13:51:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BCE7E56A30 for ; Fri, 1 Dec 2017 13:51:57 +0000 (UTC) (envelope-from prvs=50180d265=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.ctxuk.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8931130F5 for ; Fri, 1 Dec 2017 13:51:55 +0000 (UTC) (envelope-from prvs=50180d265=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.45,344,1508803200"; d="scan'208";a="64079334" Date: Fri, 1 Dec 2017 13:50:39 +0000 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Roger Pau =?iso-8859-1?Q?Monn=E9?= CC: "Herbert J. Skuhra" , Subject: Re: bootonly release target not creating etc/ssh/ Message-ID: <20171201135039.ckrnje7quf7eeuip@MacBook-Pro-de-Roger.local> References: <20171109175552.dqrcgpa5uqkmsztw@dhcp-3-128.uk.xensource.com> <87o9obrpsi.wl-herbert@mailbox.org> <20171110091232.pa7nx4tivaizuous@dhcp-3-128.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171110091232.pa7nx4tivaizuous@dhcp-3-128.uk.xensource.com> User-Agent: NeoMutt/20171027 X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 13:51:57 -0000 On Fri, Nov 10, 2017 at 09:12:32AM +0000, Roger Pau Monné wrote: > On Fri, Nov 10, 2017 at 12:33:01AM +0100, Herbert J. Skuhra wrote: > > On Thu, 09 Nov 2017 18:55:52 +0100, > > Roger Pau Monné wrote: > > > > > > Hello, > > > > > > Since recently it seems like the bootonly release make target doesn't > > > create the etc/ssh directory. I've usually done: > > > > > > # make buildworld > > > # make buildkernel > > > # make -C release ftp > > > # make -C release bootonly > > > # cp release/bootonly/etc/ssh/ > > > > > > But the ssh directory doesn't seem to exist anymore. Is this expected? > > > > Hi, > > > > on my system the files are no longer in $SRCPATH/release but in > > /usr/obj/$SRCPATH/$TARGET.$TARGET_ARCH/release: > > > > $ ls -l /usr/obj/usr/home/herbert/source/freebsd/head/src/amd64.amd64/release/bootonly/etc/ssh > > total 54 > > -rw-r--r-- 1 root wheel 553185 10 Nov 00:26 moduli > > -rw-r--r-- 1 root wheel 1780 10 Nov 00:26 ssh_config > > -rw-r--r-- 1 root wheel 3359 10 Nov 00:26 sshd_config > > > > > > Not sure if this is expected, a bug or PBKAC. :) > > Thanks! The main problem is that the flow specified above is run > inside of a script, that should be able to build images pre/post > whatever changeset that modified this behavior. IMHO there should be > a way to restore previous behavior. FWIW, the previous behavior can be restored by using -DWITHOUT_AUTO_OBJ, ie: # make -C release bootonly -DWITHOUT_AUTO_OBJ Roger. From owner-freebsd-current@freebsd.org Fri Dec 1 19:43:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E23DE68BE8 for ; Fri, 1 Dec 2017 19:43:08 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::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 890CE6E205 for ; Fri, 1 Dec 2017 19:43:08 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.208] (cpe-75-82-192-14.socal.res.rr.com [75.82.192.14]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 15477760 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 1 Dec 2017 11:42:56 -0800 (PST) To: FreeBSD Current From: Pete Wright Subject: Error attempting to link during buildworld Message-ID: <520eb756-6d01-23d2-3321-b3db6dc3438c@nomadlogic.org> Date: Fri, 1 Dec 2017 11:43:06 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 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.25 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, 01 Dec 2017 19:43:08 -0000 Hi All, I am running into this error when attempting to buildworld from a checkout I made recently (git hash 76ca06b62f3bfb21f1f2e1295eb89e3c235bdda7) --- all_subdir_stand --- /usr/home/pete/git/freebsd/stand/i386/libi386/libi386.a(bootinfo64.o): In function `bi_checkcpu': /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:149: undefined reference to `read_eflags' /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:150: undefined reference to `write_eflags' /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:151: undefined reference to `read_eflags' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [loader.sym] Error code 1 Has anyone else seen this?  I'm not sure if I have some stale files that need to be purged, or if this is a bug due to me using ccache.  I'm asking here tho as I'd love to preserve my ccache and save some cycles rebuilding LLVM :) Cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Fri Dec 1 21:50:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FF45E6BD4A for ; Fri, 1 Dec 2017 21:50:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B72A5724F9 for ; Fri, 1 Dec 2017 21:50:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x229.google.com with SMTP id u42so14794474qte.7 for ; Fri, 01 Dec 2017 13:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uWIewsoVuQlZiS/UR4a7GOydBK9vZ7E3PxwWZhk1i8k=; b=fgaPjAG7FrtmvP6F98QlPFcxVraJo/GKeTbxEWW5EA8IaHbMIJUZAolr6KdM4h636t RRhdZ+Hwmx5GXsQkqw+nZHpTrfx04QmTtz9+HoSKosNpossTgTDSROeU1ZsAf46eUSC4 m1IaWS2DwrlwiakcKJVvv6dZ9Tlyg9WT+bJinZpaOf5OGwNvZFm7R5xXKhogxqDKoYDe u2mvjiME1yAngG8tS2CFNuB4Jdq3hlIAX+aZFZxBuXJ/TsxW/gQ3BCFCdXvQ6hw3W6Qs i/HuKGNGEAoWdnfXMMlmVqXKsDY+0bargYLm8d2z/XuQzFWFzI/GKo9PPgzcMvXf5PQJ MFtg== 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=uWIewsoVuQlZiS/UR4a7GOydBK9vZ7E3PxwWZhk1i8k=; b=Mjnzl/3dxBzVbNy/SlM0gEbMF0pilB8+SPD7NI9pzIdABDiAfQ+dpAQGMgm3sVgrY6 ux5F3O7yMfw1nZf5JWmYGU7a7mtH1SdRPuMlu8FdRPYDTofIam81X/fXpPo6RuAOYFrd yFsOrnjEwwx/uFhF7LLF/lR3Yoznos/6t5LAWO587jNiAE+fIvKaPOcW09dq11BqspMv KkVdYdjbq2JH9wRGm7BSFAFatgbVZgIJvD02aUqLET26MoLgRxMnYH7s0i5eKpGZhVMi vXZxsx+8X/f1U1+XMb0oDava9ut5VUcmKC4zmJRicCsM/2ZxTt2mLA9ZwM01M4suglr0 W/OQ== X-Gm-Message-State: AKGB3mLqZszAREvOmJ/Fs8wfsOmXpbMlubQ0+anHxB+WN3Ws/btfItDO zAZRQuSbbGJN0xea2P5qG6XJ2n/Ap8Q= X-Google-Smtp-Source: AGs4zMYyTb2MWV0Ss5tcHSYzSvCKYdUl3gpbdr/F2MB+U15LzmayoF5tBPReTUzaIm2syp3h0hdoqw== X-Received: by 10.200.42.122 with SMTP id l55mr8900627qtl.66.1512165023548; Fri, 01 Dec 2017 13:50:23 -0800 (PST) Received: from mutt-hbsd (tor-exit4-readme.dfri.se. [171.25.193.78]) by smtp.gmail.com with ESMTPSA id n64sm5188341qkf.49.2017.12.01.13.50.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Dec 2017 13:50:21 -0800 (PST) Date: Fri, 1 Dec 2017 16:49:55 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yaae3ulvhny5nors" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 21:50:25 -0000 --yaae3ulvhny5nors Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: >=20 > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb > > wrote: > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb >> > > >> > wrote: > >> > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > >> shawn.webb@hardenedbsd.org> > >> > > > wrote: > >> > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapsho= t, > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots = up > >> to > >> > > > > this line: > >> > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > >> > > > > >> > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > >> > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > >> > > > >> > > It also happens on latest HEAD, so it would appear to still be bro= ken. > >> > > >> > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing = the > >> > latter, but wanted to make sure. If so, then we're past the point wh= ere > >> > boot1.efi would have failed (besides, it was fixed before that > >> snapshot). > >> > >> With DEBUG turned on for stand/fdt: > >> > >> Booting [/boot/kernel/kernel]... > >> fdt_copy(): fdt_copy va 0x01208000 > >> fdt_setup_fdtp(): fdt_setup_fdtp() > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > >> Using DTB provided by EFI at 0x801fe00000. > >> Loaded the platform dtb: 0x81f56f1630. > >> fdt_fixup(): fdt_fixup() > >> > >> ^ hangs after that message > > > > > > That doesn't sound like anything I've changed, but it could well be... I > > think to find this breakage, you may need to bisect backwards along sta= nd / > > sys/boot until we find the spot where it broke. > > >=20 > There's been several conversations on IRC about how others are hitting a > scheduler bug, at least on x86. hps' fix seems to do the trick for their > issues. >=20 > Author: hselasky > Date: Wed Nov 29 23:28:40 2017 +0000 >=20 > The sched_add() function is not only used when the thread is initially > started, but also by the turnstiles to mark a thread as runnable for > all locks, for instance sleepqueues do: > setrunnable()->sched_wakeup()->sched_add() >=20 > In r326218 code was added to allow booting from non-zero CPU numbers > by setting the ts_cpu field inside the ULE scheduler's sched_add() > function. This had an undesired side-effect that prior sched_pin() and > sched_bind() calls got disregarded. This patch fixes the > initialization of the ts_cpu field for the ULE scheduler to only > happen once when the initial thread is constructed during system > init. Forking will then later on ensure that a valid ts_cpu value gets > copied to all children. >=20 > Reviewed by: jhb, kib > Discussed with: nwhitehorn > MFC after: 1 month > Differential revision: https://reviews.freebsd.org/D13298 > Sponsored by: Mellanox Technologies >=20 >=20 > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >=20 > is the fix.... But the bug it fixes post-dates the snapshot, so maybe this > isn't the same thing... Definitely is not the same thing. I've so far got it printf'd to where the uefi loader jumps into the kernel's entry point. So the loader itself might be fine. Something in the kernel, then, is going funky. Booting in verbose mode does not provide any additional input. Here's the output I get (some of the output is from printf's I've done): FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7e0a78 data=3D0xaad80+0x443f62 syms=3D[0x8+0x1= 0ec78+0x8+0x1021d4] /boot/entropy size=3D0x1000 /boot/kernel/zfs.ko text=3D0x99070 text=3D0x130390 data=3D0x21ff8+0x9ef98 s= yms=3D[0x8+0x22c68+0x8+0x1b99b] /boot/kernel/opensolaris.ko text=3D0x1330 text=3D0xd00 data=3D0x10160+0x125= d0 syms=3D[0x8+0xff0+0x8+0x8d8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x801fe00000. fdt_copy returned. dtb_size is 9060. bi_load finished. err: 0 dev_cleanup finished About to call into the entry point at 0x81ee601000 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --yaae3ulvhny5nors Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlohzoEACgkQaoRlj1JF bu4hQRAAgL0VhELWc/KkhQSEHEN1x44yfRuqBIeWSz39SLqA5g+YTnpheJ8KSfo4 QAjt1tKYZPaq+y5Q1sWDhF2y5G2TCIptmwZ3g3ks0FkrhAV7F7bPPWqL94WP4yZz PDJtzIWMiSEh/2mBAAsT2PpJiYaEoc+bEs6QqFB+xM/LK/4rTfZkmJVDR35eoBoh e/6SIJy5zc9bD/dbVlpwkJSXMk+kwB6aLNnXw13F09s6OXMe8sia2kfOAF6WUG+R OWAIldEVIdHLr1m4SYe6jzgiTEx1+IasHGVQN8NdlkCQhdQIaiAYEOIq84tewqsX +pEM1uSqwsyaOZybn+Rlbc/p4VhCIUf60lLwbZqyz6r6zZ7SJ1nmFNPJCHHZqlhM 04mcWR8pNP8CXvACZ0DAE3zIjiDI2zifany2oMKMxa536e5bqUImJrcVo1jPhZ7X 0BlY2yJm6SIYTObSK2EmSZc3w8NLkgFj5AQHJYuhMz8Cb1FirSxYxffdHHyU9UqF 1y4Rf09Is2l8vPsMVIXfHcyD5Ttxi4Y6ixmpj+d4NZS8bLgPQLUn3imvZRZ9BkX8 AG67PhTvfYAKFuU0bVjQEc4aOQw8E3+0OBaf6Qi5wOdpKWH2+CuuTlUPMDQzAqJT TUlfsTuwUyVEHmxNfRDKvG6OqIem0+r933CJ7r8sEu5eN3x68VM= =wEoZ -----END PGP SIGNATURE----- --yaae3ulvhny5nors-- From owner-freebsd-current@freebsd.org Fri Dec 1 21:53:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79A94E6C0F5 for ; Fri, 1 Dec 2017 21:53:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3894672987 for ; Fri, 1 Dec 2017 21:53:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id w127so12759500iow.11 for ; Fri, 01 Dec 2017 13:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v0J7ha1Llo4zf5t0skenV3NOwG8sqBvKamPXAMxqDTY=; b=Bk4fjPgrxHanYjQNZUZIUfucOWzIpzlM+CSUes2s/zfsZ7G5UELlnkZ7YSZFQI34mr Slc9dA0JoHOBSF5sagetp6VQrnKgC9EXTYLKdWe4SCuaUJT2fxQuOSM/uet5kGSaVI1g HbVzP2y+BSuGiaEpz+QSYmRXusLPjUehTmA5oXPBFKUCBLfh7QYgrMoHRd4GLnjNv/5S h9Xkd1QFJb0+OSr3nVWE5qPob9t9d6n98A6q1NMxwSr082VBe/tRjYhzpb72iBDoDyEh 2HEIiwVnzgIuKHdJTF+Z4dFq/Uihi5FfNMMRy9WeW6SdsnlGMHDZP1avTwOxtw5Aht5B XOWg== 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=v0J7ha1Llo4zf5t0skenV3NOwG8sqBvKamPXAMxqDTY=; b=hoCI2psLneios2TgX2fHdCQH6xFc6xKUjhYqxcznydlsSeQOCuYcow/mV8U8cxWr3M GiSdqD/fUBHdtXNTCRpaa9pCxazOND4ke91v6Su2wPAqbTxZKdmQ805aZ1ms+rIfWlOC i3LunWULm4+iErQW63xsxKHgkYIpJ/bO10dR8erPRHoXbomDf9qylCa+zHGqMwl0FoJB RvfmKTclXi1hHb6SIEYif14JAmiebYxB5WL8M7oVEPjeRyQzXMJ1nx2N3VNCgdETBLtL Uns78PfI1c5nZV/2/m9h+jobFqrjT6Ftx3iIe6y2hw04Qn6P/0aRDlFM7kPYsJ+6HQLe YxMg== X-Gm-Message-State: AKGB3mLw38duPq5EN2Ga2BrXmKwOnBR+7/asdcT3IY0udatz6sLHFrjF vCn1WBkpk/XcgFCW+Y7mWEWjq2+eGG+NN7PJxLIA7g== X-Google-Smtp-Source: AGs4zMYShFlbLx5OCs+EKA2fCcAUKtFC8BpnU3TvWA6BmZJL7HVd3gqdhcnuU0Pw5n6fSQ9AjrgvAsQIRA7rdBeqgz8= X-Received: by 10.107.52.140 with SMTP id b134mr1715801ioa.291.1512165234381; Fri, 01 Dec 2017 13:53:54 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 1 Dec 2017 13:53:53 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> From: Warner Losh Date: Fri, 1 Dec 2017 14:53:53 -0700 X-Google-Sender-Auth: GnENBzzMvPJUa1FIQuWQfhGN_FQ Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 21:53:55 -0000 On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > shawn.webb@hardenedbsd.org> > > > wrote: > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > shawn.webb@hardenedbsd.org > > >> > > > >> > wrote: > > >> > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > >> shawn.webb@hardenedbsd.org> > > >> > > > wrote: > > >> > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > snapshot, > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots > up > > >> to > > >> > > > > this line: > > >> > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > >> > > > > > >> > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > >> > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.img > > >> > > > > >> > > It also happens on latest HEAD, so it would appear to still be > broken. > > >> > > > >> > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guessing > the > > >> > latter, but wanted to make sure. If so, then we're past the point > where > > >> > boot1.efi would have failed (besides, it was fixed before that > > >> snapshot). > > >> > > >> With DEBUG turned on for stand/fdt: > > >> > > >> Booting [/boot/kernel/kernel]... > > >> fdt_copy(): fdt_copy va 0x01208000 > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > >> Using DTB provided by EFI at 0x801fe00000. > > >> Loaded the platform dtb: 0x81f56f1630. > > >> fdt_fixup(): fdt_fixup() > > >> > > >> ^ hangs after that message > > > > > > > > > That doesn't sound like anything I've changed, but it could well be... > I > > > think to find this breakage, you may need to bisect backwards along > stand / > > > sys/boot until we find the spot where it broke. > > > > > > > There's been several conversations on IRC about how others are hitting a > > scheduler bug, at least on x86. hps' fix seems to do the trick for their > > issues. > > > > Author: hselasky > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > The sched_add() function is not only used when the thread is > initially > > started, but also by the turnstiles to mark a thread as runnable for > > all locks, for instance sleepqueues do: > > setrunnable()->sched_wakeup()->sched_add() > > > > In r326218 code was added to allow booting from non-zero CPU numbers > > by setting the ts_cpu field inside the ULE scheduler's sched_add() > > function. This had an undesired side-effect that prior sched_pin() > and > > sched_bind() calls got disregarded. This patch fixes the > > initialization of the ts_cpu field for the ULE scheduler to only > > happen once when the initial thread is constructed during system > > init. Forking will then later on ensure that a valid ts_cpu value > gets > > copied to all children. > > > > Reviewed by: jhb, kib > > Discussed with: nwhitehorn > > MFC after: 1 month > > Differential revision: https://reviews.freebsd.org/D13298 > > Sponsored by: Mellanox Technologies > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > this > > isn't the same thing... > > Definitely is not the same thing. I've so far got it printf'd to where > the uefi loader jumps into the kernel's entry point. So the loader > itself might be fine. Something in the kernel, then, is going funky. > > Booting in verbose mode does not provide any additional input. > > Here's the output I get (some of the output is from printf's I've > done): > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x7e0a78 data=0xaad80+0x443f62 > syms=[0x8+0x10ec78+0x8+0x1021d4] > /boot/entropy size=0x1000 > /boot/kernel/zfs.ko text=0x99070 text=0x130390 data=0x21ff8+0x9ef98 > syms=[0x8+0x22c68+0x8+0x1b99b] > /boot/kernel/opensolaris.ko text=0x1330 text=0xd00 data=0x10160+0x125d0 > syms=[0x8+0xff0+0x8+0x8d8] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x801fe00000. > fdt_copy returned. dtb_size is 9060. > bi_load finished. err: 0 > dev_cleanup finished > About to call into the entry point at 0x81ee601000 > You might try booting the same kernel off a small UFS partition. There's a tiny chance that the loader didn't load it right, but more likely the kernel is borked. Maybe DTB issues? Maybe something else... A quick test like that would remove ZFS from the equation, even if it's just a USB stick... Warner From owner-freebsd-current@freebsd.org Fri Dec 1 21:55:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B595EE6C230 for ; Fri, 1 Dec 2017 21:55:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41CD572B51 for ; Fri, 1 Dec 2017 21:55:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr0-x234.google.com with SMTP id s66so11496446wrc.9 for ; Fri, 01 Dec 2017 13:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nJOil9JJd2wzxv0PujzibHIHszsTmNoZi0+vgYTIkNI=; b=iRzxmD6TFpJGZWstvKPfw7o/3DXLnHbRsZ7C6entpQpqcmr4GV4HGoPqwRhDzBC9O5 1xdTnogad0SKni4yJFe5L8fHgHrLLrYq/vtJfKmihlrH6QzCwL0ADU9sjCxAbTBa9PmQ dAqp5bmKPjWCLZWmu333zQaYD8K0laGjQdTBgNXw7RyvLfUQmMv7dqLLOiv8OZQ6/hex wS9/Eersxns2j8AfRtlUXQM0Lp4drKMbGgDh5OnEUqLhKCV1ANaaw1cZvfOvKD35syQb 1kXpTRLrHxF2B5xXA46T+tilKSor8tWZ1vQ8gdMfy36/CAHHCr5rRhbFqivUtPL5GXoC hURg== 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=nJOil9JJd2wzxv0PujzibHIHszsTmNoZi0+vgYTIkNI=; b=OEALlS+47Z0+yjuWeYrSyOg7R6ivn2b8AI6OeZ7+LntB8OLh5N0fzLTI7lzJAZ/5Do aGkPtUAvVBg8yqnGBM4gUWz4ZdyKnekiO9uFOCWu/W3otLgbban/TldDmCTt+goop84b sFNpoikZT3pr/zxa/SuWKm5bJjgAtwCQjIM+DDFkZyCSJdbvepb19qA9wgHfQ4Fwa1Kp nntmOf6DxFTYFrIUOlRD7VdR9AZxG3KY9tl/Eesnu7gC0OhRZdAIfjkPsL2XNBWILzP1 9sjJTWXJgpk/hO9g5f08LEHNIpKLCWJkTD7T7OaIVXJoNo4A0GhP5VDUzxeF1saHL5di v9kA== X-Gm-Message-State: AJaThX5KcHwq7DnwyVSDJglb5dhsdzEU/HSsFv3BjtTU1zQB2cApTUo/ 9JaIdqEcqUW6jY4GrNpCAI94BQ== X-Google-Smtp-Source: AGs4zMaeFPtHlWM8CsbCG5O8VgGKuoaIoAo6NGU2RkkhrE77NOsmN6WPTzLFf1fWbc/4xruckP6kXQ== X-Received: by 10.223.202.1 with SMTP id o1mr2132835wrh.233.1512165357151; Fri, 01 Dec 2017 13:55:57 -0800 (PST) Received: from mutt-hbsd ([65.19.167.130]) by smtp.gmail.com with ESMTPSA id h7sm6844047wrb.35.2017.12.01.13.55.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Dec 2017 13:55:56 -0800 (PST) Date: Fri, 1 Dec 2017 16:55:31 -0500 From: Shawn Webb To: Warner Losh Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Subject: Re: Booting UEFI ZFS is broken on arm64 Message-ID: <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yxqbpbqi3jogdpsy" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 21:55:59 -0000 --yxqbpbqi3jogdpsy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 01, 2017 at 02:53:53PM -0700, Warner Losh wrote: > On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb > wrote: >=20 > > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > > shawn.webb@hardenedbsd.org> > > > > wrote: > > > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > > shawn.webb@hardenedbsd.org > > > >> > > > > >> > wrote: > > > >> > > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > > >> shawn.webb@hardenedbsd.org> > > > >> > > > wrote: > > > >> > > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > > snapshot, > > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It bo= ots > > up > > > >> to > > > >> > > > > this line: > > > >> > > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > > >> > > > > > > >> > > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > > >> > > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056-memstick.i= mg > > > >> > > > > > >> > > It also happens on latest HEAD, so it would appear to still be > > broken. > > > >> > > > > >> > > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm guess= ing > > the > > > >> > latter, but wanted to make sure. If so, then we're past the point > > where > > > >> > boot1.efi would have failed (besides, it was fixed before that > > > >> snapshot). > > > >> > > > >> With DEBUG turned on for stand/fdt: > > > >> > > > >> Booting [/boot/kernel/kernel]... > > > >> fdt_copy(): fdt_copy va 0x01208000 > > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > > >> Using DTB provided by EFI at 0x801fe00000. > > > >> Loaded the platform dtb: 0x81f56f1630. > > > >> fdt_fixup(): fdt_fixup() > > > >> > > > >> ^ hangs after that message > > > > > > > > > > > > That doesn't sound like anything I've changed, but it could well be= =2E.. > > I > > > > think to find this breakage, you may need to bisect backwards along > > stand / > > > > sys/boot until we find the spot where it broke. > > > > > > > > > > There's been several conversations on IRC about how others are hittin= g a > > > scheduler bug, at least on x86. hps' fix seems to do the trick for th= eir > > > issues. > > > > > > Author: hselasky > > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > > > The sched_add() function is not only used when the thread is > > initially > > > started, but also by the turnstiles to mark a thread as runnable = for > > > all locks, for instance sleepqueues do: > > > setrunnable()->sched_wakeup()->sched_add() > > > > > > In r326218 code was added to allow booting from non-zero CPU numb= ers > > > by setting the ts_cpu field inside the ULE scheduler's sched_add() > > > function. This had an undesired side-effect that prior sched_pin() > > and > > > sched_bind() calls got disregarded. This patch fixes the > > > initialization of the ts_cpu field for the ULE scheduler to only > > > happen once when the initial thread is constructed during system > > > init. Forking will then later on ensure that a valid ts_cpu value > > gets > > > copied to all children. > > > > > > Reviewed by: jhb, kib > > > Discussed with: nwhitehorn > > > MFC after: 1 month > > > Differential revision: https://reviews.freebsd.org/D13298 > > > Sponsored by: Mellanox Technologies > > > > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > > this > > > isn't the same thing... > > > > Definitely is not the same thing. I've so far got it printf'd to where > > the uefi loader jumps into the kernel's entry point. So the loader > > itself might be fine. Something in the kernel, then, is going funky. > > > > Booting in verbose mode does not provide any additional input. > > > > Here's the output I get (some of the output is from printf's I've > > done): > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > > EFI boot environment > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=3D0x7e0a78 data=3D0xaad80+0x443f62 > > syms=3D[0x8+0x10ec78+0x8+0x1021d4] > > /boot/entropy size=3D0x1000 > > /boot/kernel/zfs.ko text=3D0x99070 text=3D0x130390 data=3D0x21ff8+0x9ef= 98 > > syms=3D[0x8+0x22c68+0x8+0x1b99b] > > /boot/kernel/opensolaris.ko text=3D0x1330 text=3D0xd00 data=3D0x10160+0= x125d0 > > syms=3D[0x8+0xff0+0x8+0x8d8] > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by EFI at 0x801fe00000. > > fdt_copy returned. dtb_size is 9060. > > bi_load finished. err: 0 > > dev_cleanup finished > > About to call into the entry point at 0x81ee601000 > > >=20 > You might try booting the same kernel off a small UFS partition. There's a > tiny chance that the loader didn't load it right, but more likely the > kernel is borked. Maybe DTB issues? Maybe something else... A quick test > like that would remove ZFS from the equation, even if it's just a USB > stick... UFS works fine and dandy. It's ZFS that's b0rked. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --yxqbpbqi3jogdpsy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlohz9IACgkQaoRlj1JF bu4oXw/9EOPJzkBWeiYIsnLFVg05wSQVIIuMyhYE/oEmnY0lK5H+muPK6t9ETqM+ AVEGxjEpmgeOCkzt3tOOrC5jul/PSR/XGpmVi68ho5KEbuOFD+UPjtN50cZJraSD Uusjl8jtFWBDAybQ78O43XIrr2710NQ0PTbeZYJouQnTvLz+MkVhMgKF37YglZOK 4CLqEMzEqwNIxj/tKRvJt+G6NB12xpN3mp8w9Svq/G10v7GjxZC7ikqsd5FLH6iP hWpyqqRtoucbCpn66Ahc98c32EHpMvwx2XffsddWb8g1Z/dSjxAD1j7mBLLHBVbV 1e/CB5S7Fyexei66/UZ47q0ZIqTtVGwhYE1LqMVdvLUimhtd4t06nWJeRGUDrr0C NZuLRBOUiY8suaI5oYizyg84m4hjfCoEK27Hye5aYizF6gAh/eodllfm7YHde+oT Nos1YTb2/axrS60ibUdhom3a1gD1TvUqVVkrdRCf1+ds0RfIgAHiAAsZ9qogEoIP PBeumYz6+4Waq44VUjD1QKoEy9AG6yj0plLp/n/Dt6AoViM0nOT4puYMuhbgps+i RjBIjn8JiToBYsNppn3Gv7GTn7vwEiqU2OyfFs4CH8SZ6MIvhhLOrQ16B8BuBEGm 7erXmEi8ZtfOZHtJ6MZlJTXj48OYP1TwUuvVwuvEmPAO9LF4Mqk= =+uXh -----END PGP SIGNATURE----- --yxqbpbqi3jogdpsy-- From owner-freebsd-current@freebsd.org Fri Dec 1 21:57:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F007BE6C384 for ; Fri, 1 Dec 2017 21:57:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A291272D1C for ; Fri, 1 Dec 2017 21:57:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id u42so12771177ioi.9 for ; Fri, 01 Dec 2017 13:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L/djtXyGqNW5OYK2j4g158lvJMlJeskAGwvn9f0JbPw=; b=Xar4QR37b3bWHwQOjkJn6bCogtURFqzKEkqG1r4Te9Q+HLXFSLWSDF0WrskbFFtwfN H+9I+REtPuhbDjObme8KG6ICQIf/OgRdAcZn7VlRU4g/7itmjunlNrIj4GOu5oPeId6j pxZO2FkEvQJoUzbEqewwas4Om1bF94+EC+pv50BVbgI5hLyJ7Yw/y3H5+3QelgI/cUWW SSsp9W2lrke1x+oFHhTEbLqiyiqcdfd48ZTCq2//WA4zf2xHrKO2ijN3XeEhpzJOpfOg fDLOA4bqpBL6VLwlhZt/85o9AK0QQcCbqMgxfpnfXiEaIheoW8KbQEDiX3Jt3iqJ8O8U Cqrw== 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=L/djtXyGqNW5OYK2j4g158lvJMlJeskAGwvn9f0JbPw=; b=VfYUTMs0SJXWz8Bz2PijpiZmzatK7BmkitT2l4gBueiCBgvF2CuPeG8d+UzviJQSVS 79+KatiRkajZkpBQlLjAqb6IuDzknSfOofpsPbYpBKG1henwggDKcgKqkkVMIn2Jrnkq N+sui48e3JDuifXlwhB9qD4nv8g3qoqPUTjML67t+TCy0NvpC+SdwbbMTysqCrvwv4Lt ujFbuMWbTOf2tkgwi/BAdthaD0AIkywM6jZeO2WlJAcqY8gBnHbQehuRl/4vc3Q0can+ xPBPSTHRiwkdihpN/p9CiYmRDeoF2QvuKy+ANK3UV5ch4aLmWBTA3G/im1GHA7DEeSbF wNcw== X-Gm-Message-State: AJaThX5fy8p27wXHv72z1k76gxLdWhv8thK4tOjBUKKpkhdBZN0DhAB9 lF5FtQ/Z0M5K0jdO7dCCQftCPSZIKeNHd6PtqlkqIw== X-Google-Smtp-Source: AGs4zMabXjER7YVIk99RjzfaQbftntnxWdQL69xuf9YkPvPmYOGNuPXUxjA672vurMpVy3szbk8/wAX+Fw6czM/yHn0= X-Received: by 10.107.104.18 with SMTP id d18mr13338163ioc.136.1512165455760; Fri, 01 Dec 2017 13:57:35 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 1 Dec 2017 13:57:35 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> <20171130003458.bnltotlgfdbke5ue@mutt-hbsd> <20171130004358.usia2jrvman4cvvz@mutt-hbsd> <20171201214955.zopa6v2f2mx3rkt2@mutt-hbsd> <20171201215531.u4f2c4eno7z5irxj@mutt-hbsd> From: Warner Losh Date: Fri, 1 Dec 2017 14:57:35 -0700 X-Google-Sender-Auth: xsnz_U60W-SoNe8P-kPUqgVwzR8 Message-ID: Subject: Re: Booting UEFI ZFS is broken on arm64 To: Shawn Webb Cc: "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 21:57:37 -0000 On Fri, Dec 1, 2017 at 2:55 PM, Shawn Webb wrote: > On Fri, Dec 01, 2017 at 02:53:53PM -0700, Warner Losh wrote: > > On Fri, Dec 1, 2017 at 2:49 PM, Shawn Webb > > wrote: > > > > > On Wed, Nov 29, 2017 at 07:31:17PM -0700, Warner Losh wrote: > > > > On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb < > > > shawn.webb@hardenedbsd.org> > > > > > wrote: > > > > > > > > > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > > > >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb < > > > shawn.webb@hardenedbsd.org > > > > >> > > > > > >> > wrote: > > > > >> > > > > > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > > >> > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb < > > > > >> shawn.webb@hardenedbsd.org> > > > > >> > > > wrote: > > > > >> > > > > > > > >> > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 > > > snapshot, > > > > >> > > > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It > boots > > > up > > > > >> to > > > > >> > > > > this line: > > > > >> > > > > > > > > >> > > > > Using DTB provided by EFI at 0x801fe00000. > > > > >> > > > > > > > >> > > > > > > > >> > > > Which snapshot is that? Boot1 was broken until recently. > > > > >> > > > > > > >> > > FreeBSD-12.0-CURRENT-arm64-aarch64-20171121-r326056- > memstick.img > > > > >> > > > > > > >> > > It also happens on latest HEAD, so it would appear to still be > > > broken. > > > > >> > > > > > >> > > > > > >> > Is this boot1.efi producing the output, or loader.efi? I'm > guessing > > > the > > > > >> > latter, but wanted to make sure. If so, then we're past the > point > > > where > > > > >> > boot1.efi would have failed (besides, it was fixed before that > > > > >> snapshot). > > > > >> > > > > >> With DEBUG turned on for stand/fdt: > > > > >> > > > > >> Booting [/boot/kernel/kernel]... > > > > >> fdt_copy(): fdt_copy va 0x01208000 > > > > >> fdt_setup_fdtp(): fdt_setup_fdtp() > > > > >> fdt_load_dtb_addr(): fdt_load_dtb_addr(0x801fe00000) > > > > >> Using DTB provided by EFI at 0x801fe00000. > > > > >> Loaded the platform dtb: 0x81f56f1630. > > > > >> fdt_fixup(): fdt_fixup() > > > > >> > > > > >> ^ hangs after that message > > > > > > > > > > > > > > > That doesn't sound like anything I've changed, but it could well > be... > > > I > > > > > think to find this breakage, you may need to bisect backwards along > > > stand / > > > > > sys/boot until we find the spot where it broke. > > > > > > > > > > > > > There's been several conversations on IRC about how others are > hitting a > > > > scheduler bug, at least on x86. hps' fix seems to do the trick for > their > > > > issues. > > > > > > > > Author: hselasky > > > > Date: Wed Nov 29 23:28:40 2017 +0000 > > > > > > > > The sched_add() function is not only used when the thread is > > > initially > > > > started, but also by the turnstiles to mark a thread as runnable > for > > > > all locks, for instance sleepqueues do: > > > > setrunnable()->sched_wakeup()->sched_add() > > > > > > > > In r326218 code was added to allow booting from non-zero CPU > numbers > > > > by setting the ts_cpu field inside the ULE scheduler's > sched_add() > > > > function. This had an undesired side-effect that prior > sched_pin() > > > and > > > > sched_bind() calls got disregarded. This patch fixes the > > > > initialization of the ts_cpu field for the ULE scheduler to only > > > > happen once when the initial thread is constructed during system > > > > init. Forking will then later on ensure that a valid ts_cpu value > > > gets > > > > copied to all children. > > > > > > > > Reviewed by: jhb, kib > > > > Discussed with: nwhitehorn > > > > MFC after: 1 month > > > > Differential revision: https://reviews.freebsd.org/D13298 > > > > Sponsored by: Mellanox Technologies > > > > > > > > > > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326376 > > > > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > > > > > > > is the fix.... But the bug it fixes post-dates the snapshot, so maybe > > > this > > > > isn't the same thing... > > > > > > Definitely is not the same thing. I've so far got it printf'd to where > > > the uefi loader jumps into the kernel's entry point. So the loader > > > itself might be fine. Something in the kernel, then, is going funky. > > > > > > Booting in verbose mode does not provide any additional input. > > > > > > Here's the output I get (some of the output is from printf's I've > > > done): > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > (Wed Nov 29 21:51:14 EST 2017 shawn@hbsd-dev-laptop) > > > EFI boot environment > > > Loading /boot/defaults/loader.conf > > > /boot/kernel/kernel text=0x7e0a78 data=0xaad80+0x443f62 > > > syms=[0x8+0x10ec78+0x8+0x1021d4] > > > /boot/entropy size=0x1000 > > > /boot/kernel/zfs.ko text=0x99070 text=0x130390 data=0x21ff8+0x9ef98 > > > syms=[0x8+0x22c68+0x8+0x1b99b] > > > /boot/kernel/opensolaris.ko text=0x1330 text=0xd00 data=0x10160+0x125d0 > > > syms=[0x8+0xff0+0x8+0x8d8] > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > Using DTB provided by EFI at 0x801fe00000. > > > fdt_copy returned. dtb_size is 9060. > > > bi_load finished. err: 0 > > > dev_cleanup finished > > > About to call into the entry point at 0x81ee601000 > > > > > > > You might try booting the same kernel off a small UFS partition. There's > a > > tiny chance that the loader didn't load it right, but more likely the > > kernel is borked. Maybe DTB issues? Maybe something else... A quick test > > like that would remove ZFS from the equation, even if it's just a USB > > stick... > > UFS works fine and dandy. It's ZFS that's b0rked. OK. Let me know what you find... I assume the entry point matches with what you've loaded? Warner From owner-freebsd-current@freebsd.org Fri Dec 1 22:33:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EE23DB9135; Fri, 1 Dec 2017 22:33:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0069.outbound.protection.outlook.com [104.47.38.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92E8C74742; Fri, 1 Dec 2017 22:33:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2169.CANPRD01.PROD.OUTLOOK.COM (52.132.46.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Fri, 1 Dec 2017 22:33:25 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0282.007; Fri, 1 Dec 2017 22:33:25 +0000 From: Rick Macklem To: Emmanuel Vadot CC: Konstantin Belousov , FreeBSD Current , "freebsd-fs@freebsd.org" , John Baldwin Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Topic: Switch vfs.nfsd.issue_delegations to TUNABLE ? Thread-Index: AQHTaEyAfy6q2cCLHkW9s1ZyeaxyRaMpzDeAgAAEfyqAAB1rAIAANPobgABJSsyAAAEe3oAA8S4AgAA7/XuAA3xyQg== Date: Fri, 1 Dec 2017 22:33:25 +0000 Message-ID: References: <20171128114136.10e44d5bcfd563e9b4ab5453@bidouilliste.com> <20171128110428.GN2272@kib.kiev.ua> <20171128142610.6ab535b0b8c6b5d372cd3f27@bidouilliste.com> <20171128134009.GQ2272@kib.kiev.ua> <20171128164132.290bf07218b16164db613242@bidouilliste.com> , <20171129144040.29a10234aa5fb1cfa2611bfc@bidouilliste.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2169; 6:lWyj7vkBUH3fXtWJ2TTA2A0tMPfqDRnVXsfaCVLmLmanW8Po/nuQNmLbKqkwa4rUIfF5/rYA2UoIa/cyEEWuhIvmfU2xtBKJuYYK4vIoZhVovuvsnHsSHY5AhITwixcrlWVmDY6Kqi/+DjcdtMXcTFrLN0zVbzwTJWBgxgi9jLZa8p/jldD2wBhi17TBrotJizNbTfYUk9lxsE3BVNbbJpe6e1/3mOy+z7xdSE0vazsjWuVm/ixxvLiSCI5b/ONau6X8lVRl71f6iEXqIa4bFtndnYIvZbMtIgNAftOWwudMCWfvlJt+aQCae30HFmCOU+Vk60YRkkuOpQ4zcViDjEtdWhCCJmjAOjBU9CrCZnE=; 5:F+x51kXHcY9xV3glzJiRiR6KSteVKuhN0rUaz5d90j6/qgYVgKHjEIrQA6pJSzD4aBBzdtftbebxoSY+KN+Wt3d8Oh5hk9NAMXvEDBjjw8mAup7hPCq+oxxmoyllF15cfDUGqO0c/c2bJSRtF1rKWbLhNJ9GV0dcRRlo+0nQDFA=; 24:+QpjuEx4ikiHzJRyWDIDrrbyjCP8+nMc/vN2qkFHf/iIqhF/xxDQCvfgdQtOXGa9R6LfVPcs9EIwGx1o7oiuyIEV2/+hpiwTQ3rwZg1mK/I=; 7:i5hurOlsHVjf2Uc539srOChuTnYNE33YZQcxN6HoItnjcQw17E7SEqDA0nne+RJbvWwzjQ5ZlzYfnFAaO2gX5mGoZwWC4f3GdoT+4bs1BhqdOVGp0K4pXr8EJxmFZQX9Hj1Vh61+JAQIMgkGW0Jjiwbi2X6y20ih9sOgZJ2oDDaoQQTzvSNCDVlvhZwjMhqHVKc3zksAqFByY1yZfADs8J7GU2Wc/jDfQutFK4QeWSZG8Ooyk719ok7OYgu9encd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 85be4969-18e4-4eb5-c965-08d5390b8933 x-microsoft-antispam: UriScan:(18154293887054); BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603286); SRVR:YTOPR0101MB2169; x-ms-traffictypediagnostic: YTOPR0101MB2169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374)(18154293887054); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:YTOPR0101MB2169; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2169; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(24454002)(189002)(199003)(102836003)(2906002)(81156014)(39060400002)(99286004)(14454004)(86362001)(101416001)(53546010)(4326008)(478600001)(229853002)(6916009)(8676002)(68736007)(33656002)(106356001)(2950100002)(54356011)(3280700002)(97736004)(81166006)(7696005)(25786009)(105586002)(53936002)(9686003)(6246003)(55016002)(54906003)(316002)(74316002)(786003)(3660700001)(6506006)(5250100002)(74482002)(2900100001)(189998001)(93886005)(305945005)(5660300001)(8936002)(6306002)(76176011)(6436002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2169; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 85be4969-18e4-4eb5-c965-08d5390b8933 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 22:33:25.0839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2169 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Dec 2017 22:33:28 -0000 I have created D13327 on reviews.freebsd.org with a patch that keeps track of # of issued write delegations and allows nfsrv_checkgetattr() to return without acquiring the lock when it is 0. Hopefully kib@, jhb@ or someone who is familiar with the use of the atomic ops in the kernel can review it. (Where the counter code goes should be fine, but I am not sure I got the use of the atomic ops correct.) Hopefully Emmanuel can test the patch to see if it fixes his performance problem. rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Wednesday, November 29, 2017 12:28:05 PM To: Emmanuel Vadot Cc: Konstantin Belousov; FreeBSD Current; freebsd-fs@freebsd.org Subject: Re: Switch vfs.nfsd.issue_delegations to TUNABLE ? Emmanuel Vadot wrote: [stuff snipped] > I haven't test by I can say that it will work, I actually wondered at >first doing that. The problem with this patch is what I tried to >describe in my first and following mails, since you can turn on and off >delegation you can still have delegation (so nfsrv_delegatecnt > 0) >even if the sysctl is =3D=3D 0. That's why I went to the tunable way, seem= s >cleaner to me as disabling delegation doesn't really disable them for >current client. Yes, if you have delegations enabled and then disable them, there will be delegations issued for a "while". During that time, the code in nfsrv_checkgetattr() does need to check for them. Since no new delegations will be issued, the outstanding ones will go away when the client chooses to return them. (You can force this on the client by doing a dismount/mount, at least for the FreeBSD client.) Alternately, rebooting the server forces the clients to "recover" delegatio= ns and, if they are disabled, that fails. (Actually the recover succeeds, but = with a flag set that tells the client it must return them asap.) All the tunable does is make it impossible to disable them without rebooting, but otherwise the effect is the same. I have a patch that keeps a separate counter for write delegations (which are the ones you care about) using atomics to maintain the value. (That will be similar but somewhat better than what this patch does.= ) rick [lots more snipped] _______________________________________________ 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 Dec 2 13:54:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 976BBDFFE9A for ; Sat, 2 Dec 2017 13:54:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 8376471078 for ; Sat, 2 Dec 2017 13:54:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 7FDD8DFFE99; Sat, 2 Dec 2017 13:54:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DBB6DFFE98 for ; Sat, 2 Dec 2017 13:54:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 2D3B171077 for ; Sat, 2 Dec 2017 13:54:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il ident=exim) by kabab.cs.huji.ac.il with esmtp id 1eL83U-0003CX-B3 for current@freebsd.org; Sat, 02 Dec 2017 15:42:08 +0200 Received: from [132.65.179.42] (helo=imac.bk.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1eL83U-0002Oh-7I for current@freebsd.org; Sat, 02 Dec 2017 15:42:08 +0200 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: what happened to src/sys/boot? Message-Id: Date: Sat, 2 Dec 2017 15:42:07 +0200 To: current@freebsd.org X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 13:54:57 -0000 Hi, it seems to have disappeared. danny From owner-freebsd-current@freebsd.org Sat Dec 2 14:01:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FDE3E56176 for ; Sat, 2 Dec 2017 14:01:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBE667150A for ; Sat, 2 Dec 2017 14:00:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id E8222E56175; Sat, 2 Dec 2017 14:00:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7BDDE56174 for ; Sat, 2 Dec 2017 14:00:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B749E71509 for ; Sat, 2 Dec 2017 14:00:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id vB2E0juY089694; Sat, 2 Dec 2017 14:00:45 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vB2E0j7g089693; Sat, 2 Dec 2017 06:00:45 -0800 (PST) (envelope-from david) Date: Sat, 2 Dec 2017 06:00:45 -0800 From: David Wolfskill To: Daniel Braniss Cc: current@freebsd.org Subject: Re: what happened to src/sys/boot? Message-ID: <20171202140045.GP1229@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Daniel Braniss , current@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZRNUOYyy+Hmp9i9J" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 14:01:00 -0000 --ZRNUOYyy+Hmp9i9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 02, 2017 at 03:42:07PM +0200, Daniel Braniss wrote: > Hi, > it seems to have disappeared. > ... Ref. r325834: ------------------------------------------------------------------------ r325834 | imp | 2017-11-14 15:02:19 -0800 (Tue, 14 Nov 2017) | 4 lines Move sys/boot to stand. Fix all references to new location Sponsored by: Netflix ------------------------------------------------------------------------ Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump is an incompetent, lying bully who is unfit for any public office. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ZRNUOYyy+Hmp9i9J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaIrINXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X6kgIANW+WeVddAqnF4QD7XOJxe3y if8C6bMVl7m6PRyDVPLHQOAe2xsuDK/6corilFYblmg3nzX7VCEw2KRw6R7l9qz2 X3tgf65lwIsgTIF3m4/I30qlvI/PeMK47/6qatgo01UjP8WVoSP6QM5noKfz8Ucz cLIGYmPyfNXiGOUkhbaodiyeyrjPSIaAg2h2ElaL37lgt2qYlg3Iz6USyzQscrGj /6cu89AsoX+aI+y6aiYQUZff6qTuZewZVMUN4SVWncH1DHH6lqYVDOA//yttQ60A ldro91b0DUuKx8edP1lZhxdhrR+VHtrmoZ/Kkdp9jhSzH7fSEkdug/SXnMGfYYE= =Vq3f -----END PGP SIGNATURE----- --ZRNUOYyy+Hmp9i9J-- From owner-freebsd-current@freebsd.org Sat Dec 2 14:29:37 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94D44E56B79 for ; Sat, 2 Dec 2017 14:29:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7F96F72054 for ; Sat, 2 Dec 2017 14:29:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 7C2AEE56B78; Sat, 2 Dec 2017 14:29:37 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BC50E56B76 for ; Sat, 2 Dec 2017 14:29:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 375B172053 for ; Sat, 2 Dec 2017 14:29:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il ident=exim) by kabab.cs.huji.ac.il with esmtp id 1eL8nM-0004Me-Ko; Sat, 02 Dec 2017 16:29:32 +0200 Received: from [132.65.179.42] (helo=imac.bk.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1eL8nM-0002Y6-Hq; Sat, 02 Dec 2017 16:29:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: what happened to src/sys/boot? From: Daniel Braniss In-Reply-To: <20171202140045.GP1229@albert.catwhisker.org> Date: Sat, 2 Dec 2017 16:29:32 +0200 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <57E6D205-94E8-4975-821D-2AC3F63407F4@cs.huji.ac.il> References: <20171202140045.GP1229@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 14:29:37 -0000 > On 2 Dec 2017, at 16:00, David Wolfskill wrote: >=20 > On Sat, Dec 02, 2017 at 03:42:07PM +0200, Daniel Braniss wrote: >> Hi, >> it seems to have disappeared. >> ... >=20 > Ref. r325834: >=20 > = ------------------------------------------------------------------------ > r325834 | imp | 2017-11-14 15:02:19 -0800 (Tue, 14 Nov 2017) | 4 lines >=20 > Move sys/boot to stand. Fix all references to new location >=20 > Sponsored by: Netflix >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 >=20 grr :-), should have started my allwinner project two weeks ago. thanks, danny > Peace, > david > --=20 > David H. Wolfskill david@catwhisker.org > Trump is an incompetent, lying bully who is unfit for any public = office. >=20 > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Sat Dec 2 14:57:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70B2FE574C0 for ; Sat, 2 Dec 2017 14:57:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 51DCF72B6A for ; Sat, 2 Dec 2017 14:57:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4DE47E574BF; Sat, 2 Dec 2017 14:57:39 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BB31E574BE for ; Sat, 2 Dec 2017 14:57:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 1692572B69 for ; Sat, 2 Dec 2017 14:57:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P0C00C006Q13J00@st13p35im-asmtp002.me.com> for current@freebsd.org; Sat, 02 Dec 2017 13:57:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1512223052; bh=1bzTvvXzvpvkfPS5DJk6Z6Azh3cpnhCT/Dz1/EZXCFc=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=bQrD2iC7Ca6xTtTR/5Wljf4TQBMo+t2JqpQ9LtnLDvnKilQkln76b//M3TboKICHU ErG4cti5/AUzskrXHtAXTiUmGdfBn1J67T2MIe3R+Cswb79RljnIur9y9Hhr26KFvQ cBrP0+J/cO3Rm0Zj0nNENWfl9NvP28NpHZYMXlVfi/Vzq10eoKYduu5zmQrzaF8/rT SsMeMUqoPzCtbrPiVB9J3Z/tb/ia9K/gcSjsEOfS+xMDkcuebKE4S5cVbz9lcYL3Bv tdohvtpTZiEteZKKuqsHZHl743eqRnrSBkEECsVlGrHUH+fcEffpsdvTdigLhl13d1 nJpK2E2pZLRUg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P0C00H9L6RSLP30@st13p35im-asmtp002.me.com> for current@freebsd.org; Sat, 02 Dec 2017 13:57:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-02_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=4 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712020206 From: Toomas Soome Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit MIME-version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: what happened to src/sys/boot? Date: Sat, 02 Dec 2017 15:57:27 +0200 References: To: current@freebsd.org In-reply-to: Message-id: <52B40BAA-D3EA-4E32-97AB-EE1DB0D44A47@me.com> X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 14:57:39 -0000 > On 2 Dec 2017, at 15:42, Daniel Braniss wrote: > > Hi, > it seems to have disappeared. > it got moved to src/stand rgds, toomas From owner-freebsd-current@freebsd.org Sat Dec 2 14:58:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4461DE57611 for ; Sat, 2 Dec 2017 14:58:57 +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 1396D72CD7; Sat, 2 Dec 2017 14:58:57 +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:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1512226728; bh=f1PiPg9dxRgYYADSHs6D1O56/YKhm8ryDGvr59y nGTw=; b=RnjjqCSyzOlvQg0tzCyw4eyBdu9UFbfBg0y0fIK61oA2ri/FfmtaVpe PfJQbvg9akDhRZ+UxyVcDkhYUSCBhlCCPYwgNh31Inm2SLVezX4kUzB+vF1eFlFe EPZEo/UtfPkeWRlr2G7QOycvQy4r72Tbc4garWHI6GMBIq+1JmWs= 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 22DA31D84D; Sat, 2 Dec 2017 09:58:48 -0500 (EST) To: imp@freebsd.org Cc: freebsd-current From: Michael Butler Subject: SVN r326458 breaks efivar Message-ID: Date: Sat, 2 Dec 2017 09:58:46 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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.25 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, 02 Dec 2017 14:58:57 -0000 The introduction of efivar-dp-xlate.c into libefivar requires functions from libgeom yet usr.sbin/efvar doesn't link with it, imb From owner-freebsd-current@freebsd.org Sat Dec 2 15:42:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3240FE5D73D for ; Sat, 2 Dec 2017 15:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0D49174413 for ; Sat, 2 Dec 2017 15:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0CA45E5D73B; Sat, 2 Dec 2017 15:42:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C3BBE5D73A for ; Sat, 2 Dec 2017 15:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C672574412 for ; Sat, 2 Dec 2017 15:42:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id b5so5639031itc.3 for ; Sat, 02 Dec 2017 07:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lbN3yJSvyEOZ5ICIfyuh+5JsWgLwDAS5QuUlUN+LA3c=; b=LVsh7RFal/6Mqgi9Bwy/7M4PKVhIY3bKPzLFe33ddqh1Qs6ITMQxpykXYfcqbvFGAN UBdnLU3bmbt90VUQbhtnadzxS8ovdacMfkLlcwIq3vXE03APrfN7UvqKWEX4qdbEdf09 cOvZFCBUJN7kXQfdDFFgiIXttqt+jZ26CEGYk2Q1ckX1RuQxfuIAHRRZuJLHbtGXwwVZ kOtn6OpgUe+v1bfEXzc7Co9IsnB43veCixTahLDErKZiDG6nPuJMPp60HBWqDsPdp8Ai oyrDd6Ln3vkvh8c0VU6FdfndIGbJ5YZ/EJWmALXnfOskQGU4u8Z6gr5No4lp6V7dWwL1 aVBA== 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=lbN3yJSvyEOZ5ICIfyuh+5JsWgLwDAS5QuUlUN+LA3c=; b=qzXaUwB8sZbgoxu7+Odw89Sl/hsuGOksJUaMfoRRLfkZ8FHHbs9fMD0kSBllsgWUeM JvOtTuA/9KDM40QIvqSER3Pr5LK47dLssMz5/Kl5a7nkyKG4vd2YlCzeytVzHBS30SEu i+zCyXVrxIDwJE67zRuOps5gb6o8t58RNfYa+yZe2x4b5wkovZ0Aj5DHfg18MsX0uJTg F0NobUGa1JnKa4VDy8TH+9T8SEoprNGLtPk69fiqulQpvi7aIiYcjLdbEiWNmEVWzB+Q RtkH55mD2078/8e0ResQRkb0HdXjsTJBu7fxayxiS4v/OpmdMGWjuMmsgSQmOdPFbSN8 Tntg== X-Gm-Message-State: AJaThX4Prxv3BYYNugJQWf3AZ8gFB3PMi6kU7ba2I8OqJvnStPLTyQeM 7znSAec00epvYIRe2mbfpRZDnZAV9IXVJM05YUI+Ww== X-Google-Smtp-Source: AGs4zMYyd0dQek3QaaMIpFgo6QFfpWUGkxOfwnSBPB/tLFwo1SaNuxKLJHJscpH1vl95CxcYxNxeJ/yM+XJUcspyxCk= X-Received: by 10.36.77.143 with SMTP id l137mr6562809itb.50.1512229365108; Sat, 02 Dec 2017 07:42:45 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 2 Dec 2017 07:42:44 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sat, 2 Dec 2017 08:42:44 -0700 X-Google-Sender-Auth: 3f06cu2Hx2BXGXPFWS1g3Q0vogA Message-ID: Subject: Re: what happened to src/sys/boot? To: Daniel Braniss Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 15:42:46 -0000 On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss wrote: > Hi, > it seems to have disappeared. > After discussion on arch@, they were move to src/stand. They aren't part of the kernel, and this was the previous historic place for them. This will make things like the lua boot loader a bit easier, though we still have a bit too much accumulated debt in the boot loader that needs to be addressed first. Warner From owner-freebsd-current@freebsd.org Sat Dec 2 15:44:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83F92E5D837 for ; Sat, 2 Dec 2017 15:44:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4978F74577 for ; Sat, 2 Dec 2017 15:44:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id d21so14319356ioe.7 for ; Sat, 02 Dec 2017 07:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ryW9y9uxDy8g4962ZPvSznCJGNzUaNSpV/dokMr6iP4=; b=eWuf9gWtQCZkcgp7qa9NmH3F1N8kMWo7aIW2Dgpv3qoqO2rS6r1rXy8eFHYiK7qOQo YNIzk+Pmj3ntKc4sMa6AumjJPxSWEQ6kS1WZOFwjpWDpww0kCbXZ3jdrcyZeIHjbydfF yRKmtDqqMwIz2kWi9PSIvXFQww0Zgvf5GY0dUflB24ZEbGPfayI+XTQINzOzsC6203Xl pMJ37BWT8yD5erPyNadTpEFfDn3D6ed5APcskDeDh15O8SvrrvOZWHNPmfnMMRZ3AuaY dOojmpwLWhuDfF4u3L53kEgDAaPgxJZTmaM6o9dWBkIKBbzbpsOQG+Arh1VH1zm3pgC3 dd2g== 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=ryW9y9uxDy8g4962ZPvSznCJGNzUaNSpV/dokMr6iP4=; b=QWbukcQcjKD6XaKkIcWs6pU3XvS5OisyLNK8iKcFSEJHvRf2+tKoc32cU7uFRah2SQ C++4UBDmbdIatRwYmpJrZQwqPF+CtkZtlnT+P9xcdyR7/skEFul7xxg23TEASwDRoBlA tN9r1uQ1WojZu5ZDr4ir8456YTA5mgFKQJRzYtJWi4Wnca/9DWpQON3BckXN8oup7mmu iN3fv2M0ZuXUdqtqidX8s8DAr97ZqaGkSH5f96Ov8w1FoTimNiJU45y4uMb1QszVTxpQ QPEZcvgd9NIAkzbZ/D3z2dhVgC0YpxndaYqgagmBniYYyk57D2hHbWZZaj5gP7vheERy NR4w== X-Gm-Message-State: AJaThX4AUVaUWBYHG5sx5ceNRyF342rwEMbRFr32fp8PWkZ6HHRWqpQR cIIMaDAiBL4+HgoXzIv0PCk/dUSwiQ5yyfjfTyuhSQ== X-Google-Smtp-Source: AGs4zMYrkUCgLlAmTh4vPnX92ITYrg2p2SVByrfsDk9I2d6fuB+p+2sVhq1WtMlAQV/7gg0430gkx++xZwpAVfjrtqM= X-Received: by 10.107.48.197 with SMTP id w188mr17529420iow.301.1512229468521; Sat, 02 Dec 2017 07:44:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 2 Dec 2017 07:44:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sat, 2 Dec 2017 08:44:27 -0700 X-Google-Sender-Auth: D1Fj6t7PqL2gd65YdQCSRLyhuI0 Message-ID: Subject: Re: SVN r326458 breaks efivar To: Michael Butler Cc: Warner Losh , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 15:44:29 -0000 On Sat, Dec 2, 2017 at 7:58 AM, Michael Butler wrote: > The introduction of efivar-dp-xlate.c into libefivar requires functions > from libgeom yet usr.sbin/efvar doesn't link with it, > Yup. I didn't think it would need it since efivar doesn't reference those new functions, so I didn't test it before the commit. I'd had a mental note to do it, but just didn't. My bad. Fixed now in r326472. Warner From owner-freebsd-current@freebsd.org Sat Dec 2 19:32:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8550EE67BBB; Sat, 2 Dec 2017 19:32:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66B3C7AB17; Sat, 2 Dec 2017 19:32:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB2JWYUA045340 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Dec 2017 11:32:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB2JWYrn045339; Sat, 2 Dec 2017 11:32:34 -0800 (PST) (envelope-from sgk) Date: Sat, 2 Dec 2017 11:32:34 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] Add guard macro to fpmath.h Message-ID: <20171202193234.GA45300@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 19:32:35 -0000 The following patch adds a guard macro to fpmath.h. It is used to prevent multiple inclusions of its content. Please apply to top-of-tree. Index: libc/include/fpmath.h =================================================================== --- libc/include/fpmath.h (revision 2044) +++ libc/include/fpmath.h (working copy) @@ -27,6 +27,9 @@ * $FreeBSD: head/lib/libc/include/fpmath.h 186461 2008-12-23 22:20:59Z marcel $ */ +#ifndef _FPMATH_H_ +#define _FPMATH_H_ + #include #include "_fpmath.h" @@ -73,3 +76,5 @@ union IEEEd2bits { #endif } bits; }; + +#endif /* !_FPMATH_H */ -- Steve From owner-freebsd-current@freebsd.org Sat Dec 2 19:42:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AAF0E68011 for ; Sat, 2 Dec 2017 19:42:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 084827B2C2 for ; Sat, 2 Dec 2017 19:42:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x244.google.com with SMTP id j7so614916ybl.3 for ; Sat, 02 Dec 2017 11:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=etparZ//+3UDMzUABYJbecTExPw29q4NnzZzl8RFF5k=; b=sKxpAkXJKCHdHsBR2saGpFC2dKDjijUrEoXyzVA7MEOfYn3V9tMVs1N5C+E0PM16ey FC32efpHVwtTr4EueiIwsOwSD78HAJfLN0ldOuTC6UtjiSSSkIL1n/0gDZepeISQbTTZ JnJttZoe7O8CzpyXAprKF25yE4An1CLerUMhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=etparZ//+3UDMzUABYJbecTExPw29q4NnzZzl8RFF5k=; b=hdX2wBGNmnEwkCeBuSHen1LuvGdvTtI5aLFh+n4qjds3jr0zONeWRBy7NrZHAF9Xjn wCupa+qXMfqMnVn32MW50RBuyh7scNgT5K29YGE0uTIl2JXX93dSOfmx+lZ+sfNmuoDr X9TEcYzivLitTIz/3hSilI9FIXC3qtkRzQtuMNneAR0XVicH/oa/cpcz0HlbKIXeow5M XyTwvYOE8xyyvEtFmRK2GLT9RDjw8P4nmLy6214G4QoRVwQA38KOSTcigGDuoJqwADXD zDWwX/A2QtiGbqtwD1tiOM0VZEPC1hS1HLdLjPYBr5KLUYbl+zoLPehkjDU28MT5qLOu Zkrg== X-Gm-Message-State: AJaThX6b73iGJ+TDpfvOedUuofnEieZ5hp9ERvVSOVF2g5rPQ1DgFb4z t7sYaXkAEK9QJAGXfhQuC9e8GubDMS9nqMJjXqdcN/oM X-Google-Smtp-Source: AGs4zMbFpqZ1+pewA0YzYPvZvvh7aTKQh+MPOmhrzEJkBijwUthFPGXaVWzhoSqXqaPu5tMTjp6amwocjhyZVAAxfRw= X-Received: by 10.37.123.134 with SMTP id w128mr6410062ybc.486.1512243777084; Sat, 02 Dec 2017 11:42:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.15.66 with HTTP; Sat, 2 Dec 2017 11:42:26 -0800 (PST) In-Reply-To: <20171202193234.GA45300@troutmask.apl.washington.edu> References: <20171202193234.GA45300@troutmask.apl.washington.edu> From: Eitan Adler Date: Sat, 2 Dec 2017 11:42:26 -0800 Message-ID: Subject: Re: [PATCH] Add guard macro to fpmath.h To: Steve Kargl Cc: FreeBSD Hackers , freebsd-current Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 19:42:58 -0000 On 2 December 2017 at 11:32, Steve Kargl wrote: > The following patch adds a guard macro to fpmath.h. > It is used to prevent multiple inclusions of its > content. Please apply to top-of-tree. [69006 11:41:35.802 eax@FlyingEagle ~/svn/fbsd/head/lib]=E2=88=B4svn diff (svn:head)-[head:326419]-[326419] Index: libc/include/fpmath.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- libc/include/fpmath.h (revision 326419) +++ libc/include/fpmath.h (working copy) @@ -29,6 +29,9 @@ * $FreeBSD$ */ +#ifndef _FPMATH_H_ +#define _FPMATH_H_ + #include #include "_fpmath.h" @@ -75,3 +78,5 @@ union IEEEd2bits { #endif } bits; }; + +#endif /* !_FPMATH_H */ [69007 11:41:37.789 eax@FlyingEagle ~/svn/fbsd/head/lib]=E2=88=B4svn ci libc/include/fpmath.h (svn:head)-[head:326419]-[326419] Sending libc/include/fpmath.h Transmitting file data .done Committing transaction... Committed revision 326479. --=20 Eitan Adler From owner-freebsd-current@freebsd.org Sat Dec 2 19:50:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF4A5E682F9 for ; Sat, 2 Dec 2017 19:50:49 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::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 965147B618 for ; Sat, 2 Dec 2017 19:50:49 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.208] (cpe-23-242-94-236.socal.res.rr.com [23.242.94.236]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 500c4f98 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Sat, 2 Dec 2017 11:50:36 -0800 (PST) Subject: Re: Error attempting to link during buildworld From: Pete Wright To: FreeBSD Current References: <520eb756-6d01-23d2-3321-b3db6dc3438c@nomadlogic.org> Message-ID: <2e3d1848-81ed-6112-33c6-424b33a85fd6@nomadlogic.org> Date: Sat, 2 Dec 2017 11:50:46 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <520eb756-6d01-23d2-3321-b3db6dc3438c@nomadlogic.org> 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.25 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, 02 Dec 2017 19:50:49 -0000 On 12/01/2017 11:43, Pete Wright wrote: > Hi All, > > I am running into this error when attempting to buildworld from a > checkout I made recently (git hash > 76ca06b62f3bfb21f1f2e1295eb89e3c235bdda7) > > --- all_subdir_stand --- > /usr/home/pete/git/freebsd/stand/i386/libi386/libi386.a(bootinfo64.o): > In function `bi_checkcpu': > /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:149: > undefined reference to `read_eflags' > /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:150: > undefined reference to `write_eflags' > /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:151: > undefined reference to `read_eflags' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** [loader.sym] Error code 1 > > > Has anyone else seen this?  I'm not sure if I have some stale files > that need to be purged, or if this is a bug due to me using ccache.  > I'm asking here tho as I'd love to preserve my ccache and save some > cycles rebuilding LLVM :) just following up on this thread - i assume others have been able to buildworld on amd64, and have not been getting this linker error?  i have a fresh checkout from this morning, tested with and without ccache and am still getting this same error.  my system is currently at this revision: $ uname -ar FreeBSD runner 12.0-CURRENT FreeBSD 12.0-CURRENT #1 63d5d6c71fb(master): Sat Nov 18 08:36:45 PST 2017 pwright@runner:/usr/obj/usr/home/pwright/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV amd64 any tips on helping debug this as well would be appreciated - as i'm not %100 sure where to start (i.e. how to invoke the linker with the "-v" flag for buildworld :) cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Dec 2 20:03:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89699E68746; Sat, 2 Dec 2017 20:03:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E0177BCD7; Sat, 2 Dec 2017 20:03:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vB2K39qA045608 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Dec 2017 12:03:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vB2K39OL045607; Sat, 2 Dec 2017 12:03:09 -0800 (PST) (envelope-from sgk) Date: Sat, 2 Dec 2017 12:03:09 -0800 From: Steve Kargl To: Eitan Adler Cc: FreeBSD Hackers , freebsd-current Current Subject: Re: [PATCH] Add guard macro to fpmath.h Message-ID: <20171202200309.GA45600@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20171202193234.GA45300@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 20:03:10 -0000 On Sat, Dec 02, 2017 at 11:42:26AM -0800, Eitan Adler wrote: > On 2 December 2017 at 11:32, Steve Kargl > wrote: > > The following patch adds a guard macro to fpmath.h. > > It is used to prevent multiple inclusions of its > > content. Please apply to top-of-tree. > > [69006 11:41:35.802 eax@FlyingEagle ~/svn/fbsd/head/lib]∴svn diff (trimmed) > [69007 11:41:37.789 eax@FlyingEagle ~/svn/fbsd/head/lib]∴svn ci > libc/include/fpmath.h > (svn:head)-[head:326419]-[326419] > Sending libc/include/fpmath.h > Transmitting file data .done > Committing transaction... > Committed revision 326479. That was quick! Thanks! Now onto powl(3). -- Steve From owner-freebsd-current@freebsd.org Sat Dec 2 20:27:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DEF1E68F7F for ; Sat, 2 Dec 2017 20:27:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 E9DB57C75B for ; Sat, 2 Dec 2017 20:27:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id E63C6E68F7C; Sat, 2 Dec 2017 20:27:04 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5DFAE68F7B for ; Sat, 2 Dec 2017 20:27:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 9D8A47C75A for ; Sat, 2 Dec 2017 20:27:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il ident=exim) by kabab.cs.huji.ac.il with esmtp id 1eLENE-000LFf-CW; Sat, 02 Dec 2017 22:26:56 +0200 Received: from [132.65.179.42] (helo=imac.bk.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1eLENE-0003h8-8l; Sat, 02 Dec 2017 22:26:56 +0200 From: Daniel Braniss Message-Id: <39F80CE7-BECF-4D4F-ACEB-5B6C52FC241B@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: what happened to src/sys/boot? Date: Sat, 2 Dec 2017 22:26:54 +0200 In-Reply-To: Cc: FreeBSD Current To: Warner Losh References: X-Mailer: Apple Mail (2.3445.4.7) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 20:27:05 -0000 > On 2 Dec 2017, at 17:42, Warner Losh wrote: >=20 >=20 >=20 > On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss > wrote: > Hi, > it seems to have disappeared. >=20 > After discussion on arch@, they were move to src/stand. They aren't = part of the kernel, and this was the previous historic place for them. = This will make things like the lua boot loader a bit easier, though we = still have a bit too much accumulated debt in the boot loader that needs = to be addressed first. >=20 > Warner=20 this is what happens when you are at the BEOT :-) now lets see how difficult it is to get ubldr for allwinner to compile. cheers, danny From owner-freebsd-current@freebsd.org Sat Dec 2 20:30:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FBD1E690CD for ; Sat, 2 Dec 2017 20:30:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 004D37C8D2 for ; Sat, 2 Dec 2017 20:30:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id u42so14723530ioi.9 for ; Sat, 02 Dec 2017 12:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y80IfL2e4L1fv5g2A1WN9YvDAZll7PTAHc6ZQuJ/i7E=; b=jCjV7UQKdd12WrE6VnlDIlg512kqjaPMG7X+873jIP+GmfVABJhKjS3tmJr/pknc8W TpMxSXTrqi8Rpv5jtxOsoJDyPk8qToERzdqC++WbmU1tQXn4aU86hb/PlOBpQ3EYQjsL aRrIXkFehbBxWBMyzB05ZvA8RIcHfb3vDAdomQxj+0k94oSWedS78I8K1HW8gQ0sXASb 3POrY9THMFNpBaBlMQeO5YhfSVScdLoOmB17dxtTDytJ0gijZCyINoT8h9w5tETrBDYn 43zC/gRgEhvH8CaATTsxPI80Nu70hAhQfpTEqdlCHpZc1zh6oJQZrxJSNO3Ezl/tUQO4 jWgg== 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=y80IfL2e4L1fv5g2A1WN9YvDAZll7PTAHc6ZQuJ/i7E=; b=swZL44hbJNTB2n50F8GV/AuuZ4K4sKINNpKWQij13IrKks6l0dQ3F6dDA7shFZIv9l 0w60af0LXC++gM9shvHb90/o77iH9VO8MBj9hEMzUDnNtsGw9plm7ZYzexzERDbgSo+r p3N4tx3ocXaw+1fkLrziFLwmElWPz3yjmW0LgfBj0b67e8praere//oi3Wc5h3e3yax8 mXcCO/J/0+qISvQS/hGQcWEajfUPUBBj+sLpGeGwKGPQR5lYdqLe5uXFlcuiYhAFEFn/ 0y2QDJbLlCyAllpI1SjPf3EttGtsayL1m54i5y9nZ99HpUFrsZ6A3HyiuGsvR3kY5AKt IrGg== X-Gm-Message-State: AJaThX7gJQG4pGDcNuJ+k2n6J05rjsuid9XqpFjLwF2Gn6bwfmPgb8H0 Ri2jNurvf78tB+aBeOERsMvEMoIwpchzrV2mDe+7Lw== X-Google-Smtp-Source: AGs4zMZSHev2L6LTRAbuYKYVsGD91F7s+LWhlGT9rAhYbfPbQYN2XpRBVmwwK7S1ceZJctllLKZ2gZYNlan36GKqRVo= X-Received: by 10.107.30.81 with SMTP id e78mr17247110ioe.130.1512246628168; Sat, 02 Dec 2017 12:30:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 2 Dec 2017 12:30:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <2e3d1848-81ed-6112-33c6-424b33a85fd6@nomadlogic.org> References: <520eb756-6d01-23d2-3321-b3db6dc3438c@nomadlogic.org> <2e3d1848-81ed-6112-33c6-424b33a85fd6@nomadlogic.org> From: Warner Losh Date: Sat, 2 Dec 2017 13:30:27 -0700 X-Google-Sender-Auth: fKaqZHuM09hknU4zteV3ki5dWgU Message-ID: Subject: Re: Error attempting to link during buildworld To: Pete Wright Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 20:30:29 -0000 On Sat, Dec 2, 2017 at 12:50 PM, Pete Wright wrote: > > > On 12/01/2017 11:43, Pete Wright wrote: > >> Hi All, >> >> I am running into this error when attempting to buildworld from a >> checkout I made recently (git hash 76ca06b62f3bfb21f1f2e1295eb89e >> 3c235bdda7) >> >> --- all_subdir_stand --- >> /usr/home/pete/git/freebsd/stand/i386/libi386/libi386.a(bootinfo64.o): >> In function `bi_checkcpu': >> /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:149: >> undefined reference to `read_eflags' >> /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:150: >> undefined reference to `write_eflags' >> /usr/home/pete/git/freebsd/stand/i386/libi386/bootinfo64.c:151: >> undefined reference to `read_eflags' >> cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> *** [loader.sym] Error code 1 >> >> >> Has anyone else seen this? I'm not sure if I have some stale files that >> need to be purged, or if this is a bug due to me using ccache. I'm asking >> here tho as I'd love to preserve my ccache and save some cycles rebuilding >> LLVM :) >> > > just following up on this thread - i assume others have been able to > buildworld on amd64, and have not been getting this linker error? i have a > fresh checkout from this morning, tested with and without ccache and am > still getting this same error. my system is currently at this revision: > > $ uname -ar > FreeBSD runner 12.0-CURRENT FreeBSD 12.0-CURRENT #1 63d5d6c71fb(master): > Sat Nov 18 08:36:45 PST 2017 pwright@runner:/usr/obj/usr/ho > me/pwright/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV amd64 > > > any tips on helping debug this as well would be appreciated - as i'm not > %100 sure where to start (i.e. how to invoke the linker with the "-v" flag > for buildworld :) With today's tree, I can both build the loader by hand and as part of buildworld. I'm keen on fixing this, but I've no clue why it's failing for you. Have any weird optimizer settings? Do you get any reports of functions not declared? Warner From owner-freebsd-current@freebsd.org Sat Dec 2 20:31:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80BD5E69487 for ; Sat, 2 Dec 2017 20:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5829F7CBAB for ; Sat, 2 Dec 2017 20:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5771AE69486; Sat, 2 Dec 2017 20:31:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 571DCE69485 for ; Sat, 2 Dec 2017 20:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B3927CBA9 for ; Sat, 2 Dec 2017 20:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id o130so7272441itg.0 for ; Sat, 02 Dec 2017 12:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ysKzdxetQbJUU8vovaQRNYVnBYEdmQixGMgC7YxbNAM=; b=hjyDZx0KYtUseNSqSPcRClSiXCCFOZvwmqK+GoQiRZM95sAvM2txyhkNrUOY9Y9jWE fcnvcuDo3RVgJad/FkUD9cPx897UL3rxrp7iU1gtNMjzaLinW0apRmUaiPwQOaciNdwX Q+LrdiB3Wky6vIvwApIz4+ZADHPCv9xNcyWpEWmxZLG6sYxWhZmgDX6Lr6Q2WXn4b+2M CEC5w6M8RPJq/g+3QH6gPYfwtfPwRGK3jChEa0/OxD4dusnPfno4/i6YZD1zXU6f5crJ P/k97LtX/447Td33muC1JlbkYwQ80i5JzkslNl0GFMDBO9U1E755OQxKsrUiBs+IEO2q HqQA== 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=ysKzdxetQbJUU8vovaQRNYVnBYEdmQixGMgC7YxbNAM=; b=c68mke+3fowbVfmr/ou3xe6rB/1cFCtLVA4DdTVstJY5iPVBfy9ZD/pYyuMUhYA6z7 +oD9fIcJtDQbnZz0PCPQxstJly0uX+85JihiuK7xN4dmsXRQmWF6KvDaYG9FRc1ERS4/ JPjFqI4h2UgzWQdVz1wQ1T+QTl2Q3MBcahiLU/uL7206t6k6SUrRqXO6aDTAS7gpLIe9 jw0MwvVldZWgpNt4j5wzIPWPSXghrPxClrNgHLhqnjerSbcjdcYA7M8NCCHOl6l5zSTa bauYrGYHoTO5SPzjBCk0XFhICGsrmx+NR9xgwgv0nAi7Jsi5jOpT7V4ZRYmRR5Q+cQP5 2hpA== X-Gm-Message-State: AKGB3mKWoL5TMozE7dKE+SyVssPbZmKvbZu4XjnTlNyrc/RBanQkesOv byoxcA/t6YcG+DDQQb3Uxv3vyB2t54/zM+UD0Kjkbw== X-Google-Smtp-Source: AGs4zMYrSxg6xFakT2udC5HCbxZEPJG2zlESf83P06Tbos0OgON/xIk1yrxPxuclqeqpXSQJyui+bUHqg5rFaQkfSE8= X-Received: by 10.36.131.200 with SMTP id d191mr7282338ite.97.1512246716444; Sat, 02 Dec 2017 12:31:56 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 2 Dec 2017 12:31:55 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <39F80CE7-BECF-4D4F-ACEB-5B6C52FC241B@cs.huji.ac.il> References: <39F80CE7-BECF-4D4F-ACEB-5B6C52FC241B@cs.huji.ac.il> From: Warner Losh Date: Sat, 2 Dec 2017 13:31:55 -0700 X-Google-Sender-Auth: xGSXAM1uXAthn_RJt4FMqQQfbB8 Message-ID: Subject: Re: what happened to src/sys/boot? To: Daniel Braniss Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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, 02 Dec 2017 20:31:57 -0000 On Sat, Dec 2, 2017 at 1:26 PM, Daniel Braniss wrote: > > > On 2 Dec 2017, at 17:42, Warner Losh wrote: > > > > On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss > wrote: > >> Hi, >> it seems to have disappeared. >> > > After discussion on arch@, they were move to src/stand. They aren't part > of the kernel, and this was the previous historic place for them. This will > make things like the lua boot loader a bit easier, though we still have a > bit too much accumulated debt in the boot loader that needs to be addressed > first. > > Warner > > > this is what happens when you are at the BEOT :-) > now lets see how difficult it is to get ubldr for allwinner to compile. > Builds for me. Lemme know if that's not true for you. Warner