From owner-freebsd-stable@freebsd.org Sun Jul 21 21:42:02 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3A2FBFAD1 for ; Sun, 21 Jul 2019 21:42:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D54176DBEF for ; Sun, 21 Jul 2019 21:42:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-yw1-xc33.google.com with SMTP id f187so15210849ywa.5 for ; Sun, 21 Jul 2019 14:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eUzuW6P1M/TilvdbZuQsINtqvmZOK04Kre9iGOg4bDI=; b=qIqiu0LKSlnlnjaALCIFNycTjjidzXNvMf+sF25bjX8dGmYjT8mU58INf9tgvfCFx7 YjLcuRf2aS5G39sEGOrDslcfNCc08n6IhS9J/IH8kBSXNSSP+UyakNizjRpaPiQEJYfC +msMdvQOav/FJsPdwwoeVW9nxjmNe06SvUC7rbI+JFKfGNaLRHMgLxfvPYfBAdN4gVsv y0Rvwj4ZDWeyTCObGFJpwfG7y1j8qIxzbgSkxy3/Tmcm2Kceed1rdGO2464ulotMynFz Ag0W2W1jLBGED0nNPtO8ZFfbYeH8ApAUI0DbOZy9GMMqaSpGtT4F1+skCEVVD0iIh+vh loYg== 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:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=eUzuW6P1M/TilvdbZuQsINtqvmZOK04Kre9iGOg4bDI=; b=U0KUzMj/QSd7ISY6OyiSagYR8qqPGhtacAkEWy9iBkiNKHsD+WpN5GoxcdZOa4Zkjh 5nLfsIl9N94gkcULEcsmUPQD8N4yvxnhPHCd0Xx3TJQoYVLhXcqW6b83bKZPPeMPO+Ra bsqK4hNQKGRma3aKLzZXJBnQyj3Qr0mjq+SG/t0mJeBgHgitHiKn+gETEZnrS9f49nfT 6oiHr78Uf+rB5xgU0YvURg8hLTbRkL8gKD5RhoE8o+7lp9/dVgmZaxjmL9DNZiO510Pc o536h4Q18epbcdRg71oQ9XRoB/TplPgz34lIlIZUIHwfyTC1z5FYqu4zLbFNe7J1CH3N FNpg== X-Gm-Message-State: APjAAAVnpBMJB6wfsmQT+RUhpa97JDL0M6uCa2tW5Oum3NULdN9lIn/6 KVRjo9teFAd391u7Po12+zNn6NBy X-Google-Smtp-Source: APXvYqxusB90MnJKY52hjuyWjWhpLCoIQjgBSfq9CYNbUJOL4wxw7+qJSaad/PgxdM3RwdrIzWGyYw== X-Received: by 2002:a0d:d795:: with SMTP id z143mr39357589ywd.305.1563745320670; Sun, 21 Jul 2019 14:42:00 -0700 (PDT) Received: from spectre.mavhome.dp.ua ([2600:1700:3580:3560:228:f8ff:fe04:d12]) by smtp.gmail.com with ESMTPSA id u123sm9279413ywu.75.2019.07.21.14.41.59 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 14:41:59 -0700 (PDT) Sender: Alexander Motin Subject: Re: ZFS root mount regression To: Eugene Grosbein , Garrett Wollman , freebsd-stable@freebsd.org References: <23858.2573.932364.128957@khavrinen.csail.mit.edu> <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> From: Alexander Motin Openpgp: preference=signencrypt Autocrypt: addr=mav@FreeBSD.org; prefer-encrypt=mutual; keydata= mQENBFOzxAwBCADkPrax0pI2W/ig0CK9nRJJwsHitAGEZ2HZiFEuti+6/4UVxj81yr4ak/4g 9bKUyC7rMEAp/ZHNhd+MFCPAAcHPvtovnfykqE/vuosCS3wlSLloix2iKVLks0CwbLHGAyne 46lTQW74Xl/33c3W1Z6d8jD9gVFT/xaVzZ0U9xdzOmsYAZaAj4ki0tuxO9F7L+ct9grRe7iP g8t9hai7BL4ee3VRwk2JXnKb7UvBiVITKYWKz1jRvZIrjPokgEcCLOSlv7x/1kjuFnj3xWZU 7HSFFT8J93epBbrSSCsYsppIk2fZH41kaaFXsMQfTPH8wkeM6qwrvOh4HiQM08R+9tThABEB AAG0IUFsZXhhbmRlciBNb3RpbiA8bWF2QEZyZWVCU0Qub3JnPokBVwQTAQoAQQIbAwULCQgH AwUVCgkICwUWAwIBAAIeAQIXgAIZARYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMKuBQkN McyiAAoJEIMYw5VbqyJ/tuUIAOG3ONOSNYqjK4eTZ1TVh9jdUBAhWk5nhDFnODN49Wj0AbYm 7aIqy8O1hnCDSZG5LttjSAo3UfXJZDKQM0BLb0gpRMBnAYqO6tdolLNqAbPGJBnGoPjsh24y 6KcbDaNnis+lD4GwPXwQM+92wZGhCUFElPV9NciZGVS65TNIgk7X+yEjjhD1MSWKKijZ1r9Z zIt4OzUTxxNOvzdlABZS88nNRdJkatOQJPmFdd1mpP6UzTNCiLUo1pIqOEtJgvVVDYq5WHY6 tciWWYdmZG/tIBexJmv2mV2OLVjXR6ZeKmntVH14H72/wRHJuYHQC+r5SVRcWWayrThsY6jZ Yr4+raS5AQ0EU7PEDAEIAOZgWf2cJIu+58IzP2dkXE/urj3tr4OqrB/yHGWUf71Lz6D0Fi6Z AXgDtmcFLGPfMyWuLAvSM+xmoguk7zC4hRBYvQycmIhuqBq1jO1Wp/Z+lpoPM/1cDYLn8Flv mI/c40MhUZh345DA4jYWWaZNjQHUWVQ1fPf595vdVVMPT/abE8E5DaF6fSkRmqFTmfYRkfbt 3ytU8NdUapDcJVY7cEP2nJBVNZPnOIObR/ZIgSxjjrG5o34yXoqeup8JvwEv+/NylzzuyXEZ R1EdEIzQ/a1nh/0j4NXtzZEqKW4aTWlmSqb6wN8jh1OSOOqkYsfnE3nfxcZbxi4IRoNQYlm5 9R8AEQEAAYkBPAQYAQoAJgIbDBYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMLYBQkNMczM AAoJEIMYw5VbqyJ/TqgH/RQHClkvecE0262lwKoP/m0Mh4I5TLRgoJJn8S7G1BnqohYJkiLq A6xe6urGD7OqdNAl12UbrjWbdJV+zvea3vJoM4MZuYiYrGaXWxzFXqWJcPwMU9sAh8MRghHu uC5vgPb45Tnftw9/+n0i8GfVhQhOqepUGdQg4NPcXviSkoAvig6pp9Lcxisn0groUQKt15Gc sS9YcQWg3j9Hnipc6Mu416HX98Fb113NHJqc2geTHLkRyuBFOoyIqB6N9GKjzOAIzxxsVdl9 TevwGsrp4M4/RFzWbSgsbOnbE7454lmuVZGfReEjnUm8RHp9Q2UWKXlp3exlZjvOp/uVEpCg lz65AQ0EU7PEDAEIAOZgWf2cJIu+58IzP2dkXE/urj3tr4OqrB/yHGWUf71Lz6D0Fi6ZAXgD tmcFLGPfMyWuLAvSM+xmoguk7zC4hRBYvQycmIhuqBq1jO1Wp/Z+lpoPM/1cDYLn8FlvmI/c 40MhUZh345DA4jYWWaZNjQHUWVQ1fPf595vdVVMPT/abE8E5DaF6fSkRmqFTmfYRkfbt3ytU 8NdUapDcJVY7cEP2nJBVNZPnOIObR/ZIgSxjjrG5o34yXoqeup8JvwEv+/NylzzuyXEZR1Ed EIzQ/a1nh/0j4NXtzZEqKW4aTWlmSqb6wN8jh1OSOOqkYsfnE3nfxcZbxi4IRoNQYlm59R8A EQEAAYkBPAQYAQoAJgIbDBYhBOmM88TmnMPNDledVYMYw5VbqyJ/BQJZYMLYBQkNMczMAAoJ EIMYw5VbqyJ/TqgH/RQHClkvecE0262lwKoP/m0Mh4I5TLRgoJJn8S7G1BnqohYJkiLqA6xe 6urGD7OqdNAl12UbrjWbdJV+zvea3vJoM4MZuYiYrGaXWxzFXqWJcPwMU9sAh8MRghHuuC5v gPb45Tnftw9/+n0i8GfVhQhOqepUGdQg4NPcXviSkoAvig6pp9Lcxisn0groUQKt15GcsS9Y cQWg3j9Hnipc6Mu416HX98Fb113NHJqc2geTHLkRyuBFOoyIqB6N9GKjzOAIzxxsVdl9Tevw Gsrp4M4/RFzWbSgsbOnbE7454lmuVZGfReEjnUm8RHp9Q2UWKXlp3exlZjvOp/uVEpCglz4= Message-ID: <841d26dd-7433-2e6d-9011-76ed7ad3d5d2@FreeBSD.org> Date: Sun, 21 Jul 2019 17:41:59 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D54176DBEF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qIqiu0LK; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::c33 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-6.05 / 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:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.92)[-0.918,0]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; IP_SCORE(-2.92)[ip: (-9.01), ipnet: 2607:f8b0::/32(-3.11), asn: 15169(-2.42), country: US(-0.05)]; 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)[mav@FreeBSD.org,mavbsd@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)[]; RCPT_COUNT_THREE(0.00)[3]; 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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.3.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]; 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: Sun, 21 Jul 2019 21:42:02 -0000 Hi, I am not sure how the original description leads to conclusion that problem is related to parallel mounting. From my point of view it sounds like a problem that root pool mounting happens based on name, not pool GUID that needs to be passed from the loader. We have seen problem like that ourselves too when boot pool names collide. So I doubt it is a new problem, just nobody got to fixing it yet. On 20.07.2019 06:41, Eugene Grosbein wrote: > CC'ing Alexander Motin who comitted the change. > > 20.07.2019 1:21, Garrett Wollman wrote: > >> I recently upgraded several file servers from 11.2 to 11.3. All of >> them boot from a ZFS pool called "tank" (the data is in a different >> pool). In a couple of instances (which caused me to have to take a >> late-evening 140-mile drive to the remote data center where they are >> located), the servers crashed at the root mount phase. In one case, >> it bailed out with error 5 (I believe that's [EIO]) to the usual >> mountroot prompt. In the second case, the kernel panicked instead. >> >> The root cause (no pun intended) on both servers was a disk which was >> supplied by the vendor with a label on it that claimed to be part of >> the "tank" pool, and for some reason the 11.3 kernel was trying to >> mount that (faulted) pool rather than the real one. The disks and >> pool configuration were unchanged from 11.2 (and probably 11.1 as >> well) so I am puzzled. >> >> Other than laboriously running "zpool labelclear -f /dev/somedisk" for >> every piece of media that comes into my hands, is there anything else >> I could have done to avoid this? > > Both 11.3-RELEASE announcement and Release Notes mention this: > >> The ZFS filesystem has been updated to implement parallel mounting. > > I strongly suggest reading Release documentation in case of troubles > after upgrade, at least. Or better, read *before* updating. > > I guess this parallelism created some race for your case. > > Unfortunately, a way to fall back to sequential mounting seems undocumented. > libzfs checks for ZFS_SERIAL_MOUNT environment variable to exist having any value. > I'm not sure how you set it for mounting root, maybe it will use kenv, > so try adding to /boot/loader.conf: > > ZFS_SERIAL_MOUNT=1 > > Alexander should have more knowledge on this. > > And of course, attaching unrelated device having label conflicting > with root pool is asking for trouble. Re-label it ASAP. > -- Alexander Motin From owner-freebsd-stable@freebsd.org Mon Jul 22 00:43:05 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 00D83A398D for ; Mon, 22 Jul 2019 00:43:04 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 8369371722; Mon, 22 Jul 2019 00:43:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-96-116.dz.commufa.jp [124.18.96.116]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id x6M0B7Zx060852; Mon, 22 Jul 2019 09:11:07 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 22 Jul 2019 09:11:07 +0900 From: Tomoaki AOKI To: freebsd-stable@freebsd.org Cc: wollman@csail.mit.edu, trond.endrestol@ximalas.info, eugen@grosbein.net, mav@FreeBSD.org Subject: Re: ZFS root mount regression Message-Id: <20190722091107.910eed56a32e2fde506c013f@dec.sakura.ne.jp> In-Reply-To: <841d26dd-7433-2e6d-9011-76ed7ad3d5d2@FreeBSD.org> References: <23858.2573.932364.128957@khavrinen.csail.mit.edu> <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> <841d26dd-7433-2e6d-9011-76ed7ad3d5d2@FreeBSD.org> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8369371722 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; MX_GOOD(-0.01)[dec.sakura.ne.jp]; RECEIVED_SPAMHAUS_PBL(0.00)[116.96.18.124.zen.spamhaus.org : 127.0.0.10]; IP_SCORE(1.33)[ipnet: 210.188.224.0/19(4.86), asn: 9370(1.83), country: JP(-0.04)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.989,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(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, 22 Jul 2019 00:43:05 -0000 Hi. Maybe different problem (as mav@ noted) with Garrett's but related to parallel-mounting. *For Garrett's problem, +1 with Trond. For myself, I incorporate drive type and No. in pool name to avoid collision between 2 physical drives (one working, and one emergency) in the same host. After ZFS parallel mounting is committed (both head and stable/12), auto-mounting from manually-imported non-root pool(s) looks racy and usually fails (some datasets are shown as mounted, but not accessible until manual unmount/remount is proceeded). *I'm experiencing the problem when I import another root pool by `zpool import -R /mnt -f poolname`. Patch from ZoL on bug 237517 [1] seems to fix the parallel mounting race. (Named ZoL fix by fullermd.) As it seemed to be race condition, I'm not 100% shure the patch is really correct. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237517 On Sun, 21 Jul 2019 17:41:59 -0400 Alexander Motin wrote: > Hi, > > I am not sure how the original description leads to conclusion that > problem is related to parallel mounting. From my point of view it > sounds like a problem that root pool mounting happens based on name, not > pool GUID that needs to be passed from the loader. We have seen problem > like that ourselves too when boot pool names collide. So I doubt it is > a new problem, just nobody got to fixing it yet. > > On 20.07.2019 06:41, Eugene Grosbein wrote: > > CC'ing Alexander Motin who comitted the change. > > > > 20.07.2019 1:21, Garrett Wollman wrote: > > > >> I recently upgraded several file servers from 11.2 to 11.3. All of > >> them boot from a ZFS pool called "tank" (the data is in a different > >> pool). In a couple of instances (which caused me to have to take a > >> late-evening 140-mile drive to the remote data center where they are > >> located), the servers crashed at the root mount phase. In one case, > >> it bailed out with error 5 (I believe that's [EIO]) to the usual > >> mountroot prompt. In the second case, the kernel panicked instead. > >> > >> The root cause (no pun intended) on both servers was a disk which was > >> supplied by the vendor with a label on it that claimed to be part of > >> the "tank" pool, and for some reason the 11.3 kernel was trying to > >> mount that (faulted) pool rather than the real one. The disks and > >> pool configuration were unchanged from 11.2 (and probably 11.1 as > >> well) so I am puzzled. > >> > >> Other than laboriously running "zpool labelclear -f /dev/somedisk" for > >> every piece of media that comes into my hands, is there anything else > >> I could have done to avoid this? > > > > Both 11.3-RELEASE announcement and Release Notes mention this: > > > >> The ZFS filesystem has been updated to implement parallel mounting. > > > > I strongly suggest reading Release documentation in case of troubles > > after upgrade, at least. Or better, read *before* updating. > > > > I guess this parallelism created some race for your case. > > > > Unfortunately, a way to fall back to sequential mounting seems undocumented. > > libzfs checks for ZFS_SERIAL_MOUNT environment variable to exist having any value. > > I'm not sure how you set it for mounting root, maybe it will use kenv, > > so try adding to /boot/loader.conf: > > > > ZFS_SERIAL_MOUNT=1 > > > > Alexander should have more knowledge on this. > > > > And of course, attaching unrelated device having label conflicting > > with root pool is asking for trouble. Re-label it ASAP. > > > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Tomoaki AOKI From owner-freebsd-stable@freebsd.org Mon Jul 22 17:29:10 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 953BCB700E for ; Mon, 22 Jul 2019 17:29:10 +0000 (UTC) (envelope-from www-data@hwsrv-536422.hostwindsdns.com) Received: from hwsrv-536422.hostwindsdns.com (hwsrv-536422.hostwindsdns.com [IPv6:2607:5500:3000:1e19::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5995581586 for ; Mon, 22 Jul 2019 17:29:10 +0000 (UTC) (envelope-from www-data@hwsrv-536422.hostwindsdns.com) Received: by hwsrv-536422.hostwindsdns.com (Postfix, from userid 33) id 571E025DEA; Mon, 22 Jul 2019 17:25:14 +0000 (UTC) To: freebsd-stable@freebsd.org Subject: Prezado(a) Cliente: Pessoa Juridica Itaú X-PHP-Originating-Script: 0:1a.php From: freebsd-hackers X-Mailer: Microsoft Office Outlook, Build 17.551210 Message-Id: <20190722172514.571E025DEA@hwsrv-536422.hostwindsdns.com> Date: Mon, 22 Jul 2019 17:25:14 +0000 (UTC) X-Rspamd-Queue-Id: 5995581586 X-Spamd-Bar: +++++++++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [11.13 / 15.00]; ENVFROM_SERVICE_ACCT(1.00)[]; HAS_X_POS(0.00)[]; TO_DN_NONE(0.00)[]; MX_GOOD(-0.01)[cached: hwsrv-536422.hostwindsdns.com]; HFILTER_HELO_2(1.00)[hwsrv-536422.hostwindsdns.com]; FORGED_SENDER(0.30)[freebsd-hackers@freebsd.org,www-data@hwsrv-536422.hostwindsdns.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; IP_SCORE(1.15)[ipnet: 2607:5500::/32(3.21), asn: 54290(2.58), country: US(-0.05)]; PHISHING(1.39)[itau.com.br->storage.googleapis.com]; ASN(0.00)[asn:54290, ipnet:2607:5500::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@freebsd.org,www-data@hwsrv-536422.hostwindsdns.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997,0]; SUBJECT_NEEDS_ENCODING(1.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; RCPT_COUNT_ONE(0.00)[1]; PHP_SCRIPT_ROOT(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; MIME_HTML_ONLY(0.20)[]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: Mon, 22 Jul 2019 17:29:10 -0000 From owner-freebsd-stable@freebsd.org Mon Jul 22 21:26:01 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 58D0CBC8A6 for ; Mon, 22 Jul 2019 21:26:01 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2603:400a:0:7ec::801e:1c14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27FBE8C0D0; Mon, 22 Jul 2019 21:26:00 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.15.2/8.15.2) with ESMTPS id x6MLPxva070394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 22 Jul 2019 17:25:59 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.15.2/8.15.2/Submit) id x6MLPwQh070393; Mon, 22 Jul 2019 17:25:58 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23862.10726.330488.746920@khavrinen.csail.mit.edu> Date: Mon, 22 Jul 2019 17:25:58 -0400 From: Garrett Wollman To: Eugene Grosbein Cc: freebsd-stable@freebsd.org, Alexander Motin Subject: Re: ZFS root mount regression In-Reply-To: <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> References: <23858.2573.932364.128957@khavrinen.csail.mit.edu> <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd11.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (khavrinen.csail.mit.edu [127.0.0.1]); Mon, 22 Jul 2019 17:25:59 -0400 (EDT) X-Rspamd-Queue-Id: 27FBE8C0D0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dmarc=pass (policy=none) header.from=csail.mit.edu; spf=pass (mx1.freebsd.org: domain of wollman@khavrinen.csail.mit.edu designates 2603:400a:0:7ec::801e:1c14 as permitted sender) smtp.mailfrom=wollman@khavrinen.csail.mit.edu X-Spamd-Result: default: False [-1.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.931,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.540,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[khavrinen.csail.mit.edu,incoming.csail.mit.edu]; DMARC_POLICY_ALLOW(-0.50)[csail.mit.edu,none]; IP_SCORE(-0.00)[asn: 3(0.03), country: US(-0.05)]; FORGED_SENDER(0.30)[wollman@csail.mit.edu,wollman@khavrinen.csail.mit.edu]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:2603:400a::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[wollman@csail.mit.edu, wollman@khavrinen.csail.mit.edu] 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, 22 Jul 2019 21:26:01 -0000 < said: > Both 11.3-RELEASE announcement and Release Notes mention this: >> The ZFS filesystem has been updated to implement parallel mounting. > I strongly suggest reading Release documentation in case of troubles > after upgrade, at least. Or better, read *before* updating. Two servers breaking out of thirty-five upgraded is not the sort of thing that you'd expect to be implied by such a statement, especially when there's only one filesystem being mounted at the relevant time. -GAWollman From owner-freebsd-stable@freebsd.org Mon Jul 22 21:37:02 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A108BCCA2 for ; Mon, 22 Jul 2019 21:37:02 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2603:400a:0:7ec::801e:1c14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B402B8C6AB; Mon, 22 Jul 2019 21:37:01 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.15.2/8.15.2) with ESMTPS id x6MLb10d070854 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 22 Jul 2019 17:37:01 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.15.2/8.15.2/Submit) id x6MLb1DX070853; Mon, 22 Jul 2019 17:37:01 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23862.11389.182649.480381@khavrinen.csail.mit.edu> Date: Mon, 22 Jul 2019 17:37:01 -0400 From: Garrett Wollman To: Alexander Motin Cc: Eugene Grosbein , freebsd-stable@freebsd.org Subject: Re: ZFS root mount regression In-Reply-To: <841d26dd-7433-2e6d-9011-76ed7ad3d5d2@FreeBSD.org> References: <23858.2573.932364.128957@khavrinen.csail.mit.edu> <73cddcd9-97f0-e73f-da9d-2a454fd3ea1a@grosbein.net> <841d26dd-7433-2e6d-9011-76ed7ad3d5d2@FreeBSD.org> X-Mailer: VM 8.2.0b under 26.2 (amd64-portbld-freebsd11.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (khavrinen.csail.mit.edu [127.0.0.1]); Mon, 22 Jul 2019 17:37:01 -0400 (EDT) X-Rspamd-Queue-Id: B402B8C6AB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dmarc=pass (policy=none) header.from=csail.mit.edu; spf=pass (mx1.freebsd.org: domain of wollman@khavrinen.csail.mit.edu designates 2603:400a:0:7ec::801e:1c14 as permitted sender) smtp.mailfrom=wollman@khavrinen.csail.mit.edu X-Spamd-Result: default: False [-1.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.920,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; NEURAL_SPAM_SHORT(0.84)[0.839,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: khavrinen.csail.mit.edu]; DMARC_POLICY_ALLOW(-0.50)[csail.mit.edu,none]; IP_SCORE(-0.00)[asn: 3(0.03), country: US(-0.05)]; FORGED_SENDER(0.30)[wollman@csail.mit.edu,wollman@khavrinen.csail.mit.edu]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:2603:400a::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[wollman@csail.mit.edu, wollman@khavrinen.csail.mit.edu] 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, 22 Jul 2019 21:37:02 -0000 < said: > I am not sure how the original description leads to conclusion that > problem is related to parallel mounting. From my point of view it > sounds like a problem that root pool mounting happens based on name, not > pool GUID that needs to be passed from the loader. We have seen problem > like that ourselves too when boot pool names collide. So I doubt it is > a new problem, just nobody got to fixing it yet. This seems plausible, except that something clearly did change to result in these servers finding the correct root pool under 11.2 and finding the wrong one under 11.3. Can't say what it might be; there's nothing in UPDATING that would imply a change. (I've also seen some evidence that the parallel mounting is problematic and I'll have to figure out how to disable that.) -GAWollman From owner-freebsd-stable@freebsd.org Tue Jul 23 04:34:27 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A42EC4EEA for ; Tue, 23 Jul 2019 04:34:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 2505D74F0B for ; Tue, 23 Jul 2019 04:34:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 249A5C4EE9; Tue, 23 Jul 2019 04:34:27 +0000 (UTC) Delivered-To: stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 245DFC4EE8 for ; Tue, 23 Jul 2019 04:34:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0494074F08 for ; Tue, 23 Jul 2019 04:34:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BC30C203E9 for ; Tue, 23 Jul 2019 04:34:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6N4YQWB008839 for ; Tue, 23 Jul 2019 04:34:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6N4YQn7008838 for stable@FreeBSD.org; Tue, 23 Jul 2019 04:34:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 228536] x11/nvidia-driver: 11.2-BETA3 - fails to operate correctly Date: Tue, 23 Jul 2019 04:34:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: omarandemad@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 2505D74F0B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; 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: Tue, 23 Jul 2019 04:34:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228536 zain david changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |omarandemad@gmail.com --- Comment #14 from zain david --- great work. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed Jul 24 12:47:53 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE913A715A for ; Wed, 24 Jul 2019 12:47:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83629807B3; Wed, 24 Jul 2019 12:47:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544] ([IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x6OClf97067006 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2019 08:47:42 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) To: Dimitry Andric References: <201907231840.x6NIeWeq024894@repo.freebsd.org> From: mike tancsa Cc: freebsd-stable@freebsd.org Message-ID: Date: Wed, 24 Jul 2019 08:47:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <201907231840.x6NIeWeq024894@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 83629807B3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.80 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.66)[-0.658,0]; LONG_SUBJ(1.70)[227]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.58), country: CA(-0.09)]; MX_GOOD(-0.01)[smtp.sentex.ca]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.74)[-0.740,0]; NEURAL_HAM_MEDIUM(-0.97)[-0.970,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; 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: Wed, 24 Jul 2019 12:47:54 -0000 On 7/23/2019 2:40 PM, Dimitry Andric wrote: > Author: dim > Date: Tue Jul 23 18:40:32 2019 > New Revision: 350256 > URL: https://svnweb.freebsd.org/changeset/base/350256 > Hi,     Not sure if this is just a difference in the versions or more things are being compiled, but I noticed a buildworld on my Ryzen went from ~ 31min to just over 40min.   Is this expected ?     ---Mike ps. Thanks for all the work you put in to keeping clang up to date btw!! From owner-freebsd-stable@freebsd.org Wed Jul 24 13:45:53 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1DB8A8726 for ; Wed, 24 Jul 2019 13:45:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71938835DA; Wed, 24 Jul 2019 13:45:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 431432C463; Wed, 24 Jul 2019 13:45:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.43.233] (unknown [92.69.47.175]) (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 DEDA13F6B3; Wed, 24 Jul 2019 15:45:51 +0200 (CEST) From: Dimitry Andric Message-Id: <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_46860C6C-CD6F-4D1C-9C3E-FB278E79C9EC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) Date: Wed, 24 Jul 2019 15:45:44 +0200 In-Reply-To: Cc: freebsd-stable@freebsd.org To: mike tancsa References: <201907231840.x6NIeWeq024894@repo.freebsd.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 71938835DA X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; 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: Wed, 24 Jul 2019 13:45:53 -0000 --Apple-Mail=_46860C6C-CD6F-4D1C-9C3E-FB278E79C9EC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Jul 2019, at 14:47, mike tancsa wrote: > > On 7/23/2019 2:40 PM, Dimitry Andric wrote: >> Author: dim >> Date: Tue Jul 23 18:40:32 2019 >> New Revision: 350256 >> URL: https://svnweb.freebsd.org/changeset/base/350256 >> > Hi, > > Not sure if this is just a difference in the versions or more things > are being compiled, but I noticed a buildworld on my Ryzen went from ~ > 31min to just over 40min. Is this expected ? Most likely this is because it will now build a bootstrap compiler, whereas previously your system may have skipped this step. Can you compare the results when setting MK_SYSTEM_COMPILER=no and MK_SYSTEM_LINKER=no ? -Dimitry --Apple-Mail=_46860C6C-CD6F-4D1C-9C3E-FB278E79C9EC 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXThhCAAKCRCwXqMKLiCW o1dQAJ91zWF9v5vlKjOlTbqzXjuewwBu+gCg8lB7njtYjq1NKVazG0pndEhdXFY= =JtFK -----END PGP SIGNATURE----- --Apple-Mail=_46860C6C-CD6F-4D1C-9C3E-FB278E79C9EC-- From owner-freebsd-stable@freebsd.org Wed Jul 24 15:12:39 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 56446AF53B for ; Wed, 24 Jul 2019 15:12:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A40288ABAA; Wed, 24 Jul 2019 15:12:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544] ([IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x6OFCZin076263 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2019 11:12:37 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) To: Dimitry Andric Cc: freebsd-stable@freebsd.org References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> From: mike tancsa Message-ID: Date: Wed, 24 Jul 2019 11:12:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: A40288ABAA X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.62 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.64)[-0.643,0]; LONG_SUBJ(1.70)[227]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.58), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: smtp.sentex.ca]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.927,0]; NEURAL_HAM_MEDIUM(-0.99)[-0.986,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; 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: Wed, 24 Jul 2019 15:12:39 -0000 On 7/24/2019 9:45 AM, Dimitry Andric wrote: > On 24 Jul 2019, at 14:47, mike tancsa wrote: >> On 7/23/2019 2:40 PM, Dimitry Andric wrote: >>> Author: dim >>> Date: Tue Jul 23 18:40:32 2019 >>> New Revision: 350256 >>> URL: https://svnweb.freebsd.org/changeset/base/350256 >>> >> Hi, >> >> Not sure if this is just a difference in the versions or more things >> are being compiled, but I noticed a buildworld on my Ryzen went from ~ >> 31min to just over 40min. Is this expected ? > Most likely this is because it will now build a bootstrap compiler, > whereas previously your system may have skipped this step. Can you > compare the results when setting MK_SYSTEM_COMPILER=no and > MK_SYSTEM_LINKER=no ? Adding those two to src.conf and make.conf still shows 40min  time make -j14 buildworld > /var/log/build.out ; time make -j14 buildkernel > /var/log/build.out. [Creating objdir /usr/obj/usr/src/amd64.amd64...] 25312.621u 1237.984s 40:09.72 1101.8%   45579+3473k 656666+3288880io 214633pf+0w 1675.467u 173.497s 2:37.90 1170.9%      37728+3167k 207118+3329460io 61829pf+0w Should I be setting these vars somewhere else ?     ---Mike From owner-freebsd-stable@freebsd.org Wed Jul 24 16:08:11 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CED7B0AF6 for ; Wed, 24 Jul 2019 16:08:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E1BE8C4F4; Wed, 24 Jul 2019 16:08:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id E7F3B2D4D3; Wed, 24 Jul 2019 16:08:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::e5f9:9d28:2d74:eb2] (unknown [IPv6:2001:470:7a58:0:e5f9:9d28:2d74:eb2]) (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 C8EBF3F6C9; Wed, 24 Jul 2019 18:08:09 +0200 (CEST) From: Dimitry Andric Message-Id: <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E93DF405-33A0-4C2C-8A25-F819BDCDB244"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) Date: Wed, 24 Jul 2019 18:02:09 +0200 In-Reply-To: Cc: freebsd-stable@freebsd.org To: mike tancsa References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 4E1BE8C4F4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] 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, 24 Jul 2019 16:08:11 -0000 --Apple-Mail=_E93DF405-33A0-4C2C-8A25-F819BDCDB244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Jul 2019, at 17:12, mike tancsa wrote: >=20 > On 7/24/2019 9:45 AM, Dimitry Andric wrote: >> On 24 Jul 2019, at 14:47, mike tancsa wrote: >>> On 7/23/2019 2:40 PM, Dimitry Andric wrote: >>>> Author: dim >>>> Date: Tue Jul 23 18:40:32 2019 >>>> New Revision: 350256 >>>> URL: https://svnweb.freebsd.org/changeset/base/350256 >>>>=20 >>> Hi, >>>=20 >>> Not sure if this is just a difference in the versions or more = things >>> are being compiled, but I noticed a buildworld on my Ryzen went from = ~ >>> 31min to just over 40min. Is this expected ? >> Most likely this is because it will now build a bootstrap compiler, >> whereas previously your system may have skipped this step. Can you >> compare the results when setting MK_SYSTEM_COMPILER=3Dno and >> MK_SYSTEM_LINKER=3Dno ? >=20 > Adding those two to src.conf and make.conf still shows 40min >=20 > time make -j14 buildworld > /var/log/build.out ; time make -j14 > buildkernel > /var/log/build.out. > [Creating objdir /usr/obj/usr/src/amd64.amd64...] > 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 656666+3288880io > 214633pf+0w > 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io > 61829pf+0w >=20 > Should I be setting these vars somewhere else ? Ah, setting them in src.conf, make.conf or the environment will be overridden from Makefile.inc1, unfortunately. It will then show something like: make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: = SYSTEM_COMPILER: libclang will be built for bootstrapping a = cross-compiler. make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: = SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. E.g, it detects that your system compiler is of a lower version than the compiler in the source tree, and will thus bootstrap the latter. Can you compare the timings when setting MK_SYSTEM_COMPILER=3Dyes and MK_SYSTEM_LINKER=3Dyes? In that case, both before and after r350256, = the results should be fairly similar, I expect. -Dimitry --Apple-Mail=_E93DF405-33A0-4C2C-8A25-F819BDCDB244 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXTiBAQAKCRCwXqMKLiCW o6TnAKDQ3CA6qhEP/aLmJ6NQBVWSFxcpOgCgzWxInDBtyiTbCL59yGOv4gJUvN8= =gPwH -----END PGP SIGNATURE----- --Apple-Mail=_E93DF405-33A0-4C2C-8A25-F819BDCDB244-- From owner-freebsd-stable@freebsd.org Wed Jul 24 17:21:37 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0EB4AB29C9 for ; Wed, 24 Jul 2019 17:21:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5A9E8FDBC; Wed, 24 Jul 2019 17:21:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544] ([IPv6:2607:f3e0:0:4:4d5a:b467:255f:a544]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x6OHLXHM084755 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2019 13:21:35 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) To: Dimitry Andric Cc: freebsd-stable@freebsd.org References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> From: mike tancsa Message-ID: Date: Wed, 24 Jul 2019 13:21:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: E5A9E8FDBC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.59 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.61)[-0.613,0]; LONG_SUBJ(1.70)[227]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.58), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: smtp.sentex.ca]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; 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: Wed, 24 Jul 2019 17:21:37 -0000 On 7/24/2019 12:02 PM, Dimitry Andric wrote: > On 24 Jul 2019, at 17:12, mike tancsa wrote: >> On 7/24/2019 9:45 AM, Dimitry Andric wrote: >>> On 24 Jul 2019, at 14:47, mike tancsa wrote: >>>> On 7/23/2019 2:40 PM, Dimitry Andric wrote: >>>>> Author: dim >>>>> Date: Tue Jul 23 18:40:32 2019 >>>>> New Revision: 350256 >>>>> URL: https://svnweb.freebsd.org/changeset/base/350256 >>>>> >>>> Hi, >>>> >>>> Not sure if this is just a difference in the versions or more things >>>> are being compiled, but I noticed a buildworld on my Ryzen went from ~ >>>> 31min to just over 40min. Is this expected ? >>> Most likely this is because it will now build a bootstrap compiler, >>> whereas previously your system may have skipped this step. Can you >>> compare the results when setting MK_SYSTEM_COMPILER=no and >>> MK_SYSTEM_LINKER=no ? >> Adding those two to src.conf and make.conf still shows 40min >> >> time make -j14 buildworld > /var/log/build.out ; time make -j14 >> buildkernel > /var/log/build.out. >> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >> 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 656666+3288880io >> 214633pf+0w >> 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io >> 61829pf+0w >> >> Should I be setting these vars somewhere else ? > Ah, setting them in src.conf, make.conf or the environment will be > overridden from Makefile.inc1, unfortunately. It will then show > something like: > > make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. > make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. > > E.g, it detects that your system compiler is of a lower version than > the compiler in the source tree, and will thus bootstrap the latter. > > Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and > MK_SYSTEM_LINKER=yes? In that case, both before and after r350256, the > results should be fairly similar, I expect. odd, its still taking the same 40min  # time make  -j14 buildworld > /var/log/build.out ; time make -j14 buildkernel > /var/log/build.out.                                             [Creating objdir /usr/obj/usr/src/amd64.amd64...] 25281.564u 1233.340s 40:31.08 1090.6%   45595+3474k 633698+3288574io 213653pf+0w 1675.796u 172.082s 2:38.19 1168.1%      37746+3170k 205909+3329072io 61654pf+0w Looking at /var/log/build.out, the top line show # head /var/log/build.out --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. --- buildworld_prologue --- despite # cat /etc/src.conf /etc/make.conf MK_SYSTEM_COMPILER=no MK_SYSTEM_LINKER=no KERNCONF=server MK_SYSTEM_COMPILER=no MK_SYSTEM_LINKER=no From owner-freebsd-stable@freebsd.org Wed Jul 24 20:49:16 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 370F1B843D for ; Wed, 24 Jul 2019 20:49:16 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (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 "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCA6D7399F for ; Wed, 24 Jul 2019 20:49:15 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x6OKmn6n021862 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 24 Jul 2019 22:48:50 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x6OKmnGa021861 for freebsd-stable@freebsd.org; Wed, 24 Jul 2019 22:48:49 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x6OKQWJB051270 for ; Wed, 24 Jul 2019 22:26:32 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x6OKQ94T051157 for ; Wed, 24 Jul 2019 22:26:09 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x6OKQ9RX051154 for freebsd-stable@freebsd.org; Wed, 24 Jul 2019 22:26:09 +0200 (CEST) (envelope-from peter) Date: Wed, 24 Jul 2019 22:26:08 +0200 From: Peter To: freebsd-stable@freebsd.org Subject: Rel. 11.3: Kernel doesn't compile anymore :( Message-ID: <20190724202608.GA50442@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Wed, 24 Jul 2019 22:48:53 +0200 (CEST) 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, 24 Jul 2019 20:49:16 -0000 Trying to compile my custom kernel in Rel. 11.3 results in this: [code]--- kernel.full --- linking kernel.full atomic.o: In function `atomic_add_64': /usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of `atomic_add_64' opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here *** [kernel.full] Error code 1[/code] Same config worked with 11.2 The offending feature is either options ZFS or device dtrace (Adding any of these to the GENERIC config gives the same error.) This happens only when building for i386. Building amd64 with these options works. From owner-freebsd-stable@freebsd.org Wed Jul 24 20:56:47 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1504B883A for ; Wed, 24 Jul 2019 20:56:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E44CE74375; Wed, 24 Jul 2019 20:56:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:c95b:26e6:56f7:7413] ([IPv6:2607:f3e0:0:4:c95b:26e6:56f7:7413]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x6OKufFP099020 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2019 16:56:42 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) From: mike tancsa To: Dimitry Andric Cc: freebsd-stable@freebsd.org References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> Message-ID: <801c0dd8-7a50-d93f-77f6-999aaa91a295@sentex.net> Date: Wed, 24 Jul 2019 16:56:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: E44CE74375 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.62 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.61)[-0.612,0]; LONG_SUBJ(1.70)[227]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.57), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: smtp.sentex.ca]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; NEURAL_HAM_MEDIUM(-0.98)[-0.983,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; 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: Wed, 24 Jul 2019 20:56:47 -0000 On 7/24/2019 1:21 PM, mike tancsa wrote: > On 7/24/2019 12:02 PM, Dimitry Andric wrote: >> On 24 Jul 2019, at 17:12, mike tancsa wrote: >>> On 7/24/2019 9:45 AM, Dimitry Andric wrote: >>>> On 24 Jul 2019, at 14:47, mike tancsa wrote: >>>>> On 7/23/2019 2:40 PM, Dimitry Andric wrote: >>>>>> Author: dim >>>>>> Date: Tue Jul 23 18:40:32 2019 >>>>>> New Revision: 350256 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/350256 >>>>>> >>>>> Hi, >>>>> >>>>> Not sure if this is just a difference in the versions or more things >>>>> are being compiled, but I noticed a buildworld on my Ryzen went from ~ >>>>> 31min to just over 40min. Is this expected ? >>>> Most likely this is because it will now build a bootstrap compiler, >>>> whereas previously your system may have skipped this step. Can you >>>> compare the results when setting MK_SYSTEM_COMPILER=no and >>>> MK_SYSTEM_LINKER=no ? >>> Adding those two to src.conf and make.conf still shows 40min >>> >>> time make -j14 buildworld > /var/log/build.out ; time make -j14 >>> buildkernel > /var/log/build.out. >>> [Creating objdir /usr/obj/usr/src/amd64.amd64...] >>> 25312.621u 1237.984s 40:09.72 1101.8% 45579+3473k 656666+3288880io >>> 214633pf+0w >>> 1675.467u 173.497s 2:37.90 1170.9% 37728+3167k 207118+3329460io >>> 61829pf+0w >>> >>> Should I be setting these vars somewhere else ? >> Ah, setting them in src.conf, make.conf or the environment will be >> overridden from Makefile.inc1, unfortunately. It will then show >> something like: >> >> make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. >> make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. >> >> E.g, it detects that your system compiler is of a lower version than >> the compiler in the source tree, and will thus bootstrap the latter. >> >> Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and >> MK_SYSTEM_LINKER=yes? In that case, both before and after r350256, the >> results should be fairly similar, I expect. > odd, its still taking the same 40min > >  # time make  -j14 buildworld > /var/log/build.out ; time make -j14 > buildkernel > > /var/log/build.out.                                             > [Creating objdir /usr/obj/usr/src/amd64.amd64...] > 25281.564u 1233.340s 40:31.08 1090.6%   45595+3474k 633698+3288574io > 213653pf+0w > 1675.796u 172.082s 2:38.19 1168.1%      37746+3170k 205909+3329072io > 61654pf+0w > > > Looking at /var/log/build.out, the top line show > > # head /var/log/build.out > --- buildworld --- > make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang > will be built for bootstrapping a cross-compiler. > make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will > be built for bootstrapping a cross-linker. > --- buildworld_prologue --- > > despite > > # cat /etc/src.conf /etc/make.conf > MK_SYSTEM_COMPILER=no > MK_SYSTEM_LINKER=no > KERNCONF=server > MK_SYSTEM_COMPILER=no > MK_SYSTEM_LINKER=no Hmmm, is the logic reversed somehow ?  The good news is if nothing is defined, it does the right thing.  # head -3  /var/log/build.out.2 --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker. # time make  -j14 buildworld > /var/log/build.out.2                                               [Creating objdir /usr/obj/usr/src/amd64.amd64...] 19068.507u 1118.866s 31:07.44 1081.0%   54443+3546k 579241+2828231io 173288pf+0w  # cat /etc/src.conf /etc/make.conf MK_SYSTEM_COMPILER=yes MK_SYSTEM_LINKER=yes KERNCONF=server MK_SYSTEM_COMPILER=yes MK_SYSTEM_LINKER=yes If I comment them out,  head -4 /var/log/build.out.3-no-defs-in-src-or-make --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker. --- buildworld_prologue --- # cat /etc/src.conf /etc/make.conf #MK_SYSTEM_COMPILER=yes #MK_SYSTEM_LINKER=yes KERNCONF=server #MK_SYSTEM_COMPILER=yes #MK_SYSTEM_LINKER=yes vs  head -4 /var/log/build.out.3-no-in-src-dot-conf --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. --- buildworld_prologue ---  # cat /etc/src.conf /etc/make.conf MK_SYSTEM_COMPILER=no MK_SYSTEM_LINKER=no KERNCONF=server MK_SYSTEM_COMPILER=no MK_SYSTEM_LINKER=no From owner-freebsd-stable@freebsd.org Wed Jul 24 21:21:24 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B6C35B91EA for ; Wed, 24 Jul 2019 21:21:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5B3754A6; Wed, 24 Jul 2019 21:21:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 3F3642F943; Wed, 24 Jul 2019 21:21:23 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::e5f9:9d28:2d74:eb2] (unknown [IPv6:2001:470:7a58:0:e5f9:9d28:2d74:eb2]) (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 164C83F6F0; Wed, 24 Jul 2019 23:21:22 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_505C1569-AB6B-45EF-BF74-58E3B3385237"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) Date: Wed, 24 Jul 2019 23:21:08 +0200 In-Reply-To: <801c0dd8-7a50-d93f-77f6-999aaa91a295@sentex.net> Cc: freebsd-stable@freebsd.org To: mike tancsa References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> <801c0dd8-7a50-d93f-77f6-999aaa91a295@sentex.net> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 7D5B3754A6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; 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: Wed, 24 Jul 2019 21:21:24 -0000 --Apple-Mail=_505C1569-AB6B-45EF-BF74-58E3B3385237 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Jul 2019, at 22:56, mike tancsa wrote: > > On 7/24/2019 1:21 PM, mike tancsa wrote: >> On 7/24/2019 12:02 PM, Dimitry Andric wrote: ... >> # cat /etc/src.conf /etc/make.conf >> MK_SYSTEM_COMPILER=no >> MK_SYSTEM_LINKER=no >> KERNCONF=server >> MK_SYSTEM_COMPILER=no >> MK_SYSTEM_LINKER=no > > Hmmm, is the logic reversed somehow ? The good news is if nothing is > defined, it does the right thing. The idea is that the default is to *not* bootstrap the compiler, if the system compiler is new enough. E.g. if you build r350256 from a system built before r350256, it will normally automatically bootstrap everything. E.g., your previous builds did not have to bootstrap, and now they do, which is why they take longer. So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing. I did a few tests on a relatively fast machine, and buildworld with those settings on took approximately the same time at r350255 and r350256. I'm now repeating those experiments to feed the results to ministat. -Dimitry --Apple-Mail=_505C1569-AB6B-45EF-BF74-58E3B3385237 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXTjLxAAKCRCwXqMKLiCW o5eJAJ9AzKo5AkgsIusI2vHzbXqcCEw20wCgir2Ow1kFNRpR2MZsiN+Lo1MajB4= =T8cf -----END PGP SIGNATURE----- --Apple-Mail=_505C1569-AB6B-45EF-BF74-58E3B3385237-- From owner-freebsd-stable@freebsd.org Wed Jul 24 23:13:22 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 029CCBC1AB for ; Wed, 24 Jul 2019 23:13:22 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (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 "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A35078319C; Wed, 24 Jul 2019 23:13:21 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x6OND4d4098593 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 01:13:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x6OND4Vq098592; Thu, 25 Jul 2019 01:13:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x6ON2WYQ088990; Thu, 25 Jul 2019 01:02:32 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x6ON0sT5088677; Thu, 25 Jul 2019 01:00:54 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x6ON0sYM088676; Thu, 25 Jul 2019 01:00:54 +0200 (CEST) (envelope-from peter) Date: Thu, 25 Jul 2019 01:00:54 +0200 From: Peter To: freebsd-stable@freebsd.org Cc: hselasky@freebsd.org Subject: Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!) Message-ID: <20190724230054.GA81816@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Thu, 25 Jul 2019 01:13:08 +0200 (CEST) X-Spam: Yes 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, 24 Jul 2019 23:13:22 -0000 > Trying to compile my custom kernel in Rel. 11.3 results in this: > > -- kernel.full --- > linking kernel.full > atomic.o: In function `atomic_add_64': > /usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of `atomic_add_64' > opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here > *** [kernel.full] Error code 1 > > Same config worked with 11.2 > > The offending feature is either > options ZFS > or > device dtrace > (Adding any of these to the GENERIC config gives the same error.) > > This happens only when building for i386. Building amd64 with these > options works. Trying to analyze the issue: The problem appears with SVN 334762 in 11.3: This change adds two new functions to sys/i386/include/atomic.h: atomic_add_64() atomic_subtract_64() [I don't really understand why this goes into a headerfile, but, well, nevermind] Also, this change deactivates two functions (only in case *i386*) from sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c atomic_add_64() atomic_del_64() [Now, there seems to be a slight strangeness here: if we *deactivate* atomic_del_64(), and *insert* atomic_subtract_64(), then these two names are not the same, and I might suppose that the atomic_del_64() is then somehow missing. But, well, nevermind] Now, the strange thing: this file sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c from which now two functions get excluded *only in case i386*, is not even compiled for i386: >/usr/src/sys/conf$ grep opensolaris_atomic.c * >files.arm:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" >files.mips:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" >files.powerpc:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs powerpc | dtrace powerpc compile-with "${ZFS_C}" >files.riscv:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" [So maybe that's the reason why the now lack of atomic_del_64() is not complained? Or maybe it's not used, or maybe I didn't find some definition whereever. Well, nevermind] Anyway, the actual name clash happens between sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S, because that one *is* compiled: >/usr/src/sys/conf$ grep i386/opensolaris_atomic.S * >files.i386:cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S optional zfs | dtrace compile-with "${ZFS_S}" I tried to move out the changes from SVN 334762. Sadly, that didn't work, because something does already use these atomic_add_64() stuff, So instead, I did this one: --- sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S (revision 350287) +++ sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S (working copy) @@ -66,8 +66,7 @@ * specific mapfile and remove the NODYNSORT attribute * from atomic_add_64_nv. */ - ENTRY(atomic_add_64) - ALTENTRY(atomic_add_64_nv) + ENTRY(atomic_add_64_nv) pushl %edi pushl %ebx movl 12(%esp), %edi // %edi = target address @@ -87,7 +86,6 @@ popl %edi ret SET_SIZE(atomic_add_64_nv) - SET_SIZE(atomic_add_64) ENTRY(atomic_or_8_nv) movl 4(%esp), %edx // %edx = target address And at least it compiles now. If it actually runs, that remains to be found out. Bottomline: Please, please, please, sort this out and fix it. From owner-freebsd-stable@freebsd.org Thu Jul 25 00:27:15 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54AFDBDBE5; Thu, 25 Jul 2019 00:27:15 +0000 (UTC) (envelope-from t_uemura@macome.co.jp) Received: from smtp11.dti.ne.jp (smtp11.dti.ne.jp [202.216.231.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9292985968; Thu, 25 Jul 2019 00:27:12 +0000 (UTC) (envelope-from t_uemura@macome.co.jp) Received: from towerrecords.dyndns.org ([14.193.133.120]) by smtp11.dti.ne.jp (3.11s) with ESMTP AUTH id x6P0CdV8002104; Thu, 25 Jul 2019 09:12:39 +0900 (JST) Received: by towerrecords.dyndns.org (Postfix, from userid 58) id E25C869522E; Thu, 25 Jul 2019 09:12:38 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on towerrecords.dyndns.org Received: from [192.168.1.21] (p5307096-ipngn11902marunouchi.tokyo.ocn.ne.jp [114.166.45.96]) by towerrecords.dyndns.org (Postfix) with ESMTPSA id 568E0695114; Thu, 25 Jul 2019 09:12:35 +0900 (JST) From: UEMURA Tetsuya To: freebsd-stable@freebsd.org Subject: Bug 239100 - r348991 breaks unionfs Cc: freebsd-current@freebsd.org Sender: t_uemura@macome.co.jp MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.74.02 [ja] Message-Id: <20190725001238.E25C869522E@towerrecords.dyndns.org> Date: Thu, 25 Jul 2019 09:12:38 +0900 (JST) X-Rspamd-Queue-Id: 9292985968 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; spf=softfail (mx1.freebsd.org: 202.216.231.186 is neither permitted nor denied by domain of t_uemura@macome.co.jp) smtp.mailfrom=t_uemura@macome.co.jp X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.94)[0.939,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[macome.co.jp]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.92)[0.923,0]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[mail.macome.co.jp]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.98)[0.981,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:202.216.224.0/19, country:JP]; IP_SCORE(0.65)[asn: 10013(3.31), country: JP(-0.04)] 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, 25 Jul 2019 00:27:15 -0000 While upgrading my ports from 12.0-RELEASE to 12-STABLE, I encountered a lot of Text file busy errors, and almost no ports I could update successfully. Then I attempted to fix/workaround the issue, and finally I found that r348991 Switch to use shared vnode locks for text files during image activation broke my uinonfs, which was the culprit for Text file busy issue. https://svnweb.freebsd.org/base?view=revision&revision=348991 I filed the issue in Bugzilla. Someone please look at the issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239100 P.S. For freebsd-current, r348991 was MFC r347151,347181,347968,348421,348698,348701 . -- UEMURA, Tetsuya From owner-freebsd-stable@freebsd.org Thu Jul 25 00:54:08 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A077BE8C4 for ; Thu, 25 Jul 2019 00:54:08 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0790886ADF for ; Thu, 25 Jul 2019 00:54:07 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id z3so93653666iog.0 for ; Wed, 24 Jul 2019 17:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iSYNlq5U3bwbm3emg7V/DS64AnoAFGkC1zOPf0suHsU=; b=m+gR4anJvHbsbTigS0mkIJD6I/c6jUxCxod4id5VH7pobqOE5uIohxuMzLGG0kZJ1w sPXB0ve+8kb5QbEFFYmpeY8kxyP2xjKMKdYe51/qE2Jv+s5dPPtd+en04eQsbwD7eCsz vuz+OWzUpgB75i9fPNO73YRp1ii5ynDrHTQRpCe58fSLd26Mi+fMrdWzm/rG4rxjM1bP yjgGJCReeIa7YnNwFGNzyvN1pYtiDkE5TNhQIn6k5ljH7CXrn2pHkTuNshAoFsTzyQeI LyKAc4fhw7NK1ki6gOAfmQzWcwysWI1QkjzOgIIi71q/qYSicppSf/h/lLmwAMfCWRXq qMYw== 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=iSYNlq5U3bwbm3emg7V/DS64AnoAFGkC1zOPf0suHsU=; b=XQilURazgVFvwflhuD9TJurQ62BTvXMKleB5b3SLtPi8MkX5xpcO2yNxuSDoubmrjG f4bNytL8wmmlonpOpdlrkXE+qj5q0VN2cJWu+rymUW+9Jlod4P0oiYSbkwb9drIRWon7 XF6KsbyJzN0MfwTZTDb9YpOWYdGjXbqd/kq/sCaU1S08ndDfASE784YZFAgTutGQE/FZ M+fhjE4Bze1Jzv9F62oglyOIGQLHtk89v3+N7fqmvInXCowWSHF6FblJiHvCH/sP5vlv Y+3vp/YilkGy25tr8ecRBdNRk8S+7u+3IgchAfcFIXnej9HlPdE9pbirW9nH3+otvUC9 KBsg== X-Gm-Message-State: APjAAAUxRJJPyjFiBTcarfNWy8+SfFEvhbxfBe+L5lAOL4lRnTI+mUk6 0pXPV9Qcm6pT+fzWM4WccRT2n4JKm4obnlIIhMlpuv72Zi4= X-Google-Smtp-Source: APXvYqwQlGKsX+VuRBEjtwbKvRO4OexqU6WNKFRftxt/kT6WQ31OB+oguNZuAivJcOknaXwq76WEvWUcWVPrVH+WvaY= X-Received: by 2002:a6b:bf01:: with SMTP id p1mr49333193iof.181.1564016046237; Wed, 24 Jul 2019 17:54:06 -0700 (PDT) MIME-Version: 1.0 References: <20190710162636.GM5965@teardrop.org> In-Reply-To: <20190710162636.GM5965@teardrop.org> From: Adam Date: Wed, 24 Jul 2019 19:53:54 -0500 Message-ID: Subject: Re: Random panics in 11.0 and 12.0 on J1900 To: James Snow Cc: "freebsd-stable@freebsd.org" X-Rspamd-Queue-Id: 0790886ADF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=m+gR4anJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of amvandemore@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=amvandemore@gmail.com X-Spamd-Result: default: False [-6.04 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; URIBL_BLOCKED(0.00)[superuser.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.d.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(-2.05)[ip: (-4.67), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.43), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] 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, 25 Jul 2019 00:54:08 -0000 On Wed, Jul 10, 2019 at 11:28 AM James Snow wrote: > I have a set of J1900 hosts running 11.0-RELEASE-p1 that experience > seemingly random panics. What is the size of this J1900 set? Do you also have J1900 which do not exhibit the problem? > One, memtest has turned up no errors on 12.0 host I witnessed the panic > on. > memtest cannot conclusively confirm dimm is good, it is only conclusive on bad ones. You can find more info about others learning this lesson here(see extended comments): https://superuser.com/questions/547822/how-many-passes-are-enough-with-memtest > Two, a small number of systems on the same hardware are running > 10.3-RELEASE, and have experienced no panics in their history. Panics > have only happened on 11s, and now 12. > Once upon a time in a hypothetical universe, I had a stick of ram which would run on Win98 for very long periods without issue. It wouldn't even boot with Win NT. After the manufacturer sent the same one back twice, I tased it and RMA'd again. This time, I got a new stick and all was good. The point is memory issues can be very subtle and replacing with known good modules is the easiest way to be sure. -- Adam From owner-freebsd-stable@freebsd.org Thu Jul 25 07:40:08 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93E8EC5011 for ; Thu, 25 Jul 2019 07:40:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 553736DCBE; Thu, 25 Jul 2019 07:40:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C4CFC260082; Thu, 25 Jul 2019 09:40:04 +0200 (CEST) Subject: Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!) To: Peter , freebsd-stable@freebsd.org, Ed Maste References: <20190724230054.GA81816@gate.oper.dinoex.org> From: Hans Petter Selasky Message-ID: <2a95277f-0646-aeb1-ddf5-9f08bb35161f@selasky.org> Date: Thu, 25 Jul 2019 09:39:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190724230054.GA81816@gate.oper.dinoex.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 553736DCBE 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]; 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, 25 Jul 2019 07:40:08 -0000 On 2019-07-25 01:00, Peter wrote: >> Trying to compile my custom kernel in Rel. 11.3 results in this: >> >> -- kernel.full --- >> linking kernel.full >> atomic.o: In function `atomic_add_64': >> /usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of `atomic_add_64' >> opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here >> *** [kernel.full] Error code 1 >> >> Same config worked with 11.2 >> >> The offending feature is either >> options ZFS >> or >> device dtrace >> (Adding any of these to the GENERIC config gives the same error.) >> >> This happens only when building for i386. Building amd64 with these >> options works. > > > Trying to analyze the issue: > > > The problem appears with SVN 334762 in 11.3: > > This change adds two new functions to sys/i386/include/atomic.h: > atomic_add_64() > atomic_subtract_64() > [I don't really understand why this goes into a headerfile, but, well, > nevermind] > > Also, this change deactivates two functions (only in case *i386*) from > sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c > atomic_add_64() > atomic_del_64() > [Now, there seems to be a slight strangeness here: if we *deactivate* > atomic_del_64(), and *insert* atomic_subtract_64(), then these two > names are not the same, and I might suppose that the atomic_del_64() > is then somehow missing. But, well, nevermind] > > Now, the strange thing: > this file sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c > from which now two functions get excluded *only in case i386*, is not > even compiled for i386: > >> /usr/src/sys/conf$ grep opensolaris_atomic.c * >> files.arm:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" >> files.mips:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" >> files.powerpc:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs powerpc | dtrace powerpc compile-with "${ZFS_C}" >> files.riscv:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace compile-with "${CDDL_C}" > > [So maybe that's the reason why the now lack of atomic_del_64() is not > complained? Or maybe it's not used, or maybe I didn't find some > definition whereever. Well, nevermind] > > > Anyway, the actual name clash happens between > sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S, > because that one *is* compiled: > >> /usr/src/sys/conf$ grep i386/opensolaris_atomic.S * >> files.i386:cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S optional zfs | dtrace compile-with "${ZFS_S}" > > > I tried to move out the changes from SVN 334762. Sadly, that didn't > work, because something does already use these atomic_add_64() stuff, > > So instead, I did this one: > > --- sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S (revision 350287) > +++ sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S (working copy) > @@ -66,8 +66,7 @@ > * specific mapfile and remove the NODYNSORT attribute > * from atomic_add_64_nv. > */ > - ENTRY(atomic_add_64) > - ALTENTRY(atomic_add_64_nv) > + ENTRY(atomic_add_64_nv) > pushl %edi > pushl %ebx > movl 12(%esp), %edi // %edi = target address > @@ -87,7 +86,6 @@ > popl %edi > ret > SET_SIZE(atomic_add_64_nv) > - SET_SIZE(atomic_add_64) > > ENTRY(atomic_or_8_nv) > movl 4(%esp), %edx // %edx = target address > > > And at least it compiles now. If it actually runs, that remains to be > found out. Can you attach your kernel configuration file? --HPS From owner-freebsd-stable@freebsd.org Thu Jul 25 08:30:32 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3071C60E8; Thu, 25 Jul 2019 08:30:32 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EAE16FA4D; Thu, 25 Jul 2019 08:30:32 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 785B68F6C; Thu, 25 Jul 2019 08:30:32 +0000 (UTC) Date: Thu, 25 Jul 2019 08:30:32 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-07-21 Message-ID: <20190725083032.GA63359@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 9EAE16FA4D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; TAGGED_RCPT(0.00)[]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; 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, 25 Jul 2019 08:30:32 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-07-21 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-07-15 to 2019-07-21. During this period, we have: * 1659 builds (96.7% (-0.7) passed, 3.3% (+0.7) failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 306 test runs (56.2% (+1.9) passed, 43.1% (+5.6) unstable, 0.7% (-7.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 18 doc builds (100% (+0) passed) Test case status (by 2019-07-21 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ----- | ---- | ---- | ------- | | head/amd64 | 7460 | 7411 | 0 | 49 | | head/i386 | 7458 | 7406 | 4 | 48 | | 12-STABLE/amd64 | 7388 | 7341 | 0 | 47 | | 12-STABLE/i386 | 7386 | 7335 | 5 | 46 | | 11-STABLE/amd64 | 6845 | 6800 | 0 | 45 | | 11-STABLE/i386 | 6843 | 6759 | 34 | 50 | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/s/rJJdcpCbH and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.opencrypto.runtests.main Fixed in http://svnweb.freebsd.org/changeset/base/350164 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * Analysis from kp@: * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001933.html * https://lists.freebsd.org/pipermail/freebsd-testing/2019-June/001934.html * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * Same as -head: * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * lib.libregex.exhaust_test.regcomp_too_big * flaky, sometimes failed with: ``` /usr/src/contrib/netbsd-tests/lib/libc/regex/t_exhaust.c:72: p != NULL not met ``` * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d https://bugs.freebsd.org/237641 * 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 ## 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_loogle.com/ine_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 ## Issues ### Cause build fails * https://bugs.freebsd.org/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/233769 Possible build race: ld: error: unable to find library -lgcc_s * https://bugs.freebsd.org/238828 Possible build race: lib/libsysdecode/tables.h:948: error: 'IPV6_MIN_MEMBERSHIPS' undeclared ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237077 possible race in build: /usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected relocatable expression * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237652 tests.hotspare.hotspare_test.hotspare_snapshot_001_pos timeout since somewhere in (r346814, r 346845] * https://bugs.freebsd.org/237655 Non-deterministic panic when running pf tests in interface ioctl code (NULL passed to strncmp) * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/237657 sys.kern.pdeathsig.signal_delivered_ptrace timing out periodically on i386 * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) * https://issues.tmatesoft.com/issue/SVNKIT-740 The patch is asked to be updated and help wanted. There is a new one at: https://github.com/jenkinsci/svnkit/pull/3/files * https://bugs.freebsd.org/235356 Help on how to reproduce and analyze is wanted. ## Other News * [FCP 20190401-ci_policy: CI policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md) is in "feedback" state, please check and provide comments. From owner-freebsd-stable@freebsd.org Thu Jul 25 11:33:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 18E5EA254E for ; Thu, 25 Jul 2019 11:33:56 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (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 "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 704C3769F8; Thu, 25 Jul 2019 11:33:55 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id x6PBXjJc080822 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 13:33:46 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id x6PBXj65080821; Thu, 25 Jul 2019 13:33:45 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id x6PBEXlt087617; Thu, 25 Jul 2019 13:14:33 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id x6PBDH8k087415; Thu, 25 Jul 2019 13:13:17 +0200 (CEST) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id x6PBDHsV087414; Thu, 25 Jul 2019 13:13:17 +0200 (CEST) (envelope-from peter) Date: Thu, 25 Jul 2019 13:13:17 +0200 From: Peter To: Hans Petter Selasky Cc: Peter , freebsd-stable@freebsd.org, Ed Maste Subject: Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!) Message-ID: <20190725111317.GA82875@gate.oper.dinoex.org> References: <20190724230054.GA81816@gate.oper.dinoex.org> <2a95277f-0646-aeb1-ddf5-9f08bb35161f@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a95277f-0646-aeb1-ddf5-9f08bb35161f@selasky.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [194.45.71.2]); Thu, 25 Jul 2019 13:33:49 +0200 (CEST) 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, 25 Jul 2019 11:33:56 -0000 Hi Hans Petter, glad to read You! :) On Thu, Jul 25, 2019 at 09:39:26AM +0200, Hans Petter Selasky wrote: ! On 2019-07-25 01:00, Peter wrote: ! >> The offending feature is either ! >> options ZFS ! >> or ! >> device dtrace ! >> (Adding any of these to the GENERIC config gives the same error.) ! Can you attach your kernel configuration file? Yes, but to what point? I can reproduce this with the GENERIC configuration by adding "options ZFS" (My custom KERNCONF relates to my local patches, and is rather pointless without these. So at first I tried to reproduce without my local patches and with minimal changes from GENERIC config. And the minimal change is to add "options ZFS" into the GENERIC conf.) See here: root@disp:/usr/src/sys/i386/compile/GENERIC # make linking kernel.full atomic.o: In function `atomic_add_64': /usr/src/sys/i386/compile/GENERIC/./machine/atomic.h:629: multiple definition of `atomic_add_64' opensolaris_atomic.o:/usr/src/sys/i386/compile/GENERIC/../../../cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here *** Error code 1 Stop. make: stopped in /usr/src/sys/i386/compile/GENERIC root@disp:/usr/src/sys/i386/compile/GENERIC # root@disp:/usr/src/sys/i386/compile/GENERIC # cd ../../../.. root@disp:/usr/src # svn stat M sys/i386/conf/GENERIC root@disp:/usr/src # svn diff Index: sys/i386/conf/GENERIC =================================================================== --- sys/i386/conf/GENERIC (revision 350287) +++ sys/i386/conf/GENERIC (working copy) @@ -1,3 +1,4 @@ +options ZFS # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # root@disp:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-east.freebsd.org/base/releng/11.3 Relative URL: ^/releng/11.3 Repository Root: https://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 350287 Node Kind: directory Schedule: normal Last Changed Author: gordon Last Changed Rev: 350287 Last Changed Date: 2019-07-24 12:58:21 +0000 (Wed, 24 Jul 2019) From owner-freebsd-stable@freebsd.org Thu Jul 25 14:39:37 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E6A9A6052 for ; Thu, 25 Jul 2019 14:39:37 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (enterprise.ximalas.info [IPv6:2001:700:1100:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ximalas.info", Issuer "Hostmaster ximalas.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7AB8854B7; Thu, 25 Jul 2019 14:39:36 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (Ximalas@localhost [127.0.0.1]) by enterprise.ximalas.info (8.15.2/8.15.2) with ESMTPS id x6PEdSHI008966 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 16:39:28 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ximalas.info; s=default; t=1564065569; bh=UAFimI3ifxvUydnu4RYmnrtIlJ2heOdTYiNFRBcNa7U=; h=Date:From:To:cc:Subject; b=T1lwW+IXjXitRUqlMMWIrkfsR+a1istflucBghwvp5tMh5XSeqOyRhfWNZRImli6o 50umKlv0XFF0fV+gZIzohfTllZPWEhX5itug1mw9RKcOThK1Q3kNL3NV5iIIbC5Th8 Sdr+ht16WVFQ7QlEEKOO/HAYP7FOjoeH6l9N143Z+ShGy0e3F2aQzGx6rhS7xFq91z 7JL/ktbQv+lznygjPHqgfod7IXlukP+s4mEFU6mPrTE8rJB7YgjxxPAZqV2TUJG2TA l+2H4LY831jngDHShQ9ZmCyIM7IOhc7P7vAxE8GXFGzKwHMkzjNNkFoAWwKBK1cMiE BpCOnBBNRdLow== Received: from localhost (trond@localhost) by enterprise.ximalas.info (8.15.2/8.15.2/Submit) with ESMTP id x6PEdSTb008963; Thu, 25 Jul 2019 16:39:28 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) X-Authentication-Warning: enterprise.ximalas.info: trond owned process doing -bs Date: Thu, 25 Jul 2019 16:39:28 +0200 (CEST) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Sender: Trond.Endrestol@ximalas.info To: freebsd-stable@freebsd.org cc: kp@freebsd.org, kevans@freebsd.org Subject: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045 Message-ID: User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22) OpenPGP: url=http://ximalas.info/about/tronds-openpgp-public-key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on enterprise.ximalas.info 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, 25 Jul 2019 14:39:37 -0000 Hi, I have a VPN service running net/ocserv 0.12.4_1. Everything is ok until the first client disconnects. The main ocserv process hangs while destroying the tun interface, waiting indefinitely on "tun_cond". I ran an ocserv executable containing debug symbols through gdb and I had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, &ifr), at tun.c:770 of net/ocserv. The call to ioctl() has apparently a valid file descriptor, fd, and the fields of ifr are all zero, save the ifr_name field which contains "vpns0" and is properly null terminated. On the first attempt, I let the code run its course and had to reboot to recover. On the second attempt, I killed the ocserv process from within gdb. I ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. Rebooting is the only way to recover. Reverting to stable/12 r345045 makes ocserv serve the clients again. My guess is that one or more of r345285, r347378, and/or r348124, all related to sys/net/if_tun.c, are to blame. Can someone verify my claims? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500 https://gitlab.com/openconnect/ocserv/issues/213 -- Trond. From owner-freebsd-stable@freebsd.org Thu Jul 25 14:47:32 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FD20A65D9 for ; Thu, 25 Jul 2019 14:47:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03A1785BB0; Thu, 25 Jul 2019 14:47:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 92D1E7A2A; Thu, 25 Jul 2019 14:47:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-wm1-f52.google.com with SMTP id v15so45288729wml.0; Thu, 25 Jul 2019 07:47:31 -0700 (PDT) X-Gm-Message-State: APjAAAX6CbtIYQ3m7HnQ2qKoicqpanS8Za3Uu/tzyPdCJ4qB/BWLg6rR VFq+LBt5XQsArGuaJT6bTauA80v8kHA8623ZxAs= X-Google-Smtp-Source: APXvYqxCVEnlfZ9sQdqYLw3ekYlqznRC8g352Wp1ZHeQ//MwbqDi2ZcsefiCH9i93nE9tT2zFLZRRntVen/SjD2EGLE= X-Received: by 2002:a05:600c:20c3:: with SMTP id y3mr82714271wmm.3.1564066050485; Thu, 25 Jul 2019 07:47:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 25 Jul 2019 09:46:58 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045 To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD-STABLE Mailing List , Kristof Provost Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 03A1785BB0 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.969,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, 25 Jul 2019 14:47:32 -0000 On Thu, Jul 25, 2019 at 9:41 AM Trond Endrest=C3=B8l wrote: > > Hi, > > I have a VPN service running net/ocserv 0.12.4_1. Everything is ok > until the first client disconnects. The main ocserv process hangs > while destroying the tun interface, waiting indefinitely on > "tun_cond". > > I ran an ocserv executable containing debug symbols through gdb and I > had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, &ifr), at > tun.c:770 of net/ocserv. > > The call to ioctl() has apparently a valid file descriptor, fd, and > the fields of ifr are all zero, save the ifr_name field which contains > "vpns0" and is properly null terminated. > > On the first attempt, I let the code run its course and had to reboot > to recover. > > On the second attempt, I killed the ocserv process from within gdb. I > ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. > Rebooting is the only way to recover. > > Reverting to stable/12 r345045 makes ocserv serve the clients again. > > My guess is that one or more of r345285, r347378, and/or r348124, all > related to sys/net/if_tun.c, are to blame. > > Can someone verify my claims? > Hi, I'll take a look when I get a bit- a hang on tun_cond would be expected if a process has the tun cdev open()'d still. The device should fail to destroy until it's closed so we don't leave the controlling application in a funky state. There were some bugs around that leaving the driver in a funky state that I fixed somewhere along the way here. Thanks, Kyle Evans From owner-freebsd-stable@freebsd.org Thu Jul 25 15:23:23 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 60A89A70FA for ; Thu, 25 Jul 2019 15:23:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 3CF198717C; Thu, 25 Jul 2019 15:23:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 715DF26040E; Thu, 25 Jul 2019 17:23:19 +0200 (CEST) Subject: Re: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!) To: Peter Cc: freebsd-stable@freebsd.org, Ed Maste , Allan Jude References: <20190724230054.GA81816@gate.oper.dinoex.org> <2a95277f-0646-aeb1-ddf5-9f08bb35161f@selasky.org> <20190725111317.GA82875@gate.oper.dinoex.org> From: Hans Petter Selasky Message-ID: <37114e11-c746-7565-5c57-e51cfdfebb11@selasky.org> Date: Thu, 25 Jul 2019 17:22:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190725111317.GA82875@gate.oper.dinoex.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3CF198717C 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.980,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, 25 Jul 2019 15:23:23 -0000 Hi Allan, Can ZFS use atomic_add_64() in the kernel for i386 instead of building its own variant? --HPS On 2019-07-25 13:13, Peter wrote: > Hi Hans Petter, > glad to read You! :) > > On Thu, Jul 25, 2019 at 09:39:26AM +0200, Hans Petter Selasky wrote: > ! On 2019-07-25 01:00, Peter wrote: > > ! >> The offending feature is either > ! >> options ZFS > ! >> or > ! >> device dtrace > ! >> (Adding any of these to the GENERIC config gives the same error.) > > ! Can you attach your kernel configuration file? > > Yes, but to what point? > I can reproduce this with the GENERIC configuration by adding > "options ZFS" > > (My custom KERNCONF relates to my local patches, and is rather > pointless without these. So at first I tried to reproduce without > my local patches and with minimal changes from GENERIC config. And > the minimal change is to add "options ZFS" into the GENERIC conf.) > > See here: > > root@disp:/usr/src/sys/i386/compile/GENERIC # make > linking kernel.full > atomic.o: In function `atomic_add_64': > /usr/src/sys/i386/compile/GENERIC/./machine/atomic.h:629: multiple definition of `atomic_add_64' > opensolaris_atomic.o:/usr/src/sys/i386/compile/GENERIC/../../../cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71: first defined here > *** Error code 1 > > Stop. > make: stopped in /usr/src/sys/i386/compile/GENERIC > root@disp:/usr/src/sys/i386/compile/GENERIC # > > root@disp:/usr/src/sys/i386/compile/GENERIC # cd ../../../.. > root@disp:/usr/src # svn stat > M sys/i386/conf/GENERIC > root@disp:/usr/src # svn diff > Index: sys/i386/conf/GENERIC > =================================================================== > --- sys/i386/conf/GENERIC (revision 350287) > +++ sys/i386/conf/GENERIC (working copy) > @@ -1,3 +1,4 @@ > +options ZFS > # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > > root@disp:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-east.freebsd.org/base/releng/11.3 > Relative URL: ^/releng/11.3 > Repository Root: https://svn0.us-east.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 350287 > Node Kind: directory > Schedule: normal > Last Changed Author: gordon > Last Changed Rev: 350287 > Last Changed Date: 2019-07-24 12:58:21 +0000 (Wed, 24 Jul 2019) > > > From owner-freebsd-stable@freebsd.org Thu Jul 25 16:09:56 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E962A8075 for ; Thu, 25 Jul 2019 16:09:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FAF389146; Thu, 25 Jul 2019 16:09:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id D1A2783AD; Thu, 25 Jul 2019 16:09:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::e5f9:9d28:2d74:eb2] (unknown [IPv6:2001:470:7a58:0:e5f9:9d28:2d74:eb2]) (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 2C87F3F782; Thu, 25 Jul 2019 18:09:53 +0200 (CEST) From: Dimitry Andric Message-Id: <2B4E531D-F26E-4615-8F46-0869ED951138@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_4F215892-CF6F-42E3-8E97-AD3526648F00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) Date: Thu, 25 Jul 2019 18:09:52 +0200 In-Reply-To: Cc: freebsd-stable@freebsd.org To: mike tancsa References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> <801c0dd8-7a50-d93f-77f6-999aaa91a295@sentex.net> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 3FAF389146 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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, 25 Jul 2019 16:09:56 -0000 --Apple-Mail=_4F215892-CF6F-42E3-8E97-AD3526648F00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Jul 2019, at 23:21, Dimitry Andric wrote: >=20 > On 24 Jul 2019, at 22:56, mike tancsa wrote: >>=20 >> On 7/24/2019 1:21 PM, mike tancsa wrote: >>> On 7/24/2019 12:02 PM, Dimitry Andric wrote: > ... >>> # cat /etc/src.conf /etc/make.conf >>> MK_SYSTEM_COMPILER=3Dno >>> MK_SYSTEM_LINKER=3Dno >>> KERNCONF=3Dserver >>> MK_SYSTEM_COMPILER=3Dno >>> MK_SYSTEM_LINKER=3Dno >>=20 >> Hmmm, is the logic reversed somehow ? The good news is if nothing is >> defined, it does the right thing. >=20 > The idea is that the default is to *not* bootstrap the compiler, if = the > system compiler is new enough. E.g. if you build r350256 from a = system > built before r350256, it will normally automatically bootstrap > everything. >=20 > E.g., your previous builds did not have to bootstrap, and now they do, > which is why they take longer. >=20 > So the only good way to compare is to force MK_SYSTEM_COMPILER=3Dyes = and > MK_SYSTEM_LINKER=3Dyes, so both buildworlds will do the same thing. >=20 > I did a few tests on a relatively fast machine, and buildworld with > those settings on took approximately the same time at r350255 and > r350256. I'm now repeating those experiments to feed the results to > ministat. Repeating buildworld 3 times for r350255 and r350256 (with both MK_SYSTEM_COMPILER and MK_SYSTEM_LINKER set to "yes") shows no difference in measured real time, according to ministat: $ head real-*.txt =3D=3D> real-r350255.txt <=3D=3D 1562.12 1587.61 1582.78 =3D=3D> real-r350256.txt <=3D=3D 1574.50 1559.20 1584.50 $ ministat real-*.txt x real-r350255.txt + real-r350256.txt = +-------------------------------------------------------------------------= -----+ |+ x + x + x = | | = |_________|____________________A___M______A____________M______|___________= _|| = +-------------------------------------------------------------------------= -----+ N Min Max Median Avg = Stddev x 3 1562.12 1587.61 1582.78 1577.5033 = 13.539477 + 3 1559.2 1584.5 1574.5 1572.7333 = 12.742187 No difference proven at 95.0% confidence -Dimitry --Apple-Mail=_4F215892-CF6F-42E3-8E97-AD3526648F00 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXTnUUAAKCRCwXqMKLiCW o3mbAJ9gFtY+hANVirvpUzLTfIBYiD0EMgCgklhCHCXNgMcNq+X1NEoyYGf4qDE= =vXit -----END PGP SIGNATURE----- --Apple-Mail=_4F215892-CF6F-42E3-8E97-AD3526648F00-- From owner-freebsd-stable@freebsd.org Thu Jul 25 16:32:12 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 67D5EA867B for ; Thu, 25 Jul 2019 16:32:12 +0000 (UTC) (envelope-from snow@teardrop.org) Received: from hoopy.teardrop.org (hoopy.teardrop.org [52.27.92.245]) (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 37ABD89F41 for ; Thu, 25 Jul 2019 16:32:11 +0000 (UTC) (envelope-from snow@teardrop.org) Received: by hoopy.teardrop.org (Postfix, from userid 1002) id BC92812D198; Thu, 25 Jul 2019 16:32:39 +0000 (UTC) Date: Thu, 25 Jul 2019 16:32:39 +0000 From: James Snow To: Marco Steinbach , Adam Cc: freebsd-stable@freebsd.org Subject: Re: Random panics in 11.0 and 12.0 on J1900 Message-ID: <20190725163239.GS5965@teardrop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Rspamd-Queue-Id: 37ABD89F41 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of snow@teardrop.org designates 52.27.92.245 as permitted sender) smtp.mailfrom=snow@teardrop.org X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; URIBL_BLOCKED(0.00)[superuser.com.multi.uribl.com]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:52.27.92.245]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[teardrop.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[hoopy.teardrop.org]; NEURAL_HAM_SHORT(-0.93)[-0.933,0]; IP_SCORE(-0.95)[ipnet: 52.24.0.0/14(-3.34), asn: 16509(-1.34), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:52.24.0.0/14, country:US]; 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, 25 Jul 2019 16:32:12 -0000 Hi Marco and Adam, Thanks for the responses. Answers to your questions are inline.... On Sat, Jul 20, 2019 at 06:56:19PM +0200, Marco Steinbach wrote: > I've outfitted all of them with 4-port Intel PRO/1000 PCIe driven by > igb(4), and am not using the onboard re(4) NICs. We use the onboard re(4) NICs and they have been their own problem. It's possible they are implicated here. > I can't recall ever seeing a panic like you described. Could you share > a full dmesg and what mainboard(s) you are using ? /var/run/dmesg.boot from the 12.0 host that panicked is included below. The board is a "Q1900G2-M V2.0". On Wed, Jul 24, 2019 at 07:53:54PM -0500, Adam wrote: > What is the size of this J1900 set? Large enough that 1% panicking daily means I'm seeing multiple panics per day. > Do you also have J1900 which do not exhibit the problem? I do have a small set which have not exhibited the problem. They are about 2.5-3% of the fleet. What makes them unique is they are running 10.3. There are also some 11.0s which have not panicked, but given that we've seen hosts go ~620 days before a panic, it's possible they just haven't panicked yet; they are also a minority of the 11s. (It's also possible the 10.3s just haven't panicked yet, but as they have been deployed the longest, that seems less probable with each passing day.) Personally, I believe this is a hardware problem, but these 10.3s that don't panic are a big hole in that theory. > memtest cannot conclusively confirm dimm is good, it is only conclusive on > bad ones. You can find more info about others learning this lesson > here(see extended comments): > > https://superuser.com/questions/547822/how-many-passes-are-enough-with-memtest > > > > Two, a small number of systems on the same hardware are running > > 10.3-RELEASE, and have experienced no panics in their history. Panics > > have only happened on 11s, and now 12. > > > > Once upon a time in a hypothetical universe, I had a stick of ram which > would run on Win98 for very long periods without issue. It wouldn't even > boot with Win NT. After the manufacturer sent the same one back twice, I > tased it and RMA'd again. This time, I got a new stick and all was good. > > The point is memory issues can be very subtle and replacing with known good > modules is the easiest way to be sure. Duly noted, and I don't disagree, but given your comments about memtest and confirming memory to be good, how do you get to "known good?" Thanks for the input. dmesg output follows below. -Snow ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-RELEASE r341666 GENERIC amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 Structured Extended Features3=0xc000000 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8089657344 (7714 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20181003/tbfadt-748) ioapic0 irqs 0-86 on motherboard Launching APs: 3 2 1 Timecounter "TSC" frequency 2000056560 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module [ath_hal] loaded random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) unknown: I/O range not supported cpu0: on acpi0 atrtc0: port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff irq 8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf080-0xf087 mem 0xd0000000-0xd03fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 vgapci0: Boot video device ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xd0816000-0xd08167ff irq 19 at device 19.0 on pci0 ahci0: AHCI v1.30 with 2 3Gbps ports, Port Multiplier not supported ahcich1: at channel 1 on ahci0 xhci0: mem 0xd0800000-0xd080ffff irq 20 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 26.0 (no driver attached) hdac0: mem 0xd0810000-0xd0813fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 re0: port 0xe000-0xe0ff mem 0xd0704000-0xd0704fff,0xd0700000-0xd0703fff irq 16 at device 0.0 on pci1 re0: Using 1 MSI message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 40:62:31:03:e4:1e re0: netmap queues/slots: TX 1/256, RX 1/256 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci3: on pcib3 re1: port 0xd000-0xd0ff mem 0xd0604000-0xd0604fff,0xd0600000-0xd0603fff irq 16 at device 0.0 on pci3 re1: Using 1 MSI message re1: Chip rev. 0x2c800000 re1: MAC rev. 0x00100000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Using defaults for TSO: 65518/35/2048 re1: Ethernet address: 40:62:31:03:e4:1f re1: netmap queues/slots: TX 1/256, RX 1/256 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 ehci0: mem 0xd0815000-0xd08153ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus1: 480Mbps High Speed USB v2.0 isab0: at device 31.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12. vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid PNP0900 on isa0 est0: on cpu0 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 27,20 and 24,25 on hdaa0 hdacc1: at cad 2 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 4 on hdaa1 ugen1.1: at usbus1 ugen0.1: <0x8086 XHCI root HUB> at usbus0 ada0 at ahcich1 bus 0 scbus0 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number K1DTC7A41233647 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors) uhub0: on usbus1 sysctl_warn_reuse: can't re-use a leaf (dev.uhub.%parent)! Trying to mount root from zfs:zroot/ROOT/default []... uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 Root mount waiting for: usbus1 usbus0 uhub1: 7 ports with 7 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 uhub2 on uhub0 uhub2: on usbus1 Root mount waiting for: usbus1 uhub2: 4 ports with 4 removable, self powered ugen1.3: at usbus1 ukbd0 on uhub2 ukbd0: on usbus1 kbd2 at ukbd0 Root mount waiting for: usbus1 ugen1.4: at usbus1 uhub3 on uhub2 uhub3: on usbus1 uhub3: MTT enabled Root mount waiting for: usbus1 uhub3: 4 ports with 4 removable, self powered lo0: link state changed to UP re0: link state changed to DOWN re1: link state changed to DOWN re0: link state changed to UP uhid0 on uhub2 uhid0: on usbus1 From owner-freebsd-stable@freebsd.org Thu Jul 25 18:25:11 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5203AAF9C for ; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7D6B8EEA1; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 6900F9457; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-wr1-f43.google.com with SMTP id y4so51809229wrm.2; Thu, 25 Jul 2019 11:25:11 -0700 (PDT) X-Gm-Message-State: APjAAAWwxVTN/XCZeqK6Wjet/pHlX2wTBaYAR0Q7k3t3aPq632nDENoR 6QC85CTQ0OUTiExkl4et79oG537RVr1UXtwoc0E= X-Google-Smtp-Source: APXvYqw1fvJcUjnyWGGYlMxfakObCBzdrnur9xHFSvu4VcEuRO+1HuAsbj5DS5rKBMUbyckxpzGGJERSsnQNbC5SROI= X-Received: by 2002:adf:ce88:: with SMTP id r8mr22633199wrn.42.1564079110334; Thu, 25 Jul 2019 11:25:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 25 Jul 2019 13:24:38 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045 To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD-STABLE Mailing List , Kristof Provost Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B7D6B8EEA1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; 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, 25 Jul 2019 18:25:11 -0000 On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans wrote: > > On Thu, Jul 25, 2019 at 9:41 AM Trond Endrest=C3=B8l > wrote: > > > > Hi, > > > > I have a VPN service running net/ocserv 0.12.4_1. Everything is ok > > until the first client disconnects. The main ocserv process hangs > > while destroying the tun interface, waiting indefinitely on > > "tun_cond". > > > > I ran an ocserv executable containing debug symbols through gdb and I > > had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, &ifr), at > > tun.c:770 of net/ocserv. > > > > The call to ioctl() has apparently a valid file descriptor, fd, and > > the fields of ifr are all zero, save the ifr_name field which contains > > "vpns0" and is properly null terminated. > > > > On the first attempt, I let the code run its course and had to reboot > > to recover. > > > > On the second attempt, I killed the ocserv process from within gdb. I > > ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. > > Rebooting is the only way to recover. > > > > Reverting to stable/12 r345045 makes ocserv serve the clients again. > > > > My guess is that one or more of r345285, r347378, and/or r348124, all > > related to sys/net/if_tun.c, are to blame. > > > > Can someone verify my claims? > > > > Hi, > > I'll take a look when I get a bit- a hang on tun_cond would be > expected if a process has the tun cdev open()'d still. The device > should fail to destroy until it's closed so we don't leave the > controlling application in a funky state. There were some bugs around > that leaving the driver in a funky state that I fixed somewhere along > the way here. > > Thanks, > > Kyle Evans To follow-up to the list as well, I've added a comment on the Gitlab issue [0] -- my suspicion is that ocserv is violating the tunnel hand-off protocol (TUNSIFPID) and technically leaking the fd in the process that created it while trying to close/destroy it in another pid that actually controls the tunnel. [0] https://gitlab.com/openconnect/ocserv/issues/213 From owner-freebsd-stable@freebsd.org Thu Jul 25 19:30:30 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E181AC92E for ; Thu, 25 Jul 2019 19:30:30 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (unknown [IPv6:2607:f3e0:0:3::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8E7991BAA; Thu, 25 Jul 2019 19:30:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:c95b:26e6:56f7:7413] ([IPv6:2607:f3e0:0:4:c95b:26e6:56f7:7413]) by pyroxene.sentex.ca (8.15.2/8.15.2) with ESMTPS id x6PJUPGG088755 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2019 15:30:27 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) To: Dimitry Andric Cc: freebsd-stable@freebsd.org References: <201907231840.x6NIeWeq024894@repo.freebsd.org> <0CB72C19-405C-41F0-8967-96F363228ED6@FreeBSD.org> <8373E39A-46E7-41AB-BC1F-8CDF65F47287@FreeBSD.org> <801c0dd8-7a50-d93f-77f6-999aaa91a295@sentex.net> <2B4E531D-F26E-4615-8F46-0869ED951138@FreeBSD.org> From: mike tancsa Message-ID: Date: Thu, 25 Jul 2019 15:30:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2B4E531D-F26E-4615-8F46-0869ED951138@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: A8E7991BAA X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::18 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.67 / 15.00]; ARC_NA(0.00)[]; RDNS_NONE(1.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-0.55)[-0.550,0]; LONG_SUBJ(1.70)[227]; IP_SCORE(-1.72)[ipnet: 2607:f3e0::/32(-4.94), asn: 11647(-3.57), country: CA(-0.09)]; MX_GOOD(-0.01)[cached: smtp.sentex.ca]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; 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, 25 Jul 2019 19:30:30 -0000 On 7/25/2019 12:09 PM, Dimitry Andric wrote: > Hmmm, is the logic reversed somehow ? The good news is if nothing is >>> defined, it does the right thing. >> The idea is that the default is to *not* bootstrap the compiler, if the >> system compiler is new enough. E.g. if you build r350256 from a system >> built before r350256, it will normally automatically bootstrap >> everything. >> >> E.g., your previous builds did not have to bootstrap, and now they do, >> which is why they take longer. >> >> So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and >> MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing. >> >> I did a few tests on a relatively fast machine, and buildworld with >> those settings on took approximately the same time at r350255 and >> r350256. I'm now repeating those experiments to feed the results to >> ministat. Thanks again for verifying and explaining all this.  I was interpreting MK_SYSTEM_LINKER=yes as "along with building world, build the compiler and linker from scratch first" vs "using the existing installed system linker and compiler to build world" and as you pointed out, when its a version difference it gets overridden. > Repeating buildworld 3 times for r350255 and r350256 (with both The times on my machines all look normal now too!     ---Mike From owner-freebsd-stable@freebsd.org Fri Jul 26 18:06:33 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 77D7BA5F88 for ; Fri, 26 Jul 2019 18:06:33 +0000 (UTC) (envelope-from targetexposz4@targetexposz.com) Received: from sonic306-26.consmr.mail.sg3.yahoo.com (sonic306-26.consmr.mail.sg3.yahoo.com [106.10.241.146]) (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 A27957443E for ; Fri, 26 Jul 2019 18:06:30 +0000 (UTC) (envelope-from targetexposz4@targetexposz.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564164387; bh=rX80IIPlx/YCRZlPQ/7eUByiABiIMdJd0ZBY0WilUlE=; h=From:To:Subject:Date:From:Subject; b=KIDtCQHA+0+b8kBMB9ap+VyWtWZZja3fqew6NmAAv3NxW0T3ngo0BELV/8F6/8pSsaHmBBckcBo8L/JRpriqrl6d7LL9syviUhCg8vN5qJ9dttcQLBEdnuoalvlJH5qL5I5mIHHECjcwWghetzmpOq5cIQoF9NcaSTnvHP7tzBU74FXKt6U0d9C3PlvQBbpI6Pe4oFdT36mhUcuGTkVHbN/WVop00tjyKkbcb+yQtrRNfwqdgUXZkoqDtUIDH/YwdcprJRtrVqd/bHtMKZIyaNGoPv+vsP4v1ocZY4iUCeHDcu22QzPV4jN2Tn7BiR9aofO1L7/AbncemNWtDB5wKw== X-YMail-OSG: MW6kHSYVM1nzUJugGSkeS5qrtBPJWnmV9KTcGioJ9wIFvKolrs3Y5sduwBqaYJW GKwn9CtkBpqG6xoIshidBwYlfvuqdXsTiTFwX0fm7YWaEDUalzXUN8cfwQvj2gKFh.NgzKPWwUJz WyVTc263gy8Zsn4UmdQB.wIsc781loDo4lCYZPoWftc5GSBzcwqyE1prML2HcidgkY8pefRJOtvn lRtA5gMB7MEYCvOntAFVsoc_fK0dV43XDFXAnXq8SPp5.cPqDn.hqQ4m07uUu1VcQDB0r.J0u8uk WhJpiXEmzKXiqCoACNzti0GOrYR9GAcrI6EANLdgRwfHNukyIZJvTeShKF0BYqPeO7esLng_AVes HI01D4Vr7bnJDs3hsBL51TB6FpKN5q..OftpxDY3W_FcQmhyipNn3Nw90GTN0tWcE43JTiyLM827 W4jg3uGSr3S.hVjX7X_iQoUiCwJLJ8oqIQ3jwwL7SA6zsBBQx5twSrYRF5Om1YWGY9EZnU4NeI1P v971iBLLy_8J2mSyI67wVdJC2Dm9yR2QYcR5sYOWSdSsSXnBK8c05YfNNM9IHHcg51pEaXswBlL7 obM1Bf4NhbBCCRWatBPY3IUxkQeJvs1SUeh1oUckZw49d_A76klfCkxF1V1ko9NinCMAKx5YWTaE ImtXM62LYL68Mkddw1DW2xIPKFXeHeON7ZEAS.jXU_w1iQX9nd5QkHIXJ.WDtUq9gFlmzxbbaRSH ZwTvE2iqdRjrlXSZEI80Z9BTHDSSMp9BIqEJvrhNvIKpw97SbrpRSsuF7Df3j70fk.lUD0PhVnmK yL2yOBlsOoWrBO1Ah40ZY.81m37SvYZaW7EF5QCAUXFo5wUEzvMttgH1ZD_fZm34ykz0gafpZYlc mRd2pnGWc4BVZevzVCo49rgAWm16fC5iy8RSRxf7wdAtkcXvJL.GUqY2p4JbIvQL6mkTyRglHFDP ZQj4_eP9cUiriPP2PKNd.5ahlMg9.O1HGDZsSiDvIqrN1q62f4ZGUQz6EfvF32v.Z_2h1QhJENjt jp1dDVrjgp_nILLc5YAVDEOTbMUkJM2rW1Dfke7qqiuQc5opdHB4TdAh.9uBExpTSgjho1NNSvAP ykoohlM9PBleUiTI47FrnPes5OoUHoUUceeJE2wLURZezLSAgqOK2ElYOrHkivJ.egLujEvNyDQv uOTZ6umiT3Q6c449G3QJJKRr7581t38RePbthmG1jMiPP5XpoOYvHZ1zwI21FktoFQGNAEartQTW L3kot2H0Jqw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.sg3.yahoo.com with HTTP; Fri, 26 Jul 2019 18:06:27 +0000 Received: by smtp429.mail.sg3.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 17c207d390757da1407d00958584d37b; Fri, 26 Jul 2019 17:35:55 +0000 (UTC) From: "Shron Smith" To: Subject: Freebsd - Gartner Catalyst Conference 2019 - Register Portal List Date: Fri, 26 Jul 2019 13:35:41 -0700 Message-ID: <039a01d543f1$b5743990$205cacb0$@targetexposz.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdVD8Zugewceg5/qQA2o0ciT4MztmQ== Content-Language: en-us X-Rspamd-Queue-Id: A27957443E X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KIDtCQHA X-Spamd-Result: default: False [7.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.954,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[targetexposz.com]; NEURAL_SPAM_MEDIUM(0.96)[0.962,0]; RCPT_COUNT_ONE(0.00)[1]; DATE_IN_FUTURE(4.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.51)[ip: (-4.68), ipnet: 106.10.224.0/19(3.98), asn: 56173(3.19), country: SG(0.08)]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mx-biz.mail.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[146.241.10.106.list.dnswl.org : 127.0.5.0]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:56173, ipnet:106.10.224.0/19, country:SG]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,body] X-Spam: Yes Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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, 26 Jul 2019 18:06:33 -0000 Dear Exhibitors, We wish you a great success in the forthcoming exhibition. Gartner Catalyst Conference August 12-15, 2019 updated attendees List is Now Available! Which enables you to showcase your company's pre-show and post-show marketing efforts with unlimited usage on the contact list (No restriction on usage). Attendees: Security & Risk Management, Application Management, BI, Analytics and Data Management, Enterprise Architecture, Technical, Solution Architects, Infrastructure, Operations, Mobile, Cloud and Data Project Managers, Software Developers, key decision makers and many more... Qualified Data Field includes: Company Name, Web Address, Contact Name, Job Title, Mailing Address, Phone Number, and Industry, SIC Code, Company Mailing address with Zip Code, Fax Number, Industry Classification, and Website URL along with verified business email address. These contact lists will be delivered in Excel format which can be used for telemarketing, direct marketing, and email marketing initiatives etc. Please let me know your thoughts, as it will be my pleasure to share you the counts and pricing of the lists. Looking back to hearing from you. Regards, Shron Smith Gartner Catalyst Conference -Event Specialist. August 12-15, 2019 | San Diego, CA From owner-freebsd-stable@freebsd.org Sat Jul 27 02:43:46 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 81D7BAEEAF for ; Sat, 27 Jul 2019 02:43:46 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from mambo.koitsu.org (mambo.koitsu.org [172.81.177.231]) (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 0CF368D67C for ; Sat, 27 Jul 2019 02:43:45 +0000 (UTC) (envelope-from jdc@koitsu.org) Date: Fri, 26 Jul 2019 19:38:30 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib/Object contrib/llvm/lib/Ta...) Message-ID: <20190727023830.GA53438@koitsu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 0CF368D67C X-Spamd-Bar: +++++++++ X-Spamd-Result: default: False [9.27 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; GREYLIST(0.00)[pass,body]; FROM_HAS_DN(0.00)[]; FAKE_REPLY_C(4.30)[]; R_SPF_ALLOW(-0.20)[+ip4:172.81.177.231]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.983,0]; RCPT_COUNT_ONE(0.00)[1]; LONG_SUBJ(1.70)[227]; IP_SCORE(0.34)[asn: 174(1.73), country: US(-0.05)]; NEURAL_SPAM_SHORT(0.77)[0.774,0]; MX_GOOD(-0.01)[cached: mambo.koitsu.org]; DMARC_POLICY_ALLOW(-0.50)[koitsu.org,quarantine]; NEURAL_SPAM_LONG(0.99)[0.987,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:172.81.176.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes 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, 27 Jul 2019 02:43:46 -0000 (Please retain CCs, I am not subscribed to the list) Below is hard evidence of 3 things on stable/11 (not 12) after r350259: 1. r350259 adds *substantial* time to buildworld. 2. WITHOUT_CLANG_EXTRAS+WITHOUT_CLANG_FULL+WITHOUT_LLDB can help improve the situation after r350259, but it is still no where near as fast as pre-r350259. 3. Kernel build times are fine; issue is with world. TL;DR for lazy folks: stable/11 r350330 world + minimal clang = 1:29:34 stable/11 r350330 world + full clang = 1:46:31 stable/11 r350252 world + minimal clang = 56:52 stable/11 r350252 world + full clang = 1:14:30 I cannot even begin to tell you how big of an impact this has on my low-end dual-core VPS box (world takes hours upon hours). We've been down this road before, many many times, since the introduction of clang/LLVM. Here's just a few that went no where. I couldn't find the more-useful one that had some concrete numbers in it, dating back to pre-2016 (maybe sometime in 2014 or 2015?): https://lists.freebsd.org/pipermail/freebsd-current/2017-January/thread.html#64431 https://lists.freebsd.org/pipermail/freebsd-stable/2017-January/thread.html#86646 https://lists.freebsd.org/pipermail/freebsd-questions/2016-November/thread.html#274684 Does anyone have a good/recent write-up on how to switch to gcc? :-) System ====== * Intel Core 2 Quad Q9550 @ 2.83GHz * 8GB ECC RAM * Samsung SSD 840 EVO 250GB filesystem (UFS2 + SU (not SUJ) + TRIM) + 32GB swap * Running stable/11 r349226 * Misc notes - r350330 happened to be what was "master" at the time of my test - r350252 was the commit on stable/11 immediately before r350259 - Switching to r350252 accomplished via: cd /usr/src && svnlite up -r350252 - System uses kern.maxvnodes=856944, last tuned 2018/06/07 Test #1, building r350330 minimal clang ======================================= # cat /etc/src.conf WITHOUT_ATM=true WITHOUT_BLUETOOTH=true WITHOUT_DEBUG_FILES=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_NDIS=true WITHOUT_NETGRAPH=true WITHOUT_PPP=true WITHOUT_SENDMAIL=true WITHOUT_TESTS=true WITHOUT_WIRELESS=true WITH_OPENSSH_NONE_CIPHER=true WITHOUT_CLANG_EXTRAS=true WITHOUT_CLANG_FULL=true WITHOUT_LLDB=true WITHOUT_LLVM_TARGET_AARCH64=true WITHOUT_LLVM_TARGET_ARM=true WITHOUT_LLVM_TARGET_MIPS=true WITHOUT_LLVM_TARGET_POWERPC=true WITHOUT_LLVM_TARGET_SPARC=true WITHOUT_REPRODUCIBLE_BUILD=true # cat /etc/make.conf KERNCONF=X7SBA_RELENG_11_amd64 CPUTYPE?=core2 SVN_UPDATE=yes STRIP= CFLAGS+= -fno-omit-frame-pointer Result: # rm -fr /usr/obj/* # cd /usr/src # time make -j4 buildworld 19906.874u 1280.928s 1:29:33.51 394.3% 57966+778k 23504+14200io 13867pf+0w # time make -j4 buildkernel 1592.460u 196.047s 7:36.61 391.6% 48704+614k 6627+18158io 7361pf+0w Test #2, building r350330 full clang ==================================== "full clang" means same as Test #1 but with these 3 src.conf lines commented out, i.e. CLANG_EXTRAS, CLANG_FULL, and LLDB are ENABLED: WITHOUT_CLANG_EXTRAS=true WITHOUT_CLANG_FULL=true WITHOUT_LLDB=true Result: # rm -fr /usr/obj/* # cd /usr/src # time make -j4 buildworld 23779.674u 1463.156s 1:46:30.75 394.9% 57621+783k 20093+15423io 7283pf+0w # time make -j4 buildkernel 1594.079u 194.345s 7:36.48 391.7% 48707+614k 5301+18013io 5342pf+0w Test #3, building r350252 minimal clang ======================================= Same configs as Test #1 Result: # rm -fr /usr/obj/* # cd /usr/src # time make -j4 buildworld 12582.693u 882.543s 56:52.35 394.6% 62698+760k 21432+9694io 6923pf+0w # time make -j4 buildkernel 1649.559u 184.934s 7:48.01 391.9% 57053+622k 7566+18291io 5402pf+0w Test #4, building r350252 full clang ==================================== Same configs as Test #2 # rm -fr /usr/obj/* # cd /usr/src # time make -j4 buildworld 16600.975u 1068.754s 1:14:29.53 395.3% 63271+774k 8683+10876io 4707pf+0w # time make -j4 buildkernel 1650.654u 183.966s 7:47.47 392.4% 57117+623k 2829+17951io 1926pf+0w -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator PGP 0x2A389531 | | Making life hard for others since 1977. |