From owner-freebsd-current@freebsd.org Sun Mar 7 20:25:57 2021 Return-Path: Delivered-To: freebsd-current@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 0964B572224 for ; Sun, 7 Mar 2021 20:25:57 +0000 (UTC) (envelope-from kevans@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DttK06lWKz3kpY for ; Sun, 7 Mar 2021 20:25:56 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (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 D5D6A225F for ; Sun, 7 Mar 2021 20:25:56 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f47.google.com with SMTP id cw15so3666756qvb.11 for ; Sun, 07 Mar 2021 12:25:56 -0800 (PST) X-Gm-Message-State: AOAM530Sl0FLEpmQHSnp0x6BIDx0bXo41Bu50u4Lg2NsLCv8qxCbXfcO gQszSdNwGYMd1ZEyGJw6NyxegNBmrdcvyWULk4U= X-Google-Smtp-Source: ABdhPJzKgyAW09AuY1jCf/qVlYeJNSUWPOtUiudaz14iwwfygsY8RaKAeGBZeTCDVV/xfJJcaLjXNIO4pK9nsnNezEQ= X-Received: by 2002:a0c:fd27:: with SMTP id i7mr18506192qvs.22.1615148756349; Sun, 07 Mar 2021 12:25:56 -0800 (PST) MIME-Version: 1.0 References: <20210305.160311.867123118349124334.yasu@utahime.org> <20210306.083323.1112779300812727243.yasu@utahime.org> <20210306005643.45feb56d@bsd64.grem.de> <8a549830a3087998c1e2f80a5fb58199@bsdforge.com> <20210306.185955.1096959917131550098.yasu@utahime.org> In-Reply-To: <20210306.185955.1096959917131550098.yasu@utahime.org> From: Kyle Evans Date: Sun, 7 Mar 2021 14:25:45 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Waiting for bufdaemon To: Yasuhiro Kimura Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 20:25:57 -0000 On Sat, Mar 6, 2021 at 4:02 AM Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST) > > >> My belief is that this commit helps more users than it hurts. Namely, > >> the VMWare and KVM users, which are majority, use fast timecounter, > >> comparing to the more niche hypervisors like VirtualBox. > >> > >> For you, a simple but manual workaround, setting the timecounter to > >> ACPI (?) or might be HPET, with a loader tunable, should do it. > > > > Then please let me know the name of it. > > From: Michael Gmelin > Subject: Re: Waiting for bufdaemon > Date: Sat, 6 Mar 2021 00:56:43 +0100 > > > see `man 4 timecounters': > > > > https://www.freebsd.org/cgi/man.cgi?query=timecounters > > From: Mark Millard via freebsd-current > Subject: Re: Waiting for bufdaemon > Date: Fri, 5 Mar 2021 17:35:14 -0800 > > > Its somewhat messy but there is a technique of using > > the "timecounter" in kib's wording to explore: > ... > > From: Chris > Subject: Re: Waiting for bufdaemon > Date: Fri, 05 Mar 2021 18:54:05 -0800 > > > Not exactly what you're asking for. But sysctl sysctl(3) and loader(8) > > will provide some good clues. > > Thank you for reply. > > On the system in question 'kern.timecounter.choice' and > 'kern.timecounter.hardware' tunables have following values. > > ---------------------------------------------------------------------- > yasu@rolling-vm-freebsd1[1002]% sysctl kern.timecounter.choice > kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-1000000) > yasu@rolling-vm-freebsd1[1003]% sysctl kern.timecounter.hardware > kern.timecounter.hardware: ACPI-fast > yasu@rolling-vm-freebsd1[1004]% > ---------------------------------------------------------------------- > > So I tried setting the latter to 'i8254', 'TSC-low' and 'dummy', and > checked if the problem disappear. But unfortunately it still happened. > On the contrary changing the value from default made thing worse. > If it is set to either 'i8254' or 'TSC-low', timeout of bufdaemon also > happens when I shutdown the system just after bootstrap is completed. > And if it is set to 'dummy', the sytem hung up in the middle of > bootstrap. > > So setting 'kern.timecounter.hardware' tunable doesn't work in my > case. Then is there any way to try? I'm going to be pedantic here, but note that this isn't a tunable. You cannot, AFAIK, influence the timecounter chosen with kenv; it has to be set post-boot via sysctl, and if you're really unlucky it could be that bufdaemon wedges before you manage to change it (though it seems unlikely). I've had some success with setting it to ACPI-fast in sysctl.conf here. From owner-freebsd-current@freebsd.org Sun Mar 7 22:45:11 2021 Return-Path: Delivered-To: freebsd-current@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 7204D5519DF for ; Sun, 7 Mar 2021 22:45:11 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DtxPg1r29z4jjq for ; Sun, 7 Mar 2021 22:45:11 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.nyi.freebsd.org (Postfix) id 3EFEE5518E7; Sun, 7 Mar 2021 22:45:11 +0000 (UTC) Delivered-To: current@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 3EC9B551AB4 for ; Sun, 7 Mar 2021 22:45:11 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [5.45.198.248]) (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 4DtxPf06XXz4jjp; Sun, 7 Mar 2021 22:45:09 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from sas1-0a2be8f95474.qloud-c.yandex.net (sas1-0a2be8f95474.qloud-c.yandex.net [IPv6:2a02:6b8:c08:f21f:0:640:a2b:e8f9]) by forward105j.mail.yandex.net (Yandex) with ESMTP id B6F02B23631; Mon, 8 Mar 2021 01:45:06 +0300 (MSK) Received: from sas1-37da021029ee.qloud-c.yandex.net (sas1-37da021029ee.qloud-c.yandex.net [2a02:6b8:c08:1612:0:640:37da:210]) by sas1-0a2be8f95474.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 3KHUmax7RI-j6HCrffJ; Mon, 08 Mar 2021 01:45:06 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1615157106; bh=oYgAwn9VAlUEjqO9mROtTKdU7a3YwereGm+SrkOGCiM=; h=To:In-Reply-To:Subject:Cc:From:Message-Id:References:Date; b=MgLuxQL0c0cPHcvlPtDmTDmukqYhXf1Mm/m3xh8SXylhgDQ+R/36TixJ/iXnylryH UbhjGH6iQMlE1AyqJHCyC+PtZhhGBvWKjk/FzKaUa0ssPnOW9XaZhJcY7DAaW1Y/Ad QwOOmKiJU5pshmaojP5hLhKCTnh7D+uV1WzmQm5w= Received: by sas1-37da021029ee.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id hlwFbvn1sC-j5JiEg9P; Mon, 08 Mar 2021 01:45:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: ifa leak on VNET teardown From: "Alexander V. Chernikov" In-Reply-To: Date: Sun, 7 Mar 2021 22:45:04 +0000 Cc: "current@FreeBSD.org" , "Bjoern A. Zeeb" Content-Transfer-Encoding: quoted-printable Message-Id: References: <275831613248826@mail.yandex.ru> To: Kristof Provost X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4DtxPf06XXz4jjp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=MgLuxQL0; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 5.45.198.248 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-1.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:5.45.192.0/19]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[ipfw.ru:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[5.45.198.248:from]; ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[5.45.198.248:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; FREEFALL_USER(0.00)[melifaro]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[5.45.198.248:from:127.0.2.255]; RWL_MAILSPIKE_POSSIBLE(0.00)[5.45.198.248:from]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 22:45:11 -0000 > On 6 Mar 2021, at 09:26, Kristof Provost wrote: >=20 > On 13 Feb 2021, at 21:58, Alexander V. Chernikov wrote: >> It turns out we're leaking some ifas for loopback interfaces on VNET = teardown: >>=20 > There=E2=80=99s a recent bug about this as well: 253998. > The problem=E2=80=99s been around for a long time though. The pf tests = trigger it from time to time, although it doesn=E2=80=99t appear to be = 100% consistent, so my current feeling is that it may be racy. >=20 > I see =E2=80=98in6_purgeaddr: err=3D65, destination address delete = failed=E2=80=99 when we do leak, and I=E2=80=99ve also been able to = confirm this is about the ::1 IPv6 loopback address. The fun part is that it turns out that these side effects are caused by = 3 different issues. The unifying factor is that all of them are = loopback-specific. AF_LINK ifa leak exists simply because there is no domain teardown = procedure associated with AF_LINK, so we leak it for every non-vmoved = interface during VNET shutdown. PR 253998 is caused by the fact that rt_flushifroutes_af() is not able = to delete RTF_PINNED routes (e.g. all interface routes). D29116 = addresses that. in6_purgeaddr error is caused by the corner case with loopback&p2p = interfaces. D29121 addresses that.=20 >=20 > Best regards, > Kristof From owner-freebsd-current@freebsd.org Sun Mar 7 22:59:34 2021 Return-Path: Delivered-To: freebsd-current@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 E22BF55249C for ; Sun, 7 Mar 2021 22:59:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.ne1.yahoo.com (sonic312-24.consmr.mail.ne1.yahoo.com [66.163.191.205]) (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 4DtxkF6V7cz4kXl for ; Sun, 7 Mar 2021 22:59:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615157971; bh=DIinTRz06ipt468PIPgYeA4F7Vh5yaCNy8Yasv/fZ1v=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XOOPqrmW0ElLs7xnElk5pm4YDNPhLyRD9QO7cH3ELlrr0CL6nF8xYAmjUl3usWYW/p0t8P+aADy/Ul5WYwYht1SQqDLu567U8NjpxE1+HjX4nilIgD6uanfNoCs2wYOKUUO3jTvUV2g8xegfh0z3z36Us7/q+fEFIW436B8j11gRp3Ey92XLvb5XwTmjKexvPYtyOqJ//BVIvA8gSqKg2wvgbiGCGVF4NCCFtQwwIbK1CS5gwnM8rcNNwBA3NlAmx1iKLMLC8B/7adgmaqHbFoxr9n+hg03apHSfEYEHzF9UXyGMtGpQ8kPijHctwOz1vNTvyJkGZaxLDnGIb6F/Pw== X-YMail-OSG: dYBo8dUVM1llVGwCAgBI2Z8WN.t6VZDlNxKFtt1jZRV542B11naLq4z9g49VYOd kTDRDnxGS39ufLTO5S6B7Yccv9nI4WSpjlYVjGnvm3XAAmsANOiaUNPf3VaJJLTNfU4EV1uA7iyH v6.he9PRzWb.b0joUCtMjiz9xzjpB8TcQkhdkJKyjkad3sayVh0Phd1dGhxjhdXyiGzkeOGGpkVv lwVeelrt9t4_Kz.bcqE1v6EcCmQ6irsJ6pHJ0h9kZP9qkWnAaMekscnuk2T4DV0dmro8W75qvRkg AYdqC6j8drgA5fH9hJEya_F4Mwu8imLYnrIy.ohOqf8UHwuO0Urw0shoH9T83dcrQzHEJwLq9qTX yhdwpK.MLVGqHaGPwqVG1bT8oLybh5NegtzydO_fvpU6HWTc8ea8I4hWKqFZYhN8Z75Nflsqjay_ Eoyl6vxJJF81VQbkzLrnpP5GZeOSnHeBV0Y1ClSV5NkbB267JA9L_HyeWkS6K7hEvQ82JyHGKgEp RyVbk.CC9.Fq3gi2DK7frDIHBLgjrGIH_a3ONtpE2F3LCUojS_CbiUtqQkosxn2nM0FQd6uaxsSI A4Ti5e7iUa3tWRxbLs9sY_9hFq67gOYCc.6cW9jOiWBEIWu8.MSQG8fG8pawt31gfx0amBx2sghy qAG5rXIffM45SFeyl4Oc1NqGnd331EwmZmdo6bKmZ2w1uDuKdzEHeqx3.616iHpmYn5eScJyxU9O BAP1fMuPuUs3s8Nfi7rmpIWrwYSRMZxLgpqJUt1.R1rf3QC_fc9XufwDbIx.JjNlrTXccXNn2rD9 Y9iCMhD1k7LhcmyRU8VA2BEUku9TnbH1W0rp_XiG17esSm6XljEgY1wIgU1BJ2FForS6TiVLCX8U kv.3eBHPTFgGzaHU8Ens.El5TrQR0UaCJt5vc4PtE1lU9j.jCsMARermlBr7FufbBQVDW0MD0Jfx Nh9rqLyvLVqP0mTTg89YIyz2r6m74Gb2u1_FwkiGbvNyowCz6bY07eO_AAVhjAjvR6Ej3SfUbFO3 KBchfRPo6KBTjXORKjFJo6DATiSe_Wc2sWXGdY4X2SDYENhk0dPDSnQ2EMngzQOBv2tMyrywW0c0 Bxj26hRKK1cxrf50jQOlYQmLod76aWaV6GUJUV17FFO5sWFCWtNJXdTF.mqbCPsdrTUydhT3m8t2 GnCmezL_zD1Q_iTrb3pa7h2bHfME1RaQEJKS3TKxwsQdH7TceQ87k5SEqDQJeu8.bG7vOF7lBK9y I.2TQij38hFBBzQpdPtmQo7mCNRH9g4bZCPQ33OR1iTEGXS.2N49zzj50S7DxEhN27kHnJQ8d4uk wAhAblRYCSUhVkLwic5RVx5pGRcolRMo2DsnD2q7Gx36QaQaa17Ba114LnnnG7RLaekGwVEBRZRg y8iQtYSgLG2Rza4tzYCQTn3k._La88Aq9aWcwzCzBv37Bl0sUdlV5X.VNaa0prwkUKvsKkISkssA 4G0wBMT_Mbgg4vS61Cs2S.mXH7ffDA2_h5wG86Ao8N2WzPz2bEnYXR1j1oVBKfroUFo0OCmUf0WJ RCjbLPMEmncTVIRppkD4V8MbsmiInPZG4zEfB49sRIvGiXd_.sRVe993oAsQGx7iIbPreCzi.Zqy v5PddL10pTiOr7XfyzSQAuNhpjXVIEXnhfnOgZzd145vPm7f3m7.UT.XMqfL47E_UsflwDxzjftR NNKy4dJrSdWwnE7jlI0YYnPxAi2zcnrN6.kMofConZulSqy7Qw3FRyhajWSZoCp8blXKNZbU.Fw4 8uwzRQm1BWsUXMyCDKPPqynpX68gohtEwIs1S.7hUlnhN3UUH0MM57qiyz3LLk17KyBwiVMYLLPR fkttB43LrlRglF4g9WWJ1_Dh4FJIg2xIuiVGpTYaAwWaW9BTOAD3EpVVVeTFvzxFCFTFR066HlPx 4TGenRqL4oWA2M0Cyy4DNHGt92x.fWFc8.jK1FdNb0evZiV2Pac5tujVPf_6PNYfmS7IdA0ynr67 TjY58N62tuQnfrHTtAKppiDagIHRSm93nlBDLqfa.y9CqQqF_aHkUvW9L9xGN_b4MKJFhyQwFFy6 ODCTlT.9j56jghjlG8IGkdqr9OpIU.3Tt32K0kcnXeIzvu.OkTuyhr7lsBYEqV3leSVx66zQgoq_ aIsEuqcsDpnRrP6LNfGIVkCaldxYEsYrQf8z6_TpjN2fETJ0b6VSnmyxVcPHXoFb9Qp4Ct1PumAK Va9iTdY51G.3tx7fbk9TefB7DdeIMuJeVTbc.xvO2q56kRRg5HA.YniRoF7RWrqVg1bM_8k8sB6H DiFH4aEw8JmVRszNSTzQkTGI_TvyDQckSzojbD6Xu2fCT8ORPj91OEQM.o3qZftcUoygAshAWxkf qP3X1NMehGa3iUGh2H2sSVPiUsy89cyAERdVsWBFdP1KpaH8eo_b0ZHQkEAXKuuUPWg7Ex7gJDQf FPfYvgnilWbG7N85Y016Gh87RAIi1YS7G0CzlC6ExedU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Mar 2021 22:59:31 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 158d524762dfc709969d99b85168ef5a; Sun, 07 Mar 2021 22:59:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Waiting for bufdaemon Date: Sun, 7 Mar 2021 14:59:27 -0800 References: To: yasu@utahime.org, freebsd-current In-Reply-To: Message-Id: <54E0DAB6-FE34-4BE9-97EA-DFA1F6C2244D@yahoo.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DtxkF6V7cz4kXl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.191.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.191.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.191.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.191.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 22:59:34 -0000 On 2021-Mar-5, at 17:35, Mark Millard wrote: > Yasuhiro Kimura yasu at utahime.org wrote on > Fri Mar 5 23:34:59 UTC 2021 : >=20 >> From: Konstantin Belousov >> Subject: Re: Waiting for bufdaemon >> Date: Fri, 5 Mar 2021 22:43:58 +0200 >>=20 >>> My belief is that this commit helps more users than it hurts. = Namely, >>> the VMWare and KVM users, which are majority, use fast timecounter, >>> comparing to the more niche hypervisors like VirtualBox. >>>=20 >>> For you, a simple but manual workaround, setting the timecounter to >>> ACPI (?) or might be HPET, with a loader tunable, should do it. >>=20 >> Then please let me know the name of it. >>=20 >> I have experienced same situation several time. That is, I faced a >> problem and asked for it on ML. Then I was told to try some tunable. >> So I thought there may be tunable that can be used as workaround in >> this case. But for those who isn't familiar with kernel internal, it >> it quite hard to find it without knowing its name. If all tunable = were >> listed with brief explanation in one document, then I saw it and = could >> pick up possible candidates. But actually they are documented >> separately among many man pages. So the first difficulty is to find >> man page in which possible tunable may be explained. If the problem = is >> releted to some device, it is most hopeful to check its man page. But >> in this case, even after reading the commit message, I had no idea >> which man page to check. >=20 > Its somewhat messy but there is a technique of using > the "timecounter" in kib's wording to explore: >=20 > # sysctl -a | grep -i timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) = TSC-low(1000) dummy(-1000000) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 3054367693 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 43913 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 3575335307 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1696849832 > kern.timecounter.tc.TSC-low.counter: 590106679 > kern.timecounter.tc.TSC-low.mask: 4294967295 >=20 > Given the references to ACPI and HPET in kib's > wording, notable seems to be (from one of my > contexts): >=20 > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) = TSC-low(1000) dummy(-1000000) > kern.timecounter.hardware: TSC-low >=20 > The descriptions of those two look like: >=20 > # sysctl -ad kern.timecounter.choice kern.timecounter.hardware > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected >=20 > The "selected" wording suggests that kern.timecounter.hardware > might be able to be assigned --and kib's wording would imply > that it can be. >=20 > Looking at the descriptions without also looking at the > values need not be clear: >=20 > # sysctl -ad | grep -i timecounter > kern.timecounter:=20 > kern.timecounter.tsc_shift: Shift to pre-apply for the maximum TSC = frequency > kern.timecounter.smp_tsc_adjust: Try to adjust TSC on APs to match BSP > kern.timecounter.smp_tsc: Indicates whether the TSC is safe to use in = SMP mode > kern.timecounter.invariant_tsc: Indicates whether the TSC is P-state = invariant > kern.timecounter.fast_gettime: Enable fast time of day > kern.timecounter.tick: Approximate number of hardclock ticks in a = millisecond > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected > kern.timecounter.alloweddeviation: Allowed time interval deviation in = percents > kern.timecounter.timehands_count: Count of timehands in rotation > kern.timecounter.stepwarnings: Log time steps > kern.timecounter.tc:=20 > kern.timecounter.tc.ACPI-fast: timecounter description > kern.timecounter.tc.ACPI-fast.quality: goodness of time counter > kern.timecounter.tc.ACPI-fast.frequency: timecounter frequency > kern.timecounter.tc.ACPI-fast.counter: current timecounter value > kern.timecounter.tc.ACPI-fast.mask: mask for implemented bits > kern.timecounter.tc.i8254: timecounter description > kern.timecounter.tc.i8254.quality: goodness of time counter > kern.timecounter.tc.i8254.frequency: timecounter frequency > kern.timecounter.tc.i8254.counter: current timecounter value > kern.timecounter.tc.i8254.mask: mask for implemented bits > kern.timecounter.tc.HPET: timecounter description > kern.timecounter.tc.HPET.quality: goodness of time counter > kern.timecounter.tc.HPET.frequency: timecounter frequency > kern.timecounter.tc.HPET.counter: current timecounter value > kern.timecounter.tc.HPET.mask: mask for implemented bits > kern.timecounter.tc.TSC-low: timecounter description > kern.timecounter.tc.TSC-low.quality: goodness of time counter > kern.timecounter.tc.TSC-low.frequency: timecounter frequency > kern.timecounter.tc.TSC-low.counter: current timecounter value > kern.timecounter.tc.TSC-low.mask: mask for implemented bits >=20 > Looking at both can tend to narrow things down. >=20 > Not exactly direct, but useful. It might have been > harder before having kib's wording that used > terminology (notation) involved in the use of the > systctl commands. >=20 > I'll note that in the context I'm using for this: >=20 > # sysctl -ad | wc > 11153 57922 604736 >=20 > # sysctl -a | wc > 13080 29457 449667 >=20 > So: not a trivial amount of material. >=20 Kyle Evens' message points out that I inappropriately did not cover some sysctl command line options that are useful: -T Display only variables that are settable via loader (CTLFLAG_TUN). and: -W Display only writable variables that are not statistical. = Useful for determining the set of runtime tunable sysctls. So: # sysctl -aT | grep timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 # sysctl -aW | grep timecounter kern.timecounter.fast_gettime: 1 kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 0 (kern.timecounter.choice is not settable and so is not in either list. But I do not see an option for listing read-only, non-loader-tunable variables separately.) Between the -aT output and the -aW output, it indicates that /etc/sysctl.conf is appropriate for kern.timecounter.hardware assignment but /boot/loader.conf is not: writable but not a loader tunable. For reference: # sysctl -aT | wc 768 1519 20989 # sysctl -aW | wc 1506 3130 44717 (Some may be in both lists.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Mar 8 00:03:28 2021 Return-Path: Delivered-To: freebsd-current@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 8A044554579 for ; Mon, 8 Mar 2021 00:03:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dtz801Y0pz4pvw; Mon, 8 Mar 2021 00:03:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 12803DXW004576 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Mar 2021 02:03:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 12803DXW004576 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 12803DMs004575; Mon, 8 Mar 2021 02:03:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Mar 2021 02:03:13 +0200 From: Konstantin Belousov To: Kyle Evans Cc: Yasuhiro Kimura , FreeBSD Current Subject: Re: Waiting for bufdaemon Message-ID: References: <20210305.160311.867123118349124334.yasu@utahime.org> <20210306.083323.1112779300812727243.yasu@utahime.org> <20210306005643.45feb56d@bsd64.grem.de> <8a549830a3087998c1e2f80a5fb58199@bsdforge.com> <20210306.185955.1096959917131550098.yasu@utahime.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Dtz801Y0pz4pvw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 00:03:28 -0000 On Sun, Mar 07, 2021 at 02:25:45PM -0600, Kyle Evans wrote: > I'm going to be pedantic here, but note that this isn't a tunable. You > cannot, AFAIK, influence the timecounter chosen with kenv; it has to > be set post-boot via sysctl, and if you're really unlucky it could be > that bufdaemon wedges before you manage to change it (though it seems > unlikely). > > I've had some success with setting it to ACPI-fast in sysctl.conf here. Right, I forgot that timecounter.hardware is not tunable, I thought that it was fixed. https://reviews.freebsd.org/D29122 From owner-freebsd-current@freebsd.org Mon Mar 8 08:52:44 2021 Return-Path: Delivered-To: freebsd-current@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 4929756AE00; Mon, 8 Mar 2021 08:52:44 +0000 (UTC) (envelope-from garbytrash@gmail.com) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvBtg569Tz3qsV; Mon, 8 Mar 2021 08:52:43 +0000 (UTC) (envelope-from garbytrash@gmail.com) Received: by mail-io1-xd29.google.com with SMTP id 81so9067146iou.11; Mon, 08 Mar 2021 00:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Kw2CV4jQinlrPs0sLG99V6cE/RkktfR8YkKjEKN671U=; b=PFQ9y9y8VCxgIt+rts4r5aL9jSjjs3oVAfxEp3+4u6JqViq52xVSStAjI3kJJrQ6F2 D9wuYHf6512SYjdJiMiFyFZ00jQM3TabA7iMLUDdceWqUGQ5kYmUVKh84c7Z+oMgha4C QPTTEt6l0lkGp4nqJMJ7y7Ik/vMKppSh/uQVIjtOjKe4hTzL7JiuY0y+ShklojlCDx/S ResNBgqCaNSYvJFH71iNKHTqg72DPRnaIn7LzHgm/QTYSTsfEEwD6Nxp7cJeg49viaQa hOtcKnIrDprfJoOa9kfgp7kI8I6nyyiqhyBNxw3cVg8avHQ9vgW0YWI/vlt+VN1nDfWI 2ChQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Kw2CV4jQinlrPs0sLG99V6cE/RkktfR8YkKjEKN671U=; b=gA0Gol+VcDaYtHDw/9wcceWR5ua5l4nYbO685OsypoF4A6qrcQuH2a+X9SJvkZMo+x Uyk0KPyEXoRRPvUMqsDb7+Lqr4zUsmlsNTMeIH3NHUwsZ+sd0ACi8OpLYHkwNbQ9dG+E ZVgdVuetqSL6rcvVhv58eS6ZPZ3PRbvgRn0V+8PfILwSdx0LnjPElhgRMY7/B58GaSv6 9RF8ALL51ZkSvaiLdzv+NX7tki9WOcNBa3IopuOJ8uozvV6SnPnn+TP62OioO9fUpQhT 4C0UzHqrzpFrCRysm9eMw+pwoeIQGM84nAtWpMxn/EiNl8k1ekRloc6YqYuUhhCR1lwG Fn0w== X-Gm-Message-State: AOAM532dBSuxq2WRYUcqyX6Z6CaI2eS/86ERMoJaYFRt6uJuqXpDIRHq GzGnUb5i23IrpEBp23Nm3aUUSRzqCRofQnX+a5Lwh6ofbq4= X-Google-Smtp-Source: ABdhPJwAPE/IokyI3EuSYCLFIgyA2+K7aUu0UCorGRxZHvr8WnKXUpJ5SYNl4axRpR6+r204LqTjKfPToIt6XsmbHOg= X-Received: by 2002:a05:6602:2be1:: with SMTP id d1mr17272055ioy.148.1615193562813; Mon, 08 Mar 2021 00:52:42 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a5d:878f:0:0:0:0:0 with HTTP; Mon, 8 Mar 2021 00:52:42 -0800 (PST) From: Zenny Date: Mon, 8 Mar 2021 09:52:42 +0100 Message-ID: Subject: netgraph issues FBSD13.0-ALLSERIES To: freebsd-current Cc: freebsd-stable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvBtg569Tz3qsV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PFQ9y9y8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of garbytrash@gmail.com designates 2607:f8b0:4864:20::d29 as permitted sender) smtp.mailfrom=garbytrash@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d29:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d29:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d29:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-stable]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Mailman-Approved-At: Mon, 08 Mar 2021 10:11:14 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 08:52:44 -0000 Hi, netgraph fails on concurrent node rename as I raised in https://github.com/genneko/freebsd-vimage-jails/issues/2. In summary, it gives an error that reads: "ng_ether_ifnet_arrival_event: can't re-name node vi0_v1" for each interface. Which is similar to bug reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241954 Any clue? Thanks! -- Cheers, /z -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-. CONFIDENTIALITY NOTICE AND DISCLAIMER: Access to this e-mail and its contents by anyone other than the intended recipient is unauthorized as it contains privileged and confidential information, and is subject to legal privilege. Please do not re/distribute it. If you are not the intended recipient (or responsible for delivery of the message to such person), you may not use, copy, distribute or deliver the email and part of its contents to anyone this message (or any part of its contents or take any action in connection to it. In such case, you should destroy this message, and notify the sender immediately. If you have received this email in error, please notify the sender or your sysadmin immediately by e-mail or telephone, and delete the e-mail from any computer. If you or your employer does not consent to internet e-mail messages of this kind, please notify the sender immediately. All reasonable precautions have been taken to ensure no viruses are present in this e-mail and attachments included. As the sender cannot accept responsibility for any loss or damage arising from the use of this e-mail or attachments it is recommended that you are responsible to follow your virus checking procedures prior to use. The views, opinions, conclusions and other informations expressed in this electronic mail are not given or endorsed by any company including the network providers unless otherwise indicated by an authorized representative independent of this message. -.. .. ... -.-. .-.. .- .. -- . .-. | -.. .. ... -.-. .-.. .- .. -- . .-. From owner-freebsd-current@freebsd.org Mon Mar 8 15:58:38 2021 Return-Path: Delivered-To: freebsd-current@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 A1F52576085 for ; Mon, 8 Mar 2021 15:58:38 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvNL52pGcz4nqj for ; Mon, 8 Mar 2021 15:58:36 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 3EA622DDEB for ; Tue, 9 Mar 2021 00:58:26 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1615219106; bh=MZ05giahQ8TaulwincpGLCOtW+Xx5bH45+mqeU1LaR4=; h=Date:To:Subject:From:In-Reply-To:References; b=dsOA5wAjn3CK2o5y9Vms4b+EDP/NqsBFYrucj+pAuRO+qNE+y1L6w2lURJO18utpX VdUNtiMATKfbsMH0rL6iv+vMvwXCxcRsej27KhO5TW+eQHd9QEqVTHVI222JvNH0jr 8XrqOfpmJDah4fYv0CNdcM9SAMnKG1DjpvvLuUHY66Xe3ReA3V2BPo0NXIoaWvV0jw hdJBPY4Ix+J/dHK7t10ECUJuK44qFkkUOrWo4SLi9P4aOCW/I0LdEtObkfDexu30Nm eHGU3pEURNlPeuOsC5Py30TUlP5YsjRQq/KAyapFPXQC76ecMmPOAgp3iUFyOf5WGn NOA+Inmagb/UA== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id E655231077; Tue, 9 Mar 2021 00:58:24 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST) Message-Id: <20210309.005732.1808108188909983665.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: Waiting for bufdaemon From: Yasuhiro Kimura In-Reply-To: References: <20210306.185955.1096959917131550098.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvNL52pGcz4nqj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=dsOA5wAj; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[utahime.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 15:58:38 -0000 From: Konstantin Belousov Subject: Re: Waiting for bufdaemon Date: Mon, 8 Mar 2021 02:03:13 +0200 > On Sun, Mar 07, 2021 at 02:25:45PM -0600, Kyle Evans wrote: >> I'm going to be pedantic here, but note that this isn't a tunable. You >> cannot, AFAIK, influence the timecounter chosen with kenv; it has to >> be set post-boot via sysctl, and if you're really unlucky it could be >> that bufdaemon wedges before you manage to change it (though it seems >> unlikely). >> >> I've had some success with setting it to ACPI-fast in sysctl.conf here. > Right, I forgot that timecounter.hardware is not tunable, I thought that > it was fixed. > > https://reviews.freebsd.org/D29122 I applied the patch of D29122 to 705d06b289e of main, do `make kernel` and reboot. Then I tried the test that consists of following 6 steps. 1. Edit /boot/loader.conf.local 2. shutdow -r now 3. Login as root 4. cd /usr/src 5. make -j 4 -s buildworld 6. shutdown -r now Though I didn't intend it at first, I repeated this test 3 times changing how /boot/loader.conf.local was edited at step 1. And I got the result that was surprising and confusing, at least for me. At first trial I changed /boot/loader.conf.local so it includes 'kern.timecounter.hardware=i8254' in it. Then timeout of bufdaemon didn't happen at step 6. This means adding the line works as workaound for the problem. Next I replaced 'kern.timecounter.hardware=i8254' with 'kern.timecounter.hardware=ACPI-fast'and did test. As I wrote previous mail, 'ACPI-fast' is the initial value of kern.timecounter.hardware on the system in question. So I tried it for comparison purpose expecting the problem happens. But the result is unexpected one. Timeout of bufdaemon didn't happen at step 6 with this case either. So tried yet another case. I removed 'kern.timecounter.hardware=ACPI-fast' from /boot/loader.conf.local and did test again. In this case 'kern.timecounter.hardware' isn't touched at all. So the result should have been same as 2nd case. But it was different. Timeout of bufdeamon happend at step 6 in this case. The result surprised and confused me with following 2 points. (a) Setting initial value (2nd case) should be same as not touching at all (3rd case). But actually they caused different results. (b) 2nd case should have caused same result as one without patch. But actually it caused different one. I found the reason when I execute `sysctl kernel.timecount` and checked the output. If I do it with unpatched kernel, I get following result. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1005]% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 1311282421 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 9931 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.tc.TSC-low.frequency: 1500035122 kern.timecounter.tc.TSC-low.counter: 4026452692 kern.timecounter.tc.TSC-low.mask: 4294967295 yasu@rolling-vm-freebsd1[1006]% ---------------------------------------------------------------------- But if I do it with patched kernel, I get a bit different one. ---------------------------------------------------------------------- yasu@rolling-vm-freebsd1[1001]% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(1000) dummy(-1000000) kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 401131388 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 9975 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.tc.TSC-low.frequency: 1500035491 kern.timecounter.tc.TSC-low.counter: 581590125 kern.timecounter.tc.TSC-low.mask: 4294967295 yasu@rolling-vm-freebsd1[1002]% ---------------------------------------------------------------------- Comparing two output there are two notable differences. The first is the value of kern.timecounter.hardware. With unpatched kernel it is 'ACPI-fast'. On the other hand, with patched kernel it is 'TSC-low'. It means the initial value is changed by applying the patch. it explains why results of 2nd case and 3rd one are different. The second is the value of kern.timecounter.tc.ACPI-fast.counter. With unpatched kernel it is '1311282421' and with patch one it is '401131388'. I don't know what this value means. But I guess the difference is the reason that the result of 2nd case is different from the one of unpatched kernel. So now I know why unexpected result (a) and (b) happen. Furthermore, I comfirmed that setting kern.timecounter.hardware to either 'i8254' or 'ACPI-fast' works as workround of the problem. It is good news anyway. But still one question remains. Why have the value of kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter changed by applying the patch? My understanding is that it only makes 'kern.timecounter.hardware' loader tunable that can be configured with loader.conf. Is it unexpected side effect? Or is everything expected result? --- Yasuhiro Kimura From owner-freebsd-current@freebsd.org Mon Mar 8 16:51:03 2021 Return-Path: Delivered-To: freebsd-current@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 1407B576FCD for ; Mon, 8 Mar 2021 16:51:03 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvPVZ1N9tz4rfZ for ; Mon, 8 Mar 2021 16:51:01 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 2CC902E105 for ; Tue, 9 Mar 2021 01:50:59 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1615222259; bh=abm8xibRqQChc6NuWJBRheEEwfSgH4rphBuYYNQG00U=; h=Date:To:Subject:From:In-Reply-To:References; b=DEvX8/4jhBr+5rjQDJ966dzAqAzcC0uxdlrilCMHcVYKTAgrBcujVeTYeNJWDEqiH XCTMXnlIUJxzjf0TYeyaFLmSl+SyeL20LoCxhcL59dURNkmhQ2hUDojLh2Q8fD0Ih/ GtBKHvhkgOh+U762lBtCWcvmDqSPz/gTyhtlFX0Klq7pWRoyEp/uqCkzWgzSXZKskT zyHMvl/dSnq5nFm53KPqv2Og9CPHqTgOIl9P3uJAIi41keYgc1MrVZkoMynRZmY+gj zS53maCsGA3KcHoNjHzktxjmwAOxdjpr0XLmuzR7G7sS5cXBdSOAS3o4iT/ZwHmn/n ZZsHVCdmvkkdw== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 72D8431225; Tue, 9 Mar 2021 01:50:56 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Tue, 09 Mar 2021 01:50:21 +0900 (JST) Message-Id: <20210309.015021.2131122829257392547.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: Waiting for bufdaemon From: Yasuhiro Kimura In-Reply-To: <20210309.005732.1808108188909983665.yasu@utahime.org> References: <20210309.005732.1808108188909983665.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvPVZ1N9tz4rfZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=DEvX8/4j; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-0.43 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org:c]; MV_CASE(0.50)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-0.73)[-0.730]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[utahime.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 16:51:03 -0000 From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST) > But still one question remains. Why have the value of > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter > changed by applying the patch? My understanding is that it only makes > 'kern.timecounter.hardware' loader tunable that can be configured with > loader.conf. Is it unexpected side effect? Or is everything expected > result? Oops, I made a mistake. > If I do it with unpatched kernel, I get following result. This isn't correct. I did it with reverted kernel (i.e. 705d06b289e of main + revert of 84eaf2ccc6a). If I do it with really unpatch kernel, I get same result as patched one. Sorry for noise. --- Yasuhiro Kimura From owner-freebsd-current@freebsd.org Mon Mar 8 17:07:38 2021 Return-Path: Delivered-To: freebsd-current@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 0C7FD577E8F for ; Mon, 8 Mar 2021 17:07:38 +0000 (UTC) (envelope-from kevans@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvPsj6zM1z4sm8 for ; Mon, 8 Mar 2021 17:07:37 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 DE3E0C4DC for ; Mon, 8 Mar 2021 17:07:37 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f176.google.com with SMTP id j3so8003868qtj.12 for ; Mon, 08 Mar 2021 09:07:37 -0800 (PST) X-Gm-Message-State: AOAM533PjNc1ywg+4rcieSkozs8ylbkOCKBca89siYtP+D57Mh7bqjWo 7KX9tS+XDJ4RYEfbr9y+KWfZJFTNjmw1tyFHufc= X-Google-Smtp-Source: ABdhPJw1LrOUJVSgy8swEP/5MAAclJrG46nsIzCeQam5IOKHSi6dtRNHau76EYnA2uHaxYATg5xC59xtV+/ejbuohf0= X-Received: by 2002:ac8:5947:: with SMTP id 7mr21616990qtz.60.1615223257369; Mon, 08 Mar 2021 09:07:37 -0800 (PST) MIME-Version: 1.0 References: <20210309.005732.1808108188909983665.yasu@utahime.org> <20210309.015021.2131122829257392547.yasu@utahime.org> In-Reply-To: <20210309.015021.2131122829257392547.yasu@utahime.org> From: Kyle Evans Date: Mon, 8 Mar 2021 11:07:23 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Waiting for bufdaemon To: Yasuhiro Kimura Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 17:07:38 -0000 On Mon, Mar 8, 2021 at 10:51 AM Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST) > > > But still one question remains. Why have the value of > > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter > > changed by applying the patch? My understanding is that it only makes > > 'kern.timecounter.hardware' loader tunable that can be configured with > > loader.conf. Is it unexpected side effect? Or is everything expected > > result? > > Oops, I made a mistake. > > > If I do it with unpatched kernel, I get following result. > > This isn't correct. I did it with reverted kernel (i.e. 705d06b289e of > main + revert of 84eaf2ccc6a). If I do it with really unpatch kernel, > I get same result as patched one. > > Sorry for noise. > I've tried tracking down exactly what the problem is that causes the symptoms we're seeing, but no luck so far. I'm eyeballing the following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86: stop punishing VMs with low priority for TSC timecounter") and only punishes VirtualBox guests. diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c index 68fc57e6ea7..6f25360a67c 100644 --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -501,7 +501,12 @@ test_tsc(int adj_max_count) uint64_t *data, *tsc; u_int i, size, adj; - if ((!smp_tsc && !tsc_is_invariant) || vm_guest) + /* + * Misbehavior of TSC under VirtualBox has been observed. In + * particular, threads doing small (~1 second) sleeps may miss their + * wakeup and hang around in sleep state, causing hangs on shutdown. + */ + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX) return (-100); size = (mp_maxid + 1) * 3; data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK); From owner-freebsd-current@freebsd.org Mon Mar 8 19:18:26 2021 Return-Path: Delivered-To: freebsd-current@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 43FE0553DDA for ; Mon, 8 Mar 2021 19:18:26 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (troy.gustik.eu [165.227.162.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvSmc3zlbz3LH7 for ; Mon, 8 Mar 2021 19:18:22 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (localhost [IPv6:::1]) by troy.gustik.eu (Postfix) with ESMTP id BF9F12ADCD8 for ; Mon, 8 Mar 2021 20:18:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gustik.eu; s=troy; t=1615231094; bh=J/BWtl7fmokEnP8Kfvepm1LQBPj/R0GfXtP5/YhHxAk=; h=Subject:From:To:Date; b=jLHqiuOjgXGBRLdFoaiarvhDPH2lTKKAgWKD7Bko9RCb9RYmj9gvLbUzaSf8ak0dS tVEkSSS/1oYnXpXdAF30z/b77NIG0jSJUoggLQWBcxDq75tG18EmIbTcXaZWv3aCFP WzhoDtTcvPjIrJRFVR+mq7S0LsMTzX5MDKW6HzGw= Received: from romy.j20.helspy.pw ([178.143.43.174]) by troy.gustik.eu with ESMTPSA id WV0GLHZ4RmBiBgAADR3MKA (envelope-from ) for ; Mon, 08 Mar 2021 20:18:14 +0100 Message-ID: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> Subject: FreeBSD 13.0-RC1 ethertype IPv6 (0x86dd), length 2942 on 1500 MTU From: Lars Schotte To: freebsd-current@freebsd.org Date: Mon, 08 Mar 2021 20:18:19 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-16.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DvSmc3zlbz3LH7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gustik.eu header.s=troy header.b=jLHqiuOj; dmarc=none; spf=pass (mx1.freebsd.org: domain of lars@gustik.eu designates 165.227.162.104 as permitted sender) smtp.mailfrom=lars@gustik.eu X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gustik.eu:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[165.227.162.104:from]; ASN(0.00)[asn:14061, ipnet:165.227.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[178.143.43.174:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gustik.eu:s=troy]; FREEFALL_USER(0.00)[lars]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[gustik.eu]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[165.227.162.104:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 19:18:26 -0000 Hey friends, I am running this FreeBSD 13.0-RC1 and I am experiencing strange Ethernet frame sizes, TCP sizes well above 2500 on an MTU of 1500. Somehow it seems that this problem only applies on IPv6, IPv4 works fine. I have seen some strange network behaviour with TCP connections randomly dropping under load, and now I see that they are too big. MSS-MAX on PF also does not help. It seems to ignore my 1440 setting. Something is broken here and I do not know what. Is anyone else experiencing this on IPv6? -- Lars Schotte Mudroňova 13 92101 Piešťany From owner-freebsd-current@freebsd.org Mon Mar 8 19:31:43 2021 Return-Path: Delivered-To: freebsd-current@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 99137554EA7 for ; Mon, 8 Mar 2021 19:31:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvT3z2xWxz3Mkc; Mon, 8 Mar 2021 19:31:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f53.google.com with SMTP id i8so11220690iog.7; Mon, 08 Mar 2021 11:31:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ns/asldu5XSzCM1NMGd+Z//2Asb33OXY+GzZP3gsu54=; b=YhxRj0zsy5O9c6njlmH/mui5yFIUCVFfGXMHOfCLNrkfmoVtk9UHKkLZtcgUfwl4wQ h+SJz4VPdMBLbdvk8iaahRCYDbOweZCdInDVGW88Y4YAu5/zHuHr8yeLf7Bw1qwUTycr /qaeI56xws56BRG8EPekOW2YQSfvjIBQP04S/z1RWv1utOhLfx8vewnARxpA8N6hZxQJ SL0w8rnCardoZladrawescPkYvvTxctge3w1icsOitedhiNHnyFi4IXij/gVarLKAavt 9yfDMZvsqxAPASemrzVKPD0T3vJ9CfhGfUjpv524Cul+1tvBluuHeJ+LJ94B7CEh33yd GoDQ== X-Gm-Message-State: AOAM532gFumqLalgDdJPYEua+WRRPFlkXbNdG3xc0jW7xV+A1UOCIeYd U9geYvWScoHThJ4jNePdTXRt1eGDnu94fNDROd0sOJ8AI+D45w== X-Google-Smtp-Source: ABdhPJwh+VhZRlNEl25AuPvckO5L/CqkJxvvjsdOPia8VJKq4RC5dedDE8oMQb6uVhXLf5pq1xIhqGmkW0JNmZA+A5w= X-Received: by 2002:a6b:fc16:: with SMTP id r22mr18998460ioh.102.1615231901873; Mon, 08 Mar 2021 11:31:41 -0800 (PST) MIME-Version: 1.0 References: <20210309.005732.1808108188909983665.yasu@utahime.org> <20210309.015021.2131122829257392547.yasu@utahime.org> In-Reply-To: From: Ed Maste Date: Mon, 8 Mar 2021 14:31:15 -0500 Message-ID: Subject: Re: Waiting for bufdaemon To: Kyle Evans Cc: Yasuhiro Kimura , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvT3z2xWxz3Mkc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 19:31:43 -0000 On Mon, 8 Mar 2021 at 12:07, Kyle Evans wrote: > > diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c > index 68fc57e6ea7..6f25360a67c 100644 > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -501,7 +501,12 @@ test_tsc(int adj_max_count) > uint64_t *data, *tsc; > u_int i, size, adj; > > - if ((!smp_tsc && !tsc_is_invariant) || vm_guest) > + /* > + * Misbehavior of TSC under VirtualBox has been observed. In > + * particular, threads doing small (~1 second) sleeps may miss their > + * wakeup and hang around in sleep state, causing hangs on shutdown. > + */ > + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX) > return (-100); > size = (mp_maxid + 1) * 3; > data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK); This seems like a sensible change to me. To make it explicilty clear what the comment/workaround applies to, maybe rewrite it as: if (!smp_tsc && !tsc_is_invariant) return (-100); /* * Misbehavior of TSC under VirtualBox has been observed. In * particular, threads doing small (~1 second) sleeps may miss their * wakeup and hang around in sleep state, causing hangs on shutdown. */ if (vm_guest == VM_GUEST_VBOX) return (-100); From owner-freebsd-current@freebsd.org Mon Mar 8 20:13:48 2021 Return-Path: Delivered-To: freebsd-current@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 2F7B855606A; Mon, 8 Mar 2021 20:13:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvV0W1gjBz3PyR; Mon, 8 Mar 2021 20:13:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f45.google.com with SMTP id k2so11375705ioh.5; Mon, 08 Mar 2021 12:13:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NoIvf0hya5FBzhXr4KBKDN5VKuUnizqtWcuTC+FVVvs=; b=FhgsDtwlJHRRxM6Iq65L+HSnYXwEhGIYfxmYOoBRbO+0tFu9QOifJ9yWTlRVKYgpZS OeJTy4/4+Eucpi4TA30gb0t9nTur/OMUDg7m/uVxTlSm01zfOQG++U3s3XyFzaPqT+Pm di3JZzIfZtJpZ+mGw/BwcuWos1QuCN+MCqkKB/AoNw7zoQYyXEu+CTUg9PH87Qzm0mE/ jcflZk/BFRw8KjYpDa9zpJ9Ht57ybKM2KC2A1znb9vdhwj0fh7fWDV8IPlsz1dCxRIt2 bBBO11l0fw/TjHsnWUnUV+KaJpFg1ta1dBCOSZVpumxHzrHXKYJLm3+RZUUgrMyQoseP UXYw== X-Gm-Message-State: AOAM531ghX/2e/92CC89akv3JDVUClWTBUvZFLknmZaaTYuQ28s00qxr GQfIbYp8kHMEmGb0uNZ75mZdW21xMpddeUzoR6Xix2BZ6W3swg== X-Google-Smtp-Source: ABdhPJxBKEhCu4WYS6hz9jX7xhxIyXmY25tqv3QLuK9UbCMaCg5VVkknFJXYM/O1XVY6SD6DEUOQc0dlnuiNUNc3jOc= X-Received: by 2002:a6b:fc16:: with SMTP id r22mr19135510ioh.102.1615234424871; Mon, 08 Mar 2021 12:13:44 -0800 (PST) MIME-Version: 1.0 From: Ed Maste Date: Mon, 8 Mar 2021 15:13:19 -0500 Message-ID: Subject: Rationalizing sed -i/-I (in-place editing) argument handling To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvV0W1gjBz3PyR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.45:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[209.85.166.45:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:13:48 -0000 A relatively minor but longstanding incompatibility between FreeBSD and many other systems is the way sed handles backup files for in-place editing -- sed's -I and -i options. GNU sed and other BSDs accept an optional argument: -I.bak will save a backup file with a .bak extension, and -I with no argument will not create a backup file. FreeBSD currently accepts either -I.bak or -I .bak to save a backup with the given extension, and -I "" (an empty argument) to specify no backup. I've been tripped up by this in the past and I know many others have. Most recently tobik@ filed PR 254091 for this. Now, I think a single change to make -i/-I to be compatible with other sed implementations in one step is too much of a POLA violation, but I think it can reasonably be done in stages: 1. Update the man page to indicate that -i/-I should not have a space between the flag and the extension. This is compatible with current FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. No backup is still a special case and remains as -I "". I've opened https://reviews.freebsd.org/D29128 with proposed man page changes. 2. Continue accepting -I .bak, but emit a warning suggesting the use of -I.bak instead. 3. Change -I/-i to getopt optional arguments, but keep a special case for -I/-i "". At this point -I .bak becomes invalid as with other seds, and specifying no backup can be done with either -I "" or -I with no argument. This relies on an empty argument having no other sensible interpretation. 4. Continue accepting -I "" to specify no backup, but emit a warning suggesting the use of -I with no argument. 5. Retire the special case for -I "". These steps could be done over an extended period of time (such as one major release to another) - this is most important between steps 2 and 3. Please let me know what you think, and if there's something I've missed. From owner-freebsd-current@freebsd.org Mon Mar 8 20:25:41 2021 Return-Path: Delivered-To: freebsd-current@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 C4665556B92; Mon, 8 Mar 2021 20:25:41 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvVGF2hvsz3h0P; Mon, 8 Mar 2021 20:25:40 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 128KQ5MT095162; Mon, 8 Mar 2021 12:26:11 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Mon, 08 Mar 2021 12:26:05 -0800 From: Chris To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <0aa81e9d7124b144443da405d9ba5d43@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvVGF2hvsz3h0P X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:25:41 -0000 On 2021-03-08 12:13, Ed Maste wrote: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page > changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. > > 4. Continue accepting -I "" to specify no backup, but emit a warning > suggesting the use of -I with no argument. > > 5. Retire the special case for -I "". > > These steps could be done over an extended period of time (such as one > major release to another) - this is most important between steps 2 and > 3. > > Please let me know what you think, and if there's something I've missed. +1 This seems more than a reasonable course of action. :-) Thanks! From owner-freebsd-current@freebsd.org Mon Mar 8 20:55:55 2021 Return-Path: Delivered-To: freebsd-current@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 A5FF4557C4C for ; Mon, 8 Mar 2021 20:55:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2j.ore.mailhop.org (outbound2j.ore.mailhop.org [54.148.113.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvVx71Srhz3khX for ; Mon, 8 Mar 2021 20:55:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1615236954; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=IqrMg/xbpz81NJnMzDab/tQPUE5UC6wUfFGLFtvycp5jz/F9Lj5tHMBoVzhGM/wSYUnndO55i+c9D jh1mtvZ8IhOZkF+mN9T6asrAA+twodOocdz86sACdemZzXzqb5Gj0feZHb6y9cZKij8kdcWbooTnPj +pqsj/YMmiAKd4R72awU+DfnEfVsW4/awRvbbGXcr28DTdXooJOllQqa6gzYqLMN8tyGAZ78ELUvaZ EXo6su4b7bCOYeNueDXQVMiXnakCDwdlAtW7QqYX6NS1Zny+j8LDQjlHnVTkC0Ca9R4J4Wh200wavx 5Vh6DgIEjPJ0ylTpMad/iqw5LpKfZOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=WTmv4J9ExjuHPSlCZmsyq7KQjd854vtRJhfxWGo4l6s=; b=psCZdVRm7hlhjss5DHgqG49Kf6yXWkGHMhHCJ0eMPr3HoOM6mcfRztcCfrsvlZkvSwha8QMs9aKen KSRp0z0CgRd7paSyyCftEkQyHrw8uXboTmhCm3IutLa1CXU/2Mkbgy9PTKVMKzsARx4riRHbqJz28A alYdQYlg11hcdY8mPNOwsqune+ucKCR7DWfq9iK0szFz2LT5V/J4ufwRfIqAAF5Mc0CMTWZQ0eSoT6 OAR00KKQ1+ePA9KqF7DuGBSbFPBR4+n1/r62a51lVahTgp+wkVE2gIt9Ah9iEREACqjZRZ9Siy5MtD lo4fda77ARQ0ErQW139Iq5zp8914k6A== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-low; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=WTmv4J9ExjuHPSlCZmsyq7KQjd854vtRJhfxWGo4l6s=; b=QZ2ITA4xFu/SnsJ5RuUqT9wimAQ6+pf1oMQHT63WpXeKilZt7jG5575MpqhGQUDHiTKKoaGoDpAc6 k2p8C5EEreWtpVEGOT0g8DunMvk0EfxxK/2Y1zHPSxxJODE8/6kHMJCSF1vttHFhZWEvOTliWkdYVI tsGUD4l3ET6dFq0F6Tmm3dT3W4LCvv0U5N4w6dAkUaTeZp0QHQ8k/VO5qHK1zWnUlWkTAFTjF1yvw0 1wi/GOj8kACt9giVc9r4M3skBPvXRW0BJ942qfYRz52SzmtDKzgOd/I1/1sfYqwl4AVkUnRjQT6+hO tf+8uh9toIodUsi2tCjH8tK4jnhfdvg== X-Originating-IP: 67.177.211.60 X-MHO-RoutePath: aGlwcGll X-MHO-User: ab31223f-8050-11eb-ad62-59765e228ffb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id ab31223f-8050-11eb-ad62-59765e228ffb; Mon, 08 Mar 2021 20:55:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 128KtqFB076198; Mon, 8 Mar 2021 13:55:52 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling From: Ian Lepore To: Ed Maste , FreeBSD Hackers , FreeBSD Current Date: Mon, 08 Mar 2021 13:55:52 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvVx71Srhz3khX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:55:55 -0000 On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup > file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page > changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. > > 4. Continue accepting -I "" to specify no backup, but emit a warning > suggesting the use of -I with no argument. > > 5. Retire the special case for -I "". > > These steps could be done over an extended period of time (such as > one > major release to another) - this is most important between steps 2 > and > 3. > > Please let me know what you think, and if there's something I've > missed. > As someone who has to take care of common software that runs on everything from freebsd 8 through -current, I HATE the very idea of this. If we keep whittling away at the backwards compatibility freebsd is so famous for, I'll have abosolutely zero arguments left for why $work shouldn't just switch to the much more popular and better- supported linux. I also hate the idea of requiring no space between -I and its related value. That seems like a huge POLA violation compared to how virtually every other command's options and arguments work. -- Ian From owner-freebsd-current@freebsd.org Mon Mar 8 21:19:56 2021 Return-Path: Delivered-To: freebsd-current@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 E84A1558863; Mon, 8 Mar 2021 21:19:56 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvWSq6yyRz3m1w; Mon, 8 Mar 2021 21:19:55 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.1]) by sdaoden.eu (Postfix) with ESMTP id 9C02E16056; Mon, 8 Mar 2021 22:19:47 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 68DDDFD24; Mon, 8 Mar 2021 22:19:46 +0100 (CET) Date: Mon, 08 Mar 2021 22:19:46 +0100 From: Steffen Nurpmeso To: Ian Lepore Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Message-ID: <20210308211946.6CWxa%steffen@sdaoden.eu> In-Reply-To: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> Mail-Followup-To: Ian Lepore , Ed Maste , FreeBSD Hackers , FreeBSD Current User-Agent: s-nail v14.9.22-99-g733424fe OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4DvWSq6yyRz3m1w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.144.132.164:from]; SPAMHAUS_ZRD(0.00)[217.144.132.164:from:127.0.2.255]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 21:19:57 -0000 Ian Lepore wrote in <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org>: |On Mon, 2021-03-08 at 15:13 -0500, Ed Maste wrote: |> A relatively minor but longstanding incompatibility between FreeBSD |> and many other systems is the way sed handles backup files for |> in-place editing -- sed's -I and -i options. GNU sed and other BSDs |> accept an optional argument: -I.bak will save a backup file with a |> .bak extension, and -I with no argument will not create a backup |> file. |> FreeBSD currently accepts either -I.bak or -I .bak to save a backup |> with the given extension, and -I "" (an empty argument) to specify no |> backup. |> |> I've been tripped up by this in the past and I know many others have. |> Most recently tobik@ filed PR 254091 for this. Now, I think a single ... |> change to make -i/-I to be compatible with other sed implementations |> in one step is too much of a POLA violation, but I think it can |> reasonably be done in stages: |> |> 1. Update the man page to indicate that -i/-I should not have a space |> between the flag and the extension. This is compatible with current |> FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. |> No backup is still a special case and remains as -I "". ... |As someone who has to take care of common software that runs on |everything from freebsd 8 through -current, I HATE the very idea of |this. If we keep whittling away at the backwards compatibility freebsd |is so famous for, I'll have abosolutely zero arguments left for why |$work shouldn't just switch to the much more popular and better- |supported linux. | |I also hate the idea of requiring no space between -I and its related |value. That seems like a huge POLA violation compared to how virtually |every other command's options and arguments work. I hate it too. But just wanted to note that sccs used this (and still does, even standardized) decades ago already (and i always did it wrong). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Mon Mar 8 21:41:59 2021 Return-Path: Delivered-To: freebsd-current@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 BD687559A11; Mon, 8 Mar 2021 21:41:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvWyG6wntz3p92; Mon, 8 Mar 2021 21:41:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f178.google.com with SMTP id e7so10241169ile.7; Mon, 08 Mar 2021 13:41:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KkiHKxAfzL9AbUTn3iuTxrRObYaHODZqZC7w4/9hMvM=; b=dxFSxnKel+t+xaOu/6+e5+Go2emMKs99EKg10oPXR7V1j2nJHQtq0WtKS+1EBnzTvI QKM0IUO2cBUGOUAgrxfqH7yV5R5ZRRC9ynz6p41bCiis4cmHhwdwpKf3lMULodShQ3DW bEniycljWrPfRDEtlPDNsBdHTxN7qJn5EFOTbWyhPD0sLU921TjqfekYZm4Q9ia46zB6 q8p7Mme7yOR4CMkHp7VarEktCRqU9iL+DNMkCkhC8zF+N3BBmGfr75h81/qpMz02JRM5 sX8ocxJic/HzTRfJfAlL8NlmYhzcxxZka2/xdni9sgf99V99beIICSjP7VqVDaj8pPxY j9Mw== X-Gm-Message-State: AOAM532Lsdeyh8+Nlhx03iwphaiwCkm3xAH2ojR6Dt04EKqFZdvpQhYP AAviOyo+gMiugPVtc1QGGUInzIaI/ppstj/rIkMYs3fNPqU= X-Google-Smtp-Source: ABdhPJzMIh7fm/k03IKSg3Lrrgwak9Vm8RTfb6cAQYHpwsPDoEml1PSH80NzPL2VcovkFa8lHIXUMXiSHCK5+UVgCcc= X-Received: by 2002:a92:ce02:: with SMTP id b2mr23420953ilo.182.1615239717265; Mon, 08 Mar 2021 13:41:57 -0800 (PST) MIME-Version: 1.0 References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> In-Reply-To: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> From: Ed Maste Date: Mon, 8 Mar 2021 16:41:29 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling To: Ian Lepore Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvWyG6wntz3p92 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.178:from]; SPAMHAUS_ZRD(0.00)[209.85.166.178:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.178:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.178:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 21:41:59 -0000 On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > I also hate the idea of requiring no space between -I and its related > value. That seems like a huge POLA violation compared to how virtually > every other command's options and arguments work. On the other hand, -i.ext with no space is compatible with FreeBSD today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext works only with FreeBSD and macOS. From owner-freebsd-current@freebsd.org Mon Mar 8 22:00:35 2021 Return-Path: Delivered-To: freebsd-current@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 75F5D55A2E7; Mon, 8 Mar 2021 22:00:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvXMk3kzhz3psJ; Mon, 8 Mar 2021 22:00:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 128M0Qvw032513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Mar 2021 14:00:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 128M0Q4F032512; Mon, 8 Mar 2021 14:00:26 -0800 (PST) (envelope-from jmg) Date: Mon, 8 Mar 2021 14:00:26 -0800 From: John-Mark Gurney To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Message-ID: <20210308220026.GK5246@funkthat.com> Mail-Followup-To: Ed Maste , FreeBSD Hackers , FreeBSD Current References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 08 Mar 2021 14:00:26 -0800 (PST) X-Rspamd-Queue-Id: 4DvXMk3kzhz3psJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.51 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.29)[0.285]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:00:35 -0000 Ed Maste wrote this message on Mon, Mar 08, 2021 at 15:13 -0500: > A relatively minor but longstanding incompatibility between FreeBSD > and many other systems is the way sed handles backup files for > in-place editing -- sed's -I and -i options. GNU sed and other BSDs > accept an optional argument: -I.bak will save a backup file with a > .bak extension, and -I with no argument will not create a backup file. > FreeBSD currently accepts either -I.bak or -I .bak to save a backup > with the given extension, and -I "" (an empty argument) to specify no > backup. > > I've been tripped up by this in the past and I know many others have. > Most recently tobik@ filed PR 254091 for this. Now, I think a single > change to make -i/-I to be compatible with other sed implementations > in one step is too much of a POLA violation, but I think it can > reasonably be done in stages: > > 1. Update the man page to indicate that -i/-I should not have a space > between the flag and the extension. This is compatible with current > FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below. > No backup is still a special case and remains as -I "". > > I've opened https://reviews.freebsd.org/D29128 with proposed man page changes. > > 2. Continue accepting -I .bak, but emit a warning suggesting the use > of -I.bak instead. > > 3. Change -I/-i to getopt optional arguments, but keep a special case > for -I/-i "". At this point -I .bak becomes invalid as with other > seds, and specifying no backup can be done with either -I "" or -I > with no argument. This relies on an empty argument having no other > sensible interpretation. I will say that IMO, I really dislike a command line argument having an optional argument. It can cause parsing confusion and possibly security issues... Copying this behavior, IMO, is not good... So my vote is against this misfeature.. How is the program suppose to tell when the extension is "-e", or -e is a different option and not the argument to -I? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Mon Mar 8 22:08:56 2021 Return-Path: Delivered-To: freebsd-current@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 CA06A55A6DF; Mon, 8 Mar 2021 22:08:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvXYM45w0z3qQv; Mon, 8 Mar 2021 22:08:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f169.google.com with SMTP id c10so10302516ilo.8; Mon, 08 Mar 2021 14:08:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yPZ3T06czy5q8iTqR3SCuCl70XWXixDr+mfJXSItxSo=; b=ebEn3l5VkyAOYxCrQa7jYJxQI77XOUu5VI+XQtsJ4UL5JRL/WxyFTUwrDYFeCknAUN Yc8MNlxOrRxh5r0DOg2w8XzBP/DGnHSl2eO7W2YopEXmqBzqdnouTDj10xjS6sc6gNUJ 7wQ5UHlpS75QLkJhcVZJUoAMXj/ZI4oNOWr0QAHuzShk4wzlWXMua0xHL/P93PMJ1JmZ YI32w2K2cxufBIBTJonhAWUyGUiEbfdimGfk5nqLhHgb1iaby8YYgDs80H8fefjp/wg6 Huu4MnrdcN+7BMzJ6ViTfOo9GUE8/jwY70Exb2Q9CtHmM6aX4erSUO0YeUvNXidkJ0gq zWxw== X-Gm-Message-State: AOAM532Vue6+g6mFe7Gwb4AbxCAzM1BWkGWrrXIhMFCF6n6uA/F8GUlO /I2RsAo1Y1dLrP7fxaLOBCR2npnkmFDmaBw2qPsE1yiv3F8= X-Google-Smtp-Source: ABdhPJzUYT8YBC6JjQzfvWipPZNsrE3KvjJGqoFMshdHhIyFidtkkRGXEsCrrclWvaMnvFxKgnf0lGX/yTW5EITeK3Y= X-Received: by 2002:a05:6e02:1845:: with SMTP id b5mr22463661ilv.11.1615241334003; Mon, 08 Mar 2021 14:08:54 -0800 (PST) MIME-Version: 1.0 References: <20210308220026.GK5246@funkthat.com> In-Reply-To: <20210308220026.GK5246@funkthat.com> From: Ed Maste Date: Mon, 8 Mar 2021 17:08:27 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling To: Ed Maste , FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvXYM45w0z3qQv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[209.85.166.169:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.169:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.169:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.169:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:08:56 -0000 On Mon, 8 Mar 2021 at 17:00, John-Mark Gurney wrote: > > How is the program suppose to tell when the extension is "-e", or -e > is a different option and not the argument to -I? -i-e is an in-place edit with extension "-e" -i -e is an in-place edit with no extension From owner-freebsd-current@freebsd.org Mon Mar 8 22:14:33 2021 Return-Path: Delivered-To: freebsd-current@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 6F23555AEAE for ; Mon, 8 Mar 2021 22:14:33 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (troy.gustik.eu [165.227.162.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvXgr3jKqz3rSt for ; Mon, 8 Mar 2021 22:14:32 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (localhost [IPv6:::1]) by troy.gustik.eu (Postfix) with ESMTP id D06C72ADCD6 for ; Mon, 8 Mar 2021 23:14:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gustik.eu; s=troy; t=1615241670; bh=U2g+bWDbCpUenbQR67SaY1gULPx+0r8NaYTRBcxe4l4=; h=Subject:From:To:Date:In-Reply-To:References; b=HS4GkbLe8JRYYsRjj8OKCps6mSmaEilPBvLWLn2o6tim/JEmQmBVAvFFUUMA6yp6r /sb0uvTECPI70j0x+8MRmCrrOvc1XO1w0GQnHUPRhM67gueHh4omHLqrTQUUdsTCnH uH9M/1XIqMmKd7ia4CaVF3kCpEkzqfvse1tvxwNo= Received: from romy.j20.helspy.pw ([2a01:c844:241d:bf20:4767:2cb8:97e4:8e2d]) by troy.gustik.eu with ESMTPSA id yPMGMMahRmCnCgAADR3MKA (envelope-from ) for ; Mon, 08 Mar 2021 23:14:30 +0100 Message-ID: Subject: Re: FreeBSD 13.0-RC1 ethertype IPv6 (0x86dd), length 2942 on 1500 MTU From: Lars Schotte To: freebsd-current@freebsd.org Date: Mon, 08 Mar 2021 23:14:32 +0100 In-Reply-To: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> References: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-16.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DvXgr3jKqz3rSt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gustik.eu header.s=troy header.b=HS4GkbLe; dmarc=none; spf=pass (mx1.freebsd.org: domain of lars@gustik.eu designates 165.227.162.104 as permitted sender) smtp.mailfrom=lars@gustik.eu X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gustik.eu:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[165.227.162.104:from]; ASN(0.00)[asn:14061, ipnet:165.227.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gustik.eu:s=troy]; FREEFALL_USER(0.00)[lars]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[gustik.eu]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[165.227.162.104:from:127.0.2.255]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:14:33 -0000 It looks like vtnet driver ignored MTU setting on 13.0-RC1. I see this on both, IPv4 and IPv6 ... however IPv4 works maybe because DigitalOcean and Vultr do split those frames on KVM virt host, but don't do this for IPv6 (I suppose). Everything about this is strange but so far I have been able to reproduce this problem only with vtnet driver. On Mon, 2021-03-08 at 20:18 +0100, Lars Schotte wrote: > Hey friends, > > I am running this FreeBSD 13.0-RC1 and I am experiencing strange > Ethernet frame sizes, TCP sizes well above 2500 on an MTU of 1500. > Somehow it seems that this problem only applies on IPv6, > IPv4 works fine. > > I have seen some strange network behaviour with TCP connections > randomly dropping under load, and now I see that they are too big. > MSS-MAX on PF also does not help. It seems to ignore my 1440 setting. > > Something is broken here and I do not know what. > > Is anyone else experiencing this on IPv6? > -- Lars Schotte Mudroňova 13 92101 Piešťany From owner-freebsd-current@freebsd.org Mon Mar 8 22:22:28 2021 Return-Path: Delivered-To: freebsd-current@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 2AB7B55B211 for ; Mon, 8 Mar 2021 22:22:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvXrz3vqnz3s44 for ; Mon, 8 Mar 2021 22:22:27 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pj1-x1036.google.com with SMTP id jx13so477817pjb.1 for ; Mon, 08 Mar 2021 14:22:27 -0800 (PST) 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=P2HDjhht6w+DfWeYUVyov2MESaZk9Q8IR50lKK3cAcs=; b=o5Wvop1Bt9ci7e5cJSzNiiLbPpHu7lJFX6+LjD16cywYLXwgwByNBg7o6wbFOU/DzF qvPE8OzHEujPporzuGbXKgXhw1JHL2U4ZZ/m94jI0Rurrh0s/Rl5c+zVeGk5kxo9WFJm 3a+7cWdXJHwTL4NewOpGEIXjiUfLNXVPyNn35dm9QQ49AyNwSKUgu/K+8IKicX4MUzQr LEDSMaEJ/t/JJ1ia0fS7luv0mPRt9ftzoYjrnmj5dpmkvAh8g6TzjAR9Y3+iO3oSZucE NBcttGhBh9jYQdlXG68y1L3/JZEHnzLvzMWY+sYQhARIidh3GlGlg8RJv1+rAmtQzxXR pqDg== 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=P2HDjhht6w+DfWeYUVyov2MESaZk9Q8IR50lKK3cAcs=; b=rE5oXUP5yZcYUxWY99tO51qcPu1tGsZk/cR8PDwDXMMairpqrP3LRGefDqFOdPfIec x09fmkPF4rZLLos+NffiPD0cTpxVQGnioCxXpaD/oPOQn+z+TKyX9VgIdBYXj9vqI8PD 94hxe+gOj0m4RjvAOIXmPF+nh4MZlk5iESv/hkaLDK28SY08EcaoQvjzs94C26TbS5Gg 2x6DgMBlZDGlnhiLrOTQ0dIeg1xGyBd4CxuoPiXSbl98ptEk9fPRqGdGSmpy6lrEicfh SMu8FZsbqvfyEOXuGGZs3CqkmujTy+aTwSSCqhd5t2DgfF3MTdsdG7qT2y8jvvp44ymX LMbQ== X-Gm-Message-State: AOAM530hP+7Ga9qcy1PrnKfFF9h8Xs18cezEsfjmD44D0TZ7yJPHhoqk mQMjaB2mnDoFpYjSFPEXVHJbHEee1mJKVqWz5DBU9InT X-Google-Smtp-Source: ABdhPJwmiIlp/0PZhZqE+Hv1IzBl5XwdrkG68nr1ibVPBEh0coPXinnovB/PMBDHScG8wOeT1wVVbT3i7HM858Fizhg= X-Received: by 2002:a17:90a:8b83:: with SMTP id z3mr1146006pjn.75.1615242146333; Mon, 08 Mar 2021 14:22:26 -0800 (PST) MIME-Version: 1.0 References: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> In-Reply-To: From: Ryan Stone Date: Mon, 8 Mar 2021 17:22:15 -0500 Message-ID: Subject: Re: FreeBSD 13.0-RC1 ethertype IPv6 (0x86dd), length 2942 on 1500 MTU To: Lars Schotte Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DvXrz3vqnz3s44 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=o5Wvop1B; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::1036:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::1036:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:22:28 -0000 Hi Lars, Do you see the TSO6 option enabled on your vtnet interface? Do you see normal packet sizes if you disable it with "ifconfig vtnet0 -tso6"? Does it actually fix your IPv6 issue? From owner-freebsd-current@freebsd.org Mon Mar 8 22:28:54 2021 Return-Path: Delivered-To: freebsd-current@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 B2B5C55B626 for ; Mon, 8 Mar 2021 22:28:54 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (troy.gustik.eu [165.227.162.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvY0P58HPz3s3j for ; Mon, 8 Mar 2021 22:28:53 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (localhost [IPv6:::1]) by troy.gustik.eu (Postfix) with ESMTP id 370A62ADCD6; Mon, 8 Mar 2021 23:28:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gustik.eu; s=troy; t=1615242532; bh=YVhx7YJnAEcgOPJgVG4SDOFTzImLgITyNapvWimoBiw=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ORRejA8JjMuG5xlM+q/aJgEafGMb6pjO8PSpw2OFjkXra/V5UMVSSGSXvL86I7DIT vksWMFxNCjJSJySyCYavr1srVoWCiBeObYjyOYzG39DBw8BT5Ktt28UBKwGZz/UCPi mu/dMzyXfeNwBqoapdfOhoD54Ll6cqYMKhpo6bks= Received: from romy.j20.helspy.pw ([2a01:c844:241d:bf20:4767:2cb8:97e4:8e2d]) by troy.gustik.eu with ESMTPSA id PnfJCiSlRmBKDQAADR3MKA (envelope-from ); Mon, 08 Mar 2021 23:28:52 +0100 Message-ID: <81ffb5784c66441bf5fb399c12b2b06786cc8f35.camel@gustik.eu> Subject: Re: FreeBSD 13.0-RC1 ethertype IPv6 (0x86dd), length 2942 on 1500 MTU From: Lars Schotte To: Ryan Stone Cc: FreeBSD Current Date: Mon, 08 Mar 2021 23:28:56 +0100 In-Reply-To: References: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-16.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DvY0P58HPz3s3j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gustik.eu header.s=troy header.b=ORRejA8J; dmarc=none; spf=pass (mx1.freebsd.org: domain of lars@gustik.eu designates 165.227.162.104 as permitted sender) smtp.mailfrom=lars@gustik.eu X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gustik.eu:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[165.227.162.104:from]; ASN(0.00)[asn:14061, ipnet:165.227.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gustik.eu:s=troy]; FREEFALL_USER(0.00)[lars]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gustik.eu]; SPAMHAUS_ZRD(0.00)[165.227.162.104:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:28:54 -0000 Hi, thanks for you fast reaction. I was sceptical about this, since it contrary to my expectations indeed does affect IPv4 as well, but I tried it anyway and the result is NEGATIVE. Removing TSO6 does not help with it, it still spills out crazy sized Ethernet frames of ~4000 and so on. On Mon, 2021-03-08 at 17:22 -0500, Ryan Stone wrote: > Hi Lars, > > Do you see the TSO6 option enabled on your vtnet interface? Do you > see normal packet sizes if you disable it with "ifconfig vtnet0 > -tso6"? Does it actually fix your IPv6 issue? -- Lars Schotte Mudroňova 13 92101 Piešťany From owner-freebsd-current@freebsd.org Mon Mar 8 22:38:09 2021 Return-Path: Delivered-To: freebsd-current@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 7B5A255B9AC for ; Mon, 8 Mar 2021 22:38:09 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (troy.gustik.eu [165.227.162.104]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvYC45PZZz3sgq for ; Mon, 8 Mar 2021 22:38:08 +0000 (UTC) (envelope-from lars@gustik.eu) Received: from troy.gustik.eu (localhost [IPv6:::1]) by troy.gustik.eu (Postfix) with ESMTP id 298852ADCD6; Mon, 8 Mar 2021 23:38:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gustik.eu; s=troy; t=1615243087; bh=k6HZGp04D0ahzqjnoUsHIkSufIALM5jpjb/dOCdqoZE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=hvjWxnyRSDburFDmHP9xJZ0KOlvaZ0U8HAV4hd94ObxI0oY9rbKB+ngSSnJKsj7o2 s8zOE7XDiMEpP4XDW7z04Z9maH4mvVkgVZDoL4kgDk6V/thnTI4DiUgwpL4zI/G/K5 siuynjnXn1GVmNkjR0qEgSH2Lm2kzrabaVStKDWA= Received: from romy.j20.helspy.pw ([2a01:c844:241d:bf20:4767:2cb8:97e4:8e2d]) by troy.gustik.eu with ESMTPSA id 8iacB0+nRmC6DQAADR3MKA (envelope-from ); Mon, 08 Mar 2021 23:38:07 +0100 Message-ID: <68de2b7067f40ba7adf344a18dff12840f7efd35.camel@gustik.eu> Subject: Re: FreeBSD 13.0-RC1 ethertype IPv6 (0x86dd), length 2942 on 1500 MTU From: Lars Schotte To: Ryan Stone Cc: FreeBSD Current Date: Mon, 08 Mar 2021 23:38:11 +0100 In-Reply-To: <81ffb5784c66441bf5fb399c12b2b06786cc8f35.camel@gustik.eu> References: <2a8d7089955ca70cd4e0e644aef988ca4a9019e3.camel@gustik.eu> <81ffb5784c66441bf5fb399c12b2b06786cc8f35.camel@gustik.eu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-16.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DvYC45PZZz3sgq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gustik.eu header.s=troy header.b=hvjWxnyR; dmarc=none; spf=pass (mx1.freebsd.org: domain of lars@gustik.eu designates 165.227.162.104 as permitted sender) smtp.mailfrom=lars@gustik.eu X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gustik.eu:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[165.227.162.104:from]; ASN(0.00)[asn:14061, ipnet:165.227.160.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gustik.eu:s=troy]; FREEFALL_USER(0.00)[lars]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gustik.eu]; SPAMHAUS_ZRD(0.00)[165.227.162.104:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 22:38:09 -0000 Oh, I am afraid I have to correct myself once again. I was expecting the change to take effect immediately, however, after closing all connections to the system, it indeed seems to have helped to remove TSO6. Thanks for the quick fix. However, I will keep an eye on it, I will do more testing tomorrow. On Mon, 2021-03-08 at 23:28 +0100, Lars Schotte wrote: > Hi, > thanks for you fast reaction. > > I was sceptical about this, since it contrary to my expectations > indeed > does affect IPv4 as well, but I tried it anyway and the result is > NEGATIVE. > > Removing TSO6 does not help with it, it still spills out crazy sized > Ethernet frames of ~4000 and so on. > > On Mon, 2021-03-08 at 17:22 -0500, Ryan Stone wrote: > > Hi Lars, > > > > Do you see the TSO6 option enabled on your vtnet interface? Do you > > see normal packet sizes if you disable it with "ifconfig vtnet0 > > -tso6"? Does it actually fix your IPv6 issue? -- Lars Schotte Mudroňova 13 92101 Piešťany From owner-freebsd-current@freebsd.org Mon Mar 8 10:33:44 2021 Return-Path: Delivered-To: freebsd-current@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 D772656DA61 for ; Mon, 8 Mar 2021 10:33:44 +0000 (UTC) (envelope-from mitidzi@gmail.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DvF7D1wlgz4SHW for ; Mon, 8 Mar 2021 10:33:44 +0000 (UTC) (envelope-from mitidzi@gmail.com) Received: by mail-ua1-x92d.google.com with SMTP id t15so3159242ual.6 for ; Mon, 08 Mar 2021 02:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GiNfs7w2bKSLtZLMZS+YtE9qTWVIxqKj0FMvutqHAuw=; b=uo+1Z+8YJ3SAw0SNrXB14mtjG2hbm4QQ/9imBJBpxeuT3O5lY7JynJbPXoh4cJQsNW 3Ert29Qen9E/hIbRS0HHRgSipKmd1Wb77F4EgDNMoVuEwdKMjSVne5SUGaxO+LOypzh0 HgMB1dzCEVV5u00B12wpUdUTAxDazvhO5A0ERxYVieRSBxfpvb7K5RaMuW0V1o0N+q6N HD4zL9f4YfZmHLVzMHhjT9p5MPrOyYVqQdT5M/4GFtZ/ZNpM8MUCj8W4c32cw6qtiVeo hj79NLOPRvzlVfiKh4KZNNnb+/6ciZ4JZ7iQ/AT7j5LaLaCS22Eq1yE9ZXwshJALGhJV Je/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GiNfs7w2bKSLtZLMZS+YtE9qTWVIxqKj0FMvutqHAuw=; b=Dw01aonDjpcrQ17mTBr0+GU67oPneo26W6hG9Xe+Yfr2yU+iaV6asgP31hyb6nLBfG g9TqC+E+6UKt7TTniw/c5i1N2scz/MfDiWosUzuIhS3aai5TQoWMA1+86VW9/Qb7Kd6x 17qH+jyPxx2LN1SfABhKYUfqjeJnxPuxADqABVd+Daau4Cyx0uYQx0PTmHeRfi932J/P n0j7kYoosOzzELC2j2+U9/APHECGtFBQOMpuuP5B9vrTOrMZl4VzdcHTUqVVkkIKZjhc axyTId/Ys3oy4Cdv/ZJ92ZTQuzRo7PIQIAcnIR0w1xOHcyPYjv2IdtKVZEHqXI34qoYO B0dQ== X-Gm-Message-State: AOAM5300nB2Zh/QorPT8JA3Kaq0Iis7+F9/EMEANG9G+yYGHF2j7R2CY r0wYlCX9V28UEDCxpWbfwNQPU9AiBz+VphPPX3NJxAlztLV7+Q== X-Google-Smtp-Source: ABdhPJxfbk9PEYTrjrs4VaB8Hwo8jr/hwxAbBRpHMc+xvNpct2B2pQ3ARhsGOOMv3kSo5FUbgQv1i5rDOve3DA8JDxI= X-Received: by 2002:ab0:7394:: with SMTP id l20mr12859753uap.99.1615199623103; Mon, 08 Mar 2021 02:33:43 -0800 (PST) MIME-Version: 1.0 From: Mitidzi Racerex Date: Mon, 8 Mar 2021 19:33:32 +0900 Message-ID: Subject: RC1 builds To: freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4DvF7D1wlgz4SHW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=uo+1Z+8Y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mitidzi@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=mitidzi@gmail.com X-Spamd-Result: default: False [-3.76 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.76)[-0.755]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::92d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::92d:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92d:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-Mailman-Approved-At: Tue, 09 Mar 2021 06:18:58 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 10:33:44 -0000 Please give a link to RC1 builds. From owner-freebsd-current@freebsd.org Tue Mar 9 06:38:39 2021 Return-Path: Delivered-To: freebsd-current@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 AAA0856B97A for ; Tue, 9 Mar 2021 06:38:39 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvlsV5bBzz4v7M for ; Tue, 9 Mar 2021 06:38:38 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 989A82E315 for ; Tue, 9 Mar 2021 15:38:34 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1615271914; bh=ucm/A9RkEozn5YNIcPLYszKbdLBNRAdZT1VyMpOXD20=; h=Date:To:Subject:From:In-Reply-To:References; b=xrKauRBsdyivdFD3yZdlcKQqyA6PD3WQoI+jrh55ueIl632GbHO4OYfP5Geu9mTwv SkDD4Qf/7xdxY5N8tclDUywNHjDhHX6NtHzhXHY9Jv8tSXUZOUt/is+VghCL5UDreL kWqNuAVFE/58eM5B6NfXDRrRCjcXc8X8h0oDhBdNmOTGDxUpkFjHt7rZwZ4IfUA2Kb fGZ/eeRHtZ/FFOya21Q5am7oYOZVQEybL7VRW7ElqEUF0OcM7t6vn683YfYBBKn0Og 69G80nfENOIsP2BRKm8Cp8xLoyzCsKS44syQ+NBELtT7LXgHoN4U6hRXBY6vWYBXU/ Pqfs7VkpN4tBw== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id C78C431874; Tue, 9 Mar 2021 15:38:33 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Tue, 09 Mar 2021 15:37:44 +0900 (JST) Message-Id: <20210309.153744.777333655764248949.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: Waiting for bufdaemon From: Yasuhiro Kimura In-Reply-To: References: <20210309.005732.1808108188909983665.yasu@utahime.org> <20210309.015021.2131122829257392547.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvlsV5bBzz4v7M X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=xrKauRBs; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [1.26 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[utahime.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.96)[0.957]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 06:38:39 -0000 From: Kyle Evans Subject: Re: Waiting for bufdaemon Date: Mon, 8 Mar 2021 11:07:23 -0600 > I've tried tracking down exactly what the problem is that causes the > symptoms we're seeing, but no luck so far. I'm eyeballing the > following patch which partially reverts kib's 84eaf2ccc6aa05 ("x86: > stop punishing VMs with low priority for TSC timecounter") and only > punishes VirtualBox guests. > > diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c > index 68fc57e6ea7..6f25360a67c 100644 > --- a/sys/x86/x86/tsc.c > +++ b/sys/x86/x86/tsc.c > @@ -501,7 +501,12 @@ test_tsc(int adj_max_count) > uint64_t *data, *tsc; > u_int i, size, adj; > > - if ((!smp_tsc && !tsc_is_invariant) || vm_guest) > + /* > + * Misbehavior of TSC under VirtualBox has been observed. In > + * particular, threads doing small (~1 second) sleeps may miss their > + * wakeup and hang around in sleep state, causing hangs on shutdown. > + */ > + if ((!smp_tsc && !tsc_is_invariant) || vm_guest == VM_GUEST_VBOX) > return (-100); > size = (mp_maxid + 1) * 3; > data = malloc(sizeof(*data) * size * N, M_TEMP, M_WAITOK); After updating to 6ffdaa5f2d4, I confirmed timeout of bufdaemon dosen't happen even if I don't set kern.timecounter.hardware at all in loader.conf. Thank you for fixing the problem. --- Yasuhiro Kimura From owner-freebsd-current@freebsd.org Tue Mar 9 06:49:25 2021 Return-Path: Delivered-To: freebsd-current@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 D1A1E56BD75 for ; Tue, 9 Mar 2021 06:49:25 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Dvm5v6fXYz3Bwr for ; Tue, 9 Mar 2021 06:49:23 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id e23so885607wmh.3 for ; Mon, 08 Mar 2021 22:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=5Gg18BcVmfSv7+9EZMNf3LtDiGKroDuYrk2KTj4eTnM=; b=XA6/4RBi46bBUql4n0yK3g/AyqYHwH3n7sxwnN8nastOB/wb4xGe7m0lPHN6Fbzmjo hWDRRVOg+Jh6CZssQED914aqAK2PZxUSFH8R4zaDdFVw2fE+KTh6RwQ0Q/H3zWijT0wV ePfawy0uG0ti3Xe5a6oTt3kJEiE8HyRpOtFT3ezAL5U/czT3ZlzAcLGfIQC2ftvozNzT 3QOw8T7yGk4ASdhNfs7rx6IUa4dYuYdkTWIabI0W+jFVRnbqfsnjZKpCAB9J//BUiFYZ I1zCDRRHRWMPkrnutf12ZgDmbAGc7SEVhGvO5gB75Gb/vKKXvbkSOdVL1H1cb3hlE7t9 yYxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5Gg18BcVmfSv7+9EZMNf3LtDiGKroDuYrk2KTj4eTnM=; b=efCCFQ9gkZJ49vRvw9mBeg67Gckj28lNYRdGIqUX9cUUZlEZcRufW1wvUaIufLVr2J XoJk+V4GP/kEiCZvmwhRbWFXV8KXfZ5+2S/SwlgeRBIXQJHuq2H5SSq0+y+FRwbSe0vH 7x/gHvDHAPFiNoe+9Y2afJRVT+QwYNHdci5foumLTroU0NTbsmJJaPaGNadPz/oW82k+ 7/TglCDCRqtcU0elqI8Z3ObJj6NPulY8sVFKfQLXzoQ/5SfbNF/vwcmDctDIHnYyQwMj XOXW1Z1WGJ/81c/0wJc0ZkWRIWhMsv+aVPiUfGZyDSR2o7cPFB5CKIuhezrJt/8H3mth CobA== X-Gm-Message-State: AOAM531x3e4TQ/AAypR92bU0c2TsDdtwU6jHthyYL5UXcozsMdC2jvIT or9U11km0OAWmClMfTbH4ERIZTijCpFVaw== X-Google-Smtp-Source: ABdhPJx9hcCR7ut4YZJ9fnbcnlgabjoWGjfv6DO5zSBPzImHNBeUgwK1b8nEAwhxo9d1KLDwugt9+A== X-Received: by 2002:a05:600c:247:: with SMTP id 7mr2317042wmj.116.1615272561464; Mon, 08 Mar 2021 22:49:21 -0800 (PST) Received: from [192.168.1.13] (88-105-96-80.dynamic.dsl.as9105.com. [88.105.96.80]) by smtp.gmail.com with ESMTPSA id f14sm2465462wmf.7.2021.03.08.22.49.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Mar 2021 22:49:20 -0800 (PST) Subject: Re: RC1 builds To: Mitidzi Racerex References: Cc: freebsd-current@freebsd.org From: Graham Perrin Message-ID: <0fd6ddf3-957d-e07f-72f5-15155e7d0c12@gmail.com> Date: Tue, 9 Mar 2021 06:49:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 4Dvm5v6fXYz3Bwr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XA6/4RBi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-2.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::330:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[88.105.96.80:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.978]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::330:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::330:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 06:49:25 -0000 On 08/03/2021 10:33, Mitidzi Racerex wrote: > Please give a link to RC1 builds. See the e-mail that was posted on the 6th, 'FreeBSD 13.0-RC1 Now Available' Thanks From owner-freebsd-current@freebsd.org Tue Mar 9 08:31:58 2021 Return-Path: Delivered-To: freebsd-current@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 F1DFF56E968; Tue, 9 Mar 2021 08:31:58 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvpNG1BG4z3JJ5; Tue, 9 Mar 2021 08:31:57 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DvpND2YPwzDs70; Tue, 9 Mar 2021 00:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615278716; bh=No3sGLjgPYYpiRGRLjdOQ5VsQwkl4NWYfcEUaY258Dg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FBUg3prXUF1lVGT/Sk/zBEAbEyDKp7eP8phC/wJ4VP1eTJEPiFegYmbOnLTEfnuoC OgiexMw9c2Q60hodiUdFvJ0K15reszx/gysLJ9054Eq8gR7N6DBMnWB4v7VFQCjCKu jHchAUBQnssqT6LT+V20eHSfRKDLnKDq2ZSrMsk0= X-Riseup-User-ID: 2A22AF72F9F2E63A55AF5D49CCA7561CFFF92C50408C5312452475CA9A7B755B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4DvpNC6kTYz1xmR; Tue, 9 Mar 2021 00:31:55 -0800 (PST) MIME-Version: 1.0 Date: Tue, 09 Mar 2021 00:31:55 -0800 From: Alastair Hogge To: Hans Petter Selasky Cc: Emmanuel Vadot , Steve Kargl , Andriy Gapon , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: panic in drm or vt or deadlock on mutex or ... In-Reply-To: References: <20210203050828.GA21823@troutmask.apl.washington.edu> <4581b83f-e048-fb8b-edfe-44332d3dc460@FreeBSD.org> <20210203160324.GA23963@troutmask.apl.washington.edu> <20210204105029.5fc11bed5df0e4283f983fbf@bidouilliste.com> <36a5927f9992ec828a0fe1e9bf480ce3@riseup.net> Message-ID: <942bb6f5190e5300492120c3aecdf874@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvpNG1BG4z3JJ5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=FBUg3prX; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-x11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:31:59 -0000 On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysctl source code: > > 1) print the sysctl before it is queried. > 2) sleep 1 second between print and query. > > Should be easy to nail this down! Always panics at: $ /tmp/sysctl-with-delay -a [...] p1003_1b.mapped_files: 200112 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 200112 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 200112 p1003_1b.shared_memory_objects: 200112 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: 256 p1003_1b.aio_max: 1024 p1003_1b.aio_prio_delta_max: 0 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 From owner-freebsd-current@freebsd.org Tue Mar 9 08:45:32 2021 Return-Path: Delivered-To: freebsd-current@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 9572F56F3BA; Tue, 9 Mar 2021 08:45:32 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dvpgw3D4bz3KXF; Tue, 9 Mar 2021 08:45:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EA3AB260201; Tue, 9 Mar 2021 09:45:22 +0100 (CET) Subject: Re: panic in drm or vt or deadlock on mutex or ... To: Alastair Hogge Cc: Emmanuel Vadot , Steve Kargl , Andriy Gapon , freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20210203050828.GA21823@troutmask.apl.washington.edu> <4581b83f-e048-fb8b-edfe-44332d3dc460@FreeBSD.org> <20210203160324.GA23963@troutmask.apl.washington.edu> <20210204105029.5fc11bed5df0e4283f983fbf@bidouilliste.com> <36a5927f9992ec828a0fe1e9bf480ce3@riseup.net> <942bb6f5190e5300492120c3aecdf874@riseup.net> From: Hans Petter Selasky Message-ID: <08876514-e12d-dcc1-29de-184207bb8278@selasky.org> Date: Tue, 9 Mar 2021 09:45:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <942bb6f5190e5300492120c3aecdf874@riseup.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Dvpgw3D4bz3KXF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:45:32 -0000 On 3/9/21 9:31 AM, Alastair Hogge wrote: > On 2021-02-08 21:01, Hans Petter Selasky wrote: >> On 2/8/21 1:53 PM, Alastair Hogge wrote: >>> Boot to multi-user; login (getty): >>> $ doas kldload /boot/modules/amdgpu.ko >>> $ sysctl >>> [panic] >>> >>> ..is a guaranteed way to panic my system. >> >> Hi, >> >> Maybe you could do a hack and edit the sysctl source code: >> >> 1) print the sysctl before it is queried. >> 2) sleep 1 second between print and query. >> >> Should be easy to nail this down! > > Always panics at: > $ /tmp/sysctl-with-delay -a > [...] > p1003_1b.mapped_files: 200112 > p1003_1b.memlock: 0 > p1003_1b.memlock_range: 0 > p1003_1b.memory_protection: 0 > p1003_1b.message_passing: 0 > p1003_1b.prioritized_io: 0 > p1003_1b.priority_scheduling: 200112 > p1003_1b.realtime_signals: 200112 > p1003_1b.semaphores: 0 > p1003_1b.fsync: 200112 > p1003_1b.shared_memory_objects: 200112 > p1003_1b.synchronized_io: 0 > p1003_1b.timers: 200112 > p1003_1b.aio_listio_max: 256 > p1003_1b.aio_max: 1024 > p1003_1b.aio_prio_delta_max: 0 > p1003_1b.delaytimer_max: 2147483647 > p1003_1b.mq_open_max: 0 > p1003_1b.pagesize: 4096 > p1003_1b.rtsig_max: 62 > p1003_1b.sem_nsems_max: 0 > p1003_1b.sem_value_max: 0 > p1003_1b.sigqueue_max: 128 > p1003_1b.timer_max: 32 > Hi, On my system: p1003_1b.timer_max: 32 sys.class.drm.card0-HDMI-A-1.modes: 1680x1050 1600x1200 1280x1024 1440x900 1280x960 1024x768 800x600 640x480 720x400 So that means some modes sysctl is causing the panic. Emmanuel: Do you want to debug this? --HPS From owner-freebsd-current@freebsd.org Tue Mar 9 08:48:34 2021 Return-Path: Delivered-To: freebsd-current@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 38FFC56F659; Tue, 9 Mar 2021 08:48:34 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvplP3dWzz3Kcv; Tue, 9 Mar 2021 08:48:33 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DvplM4mq5zDqZT; Tue, 9 Mar 2021 00:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615279711; bh=n33uscq+115Ryj+zSVv1vpJF0NTQwlZPyND3RyUrKi0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Dhf3wh2A83aFehrf4R9knJIQ8+UjTt8Eg+gDu9QaTF4HyXOwRzF5TKFp9agA1U7E3 J2MzH/wt87+3QikU9AN+g3oQiRgyE0xmhGgBOx2OQ2yRCIh+ftG32jwGoKAMc6TBOB mUmj2svJJzRVYGEJvIiaengr+LoxovbwlHod5CfM= X-Riseup-User-ID: 82F939AA8B35D1A158A74B43DFFC9B3EF12DB9D57C09F8E7BD43827F8003E8DB Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4DvplM2ld9z1y6Q; Tue, 9 Mar 2021 00:48:31 -0800 (PST) MIME-Version: 1.0 Date: Tue, 09 Mar 2021 00:48:31 -0800 From: Alastair Hogge To: Emmanuel Vadot Cc: Greg V , Steve Kargl , Andriy Gapon , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: panic in drm or vt or deadlock on mutex or ... In-Reply-To: <20210208192051.fde7084c730e9bd8d43f70cd@bidouilliste.com> References: <20210203050828.GA21823@troutmask.apl.washington.edu> <4581b83f-e048-fb8b-edfe-44332d3dc460@FreeBSD.org> <20210203160324.GA23963@troutmask.apl.washington.edu> <20210204105029.5fc11bed5df0e4283f983fbf@bidouilliste.com> <36a5927f9992ec828a0fe1e9bf480ce3@riseup.net> <0928OQ.XWU19W2YPKY51@unrelenting.technology> <20210208192051.fde7084c730e9bd8d43f70cd@bidouilliste.com> Message-ID: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DvplP3dWzz3Kcv X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=Dhf3wh2A; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; R_SPF_ALLOW(-0.20)[+mx]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-x11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:48:34 -0000 On 2021-02-09 02:20, Emmanuel Vadot wrote: > Alastair: Can you report a bug there : > https://github.com/freebsd/drm-kmod/issues https://github.com/freebsd/drm-kmod/issues/64 From owner-freebsd-current@freebsd.org Tue Mar 9 12:09:21 2021 Return-Path: Delivered-To: freebsd-current@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 8345A55024D for ; Tue, 9 Mar 2021 12:09:21 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DvvC52SGxz3rqQ for ; Tue, 9 Mar 2021 12:09:21 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 53F61550056; Tue, 9 Mar 2021 12:09:21 +0000 (UTC) Delivered-To: current@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 53B97550291 for ; Tue, 9 Mar 2021 12:09:21 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvvC43YHdz3rjF for ; Tue, 9 Mar 2021 12:09:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 129C9IxQ028497 for ; Tue, 9 Mar 2021 12:09:18 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 129C9Ima028496 for current@freebsd.org; Tue, 9 Mar 2021 04:09:18 -0800 (PST) (envelope-from david) Date: Tue, 9 Mar 2021 04:09:18 -0800 From: David Wolfskill To: current@freebsd.org Subject: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D7gz3/Dw8Tqnipp0" Content-Disposition: inline X-Rspamd-Queue-Id: 4DvvC43YHdz3rjF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-0.40 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[catwhisker.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; REPLYTO_EQ_TO_ADDR(5.00)[]; MAILMAN_DEST(0.00)[current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 12:09:21 -0000 --D7gz3/Dw8Tqnipp0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just did a source-based update from: FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar 8 03:49:58 P= ST 2021 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd6= 4/sys/GENERIC amd64 1400005 1400005 to: FreeBSD 14.0-CURRENT #1206 main-n245363-b3dac3913dc9: Tue Mar 9 03:55:00 P= ST 2021 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GE= NERIC amd64 [latter scraped from the console] and: =2E.. pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 pass6: uhub3: 6 ports with 6 removable, self powered Removable Direct Access SCSI device pass6: Serial Number 20100818841300000 pass6: 40.000MB/s transfersuhub4: 8 ports with 8 removable, self powered panic: malloc(M_WAITOK) with sleeping prohibited cpuid =3D 0 time =3D 22 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e157a= 4b0 vpanic() at vpanic+0x181/frame 0xfffffe00e157a500 panic() at panic+0x43/frame 0xfffffe00e157a560 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a580 malloc() at malloc+0x34/frame 0xfffffe00e157a5e0 disk_alloc() at disk_alloc+0x1c/frame 0xfffffe00e157a600 daregister() at daregister+0x3f4/frame 0xfffffe00e157a880 cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfffffe00e157= aa10 xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic [ thread pid 17 tid 100095 ] Stopped at kdb_enter+0x37: movq $0,0x128b97e(%rip) db>=20 I can afford to leave it that way for a bit, in case anyone has suggestions for poking at it to get more information. I expect to be attempting the same upgrade on a couple of laptops -- after they finish building firefox. Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --D7gz3/Dw8Tqnipp0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBHZW5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcloxQgAwG42SVvbW2IP+OD0gUDmsRszZ/cBpO3cBqgg4CXyArqsL3eORmEujehj pjGJUPM0S+0LQ2fLpmOOqZs3neOsF2oZpykTKhFTsywdyaeHjdridyDO/PTSmCAk 5daibb+HNrmHiNlaSzP8iGe61DwhXgpC6WEQVF0dLeI9Tw9EMzzP+5v3ml4I/+U4 fEbwb5ZZUHgURAtmXQv2vVBNzZlkT1Hgy2j7tY/Wq9SMGGhPClN5Hd6egLynAoEy oMOflicpgfdN11CbxbLGlRlhX9KEoy+f6CwbyK8ke8149rU2sNZcJ4eHeRJhv1Bb Svu+PuyFXmYDjfEnwJFaRXi/389rgQ== =0HwI -----END PGP SIGNATURE----- --D7gz3/Dw8Tqnipp0-- From owner-freebsd-current@freebsd.org Tue Mar 9 13:21:23 2021 Return-Path: Delivered-To: freebsd-current@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 54AD055225C for ; Tue, 9 Mar 2021 13:21:23 +0000 (UTC) (envelope-from david@catwhisker.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 4DvwpC0NGjz3wKq for ; Tue, 9 Mar 2021 13:21:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0CF3A55225B; Tue, 9 Mar 2021 13:21:23 +0000 (UTC) Delivered-To: current@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 0CB9E551F5A for ; Tue, 9 Mar 2021 13:21:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DvwpB5TBLz3wCX for ; Tue, 9 Mar 2021 13:21:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 129DLLiZ033714 for ; Tue, 9 Mar 2021 13:21:21 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 129DLLSH033713 for current@freebsd.org; Tue, 9 Mar 2021 05:21:21 -0800 (PST) (envelope-from david) Date: Tue, 9 Mar 2021 05:21:20 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="05vaBuBZDBE4nA6M" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DvwpB5TBLz3wCX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 13:21:23 -0000 --05vaBuBZDBE4nA6M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2021 at 04:09:18AM -0800, David Wolfskill wrote: > ... > I can afford to leave it that way for a bit, in case anyone has > suggestions for poking at it to get more information. I expect to > be attempting the same upgrade on a couple of laptops -- after they > finish building firefox. > .... Neither laptop reported an issue -- each came up to multi-user mode just fine;' e.g.: Yesterday: FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #174 main-n2= 45338-221622ec0c8e-dirty: Mon Mar 8 03:52:29 PST 2021 root@g1-55.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400005 1400= 005 today: FreeBSD g1-55.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #175 main-n2= 45363-b3dac3913dc9-dirty: Tue Mar 9 05:08:07 PST 2021 root@g1-55.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400005 1400= 005 The build machine's most recent dmesg (from yesterday's verbose boot of head) is at https://www.catwhisker.org/~david/FreeBSD/history/freebeast.14_dmesg.txt Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --05vaBuBZDBE4nA6M Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBHdlBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcnxewf9EbAlonhLIOgoIItFyG9S2jnk4p4/CrB0/sjlIEYrNzX4RaHRFFKW7TRg meFo5BZpLXMMK8KwwLmkQAzlZOh4jY1kNlb3UtnRa+pCY2hxNH+wkKrXUDqKhSCK eLza1EYEsa6KUD7WULDbzBtB8WEKtlPtsjndcH3WVfKze2VwOZGAZMoDn9EnDPdY 9jdS1YgFxjdxDi4ixsAKA+CHcsFt4H+bAxxEuNdK4rMMN7zJKWDV7UqeCMA8algj zYZpUnpY7VDqPtY1k+tC5U0TsMEFoMzApXg9IM3eAsjh/V8ppPv9Q6pRPKT6RJFU Z0CdpOrY8rMjzmnSX+LsqNX/QqC0lg== =DK24 -----END PGP SIGNATURE----- --05vaBuBZDBE4nA6M-- From owner-freebsd-current@freebsd.org Tue Mar 9 15:33:32 2021 Return-Path: Delivered-To: freebsd-current@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 B3CD15564D8 for ; Tue, 9 Mar 2021 15:33:32 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dvzkg4JSGz4ZQF for ; Tue, 9 Mar 2021 15:33:31 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 9 Mar 2021 16:33:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1615304009; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=88Kplvk/VPD5QsAycgs9AGFrFpwyYvnQSCRrItDnRgU=; b=cwmYGebAiqDB5DZqkDRNPax2g1xxFivWcr911z6R973HShhQ/Udg8hkA0VvwTl2s/niFMR Jx5J0c788yw1Df+oEoOQqzq/aXWb0O+qyCUxSip2n6I4vOMqGUrIIJ3nNCDBkcBp7J2Yey c2NrvGdlOJZ86/m5QrjJmiZ98mQ/lYf9u4xHckch/4avuLODagBbELPCI0i5qzJfh+8Qzn E7Q6ehtEk4uY2cnTnXW+JCG2DSqa70xzKyKRoxkQ/gJ+H/O4zQNQ5GurKX/aXsUWU+cKCB zBU7t3QjNZJMt8RrEq28AfTgIkJKQOF7IWGRULglt2YQkSG2BTObeKmMVhOshg== From: Ronald Klop To: Mitidzi Racerex Cc: freebsd-current@freebsd.org Message-ID: <1617658290.2.1615304009453@localhost> In-Reply-To: References: Subject: Re: RC1 builds MIME-Version: 1.0 X-Mailer: Realworks (550.544.60dfe2d0fb4) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Dvzkg4JSGz4ZQF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=cwmYGebA; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.49 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_SHORT(-0.99)[-0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 15:33:32 -0000 See https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093272.html Regards, Ronald. Van: Mitidzi Racerex Datum: maandag, 8 maart 2021 11:33 Aan: freebsd-current@freebsd.org Onderwerp: RC1 builds > > Please give a link to RC1 builds. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@freebsd.org Tue Mar 9 20:53:50 2021 Return-Path: Delivered-To: freebsd-current@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 73F72570262 for ; Tue, 9 Mar 2021 20:53:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dw6rG0W97z3Ds0 for ; Tue, 9 Mar 2021 20:53:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 0FBCC5705B4; Tue, 9 Mar 2021 20:53:50 +0000 (UTC) Delivered-To: current@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 0F83A5702FB for ; Tue, 9 Mar 2021 20:53:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Dw6rF6wPJz3DpW for ; Tue, 9 Mar 2021 20:53:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id z128so14535714qkc.12 for ; Tue, 09 Mar 2021 12:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Da7SGM7X4M/aM1ebKbexNa9txbDMk8TEgp4djoil0XQ=; b=dL6yb7QJM3m0xpNX1p2e+wHxV9FipRp8RuwuOlH1TRQQ8smlzz389tIsmvLSPsJbCQ 2q3wuLLiCBYHNh3aA2OmnpiisufrWKD+wwkmeGl1HLxPofznBPqk0/3/h2QRutJUadUV zgOZnT+HeY2W6OKNOj+phHdCj72krC8tbrxjCr/1p8Ro0OJC4MpLGurrX57tFkyyTtMb T6iZDX6cbnPWw/uk1kpYtj4Xrt3/EydzLC4h6ynuGKnTOLd3ljfTQKLn0mP6+/2S4WF0 ypvQ8qAjDd+GpzaEJKkJO00VQ6YB+bX5ud/OkTGKes9OU2987nt22t3mXf/ROG39wdP5 EL+g== 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; bh=Da7SGM7X4M/aM1ebKbexNa9txbDMk8TEgp4djoil0XQ=; b=PtuYjTSEuUT5/UFitbIPupLy/AdWUFqUcYZzFTMxGP5Gxn4KWYBtiwCEaaLGYN0dvg Og+dIjjbRNj2DjJ6PCJpoPL6b/VPloWrNTB+VUWXiRX5o/bfbH56721ryuL+xfqHjl1y LGBHclYBAAWMfYf23/OgawsKjVuWwTGIT9zCfQl4zHYpDV6X5w7/5mWvJ0+ZLwEa+Xls yLw5Wdem+4dsD5mkqVl6l7VvJ+pOMfOVZM7frh/7WUfVmJlzMNCb+6t69J3lgemfVtyk UfGwkWUyCUMvqkLn3Usv+ZlbOawg17gGKK+vXmUyUAGtUZFybYdv4wRan10ksFFx54lj u/NQ== X-Gm-Message-State: AOAM530v+cIX9S2DxLqzjIKnuM74l7J1zWv5NTTHQXclbBrjg3UCcGXJ ahsS3EYmrkfmPh6yYSjhNtn51hT7evWLQN750Ycj0m2oNAamhwMs X-Google-Smtp-Source: ABdhPJyGo214IMMhFYwjzWtfULVjtkEuebTiPg87rYvpcT+YjFA3ZES9Pk7s1FZ/pjnVfhMisQ7oFb9NCcSB3XhYc+k= X-Received: by 2002:a37:a085:: with SMTP id j127mr26310801qke.206.1615323228563; Tue, 09 Mar 2021 12:53:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 9 Mar 2021 13:53:37 -0700 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 To: FreeBSD Current X-Rspamd-Queue-Id: 4Dw6rF6wPJz3DpW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 20:53:50 -0000 On Tue, Mar 9, 2021 at 5:09 AM David Wolfskill wrote: > Just did a source-based update from: > > FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar 8 03:49:58 > PST 2021 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 1400005 1400005 > > to: > > FreeBSD 14.0-CURRENT #1206 main-n245363-b3dac3913dc9: Tue Mar 9 03:55:00 > PST 2021 > root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > [latter scraped from the console] > > and: > > ... > pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 > pass6: uhub3: 6 ports with 6 removable, self powered > Removable Direct Access SCSI device > pass6: Serial Number 20100818841300000 > pass6: 40.000MB/s transfersuhub4: 8 ports with 8 removable, self powered > > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 0 > time = 22 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00e157a4b0 > vpanic() at vpanic+0x181/frame 0xfffffe00e157a500 > panic() at panic+0x43/frame 0xfffffe00e157a560 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a580 > malloc() at malloc+0x34/frame 0xfffffe00e157a5e0 > disk_alloc() at disk_alloc+0x1c/frame 0xfffffe00e157a600 > daregister() at daregister+0x3f4/frame 0xfffffe00e157a880 > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 > daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > 0xfffffe00e157aa10 > xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 > xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 > fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 17 tid 100095 ] > Stopped at kdb_enter+0x37: movq $0,0x128b97e(%rip) > db> > The following reviews should fix this. It introduces a no-wait variant for disk_alloc(), provides a way to free allocated, but not created, disks and changes CAM to use the new routines and take some care for not leaking when an allocation fails. https://reviews.freebsd.org/D29161 https://reviews.freebsd.org/D29162 https://reviews.freebsd.org/D29163 Maybe you can try it? I got similar tracebacks when I booted w/o these changes, but not a peep with them... Warner > > I can afford to leave it that way for a bit, in case anyone has > suggestions for poking at it to get more information. I expect to > be attempting the same upgrade on a couple of laptops -- after they > finish building firefox. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > It is supremely disingenuous to claim a lack of jurisdiction, then > proceed to participate in a decision on the same matter. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@freebsd.org Tue Mar 9 21:23:21 2021 Return-Path: Delivered-To: freebsd-current@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 343F2571CF2 for ; Tue, 9 Mar 2021 21:23:21 +0000 (UTC) (envelope-from david@catwhisker.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 4Dw7VJ4Nwsz3JQb for ; Tue, 9 Mar 2021 21:23:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 964EA57209F; Tue, 9 Mar 2021 21:23:20 +0000 (UTC) Delivered-To: current@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 95FF1571CEF for ; Tue, 9 Mar 2021 21:23:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dw7VJ2Dv5z3HsX for ; Tue, 9 Mar 2021 21:23:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 129LNGdm038689; Tue, 9 Mar 2021 21:23:16 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 129LNGVb038688; Tue, 9 Mar 2021 13:23:16 -0800 (PST) (envelope-from david) Date: Tue, 9 Mar 2021 13:23:16 -0800 From: David Wolfskill To: Warner Losh Cc: FreeBSD Current Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Mail-Followup-To: David Wolfskill , Warner Losh , FreeBSD Current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r9lOEJvupSBBBs75" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Dw7VJ2Dv5z3HsX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 21:23:21 -0000 --r9lOEJvupSBBBs75 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > ... > The following reviews should fix this. It introduces a no-wait variant for > disk_alloc(), provides a way to free allocated, but not created, disks a= nd > changes CAM to use the new routines and take some care for not leaking wh= en > an allocation fails. >=20 > https://reviews.freebsd.org/D29161 > https://reviews.freebsd.org/D29162 > https://reviews.freebsd.org/D29163 >=20 > Maybe you can try it? I got similar tracebacks when I booted w/o these > changes, but not a peep with them... > ... Thanks! They applied cleanly; building now -- both on the build machine (which failed earlier) and on the newer laptop (which did not fail earlier, as it's good to find out if a change has broken somehing that had been working). Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --r9lOEJvupSBBBs75 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBH50RfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmNoAf/b36CRmM9hmej9AXg5WLl0pWfD0/8M9ASeTrokumSYpDIX4B4TsoBC6ZB fsKmXwZkPsZ8y/1nCJSzE+N3NWHcI1m7foXa6Dl2dKYdnTlgsLXKW1DLrqZhIfhf 6W0PN1tLY987MRHdc3yebccUJBsWpr8vKKnJ3LDjwdHeEJxSHY8Zki2FSzSovLBc HAs/BS4MSAAzrcayG2Ef2iwYkdBSw7MEKv+4tY7wwW81aFZyilX0zdFc94RgTrrP 6mm4EXboUK2Ms036m6ZU6QzbtMjRcTER5Gne6AvNY9tOhl8p0eBOUzuGK348Xz+v cgVDahlJlmLUMiGSHoOn65+PmnLH1w== =pQo0 -----END PGP SIGNATURE----- --r9lOEJvupSBBBs75-- From owner-freebsd-current@freebsd.org Tue Mar 9 21:46:14 2021 Return-Path: Delivered-To: freebsd-current@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 5AC77572A3D for ; Tue, 9 Mar 2021 21:46:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dw80k1G7vz3Ksj for ; Tue, 9 Mar 2021 21:46:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2B440572867; Tue, 9 Mar 2021 21:46:14 +0000 (UTC) Delivered-To: current@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 2B0A5572866 for ; Tue, 9 Mar 2021 21:46:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dw80h5Y6Gz3Kmf for ; Tue, 9 Mar 2021 21:46:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 129Lk9F9039374; Tue, 9 Mar 2021 21:46:09 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 129Lk9NU039373; Tue, 9 Mar 2021 13:46:09 -0800 (PST) (envelope-from david) Date: Tue, 9 Mar 2021 13:46:09 -0800 From: David Wolfskill To: Warner Losh , FreeBSD Current Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Mail-Followup-To: David Wolfskill , Warner Losh , FreeBSD Current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RDao9UEPN9P/3u9T" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Dw80h5Y6Gz3Kmf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-5.40 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 21:46:14 -0000 --RDao9UEPN9P/3u9T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2021 at 01:23:16PM -0800, David Wolfskill wrote: > On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > > ... > > The following reviews should fix this. It introduces a no-wait variant = for > > disk_alloc(), provides a way to free allocated, but not created, disks = and > > changes CAM to use the new routines and take some care for not leaking = when > > an allocation fails. > >=20 > > https://reviews.freebsd.org/D29161 > > https://reviews.freebsd.org/D29162 > > https://reviews.freebsd.org/D29163 > >=20 > > Maybe you can try it? I got similar tracebacks when I booted w/o these > > changes, but not a peep with them... > > ... >=20 > Thanks! >=20 > They applied cleanly; building now -- both on the build machine (which > failed earlier) and on the newer laptop (which did not fail earlier, as > it's good to find out if a change has broken somehing that had been > working). > .... The laptop still works: FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #169 main-n2= 45338-221622ec0c8e-dirty: Mon Mar 8 03:50:50 PST 2021 root@g1-48.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400005 1400= 005 FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 main-n2= 45363-b3dac3913dc9-dirty: Tue Mar 9 05:06:34 PST 2021 root@g1-48.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400005 1400= 005 FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 main-n2= 45363-b3dac3913dc9-dirty: Tue Mar 9 05:06:34 PST 2021 root@g1-48.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400005 1400= 005 The build nmachine (still?) panics: =2E.. pass3: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) pass3: Command Queueing enabled pass4 at ahcich4 bus 0 scbus4 target 0 lun 0 pass4: ACS-2 ATA SATA 3.x device pass4: Serial Number 000000001242091982C2 pass4: 600.000MB/s transfers (SATA 3.x, ugen2.2: at usbus2 UDMA5, PIO 8192bytes) pass4: Command Queueing enabled uhub4 on uhub1 pass5 at ahciem0 bus 0 scbus5 target 0 lun 0 uhub4: on = usbus2 Root mount waiting for:pass5: usbus0 usbus= 1 usbus2ugen0.2: at usbus0 CAM SEMB S-E-S 2.00 device uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2 with the following non-sleepable locks held: umass0: on usbus0 exclusive sleep mutex CAM device lockumass0: SCSI over Bulk-Only; quirks = =3D 0x4000 (CAM device lock) r =3D 0 (0xfffff800122c9cd0) locked @ /usr/src/sys/cam/c= am_xpt.c:2333 umass0:6:0: Attached to scbus6 stack backtrace: (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? #0 0xffffffff80c7cce1 at witnesuhub3: 6 ports with 6 removable, self powered s_debugger+0x71 pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 #1 0xffffffff80pass6: uhub4: 8 ports with 8 removable, self powered c7ddfd at witness_warn+0x40d #2 Removable Direct Access SCSI device 0xffffffff80f42fe6 at uma_zallpass6: Serial Number 20100818841300000 oc_arg+0x46 #3 0xffffffff80be34pass6: 40.000MB/s transfers panic: malloc(M_WAITOK) with sleeping prohibited cpuid =3D 1 time =3D 22 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e157a= 2d0 vpanic() at vpanic+0x181/frame 0xfffffe00e157a320 panic() at panic+0x43/frame 0xfffffe00e157a380 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a3a0 malloc() at malloc+0x34/frame 0xfffffe00e157a400 g_post_event_x() at g_post_event_x+0x5a/frame 0xfffffe00e157a450 g_post_event() at g_post_event+0x48/frame 0xfffffe00e157a4b0 disk_create() at disk_create+0x16f/frame 0xfffffe00e157a600 daregister() at daregister+0x70a/frame 0xfffffe00e157a880 cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfffffe00e157= aa10 xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic [ thread pid 17 tid 100095 ] Stopped at kdb_enter+0x37: movq $0,0x128b8ce(%rip) db>=20 I'm willing to "poke at it" a bit, given a hint or two... Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --RDao9UEPN9P/3u9T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBH7KFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmzkQf+M8TfbJwzZjfmp15cTlAPxNf6V6o7mQWA7espcRALoklaM47zEAveoXgX ExlDeeIgwhGPem/rbZfLayPH+KseOTPi+In7R9XYbadR4SdEgEaSZjLc77YnvxMh tB9cLTCJCYMs0fAV/iMxLYFpVM1m9k+P5ysHq7I3M3ZfK/PHZpQqcgC7ftwmueBg p63RzdLBfZpuW7MLBeC5XFI+kA+JjBFqVyHIo7jWMoUIWXIXj1FTPSTimEEiuruw dZqHf4AWbD2AZCBkRc8VqV4FwnmtJO4lRQ85LTj69JkyyNDHDAGZR3hvx9YMYzPu xdlN6ZhOiFmFDhBMcGtSzK0AF8m5JQ== =u8sR -----END PGP SIGNATURE----- --RDao9UEPN9P/3u9T-- From owner-freebsd-current@freebsd.org Tue Mar 9 23:05:09 2021 Return-Path: Delivered-To: freebsd-current@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 D165D574E21 for ; Tue, 9 Mar 2021 23:05:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 4Dw9ln3mbFz3Qny for ; Tue, 9 Mar 2021 23:05:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 814F2574E20; Tue, 9 Mar 2021 23:05:09 +0000 (UTC) Delivered-To: current@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 810F1574DAC for ; Tue, 9 Mar 2021 23:05:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Dw9ln33MSz3R6x for ; Tue, 9 Mar 2021 23:05:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x732.google.com with SMTP id z128so14909247qkc.12 for ; Tue, 09 Mar 2021 15:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aJb3Kc0/xCq3QoBp9qEuPhNdVGxHwGiL1GPhrE1/WJE=; b=HOwtszIvHOgSu/JT7Slwvz2ti5jmX5ykN9KDS1oLjZem7RY0j8FO2XdOAzBnsdMDTL V7XlnjSpMXd7gIJGkBW+9oAchu5FRqEORH0JFFKawmKMcTIqn8BFbEuEQX1IBm6v13hq sN82/uDOoSDdHYiHRCR9PvBYNsPKs841D0BbcPg0BAc4n1/2ttronQfXATY9347CKluq 4svp98Dy+5pn7GSw28iCQVyN6G6JoKzoxiOlFhkYR9a30xKMDRTnPOQln1obS4rc+N85 L77BR0ZRCUR0B+CTWLo6yw7w8WBrXm4FtCxpixboF59DVSHYWSJGayKtw6ogll3OSThF ZFbw== 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; bh=aJb3Kc0/xCq3QoBp9qEuPhNdVGxHwGiL1GPhrE1/WJE=; b=B8MVAgLEJy3Ql4WDQhefPM8Zd1norgjPeN5wEsHN5PCNPoKemuBERe/gJShCB7OanI yHL1JHuP2cP5D+bOdWPaqyabGRaK8M0SSwp1wsIB8timDlDhAhFib4u2OUZElFPlpgnU ciBRYPX9fFzH5ANdd6xR0yxfQ7N4KdZ5X9ppiUfpfPO07+P3G7NvV/BSpw1dA+BNmHNY FnWDTgDMG/j9Vq2TlQRp9ebLyOYzsHV4P+1UQxaEbHhAlJx7Jzq1Lt1yN7M6aI/y8XQV AlHEgjumPFnn3Oirt+hwneunxvUEqb6CeGDfOclXr8mx4j2V4EnE7BhIibd7qYwUi9zw JiBw== X-Gm-Message-State: AOAM532SIwa2lKXAQPbRTNp5ioS00P1GtUmt1q/gqhm0cwgwpVcyL+3G C6BxVc/S04AfZxSSGg1vho1XRCBMe6dAGOngzTmdrIyBOuD7ng== X-Google-Smtp-Source: ABdhPJwmnbN9LHdmw6Yziezqc/T8N2pbPeH85dCackSrcoygzXFmamxxGGpdaNze1hmCftE//Zx0ZtG2i081ANYd1oc= X-Received: by 2002:a37:a085:: with SMTP id j127mr48867qke.206.1615331108229; Tue, 09 Mar 2021 15:05:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 9 Mar 2021 16:04:56 -0700 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 To: David Wolfskill , Warner Losh , FreeBSD Current X-Rspamd-Queue-Id: 4Dw9ln33MSz3R6x X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 23:05:09 -0000 On Tue, Mar 9, 2021 at 2:46 PM David Wolfskill wrote: > On Tue, Mar 09, 2021 at 01:23:16PM -0800, David Wolfskill wrote: > > On Tue, Mar 09, 2021 at 01:53:37PM -0700, Warner Losh wrote: > > > ... > > > The following reviews should fix this. It introduces a no-wait variant > for > > > disk_alloc(), provides a way to free allocated, but not created, > disks and > > > changes CAM to use the new routines and take some care for not leaking > when > > > an allocation fails. > > > > > > https://reviews.freebsd.org/D29161 > > > https://reviews.freebsd.org/D29162 > > > https://reviews.freebsd.org/D29163 > > > > > > Maybe you can try it? I got similar tracebacks when I booted w/o these > > > changes, but not a peep with them... > > > ... > > > > Thanks! > > > > They applied cleanly; building now -- both on the build machine (which > > failed earlier) and on the newer laptop (which did not fail earlier, as > > it's good to find out if a change has broken somehing that had been > > working). > > .... > > The laptop still works: > > FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #169 > main-n245338-221622ec0c8e-dirty: Mon Mar 8 03:50:50 PST 2021 > root@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1400005 1400005 > > FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 > main-n245363-b3dac3913dc9-dirty: Tue Mar 9 05:06:34 PST 2021 > root@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1400005 1400005 > > FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #170 > main-n245363-b3dac3913dc9-dirty: Tue Mar 9 05:06:34 PST 2021 > root@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1400005 1400005 > > > The build nmachine (still?) panics: > > ... > pass3: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) > pass3: Command Queueing enabled > pass4 at ahcich4 bus 0 scbus4 target 0 lun 0 > pass4: ACS-2 ATA SATA 3.x device > pass4: Serial Number 000000001242091982C2 > pass4: 600.000MB/s transfers (SATA 3.x, ugen2.2: 0x8000> at usbus2 > UDMA5, PIO 8192bytes) > pass4: Command Queueing enabled > uhub4 on uhub1 > pass5 at ahciem0 bus 0 scbus5 target 0 lun 0 > uhub4: on > usbus2 > Root mount waiting for:pass5: usbus0 > usbus1 usbus2ugen0.2: at usbus0 > CAM SEMB S-E-S 2.00 device > > uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2 > with the following non-sleepable locks held: > umass0: on usbus0 > exclusive sleep mutex CAM device lockumass0: SCSI over Bulk-Only; quirks > = 0x4000 > (CAM device lock) r = 0 (0xfffff800122c9cd0) locked @ > /usr/src/sys/cam/cam_xpt.c:2333 > umass0:6:0: Attached to scbus6 > stack backtrace: > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > #0 0xffffffff80c7cce1 at witnesuhub3: 6 ports with 6 removable, self > powered > s_debugger+0x71 > pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 > #1 0xffffffff80pass6: uhub4: 8 ports with 8 removable, self powered > c7ddfd at witness_warn+0x40d > #2 Removable Direct Access SCSI device > 0xffffffff80f42fe6 at uma_zallpass6: Serial Number 20100818841300000 > oc_arg+0x46 > #3 0xffffffff80be34pass6: 40.000MB/s transfers > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 1 > time = 22 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00e157a2d0 > vpanic() at vpanic+0x181/frame 0xfffffe00e157a320 > panic() at panic+0x43/frame 0xfffffe00e157a380 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a3a0 > malloc() at malloc+0x34/frame 0xfffffe00e157a400 > g_post_event_x() at g_post_event_x+0x5a/frame 0xfffffe00e157a450 > g_post_event() at g_post_event+0x48/frame 0xfffffe00e157a4b0 > disk_create() at disk_create+0x16f/frame 0xfffffe00e157a600 > daregister() at daregister+0x70a/frame 0xfffffe00e157a880 > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 > daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > 0xfffffe00e157aa10 > xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 > xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 > fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 17 tid 100095 ] > Stopped at kdb_enter+0x37: movq $0,0x128b8ce(%rip) > db> > I'm willing to "poke at it" a bit, given a hint or two... > OK. I know what's happening here. disk_create() posts an event and also expects to sleep to get memory. I can fix that too, but then that's one more 'no memory' hole. I'm unsure if we should keep playing whack-a-mole, or just defer this creation to the taskqueue we already have hanging around... Warner > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > It is supremely disingenuous to claim a lack of jurisdiction, then > proceed to participate in a decision on the same matter. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@freebsd.org Tue Mar 9 23:11:56 2021 Return-Path: Delivered-To: freebsd-current@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 0D9CC5751B2 for ; Tue, 9 Mar 2021 23:11:56 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4Dw9vb6Gc3z3hCN for ; Tue, 9 Mar 2021 23:11:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id D73955751B1; Tue, 9 Mar 2021 23:11:55 +0000 (UTC) Delivered-To: current@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 D70525754C8 for ; Tue, 9 Mar 2021 23:11:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dw9vb4CG9z3h0Z for ; Tue, 9 Mar 2021 23:11:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 129NBqqv049128; Tue, 9 Mar 2021 23:11:52 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 129NBqxT049127; Tue, 9 Mar 2021 15:11:52 -0800 (PST) (envelope-from david) Date: Tue, 9 Mar 2021 15:11:52 -0800 From: David Wolfskill To: Warner Losh Cc: FreeBSD Current Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Mail-Followup-To: David Wolfskill , Warner Losh , FreeBSD Current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ymPdGts8Ws4yWA3X" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Dw9vb4CG9z3h0Z X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 23:11:56 -0000 --ymPdGts8Ws4yWA3X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote: > ... > > The build nmachine (still?) panics: > > ... > I'm willing to "poke at it" a bit, given a hint or two... >=20 > OK. I know what's happening here. disk_create() posts an event and also > expects to sleep to get memory. I can fix that too, but then that's one > more 'no memory' hole. >=20 > I'm unsure if we should keep playing whack-a-mole, or just defer this > creation to the taskqueue we already have hanging around... >=20 > Warner ? I'll need to get the "head" slice for my build machine in a usable state soonish (within a few hours); at this point, it's looking as if using yesterday's kernel is my best bet. If here's something more useful I can do within the "within a few hours" time constraint, I'm game. Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --ymPdGts8Ws4yWA3X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBIALhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pclo0ggAvlzOQiqOddxvBjTpNTG1RJ3qBiZvj51MuomeFmdy1F4RISsVBnPUoV/7 Ais6kE2TZEIHa8+IThnDbRoz+ahI8kqcQNBnqZy4qsTm1fkl87vm71I3vFlvYKxd 23ApXRTl0xusSsY2pm7/MwOYwCAjjY+VmeaJlWoepDlcZQ+lbUv62DcP6OA0imDQ n1xToLdRqzDIDiM7RVZ3YtZUTC5/ttYv3AJZ9ArQdKD2SOw618i8zuHYMfdW/LHT qrgh8lNeQcvj2pnTkN/jB7onaGO0u/SOLJXWA+Dm2V+WZ7JLGi33WKy8aS6AlyWS dA7rGCnPcO9wo9SUvpPjNTPtsqFahA== =cYtI -----END PGP SIGNATURE----- --ymPdGts8Ws4yWA3X-- From owner-freebsd-current@freebsd.org Tue Mar 9 23:39:48 2021 Return-Path: Delivered-To: freebsd-current@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 3665157587E for ; Tue, 9 Mar 2021 23:39:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-22.consmr.mail.ne1.yahoo.com (sonic304-22.consmr.mail.ne1.yahoo.com [66.163.191.148]) (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 4DwBWl240rz3jPL for ; Tue, 9 Mar 2021 23:39:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615333186; bh=c/GhvCA/xPd1g6THbpG+3n8Q1ji7NycOYdoIZ40XIVs=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gpudxoXAOi04kvjRVQj8MYb7fg/7TetwC9qcuOL0dP7faSWg58ob+D8avFpiwyMEqGOD0XaTH9so02VLHtta4EtQnzxbDX52z24gJUsy//2SEH8ZvDYDIi9Nlsx1ctqxtfsth0/Jpah4vQA8TkilzLCwweFZIVzOKbdLITUtnIj+11dSWh8uSSlHBZRvdOC1waoRt1ol9IsTLenQLQrvRZOUYr0XCTOVukxD6YnEm1LyeZV9eKWMzW/jSfecW4v5HFKuOsFxhOM2IahfBQtIa9pDWdo50ZPw5j+XqZfuViQpPqsFz3ajZbMTjXC3wegPFJ+uhdziHN1tFEuWBYPBBA== X-YMail-OSG: UOKu_LUVM1k55_fL26Uwk9w80jrxGHoRu8HHlDjNRqRtNAWW5xS37dYRm1R7hsb ZOLVm5Sq4_ZhApUlcVn3HlPXFBQlDTXScKcOxufY6ei.vVXlixMn_SfMPYo8cjcVYDFgmPVxLh5e KgbSLnZAjLVxQ50mMEAZDRlyWcNU6zDaiLXVJmzPz6QxyMf5bBr5DLtZUded52XgyndvoVFSlwKB oIsac1CbQ.JcN0xAv4_mkD5DGou6ep4K1JvPHZJYUITDVtGXs69FBar2uLUgMyw_7Bhk4bJ3u_Jj RfQnXsn5Ed1n6y0TkCEKEl.6FMJekjVPzHMIU78U.l3xoS46vvExyrXoeFd6KBUOE.ZPzaYa2wGy fDfVbVweoponsZlnkIWf52nVWK5YDe7GBrocQUbbSNICOB2KX4RIlrDaipOIxhhoz_V52Op.WoH_ VTLNxxlRUy2SHIZ9epQbEdSdVqJG2fRYFGI9F6IcmgDj_D9jXWv.wKfWCcbq2CuzEZ.7g1lUpge9 PBjm_M_5eIjbQrshRQL.ZWd9E7W6wZW_5eZGzZqz3IlV_rF1pNp7eYpGP0ypbr6wfxi7YjLABg94 BSsgV_qqH7jlQ4U9zz6IUoqU9MZJjGmJcco77IC6p_O6xQve_sGWv7jHCRB8cBMZ1hkzygS1Wytn X5PoOkAmJcGRBgigH7OU._cEs2wI0snNW7f9xxF.CqZLR8mHwgBSCPzy2WaAnzClQHAj3UJVJZhT DOtHyq2X3sKpIlzpgE35lpEEvsonpdIMl.chZhsnJNMxbuixQSITZvBpP7JFym6aeA_8bRgaaKyg pU.tSg.p5lXUGwKx__ajtGYDZBlEYKS_WGxZQRnoQX4DBego9XnNhW45_UpGIc9tu87lJwCzRV8A nNG_ZNT9e1eT8VNAO9.qSAwzev2FlznEV60R_zP9rJ5fLIwUrklF88ahbLzI3l_vRUKuwqGvLVce O3ZfB27wx1sReO8UgaSQ14.o3_.B1a53QJFd_O5wzbbEsaXqWjbqfwjHAQwliDXU2nO5ciJWu.ua JEZzEsMVbWAj9KthNLM.oS96iLTJlz07fdHepOpOzp3aoTCfxF1GHKAknyCGzCoppnht5Qtm8WyQ TJm.kLdqHvhPTzD5uMYXxkbhBPwVtkDn9qB66gMMYpN5xeQCS1uE1r6i.4Kucu9gRpzi5hEsPxiF J_Je8Jr1dUDWXhx5baWcLG.XHwmJWCnvdPFg4UZSUQI45kStOSZEgYhKKPMDvo4O6z0Y7vIvawx7 4LswO.fAkZ1ZWhcYc6.puBCXArMOIQRsH_inJLqCsq4T9LVUfB_AMrq3zaYa0d4mRotNfMFzKIbH AB0A5dxw0CchL35XBkCbgNic7kQX2WAss6YmIv4x_.eby_DRIsXlVHZyWImUgluQUa0Wa_O_RJf9 k3j7AnQTrFMCUko.XllcI9ATPsWLsyWWbjnzFqelxzybOKWliyrP3OO.xHdvn8d9gigttWUxjHMY FwJgNMLZLKilHpI_J2zsNVglkf3d_9_iXc1MWXMxlBnXgIev.dfF6JW_3tjJXzBA8wpbIrTf1FW2 v1ALx7RjKRsY.iRDafmIG88nb8l.yQyZRt_Giw9o8_ovRfliGO5Ktu9mRgwjRq3TM4pniDVHlqSI 6UexWpA7.N5CDDhdaEYCTO2gn6cYKefGj9t.L9udCQOK_k9LX9cT2N3J.B5SDda6Celz1p91F4ta bgmL04HMs77KROulykrX3j_vBeatZiNpNm2Z4vuZKG7kya8wIUixmQk6cdHSVE6xcONALk6C19A1 ssPC5xQdk6CvlyWepOqa3LlovJuz6XGUYWGKFMRrb...ns1Yv1_af9V3lUsw2jWuyTXCZfw8cuRl a.M_RP.XXdLrobjV1d4SBQu6PBY7_zNtneNkU5y9QRryUmul6zfx9d8L0jvigs2bx80v7NkB6DEK ZajSYWY.Nl5W9TMgYN3CK3ClLaskpHnI_JMnUyRZlWSqbhduPb0KoLesccJsZTJwFLmulfFRhZCa hZDhUvM3Hi9UQn4ooQ1DvR7ob_f3DNLprjDnHSTBNIEtSHoRCveH_BsZOf89LUgkJBp0zYSLIjRf KnOFlS659nJ6HIIQTAncee7BHzq8YaH1QJxBCXtJkT0z.Jgl3CFj1nEDpWAt6qKcGrbDxHpEJzbh gjJsJ.RrRZnh_ENPmSpJdC6ho1EhxcXooipFDzmfJiKqFgK.qlyT9oGgORq5jooHWjgFZaFiI0Cj TrWoLMAre7hxvY.um8T0oLbXknjRWQ03HUt_az1GBodbSh8JpgqaHq07sNjHiTD9JGFf4YhskRWS G4XlUbyiMnEjrz3QQc0NfVjxJLT.Jdf16FAPpSpVDHuI4h_sEMXZ3s_qjgVzBm051i75e9EWtCFC ibISfslfBOpIuHfL0LK0hNGZ8lsr1nC6OcKCQdETFdm5vSm59ntjR1IWhM.2VD9VmQwOrhjB2hth 5QivFYBirC1wZFXPxlEEwP2B2Vi6yqDSkuQofrtDpVMSRUjmb4ONC0pyf_KTIhK6GSKhufzHlgiM tnJvCsVX4nLJ6KovUyJKIH84y6fwg3fPmAkyXQJ3pR7M9aALUQbSuWuYz5_P11A8f_GTCFrRnizg t X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 9 Mar 2021 23:39:46 +0000 Received: by smtp420.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID eb2f615c9fd2075c57fbcd7250ef508b; Tue, 09 Mar 2021 23:39:44 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system Message-Id: <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> Date: Tue, 9 Mar 2021 15:39:42 -0800 To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) References: <8B54D020-A3E2-4441-B6A0-894831E7E1EC.ref@yahoo.com> X-Rspamd-Queue-Id: 4DwBWl240rz3jPL X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.191.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.191.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.191.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.191.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 23:39:48 -0000 After using poudriere to build ports for native cortex-a72 on the MACCHIATObin Double Shot (and similarly for cortex-a57 on the OverDrive 1000) I attempted to do my usual bulk build targeting cortex-a7 via poudriere-devel: # poudriere jail -i -jFBSDFSSDjailArmV7 Jail name: FBSDFSSDjailArmV7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud Jail fs: =20 Jail updated: 2021-01-27 14:47:10 Jail pkgbase: disabled But I got some SIGSEGV failures that I've never before had analogous failures. I'll show the 6 backtraces. They all have a similar type-of-context but in various programs, summarized as (from the lldb bt outputs): gmake`new_job(file=3D) [3 examples] and: sh`waitcmdloop(job=3D0x00064230) [2 examples] and: cmake`(anonymous namespace)::RunCommand(command=3D, = output=3D"14.0-CURRENT\n", retVal=3D, dir=3D, = verbose=3D, encoding=3DAuto) (Only 83 ports built of 208 built, 5 failed, and 120 were skipped.) I have not yet tried simply running poudriere again to see how reliable the specific failures may or may not be: I'm first collecting and reporting this information. Nor have I tried doing the build on the cortex-a57 context instead. I'll note that when I looked at detail as the assembler level it appeared that there was a frame not shown between #0 and #1 in lldb's output: Frame #1 "->" was indicating the instruction after a simple bl to a not-shown subroutine. For building textproc/libxslt : (jobserver_acquire not shown between #0 and #1) (lldb) bt * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 frame #2: 0x0002db80 gmake`execute_file_commands(file=3D)= at commands.c:476:3 [artificial] frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x400a9700) at remake.c:1234:11 frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #6: 0x0004b08c gmake`check_dep(file=3D0x400a9700, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc4ac) at = remake.c:1024:20 frame #7: 0x00049074 gmake`update_file at remake.c:572:17 frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #9: 0x0004b08c gmake`check_dep(file=3D0x400a9400, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc564) at = remake.c:1024:20 frame #10: 0x00049074 gmake`update_file at remake.c:572:17 frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #12: 0x0004b08c gmake`check_dep(file=3D0x400a8f20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc61c) at = remake.c:1024:20 frame #13: 0x00049074 gmake`update_file at remake.c:572:17 frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd470, = envp=3D0xffffffff) at main.c:2589:13 frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D = NULL); 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 -> 0x3b5f8 <+1292>: cmp r0, #1 For building x11-toolkits/libXaw : (jobserver_acquire not shown between #0 and #1) (lldb) bt * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 frame #2: 0x0002db80 gmake`execute_file_commands(file=3D)= at commands.c:476:3 [artificial] frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036a580) at remake.c:1234:11 frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036a580, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc31c) at = remake.c:1024:20 frame #7: 0x00049074 gmake`update_file at remake.c:572:17 frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036a220, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc3d4) at = remake.c:1024:20 frame #10: 0x00049074 gmake`update_file at remake.c:572:17 frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #12: 0x0004b08c gmake`check_dep(file=3D0x40369ec0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc48c) at = remake.c:1024:20 frame #13: 0x00049074 gmake`update_file at remake.c:572:17 frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd500, = envp=3D0xffffffff) at main.c:2589:13 frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D = NULL); 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 -> 0x3b5f8 <+1292>: cmp r0, #1 For building textproc/itstool : (dowait not shown between #0 and #1) (lldb) bt * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, (struct job = *)NULL) !=3D -1); 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 -> 0x31aa8 <+84>: cmn r0, #1 For building devel/cmake : (cmsysProcess_WaitForData not shown between #0 and #1) (Note: the failing cmake is Bootstrap.cmk/cmake .) (lldb) bt * thread #1, name =3D 'cmake', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x000fd124 cmake`(anonymous = namespace)::RunCommand(command=3D, output=3D"14.0-CURRENT\n",= retVal=3D, dir=3D, verbose=3D, = encoding=3DAuto) at cmExecProgramCommand.cxx:223:15 frame #2: 0x000fca24 cmake`cmExecProgramCommand(args=3D, = status=3D) at cmExecProgramCommand.cxx:95:14 frame #3: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmExecProgramCommand(std::__1:= :vector, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmExecProgramCommand.cxx:26), args=3D,= status=3D0xffffb9a8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 frame #4: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 frame #5: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 frame #6: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408798b0, = status=3D, deferId=3D) at cmMakefile.cxx:462 frame #7: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2800, = functions=3D, inStatus=3D0xffffbd10) at = cmIfCommand.cxx:149:10 frame #8: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2800, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 frame #9: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 frame #10: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40868440, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbc78) = at cmMakefile.cxx:421 frame #11: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2760, = functions=3D, inStatus=3D0xffffc078) at = cmIfCommand.cxx:149:10 frame #12: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2760, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 frame #13: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 frame #14: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408683b8, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbfe0) = at cmMakefile.cxx:421 frame #15: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2710, = functions=3D, inStatus=3D0xffffc368) at = cmIfCommand.cxx:149:10 frame #16: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2710, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 frame #17: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 frame #18: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40873208, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffc358) = at cmMakefile.cxx:421 frame #19: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffc3f0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/Modules= /CMakeDetermineSystem.cmake", defer=3D0x00000000) at = cmMakefile.cxx:788:11 frame #20: 0x0024af34 = cmake`cmMakefile::ReadListFile(this=3D, = filename=3D) at cmMakefile.cxx:737:9 frame #21: 0x001ce448 = cmake`cmGlobalGenerator::EnableLanguage(this=3D, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalGenerator.cxx:629:9 frame #22: 0x00310bf4 = cmake`cmGlobalUnixMakefileGenerator3::EnableLanguage(this=3D0x403cc900, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalUnixMakefileGenerator3.cxx:57:28 frame #23: 0x0025d740 = cmake`cmMakefile::EnableLanguage(this=3D0x4086a000, lang=3D, = optional=3Dfalse) at cmMakefile.cxx:3748:33 frame #24: 0x0027e198 cmake`cmProjectCommand(args=3D, = status=3D) at cmProjectCommand.cxx:338:6 frame #25: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmProjectCommand(std::__1::vec= tor, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmProjectCommand.cxx:30), args=3D, = status=3D0xffffc9b8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 frame #26: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 frame #27: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 frame #28: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40884018, = status=3D, deferId=3D) at cmMakefile.cxx:462 frame #29: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffcae0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/CMakeLi= sts.txt", defer=3D0x4087b010) at cmMakefile.cxx:788:11 frame #30: 0x00254948 cmake`cmMakefile::Configure(this=3D0x4086a000) = at cmMakefile.cxx:1768:9 frame #31: 0x001d2e9c = cmake`cmGlobalGenerator::Configure(this=3D0x403cc900) at = cmGlobalGenerator.cxx:1242:10 frame #32: 0x0031123c = cmake`cmGlobalUnixMakefileGenerator3::Configure(this=3D) at = cmGlobalUnixMakefileGenerator3.cxx:132:28 frame #33: 0x002f5ab0 cmake`cmake::ActualConfigure(this=3D0xffffd018) = at cmake.cxx:1928:26 frame #34: 0x002f493c cmake`cmake::Configure(this=3D0xffffd018) at = cmake.cxx:1785:19 frame #35: 0x002f6fec cmake`cmake::Run(this=3D0xffffd018, = args=3D0xffffcfd8, noconfigure=3Dfalse) at cmake.cxx:2155:19 frame #36: 0x002fdeec cmake`main [inlined] (anonymous = namespace)::do_cmake(ac=3D, av=3D) at = cmakemain.cxx:300:16 frame #37: 0x002fde78 cmake`main(ac=3D, = av=3D) at cmakemain.cxx:861 frame #38: 0x0009b32c cmake`__start(argc=3D6, argv=3D, = env=3D, ps_strings=3D, obj=3D0x403ea004, = cleanup=3D0x403b7aa0) at crt1_c.c:92:7 -> 223 while ((p =3D cmsysProcess_WaitForData(cp, &data, &length, = nullptr))) { 0xfd120 <+744>: bl 0x3672f8 ; = cmsysProcess_WaitForData at ProcessUNIX.c:1064 -> 0xfd124 <+748>: cmp r0, #0 For devel/gdb there are 2 cores: a gmake.core and a sh.core For devel/gdb's gmake.core : (jobserver_acquire not shown between #0 and #1) (lldb) bt * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 frame #2: 0x0002db80 gmake`execute_file_commands(file=3D)= at commands.c:476:3 [artificial] frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036cda0) at remake.c:1234:11 frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D4) at remake.c:835 frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036cda0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6aec) at = remake.c:1024:20 frame #7: 0x00049074 gmake`update_file at remake.c:572:17 frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036cc20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6ba4) at = remake.c:1024:20 frame #10: 0x00049074 gmake`update_file at remake.c:572:17 frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 frame #12: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 frame #13: 0x0003f25c gmake`main(argc=3D130, argv=3D0xffffa36c, = envp=3D0xffffffff) at main.c:2589:13 frame #14: 0x0002c0fc gmake`__start(argc=3D130, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D = NULL); 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 -> 0x3b5f8 <+1292>: cmp r0, #1 For devel/gdb's sh.core : (dowait not shown between #0 and #1) (lldb) bt * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x403fd0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 frame #4: 0x00027800 sh`evaltree(n=3D0x403fd0e4, = flags=3D) at eval.c:289:4 frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 frame #7: 0x0002480c sh`__start(argc=3D26, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, (struct job = *)NULL) !=3D -1); 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 -> 0x31aa8 <+84>: cmn r0, #1 It was basically the same list of ports that had built for the cortex-a72 target context (208 armv7/cortex-a7 vs. 209 cortex-a72). I've no evidence of native aarch64 problems. The cortex-a57 self built its 209 just fine and so far the a57's cortex-a53 targeted build of the 209 has had no problems (built 148 with 61 yet to finish). So the problem seems to be specific armv7 activity on aarch64 systems, or possibly on cortex-a72 specifically. For reference . . . The chroot used to examine the expanded .tar content reports: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 merge-base: CommitDate: 2021-03-06 21:46:28 +0000 e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] Fix = AP bringup on 32-bit AIM SMP FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm armv7 1400005 1400005 The host system reports: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 merge-base: CommitDate: 2021-03-06 21:46:28 +0000 e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] Fix = AP bringup on 32-bit AIM SMP FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm64 aarch64 1400005 1400005 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 01:18:46 2021 Return-Path: Delivered-To: freebsd-current@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 979ED577EAA for ; Wed, 10 Mar 2021 01:18:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-33.consmr.mail.ne1.yahoo.com (sonic317-33.consmr.mail.ne1.yahoo.com [66.163.184.44]) (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 4DwDjx0Ltxz3njR for ; Wed, 10 Mar 2021 01:18:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615339123; bh=jfRrKk+mBpbIajIXJTmFUzrUB3tA6nkFXhO5BH2Ulji=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jqAE256EJod2kpwiD2t4NTdH12otjtoLkcB7qFbqrjGkL9GE11GjKBZeiIqu9YzNLZE1D3HIueL8/c9nr3uelyEa15srLZ+HPjjoAmnPwK9B+wK1Ipriw9U5ugF9Dx9p5ZkALki9G6RAkXDPQiNdQYRkpKsZ82vGAosvePqDbqvXyY6xQUMltlVL51K6HBEjNvGEq/Mf/yFw4ho9meF25Pgoft80DgMlJ6kYdpTXozzMxsTpgwWT75N+6t6zQOHplqi9/BwLY8MyqNQIhU0l9gAL0R9J+u7pzxOAp92cdZMLP+x5BRSPWkg9sR/CFMlu5Jiq7Vyo+ox8AMffUDsvbw== X-YMail-OSG: wogiDtgVM1kKYDPeckkRvH1ENM9C9huPWQAQ5ZBKYbYvdBFlRqZOGy42lwsBIiK PHGDtaN12JfRymogZvyyYPLfQxV3JAU4TE6PcBtU73X5zViH.huTDImALoOJ.QMBXsHaZO00frA9 u6CoKsRNff_SXsDCb4onRvH3y01dlhdgSPanlx67WUNpHgLk.QHbZbZHh6_vrGOh9YwCTMst9P_1 UlHD23mOFFFpC.zF0taFksXEIxl8R9hQbEyhAJMGGi_GA4EfuSWLRHOjbeJnNzMLnJqGU1Z1Xfo0 R4i0Aj0ZC9nmLUTlAh9Zl17r0JMtX_.iOJj63VwyHleZlpp2lUiytPRN3N2YVgtwLq_sRTwtilaA RRn1C_D7ejT35G1Rl_jspwAAavUqwrV6WQ00SZ6b2EJE1_r7rOxKZOyGddGJuXTUQi.qWuKQ13uO xAnyp2g5jwjqpe0oj29rIcysz3azOm7_L1FhCMKFXF0xt362byV1W1l_2sbNLVHj8cvopZ58BGz4 EAYc3r1vSp_._Fka3UdPSjpI9cV8G8s93wS8AaEQK3EmU0GgX_5KXlksvF6EHQOuuu.bucG0vOf6 A1wCnlmb_214K.kIXr1KGWtU.d5sR92djxtue_J_MYkW96qtop7OcX7Apu30z.X9VGcvvwpgqDsH 8qottChg04VPrRZhzdIY0X1rY5Dpqei4Zcep.BZdE4839X9SaGTUEVLtZXMW7WZgpDRH8nUc7c5Q SkmUWtapWgP6SlAQEO7xcom6Ss8Lwx2KzVbma7lSLFgbjPwMka1CbOIhxEy9UhtaOj52km1algF2 GI3L8Wktxb8emSpmYTVq.uKOWP7V9qQRVhwgHzR0KoWC_j9F8q45y2Ph5MMjmPKv5tzvSQptRRnG utkcJ1UqybqQbcGtNvePVW3fHODmsv7X0rVf3hYe42S23T.kdvNb5f1arzu1Rg3Z9mYfAuZjcrf9 2RpCrw2rV4QE5SOsaClL__iXbfbE7ndIYIuLB6ScVhsccpux45Yjlq4ZZvo3zIgtkbtKYM.OlfQM fAWK21cicT3fvxWL1dQQqSij.WKTDhrJMlCZ7p.wYzvleweJmbOQiKcqz2fCinvU0l2Vvnq8VATV tGiE3qK0JULslaAuE18t9YZKPN9yfWmOIDsPCk8Z7JkXSZCHHImtZKX9xMuflgnuJHCprD1DyEFN x2wQvOyRjS6w071DHwBpWPAyU2T8uLwbb6DMxhHnLbCSKWXciEeIp3no7oXYL_gZ2FsMVisxAd_u h7faVij1bvNQ9prdgkwzBYo1LVb0U3zrhj47LsrMYe4rOoYn8MUgdIoN1QRvCsUMG4Hel.6Fihj7 Sk_P_vSg8jFYLWnfSmCz0TB0ziOHxGNWF.s__GxdhSKsIq95mRGhXUK4n5RgOb_Fs7lymSCLmpF1 i.QpO_MY_r49xi1P5k9Rpw7IoI_KsQpr2T6lgb7A1MwpMsGyEQ.9qab5TUlBYIVVyP53ftXtcx7f hBE8q.yBLsrSKFn6_rZlgPAHDm8MuOful0ToigtkjVuSjLta6rvSBj4hRC4ULlOfNQEmEhppFNXr IQn298L.NpeRVnW2wzKD3.pfcPlnnTYzsvNzW1eE9aIGxKFJLmELjhDkqzra9Goxx_Ah558V9cu8 MDkiECV3YpL_cqo7bq8Jhwn_F4rX8RlYqPwpVb6fbMRc5mKykWtvtdh4gPL11flEn2pCfmVEUe9z lYbyV0r425cuDQAB6nplEANAIu5mxPkxVCw3FIW5sCdQXK23gLKa_V.B5_Om27kToCY9MQ_id7tC ZLtbC2yM8TU0m0E7FZgzhZLxXT5G1rJkIA.yaM4Y0WV.O4oIYRn.kYXJjx5LhINEOhWQ8nVrHfA1 7KwnerdxSyJyWXQwocPWGsvUsLOU7UAn0gmzL7E7cNQsJxSHjFm71MLojgwOzis6C8Fm6wOyPori kGwAqmn1xbUSjL.neiH0nrCLKvVdqLbtvIRmS.JLQsGYxI_eNJ8YXNE1yHdHvS7sCbcrPOW8CKnu WE0lZH71hLckojWvW.fCOKkT2aILhNSZz.JFhaaMe_ya0sWaj5MjQ0_MUIFP_AyniypgialJCX1g mtme25p3Ds5kYa4SoyuWc1rAP.nvum4aj6n5_YwDm9w2AchK79wkDVQ0zqn9_4oFmAsBgbvjTUke Ls5zs6cxHUHSgOIoMVXvM1sFv7lsRWzZDT8Ct7pNiYOOsYm_Z0l4GsG262W_9DnHAEHfje1EMEZy CuxmHuuKJL3.KoZK7.ddpdbnlohavr07kfx4YXFDdZ6o0x99aFJhxvC4zV5zTMkVDCwouRUyx7d6 kqFRe3gM6FUn0E8_3csZMDyLLXOz8hfVMRpOSe2xF8yb4ZiWcik5iBMGxJtERy_OGU8IlOS6jLlu .BlaXPAWT8aH0wk15r1_GPVDlfCWa8bbJwfYCKCsrf6ruPCVHDz06n.2dQI9WD75AcabdkqdKLZj 1cfPnmDyXfmfTRv9z5lYmTpmg_rL_owzAjFOYRdn7e.LLVUX1ATEg3ASeBPy9yonUsLUvd.6yXb_ iaXB3Ddsvgo1XgmlOEMj090cl_wMMmtHKR4qleoPS_q2w1YpearvT3fyGCVQXGF6xgSHzRImninT yZqYV1ooT X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 01:18:43 +0000 Received: by smtp407.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6de5173abb71752081dfa022bbbb967c; Wed, 10 Mar 2021 01:18:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system Date: Tue, 9 Mar 2021 17:18:34 -0800 References: <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> To: freebsd-arm , freebsd-current In-Reply-To: <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> Message-Id: <7F086465-38C0-49C0-830C-2DB0BE71169C@yahoo.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwDjx0Ltxz3njR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.42 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.92)[-0.921]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.184.44:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.184.44:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.184.44:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.184.44:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 01:18:46 -0000 On 2021-Mar-9, at 15:39, Mark Millard wrote: > After using poudriere to build ports for native cortex-a72 > on the MACCHIATObin Double Shot (and similarly for > cortex-a57 on the OverDrive 1000) I attempted to do my > usual bulk build targeting cortex-a7 via poudriere-devel: >=20 > # poudriere jail -i -jFBSDFSSDjailArmV7 > Jail name: FBSDFSSDjailArmV7 > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud > Jail fs: =20 > Jail updated: 2021-01-27 14:47:10 > Jail pkgbase: disabled >=20 > But I got some SIGSEGV failures that I've never before > had analogous failures. I'll show the 6 backtraces. > They all have a similar type-of-context but in various > programs, summarized as (from the lldb bt outputs): >=20 > gmake`new_job(file=3D) [3 examples] > and: > sh`waitcmdloop(job=3D0x00064230) [2 examples] > and: > cmake`(anonymous namespace)::RunCommand(command=3D, = output=3D"14.0-CURRENT\n", retVal=3D, dir=3D, = verbose=3D, encoding=3DAuto) >=20 > (Only 83 ports built of 208 built, 5 failed, and 120 were > skipped.) >=20 > I have not yet tried simply running poudriere again to see > how reliable the specific failures may or may not be: I'm > first collecting and reporting this information. Nor have > I tried doing the build on the cortex-a57 context instead. I have a little re-run information now: No -JN with ALLOW_MAKE_JOBS=3Dyes: seems repeatable -J1 with ALLOW_MAKE_JOBS=3Dyes: seems repeatable -J1 without ALLOW_MAKE_JOBS: mixed so far in the one run. For -J1 without ALLOW_MAKE_JOBS for as far as the bulk build has gotten (still in progress): [00:22:03] [01] [00:21:12] Finished devel/cmake | cmake-3.19.6: Failed: = configure [00:23:04] [01] [00:00:59] Finished textproc/libxslt | libxslt-1.1.34_1: = Success [00:33:35] [01] [00:00:19] Finished textproc/itstool | itstool-2.0.6: = Failed: configure Some ports dependent on libxslt-1.1.34_1 are building as well, devel/glib20 , textproc/minixmlto , and x11/xkeyboard-config have built. I'm not sure it is reasonable to wait on -J1 without ALLOW_MAKE_JOBS to see what the devel/gdb and x11-toolkits/libXaw build does. For example qt5-core that is now building and may not be worth waiting for. The results do suggest that the issue is racy, no matter if the number of active processes/threads changes the probabilities involved or not. > I'll note that when I looked at detail as the assembler level > it appeared that there was a frame not shown between #0 and #1 > in lldb's output: Frame #1 "->" was indicating the instruction > after a simple bl to a not-shown subroutine. >=20 > For building textproc/libxslt : > (jobserver_acquire not shown between #0 and #1) >=20 > (lldb) bt > * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 > frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] > frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x400a9700) at remake.c:1234:11 > frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 > frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #6: 0x0004b08c gmake`check_dep(file=3D0x400a9700, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc4ac) at = remake.c:1024:20 > frame #7: 0x00049074 gmake`update_file at remake.c:572:17 > frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #9: 0x0004b08c gmake`check_dep(file=3D0x400a9400, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc564) at = remake.c:1024:20 > frame #10: 0x00049074 gmake`update_file at remake.c:572:17 > frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #12: 0x0004b08c gmake`check_dep(file=3D0x400a8f20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc61c) at = remake.c:1024:20 > frame #13: 0x00049074 gmake`update_file at remake.c:572:17 > frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 > frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd470, = envp=3D0xffffffff) at main.c:2589:13 > frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >=20 > -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >=20 > 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 > -> 0x3b5f8 <+1292>: cmp r0, #1 >=20 >=20 > For building x11-toolkits/libXaw : > (jobserver_acquire not shown between #0 and #1) >=20 > (lldb) bt > * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 > frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] > frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036a580) at remake.c:1234:11 > frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 > frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036a580, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc31c) at = remake.c:1024:20 > frame #7: 0x00049074 gmake`update_file at remake.c:572:17 > frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036a220, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc3d4) at = remake.c:1024:20 > frame #10: 0x00049074 gmake`update_file at remake.c:572:17 > frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #12: 0x0004b08c gmake`check_dep(file=3D0x40369ec0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc48c) at = remake.c:1024:20 > frame #13: 0x00049074 gmake`update_file at remake.c:572:17 > frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 > frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd500, = envp=3D0xffffffff) at main.c:2589:13 > frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >=20 > -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >=20 > 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 > -> 0x3b5f8 <+1292>: cmp r0, #1 >=20 >=20 > For building textproc/itstool : > (dowait not shown between #0 and #1) >=20 > (lldb) bt > * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 > frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 > frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 > frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 > frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 > frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 > frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >=20 > -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >=20 > 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 > -> 0x31aa8 <+84>: cmn r0, #1 >=20 >=20 > For building devel/cmake : > (cmsysProcess_WaitForData not shown between #0 and #1) > (Note: the failing cmake is Bootstrap.cmk/cmake .) >=20 > (lldb) bt > * thread #1, name =3D 'cmake', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x000fd124 cmake`(anonymous = namespace)::RunCommand(command=3D, output=3D"14.0-CURRENT\n",= retVal=3D, dir=3D, verbose=3D, = encoding=3DAuto) at cmExecProgramCommand.cxx:223:15 > frame #2: 0x000fca24 cmake`cmExecProgramCommand(args=3D,= status=3D) at cmExecProgramCommand.cxx:95:14 > frame #3: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmExecProgramCommand(std::__1:= :vector, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmExecProgramCommand.cxx:26), args=3D,= status=3D0xffffb9a8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 > frame #4: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 > frame #5: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 > frame #6: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408798b0, = status=3D, deferId=3D) at cmMakefile.cxx:462 > frame #7: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2800, = functions=3D, inStatus=3D0xffffbd10) at = cmIfCommand.cxx:149:10 > frame #8: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2800, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 > frame #9: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 > frame #10: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40868440, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbc78) = at cmMakefile.cxx:421 > frame #11: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2760, = functions=3D, inStatus=3D0xffffc078) at = cmIfCommand.cxx:149:10 > frame #12: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2760, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 > frame #13: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 > frame #14: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408683b8, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbfe0) = at cmMakefile.cxx:421 > frame #15: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2710, = functions=3D, inStatus=3D0xffffc368) at = cmIfCommand.cxx:149:10 > frame #16: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2710, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 > frame #17: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 > frame #18: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40873208, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffc358) = at cmMakefile.cxx:421 > frame #19: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffc3f0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/Modules= /CMakeDetermineSystem.cmake", defer=3D0x00000000) at = cmMakefile.cxx:788:11 > frame #20: 0x0024af34 = cmake`cmMakefile::ReadListFile(this=3D, = filename=3D) at cmMakefile.cxx:737:9 > frame #21: 0x001ce448 = cmake`cmGlobalGenerator::EnableLanguage(this=3D, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalGenerator.cxx:629:9 > frame #22: 0x00310bf4 = cmake`cmGlobalUnixMakefileGenerator3::EnableLanguage(this=3D0x403cc900, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalUnixMakefileGenerator3.cxx:57:28 > frame #23: 0x0025d740 = cmake`cmMakefile::EnableLanguage(this=3D0x4086a000, lang=3D, = optional=3Dfalse) at cmMakefile.cxx:3748:33 > frame #24: 0x0027e198 cmake`cmProjectCommand(args=3D, = status=3D) at cmProjectCommand.cxx:338:6 > frame #25: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmProjectCommand(std::__1::vec= tor, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmProjectCommand.cxx:30), args=3D, = status=3D0xffffc9b8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 > frame #26: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 > frame #27: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 > frame #28: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40884018, = status=3D, deferId=3D) at cmMakefile.cxx:462 > frame #29: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffcae0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/CMakeLi= sts.txt", defer=3D0x4087b010) at cmMakefile.cxx:788:11 > frame #30: 0x00254948 cmake`cmMakefile::Configure(this=3D0x4086a000) = at cmMakefile.cxx:1768:9 > frame #31: 0x001d2e9c = cmake`cmGlobalGenerator::Configure(this=3D0x403cc900) at = cmGlobalGenerator.cxx:1242:10 > frame #32: 0x0031123c = cmake`cmGlobalUnixMakefileGenerator3::Configure(this=3D) at = cmGlobalUnixMakefileGenerator3.cxx:132:28 > frame #33: 0x002f5ab0 cmake`cmake::ActualConfigure(this=3D0xffffd018)= at cmake.cxx:1928:26 > frame #34: 0x002f493c cmake`cmake::Configure(this=3D0xffffd018) at = cmake.cxx:1785:19 > frame #35: 0x002f6fec cmake`cmake::Run(this=3D0xffffd018, = args=3D0xffffcfd8, noconfigure=3Dfalse) at cmake.cxx:2155:19 > frame #36: 0x002fdeec cmake`main [inlined] (anonymous = namespace)::do_cmake(ac=3D, av=3D) at = cmakemain.cxx:300:16 > frame #37: 0x002fde78 cmake`main(ac=3D, = av=3D) at cmakemain.cxx:861 > frame #38: 0x0009b32c cmake`__start(argc=3D6, argv=3D, = env=3D, ps_strings=3D, obj=3D0x403ea004, = cleanup=3D0x403b7aa0) at crt1_c.c:92:7 >=20 > -> 223 while ((p =3D cmsysProcess_WaitForData(cp, &data, = &length, nullptr))) { >=20 > 0xfd120 <+744>: bl 0x3672f8 ; = cmsysProcess_WaitForData at ProcessUNIX.c:1064 > -> 0xfd124 <+748>: cmp r0, #0 >=20 >=20 > For devel/gdb there are 2 cores: a gmake.core and a sh.core >=20 >=20 > For devel/gdb's gmake.core : > (jobserver_acquire not shown between #0 and #1) >=20 > (lldb) bt > * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 > frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] > frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036cda0) at remake.c:1234:11 > frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D4) at remake.c:835 > frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036cda0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6aec) at = remake.c:1024:20 > frame #7: 0x00049074 gmake`update_file at remake.c:572:17 > frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036cc20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6ba4) at = remake.c:1024:20 > frame #10: 0x00049074 gmake`update_file at remake.c:572:17 > frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 > frame #12: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 > frame #13: 0x0003f25c gmake`main(argc=3D130, argv=3D0xffffa36c, = envp=3D0xffffffff) at main.c:2589:13 > frame #14: 0x0002c0fc gmake`__start(argc=3D130, argv=3D,= env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >=20 > -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >=20 > 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 > -> 0x3b5f8 <+1292>: cmp r0, #1 >=20 >=20 >=20 > For devel/gdb's sh.core : > (dowait not shown between #0 and #1) >=20 > (lldb) bt > * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 > frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 > frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x403fd0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 > frame #4: 0x00027800 sh`evaltree(n=3D0x403fd0e4, = flags=3D) at eval.c:289:4 > frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 > frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 > frame #7: 0x0002480c sh`__start(argc=3D26, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >=20 > -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >=20 > 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 > -> 0x31aa8 <+84>: cmn r0, #1 >=20 >=20 >=20 > It was basically the same list of ports that had built for > the cortex-a72 target context (208 armv7/cortex-a7 vs. 209 > cortex-a72). I've no evidence of native aarch64 problems. >=20 > The cortex-a57 self built its 209 just fine and so far the > a57's cortex-a53 targeted build of the 209 has had no > problems (built 148 with 61 yet to finish). >=20 > So the problem seems to be specific armv7 activity on aarch64 > systems, or possibly on cortex-a72 specifically. >=20 >=20 >=20 > For reference . . . >=20 > The chroot used to examine the expanded .tar content reports: >=20 > # ~/fbsd-based-on-what-freebsd-main.sh=20 > merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 > merge-base: CommitDate: 2021-03-06 21:46:28 +0000 > e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. > bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] = Fix AP bringup on 32-bit AIM SMP > FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm armv7 1400005 1400005 >=20 > The host system reports: >=20 > # ~/fbsd-based-on-what-freebsd-main.sh=20 > merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 > merge-base: CommitDate: 2021-03-06 21:46:28 +0000 > e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. > bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] = Fix AP bringup on 32-bit AIM SMP > FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm64 aarch64 1400005 1400005 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 02:54:52 2021 Return-Path: Delivered-To: freebsd-current@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 5DF8257AAC4 for ; Wed, 10 Mar 2021 02:54:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-25.consmr.mail.ne1.yahoo.com (sonic310-25.consmr.mail.ne1.yahoo.com [66.163.186.206]) (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 4DwGrq383mz3tpY for ; Wed, 10 Mar 2021 02:54:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615344889; bh=B+zohv4PpERO1m5tC4bnWNpFGUZbMOnOFT0nzI+Ou5C=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rIFko/hrbSgSW0/dCM/8iQUyu1Q/hjmHmkYRjfsm94HuWRl0KYiRPp9V7zYzLqx3txZbva98jBL7yJRpdpwH6GSjVXZWn0gi2QbZ7ygQ7MjZO0S9wrAeSr1cGvEaR056ALviDXRv1XCGfeOufHBu1NCJcxRAPfnrxhcu7Q2vc/MPqTDsrbsBDYwVScvx98rrFIbv676lCyIY2QopMY32S4Qa0TxtYzg2Woex7v6mHQSM1XIZ+0ev6gFztw4O6Gx/ybiaQqObAoM3rwmp4o49S61QPD9KHcmuqb2FFialzAhN2otMDSbhJpupY4YciqsojijWLXT5WKPzjPnyQw5gWA== X-YMail-OSG: EkUxlC8VM1mQwcC93.eaxRoVD08XCE88gt.egW9V8pUFEzuVbMyb8o2F7Np7NSz 1nRw0bcLV_mruG_C_UIhrOI3TC.wo1WPSbHF9fifCCXXhNP.0RJ6oqoxR6cvHPLsHDfGoyHR_Tlk 8_eal4Pt6S7dsp.MNCEWVeIxvuQAyf7_WkuD2G7xOD9HMkfMjZUUpzOIz6chJwE9dwgNxWa1CJdB dFNhVvRigf44Kv2DBBR7IjEAvti4ga1jQqQb7MjjxcVHKsSbEwpfG7ofqBETyGyvaUCvJPrbA8IL 1CV.ILSUI8cEfUnP0EsSngVsGrtKuRDL130qHzGQsoqa1R8s7Skeq6NWPSWvFUMHZIaAwZDReGAM jItWgE66bLG.sULrHu3Cv2cXZqU50Jml3_ZlFBG7EbEBcWZeTG7O8mXwrZmxNaBhKnrrKUgskkCk C62zn6JLrMqbaNY4BYMyD5VgMbaSeUd0u5Hi8SY6dK5kLkP15_kVfCcCgUyYvZPoMzO0EAJDzkcp pdRqB.U2TaYaMaP7CmEB7PJqETbffMWP4wudx6.5JUIrHduYmMINm7Y53IOkpndSISJmhr5VJ0SO FDzZUVKGJES3RAPEX4OmWM0x9hUB63i8WdGZGYoYSuSWnENrLravrgOkhumoXLeVo71RgHXdjxiZ KgwcePtKxlO_92APhiyeDQbIH0vpgIfl8G_okbad147QwaHrWws5VxeJhIUrb99aU0F0xaMrU3Nn k4PM1sXaMpx4gvb7WUTk6fXd4oKfdWeml3xDhPIfiTCc1NFjIoZ77ffSYyszC_XPJYRFg47Sb7e9 AoH5gqF9NQpOVv59LBStpyoh78xrZi4dh7wV.Yydi9dPPUZ3s39dYc5P5mgzq_YBUNxjeXMWMpVR vceMFM.FEMYJ.oTkbofxkXfbXugBsvmjJksQ.sYPorf3Ze_zaZCerjT0DpFFxfi6y2QzyeIHF95U NrwZplgXQi0eVdgpNyvmg_CjC002xNHukRYvczUPY1nTnqWZj7Q4eV46KNK3CxltNkr7w_iLGNLD NUnKOEehLeN3gTW4iZTzJKoapSVjzUiNkZo_nL6W72GMNHO753YL2BvQZdgjgY9jmVZtAFpIUGp4 AQShiiJuI3wGZpyCipUi2W.HmoTqfbu4CJHJudg8DqFkCxarCN6Vh3gCvrjHBpWjSMqBWMQyPSoJ wkrS_erYPnsh0wZwzF.0.IS8tXWQfKTpwmfhPp_m7Ih57z3O5n2iKyYSKixmgz19HowHhUFzfQRo 8lv4tq3Gs_uFquMygN1.q_Lq4vdda0VcQ6VW93wYNiiwQc8UaI2mf9iHxZ9aAXXHc8q8EICQC4eY X2owJ6zZasInih0WLk.cGArGSxAp.Ja21CpJRh0nFY4UifJmHXzo.01xmM662BjxbysY7W96Vyak 7PcUuBA685Fc.Ak7jQo3juo6kZH60z0RapTUcweKaD4PeBsL6IGGHWFw0VJQLZCbW1Ge7loOYzyr sZZ9W7iMtuAzI7SJye6e_307.L8wspAQwhwFMOR6WwHRqDRY253IYrerX1vvmscSx58.BtKMyP7q ccHenB6qH3q2bkT3uHtNivTsSxxkhqWwTeJ3ib3WBSGFXMEEAwKrcnD_HOs3LKIBgnoGP5pnwNdQ xnwNP5edbfbuz3q0bGDdyyOwZNE4za8OtrqmH9S3wjRLahpm5GtGYfa8pKMhHHsF42C4KKfCGycz PoLZxiFGo99Jcl77K2850DesLWqpliroaGU07i.WUwB8hTh.PYVG.mxcGQi.v6xW9LfV86wOJEGm bdsJFegPheJfruXjvSyJPHjhs96FMKUs9_lhR28p_8hpMXShBMrnYJ97F8u92UN6cXqQoXlD.RY. 2Q3K3ZRV.fu.tA13p6T_uTs3hyP31AeRvtscQbBZ_DcQrrVMyUB6VbtllpW7CZ4owqKGMCsWJTaE rxIVkP4fxmCU3r67I1WEJMkC_kf2dl14fgehpNU8gE6QYTSuvIVH9ZJ_5BGytewHQ138GQ9zIBBv 3W6qAsOODUTIPZYnf335ee3960O.SIqqGUrY6cR3BIGz9cPE.VQ294KnKsz20cKEoyanQ_2GxY1V AjaNl9tfvTbarIozK.TdchtIBDdSzEgLyNRTJvwmdL5XP59KYnWE_W2IF3nEQ75POgrqK.wnQJqe YXBDWCsbyr25Z_kCqJYWLAFBwAYDM91tzUOaMzm32IMX5hrtxL0Fe6rakPHPhYCHqYJOYscgQjyH yRfwqmBJW17kgu_9bHJCN0tMyXkAghRvvrC.iZdG0t3aWYb896g2CjyJ8D1Cqr91B44BaXAFmx4. 6I7N6SRGtsN2QgOH2KWdx7hrijhWnjViLnfVdK0hmOoo_jjSF0ukOSGS.NgCx1zL2T7hQdp2OaFx P5Dy5okUZP4d5s_tzk0MQqfQUuRJRme9eH6HPxiw_Ac5vgynIPQXWhqaRo3zBq6MLXAPaWd6Kojc Wl8kvyhlOx3PbaFS_Rv7EZb9grKzXBmYl0sXOBmMY_JwRy0ytPR0wT9fhKnhBhc_5BPtGtEZW97X mfxfxbGy08mb4xH_gxNa8S4TyuZFkYKT9Q5c6cB5rM834G29FvjU2JbOsPqid574Q8BFawaze_7X 8GeayuI3zB5eLOftn0DWmxLa.ABXrID5RGfU_OobpCp9ro9v.VFVkigZooA3C X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 02:54:49 +0000 Received: by smtp424.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 08545deb0b850d1516c879d56328173b; Wed, 10 Mar 2021 02:54:45 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system Date: Tue, 9 Mar 2021 18:54:43 -0800 References: <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> <7F086465-38C0-49C0-830C-2DB0BE71169C@yahoo.com> To: freebsd-arm , freebsd-current In-Reply-To: <7F086465-38C0-49C0-830C-2DB0BE71169C@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwGrq383mz3tpY X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.186.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.186.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.186.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.186.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 02:54:52 -0000 On 2021-Mar-9, at 17:18, Mark Millard wrote: > On 2021-Mar-9, at 15:39, Mark Millard wrote: >=20 >> After using poudriere to build ports for native cortex-a72 >> on the MACCHIATObin Double Shot (and similarly for >> cortex-a57 on the OverDrive 1000) I attempted to do my >> usual bulk build targeting cortex-a7 via poudriere-devel: >>=20 >> # poudriere jail -i -jFBSDFSSDjailArmV7 >> Jail name: FBSDFSSDjailArmV7 >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud >> Jail fs: =20 >> Jail updated: 2021-01-27 14:47:10 >> Jail pkgbase: disabled >>=20 >> But I got some SIGSEGV failures that I've never before >> had analogous failures. I'll show the 6 backtraces. >> They all have a similar type-of-context but in various >> programs, summarized as (from the lldb bt outputs): >>=20 >> gmake`new_job(file=3D) [3 examples] >> and: >> sh`waitcmdloop(job=3D0x00064230) [2 examples] >> and: >> cmake`(anonymous namespace)::RunCommand(command=3D, = output=3D"14.0-CURRENT\n", retVal=3D, dir=3D, = verbose=3D, encoding=3DAuto) >>=20 >> (Only 83 ports built of 208 built, 5 failed, and 120 were >> skipped.) >>=20 >> I have not yet tried simply running poudriere again to see >> how reliable the specific failures may or may not be: I'm >> first collecting and reporting this information. Nor have >> I tried doing the build on the cortex-a57 context instead. >=20 > I have a little re-run information now: >=20 > No -JN with ALLOW_MAKE_JOBS=3Dyes: seems repeatable > -J1 with ALLOW_MAKE_JOBS=3Dyes: seems repeatable > -J1 without ALLOW_MAKE_JOBS: mixed so far in the one run. >=20 > For -J1 without ALLOW_MAKE_JOBS for as far as the bulk > build has gotten (still in progress): >=20 > [00:22:03] [01] [00:21:12] Finished devel/cmake | cmake-3.19.6: = Failed: configure > [00:23:04] [01] [00:00:59] Finished textproc/libxslt | = libxslt-1.1.34_1: Success > [00:33:35] [01] [00:00:19] Finished textproc/itstool | itstool-2.0.6: = Failed: configure >=20 > Some ports dependent on libxslt-1.1.34_1 are building as well, > devel/glib20 , textproc/minixmlto , and x11/xkeyboard-config > have built. >=20 > I'm not sure it is reasonable to wait on -J1 without > ALLOW_MAKE_JOBS to see what the devel/gdb and > x11-toolkits/libXaw build does. For example qt5-core > that is now building and may not be worth waiting for. >=20 > The results do suggest that the issue is racy, no matter > if the number of active processes/threads changes the > probabilities involved or not. I stopped the build and continued by starting another . . . Without both -J and ALLOW_MAKE_JOBS ((so implicitly -J4 in the context) it got the following results for the 4-left of 5 originally failing: [00:00:51] [02] [00:00:19] Finished textproc/itstool | itstool-2.0.6: = Failed: configure [00:05:00] [02] [00:02:38] Finished x11-toolkits/libXaw | = libXaw-1.0.13_3,2: Success [00:19:02] [03] [00:15:00] Finished devel/gdb@py37 | gdb-10.1_1: Failed: = build [00:29:33] [01] [00:29:01] Finished devel/cmake | cmake-3.19.6: Failed: = configure 17 ports built that depend on textproc/libxslt and/or x11-toolkits/libXaw . The 3 failures above made the rest (100) skip. textproc/libxslt and x11-toolkits/libXaw sometimes failing and sometimes not suggests a racy context at some level of the operations involved. >> I'll note that when I looked at detail as the assembler level >> it appeared that there was a frame not shown between #0 and #1 >> in lldb's output: Frame #1 "->" was indicating the instruction >> after a simple bl to a not-shown subroutine. >>=20 >> For building textproc/libxslt : >> (jobserver_acquire not shown between #0 and #1) >>=20 >> (lldb) bt >> * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 >> frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] >> frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x400a9700) at remake.c:1234:11 >> frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 >> frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #6: 0x0004b08c gmake`check_dep(file=3D0x400a9700, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc4ac) at = remake.c:1024:20 >> frame #7: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #9: 0x0004b08c gmake`check_dep(file=3D0x400a9400, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc564) at = remake.c:1024:20 >> frame #10: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #12: 0x0004b08c gmake`check_dep(file=3D0x400a8f20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc61c) at = remake.c:1024:20 >> frame #13: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 >> frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd470, = envp=3D0xffffffff) at main.c:2589:13 >> frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >>=20 >> -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >>=20 >> 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 >> -> 0x3b5f8 <+1292>: cmp r0, #1 >>=20 >>=20 >> For building x11-toolkits/libXaw : >> (jobserver_acquire not shown between #0 and #1) >>=20 >> (lldb) bt >> * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 >> frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] >> frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036a580) at remake.c:1234:11 >> frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D6) at remake.c:835 >> frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036a580, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc31c) at = remake.c:1024:20 >> frame #7: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036a220, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc3d4) at = remake.c:1024:20 >> frame #10: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #12: 0x0004b08c gmake`check_dep(file=3D0x40369ec0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffffc48c) at = remake.c:1024:20 >> frame #13: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #14: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #15: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 >> frame #16: 0x0003f25c gmake`main(argc=3D2, argv=3D0xffffd500, = envp=3D0xffffffff) at main.c:2589:13 >> frame #17: 0x0002c0fc gmake`__start(argc=3D2, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >>=20 >> -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >>=20 >> 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 >> -> 0x3b5f8 <+1292>: cmp r0, #1 >>=20 >>=20 >> For building textproc/itstool : >> (dowait not shown between #0 and #1) >>=20 >> (lldb) bt >> * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 >> frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 >> frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 >> frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 >> frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 >> frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >>=20 >> -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >>=20 >> 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 >> -> 0x31aa8 <+84>: cmn r0, #1 >>=20 >>=20 >> For building devel/cmake : >> (cmsysProcess_WaitForData not shown between #0 and #1) >> (Note: the failing cmake is Bootstrap.cmk/cmake .) >>=20 >> (lldb) bt >> * thread #1, name =3D 'cmake', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x000fd124 cmake`(anonymous = namespace)::RunCommand(command=3D, output=3D"14.0-CURRENT\n",= retVal=3D, dir=3D, verbose=3D, = encoding=3DAuto) at cmExecProgramCommand.cxx:223:15 >> frame #2: 0x000fca24 cmake`cmExecProgramCommand(args=3D,= status=3D) at cmExecProgramCommand.cxx:95:14 >> frame #3: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmExecProgramCommand(std::__1:= :vector, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmExecProgramCommand.cxx:26), args=3D,= status=3D0xffffb9a8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 >> frame #4: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 >> frame #5: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 >> frame #6: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408798b0, = status=3D, deferId=3D) at cmMakefile.cxx:462 >> frame #7: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2800, = functions=3D, inStatus=3D0xffffbd10) at = cmIfCommand.cxx:149:10 >> frame #8: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2800, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 >> frame #9: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 >> frame #10: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40868440, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbc78) = at cmMakefile.cxx:421 >> frame #11: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2760, = functions=3D, inStatus=3D0xffffc078) at = cmIfCommand.cxx:149:10 >> frame #12: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2760, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 >> frame #13: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 >> frame #14: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x408683b8, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffbfe0) = at cmMakefile.cxx:421 >> frame #15: 0x001eabac = cmake`cmIfFunctionBlocker::Replay(this=3D0x403d2710, = functions=3D, inStatus=3D0xffffc368) at = cmIfCommand.cxx:149:10 >> frame #16: 0x00157d50 = cmake`cmFunctionBlocker::IsFunctionBlocked(this=3D0x403d2710, = lff=3D, status=3D) at = cmFunctionBlocker.cxx:42:20 >> frame #17: 0x002484a4 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = cmMakefile::IsFunctionBlocked(this=3D0x4086a000, lff=3D, = status=3D) at cmMakefile.cxx:3426:40 >> frame #18: 0x00248484 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40873208, = status=3D, deferId=3Doptional, std::__1::allocator > > @ 0xffffc358) = at cmMakefile.cxx:421 >> frame #19: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffc3f0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/Modules= /CMakeDetermineSystem.cmake", defer=3D0x00000000) at = cmMakefile.cxx:788:11 >> frame #20: 0x0024af34 = cmake`cmMakefile::ReadListFile(this=3D, = filename=3D) at cmMakefile.cxx:737:9 >> frame #21: 0x001ce448 = cmake`cmGlobalGenerator::EnableLanguage(this=3D, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalGenerator.cxx:629:9 >> frame #22: 0x00310bf4 = cmake`cmGlobalUnixMakefileGenerator3::EnableLanguage(this=3D0x403cc900, = languages=3D0xffffc63c, mf=3D0x4086a000, optional=3Dfalse) at = cmGlobalUnixMakefileGenerator3.cxx:57:28 >> frame #23: 0x0025d740 = cmake`cmMakefile::EnableLanguage(this=3D0x4086a000, lang=3D, = optional=3Dfalse) at cmMakefile.cxx:3748:33 >> frame #24: 0x0027e198 cmake`cmProjectCommand(args=3D, = status=3D) at cmProjectCommand.cxx:338:6 >> frame #25: 0x002a0ca0 = cmake`InvokeBuiltinCommand(command=3D(cmake`cmProjectCommand(std::__1::vec= tor, = std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&) at cmProjectCommand.cxx:30), args=3D, = status=3D0xffffc9b8)(std::__1::vector, std::__1::allocator >, = std::__1::allocator, std::__1::allocator > > > const&, = cmExecutionStatus&), std::__1::vector > const&, cmExecutionStatus&) at = cmState.cxx:430:10 >> frame #26: 0x00248988 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::__function::__value_func > const&, = cmExecutionStatus&)>::operator(this=3D, = __args=3D, = __args=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:1884:16 >> frame #27: 0x00248980 = cmake`cmMakefile::ExecuteCommand(cmListFileFunction const&, = cmExecutionStatus&, cm::optional, std::__1::allocator > >) [inlined] = std::__1::function > const&, = cmExecutionStatus&)>::operator(this=3D, = __arg=3D, = __arg=3D)(std::__1::vector > const&, cmExecutionStatus&) = const at functional:2556 >> frame #28: 0x00248980 = cmake`cmMakefile::ExecuteCommand(this=3D0x4086a000, lff=3D0x40884018, = status=3D, deferId=3D) at cmMakefile.cxx:462 >> frame #29: 0x0024a628 = cmake`cmMakefile::RunListFile(this=3D, listFile=3D0xffffcae0,= = filenametoread=3D"/wrkdirs/usr/ports/devel/cmake/work/cmake-3.19.6/CMakeLi= sts.txt", defer=3D0x4087b010) at cmMakefile.cxx:788:11 >> frame #30: 0x00254948 cmake`cmMakefile::Configure(this=3D0x4086a000) = at cmMakefile.cxx:1768:9 >> frame #31: 0x001d2e9c = cmake`cmGlobalGenerator::Configure(this=3D0x403cc900) at = cmGlobalGenerator.cxx:1242:10 >> frame #32: 0x0031123c = cmake`cmGlobalUnixMakefileGenerator3::Configure(this=3D) at = cmGlobalUnixMakefileGenerator3.cxx:132:28 >> frame #33: 0x002f5ab0 cmake`cmake::ActualConfigure(this=3D0xffffd018)= at cmake.cxx:1928:26 >> frame #34: 0x002f493c cmake`cmake::Configure(this=3D0xffffd018) at = cmake.cxx:1785:19 >> frame #35: 0x002f6fec cmake`cmake::Run(this=3D0xffffd018, = args=3D0xffffcfd8, noconfigure=3Dfalse) at cmake.cxx:2155:19 >> frame #36: 0x002fdeec cmake`main [inlined] (anonymous = namespace)::do_cmake(ac=3D, av=3D) at = cmakemain.cxx:300:16 >> frame #37: 0x002fde78 cmake`main(ac=3D, = av=3D) at cmakemain.cxx:861 >> frame #38: 0x0009b32c cmake`__start(argc=3D6, argv=3D, = env=3D, ps_strings=3D, obj=3D0x403ea004, = cleanup=3D0x403b7aa0) at crt1_c.c:92:7 >>=20 >> -> 223 while ((p =3D cmsysProcess_WaitForData(cp, &data, = &length, nullptr))) { >>=20 >> 0xfd120 <+744>: bl 0x3672f8 ; = cmsysProcess_WaitForData at ProcessUNIX.c:1064 >> -> 0xfd124 <+748>: cmp r0, #0 >>=20 >>=20 >> For devel/gdb there are 2 cores: a gmake.core and a sh.core >>=20 >>=20 >> For devel/gdb's gmake.core : >> (jobserver_acquire not shown between #0 and #1) >>=20 >> (lldb) bt >> * thread #1, name =3D 'gmake', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x0003b5f8 gmake`new_job(file=3D) at = job.c:1870:21 >> frame #2: 0x0002db80 = gmake`execute_file_commands(file=3D) at commands.c:476:3 = [artificial] >> frame #3: 0x00049acc gmake`update_file [inlined] = remake_file(file=3D0x4036cda0) at remake.c:1234:11 >> frame #4: 0x00049a84 gmake`update_file [inlined] = update_file_1(file=3D, depth=3D4) at remake.c:835 >> frame #5: 0x000494ec gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #6: 0x0004b08c gmake`check_dep(file=3D0x4036cda0, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6aec) at = remake.c:1024:20 >> frame #7: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #8: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #9: 0x0004b08c gmake`check_dep(file=3D0x4036cc20, = depth=3D, this_mtime=3D1, must_make_ptr=3D0xffff6ba4) at = remake.c:1024:20 >> frame #10: 0x00049074 gmake`update_file at remake.c:572:17 >> frame #11: 0x00048b80 gmake`update_file(file=3D, = depth=3D) at remake.c:336 >> frame #12: 0x000487e0 = gmake`update_goal_chain(goaldeps=3D) at remake.c:151:22 >> frame #13: 0x0003f25c gmake`main(argc=3D130, argv=3D0xffffa36c, = envp=3D0xffffffff) at main.c:2589:13 >> frame #14: 0x0002c0fc gmake`__start(argc=3D130, argv=3D,= env=3D, ps_strings=3D, obj=3D0x400c4004, = cleanup=3D0x40091aa0) at crt1_c.c:92:7 >>=20 >> -> 1870 got_token =3D jobserver_acquire (waiting_jobs !=3D= NULL); >>=20 >> 0x3b5f4 <+1288>: bl 0x50078 ; = jobserver_acquire at posixos.c:265 >> -> 0x3b5f8 <+1292>: cmp r0, #1 >>=20 >>=20 >>=20 >> For devel/gdb's sh.core : >> (dowait not shown between #0 and #1) >>=20 >> (lldb) bt >> * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 >> frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x403fd0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 >> frame #4: 0x00027800 sh`evaltree(n=3D0x403fd0e4, = flags=3D) at eval.c:289:4 >> frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 >> frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 >> frame #7: 0x0002480c sh`__start(argc=3D26, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >>=20 >> -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >>=20 >> 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 >> -> 0x31aa8 <+84>: cmn r0, #1 >>=20 >>=20 >>=20 >> It was basically the same list of ports that had built for >> the cortex-a72 target context (208 armv7/cortex-a7 vs. 209 >> cortex-a72). I've no evidence of native aarch64 problems. >>=20 >> The cortex-a57 self built its 209 just fine and so far the >> a57's cortex-a53 targeted build of the 209 has had no >> problems (built 148 with 61 yet to finish). >>=20 >> So the problem seems to be specific armv7 activity on aarch64 >> systems, or possibly on cortex-a72 specifically. >>=20 >>=20 >>=20 >> For reference . . . >>=20 >> The chroot used to examine the expanded .tar content reports: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 >> merge-base: CommitDate: 2021-03-06 21:46:28 +0000 >> e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >> bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] = Fix AP bringup on 32-bit AIM SMP >> FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm armv7 1400005 1400005 >>=20 >> The host system reports: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> merge-base: bad9fa56620eb82395c5ab66d300e91a0222dde2 >> merge-base: CommitDate: 2021-03-06 21:46:28 +0000 >> e48a1c379bfc (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >> bad9fa56620e (freebsd/main, freebsd/HEAD, pure-src, main) [PowerPC] = Fix AP bringup on 32-bit AIM SMP >> FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245316-e48a1c379bfc GENERIC-NODBG arm64 aarch64 1400005 1400005 >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 03:17:38 2021 Return-Path: Delivered-To: freebsd-current@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 3E65D57B128 for ; Wed, 10 Mar 2021 03:17:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-30.consmr.mail.ne1.yahoo.com (sonic301-30.consmr.mail.ne1.yahoo.com [66.163.184.199]) (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 4DwHM52sVYz3w0q for ; Wed, 10 Mar 2021 03:17:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615346255; bh=/UK3eoVfyG3iVY/73vHJAkJ3snlN5LYD49C63zYuFPF=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZHP9UtNu11dbmcWVhADf4YsvhoKg1/HahlFzrgYcNuHgLaJcVOtfOnxegZZik4AFWVaQor+NlTXgWcsEv1H5wKRLKkYE6Ta0PlWQhyN+HP+F3bM64OGWifAz9TUPMbYxwzrYfZwkpvDlYjlo9+SeqWnGgOuO+hxMCRTZEh4vQW7fKJXOwXnHC1XvT0bsK0M6JvUjsa3SCKUI3oVlGPFiwsfBenPkIUdblEo5GV28e30R+3qGqiG8efB/NfYU8iXqmxvvvueJXGQAUpzgPaXFdzbvXXu6z4vVC8veDx5EE7nLml7+cE7Ah1RxhyVSnniDwztamfr80zGVqAvRrJkxuQ== X-YMail-OSG: x9bSht4VM1kARiyJsM9ivueSnavFK8KP_8X.dQ5nYtRMUyIsMjEUU9lfDalP49d ioi5Hckt63_DKIxI9AzGcjTznUv5tM17KjmxiFL.fzVAdvohQVcFjnYfE4NaLhiAGwCOrZz5H27l PPOV9LOUm8D52VN46JjYzHK96iKgFYYyl0faTOyBnvPyUH78F_xN14hpisNotRNTFFFLb1EKocBU F8d3tVi6ZUCNA9uKVrPd3TGvVuWXErN_7dm8u6Sn5UWaFj4eVJXAbrvPoBRUhTnJBw9OavTFHgRn WSFgfqhNEvktDfi5jpj2grnLSg2VbSbEoVWctpR89kK7V2kkYRkxeAgQLwUTcWjAZ14kadnmtny3 iNgL4u3VAzsMbYkCGjksQ08h.Kx_9O4iXnLN6oSl1CVsqRQMGEBWRzQlhRPJXS7rZRXfLGxQ_ZO8 pw94f9HAS9U.cJR_Pl.rhCk1iBoAdSM4Y0IrMOeXQPZuOVRg0hqaPu0mdw_nvu0ZXZBull3GB7Ci N4EFKi4ImBA0exNEZn9KiqUnSWqsouFU510eEM9DUbxwZdQFIlTiFj3QFi93ZfAGl7HVNbysHmMZ EVSYHAJiscSna3VLoOEeV2PskJsBnvd00ihHseFHuHtIdk1SjbYrA5eyXBLGGdcbZIhy7qqegt_U H3_uKBqaLcNcvR7Mjrtqsj.YYCDIMCKQAVdmp68U.GuXt487iJCv311vGptuJ_w6466IE.FLPYW0 d3IksmjFA17MVj0qTR4xfhkcSciCTRCmynNYRSWUh8OP_7F8tkaDJQXRVOcuSCIKgahg0QM2.FBZ .EgpcVnDn4..VC9HZTG7Ukaa5.vEKJY6iLTXMF711osP23FbRqFQg6F5UPYOHEEW_KrK9UR17YXx rO.aHMXG8xXitzmXEcX5obZ976ahn25td5xgu47EehfmuPmMioDvpogrwwsEXHvOcoDa79bn1.WZ jvphAmdgyxMD0.IqJHOjZgq0SwWBe68Me.41og2pFuBPO.yx.PKUguubtgkACvROhbCvUh5HeW92 qPEkCLMYrB0BsxVG7qAeBwYcwTUWyCHeuSApu46cs7uv6g6W3L0cTljpM_g7jzaYmXtpQfdWuhJq a6EvyuP6ZayVOrDFQyOO95cv7oo3gfpvRQXoBLRiz8gE8Iy8K6qihO9rNbxZF4Dj5IjSQ619Z5jT cd9YJ1P4SOq9MZo6593LVWlhO6e9USq99f.6XVMpXWdHDFXBvuDKy5oG5SiKW4VuCdwfmkGQJk1B xDJ0j8gu7Ly3QWkhsK.e.vmLH.2HugEZAK.97vWG0q_Nzp5YSzceaxXFPh8Qb9y9YTTaWaS4wfMQ TSaQeiCC_4sDiB_HVNV1xqDp8CyqKjH4NWVg3utqBjNTd5uaE823QTiHgmoz599DHYBbK5AcExe_ leta7brZioSV6_UhCNTbu.7HkWIbF.HvtjUqLOtoXFCkfjPs4rLtzYheF.SPV21EgHFg6G0nwkEI NbDwSUYFdgOSo.uJX_0Q7YJsunuogTR1P3puyIn7LpZyivngKVMF5bgK3ySjPxXDCcDMdZ0IwGPt NyEZ5Ho0LW57K3tUmNyvdi5xttlgQXMYSDSJ5ZDogCNuoVCltiF8omKprMebWxkNxnCqiHU4ldF2 fg632HmDmMtDpsmC7FwbnYRXS_3n3qH3VSoCoqql43pJhbQY6t0MIOsCIdr1_1R1EgVF3D_gf4WD 216Z16iyei0rgWxSypmcJyfLw2NmJjt_jFppLe7gkLfPDL_Az6BYEOEPBNgD8MJRjJzMkdrXyWib syrfP4_Mo.p6.k2SKQWG.yVebpdbA4R.okDa9rPxl_aqT_GqH.JiN2ibw4iKy_vnddMLPtdIBssT f2Y1YTtXDAzx6NufsJs1WOg4BNbvOIbI0rRkUEa7LUWeOsIbiWPUkNdxqOBZ1lQZcY8ki3FfpG1f qQrzv0c.naQIQ3SVABTWRc14s_7LPQu34ip09QDr3BE2cfGPOLxI6GxNvExDv29bjtOCNCd8PJnj wdOnNSXlI3TWKKKGtl_axyvySdNx9BZgdQ3Pbn0N5WqiWgThLQlOaWw0J5TGukZ1kchPWlj7ofc7 WqF_El.VNKGADjUtFa2a0oq0WqabNUNo7NZ2bacvR6y5k6CwTtpjqMd1HTrgMheItBzqd52AWfG. u3W0YHOggjZs_Ki93cslOq5I5x3bGBX_LpDZmYEgjtJBoeVMaZUvormI0HcZDv5JWMmOt.vhmyOW _tpwgM1fysjN7Nmx64.eif.p0yACk9zoGSlMc5QGS74bp6Doh4B5ODT_5C.s3UUgYsCxkPEWKBSw QAEOWYEAVQfLDTa.0pMrwatQ51QSZ2W.t3tmZNKHOnQG3iB8aV_mLf7kWptIuTtOyJlwRxy6K3mO ZbJrVO6FCIVBNErxCtPknsELQCNrEUwV93Xxslv3HSBraDWoTpbimP5hI6teD0OnjAAnCpFYv_1v 6UhStyMXtbhAv9KGSKr_CYmDPuH65uMrMDCVQnweNN3PWMpSjQ8YZlpoq_3foRojeMUQyGGzSW5j 2itpa91j9lZbKHi.dUWK1kiqv1E3b4ZQjYSZ_g5MmT3qskxNilVccvytFAyIKSZ0oBnzbxHQ_Q5Y BHJNGCiv6wOWm51xdsqnLdof20JULMbKIhql5WQVE4IbKLJfrGZLpYtU2G29enD.G0lXUlJY9QwF bviis361gZvzwmpI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 03:17:35 +0000 Received: by smtp408.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 294a1eed1cf6de2494b1f12e030d5628; Wed, 10 Mar 2021 03:17:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls while using poudriere-devel to build armv7 ports on aarch64 Message-Id: Date: Tue, 9 Mar 2021 19:17:31 -0800 To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) References: X-Rspamd-Queue-Id: 4DwHM52sVYz3w0q X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.184.199:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.184.199:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.184.199:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.184.199:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 03:17:38 -0000 Using the quickest to so-far-reliably-fail type of example from another thread I used truss to see what happens, here filtered down to two processes that appear to be involved and only near the failure. (The overall truss output is huge from the prior activity in the poudriere bulk relatated activity). Also, this initiated watching from aarch64 but the failing code is armv7. 83630 100199: #340(0x1,0xffffd18c,0xffffd17c) =3D 0 (0x0) 83630 100199: #416(0x14,0xffffd1b4,0xffffd19c) =3D 0 (0x0) 83630 100199: #7(0xffffffff,0xffffd178,0x1,0x0) =3D 0 (0x0) 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) 83731 100161: #1(0x0) =20 83731 100161: process exit, rval =3D 0 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0 = status=3D0 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 83630 100199: process killed, signal =3D 11 (core dumped) As a reminder of the lldb backtrace of the sh.core and the like: (lldb) bt * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV * frame #0: 0xffffe190 frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 (lldb) up frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at jobs.c:608:11 605 break; 606 } 607 } -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, (struct job = *)NULL) !=3D -1); 609 =09 610 sig =3D pendingsig_waitcmd; 611 pendingsig_waitcmd =3D 0; (lldb) disass sh`waitcmdloop: 0x31a54 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 0x31a58 <+4>: add r11, sp, #28 0x31a5c <+8>: sub sp, sp, #4 0x31a60 <+12>: movw r6, #0x3ea0 0x31a64 <+16>: movw r7, #0x3e9c 0x31a68 <+20>: movw r9, #0x4040 0x31a6c <+24>: movw r8, #0x3ea4 0x31a70 <+28>: mov r4, r0 0x31a74 <+32>: movt r6, #0x6 0x31a78 <+36>: movt r7, #0x6 0x31a7c <+40>: movt r9, #0x6 0x31a80 <+44>: mov r10, #0 0x31a84 <+48>: movt r8, #0x6 0x31a88 <+52>: cmp r4, #0 0x31a8c <+56>: beq 0x31ab4 ; <+96> at = jobs.c:590:37 0x31a90 <+60>: ldrb r0, [r4, #0x18] 0x31a94 <+64>: cmp r0, #2 0x31a98 <+68>: beq 0x31b84 ; <+304> [inlined] = getjobstatus at jobs.c:575 0x31a9c <+72>: mov r0, #3 0x31aa0 <+76>: mov r1, #0 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 -> 0x31aa8 <+84>: cmn r0, #1 For reference a local context around the SIGSEGV looks like (all lines in the range selected): . . . 83833 102738: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) 83833 102738: openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) = =3D 3 (0x3) 83833 102738: dup2(3,2) =3D 2 (0x2) 83833 102738: close(3) =3D 0 (0x0) 83833 102738: unlink("./.data.json.SYR1bCaL") =3D 0 (0x0) 83833 102738: dup2(10,2) =3D 2 (0x2) 83833 102738: close(10) =3D 0 (0x0) 83833 102738: exit(0x0) =20 83833 102738: process exit, rval =3D 0 77872 100638: wait4(-1,{ EXITED,val=3D0 },0x0,0x0) =3D 83833 (0x14779) 77872 100638: fcntl(0,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) 77872 100638: = openat(AT_FDCWD,"/var/run/poudriere/lock-poudriere-shared-json_top.pid",O_= RDONLY,00) =3D 3 (0x3) 77872 100638: dup2(3,0) =3D 0 (0x0) 77872 100638: close(3) =3D 0 (0x0) 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 11 (0xb) 77872 100638: openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) = =3D 3 (0x3) 77872 100638: dup2(3,2) =3D 2 (0x2) 77872 100638: close(3) =3D 0 (0x0) 77872 100638: lseek(0,0x0,SEEK_CUR) =3D 0 (0x0) 77872 100638: read(0,"77563",1024) =3D 5 (0x5) 77872 100638: read(0,0xffffffffb9e8,1024) =3D 0 (0x0) 77872 100638: dup2(10,0) =3D 0 (0x0) 77872 100638: close(10) =3D 0 (0x0) 77872 100638: dup2(11,2) =3D 2 (0x2) 77872 100638: close(11) =3D 0 (0x0) 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) 77872 100638: openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) = =3D 3 (0x3) 77872 100638: dup2(3,2) =3D 2 (0x2) 77872 100638: close(3) =3D 0 (0x0) 77872 100638: rmdir("/var/run/poudriere/lock-poudriere-shared-json_top") = =3D 0 (0x0) 77872 100638: dup2(10,2) =3D 2 (0x2) 77872 100638: close(10) =3D 0 (0x0) 77872 100638: sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 (0x0) 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) 77872 100638: openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) = =3D 3 (0x3) 77872 100638: dup2(3,2) =3D 2 (0x2) 77872 100638: close(3) =3D 0 (0x0) 77872 100638: sigaction(SIGINFO,{ 0x239c30 SA_RESTART ss_t },{ SIG_DFL = 0x0 ss_t }) =3D 0 (0x0) 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) -- UNKNOWN FreeBSD32 SYSCALL 1 -- 83731 100161: #1(0x0) =20 83731 100161: process exit, rval =3D 0 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0 = status=3D0 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 83630 100199: process killed, signal =3D 11 (core dumped) 83316 100123: #7(0xffffffff,0xffffca58,0x0,0x0) =3D 83630 (0x146ae) -- UNKNOWN FreeBSD32 SYSCALL 477 -- 83316 100123: = #477(0x0,0x7000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077833728 (0x403e7000) -- UNKNOWN FreeBSD32 SYSCALL 552 -- 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No such = file or directory' -- UNKNOWN FreeBSD32 SYSCALL 552 -- 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No such = file or directory' -- UNKNOWN FreeBSD32 SYSCALL 552 -- 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No such = file or directory' -- UNKNOWN FreeBSD32 SYSCALL 552 -- 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No such = file or directory' -- UNKNOWN FreeBSD32 SYSCALL 477 -- 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077862400 (0x403ee000) -- UNKNOWN FreeBSD32 SYSCALL 4 -- 83316 100123: #4(0x2,0x403ee000,0x21) =3D 33 (0x21) -- UNKNOWN FreeBSD32 SYSCALL 477 -- 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077866496 (0x403ef000) -- UNKNOWN FreeBSD32 SYSCALL 477 -- 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077870592 (0x403f0000) -- UNKNOWN FreeBSD32 SYSCALL 477 -- 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077874688 (0x403f1000) -- UNKNOWN FreeBSD32 SYSCALL 4 -- 83316 100123: #4(0x1,0x403ef000,0x2e) =3D 46 (0x2e) -- UNKNOWN FreeBSD32 SYSCALL 542 -- 83316 100123: #542(0xffffcd54,0x0) =3D 0 (0x0) -- UNKNOWN FreeBSD32 SYSCALL 2 -- 83842 100199: 83316 100123: #2() =3D 83842 (0x14782) -- UNKNOWN FreeBSD32 SYSCALL 6 -- -- UNKNOWN FreeBSD32 SYSCALL 6 -- 83316 100123: #6(0x7) =3D 0 (0x0) 83842 100199: #6(0x5) =3D 0 (0x0) . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 05:11:32 2021 Return-Path: Delivered-To: freebsd-current@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 0ACA857DBB7 for ; Wed, 10 Mar 2021 05:11:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (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 4DwKtV6tScz4X7B for ; Wed, 10 Mar 2021 05:11:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615353089; bh=TtD9JWavAagtxCBb29SHV0ka9pD65n95G/AvhGfBflH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=adWgDPCeQLBG5AUszRffSG2/fedZq6BXSD/YXW5mtzmzRmmyepJMQufAZ3lJI+GZjnVuqNqXHoeVRMUVrcWpLN0TzzUDH7rrSqdnE7Z8J5/O4ggFjX1x8LFN1d7EhWRm0brAotUZl96zh+vQQd098e/y8Oz2jPzB5ZDenNqDl3zX/jkqhqwe/MivcIcjsQANNI/ptqUmCmUUUjONSrEQqskZQBSPmrSnfNb/H+MB5cVLqetObDQKFOHqqlrfkzh70zOkoShwNtSvodZ4l0z7Hmije5JhjkkqLoDP6rvS7Za+q5GJ/+iDnL3GYV25wa6FAjR+0YHvs3ojpSH36NLVQg== X-YMail-OSG: E2R7ArQVM1knT6HOMa7koh1u1JUSEQaNRUq4ANkizAbupB_6qACw2MElQwVTsVK WP9xhBNOKIc.Gz_UWEneHDMRT.vayJkOjcwdSuegUKnkG6cSUdK5Km0Yz9XgTvWF50jH.IdkAcmC w0fqEseWtmpTJOEoGLRQUYJ22nFMw1zSSqfGUG7_pl9C0PtgjBnm.tDCg5AQ5KqhPJxnTwp_0_A2 aT0eD8SthOgK5KzxakusVkfThLQWM0tLAIHq2DnH38kkO5PJXunTSepF.pNzt_GiM5Wl3FN4S_hl OpKHeXfPTDtFzR32g9tuRn7I95x_d3MMGL07ToDGpZMdpF4TRiBybSGVYoYTMr4SCDBbNMdqRkSA 80Lz1YXOr2y81eWG650nQMkg457q0bjbJCUyBQTK8LPnnnpnnrDezZL6c94SDIy_uix4rxh7kjWz 9ee6.BYLXmQk5T3EujTvlr0ZO5XTFq2Z7r1Bs4ubrWaMRD8fNaEzih1e65KboaZ2pZ.xNSQzr0Un oNZiSWlackAXsphwaViXEd_8D2lpYXjs4LzJk9bDXzVa1B_._gnHpKmci0FF.RKJ9Lyc_l0pBDpq BSwg2Y92xIk6GZqJLXNnO6YIZyuAABTw2o3RR6YnBOgrro8K2oCoey7lO4SWBG1fTfzsSO7N6bpC 5TjesOIEr6w7ifs7jtjucoAoLkSh1ANZxA8.1eTNzoDyEcIfuyN.QufHktw5Zx6Sm335kwbMlsWU B26mZEK4rbZMv2Aw.JS5lwxAIbCNJvLQpO5lELXRKsqHddjP872ej13IKuLvXak3.PxlShw2kL3i dcMWlvVdT1NVXNo1FhJuMSveRGECb.jNMy7DO62qYoJir3rFBrteOiQUvTfp1vInuOfaA_UC0c92 z1uUEi0GMMcW4Vljk1zCqbaTd_X_hR_ylhCN_SmiQ.OPCjuYMJQiD_1QTdS6V705wsk3yC4A31cm 3QP.k5YRt3nV7p9TPQW_FlgF6kkBNSTvtfdR7M5K._qc408XX5gEn7xBSAvAzRRiLx62y0Y82VjG N8DmT9Jhn85wNTIFOkmwTV223fV48O2hHr0ECRDcJIMU99WQ5h.lNtCBp_Zu9kKC0WnqIKkVvAj1 FS2jDU4C3DTmqQHRv0Mw3u2FvMndoXbd6xp1LEaB.ZXICDZK3qDHM..wKNi_hQSIC_pOzCKYy5mc _adu86gJqQr2vzmSfe50X.9uIY_jb4dmCA_iWup9eB0hNzMSkKUMol_fstkyXy.ngplJsN6q6DHJ 0knVDYd4jHrMArrGCv641YTeGsKyV8wEu9UXPR_5pykKQvf98F0GR8wpK6dLPQ4sBirjbrLtmqdk q1VcS4wxP7wcBdeqrPJATZwQTcxkac8ozrFZVLM9MFIXtYGqzn4t_kAluVaDTCzpm0Usd5QNEtyB 0UfnNjR3AXYiQqyF3Z_32BiIktHaYWK6tq3whvZ2vo1Tb_eW..VtbvpJfoJ5a4mEJIbyktxdzybL V1pOrMCbf7fU73L32zwnfknxOsAo6ifAu79kMpy7Cx.v_J718crJNF47WYJoEB8WP3yfqLbOwElQ cEVloDEhpgrmmyW_EIxgTRsL1uSKZUvJu1LgcaVbZAOLKINoRBJq2mw2e5j.CvfSYDvfsB3NTTQS wm__aeC7Z.X9G1dbBgIT_k1W8P7rUl7HM81jhJk0J8SEWcrdpre3nkq7BuT7FZFntGD6nLq3fRFg yF9IwNFCaR7g2EKf2UfeJ.pCkZmrQWMvNwrwulKdii0YazuWJBTqkgy2FIsuY2xHq_FgeR_wk00m 5B3YKxVSVumyaDj72OuRfiElWrbuBRa7DzkDO3nrf0f1DPi5VNqgUGTukCelOGj8RJvSZDUTSPpI rRoTWYGNRHgdwX5VT3ZWnjbwfOKwTJuUaKaVe2LnJ75juheikngJ5BCvzkNfVGTfCG3b3MWPfcuW pW8atHjxVx2i1g2wblKjeLxaqOSOy8VTjdVSl7P5jDQHO0T6V0qR4vc4j6vXXulsaHGJi0LyLW6R Nzbh38bWG_xlLEG440eSiqcyjqNCl0A15LExCHZbBGWnXQIF9da3aH7Ynk7pgqAnBhMJS1WXmA66 IOxbma9iRvUMEebrxysEMMEli5Yicoq62zEkViycBXxA4.FfWCVoKS6YAbNMnXZpqcskKlBMT6Ke yIFsGq0DXmCAftxR4aEreUVB_dka0eOM3inPTWLpfpIdIw4hxh9vW4HX4KD6TegVvVG4_bQ9FXfQ qnm0seW83VykF3DbV.AokzaTPlXK4x0jJmQOZwFmjgF1Ql1XMIdyc5stVR9Bx5r3N.ffKYytlE9e pdlwDGPzvAB.HCQzqlGFIwU_fHmC5ZZU0SJfgEHId8pIGvFW2Bay1lM5KMJvlcL0iQvQtXmj5HLl H_JuMlgNhdK6ur8csV9KHvpBFaAPV5DGYi.35FEThjnh5AIj46lPS_bzvSmLrpNsuIFhEnuDXxB2 AabgfcR6EkAq1YQ_eV2xaY7pLzV0EsHrF8_pliynIwGm2UXv_D01ma.ikIJQHoZ2ri6BA9luHgIS 7SuRjVgCmxyb8ZGN49xQ5XD3e_NI3yU04O.drPdonOo_O.Vb3xt4vYfLkD.aSv6Jdbb_95WTw_YA lHeWnEfxbkEND6246DkT2Ar8lHEh1VRJ64SOsQ3TTbPwCaNsiKz2S6_m9I4nyUpdgtKnWTGg8NXU 6b_yLC7t61IZ6.gyJVvK4BZkhGe18xD0.vif1a_RKW3EHApyeEm53HD8soc961Q6emqpuecV8AHq iTis01CY4vg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 05:11:29 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9c7fcc94fb660efc83590cf6e2ebef7a; Wed, 10 Mar 2021 05:11:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls (cortex-a57/a72 fail, cortex-a53/cortex-a7 work) From: Mark Millard In-Reply-To: Date: Tue, 9 Mar 2021 21:11:22 -0800 Cc: Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwKtV6tScz4X7B X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.189.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.189.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.189.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.189.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 05:11:32 -0000 On 2021-Mar-9, at 19:17, Mark Millard wrote: [My only testing context for this has been main, not 13.0. But it might be a 13.0 worry.] > Using the quickest to so-far-reliably-fail type of example from > another thread I used truss to see what happens, here filtered > down to two processes that appear to be involved and only > near the failure. (The overall truss output is huge from the > prior activity in the poudriere bulk relatated activity). Also, > this initiated watching from aarch64 but the failing code is > armv7. >=20 > 83630 100199: #340(0x1,0xffffd18c,0xffffd17c) =3D 0 (0x0) > 83630 100199: #416(0x14,0xffffd1b4,0xffffd19c) =3D 0 (0x0) > 83630 100199: #7(0xffffffff,0xffffd178,0x1,0x0) =3D 0 (0x0) > 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) > 83731 100161: #1(0x0) =20 > 83731 100161: process exit, rval =3D 0 > 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0 = status=3D0 > 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' > 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 > 83630 100199: process killed, signal =3D 11 (core dumped) >=20 > As a reminder of the lldb backtrace of the sh.core > and the like: >=20 > (lldb) bt > * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV > * frame #0: 0xffffe190 > frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 > frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 > frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 > frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 > frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 > frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 > frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 > (lldb) up > frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at jobs.c:608:11 > 605 break; > 606 } > 607 } > -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); > 609 =09 > 610 sig =3D pendingsig_waitcmd; > 611 pendingsig_waitcmd =3D 0; >=20 > (lldb) disass > sh`waitcmdloop: > 0x31a54 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} > 0x31a58 <+4>: add r11, sp, #28 > 0x31a5c <+8>: sub sp, sp, #4 > 0x31a60 <+12>: movw r6, #0x3ea0 > 0x31a64 <+16>: movw r7, #0x3e9c > 0x31a68 <+20>: movw r9, #0x4040 > 0x31a6c <+24>: movw r8, #0x3ea4 > 0x31a70 <+28>: mov r4, r0 > 0x31a74 <+32>: movt r6, #0x6 > 0x31a78 <+36>: movt r7, #0x6 > 0x31a7c <+40>: movt r9, #0x6 > 0x31a80 <+44>: mov r10, #0 > 0x31a84 <+48>: movt r8, #0x6 > 0x31a88 <+52>: cmp r4, #0 > 0x31a8c <+56>: beq 0x31ab4 ; <+96> at = jobs.c:590:37 > 0x31a90 <+60>: ldrb r0, [r4, #0x18] > 0x31a94 <+64>: cmp r0, #2 > 0x31a98 <+68>: beq 0x31b84 ; <+304> [inlined] = getjobstatus at jobs.c:575 > 0x31a9c <+72>: mov r0, #3 > 0x31aa0 <+76>: mov r1, #0 > 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 > -> 0x31aa8 <+84>: cmn r0, #1 >=20 >=20 > For reference a local context around the > SIGSEGV looks like (all lines in the range > selected): >=20 > . . . > 83833 102738: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) > 83833 102738: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) > 83833 102738: dup2(3,2) =3D 2 (0x2) > 83833 102738: close(3) =3D 0 (0x0) > 83833 102738: unlink("./.data.json.SYR1bCaL") =3D 0 (0x0) > 83833 102738: dup2(10,2) =3D 2 (0x2) > 83833 102738: close(10) =3D 0 (0x0) > 83833 102738: exit(0x0) =20 > 83833 102738: process exit, rval =3D 0 > 77872 100638: wait4(-1,{ EXITED,val=3D0 },0x0,0x0) =3D 83833 (0x14779) > 77872 100638: fcntl(0,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) > 77872 100638: = openat(AT_FDCWD,"/var/run/poudriere/lock-poudriere-shared-json_top.pid",O_= RDONLY,00) =3D 3 (0x3) > 77872 100638: dup2(3,0) =3D 0 (0x0) > 77872 100638: close(3) =3D 0 (0x0) > 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 11 (0xb) > 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) > 77872 100638: dup2(3,2) =3D 2 (0x2) > 77872 100638: close(3) =3D 0 (0x0) > 77872 100638: lseek(0,0x0,SEEK_CUR) =3D 0 (0x0) > 77872 100638: read(0,"77563",1024) =3D 5 (0x5) > 77872 100638: read(0,0xffffffffb9e8,1024) =3D 0 (0x0) > 77872 100638: dup2(10,0) =3D 0 (0x0) > 77872 100638: close(10) =3D 0 (0x0) > 77872 100638: dup2(11,2) =3D 2 (0x2) > 77872 100638: close(11) =3D 0 (0x0) > 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) > 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) > 77872 100638: dup2(3,2) =3D 2 (0x2) > 77872 100638: close(3) =3D 0 (0x0) > 77872 100638: = rmdir("/var/run/poudriere/lock-poudriere-shared-json_top") =3D 0 (0x0) > 77872 100638: dup2(10,2) =3D 2 (0x2) > 77872 100638: close(10) =3D 0 (0x0) > 77872 100638: sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 (0x0) > 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) > 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) > 77872 100638: dup2(3,2) =3D 2 (0x2) > 77872 100638: close(3) =3D 0 (0x0) > 77872 100638: sigaction(SIGINFO,{ 0x239c30 SA_RESTART ss_t },{ SIG_DFL = 0x0 ss_t }) =3D 0 (0x0) > 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) > -- UNKNOWN FreeBSD32 SYSCALL 1 -- > 83731 100161: #1(0x0) =20 > 83731 100161: process exit, rval =3D 0 > 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0 = status=3D0 > 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' > 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 > 83630 100199: process killed, signal =3D 11 (core dumped) > 83316 100123: #7(0xffffffff,0xffffca58,0x0,0x0) =3D 83630 (0x146ae) > -- UNKNOWN FreeBSD32 SYSCALL 477 -- > 83316 100123: = #477(0x0,0x7000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077833728 (0x403e7000) > -- UNKNOWN FreeBSD32 SYSCALL 552 -- > 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' > -- UNKNOWN FreeBSD32 SYSCALL 552 -- > 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' > -- UNKNOWN FreeBSD32 SYSCALL 552 -- > 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' > -- UNKNOWN FreeBSD32 SYSCALL 552 -- > 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' > -- UNKNOWN FreeBSD32 SYSCALL 477 -- > 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077862400 (0x403ee000) > -- UNKNOWN FreeBSD32 SYSCALL 4 -- > 83316 100123: #4(0x2,0x403ee000,0x21) =3D 33 (0x21) > -- UNKNOWN FreeBSD32 SYSCALL 477 -- > 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077866496 (0x403ef000) > -- UNKNOWN FreeBSD32 SYSCALL 477 -- > 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077870592 (0x403f0000) > -- UNKNOWN FreeBSD32 SYSCALL 477 -- > 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077874688 (0x403f1000) > -- UNKNOWN FreeBSD32 SYSCALL 4 -- > 83316 100123: #4(0x1,0x403ef000,0x2e) =3D 46 (0x2e) > -- UNKNOWN FreeBSD32 SYSCALL 542 -- > 83316 100123: #542(0xffffcd54,0x0) =3D 0 (0x0) > -- UNKNOWN FreeBSD32 SYSCALL 2 -- > 83842 100199: > 83316 100123: #2() =3D 83842 (0x14782) > -- UNKNOWN FreeBSD32 SYSCALL 6 -- > -- UNKNOWN FreeBSD32 SYSCALL 6 -- > 83316 100123: #6(0x7) =3D 0 (0x0) > 83842 100199: #6(0x5) =3D 0 (0x0) > . . . Turns out that the failure happens on the processors with out-of-order execution and the like but works on the strictly in-order cortex-a53. (For as much testing as I've done.) So it looks like some form of synchronization is missing that in-order-only does not need. (This would be the 2nd time I've run into such for FreeBSD aarch64 if it holds true. The prior example was fixed a fair time ago.) The testing status . . . Problem replicated using the following contexts to attempt the textproc/itstool build, targeting armv7 (cortex-a7): cortex-a72 aarch64 MACHHIATObin Double Shot cortex-a57 aarch64 OverDrive 1000 (No successful builds for the above 2, all stopping in configure the same way.) No problem using the following to build textproc/itstool, targeting armv7: cortex-a53 aarch64 Rock64 (armv7 on aarch64 case) cortext-a7 armv7 OrangePi+ 2ed (native armv7 case) It will take a long time to run a full poudriere bulk that will build about 200 ports, targeting the cortex-a7 on the slower cortex-a53: days. So further evidence that the cortex-a53 does not get the problem will take a while. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 06:00:17 2021 Return-Path: Delivered-To: freebsd-current@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 CF0C057E458 for ; Wed, 10 Mar 2021 06:00:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.148]) (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 4DwLym6Zpcz4Yvl for ; Wed, 10 Mar 2021 06:00:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615356015; bh=ZZrUBs3zRbN0QxEymX+Av1ZuYY/oPGvWJKZwT6RVrcT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OP6wB2lbOn618Nnu8W+ULkbx2hiIEgGR5QKso+/uZKQgb7gYFY1jF0a3MnZBWlcUSSRikuSABzePGdYdUsJjfUBwj9BSbDS5m6LPPD2BNH+5P6cjF/rfpsmlxUV6Z4g0FMLLEdf6wHR/b4yZP9VhRAdt+V2OACN3BUtleV3Z1hrVq8kDPh3nJWCF1957WOSRL+cbifR0/o/btV2dlyh2Bl6hSVkQd2D57zMjhCrk5hZzVTWoON9p3ZoyKLhdAGKMD3O0PHMC78tX8eXifczTutBnjbtYrfXv60UmxgFabLWB/4+rr0fiAABZiBBbN2S+8VK8Pq4HNstanOfNDx4C5A== X-YMail-OSG: _kcXBMoVM1n8xVMGWTiydHaKYoAxWNRJYyDVJp8IYoFsWgRf_VK2HhEJOZM4SaL 2q4Imc1NkWJ5y2030AX797yR0rYlq44kf0p.bB_DMHvs1bJ.qgG_llSsrBnNdxqWd.72UW18IJ7y .e5G3i1CfD1Qiyc8uW7dgnHsRICq7VQsB22_6LWDIfnCXj_T5b4lhxnVMuq6ULbCsti6kJFwAbE. Q6PyNpINC.kQP_ZCY.nymKp2EUtUVs4IyWh9zEKZfu1tOKBohtOjVjs.8DtiKpkAgthpQBlw.yoK bjAaWLB4WGIRPWOSIZuNVXKf_wJMFHUF2XH1gRW.4QIsYlSMUDB7NYPc6Ko0jp0IAtBn4bI9L0i5 U7_ELrO1pw4LxvR_4KTRqh.ScfMirAokHLDWLofFNuM0ACfT.Ob86lQnGUEox_T_GWVednDrc8Zq NGnZ__ZasMxZ6h6_g8XeUBIHvmpZ7TZXgO.R_46ffbty8k0MeuFR7anHqqsRBb1zEEIUktx_fSjK NQRRp1OGS2muG13zIU7rq81Y96MCeGBdgixH1Fm6IPcFXZLxEsdStu_BmFERr0cYGq1Vvg_cXyLY VQJnmx46.O1kukTADa9SrpJE4gG7rVrifjA4gEg2N2PDtVpTB5MyAqeMDIaxu38CfcqWxJ1o.TFP BOoI9HZZj1gWoAc0HyovGqLafYDwCRmuhbYtfXTu6zeLc70EeBMMWcxf27jg2Od57qkWNQlas5o0 a8CP9pFln3xsWHyWlIjSQcEddPzDf.Ay9NdScRtDuMrFGct1H0hrSJceYB4LfQdlIoIZpsxv2Yyd NWzcRiifsIEQEwjkxVeTaEKMMXpzYVVhCLxzRoVYZy9cgFpvId8vnYmztoN1rRAheDtcNKw80uiY X3Ais03tt5a5nUhnArlDjy.NOjJ2gIbt_05aKlsEEuVzlbjHhCdj00w1Nyv0Rtlv_xmgMoBn.fnh rGkBpnOayKMVO4m.NwFDT_xcQ1_bnX3Wis2KCHW.GIEjkqq2IDSg.zsnPGgbr6.wIOIAoVRc4RZP gLzua2_qMZ.beNS0LsjL9O7YnsOnTOs2N7brsQPGjCrDGPO4vrcvvZ3jVMIvmdkWTYhDVEhgyLNx 1EFd0zkAnCJijJa3iBE_ozhhV72KeJvmgrn7Kx1a7Mrl7tsIvv_JY6YopALisQL9USDC0f2b.dwh jLtQv7.4_ks5.mFGh0ZZR8M_FDJnPKsq5WUDNoHmPdWKEhwKnBXUo5U_upzgiAuyn3D0vRpLbM81 oAV6xUs_tonGekCTA_8mL_JPT9XstkM7e4rOO9uMcKeFXrrus1oJAbkY7gvn7yWm.yPjmgOcr2ly Sf3oxk.Vt_0UgCavFMmEzTvB2dDtTaPc2vxY22096fjYdC7v0MRFCYSKkt7RCHJGeuDCouMhTOaT Agc6ZF5Cg1FkK5J_a9zTyUc08vplDw5FQVaxfURtmjAOWuj9E8.cFGuwrneIeVxNcvoXQ.8QdeKw MOYLBcJgbyVbdBVCcb7gBvAmnGlkrEO5JcKbT45FDeZKdDjKLPFSByAHo1jI5I2J6gL.IU9Ars9P tOo_IR069CQkH_e_DbVdIxSfO72AQFYfkapKB4A9Mw2hcpu7cdKyXA73VYngRL2McEi9xHk8.rQY TDVvROVLU0.GrR5XLu7Ke33LxIhI8bmnZn6IiSnNt5wKCcv2nFLN_U7KtVYDDn14s8pGta5SWVkR 06J6eV4lLusYpoYFgWnsU5yJWlOCr2j7gv8_N4hmqNIOxfSq2xvD8koB075C7aCNaObnN_i20UMl .gzLjgG6ZCU0L5ipmrDQHHc8ZWFieLd6jkYLvRwEJr.SXy7aoBr6IvE5XXRNy1wmSJE1vcHkRMv2 tm_9ljtSX_l_tx3HkOrAWb10yzBDwK7dfEQSj.SlLkiugpJrZMnr2zwN_ShnCYJfbTX3tuBuEIWw Cn6ZOr._BdyZVX3KrRejCZlltxnRWOWPC6xHAonC.5KJiIUslxqiqzNEhcSRRWgX6SmBKACwzjYW RuvkrnToI_1NvQGGZIZGrX9G17l3e.HTFS5daZjasdWIWEyI08FScQYyknFF4TF22ZtMkNXTk.o. Tfom_pAgb_5rimHWiUO4ifGr21Qz6OGkvyPLPTZTnerjcNBWePrBvQHtzEfjtz.B9LBnWY8fjXH3 IZUKQnTEEPmdJljjKetUqJ8t1mjRYOOQmG1b8gx1yilY3vhdMkUsr341j1nuX4nctp3j.aSX2.Bz l0H7qixCwrZw5KcnqEt1KiyS.hMTv8mwTfoC3bbbvuwElDucBexvtyGLDKxbJ_ClKA1FwNs6f7hF R.4qE5rKPypiO8100Bdplamrwm5epaCEHJeFmd6EiVDYjcV_hVMkxV3DNcvARx_Uii5fJtcuQnpP t0aG9dX63nAeS59u.0Qqh8h.6J.5OyEi8wI8C8fIALYleyYwAau3RDP88RUCZJLmsKSqfJ4YklVX jDx6eYukx5fbqYReNBP6N_.9BxM4XrynjGcvnvcoi_Vk6z9851LY6Ker3JQ_LZULzoo5X7XNtFUH FKd_ksBOftWsekkZCxbpcWdtjgQmDJjuhF08_VqmeycHb9tFQF5l.LaEoAHjM7zHC4Vka4W43qjk HsERBI1TLaqR19pJwP6kWNzseIRUJWGCo4EgJWIoftpoKeXK5.CUi3ikb7BGXirdvAg.K7lTOW2D xsp.4yELoWDqWWK5vnq_jTck88j.HHH5yAV5O1d3FLKAWXU3OqhY5 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 06:00:15 +0000 Received: by kubenode572.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8f91ed7f4fb802b489deff373b9bf435; Wed, 10 Mar 2021 06:00:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls (cortex-a57/a72 fail, cortex-a53/cortex-a7 work) From: Mark Millard In-Reply-To: Date: Tue, 9 Mar 2021 22:00:07 -0800 Cc: Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <1C468B92-E53F-4CBC-A6C0-05FEB887F45B@yahoo.com> References: To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwLym6Zpcz4Yvl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.190.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.190.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.190.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.190.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 06:00:17 -0000 On 2021-Mar-9, at 21:11, Mark Millard wrote: > On 2021-Mar-9, at 19:17, Mark Millard wrote: >=20 > [My only testing context for this has been main, not 13.0. > But it might be a 13.0 worry.] >=20 >> Using the quickest to so-far-reliably-fail type of example from >> another thread I used truss to see what happens, here filtered >> down to two processes that appear to be involved and only >> near the failure. (The overall truss output is huge from the >> prior activity in the poudriere bulk relatated activity). Also, >> this initiated watching from aarch64 but the failing code is >> armv7. >>=20 >> 83630 100199: #340(0x1,0xffffd18c,0xffffd17c) =3D 0 (0x0) >> 83630 100199: #416(0x14,0xffffd1b4,0xffffd19c) =3D 0 (0x0) >> 83630 100199: #7(0xffffffff,0xffffd178,0x1,0x0) =3D 0 (0x0) >> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >> 83731 100161: #1(0x0) =20 >> 83731 100161: process exit, rval =3D 0 >> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0= status=3D0 >> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >> 83630 100199: process killed, signal =3D 11 (core dumped) >>=20 >> As a reminder of the lldb backtrace of the sh.core >> and the like: >>=20 >> (lldb) bt >> * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV >> * frame #0: 0xffffe190 >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 >> frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 >> frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 >> frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 >> frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 >> frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >> (lldb) up >> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >> 605 break; >> 606 } >> 607 } >> -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >> 609 =09 >> 610 sig =3D pendingsig_waitcmd; >> 611 pendingsig_waitcmd =3D 0; >>=20 >> (lldb) disass >> sh`waitcmdloop: >> 0x31a54 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} >> 0x31a58 <+4>: add r11, sp, #28 >> 0x31a5c <+8>: sub sp, sp, #4 >> 0x31a60 <+12>: movw r6, #0x3ea0 >> 0x31a64 <+16>: movw r7, #0x3e9c >> 0x31a68 <+20>: movw r9, #0x4040 >> 0x31a6c <+24>: movw r8, #0x3ea4 >> 0x31a70 <+28>: mov r4, r0 >> 0x31a74 <+32>: movt r6, #0x6 >> 0x31a78 <+36>: movt r7, #0x6 >> 0x31a7c <+40>: movt r9, #0x6 >> 0x31a80 <+44>: mov r10, #0 >> 0x31a84 <+48>: movt r8, #0x6 >> 0x31a88 <+52>: cmp r4, #0 >> 0x31a8c <+56>: beq 0x31ab4 ; <+96> at = jobs.c:590:37 >> 0x31a90 <+60>: ldrb r0, [r4, #0x18] >> 0x31a94 <+64>: cmp r0, #2 >> 0x31a98 <+68>: beq 0x31b84 ; <+304> [inlined] = getjobstatus at jobs.c:575 >> 0x31a9c <+72>: mov r0, #3 >> 0x31aa0 <+76>: mov r1, #0 >> 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 >> -> 0x31aa8 <+84>: cmn r0, #1 >>=20 >>=20 >> For reference a local context around the >> SIGSEGV looks like (all lines in the range >> selected): >>=20 >> . . . >> 83833 102738: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 83833 102738: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 83833 102738: dup2(3,2) =3D 2 (0x2) >> 83833 102738: close(3) =3D 0 (0x0) >> 83833 102738: unlink("./.data.json.SYR1bCaL") =3D 0 (0x0) >> 83833 102738: dup2(10,2) =3D 2 (0x2) >> 83833 102738: close(10) =3D 0 (0x0) >> 83833 102738: exit(0x0) =20 >> 83833 102738: process exit, rval =3D 0 >> 77872 100638: wait4(-1,{ EXITED,val=3D0 },0x0,0x0) =3D 83833 = (0x14779) >> 77872 100638: fcntl(0,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/var/run/poudriere/lock-poudriere-shared-json_top.pid",O_= RDONLY,00) =3D 3 (0x3) >> 77872 100638: dup2(3,0) =3D 0 (0x0) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 11 (0xb) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: lseek(0,0x0,SEEK_CUR) =3D 0 (0x0) >> 77872 100638: read(0,"77563",1024) =3D 5 (0x5) >> 77872 100638: read(0,0xffffffffb9e8,1024) =3D 0 (0x0) >> 77872 100638: dup2(10,0) =3D 0 (0x0) >> 77872 100638: close(10) =3D 0 (0x0) >> 77872 100638: dup2(11,2) =3D 2 (0x2) >> 77872 100638: close(11) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: = rmdir("/var/run/poudriere/lock-poudriere-shared-json_top") =3D 0 (0x0) >> 77872 100638: dup2(10,2) =3D 2 (0x2) >> 77872 100638: close(10) =3D 0 (0x0) >> 77872 100638: sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 (0x0) >> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >> 77872 100638: dup2(3,2) =3D 2 (0x2) >> 77872 100638: close(3) =3D 0 (0x0) >> 77872 100638: sigaction(SIGINFO,{ 0x239c30 SA_RESTART ss_t },{ = SIG_DFL 0x0 ss_t }) =3D 0 (0x0) >> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >> -- UNKNOWN FreeBSD32 SYSCALL 1 -- >> 83731 100161: #1(0x0) =20 >> 83731 100161: process exit, rval =3D 0 >> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 uid=3D0= status=3D0 >> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >> 83630 100199: process killed, signal =3D 11 (core dumped) >> 83316 100123: #7(0xffffffff,0xffffca58,0x0,0x0) =3D 83630 (0x146ae) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x7000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077833728 (0x403e7000) >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077862400 (0x403ee000) >> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >> 83316 100123: #4(0x2,0x403ee000,0x21) =3D 33 (0x21) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077866496 (0x403ef000) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077870592 (0x403f0000) >> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077874688 (0x403f1000) >> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >> 83316 100123: #4(0x1,0x403ef000,0x2e) =3D 46 (0x2e) >> -- UNKNOWN FreeBSD32 SYSCALL 542 -- >> 83316 100123: #542(0xffffcd54,0x0) =3D 0 (0x0) >> -- UNKNOWN FreeBSD32 SYSCALL 2 -- >> 83842 100199: >> 83316 100123: #2() =3D 83842 (0x14782) >> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >> 83316 100123: #6(0x7) =3D 0 (0x0) >> 83842 100199: #6(0x5) =3D 0 (0x0) >> . . . >=20 > Turns out that the failure happens on the > processors with out-of-order execution and > the like but works on the strictly in-order > cortex-a53. (For as much testing as I've > done.) >=20 > So it looks like some form of synchronization > is missing that in-order-only does not need. > (This would be the 2nd time I've run into such > for FreeBSD aarch64 if it holds true. The > prior example was fixed a fair time ago.) >=20 >=20 > The testing status . . . >=20 >=20 > Problem replicated using the following contexts > to attempt the textproc/itstool build, targeting > armv7 (cortex-a7): >=20 > cortex-a72 aarch64 MACHHIATObin Double Shot > cortex-a57 aarch64 OverDrive 1000 >=20 > (No successful builds for the above 2, > all stopping in configure the same way.) >=20 >=20 > No problem using the following to build > textproc/itstool, targeting armv7: >=20 > cortex-a53 aarch64 Rock64 (armv7 on aarch64 case) > cortext-a7 armv7 OrangePi+ 2ed (native armv7 case) >=20 >=20 > It will take a long time to run a full > poudriere bulk that will build about > 200 ports, targeting the cortex-a7 on > the slower cortex-a53: days. So > further evidence that the cortex-a53 > does not get the problem will take a > while. I have confirmed that I still get the problem on the cortex-a72 when I substitute the kernel.txz and kernel-dbg.txz content from: = https://artifact.ci.freebsd.org/snapshot/main/bad9fa56620eb82395c5ab66d300= e91a0222dde2/arm64/aarch64/ and boot with it. ( My non-debug build is also of bad9fa56 .) This avoids worries about my kernel build being involved. The debug kernel did not report anything special while the port was building. Earlier it did report the classic: [00:00:06] Mounting system devices for FBSDFSSDjailArmV7-default lock order reversal: 1st 0xffffa0017b9915b0 ufs (ufs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1071 2nd 0xffffa0017bdb8070 devfs (devfs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1083 lock order devfs -> ufs established at: . . . I have not tried substituting base.txz and base-dbg.txz content. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 06:52:09 2021 Return-Path: Delivered-To: freebsd-current@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 6B62257F7AC for ; Wed, 10 Mar 2021 06:52:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-34.consmr.mail.ne1.yahoo.com (sonic317-34.consmr.mail.ne1.yahoo.com [66.163.184.45]) (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 4DwN6c2yZdz4cPg for ; Wed, 10 Mar 2021 06:52:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615359126; bh=/U+OJEeLcv/s+fkWl6rm37V9a8AD76qxESEqdf59M6e=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Aag6sJN37odm4u/zJQQjreP7hEozI6W64XMqzwEKvFrBEyUodzZDB5HYlJmLEfuBlfpcA0RblpvdXd9FeA7L4YYClbz6QEvlOrA7HYn6A8MvnQhbVq9oEyOnwdTK8PCkyIyoNvBdAQp7AEY6vIrRwYja0A5D6v7WyWtJokgrbpdGW0hyqSpTGfZTuQZ9eOBy8j3mAsTVLBdP8WngHZfUaTOV4YU+IyXPLOOVjTJM2WkgaZb7TMvPEmgP2inea8BD9z1kH/oCAWBzWwr1uWVM20mnFeIhGYt+8TYthJcYoc+PxNxSvg0kd+3ULlJEpVk1iFHSpdmXDAELJhhrT5Bp+w== X-YMail-OSG: VNoIIxoVM1lz0oh4f6PgGZDgYJ__u6F.Xr.kd.ad4kyllmNbiK7jHjQ6yFMxneV 8rSKtuqdFyjvVPeGMmTXwELZ1n3m9ddHUlZqB2aattqcbRxz8ktI8FrI02wFIIeuZXjOj.xDs2aB Zj4AL91g5ZWDP5Mg_dW5TialzBocTEarxz2E715Qm39aj1nFwiblV8le8c4JLoiChiZMovgNOkBG 8hnOX0e_dod6YoGWeefIbnT1JM7AJOvvf6NYQblX69cBjIJB8VoRPnR5ers8CxmXrrdKB4ifP1HB bzu1YY1NT4LEAtrZVm.d7oQ.qvuYTwz3ET4ZHJLqx1YGp5DyaVa074IW0Z6YCgDoEPv2HtEOdRCS lhuVkPN__eqS4RtSy9i7OD9U2WMQJIgICoHPNEzCaXbcrRXatXUJJOQVfpLo7mgbINx35QciooBq .J8Q40fOgvPqSFgMpYno41NmQhsRiAqv4tnoQPzmxzqPwwdz1XvFZkDqwgWex5YSvEj0yzov2tzM owa5jFGObs1..72hro8JJ0GiSV8p9Ub0sxxBQbwMSN5nrj7NZkPSbgZ7aoq7fdlzcuNj9XXavJ2v nWDEt0k1sWnVItJCS4A4xLOnQLma_S1VHqQaRoEDlIqRtDbQIkWmw3hE1Et2eK0jswnwflkYaiUV 8QRmtlWtg4kY3lc3bgW4dmUTt.A6vQPNHRA.aaBfbmb7dtV653wnahodCstl0Bgg90g_0uxzeqS1 NrTRLlK3BtMmACwy1jRY0ZK2Q9hI8H.MZwObjIk8IC5nzLXBCaO2FDaT41IN8mU46KrlOS5mk2og hiX.IaL4QNqG0XrwzhAutsVS30k5tHF4ty61CbSwjzpkgZ6Lri01kT4hHGpMrn2s_eiaPUKMWEhp MTBGK8kzitTakVYlFGOaio1H6C318cztePoXjJOv2jon6sdNh6bIVM9Bwk7etxBNwKJNS6wO6OC. SWBKyGWfe3jW7560BdhyRdT9XPOkyABdtjXESse_019KviLcpt3qnIIf5gZb_RMFTInacy8JfV6H OSu4n2f8kFBH8vmGsw3Mo5AdDm._kkyZOosufvh0RicXwmBzORF4hA0hh_J36ZkM2CAwnjzWti0c raR_CBpaTUtbqEIotOdj53lo9_AuHhfv4p.tw2Qo12o0VhcGEVBW7odn4SqVbGIJUZz4M.l9wcEt sjmQdY.yWDIctcylZgFZif1aA.x7oOoG1z2Uufd08x2v7C_RQcRaF3uZQBbFpIWipyc8TVaQCT8G fqZ8HjzQEKO7bf_q0nxlHYbMFRLm2SFdPIsg8c4lpHuhwQ08iuBJIalXzkF3vzATTdsqOrMadAU1 UyhERQVv7GJNvlB5ItY1IdnOkCDIZ3QmKH6gQMF5mW7p5zbT6hdv7BBQqycYkZLjOP2jrMWqAUMh U3F6q_4X_M8sBoZ19Urh1__3Grh66.EDFnGzLZ92jm_vrYE8Eq8srIjEVoDrt2aiILZQ.ixI2mOs 3ZedPhe5GW3N52sgmvmb9dvL2s6E0R.2WnXRL2c6AivooYq2BXgo7sWNhnQCndbXqElmFOmyQvnF f9mC6zrBvQgBASokFpbhUy1J4bx9aOmXLZoB5Ikw12TzfNDkg7v2uHnnm1GMs8HjBcSxikYtcwVa 4xZ7NFxTyHAf38SnRlYH2LGO0uLOScZi6.hVDhyngmC29TqmqAvTFE0Pgp6WUC_ozd5U4d33KvVc dhXwo6Aqu48r.MFs3N0bgZ7EIOMWMNvjMxEjozwDJTQbwZZ2KkVI13xNVKBzimTalbdDQ3PWTUAw fX8iobrSf0Vq25YszpG6HGFyNKcDzRd8EgbAksEGyNgHGir.ldFEQTUvgJpTbEDyPF476W7Huno_ .4NkPmFFtqRHCZF6X5QZWqXxysT_zaVekJsb37l13H7p0K6WZns97WbR2nkpdw5.YO.vgq_s_DD2 3ADQOJoMYdCI.ikQkzbKKE02PKYUWy0D_.pKSmDjur61xLy7st2nmcR0UkIVFhkub27DOz3nu.WW kR9DeVaLTR6LzM3hktQ4PpFlzJqlRGdwM05N49jmivjXD9HZMUFLxWaUNIRcUZm2PgcFLTg01pBc xgoyBYOt7yryg5LRHnzfTFlL1Ge__wjKmeUe5lFBEyoPbtCgIIvvr4CQj2w5pIFlufH5ch3fYKsB JRctHuGb0Ig7IMnxb04jZuQ12eYjH7qQeDs3v.RRVqn9bX2ueWA.UXZ_zqHSfBbMfH_a6GS2AnQ1 Bb2S_jPMFGZkSBQH6oAiKXYd1kQ1r.tRhxocaqOJEOOZYmVLELz.zWLfuDYOsZYWbiHZYzOoVoqL j4HSVFdRTiyQb2GepBdSI6usDHR0cBQ_ijAPxyTj5sO3RabjpXYWD9HWnMWP_ySg_1NKN_Dc7ZYH w6zjUl.1A.soDBPw8YjmH5PEmoIVSbGEMuk8iQ8r1D2rpzQ2qfoUZjec6PMVJGC3wzqoG5BNXQaX 4rK79kBRp1KZJHJ7.r7UwwxQwdY8t5jA0ctcfRp0uHtR8PWDP1wz4dL5g4QDxAlJXSbtRedDGWPz GVE0CzeCkxO6qArV3eGYoApQXEm1btIKJhaGM9myReI6fT3nG0b3OU9hX0qdXt11Y6m7q35fuYP0 d_nF2PsTrUI1LPro.F0ik5OUOQBujZccrGqQFQLLafQSzwCyl6.0e5NEr_NsiRx_nZMOWZ0eetYM U4KnIn6goA8WZtd3z_n6Bv_07MMUx0cu2nydny.brK1zFQPgJ6nJ0WBiUisf_oMDc X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 10 Mar 2021 06:52:06 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ca908e9dbb425236c156324e8d1e45b3; Wed, 10 Mar 2021 06:52:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's are tied to interrupted system calls for armv7 poudriere target (cortex-a53/a57/a72 fail, cortex-a7 works(?)) From: Mark Millard In-Reply-To: <1C468B92-E53F-4CBC-A6C0-05FEB887F45B@yahoo.com> Date: Tue, 9 Mar 2021 22:51:59 -0800 Cc: Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <8C348A15-D967-46C1-8BEB-1E41A7490E11@yahoo.com> References: <1C468B92-E53F-4CBC-A6C0-05FEB887F45B@yahoo.com> To: freebsd-arm , freebsd-current X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DwN6c2yZdz4cPg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.184.45:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.184.45:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.184.45:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.184.45:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 06:52:09 -0000 On 2021-Mar-9, at 22:00, Mark Millard wrote: [Trying to be timely about reporting new information because of 13.0 not having much time left.] > On 2021-Mar-9, at 21:11, Mark Millard wrote: >=20 >> On 2021-Mar-9, at 19:17, Mark Millard wrote: >>=20 >> [My only testing context for this has been main, not 13.0. >> But it might be a 13.0 worry.] >>=20 >>> Using the quickest to so-far-reliably-fail type of example from >>> another thread I used truss to see what happens, here filtered >>> down to two processes that appear to be involved and only >>> near the failure. (The overall truss output is huge from the >>> prior activity in the poudriere bulk relatated activity). Also, >>> this initiated watching from aarch64 but the failing code is >>> armv7. >>>=20 >>> 83630 100199: #340(0x1,0xffffd18c,0xffffd17c) =3D 0 (0x0) >>> 83630 100199: #416(0x14,0xffffd1b4,0xffffd19c) =3D 0 (0x0) >>> 83630 100199: #7(0xffffffff,0xffffd178,0x1,0x0) =3D 0 (0x0) >>> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >>> 83731 100161: #1(0x0) =20 >>> 83731 100161: process exit, rval =3D 0 >>> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 = uid=3D0 status=3D0 >>> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >>> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >>> 83630 100199: process killed, signal =3D 11 (core dumped) >>>=20 >>> As a reminder of the lldb backtrace of the sh.core >>> and the like: >>>=20 >>> (lldb) bt >>> * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV >>> * frame #0: 0xffffe190 >>> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >>> frame #2: 0x00031a24 sh`waitcmd(argc=3D, = argv=3D) at jobs.c:554:13 >>> frame #3: 0x00028f54 sh`evalcommand(cmd=3D0x400ad0e4, = flags=3D, backcmd=3D0x00000000) at eval.c:1107:16 >>> frame #4: 0x00027800 sh`evaltree(n=3D0x400ad0e4, = flags=3D) at eval.c:289:4 >>> frame #5: 0x000344d0 sh`cmdloop(top=3D1) at main.c:221:4 >>> frame #6: 0x000342f4 sh`main(argc=3D, = argv=3D) at main.c:168:3 >>> frame #7: 0x0002480c sh`__start(argc=3D8, argv=3D, = env=3D, ps_strings=3D, obj=3D0x400b4004, = cleanup=3D0x40081aa0) at crt1_c.c:92:7 >>> (lldb) up >>> frame #1: 0x00031aa8 sh`waitcmdloop(job=3D0x00064230) at = jobs.c:608:11 >>> 605 break; >>> 606 } >>> 607 } >>> -> 608 } while (dowait(DOWAIT_BLOCK | DOWAIT_SIG, = (struct job *)NULL) !=3D -1); >>> 609 =09 >>> 610 sig =3D pendingsig_waitcmd; >>> 611 pendingsig_waitcmd =3D 0; >>>=20 >>> (lldb) disass >>> sh`waitcmdloop: >>> 0x31a54 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr} >>> 0x31a58 <+4>: add r11, sp, #28 >>> 0x31a5c <+8>: sub sp, sp, #4 >>> 0x31a60 <+12>: movw r6, #0x3ea0 >>> 0x31a64 <+16>: movw r7, #0x3e9c >>> 0x31a68 <+20>: movw r9, #0x4040 >>> 0x31a6c <+24>: movw r8, #0x3ea4 >>> 0x31a70 <+28>: mov r4, r0 >>> 0x31a74 <+32>: movt r6, #0x6 >>> 0x31a78 <+36>: movt r7, #0x6 >>> 0x31a7c <+40>: movt r9, #0x6 >>> 0x31a80 <+44>: mov r10, #0 >>> 0x31a84 <+48>: movt r8, #0x6 >>> 0x31a88 <+52>: cmp r4, #0 >>> 0x31a8c <+56>: beq 0x31ab4 ; <+96> at = jobs.c:590:37 >>> 0x31a90 <+60>: ldrb r0, [r4, #0x18] >>> 0x31a94 <+64>: cmp r0, #2 >>> 0x31a98 <+68>: beq 0x31b84 ; <+304> [inlined] = getjobstatus at jobs.c:575 >>> 0x31a9c <+72>: mov r0, #3 >>> 0x31aa0 <+76>: mov r1, #0 >>> 0x31aa4 <+80>: bl 0x32bcc ; dowait at = jobs.c:1142 >>> -> 0x31aa8 <+84>: cmn r0, #1 >>>=20 >>>=20 >>> For reference a local context around the >>> SIGSEGV looks like (all lines in the range >>> selected): >>>=20 >>> . . . >>> 83833 102738: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >>> 83833 102738: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >>> 83833 102738: dup2(3,2) =3D 2 (0x2) >>> 83833 102738: close(3) =3D 0 (0x0) >>> 83833 102738: unlink("./.data.json.SYR1bCaL") =3D 0 (0x0) >>> 83833 102738: dup2(10,2) =3D 2 (0x2) >>> 83833 102738: close(10) =3D 0 (0x0) >>> 83833 102738: exit(0x0) =20 >>> 83833 102738: process exit, rval =3D 0 >>> 77872 100638: wait4(-1,{ EXITED,val=3D0 },0x0,0x0) =3D 83833 = (0x14779) >>> 77872 100638: fcntl(0,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >>> 77872 100638: = openat(AT_FDCWD,"/var/run/poudriere/lock-poudriere-shared-json_top.pid",O_= RDONLY,00) =3D 3 (0x3) >>> 77872 100638: dup2(3,0) =3D 0 (0x0) >>> 77872 100638: close(3) =3D 0 (0x0) >>> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 11 (0xb) >>> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >>> 77872 100638: dup2(3,2) =3D 2 (0x2) >>> 77872 100638: close(3) =3D 0 (0x0) >>> 77872 100638: lseek(0,0x0,SEEK_CUR) =3D 0 (0x0) >>> 77872 100638: read(0,"77563",1024) =3D 5 (0x5) >>> 77872 100638: read(0,0xffffffffb9e8,1024) =3D 0 (0x0) >>> 77872 100638: dup2(10,0) =3D 0 (0x0) >>> 77872 100638: close(10) =3D 0 (0x0) >>> 77872 100638: dup2(11,2) =3D 2 (0x2) >>> 77872 100638: close(11) =3D 0 (0x0) >>> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >>> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >>> 77872 100638: dup2(3,2) =3D 2 (0x2) >>> 77872 100638: close(3) =3D 0 (0x0) >>> 77872 100638: = rmdir("/var/run/poudriere/lock-poudriere-shared-json_top") =3D 0 (0x0) >>> 77872 100638: dup2(10,2) =3D 2 (0x2) >>> 77872 100638: close(10) =3D 0 (0x0) >>> 77872 100638: sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 (0x0) >>> 77872 100638: fcntl(2,F_DUPFD_CLOEXEC,0xa) =3D 10 (0xa) >>> 77872 100638: = openat(AT_FDCWD,"/dev/null",O_WRONLY|O_CREAT|O_TRUNC,0666) =3D 3 (0x3) >>> 77872 100638: dup2(3,2) =3D 2 (0x2) >>> 77872 100638: close(3) =3D 0 (0x0) >>> 77872 100638: sigaction(SIGINFO,{ 0x239c30 SA_RESTART ss_t },{ = SIG_DFL 0x0 ss_t }) =3D 0 (0x0) >>> 83731 100161: #240(0xffffd5f0,0xffffd5f0) =3D 0 (0x0) >>> -- UNKNOWN FreeBSD32 SYSCALL 1 -- >>> 83731 100161: #1(0x0) =20 >>> 83731 100161: process exit, rval =3D 0 >>> 83630 100199: SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED pid=3D83731 = uid=3D0 status=3D0 >>> 83630 100199: #341(0xffffd17c) ERR#4 'Interrupted = system call' >>> 83630 100199: SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 = addr=3D0xffffffe1 >>> 83630 100199: process killed, signal =3D 11 (core dumped) >>> 83316 100123: #7(0xffffffff,0xffffca58,0x0,0x0) =3D 83630 (0x146ae) >>> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >>> 83316 100123: = #477(0x0,0x7000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077833728 (0x403e7000) >>> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >>> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >>> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >>> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >>> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >>> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >>> -- UNKNOWN FreeBSD32 SYSCALL 552 -- >>> 83316 100123: #552(0xffffff9c,0xffffc504,0xffffc908,0x0) ERR#2 'No = such file or directory' >>> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >>> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077862400 (0x403ee000) >>> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >>> 83316 100123: #4(0x2,0x403ee000,0x21) =3D 33 (0x21) >>> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >>> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077866496 (0x403ef000) >>> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >>> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077870592 (0x403f0000) >>> -- UNKNOWN FreeBSD32 SYSCALL 477 -- >>> 83316 100123: = #477(0x0,0x1000,0x3,0xc001002,0xffffffff,0x40401428,0x0,0x0) =3D = 1077874688 (0x403f1000) >>> -- UNKNOWN FreeBSD32 SYSCALL 4 -- >>> 83316 100123: #4(0x1,0x403ef000,0x2e) =3D 46 (0x2e) >>> -- UNKNOWN FreeBSD32 SYSCALL 542 -- >>> 83316 100123: #542(0xffffcd54,0x0) =3D 0 (0x0) >>> -- UNKNOWN FreeBSD32 SYSCALL 2 -- >>> 83842 100199: >>> 83316 100123: #2() =3D 83842 (0x14782) >>> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >>> -- UNKNOWN FreeBSD32 SYSCALL 6 -- >>> 83316 100123: #6(0x7) =3D 0 (0x0) >>> 83842 100199: #6(0x5) =3D 0 (0x0) >>> . . . >>=20 >> Turns out that the failure happens on the >> processors with out-of-order execution and >> the like but works on the strictly in-order >> cortex-a53. (For as much testing as I've >> done.) Further testing has shown the problem on the cortex-a53 as well, at least when all 5 ports known to hit the problem(s) are considered. Out of order execution or the like is not required; processors with in order execution can get the problem. >> So it looks like some form of synchronization >> is missing that in-order-only does not need. >> (This would be the 2nd time I've run into such >> for FreeBSD aarch64 if it holds true. The >> prior example was fixed a fair time ago.) Since further testing has shown the problem on the cortex-a53, the above does not apply. >> The testing status . . . >>=20 >>=20 >> Problem replicated using the following contexts >> to attempt the textproc/itstool build, targeting >> armv7 (cortex-a7): >>=20 >> cortex-a72 aarch64 MACHHIATObin Double Shot >> cortex-a57 aarch64 OverDrive 1000 >>=20 >> (No successful builds for the above 2, >> all stopping in configure the same way.) cortex-a53 aarch64 Rock64 (armv7 on aarch64 case) (also fails, at least sometimes) (again seems racy) >> No problem using the following to build >> textproc/itstool, targeting armv7: >>=20 >> cortex-a53 aarch64 Rock64 (armv7 on aarch64 case) Wrong above: cortex-a53 does (sometimes) get the problem(s), at least when all 5 examples of failing ports are considered. >> cortext-a7 armv7 OrangePi+ 2ed (native armv7 case) It likely will be some time before I'll have significantly more evidence for cortex-a7 native builds: slower builds. >> It will take a long time to run a full >> poudriere bulk that will build about >> 200 ports, targeting the cortex-a7 on >> the slower cortex-a53: days. So >> further evidence that the cortex-a53 >> does not get the problem will take a >> while. I lucked out on the order of port builds and getting early failures on further cortex-a53 testing. So reporting that failures happen did not take all that long. cortex-a7 native-testing takes much more time to build things. If no port builds fail, the around 200 ports might take a week or more to build. > I have confirmed that I still get the problem on > the cortex-a72 when I substitute the kernel.txz > and kernel-dbg.txz content from: >=20 > = https://artifact.ci.freebsd.org/snapshot/main/bad9fa56620eb82395c5ab66d300= e91a0222dde2/arm64/aarch64/ >=20 > and boot with it. ( My non-debug build is also of > bad9fa56 .) This avoids worries about my kernel > build being involved. >=20 > The debug kernel did not report anything special > while the port was building. Earlier it did report > the classic: >=20 > [00:00:06] Mounting system devices for FBSDFSSDjailArmV7-default > lock order reversal: > 1st 0xffffa0017b9915b0 ufs (ufs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1071 > 2nd 0xffffa0017bdb8070 devfs (devfs, lockmgr) @ = /usr/src/sys/kern/vfs_mount.c:1083 > lock order devfs -> ufs established at: > . . . >=20 > I have not tried substituting base.txz and > base-dbg.txz content. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Mar 10 09:15:50 2021 Return-Path: Delivered-To: freebsd-current@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 88E3E5A9EA6 for ; Wed, 10 Mar 2021 09:15:50 +0000 (UTC) (envelope-from pho@holm.cc) 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 4DwRJQ2gDwz4jqg for ; Wed, 10 Mar 2021 09:15:50 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.nyi.freebsd.org (Postfix) id 59CD35AA13A; Wed, 10 Mar 2021 09:15:50 +0000 (UTC) Delivered-To: current@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 5993F5AA139 for ; Wed, 10 Mar 2021 09:15:50 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwRJP4pv5z4jws for ; Wed, 10 Mar 2021 09:15:49 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (unknown [80.208.71.94]) by relay05.pair.com (Postfix) with ESMTP id 5B7A21A28DC for ; Wed, 10 Mar 2021 04:15:48 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 12A9FmbY076217 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 10 Mar 2021 10:15:48 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 12A9Fmbw076216 for current@freebsd.org; Wed, 10 Mar 2021 10:15:48 +0100 (CET) (envelope-from pho) Date: Wed, 10 Mar 2021 10:15:48 +0100 From: Peter Holm To: current@freebsd.org Subject: panic: malloc(M_WAITOK) with sleeping prohibited Message-ID: <20210310091548.GA76176@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4DwRJP4pv5z4jws X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pho@holm.cc has no SPF policy when checking 216.92.24.67) smtp.mailfrom=pho@holm.cc X-Spamd-Result: default: False [-1.90 / 15.00]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[pho@freebsd.org,pho@holm.cc]; RCVD_IN_DNSWL_LOW(-0.10)[216.92.24.67:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[216.92.24.67:from]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[pho@freebsd.org,pho@holm.cc]; ASN(0.00)[asn:7859, ipnet:216.92.0.0/16, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[pho]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[216.92.24.67:from:127.0.2.255]; DMARC_NA(0.00)[freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 09:15:50 -0000 I just got this panic: igb0: port 0xd020-0xd03f mem 0xfb320000-0xfb33ffff,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6 igb0: Using 6 RX queues 6 TX queues igb0: Using MSI-X interrupts with 7 vectors igb0: db> db> show panic panic: malloc(M_WAITOK) with sleeping prohibited db> bt Tracing pid 12 tid 100172 td 0xfffffe010dce2100 kdb_enter() at kdb_enter+0x37/frame 0xfffffe00e4f72980 vpanic() at vpanic+0x1b2/frame 0xfffffe00e4f729d0 panic() at panic+0x43/frame 0xfffffe00e4f72a30 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4f72a50 malloc() at malloc+0x34/frame 0xfffffe00e4f72ab0 linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4f72b00 linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfffffe00e4f72b20 ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4f72bb0 fork_exit() at fork_exit+0x80/frame 0xfffffe00e4f72bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4f72bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db> x/s version version: FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 10:00:29 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 db> - Peter From owner-freebsd-current@freebsd.org Wed Mar 10 09:53:13 2021 Return-Path: Delivered-To: freebsd-current@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 B12535AB2D5 for ; Wed, 10 Mar 2021 09:53:13 +0000 (UTC) (envelope-from hps@selasky.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 4DwS7Y3wXGz4nFZ for ; Wed, 10 Mar 2021 09:53:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.nyi.freebsd.org (Postfix) id 84BF15AB2D4; Wed, 10 Mar 2021 09:53:13 +0000 (UTC) Delivered-To: current@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 847EA5AB3F5 for ; Wed, 10 Mar 2021 09:53:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwS7Y2sMBz4nYZ; Wed, 10 Mar 2021 09:53:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D9714260185; Wed, 10 Mar 2021 10:53:09 +0100 (CET) Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited To: Peter Holm , current@freebsd.org References: <20210310091548.GA76176@x8.osted.lan> From: Hans Petter Selasky Message-ID: Date: Wed, 10 Mar 2021 10:52:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210310091548.GA76176@x8.osted.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DwS7Y2sMBz4nYZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 09:53:13 -0000 On 3/10/21 10:15 AM, Peter Holm wrote: > I just got this panic: > > igb0: port 0xd020-0xd03f mem 0xfb320000-0xfb33ffff,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 > igb0: Using 1024 TX descriptors and 1024 RX descriptors > igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6 > igb0: Using 6 RX queues 6 TX queues > igb0: Using MSI-X interrupts with 7 vectors > igb0: > db> > db> show panic > panic: malloc(M_WAITOK) with sleeping prohibited > db> bt > Tracing pid 12 tid 100172 td 0xfffffe010dce2100 > kdb_enter() at kdb_enter+0x37/frame 0xfffffe00e4f72980 > vpanic() at vpanic+0x1b2/frame 0xfffffe00e4f729d0 > panic() at panic+0x43/frame 0xfffffe00e4f72a30 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4f72a50 > malloc() at malloc+0x34/frame 0xfffffe00e4f72ab0 > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4f72b00 > linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfffffe00e4f72b20 > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4f72bb0 > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4f72bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4f72bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > db> x/s version > version: FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 10:00:29 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 > db> This should fix it: https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427 --HPS From owner-freebsd-current@freebsd.org Wed Mar 10 11:41:52 2021 Return-Path: Delivered-To: freebsd-current@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 60F085ADD03 for ; Wed, 10 Mar 2021 11:41:52 +0000 (UTC) (envelope-from pho@holm.cc) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DwVXw0z7sz4vLb for ; Wed, 10 Mar 2021 11:41:52 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.nyi.freebsd.org (Postfix) id 1F4175ADC23; Wed, 10 Mar 2021 11:41:52 +0000 (UTC) Delivered-To: current@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 1DEFA5ADB3C for ; Wed, 10 Mar 2021 11:41:52 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwVXw08Xzz4vJV for ; Wed, 10 Mar 2021 11:41:51 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (unknown [80.208.71.94]) by relay05.pair.com (Postfix) with ESMTP id DADDF1A27FE; Wed, 10 Mar 2021 06:41:50 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 12ABfotj077879 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 12:41:50 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 12ABfoe3077878; Wed, 10 Mar 2021 12:41:50 +0100 (CET) (envelope-from pho) Date: Wed, 10 Mar 2021 12:41:50 +0100 From: Peter Holm To: Hans Petter Selasky Cc: current@freebsd.org Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited Message-ID: <20210310114150.GA77805@x8.osted.lan> References: <20210310091548.GA76176@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DwVXw08Xzz4vJV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 11:41:52 -0000 On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote: > On 3/10/21 10:15 AM, Peter Holm wrote: > > I just got this panic: > > > > igb0: port 0xd020-0xd03f mem 0xfb320000-0xfb33ffff,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 > > igb0: Using 1024 TX descriptors and 1024 RX descriptors > > igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6 > > igb0: Using 6 RX queues 6 TX queues > > igb0: Using MSI-X interrupts with 7 vectors > > igb0: > > db> > > db> show panic > > panic: malloc(M_WAITOK) with sleeping prohibited > > db> bt > > Tracing pid 12 tid 100172 td 0xfffffe010dce2100 > > kdb_enter() at kdb_enter+0x37/frame 0xfffffe00e4f72980 > > vpanic() at vpanic+0x1b2/frame 0xfffffe00e4f729d0 > > panic() at panic+0x43/frame 0xfffffe00e4f72a30 > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4f72a50 > > malloc() at malloc+0x34/frame 0xfffffe00e4f72ab0 > > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4f72b00 > > linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfffffe00e4f72b20 > > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4f72bb0 > > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4f72bf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4f72bf0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > db> x/s version > > version: FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 10:00:29 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 > > db> > > This should fix it: > https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427 > > --HPS Yes, thank you. Now I see this: ugen0.3: at usbus0 ukbd0 on uhub3 ukbd0: on usbus0 kbd2 at ukbd0 panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 0 time = 1615375651 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e4974890 vpanic() at vpanic+0x181/frame 0xfffffe00e49748e0 panic() at panic+0x43/frame 0xfffffe00e4974940 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974960 malloc() at malloc+0x34/frame 0xfffffe00e49749c0 linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4974a10 linux_timer_callback_wrapper() at linux_timer_callback_wrapper+0x37/frame 0xfffffe00e4974a30 softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 softclock() at softclock+0x66/frame 0xfffffe00e4974b20 ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 12 tid 100088 ] Stopped at kdb_enter+0x37: movq $0,0x12891fe(%rip) db> x/s version version: FreeBSD 14.0-CURRENT #0 main-n245372-d1cbe7908986: Wed Mar 10 12:25:03 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 db> - Peter From owner-freebsd-current@freebsd.org Wed Mar 10 12:33:53 2021 Return-Path: Delivered-To: freebsd-current@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 3BD615AF991 for ; Wed, 10 Mar 2021 12:33:53 +0000 (UTC) (envelope-from hps@selasky.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 4DwWhw6mwvz3FXR for ; Wed, 10 Mar 2021 12:33:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.nyi.freebsd.org (Postfix) id E69485AF723; Wed, 10 Mar 2021 12:33:52 +0000 (UTC) Delivered-To: current@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 E65C55AF460 for ; Wed, 10 Mar 2021 12:33:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwWhw5NzZz3FCp; Wed, 10 Mar 2021 12:33:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E1C72260C4C; Wed, 10 Mar 2021 13:33:50 +0100 (CET) Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited To: Peter Holm Cc: current@freebsd.org References: <20210310091548.GA76176@x8.osted.lan> <20210310114150.GA77805@x8.osted.lan> From: Hans Petter Selasky Message-ID: Date: Wed, 10 Mar 2021 13:33:34 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210310114150.GA77805@x8.osted.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DwWhw5NzZz3FCp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 12:33:53 -0000 On 3/10/21 12:41 PM, Peter Holm wrote: > On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote: >> On 3/10/21 10:15 AM, Peter Holm wrote: >>> I just got this panic: >>> >>> igb0: port 0xd020-0xd03f mem 0xfb320000-0xfb33ffff,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 >>> igb0: Using 1024 TX descriptors and 1024 RX descriptors >>> igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6 >>> igb0: Using 6 RX queues 6 TX queues >>> igb0: Using MSI-X interrupts with 7 vectors >>> igb0: >>> db> >>> db> show panic >>> panic: malloc(M_WAITOK) with sleeping prohibited >>> db> bt >>> Tracing pid 12 tid 100172 td 0xfffffe010dce2100 >>> kdb_enter() at kdb_enter+0x37/frame 0xfffffe00e4f72980 >>> vpanic() at vpanic+0x1b2/frame 0xfffffe00e4f729d0 >>> panic() at panic+0x43/frame 0xfffffe00e4f72a30 >>> malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4f72a50 >>> malloc() at malloc+0x34/frame 0xfffffe00e4f72ab0 >>> linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4f72b00 >>> linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfffffe00e4f72b20 >>> ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4f72bb0 >>> fork_exit() at fork_exit+0x80/frame 0xfffffe00e4f72bf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4f72bf0 >>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >>> db> x/s version >>> version: FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 10:00:29 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 >>> db> >> >> This should fix it: >> https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427 >> >> --HPS > > Yes, thank you. Now I see this: > > ugen0.3: at usbus0 > ukbd0 on uhub3 > ukbd0: on usbus0 > kbd2 at ukbd0 > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 0 > time = 1615375651 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e4974890 > vpanic() at vpanic+0x181/frame 0xfffffe00e49748e0 > panic() at panic+0x43/frame 0xfffffe00e4974940 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974960 > malloc() at malloc+0x34/frame 0xfffffe00e49749c0 > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4974a10 > linux_timer_callback_wrapper() at linux_timer_callback_wrapper+0x37/frame 0xfffffe00e4974a30 > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 > softclock() at softclock+0x66/frame 0xfffffe00e4974b20 > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 12 tid 100088 ] Try this: https://cgit.freebsd.org/src/commit/?id=dfb33cb0ef48084da84072244e8ca486dfcf3a96 There will be a more comprehensive fix coming: https://reviews.freebsd.org/D29183 --HPS From owner-freebsd-current@freebsd.org Wed Mar 10 12:37:49 2021 Return-Path: Delivered-To: freebsd-current@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 E9A925AF9DA for ; Wed, 10 Mar 2021 12:37:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DwWnT4sFjz3Frs for ; Wed, 10 Mar 2021 12:37:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id A6BAF5AFA3C; Wed, 10 Mar 2021 12:37:49 +0000 (UTC) Delivered-To: current@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 A68235AF847 for ; Wed, 10 Mar 2021 12:37:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwWnT2dDgz3Ffb for ; Wed, 10 Mar 2021 12:37:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 12ACbesI083611; Wed, 10 Mar 2021 12:37:40 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 12ACbeM1083610; Wed, 10 Mar 2021 04:37:40 -0800 (PST) (envelope-from david) Date: Wed, 10 Mar 2021 04:37:40 -0800 From: David Wolfskill To: Warner Losh Cc: FreeBSD Current Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Mail-Followup-To: David Wolfskill , Warner Losh , FreeBSD Current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lwHcNMrBwCAXLMBZ" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DwWnT2dDgz3Ffb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 12:37:50 -0000 --lwHcNMrBwCAXLMBZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote: > On Tue, Mar 9, 2021 at 2:46 PM David Wolfskill wro= te: > ... > > uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2 > > with the following non-sleepable locks held: > > umass0: on usbus0 > > exclusive sleep mutex CAM device lockumass0: SCSI over Bulk-Only; quir= ks > > =3D 0x4000 > > (CAM device lock) r =3D 0 (0xfffff800122c9cd0) locked @ > > /usr/src/sys/cam/cam_xpt.c:2333 > > umass0:6:0: Attached to scbus6 > > stack backtrace: > > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > > #0 0xffffffff80c7cce1 at witnesuhub3: 6 ports with 6 removable, self > > powered > > s_debugger+0x71 > > pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 > > #1 0xffffffff80pass6: uhub4: 8 ports with 8 removable, self powered > > c7ddfd at witness_warn+0x40d > > #2 Removable Direct Access SCSI device > > 0xffffffff80f42fe6 at uma_zallpass6: Serial Number 20100818841300000 > > oc_arg+0x46 > > #3 0xffffffff80be34pass6: 40.000MB/s transfers > > panic: malloc(M_WAITOK) with sleeping prohibited > > cpuid =3D 1 > > time =3D 22 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe00e157a2d0 > > vpanic() at vpanic+0x181/frame 0xfffffe00e157a320 > > panic() at panic+0x43/frame 0xfffffe00e157a380 > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a3a0 > > malloc() at malloc+0x34/frame 0xfffffe00e157a400 > > g_post_event_x() at g_post_event_x+0x5a/frame 0xfffffe00e157a450 > > g_post_event() at g_post_event+0x48/frame 0xfffffe00e157a4b0 > > disk_create() at disk_create+0x16f/frame 0xfffffe00e157a600 > > daregister() at daregister+0x70a/frame 0xfffffe00e157a880 > > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 > > daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 > > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > > 0xfffffe00e157aa10 > > xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 > > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 > > xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 > > fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 > > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > > KDB: enter: panic > > [ thread pid 17 tid 100095 ] > > Stopped at kdb_enter+0x37: movq $0,0x128b8ce(%rip) > > db> > > > I'm willing to "poke at it" a bit, given a hint or two... > > >=20 > OK. I know what's happening here. disk_create() posts an event and also > expects to sleep to get memory. I can fix that too, but then that's one > more 'no memory' hole. >=20 > I'm unsure if we should keep playing whack-a-mole, or just defer this > creation to the taskqueue we already have hanging around... >=20 > Warner > .... Same (build) machine had a similar panic after updating source to main-n245372-d1cbe7908986 & rebuilding. FWIW. Also (as yesterday), neither laptop exhibited a problem after the corresponding update. Peace, david --=20 David H. Wolfskill david@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then =20 proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --lwHcNMrBwCAXLMBZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBIvZRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmSJwf+Pzx9Jg1ANJhLJxtVZAo0bGlrIRXiRKCcEq+5li8ge3K2tVahgwremHB/ UR7Y/FKNcnp3nQVGZtS5mnQ3tX050nVQyCN4JLnLQqLIvdJz7eGtG+dqJLOPAqgb 8OpAW2AlQEFk4VY0+AGbGrec6IvMJRBTaT0PXgfB23N/+N4HB6ruW4ZWzM+94i+r r0jVAGuIBjodLSr50oKpn+jXNXXKKliW9ZT7lbPO+Fwu3Ze7tOg0grCCELu044Pv BBxLNnXfYA925otvrVgW1br5sisWdYtr1Pd2vp/wPduDPAAzHS5YJLFNUhBjQ61w Y9de5+oLe7AqsapiOfoAPVUD7jBZnw== =Cgik -----END PGP SIGNATURE----- --lwHcNMrBwCAXLMBZ-- From owner-freebsd-current@freebsd.org Wed Mar 10 13:15:08 2021 Return-Path: Delivered-To: freebsd-current@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 4700A5688A6 for ; Wed, 10 Mar 2021 13:15:08 +0000 (UTC) (envelope-from pho@holm.cc) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DwXcW74xZz3Hhn for ; Wed, 10 Mar 2021 13:15:07 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.nyi.freebsd.org (Postfix) id F307D56898E; Wed, 10 Mar 2021 13:15:07 +0000 (UTC) Delivered-To: current@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 F2CC55684C2 for ; Wed, 10 Mar 2021 13:15:07 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DwXcW6VHPz3HcQ for ; Wed, 10 Mar 2021 13:15:07 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (unknown [80.208.71.94]) by relay05.pair.com (Postfix) with ESMTP id D59321A2986; Wed, 10 Mar 2021 08:15:06 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 12ADF63V078964 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 14:15:06 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 12ADF4U2078963; Wed, 10 Mar 2021 14:15:04 +0100 (CET) (envelope-from pho) Date: Wed, 10 Mar 2021 14:15:04 +0100 From: Peter Holm To: Hans Petter Selasky Cc: current@freebsd.org Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited Message-ID: <20210310131504.GA78928@x8.osted.lan> References: <20210310091548.GA76176@x8.osted.lan> <20210310114150.GA77805@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DwXcW6VHPz3HcQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 13:15:08 -0000 On Wed, Mar 10, 2021 at 01:33:34PM +0100, Hans Petter Selasky wrote: > On 3/10/21 12:41 PM, Peter Holm wrote: > > On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote: > >> On 3/10/21 10:15 AM, Peter Holm wrote: > >>> I just got this panic: > >>> > >>> igb0: port 0xd020-0xd03f mem 0xfb320000-0xfb33ffff,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8 > >>> igb0: Using 1024 TX descriptors and 1024 RX descriptors > >>> igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6 > >>> igb0: Using 6 RX queues 6 TX queues > >>> igb0: Using MSI-X interrupts with 7 vectors > >>> igb0: > >>> db> > >>> db> show panic > >>> panic: malloc(M_WAITOK) with sleeping prohibited > >>> db> bt > >>> Tracing pid 12 tid 100172 td 0xfffffe010dce2100 > >>> kdb_enter() at kdb_enter+0x37/frame 0xfffffe00e4f72980 > >>> vpanic() at vpanic+0x1b2/frame 0xfffffe00e4f729d0 > >>> panic() at panic+0x43/frame 0xfffffe00e4f72a30 > >>> malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4f72a50 > >>> malloc() at malloc+0x34/frame 0xfffffe00e4f72ab0 > >>> linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4f72b00 > >>> linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfffffe00e4f72b20 > >>> ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4f72bb0 > >>> fork_exit() at fork_exit+0x80/frame 0xfffffe00e4f72bf0 > >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4f72bf0 > >>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > >>> db> x/s version > >>> version: FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 10:00:29 CET 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012 > >>> db> > >> > >> This should fix it: > >> https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427 > >> > >> --HPS > > > > Yes, thank you. Now I see this: > > > > ugen0.3: at usbus0 > > ukbd0 on uhub3 > > ukbd0: on usbus0 > > kbd2 at ukbd0 > > panic: malloc(M_WAITOK) with sleeping prohibited > > cpuid = 0 > > time = 1615375651 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e4974890 > > vpanic() at vpanic+0x181/frame 0xfffffe00e49748e0 > > panic() at panic+0x43/frame 0xfffffe00e4974940 > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974960 > > malloc() at malloc+0x34/frame 0xfffffe00e49749c0 > > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfffffe00e4974a10 > > linux_timer_callback_wrapper() at linux_timer_callback_wrapper+0x37/frame 0xfffffe00e4974a30 > > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 > > softclock() at softclock+0x66/frame 0xfffffe00e4974b20 > > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 > > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > KDB: enter: panic > > [ thread pid 12 tid 100088 ] > > Try this: > https://cgit.freebsd.org/src/commit/?id=dfb33cb0ef48084da84072244e8ca486dfcf3a96 > Works for me. Thank you! - Peter > There will be a more comprehensive fix coming: > https://reviews.freebsd.org/D29183 > > --HPS From owner-freebsd-current@freebsd.org Wed Mar 10 15:25:12 2021 Return-Path: Delivered-To: freebsd-current@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 9C6CE56E714 for ; Wed, 10 Mar 2021 15:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 4DwbVc1jCkz3k2b for ; Wed, 10 Mar 2021 15:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 3899656E713; Wed, 10 Mar 2021 15:25:12 +0000 (UTC) Delivered-To: current@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 3860056E712 for ; Wed, 10 Mar 2021 15:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DwbVc0vZ4z3jtN for ; Wed, 10 Mar 2021 15:25:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf33.google.com with SMTP id 30so933185qva.9 for ; Wed, 10 Mar 2021 07:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZOQZoeNhM+mn9X9X9ATbuvQvYlDEbpEJcLlsCTLqTo8=; b=oihK6XaoILa/5LkLkLuXHVu1Df7eEkTUvoJg7SnznxSJgh0bbVeWyjDGpBEQEc/g2G FnFPkWgtLDPZZnZDTWiqBOMhS2iFzL5XbpxDBXxb5cCoUtieDp4EiJPuPFHU5pTALNHx P7eqeiTnY7/B6hJ0+4G75HOCnqAdkIy1XO+RXR6lI8Q6+YNEzcXJpO2RjfYod5KX8BT/ zlwYlIqMyddTCTtrUzNLQ18F8iyr8q/zqC8ltg1PTzexeN6eNHO8hBl8EYOkm2fCM4g5 Fs6Oej3jPn2sCyrEgSjrLybOBvDr5xilkROIw0m6u0Ny3+71F0liycC+nVmgIj+KLm9P Zjlg== 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; bh=ZOQZoeNhM+mn9X9X9ATbuvQvYlDEbpEJcLlsCTLqTo8=; b=LQL/w0WFkSHAULfaPujE/PkFw8fHmX0iz7oD16ZqvodEmvzNgHH5Tl3ZWBUK2fdGRs w2EF06k+56ZRm+JpJ+M/XZUak6oBPlluh1K7CApsM8PD9T/V8uSTr/nBoKsMspmg43fS +aruGThMBpNQOdBhElR1yDXTmbIGyM+N5pMpL7FROfnboFKy2jpcTeck+mZ/qYLTUb18 /3S9AtLumckFNgHXa7TodAlldPpqDcYu66TqPWG8mGOlE4ILFH6JjH69znLg3Zz7KtL6 GHL9+A9l2Dl4m9CrMyzN/HlcjfxeYDXwpD977yzcrh09A0l4teEo4u6p+GYjJqW2Jcly LEYw== X-Gm-Message-State: AOAM532u10vJK/2NdQwjAdaPwoxeZ73AtvMvXctnHD4oNuqCeyscEzOU 2TL1lOCVU923kKL+p0ZYv+vKIKlNC70XFHKbklGvR2uyYvI8nA== X-Google-Smtp-Source: ABdhPJyy6UrAqto1kRQlVY7c/8Z+rBsuoK4ZVrEKPdEl8Qq1TbDcYtCt1bZozP2TjNONn4m4AR9gd3uhmsvqsfzKmi0= X-Received: by 2002:a0c:a954:: with SMTP id z20mr3275682qva.29.1615389911000; Wed, 10 Mar 2021 07:25:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 10 Mar 2021 08:25:00 -0700 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 To: David Wolfskill , Warner Losh , FreeBSD Current X-Rspamd-Queue-Id: 4DwbVc0vZ4z3jtN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:25:12 -0000 On Wed, Mar 10, 2021 at 5:37 AM David Wolfskill wrote: > On Tue, Mar 09, 2021 at 04:04:56PM -0700, Warner Losh wrote: > > On Tue, Mar 9, 2021 at 2:46 PM David Wolfskill > wrote: > > ... > > > uma_zalloc_debug: zone "malloc-1024"umass0 on uhub2 > > > with the following non-sleepable locks held: > > > umass0: on usbus0 > > > exclusive sleep mutex CAM device lockumass0: SCSI over Bulk-Only; > quirks > > > = 0x4000 > > > (CAM device lock) r = 0 (0xfffff800122c9cd0) locked @ > > > /usr/src/sys/cam/cam_xpt.c:2333 > > > umass0:6:0: Attached to scbus6 > > > stack backtrace: > > > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > > > #0 0xffffffff80c7cce1 at witnesuhub3: 6 ports with 6 removable, self > > > powered > > > s_debugger+0x71 > > > pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0 > > > #1 0xffffffff80pass6: uhub4: 8 ports with 8 removable, self powered > > > c7ddfd at witness_warn+0x40d > > > #2 Removable Direct Access SCSI device > > > 0xffffffff80f42fe6 at uma_zallpass6: Serial Number 20100818841300000 > > > oc_arg+0x46 > > > #3 0xffffffff80be34pass6: 40.000MB/s transfers > > > panic: malloc(M_WAITOK) with sleeping prohibited > > > cpuid = 1 > > > time = 22 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > 0xfffffe00e157a2d0 > > > vpanic() at vpanic+0x181/frame 0xfffffe00e157a320 > > > panic() at panic+0x43/frame 0xfffffe00e157a380 > > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a3a0 > > > malloc() at malloc+0x34/frame 0xfffffe00e157a400 > > > g_post_event_x() at g_post_event_x+0x5a/frame 0xfffffe00e157a450 > > > g_post_event() at g_post_event+0x48/frame 0xfffffe00e157a4b0 > > > disk_create() at disk_create+0x16f/frame 0xfffffe00e157a600 > > > daregister() at daregister+0x70a/frame 0xfffffe00e157a880 > > > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950 > > > daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0 > > > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > > > 0xfffffe00e157aa10 > > > xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20 > > > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60 > > > xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0 > > > fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0 > > > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > > > KDB: enter: panic > > > [ thread pid 17 tid 100095 ] > > > Stopped at kdb_enter+0x37: movq $0,0x128b8ce(%rip) > > > db> > > > > > I'm willing to "poke at it" a bit, given a hint or two... > > > > > > > OK. I know what's happening here. disk_create() posts an event and also > > expects to sleep to get memory. I can fix that too, but then that's one > > more 'no memory' hole. > > > > I'm unsure if we should keep playing whack-a-mole, or just defer this > > creation to the taskqueue we already have hanging around... > > > > Warner > > .... > > Same (build) machine had a similar panic after updating source to > main-n245372-d1cbe7908986 & rebuilding. FWIW. > > Also (as yesterday), neither laptop exhibited a problem after the > corresponding update. > Yes it "works" without invariants. I'm working on a better fix that isn't such a huge game of whack-a-mole that defers the async messages to an taskqueue where they can sleep for memory, if need be. Warner > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > It is supremely disingenuous to claim a lack of jurisdiction, then > proceed to participate in a decision on the same matter. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@freebsd.org Wed Mar 10 15:36:43 2021 Return-Path: Delivered-To: freebsd-current@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 0F65656EBD0 for ; Wed, 10 Mar 2021 15:36:43 +0000 (UTC) (envelope-from david@catwhisker.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 4Dwblt5KQxz3kh1 for ; Wed, 10 Mar 2021 15:36:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id B6B0A56EBCF; Wed, 10 Mar 2021 15:36:42 +0000 (UTC) Delivered-To: current@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 B66F256EF03 for ; Wed, 10 Mar 2021 15:36:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dwblt39tkz3kpc for ; Wed, 10 Mar 2021 15:36:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 12AFackJ085482; Wed, 10 Mar 2021 15:36:38 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 12AFacVo085481; Wed, 10 Mar 2021 07:36:38 -0800 (PST) (envelope-from david) Date: Wed, 10 Mar 2021 07:36:38 -0800 From: David Wolfskill To: Warner Losh Cc: FreeBSD Current Subject: Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9 Message-ID: Mail-Followup-To: David Wolfskill , Warner Losh , FreeBSD Current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ckbIY/JPjm4i2/MB" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Dwblt39tkz3kpc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:36:43 -0000 --ckbIY/JPjm4i2/MB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2021 at 08:25:00AM -0700, Warner Losh wrote: > ... > > Also (as yesterday), neither laptop exhibited a problem after the > > corresponding update. > > >=20 > Yes it "works" without invariants. I'm working on a better fix that isn't > such a huge game of whack-a-mole that defers the async messages to an > taskqueue where they can sleep for memory, if need be. > .... Fair enough -- we see that ("works" without INVARIANTS option) often enough at work. :-} I'm happy to test.... Peace, david --=20 David H. Wolfskill david@catwhisker.org "So much money is being raised and completely wasted by people that do not have the GOP's best interests in mind." - D. Trump, who would know firsthan= d. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --ckbIY/JPjm4i2/MB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBI54ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmnHAgAhHnJXy0SZu+0ZPz/kiP7d1NXSmYfXh7d3wyiNAXvTp7EvaBv/oXaiJqe zAFStErDme+bnG/hihlUlGjdQwgNRybmThCz43km4mceWqg3OMIXYqNbJoBUVPDA Jr1MPO/fGYecA70UDBxi8aqWiEPpSXMy/4/yMwweFXb01tObTgxatVhYdgoDGaN1 fnFTEuj5gsy7ruuHAeC7gUf0OdAYyTgqLRqBsE6gfpNCpM1V/w7crjbP6S9ViL+d Gp819zqFxxO4SCln56A539LDhtE0qKPhbu0k3PhWBF1AL3dl4NX1KfrXzFmxNbbo TOBkTRePSdENLsEb4cUE/AtF+S/p9g== =vJi6 -----END PGP SIGNATURE----- --ckbIY/JPjm4i2/MB-- From owner-freebsd-current@freebsd.org Wed Mar 10 18:09:58 2021 Return-Path: Delivered-To: freebsd-current@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 2AD325721EB; Wed, 10 Mar 2021 18:09:58 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (kanar.ci0.org [IPv6:2001:bc8:35e6::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "sd-143795", Issuer "sd-143795" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dwg8j2BgSz3vw1; Wed, 10 Mar 2021 18:09:57 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (localhost [127.0.0.1]) by kanar.ci0.org (8.16.1/8.16.1) with ESMTPS id 12AI9cbs003713 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 19:09:38 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.16.1/8.16.1/Submit) id 12AI9cLh003710; Wed, 10 Mar 2021 19:09:38 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 10 Mar 2021 19:09:35 +0100 From: Olivier Houchard To: Mark Millard Cc: freebsd-arm , freebsd-current Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system Message-ID: References: <8B54D020-A3E2-4441-B6A0-894831E7E1EC.ref@yahoo.com> <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> X-Rspamd-Queue-Id: 4Dwg8j2BgSz3vw1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mlfbsd@kanar.ci0.org has no SPF policy when checking 2001:bc8:35e6::1) smtp.mailfrom=mlfbsd@kanar.ci0.org X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ci0.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:bc8:35e6::1:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:bc8:35e6::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[mlfbsd@ci0.org,mlfbsd@kanar.ci0.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:12876, ipnet:2001:bc8::/32, country:FR]; FROM_NEQ_ENVFROM(0.00)[mlfbsd@ci0.org,mlfbsd@kanar.ci0.org]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current] X-Mailman-Approved-At: Wed, 10 Mar 2021 19:17:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 18:09:58 -0000 Hi Mark, On Tue, Mar 09, 2021 at 03:39:42PM -0800, Mark Millard via freebsd-arm wrote: > After using poudriere to build ports for native cortex-a72 > on the MACCHIATObin Double Shot (and similarly for > cortex-a57 on the OverDrive 1000) I attempted to do my > usual bulk build targeting cortex-a7 via poudriere-devel: > > # poudriere jail -i -jFBSDFSSDjailArmV7 > Jail name: FBSDFSSDjailArmV7 > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud > Jail fs: > Jail updated: 2021-01-27 14:47:10 > Jail pkgbase: disabled > > But I got some SIGSEGV failures that I've never before > had analogous failures. I'll show the 6 backtraces. > They all have a similar type-of-context but in various > programs, summarized as (from the lldb bt outputs): > FREEBSD_COMPAT32 was indeed broken on arm64, and the process would crash when receiving a signal. I believe I fixed it in -CURRENT with commit c328f64d81079bad5064c8a387883df50ab5aaed Regards, Olivier From owner-freebsd-current@freebsd.org Thu Mar 11 00:18:38 2021 Return-Path: Delivered-To: freebsd-current@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 1634F57BD20 for ; Thu, 11 Mar 2021 00:18:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DwqL46Vl4z4tZw for ; Thu, 11 Mar 2021 00:18:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f170.google.com with SMTP id t83so11260413oih.12 for ; Wed, 10 Mar 2021 16:18:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o/zLsiCk2zKmrPoN7L8FTy1qKAT9/vDem/JoAMvTOEk=; b=rmI2z9RcNlKNkbV0Hr5lFHsUlvdlTJZFmttEneUYQmTAqmuvaXg61bADWCT7m3tVOF eEUA67tuD7z146S54PsXJ1dy5bQpkTAjnth3D1olJ+ovoCBdSxVYV5MmY8QTon5xmHB5 Aqkj2RJAXf4cluB5nodWI+rKCiLhsj0m38mRMkAecXi0XRQ6SsTw7cVWlHnQTW0HjOmp +if92ukdlqryX5QpPWSN0APFC61uNzcy/UqMqeH5iRsb/wkpFUJz5LBht+Bvm3ik+Zz5 o2v9dUDILJzn1WaRxGTzNUx+3jrBp90PFxS4o/YY+VfZMkRsREzZqTutGVolSSPnujOf 58aw== X-Gm-Message-State: AOAM531w8TPSQL76ga/16hQksU+NOpzf2vaxEbEMzye0n0B3J2rkHBES MLI/3/DfAb+0EEuppjGME4rDGnbcMUgbpEmSgsj+cJ09t4lrdA== X-Google-Smtp-Source: ABdhPJykoNAbExBMjys+CB2yS19QEWfowVEyDwaH/iFSKof1N9TUEZzRlwUlRmKj6rmSLna3cwhbTawtnJEWm60ZuRs= X-Received: by 2002:aca:4f0b:: with SMTP id d11mr4390050oib.73.1615421915186; Wed, 10 Mar 2021 16:18:35 -0800 (PST) MIME-Version: 1.0 From: Alan Somers Date: Wed, 10 Mar 2021 17:18:24 -0700 Message-ID: Subject: Getting started with ktls To: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DwqL46Vl4z4tZw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.170:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[209.85.167.170:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.170:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.170:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 00:18:38 -0000 I'm trying to make ktls work with "zfs send/recv" to substantially reduce the CPU utilization of applications like zrepl. But I have a few questions: * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported Libraries" section says "Applications using a supported library should generally work with ktls without any changes". These sentences seem to be contradictory. I think it means that the TCP_TXTLS_ENABLE option is necessary, but OpenSSL sets it automatically? * When using OpenSSL, the library will automatically call setsockopt(_, TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an application to tell if ktls is enabled on a particular socket or OpenSSL session? * From experiment, I can see that OpenSSL attempts to set TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? >From reading ktls_start and ossl_statem_server_post_work, it looks like maybe a single socket cannot have ktls enabled for both sending and receiving at the same time. Is that true? Based on the man page and rmacklem's previous mailing list posts, I think this should be workable with minor modifications to the kernel and libzfs. I just need to figure out how to use ktls first. -Alan From owner-freebsd-current@freebsd.org Thu Mar 11 00:31:44 2021 Return-Path: Delivered-To: freebsd-current@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 ECE9E57C6F4 for ; Thu, 11 Mar 2021 00:31:44 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4DwqdD0Z1bz4vc4; Thu, 11 Mar 2021 00:31:43 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12B0Va6H006213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 19:31:41 -0500 Date: Wed, 10 Mar 2021 16:31:36 -0800 From: Benjamin Kaduk To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: Getting started with ktls Message-ID: <20210311003136.GM56617@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DwqdD0Z1bz4vc4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 00:31:45 -0000 On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > the CPU utilization of applications like zrepl. But I have a few questions: > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > Libraries" section says "Applications using a supported library should > generally work with ktls without any changes". These sentences seem to be > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > necessary, but OpenSSL sets it automatically? Yes, OpenSSL sets it automatically for the builtin socket and connection BIO classes. Applications using other BIO classes will need to do things manually (or implement the appropriate _ctrl() parameters for their BIO class). > * When using OpenSSL, the library will automatically call setsockopt(_, > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > application to tell if ktls is enabled on a particular socket or OpenSSL > session? IIRC the lack of answer for this is part of why upstream OpenSSL doesn't have specific KTLS tests enabled in the automated test suite. > * From experiment, I can see that OpenSSL attempts to set > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > From reading ktls_start and ossl_statem_server_post_work, it looks like > maybe a single socket cannot have ktls enabled for both sending and > receiving at the same time. Is that true? No. They just get enabled separately, since change_cipher_state() is called separately for read and write transitions. -Ben > Based on the man page and rmacklem's previous mailing list posts, I think > this should be workable with minor modifications to the kernel and libzfs. > I just need to figure out how to use ktls first. > > -Alan > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 11 01:17:54 2021 Return-Path: Delivered-To: freebsd-current@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 90E5657E167 for ; Thu, 11 Mar 2021 01:17:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DwrfV3g5qz3G6Q for ; Thu, 11 Mar 2021 01:17:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id n23so12798584otq.1 for ; Wed, 10 Mar 2021 17:17:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dE2ipxBtRwPtOyFB+xuzXwuRbGTtrgIYM5gdq1IIqLI=; b=bq4cSE+lzglToCPvGWQRSoMsO9E/T5Yxyl4Rbb1o1E5om003HRTaX+xKChcmiHdd53 oqSxUpXJwaQfe39QFAh7rjokfCkVTYGhDssKPR1F8qoz+7is5g48RrXse9WP5df0IXeW hK/YQ2F4/O5K8M6J834DuAo+9dyyEjPcAYLbia2QHucUGDd7ux6DqngeL2M5aP/V2eMx k6hLQ0542rjjBbFik1JOxfgjpK6+GyNJ5oJm7jQAdnBS4ff8BXpKUC9MOeK+BWEd+HUd LbcDXP0Eit2cjQXMxZ6Y9eFNOtoKJT0ii+5gNUv8iSOib5MwX3tVeUk7tHLofKsg5WQJ +Ifw== X-Gm-Message-State: AOAM532ivC32fdMk6dTUchWqSAWggIqWRM2CquHIDASRc8+2jPct2gWG cUJEtpbT1IEHUr7+KeKGPjVOwe37mPhnmpSIzLM= X-Google-Smtp-Source: ABdhPJx8zNfMTuQ6Zjx/IEeiqpb77CHCcq+0kEDEd9zG4NvCXreTJyb/twj83m8yFO8RHx1S26BsvYLiDilIGMV7pHE= X-Received: by 2002:a9d:76d4:: with SMTP id p20mr4911995otl.18.1615425473539; Wed, 10 Mar 2021 17:17:53 -0800 (PST) MIME-Version: 1.0 References: <20210311003136.GM56617@kduck.mit.edu> In-Reply-To: <20210311003136.GM56617@kduck.mit.edu> From: Alan Somers Date: Wed, 10 Mar 2021 18:17:42 -0700 Message-ID: Subject: Re: Getting started with ktls To: Benjamin Kaduk Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DwrfV3g5qz3G6Q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 01:17:54 -0000 On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, OpenSSL sets it automatically for the builtin socket and connection > BIO classes. Applications using other BIO classes will need to do things > manually (or implement the appropriate _ctrl() parameters for their BIO > class). > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > IIRC the lack of answer for this is part of why upstream OpenSSL doesn't > have specific KTLS tests enabled in the automated test suite. > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason why it's not implemented? That might be the easiest way to check for the ktls status of an individual socket. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > No. They just get enabled separately, since change_cipher_state() is > called separately for read and write transitions. > Apologies if I'm too ignorant, but what is a transition in SSL-speak? This is my first attempt at any kind of SSL programming. What I know from ktrace is that TCP_RXTLS_ENABLE never gets set. > > -Ben > > > Based on the man page and rmacklem's previous mailing list posts, I think > > this should be workable with minor modifications to the kernel and > libzfs. > > I just need to figure out how to use ktls first. > > > > -Alan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Mar 11 03:05:33 2021 Return-Path: Delivered-To: freebsd-current@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 CE7225ACEDA for ; Thu, 11 Mar 2021 03:05:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (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 4Dwv2h1n7hz3hHr for ; Thu, 11 Mar 2021 03:05:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615431931; bh=6lL10SD54uO1tnnnZwvXWuHVrAljxIVKy2zAtXc9LYC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OGJ7hN3OTEgdEBAZEQ4K1CM/wi8XRqEIDyitlgyBqOoDpzEMQiah9IlUG+HmwiX39GQCXlBmKsdupeXE295geY6X3NkSe0v2rzRZXw6/xGT0qcyiJHBjS+eEerVKS8X/aFk93h0xmhT6oxyA2e11XEYvh3FGYvvv2hOYDNFgz6DGgsyaWmFivy7iheTB9CT0Wh5ky14pwzC+Ivl18Wk1vzIqvPcM5YO7MqukPKyLfYLraISse9R1VsYOcIqt3gew/rsp1gA2WYbZb9mJlrq0B6dtMGRyyC0gIXOKEHzcA/TrLoGfJUIYXFabRmoehvQj3dWJqCX6jqznFe+2ppQsGQ== X-YMail-OSG: r2UBpQIVM1liSeSvByswcP2sXu.nXsQLvg0exRa0auUIhcMLz324dZhcasPAl1l PfIdDp2JKOs2aUkvJUGRKYhArirGGpc3xxIUK7cpe1q9V.a0iCVBX0LsYSTn9_c7Cc4b_6vTqyPd EmUlTeNALoBlB1JhKbks7m2vpHIwRCPyahhk4IKC9Q0xLmjf_P1FHbszEzNrWMTqMUIklH4PhXLk PzXNB7ZqVA8N6VqnbU7sl7RJQez3Q4PopHsMkZSIC52y0UJ9fVAyvcgvWNIlQ8Oa3mmHysAJPpy0 dhXjJuYbfCkFmdQ2V0GtCEERNyUxiZPjNyHTxHxvepOgTdhMRH5spLv5IkDilT0IqazjWa_YysjN PB4lk5sisejuQxqkjlOy5E6S_RqXaXv6kRXsAaiaoscsQUqr3Grm3WxmL9BYWF5ua2M4UD1uMwLC ZBtVbjn1IWTtTU32Ezf10s748x9aF6Z2ps04wsAeYVnWB2nPl53X81f8L9q68DhBEZiCeqi_nPBu 89t6NK.J2.Owd2JVbl5gC6gVRcFIQAg7xplMyW09MozBENoZ3GbD16zY6M40RRDveKQe6gfoDy17 f1dTlhj8KNfISQGMxwTqP0TnRbYSHl09cNEvLNkNadLXenUP0LXmlS_zzZGeQ8qtdyPkbeH8CoCY KxNrXmf6UdDqAx5aMJUvrm1rhUIOuKtRjbVnx49cK__wdKTdYS5McWM9JXh6xVcTk0Ao5tFsRJdT 2YGrY2_iM8Xm.dvQmRHXgzMUyyVP4JEgRmtmB1FKeJ53KqVBTIT0S2bqoAO9K2ytn3KmJyk6xAcb zOGowsKgDK6UjSzlGXUvWE3ZgYxMLrtsm5L0blLT2_qf6TYdMhjyaFInqCA6u6wXlZzn3421crZK VD1O4OdDBGllKm2YF4mLfca1p230U.RWlA8SNIlQc72XAEUyOdDDGxHz5fwqMbSrmWsNJP5rFm4C wY77rDKk2xDdSa8R9uB6adaXH7Os4pBKshTbOCxWG6zXrjjOyLDoV7oawKc2emlbuPd46BDo93Mh VO4Qf3M6WeMWFCxjGzNL8GZ39rVDp1c6O6AkbhVykCkjjIQG0Torx6yrtisEO__imnLMY2xfoMvG g_G07PJ0Swid.V_d43.GLgbppcH12xpI7mnpRLLoBsXbV9314iaXr3UFmlAVg3v3FwR5n1aGg0jW 8MqYKh8_VzbMapEb2nU5KglH_evPAQWEAxNKdhkZJQqI1KZ4vNAsC1ypXJ4qoh9424DIsKR4pNr. cJbM6CGCNVf5Ir5VNltJ0uV2J4L2L0gbcgZnswUbIzVhFCWv4EwAy12e71ytfXrw3JwfERFwCXQv kDdkzMInWl3Kye9MwJU5TMFtPNHw9f3ZVYe8f6_TJ2KoLY48d1EkQ.KtQmhHM46HyOGZLASj.SYr 7.8v5FE.w_9my6IeSh.SC0sv1IHC89UqQLnYOK71aJKWmtq9_oleTzdIwLPzivwB1YUCGPK8GSZv ctveF4_yXCqG.nlbPTUxjwd_A1KSVh0iuua6K0C6oABzqyzbBKxaAVu.ALivGt6BrfPfsZ5VSam3 7s1MgwzxGuZLMXhxJhYhAK_7iWDW5Y0pj9FeQ3Af8lMkrmoLhrsDTPVp5VzlaiScUai42lKy4uTm wA7nOknSU9afwS75mdBN61PeXo3Y6GfkhEr.yHFRcCxLmLfV9XPfZo.nu2Q5v4_cgTsttsUEGQGs yP5GWnfgjYokiUFgBi_HhXmAENkesKb0D0GlEL041.SopvocBcmrLImr1Ti8vkoBF4nvzMovktkW 53YDD4_WY4nzJXvjQPSr3bb7CXK5BAuq4naliut82wTJSVuvO9y4fDUdIjzWJhHfLjlmvXDYw__E mI3jwrPHmR6OoyDEe9qL.cjbANxjVOFlXvcPoLDlHGyADU4BKKghQBstcmxclc0i2NCJshinTOrV h16HQBH5IH.LLFMxxLFbY_y8Y2Sqar.omr1gkFszih.zwDCICpPUZzQc_fsMKHijWDT8q6f90xcF em3Ea60OcZRk9hrPT0glsmCqiqZuf8iLq2n7v4ni2WQuqL9AqsBZntyIoBsB8cwkoFJVh8iGZk_n UJgo6N0ok0DjK8FyJ14alWUBD.8sEdJPnciv7_0u8ys_dAtsX4YC3E_fdTvfhtkB4vZZJ.wV5NCm upr.l2vGjfm4xfLEz0ueF6cLXfx4rcLWwN8POay7yzyFj726Z6ThNeX7W0oZGIl7yIM1LvBh48xt P_fn1Xott5qCKLOob3wYlnqJhdyclA.RqOnG21oNnoNsfV6O3bG5CKI1BSJ7xw3zEEEZLQGIZu_p 1VsmaMQOK4.DJXCax9j.nYLAdFM1QPrrUBNyrYklJsXOVpy2Ya05jz7TAW4dhTutTgzNxXnov6z3 lox2cDcJ2hW2qAEBbth6ADpkMGOo8pqRzbfBwUBYgUlDfjwyZQaWq7x3OJgQYQ7_n6tOCssFuGHQ qV.ha7JPYwKYKhWnzMKZoHpjVE3AloIfo0UxpfSUxU260qceLJEgFtZ20tdNXiLKVwl8eF5UDb6E UDRqhfW6n7oKF82c6O.JKzzCKSSnmmg8rRV4m1HV27C._WZa5I9FiDyLXZz38gHiDiM0Ry9ynSzM ydcq5pJ_2Z7haxnLwfq125AB8mSbQcPQq34HSEMey6D5Ttkogr42zmep5eqiNXuDhpFpmlSj84o_ uzrMyUxCZIDrW8DiMQZtkWY40kHKuwJtfVUwC4y9FUNNhl0tz7kfgUO8h07mEx6u8AY7CdX7_8JZ ZVs9s58Dsxu.HYD9Xzi3GgDd6051BbTKhfgISI5xzpmp4ew-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Thu, 11 Mar 2021 03:05:31 +0000 Received: by smtp425.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 62e8888b4473b06363a18829889eab64; Thu, 11 Mar 2021 03:05:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: FYI: main (bad9fa56620e based): some unexpected SIGSEGV's using poudriere-devel to build armv7 ports on aarch64 (cortex-a72) system From: Mark Millard In-Reply-To: Date: Wed, 10 Mar 2021 19:05:26 -0800 Cc: freebsd-arm , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <44D4B523-D8E7-4E86-8458-B8F5165689C9@yahoo.com> References: <8B54D020-A3E2-4441-B6A0-894831E7E1EC.ref@yahoo.com> <8B54D020-A3E2-4441-B6A0-894831E7E1EC@yahoo.com> To: Olivier Houchard X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4Dwv2h1n7hz3hHr X-Spamd-Bar: - X-Spamd-Result: default: False [-1.52 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.189.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.98)[0.982]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.189.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.189.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.189.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 03:05:33 -0000 On 2021-Mar-10, at 10:09, Olivier Houchard wrote: > On Tue, Mar 09, 2021 at 03:39:42PM -0800, Mark Millard via freebsd-arm = wrote: >> After using poudriere to build ports for native cortex-a72 >> on the MACCHIATObin Double Shot (and similarly for >> cortex-a57 on the OverDrive 1000) I attempted to do my >> usual bulk build targeting cortex-a7 via poudriere-devel: >>=20 >> # poudriere jail -i -jFBSDFSSDjailArmV7 >> Jail name: FBSDFSSDjailArmV7 >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/clang-armv7-installworld-poud >> Jail fs: =20 >> Jail updated: 2021-01-27 14:47:10 >> Jail pkgbase: disabled >>=20 >> But I got some SIGSEGV failures that I've never before >> had analogous failures. I'll show the 6 backtraces. >> They all have a similar type-of-context but in various >> programs, summarized as (from the lldb bt outputs): >>=20 >=20 > FREEBSD_COMPAT32 was indeed broken on arm64, and the process would = crash > when receiving a signal. I believe I fixed it in -CURRENT with commit > c328f64d81079bad5064c8a387883df50ab5aaed >=20 I built and updated FreeBSD based on that vintage and the port builds are part way through. The ports that I had observed problems for have built just fine and no others have failed so far. If it all builds, it will be tomorrow sometime before the bulk builds finish. But I figured I'd indicate that the fix looks to have fully worked for my context that had the problem. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu Mar 11 03:15:10 2021 Return-Path: Delivered-To: freebsd-current@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 42E8C5AD4EB for ; Thu, 11 Mar 2021 03:15:10 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4DwvFm3gsBz3jCm; Thu, 11 Mar 2021 03:15:08 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12B3F1JK023312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 22:15:06 -0500 Date: Wed, 10 Mar 2021 19:15:01 -0800 From: Benjamin Kaduk To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: Getting started with ktls Message-ID: <20210311031501.GP56617@kduck.mit.edu> References: <20210311003136.GM56617@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DwvFm3gsBz3jCm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 03:15:10 -0000 On Wed, Mar 10, 2021 at 06:17:42PM -0700, Alan Somers wrote: > On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > > > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > > the CPU utilization of applications like zrepl. But I have a few > > questions: > > > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > > Libraries" section says "Applications using a supported library should > > > generally work with ktls without any changes". These sentences seem to > > be > > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > > necessary, but OpenSSL sets it automatically? > > > > Yes, OpenSSL sets it automatically for the builtin socket and connection > > BIO classes. Applications using other BIO classes will need to do things > > manually (or implement the appropriate _ctrl() parameters for their BIO > > class). > > > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > > application to tell if ktls is enabled on a particular socket or OpenSSL > > > session? > > > > IIRC the lack of answer for this is part of why upstream OpenSSL doesn't > > have specific KTLS tests enabled in the automated test suite. > > > > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason > why it's not implemented? That might be the easiest way to check for the > ktls status of an individual socket. I think that's probably more of a question for jhb than me. I don't know of a reason why not, but I do know that there is some desire to keep the functionality that openssl exposes roughly compatible between linux and FreeBSD KTLS. I don't know whether Linux has something similar. > > > > > > * From experiment, I can see that OpenSSL attempts to set > > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > > maybe a single socket cannot have ktls enabled for both sending and > > > receiving at the same time. Is that true? > > > > No. They just get enabled separately, since change_cipher_state() is > > called separately for read and write transitions. > > > > Apologies if I'm too ignorant, but what is a transition in SSL-speak? This > is my first attempt at any kind of SSL programming. What I know from > ktrace is that TCP_RXTLS_ENABLE never gets set. Sorry! I'm pretty conversant with this stuff (I'm the security area director that is responsible for the IETF TLS working group) and don't always target the right level. Basically, for a decent encrypting protocol you want different encrytion keys for the read and write direction (whichever peer you are), and the TLS (1.3) handshake has a multi-stage key hierarchy to try to encrypt as much of it as possible. So, for example, the client will need to update it's encryption key for reading once it reads the ServerHello (and before reading the Encrypted Extensions) message, even though the keys the client uses for writing don't change at that time. Internally, OpenSSL implements this "transition" of key material with a change_cipher_state() abstraction, that takes a flags argument (`which`). The flags indicate which set of keys to update, and which direction (read or write). So, by my read of the code, what's *supposed* to happen is that we call: if (BIO_set_ktls(bio, &crypto_info, which & SSL3_CC_WRITE)) And if SSL3_CC_WRITE is set, that translates to calling BIO_set_ktls() with an `is_txt` value that evaluates to true; otherwise, `is_txt` is false, which corresponds to the RX case that you're failing to see happen. Just to get the boring stuff out of the way: what version of openssl are you testing against, and did you verify that OPENSSL_NO_KTLS_RX is not defined when ktls_start() is being compiled (so that the setsockopt(fd, IPPROTO_TCP, TCP_RXTLS_ENABLE, .) is compiled in at all)? Thanks, Ben From owner-freebsd-current@freebsd.org Thu Mar 11 03:55:21 2021 Return-Path: Delivered-To: freebsd-current@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 77D665AEEFD for ; Thu, 11 Mar 2021 03:55:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Dww892xMDz3m0j for ; Thu, 11 Mar 2021 03:55:21 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id m1so137011ote.10 for ; Wed, 10 Mar 2021 19:55:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ijtNFrkVaYB/8Eee0PoSSul9n3dRiuRDXlNXgf/u7BQ=; b=cm+EPaDMSTevG0TXVpVCaUYi3FOvhtaAmeDVZaAxzB81bSfdq+gENkRk+4KYYDOlHI ioaQuToU7JA+/4j40JCinTyy83LegphoOchdoOe3qVY5AME/0bwEWzH+19NdP1B3HauV NwvXwwWH+zzcSgaohTuwkkQxBvJWBG37j7XLQ94FQ8eGBiHo8yWKP6D1sByBPXYO0xcg B2RsEd5gA1/lFqBYAiiqUJazs/bc5vJ5gvAZikmjbAF0iMv2O0nv83zCBwu9PTHhY57n ZFbzMcoxwqu3A0DXJayuHW79WfYqZn18Cpoz4T81LV2RO87O0gBsbDv18Z3iHaihfzqS QVHw== X-Gm-Message-State: AOAM530s99kdIMKDXR4GeChk5JXA56CTfMd6W9s05G5aHW9zdzhKvvXY hyTwXTIM2cR94fUsdAvfBnW8VOxXFpX0AqHSIdY= X-Google-Smtp-Source: ABdhPJw/B1+l6W1JeTjNyr05yRvz7/hO3HHi/AFUwGccojoPS/w91E5iE7NgkgbCtpPvIwj841p7sC6KILxvYA/lE/k= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr5466762otq.251.1615434920439; Wed, 10 Mar 2021 19:55:20 -0800 (PST) MIME-Version: 1.0 References: <20210311003136.GM56617@kduck.mit.edu> <20210311031501.GP56617@kduck.mit.edu> In-Reply-To: <20210311031501.GP56617@kduck.mit.edu> From: Alan Somers Date: Wed, 10 Mar 2021 20:55:09 -0700 Message-ID: Subject: Re: Getting started with ktls To: Benjamin Kaduk Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4Dww892xMDz3m0j X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 03:55:21 -0000 On Wed, Mar 10, 2021 at 8:15 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 06:17:42PM -0700, Alan Somers wrote: > > On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > > > > > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > > > I'm trying to make ktls work with "zfs send/recv" to substantially > reduce > > > > the CPU utilization of applications like zrepl. But I have a few > > > questions: > > > > > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by > a > > > > successful set of the TCP_TXTLS_ENABLE socket option", but the > "Supported > > > > Libraries" section says "Applications using a supported library > should > > > > generally work with ktls without any changes". These sentences seem > to > > > be > > > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > > > necessary, but OpenSSL sets it automatically? > > > > > > Yes, OpenSSL sets it automatically for the builtin socket and > connection > > > BIO classes. Applications using other BIO classes will need to do > things > > > manually (or implement the appropriate _ctrl() parameters for their BIO > > > class). > > > > > > > * When using OpenSSL, the library will automatically call > setsockopt(_, > > > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > > > application to tell if ktls is enabled on a particular socket or > OpenSSL > > > > session? > > > > > > IIRC the lack of answer for this is part of why upstream OpenSSL > doesn't > > > have specific KTLS tests enabled in the automated test suite. > > > > > > > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason > > why it's not implemented? That might be the easiest way to check for the > > ktls status of an individual socket. > > I think that's probably more of a question for jhb than me. I don't know > of a reason why not, but I do know that there is some desire to keep the > functionality that openssl exposes roughly compatible between linux and > FreeBSD KTLS. I don't know whether Linux has something similar. > > > > > > > > > > * From experiment, I can see that OpenSSL attempts to set > > > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why > not? > > > > From reading ktls_start and ossl_statem_server_post_work, it looks > like > > > > maybe a single socket cannot have ktls enabled for both sending and > > > > receiving at the same time. Is that true? > > > > > > No. They just get enabled separately, since change_cipher_state() is > > > called separately for read and write transitions. > > > > > > > Apologies if I'm too ignorant, but what is a transition in SSL-speak? > This > > is my first attempt at any kind of SSL programming. What I know from > > ktrace is that TCP_RXTLS_ENABLE never gets set. > > Sorry! I'm pretty conversant with this stuff (I'm the security area > director that is responsible for the IETF TLS working group) and don't > always target the right level. Basically, for a decent encrypting protocol > you want different encrytion keys for the read and write direction > (whichever peer you are), and the TLS (1.3) handshake has a multi-stage key > hierarchy to try to encrypt as much of it as possible. So, for example, > the client will need to update it's encryption key for reading once it > reads the ServerHello (and before reading the Encrypted Extensions) > message, even though the keys the client uses for writing don't change at > that time. Internally, OpenSSL implements this "transition" of key > material with a change_cipher_state() abstraction, that takes a flags > argument (`which`). The flags indicate which set of keys to update, and > which direction (read or write). So, by my read of the code, what's > *supposed* to happen is that we call: > > if (BIO_set_ktls(bio, &crypto_info, which & SSL3_CC_WRITE)) > > And if SSL3_CC_WRITE is set, that translates to calling BIO_set_ktls() with > an `is_txt` value that evaluates to true; otherwise, `is_txt` is false, > which corresponds to the RX case that you're failing to see happen. > > Just to get the boring stuff out of the way: what version of openssl are > you testing against, and did you verify that OPENSSL_NO_KTLS_RX is not > defined when ktls_start() is being compiled (so that the setsockopt(fd, > IPPROTO_TCP, TCP_RXTLS_ENABLE, .) is compiled in at all)? > > Thanks, > > Ben > I'm using the OpenSSL that's in base in 14.0-CURRENT: 1.1.1j-freebsd . I haven't recompiled the code to check whether OPENSSL_NO_KTLS_RX is defined, but it sure looks like it shouldn't be, based on my reading of the source. -Alan From owner-freebsd-current@freebsd.org Thu Mar 11 08:51:27 2021 Return-Path: Delivered-To: freebsd-current@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 AC53056EF22 for ; Thu, 11 Mar 2021 08:51:27 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dx2jp4tJbz4WyV for ; Thu, 11 Mar 2021 08:51:26 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Thu, 11 Mar 2021 09:51:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1615452684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Jc43NCX6aUWGi2GUsh3C9y2DgNrkD2zrMWKU6nqcuvA=; b=VDo+C9VleMi9oQILvfkKR2f1dGZrdwlwX/RhepgOc4PQr5KJIAb5OMxBU4YBE9HlPgDKd7 9hsAd+we3dY2+KrHlSDZ1QCFwEcep8c5v3RH9bASkOtTQ7tYwErNM3ZC0snYYLcx2FxnLz 0hEAZcWfyzzdRdjR/KwotBh1MH7tc1dtSk/UhWronCGbgs6TWm/RoctIjT1i7EN+QBRfXg EdfYgOWPP1Mpe4oWN2llOD92kNm9tJAHzo8kso4SYpvhsccBqsECx3GGLVTkX+3PhII5Db +Uqhc/VmHM2NgGzkxyG823LgN57hQWri7/dtZBVYUYirxFrM7CEDqvXEUaWh9A== From: Ronald Klop To: FreeBSD CURRENT Message-ID: <1560991455.28.1615452681953@localhost> Subject: libifconfig_sfp.h does not compile for me MIME-Version: 1.0 X-Mailer: Realworks (551.2.89c726ce8c6) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Dx2jp4tJbz4WyV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=VDo+C9Vl; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 08:51:27 -0000 Hi, This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. The last change in these files is a few days ago, am I the only one with this problem? This is on 14-CURRENT/amd64. Regards, Ronald. From owner-freebsd-current@freebsd.org Thu Mar 11 09:04:26 2021 Return-Path: Delivered-To: freebsd-current@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 06E7C56FA38 for ; Thu, 11 Mar 2021 09:04:26 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dx30n5P76z4XrH for ; Thu, 11 Mar 2021 09:04:25 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lKHF0-0001qt-Lw; Thu, 11 Mar 2021 10:04:22 +0100 Date: Thu, 11 Mar 2021 10:04:22 +0100 From: Kurt Jaeger To: Ronald Klop Cc: FreeBSD CURRENT Subject: Re: libifconfig_sfp.h does not compile for me Message-ID: References: <1560991455.28.1615452681953@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1560991455.28.1615452681953@localhost> X-Rspamd-Queue-Id: 4Dx30n5P76z4XrH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 09:04:26 -0000 Hi! > This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. > The last change in these files is a few days ago, am I the only one with this problem? > > This is on 14-CURRENT/amd64. It looks like libifconfig_sfp_tables.h might be created during the build via the template https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp_tables.tpl.h Maybe this fails to build ? -- pi@opsec.eu +49 171 3101372 Now what ? From owner-freebsd-current@freebsd.org Thu Mar 11 09:08:53 2021 Return-Path: Delivered-To: freebsd-current@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 BA80E56FEE5 for ; Thu, 11 Mar 2021 09:08:53 +0000 (UTC) (envelope-from SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dx35w52SJz4YR9 for ; Thu, 11 Mar 2021 09:08:52 +0000 (UTC) (envelope-from SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 6CBE3CB8B; Thu, 11 Mar 2021 10:08:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1615453725; bh=FuJCplGDmw75qVh5Ep36r6TkDR7nfETlF9hbDeJgBu0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mOCDW+QYyBFqxu+QwuO7P58gvF4dGNSpT5LuwMJFOfxSPsdpEW4ZPZt+TTyfza09p WqoI/cdlkL6Bb4masVI28kmlJuVj9ALtZ9fz9i5B9MFTtI0CCashDoxvHJLTU4Zeo9 xAXHN5O+1NjVyd7u2sxBAx7rm+B08ch7OZNxRWto= From: "Kristof Provost" To: "Ronald Klop" Cc: "FreeBSD CURRENT" Subject: Re: libifconfig_sfp.h does not compile for me Date: Thu, 11 Mar 2021 10:08:44 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: <5C5418A4-B636-4E66-A346-74A24C9F8CA3@sigsegv.be> In-Reply-To: <1560991455.28.1615452681953@localhost> References: <1560991455.28.1615452681953@localhost> MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Dx35w52SJz4YR9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=mOCDW+QY; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be designates 5.9.86.228 as permitted sender) smtp.mailfrom=SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-3.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.9.86.228]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SPAMHAUS_ZRD(0.00)[5.9.86.228:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[sigsegv.be:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[5.9.86.228:from]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=OZui=IJ=sigsegv.be=kristof@codepro.be]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 09:08:53 -0000 On 11 Mar 2021, at 9:51, Ronald Klop wrote: > Hi, > > This > https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h > includes libifconfig_sfp_tables.h which does not exist. > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, > but no succes. > The last change in these files is a few days ago, am I the only one > with this problem? > How are you building? libifconfig_sfp_tables.h is a generated file, and the build should have created it. It does for me: /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables.tpl.h >libifconfig_sfp_tables.h /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables.tpl.c >libifconfig_sfp_tables.c /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables_internal.tpl.h >libifconfig_sfp_tables_internal.h Although I do not understand the magical incantations in the makefile that make it do so I can see that they’re there and that they do what’s required. Regards, Kristof From owner-freebsd-current@freebsd.org Thu Mar 11 09:26:12 2021 Return-Path: Delivered-To: freebsd-current@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 1CA87570625 for ; Thu, 11 Mar 2021 09:26:12 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dx3Tv2ZHPz4ZRg for ; Thu, 11 Mar 2021 09:26:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Thu, 11 Mar 2021 10:26:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1615454769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u44+hInNc/dM5yEuOqf8vk3qNUmqWZgnYwZ8T6aWtnc=; b=fiXaZJfTMidP+ktmM9B9Rd2x0WFTqdS/VCOOjpB5FDVtw7GlLL4TgNY4yZUEWgtqQf1/Ft jX0C4h/fRM0XcNsA7gV37nix9iIIc62kFAEJYRWPB5TMEoj/JlXQq4lMwfo2iXwjwuawAP 6P6KhhN6c0737i7pyRB1kfh6tc2OmtGs+8bRNCFw4nHIlnOsC6wV+rap7EWFZM4F8zzTjF xx5Cw8YO31EGKexgSIo81OLlLbH1f5nmBoVzVdSPDjDew5zAW/neQ5yijs91XTDTq6UEOk KXWj6aM4Q312BcNAGKGw9nSOhXiyGLbFpd2+svW00IiKJb2plMPuESeC8RYH4Q== From: Ronald Klop To: FreeBSD CURRENT Message-ID: <1556373450.7.1615454769214@localhost> In-Reply-To: References: <1560991455.28.1615452681953@localhost> Subject: Re: libifconfig_sfp.h does not compile for me MIME-Version: 1.0 X-Mailer: Realworks (551.2.89c726ce8c6) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Dx3Tv2ZHPz4ZRg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=fiXaZJfT; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(1.00)[0.997]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 09:26:12 -0000 Van: Kurt Jaeger Datum: donderdag, 11 maart 2021 10:04 Aan: Ronald Klop CC: FreeBSD CURRENT Onderwerp: Re: libifconfig_sfp.h does not compile for me > > Hi! > > > This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. > > > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. > > The last change in these files is a few days ago, am I the only one with this problem? > > > > This is on 14-CURRENT/amd64. > > It looks like libifconfig_sfp_tables.h might be created during the > build via the template > > https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp_tables.tpl.h > > Maybe this fails to build ? > > -- > pi@opsec.eu +49 171 3101372 Now what ? > > > Hi, Thanks for the quick answers. I did some more manual cleaning, but the error keeps coming back. Although I see the generated file in the obj dir. Now nuked the whole /obj dir and doing a clean build. So I will report back after llvm/clang is build again. Probably next week. :-) Regards, Ronald. From owner-freebsd-current@freebsd.org Thu Mar 11 10:54:48 2021 Return-Path: Delivered-To: freebsd-current@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 D8BF15739F2 for ; Thu, 11 Mar 2021 10:54:48 +0000 (UTC) (envelope-from freqlabs@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dx5S85nTbz4h0b for ; Thu, 11 Mar 2021 10:54:48 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MacBook-Pro.local (69-228-200-148.lightspeed.knvltn.sbcglobal.net [69.228.200.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A3802BE3B for ; Thu, 11 Mar 2021 10:54:48 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: libifconfig_sfp.h does not compile for me To: freebsd-current@freebsd.org References: <1560991455.28.1615452681953@localhost> From: Ryan Moeller Message-ID: Date: Thu, 11 Mar 2021 05:54:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <1560991455.28.1615452681953@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 10:54:48 -0000 On 3/11/21 3:51 AM, Ronald Klop wrote: > Hi, > > This > https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h > includes libifconfig_sfp_tables.h which does not exist. > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, > but no succes. > The last change in these files is a few days ago, am I the only one > with this problem? > The generated files live only in the obj dir, so after cleaning you'll need to rebuild libifconfig (and not clean) before you can build ifconfig again. make -C lib/libifconfig make -C sbin/ifconfig -Ryan From owner-freebsd-current@freebsd.org Thu Mar 11 15:42:58 2021 Return-Path: Delivered-To: freebsd-current@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 681F257996A for ; Thu, 11 Mar 2021 15:42:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660071.outbound.protection.outlook.com [40.107.66.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxCrd3V8kz3DYP; Thu, 11 Mar 2021 15:42:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CrPnGx0ea0v0CdWUcQIBZd6Xjlhtd5SghcRAKDXN0XGaAWxaNMRExlIW+ToKTXoLZisV0qXP/S2u/T3K/Q41G7xXJfeEo+FK2wRYgs4rFb+I5nEK80CLwoaMi1Xgqq0iouzDYaFJL43l7OHpwYl0KRcZmSK+4I333n5ZNXThKqq7xyK3a9naTSRzMuraujKmLY367RnjAZB8v7/NotpABav4Q0WRtqM88/1yDuJP/ex7DiwgHWIxoSH5AwOEP36I3ier4+t9LFyLPTlcGIbA4YLoUWZxUupjk7wy5RaCC1my1DodegBrSPCRjlt5WLihUBqA3NNAXJi4f1eOQ1BbSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ksvkI4oT2BuxxofPB7eO+kYnBsEhhRCWPKgrMB6biO8=; b=mAHt15SmEupCb6ThaDPsyz1mADKycap+2Dlx8Zv9LXmAVMh1yfbIK/cr8NliOF24b9gzG95KLn8WLqN+B8gdefqlbMJ2VTyYCrrxP43BzQ8z71cGFkQBkng/jtxx9N+I7e3ziOiL7Yu+PWB1LDl6R/ZakzqrWoGNUHX85SoAE1E6/FejK3qdH/puduiUesCXsiL2CfH2bpX7GEy1x7U589U1BpFUcJ3vdLtb2ReBfJFJA79E2utqoI9k714K/xoNpDr91RXbhCmj62nz9JqJZ4uYTwmY5hcUPT13pzrAmp1uT21ZTSwNfOwHwmxXTMLxWhF26MDKVyWjGI6nYmEqbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ksvkI4oT2BuxxofPB7eO+kYnBsEhhRCWPKgrMB6biO8=; b=Qu1W9LEayl/XJsB+wpozst/E3fUlb5v36nPFo5xiFt+fD4MWXTE9xDo2YfFK2Fyn3PkE6lMsfloQyRuNwlqHoqZfEUo1NAMaQqIHvVp2mVtxyhxDGmUOFTBC2DHDg1NpRb0IW7gGB2nTLTjb7EV77h5os6mfjC/MI24hVUdI3Yw5XPWUwJckjUFd7+PcICreuKulrX7Eo6tLEiwCBDObQWfa6JoAZaCZzji3OB9QG3jvvF6AabZ8HleUtfeQ8aIBi111vo0nxH3nTvi3grHC8INm8Q9YSjg/YUTsLarFjUKwIozSD0Gvgqj6cmAf1Dc73AhAQIvIOq2fF6+WdUbo2A== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB3688.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.31; Thu, 11 Mar 2021 15:42:55 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::6073:6fc0:5ddf:dc8a%7]) with mapi id 15.20.3890.041; Thu, 11 Mar 2021 15:42:55 +0000 From: Rick Macklem To: Alan Somers , Benjamin Kaduk CC: FreeBSD CURRENT Subject: Re: Getting started with ktls Thread-Topic: Getting started with ktls Thread-Index: AQHXFgwYWcBrnpJjzEOOvEeMKEi/Wap977EAgAAM4QCAACDHgIAACzeAgADCPHs= Date: Thu, 11 Mar 2021 15:42:55 +0000 Message-ID: References: <20210311003136.GM56617@kduck.mit.edu> <20210311031501.GP56617@kduck.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf876a6c-39c3-4642-02da-08d8e4a456bb x-ms-traffictypediagnostic: YQXPR01MB3688: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xcpK8zctCSlM7wAF/YgPpi2FvG2Qmh1Y//G2A5i04Pv99Ex1fR6hI2KL3rdOpGNfJzHwW9tBrKq4wEAgrXY0eayJCB55zL0PlnBqFNzPg/Eda7aihmFzwD0b04edI7H2QE06R0UM+WbyFtsjB1eo5ROCcug0b8oHtZAnvsHHzYzzSxoMAWPq5+ekQw3Arj0e/brlEmjwlujWpzebLmK+m+kd2QVbh0kvvemIPtexFGhN2Eo8IQU3WeHufwPYKKZHkmNrncaVTnSmcSC6RNbKc2yYTEmacgm9NnfoW//gqbb2u4u5anXD2+ivyGBRX0qw+GgswyLmNDIwtyOCJa1bDmopHdSH+a3dIrFotA1SqSJ2VRkEGa4AOGKAFYkCrG/mF2Xiw/d0CKHK+OoJQeq7I4nrd35nEChdPmTppvto0A4egPb1Z1fBJWPmYU7M0FslPei0DXOBPvTnKJx77lOZulzZ+L7Wu1VeilVA1GghmcqiRI2/WYNJWGPmWJoeQuF4PpvvhXFGFCKRaTrcCV0LFUHBLeiGjxzOdFVm1zV+c3V2KvPGwpSACIpR4BTrqTBDuCGY5Rxyp+aVbBnmzbpNjcAe+YXmAuE2J/MY4VaEiQ4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(366004)(39860400002)(136003)(9686003)(5660300002)(55016002)(316002)(786003)(8936002)(91956017)(76116006)(66476007)(8676002)(66446008)(3480700007)(478600001)(4326008)(52536014)(966005)(66946007)(7696005)(110136005)(64756008)(66556008)(2906002)(83380400001)(186003)(86362001)(53546011)(6506007)(33656002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?MhP7E6+2audbhwVktFmXLYFkR6Za+lafMhBwhuBZWQuKhR/Gkgg/1AUOSHTF?= =?us-ascii?Q?sgu6xEjDPMi7W0zS3lwilTpfwwIfRkxa+RgeCDjSJEGh+oVIUwVdkPAGrJ9H?= =?us-ascii?Q?LhB9dJsdig/f4L8z/s1fuPrwbkclwOYEPBgQw5/fCMEGSyb7VsPHU1zplsY9?= =?us-ascii?Q?8eN5Xk6MXHCTRJ4/4kcF7XsQ+qWgs8e7DJZCCltQru99WyZ7cE04ALCWSyav?= =?us-ascii?Q?zaQPVfvpjd3oOcr58PCGzHJ9EEwfEtYcUVUYc55lUIJ+bnV1+kIsoWxYLN40?= =?us-ascii?Q?gLwDL3Qvor5G6VrpfA0qpHr+ODkOcdxsTW7sUZxh5vEyfl8oKpxmwxXzzWNn?= =?us-ascii?Q?7LDTaJu1KrC3rovIg9jlwac6vwtflKKLzLu6iMTuH59SQiraRe98Ci8eZasf?= =?us-ascii?Q?x2kN/UIEIKzy/LPop27EvTJmcvjnk/mQmakmXhjixVZlx/hsSs2JQ/vK0sY9?= =?us-ascii?Q?aHl+NGFd/tM+g1gRoPB27bkDnOymZ0VkCucCHpl+9H6s+NXKlVMl8Xke3q5C?= =?us-ascii?Q?kcIfJ71QKpOEv7tNbaWLJ9UN94CCg6MOWRnXg6AJxWK6Fyw9JTRMlLTqkW8m?= =?us-ascii?Q?WU8I/auG+s8to6ydugxw9UufUWudl9sHqWmiy0uwUPl5rA/JXEkbxD3EPwq9?= =?us-ascii?Q?yxvCOSkI/SRMFKzmhL9Y/SmulHr7lUC0xlKvGwqE5aXQO3t9ahu9qeQ/R7Dm?= =?us-ascii?Q?ZQMxk3Bl2uX0S99OmQ9mw7YcP7OMSRnOLZYnxnqEw1/LpJCkMmr4ItpUe+zu?= =?us-ascii?Q?7+5SCQH4Ptl5jXovZewQNhIdKhMkoZEDIsebNaJY7bIp03Tz2ivfEJqFU1HQ?= =?us-ascii?Q?XRbVSYBdZ8iKLCjqXXJTMGgcES6+T6S/1bncJfvW/lLx1glD3sdFOwGzM37E?= =?us-ascii?Q?60jCmEYT/mxMCcU7nnCfu8MNkPFOjCycuoZ94ks8+Sw4YH+PGK+b7mBg5/nA?= =?us-ascii?Q?rcMD0HMqxpOIZKw5xxk7LvTu01T7RK8WXYpS6yE0dBS21KTTGjH/tXOGHIbt?= =?us-ascii?Q?ntAv+vOp1Th6UCmfU8GqfzhV9ka73QLO0xY8LnuN04zxy2UQkO3vmS3mHrJZ?= =?us-ascii?Q?fnpiVBg3snhyzbFUmTXvpZvP4TtPgv/L04P0yXgs4DVVoKguDkSx8sqRXr0i?= =?us-ascii?Q?1qI2OhcmV7MRvdGqTyZW+yt0j6cH89AAKo4dzka0hgiovbvyYFBMQGWWiZUy?= =?us-ascii?Q?6XxDBoTDxIpeYGQ/xWT6VeWHdINYXJojXCMOHrayg24x1lYUWMN4Fc5LnF8A?= =?us-ascii?Q?+R7Nwgko/DKUOPO29cc29TG6N276i+PmY3j06WRFv2cyup35QTbT4d+PPod3?= =?us-ascii?Q?W0w4pMtugJNHn4A+IeTulj/ifSnCSDifUvWTyVcPRETA8jsI7X+VVxwqyZx0?= =?us-ascii?Q?3yVJ9pw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cf876a6c-39c3-4642-02da-08d8e4a456bb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 15:42:55.2681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PZeLQeWFuoo94omGNIks/xcu7AgKLVlRTIg5a2NeNX7khwiutSDsZJpcnArpuTinC9B6uZEjrmoEwilCZF5jkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3688 X-Rspamd-Queue-Id: 4DxCrd3V8kz3DYP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=Qu1W9LEa; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.71 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.67 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.66.71:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[40.107.66.71:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.71:from]; NEURAL_HAM_SHORT(-0.67)[-0.672]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.71:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 15:42:58 -0000 I'm going to cheat and top post (the discussion looks pretty convoluted). - The kernel must be built with "options KERN_TLS" - OpenSSL must be built with KTLS enabled - These two sysctls need to be set to 1 kern.ipc.tls.enable kern.ipc.mb_use_ext_pgs then it all happens "behind the curtain" in the OpenSSL libraries. To find out if it is enabled, do the following after the handshake. (SSL_connect() or SSL_accept() or ??) ret =3D BIO_get_ktls_send(SSL_get_wbio(ssl)); if (ret !=3D 0) ret =3D BIO_get_ktls_recv(SSL_get_rbio(ssl)); if (ret !=3D 0) /* KTLS enabled for both send and recv. */ The calls return non-zero if it is enabled for that direction. You'll need it to use TLS 1.2 if you want both directions to work at this time. (The code is in usr.sbin/rpc.tlsclntd and usr.sbin/rpc.tlsservd. Much easier to look at than man pages imho.) --> Now you can sosend()/soreceive() on the socket in the kernel. If your data is already in mbufs, then they must be M_EXTPG mbufs. There is a function that copies an mbuf chain into M_EXTPG mbufs, but I can't remember what I called it. rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Alan Somers Sent: Wednesday, March 10, 2021 10:55 PM To: Benjamin Kaduk Cc: FreeBSD CURRENT Subject: Re: Getting started with ktls CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca On Wed, Mar 10, 2021 at 8:15 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 06:17:42PM -0700, Alan Somers wrote: > > On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > > > > > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > > > I'm trying to make ktls work with "zfs send/recv" to substantially > reduce > > > > the CPU utilization of applications like zrepl. But I have a few > > > questions: > > > > > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled b= y > a > > > > successful set of the TCP_TXTLS_ENABLE socket option", but the > "Supported > > > > Libraries" section says "Applications using a supported library > should > > > > generally work with ktls without any changes". These sentences see= m > to > > > be > > > > contradictory. I think it means that the TCP_TXTLS_ENABLE option i= s > > > > necessary, but OpenSSL sets it automatically? > > > > > > Yes, OpenSSL sets it automatically for the builtin socket and > connection > > > BIO classes. Applications using other BIO classes will need to do > things > > > manually (or implement the appropriate _ctrl() parameters for their B= IO > > > class). > > > > > > > * When using OpenSSL, the library will automatically call > setsockopt(_, > > > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > > > application to tell if ktls is enabled on a particular socket or > OpenSSL > > > > session? > > > > > > IIRC the lack of answer for this is part of why upstream OpenSSL > doesn't > > > have specific KTLS tests enabled in the automated test suite. > > > > > > > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reas= on > > why it's not implemented? That might be the easiest way to check for t= he > > ktls status of an individual socket. > > I think that's probably more of a question for jhb than me. I don't know > of a reason why not, but I do know that there is some desire to keep the > functionality that openssl exposes roughly compatible between linux and > FreeBSD KTLS. I don't know whether Linux has something similar. > > > > > > > > > > * From experiment, I can see that OpenSSL attempts to set > > > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why > not? > > > > From reading ktls_start and ossl_statem_server_post_work, it looks > like > > > > maybe a single socket cannot have ktls enabled for both sending and > > > > receiving at the same time. Is that true? > > > > > > No. They just get enabled separately, since change_cipher_state() is > > > called separately for read and write transitions. > > > > > > > Apologies if I'm too ignorant, but what is a transition in SSL-speak? > This > > is my first attempt at any kind of SSL programming. What I know from > > ktrace is that TCP_RXTLS_ENABLE never gets set. > > Sorry! I'm pretty conversant with this stuff (I'm the security area > director that is responsible for the IETF TLS working group) and don't > always target the right level. Basically, for a decent encrypting protoc= ol > you want different encrytion keys for the read and write direction > (whichever peer you are), and the TLS (1.3) handshake has a multi-stage k= ey > hierarchy to try to encrypt as much of it as possible. So, for example, > the client will need to update it's encryption key for reading once it > reads the ServerHello (and before reading the Encrypted Extensions) > message, even though the keys the client uses for writing don't change at > that time. Internally, OpenSSL implements this "transition" of key > material with a change_cipher_state() abstraction, that takes a flags > argument (`which`). The flags indicate which set of keys to update, and > which direction (read or write). So, by my read of the code, what's > *supposed* to happen is that we call: > > if (BIO_set_ktls(bio, &crypto_info, which & SSL3_CC_WRITE)) > > And if SSL3_CC_WRITE is set, that translates to calling BIO_set_ktls() wi= th > an `is_txt` value that evaluates to true; otherwise, `is_txt` is false, > which corresponds to the RX case that you're failing to see happen. > > Just to get the boring stuff out of the way: what version of openssl are > you testing against, and did you verify that OPENSSL_NO_KTLS_RX is not > defined when ktls_start() is being compiled (so that the setsockopt(fd, > IPPROTO_TCP, TCP_RXTLS_ENABLE, .) is compiled in at all)? > > Thanks, > > Ben > I'm using the OpenSSL that's in base in 14.0-CURRENT: 1.1.1j-freebsd . I haven't recompiled the code to check whether OPENSSL_NO_KTLS_RX is defined, but it sure looks like it shouldn't be, based on my reading of the source. -Alan _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 11 17:32:16 2021 Return-Path: Delivered-To: freebsd-current@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 9EB3A57C706 for ; Thu, 11 Mar 2021 17:32:16 +0000 (UTC) (envelope-from pho@holm.cc) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DxGGm3GMdz3NCb for ; Thu, 11 Mar 2021 17:32:16 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.nyi.freebsd.org (Postfix) id 7009057C3B4; Thu, 11 Mar 2021 17:32:16 +0000 (UTC) Delivered-To: current@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 6FC3A57BFF6 for ; Thu, 11 Mar 2021 17:32:16 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxGGl5J9tz3N4b for ; Thu, 11 Mar 2021 17:32:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (unknown [80.208.71.94]) by relay05.pair.com (Postfix) with ESMTP id C0CC41A296D for ; Thu, 11 Mar 2021 12:32:14 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 12BHWDuD097862 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 11 Mar 2021 18:32:13 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 12BHWDXF097861 for current@freebsd.org; Thu, 11 Mar 2021 18:32:13 +0100 (CET) (envelope-from pho) Date: Thu, 11 Mar 2021 18:32:13 +0100 From: Peter Holm To: current@freebsd.org Subject: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177 Message-ID: <20210311173213.GA97802@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4DxGGl5J9tz3N4b X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pho@holm.cc has no SPF policy when checking 216.92.24.67) smtp.mailfrom=pho@holm.cc X-Spamd-Result: default: False [-1.90 / 15.00]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[pho@freebsd.org,pho@holm.cc]; RCVD_IN_DNSWL_LOW(-0.10)[216.92.24.67:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[216.92.24.67:from]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[pho@freebsd.org,pho@holm.cc]; ASN(0.00)[asn:7859, ipnet:216.92.0.0/16, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEFALL_USER(0.00)[pho]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[216.92.24.67:from:127.0.2.255]; DMARC_NA(0.00)[freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:32:16 -0000 I just got this panic: panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 0 time = 1615472733 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e49748b0 vpanic() at vpanic+0x181/frame 0xfffffe00e4974900 panic() at panic+0x43/frame 0xfffffe00e4974960 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974980 malloc() at malloc+0x34/frame 0xfffffe00e49749e0 g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfffffe00e4974a30 softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 softclock() at softclock+0x66/frame 0xfffffe00e4974b20 ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 https://people.freebsd.org/~pho/stress/log/log0078.txt - Peter From owner-freebsd-current@freebsd.org Thu Mar 11 17:56:04 2021 Return-Path: Delivered-To: freebsd-current@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 5C31A57CB6B for ; Thu, 11 Mar 2021 17:56:04 +0000 (UTC) (envelope-from markjdb@gmail.com) 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 4DxGpC53vvz3Q31 for ; Thu, 11 Mar 2021 17:56:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id ABB7557CB6A; Thu, 11 Mar 2021 17:56:03 +0000 (UTC) Delivered-To: current@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 AA59557CEE9 for ; Thu, 11 Mar 2021 17:56:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DxGpC45t3z3Q9x; Thu, 11 Mar 2021 17:56:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72b.google.com with SMTP id t4so21578051qkp.1; Thu, 11 Mar 2021 09:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/oVMe6OxEV+eiGqc+h3GAEMq7nPdNPwTmj6iLbpydgg=; b=F2ka1gdRIE0tpvrskAK80wcTLkuC95FdsUJoAphAt8MNnx+f/EKKyHzvrLmJfGdMA7 OrZ3T9fiocu8hYh/xOVPACjCe9iQ3LaeGWZuBSF1TUAneKKh/d05sE4Z4jFTpUY84enP YIrR9hfSsY5+SayoaUUE1fZ1xLfG1L7HzMWXN37aOXw4nYckY+bulsHqqazbswJDgHOo iL4Kd6NCPT7YofDUPer1hXMxbAguWLq4Dn+TPSQYoPDtnIa18ASwZAaZntsCIdm51S3i LnzkuEbIebBGrpaE4mTvjqUdZ5BEzhaNfCyPGn6uSqbb9BaK/TGu5ifDWW/hFXtjgaJO pV4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=/oVMe6OxEV+eiGqc+h3GAEMq7nPdNPwTmj6iLbpydgg=; b=Bls2YfZ03tpXIfVt0u6152Xfuda32Am59MoYSJTNJhumZPPsugpYI3O0Q8t49fDZpS 0JgrgKK+fi6slK7ZTe8yVh5ego/FGPN3ZAXf4oWnEHzlKZMswsCNv7zg9MQzZjX3n90V j68Vpp1opwvVqTyChaYToqtMpxxVnWIeesmZ+cEdjGBJGSJ2jsVDX79BSvLbG1Izvv2r deB2BEd55CKjAsgUrqDLNiDb2+V0olY6EMwMYHa2Hp56HaYAujNhS9YTRWGhq8hpziUD KHdDKJhO/FNDyyCc0JQ5/dezWltWWZDN65V/y1dM4tLJeMeOqJhQwEi3y9HpxhBeEM6P HG5g== X-Gm-Message-State: AOAM530UQLbHF20G1i6+fgUdkxUgj3yxmkqkyKBVk2oDlLXCw3shs0GV ekt8PVzA8s4CfSIw03e1LcRpKIMrEWNzIOfQ X-Google-Smtp-Source: ABdhPJw+9wbrSlARmGyJ+ASyWwtI5Hpjv9AVE1Id24gIm4LvqbENnMNI6nsPoqrjufKl6FyU12DAxQ== X-Received: by 2002:a37:c16:: with SMTP id 22mr8851563qkm.84.1615485362544; Thu, 11 Mar 2021 09:56:02 -0800 (PST) Received: from nuc ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id p5sm2570745qkj.35.2021.03.11.09.56.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 09:56:02 -0800 (PST) Sender: Mark Johnston Date: Thu, 11 Mar 2021 12:56:02 -0500 From: Mark Johnston To: Peter Holm Cc: current@freebsd.org Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177 Message-ID: References: <20210311173213.GA97802@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210311173213.GA97802@x8.osted.lan> X-Rspamd-Queue-Id: 4DxGpC45t3z3Q9x X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 17:56:04 -0000 On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote: > I just got this panic: > > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 0 > time = 1615472733 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e49748b0 > vpanic() at vpanic+0x181/frame 0xfffffe00e4974900 > panic() at panic+0x43/frame 0xfffffe00e4974960 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974980 > malloc() at malloc+0x34/frame 0xfffffe00e49749e0 > g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfffffe00e4974a30 > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 > softclock() at softclock+0x66/frame 0xfffffe00e4974b20 > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 > > https://people.freebsd.org/~pho/stress/log/log0078.txt Hi Peter, Could you try the patch here? https://reviews.freebsd.org/D29223 From owner-freebsd-current@freebsd.org Thu Mar 11 18:49:13 2021 Return-Path: Delivered-To: freebsd-current@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 C053D5AA030 for ; Thu, 11 Mar 2021 18:49:13 +0000 (UTC) (envelope-from jhb@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxHzY54Xgz3kyM; Thu, 11 Mar 2021 18:49:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 50119F7FD; Thu, 11 Mar 2021 18:49:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Getting started with ktls To: Alan Somers , FreeBSD CURRENT References: From: John Baldwin Message-ID: <24d697e1-1232-7b53-923c-5ba39c6d8d80@FreeBSD.org> Date: Thu, 11 Mar 2021 10:49:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 18:49:13 -0000 On 3/10/21 4:18 PM, Alan Somers wrote: > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > the CPU utilization of applications like zrepl. But I have a few questions: > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > Libraries" section says "Applications using a supported library should > generally work with ktls without any changes". These sentences seem to be > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > necessary, but OpenSSL sets it automatically? Yes, you can do it by hand if you want but you'd have to do all the key exchange by hand as well. > * When using OpenSSL, the library will automatically call setsockopt(_, > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > application to tell if ktls is enabled on a particular socket or OpenSSL > session? BIO_get_ktls_send() and BIO_get_ktls_recv() on the write and read BIO's of the connection, respectively. > * From experiment, I can see that OpenSSL attempts to set > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > From reading ktls_start and ossl_statem_server_post_work, it looks like > maybe a single socket cannot have ktls enabled for both sending and > receiving at the same time. Is that true? Neither FreeBSD nor OpenSSL yet support RX offload on TLS 1.3. If you use TLS 1.2 you will get KTLS in both directions (or if you use TLS 1.1 with TOE offload on a Chelsio T6). -- John Baldwin From owner-freebsd-current@freebsd.org Thu Mar 11 20:36:38 2021 Return-Path: Delivered-To: freebsd-current@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 CBB6B5AC442 for ; Thu, 11 Mar 2021 20:36:38 +0000 (UTC) (envelope-from pho@holm.cc) 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 4DxLMV3yD2z3sQF for ; Thu, 11 Mar 2021 20:36:38 +0000 (UTC) (envelope-from pho@holm.cc) Received: by mailman.nyi.freebsd.org (Postfix) id 859A05AC598; Thu, 11 Mar 2021 20:36:38 +0000 (UTC) Delivered-To: current@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 842F45AC528 for ; Thu, 11 Mar 2021 20:36:38 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxLMV3DCCz3sF1; Thu, 11 Mar 2021 20:36:38 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (unknown [80.208.71.94]) by relay05.pair.com (Postfix) with ESMTP id CEA3E1A27BF; Thu, 11 Mar 2021 15:36:36 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 12BKaaBF099984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 21:36:36 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 12BKaaC2099983; Thu, 11 Mar 2021 21:36:36 +0100 (CET) (envelope-from pho) Date: Thu, 11 Mar 2021 21:36:30 +0100 From: Peter Holm To: Mark Johnston Cc: current@freebsd.org Subject: Re: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177 Message-ID: <20210311203630.GA99255@x8.osted.lan> References: <20210311173213.GA97802@x8.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DxLMV3DCCz3sF1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 20:36:38 -0000 On Thu, Mar 11, 2021 at 12:56:02PM -0500, Mark Johnston wrote: > On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote: > > I just got this panic: > > > > panic: malloc(M_WAITOK) with sleeping prohibited > > cpuid = 0 > > time = 1615472733 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e49748b0 > > vpanic() at vpanic+0x181/frame 0xfffffe00e4974900 > > panic() at panic+0x43/frame 0xfffffe00e4974960 > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e4974980 > > malloc() at malloc+0x34/frame 0xfffffe00e49749e0 > > g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfffffe00e4974a30 > > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfffffe00e4974b00 > > softclock() at softclock+0x66/frame 0xfffffe00e4974b20 > > ithread_loop() at ithread_loop+0x279/frame 0xfffffe00e4974bb0 > > fork_exit() at fork_exit+0x80/frame 0xfffffe00e4974bf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e4974bf0 > > > > https://people.freebsd.org/~pho/stress/log/log0078.txt > > Hi Peter, > > Could you try the patch here? https://reviews.freebsd.org/D29223 This fixed the problem for me. I ran the problem test for an hour and then the rest of the g_mirror tests. No problems seen. - Peter From owner-freebsd-current@freebsd.org Thu Mar 11 22:24:38 2021 Return-Path: Delivered-To: freebsd-current@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 5AAD95AE392 for ; Thu, 11 Mar 2021 22:24:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DxNm53kFXz4TN1 for ; Thu, 11 Mar 2021 22:24:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f180.google.com with SMTP id v14so785881ilj.11 for ; Thu, 11 Mar 2021 14:24:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=cjdqkVu9gJYb1fFpXZ2kaWg3Y4SH534Wcv+nivTe0Mw=; b=IcvqgzUjgYR/9qVo+LdV6vjBfdUATyIZ4LPX47XUfeUeuRUV1DMNm7JAOCFiL8Skab RHQLD4+QhHklAU0MIVcgHz6LjrXVKyJyduyNkHw2yNm7A/wss/f7MoRTLinp9agqa4/X steq9gu7gtREmLrK9BHpsZgCZYS2BeuPmCMo8S2ja6yuv1ovosnTUF2BbXSnrMKgTG0r MAh54iTx1N6MAQV2BIng74zwXYHI73Ie/OmRE1yJMquFXP774Ce/7YbbKNzm8StUQpF5 47roRrrm154o18SfHLkubW0E4fHoIlk4+BJD3QXc+0+OwKRNVJ9b/kmH6oRR37cuXE0O rHpA== X-Gm-Message-State: AOAM533mO4DQclbfUGUJFjC+7GNWtN4gaYZqpBBgK15eIm6MESiI69XR GFbI6RyoH4vwwIBFmUs7RB3ASkrs7h1V+aND0zE= X-Received: by 2002:a92:c690:: with SMTP id o16mt535562ilg.256.1615501476402; Thu, 11 Mar 2021 14:24:36 -0800 (PST) MIME-Version: 1.0 References: <8e9983a4243d158789029ec8b16837b35ca4451a.camel@freebsd.org> In-Reply-To: From: Ed Maste Date: Thu, 11 Mar 2021 17:23:55 -0500 Message-ID: Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DxNm53kFXz4TN1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.180 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.180:from]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.166.180:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.180:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.180:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 22:24:38 -0000 On Mon, 8 Mar 2021 at 16:41, Ed Maste wrote: > > On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > > > I also hate the idea of requiring no space between -I and its related > > value. That seems like a huge POLA violation compared to how virtually > > every other command's options and arguments work. > > On the other hand, -i.ext with no space is compatible with FreeBSD > today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext > works only with FreeBSD and macOS. I'd like to go ahead with a man page update shortly. Even if we do not modify sed, it is valuable to document and describe the compatibility issues with our -i/-I, including the odd way we specify no backup file. On the topic of POLA our -i/-I support was based on perl's in-place editing, except perl uses the optional argument style (-i / -i.bak). I'd also argue that our -i "" is a POLA violation compared to how most other commands work, and has caused significant confusion for folks interested in cross-OS compatibility. If anyone has suggestions or improvements to the proposed man page text I'd appreciate a follow-up here or a comment in the review, https://reviews.freebsd.org/D29128. From owner-freebsd-current@freebsd.org Thu Mar 11 22:55:01 2021 Return-Path: Delivered-To: freebsd-current@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 9877F5AEF09 for ; Thu, 11 Mar 2021 22:55:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DxPR93tJ4z4VmB; Thu, 11 Mar 2021 22:55:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f170.google.com with SMTP id d16so15618882oic.0; Thu, 11 Mar 2021 14:55:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ckrV9/SyQXos2J5iZnodzjC2qsCcXn41sj1CsoLggOI=; b=EW4dylbJQS2lV+LB+KVHVKzn1qunivRh4viCQgBFjKilBRC9GiSuXSpHe6DvGWwXT7 9rivnUoL2yEvsapH/yOmQu2PtFLPLK7O+58GUtXUHpRrxxahlSJQslV4Z5Nq36CNFgQ2 DUpT3K1IBtmmell+gH4DUW6ak0Fj7FPn6QIabkmRQVpZ1MYY0A+Gvaw7rkUqvtEwOqXU Ix9C4uWmVt+xslXNaeJRpBL74fr5N3QKCN0XOhOeXAZow+31oAg973kJ7Kafmui6XC8s 7JxCIboICONi+MyTnZJlNb4rrXL5RIyseIuyTc4PLYLBybFrN4irOw7859B358KoXDUJ LBdg== X-Gm-Message-State: AOAM5334TG2nvcha1Z1EApfcKJOLMQGl4iISTv1ayM7Jlvos1PqcuB/U k+hYKF+u9WCmuaRHdWwEOnXgbwqTqiB/waqYOkGsYRPV9791eg== X-Google-Smtp-Source: ABdhPJyES2sfu5afxAGO6wJLAsfneW8xIQ8KlapF/F6IQWP6FNxBeWeyPxkchTIYlFxgV2iJlb38q+yEGEpimCIZ9+U= X-Received: by 2002:aca:4f0b:: with SMTP id d11mr8178107oib.73.1615503300133; Thu, 11 Mar 2021 14:55:00 -0800 (PST) MIME-Version: 1.0 References: <24d697e1-1232-7b53-923c-5ba39c6d8d80@FreeBSD.org> In-Reply-To: <24d697e1-1232-7b53-923c-5ba39c6d8d80@FreeBSD.org> From: Alan Somers Date: Thu, 11 Mar 2021 15:54:48 -0700 Message-ID: Subject: Re: Getting started with ktls To: John Baldwin , Rick Macklem Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DxPR93tJ4z4VmB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 22:55:01 -0000 On Thu, Mar 11, 2021 at 11:49 AM John Baldwin wrote: > On 3/10/21 4:18 PM, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, you can do it by hand if you want but you'd have to do all the key > exchange by hand as well. > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > BIO_get_ktls_send() and BIO_get_ktls_recv() on the write and read BIO's of > the connection, respectively. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > Neither FreeBSD nor OpenSSL yet support RX offload on TLS 1.3. If you use > TLS 1.2 you will get KTLS in both directions (or if you use TLS 1.1 with > TOE offload on a Chelsio T6). > > -- > John Baldwin > Switching to TLS 1.2 turned out to be key. Once I did that, ... it just worked. I was expecting to need minor changes throughout the kernel and libzfs. However, that wasn't necessary. Here is my proof-of-concept program. So far only the recv path is implemented. I'll probably implement the send path too, but I'm not currently planning to integrate this into any open-source application. Thanks for all the help! https://github.com/asomers/freebsd-src/tree/ktls-zfs/tools/zfs-ktls -Alan From owner-freebsd-current@freebsd.org Fri Mar 12 03:57:39 2021 Return-Path: Delivered-To: freebsd-current@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 E473856C3A4 for ; Fri, 12 Mar 2021 03:57:39 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxX8M16mbz4kmy for ; Fri, 12 Mar 2021 03:57:38 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DxX8K0cvbzDy18 for ; Thu, 11 Mar 2021 19:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615521457; bh=cW4ztJmgAZSs8sj7vh3wy5V71wEOkEbopaJ3Uc9UxdU=; h=Date:From:To:Subject:In-Reply-To:References:From; b=L5A6MZfeqeagJu6mK/h1jBZ3a3WJGeVL8yt6CC2paZAyjIyf+pB7VYdSDColbLgdi 3UGL7uXMpavA1PzwRy4Y/EOkAkrgHMTZXng4tFyCI/efYZgBmxPKsHliz70mqf0x0X n+m9R0jv1iCfjx/ACO0KFSBg2jdlVttUSRLz/6T8= X-Riseup-User-ID: A38A94DAFA82A0D5CA263792A88716ACB5B2EEE114600EC6B8608774B243A02D Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DxX8J6NB0z5vRr for ; Thu, 11 Mar 2021 19:57:36 -0800 (PST) MIME-Version: 1.0 Date: Thu, 11 Mar 2021 19:57:36 -0800 From: Alastair Hogge To: freebsd-current@freebsd.org Subject: Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited) In-Reply-To: References: Message-ID: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxX8M16mbz4kmy X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=L5A6MZfe; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 03:57:39 -0000 Turns out, EFI boot stopped working. The following boots but fails with umass0:6:0: Attached to scbus6 Root mount waiting for: usbus5 CAM panic: malloc(M_WAITOK) with sleeping prohibited Tested with FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-mini-memstick.img OK boot [176/1976] Loading kernel... /boot/kernel/kernel text=0x17f580 text=0xe09440 text=0x6a7ae4 data=0x140 data=0x1c2648+0x43c9b8 syms=[0x8+0x187d28+0x8+0x1a8351] Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb ---<>--- Copyright (c) 1992-2021 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 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 06:32:09 UTC 2021 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1649.98-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff SVM: NP,NRIP,NAsids=8 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7845748736 (7482 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20210105/tbfadt-796) ioapic0: MADT APIC ID 0 != hw id 3 ioapic0 irqs 0-23 Launching APs: 1 Timecounter "TSC" frequency 1649980197 Hz quality 800 random: entropy device external interface WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. kbd1 at kbdmux0 mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020) vtvga0: smbios0: at iomem 0xf0460-0xf047e smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: No AES or SHA support. acpi0: acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xd0000000-0xdfffffff,0xfeb00000-0xfeb3ffff irq 18 at device 1.0 on pci0 vgapci0: Boot video device hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 igb0: mem 0xfe600000-0xfe6fffff,0xfe784000-0xfe787fff irq 16 at device 0.0 on pci1 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 2 RX queues 2 TX queues igb0: Using MSI-X interrupts with 3 vectors igb0: Ethernet address: a0:36:9f:07:d9:58 [103/1976] igb0: netmap queues/slots: TX 2/1024, RX 2/1024 igb1: mem 0xfe500000-0xfe5fffff,0xfe780000-0xfe783fff irq 17 at device 0.1 on pci1 igb1: Using 1024 TX descriptors and 1024 RX descriptors igb1: Using 2 RX queues 2 TX queues igb1: Using MSI-X interrupts with 3 vectors igb1: Ethernet address: a0:36:9f:07:d9:59 igb1: netmap queues/slots: TX 2/1024, RX 2/1024 ahci0: port 0xf140-0xf147,0xf130-0xf133,0xf120-0xf127,0xf110-0xf113,0xf100-0xf10f mem 0xfeb4f000-0xfeb4f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahci0: quirks=0x22000 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ohci0: mem 0xfeb4e000-0xfeb4efff irq 18 at device 18.0 on pci0 usbus0 on ohci0 usbus0: 12Mbps Full Speed USB v1.0 ehci0: mem 0xfeb4d000-0xfeb4d0ff irq 17 at device 18.2 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus1: 480Mbps High Speed USB v2.0 ohci1: mem 0xfeb4c000-0xfeb4cfff irq 18 at device 19.0 on pci0 usbus2 on ohci1 usbus2: 12Mbps Full Speed USB v1.0 ehci1: mem 0xfeb4b000-0xfeb4b0ff irq 17 at device 19.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 usbus3: 480Mbps High Speed USB v2.0 hdac1: mem 0xfeb40000-0xfeb43fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 ohci2: mem 0xfeb4a000-0xfeb4afff irq 18 at device 20.5 on pci0 usbus4 on ohci2 usbus4: 12Mbps Full Speed USB v1.0 pcib3: at device 21.0 on pci0 pci3: on pcib3 pcib4: irq 16 at device 0.0 on pci3 pci4: on pcib4 pci4: at device 4.0 (no driver attached) pcib5: at device 21.2 on pci0 pci5: on pcib5 pcib6: irq 18 at device 0.0 on pci5 pci6: on pcib6 pci6: at device 2.0 (no driver attached) pcib7: at device 21.3 on pci0 pci7: on pcib7 xhci0: mem 0xfe800000-0xfe807fff irq 19 at device 0.0 on pci7 xhci0: 32 bytes context size, 32-bit DMA usbus5 on xhci0 usbus5: 5.0Gbps Super Speed USB v3.0 ohci3: mem 0xfeb49000-0xfeb49fff irq 18 at device 22.0 on pci0 usbus6 on ohci3 usbus6: 12Mbps Full Speed USB v1.0 ehci2: mem 0xfeb48000-0xfeb480ff irq 17 at device 22.2 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci2 usbus7: 480Mbps High Speed USB v2.0 acpi_button0: on acpi0 uart2: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart2: console (115200,n,8,1) orm0: at iomem 0xce800-0xcf7ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. hwpstate0: on cpu0 Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 [30/1976] hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm1: at nid 20 and 24,26 on hdaa1 pcm2: at nid 27 and 25 on hdaa1 pcm3: at nid 30 on hdaa1 pcm4: at nid 17 on hdaa1 WARNING: WITNESS option enabled, expect reduced performance. ugen7.1: at usbus7 ugen6.1: at usbus6 uhub0 on usbus7 uhub1 on usbus6 uhub0: on usbus7 uhub1: on usbus6 ugen4.1: at usbus4 ugen5.1: <0x1b21 XHCI root HUB> at usbus5 uhub2 on usbus4 uhub3 on usbus5 uhub3: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus5 uhub2: on usbus4 ugen2.1: at usbus2 ugen3.1: at usbus3 uhub4 on usbus2 uhub5 on usbus3 uhub5: on usbus3 uhub4: on usbus2 ugen0.1: at usbus0 ugen1.1: at usbus1 uhub6 on usbus0 uhub6: on usbus0 uhub7 on usbus1 uhub7: on usbus1 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Root mount waiting for: CAM usbus0ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number 20442B2AE044 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors) usbus1 usbus2 usbus3 usbus4 usbus5 usbus6 usbus7 uhub2: 2 ports with 2 removable, self powered uhub1: 4 ports with 4 removable, self powered uhub4: 5 ports with 5 removable, self powered uhub6: 5 ports with 5 removable, self powered uhub3: 4 ports with 4 removable, self powered ugen5.2: at usbus5 uhub8 on uhub3 uhub8: on usbus5 Root mount waiting for: usbus1 usbus3 usbus5 usbus7 uhub0: 4 ports with 4 removable, self powered uhub8: 4 ports with 4 removable, self powered uhub5: 5 ports with 5 removable, self powered uhub7: 5 ports with 5 removable, self powered ugen7.2: at usbus7 umass0 on uhub0 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:6:0: Attached to scbus6 Root mount waiting for: usbus5 CAM panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 0 time = 4 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0081dcf5f0 vpanic() at vpanic+0x181/frame 0xfffffe0081dcf640 panic() at panic+0x43/frame 0xfffffe0081dcf6a0 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe0081dcf6c0 malloc() at malloc+0x34/frame 0xfffffe0081dcf720 disk_alloc() at disk_alloc+0x1c/frame 0xfffffe0081dcf740 daregister() at daregister+0x3f4/frame 0xfffffe0081dcf9c0 cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe0081dcfa90 daasync() at daasync+0x2c2/frame 0xfffffe0081dcfb00 xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfffffe0081dcfb50 xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe0081dcfc60 xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe0081dcfca0 xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe0081dcfcf0 fork_exit() at fork_exit+0x80/frame 0xfffffe0081dcfd30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0081dcfd30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic [ thread pid 6 tid 100043 ] Stopped at kdb_enter+0x37: movq $0,0x128bbde(%rip) db> bt Tracing pid 6 tid 100043 td 0xfffffe0010b40700 kdb_enter() at kdb_enter+0x37/frame 0xfffffe0081dcf5f0 vpanic() at vpanic+0x1b2/frame 0xfffffe0081dcf640 panic() at panic+0x43/frame 0xfffffe0081dcf6a0 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe0081dcf6c0 malloc() at malloc+0x34/frame 0xfffffe0081dcf720 disk_alloc() at disk_alloc+0x1c/frame 0xfffffe0081dcf740 daregister() at daregister+0x3f4/frame 0xfffffe0081dcf9c0 cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe0081dcfa90 daasync() at daasync+0x2c2/frame 0xfffffe0081dcfb00 xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xfffffe0081dcfb50 xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe0081dcfc60 xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe0081dcfca0 xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe0081dcfcf0 fork_exit() at fork_exit+0x80/frame 0xfffffe0081dcfd30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0081dcfd30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db> From owner-freebsd-current@freebsd.org Fri Mar 12 04:04:30 2021 Return-Path: Delivered-To: freebsd-current@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 8DD8956D2B2 for ; Fri, 12 Mar 2021 04:04:30 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxXJF3tQpz4lZP for ; Fri, 12 Mar 2021 04:04:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 12C44L39005481; Fri, 12 Mar 2021 04:04:21 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 12C44LS6005480; Thu, 11 Mar 2021 20:04:21 -0800 (PST) (envelope-from david) Date: Thu, 11 Mar 2021 20:04:21 -0800 From: David Wolfskill To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited) Message-ID: Mail-Followup-To: David Wolfskill , Alastair Hogge , freebsd-current@freebsd.org References: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vTq3HNOqMxyiF/CM" Content-Disposition: inline In-Reply-To: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> X-Rspamd-Queue-Id: 4DxXJF3tQpz4lZP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-5.07 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[catwhisker.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.67)[-0.670]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 04:04:30 -0000 --vTq3HNOqMxyiF/CM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: > Turns out, EFI boot stopped working. The following boots but fails with > ...=20 > umass0: SCSI over Bulk-Only; quirks =3D 0x4001 > umass0:6:0: Attached to scbus6 > Root mount waiting for: usbus5 CAM > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid =3D 0 > time =3D 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe0081dcf5f0 > vpanic() at vpanic+0x181/frame 0xfffffe0081dcf640 > panic() at panic+0x43/frame 0xfffffe0081dcf6a0 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe0081dcf6c0 > malloc() at malloc+0x34/frame 0xfffffe0081dcf720 > disk_alloc() at disk_alloc+0x1c/frame 0xfffffe0081dcf740 > daregister() at daregister+0x3f4/frame 0xfffffe0081dcf9c0 > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe0081dcfa90 > daasync() at daasync+0x2c2/frame 0xfffffe0081dcfb00 > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > 0xfffffe0081dcfb50 > xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe0081dcfc60 > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe0081dcfca0 > xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe0081dcfcf0 > fork_exit() at fork_exit+0x80/frame 0xfffffe0081dcfd30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0081dcfd30 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > .... You may find the change that's in https://reviews.freebsd.org/D29210 helps -- the trace looks similar to what I saw, and it has worked for me. Note that I only saw the panic while running a kernel with INVARIANTS. Peace, david --=20 David H. Wolfskill david@catwhisker.org That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)? Ever Republican vote in Congress was against it. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --vTq3HNOqMxyiF/CM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAmBK6EVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcm1lwgA0pcQkZ105ZmOyNmaxj3TEq9zVW+iYeWm/5vadsKQSdnHOHkYFfS3ULFS j8WkN93AEgYNWD5KC4jjx3qb4Cew8PabBsw1nMJ9/EGHcwlLzvWLwfXqmaAW5kfO fA/wajAOce1Bbq2qWafCiiAT5hmMF1vZoTn+2ERL0fV9GowSv2VFP3AkVTT1k5fr ozxKcC2fZIZiiMvXghrXAduAeFpolYNxU76z5cWQ4hzPohWyfDLEKsFt0vdfhH8x HjNUY2y0A4gBIlwBGyaslevYvegF61d0nH44jplSoxWOHv2lVh1eFQjbbdJ6O2ml vDCaQKJhkb6z0EtVI3o0IJ4rXyS3yQ== =B2Cl -----END PGP SIGNATURE----- --vTq3HNOqMxyiF/CM-- From owner-freebsd-current@freebsd.org Fri Mar 12 04:08:27 2021 Return-Path: Delivered-To: freebsd-current@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 DC65656D2AC for ; Fri, 12 Mar 2021 04:08:27 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxXNq19kmz4mH1 for ; Fri, 12 Mar 2021 04:08:26 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DxXNn3Y2QzDy3L for ; Thu, 11 Mar 2021 20:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615522105; bh=2VaRGSFiJJsP36roS48eHL9Iif/VwlpWUuq85gYN/l8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YRuhEWPj6B2mO9C3Cs2wbsnsaUv1MB0HLHyvRvsmTSJtC1EbK1WdZGYDr13yCb3v0 PPjRd+a3LVmYo4qo+5G5TOfOAYAUy8tCq78NpBhV1dlIbcuQL/mhDt+043/IxoHuiw /4XcUfL9CpBGTJA37vufI13u5tGKRJS0kP/8nCqc= X-Riseup-User-ID: 5A90DFA3CC4289FAC023FBDC098A6E4629257D99DD1292EE2D8F896260B297C9 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DxXNn2Mp7z5vNM; Thu, 11 Mar 2021 20:08:25 -0800 (PST) MIME-Version: 1.0 Date: Thu, 11 Mar 2021 20:08:25 -0800 From: Alastair Hogge To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited) In-Reply-To: References: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> Message-ID: <75c4ededf209275342c62b1c339bf809@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxXNq19kmz4mH1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=YRuhEWPj; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 04:08:27 -0000 On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfffffe0081dcf640 >> panic() at panic+0x43/frame 0xfffffe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfffffe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfffffe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfffffe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfffffe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfffffe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfffffe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> .... > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Fantastic! Thanks for those pointers, I will try imp's fix after the current build finishes. To health, Alastair From owner-freebsd-current@freebsd.org Fri Mar 12 07:20:26 2021 Return-Path: Delivered-To: freebsd-current@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 6573E5709A0 for ; Fri, 12 Mar 2021 07:20:26 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxcfK2s23z4vWJ for ; Fri, 12 Mar 2021 07:20:25 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4Dxcf73l0jzDySX for ; Thu, 11 Mar 2021 23:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615533623; bh=6v2MrN0hFKroKXznjhDvbGjlX3ApPlA4YSVOUZRhrCI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ccNrVCGF3ZcuA7GYkNDYP70Lcym2iRYOcpp8eb6TUBRBugx6SvtDU/eBx1rtT/77X aszWBmNzxCKslmy9RrRZ0D/hf/HB+SMSjLXao92Hc8pc+5rN9gwmQi5HJrBtEgPivR yGfb/1h5jkUO9YKo+GCJbtudKg/2BHKtr4qfuYAQ= X-Riseup-User-ID: F88B8888D77E3ED58434CCA4CDF7E7EAD60D92B28B5722A114C90DDAC955CA8B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4Dxcf72Z34z1yQs; Thu, 11 Mar 2021 23:20:15 -0800 (PST) MIME-Version: 1.0 Date: Thu, 11 Mar 2021 23:20:15 -0800 From: Alastair Hogge To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited) In-Reply-To: References: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> Message-ID: <9ec378ec3287b7c8978fa5c27579af16@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxcfK2s23z4vWJ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=ccNrVCGF; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 07:20:26 -0000 On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfffffe0081dcf640 >> panic() at panic+0x43/frame 0xfffffe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfffffe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfffffe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfffffe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfffffe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfffffe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfffffe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> .... > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Patch works; tested with INVARIANTS only. Thanks all. To good health, Alastair From owner-freebsd-current@freebsd.org Fri Mar 12 07:21:29 2021 Return-Path: Delivered-To: freebsd-current@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 6F2C35708DC for ; Fri, 12 Mar 2021 07:21:29 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxcgX67VQz4vkP for ; Fri, 12 Mar 2021 07:21:28 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DxcgW6jGHzDyRK for ; Thu, 11 Mar 2021 23:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1615533687; bh=ABYAvNO1EHxVKChB6e3wkmtB2NLtBCQMNGhdusFgM8U=; h=Date:From:To:Subject:In-Reply-To:References:From; b=YlV7H21J93jb6f2q89AIide/voVuJ0RQ+3vFCxNlwwI3ngmWLi3jlrd1LZroGI9CJ h35bhKfeabmmonVObvvG5XLgIG/ZskCpwHe7NIdfoS4iMPb+uO5t29VUJpvrn4QP9R VjIlMaFiKaKrTCxOxdRjlS0COn8iyR/MPsJVl7hI= X-Riseup-User-ID: 81F9985715261E193D052E6EEABE2FA0A1446888988F48A291CBE96A62CCD2AB Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4DxcgW5GD5z1y6h for ; Thu, 11 Mar 2021 23:21:27 -0800 (PST) MIME-Version: 1.0 Date: Thu, 11 Mar 2021 23:21:27 -0800 From: Alastair Hogge To: freebsd-current@freebsd.org Subject: Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited) In-Reply-To: <9ec378ec3287b7c8978fa5c27579af16@riseup.net> References: <3db68a3f1944fa9e099796ff45f1b1a2@riseup.net> <9ec378ec3287b7c8978fa5c27579af16@riseup.net> Message-ID: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxcgX67VQz4vkP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=YlV7H21J; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[riseup.net:+]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.252.153.129:from]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; SPAMHAUS_ZRD(0.00)[198.252.153.129:from:127.0.2.255]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 07:21:29 -0000 Tested on main-n245400-e75eac2cb81 From owner-freebsd-current@freebsd.org Fri Mar 12 18:24:28 2021 Return-Path: Delivered-To: freebsd-current@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 759D65A8E2F; Fri, 12 Mar 2021 18:24:28 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (mail.xzibition.com [52.11.127.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DxvNW4G0rz4gW9; Fri, 12 Mar 2021 18:24:27 +0000 (UTC) (envelope-from bryan-lists@shatow.net) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 10F1219F70; Fri, 12 Mar 2021 18:24:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id jDwy_3VBYXAG; Fri, 12 Mar 2021 18:24:13 +0000 (UTC) Subject: Re: Rationalizing sed -i/-I (in-place editing) argument handling DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com D9DA719F66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shatow.net; s=mxc204805312015; t=1615573453; bh=B4zjcqIrHAN23n0XH7HAE9S15ooWmwJW2m1jRGacKRA=; h=Subject:To:References:From:Date:In-Reply-To; b=WdgVuKlO+WoxXgshcOBBDzeTAUfuQzfVfKp2lf3qXsRtCUCBO1P2Wu2lXd84PtzB3 0SYWsYrD/a4ZCS0MFPI07/QqAX/8CFegrh0mwvXQU29tJ1wknJxSIeENaMMW/hrrkZ 5bnWCxOo94/yXhSGWmyqXBzQaeWCTm9rC0DPOtEGriDQ4gYlgFU7gZgB8ckyQ7hN6o o/qK5AYvzHxLcVz4M8nB1fgViKv0Nhfrx0bWBWoaUHQ+JvVdGES9USySJ4sLCBu0t2 Fy7kYBa01MKYQw2yDpMxfm66B2ylZfADZaHq50mlhWrkFTNYzXXleHCc8ba02ZTUMr yDyn2p6tNtJhg== To: Ed Maste , FreeBSD Hackers , FreeBSD Current References: From: Bryan Drewery Message-ID: Date: Fri, 12 Mar 2021 10:24:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxvNW4G0rz4gW9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shatow.net header.s=mxc204805312015 header.b=WdgVuKlO; dmarc=pass (policy=none) header.from=shatow.net; spf=pass (mx1.freebsd.org: domain of bryan-lists@shatow.net designates 52.11.127.251 as permitted sender) smtp.mailfrom=bryan-lists@shatow.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[52.11.127.251:from]; R_DKIM_ALLOW(-0.20)[shatow.net:s=mxc204805312015]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[52.11.127.251:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[shatow.net:+]; DMARC_POLICY_ALLOW(-0.50)[shatow.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.10.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 18:24:28 -0000 On 3/8/2021 12:13 PM, Ed Maste wrote: > 5. Retire the special case for -I "". Just to be clear, we are not suggesting removing compat for -i '' right? -- Regards, Bryan Drewery From owner-freebsd-current@freebsd.org Sat Mar 13 00:11:13 2021 Return-Path: Delivered-To: freebsd-current@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 681425B17F1; Sat, 13 Mar 2021 00:11:13 +0000 (UTC) (envelope-from gjb@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dy34d2CWVz3KvL; Sat, 13 Mar 2021 00:11:13 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1615594273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=ZKcM9VX91av0PaPoa6eBHbhWreTHmk8uHX1plMJwKfI=; b=Fsy5bJrcuqdqaRyHp8NsP1Zk2K8TClg4ubsEUAUL3GvGcnkJGRj1oh4v55no8S0e33ME3q 7Gq5ltOwNqkX7VoAHx20PAunKx62vqqOXGFkGeeAS4nFqeiL+XeRiegocWh6QwJ7o1Gbch kBX+QCwM8PMoUOS776oJWoBURWQ3+tw3zibpNHLXlKHpLOfDet64oeUlXebW/ymMQEXkxV ZP1jyfc8ts8JIIrL7T78K9n0iYdDDejG4ulZuX75UB3COcdLYkp0CUMvVW2xTz0dQEimzc 97muW8suba4hV9D9epcyf0hPX2mHqGFeyCtM/CYO3d4/xgZhqEMbO6wcWG/ccg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id D0D5A15202; Sat, 13 Mar 2021 00:11:12 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 13 Mar 2021 00:11:10 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-snapshots@freebsd.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 13.0-RC2 Now Available Message-ID: <20210313001110.GP92054@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1615594273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=ZKcM9VX91av0PaPoa6eBHbhWreTHmk8uHX1plMJwKfI=; b=jLy7KAx0fhgmWc3A/6G2q8tr3V+eAZQSCMLzBwP7mOd6E323hNfeH3nLqVZNO4lfSPWC/C UGYMh6xLa8qwI7YDkNjIMNg7uyS1KLrbPyaWzV/86e07wzUpojE0AnF2r+sBy0u7QOBigg loCB6jdfv57VmRay94ov84+Jzq6dTjLx/LFKlSqMBiJA1jmeIrvAnTKj4gpxJ3NUJpmEsz tqKHzWU7MloJSVCzuOUIGSLDGNzcsgFD5v/cqkAhpC8qkNewfAy/rfTe+aVQsLgQcstId3 C6cFjeaeqm7jBC+LWZagRTOR7NT4BIZV54HzLQEvP+7S/iYBvBlw+uH0a7RRMQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1615594273; a=rsa-sha256; cv=none; b=TTXdN/4dfJlt5NSB4EHhPa1Lxs+itUlxc1qVY7M8WrPtDFG6J+w79tsx3JZDSd4T0l03e+ NvZ6upcJABHbDdY/dnbl3WI+JxHWACIFyRjoT/JTf49eAAsHWpAJq+IF5aOw0+dLl3rQfn XWN49ROsfyLc28742oeWK/oO6t8ff96TLy2sHkwMdR0RdFSON5yQLA9ZEyHg8LU+BT1SMF w0CuiuBr48oMc58O1KkBQOVEHh7Q38oRHKfxwftnuaUIWECbBP7K6vE+3c1z1/NnnvpcKO 7Q1HcTYzeOQjnZOO49oCJ3V+xWNrtwzpomE/200fEPaYInYuOEVsBU05z2xVWQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 00:11:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The second RC build of the 13.0-RELEASE release cycle is now available. Installation images are available for: o 13.0-RC2 amd64 GENERIC o 13.0-RC2 i386 GENERIC o 13.0-RC2 powerpc GENERIC o 13.0-RC2 powerpc64 GENERIC64 o 13.0-RC2 powerpc64le GENERIC64LE o 13.0-RC2 powerpcspe MPC85XXSPE o 13.0-RC2 armv6 RPI-B o 13.0-RC2 armv7 GENERICSD o 13.0-RC2 aarch64 GENERIC o 13.0-RC2 aarch64 RPI o 13.0-RC2 aarch64 PINE64 o 13.0-RC2 aarch64 PINE64-LTS o 13.0-RC2 aarch64 PINEBOOK o 13.0-RC2 aarch64 ROCK64 o 13.0-RC2 aarch64 ROCKPRO64 o 13.0-RC2 riscv64 GENERIC o 13.0-RC2 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use Git to do a source based update of an existing system, use the "releng/13.0" branch. A summary of changes since 13.0-RC1 includes: o Miscellaneous loader fixes. o Fixes to if_wg(4) have been added. o The growfs(8) utility has been updated to allow operating on read/write filesystems. o Several ZFS fixes. o Several TCP fixes. o The bc(1) utility has been updated to version 3.3.3. o An arm64 AES-XTS regression has been fixed. o A fix for VLAN hardware filtering in ixl(4) has been fixed. o The ice(4) driver has been updated to version 0.28.1-k. A list of changes since 12.2-RELEASE is available in the releng/13.0 release notes: https://www.freebsd.org/releases/13.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 13.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. BASIC-CI images can be found at: https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC2/ === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: af-south-1 region: ami-075584d5b26000fb4 eu-north-1 region: ami-01bc9e74704057f84 ap-south-1 region: ami-0482a65377ea03c8e eu-west-3 region: ami-089013cf606c3cef0 eu-west-2 region: ami-074ec752c433390e3 eu-south-1 region: ami-0fa2b27853fc18f1c eu-west-1 region: ami-08e5c85eec858fe9c ap-northeast-3 region: ami-0cd8f0feba156c1b8 ap-northeast-2 region: ami-0f407f222ea20777f me-south-1 region: ami-0752247a4f4b7f1c5 ap-northeast-1 region: ami-062b0b3b7c9be696d sa-east-1 region: ami-07ef18e5aa3e4b373 ca-central-1 region: ami-064103ca013b74ee3 ap-east-1 region: ami-0c86834fdbbd272aa ap-southeast-1 region: ami-07791074bad9e30f5 ap-southeast-2 region: ami-0f9d5ee9afd3c9166 eu-central-1 region: ami-036260c2bf5ffaab0 us-east-1 region: ami-06df356662db1c1c0 us-east-2 region: ami-0b81e7e91a55d8a44 us-west-1 region: ami-0293a117e598e5d79 us-west-2 region: ami-047216a21fe30e18f FreeBSD/aarch64 EC2 AMIs are available in the following regions: af-south-1 region: ami-0f24d089d2383ba32 eu-north-1 region: ami-06368e4701f2a8732 ap-south-1 region: ami-0186094ac26aaab14 eu-west-3 region: ami-0297345102a342c4c eu-west-2 region: ami-02ad08dcf7eb46940 eu-south-1 region: ami-02c217018c44903b0 eu-west-1 region: ami-0a13bb7013c52966d ap-northeast-3 region: ami-0f3492211bdf21572 ap-northeast-2 region: ami-0c4cb857f15dbcded me-south-1 region: ami-039cf70b6a94eb021 ap-northeast-1 region: ami-0a0f327c3011be6ed sa-east-1 region: ami-0a648f8fcf60c6550 ca-central-1 region: ami-0d1c97dccc085cc92 ap-east-1 region: ami-09728de5d6589231f ap-southeast-1 region: ami-0f7557b725c8ea743 ap-southeast-2 region: ami-0e9dd1ed03dbbe2cd eu-central-1 region: ami-0c15e0a54e52ade93 us-east-1 region: ami-0a148ecd7853db173 us-east-2 region: ami-027783264e56f740e us-west-1 region: ami-014c3ef86fde1528c us-west-2 region: ami-075720b038e6e7c0c === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-13.0-RC2 % vagrant up === Upgrading === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 13.0-RC2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 11.x. Alternatively, the user can install misc/compat11x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 13.0-RC2 amd64 GENERIC: SHA512 (FreeBSD-13.0-RC2-amd64-bootonly.iso) = 54a73543cafc861c90ff1a72aa6c921c307d2af76800079aa1191bad89339076a9680a430c939d0d4d052888bbedcabe7aa8f2bcdb5e228a4704460351513d56 SHA512 (FreeBSD-13.0-RC2-amd64-bootonly.iso.xz) = 530811c49445a0985036863f88d03e4753cf6ebd19452f39d6230fbf582ff6ac4d5d90817cc5af22bf85dc85683302e12f154e6827f272e51e727773f7336f25 SHA512 (FreeBSD-13.0-RC2-amd64-disc1.iso) = 7414ee64ba2fe3192cf4b4e9daa93925433bc04074e869d71696c086eb7d0691478ea359cf3471f7c626bf2834c10ed1910f0d5bc41a83b12fe128c13dd31bdc SHA512 (FreeBSD-13.0-RC2-amd64-disc1.iso.xz) = 99a876e2b2c1d1c6752ceadafc70a6745ad8e9136526d23826ce5922b628ca76ba27159c74feea174b6cec2f5b06d48829f639967522eb6196725086f66b2f6d SHA512 (FreeBSD-13.0-RC2-amd64-dvd1.iso) = 5cd73bccc7d653760bc816e3922d74b034c4652d58a94bb6bba2cf53c261ea19b5f54acf7023170c6af79b07d0fdc618b5529ecdbd86d047e3a56cabdf49176f SHA512 (FreeBSD-13.0-RC2-amd64-dvd1.iso.xz) = 55026fe23d2ab135bbd88096cfde02310a3ec2ecebed0625b896924bca8c028bdd56d6d05178a613cf9e479ad36dcc29f3cbb988df65a63e43e2c16b822fc2d4 SHA512 (FreeBSD-13.0-RC2-amd64-memstick.img) = 850c82bb99435e8467b8e54893b4e39ee3d304797e69b795938b3e00e2e59b8baedf65f86e40e14a6631d80bf669417169d14ddaf7ae0bed69a20a3cb3563bdf SHA512 (FreeBSD-13.0-RC2-amd64-memstick.img.xz) = 6500796c500dbfac1290db846e1d8882091a23b055cb034bf85fbc329183c70539db5f2b525468e53d8f023bd4cbd70c866e73ae8e2ed2934df1327d29386e4b SHA512 (FreeBSD-13.0-RC2-amd64-mini-memstick.img) = 1ad8816a50c5276dffa0be73d0fc753a5d72e4ef988daeeaefb47902a91e3dd672355ba2788bbb6559de4ab8201e9ef6c1af9001d2c04214e316082174270e21 SHA512 (FreeBSD-13.0-RC2-amd64-mini-memstick.img.xz) = fe5f1fb95910f71fb638caa06dcaaf16d06ae99fe2f11738deba9dc3afb58edda0d1af8c89c503c11a2057a028ec200d2c2f7aa5d2f64f230bcdf751a2dccda3 SHA256 (FreeBSD-13.0-RC2-amd64-bootonly.iso) = 58e43e0b092a268edf8533c9e1cebc41b58e69c7058cf563618ac455052daffd SHA256 (FreeBSD-13.0-RC2-amd64-bootonly.iso.xz) = 48a4ea3b60215fd095004832dff7f6195361be29014b6779b73803029da9ac98 SHA256 (FreeBSD-13.0-RC2-amd64-disc1.iso) = ab244a85e7acbadd5ea609934809f549302e911a68d6abfb784e4b83a6905cef SHA256 (FreeBSD-13.0-RC2-amd64-disc1.iso.xz) = 46ee6d455f60579e9ce3bfed19bc1abce6fb3ea4d1fbd9615e31a0f1ae7a6fd1 SHA256 (FreeBSD-13.0-RC2-amd64-dvd1.iso) = 371c629b2e1ffda6be07788e102b47d59ad3bf463ccd5ced24009d323fda1380 SHA256 (FreeBSD-13.0-RC2-amd64-dvd1.iso.xz) = d1c7beaaee2836ea88016af7db227f014cbdd07a311bae75da87ba013b0c71e9 SHA256 (FreeBSD-13.0-RC2-amd64-memstick.img) = b3433a608ade02ba4e5f7e20bde351bf5d803272e86b0102e3859026c6df1a69 SHA256 (FreeBSD-13.0-RC2-amd64-memstick.img.xz) = 9aad5873f1f4215570dab24abfca20d10f3bff91a48be76fb65768a738ee777e SHA256 (FreeBSD-13.0-RC2-amd64-mini-memstick.img) = 4571db996294b101f20b7f5ed4c6adf32fd96a87023baffe866ebf8d8032ad67 SHA256 (FreeBSD-13.0-RC2-amd64-mini-memstick.img.xz) = 3b8dd166da52e7d623d0109a240677173c580e17cb23d8e0c3458fb5d858e3ae o 13.0-RC2 i386 GENERIC: SHA512 (FreeBSD-13.0-RC2-i386-bootonly.iso) = 1ba5c7a299b7f2eda6229059263d44bb16e9a073ac7ac4e8412362d5a4778faf771949b8874825f429741b50418b142d3fa92b8c7d3ef51e37572eeecac31b28 SHA512 (FreeBSD-13.0-RC2-i386-bootonly.iso.xz) = 6443f547d670e4f58ba4828b1c38519063226438812679b97a90a8da7eb56c921364ee305d2bab885d9728437425d4172bd79f464833b00ba4313731b4ef39bf SHA512 (FreeBSD-13.0-RC2-i386-disc1.iso) = 0350e7505c042a4ce05dc192a7d2c38377371748f8ac3242e99c8684d3b6fd079198d13de996a08da6ea84fbfeb6c2bd3499d737b4abfa1ba83a5773b82e692e SHA512 (FreeBSD-13.0-RC2-i386-disc1.iso.xz) = a57aedf285f7b73652f72c68eb6c4816299f0ad92426e7ea51cde37e5a60a23f7d64f891444ffad679e3d581293c42b8e9250f77677ff883118a9491b37859c9 SHA512 (FreeBSD-13.0-RC2-i386-dvd1.iso) = b055fbcb611ed8ab5f50795b2db888e5108b7decff8ee0c54d7a6cd1c01f4228622962dbeb9578a3d9a2740ade342abbc4e294ea338e31f69e62c60fc3366b5d SHA512 (FreeBSD-13.0-RC2-i386-dvd1.iso.xz) = f0ec4d1b1dad9738542d1814fd1c96493482c0d0e23897ae899f7cffb11204eb709a7dd804f9423764ebd88f5db6f063e355eb6833b008acc8bfe3b1343b85e0 SHA512 (FreeBSD-13.0-RC2-i386-memstick.img) = 87102d85e592cf068720cde39a6e8844337bbc27ce50775e6715e5f90c53f2865ba17990c0f1d29f785d47235c1a18493184a8af73aedc7271743c5e9a38af27 SHA512 (FreeBSD-13.0-RC2-i386-memstick.img.xz) = 85053cbce49b99d8494ec80571bc5c4821510d7b4dfb3139b1af266323350bd7e78f7b2bfa09a92c7760c838e815df50f514b5bfaaae6a675cbfb10604ca52e3 SHA512 (FreeBSD-13.0-RC2-i386-mini-memstick.img) = 738f99a3e16e38bbcaecc1908ee548dab9d500d84921c3e6cc6b907717f31452929126080e15f385f7bca57b3e68ca09d5694642e5c256d9fd94bff12ee5b7a5 SHA512 (FreeBSD-13.0-RC2-i386-mini-memstick.img.xz) = c1136fe3f94b8d8ae8537260d3f09485d1284ab827f5889ef065cb9b780fde59474e8b80e5b801084b656d00bd40cac4e850528980b7a07565f98cca9365a951 SHA256 (FreeBSD-13.0-RC2-i386-bootonly.iso) = e8bf5eba663773299e1c39ce1c8727638d8ef53b153956a433e7da2b2c1dfcfd SHA256 (FreeBSD-13.0-RC2-i386-bootonly.iso.xz) = 756d1d9befc0a62bc77cae8695ae296f5945d6b151cff52e0ce8109dad475978 SHA256 (FreeBSD-13.0-RC2-i386-disc1.iso) = e473a649f8d385078a7f8385092d09628b14f83586c6ab7e3d504a8e3ac1bda5 SHA256 (FreeBSD-13.0-RC2-i386-disc1.iso.xz) = ba3dfd63f4a9a62077c849a0b6cd7b7c2516729a81c9e6fd3f75cead37a99ee0 SHA256 (FreeBSD-13.0-RC2-i386-dvd1.iso) = be42a76332ef59654a0f76e32b04f1b5cd8a8e7fa033e003d7986cfad1951c50 SHA256 (FreeBSD-13.0-RC2-i386-dvd1.iso.xz) = 158dfaa9f4406cf5c8ed432601cd2f9ca3c51b03eb1f8c158ff432dd34572328 SHA256 (FreeBSD-13.0-RC2-i386-memstick.img) = 3ccab85ca211a8900c29a0fc662f45e9986d1b8a01154ec289671a3d1069acf8 SHA256 (FreeBSD-13.0-RC2-i386-memstick.img.xz) = aa6bfacb77432b2c74528df15c188b8526fc13e7574853fd69074ed9b829f4df SHA256 (FreeBSD-13.0-RC2-i386-mini-memstick.img) = 33174aa878182832f6aa544be93237e4a804bf793053e0bfa19496afb1e714e5 SHA256 (FreeBSD-13.0-RC2-i386-mini-memstick.img.xz) = 09f9074c66be05dedc1fc9499b6a6d5da56435fba01861a5a18d59c26aa91880 o 13.0-RC2 powerpc GENERIC: SHA512 (FreeBSD-13.0-RC2-powerpc-bootonly.iso) = d930e203dcd48bda4dee8348a9e79d49cd40a86f67c5cf17ce948ab147e75a66d912994032920aa5231670b4b0561b71da19a09895f34435a8a9e26a896a3263 SHA512 (FreeBSD-13.0-RC2-powerpc-bootonly.iso.xz) = 80926ab6063e71e39485dbf6d2f4b3b1eabe2faa7011ddfdb2a9ac489deedd42f76619c3539e2c4afe2d1ae551c42c57cd0cf454fcc07c9d41aa489a49ea110b SHA512 (FreeBSD-13.0-RC2-powerpc-disc1.iso) = 07cfdbd1d041a73b520381903d5cb5c477bd8a6fd318d6405405638b4603a3679fb3c95a4a6d7763fd1395d2907837225a00c92f4babab9fc82a032c4b26260e SHA512 (FreeBSD-13.0-RC2-powerpc-disc1.iso.xz) = 1debf604d33ec0e1695dc31463988bbc87221744b11e595e2e3ebf817b5b4144ca87a9eb781c4e2fb946277a40cdb9411797b1d1e45b8e9e38a856a9dd44945e SHA512 (FreeBSD-13.0-RC2-powerpc-dvd1.iso) = 174e0ed0cf24e02f4ff2d89a3c4b00bf1ed2a8a815449df2efe05572835fc7f2e503e28ecc53a6f588ee6f9e27968b59d45fff255ab62e5c6db2c5f25436bd86 SHA512 (FreeBSD-13.0-RC2-powerpc-dvd1.iso.xz) = 98ccaa4d325a93e14edcbad10f88fc70742e216724fa0f6adcc40f98041113add5654313132a47d811a46b977a7a948edcc120fbc48742804295f61c96bf3fe3 SHA512 (FreeBSD-13.0-RC2-powerpc-memstick.img) = d1319c86b348804ed442a61d0277982157a8ab9d67336e55891a3852355de28f81f2f0eaa66b408b413802832f16f118a83dbe1280792345bb62cb9ee83abf66 SHA512 (FreeBSD-13.0-RC2-powerpc-memstick.img.xz) = 6c624758bd42e56206d07a0197ad51f6344445b1016c55c5db26ffd7f7b16e6e85377b7c8b9fb4c9fc782b3ec074ca0d0b62a6ed885773aea38240896b28c899 SHA512 (FreeBSD-13.0-RC2-powerpc-mini-memstick.img) = 3a09c380ce88749344f5c253b9c05207712981d53a6c16ff61f55f8fcbf3cf3e5e428d52c4ced9b914c3983a6eebb0aeb7d853a56d8466800d5d247b2376ce07 SHA512 (FreeBSD-13.0-RC2-powerpc-mini-memstick.img.xz) = fdf15c091404d20da8de47b269ff0de06ec82095ea4b2360414dab7091e01a0034e22bb7e4e77e540dd0b09dc0c8f4da6594e36ef086a107b3dbc67a06c018fe SHA256 (FreeBSD-13.0-RC2-powerpc-bootonly.iso) = 8573da6dfcc28ef51742f477b5a57a616f54d1e7e6dfb4e98bf01d3e5af63f91 SHA256 (FreeBSD-13.0-RC2-powerpc-bootonly.iso.xz) = 92853fac30c594f87cbea4eccdfa28dbe9a5cb6d5202ebc45076626c9f978a34 SHA256 (FreeBSD-13.0-RC2-powerpc-disc1.iso) = cbb6bcab279d0fb0118ff39e0cbfebb59cfe1e14d241a5e749266a14e444f447 SHA256 (FreeBSD-13.0-RC2-powerpc-disc1.iso.xz) = 6981e01022ade54cafd9e7378fc36928a01d182b2e92d3ab175229bdbecd2e96 SHA256 (FreeBSD-13.0-RC2-powerpc-dvd1.iso) = fc1d59afa1d6d006b22aeacdbd621d85295fc98152a8a898f9912fe5f4b05c7b SHA256 (FreeBSD-13.0-RC2-powerpc-dvd1.iso.xz) = f6683b3730e6e7fcd33f98390daf09bbd90afd062817ea0a304e11022f53d352 SHA256 (FreeBSD-13.0-RC2-powerpc-memstick.img) = 63907e8004e6fbcedb002be8797f5c87b014ca4f773b5f631fe9420055c59ef3 SHA256 (FreeBSD-13.0-RC2-powerpc-memstick.img.xz) = c1bad1a63a015c66ae463008f36881c9015d6b04a1e9d13d5aa098b1cd7ed247 SHA256 (FreeBSD-13.0-RC2-powerpc-mini-memstick.img) = bd705ed8b7f9cea0d6316b2c69200986ad084ea3923065c38586a2d2836882f6 SHA256 (FreeBSD-13.0-RC2-powerpc-mini-memstick.img.xz) = a77f2d7a77c14aeb500f442e43138a707a379b9a4eafa4f67673463da3e7e71c o 13.0-RC2 powerpc64 GENERIC64: SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-bootonly.iso) = ed4192f27bae4b11fc0eaa3e1dddd182acb12bbc157355d2ffd1f2db81d61a960201aab30cb7a61530b22bfc43a724fb34ecc9dcea32f522daddc1803dd3e9ea SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-bootonly.iso.xz) = 228741e31a653671431bd223e736014f917a9dcfa68ceb90c741214ef5a2e6b1c7203ef4eed6d75abd16c9814663cc75d91bcb9ef645cd0f5eed190cc03be847 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-disc1.iso) = e2c7a71ae205c83a4ca6bf02eb80424a99fd81847c8149c51cfea399ce363fa1bfa374d59ce09cae2c4a52939aa345f6e05f7ebc7c76d97c498fdcd771e18713 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-disc1.iso.xz) = 9991de3768ed5e9c06ad82dc5de526ad7efe79a75649ee037d48fde634afcd1aea6f3488ba03c57d9ce06d66a1adb2b8e0a7401116f73269dd4bcaaf4e7bf03d SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-dvd1.iso) = f05b751d4943c6f5ddfe258bfac21206d5ffebf436f8658f047f3b755c737a595acd5aab2089f8f42aa58993d1738bf6d0174d1a53843fe36a9deb36f75d129f SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-dvd1.iso.xz) = cc8b1a83f67b001b819ec90048ceb73e7deac8e4ecced15c32606b53f8af65b3a47296d67cbe37e5e3e0be9bbd6a032fa64574aa9b55ca7665c0cbd7982cb3d5 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-memstick.img) = e74474f60c809fb1904c42ffdf6d8a122ad5aa38688fe5ba508732cc59439a8bf96ef9322545b606b261d0a27976470f2ead74c4e714e044c6b0750b8e31c78c SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-memstick.img.xz) = 88a958362add33d74624bf9605bf81d89259b39c9521510cc6dc3c1e250fcc629e3fe945b211a30c77ca966c0ced8ebd6e5a154f3d6c92fa10da236ed0f10187 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-mini-memstick.img) = c87da67cc2cd563caaf2042c4693682adf289365208ee5085ff70592ab748b5241bc4caf967eb9d1bb053aa5fc8689ac7b84617f73af4cd84439a77bf9aa3fc6 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64-mini-memstick.img.xz) = 3d9a3987a12f9f2c51385feb09b065f6f1fcb9fd97b4cbdb122ae117d179de561f23ddfe250706211bc9b93ed4c1e3d42b34b156b0b6631a340d298394790945 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-bootonly.iso) = 0df9703ba834f543b4463a67f1f26f4581d04e6a4b6eccc1684e7e42f547b11c SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-bootonly.iso.xz) = 3b6e6cb6945ef8573341ce46cdcbe33e9e8c63e1d33c6f6cc1fad08ea456a458 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-disc1.iso) = 734b4fcb73ea1ec28543c323c1f7a5dc20aa2b1657628654600fbfcf0f8e04b3 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-disc1.iso.xz) = 1963eb9cc40cce1b6eb67b345c62212de7e1b7a4114dda77c97eadad31ddc906 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-dvd1.iso) = 1e3375fa76d2646cb0f54c906aabd86c092a917d37437e8e0056b30357d271da SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-dvd1.iso.xz) = fd0588dc4d90913a0562c49bae31b863ed0532e849dadd44095727790f746872 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-memstick.img) = c7857f21882b92c13dee8c4a64429b7535c79ee149eb7dda34607eda0844142c SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-memstick.img.xz) = 9855ccca699274f8c33073878d771ae54fc7931cb3a1eba1beb6a75d8cb7177e SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-mini-memstick.img) = e0e56da0ad6de77f7d8721deb98950e7ff4330a3b52a02ff072d029a96f3494c SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64-mini-memstick.img.xz) = 999edbd64584b4817f2d709c8186c0fbf9c853daa859ebd6c09034f67be6cdfe o 13.0-RC2 powerpc64le GENERIC64LE: SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-bootonly.iso) = 534c56211dcc1b5431ced1eb9613d05b54b6520a8b48e4c23452b450878870bf80b14814f25ea1841cabece0ed8e530aa34064779990953490e6b5a59b29518a SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-bootonly.iso.xz) = a5b976b496fc910f2de0efcd5420b08735506ed00df1c7e0e65c5c365b4163fad74ca14963c0bf912a14f31938d9f2a56e6813aae60ec0edb431bd933bf9b15e SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-disc1.iso) = ed4ea18ecdfada067dd966ae324622cdc47aa9ee68026f0906e78080947c6b991bec700619ea6e0364e13bc4f2f6f863e3f483a00a400c0bc8fc77e8dd78cca4 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-disc1.iso.xz) = 0242dd853b93e1b646d92abdb2e3d25d2270da3aeb32d2596b530855f64d598529744e145059d6cd4e8aa9b7713414dbb189f57e6ee68a3c18414087f1d119c3 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-dvd1.iso) = 0b3ed6c55ac6556aaaa112b2b31fd2c7cdf987b945e7a9979c82a4e6c4a74b8c94a1cec219b9eed196e02327f08c14ab77afe8dcec187b03a1b57c7c4d587cfe SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-dvd1.iso.xz) = e923ee67b96a95cf99e6a22478271a3bf411f8818496e09e9b4e732f65dd43f4395f441b62ff3cd2976de8c2600adf86032f080926db38910664364d79ddd6ac SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-memstick.img) = a0e5caedfcf3a01a2c1cbb6a5a318bcd4c5f73f4b6fc5d18f892866686216f8fa6222047bc938555e2bdfb11b0e9cb8e27ad9e103dc3955c20ae6317e6dc13ff SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-memstick.img.xz) = 5e948e9a4d07c16abc1257338b522d753743e4379c0fdab1c688de595e69fc9354380d94f9de065a105024ad7ca97f488b9980d566a1890569ad3c1b1041efeb SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-mini-memstick.img) = b086dc1d5c05dabdaeb29cd34a2702c62d90aa8de32a0ab0640abdfb56bb524392690b6d81e4dc322e30ff78be84f1be732ad9e9c10768113092a95eb15c4fdc SHA512 (FreeBSD-13.0-RC2-powerpc-powerpc64le-mini-memstick.img.xz) = fe5c7bbc77d8fbf7299c439c40532b8f7b30a20c3914b1a7cf22e21e185892d4a10bc61592922261496a8bae287236599b7f27d9125f4a115c8d456226bd618d SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-bootonly.iso) = 727433629962d3ce37a006bf17368aa9c3c34f10e8669869440410be6bc62be5 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-bootonly.iso.xz) = a4aa1ebb4418dc51fdeeee3f9a2bab02577b7022a5eab8338922286b7cb7ebe5 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-disc1.iso) = d78cdbd371494c5379582b8ce321a37bc9a984c9db4ecbf39de31d68ecfcd86f SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-disc1.iso.xz) = 7649cf94c43bff294d0efb8a9173f82a7a4bf5f1f0f4faeb8a0c9b80e7445bda SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-dvd1.iso) = 16e5ece2d2deef79213de2d8c0de264156e37a98ec54e711426a5d33bfb37b80 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-dvd1.iso.xz) = 4716d4d5055bde9dfaf9b6a0c3e3acde50e7845c81276ad87a5378492221c218 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-memstick.img) = 68d2beb5bd80c773fface906bba0c941b8e5984fb5146e16d605b5c227b9fbd8 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-memstick.img.xz) = 293b3d3dc97c0338bc37bd83149ca178b1126ab14d86ba68a5d41b51f04135dd SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-mini-memstick.img) = 0dec7fafe00977ba79e27448c59b4b6f6d150bd19ab3490f7e234d89de91cda4 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpc64le-mini-memstick.img.xz) = 3628eeda95e898965337acba9b046cc3b9cee752581653281d460e60e040de16 o 13.0-RC2 powerpcspe MPC85XXSPE: SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-bootonly.iso) = ad926a3153a2752dacfc9f9e9928c2dacdbd1b3332e10ebd2743adc387299c5e27d1d97b5f1f6cb98e615f8c3cadb9bb99ad656d9dcb5952b63c5403ef928996 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-bootonly.iso.xz) = 8d4500fe3491dbf9cb8e5ab64ac45c8729a99c339bfeced8594d354f8f8c03631d7d8c3c343ee3837e53340be66bd19f347572ce1f8244cb877e13eb0bc41a21 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-disc1.iso) = 4086601126196f121625c6b607335491aad9a7649044333e83c34bc4256a10861c442ff2cd1f517222c2885f6c63bb91bf0890ed128c9264709d1c83475e6e54 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-disc1.iso.xz) = 62f97cf5fb70503de1b67526b028191e9bb4836d4cda20d8168a6a53395e258b5c7530403e07c3aa7d14e366dedbd393f82506d645b26b632c7e38733ddce52d SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-dvd1.iso) = 57b3cbae99b372743ac85cf4500a83ce64aa97931944cdeb7a180ae5f234476088f42d3a88de17e80ce6d0bd9a7251ab30dffd2c7c31b86ef026a5bcee197eaf SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-dvd1.iso.xz) = f3cf5d85dbe915c3ee2eac89ffbf184558e12335021176261d6f2ebe62d0c55b002584eb4da282f2c2d250a57f8068463cbcf4fa99a2787932f14cae1faf5f7d SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-memstick.img) = 1d7df97c2e835eea844c49ed7a0d047b4f7e1d5a85e6b41aad90bb3631cb9e50e51002f0d0b0714a0f56f00860cfb4a965ebfe6693a5e37dad5fad34da54ee60 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-memstick.img.xz) = d84d530029234bb80e848b392a83152b64502e1518f94b8aa8797a88e3830cabebac3887d1232653e0ce521962ac3857c4dbea91aa4d789ff6180a74c18db02a SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-mini-memstick.img) = 4d2a35751ef8e17b0a776ab875bb962edf30debce3e6df27c26b3fea3cb3a4447871b9efca5a053699e138b68764974e8e77eaaec7e5b6ef44e86d91185a4b23 SHA512 (FreeBSD-13.0-RC2-powerpc-powerpcspe-mini-memstick.img.xz) = 762babec0c953137e5d7fc76f625e1f136b860e7cc2bd2457ed35dbbd747e4a31a5ae5b9e8171e1547aab71e13da35db7fd5d93dc5069ab603916ed0a160a301 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-bootonly.iso) = 3257c9b09dee563f21056cccb87ba2bd888ec4079440d903d48cecd196f16731 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-bootonly.iso.xz) = 146df7e141c3aee283cf22b774fe753ec9d36c60396c6c73ec8fe17d24bc3b30 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-disc1.iso) = c00a0be5943a2f49bcb1494d457240b13d78ac47f41a3dafb928fbade790bdd0 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-disc1.iso.xz) = f044544cdc8d1adac718b08b6d3915665b533850f8c1d0941568a9076817a126 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-dvd1.iso) = 445258ea6f5912e79ebbedcb0453b7d21b33adac81f72129e0889ef0cbfe3f50 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-dvd1.iso.xz) = 1379a9a668bdfc6e50a5bd2be28d69437d73a1c6a857a16ae5f1a80d8adf3ba8 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-memstick.img) = ca8c69f4c5db8e5337514058e73cfc21c4bee413a7bd707363b51a2d867451f8 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-memstick.img.xz) = 9a64d11dd09b86292bc0ec9cf9bf30e029e303be7eac763fbeb24bb2e2d4b920 SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-mini-memstick.img) = 25acf936313d4468464915be0bb9fc260cb2621ce1f5d4d7fdaf8c72ad6baf8b SHA256 (FreeBSD-13.0-RC2-powerpc-powerpcspe-mini-memstick.img.xz) = 4e8bd1fd810faac7e1c7aebe0a020fb7cda337ce5a01b9a1f2be6ebf82040040 o 13.0-RC2 armv6 RPI-B: SHA512 (FreeBSD-13.0-RC2-arm-armv6-RPI-B.img.xz) = fa0c63a19aef94fb8ded49ce1c0fd1c7f1148c47ae54bab91e67599dfa8d5982ee9b2e129a108b40cb0ff590ef263c1178e8421c90b7b998cc2daddaa3968bca SHA256 (FreeBSD-13.0-RC2-arm-armv6-RPI-B.img.xz) = 2fcb4b129c30b2b17701c8619838967a0c2ec53326c2a3509f551b89dcf59771 o 13.0-RC2 armv7 GENERICSD: SHA512 (FreeBSD-13.0-RC2-arm-armv7-GENERICSD.img.xz) = 01d65a3b02892a9f94733532556322600ce2b9320d0c4226df4dc4f225803a9675074c805be728e9b3a09d207e82f2065f86c9b14fabca18a55247ec830c715a SHA256 (FreeBSD-13.0-RC2-arm-armv7-GENERICSD.img.xz) = 2d68bbae1e34a911a36f0a519aefce4d20b9fd85de6df33ff06dd1fbb8803ec5 o 13.0-RC2 aarch64 GENERIC: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-bootonly.iso) = d8e64e798c208fe64354ef2eb23260dc62f9363064fd29eb2c4a93500cd472fcae0d7e323dee06990f6e67c4e3f105c7e737dcd7ba4670dd59afda1b1249f3f8 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-bootonly.iso.xz) = 283351025fbc622e9cffd28ee06083a16a72313a96e3c5bd562246e077b3e0c0f44a99b8cf1e811066d1f8a3456cecb771f2b254fd15089833708c3e5890439e SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-disc1.iso) = beccb93e45470e2d16ba9ef659415939d5bb55ceaeea74c9a06f39025704cfc447b20adbe34ec2dc2b356d9a36f92984b20a84a6133c019ae22e11aa52c9b144 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-disc1.iso.xz) = 8603bf93dff8787da247462ebdec8330b520ce1a69270f9536735e6270ff70abd0bcdbedc8e4669464cf75a8358c7dc947f1b2eca345c01eab792c57ec5f3bdd SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-dvd1.iso) = 9a850474bf7e75c0b4911e17acd58a2527156c471883e573122ffc1622990112f2583c4549ff68bd96e19460bf02c0cc7841de0428720a3a63ba287ae2460ce4 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-dvd1.iso.xz) = da33b882e02142ceebc4ca74b6e4bc11cb34c102b3455cf9341a645c55f4aad6ce3ea7caf5c5d22321dac75eb7d8b88b050345060bb3205e651072f5e88b916a SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-memstick.img) = cf928599246c6d807dae56f976a8239be58dac59e46aa13fcf24cdb311e88a9e627c97cc1980505a736057d89846bed00368b5789703d4ee2e41c0c1f534432f SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-memstick.img.xz) = 81d9b60e2f5c561aa22ed7a325eca87b0c80a9f0600f15c97f33c4cf270f437f68d5eb93e25bf52c76594c37fc4bc4365d4e210f9a15c525a21c9c686635ea88 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-mini-memstick.img) = 6f6cdd67aebb0db5d918db0d3fc1bf2eec653c6dfafdd70a216233344be73814b81c23e437873266c81ce2fe03186026b490ff98fc76501dd5cc020d96eeedbf SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-mini-memstick.img.xz) = e32d21ad8b2344159656b9e13b6b87d8ffd96958507bf673190bcf4e0338592071816dfc37994d9791052ba2840886371c1776b2d2944daaf395a25c2e25d1e7 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-bootonly.iso) = 7c6fefd776c87c416eaff9e5b3fd37109e139c093375041b1f85ac59c0bcb6c2 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-bootonly.iso.xz) = 31a9dc6858fbdb1905b4e964b5a09482d3466e95533d40d2d554ee825f95f22a SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-disc1.iso) = 6f448a1fd18ee42383eeb11302bd9186d2a831642c289fdd9da98ae46dfcedce SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-disc1.iso.xz) = d871e45a7e8a72cb38eb011eb121b13687b2381ca939534d6badf7e0176d4e12 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-dvd1.iso) = dc51f1c30acdfa621303c994a7c19c994e6478913e3bf603410baf6cdd47416a SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-dvd1.iso.xz) = a1ee44e3371599c97e8ea06a5a273f3bbe13525442e79db8f586dc6c01db1882 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-memstick.img) = a64cbe77c5df96b051f61da27b754ee39a3e529323bce0c56b3af7a8fcd59f5d SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-memstick.img.xz) = 09b133a2a059ef30f036f001d5147164cc0893ff2144af694fbafda504284129 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-mini-memstick.img) = 26eb7dd67106908ae50a7330fcd59aadd32d8f54499f47f00960006373e02f0b SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-mini-memstick.img.xz) = 41a8b1d3693dfda4c6488f8a2fb2672b06dd5d1bf072508eb068fcda465ea51a o 13.0-RC2 aarch64 RPI: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-RPI.img.xz) = 0606410160b549030d4d76e087ea94d03627832bab41a14a9df3d2bf8498d4e55d26a544f7aa928bfa576ec2fa45e3430a62ee7495dfe8d71158187aa79f8088 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-RPI.img.xz) = e7832f2e66583357d4f89b89127acea4eb9767807c105b8acefa68fd45ff0d7e o 13.0-RC2 aarch64 PINE64: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-PINE64.img.xz) = 773594a9806436038e95ebc0b71f3e022cf1201bd6700a3fcb5ee0fa498bab735b04900e9c166bbf80d8dcb2bd3098cb257e45ef789c4bb9d37610aa3749c305 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-PINE64.img.xz) = ac9a5340f208efdfba4ac02765326e4087537408c02b81a39b9ed8dd381e7f70 o 13.0-RC2 aarch64 PINE64-LTS: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-PINE64-LTS.img.xz) = bd2ba8b020b17f1935ed560f9020a3ba634e7822ef83c950934dd64eda9180aab6a9d42fe6782c09aa68bbb21aa9406a8b091271bc33ee2d4a5a95e942993ae7 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-PINE64-LTS.img.xz) = 4ac9f161cb7bde4e8ef01d20c2ed7163da48927d6e85d3c8ad477370d16c4cd4 o 13.0-RC2 aarch64 PINEBOOK: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-PINEBOOK.img.xz) = 40e71ac98457451664f75930f61ddaf1f2a990743410c0556c15b9493925da39c50a76a737b6083334fad5b432a241d7cfb7b2258a78c2577ea0aa86f23d9c4e SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-PINEBOOK.img.xz) = acb6dc0784a635fc8c06f1b4e9a818c0036755ea77c8b99d1e42c0efe35e9667 o 13.0-RC2 aarch64 ROCK64: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-ROCK64.img.xz) = b58e344d03e002cd9518b9e69b6721acba3aa16cf0d44bfc7183ac8e69ccebdcaed3fe99cd08ae1df819535abdce9d58673b707e3fb5355b1b117c950161b948 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-ROCK64.img.xz) = 5ea9a59f1d4cfd62cb15a2a40dc2c77b88919e724aa5328e7fef639e713f7c7a o 13.0-RC2 aarch64 ROCKPRO64: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64-ROCKPRO64.img.xz) = 4c4aa8151ddc9a27758e37e86cfde0f833f787c63fe7b5154783b446278d029bb1e7d2740277cfdf8966c6c6ed7d6c0cb5f9b4a86060d2caec2785024807ac13 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64-ROCKPRO64.img.xz) = cee744f39642898f03ab9b137cfb6edda9f63424767ca10587799a1c8eedf5a7 o 13.0-RC2 riscv64 GENERIC: SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-bootonly.iso) = c1be998a5bb2c93480e3fdfa5eeebc3a20ca3ca5b4870067d091ee73d70f3a1b97bd7a56248c54d0d17df2df80fdddcd1c00bd377e0eb101bb4f4bf818b2bbca SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-bootonly.iso.xz) = d6524505078de5b90d570b9ae433bb3b44aadc01e7e2eda90921b24e5fe1e91ad9a4f1ac6cc22adfb8448f61bf502063f7181941aaef925fa19587165ff141a4 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-disc1.iso) = 8264285d9980f60083d94aad094f07e106b87448e53742dc74428432827413dd190d48d35c158f738fbb26b3a7d450ec94229726163f66f96f561bfa0c589ba0 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-disc1.iso.xz) = 2ff3974505884c0a11da855a0ae1ba99041d32253d0a4f58ab841f36b4227f23853a55b4d9f42f35b9ede11536a8b7b06b9a9bdd120088c0b5a1b13e8ec29b47 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-dvd1.iso) = 8e4513b4b60c64830ac1eaac4f0deed023feb03b3d9991bfc084fa451db899ed646148b0b01fa838724d599ae64591e3b617b7843bc61ae2cfaf37dac1e47e19 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-dvd1.iso.xz) = 366606b578621c0a939aafd7708890d0ef4208e64a59cc6a5f467f1bec138954b2e3fa476860a4abee235252989369184d0d73fb46bd0d669a5017bfc7550666 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-memstick.img) = 66a495b0008febb9b6d11aeedd093d81894b73ded1239281b872a96838ad41ec3834e8aca7b68ede2752bf3843ee7fe40435faa8e6bc1ca877a5af6dfa5f60e4 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-memstick.img.xz) = d23e9240f85b3d77a86add1bcd5fe16aafe29e163c26c54fa0ebe971b324721bb9e2d6d02bdc1f553c61960adaf0ed8179ba4cc181f3b1ce69a57834d8e034df SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-mini-memstick.img) = 5431f62be580829d324d7ab1cffaeef1f929fc3ba96f15ae2b29eb7bd89a583e21b4ece7b2544af8f664bc0e9c8f3d7a5880a528eb2854180b54396345acc4e9 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-mini-memstick.img.xz) = 73ed71f9bd031d1c9fa715d750b77570967e7af02782a1924dab98256ebfa292c9619a766c818325e868366e4be01789b4ca646d00444dd87d15b75ac5670197 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-bootonly.iso) = 4293e27d8490015ac84f72f7ff76d555bbb4a743c1583dab1e757971866646bd SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-bootonly.iso.xz) = 8abcf9ed54d1e3e0411c6a77f13a2c9e1c1a4a25e5e174472290a82feeb464e3 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-disc1.iso) = ef5990b171849675abc6251c41ae9915185d6a0750f8a619a4c6f7804066dbad SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-disc1.iso.xz) = 5295efb9854a292a838d286323452eb08548965773af5e25170f2208e4a99944 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-dvd1.iso) = 460b99600f094e7163525d906669d63485be24010756ac87d73d43bc791f2b0e SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-dvd1.iso.xz) = 74eac73be6226da03b0bf93be7bdf088fbd9315af0d5d51a0bc62dbc487f221b SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-memstick.img) = fb2de2dde6f2bc845ab2ea9af032d7cfac9266d89845ea43effd586c700bd9ac SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-memstick.img.xz) = 9dccf3ebf5b003bcf2cdb83e311a64a494b2793cfedba30e6cd80f07b8a00eb3 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-mini-memstick.img) = 15367e76249ee5ca71dfa8f80ed20d9f91cd56f24c0c7853fb531d1e217bf724 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-mini-memstick.img.xz) = 71c9aecfeb3c9647a0710db3786130f7a14d73a62a6ea2951f3fc659b5a21f46 o 13.0-RC2 riscv64 GENERICSD: SHA512 (FreeBSD-13.0-RC2-riscv-riscv64-GENERICSD.img.xz) = 766d55d0b13801d71f5a55c3df909d5d1704111228756d646952f8851580f1dcd88a87098c5fd6004b15abb2c52ddd0387568214e0bb3fa931ae4863e506169c SHA256 (FreeBSD-13.0-RC2-riscv-riscv64-GENERICSD.img.xz) = b2d1c96de2df8d7a9e90ee98212b0792a006544c767c5f17a1ce317de7107bd0 == VM IMAGE CHECKSUMS == o 13.0-RC2 amd64: SHA512 (FreeBSD-13.0-RC2-amd64.qcow2.xz) = eb8b3ba2178e167d4d52c7ff36e64bb2cd357470cfeda8b080ba70c6c040f30c97a11524293785f198d6cf53f9311fc1f054812087f630600bb76cc4501aebbb SHA512 (FreeBSD-13.0-RC2-amd64.raw.xz) = 92f3277786446ac633caad0558e05217f92369d1a0a76d698adca1524672cbe57dadea2569c0a093b3d259c1dfc4337ebabb55fe6adcded615bb26812df9116a SHA512 (FreeBSD-13.0-RC2-amd64.vhd.xz) = 2a0e943f3ba3ba24c8bf893f3999d6f967b955cdf12e156a40d2723c118053596a1dfb0a89b257c4b1f2f0b8bebbaec5618a5d81f958d9573dae683dde964ed3 SHA512 (FreeBSD-13.0-RC2-amd64.vmdk.xz) = 8879a8b608cce9bf1a95110a1464d1acae9371cc9caabb3e2c13e8884ca9b84fb91d1cae121f53704c089f0922467c49ee9e21896a399ec172baf7abf7c73e6b SHA256 (FreeBSD-13.0-RC2-amd64.qcow2.xz) = aa854ab8ec61514ab82973a703a91fe845daf7effff9596f588e26c5c4857248 SHA256 (FreeBSD-13.0-RC2-amd64.raw.xz) = 45ca10786b5631b1b27252a0696ccca74b891834e7fcbb244c80627e5f44e8bc SHA256 (FreeBSD-13.0-RC2-amd64.vhd.xz) = 2da3f3010bdc9c8f54fcfe506fb8ed8b27a569581a43f681280ef3a277313aa6 SHA256 (FreeBSD-13.0-RC2-amd64.vmdk.xz) = 51e5c70801b9be8fe36683d65bbb33695005557b42938d489d0cd430689c75f9 o 13.0-RC2 i386: SHA512 (FreeBSD-13.0-RC2-i386.qcow2.xz) = c93b3106b631ddd48672c53152611dff4ef78dd20f70afbf963a5e5c1f6595f40a20d6dec47ab4fd1089347a03c8094d12117d12a2946c16c0386f0114247009 SHA512 (FreeBSD-13.0-RC2-i386.raw.xz) = fe09498cc8836a271bb11777b8b15a33ab1085b907482350a85f457fe97d98ee7492640029a92d379c89a8297be7dff3ed00490a2437252b623b7a148c16fae9 SHA512 (FreeBSD-13.0-RC2-i386.vhd.xz) = 415ba863db8d018c57629d9dd16a28cc4aed14587a70f81fa01529e9e98e2233c677f6ab994bdf6b01d205b3293da248786f5b3b3c0f535af18ebf53993f4d19 SHA512 (FreeBSD-13.0-RC2-i386.vmdk.xz) = 376990553adcbba7a148aadef23e206454f4b8c4ff3c1b0ade416dc180e3d7d5d1ec4d15e8a5af714363a5e818804e729c69adf503c93ab65a7d54f8317bfd4e SHA256 (FreeBSD-13.0-RC2-i386.qcow2.xz) = be1917ee2f52043938fe0c9b7d017a58bbdb8e76162b16a67fd6bcc6bab81225 SHA256 (FreeBSD-13.0-RC2-i386.raw.xz) = 2b20462bd9cdf31a535696029f4afa2082fdd7ce2db7e577760be75e5444ce1a SHA256 (FreeBSD-13.0-RC2-i386.vhd.xz) = 84f51f7835d2a647c8b02ac9b482f2f84bc0dfeea43498419e05490d638ce843 SHA256 (FreeBSD-13.0-RC2-i386.vmdk.xz) = 303dcba1e14a96f7ac562290f6c4bca916c432d5f79893226b20efecdecf80f9 o 13.0-RC2 aarch64: SHA512 (FreeBSD-13.0-RC2-arm64-aarch64.qcow2.xz) = 4c50efa22d57006178a513772d944e788a899316f7fa43ee221ab5ec06ea4e71a8101fc41fa6c2dd94a2eeaa1dc36ff35b176477330b1858e89405865204685f SHA512 (FreeBSD-13.0-RC2-arm64-aarch64.raw.xz) = 76383bac800d589f575d54872a746a858ffdc3bf35d0663c9faac0d1f341675e0c31877263c98177b9430aafabddb4d47e063a48b77bee2fb4565407404b6bc3 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64.vhd.xz) = 61b0fa96f60b562bd99af1b9bbaf8a9b31400982001f139ae55eed806af2b75a8469d00cfba25ac16fcdcc4b1ad559a7061e78286a5df1264ce1964904e3d7b8 SHA512 (FreeBSD-13.0-RC2-arm64-aarch64.vmdk.xz) = 5733b32e1d5eb4ec8ea976522cd41e2fce2ad5e1ea300f0c3ecd1a6247ca87f74c456f67f64edb90f6490a9cefbda70b67f6997f4a9a021b80d2b92a3f88e784 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64.qcow2.xz) = 21a26d066a2673ffc3b1b29a3718bc4d47d82f56e6030dc607c2868cbdb24af1 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64.raw.xz) = 891ed284dd66b382210925818f633b2f840d3f572d84a410a8961af829d63454 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64.vhd.xz) = cca8b0b0736cc9e3af5364f9e9dad7b2756dcc7747283ef2f0a28d8bace66950 SHA256 (FreeBSD-13.0-RC2-arm64-aarch64.vmdk.xz) = 2781f5f0dea92964431d7af3cb74fef4837c5d3207aeca21296d9baf2b048cf2 o 13.0-RC2 riscv64: SHA512 (FreeBSD-13.0-RC2-riscv-riscv64.qcow2.xz) = 886c9aa8206b536f9734db1cfcec6b7a1f5adcb5410df0f8d7031547dc9f8e27e51400c3793523be9f3827b8c4cd1cdef57f3623faf6144d31a36d81c5cd62f6 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64.raw.xz) = dc63e5a94a1129466bbd1702e986b712ebe900d859605c822fd24ad20365240747877d1bf1c9449e93ad985f31eb56feef3cc5206b1c3f2b8653893c76e151c9 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64.vhd.xz) = 1ea1f2bc8f65d4fe57c844dde06bf604c45f2ee91f0b0d9207f2b7e68dfe509b2f2fc75b348ab1b651b6e34be156cf4f1e947069e92e76b79d599451474a3956 SHA512 (FreeBSD-13.0-RC2-riscv-riscv64.vmdk.xz) = 40d2db849f854966eb9f5a4b4f2d221c1cc4e255268bac2edd37f8f83b7144fd25607683a4e127e932de431a698f97a5ee01086d091fdaa07c1c51842076961b SHA256 (FreeBSD-13.0-RC2-riscv-riscv64.qcow2.xz) = 77268692d05047bb552a18c759bdcbc2431aae6745d38665681c936c8913a480 SHA256 (FreeBSD-13.0-RC2-riscv-riscv64.raw.xz) = 4123a1c73c057a86d7c7784e517a70dddc472235630c8ca0cdeedb3eb1b662cb SHA256 (FreeBSD-13.0-RC2-riscv-riscv64.vhd.xz) = 6928668e824e9926ee17e0204d3036c278c26ca27a77b846bf943b071f4abd2d SHA256 (FreeBSD-13.0-RC2-riscv-riscv64.vmdk.xz) = 8f07c1e86a9b772d213eddf312f8db6672047a3be73e2287094d78c7a776142f o 13.0-RC2 amd64 BASIC-CI: SHA512 (FreeBSD-13.0-RC2-amd64-BASIC-CI.raw.xz) = e26b78dac694d28451713375af5b246df7e3e6581a63c6016b6743c09c3959cad55ac47696c32fced0648bb8349723c4ca61a32b6bd3cf9797d85a98033445d6 SHA256 (FreeBSD-13.0-RC2-amd64-BASIC-CI.raw.xz) = ad5998c2975cd873af7a05db7eac2c9a4cd7c1c5c2dda6c1656063b840b5d1af Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmBMAx4ACgkQAxRYpUeP 4pNR0xAAlF5tUhtiuRsBxJhCK9KM2K2VC1eQnhPedcvrOTYIxOvbuVCDU4N4VrVC 08GalLuhzmVpQibprXFLQzxCKJuYKNT3HQ6xSuZb3ntqOOkGKmgVkzzA4k0dzU/D /PrrI7feZKY3ZqSjmsMV3K+tlUtmTSnlid2IBwkja+MfiS2wIqYMQ+lV9usgASel xTvymz7tNGAg3SrZowR7op8rF3kBHdER0zXjlFpETxFZc+J8WAq1Xvq5mI5IZPQj jFBpH0rWRcn2fmYx0rUHgod72QPVP6tAI1NRgB3RWVWEv5i2BTdykRbAtf4xIVqb 4LdOr5AS+wKGkpSWpDkkB3q8HvzFdgPZj2hUfsXhXC85PJc68GSJOG8PpZpjSWsN QQTVlkM9rO+YG4rvPGQBdUJB3gIgiBQIIR2kwisKE3DsO4+ljNuq90nlfV2DLWWk 1A+eK2mSBTE7RfrhmaSot+I5BEB11YbzDt6GrJzxtbxal0OU3e5raLnRIvL6OOU5 uwxuFetu5KOg2xA2vKWlaKh1L2H44i0LcbIVLxVk40pscBTTXYxCrS3wq8FCwz9Q UWKSagqk+rrBszQmadtMpH7/2UupH6rGn8JXeJRdpkX/+t9XQJwFq9vVmD+XWjbY HUJJGhl/e93PrRWu6Xr7tvrnbfLR9cULucjbWoEGC5yVvss4RuY= =l7V8 -----END PGP SIGNATURE----- From owner-freebsd-current@freebsd.org Sat Mar 13 09:50:02 2021 Return-Path: Delivered-To: freebsd-current@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 68B5F570E9F for ; Sat, 13 Mar 2021 09:50:02 +0000 (UTC) (envelope-from eduardo@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyHwV2Ykwz4dg5 for ; Sat, 13 Mar 2021 09:50:02 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (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: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 45FED1BCC for ; Sat, 13 Mar 2021 09:50:02 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-ej1-f51.google.com with SMTP id p7so46682667eju.6 for ; Sat, 13 Mar 2021 01:50:02 -0800 (PST) X-Gm-Message-State: AOAM533ML/x/iGKlHBIVRvGACEo6dG1TtCwQBHn8CZBOCCZFOFofs2Yc nMArU1PLpWKRIRDHmSoO7xUPhy+tJOUd1hXgjP8= X-Google-Smtp-Source: ABdhPJxh3c6oL+h53gss52Nr8djgbraPO30zAdm4t7qdeb/QgwJXulHjaVeiwRQQfq0u36VsTB+fsBq/sSMm525LoyU= X-Received: by 2002:a17:906:a1c8:: with SMTP id bx8mr12850975ejb.381.1615629001284; Sat, 13 Mar 2021 01:50:01 -0800 (PST) MIME-Version: 1.0 From: Nuno Teixeira Date: Sat, 13 Mar 2021 09:49:50 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: poudriere jail: specific commit To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 09:50:02 -0000 Hello! I'm running 14.0-CURRENT #0 fb3edd4f3 and I need a poudriere jail with same commit fb3edd4f3. porters handbook says: --- If a specific Subversion revision is needed, append it to the version string. For example: # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https --- How can I tell poudriere to fetch git commit fb3edd4f3? I'm asking this because I need poudriere testport, and I will like that jailed version is same as installed OS. Thanks, Nuno Teixeira From owner-freebsd-current@freebsd.org Sat Mar 13 10:00:51 2021 Return-Path: Delivered-To: freebsd-current@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 8F7C9571230 for ; Sat, 13 Mar 2021 10:00:51 +0000 (UTC) (envelope-from driesm.michiels@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DyJ8z3Qd6z4fQq; Sat, 13 Mar 2021 10:00:51 +0000 (UTC) (envelope-from driesm.michiels@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id w18so11419498edc.0; Sat, 13 Mar 2021 02:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=1NK8e5C+kUKe5xj7LtV5M+5OHQtQmsV/DjhHfV1u1HU=; b=fmV1hYkNKynI0fKUi97aD/HcfhAZD4MefZmXONIiB2b+TgZQ0MueRSl7Xo3hOsj7HP gpvqVFWQFjgP2FQt/KYUotfgTCB8KcKzcW+TxneFMz4Ws2/naoarnn9LJe2012mK/lGg 4wcnLrevpzrvS3+BFNYIn8c4/+UDv0gOqNPW7rQzUZhKuNa1GPlJeBVaXbBJmQ2l51EF QjfgwVoknhwuTli7xLL0P9/eimS+10itw/CTJ1lkg5qw+IUbAXducfqwaeI7LhAMIzcx 0tbrf7+GY7KmerPmt6WiWSJPZLsxtqKeHe/Hqwv09Gg+/DHdUcG+EnBnbyB9VjDgU+ZT BYEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=1NK8e5C+kUKe5xj7LtV5M+5OHQtQmsV/DjhHfV1u1HU=; b=dEvoo3zHrljkh4puIcVDRHgauEsR6vvLf0MgftV7C4VxGhIpqc37RkxW7bmlfTlCXl To+6wx2V/i6tDOBPpEdg424UaQzhP7wCyetmpgYeGJO5kuSeGyd0+Ghw1uLb4aU6Jk78 zUjnU1H1FpZed4Fz+k/3D6XAWpHPXQmsWQTl5eWq9gZBGJCHgnFy4MprbeAXLWaVr1ey skLzIKm5fYCSxYQzM8YD/obzlkymOkZZoBqIVTy0T/bm9sN2+li89R8Kd8eozxNdp59b NnHHdjgiv2JfM4OMi3/UyK/5GrGPX4hDkAsM2D/lfX3Dv7S8U7FUA6oR2mMw+xQMI1Pp soZw== X-Gm-Message-State: AOAM530uupR4HjnI+r5z2clmn0sIRC+wmqpVgjhIkoJ+r6PgVC2kuLBQ N7hFDz1VCfZ3HBiwP1UtLrvrigq4lNk5GQ== X-Google-Smtp-Source: ABdhPJzB4XzXeaac6Dq9xRkTudYvBoBnGb7Ynee5wwcEPXi9Z0V+tNuL3F60q9nSc7MN7ae1VID/lw== X-Received: by 2002:aa7:da48:: with SMTP id w8mr18677829eds.81.1615629649021; Sat, 13 Mar 2021 02:00:49 -0800 (PST) Received: from DRIESPC (ptr-8sijbm693ud0e0aytbk.18120a2.ip6.access.telenet.be. [2a02:1811:2505:1601:5d73:1a11:5380:f2f0]) by smtp.gmail.com with ESMTPSA id a2sm3927742ejy.108.2021.03.13.02.00.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Mar 2021 02:00:48 -0800 (PST) From: To: "'Nuno Teixeira'" , References: In-Reply-To: Subject: RE: poudriere jail: specific commit Date: Sat, 13 Mar 2021 11:00:47 +0100 Message-ID: <000401d717ef$bdfcc180$39f64480$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJbPy5fS2BnApy25qD66A7trUEvPKl5YHdA Content-Language: en-be X-Rspamd-Queue-Id: 4DyJ8z3Qd6z4fQq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 10:00:51 -0000 Given that you are running CURRENT I assume you are compiling from source to update the system. You can build a jail from the built source on the host: poudriere jail -c -j host -m /usr/src This assume you have a built tree ready under /usr/obj to install from. Regards, Dries > -----Original Message----- > From: owner-freebsd-current@freebsd.org current@freebsd.org> On Behalf Of Nuno Teixeira > Sent: Saturday, 13 March 2021 10:50 > To: freebsd-current@freebsd.org > Subject: poudriere jail: specific commit > > Hello! > > I'm running 14.0-CURRENT #0 fb3edd4f3 and I need a poudriere jail with same > commit fb3edd4f3. > > porters handbook says: > --- > If a specific Subversion revision is needed, append it to the version string. For > example: > > # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https > --- > How can I tell poudriere to fetch git commit fb3edd4f3? > > I'm asking this because I need poudriere testport, and I will like that jailed > version is same as installed OS. > > Thanks, > > Nuno Teixeira > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Mar 13 10:05:29 2021 Return-Path: Delivered-To: freebsd-current@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 83027571729 for ; Sat, 13 Mar 2021 10:05:29 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyJGJ1Twtz4fjg for ; Sat, 13 Mar 2021 10:05:27 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 6DE542F5CB for ; Sat, 13 Mar 2021 19:05:17 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1615629917; bh=YakW5tzXKxC2lddy9MToERa0mWc3wKDoHkAJx6crk+U=; h=Date:To:Subject:From:In-Reply-To:References; b=obHoGN9yaHrjkp8GWHYDsw2HwmZpdoCNgKPRHQajUElleCO/2rpxh2i22U6denDfp sDbeNIEx7An8rYv7ulDP7Ti/7DZcvWPwrVCHdgRRydjee15XyYZmvzmnUG2cWlBpD5 w7hhinV9C1crZAj00Pb1xOIPZMgoyJRLo2waIzLra1/fFgUudibl+BIBQ7tQVHqn4F Ps+MouMY4zMfo8ZBs8+HxMNZAxue+xUXA8hXC8+BsKp3A5ntpizUGiylMXTPZOQ55u WaYM2XayppM0xNeC5+K0cBP2Q6sTMW8gXV3bJf6QeumGUoGP1btZhC3NUX4xWQITt9 HHSNcv5iy9/Gw== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id A444234B33; Sat, 13 Mar 2021 19:05:15 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Sat, 13 Mar 2021 19:04:36 +0900 (JST) Message-Id: <20210313.190436.692007261153478069.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: poudriere jail: specific commit From: Yasuhiro Kimura In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DyJGJ1Twtz4fjg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=obHoGN9y; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.1.226.64:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[utahime.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; DBL_PROHIBIT(0.00)[0.1.226.64:email]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 10:05:29 -0000 From: Nuno Teixeira Subject: poudriere jail: specific commit Date: Sat, 13 Mar 2021 09:49:50 +0000 > I'm running 14.0-CURRENT #0 fb3edd4f3 and I need a poudriere jail with same > commit fb3edd4f3. > > porters handbook says: > --- > If a specific Subversion revision is needed, append it to the version > string. For example: > > # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https > --- > How can I tell poudriere to fetch git commit fb3edd4f3? > > I'm asking this because I need poudriere testport, and I will like that > jailed version is same as installed OS. > > Thanks, You updated your host OS to 14.0-CURRENT fb3edd4f3 with regular steps described in /usr/src/Makefile. Right? If so you can create jail of same commit as host with following command. # poudriere jail -c -j jailname -m src=/usr/src In this case files under /usr/obj are used to create jail. So you need not do 'make buildworld' again for jail. --- Yasuhiro Kimura From owner-freebsd-current@freebsd.org Sat Mar 13 10:57:39 2021 Return-Path: Delivered-To: freebsd-current@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 5C764572CF1 for ; Sat, 13 Mar 2021 10:57:39 +0000 (UTC) (envelope-from eduardo@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyKQW29f0z4jQl for ; Sat, 13 Mar 2021 10:57:39 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 3330D1BFB for ; Sat, 13 Mar 2021 10:57:39 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-ed1-f46.google.com with SMTP id dm8so11526339edb.2 for ; Sat, 13 Mar 2021 02:57:39 -0800 (PST) X-Gm-Message-State: AOAM533YSm/FGr+v3BQrE0nkxAdgA+Q5ijDxeYevGHxHLCxHeKITJIcN qxMA1aufmt6nglsuFeXGCZKyK3UGZDme2jlVmAs= X-Google-Smtp-Source: ABdhPJyvFtsCvzk+kzG5OYZ746ltdm/V+TKtRO0lM3/CdaVHfHUysQdOqYFlhsCI/HO44Pb5aRh67+hWXWC01dB7VHI= X-Received: by 2002:a50:fe06:: with SMTP id f6mr19498500edt.349.1615633058080; Sat, 13 Mar 2021 02:57:38 -0800 (PST) MIME-Version: 1.0 References: <20210313.190436.692007261153478069.yasu@utahime.org> In-Reply-To: <20210313.190436.692007261153478069.yasu@utahime.org> From: Nuno Teixeira Date: Sat, 13 Mar 2021 10:57:27 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: poudriere jail: specific commit To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 10:57:39 -0000 And next time I upgrade my host OS should this command work? # poudriere jail -u -j jailname -m src=3D/usr/src Yasuhiro Kimura escreveu no dia s=C3=A1bado, 13/03/2021 = =C3=A0(s) 10:05: > From: Nuno Teixeira > Subject: poudriere jail: specific commit > Date: Sat, 13 Mar 2021 09:49:50 +0000 > > > I'm running 14.0-CURRENT #0 fb3edd4f3 and I need a poudriere jail with > same > > commit fb3edd4f3. > > > > porters handbook says: > > --- > > If a specific Subversion revision is needed, append it to the version > > string. For example: > > > > # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https > > --- > > How can I tell poudriere to fetch git commit fb3edd4f3? > > > > I'm asking this because I need poudriere testport, and I will like that > > jailed version is same as installed OS. > > > > Thanks, > > You updated your host OS to 14.0-CURRENT fb3edd4f3 with regular steps > described in /usr/src/Makefile. Right? If so you can create jail of > same commit as host with following command. > > # poudriere jail -c -j jailname -m src=3D/usr/src > > In this case files under /usr/obj are used to create jail. So you need > not do 'make buildworld' again for jail. > > --- > Yasuhiro Kimura > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Sat Mar 13 11:04:04 2021 Return-Path: Delivered-To: freebsd-current@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 C548F5733E2 for ; Sat, 13 Mar 2021 11:04:04 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyKYv4kTpz4jy8 for ; Sat, 13 Mar 2021 11:04:03 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 47B4B2F648 for ; Sat, 13 Mar 2021 20:03:58 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=utahime.org; s=maybe2019112701; t=1615633438; bh=bdBO0hQ1G+lr02Y9fpPfnwnOH18tI42HD9utfj1iG4o=; h=Date:To:Subject:From:In-Reply-To:References; b=TBlA31E0U29O3ryuGQFWELwcXjQgLzK4VuEzN8wqHB9DvSkEpz33dMat9NzC1dnAa YxRe246yulnKhorey78lYLbYwqd/WFsyVYgt6VcnLggUbyf4id2SGM3Fh1L8VMo9RQ AtYzE7b7melbRWD2xbAZAQ9eTwHfOSMYTjSHEhFgynDnJt+jyEZ78AcZJRu17sBLwb 0mnbEndUVCMf5sbx1X4mEl9O7z15ehHmW9hwr9t0jwnvmux7ARrUVa/qXWlQx5/Js5 9TJKGeLMicQyGiI13XhVLa66byXbGV/34ub23+Ix8jm4+CVu5yePiWxkabxrvWHCUM uDLa194uHvUcQ== Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 7839434C2F; Sat, 13 Mar 2021 20:03:57 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.1 at eastasia.home.utahime.org Date: Sat, 13 Mar 2021 20:03:50 +0900 (JST) Message-Id: <20210313.200350.2123683098935599415.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: poudriere jail: specific commit From: Yasuhiro Kimura In-Reply-To: References: <20210313.190436.692007261153478069.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DyKYv4kTpz4jy8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=utahime.org header.s=maybe2019112701 header.b=TBlA31E0; dmarc=none; spf=pass (mx1.freebsd.org: domain of yasu@utahime.org designates 183.180.29.210 as permitted sender) smtp.mailfrom=yasu@utahime.org X-Spamd-Result: default: False [0.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org:c]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[utahime.org:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.180.29.210:from]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[utahime.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[183.180.29.210:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.57)[0.570]; MID_CONTAINS_FROM(1.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 11:04:04 -0000 From: Nuno Teixeira Subject: Re: poudriere jail: specific commit Date: Sat, 13 Mar 2021 10:57:27 +0000 > And next time I upgrade my host OS should this command work? > > # poudriere jail -u -j jailname -m src=/usr/src Once you create jail you can update jail with # poudriere jail -u -j jailname --- Yasuhiro Kimura From owner-freebsd-current@freebsd.org Sat Mar 13 11:24:49 2021 Return-Path: Delivered-To: freebsd-current@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 CAC23573B4E for ; Sat, 13 Mar 2021 11:24:49 +0000 (UTC) (envelope-from eduardo@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyL1s5KRpz4kxL for ; Sat, 13 Mar 2021 11:24:49 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id A54B426DB for ; Sat, 13 Mar 2021 11:24:49 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-ed1-f54.google.com with SMTP id i61so11592354edd.7 for ; Sat, 13 Mar 2021 03:24:49 -0800 (PST) X-Gm-Message-State: AOAM530VoCHlvHK9lIZPjkNBO6oIc9hkwiZ4QSo2NfhI2xvuVKWpGfOV dF7RoheVNVnxDWY1uGxNiO5VSenQ2KZmm8ROZfg= X-Google-Smtp-Source: ABdhPJwhRilwu1U1QMNr3NXM9epjDDm4EYAiJz7xxcKWZssrzUEtXOYDdGdHqvZRr5wjUgNcuiVc/MpcaDAkvh7TgrE= X-Received: by 2002:aa7:db0c:: with SMTP id t12mr19121965eds.34.1615634688731; Sat, 13 Mar 2021 03:24:48 -0800 (PST) MIME-Version: 1.0 References: <20210313.190436.692007261153478069.yasu@utahime.org> <20210313.200350.2123683098935599415.yasu@utahime.org> In-Reply-To: <20210313.200350.2123683098935599415.yasu@utahime.org> From: Nuno Teixeira Date: Sat, 13 Mar 2021 11:24:37 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: poudriere jail: specific commit To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 11:24:49 -0000 Nice! Thanks very much, Nuno Teixeira Yasuhiro Kimura escreveu no dia s=C3=A1bado, 13/03/2021 = =C3=A0(s) 11:04: > From: Nuno Teixeira > Subject: Re: poudriere jail: specific commit > Date: Sat, 13 Mar 2021 10:57:27 +0000 > > > And next time I upgrade my host OS should this command work? > > > > # poudriere jail -u -j jailname -m src=3D/usr/src > > Once you create jail you can update jail with > > # poudriere jail -u -j jailname > > --- > Yasuhiro Kimura > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Sat Mar 13 19:01:27 2021 Return-Path: Delivered-To: freebsd-current@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 702CE57F53C for ; Sat, 13 Mar 2021 19:01:27 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyX8k2Rrwz3Fdw for ; Sat, 13 Mar 2021 19:01:26 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615662084; bh=MRRHxFeyapcGOdz3zJjv7ncLd72thQLkZ2k4tJmDDAk=; h=X-UI-Sender-Class:Date:From:To:Subject; b=GBYTRPioJ72Kaqp2rCTgK+4J+Mq+8TzIk2YQDy0VdcP9PiieeSR8kknX1RS/0lC11 X6Y3pknymbJyaom20SzpZ9UXgJ+CcSR04IjDL0kEVyJ9AOxFnntLWkmynCpDOtxOR/ 32Ct+V8J7mw+omZ5mhcrR2mPxoUzb8hc6slMjqa0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.14.8.154]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MysW2-1lhvZ00akU-00vxe0 for ; Sat, 13 Mar 2021 20:01:24 +0100 Date: Sat, 13 Mar 2021 20:01:17 +0100 From: "Hartmann, O." To: FreeBSD CURRENT Subject: console: no USB keyboard! Message-ID: <20210313200117.46db6706@hermann.fritz.box> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/20lb/8RXvCyUqn5iVDUlzLX"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:+n4DNvIAN3r1hkuuw7BZVkPR8Inryvbhz/+ZY5AC9AHAVA1JD88 5fHojsvXLbAbAfboKgMwnPTPJlBmxW1EOVxnLvzg+vIIlALFLDc1//EVLK8cc3pGkNpNcA4 gDYqjA1Y/FFbeA2cffgCbDalBZoVHf3/s0ejHuiDy7NXYXItvleBaGVeqa96CDVJfI8jM19 Mp9e/ICbhCqa+CtOnYC7w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:5kqqLc1kwwE=:rjqjPWGCh/qNx2bFKjruSU nIJUO50PzwxRoXG/scUcagWNEpUK+X9BsYAGS2DTsOc2W6u262TNHnCI6nta7XtOtI6R9cmfL uTXh5J2/dvG1oHk25DnaP/iFCAigccksyEGlz4xZxngOy5Tugf0iFrIvf7iMsPve1+Mx+Aknj 4y+D+s9TtnVGssetkkhPRWNCBBraPt4/phgyuKrdBPbmC0ONpiSBjMTJaCT4SU/p1uU6uksgD KKtY5Ldqm7GArTraRmPCYRUv39Rfpr6VzIHtKyHv5DPLH3d9GkAK/cGS15n98QRpHNeRh5FA/ rr7ZElZsx9ti1iybHtWHgPQsOWF4JorQmmsa4beGJD8MMU2lQRg5SwsvBxZrTr8rR4eXvXf/x vqV/rVqsvty+KuRWUUhnmuviUdfMuM5ImLGWJ9p0sW9Zvez6LGnZFdf9QSaTXhSRtXANw3aU8 8tskJP9FlmN+VLG0GwhJj8dWBFMl7D7OhEfSUAUaB2scqecrRF6js3dSAwT1vlC8V239VCb7Z dvs+8qCDA6K6g/IxY1swql2uMZsdjnMuxHlmACpxYq04p40uOg5MkMd0EJTqzhFBqHD9tdxm7 clf3orsw9pO7X3ksjcJSBd81umID5t5sT/IGm0a30HkHl7d/ylz/elr5W4M9vkPc89hRdozwn vHnOqoy6NERAFTrgy4hNSxhFmtNLw5ngJLzUCMj2dXKsg8TQIdfled64skMqe9rkq+JjMHfD7 h6F2vnVdE1nJku0H9c3K60ceGWwpZcchhkFWDmCS/+UyXuaPBatJdBqipS9AuSnM2qndtT3lK BA1EFem/uMyf4drTJ2Tf5mo8nBz/iA9qU0kKj1EMSTAjmtIJpDsXrdNGj3xkC5ha/TGOJSJnd tFsLAg740UiHs3CcmZ+g== X-Rspamd-Queue-Id: 4DyX8k2Rrwz3Fdw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=GBYTRPio; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.17.22) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJECT_ENDS_EXCLAIM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[89.14.8.154:received]; FROM_EQ_ENVFROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.17.22:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[212.227.17.22:from:127.0.2.255]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 19:01:27 -0000 --Sig_/20lb/8RXvCyUqn5iVDUlzLX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Running 14-CURRENT on several boxes (i.e. FreeBSD 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64) with custom = and/or GENERIC kernel and USB-only equipment (mouse if available, keyboard). In multiuser mode, there is no problem using the USB keyboard. On single us= er console (for maintenance purposes), no USB keyboard is available. The same is true = while booting and the rc scripts are worked on. Usually, one can hit the enter key and in= serts a newline, this doesn't work anymore until the box is completely up!=20 I do not know when this problem as been introduced, the very same config is= used since 13-CURRENT in its earlier time and has been modified accordingly, but I can= 't see obvios changes which would explain the wrecked behaviour now.=20 I got aware of this problem, when a small mistake in /etc/fstab rendered a = box unbootable, I had to head for the datacenter and wasn't even capable of int= errupting the stuck system. Checking on other boxes running recent 14-CURRENT revealed th= e same problem. The interesting part is, that as long as those boxes are with the loader pr= esent (all boxes are UEFI booting!), the USB keyboard works as expected and I'm able t= o select kernel/kernel.old and so on. How to fix this? Thanks in advance and kind regards, O. Hartmann --Sig_/20lb/8RXvCyUqn5iVDUlzLX Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYE0L/QAKCRA4N1ZZPba5 Rw87AP9LD6hUkFpWF5ToUntroH4ROeiEn3IOChnKhy/QaKvinwEAx8XLRwYzjLoG wTZp4HjlwK/I9UJg8qJJTT2XO2PKRwI= =YL/N -----END PGP SIGNATURE----- --Sig_/20lb/8RXvCyUqn5iVDUlzLX-- From owner-freebsd-current@freebsd.org Sat Mar 13 19:17:07 2021 Return-Path: Delivered-To: freebsd-current@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 3C68057FF89; Sat, 13 Mar 2021 19:17:07 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyXVp1xh0z3GR0; Sat, 13 Mar 2021 19:17:05 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615663024; bh=6FvTd+w8KaCRmg+m6hjk03WLe8tC3oZnm2VOFKVSJfI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject; b=CURhz0ZrNoE1FD0U6ffQq7+HPSkbELoqBSiamyv58y+zF+gmSk6lHf8UG+5GAyoYu hqn0c6clgtgpeQhw75dc54chtzVO+wrqXfJkssOFPazW+LYHPiWQEkFyB+8C0HAy5x rO7iRNAZBuOXcW6yBydVhGW5YasQs2SzolGfFM0s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.14.8.154]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M7b6b-1lLz6Y3y9N-0085FI; Sat, 13 Mar 2021 20:17:04 +0100 Date: Sat, 13 Mar 2021 20:17:02 +0100 From: "Hartmann, O." To: FreeBSD Ports Cc: FreeBSD CURRENT Subject: On 14-CURRENT: no ports options anymore? Message-ID: <20210313201702.5f9dfa9b@hermann.fritz.box> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/fFrJEM/KpKTY.iPHr_+MvU7"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:TujpNuGTFljXApWwx93VvHe22gB7wtSddy/WlYqV3BG2IpP9kwm Bok0rGAzCD+NTpV9BOf9eWVY1WfpdJ9SfYQL4ZrbT3oMCZWE2durZm16WrTlMuwWozL+RgD T6ROomPuMn7Smcitb+s8G3wWkoCTsDR9LIVwW6KgCQhHyfHuAvY+9TYRYyGdP1Ipxt7aJvu oUK5A/BkerMktfadYrFqw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qP4S9nNC4Qs=:rfdu4PI3bkhNtOLo5YjYlo +3wBiyzy5kg2CPxpMBhl0F8I+zwqx9acoSw87MscK6TpubHGxs0ETzzMxr0RYEG3Db5oveo1S RprHsn74RTj8AhNhLqTSsQxX6x8+8nJLkhDyFCYjSJuvPQ/QbuN3a1brABdsXJD7Jsp+4ZBIG Ak/HODeXwcp+F3U+Z2giub1WF808vgliy7nHKltfJ4V2NTzy5kavHkKI6NuzR0ZSJgcq9/HFz 1n8aZ92nnXNwarKmXjMql7EdBh0tT4IywgO215KY9Do6bpet1STEuApBPoyPMGiicNVIdupJz AHTeQDDrswO5stLoi7aR8TeQC1MP8gMp49/DSS9aj6ozXnJvpnHmY173YZ1PGBMfIY9aPJIQZ TzSejtl2CEmC2nr+v30bKXNQ99YE8XCY/cE0PfdqZgRentRokx/GchrFEQ2nwTznVI5bIAn0d 3fY78+YTdLGxUpZ4jgnhd1F7sNBC8GKsOPHEIVaGOrYs0BbT5XFILVMlPI1pXj19K2rIvbRNm v6wuaC+dKPXrWVXCxA2EoGdlpvZBTtzv3LHlz6TZ06Iix9NE8mA5qKIFm8o0gsEci0T1UUQJY KZx7J4NjBDdFuJI9QGt6grIa+t/aLxsyUdsKnSAjlyejusgt7Alku1q8fS2OZAEQ8NpXOm+Ny udqrUZ0nz+kxRpLkMPZ9VOUFQyrJY82Qm3ERB8CPC9PVuyeqNpT/g0nOsIzThttZWnqtdEiok xSF9WUNKGob/Hf2XEVyK1F9YduujHQNsLuXvU9S+6pdMJVK3niyOyKe/mhdO2v+7Y6uJyGvbD QqbXnDxcM7cM775l0fLSfLfn4hekg4HbXelixFGBgbVwmVYinehvmm4HQiTERIjtWznVypEYK SQTQSl2hM3Gbauf2ksdg== X-Rspamd-Queue-Id: 4DyXVp1xh0z3GR0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=CURhz0Zr; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.17.20) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RECEIVED_SPAMHAUS_PBL(0.00)[89.14.8.154:received]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.17.20:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; SPAMHAUS_ZRD(0.00)[212.227.17.20:from:127.0.2.255]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.20:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 19:17:07 -0000 --Sig_/fFrJEM/KpKTY.iPHr_+MvU7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since I moved on to 14-CURRENT, I face a very strange behaviour when trying= to set options via "make config" or via poudriere accordingly. I always get "=3D= =3D=3D> Options unchanged" (when options has been already set and I'd expect a dialog menu). This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at Fr= eeBSD 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 am= d64). I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. How to fix this? What happened? Thanks in advance, O. Hartmann --Sig_/fFrJEM/KpKTY.iPHr_+MvU7 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYE0PrgAKCRA4N1ZZPba5 RxrXAP0cLnaxcCVbKbAqfJGVFKjn7p2fwU7P/HoHEXhA0aS8gQD9GWtdfJ8pD031 a4ImuGqY0lDlgUclFEyMHrnLHXwTKgo= =vZC8 -----END PGP SIGNATURE----- --Sig_/fFrJEM/KpKTY.iPHr_+MvU7-- From owner-freebsd-current@freebsd.org Sat Mar 13 19:33:31 2021 Return-Path: Delivered-To: freebsd-current@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 D64845A859B; Sat, 13 Mar 2021 19:33:31 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyXsl5ccNz3HYp; Sat, 13 Mar 2021 19:33:31 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300cd5f26c9008d635a354247a253.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:c900:8d63:5a35:4247:a253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 35DE5643E; Sat, 13 Mar 2021 19:33:31 +0000 (UTC) (envelope-from se@freebsd.org) To: "Hartmann, O." Cc: FreeBSD CURRENT , FreeBSD Ports References: <20210313201702.5f9dfa9b@hermann.fritz.box> From: Stefan Esser Subject: Re: On 14-CURRENT: no ports options anymore? Message-ID: <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> Date: Sat, 13 Mar 2021 20:33:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210313201702.5f9dfa9b@hermann.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zob7mR4fUe86Rew8MojntruHTaM6PeKFF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 19:33:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zob7mR4fUe86Rew8MojntruHTaM6PeKFF Content-Type: multipart/mixed; boundary="F7Y6uu6oL4a8Kr1geKNuCUEofLLTWgXDz"; protected-headers="v1" From: Stefan Esser To: "Hartmann, O." Cc: FreeBSD CURRENT , FreeBSD Ports Message-ID: <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> Subject: Re: On 14-CURRENT: no ports options anymore? References: <20210313201702.5f9dfa9b@hermann.fritz.box> In-Reply-To: <20210313201702.5f9dfa9b@hermann.fritz.box> --F7Y6uu6oL4a8Kr1geKNuCUEofLLTWgXDz Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Am 13.03.21 um 20:17 schrieb Hartmann, O.: > Since I moved on to 14-CURRENT, I face a very strange behaviour when tr= ying to set > options via "make config" or via poudriere accordingly. I always get "=3D= =3D=3D> Options > unchanged" (when options has been already set and I'd expect a dialog m= enu). > This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is a= t FreeBSD > 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 202= 1 amd64). >=20 > I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. >=20 > How to fix this? What happened? Hi Oliver, please check your TERM setting and test with a trivial setting if it is not one of xterm, vt100 or vt320 (for example). I had this problem when my TERM variable was xterm-color, which used to be supported but apparently no longer is. Regards, STefan --F7Y6uu6oL4a8Kr1geKNuCUEofLLTWgXDz-- --zob7mR4fUe86Rew8MojntruHTaM6PeKFF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmBNE4QFAwAAAAAACgkQR+u171r99UQ9 fgf+J236Ro02+rPe6BNuiklYBscvwXuTQ++4M6CD3JC3CHkjObB1NI2Za0bRDFNYixNuhB6RvJvk afpr5PTXNkNUntQHrtlw7KvcNe7SC3LhZQN6DEW0cXmNRb2nYa54mQW93gWvYP1bHETo6XQmvbXf wfHb8IJ/VizYRBPOtP+uAxFP2F0hfopJgaJglJuX7ROo3AdVIdrTSvJeQSpStnFXLHwLxAGMsSX6 OkNpgOwzJ+TU0zptLaogHB+DHMzEIWOCHODGG67RBXnIamFF+yowcOizovdiln8QMLJIcTw+IL6d wt+j7yYo0BDZ6+5rtY133A6u56zA+5orjlicFo5XaQ== =uwY8 -----END PGP SIGNATURE----- --zob7mR4fUe86Rew8MojntruHTaM6PeKFF-- From owner-freebsd-current@freebsd.org Sat Mar 13 19:52:52 2021 Return-Path: Delivered-To: freebsd-current@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 BA5AB5A8F53 for ; Sat, 13 Mar 2021 19:52:52 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DyYJ43T0Dz3Jlh for ; Sat, 13 Mar 2021 19:52:52 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 7712E5A8F52; Sat, 13 Mar 2021 19:52:52 +0000 (UTC) Delivered-To: current@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 76D755A9101 for ; Sat, 13 Mar 2021 19:52:52 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (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 4DyYJ33pPxz3K7V for ; Sat, 13 Mar 2021 19:52:51 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615665169; bh=rKwQ6c4J4v4Ih+pH0RCY5ad8pD1+K471FHfyk86KaVG=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Fr5tdqD1sPlrU4sdMofnd1fjwaX78tQqbr9RX8MVu5eWVVc+xwywFxo6Q2glD1OIkgeL2lSTVNLXoT0+ZmTGOawCzb0ZpHKos7rChsRwfWFDdRSj65/r6SHN2DssDivSSfF+WitSNLYz+E51CQTvWa4NnoG9eJAWZP5WNG2kk0T+/fOO/rdtCQrxlKM2bWxKqH3d2HtQ4WatDd+vuwKxq/3cfuYz+2Nnt729Mre+OfSX8J4iA4AsFDOFitLgBcYLizPvEZcYUnbial+S/ofLKYDcxFOwjdL1F0QLSiSmieock7uxGr4/3c5IVZ+Nkwg+m4FaLfc0Jwdbrh19S6hSWw== X-YMail-OSG: qTFbpDIVM1lNUd.VT3.uAHsTIKO_2_.UL8LOe7fjisGdIEWuwHntg8JhcuOtE5_ NmY7og0q8jPUrFaCSHN5eowBL0fh5aVHa2UaGiVYDHUkscY.gyiCvtEfDNeUFEeCbPwc4JJXCiFa hh103HizoYrjUkYjuomUQ8ltiMThTky6GS1Lwfn3VaUnBCXkiOPIBj0UCdlSFXdFkwbrw5ojwQ_T jdPD6c94sUSyfFZ3Gclr7SQBces1.y4.JqsIYsk_G.YezCV3ZyzFkhUWOqZpBY3OKlvC7QUdD0NN rp5e4PpqLzconbXhzizm1yA3EBdFRUwTH_YKmi_xoBWCBzP_QDdygDfpW6osg9f1DNYe8ksMHk4S m_f5uoiW2RTsAxeF.O7Dn_X5ZKqGlwWR5AF0aw8yR2qUx02iDRJF6ya1Eh2AdBsrehb_RX.zFC9Z iRV31OyquKh1DkyVhm.r2bVoldWlFOvQkCfZyOvS94AqDGebDyCRA7Tgk4mQtJ36awjRmFk.1A7l t38rbg1nHyNmZ1fyDdxGLApRFF_C5tQOX22yenPg3o1kY3UjrzFO6tYxS02v_b48eg.wxYgekjan O38rpRVw5zGQGk6DxVovysG0M.MPJhkCUd_V0zDeVI9p6Q4ovTyPKj9Mg0A3vN9SDZL2Uu7EWHrM pqCCsZaaxLXM7LjZnh8gF0ErsgAXsEHfL4WcBAxDgWw.exe1VV4MLwFMLOZWy05ftqiHKryBGQAT tns74QFPcdFgvOEbbroN2GqfiLXGeiIrAuUzw8.joPJUe11uzoZPecXl0fwkV5juECpk45riG1Y8 DZc0rPFCmWGNQwGSMtICyhFKYDRu1ZlGAUNTEjYScVlbsfXsMvATDIDZzx7i.kFcn6N_S9RQItMk 38RCyWQ1VfCl6DOioq0u9dRJsJarnaysw6SvnhNLOEaDKaD.GyKU1qw1873Edqma24TQfU3yZl9V xUzluFboL6Dj3fr1mgqJV6.595TTHVa3G1q3HVq6BrF43G24YAsWvcgom_Z2R4DR43pqgkHjd38u onf1FLHKUlrQL9_RmfvmvRb6RscTOFKkfWswEuc0a70sw11xIjSzpNxRfwqYnAcVzRneFWwQsIHQ lT.kzIV9YPrSEgVORyZk02BqGddo510A7v7.rZHHyxCjjINoger3pejbRmg8PE6jt.gW0ZSE4en_ afoS60VCkz3BP8xncQ7cTuy3yD0qJy1d0SDTEeFGOr5a5tOK.7aP8b6lo_P_b67mxfPADBE61ghe TFPOzxVrq_zRubEaKaPpxKrbUA1xxePDCXwdkYhQ8u5wgB6Ue8cO3ryH22aHnleoC7VTXuBP5PXJ 1ojqR.l7_raL5W7.aNDyoEe9kmjr1Ls08yBDrsorsMzjMNool7RqfTiNa9IRjm9dZHlsDjjoj3Wf F0IW0.yYmJguUfenFsbT.oTxobmu_QEAn2MN1EE4qJXzOzze.yHdbBHtNuqpLYLOuGWUeKjt8bZu .W56iH2EsuTu7Y1vEkDWRPBfJHhR2EQp8XiLO_b.0gxgmLTpqPcGJPrrLJk6WYGyg0eQwPs96yM7 XTqIzPtCPm5YWYdomIQ9UkU28oZCSAnV8Qqz_L6sGUpohyCW4hE6.4RSq9CL3fz7b5IRwBzJse9l XLfTBYP8p1VqEPx2fn6JthYP4pqXeG7XJ_7nMK9cS4Gxn5s3jUw9gbwndXpnhxmXuz4JRsnlieAj gDWVQRkB6d6f2nCfRjeR9V9dTqBTFiSgqknHSxDzwx5UE.CRYO7veDfHh5WZ.CUcExXG6XG49Oz7 JqugRJnMU9njNZ8TboFJAx15vRY6BJleAyR66nI1QPxLnoerBcVDohmtnbKFxD8ZGM3l5t2t8XEf hWfW0E5pQEjgTZozkH_YCNxDHd_uuyktCsqBJofRldjzhgGXCqcPTp.aDxZYbeFtz9rN7e7cFuUB XZw9GcMmXnxB4AceEV2b9Bc1fX9nJyRldFsYamH7XaYLyZGeE9rCJXDe9z3Bmsx8CujgDS5qUqcV UmUWBNuDy3x.pMMeCOdrngC87L9eIiJbEkTrzjL23bKAiS5ktXOf7RYdxaTDGR8Y8Z2VBrLUa7EO VzkPGQdEkYtnfNapnp7AYy4_r3susWr4TnJ2YsM_qfxvQGXyPsdRETylKlStRBUVIH8lUCmaqzfV LWIMM80j_YvQyJb.1DGS3RS1skM3fUNb9pfgyc_EMqaFgnTe4m92Tt2YiTSVmzCER7_jZQ99krnq A4VuAcAPjFZtJbUzlo_qYObNgSA_oeBdi3nBrmEmlMUJL_wPmigBm7kwnNbP2e7THDNjO0SwFtOf 8ATiZfoxPDl6EMQBwCTcSURskjyhC_vKRYsMsKXNuv046g4g4iJYFBJMW_ljhC9xHCliYdQ3NP7S asKNCrBAG3pIDx9.iJRx7vobRVpsMyd3oY.QTNdYOiR1vVw58B7dzCZaBsvIrE2fngFr5Yp933ho j5N.zL5qn X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Sat, 13 Mar 2021 19:52:49 +0000 Date: Sat, 13 Mar 2021 19:52:47 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <509410723.637403.1615665167513@mail.yahoo.com> In-Reply-To: <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> References: <20210313201702.5f9dfa9b@hermann.fritz.box> <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> Subject: Re: On 14-CURRENT: no ports options anymore? MIME-Version: 1.0 X-Mailer: WebService/1.1.17936 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:86.0) Gecko/20100101 Firefox/86.0 X-Rspamd-Queue-Id: 4DyYJ33pPxz3K7V X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.187.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.163.187.32:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[66.163.187.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.187.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 19:52:52 -0000 I had the same problem in console modeFiippo On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser wrote: Am 13.03.21 um 20:17 schrieb Hartmann, O.: > Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set > options via "make config" or via poudriere accordingly. I always get "===> Options > unchanged" (when options has been already set and I'd expect a dialog menu). > This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD > 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64). > > I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. > > How to fix this? What happened? Hi Oliver, please check your TERM setting and test with a trivial setting if it is not one of xterm, vt100 or vt320 (for example). I had this problem when my TERM variable was xterm-color, which used to be supported but apparently no longer is. Regards, STefan From owner-freebsd-current@freebsd.org Sat Mar 13 20:00:08 2021 Return-Path: Delivered-To: freebsd-current@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 488BF5A9410; Sat, 13 Mar 2021 20:00:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyYSR74Bnz3Kf9; Sat, 13 Mar 2021 20:00:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615665604; bh=b9TE/H9M7W+iWzLa+FSxN14eTBlsL7tYTbIwRCyPopM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References; b=TVgcjiXCY33TH3NXfjS49/q9X5J7rkGcR1BYwaKe97krpxf4YHIXaId2z4xX27QIY /xQ9Z/kpxI6cCTKyg9v0K97s1gv4C6MId7JvzP+9KL0czbHhwKgBM7sBP6DHWp6BSC A0ACifuBi8XtiqoJgzwM1XFSQ0MYs+Cx78U8L/aI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.14.8.154]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOREc-1l5Ge53vR8-00PvUb; Sat, 13 Mar 2021 21:00:04 +0100 Date: Sat, 13 Mar 2021 21:00:02 +0100 From: "Hartmann, O." To: Filippo Moretti via freebsd-current Cc: Filippo Moretti , FreeBSD Current Subject: Re: On 14-CURRENT: no ports options anymore? Message-ID: <20210313210002.30ad4345@hermann.fritz.box> In-Reply-To: <509410723.637403.1615665167513@mail.yahoo.com> References: <20210313201702.5f9dfa9b@hermann.fritz.box> <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> <509410723.637403.1615665167513@mail.yahoo.com> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/wgYtmhDXj5sTmL8fnZ54=W4"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:Act/MyqlFkXsf6NqOibwzZgbFNA1Gbn4B9/RWG74Gtd2EcnnEsx BLxyHyOI1yY22S5LGSbExhy/KmV4XUOYtVCLx9dcr27Gro+M+uBfsctzJRatSH87xASNxMm j6amCn+2HUc1Wdqntj0HU07VE5YpzBCoCAZuntvgD27q3I/ZxzeYXVp04JGHWrWGtAr3yhY w+3YvgzwyjbfXYJDExCrw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QjnxptMjVaE=:Xej9MPw+2gsOHmbIJtU0zH 8et09BwiverWrV2IcPvZmsAuyzzk8W3e48rHCuavN2YkXKtWGkGdTV/Ez3jW0VpXwbbQ1fsZB fQaTv96Q6kSzcNaVT/hMdwtVOGCd3hpgGaxL0QgM39nj7VB/H04gg5q9jq0jXb1gAJbPbXJqb 96nUXFBOId01yTJkUENzxzCpqcW7MUBH0iwZWvmEQ4uTAYAoc+z1f71paZ+mPktcxhjXhUWi7 xetKhyiw0Vy34waYHfq/GS5cUZAwr/MyhXUBM6v1sAk7UWu/An8s6QU+pbDKINRVYBloUS8PJ Q/lN7mv/kR3Z3yHXujt4VmgFHgNgR1BjulsVXuMB9i59TO7kG6yEdrFww4mnujWkL4NK9MngF 1iW9JTfS7j3WJFM2CEgfHH6S0S//6Fw5mf+tvavMjZsuwNrOeroGTHsGTZu/i0fSFD251V4q9 InvKGkHhbR2oamcw00d3iW392cgzbWRpTTsfFw8yCfMMdXFuFEUhboVLWhEBu2ZbP6yCXbfO3 d/uF/YFhnt6f7wF50qG33YeZmIclJUtLMTnCZN2BmyrU4L9AVZybJGAorhr1j7iFk27EiUt/u mvJEhtB6uyWwZIAVdRDjzp05srJPE3woRsSUjGof2vRSJifG7RIt0lrS0Ylu/M3at8B+E0Xmx bpI8cWA5LsuN5ow0Zu0d+rnsjMdbVJB/hWEgFygmRCE2V1VjvFOY1QDmnHyVPssU62/sR7sX5 x0IhZ/p9zRu+bjhR1UzVH3WORXbhA4ZnDJTxnzCYlWC7kHW1DkP3ELde7iYKO+MmXN4cDqd+q r6FbDOqU0+ziyWydD+oPFHHgSZcMo5LM1ZiCTl4OSCxhr56pXilEwyrEGasdA8n+Kgpz/96eT boU7wYf164dT1nUL+txg== X-Rspamd-Queue-Id: 4DyYSR74Bnz3Kf9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 20:00:08 -0000 --Sig_/wgYtmhDXj5sTmL8fnZ54=W4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 13 Mar 2021 19:52:47 +0000 (UTC) Filippo Moretti via freebsd-current wrote: > =20 > I had the same problem in console modeFiippo > On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser wrote: >=20 > Am 13.03.21 um 20:17 schrieb Hartmann, O.: > > Since I moved on to 14-CURRENT, I face a very strange behaviour when tr= ying to set > > options via "make config" or via poudriere accordingly. I always get "= =3D=3D=3D> Options > > unchanged" (when options has been already set and I'd expect a dialog m= enu). > > This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is a= t FreeBSD > > 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 202= 1 amd64). > >=20 > > I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. > >=20 > > How to fix this? What happened? =20 >=20 > Hi Oliver, >=20 > please check your TERM setting and test with a trivial setting > if it is not one of xterm, vt100 or vt320 (for example). >=20 > I had this problem when my TERM variable was xterm-color, which > used to be supported but apparently no longer is. >=20 > Regards, STefan [...] on one of the hosts (non-X11), loged in via ssh, the settings are: # echo $TERM xterm cd /usr/ports/www/apache24 make config =3D=3D=3D> Options unchanged (no menu popping up) --Sig_/wgYtmhDXj5sTmL8fnZ54=W4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYE0ZwwAKCRA4N1ZZPba5 R32oAPwP36HI3yroh8HRcmzOGjmb5x6rp/X9z6IOneqk0ixUxQEA4k6JWei5Txwm +skId+5yd9JLXbZbdk55nIIqUaJ2FwI= =3r3h -----END PGP SIGNATURE----- --Sig_/wgYtmhDXj5sTmL8fnZ54=W4-- From owner-freebsd-current@freebsd.org Sat Mar 13 20:13:24 2021 Return-Path: Delivered-To: freebsd-current@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 DE9D35A97C1 for ; Sat, 13 Mar 2021 20:13:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DyYlm52zXz3Lgk for ; Sat, 13 Mar 2021 20:13:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: by mailman.nyi.freebsd.org (Postfix) id AD3695A97C0; Sat, 13 Mar 2021 20:13:24 +0000 (UTC) Delivered-To: current@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 ACFC75A974F for ; Sat, 13 Mar 2021 20:13:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyYlm3ZSpz3LSN for ; Sat, 13 Mar 2021 20:13:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id DE24C1C569; Sat, 13 Mar 2021 15:13:15 -0500 (EST) Subject: Re: On 14-CURRENT: no ports options anymore? To: "Hartmann, O." Cc: FreeBSD Current References: <20210313201702.5f9dfa9b@hermann.fritz.box> <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> <509410723.637403.1615665167513@mail.yahoo.com> <20210313210002.30ad4345@hermann.fritz.box> From: Michael Butler Message-ID: <52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net> Date: Sat, 13 Mar 2021 15:13:15 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210313210002.30ad4345@hermann.fritz.box> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-NZ Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DyYlm3ZSpz3LSN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 20:13:24 -0000 On 3/13/21 3:00 PM, Hartmann, O. wrote: > On Sat, 13 Mar 2021 19:52:47 +0000 (UTC) > Filippo Moretti via freebsd-current wrote: > >> >> I had the same problem in console modeFiippo >> On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser wrote: >> >> Am 13.03.21 um 20:17 schrieb Hartmann, O.: >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set >>> options via "make config" or via poudriere accordingly. I always get "===> Options >>> unchanged" (when options has been already set and I'd expect a dialog menu). >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64). >>> >>> I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. >>> >>> How to fix this? What happened? >> >> Hi Oliver, >> >> please check your TERM setting and test with a trivial setting >> if it is not one of xterm, vt100 or vt320 (for example). >> >> I had this problem when my TERM variable was xterm-color, which >> used to be supported but apparently no longer is. >> >> Regards, STefan > > [...] > > on one of the hosts (non-X11), loged in via ssh, the settings are: > > # echo $TERM > xterm > cd /usr/ports/www/apache24 > make config > ===> Options unchanged (no menu popping up) > I ran into something similar where dialog4ports would dump core after an upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me, imb From owner-freebsd-current@freebsd.org Sat Mar 13 20:27:30 2021 Return-Path: Delivered-To: freebsd-current@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 DBD0E5AA46B for ; Sat, 13 Mar 2021 20:27:30 +0000 (UTC) (envelope-from filippomore@yahoo.com) 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 4DyZ424P8rz3Mtr for ; Sat, 13 Mar 2021 20:27:30 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 96CA55AA6D8; Sat, 13 Mar 2021 20:27:30 +0000 (UTC) Delivered-To: current@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 968DC5AA468 for ; Sat, 13 Mar 2021 20:27:30 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 4DyZ4162g0z3Myh for ; Sat, 13 Mar 2021 20:27:29 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615667248; bh=vwFV+3KcxbMGLCUejlHjflP2NgGZVF6T+S935QCeTpc=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=iGq/8pw3bywlk8cFQQjTmhIhhLgNHM4Ykgsgm1di5jo0HYEV0tGH275leZcwlxwcMy51tKTYZ/IZ9ODu+JEWiKZ47e3SZPwfnqiibtP/km/SkXMhUNJ8R4uu4qYu/Rag5eBE+jC+4l1yTC44b7DsiSH6jXJTs8drAVR1haEaa4DSPdagP7XlwTufEVmEQECNCya1BSNKwuCB/usXKpSbXRVYqxkRtn1aHWJbV4aDuhzY3UzybmlT0p5SxSobuj3TsPpHz3pORoq3bjPdCZUGCEYwHhzqAYpUsL2Qogs4VD5Eo8PH4VsXZX1+ny+FLSdqQDo4eABajEUo7pZ50D2P4Q== X-YMail-OSG: lm3cGGgVM1mAzYIiVTbtZHeiCJcPKw5cWG.fgPvtwabFMlsIRb6LdXDbxbHCRzh wvSQU40ZjxuMFrcR7zUZJYPy_EoGoDB7EmqHLgBBcLs2NipAzGXr6fTrY6UkujSmZCBumSy5xyIr dVlWpvHP7t0ye8r6CIFb8WjGaeZ2D6RohZeXCodLMsK_wMb6kOIw5O_.bGnPgvIm4Z0V3yMiI6zb SAI4YmAcOoRvoZEyIpzge.sVryaZPgsi3vhZR8oEA1fana8qpET.PAIlX5bnoCURXxtStINQU0EN wJE5Zp.iVnID20vW0o8877yXK6iC_jjSeypI21wLVARIIgNi.qzDacXAlKMrgvuRCd7VfKdQ7h0L lj4a3lLwyPuySQtxKMpwayoUJTdVkBKKPgroBr8LTOSTUWIsa3p8r3QnsAzCGVZJbUAX5bKEIWYI p9GDeCLJ9cIM0MLqzqw4uq2xV2JAR75XxrrBFJQ37_tw9SsLNBNPgDiISsdmVqQrtzi5oEcugzrp 4tnyAtW2ezqdSVZfjYS_a5Y1inbFskShNL07mnUJtx0ZYvoNYgDrAkgkkfJBd9Xvtvla7tAkw.rw xXgVetTjjzWdtPAF1cU20wJnUWiZ1RW.y6c4HWo9eoNksf29Jwwa.bqe72NTvSJMAPaV937dtpeA exJAe7wOluGJAcGWAkOqqHtEXRGo16O5GXM.9lQeNUeuTEBFPw1c6eIcdveHhd3Qp.5KSTeafznG OtGcXMhxt7yewt0tQIrPPnoBLP1n_8rq9WQzOjdA7QlK_k_wcCMzp6H4KC6DlLJcfcx1m_8nWP_g 6CFKHa1KZCTtp487qTxZ4yQiuqlEnyV4UlXw34F4a6eXXiqbRvbfH83QFQLcgdNDciZJ6vT9dKdu Emf9eJrpg1y2IugNubefU5NmHMH9QBSks7eAaCbT48LHraZhzOfMC3AGyEXr7YLFDE.An0Q9GIdY T64C6mkiHOQZkwJcZmVj6ZLYpy227UqeDEmXU9kITvfkVf31ukC3Nv9XpB8KcZ6kLkg5Gwt1jnQF VNKli.KOmlDzaw6LAur3jZvfC4Y36G5CC01yWp6YwXTqiAsF5DBIAsjZWk7_40vCeIutgYtmgIix qf1pHu25oV6SqGoivwPnC4Wfak7Q2wiF7WhW54sFZIQvUzWjJFmoTpUlASywHpbGJhA3.dfZWfRR tzX_3bvuzijMhgPnYh9Yox9f4K.n1Zq_2aA4DP3QZY_ookjbhgL4_4r7Kb4B.M5Zd6dHTBDhrAUI p3Y.75AuWMIprB7mW4ZmzSMeQe75zGLnjrhhRA7GIaAFs3FOEx1UZV.tBaZv0lLxjw09Ao_D6Rki ZKRHFBJbXNf9x1w67zOlBauOwQzbbDJtKF6iJYZ1CusNPsgNz3Lx1kEYQVKqG5s_nSEJgos4blWF Mn9B_AGombBI.pDam1.sdixZoTNpy3PnCM6wIOoPXZFm4IHfVdLjTVaZf1VtKoSeSL2Ts2qUsAv_ u4faIyE3L4y35omMDKF7aQQ5BHgiyaDeHCxjFkkL6imLz5dEz6URUZJhO06xwAcAIsCIz.A_VM1c _69HdcscMKqpGEm6PEZ_sk54CZO.lMFfsKBZmT.IQk3va.LRpTUicH9WwRSoc8kzF3hUaZwop27f WNbEatJLUCrlN5yqQXfwRycigtpbRh9iUu9Ge_beJdtp20sfEVSZ1PQ9aWDubfnROzGAPmpRDvIL _iQYmtXJiKbesQWPZAdgie65EugwCsPStgzwYM7aswSmg9_8I1k3uAGnXEmS9MG7AnHJtLkuAekN WguMScKyfbFCWs08R746q0ILHDXO0SHMGwO1mApcPAXmGkaHyrGiKH8ZtMNCc4BKUd4mKJM4e4rj FDA8zcZL2HLsWwp9guWFeapvrRgglr6IBs2Rs8CZE_Bhk.Pm0pa8gRoUbo2dN91Y76vabScoAUT9 ADXdgv5QCTg7kKpPmxuzFgGwUD9ehKGDgljaujRqUk8sVqUflcV9vOvf_xkWl_fzRc0uolm7WSas CCYsqUu6uXN_S.Ahit_dd2ak_u1A_t4.BhEhko.iljkuoVLNysWsJvwaWEgHKHP0VWFcFVrGSYhS bE8FbSMeF9cxasSpEodvwxpzmBlNfWXZLlB55iqeMb2Bh4Q9zEFcoejQ2pzm6woVHSx1rw1KXm1o gb1_oU0a6uLweXQLJ45RB90v6.HedLDcYg7z654QRObaFZX1gmYh4f0.TksSmu9e5SjnrOpaR17i vZtLGNYx0cBLxyty_9yazQ0j58qYhZrcabAaiuB3VY8o2BgXiLgOIDCUC9_4VN5_HBc2b.ODAMUa keFRQeNo.5JQHuehBUqEKwHns9BKX.1SdkvIwLOkMMKELPW3IIfB3ULOHZjFFyXSnIQpRweEahXk _2ZAJDroTnnclm6Uw8Ji2HH4bu1fcYPQDLq2TCK44wWkeGSnbPzx8qRpOXHqsJr2pQmVvHfDNz78 TTR0j6gzI X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sat, 13 Mar 2021 20:27:28 +0000 Date: Sat, 13 Mar 2021 20:27:23 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <522683978.652277.1615667243487@mail.yahoo.com> In-Reply-To: <52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net> References: <20210313201702.5f9dfa9b@hermann.fritz.box> <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> <509410723.637403.1615665167513@mail.yahoo.com> <20210313210002.30ad4345@hermann.fritz.box> <52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net> Subject: Re: On 14-CURRENT: no ports options anymore? MIME-Version: 1.0 X-Mailer: WebService/1.1.17936 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:86.0) Gecko/20100101 Firefox/86.0 X-Rspamd-Queue-Id: 4DyZ4162g0z3Myh X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.186.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.163.186.205:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[66.163.186.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.186.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 20:27:30 -0000 > Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,for me to= o Thank youFilippo On Saturday, March 13, 2021, 9:13:46 PM GMT+1, Michael Butler via freeb= sd-current wrote: =20 =20 On 3/13/21 3:00 PM, Hartmann, O. wrote: > On Sat, 13 Mar 2021 19:52:47 +0000 (UTC) > Filippo Moretti via freebsd-current wrote: >=20 >>=C2=A0=20 >> I had the same problem in console modeFiippo >>=C2=A0 =C2=A0 =C2=A0 On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefa= n Esser wrote: >> >>=C2=A0 Am 13.03.21 um 20:17 schrieb Hartmann, O.: >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when tr= ying to set >>> options via "make config" or via poudriere accordingly. I always get "= =3D=3D=3D> Options >>> unchanged" (when options has been already set and I'd expect a dialog m= enu). >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is a= t FreeBSD >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 202= 1 amd64). >>> >>> I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. >>> >>> How to fix this? What happened? >> >> Hi Oliver, >> >> please check your TERM setting and test with a trivial setting >> if it is not one of xterm, vt100 or vt320 (for example). >> >> I had this problem when my TERM variable was xterm-color, which >> used to be supported but apparently no longer is. >> >> Regards, STefan >=20 > [...] >=20 > on one of the hosts (non-X11), loged in via ssh, the settings are: >=20 > # echo $TERM > xterm > cd /usr/ports/www/apache24 > make config > =3D=3D=3D> Options unchanged (no menu popping up) >=20 I ran into something similar where dialog4ports would dump core after an=20 upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me, =C2=A0=C2=A0=C2=A0 imb _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" =20 From owner-freebsd-current@freebsd.org Sat Mar 13 20:58:34 2021 Return-Path: Delivered-To: freebsd-current@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 56B935AB4D4; Sat, 13 Mar 2021 20:58:34 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyZls3DD4z3PqC; Sat, 13 Mar 2021 20:58:33 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4DyZlk0DQ3z6dPY; Sat, 13 Mar 2021 21:58:26 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id fMdlHw3GC5J2; Sat, 13 Mar 2021 21:58:24 +0100 (CET) Subject: Re: On 14-CURRENT: no ports options anymore? To: "Hartmann, O." , FreeBSD Ports Cc: FreeBSD CURRENT References: <20210313201702.5f9dfa9b@hermann.fritz.box> From: Guido Falsi Message-ID: <8a39cc8f-df2b-8a43-54c4-44eebb4b12de@madpilot.net> Date: Sat, 13 Mar 2021 21:58:23 +0100 In-Reply-To: <20210313201702.5f9dfa9b@hermann.fritz.box> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DyZls3DD4z3PqC X-Spamd-Bar: / X-Spamd-Result: default: False [-0.76 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[159.69.1.99:from]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[159.69.1.99:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-0.76)[-0.763]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-ports] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 20:58:34 -0000 On 13/03/21 20:17, Hartmann, O. wrote: > Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set > options via "make config" or via poudriere accordingly. I always get "===> Options > unchanged" (when options has been already set and I'd expect a dialog menu). > This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is at FreeBSD > 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2021 amd64). > > I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. > > How to fix this? What happened? I encountered something similar, some base shared library has changed, guess this is related with the ncurses changes in base. If I remember correctly force reinstalling dialog4ports package fixed it. Make sure you reinstall a freshly rebuilt one. Most probably anything using ncurses will require rebuild/reinstall. The cause is dialog4ports failing to start and the system sees no option changed. If that's not enough try # ldd -v /usr/local/bin/dialog4ports And see if it reports some useful information. -- Guido Falsi From owner-freebsd-current@freebsd.org Sat Mar 13 21:03:25 2021 Return-Path: Delivered-To: freebsd-current@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 16B1D5AB74F; Sat, 13 Mar 2021 21:03:25 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DyZsS5ZRmz3Qkn; Sat, 13 Mar 2021 21:03:24 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615669390; bh=R8cDdzfwkIh0Cfp+EnMXUwMWGMpvJLQtwXdwzYStqk0=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References; b=aHZJzE/4/bb8wkepgNvvDwIFSTtNeQfVTpO8xlBkd0wR1muq3aW/9E35dsg/tMUIy dEfvMzcKh81KskF4pC0F5dFQmFiqt5DPnf/wP3ltX4RtcEkB5H4G0diZSdp445CbP6 HhLReIMKuO9ioA7sPaNrYUj1klvaU9EjCmv+uZNs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.14.8.154]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MSc1L-1l9w630lRZ-00SzCC; Sat, 13 Mar 2021 22:03:10 +0100 Date: Sat, 13 Mar 2021 22:03:01 +0100 From: "Hartmann, O." To: Michael Butler via freebsd-current Cc: Michael Butler , FreeBSD Current Subject: Re: On 14-CURRENT: no ports options anymore? Message-ID: <20210313220301.28db1d0f@hermann.fritz.box> In-Reply-To: <52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net> References: <20210313201702.5f9dfa9b@hermann.fritz.box> <25cd3ca3-edb6-8b7a-8ad5-f0737d8bd493@freebsd.org> <509410723.637403.1615665167513@mail.yahoo.com> <20210313210002.30ad4345@hermann.fritz.box> <52964883-05ce-66cc-4d6f-9797746a9a62@protected-networks.net> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/pKvg+lh/Uqtr0traoqMY_l_"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:xIm2IC36T8nbHQp856mBFMrd/V2Bkm27c+Hw/G28SJLDMZ3Z3GE 7jhM97eZ6BA72j1KWusdKANxTOBn6ObV0F13ogvl9IdXVme7lozikTf5JJ/JKuS21QeXnjm 4sWYFrohw8ngeRLCmWjOJ2tEUUNdfYrp2cUhaI/zvqBTh1zf7yvyZgRToS6E7a4uopVdiil gnJJw107YOw1ohaZBsB8Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:a8QNr92hT1c=:AdXAmZzYLt6lHofeb+p72R XeJgqtHkEQsZKe25JFMCPFH/aWUv3IRsl+2Ts1o2KiabPDPwVrO772z4w4OosvVjEuTr3zIFP Xmy8xtd9W0PWNvRJAtBRrKdp81AR5045vWbAf6T/rTZ6OU/ECE19VIr9MyPO2Zkfvmi5dvXGP tNN1c8Tt0ussyBA4nl3UQ0V/jbWiFA3boOiO/fTNkNvGhrraMwNQm06f8Jlwugq/sPNzkf1jv bjZkm1OAKfjW2xslb3PITKGoBA25hJwkqzT3WMwXX5EyhzBwkluhiOYuHSUhPJKA2jVv87ZZx EAvpSJR5c5E9LKNdrP/Qv2KKz5V1xVHxAzAwTOUuaLo2ENx9CbE+9VwcNeATIgLiiI6jljeit wZto2+08zoC4Cw9BWYA4jh17IPEz3f51jJZXsJvfPJu9XJTf8q1C7X1QLD0cT4+2GHBmz2wKG MFZj42LZPT4mVFxjoZ1xNJKxOb9gQ5OC9qClgHSuxe/Vave1LmZz4Ue9QlOazGUcEUNfOMl4n ekMM8Gc9FeIIQSDPU6zL2rdRmqDJuAq0pcIVSAuJivNaJsYTyQv9FSZc1DsiDjx2RyBbtNH6l uiRslnjYIMWI4dXj/o3ey/2OiJWdkxYmH47sJJxvsybbf5lNsPDJAOuqp/Lt1k+L/vKeWvDHU ylmQvMmZB9nPVl4XUtG43VBYAQJX8wwR6KaNPSQkRgrYf6JtGmT5810u5BW3BpVceS03kJDmf TiilDygDbcnrGF67BboT14zWps1KgKTkVVu+tCvwh3TR0AJ7TxmX3uySWh7AtsM4Q3zFMl+kI u13vOVc1QYRhXZuGWRPMA0ApQWbevlssOkSH5dKpve3ZJfbuEcA8dzBy3UQVtxq2rD7GbMOry wfjOejW2zxxpFNb24spA== X-Rspamd-Queue-Id: 4DyZsS5ZRmz3Qkn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 21:03:25 -0000 --Sig_/pKvg+lh/Uqtr0traoqMY_l_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 13 Mar 2021 15:13:15 -0500 Michael Butler via freebsd-current wrote: > On 3/13/21 3:00 PM, Hartmann, O. wrote: > > On Sat, 13 Mar 2021 19:52:47 +0000 (UTC) > > Filippo Moretti via freebsd-current wrote: > > =20 > >> =20 > >> I had the same problem in console modeFiippo > >> On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser > >> wrote: > >> > >> Am 13.03.21 um 20:17 schrieb Hartmann, O.: =20 > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when = trying to set > >>> options via "make config" or via poudriere accordingly. I always get = "=3D=3D=3D> Options > >>> unchanged" (when options has been already set and I'd expect a dialog= menu). > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is= at FreeBSD > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 2= 021 amd64). > >>> > >>> I do not see such a behaviour with 13-STABLE, 12-STABLE, 12.2-RELENG. > >>> > >>> How to fix this? What happened? =20 > >> > >> Hi Oliver, > >> > >> please check your TERM setting and test with a trivial setting > >> if it is not one of xterm, vt100 or vt320 (for example). > >> > >> I had this problem when my TERM variable was xterm-color, which > >> used to be supported but apparently no longer is. > >> > >> Regards, STefan =20 > >=20 > > [...] > >=20 > > on one of the hosts (non-X11), loged in via ssh, the settings are: > >=20 > > # echo $TERM > > xterm > > cd /usr/ports/www/apache24 > > make config =20 > > =3D=3D=3D> Options unchanged (no menu popping up) =20 > > =20 >=20 > I ran into something similar where dialog4ports would dump core after an= =20 > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me, >=20 > imb Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure t= hat after some ncurses changes in 14-CURRENT I've rebuilt every single port on all 14-CURR= ENT systems after that incident, bad luck. Thanks. oh --Sig_/pKvg+lh/Uqtr0traoqMY_l_ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYE0ohQAKCRA4N1ZZPba5 RwslAQDkxGKPpLUvS5gVdEliIEfxCOLDlg/g28IvcorNyfiL5wEA3CS+KLfn1Ivs HSlpLwNUCMATushsHJwPjOnJsryBWwk= =2yOi -----END PGP SIGNATURE----- --Sig_/pKvg+lh/Uqtr0traoqMY_l_-- From owner-freebsd-current@freebsd.org Sat Mar 13 23:49:11 2021 Return-Path: Delivered-To: freebsd-current@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 F03CE5AF851; Sat, 13 Mar 2021 23:49:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DyfXk2pLPz3qsX; Sat, 13 Mar 2021 23:49:10 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-oo1-xc36.google.com with SMTP id c13-20020a4ab18d0000b02901b5b67cff5eso2482885ooo.2; Sat, 13 Mar 2021 15:49:10 -0800 (PST) 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=PRXpVvocV5d6LPQdH7N5nEMKO1uf5qby74KMFSkja4A=; b=YFqUWXRZvNZqDBwvOuOfsCmZ9quOLLpFkav2VOCeJL2CxsROxdBOo+3R0AUbCebLux urytkFekYKfMRVo8nSQTeeUcWwLRmzi3uhvBjmz+NSX1Hv84d13UnYeT6Z2CiR2hmqXE z6N5HEryG7g6eLfcgDgf7kiVCePY/FeazA0SuNdoa/duBgGlA49gnxdMMTW01XGPZa4Z W7h+2GXsLXArSb3J14sLDom55F6bpUOYsBjp3eHbwPwwZgVS9r4W5/MB5sEus5hxFbzz MLLmqWHlczhkwjz5OnvC3VwxZq+zwVzU3zeufiCnBNdYtM7pM0WtJ4SpaYFnmYAMu9ZH Y26Q== 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=PRXpVvocV5d6LPQdH7N5nEMKO1uf5qby74KMFSkja4A=; b=VdoqGjY7Ff7PSNwHnCP8E68w1Q0mDjpbCULrf+8u+jZg/XzMelYzrWKwEA7FWtP05R qbbkv/N4QjCIuA3VZY7IsEEOWHzdYTmEX6C6p9zlQW7o3O29Nc8X6f/urxoi+jZEqc+5 TAy6sxRWy7FTAxohr173X6dnLNiNTpVrffACpA96+caqfGtrreb9NrVMhjueKne+H8eS Z8ve9tYhhYD9C2TFPACnLv2rYn8vCXuArDa/FTM/usb1sCkrwhibN1pTvMwHKBlcuyv2 bVJ7cxJK16fnuyrOqJ+7N+p0WxaRz4AvlWQ9W/pxDrSb04XL7Z5m078xZ8reT8Mj2n4f +oag== X-Gm-Message-State: AOAM530lK+2b67+07R6xK3VdhHmZosUpTH6vwQTvD9r4MylOtpEZ+qVv cgmrf1znxz3jMA4EBSO+epGjHtTKNYvZTQNxdvRLhQFc+PQ= X-Google-Smtp-Source: ABdhPJywwx9dSeODnLb8UWdU0cwwjP+WoJPEjkM9bUUeUWUkA/5fomHh5YsN3k1LcKQuEjX/tGXsR7pxf4KBYNRCFBI= X-Received: by 2002:a4a:bd97:: with SMTP id k23mr8404138oop.13.1615679349102; Sat, 13 Mar 2021 15:49:09 -0800 (PST) MIME-Version: 1.0 References: <20210313201702.5f9dfa9b@hermann.fritz.box> <8a39cc8f-df2b-8a43-54c4-44eebb4b12de@madpilot.net> <3779241B-6501-45A5-A63C-7A10DC9FDBF0@gushi.org> In-Reply-To: <3779241B-6501-45A5-A63C-7A10DC9FDBF0@gushi.org> From: Kevin Oberman Date: Sat, 13 Mar 2021 15:48:53 -0800 Message-ID: Subject: Re: On 14-CURRENT: no ports options anymore? To: "Dan Mahoney (Ports)" Cc: Guido Falsi , "Hartmann, O." , FreeBSD Ports , FreeBSD CURRENT X-Rspamd-Queue-Id: 4DyfXk2pLPz3qsX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YFqUWXRZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::c36 as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::c36:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::c36:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c36:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ports,freebsd-current] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 23:49:12 -0000 On Sat, Mar 13, 2021 at 2:51 PM Dan Mahoney (Ports) wrote: > If this isn=E2=80=99t at least in /usr/ports/UPDATING it sure should be. > > -Dan > Ditto! While it did not take me long to discover that the ncurses shareable had bumped the version, I wasted a lot of time rebuilding ports one by one. At least a heads-up would have been nice. The way to do this is unclear, though, as it was a base library update. I assume that it only bit those running current or 13. Those running 13-STABLE, as I was, had no warning. I'm not sure a note in UPDATING would have been appropriate, but a post to stable@ and current@ would have been nice. Or, did I miss them? This would also be made VERY clear in the 13.0 Release Notes. I suspect installing misc/compat12x would have worked. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683