From owner-freebsd-stable@freebsd.org Sun Feb 24 11:59:38 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA92151C528 for ; Sun, 24 Feb 2019 11:59:38 +0000 (UTC) (envelope-from filippomore@yahoo.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 5578C6A8C7 for ; Sun, 24 Feb 2019 11:59:37 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1172F151C527; Sun, 24 Feb 2019 11:59:37 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6B2D151C526 for ; Sun, 24 Feb 2019 11:59:36 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic310-21.consmr.mail.ne1.yahoo.com (sonic310-21.consmr.mail.ne1.yahoo.com [66.163.186.202]) (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 2A9BF6A8C6 for ; Sun, 24 Feb 2019 11:59:35 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-YMail-OSG: QOygSFkVM1lfcs8.XE8Ai3hV3fhGAJfoUunlPKU6ukYVHVxCIY5IeLY1QSd3cAy kM3VCOs.drpmxZkyxCzQGQq9Rm7aLMdKyZs53E4Z6L1G9gSFyrd6bZG__lXaY3iVUAKtsC0gEc86 fkIshksH8.YWaOuZBllu4KrCiQQgMZq1v0jVzy.KG80Yfg9Y7qTQSjkZnGYLmjzNyJvHe2mlPPtA 5ip6GGh74pSR4NGi2Ze8tnbBDaGCZqHIDth6vPFF2lk1vRqhblz7jHKLOHq4UzfQDakE0G.5SNDe Bp6oJxiZN4trznPntHgcqNHEWAALyr5_ObT06rRHGp9G0BkcVeriF1jrEJeArnKQNUgzfbx3.uSk NLyZVeZ1Js1eRqk.6FBKbX7.4lI.McHXiDquJZ4jkhwEnxX_PtL7A5yst8CokDVl0yenNtiZoygl GyNIsfnT9D3vMQ5Cb3W4KBKEbajyfBq_o7Ayf1vl7I7GsxqVsgM0Ec4ED3uTgysV9oZp3JY4Vy6w sx9REcius6ZCA_oZ_XVCB6q4RKYQRE1_Z0v3TR.1noP6il_MuuzvSfLTuScU.zZo.wfLsHqvi0Ky YVXIwZew4k.Kf.E3REELz06CcCiOwydenojsCG0tId9hHxFfpw5nf7KBN.3IULbwpPKhYXx9XCxX UFhXVQm_yCOK5XQUj0eXGWxQF8tUId2FNKjcpRRjLlIoEurASHXAGR5YacMrGxcxCVf.YOrsxjXS muCS_WWkbUCnXjcd.bxGReJ7yzArksLT1rIE9R17mfC7Yc3vFgmAyVAczRRKlmT67_gZEMX4i.Ys xB9p_nLA9dfGRrQ.TtqXuNtYVFrHRoQNcJUQL1Ljn8cGL3nKZ68MFsGuD7nWKRsKC3pQfp_Pd8AS mvp8rpZsOQzkuAEWKLnvTy8CjiN1QBbbbYwILOjg.E5JukKUyMr3pqG8fFZ_nh85jLdHCcKXRaRH PWA1.ULO6i.Baf6jPaFsy0ynzJw9MG7F.rP.l8B65Hf.xeMDVcr8oOhaMWNZDcp436e9ftp21LXV XaaYoYML.lDwcGUOVXOyKZzCtEQwPUW1LpxD0hU.9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sun, 24 Feb 2019 11:59:29 +0000 Date: Sun, 24 Feb 2019 11:59:24 +0000 (UTC) From: Filippo Moretti To: FreeBSD Stable ML Message-ID: <1252756970.4179337.1551009564377@mail.yahoo.com> In-Reply-To: References: <3BB1A8CA-272D-4B48-81A2-CBAF7EE23507@gmail.com> <20181227140706.748bf173@ernst.home> <201901060714.x067DqZP016183@fire.js.berklix.net> <20190106130206.56332774@ernst.home> <201901062231.x06MV3OP028712@fire.js.berklix.net> <201901071626.x07GPtW6049111@fire.js.berklix.net> <1550913614539-0.post@n6.nabble.com> Subject: Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64) MIME-Version: 1.0 X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:65.0) Gecko/20100101 Firefox/65.0 X-Rspamd-Queue-Id: 2A9BF6A8C6 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.995,0]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 11:59:38 -0000 For what it may be worth I built it with LLVM80-RC from ports and I did no= t experience tis problemsincerely Filippo On Saturday, February 23, 2019, 8:12:00 PM GMT+1, Dimitry Andric wrote: =20 =20 On 23 Feb 2019, at 16:48, Jan Beich wrote: >=20 > Jakub Lach writes: >=20 >> Hello, >>=20 >> I'm on FreeBSD 12.0-STABLE #0 r344261 amd64. >>=20 >> I've rebuilt all ports after clang 7 import to 12-STABLE. >>=20 >> Now I get with mplayer >>=20 >> ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname" >=20 > https://svnweb.freebsd.org/changeset/ports/490727 needs to be adjusted > for -STABLE as well. No, the correct solution is to fix mplayer's linker script, or better, to delete it entirely. :-)=C2=A0 Afterwards, r490727 can be reverted. -Dimitry =20 From owner-freebsd-stable@freebsd.org Mon Feb 25 00:19:35 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D14B11512E55 for ; Mon, 25 Feb 2019 00:19:35 +0000 (UTC) (envelope-from prvs=09594c68c9=ari@ish.com.au) Received: from fish.ish.com.au (ip-2.ish.com.au [203.29.62.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 5BB4E8F70E for ; Mon, 25 Feb 2019 00:19:32 +0000 (UTC) (envelope-from prvs=09594c68c9=ari@ish.com.au) Received: from ip-145.ish.com.au ([203.29.62.145]:64858) by fish.ish.com.au with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gy3zJ-000767-2y; Mon, 25 Feb 2019 11:19:18 +1100 X-CTCH-RefID: str=0001.0A090205.5C733486.0010:SCFSTAT42589845, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: Java support To: Charlie Li Cc: Kurt Jaeger , freebsd-stable References: <20190221101815.GU2748@home.opsec.eu> <1942e86e-8a6a-d5ca-c701-abb1036b5ee2@vishwin.info> From: Aristedes Maniatis Message-ID: Date: Mon, 25 Feb 2019 11:19:16 +1100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Thunderbird/66.0 MIME-Version: 1.0 In-Reply-To: <1942e86e-8a6a-d5ca-c701-abb1036b5ee2@vishwin.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 5BB4E8F70E X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of prvs=09594c68c9=ari@ish.com.au designates 203.29.62.2 as permitted sender) smtp.mailfrom=prvs=09594c68c9=ari@ish.com.au X-Spamd-Result: default: False [1.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr]; ENVFROM_PRVS(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ish.com.au]; FORGED_SENDER_VERP_SRS(0.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.938,0]; NEURAL_HAM_LONG(-0.38)[-0.379,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mx.ish.com.au]; NEURAL_SPAM_SHORT(0.96)[0.960,0]; IP_SCORE(0.76)[asn: 7545(3.82), country: AU(-0.04)]; FORGED_SENDER(0.00)[ari@ish.com.au,prvs=09594c68c9=ari@ish.com.au]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7545, ipnet:203.29.62.0/24, country:AU]; FROM_NEQ_ENVFROM(0.00)[ari@ish.com.au,prvs=09594c68c9=ari@ish.com.au]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 00:19:36 -0000 On 22/2/19 4:12pm, Charlie Li wrote: > I don't think this is beyond the open source community's capabilities at > all; quite the opposite. The real crux is individual priorities. Right now there is no publicly visible work on porting Java 11 (the only version worth working on at this time I think). Someone may step up when it becomes important enough to them. Or not. > Please refer to the following PR: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222568 > > The last comment there is exactly the point of what I had typed in an > earlier incarnation of this email message before I had some second > thoughts on just how rude it could come off. Yeah, not especially helpful. Not everyone with a need for new Java has the technical expertise to work on something as complex as porting a JVM. I have considerable experience working in open source communities and I know that the right confluence of people and tasks are not always something you can predict. I was hoping that either the FreeBSD Foundation might step up to this problem or else some contributors might discuss efforts happening behind closed doors. However I do think that a lack of modern Java is going to bite into the credibility of FreeBSD as a server platform before long. Are the sponsors behind the AdoptOpenJDK project interested in FreeBSD as a platform? Are there conversations happening there to try and get FreeBSD including in their test farm? Can the FreeBSD project assist by making servers available, especially with the rumours of Travis downsizing? Cheers Ari [1] https://adoptopenjdk.net/sponsors.html From owner-freebsd-stable@freebsd.org Mon Feb 25 17:47:55 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE78A1510753 for ; Mon, 25 Feb 2019 17:47:54 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCBF37032D for ; Mon, 25 Feb 2019 17:47:53 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu (static62133140050.ostnet.pl [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id x1PHlecq073035 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 25 Feb 2019 18:47:49 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1551116869; bh=7KvBigN4ZnAMsP8CUKkmVZEAkAiApzv36TyP1pxiaMw=; h=To:References:From:Subject:Date:In-Reply-To; b=Nb8RINvHMY0kAP1+S9fqj0IGGnU7k6YiCZdH3F6m7TppDI/bOvRn6EkPrFZuUgSoO xpCp31uUw3leQ7xabyH/jWoyfnUltNqyhmyRXGj1UqSclLD/b7wwn4nhIbppq1msGl /Pgl/DA5Q1XwO2urxDM/6Dp8s847XqwjuhM14WnpQ0gN65rNHEF3UTmjEKtZ3Q19nA JwwA5Rhf43cO6lRIonk85IpW+zdjT+4+eQ/YN+qi2HWuNwiaO0v3emcdkRBtfthQ2e m/slIELRfrL8ruOVUGhnjY7fP9EETi0Y5bNpppcTHtspn96AyfQMZkoqQcqqbsXeS1 A9caN6kI04IMA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host static62133140050.ostnet.pl [62.133.140.50] claimed to be fomalhaut.potoki.eu To: freebsd-stable@freebsd.org References: <056a2bc4-260c-5f65-a8a1-a3b849e64502@plan-b.pwste.edu.pl> From: Marek Zarychta Openpgp: preference=signencrypt Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: FreeBSD 12 and Nocona Message-ID: <9b2c6cb7-dbbb-39c4-f409-84393311a6c5@plan-b.pwste.edu.pl> Date: Mon, 25 Feb 2019 18:47:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m3rb1DpAP3HeVmxoerSl0l55sDbdyoUEx" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 17:47:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m3rb1DpAP3HeVmxoerSl0l55sDbdyoUEx Content-Type: multipart/mixed; boundary="f7wC6Bb29MLOOGL8hszYbhmKpqn2OzzW1"; protected-headers="v1" From: Marek Zarychta To: freebsd-stable@freebsd.org Message-ID: <9b2c6cb7-dbbb-39c4-f409-84393311a6c5@plan-b.pwste.edu.pl> Subject: Re: FreeBSD 12 and Nocona References: <056a2bc4-260c-5f65-a8a1-a3b849e64502@plan-b.pwste.edu.pl> In-Reply-To: --f7wC6Bb29MLOOGL8hszYbhmKpqn2OzzW1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 08.01.2019 o=C2=A012:51, Stefan Bethke pisze: > Am 08.01.2019 um 10:34 schrieb Marek Zarychta : >> W dniu 03.01.2019 o 14:13, Stefan Bethke pisze: >>>> I have under supervision a few old servers running 11.2-STABLE. The >>>> hardware is almost for retirement, but still in working condition. I= t's >>>> all old Nocona NetBurst microarchitecture. I have recently tried do >>>> upgrade OS two of them to 12.0-STABLE, but failed. When I use old >>>> bootloader the boot freezes on blue highlighted "Booting" stage, whe= n I >>>> tried to use 12 loader, it freezes earlier, on loading kernel module= s. >>>> The kernel was compiled from fresh sources for CPUTYPE?=3Dnocona. >>>> 11.2-STABLE is fine with this optimization and the same kernel boots= >>>> fine on newer hardware. >>>> >>>> It is fair, that 11 EOL is expected September 30, 2021 and these ser= vers >>>> will likely be retired before this date, but some questions arise: >>>> >>>> Is such old hardware still supported? Is it possible (how to) debug = the >>>> booting process? >>> The first step is to try with known-good bits: can you boot these mac= hines off the 12.0 ISO or memstick images? Can you load your kernel and m= odules with the loader from the ISO/memstick? Does GENERIC built without = any flags work? >>> >>> If any of these don=E2=80=99t work, try to be as specific as possible= when reporting problems. For example, the exact make of mainboard (kenv = output) and the BIOS version, and any relevant BIOS settings are likely i= mportant for problems regarding the loader. If the kernel and modules loa= d, you can try a verbose boot to see better how far the kernel gets. >>> >>> I=E2=80=99d be really surprised if the CPUs themselves would cause tr= ouble. >> >> The first step is done. The affected hardware doesn't boot from offici= al >> 12.0-RELEASE CD either. Loader also freezes at the stage of loading >> kernel modules. These servers are old Maxdata Platinum 500 and 3200. >> Some time ago I have submitted dmesgs to NYC BUG dmesg repository[1][2= ]. >> >> Both configurations are fine with 11-STABLE, so I am not going to >> upgrade them and I am replying only FYI. >> >> >> [1] https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D3790 >> [2] https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D4111 > I think it would be great to get some input from someone familiar with = the new loader. I=E2=80=99ve cc=E2=80=99ed Warner, Kyle and Toomas, as th= ey were listed in the quarterly status report. > After recent MFCs LUA loader became available in 11-STABLE branch. I have tested it on this old hardware using freshly built r344482. I must admit the LUA loader on this hardware loads and boots 11-STABLE kernel flawlessly in root on ZFS environment. The only caveat was that kernel.old haven't been listed under "5" key, but it wasn't tested intensely so the error could be temporary or nonexistent. Nothing changed with regard to booting FreeBSD 12 on this hardware. I have tried to boot the recent 12-STABLE kernel. The kernel and all modules were loaded (in the same manner as previously loader 4th did), but instead of booting machine froze at this stage, so the breakage is elsewhere. --=20 Marek Zarychta --f7wC6Bb29MLOOGL8hszYbhmKpqn2OzzW1-- --m3rb1DpAP3HeVmxoerSl0l55sDbdyoUEx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlx0KjsACgkQdZ/s//1S jSxGVQf/VodWqonALtASty44ad6TMk+4c8q/59DxwTT0hGYwiOXJR1QpxdH6fxw7 Xl67/EjhB3+Z8r9BWNlT8mgO2A45su+s/4V0xv+1r29kWxDTN5ea71X5czw+Hhy9 wANeR0wpI7jcT1UhAVKZN88n3ai07p1uJ8KAFP5koSs8zU5x2IzVcxeJDOn3KcMh hg5THTvkQgJja1fmCTKs8+OsirrP6oGaDMZq7TKWqLyuQfgEMWJhT10CJR7SHyD7 h7LWh1oHYIrWM8Hj1wBgxuIo4ScKf8dZ0bfR4bGqnNZwemtA43FQhOlgOysrPCxy HzDv62XFt/2VWTNP2T4/17gEb8ZJUw== =RETb -----END PGP SIGNATURE----- --m3rb1DpAP3HeVmxoerSl0l55sDbdyoUEx-- From owner-freebsd-stable@freebsd.org Tue Feb 26 22:55:24 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C038F1507105 for ; Tue, 26 Feb 2019 22:55:24 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yw1-f66.google.com (mail-yw1-f66.google.com [209.85.161.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 081AB80064 for ; Tue, 26 Feb 2019 22:55:23 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yw1-f66.google.com with SMTP id k14so6577141ywe.4 for ; Tue, 26 Feb 2019 14:55:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Wk7odRJLPnAWnxaxeHiqbNDY7PJ/4nKc2QhqP4jC0vU=; b=d1FsxameIzSo2rqmT6MIGarkoFfY2WrBhBRoPmY7ZM4Rxoh+BJnEpjgekAVURWl3OX bDtXsEVTd4sqSBeI5hxsYqXvYMZ2lOtX8QFCUHMQ9MD/+Ss3NdkhZxSCb57GkdVTiZGv iLpJV0JsbbJa2FVcgeKxPa1f+ENzEMG5wnNJwmvrjdHXuMMqSxzmoPHHsUH/H8LVG81Y yaM5pU39HSJ/3jkidUR990EC/9ECpaQzo3Fe9dLUDXtIfX8R9yk7976jG2cA9Tixmtwc I2MJx6/4kGzpAObG1muWFeSmu5SPOLF7ic/0k3pUkJAntyTnfLG2YFwcekprLl6h7Zz5 hLxA== X-Gm-Message-State: AHQUAuYiOuutp7vz0iWCl1zEICZ6PMpZ8yrD/c8DOk+6BiOJZMIbR4+1 FQDFVYsY2hooJmkk6k7zlc8Gko2ROVTLgulfaeo= X-Google-Smtp-Source: AHgI3IajoOq9JD3nHYedEAnyZqCTJRf//2Zmda+1ZlhSWw0AKRu8Mgd2YmEtq9A9SvUz2G6ADvy51xKI3V8MZSuCx8A= X-Received: by 2002:a25:25d4:: with SMTP id l203mr6197359ybl.490.1551221344158; Tue, 26 Feb 2019 14:49:04 -0800 (PST) MIME-Version: 1.0 From: Li-Wen Hsu Date: Wed, 27 Feb 2019 06:48:48 +0800 Message-ID: Subject: FreeBSD CI Weekly Report 2019-02-24 To: freebsd-testing@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 081AB80064 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.161.66 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.76)[-0.759,0]; RCVD_IN_DNSWL_NONE(0.00)[66.161.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.18)[ipnet: 209.85.128.0/17(-3.81), asn: 15169(-2.01), country: US(-0.07)]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; DMARC_NA(0.00)[freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FORGED_RECIPIENTS(0.00)[freebsd-testing@freebsd.org,freebsd-stable@freebsd.org]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Mailman-Approved-At: Wed, 27 Feb 2019 00:22:28 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 22:55:25 -0000 (bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-02-24 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-02-18 to 2019-02-24. During this period, we have: * 2214 builds (98.7% passed, 1.3% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 575 test runs (32.2% passed, 65.5% unstable, 2.3% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 7 doc buils (100% passed) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. Web version of this report is available at https://hackmd.io/s/rJAJu2RSE and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * lib.libc.sys.sendfile_test.hdtr_positive_v4 * lib.libc.sys.sendfile_test.hdtr_positive_v6 Fixed (Remove expected failure) in https://svnweb.freebsd.org/changeset/base/344310 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * common.rates.t_dtrace_contrib.tst_switchrate_d * common.syscall.t_dtrace_contrib.tst_args_d * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sbin.bectl.bectl_test.bectl_mount * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum WIP: https://reviews.freebsd.org/D18495 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.procstat.procstat_test.kernel_stacks * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * sys.netmap.ctrl-api-test.main * sys.opencrypto.runtests.main * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Open Issues ### Cause build fails * [233339: genassym.o build race](https://bugs.freebsd.org/233339) * Patch available: https://people.freebsd.org/~bdrewery/patches/PR233339.diff * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ## Other News * After creating pipeline for clang800-import branch in project/, now we support adding pipeline for other projects. Please contact jenkins-admin through "Testing & CI" component of "Services" product on https://bugs.freebsd.org From owner-freebsd-stable@freebsd.org Wed Feb 27 19:40:28 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCA8C1502E16 for ; Wed, 27 Feb 2019 19:40:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6238A8C601 for ; Wed, 27 Feb 2019 19:40:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 1C8771502E15; Wed, 27 Feb 2019 19:40:28 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0ACCC1502E14 for ; Wed, 27 Feb 2019 19:40:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EB818C600 for ; Wed, 27 Feb 2019 19:40:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1gz53w-000HdB-GZ for stable@freebsd.org; Wed, 27 Feb 2019 22:40:16 +0300 Date: Wed, 27 Feb 2019 22:40:16 +0300 From: Slawa Olhovchenkov To: stable@freebsd.org Subject: ZFS boot code regression Message-ID: <20190227194016.GB2178@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 0EB818C600 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.50 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.952,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.74)[0.744,0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[zxy.spb.ru]; NEURAL_SPAM_LONG(0.91)[0.911,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[country: RU(0.00)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:40:29 -0000 1. gptzfsboot from 12 incompatible w/ loader from 11 ("kernel not found") 2. loader from 12 incomatibe w/ kernel from 11 (ZFS file system unknown) From owner-freebsd-stable@freebsd.org Wed Feb 27 20:54:25 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B06141504F66 for ; Wed, 27 Feb 2019 20:54:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1BA8F764 for ; Wed, 27 Feb 2019 20:54:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id D33A71504F65; Wed, 27 Feb 2019 20:54:24 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95D2D1504F64 for ; Wed, 27 Feb 2019 20:54:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71B478F763 for ; Wed, 27 Feb 2019 20:54:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1gz6Dc-000IPs-4F for stable@freebsd.org; Wed, 27 Feb 2019 23:54:20 +0300 Date: Wed, 27 Feb 2019 23:54:20 +0300 From: Slawa Olhovchenkov To: stable@freebsd.org Subject: FreeBSD-11: Fatal trap 9: general protection fault while in kernel mode (in key_addref()) Message-ID: <20190227205420.GC2178@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 71B478F763 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.39 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.90)[0.896,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.70)[0.696,0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: zxy.spb.ru]; NEURAL_SPAM_LONG(0.90)[0.904,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[country: RU(0.00)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 20:54:26 -0000 Is this known issuse? Fatal trap 9: general protection fault while in kernel mode cpuid = 13; apic id = 2a instruction pointer = 0x20:0xffffffff806b6a94 stack pointer = 0x28:0xfffffe2026e274f0 frame pointer = 0x28:0xfffffe2026e274f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq295: t5nex0:0a5) trap number = 9 panic: general protection fault cpuid = 13 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8032667b = db_trace_self_wrapper+0x2b/frame 0xfffffe2026e27130 vpanic() at 0xffffffff804c2006 = vpanic+0x186/frame 0xfffffe2026e271b0 panic() at 0xffffffff804c1e73 = panic+0x43/frame 0xfffffe2026e27210 trap_fatal() at 0xffffffff807503f2 = trap_fatal+0x322/frame 0xfffffe2026e27260 trap() at 0xffffffff8074fa5e = trap+0x5e/frame 0xfffffe2026e27420 calltrap() at 0xffffffff80735771 = calltrap+0x8/frame 0xfffffe2026e27420 --- trap 0x9, rip = 0xffffffff806b6a94, rsp = 0xfffffe2026e274f0, rbp = 0xfffffe2026e274f0 --- key_addref() at 0xffffffff806b6a94 = key_addref+0x4/frame 0xfffffe2026e274f0 ipsec_getpcbpolicy() at 0xffffffff806b20b9 = ipsec_getpcbpolicy+0x49/frame 0xfffffe2026e27530 ipsec4_getpolicy() at 0xffffffff806b10a5 = ipsec4_getpolicy+0x25/frame 0xfffffe2026e275d0 ipsec4_in_reject() at 0xffffffff806b138b = ipsec4_in_reject+0x1b/frame 0xfffffe2026e27600 tcp_input() at 0xffffffff8066127c = tcp_input+0x97c/frame 0xfffffe2026e27740 ip_input() at 0xffffffff805e447f = ip_input+0x10f/frame 0xfffffe2026e277a0 netisr_dispatch_src() at 0xffffffff805c4750 = netisr_dispatch_src+0xa0/frame 0xfffffe2026e277f0 ether_demux() at 0xffffffff805b43ff = ether_demux+0x13f/frame 0xfffffe2026e27820 ether_nh_input() at 0xffffffff805b506b = ether_nh_input+0x31b/frame 0xfffffe2026e27880 netisr_dispatch_src() at 0xffffffff805c4750 = netisr_dispatch_src+0xa0/frame 0xfffffe2026e278d0 ether_input() at 0xffffffff805b4676 = ether_input+0x26/frame 0xfffffe2026e278f0 t4_eth_rx() at 0xffffffff816403b3 = t4_eth_rx+0x103/frame 0xfffffe2026e27910 service_iq() at 0xffffffff81644886 = service_iq+0x4a6/frame 0xfffffe2026e279c0 t4_intr() at 0xffffffff81644b3e = t4_intr+0x2e/frame 0xfffffe2026e279e0 intr_event_execute_handlers() at 0xffffffff804871ac = intr_event_execute_handlers+0xec/frame 0xfffffe2026e27a20 ithread_loop() at 0xffffffff80487846 = ithread_loop+0xd6/frame 0xfffffe2026e27a70 fork_exit() at 0xffffffff80484805 = fork_exit+0x85/frame 0xfffffe2026e27ab0 fork_trampoline() at 0xffffffff80735cae = fork_trampoline+0xe/frame 0xfffffe2026e27ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Uptime: 657d14h33m52s From owner-freebsd-stable@freebsd.org Wed Feb 27 23:37:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0BD1508F6E for ; Wed, 27 Feb 2019 23:37:31 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C4BE6960E3 for ; Wed, 27 Feb 2019 23:37:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 887EB1508F6D; Wed, 27 Feb 2019 23:37:30 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 760D61508F6C for ; Wed, 27 Feb 2019 23:37:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAEFB960E2 for ; Wed, 27 Feb 2019 23:37:29 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1RNbR8i053450 for ; Wed, 27 Feb 2019 15:37:27 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1RNbRU7053449 for stable@freebsd.org; Wed, 27 Feb 2019 15:37:27 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902272337.x1RNbRU7053449@pdx.rh.CN85.dnsmgr.net> Subject: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: stable@freebsd.org Date: Wed, 27 Feb 2019 15:37:27 -0800 (PST) Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: AAEFB960E2 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.77 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.01)[ip: (0.06), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_SHORT(0.19)[0.193,0]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; NEURAL_SPAM_LONG(0.85)[0.853,0]; DMARC_NA(0.00)[dnsmgr.net]; NEURAL_SPAM_MEDIUM(0.83)[0.826,0]; R_SPF_NA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 23:37:31 -0000 config CUSTOM Kernel build directory is ../compile/CUSTOM Don't forget to do ``make cleandepend && make depend'' fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make -j4 && make install) >&make.OUT fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support fb-bld-120-i386.dnsmgr.net:root {203}# uname -a FreeBSD fb-bld-120-i386.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC i386 fb-bld-120-i386.dnsmgr.net:root {204}# fb-bld-120-i386.dnsmgr.net:root {205}# cd ../../conf fb-bld-120-i386.dnsmgr.net:root {206}# config GENERIC Kernel build directory is ../compile/GENERIC Don't forget to do ``make cleandepend && make depend'' fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/GENERIC fb-bld-120-i386.dnsmgr.net:root {209}# !201 ( make cleandepend && make depend && make -j4 && make install ) > & make.OUT fb-bld-120-i386.dnsmgr.net:root {210}# fb-bld-120-i386.dnsmgr.net:root {210}# more make.OUT make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support fb-bld-120-i386.dnsmgr.net:root {211}# -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 01:35:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D3F6150DC42 for ; Thu, 28 Feb 2019 01:35:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) 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 C80666D5F2 for ; Thu, 28 Feb 2019 01:35:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 82005150DC3E; Thu, 28 Feb 2019 01:35:30 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45C3B150DC3D for ; Thu, 28 Feb 2019 01:35:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670046.outbound.protection.outlook.com [40.107.67.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBF486D5EB; Thu, 28 Feb 2019 01:35:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM (52.132.89.15) by QB1PR01MB2562.CANPRD01.PROD.OUTLOOK.COM (52.132.86.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.19; Thu, 28 Feb 2019 01:35:27 +0000 Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c]) by QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c%6]) with mapi id 15.20.1643.022; Thu, 28 Feb 2019 01:35:27 +0000 From: Rick Macklem To: "stable@freebsd.org" , "rgrimes@freebsd.org" Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? Thread-Topic: FreeBSD 12.0 RELEASE i386 can not build a kernel? Thread-Index: AQHUzvVx5gQ9lwihIUyUHmON6TqFyaX0bHvJ Date: Thu, 28 Feb 2019 01:35:27 +0000 Message-ID: References: <201902272337.x1RNbRU7053449@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902272337.x1RNbRU7053449@pdx.rh.CN85.dnsmgr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd78efb6-bf8d-4f51-e169-08d69d1d0480 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:QB1PR01MB2562; x-ms-traffictypediagnostic: QB1PR01MB2562: x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; QB1PR01MB2562; 23:ZmdNCjEoSKtLmkz3wLquoAzr5iLTZCmc0qwF0lV?= =?iso-8859-1?Q?BVvE5/KH+e9hvLvIjSj0O9eTn1vIggea403PSwL8if5l3UyYoE/Hw2Jiuo?= =?iso-8859-1?Q?SIsNysf2MTRmaq/Qh60DKMrctviWfMafEA+bp5EUcHRP3LtP1Bj3hEue9U?= =?iso-8859-1?Q?gWOxHxakyE/9ogeMnnf5Mm4wvmAEHzEh5WaEdYOAgxaFVJl7Zq6c19DvbQ?= =?iso-8859-1?Q?pZF6q9doiVOln0AhJBlu6sIPmumP70qMx5xn9a8S5zSk6TQVGGyVfpNBCl?= =?iso-8859-1?Q?RVB85rjmzPhytJqAJfT0s7U4chhntpi9JLnVtNyj2dO5DvAP+mQqp8Js1D?= =?iso-8859-1?Q?Pv2OPG+o0qNUq3L9BSpOIzAFjBNMYMePeYUDh9re5DiTzs1twnWlslAe5+?= =?iso-8859-1?Q?K/WvI96FOmv8k9CRhJ3+SdDdaj9TTncRVoN02+9UmTT7GrQGMu/nN9HGo9?= =?iso-8859-1?Q?PeCoQpcv4le3JhViCtMvnRn9YGyDTWADholwOzvKhpeybYhZV5QO3SLJs2?= =?iso-8859-1?Q?JnKy1DpocbBC44mB/F8r1aPtfMp4j+mgTp9EP66AgyL5OlQrsOdh8W8ZVY?= =?iso-8859-1?Q?wBvqPYbODWSj4G4Cny8IQww5teGwiFomhXLUlTwYjDGaLLXd2fbq6hRM7+?= =?iso-8859-1?Q?Qz3G81KR2/43O/BxKReFV9DV5zfzIIb/Urn27q6dm88vN9Y+ne203PULSD?= =?iso-8859-1?Q?uRRa0NLFKHHU/qyt30P1d+g2FGMoYAVqyQizFtInCwVuk0fqj4jdDUbKtr?= =?iso-8859-1?Q?xIEVo3GivMmrOqv+Ugavy24xCXDipDWLJ3PGGuUyujgF1rpRV+kkUV8nT/?= =?iso-8859-1?Q?jyDnlZMVdxTjYRpmKuLCj+i/9sa+FmBbVUnB+vG/Xf5C7sbkollL9LDoH8?= =?iso-8859-1?Q?tJWthzCoirttgk0U6wrDHhuUXz7UZ49ie2yk6tbjrZH2YrpZiOSzjm4Rf1?= =?iso-8859-1?Q?V68iYryxQE1ghLD1KJlzzXT2KXw27gmKb13glYTdq9HQtYhO7yno1PTUpv?= =?iso-8859-1?Q?oejYEBfssq87hfVPm9HOy9ySzAgawdypkuvMDedvJxtImLq0oOOveblg+4?= =?iso-8859-1?Q?h48XqoJ1KSzQBU10M1P7rVzq6pGLjbfVTPawfs8i638hP/ZPBNgFyeb2Xj?= =?iso-8859-1?Q?y7pRU3/aYMt/JO4kXbANHJNWwjACptDclJrFmURyvZ8LsXYMLwaKFMx90c?= =?iso-8859-1?Q?aD0hAsxcuXr4O7N4aGq4SYqo97380TGmBOI2rwGEzpnsEyQMtrqftKKPPu?= =?iso-8859-1?Q?ocsPz7zVWEu4aNzLb?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(376002)(346002)(136003)(199004)(189003)(53936002)(6506007)(6346003)(6246003)(8936002)(8676002)(81156014)(81166006)(450100002)(478600001)(99286004)(86362001)(186003)(74316002)(2501003)(305945005)(97736004)(229853002)(55016002)(9686003)(6436002)(7696005)(102836004)(68736007)(76176011)(25786009)(14454004)(2906002)(110136005)(46003)(74482002)(5660300002)(256004)(486006)(446003)(14444005)(11346002)(71190400001)(71200400001)(786003)(476003)(4744005)(33656002)(105586002)(316002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB2562; H:QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: viaeO1uQUrGAuELZInGXwmhVefPQMS5Sz7jkeeoyg07jBpIkuJECBRV+bb6p7Ou9Dndgsec9UjxcxXPzXLX415/1AwWR4XjTCI9bdeDvvRbyASY7DDOM2ZLX5WC9p9urP+5sJt4C1aaNW/V3EOVGtWA1CP6mo29HDCd/GEkJXO4nOTNUK5k1vfrCRq5TdQK69uaw4ncdYaUZ+LvDhr32azpM4Jo0PAlYLxN6g2LDVMg+mc3WZqNBeptSaYgCa+c2aKKniXFdyAzxa9EUoSsqntUhPCeGgw8D1glI+N8EJBA2bzaR3hmpFbxUSz9yi8EW74L7W67BzcO4PyH7PiyZv+HRHIM17bzlVP7UpDxSi7qa83U5OsD1co0LZFR/UC6k08xKtV/vcQwFVeKCMbhzTb5zAI0tIZ1D45t0ZMta6Co= 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: cd78efb6-bf8d-4f51-e169-08d69d1d0480 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 01:35:27.3850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2562 X-Rspamd-Queue-Id: CBF486D5EB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:35:31 -0000 Rodney W. Grimes wrote: >config CUSTOM >Kernel build directory is ../compile/CUSTOM >Don't forget to do ``make cleandepend && make depend'' >fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM >fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend &&= >make -j4 && make install) >&make.OUT >fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT >make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386= kernel >requires linker ifunc support I typically build kernels without doing "make buildkernel" and I've found I= need LD=3Dlld SRCTOP=3D on the make commands. (or something close to that. I haven't done this since December.) I haven't tried, but I assumed "make buildkernel" takes care of this "behin= d the curtains". rick From owner-freebsd-stable@freebsd.org Thu Feb 28 01:51:00 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB495150EDF3 for ; Thu, 28 Feb 2019 01:50:59 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 503D26E0F4 for ; Thu, 28 Feb 2019 01:50:59 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0F6C2150EDE9; Thu, 28 Feb 2019 01:50:59 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F21AB150EDE6 for ; Thu, 28 Feb 2019 01:50:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AA1A6E0EE; Thu, 28 Feb 2019 01:50:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1S1otRV053872; Wed, 27 Feb 2019 17:50:55 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1S1ot00053871; Wed, 27 Feb 2019 17:50:55 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902280150.x1S1ot00053871@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Rick Macklem Date: Wed, 27 Feb 2019 17:50:55 -0800 (PST) CC: "stable@freebsd.org" , "rgrimes@freebsd.org" Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 7AA1A6E0EE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:51:00 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > Rodney W. Grimes wrote: > >config CUSTOM > >Kernel build directory is ../compile/CUSTOM > >Don't forget to do ``make cleandepend && make depend'' > >fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > >fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && >make -j4 && make install) >&make.OUT > >fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > >make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel >requires linker ifunc support > I typically build kernels without doing "make buildkernel" and I've found I need > LD=lld SRCTOP= on the make commands. > (or something close to that. I haven't done this since December.) > I haven't tried, but I assumed "make buildkernel" takes care of this "behind the > curtains". -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- cd /usr/obj/usr/src/i386.i386/sys/GENERIC; MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= CC="cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CXX="c++ -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CPP="cpp -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp -B/usr/obj/usr/src/i386.i386/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386.i386/tmp/legacy/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/legacy/usr/bin:/usr/obj/usr/src/i386.i386/tmp/legacy/bin:/usr/obj/usr/src/i386.i386/tmp/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /usr/src/share/mk KERNEL=kernel cleandir make[2]: "/usr/src/sys/conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src > rick -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 06:56:08 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA669151D868 for ; Thu, 28 Feb 2019 06:56:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5203D82DF6 for ; Thu, 28 Feb 2019 06:56:08 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 08DD0151D867; Thu, 28 Feb 2019 06:56:08 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA53B151D866 for ; Thu, 28 Feb 2019 06:56:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80DB782DF4; Thu, 28 Feb 2019 06:56:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::80fb:b37d:41e4:438b] (unknown [IPv6:2001:470:7a58:0:80fb:b37d:41e4:438b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3ED51382C8; Thu, 28 Feb 2019 07:55:59 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B3065D42-6083-4ED4-AF3E-425E5D21AF43"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? Date: Thu, 28 Feb 2019 07:55:58 +0100 In-Reply-To: <201902272337.x1RNbRU7053449@pdx.rh.CN85.dnsmgr.net> Cc: stable@freebsd.org To: rgrimes@freebsd.org References: <201902272337.x1RNbRU7053449@pdx.rh.CN85.dnsmgr.net> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 80DB782DF4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 06:56:08 -0000 --Apple-Mail=_B3065D42-6083-4ED4-AF3E-425E5D21AF43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Feb 2019, at 00:37, Rodney W. Grimes = wrote: >=20 > config CUSTOM > Kernel build directory is ../compile/CUSTOM > Don't forget to do ``make cleandepend && make depend'' > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make = depend && make -j4 && make install) >&make.OUT > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > make: "../../../conf/../../../conf/kern.pre.mk" line 127: = amd64/arm64/i386 kernel requires linker ifunc support After ifunc support was introduced, you have to run at least "make kernel-toolchain" before "make buildkernel", or otherwise just run "make buildworld" first. That will build the linker which supports the required functionality. -Dimitry --Apple-Mail=_B3065D42-6083-4ED4-AF3E-425E5D21AF43 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXHeF/gAKCRCwXqMKLiCW o4+pAJ9lzzaOrIpE8OqaV+L6uBQ8cRjUKgCfblcg7D7mC7q8EffSMsoTeg+tSaU= =GFW9 -----END PGP SIGNATURE----- --Apple-Mail=_B3065D42-6083-4ED4-AF3E-425E5D21AF43-- From owner-freebsd-stable@freebsd.org Thu Feb 28 07:20:44 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9ECA151EEB3 for ; Thu, 28 Feb 2019 07:20:44 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2808D83FCD for ; Thu, 28 Feb 2019 07:20:43 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D97A9151EEB2; Thu, 28 Feb 2019 07:20:42 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C559A151EEB1 for ; Thu, 28 Feb 2019 07:20:42 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 350C083FC6; Thu, 28 Feb 2019 07:20:41 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1S7Kegs054943; Wed, 27 Feb 2019 23:20:40 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1S7Kewb054942; Wed, 27 Feb 2019 23:20:40 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902280720.x1S7Kewb054942@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Dimitry Andric Date: Wed, 27 Feb 2019 23:20:40 -0800 (PST) CC: rgrimes@FreeBSD.org, stable@FreeBSD.org Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 350C083FC6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 07:20:45 -0000 -- Start of PGP signed section. > On 28 Feb 2019, at 00:37, Rodney W. Grimes wrote: > > > > config CUSTOM > > Kernel build directory is ../compile/CUSTOM > > Don't forget to do ``make cleandepend && make depend'' > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make -j4 && make install) >&make.OUT > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support > > After ifunc support was introduced, you have to run at least > "make kernel-toolchain" before "make buildkernel", or otherwise just run > "make buildworld" first. That will build the linker which supports the > required functionality. This is the -RELEASE, why is the release not built with the proper toolchain in place? This is not some upgrade or anything odd, download 12.0-RELEASE i386 iso, install it with sources, try to build a kernel. I am running your suggested make kernel-toolchain now to see if that fixes the problem (it shouid not, or if it does we have a major issue with our release building procedures.) > -Dimitry -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 08:49:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 160E31521EDC for ; Thu, 28 Feb 2019 08:49:31 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 71B0887007 for ; Thu, 28 Feb 2019 08:49:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 3050C1521ED9; Thu, 28 Feb 2019 08:49:30 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D7351521ED8 for ; Thu, 28 Feb 2019 08:49:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A1C286FFF; Thu, 28 Feb 2019 08:49:29 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1S8nPpI055317; Thu, 28 Feb 2019 00:49:25 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1S8nPwR055316; Thu, 28 Feb 2019 00:49:25 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902280849.x1S8nPwR055316@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: <201902280720.x1S7Kewb054942@pdx.rh.CN85.dnsmgr.net> To: rgrimes@FreeBSD.org Date: Thu, 28 Feb 2019 00:49:25 -0800 (PST) CC: Dimitry Andric , stable@FreeBSD.org Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 6A1C286FFF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 08:49:31 -0000 > -- Start of PGP signed section. > > On 28 Feb 2019, at 00:37, Rodney W. Grimes wrote: > > > > > > config CUSTOM > > > Kernel build directory is ../compile/CUSTOM > > > Don't forget to do ``make cleandepend && make depend'' > > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make -j4 && make install) >&make.OUT > > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support > > > > After ifunc support was introduced, you have to run at least > > "make kernel-toolchain" before "make buildkernel", or otherwise just run > > "make buildworld" first. That will build the linker which supports the > > required functionality. > > This is the -RELEASE, why is the release not built with the > proper toolchain in place? This is not some upgrade or anything > odd, download 12.0-RELEASE i386 iso, install it with sources, > try to build a kernel. > > I am running your suggested make kernel-toolchain now > to see if that fixes the problem (it shouid not, or > if it does we have a major issue with our release > building procedures.) Sadly I have confirmed that "make kernel-toolchain" does infact fix the above error. Now the begging question, why isnt the toolchain as shipped already properly built? This is a stock FreeBSD-12.0=RELEASE-i386-disc1.iso install, with stock sources from the iso. I was simply configuring a custom kernel, I should not need to build a took chain to build a kernel when nothing has changed from the RELEASE, it should already be the correct toolchain. > > -Dimitry > -- > Rod Grimes rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 09:44:21 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CB3D1524E70 for ; Thu, 28 Feb 2019 09:44:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D1DAD89F7B for ; Thu, 28 Feb 2019 09:44:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 958B81524E69; Thu, 28 Feb 2019 09:44:20 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 841671524E68 for ; Thu, 28 Feb 2019 09:44: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 A3A8289F78; Thu, 28 Feb 2019 09:44: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 x1S9iCke007874 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 11:44:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1S9iCke007874 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1S9iCqj007873; Thu, 28 Feb 2019 11:44:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Feb 2019 11:44:12 +0200 From: Konstantin Belousov To: rgrimes@FreeBSD.org Cc: stable@FreeBSD.org, Dimitry Andric Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? Message-ID: <20190228094412.GS2420@kib.kiev.ua> References: <201902280720.x1S7Kewb054942@pdx.rh.CN85.dnsmgr.net> <201902280849.x1S8nPwR055316@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201902280849.x1S8nPwR055316@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 09:44:21 -0000 On Thu, Feb 28, 2019 at 12:49:25AM -0800, Rodney W. Grimes wrote: > > -- Start of PGP signed section. > > > On 28 Feb 2019, at 00:37, Rodney W. Grimes wrote: > > > > > > > > config CUSTOM > > > > Kernel build directory is ../compile/CUSTOM > > > > Don't forget to do ``make cleandepend && make depend'' > > > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > > > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make -j4 && make install) >&make.OUT > > > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > > > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support > > > > > > After ifunc support was introduced, you have to run at least > > > "make kernel-toolchain" before "make buildkernel", or otherwise just run > > > "make buildworld" first. That will build the linker which supports the > > > required functionality. > > > > This is the -RELEASE, why is the release not built with the > > proper toolchain in place? This is not some upgrade or anything > > odd, download 12.0-RELEASE i386 iso, install it with sources, > > try to build a kernel. > > > > I am running your suggested make kernel-toolchain now > > to see if that fixes the problem (it shouid not, or > > if it does we have a major issue with our release > > building procedures.) > > Sadly I have confirmed that "make kernel-toolchain" does infact > fix the above error. > > Now the begging question, why isnt the toolchain as shipped > already properly built? > > This is a stock FreeBSD-12.0=RELEASE-i386-disc1.iso install, > with stock sources from the iso. I was simply configuring > a custom kernel, I should not need to build a took chain > to build a kernel when nothing has changed from the > RELEASE, it should already be the correct toolchain. Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? Then you need to use 'LD=ld.ldd make'. The proper way of 'make buildkernel' from top-level src handles it automatically. From owner-freebsd-stable@freebsd.org Thu Feb 28 12:50:49 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 828691506571 for ; Thu, 28 Feb 2019 12:50:49 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D95D9684EA for ; Thu, 28 Feb 2019 12:50:48 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 9278D150656D; Thu, 28 Feb 2019 12:50:48 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FED4150656B for ; Thu, 28 Feb 2019 12:50:48 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1039684E5; Thu, 28 Feb 2019 12:50:47 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SCogn1056288; Thu, 28 Feb 2019 04:50:42 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SCogDB056287; Thu, 28 Feb 2019 04:50:42 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281250.x1SCogDB056287@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: <20190228094412.GS2420@kib.kiev.ua> To: Konstantin Belousov Date: Thu, 28 Feb 2019 04:50:42 -0800 (PST) CC: rgrimes@FreeBSD.org, stable@FreeBSD.org, Dimitry Andric Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: E1039684E5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.950,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 12:50:49 -0000 > On Thu, Feb 28, 2019 at 12:49:25AM -0800, Rodney W. Grimes wrote: > > > -- Start of PGP signed section. > > > > On 28 Feb 2019, at 00:37, Rodney W. Grimes wrote: > > > > > > > > > > config CUSTOM > > > > > Kernel build directory is ../compile/CUSTOM > > > > > Don't forget to do ``make cleandepend && make depend'' > > > > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM > > > > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make -j4 && make install) >&make.OUT > > > > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT > > > > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support > > > > > > > > After ifunc support was introduced, you have to run at least > > > > "make kernel-toolchain" before "make buildkernel", or otherwise just run > > > > "make buildworld" first. That will build the linker which supports the > > > > required functionality. > > > > > > This is the -RELEASE, why is the release not built with the > > > proper toolchain in place? This is not some upgrade or anything > > > odd, download 12.0-RELEASE i386 iso, install it with sources, > > > try to build a kernel. > > > > > > I am running your suggested make kernel-toolchain now > > > to see if that fixes the problem (it shouid not, or > > > if it does we have a major issue with our release > > > building procedures.) > > > > Sadly I have confirmed that "make kernel-toolchain" does infact > > fix the above error. > > > > Now the begging question, why isnt the toolchain as shipped > > already properly built? > > > > This is a stock FreeBSD-12.0=RELEASE-i386-disc1.iso install, > > with stock sources from the iso. I was simply configuring > > a custom kernel, I should not need to build a took chain > > to build a kernel when nothing has changed from the > > RELEASE, it should already be the correct toolchain. > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > Then you need to use 'LD=ld.ldd make'. The proper way of > 'make buildkernel' from top-level src handles it automatically. > If you back up in the thread you would also see the output is the same for cd /usr/src; make buildkernel conf=CUSTOM -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 13:07:45 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 493F11506BCD for ; Thu, 28 Feb 2019 13:07:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9E0C16A155 for ; Thu, 28 Feb 2019 13:07:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 578731506BC8; Thu, 28 Feb 2019 13:07:44 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44B4A1506BC6 for ; Thu, 28 Feb 2019 13:07:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B20566A150; Thu, 28 Feb 2019 13:07:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f180.google.com with SMTP id v2so14513837ith.3; Thu, 28 Feb 2019 05:07:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YUhO6tDLdjimQs3IMUK10AfMJQ0ywPNAXS5nvfxVh50=; b=GMcnaipx3XBm6sdJ4QQz846WUop5a7VsRx4T7QGdSXYpWI0d6e8EnQ7LM5sRnHY7xG s3gHdRmEHVcyaAtxJ4aDtL+2dNT9Tgg2bUAiX7pTCOWW7GIl1jT3One5gD96YWeEbwPG dj8QRmGioyN9Y7CzM3SAJ9tbjPeMYbbi37cLC/dGRDYwoyD1wKenbP4x0XNPZALoXF6m 6M4i8FHon5ASjPRqrWGCAaPLQq4mQsqY/QgbahF+fxGsa8BfEgWYdrE12IJrh+uiGCuS OsdnJbNFvY/WblkER+CGURdBQdOKC+D4MxHafxZZnWo8hzThDp4fN/qBGQx0U41468g+ 2Umw== X-Gm-Message-State: AHQUAuaOkqZIq/wKvOfI/Cv2U0GvkNhSF4RYAzWuq9gLB2yYM1TEnFfz NtlA1DDbFP86gOnlyb1QbLngEfrqdwj6fhsUH700YA== X-Google-Smtp-Source: APXvYqyQoAiUSXYUgVhPT32WojxMFe/YlcNyf4cHab3leEc44C8ughW7vu7zDU4HH6Kv59RnF/t41Fv6mOyrb9QzZEI= X-Received: by 2002:a24:6f94:: with SMTP id x142mr2696543itb.33.1551359256205; Thu, 28 Feb 2019 05:07:36 -0800 (PST) MIME-Version: 1.0 References: <201902280720.x1S7Kewb054942@pdx.rh.CN85.dnsmgr.net> <201902280849.x1S8nPwR055316@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902280849.x1S8nPwR055316@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Thu, 28 Feb 2019 08:07:24 -0500 Message-ID: Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: "Rodney W. Grimes" Cc: stable@freebsd.org, Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B20566A150 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.91 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.91)[-0.909,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:07:45 -0000 On Thu, 28 Feb 2019 at 03:50, Rodney W. Grimes wrote: > > Now the begging question, why isnt the toolchain as shipped > already properly built? The required toolchain is included in 12.0-RELEASE i386 - the linker is /usr/bin/ld.lld. It just needs to be specified explicitly if build via a method other than make buildworld or kernel-toolchain followed by buildkernel. I wanted to ship 12.0 i386 with lld as /usr/bin/ld, but held off on re and portmgr's advice due to ports fallout. From owner-freebsd-stable@freebsd.org Thu Feb 28 13:18:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D1A5150702C for ; Thu, 28 Feb 2019 13:18:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1EE6A74B for ; Thu, 28 Feb 2019 13:18:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 35457150702B; Thu, 28 Feb 2019 13:18:29 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 225EC150702A for ; Thu, 28 Feb 2019 13:18:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7D776A748; Thu, 28 Feb 2019 13:18:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f43.google.com with SMTP id x3so16519765ior.6; Thu, 28 Feb 2019 05:18:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N0zZyGqT2K5BnpBYyFu9yq2V85JsHSGYo7qkqKfoEWQ=; b=rIyZh0vHjoXAaGJBo7FW3eaOPDk/p2YVr5wlKVJoGxtscl6Mk1yIrXxCozicW4nXPe L8uWiLqb//VE7BxOPU/zqmwrDQ9nvZga32ImHoyCzQgoqLfu57EzolFrXXx+dk7eSXWm BHAzgDowopPfOx3cRtmlXkO7mfTjnvlj1SD0wWwNaioGG65RnjLXCOSjBHEzALKUp2bJ wDUag9DoxGL2cwi9bc1CqcvM6K6BLSJrJUTewGwXNumC8IuyvJ+lW/7+te+v7oMZWToV dTNJ6JehQyGgH50upDymGdt70AhLd+TxO+lRgEJE4w3lz8pvHsJICUM5d7sUPjluUUOJ WsPQ== X-Gm-Message-State: APjAAAXTnqTs+L1Y4f8IlltdCfv3Z3fxfcv/VEg0SGoAAnm0RGKbQBzR ulO7V2M/QINC4u8tL708gXnVx8t2VURykWQP8sHMFSI5 X-Google-Smtp-Source: APXvYqwFQBli4WpB8yA0HKJTQ4MjOY0UMJ5M4plME2Idj9lOD1Y3Q9Joxh/3p+8YqzzH9L4Ah2ifF/zGR5TtGsIc/CE= X-Received: by 2002:a6b:ee02:: with SMTP id i2mr4928463ioh.294.1551359901416; Thu, 28 Feb 2019 05:18:21 -0800 (PST) MIME-Version: 1.0 References: <20190228094412.GS2420@kib.kiev.ua> <201902281250.x1SCogDB056287@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902281250.x1SCogDB056287@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Thu, 28 Feb 2019 08:18:09 -0500 Message-ID: Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: "Rodney W. Grimes" Cc: Konstantin Belousov , stable@freebsd.org, Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A7D776A748 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.91 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.911,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:18:30 -0000 > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > > Then you need to use 'LD=ld.ldd make'. The proper way of > > 'make buildkernel' from top-level src handles it automatically. > > > If you back up in the thread you would also see the output > is the same for cd /usr/src; make buildkernel conf=CUSTOM "make buildworld" or "make kernel-toolchain" needs to be run first. Also, there's a typo in kib's command - it should be LD=ld.lld (two 'l's, not two 'd's). There's more information about this issue (when it applied to amd64) at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html. From owner-freebsd-stable@freebsd.org Thu Feb 28 13:18:49 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD7891507041 for ; Thu, 28 Feb 2019 13:18:49 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 44C6B6A776 for ; Thu, 28 Feb 2019 13:18:49 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id F28A81507040; Thu, 28 Feb 2019 13:18:48 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE910150703D for ; Thu, 28 Feb 2019 13:18:48 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 567B66A770; Thu, 28 Feb 2019 13:18:48 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SDIjV9056481; Thu, 28 Feb 2019 05:18:45 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SDIjOn056480; Thu, 28 Feb 2019 05:18:45 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281318.x1SDIjOn056480@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Ed Maste Date: Thu, 28 Feb 2019 05:18:45 -0800 (PST) CC: "Rodney W. Grimes" , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 567B66A770 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:18:50 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, 28 Feb 2019 at 03:50, Rodney W. Grimes > wrote: > > > > Now the begging question, why isnt the toolchain as shipped > > already properly built? > > The required toolchain is included in 12.0-RELEASE i386 - the linker > is /usr/bin/ld.lld. It just needs to be specified explicitly if build > via a method other than make buildworld or kernel-toolchain followed > by buildkernel. Why is this not included in the /usr/src; make buildkernel target? > > I wanted to ship 12.0 i386 with lld as /usr/bin/ld, but held off on re > and portmgr's advice due to ports fallout. Is there a release note item describing that kernel building now requires specical procedures to build a kernel? This is a POLA issue. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 13:26:12 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A8C15074C8 for ; Thu, 28 Feb 2019 13:26:12 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2D06AD67 for ; Thu, 28 Feb 2019 13:26:12 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id DEAFC15074C7; Thu, 28 Feb 2019 13:26:11 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC17915074C3 for ; Thu, 28 Feb 2019 13:26:11 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B46E6AD61; Thu, 28 Feb 2019 13:26:11 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SDQ9Ug056522; Thu, 28 Feb 2019 05:26:09 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SDQ9ds056521; Thu, 28 Feb 2019 05:26:09 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281326.x1SDQ9ds056521@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Ed Maste Date: Thu, 28 Feb 2019 05:26:09 -0800 (PST) CC: "Rodney W. Grimes" , Konstantin Belousov , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4B46E6AD61 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:26:12 -0000 > > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > > > Then you need to use 'LD=ld.ldd make'. The proper way of > > > 'make buildkernel' from top-level src handles it automatically. > > > > > If you back up in the thread you would also see the output > > is the same for cd /usr/src; make buildkernel conf=CUSTOM > > "make buildworld" or "make kernel-toolchain" needs to be run first. Are you really rally expecting a user to rebuild the world that he just installed that should be exactly the same world he gets build (reproduceable builds and all??). But in your other mail you said the proper toolchain is included, so this is not really true? > Also, there's a typo in kib's command - it should be LD=ld.lld (two > 'l's, not two 'd's). > > There's more information about this issue (when it applied to amd64) > at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html. Yes I remeber the issue but we shipped a release with the issue in it? An issue that was hit 7 months before the release? Really? Isn't this just a mater of fixing the toplevel make at /usr/src for target buildkernel to include the LD=ld.lld or fixing the kernel Makefile likewise? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 13:50:59 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 796A01508155 for ; Thu, 28 Feb 2019 13:50:59 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BADB06BB4C for ; Thu, 28 Feb 2019 13:50:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 7993A1508154; Thu, 28 Feb 2019 13:50:58 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 673FD1508153 for ; Thu, 28 Feb 2019 13:50:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B30FD6BB47; Thu, 28 Feb 2019 13:50:57 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SDosU7056595; Thu, 28 Feb 2019 05:50:54 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SDoqdF056594; Thu, 28 Feb 2019 05:50:52 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281350.x1SDoqdF056594@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: <201902281326.x1SDQ9ds056521@pdx.rh.CN85.dnsmgr.net> To: rgrimes@freebsd.org Date: Thu, 28 Feb 2019 05:50:52 -0800 (PST) CC: Ed Maste , Konstantin Belousov , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: B30FD6BB47 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 13:50:59 -0000 > > > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > > > > Then you need to use 'LD=ld.ldd make'. The proper way of > > > > 'make buildkernel' from top-level src handles it automatically. > > > > > > > If you back up in the thread you would also see the output > > > is the same for cd /usr/src; make buildkernel conf=CUSTOM > > > > "make buildworld" or "make kernel-toolchain" needs to be run first. > > Are you really rally expecting a user to rebuild the world that > he just installed that should be exactly the same world he gets > build (reproduceable builds and all??). > > But in your other mail you said the proper toolchain is included, > so this is not really true? > > > Also, there's a typo in kib's command - it should be LD=ld.lld (two > > 'l's, not two 'd's). > > > > There's more information about this issue (when it applied to amd64) > > at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html. > > Yes I remeber the issue but we shipped a release with the issue in it? > An issue that was hit 7 months before the release? > Really? > > Isn't this just a mater of fixing the toplevel make at > /usr/src for target buildkernel to include the LD=ld.lld or > fixing the kernel Makefile likewise? I have confirmed that cd /usr/src; LD=ld.lld make buildkernel config=GENERIC does resolve this issue, so can we add LD=ld.lld to the buildkernel target and fix the kernel Makefile on i386 to have this set? (On RELENG/12.0 branch). > Rod Grimes rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 14:13:14 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA8AA1508D91 for ; Thu, 28 Feb 2019 14:13:13 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2596C958 for ; Thu, 28 Feb 2019 14:13:13 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 069171508D90; Thu, 28 Feb 2019 14:13:13 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E69961508D8F for ; Thu, 28 Feb 2019 14:13:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 734846C954; Thu, 28 Feb 2019 14:13:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f176.google.com with SMTP id v83so15812532itf.1; Thu, 28 Feb 2019 06:13:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/AMq6UzTg5oykmlEdR0M7xScaJY9IiX/aHTqso1zS9E=; b=X/EQ7NtpKk7UJmop+OgvnI7aJibGOEhwnGWsHIYVWDTHXeknK0k5cBa9Qye4DYoJp+ 2cEOVNAt/jqflRSY5B3cUZoKikEOHYBRQVXnU2cAIUgpe0aI5rymVDo/LUFNIO+qkqAC NdhMrXC1RKvrMUk7CCkPK0hcsbVvJs8XKMyBLcEznoE/dJZ8EeAOUU1cnoEilXfuEMCJ 1MgqxUAWswPNyhbmEt+xn/L+PdPx9HRaKzMbCVj0EUjlblJNtRNdzYDbR5S8czQvdNx/ VAtA9CxRQkqW+n5cLxx1B/XNOKRrqXRxAUe/cOtPL5klUe98LEG5CMJQ+Yyfov4I5f0u +5kQ== X-Gm-Message-State: AHQUAua6Alg9bZJxl+izGYjlllj+dJ6RBAe1Pdn4H5G+1oho7G0NkB79 4o6TDoWU6/50RlUxAa+M2T4K+yLYVYwEVTyNL0LTgw== X-Google-Smtp-Source: APXvYqwgZM/1/6c1iTLSekpZQ/R+8xrLucvaqIGQeKXmGIV+HQ0nIXs+krk+9EcELWZhm+VyelfF/zwO4N/zvSh63jg= X-Received: by 2002:a24:6f94:: with SMTP id x142mr2869192itb.33.1551363190673; Thu, 28 Feb 2019 06:13:10 -0800 (PST) MIME-Version: 1.0 References: <201902281326.x1SDQ9ds056521@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902281326.x1SDQ9ds056521@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Thu, 28 Feb 2019 09:12:57 -0500 Message-ID: Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: "Rodney W. Grimes" Cc: Konstantin Belousov , stable@freebsd.org, Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 734846C954 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.91)[-0.905,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 14:13:14 -0000 On Thu, 28 Feb 2019 at 08:26, Rodney W. Grimes wrote: > > Are you really rally expecting a user to rebuild the world that > he just installed that should be exactly the same world he gets > build (reproduceable builds and all??). I'm expecting that a user will either follow the directions in the handbook (or use the LD=ld.lld override). A user that rebuilds the world they just installed will indeed get the same world. > But in your other mail you said the proper toolchain is included, > so this is not really true? > Yes I remeber the issue but we shipped a release with the issue in it? > An issue that was hit 7 months before the release? > Really? Yes, unfortunately re and portmgr asked me not to change this for the release. > Isn't this just a mater of fixing the toplevel make at > /usr/src for target buildkernel to include the LD=ld.lld or > fixing the kernel Makefile likewise? Possibly, but we don't want to break things if the user provides their own setting for LD=. I had a brief look at it when this issue existed on amd64 but there was no trivial fix. From owner-freebsd-stable@freebsd.org Thu Feb 28 14:33:44 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EB451509602 for ; Thu, 28 Feb 2019 14:33:44 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 609236D393 for ; Thu, 28 Feb 2019 14:33:43 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 19FD715095F8; Thu, 28 Feb 2019 14:33:43 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0872915095F5 for ; Thu, 28 Feb 2019 14:33:43 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A0D36D38E; Thu, 28 Feb 2019 14:33:42 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SEXeJ9056761; Thu, 28 Feb 2019 06:33:40 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SEXeLc056760; Thu, 28 Feb 2019 06:33:40 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281433.x1SEXeLc056760@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Ed Maste Date: Thu, 28 Feb 2019 06:33:40 -0800 (PST) CC: "Rodney W. Grimes" , Konstantin Belousov , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 7A0D36D38E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.970,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 14:33:44 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, 28 Feb 2019 at 08:26, Rodney W. Grimes > wrote: > > > > Are you really rally expecting a user to rebuild the world that > > he just installed that should be exactly the same world he gets > > build (reproduceable builds and all??). > > I'm expecting that a user will either follow the directions in the > handbook (or use the LD=ld.lld override). A user that rebuilds the > world they just installed will indeed get the same world. > > > But in your other mail you said the proper toolchain is included, > > so this is not really true? > > > Yes I remeber the issue but we shipped a release with the issue in it? > > An issue that was hit 7 months before the release? > > Really? > > Yes, unfortunately re and portmgr asked me not to change this for the release. > > > Isn't this just a mater of fixing the toplevel make at > > /usr/src for target buildkernel to include the LD=ld.lld or > > fixing the kernel Makefile likewise? > > Possibly, but we don't want to break things if the user provides their > own setting for LD=. I had a brief look at it when this issue existed > on amd64 but there was no trivial fix. LD?=ld.lld in the right place(s)? And is this still an issue for stable/12 i386? or has ld been changed to ld.lld? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 14:42:45 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D55F7150A06A for ; Thu, 28 Feb 2019 14:42:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A400A6DD20 for ; Thu, 28 Feb 2019 14:42:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 67912150A05C; Thu, 28 Feb 2019 14:42:44 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5486C150A05B for ; Thu, 28 Feb 2019 14:42:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0C066DD1D; Thu, 28 Feb 2019 14:42:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f170.google.com with SMTP id e24so15003019itl.1; Thu, 28 Feb 2019 06:42:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jqCda+Ho8yqxGIJ+rlDOTSXlJZEwXND6ZB4TrPCoVJA=; b=VwJUyKHow+zsiPSlVysVWPeGxxZAG/8y7Q2RIcIwbTnBtaE5vK6dcemAMjiS+LFIBb zRK6jb2hu5skZ4YOSVADsZw/zfQ4z5EeaGQEE+fiXh9A0POKms9KMFn6uaBQd66XqXdD V/Al64TEIOLBIikrKHYLjPdXnAvWnIgyXuiNdmJtSoSVX1cOjWF1C32BwJH/GCvIZXS3 CS1WjmSIaCab1pA7HLlnivDxjvaiJVYVyOU7FuHBzZfBF8eHcmLPG537JgazFF3yQS9o xfhvI5lrtd1izwoSC7v2MC7pnpBIcDaiupcT0Wl9sLvzus6n4Z88n14MqJpAnYI9ukj0 YFNg== X-Gm-Message-State: APjAAAVzOREIHXYxh1eQkbXxqjiKDDJkKm8TeDfixJf653t/QmFPauhV OXiMJD8662piFQgPVQBsZ/30DnJIdDJU50gpXxRUflfB X-Google-Smtp-Source: AHgI3IZTET40GvIS5/rKcFZGgKmvFZMyE4IkeuJn3XgooMXXRB38IW8sr76upU0FQ1OPV5ssZGE/HZOfgyagMD2aGTM= X-Received: by 2002:a24:b501:: with SMTP id v1mr36999ite.174.1551364962018; Thu, 28 Feb 2019 06:42:42 -0800 (PST) MIME-Version: 1.0 References: <201902281433.x1SEXeLc056760@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902281433.x1SEXeLc056760@pdx.rh.CN85.dnsmgr.net> From: Ed Maste Date: Thu, 28 Feb 2019 09:42:29 -0500 Message-ID: Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: "Rodney W. Grimes" Cc: Konstantin Belousov , stable@freebsd.org, Dimitry Andric Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C0C066DD1D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.947,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 14:42:46 -0000 On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes wrote: > > LD?=ld.lld in the right place(s)? Perhaps, I seem to recall some issue with that, but not the specifics. > And is this still an issue for stable/12 i386? > or has ld been changed to ld.lld? stable/12 i386 still has GNU ld as /usr/bin/ld and there are a small number of ports (particularly Free Pascal ones) which fail to build with lld. They're tracked as children of PR 214864: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=214864&hide_resolved=1 The Lazarus / Free Pascal issue is in PR 233413. In my opinion we should merge the switch to lld as /usr/bin/ld to stable/12 now and iterate on fixing the remaining ports fallout, but would like re/portmgr's assent. From owner-freebsd-stable@freebsd.org Thu Feb 28 15:33:59 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7717A150BC45 for ; Thu, 28 Feb 2019 15:33:59 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 91DE370511 for ; Thu, 28 Feb 2019 15:33:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 520C9150BC3F; Thu, 28 Feb 2019 15:33:58 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6C3150BC3E for ; Thu, 28 Feb 2019 15:33:58 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2317050A; Thu, 28 Feb 2019 15:33:57 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SFXsul056991; Thu, 28 Feb 2019 07:33:54 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SFXsEu056990; Thu, 28 Feb 2019 07:33:54 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281533.x1SFXsEu056990@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Ed Maste Date: Thu, 28 Feb 2019 07:33:54 -0800 (PST) CC: "Rodney W. Grimes" , Konstantin Belousov , stable@freebsd.org, Dimitry Andric , re@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 9E2317050A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 15:33:59 -0000 > On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes > wrote: > > > > LD?=ld.lld in the right place(s)? > > Perhaps, I seem to recall some issue with that, but not the specifics. Any idea on what that issue was? > > And is this still an issue for stable/12 i386? > > or has ld been changed to ld.lld? > > stable/12 i386 still has GNU ld as /usr/bin/ld and there are a small > number of ports (particularly Free Pascal ones) which fail to build > with lld. > > They're tracked as children of PR 214864: > https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=214864&hide_resolved=1 > The Lazarus / Free Pascal issue is in PR 233413. Thank you, I am now cc: on PR214864 > In my opinion we should merge the switch to lld as /usr/bin/ld to > stable/12 now and iterate on fixing the remaining ports fallout, but > would like re/portmgr's assent. I'll defer to gjb@ on that, but this seems reasonable from my perspective. Adding re@ to cc: list -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 16:18:36 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A266150D5CA for ; Thu, 28 Feb 2019 16:18:36 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33F4472314 for ; Thu, 28 Feb 2019 16:18:35 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: by mail-pf1-x42b.google.com with SMTP id u9so9957801pfn.1 for ; Thu, 28 Feb 2019 08:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=6cXHQbQJbLhziCBychOEcpn+0m9SQHbZ2zJMyP0pZfc=; b=XiVrqad8hWYZF+00wsDPr24UDSBE1n67/3CSeR++3AWI0GBUbIzT/+A2TE1Mb3wauQ SzqsvNMR0iIyrAyjSEOTQeVwDaqUPX1wqTTKP+rRa65o/+D4auNTKPMsdYc5iz1P25zC aPB7V9Lh6diCzDXnlOsaDoxzExBbCsShb+7MgGWU3B/q8dXz5u54t1+221EDbxggPgKj rlHdostAJocVV3z22QZj8XkvfA3n/JsCGRl8OjdOeuk+GEqPas9gsr1m3/oEu46J4RPv ZrUg3LvX5p2MyVvQ86QRlGXl4FS6eVgO9F/08oouf6tuPbru+xH8X7FabPa0ctZajulS mpkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=6cXHQbQJbLhziCBychOEcpn+0m9SQHbZ2zJMyP0pZfc=; b=gkRW15T3YCItuVKUHvmuyyJSVXsyRiTjM6NfS8mTlyOanAgfQ8zqKgrWSahHjGzGhm ie1WqQnVEO94gVlUd4xgcY8yUJ7qzMc9Vh0kk/rXJv0+UhA3WgFJFQDCcTmnaOd8tTr+ mTE57UA+gXoaLA7ibfYBlJRUpIEEgA/wiMwGM/aQ68rPE5FnMEE9+P8VqfW8haW+FvwD bgh/SqGRlcLMiVphFY8P23oCvhBsYpzB1F/mtRK+N8YxjQ2jBtEmq/1mH8cmeciLOzke 4wRj/iF5jPAvnl4vlrG3WGiB6WHw8wuR6dUuQPQphCuYCTNQjzbC1CgUIJ+95Iac1fOf 5bmQ== X-Gm-Message-State: AHQUAuY/sLsKDzZ3agHWDoTZ+iAJDoSY1ncKTFfJayqLZTfIwyPaUJ89 KBChgtdLO+73P6W4+rnUUtWNoMTY X-Google-Smtp-Source: AHgI3IZvkXPSHi5CcpY8g6SdfGEe0jETqKOoOyO8Xp7iuihqKZjOHG1q15Iy0J9dcbLWtzt5B90+lw== X-Received: by 2002:a63:1053:: with SMTP id 19mr9252970pgq.55.1551370713439; Thu, 28 Feb 2019 08:18:33 -0800 (PST) Received: from vanyelcastleorg.local ([140.142.220.199]) by smtp.gmail.com with ESMTPSA id 11sm29621904pfn.7.2019.02.28.08.18.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 08:18:32 -0800 (PST) Sender: Lee Damon To: freebsd-stable@freebsd.org From: Lee Damon Subject: source upgrade FBSD10 -> 11 (then 12) Message-ID: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> Date: Thu, 28 Feb 2019 08:18:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 33F4472314 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XiVrqad8; spf=pass (mx1.freebsd.org: domain of thenomad@gmail.com designates 2607:f8b0:4864:20::42b as permitted sender) smtp.mailfrom=thenomad@gmail.com X-Spamd-Result: default: False [-5.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FORGED_SENDER(0.30)[nomad@castle.org,thenomad@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[nomad@castle.org,thenomad@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[castle.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.72)[ip: (-8.83), ipnet: 2607:f8b0::/32(-2.69), asn: 15169(-2.02), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[b.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 16:18:36 -0000 I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do this by building a new box with the latest OS then migrating services and data. Unfortunately I don't have that option this time, the upgrade has to happen in-place. My plan is to go from 10 to 11 then from 11 to 12. I was looking at the "Upgrading FreeBSD" part of https://www.freebsd.org/releases/11.1R/installation.html#upgrade but unfortunately it seems to be missing a critical URL or two: "The procedure for doing a source code based update is described in and ." I tracked down where I think it points and the instructions appear to be just for same-version updates. Can I safely move /usr/src out of the way then check out the stable/11 and compile/install it or are there other things I need to do? thanks, nomad From owner-freebsd-stable@freebsd.org Thu Feb 28 16:56:01 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 520A4150E7AE for ; Thu, 28 Feb 2019 16:56:01 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 9EC037428C for ; Thu, 28 Feb 2019 16:55:50 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id x1SGfloU062252; Thu, 28 Feb 2019 16:41:47 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: source upgrade FBSD10 -> 11 (then 12) From: Bob Bishop In-Reply-To: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> Date: Thu, 28 Feb 2019 16:41:47 +0000 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> To: Lee Damon X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 9EC037428C X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.67)[-0.670,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[250.164.32.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-1.42)[ip: (-3.95), ipnet: 194.32.164.0/24(-1.98), asn: 42831(-1.06), country: GB(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 16:56:01 -0000 Hi, > On 28 Feb 2019, at 16:18, Lee Damon wrote: >=20 > I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do = this by building a new box with the latest OS then migrating services = and data. Unfortunately I don't have that option this time, the upgrade = has to happen in-place. My plan is to go from 10 to 11 then from 11 to = 12. >=20 > I was looking at the "Upgrading FreeBSD" part of = https://www.freebsd.org/releases/11.1R/installation.html#upgrade but = unfortunately it seems to be missing a critical URL or two: >=20 > "The procedure for doing a source code based update is described in = and ." >=20 > I tracked down where I think it points and the instructions appear to = be just for same-version updates. Can I safely move /usr/src out of the = way then check out the stable/11 and compile/install it or are there = other things I need to do? See the Handbook section 23.5: = https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > thanks, > nomad -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@freebsd.org Thu Feb 28 16:59:31 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3154150E8DD for ; Thu, 28 Feb 2019 16:59:31 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E762374409 for ; Thu, 28 Feb 2019 16:59:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id A5C3B150E8DA; Thu, 28 Feb 2019 16:59:30 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 939D3150E8D9 for ; Thu, 28 Feb 2019 16:59:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 116ED74404; Thu, 28 Feb 2019 16:59:29 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1SGxQ5d057344; Thu, 28 Feb 2019 08:59:26 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1SGxP7X057343; Thu, 28 Feb 2019 08:59:25 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201902281659.x1SGxP7X057343@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Ed Maste Date: Thu, 28 Feb 2019 08:59:25 -0800 (PST) CC: "Rodney W. Grimes" , Konstantin Belousov , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 116ED74404 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 16:59:31 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes > wrote: > > > > LD?=ld.lld in the right place(s)? > > Perhaps, I seem to recall some issue with that, but not the specifics. sys.mk already does a LD?=ld so by the time we try to override it in the Makefile.i386 it is too late as already defined. *sigh* > > And is this still an issue for stable/12 i386? > > or has ld been changed to ld.lld? > > stable/12 i386 still has GNU ld as /usr/bin/ld and there are a small > number of ports (particularly Free Pascal ones) which fail to build > with lld. > > They're tracked as children of PR 214864: > https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=214864&hide_resolved=1 > The Lazarus / Free Pascal issue is in PR 233413. > > In my opinion we should merge the switch to lld as /usr/bin/ld to > stable/12 now and iterate on fixing the remaining ports fallout, but > would like re/portmgr's assent. > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Thu Feb 28 22:40:23 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2F62151C81B for ; Thu, 28 Feb 2019 22:40:22 +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 3868E8D645 for ; Thu, 28 Feb 2019 22:40:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id EC582151C81A; Thu, 28 Feb 2019 22:40:21 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7607151C819 for ; Thu, 28 Feb 2019 22:40:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F3E58D641 for ; Thu, 28 Feb 2019 22:40:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72f.google.com with SMTP id f196so13147368qke.10 for ; Thu, 28 Feb 2019 14:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v6mNFjfGHnz1wy0PUFZAFcLoO3dbGy4qDz3tFAfAIu8=; b=zjcqOC7ScWncKVUlWtDrjjeGyK5k2+JpikwIY9O/bqWTZ+87q/ZX73mDs+pNmygPy5 OUSZ4L6GBdVEr495bBsJW36viuJun3VPloxCepviTWi4rmua5zdYB4OdsRcG6WtSihZ3 4pKcXokuCfrubIlHQ50n6NdDq7rlphsu71tTEF8q59be4tQK6YEDQNy6q0AtzmPTQCyY MzrzkEFelsNj40CEKj7HvfJ6Yzvhh5/FeSMKH8Zsv7SE6EeiA9x6pLf2sl6SPv+VA5Wx jv/HV6NMbSE4cjl5mQzHx0XzETcDr86v9RepspgfcymyoUm0LupJl1C7ib1S7c/Et+dk hyAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v6mNFjfGHnz1wy0PUFZAFcLoO3dbGy4qDz3tFAfAIu8=; b=O/vQXOomYPdauCHYu26hxZn/LJ1bze+TN56qTEeTPm6Gsoc9JYJsFI7vsjwrwi06Cb 9IhFNks86MA/oGklZgINjKy+owA+8+6oF0pnnIe6LZ411Ey5LY9l094uVnU/wW5aWTEz IE+SOY6j3hW/yIXzhhivLqaAbhc9wCqd6z/SHCJ2MTe2IaaGDiH2XmmL6/mzXOR0UZhl 5W7XFM0nQHoiICosy40Z7glyPLbjdpLO60qrkeSwUtnQt+iXePkdMqvByM67DxxqFUJ3 vd/4oAz19n2CULflqJoj9yA/napwD7u6BUuK7kUTt8WPjAScJU1zsAlvZPhYuRZYj1tF J7Pw== X-Gm-Message-State: APjAAAUym/Jpum2ldcg+ovYmKtWp+pbkNB7UpzbHflwySsp9TqCsDsxl Kc2SBrR0Z0jafxYE6QZVFx1+0TNx8KY2p0Oe8Rxkrw== X-Google-Smtp-Source: APXvYqx6ewoIydW8oIW93l9L8/LiD9pAZ0kmxtL3Sivu++a6qcgbftHnjCS5vfKssj3I5xWeXN4WVAl3wXUF/whiveM= X-Received: by 2002:a37:a704:: with SMTP id q4mr1539782qke.245.1551393620477; Thu, 28 Feb 2019 14:40:20 -0800 (PST) MIME-Version: 1.0 References: <201902281659.x1SGxP7X057343@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902281659.x1SGxP7X057343@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Thu, 28 Feb 2019 15:40:09 -0700 Message-ID: Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? To: "Rodney W. Grimes" Cc: Ed Maste , Konstantin Belousov , stable@freebsd.org, Dimitry Andric X-Rspamd-Queue-Id: 4F3E58D641 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 22:40:23 -0000 On Thu, Feb 28, 2019 at 10:00 AM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes > > wrote: > > > > > > LD?=ld.lld in the right place(s)? > > > > Perhaps, I seem to recall some issue with that, but not the specifics. > > sys.mk already does a LD?=ld so by the time we try > to override it in the Makefile.i386 it is too late > as already defined. > > *sigh* > Yes, the problem is that ?= only works once. There's some gross things we can do, but they aren't worthwhile, imho. eg .if defined(KERNEL_LD_OVERRIDE) LD=${KERNEL_LD_OVERRIDE} .else LD=ld.lld .endif or other variations on that. We could do it without the .else clause and just add KERNEL_LD_OVERRIDE=ld.lld to GENERIC on i386 as a build-time override. This would give people a way out, but would violate POLA a little bit. Given the frequency of overriding LD=, it may be OK. People sophisticated enough to do that surely are sophisticated enough to read changes to the kernel config files. This wouldn't help everybody (especially those with custom kernel configs), but short of adding it to DEFAULTS, it's likely pushing the edge of how disruptive one can be in a stable branch. So there's a number of variations on this theme. I'm not convinced they are worthwhile for this issue because none are side-effect free, but it's certainly a solution space others can noodle through to see if they can find the "just so" mix of POLA and bug fixing. Warner From owner-freebsd-stable@freebsd.org Fri Mar 1 00:54:03 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DAE51520559 for ; Fri, 1 Mar 2019 00:54:03 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 559496B231 for ; Fri, 1 Mar 2019 00:54:02 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 191761520558; Fri, 1 Mar 2019 00:54:02 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06C081520557 for ; Fri, 1 Mar 2019 00:54:02 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66E556B22D; Fri, 1 Mar 2019 00:54:01 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x210rpnF058633; Thu, 28 Feb 2019 16:53:51 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x210ro2G058632; Thu, 28 Feb 2019 16:53:50 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201903010053.x210ro2G058632@pdx.rh.CN85.dnsmgr.net> Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? In-Reply-To: To: Warner Losh Date: Thu, 28 Feb 2019 16:53:50 -0800 (PST) CC: "Rodney W. Grimes" , Ed Maste , Konstantin Belousov , stable@freebsd.org, Dimitry Andric Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 66E556B22D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 00:54:03 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, Feb 28, 2019 at 10:00 AM Rodney W. Grimes < > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > [ Charset UTF-8 unsupported, converting... ] > > > On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes > > > wrote: > > > > > > > > LD?=ld.lld in the right place(s)? > > > > > > Perhaps, I seem to recall some issue with that, but not the specifics. > > > > sys.mk already does a LD?=ld so by the time we try > > to override it in the Makefile.i386 it is too late > > as already defined. > > > > *sigh* > > > > Yes, the problem is that ?= only works once. There's some gross things we > can do, but they aren't worthwhile, imho. > > eg > > .if defined(KERNEL_LD_OVERRIDE) > LD=${KERNEL_LD_OVERRIDE} > .else > LD=ld.lld > .endif > > or other variations on that. We could do it without the .else clause and > just add KERNEL_LD_OVERRIDE=ld.lld to GENERIC on i386 as a build-time > override. This would give people a way out, but would violate POLA a little > bit. Given the frequency of overriding LD=, it may be OK. People > sophisticated enough to do that surely are sophisticated enough to read > changes to the kernel config files. This wouldn't help everybody > (especially those with custom kernel configs), but short of adding it to > DEFAULTS, it's likely pushing the edge of how disruptive one can be in a > stable branch. > > So there's a number of variations on this theme. I'm not convinced they are > worthwhile for this issue because none are side-effect free, but it's > certainly a solution space others can noodle through to see if they can > find the "just so" mix of POLA and bug fixing. I would be happy with expanding the error that is emitted by pre.mk to add the text "You can fix this with LD=ld.lld make ..." and an entry in UPDATING that specifically says for 12.0 on i386 you need... > Warner -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Fri Mar 1 04:35:22 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 201B61503B2B for ; Fri, 1 Mar 2019 04:35:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50E0273B68 for ; Fri, 1 Mar 2019 04:35:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x214YljU051250 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Mar 2019 05:34:51 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nomad@castle.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x214YkQr055900 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Mar 2019 11:34:46 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: source upgrade FBSD10 -> 11 (then 12) To: Lee Damon , freebsd-stable@freebsd.org References: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> From: Eugene Grosbein Message-ID: <389988d2-659e-de84-1eef-e20f484b130f@grosbein.net> Date: Fri, 1 Mar 2019 11:34:34 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 50E0273B68 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.68)[-0.679,0]; IP_SCORE(-1.30)[ip: (-1.86), ipnet: 2a01:4f8::/29(-2.40), asn: 24940(-2.21), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 04:35:22 -0000 28.02.2019 23:18, Lee Damon wrote: > I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do this by building a new box with the latest OS then migrating services and data. Unfortunately I don't have that option this time, the upgrade has to happen in-place. My plan is to go from 10 to 11 then from 11 to 12. > > I was looking at the "Upgrading FreeBSD" part of https://www.freebsd.org/releases/11.1R/installation.html#upgrade but unfortunately it seems to be missing a critical URL or two: > > "The procedure for doing a source code based update is described in and ." > > I tracked down where I think it points and the instructions appear to be just for same-version updates. Can I safely move /usr/src out of the way then check out the stable/11 and compile/install it or are there other things I need to do? I did source upgrade from 10.3-STABLE to 11.2-STABLE multiple times with no problems. Keep in mind that you should not try source upgrade from 10.2 or earlier without test try first in lab because it might work but not supported. Better safe than sorry and first update FreeBSD10 system to 10.3-STABLE (if not yet) and only then update to 11.2-STABLE. From owner-freebsd-stable@freebsd.org Fri Mar 1 12:30:25 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 592CA15152CB for ; Fri, 1 Mar 2019 12:30:25 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 C82C8760F4 for ; Fri, 1 Mar 2019 12:30:24 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id DE67628417; Fri, 1 Mar 2019 13:30:13 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 46EDB28416; Fri, 1 Mar 2019 13:30:06 +0100 (CET) Subject: Re: source upgrade FBSD10 -> 11 (then 12) To: Lee Damon , freebsd-stable@freebsd.org References: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Fri, 1 Mar 2019 13:30:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <04a54d93-9132-5d6d-b8a7-c8a4dd8de8c5@castle.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C82C8760F4 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.01 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.780,0]; IP_SCORE(0.27)[ip: (0.68), ipnet: 94.124.104.0/21(0.34), asn: 42000(0.27), country: CZ(0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.86)[0.859,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: elsa.codelab.cz]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.91)[0.914,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[209.16.49.86.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 12:30:25 -0000 Lee Damon wrote on 2019/02/28 17:18: > I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do > this by building a new box with the latest OS then migrating services > and data. Unfortunately I don't have that option this time, the upgrade > has to happen in-place. My plan is to go from 10 to 11 then from 11 to 12. > > I was looking at the "Upgrading FreeBSD" part of > https://www.freebsd.org/releases/11.1R/installation.html#upgrade but > unfortunately it seems to be missing a critical URL or two: > > "The procedure for doing a source code based update is described in and ." > > I tracked down where I think it points and the instructions appear to be > just for same-version updates. Can I safely move /usr/src out of the way > then check out the stable/11 and compile/install it or are there other > things I need to do? The upgrade procedure is the same for major upgrade (10.x to 11.x ) as for minor upgrade (10.3 to 10.4). It is recommended to upgrade to the latest 10.x then to 11.x but sometimes I did source upgrade with skipping the whole branch - from 8.4 to 10.1 or 10.2. It worked with one exception but this must be tested first. If you plan to upgrade from 10.x to 11.2 then everything you need is described in /usr/src/Makefile Just checkout the sources in to /usr/src as usual and then For individuals wanting to upgrade their sources (even if only a delta of a few days): 1. `cd /usr/src' (or to the directory containing your source tree). 2. `make buildworld' 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). [steps 3. & 4. can be combined by using the "kernel" target] 5. `reboot' (in single user mode: boot -s from the loader prompt). 6. `mergemaster -p' 7. `make installworld' 8. `mergemaster' (you may wish to use -i, along with -U or -F). 9. `make delete-old' 10. `reboot' 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) I always skip step 5. doing all without reboot but beware of dragons! On upgrade from latest 10 (10-STABLE or 10.4-RELEASE) you may see notices on "make installkernel" phase: kldxref: unknown metadata record 4 in file atacard.ko kldxref: unknown metadata record 4 in file atp.ko They can be safely ignored. More details about the upgrade process https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Mar 1 15:00:59 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E03BC151A256 for ; Fri, 1 Mar 2019 15:00:57 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8463683E9A for ; Fri, 1 Mar 2019 15:00:56 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: by mail-yw1-xc2c.google.com with SMTP id i204so11705829ywb.0 for ; Fri, 01 Mar 2019 07:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l6Yxxc0EHzxjjaDmMIInSVNrwvrTaWGE8cRA/YYERkE=; b=UeWJ9yomfHamAfa20TsroFcGgXtkk2Rh/sQwVpsbzMFfQcxd6yX4pt0uVWrNZfIyaZ MXvQOB/+XbKxD/zaC/5a55Bh0mBw3Tux54E6cm55/DBRqirHKLXTMaey9ec095O9eWxJ IOzSaC9R4HCG3hEEbXy5m3kLmeE9k24T2d+Z2RxAfH/+SbghgXIRidlOuNRCl+5isYCz 1FsDjX6Uej9dzinOfyKOnx/5NEiMp4aUK9h+C4YbJFrCkG7hdURS50o91MlAESyexMjS lnbO7OUQDWbz8CHNeCmZGIvHD0OE60hG5z/b4gbgZ55Nz8OMg+jYZBIvdlSLyAlACEDl AEVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l6Yxxc0EHzxjjaDmMIInSVNrwvrTaWGE8cRA/YYERkE=; b=qzTo/pA+071SX7tXktoEfXEugXZnuu/ndIyJXGJuhRoZwiifAQZQykTaXhdVaMo+BW 1aZNePUQeHwcYaHzugulQCPNGyAqqvZxSV5tOyXa8GWj3QTJvS1MMY0nMSY40WFPtDpI E2asGKHwdKFHHGCeK6kFOBdCk9Ui8fALaojbq8SvUVQIVI9LyR0ESZKW7Ak0qZX+5RQ2 Bl0RbGT0qoLDFJ8zMW+xYQolhwUN66TqeQJZzmlNhRa2oqjx8Nw8oCT/qOYCXXWrt1kr xHyM2gzHglUx/BbTL82MXXfNxVoQKME8rATZvRQFPRB4ctW9hgf0Vfp6wbcXafmWiemk hgaQ== X-Gm-Message-State: APjAAAVMwmun83Wz1wZ+fSOYyVObViQ03aCHWr86LsKCpjr14T0Jg8qm gouK2EO7gCj4WLVKREwGbcRH3wZdtwsVWe3mnc4+Mzof X-Google-Smtp-Source: APXvYqxvtPM4zeHu5tAemZXmiLuwj3tKsStTPMcHBSOcCoYZiDuTC3CoCAj+iErXMJL5tsSKLqwcaiMOtQU6LYM5SGc= X-Received: by 2002:a5b:887:: with SMTP id e7mr4323906ybq.452.1551452454041; Fri, 01 Mar 2019 07:00:54 -0800 (PST) MIME-Version: 1.0 From: Nick Rogers Date: Fri, 1 Mar 2019 10:00:42 -0500 Message-ID: Subject: 12.0-RELEASE zfs/vnode deadlock issue To: FreeBSD STABLE X-Rspamd-Queue-Id: 8463683E9A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=UeWJ9yom; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ncrogers@gmail.com designates 2607:f8b0:4864:20::c2c as permitted sender) smtp.mailfrom=ncrogers@gmail.com X-Spamd-Result: default: False [-6.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[c.2.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-2.91)[ip: (-9.74), ipnet: 2607:f8b0::/32(-2.71), asn: 15169(-2.03), country: US(-0.07)]; NEURAL_HAM_SHORT(-0.94)[-0.939,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 15:00:59 -0000 Recently a number of my production 12.0 systems have experienced what I can only gather is a ZFS deadlock related to vnodes. It seems similar to the relatively recent FreeBSD-EN-18:18.zfs (ZFS vnode reclaim deadlock) problem. Previously the same systems were running 11.1-RELEASE without problem. Threads are always stuck with the stack around vn_lock->zfs_root->lookup->namei. When the system is in this state, a simple `ls /` or `ls /tmp` always hangs, but other datasets seem unaffected. I have a fairly straightforward ZFS root setup on a single pool with one SSD. The workload is a ruby/rails/nginx/postgresql backed web application combined with some data warehousing and other periodic tasks. Sometimes I can remote SSH in, other times that fails because the user shell fails to load, and I can run commands via `ssh ... command`. Sometimes the system is not accessible remotely at all, or it eventually becomes inaccessible if left long enough in this state. I always have to physically reboot the device because the shutdown procedure fails. The network stack (e.g. ping) seems to work completely fine whilst this is going on, until you try to interact with or spawn a process that hits the deadlock. Like previous similar ZFS deadlock issues, increasing kern.vnodes seems to make the system last longer by up to a few weeks, but is still a bandaid. However, I have yet to witness vnodes usage actually getting close to the maximum. I haven't had any luck reproducing this reliably, but eventually it happens after a few days or a few weeks... I managed to connect to a system in this state and grab a procstat and get (hopefully) something useful out of kgdb. I will note that although I was able to install debug symbols, I couldn't manage to get the source files onto it for kgdb purposes before I lost SSH access. I am hoping someone can help me figure out if this is a legitimate bug, or something already fixed in 12-STABLE. I wish I could reproduce it reliably to try against STABLE, but there doesn't appear to be any related ZFS fixes not in RELEASE. Thanks. Below is an abbreviated procstat and what I was able to get out of kgdb for an affected thread. Note that the thread backtrace is from a simple `ls` command. The procstat dump below is truncated because my last attempt to send this was rejected by this list for being too long - so a number of sh/cron processes and some zfs threads in a hung state were removed. ld# kgdb GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. sched_switch (td=0xfffff8002452a000, newtd=0xfffff80003625580, flags=) at /usr/src/sys/kern/sched_ule.c:2112 2112 /usr/src/sys/kern/sched_ule.c: No such file or directory. (kgdb) tid 102023 (kgdb) bt #0 sched_switch (td=0xfffff801a83dc580, newtd=0xfffff80003550580, flags=) at /usr/src/sys/kern/sched_ule.c:2112 #1 0xffffffff80d0e0a1 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439 #2 0xffffffff80d5c80c in sleepq_wait (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:692 #3 0xffffffff80cd9105 in sleeplk (lk=0xfffff800247307e8, flags=, ilk=, wmesg=, pri=, timo=51, queue=1) at /usr/src/sys/kern/kern_lock.c:300 #4 0xffffffff80cd7f85 in lockmgr_slock_hard (lk=, flags=, ilk=, file=, line=0, lwa=) at /usr/src/sys/kern/kern_lock.c:646 #5 0xffffffff813acc5e in VOP_LOCK1_APV (vop=, a=0xfffffe00f89dd450) at vnode_if.c:2087 #6 0xffffffff80de2820 in VOP_LOCK1 (vp=0xfffff80024730780, flags=2105344, file=0xffffffff814d4f74 "/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c", line=2074) at ./vnode_if.h:859 #7 _vn_lock (vp=0xfffff80024730780, flags=2105344, file=0xffffffff814d4f74 "/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c", line=2074) at /usr/src/sys/kern/vfs_vnops.c:1533 #8 0xffffffff8049f68d in zfs_root (vfsp=, flags=2105344, vpp=0xfffffe00f89dd558) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:2074 #9 0xffffffff80dc5d43 in lookup (ndp=0xfffffe00f89dd780) at /usr/src/sys/kern/vfs_lookup.c:961 #10 0xffffffff80dc4f9b in namei (ndp=0xfffffe00f89dd780) at /usr/src/sys/kern/vfs_lookup.c:444 #11 0xffffffff80ddc637 in kern_statat (td=0xfffff801a83dc580, flag=, fd=, path=0x800729c78 , pathseg=UIO_USERSPACE, sbp=0xfffffe00f89dd898, hook=0x0) at /usr/src/sys/kern/vfs_syscalls.c:2283 #12 0xffffffff80ddcdcf in sys_fstatat (td=, uap=0xfffff801a83dc940) at /usr/src/sys/kern/vfs_syscalls.c:2260 #13 0xffffffff81222449 in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #14 amd64_syscall (td=0xfffff801a83dc580, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1076 #15 #16 0x000000080047941a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe178 (kgdb) fr 7 #7 _vn_lock (vp=0xfffff80024730780, flags=2105344, file=0xffffffff814d4f74 "/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c", line=2074) at /usr/src/sys/kern/vfs_vnops.c:1533 1533 /usr/src/sys/kern/vfs_vnops.c: No such file or directory. (kgdb) print *vp $1 = {v_tag = 0xffffffff8144af45 "zfs", v_op = 0xffffffff81c64fd0 , v_data = 0xfffff800247e8110, v_mount = 0xfffff800247e1000, v_nmntvnodes = {tqe_next = 0xfffff800247305a0, tqe_prev = 0xfffff800247e1060}, { v_mountedhere = 0x0, v_unpcb = 0x0, v_rdev = 0x0, v_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {lh_first = 0xfffff8016f1ff5b0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffff800247307d0}, v_cache_dd = 0x0, v_lock = {lock_object = { lo_name = 0xffffffff8144af45 "zfs", lo_flags = 117112832, lo_data = 0, lo_witness = 0x0}, lk_lock = 18446735294395164034, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = { lo_name = 0xffffffff814e4508 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 0}, v_vnlock = 0xfffff800247307e8, v_actfreelist = {tqe_next = 0x0, tqe_prev = 0xfffff80024730660}, v_bufobj = {bo_lock = {lock_object = { lo_name = 0xffffffff814a9e5f "bufobj interlock", lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, bo_ops = 0xffffffff81d38600 , bo_object = 0xfffff80006f5d100, bo_synclist = { le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffff80024730780, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffff80024730898}, bv_root = {pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = { tqh_first = 0x0, tqh_last = 0xfffff800247308b8}, bv_root = {pt_root = 0}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_domain = 1, bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = { rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffff80024730908}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 241, v_usecount = 240, v_iflag = 512, v_vflag = 1, v_mflag = 0, v_writecount = 0, v_hash = 4, v_type = VDIR} (kgdb) ld# procstat -kka PID TID COMM TDNAME KSTACK 0 100000 kernel swapper mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 swapper+0x6b btext+0x2c 0 100012 kernel thread taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100014 kernel kqueue_ctx taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100015 kernel config_0 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100017 kernel aiod_kick taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100018 kernel if_io_tqg_0 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100019 kernel if_io_tqg_1 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100020 kernel if_io_tqg_2 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100021 kernel if_io_tqg_3 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100022 kernel if_io_tqg_4 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100023 kernel if_io_tqg_5 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100024 kernel if_io_tqg_6 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100025 kernel if_io_tqg_7 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100026 kernel softirq_0 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100027 kernel softirq_1 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100028 kernel softirq_2 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100029 kernel softirq_3 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100030 kernel softirq_4 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100031 kernel softirq_5 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100032 kernel softirq_6 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100033 kernel softirq_7 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100034 kernel if_config_tqg_0 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 gtaskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100056 kernel firmware taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100057 kernel crypto_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100058 kernel crypto_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100059 kernel crypto_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100060 kernel crypto_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100061 kernel crypto_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100062 kernel crypto_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100063 kernel crypto_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100064 kernel crypto_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100096 kernel system_taskq_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100097 kernel system_taskq_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100098 kernel system_taskq_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100099 kernel system_taskq_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100100 kernel system_taskq_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100101 kernel system_taskq_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100102 kernel system_taskq_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100103 kernel system_taskq_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100104 kernel mca taskq mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 taskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100109 kernel arc_prune_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100110 kernel arc_prune_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100111 kernel arc_prune_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100112 kernel arc_prune_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100113 kernel arc_prune_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100114 kernel arc_prune_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100115 kernel arc_prune_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100116 kernel arc_prune_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100119 kernel dbu_evict mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100121 kernel z_vdev_file_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100122 kernel z_vdev_file_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100123 kernel z_vdev_file_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100124 kernel z_vdev_file_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100125 kernel z_vdev_file_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100126 kernel z_vdev_file_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100127 kernel z_vdev_file_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100128 kernel z_vdev_file_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100129 kernel z_vdev_file_8 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100130 kernel z_vdev_file_9 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100131 kernel z_vdev_file_10 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100132 kernel z_vdev_file_11 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100133 kernel z_vdev_file_12 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100134 kernel z_vdev_file_13 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100135 kernel z_vdev_file_14 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100136 kernel z_vdev_file_15 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100138 kernel zfsvfs mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100143 kernel acpi_task_0 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 taskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100144 kernel acpi_task_1 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 taskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100145 kernel acpi_task_2 mi_switch+0xe1 sleepq_wait+0x2c msleep_spin_sbt+0x177 taskqueue_thread_loop+0xc3 fork_exit+0x83 fork_trampoline+0xe 0 100146 kernel CAM taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100167 kernel zio_null_issue mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100168 kernel zio_null_intr mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100169 kernel zio_read_issue_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100170 kernel zio_read_issue_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100171 kernel zio_read_issue_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100172 kernel zio_read_issue_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100173 kernel zio_read_issue_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100174 kernel zio_read_issue_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100175 kernel zio_read_issue_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100176 kernel zio_read_issue_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100177 kernel zio_read_intr_0_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100178 kernel zio_read_intr_0_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100179 kernel zio_read_intr_0_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100180 kernel zio_read_intr_0_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100181 kernel zio_read_intr_0_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100182 kernel zio_read_intr_0_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100183 kernel zio_read_intr_0_6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100184 kernel zio_read_intr_0_7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100185 kernel zio_read_intr_0_8 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100186 kernel zio_read_intr_0_9 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100187 kernel zio_read_intr_0_10 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100188 kernel zio_read_intr_0_11 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100189 kernel zio_read_intr_1_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100393 kernel zio_free_intr mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100394 kernel zio_claim_issue mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100395 kernel zio_claim_intr mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100396 kernel zio_ioctl_issue mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100397 kernel zio_ioctl_intr mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100403 kernel dp_sync_taskq_0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100404 kernel dp_sync_taskq_1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100405 kernel dp_sync_taskq_2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100406 kernel dp_sync_taskq_3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100407 kernel dp_sync_taskq_4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100408 kernel dp_sync_taskq_5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100409 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100410 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100411 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100412 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100413 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100414 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100415 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100416 kernel dp_zil_clean_taskq_ mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100417 kernel zfs_vn_rele_taskq mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100418 kernel metaslab_group_task mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100419 kernel metaslab_group_task mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100420 kernel metaslab_group_task mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 0 100421 kernel metaslab_group_task mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 taskqueue_thread_loop+0xf1 fork_exit+0x83 fork_trampoline+0xe 1 100002 init - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_wait6+0x66d sys_wait4+0x78 amd64_syscall+0x369 fast_syscall_common+0x101 2 100065 crypto - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_proc+0x2e5 fork_exit+0x83 fork_trampoline+0xe 3 100066 crypto returns 0 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 4 100067 crypto returns 1 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 5 100068 crypto returns 2 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 6 100069 crypto returns 3 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 7 100070 crypto returns 4 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 8 100071 crypto returns 5 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 9 100072 crypto returns 6 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 10 100001 audit - mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 audit_worker+0x73 fork_exit+0x83 fork_trampoline+0xe 11 100003 idle idle: cpu0 acpi_cpu_idle+0x2e7 cpu_idle_acpi+0x3f cpu_idle+0xa7 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100004 idle idle: cpu1 mi_switch+0xe1 critical_exit_preempt+0x58 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100005 idle idle: cpu2 acpi_cpu_idle+0x2e7 cpu_idle_acpi+0x3f cpu_idle+0xa7 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100006 idle idle: cpu3 mi_switch+0xe1 critical_exit_preempt+0x58 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100007 idle idle: cpu4 acpi_cpu_idle+0x2e7 cpu_idle_acpi+0x3f cpu_idle+0xa7 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100008 idle idle: cpu5 mi_switch+0xe1 critical_exit_preempt+0x58 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100009 idle idle: cpu6 acpi_cpu_idle+0x2e7 cpu_idle_acpi+0x3f cpu_idle+0xa7 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 11 100010 idle idle: cpu7 acpi_cpu_idle+0x2e7 cpu_idle_acpi+0x3f cpu_idle+0xa7 sched_idletd+0x515 fork_exit+0x83 fork_trampoline+0xe 12 100011 intr swi6: Giant taskq mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100013 intr swi5: fast taskq 12 100016 intr swi6: task queue mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100035 intr swi4: clock (0) mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100036 intr swi4: clock (1) 12 100037 intr swi4: clock (2) 12 100038 intr swi4: clock (3) 12 100039 intr swi4: clock (4) 12 100040 intr swi4: clock (5) 12 100041 intr swi4: clock (6) 12 100042 intr swi4: clock (7) 12 100043 intr swi1: netisr 0 mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100044 intr swi3: vm 12 100077 intr irq274: xhci0 mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100083 intr irq18: ehci0 ehci1 mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100094 intr irq305: ahci0 mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100095 intr swi0: uart uart mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 12 100141 intr swi1: pf send mi_switch+0xe1 ithread_loop+0x393 fork_exit+0x83 fork_trampoline+0xe 13 100045 ng_queue ng_queue0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100046 ng_queue ng_queue1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100047 ng_queue ng_queue2 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100048 ng_queue ng_queue3 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100049 ng_queue ng_queue4 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100050 ng_queue ng_queue5 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100051 ng_queue ng_queue6 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 13 100052 ng_queue ng_queue7 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 ngthread+0x9c fork_exit+0x83 fork_trampoline+0xe 14 100053 geom g_event mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 g_run_events+0x4f fork_exit+0x83 fork_trampoline+0xe 14 100054 geom g_up mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 g_io_schedule_up+0xcc g_up_procbody+0x6d fork_exit+0x83 fork_trampoline+0xe 14 100055 geom g_down mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 g_io_schedule_down+0xcc g_down_procbody+0x6d fork_exit+0x83 fork_trampoline+0xe 15 100073 crypto returns 7 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 crypto_ret_proc+0x1cd fork_exit+0x83 fork_trampoline+0xe 16 100074 sequencer 00 - mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 seq_eventthread+0xdc fork_exit+0x83 fork_trampoline+0xe 17 100075 cam doneq0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 xpt_done_td+0x9b fork_exit+0x83 fork_trampoline+0xe 17 100076 cam doneq1 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 xpt_done_td+0x9b fork_exit+0x83 fork_trampoline+0xe 17 100147 cam scanner mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 xpt_scanner_thread+0x99 fork_exit+0x83 fork_trampoline+0xe 18 100078 usb usbus0 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100079 usb usbus0 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100080 usb usbus0 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100081 usb usbus0 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100082 usb usbus0 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100084 usb usbus1 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100085 usb usbus1 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100086 usb usbus1 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100087 usb usbus1 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100088 usb usbus1 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100089 usb usbus2 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100090 usb usbus2 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100091 usb usbus2 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100092 usb usbus2 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 18 100093 usb usbus2 mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 usb_process+0x137 fork_exit+0x83 fork_trampoline+0xe 19 100105 soaiod1 - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 soaio_kproc_loop+0x1bf fork_exit+0x83 fork_trampoline+0xe 20 100106 soaiod2 - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 soaio_kproc_loop+0x1bf fork_exit+0x83 fork_trampoline+0xe 21 100107 soaiod3 - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 soaio_kproc_loop+0x1bf fork_exit+0x83 fork_trampoline+0xe 22 100108 soaiod4 - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 soaio_kproc_loop+0x1bf fork_exit+0x83 fork_trampoline+0xe 23 100117 zfskern arc_reclaim_thread mi_switch+0xe1 sleepq_timedwait+0x2f _cv_timedwait_sbt+0x17a arc_reclaim_thread+0x146 fork_exit+0x83 fork_trampoline+0xe 23 100118 zfskern arc_dnlc_evicts_thr mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 arc_dnlc_evicts_thread+0x16f fork_exit+0x83 fork_trampoline+0xe 23 100120 zfskern dbuf_evict_thread mi_switch+0xe1 sleepq_timedwait+0x2f _cv_timedwait_sbt+0x17a dbuf_evict_thread+0x1c8 fork_exit+0x83 fork_trampoline+0xe 23 100137 zfskern l2arc_feed_thread mi_switch+0xe1 sleepq_timedwait+0x2f _cv_timedwait_sbt+0x17a l2arc_feed_thread+0x219 fork_exit+0x83 fork_trampoline+0xe 23 100398 zfskern trim zroot mi_switch+0xe1 sleepq_timedwait+0x2f _cv_timedwait_sbt+0x17a trim_thread+0x11f fork_exit+0x83 fork_trampoline+0xe 23 100434 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 txg_quiesce+0x21b txg_quiesce_thread+0x11b fork_exit+0x83 fork_trampoline+0xe 23 100435 zfskern txg_thread_enter mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 txg_sync_thread+0x13b fork_exit+0x83 fork_trampoline+0xe 23 100436 zfskern solthread 0xfffffff mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 zthr_procedure+0xcc fork_exit+0x83 fork_trampoline+0xe 23 100437 zfskern solthread 0xfffffff mi_switch+0xe1 sleepq_wait+0x2c _cv_wait+0x152 zthr_procedure+0xcc fork_exit+0x83 fork_trampoline+0xe 24 100139 sctp_iterator - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 sctp_iterator_thread+0x59 fork_exit+0x83 fork_trampoline+0xe 25 100140 pf purge - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 pf_purge_thread+0xb9 fork_exit+0x83 fork_trampoline+0xe 26 100142 rand_harvestq - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 random_kthread+0x286 fork_exit+0x83 fork_trampoline+0xe 27 100148 enc_daemon0 - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 enc_daemon+0x349 fork_exit+0x83 fork_trampoline+0xe 28 100149 pagedaemon dom0 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 vm_pageout_worker+0x28e vm_pageout+0x15a fork_exit+0x83 fork_trampoline+0xe 28 100151 pagedaemon laundry: dom0 mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 vm_pageout_laundry_worker+0xfdd fork_exit+0x83 fork_trampoline+0xe 28 100153 pagedaemon uma mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 uma_reclaim_worker+0xca fork_exit+0x83 fork_trampoline+0xe 29 100150 vmdaemon - mi_switch+0xe1 sleepq_wait+0x2c _sleep+0x237 vm_daemon+0x94 fork_exit+0x83 fork_trampoline+0xe 30 100152 bufdaemon - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 buf_daemon+0xe8 fork_exit+0x83 fork_trampoline+0xe 30 100156 bufdaemon bufspacedaemon-0 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100157 bufdaemon bufspacedaemon-1 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100158 bufdaemon bufspacedaemon-2 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100159 bufdaemon bufspacedaemon-3 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100160 bufdaemon bufspacedaemon-4 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100161 bufdaemon bufspacedaemon-5 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 30 100162 bufdaemon bufspacedaemon-6 mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 bufspace_daemon+0xa4 fork_exit+0x83 fork_trampoline+0xe 31 100154 vnlru - mi_switch+0xe1 sleepq_timedwait+0x2f _sleep+0x217 vnlru_proc+0x95 fork_exit+0x83 fork_trampoline+0xe 32 100155 syncer - mi_switch+0xe1 sleepq_timedwait+0x2f _cv_timedwait_sbt+0x17a sched_sync+0xc4 fork_exit+0x83 fork_trampoline+0xe 2925 100473 devd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 3014 100487 syslogd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 3121 100443 automountd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 autofs_ioctl+0xbd devfs_ioctl+0xad VOP_IOCTL_APV+0x7e vn_ioctl+0x1a4 devfs_ioctl_f+0x1f kern_ioctl+0x26d sys_ioctl+0x15e amd64_syscall+0x369 fast_syscall_common+0x101 3127 100461 autounmountd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 3246 100488 sshd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 7053 100664 smbd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 7062 100616 smbd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 7063 100670 smbd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 7064 100455 smbd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 7065 100519 snmptrapd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 10568 100483 nginx - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_sigsuspend+0x174 sys_sigsuspend+0x31 amd64_syscall+0x369 fast_syscall_common+0x101 10569 100803 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10570 100448 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10571 100527 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10572 100552 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10573 100617 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10574 101643 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10575 100610 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 10576 100653 nginx - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b unp_connectat+0x174 soconnect+0xad kern_connectat+0x106 sys_connect+0x77 amd64_syscall+0x369 fast_syscall_common+0x101 20584 100460 openvpn - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21660 100615 postgres - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b kern_utimesat+0x110 amd64_syscall+0x369 fast_syscall_common+0x101 21662 100612 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21663 100626 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21664 100450 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21665 100638 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21666 100635 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 21667 100700 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 22183 100518 getty - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 tty_wait+0x1c ttydisc_read+0x1f2 ttydev_read+0x64 devfs_read_f+0xdc dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 22184 100509 getty - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 tty_wait+0x1c ttydisc_read+0x1f2 ttydev_read+0x64 devfs_read_f+0xdc dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 22185 101647 getty - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 tty_wait+0x1c ttydisc_read+0x1f2 ttydev_read+0x64 devfs_read_f+0xdc dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 22435 100440 getty - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 tty_wait+0x1c ttydisc_read+0x1f2 ttydev_read+0x64 devfs_read_f+0xdc dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 24825 101365 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24851 100599 perl - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 kern_clock_nanosleep+0x1a7 sys_nanosleep+0x5f amd64_syscall+0x369 fast_syscall_common+0x101 24855 101640 ntpd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24865 100459 radiusd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 24865 101450 radiusd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_sem2_wait+0x68a __umtx_op_sem2_wait+0x4b amd64_syscall+0x369 fast_syscall_common+0x101 24869 100545 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24869 101382 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100813 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100960 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100961 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100962 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100968 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100973 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100979 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100981 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24870 100984 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24871 100541 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24871 100665 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24871 100986 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24871 100987 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24871 100989 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24871 101001 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24871 101037 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24871 101047 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24871 101051 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24873 100637 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24873 100828 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101055 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101064 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101077 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101098 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101102 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101118 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24873 101122 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24874 100516 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101036 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101129 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101143 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101144 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101147 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101194 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101259 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24874 101267 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24875 100539 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101071 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101284 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101289 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101298 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101334 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101347 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101350 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24875 101369 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24876 100642 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101384 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101411 ruby25 cluster.rb:253 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101423 ruby25 cluster.rb:287 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101429 ruby25 puma 001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101431 ruby25 reactor.rb:249 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101441 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101444 ruby25 thread_pool.rb* mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 24876 101447 ruby25 server.rb:358 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 24885 100816 snort - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 bpfread+0x318 devfs_read_f+0xdc dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 24885 101457 snort - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 kern_clock_nanosleep+0x1a7 sys_nanosleep+0x5f amd64_syscall+0x369 fast_syscall_common+0x101 25043 100810 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 25043 101658 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 25044 100682 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 25422 100603 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 25433 100691 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 25442 100504 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 26015 100805 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 27660 100636 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 29381 100553 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 34928 100480 dhcpd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 36704 101146 perl - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cred+0x2c9 kern_openat+0x20c amd64_syscall+0x369 fast_syscall_common+0x101 36751 101709 cron - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a pipe_read+0x446 dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 39368 101861 sendmail - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_wait6+0x66d sys_wait4+0x78 amd64_syscall+0x369 fast_syscall_common+0x101 39370 101856 mail.local - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b kern_statat+0x77 sys_fstatat+0x2f amd64_syscall+0x369 fast_syscall_common+0x101 40693 101766 perl - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b kern_statat+0x77 sys_fstatat+0x2f amd64_syscall+0x369 fast_syscall_common+0x101 40696 101911 sshd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 40698 101972 sshd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 40699 101310 bash - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_wait6+0x66d sys_wait4+0x78 amd64_syscall+0x369 fast_syscall_common+0x101 40711 101974 cron - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a pipe_read+0x446 dofileread+0x95 sys_read+0xc3 amd64_syscall+0x369 fast_syscall_common+0x101 40712 101395 sh - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b kern_statat+0x77 sys_fstatat+0x2f amd64_syscall+0x369 fast_syscall_common+0x101 40715 101969 su - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_wait6+0x66d sys_wait4+0x78 amd64_syscall+0x369 fast_syscall_common+0x101 40716 101976 csh - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_sigsuspend+0x174 sys_sigsuspend+0x31 amd64_syscall+0x369 fast_syscall_common+0x101 40722 101977 procstat - sysctl_kern_proc_kstack+0x282 sysctl_root_handler_locked+0x8b sysctl_root+0x257 userland_sysctl+0x17a sys___sysctl+0x5f amd64_syscall+0x369 fast_syscall_common+0x101 81907 100546 racoon - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 83204 100656 perl - mi_switch+0xe1 sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_slock_hard+0x2c5 VOP_LOCK1_APV+0x7e _vn_lock+0x40 zfs_root+0x6d lookup+0x933 namei+0x44b kern_statat+0x77 sys_fstatat+0x2f amd64_syscall+0x369 fast_syscall_common+0x101 83208 100501 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 83209 100525 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 83210 100628 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 83424 100485 ladvd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 83425 100554 ladvd - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 83428 101357 perl - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 kern_clock_nanosleep+0x1a7 sys_nanosleep+0x5f amd64_syscall+0x369 fast_syscall_common+0x101 83444 100542 snmpd - 83545 100486 sendmail - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _cv_timedwait_sig_sbt+0x17a seltdwait+0x7b kern_select+0x87f sys_select+0x56 amd64_syscall+0x369 fast_syscall_common+0x101 83548 100814 sendmail - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_sigsuspend+0x174 sys_sigsuspend+0x31 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100427 named isc-worker0000 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100431 named isc-worker0001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100432 named isc-worker0002 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100556 named - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_sigtimedwait+0x3d4 sys_sigwait+0x5c amd64_syscall+0x369 fast_syscall_common+0x101 83554 100774 named isc-worker0003 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100819 named isc-worker0004 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100820 named isc-worker0005 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100849 named isc-worker0006 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 100990 named isc-worker0007 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 101481 named isc-timer mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83554 101534 named isc-socket mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 83556 100608 named - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kern_sigtimedwait+0x3d4 sys_sigwait+0x5c amd64_syscall+0x369 fast_syscall_common+0x101 83556 101540 named isc-worker0000 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101541 named isc-worker0001 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101543 named isc-worker0002 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101545 named isc-worker0003 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101546 named isc-worker0004 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101549 named isc-worker0005 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101560 named isc-worker0006 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101583 named isc-worker0007 mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101596 named isc-timer mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83556 101600 named isc-socket mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _sleep+0x22a kqueue_kevent+0x29e kern_kevent+0xb5 kern_kevent_generic+0x71 sys_kevent+0x61 amd64_syscall+0x369 fast_syscall_common+0x101 83559 100514 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83559 101604 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 83562 100463 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83562 101486 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 83565 100821 ruby25 - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 umtxq_sleep+0x143 do_wait+0x427 __umtx_op_wait_uint_private+0x53 amd64_syscall+0x369 fast_syscall_common+0x101 83565 101606 ruby25 ruby-timer-thr mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 84111 100668 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 84112 100613 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 84113 101274 postgres - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_wait_sig+0xf _cv_wait_sig+0x154 seltdwait+0xc3 kern_poll+0x43d sys_poll+0x50 amd64_syscall+0x369 fast_syscall_common+0x101 84416 100550 cron - mi_switch+0xe1 sleepq_catch_signals+0x405 sleepq_timedwait_sig+0x14 _sleep+0x205 kern_clock_nanosleep+0x1a7 sys_nanosleep+0x5f amd64_syscall+0x369 fast_syscall_common+0x101 From owner-freebsd-stable@freebsd.org Fri Mar 1 21:17:41 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B6D9150115A for ; Fri, 1 Mar 2019 21:17:41 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AB5ED91D6C for ; Fri, 1 Mar 2019 21:17:40 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 645BF1501157; Fri, 1 Mar 2019 21:17:40 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CEFD1501155 for ; Fri, 1 Mar 2019 21:17:40 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A05CD91D66; Fri, 1 Mar 2019 21:17:39 +0000 (UTC) (envelope-from rollingbits@gmail.com) Received: by mail-qt1-x82b.google.com with SMTP id o6so29497955qtk.6; Fri, 01 Mar 2019 13:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5drEgleacOYfYscHrn+25n8q36a03HPMycDmeMOclT4=; b=ritYX7hTBfyvWOUR3D83kxusOlEFT4Ih/TGnIfhKHQlFGhQiIJtHvzN5BkOTs3BrN1 0i20vB/6diE5sgnMKfHtk/yBhqhIVYzq2oEqZhLNQK0kojT2u6d4QL9F7U/a7VL0GDkk wAclVZAtaU4hR7ADz9Wsyt8AyQxEMcGxk7B11IMmMxSevwTD0t9MSjS6EJ4A87AlQXzb BWbQYhhDRh8h5udJQlh3H2foJxjI3qdjb82/99nN2zu24QkxYbnqYLactvvB6clnS5Dk sZoRCqcTH5iwb3sbiifG0sILJ33o2nqj4iKlkw30ErxFfNc7V3INDmZGK60g1t/umGaV BhyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5drEgleacOYfYscHrn+25n8q36a03HPMycDmeMOclT4=; b=b7aEZnLfnp3bOBGMfoXIj/vSafmn6u5trtDX/kbc7rDB0CrqGTQtTRlxzIZFVbhBPx Tt7Ci42Ep8CQrdZ0/ztqBcMpmBHi9g/O+RUv7maR97WWZ+KRkCG+R89RksdaqcDzLlRz j1uA5t5sL4yheDklSgbVMsSF9k4Y0wie5Pp1ucT+jS1HKKZPlqT2dg0SPhYV65Iz6XOa luUDwKC7IaC4/vjHMaGvEg3a3vL6SYo/Wh8u4NpgcT65gQFNnSUqyyJQsBLcc39yCGyD 3D6hMB4SItz+WE7lloVlDdmbA8A4cFNzlicozB2V0Oc4wa24OEsWY62yX55dSef1H3S3 RQwQ== X-Gm-Message-State: APjAAAVBnCCWq+YjKkE1dt+JAJ6FmMQK8g3yYBQlE31+CYmauw1dKs85 y7vojlaUYGptQXWooaQftRk= X-Google-Smtp-Source: APXvYqxAj7kyxoI1ZH2MI7z39h9Lmxli7rNSJ6hYrWUAOPPQCYhUGEhiIWREX4g4K+xSCTgqOXnrnA== X-Received: by 2002:ac8:6894:: with SMTP id m20mr5567656qtq.277.1551475059197; Fri, 01 Mar 2019 13:17:39 -0800 (PST) Received: from ?IPv6:2804:388:e02d:be4c:6c62:9d73:7703:3c1d? ([2804:388:e02d:be4c:6c62:9d73:7703:3c1d]) by smtp.gmail.com with ESMTPSA id x6sm11526101qtr.9.2019.03.01.13.17.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 13:17:38 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD 12.0 RELEASE i386 can not build a kernel? From: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Fri, 1 Mar 2019 18:17:36 -0300 Cc: "Rodney W. Grimes" , Konstantin Belousov , Dimitry Andric , stable@freebsd.org, Ed Maste Message-Id: References: <201902281659.x1SGxP7X057343@pdx.rh.CN85.dnsmgr.net> To: Warner Losh X-Rspamd-Queue-Id: A05CD91D66 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:17:41 -0000 > On Feb 28, 2019, at 7:40 PM, Warner Losh wrote: >=20 > On Thu, Feb 28, 2019 at 10:00 AM Rodney W. Grimes < > freebsd@pdx.rh.cn85.dnsmgr.net> wrote: >=20 > .if defined(KERNEL_LD_OVERRIDE) > LD=3D${KERNEL_LD_OVERRIDE} > .else > LD=3Dld.lld > .endif My suggestion would be to test $LD =3D=3D ld and then use LD=3Dld.lld with a= comment about the reason but my makefile syntax knowledge is limited. Lc --=20 rollingbits =E2=80=94 =F0=9F=93=A7 rollingbits@gmail.com =F0=9F=93=A7 rollin= gbits@terra.com.br =F0=9F=93=A7 rollingbits@yahoo.com =F0=9F=93=A7 rollingbi= ts@globo.com =F0=9F=93=A7 rollingbits@icloud.com From owner-freebsd-stable@freebsd.org Fri Mar 1 21:53:52 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3745D1502E9C for ; Fri, 1 Mar 2019 21:53:52 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAE0993681 for ; Fri, 1 Mar 2019 21:53:40 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: by mail-pf1-x444.google.com with SMTP id i20so12021828pfo.6 for ; Fri, 01 Mar 2019 13:53:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=dcTrSla/o3bVukxWS1nd/7Y97IYf7B/e7NgAUwpea48=; b=qAy+vh+E1SL5Sfz2aY0ZEUY8WvnqQ7iSuONgwJ9YEPVsReCAdD1DmIcraboXrF/uRc DmZBKH0O1B+sop8Lfg5zQvMqHcjPFZQTSzo1sXlP5UKKsG6av8zkc6014fDxW5AWtvUK XKH4v5Y8565/z8zb/N58CgeADJluFBp1qL6pNSdzgL4KOGhv636km5/atSruZ74eazpH bwpqNPdSdIj2fTWF6vfT30Cot25bW5xUxNqpTIv1QrgK3SS6vhx4LWbCCDCWV75W3XfZ QMg+62ycquchrUmubv7ltCXil1LKYl7Cs5gyfZJr6kbTiEDHEyAax8PvxPeItp52ST2c TLug== X-Gm-Message-State: APjAAAUzG1JD1sqbM8sITA8U2BZB4bYFsBNc8KHtQz+0pgSSItVPLiou uF+yeF0VfXC+gYrSWYb5dz5WE6gm X-Google-Smtp-Source: APXvYqyNaM/fPiLgMyBIv9JIBkOcz/6juj3cCetd3pr2R6KYEFGKZn4ugeIXAmwHnBFAeiO35pISxA== X-Received: by 2002:a63:305:: with SMTP id 5mr7042986pgd.57.1551477218918; Fri, 01 Mar 2019 13:53:38 -0800 (PST) Received: from vanyel.ee.washington.edu (vanyel.ee.washington.edu. [128.208.232.99]) by smtp.gmail.com with ESMTPSA id s37sm3561129pgk.36.2019.03.01.13.53.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 13:53:37 -0800 (PST) Sender: Lee Damon From: Lee Damon Subject: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: freebsd-stable@freebsd.org Message-ID: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> Date: Fri, 1 Mar 2019 13:53:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AAE0993681 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.38)[-0.379,0]; FORGED_SENDER(0.30)[nomad@castle.org,thenomad@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[nomad@castle.org,thenomad@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.41)[ip: (2.77), ipnet: 2607:f8b0::/32(-2.72), asn: 15169(-2.04), country: US(-0.07)]; DMARC_DNSFAIL(0.00)[castle.org : query timed out]; RCVD_IN_DNSWL_NONE(0.00)[4.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:53:52 -0000 After discussion with Bob Bishop (thanks for the help!) I've tried to do the following to upgrade one of the old boxes I mentioned previously. cd /usr/src tar ... . rm -rf .??* * svn checkout httpg://svn.freebsd.org/base/releng/10.3 /usr/src compile, installkernel, installworld... Now that the host is running RELENG the next step was to update from 10.4 to 11.2 via freebsd-update freebsd-update freebsd-install freebsd-update upgrade -r 11.2-RELEASE freebsd-update install so far, so good. Now it all falls apart shutdown -r now ... why isn't the host coming back? Oh look, kernel panic. Fatal trap 12: page fault while in kernel mode cpuid = 1; apci id = 01 fault virtual address = 0x84 fault code = supervisor read data, page not present Google searches find references to the same panic type in VMs running 11.1, including https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220923 The differences are, that's 11.1 not 11.2 (I would presume the fix made it into 11.2 but maybe not) and most notably, that's against VMs and the host I'm doing this on is bare iron (Sun x4500). Still, I gave the two entries in /boot/loader.conf a try, no joy. Exactly the same panic. Recording the boot with slow-mo shows the panic happening just after the USB devices are enumerated by the kernel. It never even tries to mount root. I am able to boot to kernel.old, which appears to be my old 10.4-STABLE kernel. So now I'm kind of stuck. The update has already modified the config files as part of the first pass so rolling back may be a problem and moving forward seems unwise. I have only one x4500 but I have three x4540s running 11.2-STABLE (also installed from source) just fine. Anyone have any brilliant suggestions? I'm thinking of trying to compile 11.2-RELENG in /usr/src so I can try installing that kernel but that'll take several hours at least (it's an old box). nomad From owner-freebsd-stable@freebsd.org Fri Mar 1 22:19:29 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 652261503961 for ; Fri, 1 Mar 2019 22:19:29 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 D1291947BC for ; Fri, 1 Mar 2019 22:19:27 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B25D828416; Fri, 1 Mar 2019 23:19:24 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 608F328411; Fri, 1 Mar 2019 23:19:17 +0100 (CET) Subject: Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: Lee Damon , freebsd-stable@freebsd.org References: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> Date: Fri, 1 Mar 2019 23:19:16 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D1291947BC X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.947,0]; IP_SCORE(0.27)[ip: (0.66), ipnet: 94.124.104.0/21(0.33), asn: 42000(0.26), country: CZ(0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.963,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: elsa.codelab.cz]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.92)[0.923,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[209.16.49.86.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 22:19:29 -0000 Lee Damon via freebsd-stable wrote on 2019/03/01 22:53: > After discussion with Bob Bishop (thanks for the help!) I've tried to do > the following to upgrade one of the old boxes I mentioned previously. > > cd /usr/src > tar ... . > rm -rf .??* * > svn checkout httpg://svn.freebsd.org/base/releng/10.3 /usr/src > compile, installkernel, installworld... > > Now that the host is running RELENG the next step was to update from > 10.4 to 11.2 via freebsd-update > > freebsd-update > freebsd-install > freebsd-update upgrade -r 11.2-RELEASE > freebsd-update install > > so far, so good. Now it all falls apart > > shutdown -r now > ... why isn't the host coming back? Oh look, kernel panic. > >   Fatal trap 12: page fault while in kernel mode >   cpuid = 1; apci id = 01 >   fault virtual address = 0x84 >   fault code = supervisor read data, page not present I went back from freebsd-update to source upgrades few years ago and now use exclusively source builds (build it on powerful build machine and distribute it to clients thru NFS so clients can just run make installkernel and make installworld) because I was bitten by failed freebsd-update upgrade many times... > Google searches find references to the same panic type in VMs running > 11.1, including https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220923 > > The differences are, that's 11.1 not 11.2 (I would presume the fix made > it into 11.2 but maybe not) and most notably, that's against VMs and the > host I'm doing this on is bare iron (Sun x4500). > > Still, I gave the two entries in /boot/loader.conf a try, no joy. > Exactly the same panic. Recording the boot with slow-mo shows the panic > happening just after the USB devices are enumerated by the kernel. It > never even tries to mount root. > > I am able to boot to kernel.old, which appears to be my old 10.4-STABLE > kernel. So now I'm kind of stuck. The update has already modified the > config files as part of the first pass so rolling back may be a problem > and moving forward seems unwise. > > I have only one x4500 but I have three x4540s running 11.2-STABLE (also > installed from source) just fine. > > Anyone have any brilliant suggestions? I'm thinking of trying to compile > 11.2-RELENG in /usr/src so I can try installing that kernel but that'll > take several hours at least (it's an old box). If you can boot with the old 10.4 kernel and go online, just fetch kernel.txz from the net: http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/kernel.txz and unpack it to /boot/kernel112 then you can try to reboot a manually select to boot this kernel instead of default /boot/kernel. If you cannot access the boot loader prompt you can try "nextboot" command. 1) unpack the kernel 2) set nextboot: nextboot -k kernel112 3) shutdown -r now and hope for a luck If your machine boots fine with 11.2 kernel, you can fetch sources and rebuild kernel and userland for 11.2 as usual. Or you can try to fetch and unpack base.txz http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/base.txz over your current files. It can make a mess but you can always clean it with "make delete-old & make delete-old-libs" Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Mar 1 22:56:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27A531504CC7 for ; Fri, 1 Mar 2019 22:56:56 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 4938696D65 for ; Fri, 1 Mar 2019 22:56:51 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (chombo [IPv6:2601:1c2:1402:1770:ae1f:6bff:fe6b:9e1c]) by echo.brtsvcs.net (Postfix) with ESMTPS id 9C50F38D14 for ; Fri, 1 Mar 2019 14:56:42 -0800 (PST) Received: from [10.26.24.66] (ivy.wlan.pilgrimaccounting.com [10.26.24.66]) by chombo.houseloki.net (Postfix) with ESMTPSA id C682B2307 for ; Fri, 1 Mar 2019 14:56:41 -0800 (PST) To: freebsd-stable@freebsd.org From: Mel Pilgrim Subject: Would someone commit the revised patch in usb/234503, please Message-ID: <182c691f-62c7-102f-a1a0-663e4566f292@bluerosetech.com> Date: Fri, 1 Mar 2019 14:56:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4938696D65 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-6.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[bluerosetech.com]; MX_GOOD(-0.01)[echo.brtsvcs.net,foxtrot.brtsvcs.net]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; IP_SCORE(-3.43)[ip: (-8.76), ipnet: 2607:f740:c::/48(-4.44), asn: 36236(-3.90), country: US(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 22:56:56 -0000 usb/234503 contains a patch to broaden the scope of an existing scsi_da quirk (attachment labeled "Patch to broaden quirk coverage to all Chipfancier devices"). It's a minor change, but it's a showstopper for me and I need to see it get into 11-stable ahead of 11.3-R and 12-stable ahead of 12.1-R. Would someone have a look at it and commit it? Thank you From owner-freebsd-stable@freebsd.org Fri Mar 1 23:06:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DA67150540F for ; Fri, 1 Mar 2019 23:06:30 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56BB39739A for ; Fri, 1 Mar 2019 23:06:19 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: by mail-pf1-x442.google.com with SMTP id i20so12093554pfo.6 for ; Fri, 01 Mar 2019 15:06:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=9ivhZp60ezyxV4qrqV3y22m8hgBWwXb/o6m7/HW+L+o=; b=WEdt+22IdwqyT8VdxdwhtvNLEd06gZpjedHp/luwQ4AG00/8QSrpZvGggM+PxuVqU9 5HXEI+5CB3bA/maA/e3oWXhe0RRgB3GM43HI7tq2ube/aEKOuvs7HbGCC82fnezAnlMC 5p3SD/4q4OKpUM2VUr7BqozhbXNyiW6mmr1E0FuIo4GT9o6bhASr9+V3A6o9h02o9x4h K+ioPicnVq2rDeLTWgYO+7iMg0w3cPtBNB5SW+ISiXzTw2eI6Jh/ZJtrMgOEp4wrc77e cr07NxIfAvTyy0WOKR/vkEpVgrfBSt6CdL5MSJmvHqS1G+Q7Nb3wqlJcnmW4o/o0OcGw jWQA== X-Gm-Message-State: APjAAAXvWfWCXkwirmtRkrLGWR0e/awYfBpRIST/GivILqUhsV4U8hFB 5JAcwXnM3cExtsHkt1byfv3hoVbs X-Google-Smtp-Source: APXvYqwmgiN+kijObxvZ7GjjlLbElnSAckE5gCVdJ+Zsyqp3ngMmyD8PSwvMdWRvkop0y6tBBVG5Pg== X-Received: by 2002:a63:591f:: with SMTP id n31mr7209976pgb.304.1551481577488; Fri, 01 Mar 2019 15:06:17 -0800 (PST) Received: from vanyel.ee.washington.edu (vanyel.ee.washington.edu. [128.208.232.99]) by smtp.gmail.com with ESMTPSA id l184sm32642279pfc.41.2019.03.01.15.06.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 15:06:15 -0800 (PST) Sender: Lee Damon Subject: Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org References: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> From: Lee Damon Message-ID: <487c50a4-216b-efc6-044f-80114749bf86@castle.org> Date: Fri, 1 Mar 2019 15:06:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> Content-Type: multipart/mixed; boundary="------------19785548ADFB862C2A7A9CF2" Content-Language: en-US X-Rspamd-Queue-Id: 56BB39739A X-Spamd-Bar: - X-Spamd-Result: default: False [-1.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; CTYPE_MIXED_BOGUS(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; MIME_BASE64_TEXT(0.10)[]; FORGED_SENDER(0.30)[nomad@castle.org,thenomad@gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[nomad@castle.org,thenomad@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.48)[-0.482,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_DNSFAIL(0.00)[castle.org : query timed out]; RCVD_IN_DNSWL_NONE(0.00)[2.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.38)[ip: (2.94), ipnet: 2607:f8b0::/32(-2.72), asn: 15169(-2.04), country: US(-0.07)] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 23:06:30 -0000 This is a multi-part message in MIME format. --------------19785548ADFB862C2A7A9CF2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/1/19 14:19 , Miroslav Lachman wrote: > If you can boot with the old 10.4 kernel and go online, just fetch > kernel.txz from the net: > http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/kernel.txz and > unpack it to /boot/kernel112 then you can try to reboot a manually > select to boot this kernel instead of default /boot/kernel. Darn it. I get the same kernel panic with that one. I'm compiling locally but I don't expect that to make any difference. I'll need to go pawing through the release notes and see if there are any references to deprecated hardware that might be involved. I'm attaching a copy of dmesg output from a successful boot into 10.4-STABLE. The kernel panic appears to happen around 15% of the way into the output, around ... mvsch13: at channel 5 on mvs1 mvsch14: at channel 6 on mvs1 mvsch15: at channel 7 on mvs1 pcib3: at device 6.0 on pci0 pci3: on pcib3 ohci0: mem 0xfd1fe000-0xfd1fefff irq 19 at device 0.0 on pci3 usbus0 on ohci0 ohci1: mem 0xfd1fd000-0xfd1fdfff irq 19 at device 0.1 on pci3 usbus1 on ohci1 ... (Just before it enumerates vgapci0) but I can't be sure because the screen moves so fast that even slow-mo video is just a blur. nomad --------------19785548ADFB862C2A7A9CF2 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="goose_dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="goose_dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMTcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMC40LVNUQUJMRSAjMjUg cjM0Mjk0NzogRnJpIEphbiAxMSAxNDoxNzo0MCBQU1QgMjAxOQogICAgbHZkQGdvb3NlLmVl Lndhc2hpbmd0b24uZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJl ZUJTRCBjbGFuZyB2ZXJzaW9uIDMuNC4xICh0YWdzL1JFTEVBU0VfMzQvZG90MS1maW5hbCAy MDgwMzIpIDIwMTQwNTEyCkNQVTogRHVhbCBDb3JlIEFNRCBPcHRlcm9uKHRtKSBQcm9jZXNz b3IgMjkwICgyNzkyLjExLU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luPSJBdXRoZW50aWNB TUQiICBJZD0weDIwZjEyICBGYW1pbHk9MHhmICBNb2RlbD0weDIxICBTdGVwcGluZz0yCiAg RmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4 LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNS LFNTRSxTU0UyLEhUVD4KICBGZWF0dXJlczI9MHgxPFNTRTM+CiAgQU1EIEZlYXR1cmVzPTB4 ZTI1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLExNLDNETm93ISssM0ROb3chPgogIEFN RCBGZWF0dXJlczI9MHgzPExBSEYsQ01QPgpyZWFsIG1lbW9yeSAgPSAxNzE3OTg2OTE4NCAo MTYzODQgTUIpCmF2YWlsIG1lbW9yeSA9IDE2NDE4NDg0MjI0ICgxNTY1NyBNQikKRXZlbnQg dGltZXIgIkxBUElDIiBxdWFsaXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxTVU4gICAgWDQ1 MDAgICA+CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQg Q1BVcwpGcmVlQlNEL1NNUDogMiBwYWNrYWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1Ap OiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElD IElEOiAgMgogY3B1MyAoQVApOiBBUElDIElEOiAgMwpyYW5kb206IDxTb2Z0d2FyZSwgWWFy cm93PiBpbml0aWFsaXplZApNQURUOiBGb3JjaW5nIGFjdGl2ZS1sb3cgcG9sYXJpdHkgYW5k IGxldmVsIHRyaWdnZXIgZm9yIFNDSQppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIz IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzEgPFZlcnNpb24gMS4xPiBpcnFzIDI0LTMwIG9uIG1v dGhlcmJvYXJkCmlvYXBpYzIgPFZlcnNpb24gMS4xPiBpcnFzIDMxLTM3IG9uIG1vdGhlcmJv YXJkCmlvYXBpYzMgPFZlcnNpb24gMS4xPiBpcnFzIDM4LTQ0IG9uIG1vdGhlcmJvYXJkCmlv YXBpYzQgPFZlcnNpb24gMS4xPiBpcnFzIDQ1LTUxIG9uIG1vdGhlcmJvYXJkCmlvYXBpYzUg PFZlcnNpb24gMS4xPiBpcnFzIDUyLTU4IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzYgPFZlcnNp b24gMS4xPiBpcnFzIDU5LTY1IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzcgPFZlcnNpb24gMS4x PiBpcnFzIDY2LTcyIG9uIG1vdGhlcmJvYXJkCmlvYXBpYzggPFZlcnNpb24gMS4xPiBpcnFz IDczLTc5IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzkgPFZlcnNpb24gMS4xPiBpcnFzIDgwLTg2 IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzEwIDxWZXJzaW9uIDEuMT4gaXJxcyA4Ny05MyBvbiBt b3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxTVU4gWDQ1MDA+IG9uIG1vdGhl cmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpjcHUwOiA8QUNQSSBDUFU+IG9u IGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBh Y3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBv cnQgMHg0MC0weDQzIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwCkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMx ODIgSHogcXVhbGl0eSAxMDAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3 MC0weDcxIG9uIGFjcGkwCkV2ZW50IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBx dWFsaXR5IDAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhm ZWMwMTAwMC0weGZlYzAxM2ZmIGlycSAwLDggb24gYWNwaTAKVGltZWNvdW50ZXIgIkhQRVQi IGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MApUaW1lY291bnRlciAiQUNQSS1m YXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0 LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDE4MDgtMHgxODBiIG9uIGFjcGkw CnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDEuMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCm12czA6IDxNYXJ2 ZWxsIDg4U1g2MDgxIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweDdjMDAtMHg3Y2ZmIG1lbSAw eGZhZTAwMDAwLTB4ZmFlZmZmZmYgaXJxIDI0IGF0IGRldmljZSAxLjAgb24gcGNpMQptdnMw OiBHZW4tSUksIDggM0dicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBzdXBwb3J0ZWQKbXZz Y2gwOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBtdnMwCm12c2No MTogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gbXZzMAptdnNjaDI6 IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIG12czAKbXZzY2gzOiA8 TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBtdnMwCm12c2NoNDogPE1h cnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDQgb24gbXZzMAptdnNjaDU6IDxNYXJ2 ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIG12czAKbXZzY2g2OiA8TWFydmVs bCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgNiBvbiBtdnMwCm12c2NoNzogPE1hcnZlbGwg U0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDcgb24gbXZzMApwY2liMjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAyLjAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMgptdnMxOiA8TWFydmVsbCA4OFNYNjA4MSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQg MHg4YzAwLTB4OGNmZiBtZW0gMHhmYjAwMDAwMC0weGZiMGZmZmZmIGlycSAzMiBhdCBkZXZp Y2UgMS4wIG9uIHBjaTIKbXZzMTogR2VuLUlJLCA4IDNHYnBzIHBvcnRzLCBQb3J0IE11bHRp cGxpZXIgc3VwcG9ydGVkCm12c2NoODogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFu bmVsIDAgb24gbXZzMQptdnNjaDk6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5l bCAxIG9uIG12czEKbXZzY2gxMDogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVs IDIgb24gbXZzMQptdnNjaDExOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwg MyBvbiBtdnMxCm12c2NoMTI6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA0 IG9uIG12czEKbXZzY2gxMzogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDUg b24gbXZzMQptdnNjaDE0OiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgNiBv biBtdnMxCm12c2NoMTU6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA3IG9u IG12czEKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBj aTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKb2hjaTA6IDxPSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmQxZmUwMDAtMHhmZDFmZWZmZiBpcnEgMTkgYXQg ZGV2aWNlIDAuMCBvbiBwY2kzCnVzYnVzMCBvbiBvaGNpMApvaGNpMTogPE9IQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZDFmZDAwMC0weGZkMWZkZmZmIGlycSAxOSBh dCBkZXZpY2UgMC4xIG9uIHBjaTMKdXNidXMxIG9uIG9oY2kxCnZnYXBjaTA6IDxWR0EtY29t cGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4OTgwMC0weDk4ZmYgbWVtIDB4ZmMwMDAwMDAtMHhm Y2ZmZmZmZiwweGZkMWZmMDAwLTB4ZmQxZmZmZmYgaXJxIDE2IGF0IGRldmljZSAzLjAgb24g cGNpMwp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpvaGNpMjogPE5FQyB1UEQgOTIxMCBV U0IgY29udHJvbGxlcj4gbWVtIDB4ZmQxZmMwMDAtMHhmZDFmY2ZmZiBpcnEgMTcgYXQgZGV2 aWNlIDQuMCBvbiBwY2kzCnVzYnVzMiBvbiBvaGNpMgpvaGNpMzogPE5FQyB1UEQgOTIxMCBV U0IgY29udHJvbGxlcj4gbWVtIDB4ZmQxZmIwMDAtMHhmZDFmYmZmZiBpcnEgMTggYXQgZGV2 aWNlIDQuMSBvbiBwY2kzCnVzYnVzMyBvbiBvaGNpMwplaGNpMDogPE5FQyB1UEQgNzIwMTB4 IFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmQxZmFjMDAtMHhmZDFmYWNmZiBpcnEgMTkg YXQgZGV2aWNlIDQuMiBvbiBwY2kzCnVzYnVzNDogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czQg b24gZWhjaTAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kw CmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8QU1EIDgxMTEgVURNQTEzMyBj b250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4 ZmZhMC0weGZmYWYgYXQgZGV2aWNlIDcuMSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbD4g YXQgY2hhbm5lbCAwIG9uIGF0YXBjaTAKYXRhMTogPEFUQSBjaGFubmVsPiBhdCBjaGFubmVs IDEgb24gYXRhcGNpMApwY2kwOiA8YnJpZGdlPiBhdCBkZXZpY2UgNy4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaWI0OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTQ6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDMuMCBvbiBwY2k0CnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1Cm12 czI6IDxNYXJ2ZWxsIDg4U1g2MDgxIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweGFjMDAtMHhh Y2ZmIG1lbSAweGZkNzAwMDAwLTB4ZmQ3ZmZmZmYgaXJxIDM4IGF0IGRldmljZSAxLjAgb24g cGNpNQptdnMyOiBHZW4tSUksIDggM0dicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBzdXBw b3J0ZWQKbXZzY2gxNjogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24g bXZzMgptdnNjaDE3OiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBt dnMyCm12c2NoMTg6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIG12 czIKbXZzY2gxOTogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDMgb24gbXZz MgptdnNjaDIwOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgNCBvbiBtdnMy Cm12c2NoMjE6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIG12czIK bXZzY2gyMjogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDYgb24gbXZzMgpt dnNjaDIzOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgNyBvbiBtdnMyCnBj aWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2k0CnBjaTY6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2Cm12czM6IDxNYXJ2ZWxsIDg4U1g2MDgxIFNBVEEg Y29udHJvbGxlcj4gcG9ydCAweGJjMDAtMHhiY2ZmIG1lbSAweGZkOTAwMDAwLTB4ZmQ5ZmZm ZmYgaXJxIDQ2IGF0IGRldmljZSAxLjAgb24gcGNpNgptdnMzOiBHZW4tSUksIDggM0dicHMg cG9ydHMsIFBvcnQgTXVsdGlwbGllciBzdXBwb3J0ZWQKbXZzY2gyNDogPE1hcnZlbGwgU0FU QSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gbXZzMwptdnNjaDI1OiA8TWFydmVsbCBTQVRB IGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBtdnMzCm12c2NoMjY6IDxNYXJ2ZWxsIFNBVEEg Y2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIG12czMKbXZzY2gyNzogPE1hcnZlbGwgU0FUQSBj aGFubmVsPiBhdCBjaGFubmVsIDMgb24gbXZzMwptdnNjaDI4OiA8TWFydmVsbCBTQVRBIGNo YW5uZWw+IGF0IGNoYW5uZWwgNCBvbiBtdnMzCm12c2NoMjk6IDxNYXJ2ZWxsIFNBVEEgY2hh bm5lbD4gYXQgY2hhbm5lbCA1IG9uIG12czMKbXZzY2gzMDogPE1hcnZlbGwgU0FUQSBjaGFu bmVsPiBhdCBjaGFubmVsIDYgb24gbXZzMwptdnNjaDMxOiA8TWFydmVsbCBTQVRBIGNoYW5u ZWw+IGF0IGNoYW5uZWwgNyBvbiBtdnMzCnBjaWI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDUuMCBvbiBwY2k0CnBjaTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI3CmVt MDogPEludGVsKFIpIFBSTy8xMDAwIExlZ2FjeSBOZXR3b3JrIENvbm5lY3Rpb24gMS4xLjA+ IHBvcnQgMHhjYzAwLTB4Y2MzZiBtZW0gMHhmZGFlMDAwMC0weGZkYWZmZmZmIGlycSA1MiBh dCBkZXZpY2UgMS4wIG9uIHBjaTcKZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxNDo0Zjph NjpjYTo4OAplbTE6IDxJbnRlbChSKSBQUk8vMTAwMCBMZWdhY3kgTmV0d29yayBDb25uZWN0 aW9uIDEuMS4wPiBwb3J0IDB4YzgwMC0weGM4M2YgbWVtIDB4ZmRhYzAwMDAtMHhmZGFkZmZm ZiBpcnEgNTMgYXQgZGV2aWNlIDEuMSBvbiBwY2k3CmVtMTogRXRoZXJuZXQgYWRkcmVzczog MDA6MTQ6NGY6YTY6Y2E6ODkKcGNpYjg6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgNi4wIG9uIHBjaTQKcGNpYjg6IGZhaWxlZCB0byBhbGxvY2F0ZSBpbml0aWFsIEkvTyBw b3J0IHdpbmRvdzogMHhkMDAwLTB4ZGZmZgpwY2k4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li OAplbTI6IDxJbnRlbChSKSBQUk8vMTAwMCBMZWdhY3kgTmV0d29yayBDb25uZWN0aW9uIDEu MS4wPiBtZW0gMHhmZGJlMDAwMC0weGZkYmZmZmZmIGlycSA2MSBhdCBkZXZpY2UgMS4wIG9u IHBjaTgKZW0yOiAweDQwIGJ5dGVzIG9mIHJpZCAweDIwIHJlcyA0IGZhaWxlZCAoMCwgMHhm ZmZmZmZmZmZmZmZmZmZmKS4KZW0yOiBVbmFibGUgdG8gYWxsb2NhdGUgYnVzIHJlc291cmNl OiBpb3BvcnQKZW0yOiBBbGxvY2F0aW9uIG9mIFBDSSByZXNvdXJjZXMgZmFpbGVkCmRldmlj ZV9hdHRhY2g6IGVtMiBhdHRhY2ggcmV0dXJuZWQgNgplbTI6IDxJbnRlbChSKSBQUk8vMTAw MCBMZWdhY3kgTmV0d29yayBDb25uZWN0aW9uIDEuMS4wPiBtZW0gMHhmZGJjMDAwMC0weGZk YmRmZmZmIGlycSA2MiBhdCBkZXZpY2UgMS4xIG9uIHBjaTgKZW0yOiAweDQwIGJ5dGVzIG9m IHJpZCAweDIwIHJlcyA0IGZhaWxlZCAoMCwgMHhmZmZmZmZmZmZmZmZmZmZmKS4KZW0yOiBV bmFibGUgdG8gYWxsb2NhdGUgYnVzIHJlc291cmNlOiBpb3BvcnQKZW0yOiBBbGxvY2F0aW9u IG9mIFBDSSByZXNvdXJjZXMgZmFpbGVkCmRldmljZV9hdHRhY2g6IGVtMiBhdHRhY2ggcmV0 dXJuZWQgNgpwY2liOTogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMApwY2kxMjog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjkKcGNpYjEwOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDkuMCBvbiBwY2kxMgpwY2kxMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEw CnBjaWIxMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTEy CnBjaTE0OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTEKcGNpYjEyOiA8QUNQSSBIb3N0LVBD SSBicmlkZ2U+IG9uIGFjcGkwCnBjaTk6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMgpwY2li MTM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTkKcGNpMTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMwptdnM0OiA8TWFydmVsbCA4OFNYNjA4MSBTQVRB IGNvbnRyb2xsZXI+IHBvcnQgMHhlYzAwLTB4ZWNmZiBtZW0gMHhmZTMwMDAwMC0weGZlM2Zm ZmZmIGlycSA2OCBhdCBkZXZpY2UgMS4wIG9uIHBjaTEwCm12czQ6IEdlbi1JSSwgOCAzR2Jw cyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIHN1cHBvcnRlZAptdnNjaDMyOiA8TWFydmVsbCBT QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBtdnM0Cm12c2NoMzM6IDxNYXJ2ZWxsIFNB VEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIG12czQKbXZzY2gzNDogPE1hcnZlbGwgU0FU QSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gbXZzNAptdnNjaDM1OiA8TWFydmVsbCBTQVRB IGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBtdnM0Cm12c2NoMzY6IDxNYXJ2ZWxsIFNBVEEg Y2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIG12czQKbXZzY2gzNzogPE1hcnZlbGwgU0FUQSBj aGFubmVsPiBhdCBjaGFubmVsIDUgb24gbXZzNAptdnNjaDM4OiA8TWFydmVsbCBTQVRBIGNo YW5uZWw+IGF0IGNoYW5uZWwgNiBvbiBtdnM0Cm12c2NoMzk6IDxNYXJ2ZWxsIFNBVEEgY2hh bm5lbD4gYXQgY2hhbm5lbCA3IG9uIG12czQKcGNpYjE0OiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDguMCBvbiBwY2k5CnBjaWIxNDogZmFpbGVkIHRvIGFsbG9jYXRlIGlu aXRpYWwgSS9PIHBvcnQgd2luZG93OiAweGYwMDAtMHhmZmZmCnBjaTExOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMTQKbXZzNTogPE1hcnZlbGwgODhTWDYwODEgU0FUQSBjb250cm9sbGVy PiBtZW0gMHhmZTUwMDAwMC0weGZlNWZmZmZmIGlycSA3NiBhdCBkZXZpY2UgMS4wIG9uIHBj aTExCm12czU6IEdlbi1JSSwgOCAzR2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIHN1cHBv cnRlZAptdnNjaDQwOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBt dnM1Cm12c2NoNDE6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIG12 czUKbXZzY2g0MjogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gbXZz NQptdnNjaDQzOiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMyBvbiBtdnM1 Cm12c2NoNDQ6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA0IG9uIG12czUK bXZzY2g0NTogPE1hcnZlbGwgU0FUQSBjaGFubmVsPiBhdCBjaGFubmVsIDUgb24gbXZzNQpt dnNjaDQ2OiA8TWFydmVsbCBTQVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgNiBvbiBtdnM1Cm12 c2NoNDc6IDxNYXJ2ZWxsIFNBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCA3IG9uIG12czUKYWNw aV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAp1YXJ0MDogPDE2NTUwIG9yIGNv bXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApv cm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzlmZmYsMHhjYTAw MC0weGNhZmZmLDB4Y2IwMDAtMHhjYmZmZiwweGNjMDAwLTB4Y2NmZmYsMHhjZDAwMC0weGNk ZmZmLDB4Y2UwMDAtMHhjZWZmZiwweGNmMDAwLTB4ZDU3ZmYgb24gaXNhMApzYzA6IDxTeXN0 ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVh bCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBv cnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYXRrYmRjMDog PEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNh MAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2Jk MAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0 IHJhbmdlCnBvd2Vybm93MDogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MApwb3dlcm5vdzE6 IDxDb29sYG4nUXVpZXQgSzg+IG9uIGNwdTEKcG93ZXJub3cyOiA8Q29vbGBuJ1F1aWV0IEs4 PiBvbiBjcHUyCnBvd2Vybm93MzogPENvb2xgbidRdWlldCBLOD4gb24gY3B1MwpaRlMgZmls ZXN5c3RlbSB2ZXJzaW9uOiA1ClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbjogZmVhdHVyZXMg c3VwcG9ydCAoNTAwMCkKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpyYW5k b206IHVuYmxvY2tpbmcgZGV2aWNlLgp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2 MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w CnVzYnVzNDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxBTUQgT0hD SSByb290IEhVQj4gYXQgdXNidXMwCnVodWIwOiA8QU1EIE9IQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEFNRCBP SENJIHJvb3QgSFVCPiBhdCB1c2J1czEKdWh1YjE6IDxBTUQgT0hDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8TkVD IE9IQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMgp1aHViMjogPE5FQyBPSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6IDxO RUMgT0hDSSByb290IEhVQj4gYXQgdXNidXMzCnVodWIzOiA8TkVDIE9IQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTog PE5FQyBFSENJIHJvb3QgSFVCPiBhdCB1c2J1czQKdWh1YjQ6IDxORUMgRUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1aHViMDog MyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDMgcG9ydHMg d2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIzOiAyIHBvcnRzIHdpdGggMiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWdlbjAuMjogPEFtZXJpY2FuIE1lZ2F0cmVuZHMgSW5jLiBWaXJ0 dWFsIEtleWJvYXJkIGFuZCBNb3VzZT4gYXQgdXNidXMwCnVrYmQwOiA8S2V5Ym9hcmQgSW50 ZXJmYWNlPiBvbiB1c2J1czAKa2JkMiBhdCB1a2JkMAp1aHViNDogNSBwb3J0cyB3aXRoIDUg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjMuMjogPEp1c3Rjb20gVGVjaG5vbG9neSBV U0IgS1ZNIFN3aXRjaD4gYXQgdXNidXMzCnVrYmQxOiA8SnVzdGNvbSBUZWNobm9sb2d5IFVT QiBLVk0gU3dpdGNoLCBjbGFzcyAwLzAsIHJldiAxLjEwLzEuMDAsIGFkZHIgMj4gb24gdXNi dXMzCmtiZDMgYXQgdWtiZDEKdWdlbjQuMjogPHZlbmRvciAweDA0YjQgcHJvZHVjdCAweDY1 NjA+IGF0IHVzYnVzNAp1aHViNTogPHZlbmRvciAweDA0YjQgcHJvZHVjdCAweDY1NjAsIGNs YXNzIDkvMCwgcmV2IDIuMDAvMC4wYiwgYWRkciAyPiBvbiB1c2J1czQKdWh1YjU6IE1UVCBl bmFibGVkCnVodWI1OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAph ZGEwIGF0IG12c2NoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPEhJVEFD SEkgSERTNzI1MFNBU1VONTAwRyAwNzM0S1A1VjhIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIu eCBkZXZpY2UKYWRhMDogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNVY4SAphZGEwOiAzMDAu MDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRh MDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDQ3Njk0ME1CICg5NzY3NzMxNjgg NTEyIGJ5dGUgc2VjdG9ycykKYWRhMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0CmFk YTEgYXQgbXZzY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMAphZGExOiA8SElUQUNI SSBIRFM3MjUwU0FTVU41MDBHIDA3MzRLUDVVRUggSzJBT0FWMEE+IEFUQS03IFNBVEEgMi54 IGRldmljZQphZGExOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA1VUVICmFkYTE6IDMwMC4w MDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gMjA0OGJ5dGVzKQphZGEx OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1 MTIgYnl0ZSBzZWN0b3JzKQphZGExOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDYKYWRh MiBhdCBtdnNjaDIgYnVzIDAgc2NidXMyIHRhcmdldCAwIGx1biAwCmFkYTI6IDxISVRBQ0hJ IEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNOUdFSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLngg ZGV2aWNlCmFkYTI6IFNlcmlhbCBOdW1iZXIgS1JWUDY3WkJITTlHRUgKYWRhMjogMzAwLjAw ME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyAyMDQ4Ynl0ZXMpCmFkYTI6 IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyOiA0NzY5NDBNQiAoOTc2NzczMTY4IDUx MiBieXRlIHNlY3RvcnMpCmFkYTI6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkOAphZGEz IGF0IG12c2NoMyBidXMgMCBzY2J1czMgdGFyZ2V0IDAgbHVuIDAKYWRhMzogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzMzS1A3N1hIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhMzogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNzdYSAphZGEzOiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTM6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhMzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxMAphZGE0 IGF0IG12c2NoNCBidXMgMCBzY2J1czQgdGFyZ2V0IDAgbHVuIDAKYWRhNDogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzM0S1A1VjlIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhNDogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNVY5SAphZGE0OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNDog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTQ6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhNDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxMgphZGE1 IGF0IG12c2NoNSBidXMgMCBzY2J1czUgdGFyZ2V0IDAgbHVuIDAKYWRhNTogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzM0S1A1VlBIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhNTogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNVZQSAphZGE1OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNTog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTU6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhNTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxNAphZGE2 IGF0IG12c2NoNiBidXMgMCBzY2J1czYgdGFyZ2V0IDAgbHVuIDAKYWRhNjogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzMzS1A3NFZIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhNjogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNzRWSAphZGE2OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNjog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTY6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhNjogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxNgphZGE3 IGF0IG12c2NoNyBidXMgMCBzY2J1czcgdGFyZ2V0IDAgbHVuIDAKYWRhNzogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzMzS04yNTZIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhNzogU2VyaWFsIE51bWJlciBLUlZONjdaQkhOMjU2SAphZGE3OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNzog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTc6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhNzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxOAphZGE4 IGF0IG12c2NoOCBidXMgMCBzY2J1czggdGFyZ2V0IDAgbHVuIDAKYWRhODogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzM0S1IwV1lIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhODogU2VyaWFsIE51bWJlciBLUlZONjdaQkhSMFdZSAphZGE4OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhODog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTg6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhODogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQyMAphZGE5 IGF0IG12c2NoOSBidXMgMCBzY2J1czkgdGFyZ2V0IDAgbHVuIDAKYWRhOTogPEhJVEFDSEkg SERTNzI1MFNBU1VONTAwRyAwNzM0S1A1VlJIIEsyQU9BVjBBPiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhOTogU2VyaWFsIE51bWJlciBLUlZONjdaQkhQNVZSSAphZGE5OiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhOTog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTk6IDQ3Njk0ME1CICg5NzY3NzMxNjggNTEy IGJ5dGUgc2VjdG9ycykKYWRhOTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQyMgphZGEx MCBhdCBtdnNjaDEwIGJ1cyAwIHNjYnVzMTAgdGFyZ2V0IDAgbHVuIDAKYWRhMTA6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNOUJXSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTEwOiBTZXJpYWwgTnVtYmVyIEtSVlA2N1pCSE05QldICmFkYTEwOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhMTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExMDogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExMDogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQyNAphZGExMSBhdCBtdnNjaDExIGJ1cyAwIHNjYnVzMTEgdGFyZ2V0IDAgbHVuIDAKYWRh MTE6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tQNzRZSCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTExOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA3NFlI CmFkYTExOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhMTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExMTogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExMTogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQyNgphZGExMiBhdCBtdnNjaDEyIGJ1cyAwIHNjYnVzMTIgdGFyZ2V0IDAg bHVuIDAKYWRhMTI6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtSMFpUSCBLMkFP QVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTEyOiBTZXJpYWwgTnVtYmVyIEtSVk42 N1pCSFIwWlRICmFkYTEyOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhMTI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEx MjogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExMjogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQyOAphZGExMyBhdCBtdnNjaDEzIGJ1cyAwIHNjYnVzMTMg dGFyZ2V0IDAgbHVuIDAKYWRhMTM6IDxISVRBQ0hJIEhVQTcyNTBTQlNVTjUwMEcgMDgxNEo4 NjNVRiBHSzZPQTkwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTEzOiBTZXJpYWwgTnVt YmVyIEdURjQwMlA2Rzg2M1VGCmFkYTEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMTM6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGExMzogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEx MzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQzMAphZGExNCBhdCBtdnNjaDE0IGJ1cyAw IHNjYnVzMTQgdGFyZ2V0IDAgbHVuIDAKYWRhMTQ6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDczM0tOMjkzSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTE0OiBT ZXJpYWwgTnVtYmVyIEtSVk42N1pCSE4yOTNICmFkYTE0OiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMTQ6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGExNDogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGExNDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQzMgphZGExNSBhdCBtdnNj aDE1IGJ1cyAwIHNjYnVzMTUgdGFyZ2V0IDAgbHVuIDAKYWRhMTU6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczM0tQNk0xSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTE1OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA2TTFICmFkYTE1OiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMTU6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExNTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGExNTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQzNAphZGEx NiBhdCBtdnNjaDE2IGJ1cyAwIHNjYnVzMTggdGFyZ2V0IDAgbHVuIDAKYWRhMTY6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDcyNktCWk1VSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTE2OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSEJaTVVICmFkYTE2OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhMTY6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExNjogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExNjogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQzNgphZGExNyBhdCBtdnNjaDE3IGJ1cyAwIHNjYnVzMTkgdGFyZ2V0IDAgbHVuIDAKYWRh MTc6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtSME1YSCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTE3OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFIwTVhI CmFkYTE3OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhMTc6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExNzogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExNzogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQzOAphZGExOCBhdCBtdnNjaDE4IGJ1cyAwIHNjYnVzMjAgdGFyZ2V0IDAg bHVuIDAKYWRhMTg6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNNVRHSCBLMkFP QVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTE4OiBTZXJpYWwgTnVtYmVyIEtSVlA2 N1pCSE01VEdICmFkYTE4OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhMTg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEx ODogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGExODogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ0MAphZGExOSBhdCBtdnNjaDE5IGJ1cyAwIHNjYnVzMjEg dGFyZ2V0IDAgbHVuIDAKYWRhMTk6IDxISVRBQ0hJIEhVQTcyNTBTQlNVTjUwMEcgMDgxNEo4 NEhLRiBHSzZPQTkwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTE5OiBTZXJpYWwgTnVt YmVyIEdURjQwMlA2Rzg0SEtGCmFkYTE5OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMTk6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGExOTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEx OTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0MgphZGEyMCBhdCBtdnNjaDIwIGJ1cyAw IHNjYnVzMjIgdGFyZ2V0IDAgbHVuIDAKYWRhMjA6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDcyNktEWk1MSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTIwOiBT ZXJpYWwgTnVtYmVyIEtSVk42N1pCSERaTUxICmFkYTIwOiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMjA6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGEyMDogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGEyMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0NAphZGEyMSBhdCBtdnNj aDIxIGJ1cyAwIHNjYnVzMjMgdGFyZ2V0IDAgbHVuIDAKYWRhMjE6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczNEtQNVVUSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTIxOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA1VVRICmFkYTIxOiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMjE6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyMTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGEyMTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ0NgphZGEy MiBhdCBtdnNjaDIyIGJ1cyAwIHNjYnVzMjQgdGFyZ2V0IDAgbHVuIDAKYWRhMjI6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNNkE0SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTIyOiBTZXJpYWwgTnVtYmVyIEtSVlA2N1pCSE02QTRICmFkYTIyOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhMjI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyMjogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEyMjogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQ0OAphZGEyMyBhdCBtdnNjaDIzIGJ1cyAwIHNjYnVzMjUgdGFyZ2V0IDAgbHVuIDAKYWRh MjM6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tOV0w4SCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTIzOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSE5XTDhI CmFkYTIzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhMjM6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyMzogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEyMzogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ1MAphZGEyNCBhdCBtdnNjaDI0IGJ1cyAwIHNjYnVzMjYgdGFyZ2V0IDAg bHVuIDAKYWRhMjQ6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDcyNktBUkwwSCBLMkFP QVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTI0OiBTZXJpYWwgTnVtYmVyIEtSVk42 N1pCSEFSTDBICmFkYTI0OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhMjQ6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEy NDogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEyNDogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ1MgphZGEyNSBhdCBtdnNjaDI1IGJ1cyAwIHNjYnVzMjcg dGFyZ2V0IDAgbHVuIDAKYWRhMjU6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtQ NVdISCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTI1OiBTZXJpYWwgTnVt YmVyIEtSVk42N1pCSFA1V0hICmFkYTI1OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMjU6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGEyNTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEy NTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ1NAphZGEyNiBhdCBtdnNjaDI2IGJ1cyAw IHNjYnVzMjggdGFyZ2V0IDAgbHVuIDAKYWRhMjY6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDczNEtLWEw5SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTI2OiBT ZXJpYWwgTnVtYmVyIEtSVlA2N1pCSEtYTDlICmFkYTI2OiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMjY6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGEyNjogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGEyNjogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ1NgphZGEyNyBhdCBtdnNj aDI3IGJ1cyAwIHNjYnVzMjkgdGFyZ2V0IDAgbHVuIDAKYWRhMjc6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczM0tOR1o4SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTI3OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSE5HWjhICmFkYTI3OiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMjc6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyNzogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGEyNzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ1OAphZGEy OCBhdCBtdnNjaDI4IGJ1cyAwIHNjYnVzMzAgdGFyZ2V0IDAgbHVuIDAKYWRhMjg6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDcyNktEWktWSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTI4OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSERaS1ZICmFkYTI4OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhMjg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyODogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEyODogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQ2MAphZGEyOSBhdCBtdnNjaDI5IGJ1cyAwIHNjYnVzMzEgdGFyZ2V0IDAgbHVuIDAKYWRh Mjk6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtSMFoySCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTI5OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFIwWjJI CmFkYTI5OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhMjk6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEyOTogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEyOTogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ2MgphZGEzMCBhdCBtdnNjaDMwIGJ1cyAwIHNjYnVzMzIgdGFyZ2V0IDAg bHVuIDAKYWRhMzA6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNNzdaSCBLMkFP QVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTMwOiBTZXJpYWwgTnVtYmVyIEtSVlA2 N1pCSE03N1pICmFkYTMwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhMzA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEz MDogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEzMDogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ2NAphZGEzMSBhdCBtdnNjaDMxIGJ1cyAwIHNjYnVzMzMg dGFyZ2V0IDAgbHVuIDAKYWRhMzE6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tN MUpMSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTMxOiBTZXJpYWwgTnVt YmVyIEtSVk42N1pCSE0xSkxICmFkYTMxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzE6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGEzMTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEz MTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ2NgphZGEzMiBhdCBtdnNjaDMyIGJ1cyAw IHNjYnVzMzQgdGFyZ2V0IDAgbHVuIDAKYWRhMzI6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDcyNktEWlAzSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTMyOiBT ZXJpYWwgTnVtYmVyIEtSVk42N1pCSERaUDNICmFkYTMyOiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzI6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGEzMjogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGEzMjogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ2OAphZGEzMyBhdCBtdnNj aDMzIGJ1cyAwIHNjYnVzMzUgdGFyZ2V0IDAgbHVuIDAKYWRhMzM6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczNEtSMFpWSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTMzOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFIwWlZICmFkYTMzOiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzM6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEzMzogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGEzMzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ3MAphZGEz NCBhdCBtdnNjaDM0IGJ1cyAwIHNjYnVzMzYgdGFyZ2V0IDAgbHVuIDAKYWRhMzQ6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tQNEc5SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTM0OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA0RzlICmFkYTM0OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhMzQ6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEzNDogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEzNDogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQ3MgphZGEzNSBhdCBtdnNjaDM1IGJ1cyAwIHNjYnVzMzcgdGFyZ2V0IDAgbHVuIDAKYWRh MzU6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tQQjZXRiBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTM1OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFBCNldG CmFkYTM1OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhMzU6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEzNTogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEzNTogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ3NAphZGEzNiBhdCBtdnNjaDM2IGJ1cyAwIHNjYnVzMzggdGFyZ2V0IDAg bHVuIDAKYWRhMzY6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtSMFpYSCBLMkFP QVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTM2OiBTZXJpYWwgTnVtYmVyIEtSVk42 N1pCSFIwWlhICmFkYTM2OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhMzY6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEz NjogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEzNjogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ3NgphZGEzNyBhdCBtdnNjaDM3IGJ1cyAwIHNjYnVzMzkg dGFyZ2V0IDAgbHVuIDAKYWRhMzc6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtQ NVVWSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTM3OiBTZXJpYWwgTnVt YmVyIEtSVk42N1pCSFA1VVZICmFkYTM3OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzc6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGEzNzogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGEz NzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ3OAphZGEzOCBhdCBtdnNjaDM4IGJ1cyAw IHNjYnVzNDAgdGFyZ2V0IDAgbHVuIDAKYWRhMzg6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDczNEtNR0pQSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTM4OiBT ZXJpYWwgTnVtYmVyIEtSVlA2N1pCSE1HSlBICmFkYTM4OiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzg6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGEzODogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGEzODogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ4MAphZGEzOSBhdCBtdnNj aDM5IGJ1cyAwIHNjYnVzNDEgdGFyZ2V0IDAgbHVuIDAKYWRhMzk6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczM0tOR1ZYSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTM5OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSE5HVlhICmFkYTM5OiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhMzk6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEzOTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGEzOTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ4MgphZGE0 MCBhdCBtdnNjaDQwIGJ1cyAwIHNjYnVzNDIgdGFyZ2V0IDAgbHVuIDAKYWRhNDA6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDcyNktFNEtLSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTQwOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSEU0S0tICmFkYTQwOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhNDA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0MDogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0MDogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQ4NAphZGE0MSBhdCBtdnNjaDQxIGJ1cyAwIHNjYnVzNDMgdGFyZ2V0IDAgbHVuIDAKYWRh NDE6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtQNVdBSCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTQxOiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA1V0FI CmFkYTQxOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhNDE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0MTogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0MTogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ4NgphZGE0MiBhdCBtdnNjaDQyIGJ1cyAwIHNjYnVzNDQgdGFyZ2V0IDAg bHVuIDAKYWRhNDI6IDxISVRBQ0hJIEhVQTcyNTBTQlNVTjUwMEcgMDgxNEo4NjNXRiBHSzZP QTkwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTQyOiBTZXJpYWwgTnVtYmVyIEdURjQw MlA2Rzg2M1dGCmFkYTQyOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDIwNDhieXRlcykKYWRhNDI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0 MjogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0MjogUHJldmlv dXNseSB3YXMga25vd24gYXMgYWQ4OAphZGE0MyBhdCBtdnNjaDQzIGJ1cyAwIHNjYnVzNDUg dGFyZ2V0IDAgbHVuIDAKYWRhNDM6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tQ Nk4wSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTQzOiBTZXJpYWwgTnVt YmVyIEtSVk42N1pCSFA2TjBICmFkYTQzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEg Mi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNDM6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZAphZGE0MzogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0 MzogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ5MAphZGE0NCBhdCBtdnNjaDQ0IGJ1cyAw IHNjYnVzNDYgdGFyZ2V0IDAgbHVuIDAKYWRhNDQ6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUw MEcgMDcyNktES1VLSCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNlCmFkYTQ0OiBT ZXJpYWwgTnVtYmVyIEtSVk42N1pCSERLVUtICmFkYTQ0OiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNDQ6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGE0NDogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGE0NDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ5MgphZGE0NSBhdCBtdnNj aDQ1IGJ1cyAwIHNjYnVzNDcgdGFyZ2V0IDAgbHVuIDAKYWRhNDU6IDxISVRBQ0hJIEhEUzcy NTBTQVNVTjUwMEcgMDczNEtSMFk3SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAyLnggZGV2aWNl CmFkYTQ1OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFIwWTdICmFkYTQ1OiAzMDAuMDAwTUIv cyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykKYWRhNDU6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0NTogNDc2OTQwTUIgKDk3Njc3MzE2OCA1MTIg Ynl0ZSBzZWN0b3JzKQphZGE0NTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ5NAphZGE0 NiBhdCBtdnNjaDQ2IGJ1cyAwIHNjYnVzNDggdGFyZ2V0IDAgbHVuIDAKYWRhNDY6IDxISVRB Q0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczNEtNNzg1SCBLMkFPQVYwQT4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTQ2OiBTZXJpYWwgTnVtYmVyIEtSVlA2N1pCSE03ODVICmFkYTQ2OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIwNDhieXRlcykK YWRhNDY6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0NjogNDc2OTQwTUIgKDk3Njc3 MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0NjogUHJldmlvdXNseSB3YXMga25vd24gYXMg YWQ5NgphZGE0NyBhdCBtdnNjaDQ3IGJ1cyAwIHNjYnVzNDkgdGFyZ2V0IDAgbHVuIDAKYWRh NDc6IDxISVRBQ0hJIEhEUzcyNTBTQVNVTjUwMEcgMDczM0tQNzQwSCBLMkFPQVYwQT4gQVRB LTcgU0FUQSAyLnggZGV2aWNlCmFkYTQ3OiBTZXJpYWwgTnVtYmVyIEtSVk42N1pCSFA3NDBI CmFkYTQ3OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDIw NDhieXRlcykKYWRhNDc6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGE0NzogNDc2OTQw TUIgKDk3Njc3MzE2OCA1MTIgYnl0ZSBzZWN0b3JzKQphZGE0NzogUHJldmlvdXNseSB3YXMg a25vd24gYXMgYWQ5OApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzIg TGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHpmczp6cm9vdC9ST09UL2RlZmF1bHQgW10uLi4KZW0wOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVAKdW1zMTogPEp1c3Rjb20gVGVjaG5vbG9neSBVU0IgS1ZNIFN3aXRjaCwg Y2xhc3MgMC8wLCByZXYgMS4xMC8xLjAwLCBhZGRyIDI+IG9uIHVzYnVzMwp1bXMwOiA8TW91 c2UgSW50ZXJmYWNlPiBvbiB1c2J1czAKdW1zMTogNSBidXR0b25zIGFuZCBbWFlaXSBjb29y ZGluYXRlcyBJRD0wCmVtMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCg== --------------19785548ADFB862C2A7A9CF2-- From owner-freebsd-stable@freebsd.org Fri Mar 1 23:38:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B1F41505E57 for ; Fri, 1 Mar 2019 23:38:56 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 9C13D6826D for ; Fri, 1 Mar 2019 23:38:54 +0000 (UTC) (envelope-from SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id DB48528417; Sat, 2 Mar 2019 00:38:51 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0531E28411; Sat, 2 Mar 2019 00:38:50 +0100 (CET) Subject: Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: Lee Damon , freebsd-stable@freebsd.org References: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> <487c50a4-216b-efc6-044f-80114749bf86@castle.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <824b0eaf-c99e-84b1-ef50-c5b1c6ae5ed4@quip.cz> Date: Sat, 2 Mar 2019 00:38:49 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <487c50a4-216b-efc6-044f-80114749bf86@castle.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9C13D6826D X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.948,0]; IP_SCORE(0.26)[ip: (0.65), ipnet: 94.124.104.0/21(0.32), asn: 42000(0.26), country: CZ(0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.939,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: elsa.codelab.cz]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.96)[0.962,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[209.16.49.86.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=Lvyw=RE=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 23:38:56 -0000 Lee Damon wrote on 2019/03/02 00:06: > Darn it. I get the same kernel panic with that one. > > I'm compiling locally but I don't expect that to make any difference. > I'll need to go pawing through the release notes and see if there are > any references to deprecated hardware that might be involved. > > I'm attaching a copy of dmesg output from a successful boot into > 10.4-STABLE. The kernel panic appears to happen around 15% of the way > into the output, around I am running 11.2 on SunFire X2100 M2 but according to your dmesg it uses different chips. X2100 M2 has nVidia nForce MCP55 chipset for ATA devices, nfe for 2 NICs and Broadcom bge for the other 2 NIC's. Did you tried to boot "safe mode"? (selectable in boot menu). Or you can try to disable / enable some settings in the BIOS. Something related to USB or onboard VGA etc. may help. Miroslav Lachman From owner-freebsd-stable@freebsd.org Sat Mar 2 00:36:50 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9D8E150795B for ; Sat, 2 Mar 2019 00:36:49 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E269B6B754 for ; Sat, 2 Mar 2019 00:36:38 +0000 (UTC) (envelope-from thenomad@gmail.com) Received: by mail-pl1-x636.google.com with SMTP id y10so12275647plp.0 for ; Fri, 01 Mar 2019 16:36:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+az+PFXXtmAO7++ucjPGUSxbz47KJcyO0D/RWi0LMjo=; b=Ghz1AQMRGEDj0cQ+1bamOf4jmjs7ZIrnyu0KqPmcr4Ea01AqlUvf9FHGzRmecm7AEe 5WZi9wymvuTRnfd4+9KBfWhSOekMB4BXOq+5UjiiL2t+VTWaHUjVygJVNU0dHJw13Zpw TtdND8MmXZ3UAavrPOj33pLKQum0ZnNsqnHvtgrbAmUiM/K2+YIn7zhAPM/yfcZGoDtn HG2q1x6acY5CDU7VuA06LRsdWN0u9MhLZ0J2buqGbTnjBEw8iYAxJO7Yi3kEYbd6hTa7 UA4UoXNajUOl5rfliMongIXbkrtClSxgXJ/wUM5Y41XWPAjLlzGgdqKRh+QPzOc5sh0S dpAw== X-Gm-Message-State: APjAAAXKtML/DXvI82YbCSja6nc98Se9gjwfViIFWcfz4LHhjvQDsS3d 1GB2oKjabnlXgA2GyZB6acrk9o3E X-Google-Smtp-Source: APXvYqwPfGUCS10zoYsZpczYmV8eQK8WBBAgNlF9FBdKS4qI80AsXXPhDSbVlKuFdT1UFRjykHsG6g== X-Received: by 2002:a17:902:3143:: with SMTP id w61mr8610188plb.253.1551486997060; Fri, 01 Mar 2019 16:36:37 -0800 (PST) Received: from vanyel.ee.washington.edu (vanyel.ee.washington.edu. [128.208.232.99]) by smtp.gmail.com with ESMTPSA id n4sm46147800pfh.8.2019.03.01.16.36.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 16:36:35 -0800 (PST) Sender: Lee Damon Subject: Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org References: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> <487c50a4-216b-efc6-044f-80114749bf86@castle.org> <824b0eaf-c99e-84b1-ef50-c5b1c6ae5ed4@quip.cz> From: Lee Damon Message-ID: Date: Fri, 1 Mar 2019 16:36:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <824b0eaf-c99e-84b1-ef50-c5b1c6ae5ed4@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E269B6B754 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FORGED_SENDER(0.30)[nomad@castle.org,thenomad@gmail.com]; IP_SCORE(-2.86)[ip: (-9.46), ipnet: 2607:f8b0::/32(-2.72), asn: 15169(-2.04), country: US(-0.07)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[nomad@castle.org,thenomad@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.913,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_DNSFAIL(0.00)[castle.org : query timed out]; RCVD_IN_DNSWL_NONE(0.00)[6.3.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 00:36:50 -0000 On 3/1/19 15:38 , Miroslav Lachman wrote: > Did you tried to boot "safe mode"? (selectable in boot menu). I completely forgot about safe mode. Yep. It boots. I'm going to finish the freebsd-update process then reboot into safe mode again. I'm out of time to work on this today and am only in this lab on Fridays so I'll have to pick up working on this problem next Friday. Thanks for the help, nomad From owner-freebsd-stable@freebsd.org Sat Mar 2 03:16:53 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99AD5150E19E for ; Sat, 2 Mar 2019 03:16:53 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [96.73.9.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A20C71D76 for ; Sat, 2 Mar 2019 03:16:52 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id 12E14780C7 for ; Fri, 1 Mar 2019 20:17:54 -0700 (MST) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ekGko9uKiMLX for ; Fri, 1 Mar 2019 20:17:53 -0700 (MST) Received: from macbex.local (gw.bluestop.org [96.73.9.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA for ; Fri, 1 Mar 2019 20:17:53 -0700 (MST) To: freebsd-stable@freebsd.org From: Rebecca Cran Subject: EHCI interrupt storm (~24000 per second) on 12.0 (Lynx Point chipset) Message-ID: Date: Fri, 1 Mar 2019 20:16:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4A20C71D76 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.75 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bluestop.org:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-2.93)[ip: (-9.74), ipnet: 96.64.0.0/11(-4.28), asn: 7922(-0.56), country: US(-0.07)]; DKIM_TRACE(0.00)[bluestop.org:+]; DMARC_POLICY_ALLOW(-0.50)[bluestop.org,quarantine]; MX_GOOD(-0.01)[mail.bluestop.org]; NEURAL_HAM_SHORT(-0.81)[-0.815,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 03:16:53 -0000 I have an Intel Server board (it's a UEFI Development Kit system, based on the S1200V3RPS) that I recently upgraded to 12.0-RELEASE, and today noticed the intr task taking up too much CPU time. I can't say whether this is a regression from 11.x or not. Looking at the output of "vmstat -i" there appears to be an interrupt storm: bcran@muon:~ % vmstat -i interrupt                          total       rate irq4: uart0                          248          4 irq16: ehci0                         147          2 irq23: ehci1                     1689451      24000 cpu0:timer                          6398         91 cpu1:timer                          3696         53 cpu2:timer                          2246         32 cpu3:timer                          2386         34 cpu4:timer                          3152         45 cpu5:timer                          2341         33 cpu6:timer                         75101       1067 cpu7:timer                          1646         23 irq265: igb0:rxq0                    118          2 irq266: igb0:rxq1                    133          2 irq267: igb0:rxq2                     17          0 irq268: igb0:rxq3                    259          4 irq269: igb0:aq                        2          0 irq270: igb1:rxq0                      2          0 irq275: ahci0                      17450        248 Total                            1804793      25639 This is after I tried setting hw.usb.ehci.lostintrbug=1 in /boot/loader and rebooting. The USB devices connected are: bcran@muon:~ % sudo usbconfig ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (2mA) dmesg shows it being a Lynx Point USB controller: ehci1: mem 0xc2b29000-0xc2b293ff at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 usbus1: 480Mbps High Speed USB v2.0 Strangely, em0 is failing to attach, but I guess that's unrelated? em0: port 0x5040-0x505f mem 0xc2b00000-0xc2b1ffff,0xc2b2b000-0xc2b2bfff at device 25.0 on pci0 em0: attach_pre capping queues at 1 em0: Setup of Shared code failed, error -2 em0: IFDI_ATTACH_PRE failed 6 device_attach: em0 attach returned 6 -- Rebecca Cran From owner-freebsd-stable@freebsd.org Sat Mar 2 09:46:38 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5643151B19E for ; Sat, 2 Mar 2019 09:46:38 +0000 (UTC) (envelope-from SRS0=WO7H=RF=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 13D61869A7 for ; Sat, 2 Mar 2019 09:46:36 +0000 (UTC) (envelope-from SRS0=WO7H=RF=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C3CD928416; Sat, 2 Mar 2019 10:46:33 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 70C1628411; Sat, 2 Mar 2019 10:46:29 +0100 (CET) Subject: Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic To: Lee Damon , freebsd-stable@freebsd.org References: <987591af-c860-2427-0f44-7e4cb491ff68@castle.org> <1e7a5b3a-16a0-fc4d-9a65-631bb177f68d@quip.cz> <487c50a4-216b-efc6-044f-80114749bf86@castle.org> <824b0eaf-c99e-84b1-ef50-c5b1c6ae5ed4@quip.cz> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Sat, 2 Mar 2019 10:46:25 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 13D61869A7 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.90 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.58)[0.584,0]; IP_SCORE(0.25)[ip: (0.63), ipnet: 94.124.104.0/21(0.32), asn: 42000(0.25), country: CZ(0.07)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.955,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: elsa.codelab.cz]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.92)[0.921,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=WO7H=RF=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[209.16.49.86.zen.spamhaus.org : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=WO7H=RF=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 09:46:38 -0000 Lee Damon wrote on 2019/03/02 01:36: > On 3/1/19 15:38 , Miroslav Lachman wrote: >> Did you tried to boot "safe mode"? (selectable in boot menu). > > I completely forgot about safe mode. > > Yep. It boots. I'm going to finish the freebsd-update process then > reboot into safe mode again. I'm out of time to work on this today and > am only in this lab on Fridays so I'll have to pick up working on this > problem next Friday. Glad to know something finally works :) You can look in to /boot/menu-commands.4th there is definition what Safe Mode disable : safemode_enabled? ( -- flag ) s" kern.smp.disabled" getenv -1 <> dup if swap drop ( c-addr flag -- flag ) then ; : safemode_enable ( -- ) s" set kern.smp.disabled=1" evaluate s" set hw.ata.ata_dma=0" evaluate s" set hw.ata.atapi_dma=0" evaluate s" set hw.ata.wc=0" evaluate s" set hw.eisa_slots=0" evaluate s" set kern.eventtimer.periodic=1" evaluate s" set kern.geom.part.check_integrity=0" evaluate ; You can play with these items one by one to find what is the root cause in your case. Miroslav Lachman From owner-freebsd-stable@freebsd.org Sat Mar 2 17:57:05 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34EE21506DB6 for ; Sat, 2 Mar 2019 17:57:05 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D92E722E9 for ; Sat, 2 Mar 2019 17:57:04 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f178.google.com with SMTP id d14so850251ljl.9 for ; Sat, 02 Mar 2019 09:57:04 -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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qZb4ZBNmppe9EYhW2MLyWrgg5I5zvd5cLzNxNRebAoM=; b=Nz1yVuxwKLpmDi1bxL3f1Or7nYolRsU53tcR2Pf0eF9R4BU+SyVAt1pUThu/Vo7g9K yfFDZYda/LW9BWAYJOsGE1djrfHarK++4CIfpOVVq8+E48wtEN68tu4ojPYCgdE1Jy+4 Zvldmy5aDT3mYCSP68vlirkZbnBkusUN0dsNI0ieE+8q2dgodfKotkHwvCaOmnoAep43 /IohPEmCm+4+tvvsW3lLKpPfIJVJqqCC/gUGYAoMQnpGUK59+1/tW3u1Qd9FRHkvd2Vs gwkWD42UfMzQYjZ/KNrLFAJrhtaxjY8pWEwEcYNoITqHg/0Vk5rRMvn77GXElozd1r6V GJ+A== X-Gm-Message-State: APjAAAU2XJ0JX4m8HWppInRFkMR5z6uPtirQejUHzwz7Dxjh984RfI/S hec9nNgWXiXv5Ui43A057CdFmB4H X-Google-Smtp-Source: APXvYqxATEk3+xGAczX3Z7jTzz02gYxLhQ7bHBMXo/sY65zNfFdrZ7ZtvSUVfKeoRRNf4I20qenNIg== X-Received: by 2002:a2e:5bc9:: with SMTP id m70mr6141436lje.159.1551548937620; Sat, 02 Mar 2019 09:48:57 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 13sm340752lju.27.2019.03.02.09.48.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Mar 2019 09:48:56 -0800 (PST) Subject: Re: 12.0-RELEASE zfs/vnode deadlock issue To: Nick Rogers , FreeBSD STABLE References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <233f3723-a78e-91db-ebe6-9e13c1c9b50d@FreeBSD.org> Date: Sat, 2 Mar 2019 19:48:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2D92E722E9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-4.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.78)[-0.784,0]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; IP_SCORE(-1.28)[ip: (-0.45), ipnet: 209.85.128.0/17(-3.83), asn: 15169(-2.04), country: US(-0.07)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[178.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 17:57:05 -0000 On 01/03/2019 17:00, Nick Rogers wrote: > 36704 101146 perl - mi_switch+0xe1 > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c VOP_LOCK1_APV+0x7e > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d > zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cred+0x2c9 > kern_openat+0x20c amd64_syscall+0x369 fast_syscall_common+0x101 I suspect that this thread is a root cause of the problem. In this place, the vnode should be freshly created and not visible to anything but the current thread. So, vn_lock() should always immediately succeed. I cannot understand how the vnode lock could be held by another thread. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Sat Mar 2 22:16:41 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 446EF1512CA0 for ; Sat, 2 Mar 2019 22:16:41 +0000 (UTC) (envelope-from peter@theshell.com) Received: from cs.theshell.com (cs.theshell.com [162.213.38.101]) (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 8925886F85 for ; Sat, 2 Mar 2019 22:16:30 +0000 (UTC) (envelope-from peter@theshell.com) Received: from [69.4.151.27] (helo=[192.168.13.201]) by cs.theshell.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1h0Cvd-000NSu-NF for freebsd-stable@freebsd.org; Sat, 02 Mar 2019 14:16:21 -0800 From: Peter Avalos Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: 12.0-RELEASE zfs/vnode deadlock issue Date: Sat, 2 Mar 2019 14:16:20 -0800 References: To: FreeBSD STABLE In-Reply-To: Message-Id: <43FE13F0-FCC6-40C9-81DA-B1A38024E433@theshell.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 8925886F85 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MX_INVALID(0.50)[greylisted]; R_SPF_ALLOW(-0.20)[+ip4:162.213.38.101]; MV_CASE(0.50)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[theshell.com:+]; RCVD_IN_DNSWL_MED(-0.20)[101.38.213.162.list.dnswl.org : 127.0.4.2]; DMARC_POLICY_ALLOW(-0.50)[theshell.com,reject]; RECEIVED_SPAMHAUS_PBL(0.00)[27.151.4.69.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50837, ipnet:162.213.38.0/24, country:CH]; IP_SCORE(0.01)[country: CH(0.03)]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.26)[-0.265,0]; R_DKIM_ALLOW(-0.20)[theshell.com:s=cs]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(0.00)[theshell.com.dwl.dnswl.org : 127.0.4.2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.989,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.32)[0.318,0]; RCPT_COUNT_ONE(0.00)[1]; RBL_COMPOSITE_RCVD_IN_DNSWL_MED_DWL_DNSWL_MED(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 22:16:41 -0000 > On Mar 1, 2019, at 7:00 AM, Nick Rogers wrote: >=20 > I am hoping someone can help me figure out if this is a legitimate = bug, or > something already fixed in 12-STABLE. I wish I could reproduce it = reliably > to try against STABLE, but there doesn't appear to be any related ZFS = fixes > not in RELEASE. Thanks. >=20 I have also experienced this problem, but I haven=E2=80=99t been able to = troubleshoot it at all. Peter=