From owner-freebsd-current@freebsd.org Sun Jul 12 03:33:37 2020 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 0188B351635 for ; Sun, 12 Jul 2020 03:33:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4C6k5TfLz3yCd for ; Sun, 12 Jul 2020 03:33:34 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 06C3XXca063426 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 Jul 2020 20:33:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 06C3XWrj063425; Sat, 11 Jul 2020 20:33:33 -0700 (PDT) (envelope-from fbsd) Date: Sat, 11 Jul 2020 20:33:32 -0700 From: bob prohaska To: freebsd-current@freebsd.org Cc: bob prohaska Subject: Is there any error checking on swap? Message-ID: <20200712033332.GA63411@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4B4C6k5TfLz3yCd X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.95 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.037]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.33)[0.328]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.69)[0.687]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 03:33:37 -0000 Is there any error checking on swap traffic, along the lines of a checksum or parity test? Just curious what happens if a page written out is corrupted when it comes back. Thanks for reading, bob prohaska From owner-freebsd-current@freebsd.org Sun Jul 12 06:37:12 2020 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 BFA7135996D for ; Sun, 12 Jul 2020 06:37:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4B4HBb4Gbvz4BsV for ; Sun, 12 Jul 2020 06:37:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: UBh7QREVM1lykxwMs7RxZ2Py_c4HovBhUQXuIjSI2LWAG1OuLiPtUw1fVi0fG5n tsScTBXZPL3ST8GdvRJcJVAwompHzdvBJmccNu0LFLG0zQBNibfZTvEjWATheKUmD6S3N_uPfvfC TVxZSV1usqhCO1otVjCVFrrATXWKXE4eMGZBi53gZz_dvMB1ZrAGBtFo73dgq5ohSZfauzySRNe_ U8G_8Uz8T79ZJXQZPI0nAeX65BxswzN8pZOGyEQc9QuZLqqGt9FqyaYzZ2eNRObOxWl7w.pUQS_. WzwQgolqJh0pJMNw.1cnk7oczbTRumsDKjxvnQn6WLBy0eCVDB9__g_YsZZ757QSon1b.nPjS3Oh OUYyxgRrJcfKrf93W8HJ9OQTnlnJ6FM4izGIj0ee4FZNTPgz_A5qj098PosN_4V3fpXVuVmfM_eq nnL8D2WWCqQdEDNYNrcfKb7r_6NCAVRMaFLBX7K56UK6RCOivewiP6pocD.k9VpHSMQJ9D2Ng8Pz YNiW9zqo4xT4448EhmcNoAZ6uJOcVSjRbyfaYXi7sbKEka7r.joSfZb3ockUKZS1nKH8LNWNn9sJ lXuIjrnyiOn8lc9dn.UrqIUZJXVgbYJ0JJVg8U97nP41DY46wM0rEp_aLtFjO68ta.5QyAzYBI8Y 9uq82Vl1.kN4hLmZ5beaJIFfI8G9gJimcCAcnekjlJpKW9qgeW.51HVCawFg0kaAdHC_595ctwuE V_Qkl2I28GS921aukS8DISSeRMDMFdqZcNB9qZyC3lkiRpHmQ5_5KPdA0Ajmk1Ap.P1hMdgU6QSL Qk_L.lDdt.VaoSNbwaZieW8L8NWYvIxdAT_Che0R9gf88Z2jbk96fe2QuQWy_tXt83M0emi.6GFH UTeQgaHsTQu5ncCNuIZeGDCE6gsvCaw_sPjGwUzuCBsiW2trZEpgCaj3Lb6.7kbEWw9Q_eS4i7E8 S3qzHqMd4ofv1ZrUWwhqxn6X8gRxrOkQ8qXOSwEObBEofhqv36vTGwjExysOEy6QWWxwZuLKU2DV UqAyuKLRUEunnj95WUpVoR0tykyKcuoSoM.ifXHCiQKY7tB8mYUrkBqlYWf82gr.33xK8P7QLzEb Ooa7FSiK3z5jqsqgpjBFx7.NfVIbKVa8PbzSWn5FPHZ5ZQC0oTTrUUjvqkmfNcmxElT9fd4uoS4_ We5Y1UTHoKfoF8HMZUu_4LGNv0FQQOVKR6kcPfZq4bRG54efSyNVZuRGEpAi6KxwWpWDpqeSiqze n.xJFKvPRH7cInnqRrJRQWOFAXv7tTOqDuST_HWvfGYDMCwUFC5t8oq.0pSSG7V1MAv4TTwSezYd sgqfrUnLIpzz3JSWhFQXPryS5kxmyG0vV2nMOc1Mu4B0.mM9hrgLi7qLbXNgEfjOKvibyYaLxWq5 Qm48o5oImiXiARETklhPWpLZDAqO7pzxC44RROueWP6fkxyuRmf8dZXl903J3lJU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Jul 2020 06:37:10 +0000 Received: by smtp422.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c795fcc920c17f9012ac80620effc32; Sun, 12 Jul 2020 06:37:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) From: Mark Millard In-Reply-To: <9FBC6DEB-23FA-4FA2-AB10-3D6BDC4CE010@yahoo.com> Date: Sat, 11 Jul 2020 23:37:07 -0700 Cc: Andrew Turner , freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <4FACEC9A-4E07-4B5C-A184-7B8049CE3E1C@yahoo.com> References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> <9FBC6DEB-23FA-4FA2-AB10-3D6BDC4CE010@yahoo.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B4HBb4Gbvz4BsV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 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(-0.27)[-0.272]; FREEMAIL_TO(0.00)[protonmail.com]; 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:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.01)[-1.013]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 06:37:12 -0000 > On 2020-Jul-11, at 15:12, Mark Millard wrote: >=20 >=20 >>=20 >> On 2020-Jul-11, at 14:45, Robert Crowston = wrote: >>=20 >> So what is the mistake I made here? >>=20 >> Should I have given a globally unique name as the first argument to = DRIVER_MODULE()? I didn't see that in the man page, and other examples = of pcib drivers apparently get away with it. >>=20 >> I did notice the weird message about "driver already loaded from = kernel". I wondered if that meant I was dragging in code to the core = kernel, that would otherwise live in an external module? >>=20 >> Let me know how I can help fix it! >>=20 >> -- RHC. >=20 > It is not an area of expertise for me. I've spent hours just > getting to the point of sending the notes that I have sent. >=20 Having found no evidence of any likely disaster from trying the experiment, I've tried: # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision = 363021) +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) @@ -739,5 +739,5 @@ sizeof(struct bcm_pcib_softc), generic_pcie_fdt_driver); =20 static devclass_t bcm_pcib_devclass; -DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, = 0); +DRIVER_MODULE(bcm_pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, = 0, 0); =20 This was enough of a change for Ethernet and USB to become available again on the OverDrive 1000. Apparently one must search all existing DRIVER_MODULE use and then pick naming to have the new DRIVER_MODULE(NAME,BUSNAME,... end up with the NAME,BUSNAME as a unique combination of names (or combinations for when there is BUSNAME0, BUSNAME1, . . .). I also updated the USB3 SSD I use for booting either RPi4 or Rock64. Be warned that the RPi4 boots are via UEFI v1.16 use instead of by sysutils/u-boot-rpi4 use. I do not have things set up for sysutils/u-boot-rpi4 as stands. The SSD booted both contexts fine and the USB worked like normal. On the Rock64, the built-in EtherNet also worked fine. For the RPi4, a USB3 EtherNet adapter is used and it worked fine. If someone checks sysutils/u-boot-rpi4 operation and finds that it works, then I expect that such a patch as above is all that is required. Note: If future bcmDDDDD's need similar code, care will need to be taken naming ???? in DRIVER_MODULE(????,... for them so that uniqueness is maintained. My use of "bcm_" to match the context is not the only prefix that would lead to unique naming currently. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Jul 12 07:29:17 2020 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 6482935B041 for ; Sun, 12 Jul 2020 07:29:17 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4JLh1nZwz4F8W for ; Sun, 12 Jul 2020 07:29:15 +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 06C7TCen040261 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 00:29:13 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06C7TC3g040260; Sun, 12 Jul 2020 00:29:12 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 00:29:12 -0700 From: John-Mark Gurney To: bob prohaska Cc: freebsd-current@freebsd.org Subject: Re: Is there any error checking on swap? Message-ID: <20200712072911.GG4213@funkthat.com> Mail-Followup-To: bob prohaska , freebsd-current@freebsd.org References: <20200712033332.GA63411@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200712033332.GA63411@www.zefox.net> 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]); Sun, 12 Jul 2020 00:29:13 -0700 (PDT) X-Rspamd-Queue-Id: 4B4JLh1nZwz4F8W 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 [3.68 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.34)[0.341]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.53)[0.529]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.61)[0.606]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 07:29:17 -0000 bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > Is there any error checking on swap traffic, along the lines of > a checksum or parity test? > > Just curious what happens if a page written out is corrupted when > it comes back. Looks like it doesn't: https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 -- 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 Sun Jul 12 07:31:15 2020 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 A8F7535B484; Sun, 12 Jul 2020 07:31:15 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 4B4JNy2RZPz4FWK; Sun, 12 Jul 2020 07:31:14 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id f18so9920858wml.3; Sun, 12 Jul 2020 00:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:reply-to:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UUB6qR05EYUhK+nl6j+/FveBlGjHcMTvWadtvbjevHo=; b=JdtNCEXtc8Qq2CujQPo6WGFsMzCf/fyfYQJe7Dw8WSw0kkAniI5ieiQEbzmLuL0n3S OJyA/BzQDsxhBfmFcR7dmjsrVXxqG/WRAWfonJRYz1LD6t67VIIKzdteTwTSsNVCPivj HtI1MxEYqLvaJwEnNkVhvzitpNaJmbWfMlnfI/CK8gJ/cWJI7HBFv4qRDW9dtk/ym7e/ gn9wSSfCgAuJ++Nl60E1cc/EcclA7lzsi69gEryeLvHMOSc0sKMUPSAf4OqKO8xrQQ9v OwiaYThwHQaO6BJhuysu99BmRrqHjLX3dBOgzpVrsQE0Na4d4IKk3yn7ylGPhxtpKjy8 zv8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UUB6qR05EYUhK+nl6j+/FveBlGjHcMTvWadtvbjevHo=; b=FSQTzrKbq8d+ErumxgDqzUfW8s7FuofH9e8lC7j5xgZlyl/VIzwuoz4PrEkfPWFmuw YdI4CscI7TLTZAo9kZvZSTfvGqCdA0I2/giioDYJ3JLizjiEHYxG4g1KWz0LcdZL/sOU HtyzxtHyPba3oPjml5KL3bfJzrNVRyPTU+QGEU/HHadKuh7P3/ik5MiAbTMdlsDeXRjG VR3QQoSyZn4BJH+uuPekFex7kMNBh7icQGy4V6WY5WJEBRpDxOgAIKooTYPov9uQgoZq zN55a6fWzcOuFFmceOB1aedWsIf2q4jTyoFIJYrR9cBZLZVmoWv3I3HPzRCBd/oF+FFE w86w== X-Gm-Message-State: AOAM531Y48S3mVwIt7ekg0gEZj7zZd+34FB797BV4L9sippLJ78wqACy Dztu2oIf8aCL/yC9j1tdj51hLO1hVCk= X-Google-Smtp-Source: ABdhPJzcFJIPN/e7WuntgRE0zJuUUvWkgCnoYHrjBl8MbWpa2Z8vSBcGs4iaZugaLLqXcASzzm6L0A== X-Received: by 2002:a1c:3bc1:: with SMTP id i184mr11516081wma.119.1594539072697; Sun, 12 Jul 2020 00:31:12 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id j6sm18556513wro.25.2020.07.12.00.31.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jul 2020 00:31:12 -0700 (PDT) Sender: Michal Meloun From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect) To: Mark Millard , Robert Crowston Cc: Andrew Turner , freebsd-arm , FreeBSD Current References: <6E0B6750-273C-468A-9233-E868B0674F34@yahoo.com> <8AA99118-C9C5-4CC7-83C6-2A85DFF9CBE1@yahoo.com> <334D89BD-2F7A-4BF1-AB96-2D6B273BBCD3@yahoo.com> <8CA66D0C-BA19-41D1-A67C-B54ED1B6EE79@yahoo.com> <9FBC6DEB-23FA-4FA2-AB10-3D6BDC4CE010@yahoo.com> <4FACEC9A-4E07-4B5C-A184-7B8049CE3E1C@yahoo.com> Message-ID: Date: Sun, 12 Jul 2020 09:31:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4FACEC9A-4E07-4B5C-A184-7B8049CE3E1C@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B4JNy2RZPz4FWK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JdtNCEXt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::341 as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-3.11 / 15.00]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.10)[-0.099]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.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]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.018]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::341:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 07:31:15 -0000 On 12.07.2020 8:37, Mark Millard via freebsd-arm wrote: > > >> On 2020-Jul-11, at 15:12, Mark Millard wrote: >> >> >>> >>> On 2020-Jul-11, at 14:45, Robert Crowston wrote: >>> >>> So what is the mistake I made here? >>> >>> Should I have given a globally unique name as the first argument to DRIVER_MODULE()? I didn't see that in the man page, and other examples of pcib drivers apparently get away with it. >>> >>> I did notice the weird message about "driver already loaded from kernel". I wondered if that meant I was dragging in code to the core kernel, that would otherwise live in an external module? >>> >>> Let me know how I can help fix it! >>> >>> -- RHC. >> >> It is not an area of expertise for me. I've spent hours just >> getting to the point of sending the notes that I have sent. >> > > Having found no evidence of any likely disaster from trying > the experiment, I've tried: > > # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c > =================================================================== > --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (revision 363021) > +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c (working copy) > @@ -739,5 +739,5 @@ > sizeof(struct bcm_pcib_softc), generic_pcie_fdt_driver); > > static devclass_t bcm_pcib_devclass; > -DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > +DRIVER_MODULE(bcm_pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0); > > > This was enough of a change for Ethernet and USB to become available > again on the OverDrive 1000. > > Apparently one must search all existing DRIVER_MODULE use and then > pick naming to have the new DRIVER_MODULE(NAME,BUSNAME,... end up > with the NAME,BUSNAME as a unique combination of names (or > combinations for when there is BUSNAME0, BUSNAME1, . . .). > > I also updated the USB3 SSD I use for booting either RPi4 > or Rock64. Be warned that the RPi4 boots are via > UEFI v1.16 use instead of by sysutils/u-boot-rpi4 use. > I do not have things set up for sysutils/u-boot-rpi4 as > stands. > > The SSD booted both contexts fine and the USB worked like > normal. On the Rock64, the built-in EtherNet also worked > fine. For the RPi4, a USB3 EtherNet adapter is used and > it worked fine. > > If someone checks sysutils/u-boot-rpi4 operation and finds > that it works, then I expect that such a patch as above is > all that is required. > > Note: If future bcmDDDDD's need similar code, care will > need to be taken naming ???? in DRIVER_MODULE(????,... > for them so that uniqueness is maintained. My use of > "bcm_" to match the context is not the only prefix that > would lead to unique naming currently. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Fixed in r363121. Thanks for the report. Michal Meloun From owner-freebsd-current@freebsd.org Sun Jul 12 07:57:41 2020 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 E19FE35BF4A; Sun, 12 Jul 2020 07:57:41 +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 4B4JzS5Rd5z4H2Q; Sun, 12 Jul 2020 07:57:40 +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 B5A00260276; Sun, 12 Jul 2020 09:57:32 +0200 (CEST) Subject: Re: slow USB 3.0 on -current To: freebsd-usb@FreeBSD.org, freebsd-current@FreeBSD.org References: <20200711224426.GC4213@funkthat.com> From: Hans Petter Selasky Message-ID: Date: Sun, 12 Jul 2020 09:57:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200711224426.GC4213@funkthat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B4JzS5Rd5z4H2Q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-0.89)[-0.895]; NEURAL_HAM_MEDIUM(-0.90)[-0.901]; NEURAL_HAM_SHORT(-0.21)[-0.207]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 07:57:41 -0000 On 2020-07-12 00:44, John-Mark Gurney wrote: > Hello, > > I'm having issues getting good ethernet performance from a USB ethernet > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > adapter only gets around 10MB/sec performance. During the transfer, > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > 100MB/sec+ w/o troubles. > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > Any hints on how to fix this? > > This may be related, but I'm also having issues w/ booting when I have > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > If I move the SD card reader to USB 2.0, the umass device will attach > and work. I have also attached a clip of the dmesg from that > happening. > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > the performance issues? Hi, Can you check the output from ifconfig. What is the actual link speed. I suspect it has something to do with the MII bus code/implementation. Also check output from "vmstat -i" during usage to see if the number of IRQ/s is low. --HPS From owner-freebsd-current@freebsd.org Sun Jul 12 15:37:49 2020 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 AC522366490 for ; Sun, 12 Jul 2020 15:37:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4WBN3yZXz4fKK for ; Sun, 12 Jul 2020 15:37:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 06CFbqB1064942 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 12 Jul 2020 08:37:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 06CFbqDG064941 for freebsd-current@freebsd.org; Sun, 12 Jul 2020 08:37:52 -0700 (PDT) (envelope-from fbsd) Date: Sun, 12 Jul 2020 08:37:51 -0700 From: bob prohaska To: freebsd-current@freebsd.org Subject: Re: Is there any error checking on swap? Message-ID: <20200712153751.GA64898@www.zefox.net> References: <20200712033332.GA63411@www.zefox.net> <20200712072911.GG4213@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200712072911.GG4213@funkthat.com> X-Rspamd-Queue-Id: 4B4WBN3yZXz4fKK X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [4.93 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.72)[0.724]; DMARC_NA(0.00)[zefox.net]; NEURAL_SPAM_SHORT(0.39)[0.386]; NEURAL_SPAM_LONG(0.92)[0.918]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 15:37:49 -0000 On Sun, Jul 12, 2020 at 12:29:12AM -0700, John-Mark Gurney wrote: > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > > Is there any error checking on swap traffic, along the lines of > > a checksum or parity test? > > > > Just curious what happens if a page written out is corrupted when > > it comes back. > > Looks like it doesn't: > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 > Certainly nothing about parity or checksums in the comments. All faith in the hardware, I guess.... Thanks for writing! bob prohaska From owner-freebsd-current@freebsd.org Sun Jul 12 21:46:37 2020 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 18D3836FAAE for ; Sun, 12 Jul 2020 21:46:37 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4gMv72mLz45gw for ; Sun, 12 Jul 2020 21:46:35 +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 06CLkXOH064306 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 14:46:33 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06CLkWFK064305; Sun, 12 Jul 2020 14:46:32 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 14:46:32 -0700 From: John-Mark Gurney To: bob prohaska Cc: freebsd-current@freebsd.org Subject: Re: Is there any error checking on swap? Message-ID: <20200712214632.GH4213@funkthat.com> Mail-Followup-To: bob prohaska , freebsd-current@freebsd.org References: <20200712033332.GA63411@www.zefox.net> <20200712072911.GG4213@funkthat.com> <20200712153751.GA64898@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200712153751.GA64898@www.zefox.net> 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]); Sun, 12 Jul 2020 14:46:33 -0700 (PDT) X-Rspamd-Queue-Id: 4B4gMv72mLz45gw 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 [4.34 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.62)[0.624]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.77)[0.769]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.75)[0.746]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 21:46:37 -0000 bob prohaska wrote this message on Sun, Jul 12, 2020 at 08:37 -0700: > On Sun, Jul 12, 2020 at 12:29:12AM -0700, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > > > Is there any error checking on swap traffic, along the lines of > > > a checksum or parity test? > > > > > > Just curious what happens if a page written out is corrupted when > > > it comes back. > > > > Looks like it doesn't: > > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=361965#l1389 > > > > Certainly nothing about parity or checksums in the comments. > All faith in the hardware, I guess.... > > Thanks for writing! It probably wouldn't be too hard to add the feature... Just expand the page entry to store a fletcher checksum or the like... Another option would be to try to use swap on ZFS, and use ZFS's builtin checksum feature: https://wiki.freebsd.org/RootOnZFS#ZFS_Swap_Volume -- 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 Sun Jul 12 21:54:53 2020 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 B8EB036FF94; Sun, 12 Jul 2020 21:54:53 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4gYS6hf1z46CW; Sun, 12 Jul 2020 21:54:52 +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 06CLso2A064479 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 14:54:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06CLsnK7064478; Sun, 12 Jul 2020 14:54:49 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 14:54:49 -0700 From: John-Mark Gurney To: Hans Petter Selasky Cc: freebsd-usb@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: slow USB 3.0 on -current Message-ID: <20200712215449.GI4213@funkthat.com> Mail-Followup-To: Hans Petter Selasky , freebsd-usb@FreeBSD.org, freebsd-current@FreeBSD.org References: <20200711224426.GC4213@funkthat.com> 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]); Sun, 12 Jul 2020 14:54:50 -0700 (PDT) X-Rspamd-Queue-Id: 4B4gYS6hf1z46CW 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 [3.35 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.61)[0.615]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.84)[0.842]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.70)[0.697]; 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]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 21:54:53 -0000 Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > On 2020-07-12 00:44, John-Mark Gurney wrote: > > Hello, > > > > I'm having issues getting good ethernet performance from a USB ethernet > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > adapter only gets around 10MB/sec performance. During the transfer, > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > 100MB/sec+ w/o troubles. > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > Any hints on how to fix this? > > > > This may be related, but I'm also having issues w/ booting when I have > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > and work. I have also attached a clip of the dmesg from that > > happening. > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > the performance issues? > > Can you check the output from ifconfig. What is the actual link speed. I > suspect it has something to do with the MII bus code/implementation. ifconfig is reporting it's 1000baseT. > Also check output from "vmstat -i" during usage to see if the number of > IRQ/s is low. Not sure what is considered low, but I'm seeing consistently around 7800 int/s for xhci0. -- 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 Sun Jul 12 22:06:57 2020 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 5BF75350407 for ; Sun, 12 Jul 2020 22:06:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (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 "anubis.delphij.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4gqN27Ffz46PJ for ; Sun, 12 Jul 2020 22:06:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from p51.home.us.delphij.net (unknown [IPv6:2601:646:8600:58ba:e670:b8ff:fe5c:4e69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id AC0CE45869 for ; Sun, 12 Jul 2020 15:06:54 -0700 (PDT) Reply-To: d@delphij.net To: freebsd-current@freebsd.org References: <20200712033332.GA63411@www.zefox.net> <20200712072911.GG4213@funkthat.com> From: Xin Li Autocrypt: addr=delphij@delphij.net; keydata= mQINBFuSR4oBEACvvEgwRIHs6IcSP/yaDtySF78Ji3rP29qdiQsxhMsOtvtffdbS56VApIWO UFb3/iN2gA8HwLvrmjijN0HEoLVX7na1WARmxRYzQMtApsZIUTtx7hnUYlsi2F5odZa6CDW9 a954DLRzYxiUwYDcu5Zjl9bglK1H8e/N9uC0Vuigr4teWfh86brzOyf819QzwFVYfMIK4ihw QGwMvTzbyVuCFy+LENkmcVYni70oQy6rZ5ktSuYbuOFvu7inRRfhSWPHziV7k+bW88sJ7xhv lBlegcnhkSudWX2M8tZ3MO1PJOcyys0CJlsBY5Weiog2lIPi05h/E9pZ9mc1Vud17iqDaL6w RaggOUhuPfDGCdO5ro82W4BZGeQMRnRF5Ntk+t2ShIH4nn3xRLV0E5nziCiKlgiMqOrz/ZTL QTVbHrCuiwD+fSK14y0oHbkOLYTYLlgh1JbwfY2Ty7elOYiWzyeJ7sJh2dF91NSEneWIOys3 mBpuvtU3nSzzTvAB48VV+Nbg1CpIOgNlPjj7uhIum/Z/VjUaJEyaLpTIRh0MVJVcbP7hXSqZ NA35EEZZVnWEOYdycm4CmEdeNPWkrAf2Ya77iR5VLGypwMlsUMQPh+sKVWDD38M8stFGBBNm d01Hi74Bsq5hKan654dOqMt5eYklrVj0ucMzFQtus7oE502UswARAQABtBxYaW4gTEkgPGRl bHBoaWpAZGVscGhpai5uZXQ+iQJUBBMBCgA+FiEEceNg5NEMZIki80nQQHl/fJX0g08FAluS R/YCGwMFCQmuhAAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQQHl/fJX0g0+2Og//bWpE F2V5/M5l6YW1T8oLcT9rIOH6oq9M0LMNRgFeiNNnilGIeeIgtOGBRueG4CZiZAvsRPJkrO70 1R2SrdkCIvwGUzUAxx1NfBWb+vgm4fgkW/MotGonceM5v0qfSKKXasWvDctkK28aG+IoQzmi FjXNW4+ju4zeQFYwD4ZDWqw9MqO0hVb24uW3dxtQhbfmOLgJ/PEDMQaFuANbW1c+iR0BQA3D Go/EeMY4kpN8on6Aqt/S/4JVltudfQ9OXdjQsC7netSaB9K3mHGt9aKAAB7RzlRY00DKkYS/ /eQwLzGPmK7yX13M68mMDjBs6mIR8t/E1S5OdBNhHRPNPlEbwugR4KaiCsN5yqzJoSV99fKY z2VyxjWPaG8yhHE+jmKUgIBKTfFUQEfkriQR4EASoeJ+soaMTiFDBij1Zw5n3ndLRFMB1ZCl fZLER36mAgW4m4kP83TWnDiJLxOxSOxifV8HpTFjff902H85cybg9KMwrfPDr6W19GGk5Vo1 fkza5krRMGbKWb7+74Evusi0ZxJLIOFwp5Y8eVqUMZaAD3f1ZX1M3pgXOp20QgAy+2KvMHij rLa4q+tMGRzYYD1BnFVSVdXAX5VOoTmHBcDz67DkuRwk2Byp1sgd407oEOmSwrNJlKS0TPCm xUJ2fdSQF+1/MMSRfee49vtMvz7cOrC5Ag0EW5JHigEQANiBmIFAfRNH3nzYNWC0yC+tfx3z sUwAsH1VaBM/cTib+yKtbBOSIlXWjJZWX3MHwoI/1LeGghB2mxkkX1L0pJ/vj1eXNR+sFZ32 0pYcl61Fxg/5fioG4QDTM4i3i7NR5PxDnc6UVaynSlII93DedRhZ1ROtdn4vyMgzsDiqhbL7 BthDOt5KxjqdRk4qRPSw7BovEqZLOcG5IJtf/zZUzRbM7SBljEbOAfekDGx1Br+RrYSD7/Ef Pwwzou9T8315IpBpIHyQF/dZNk3iFiB9Ed5CA71ZRYV5YoLWE9lL0j9kxOLQ5vHnX3mVq7QZ Bc7nzwZ6UhQgYmrG5+RWvuiPpGwvDRIsugJUGXucYkAQh5kuNblmkwpv6u9rNMjCNbzAylOa qdogra5EW+RUSbRz0b4iIr8nnZeAlh7BihCe7JjOwbDjoBEEEtSfVc4hD/LENqpcYVrChphf aOLB9YIXhnVDTVvMc9OklWT/81HzAaDQqOQCzEfY92199Ct9/CwRoQ2OpO8TO5+8A7b9Nb33 nmxMn09mb48ruRacMrfHxCWbgU4w9SEfbip4GcS5wGG6yTC+hw55Iwnnwus40NrJ0GEr8a4r cdsLbkvlyoNHB8ZGgyJ4aFCQ1V4qE1BnlTk7Z8BYBUkJM1odPSkVvHpCnMUjVpJ3hEOC+73Z YH1dh7lZABEBAAGJAjwEGAEKACYWIQRx42Dk0QxkiSLzSdBAeX98lfSDTwUCW5JHigIbDAUJ Ca6EAAAKCRBAeX98lfSDTz8DEACMh3poeUb+gWNF4RWFZuLteZVo0+E1JLYXQkmtrRBLXviP +Qy0pXyFAVxLM4hNIBoIDYfK9BcwrBYf7AwSKrH0GiNwFpgHCkbZd6qoZy2gB+adTnCpVCTJ KJetsH/8awkrChJWMK0ckGf3EeWMPvawG7kW7FBz70NYEZ0pOMiaEZNVtzD3wwbYWUiDFYth 83XGglOExg+1ShTW5XjQPRrdyJAO+aUW4o3lVjfyUJXMgI4rmhMiLVm06GuNrbpKIF0s+4Vd jQAjhrDQjfoXi9CkfsA/cONseuHNv1JGj3RqHiqHJq1dbrpodXp925zGDAnUGxCOBPoFopAH gVzR89GTut059GpwqsddZmU6y7rqifuam/ekJ+QRwc16vgt7pHqCrTY8WPxRZr2UpFU1wlTo COdeiFep1gq1F9jzFjJnoMaAdmC6k7bgAA+RQusOgIhJL0jIej7DoAHxmxFFCfRy+lDtpXwF gQ8HMvzHI65QWmQnMo7s6SQH/ZH5s1yR6SJq8+3lDz+dCuT42qJVqIPVvxd10LW0FNN+t7HF eLadU6ekSgD13/EYMYXlvNHkw7dAItSDxIzgRyykLz0bCU9xwNWoS4Z43+ifF9anJ+uR0ltW El1j++h6ZrD3LLuCgJIt1so0m49GzdcSpOI7LCwMlacyvafiEyjUn+tSNDsnfw== Organization: The FreeBSD Project Subject: Re: Is there any error checking on swap? Message-ID: Date: Sun, 12 Jul 2020 15:06:49 -0700 MIME-Version: 1.0 In-Reply-To: <20200712072911.GG4213@funkthat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LMnbsEF8WeMUkozyo6orSrKHBIwGgugr0" X-Rspamd-Queue-Id: 4B4gqN27Ffz46PJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.07 / 15.00]; HAS_REPLYTO(0.00)[d@delphij.net]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:sirius.delphij.net]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.022]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.984]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.04)[0.037]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 22:06:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LMnbsEF8WeMUkozyo6orSrKHBIwGgugr0 Content-Type: multipart/mixed; boundary="UGCJhs9mWmeFod3EV4IksQZz4eH5wRmpc"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: freebsd-current@freebsd.org Message-ID: Subject: Re: Is there any error checking on swap? References: <20200712033332.GA63411@www.zefox.net> <20200712072911.GG4213@funkthat.com> In-Reply-To: <20200712072911.GG4213@funkthat.com> --UGCJhs9mWmeFod3EV4IksQZz4eH5wRmpc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/12/20 12:29 AM, John-Mark Gurney wrote: > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: >> Is there any error checking on swap traffic, along the lines of >> a checksum or parity test?=20 >> >> Just curious what happens if a page written out is corrupted when >> it comes back. >=20 > Looks like it doesn't: > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=3D361= 965#l1389 Technically one can enable checks with e.g. geli(8), but note that the geli(8) provider will not "prime" the HMAC data so attaching the device will immediately spam the system log with some authentication errors due to GEOM tasting (because the kernel would try to read locations that potentially contain metadata for other GEOM providers). For the case of swap, since the write is always page sized, it's probably optimal to implement something in the swap layer itself and store the expected checksums in memory. Cheers, --UGCJhs9mWmeFod3EV4IksQZz4eH5wRmpc-- --LMnbsEF8WeMUkozyo6orSrKHBIwGgugr0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.20 (FreeBSD) iQIzBAEBCgAdFiEEceNg5NEMZIki80nQQHl/fJX0g08FAl8LiX0ACgkQQHl/fJX0 g09xQQ//UXdeg1WXxoi0WQR8Dr1xwLeKUhW+KULfN3wuH0M8feIcVZca033Ra8w4 rMdx9HF7H87vbgUb4Cw1UfcAyLgJSbQ09tV0m3O6NRgI9E9Awfys0vVIOnpvrcI7 R1VTHqYqiI2iKuaxf0aY/YVoMQWXGeP7G45dKUk/jhXC9XfSphhep0xUOacm7cyp W14uIn8mDeEyHCjEByxfuZ3Xefg8cO7hwcgDCRY3qK+Wd3D1hOwRvQkPSbzTyLJA QITqqZFnGbiTTpSO+IIkmFdH+HfvM7R6lZOuNAC7PG0+0neosCG82wRwH2XTzRhz g49dWL+NXheTJhaTQ5CStMZw3dnNafm9nuxLkA2OtHuRsVYmJUHXj9ynRAVJd8dA A/G/6Dk9mtkZW+cIEft0jqmF9iVdv/pPH/efyJaJtarabr8rZztefn8vbZ5P6pKW nAZLcSBdGo1AhVaGEaK9dneQ1mFn7DFsQBjv1gGYPR3TKXXC4GfbZWTLlapiAZ8U BaIYtk6YgR819w21Qk0OBNh+zTLuAxTpwMJo02xOTgPRbIZ9b5hzR+c7MlIULlvY 6mBiB4omc5lqvWRC+8QR/kFXTMxkrghA405uiBwX+z9s8EEdJuOaNm948GqGxW7N Hn4PNyUFyILqiRUGTlUL3jSPq4O3jLl7L+wJ+Y6XFx32qrN8RC8= =cW4G -----END PGP SIGNATURE----- --LMnbsEF8WeMUkozyo6orSrKHBIwGgugr0-- From owner-freebsd-current@freebsd.org Sun Jul 12 23:24:51 2020 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 BA8F535185F; Sun, 12 Jul 2020 23:24:51 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 4B4jYG3byKz48xt; Sun, 12 Jul 2020 23:24:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ot1-x32d.google.com with SMTP id w17so8257491otl.4; Sun, 12 Jul 2020 16:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gnCFVLimNbOWh2nB4+Q05L85oezpfiNQybscKUKcK40=; b=XTc/FvmNdoH6Sb93OKjNVZxfqrm9R9hTGN8uqIe/PtYjzfm1Lvu9tqZlKdtCBPK3wY iRgXMoW7OWrlSPt2iB8yn5u3NtvZKVMquONNMUgP3MCYwJDDWadtn2QXfJx6fh/y0g1I Zfh2PqyU2af6WuUfyL1Qw3kzBIfCJMYE3VSbOVjyt0R+sJDkvGCecJa4BeFsoplQYuYz COuoja1JOdUPPJRJGTvE+lpcwJXH+gZPZFjsvB8paCmQLTIzpDPZASZA0InzxOHF8aZi LITftK5dCgkhCQ1e5mfczMMQ5nPvWXvDccUODj2xiWNlElQQAII0rvFtUdL1YkgcZDwc MHjA== 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=gnCFVLimNbOWh2nB4+Q05L85oezpfiNQybscKUKcK40=; b=GpTNiHt9UbAT2qPeNpFER5XxP4hcEp2Pq1/070plqTLlr8oqRd5vJVAfqMq+FaOVsS 5EL51O3LkzP0j84L/53FbjHWdv8+EixB5pIZMiyeJtrUQNlah4DPNHliFG9rVcXLdFIw p/qPH7ZldW0bJzBc9nP54X4ULZGYIkPexKoDAD5vJxjoE95EGb6M3vcGFrtRAAzqtJJu YZiK+wQI5pCVQ3rgYoIt0gb0T4TmbyNxiu4X+4rW61VAFxcwp/9bOstq7xJn1FxKXpj4 qyWJEDwlqwJsI0azTKLvb4yDVbSWR1zQQg6c618fqJpcvUjuOpGB/BUVizNSW07+Hd4u uf+A== X-Gm-Message-State: AOAM532h67eCeGQz9kPfcMZKgyHZvMxHqUeWAZUWuwkF3IevTr32zHp/ l0Sedrx84JRM5H3cXINV8j9iiKIw9Uam9kBxSH/a3S/g X-Google-Smtp-Source: ABdhPJySG9bf+68ZKEZ4SQvBw1nZNmBpv119CkBoujNL2AThTly8HzhJlpHd+gxUoDamBOEX3cWCV3LgW9IEi8ueXyU= X-Received: by 2002:a05:6830:1af9:: with SMTP id c25mr40715179otd.271.1594596288900; Sun, 12 Jul 2020 16:24:48 -0700 (PDT) MIME-Version: 1.0 References: <20200711224426.GC4213@funkthat.com> <20200712215449.GI4213@funkthat.com> In-Reply-To: <20200712215449.GI4213@funkthat.com> From: Kevin Oberman Date: Sun, 12 Jul 2020 16:24:32 -0700 Message-ID: Subject: Re: slow USB 3.0 on -current To: Hans Petter Selasky , "freebsd-usb@FreeBSD.org" , FreeBSD Current X-Rspamd-Queue-Id: 4B4jYG3byKz48xt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XTc/FvmN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.01)[-1.007]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32d:from]; NEURAL_HAM_SHORT(-0.01)[-0.014]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 12 Jul 2020 23:24:51 -0000 On Sun, Jul 12, 2020 at 2:55 PM John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > > On 2020-07-12 00:44, John-Mark Gurney wrote: > > > Hello, > > > > > > I'm having issues getting good ethernet performance from a USB ethernet > > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > > adapter only gets around 10MB/sec performance. During the transfer, > > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > > 100MB/sec+ w/o troubles. > > > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > > > Any hints on how to fix this? > > > > > > This may be related, but I'm also having issues w/ booting when I have > > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > > and work. I have also attached a clip of the dmesg from that > > > happening. > > > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > > the performance issues? > > > > Can you check the output from ifconfig. What is the actual link speed. I > > suspect it has something to do with the MII bus code/implementation. > > ifconfig is reporting it's 1000baseT. > > > Also check output from "vmstat -i" during usage to see if the number of > > IRQ/s is low. > > Not sure what is considered low, but I'm seeing consistently around > 7800 int/s for xhci0. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > This is just for clarification, but is 'MB' MBytes? In the networking world that is what it would mean, but the context leads me to think that you mean Mbits. It's also possible that some numbers are in bits and some in Bytes, causing real confusion. I'm sure that 1000baseT is bits, of course. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Jul 13 01:02:52 2020 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 1E377353AB9; Mon, 13 Jul 2020 01:02:52 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4lkM1ySrz4Dbx; Mon, 13 Jul 2020 01:02:50 +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 06D12f9T070574 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 18:02:41 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06D12eZP070573; Sun, 12 Jul 2020 18:02:40 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 18:02:40 -0700 From: John-Mark Gurney To: Kevin Oberman Cc: Hans Petter Selasky , "freebsd-usb@FreeBSD.org" , FreeBSD Current Subject: Re: slow USB 3.0 on -current Message-ID: <20200713010240.GJ4213@funkthat.com> Mail-Followup-To: Kevin Oberman , Hans Petter Selasky , "freebsd-usb@FreeBSD.org" , FreeBSD Current References: <20200711224426.GC4213@funkthat.com> <20200712215449.GI4213@funkthat.com> 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]); Sun, 12 Jul 2020 18:02:41 -0700 (PDT) X-Rspamd-Queue-Id: 4B4lkM1ySrz4Dbx 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 [3.94 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.936]; NEURAL_SPAM_SHORT(0.92)[0.923]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.878]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; 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] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 01:02:52 -0000 Kevin Oberman wrote this message on Sun, Jul 12, 2020 at 16:24 -0700: > On Sun, Jul 12, 2020 at 2:55 PM John-Mark Gurney wrote: > > > Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > > > On 2020-07-12 00:44, John-Mark Gurney wrote: > > > > Hello, > > > > > > > > I'm having issues getting good ethernet performance from a USB ethernet > > > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > > > adapter only gets around 10MB/sec performance. During the transfer, > > > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > > > 100MB/sec+ w/o troubles. > > > > > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > > > > > Any hints on how to fix this? > > > > > > > > This may be related, but I'm also having issues w/ booting when I have > > > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > > > and work. I have also attached a clip of the dmesg from that > > > > happening. > > > > > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > > > the performance issues? > > > > > > Can you check the output from ifconfig. What is the actual link speed. I > > > suspect it has something to do with the MII bus code/implementation. > > > > ifconfig is reporting it's 1000baseT. > > > > > Also check output from "vmstat -i" during usage to see if the number of > > > IRQ/s is low. > > > > Not sure what is considered low, but I'm seeing consistently around > > 7800 int/s for xhci0. > > > This is just for clarification, but is 'MB' MBytes? In the networking world > that is what it would mean, but the context leads me to think that you mean > Mbits. It's also possible that some numbers are in bits and some in Bytes, > causing real confusion. I'm sure that 1000baseT is bits, of course. MB means megabytes.. I would use Mbps for bits... so, on Win10 and NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, I'm only getting a tenth the capability of gige at 9-10 MBytes/sec... I'll note that fetch reports numbers of MBps, which is one of the tools I've been using for testing. -- 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 Jul 13 01:09:56 2020 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 C3A3935472D for ; Mon, 13 Jul 2020 01:09:56 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4ltX14SBz4FJ0 for ; Mon, 13 Jul 2020 01:09:55 +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 06D19fDr070744 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 18:09:41 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06D19fIC070743; Sun, 12 Jul 2020 18:09:41 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 18:09:41 -0700 From: John-Mark Gurney To: d@delphij.net Cc: freebsd-current@freebsd.org Subject: Re: Is there any error checking on swap? Message-ID: <20200713010941.GK4213@funkthat.com> Mail-Followup-To: d@delphij.net, freebsd-current@freebsd.org References: <20200712033332.GA63411@www.zefox.net> <20200712072911.GG4213@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e9ndEBTQFD7P4kUb" 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]); Sun, 12 Jul 2020 18:09:41 -0700 (PDT) X-Rspamd-Queue-Id: 4B4ltX14SBz4FJ0 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.77 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.22)[0.218]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.34)[0.345]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.11)[0.112]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_SPF_NA(0.00)[no SPF record]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 01:09:56 -0000 --e9ndEBTQFD7P4kUb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Xin Li wrote this message on Sun, Jul 12, 2020 at 15:06 -0700: >=20 >=20 > On 7/12/20 12:29 AM, John-Mark Gurney wrote: > > bob prohaska wrote this message on Sat, Jul 11, 2020 at 20:33 -0700: > >> Is there any error checking on swap traffic, along the lines of > >> a checksum or parity test?=20 > >> > >> Just curious what happens if a page written out is corrupted when > >> it comes back. > >=20 > > Looks like it doesn't: > > https://svnweb.freebsd.org/base/head/sys/vm/swap_pager.c?annotate=3D361= 965#l1389 >=20 > Technically one can enable checks with e.g. geli(8), but note that the > geli(8) provider will not "prime" the HMAC data so attaching the device > will immediately spam the system log with some authentication errors due > to GEOM tasting (because the kernel would try to read locations that > potentially contain metadata for other GEOM providers). Yeah, and enabling auth w/ geli(8) is problematic, as it creates a disconnect between layers, as it expands 4096 byte writes to 9 512 byte sector writes, if you're using a 4k drive (which is pretty much the only thing sold these days), the performance is likely to be pretty terrible... see: https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli_integrity.c?annotat= e=3D361481#l56 So, it'd be doable, but less than ideal... > For the case of swap, since the write is always page sized, it's > probably optimal to implement something in the swap layer itself and > store the expected checksums in memory. +1 --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --e9ndEBTQFD7P4kUb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJfC7RUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MEI1RTRGMTNDNzYyMDZDNjEyMDBCNjAy MDVGMEIzM0REMDA2QURBAAoJECBfCzPdAGrakmUQAKcZeuy8dCLIfJfwcCS/+mrd ThVb+JYaVUDv1vavVU4iXH66/Nqw7+WC29ZrMOJCtQ8ttSRahzn5xpOt3xSXt+Ks Hk8qfdpPOgK35QVmwJFncpqAzhY020JKHk79+xssBs0ukxF+KRk0RIrR26av2iTF 5Prz3eIQv16OedQWYJXxXLW3umNbt2OPzI3pl1Kd8FpEE2/xRuvH1NmVxuHadDtB FK2VNdiumSEHhXbya6O/nCNljzlmLZ3X7OEa9YHsCJ6+gM/s/LAq0kvizigfNX5Q o0UCTmvURvtmOYuzhJd0ZwwDWM4+X0DkdKGJhGmw7pOizFqKtH1mnbSBKRjPcz5q MRG1tHYZ+EffB3aGKPfsuEZNXQtsuJz5B9atkoju8v0ELLa6Xt0x+F6NFY19jg5F vYEOdhC7PdX4GT1z+7S5UrWfZBISd0zAssZcXKKJLXQtVtT2kriFr35jhWXndF/l VDs+W7Uy4Er9tqxCxKVfbJIwmvFTShBu2/Zk7qanIGTncnBw1+GIJOmN+nuAkRf5 mJZvlHZH3D9wrqpqMZhtO7n4C4BCZi3wrUW7g6DSLq8DJD9cddvM0xz8vNieJ2Sa qwed+ZLb3L9pT/v3gOYj2UYaKcxG9HskqTxYf6c2jJRsbLihNkG608aL6xnDHB/5 sXD0vlegZSLxeQZPR51o =nyzJ -----END PGP SIGNATURE----- --e9ndEBTQFD7P4kUb-- From owner-freebsd-current@freebsd.org Mon Jul 13 01:26:33 2020 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 B5CEF354E46 for ; Mon, 13 Jul 2020 01:26:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4mFg5DLTz4G5J for ; Mon, 13 Jul 2020 01:26:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Dal7fSQVM1mJ70mMY87719JlsEwz63muv9fc0h9Slt8jNzSGmf.KHC_08w7Rn3E VZTRrQdv.kliCzpsHNYZ6PpN66Mz5Dk0xtrdpgvnzMwVe3QFQ1N0A3z932xhv3tNSqavGbSz8VrM BmUULNXobvXujao7zOR79j3E.ng0kUCt5EstT9CHO1SYaELkr.oohjujt7BZA8vVa179GG6LpoZE pfk57t0qunKftP8lXwawMVELoTumLIpiqHBDh5Yuxu3XcMVbdb89n8sU8WOp1zrtPvAXZV8aqq6w C22_DaZFp5V21epxDyHI9XpHbrE7uAyAT7h9v5BcLnOSIR3yuK2O0oEZsimuVARYS9BRjbBksVnz VKCSnplMYmZV8Y3BNOhrFRRl.NJ_7kZLsLXnZyeLjBZ_6BPmXkVBCr_Qva0LNfig2mPP2pDYL921 XSSMn4MoXfLReGmkKABNaTgJrkJpjkUzYALUQZOenrn6Z7lia63TjoTVyO_UTN4eucrCNRHbQpJx rFaQmXKlntGU4F5Wq6VtyxNSwXQkztn_VNpMjqANhT3apQXzDCiLOcVBvyO3n2L3nQcpUgSyE2mC FpSn62Kf5ZRbYx.Xnh1i_KVH9E.G6ojSUXmzkrEoDYGHiDZqZU8pZInbjOor6AnGeVCQ1UbscTuA 2xTpWJyJDVCAeqoOc5Z503vUSjmw9FPyqXogyekR0kf8B7CpXNrX5hnd_keNLqCjWI2eb3arPJ71 BrjQHO5I0ow0lN5s2c6dJ52xcAjSKE_ceVYdxyLU08eOudwoFtsdwRl5fsCOTYAQbQrUp82oU90e 1MxSRbcqWp.rgsS1SurFgRYPp4opPuGSj1XIrsxL7e7n.9iY_ygrZoouCcrQ1xwEFJaJHCh.IpMT X9BhQLFSrVWKZWj7032Nycs_dSqtmJ_Gs61jskZEHg2R5AHlkfaKiLze4ZMKJIv6CR0wFeNdcQRP aNfdY.XK9iTSxZG4Lpgqaihpx32tzDZPR7Cg4v3_BIKE0DHY9xw6NrO4W0xm_qmmhqqZQM1Pi4OV 4PNnn6zQLO3dzZMXbMWCCR9N3OCv8OuCuadtJLyKu7C6tYNSLSVeI5DvCeQwMbBLcKvtmz5W2z0v l8TUdno0jhJePVv85jolQ3jKK9zrSLEa9nAz7Jc5uHiv8LRqv2WntztuxbMNsXksDQnepvQ04caZ 8ZnbzOUsW9xXhEWrVykS2F.fXtDQE1ps.i6Mm.P.Q92zKwOx1KqseokwQhHMuAI5LbsC5JOJ582N pko9S.PpHCfCXdOxeIsd2CztiyGaA4e1ZGMK49GQMjtX8APKM5rKvElM0lLUWKr_uqnyXNnY_bbC 61S.f3RR3FdQYuAn2meUYWMqPVDapWSz9uJKehu.uzx1YP2Eac3cPZpcAG3xoUjj0npUlJ_Jx2lC 4laJvZ_pYng23s_u1.6RiQD0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Jul 2020 01:26:30 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1b5528573ac9db2cb3a88db2b68aa077; Mon, 13 Jul 2020 01:26:26 +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 13.4 \(3608.80.23.2.2\)) Subject: Re: slow USB 3.0 on -current Message-Id: <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> Date: Sun, 12 Jul 2020 18:26:24 -0700 To: John-Mark Gurney , FreeBSD Current X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> X-Rspamd-Queue-Id: 4B4mFg5DLTz4G5J X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; NEURAL_HAM_SHORT(-1.10)[-1.099]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 01:26:33 -0000 John-Mark Gurney jmg at funkthat.com wrote on Sat Jul 11 22:44:36 UTC 2020 : > I'm having issues getting good ethernet performance from a USB = ethernet > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's = an > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. >=20 > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > adapter only gets around 10MB/sec performance. During the transfer, > the CPU usage is only around 3-5%, so it's definitely not CPU bound. >=20 > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > 100MB/sec+ w/o troubles. >=20 > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. >=20 > Any hints on how to fix this? >=20 > This may be related, but I'm also having issues w/ booting when I have > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. >=20 > If I move the SD card reader to USB 2.0, the umass device will attach > and work. I have also attached a clip of the dmesg from that > happening. >=20 > Has anyone else seen this issue? Ideas or thoughts on how to resolve > the performance issues? >=20 It might prove useful to use iperf3 with # iperf3 -s on one machine and doing # iperf3 -c ADDR . . . # iperf3 -R -c ADDR . . . on the other. (That last swaps the sender/receiver status.) All 3 commands will have output. The -s one will produce output for each of the -c ones. The outputs for the sender(s) will include Cwnd (congestion window size) information that may be relevant. It will report bit rate and retry count sampling (and overall figures). Comparing the output of using iperf3 under NetBSD 9.0 or Windows 10 could be instructive. My observation would be that neither type of USB3 Ethernet adapter that I've tried (different chipsets) get anywhere near 100 MByte/s when ifconfig reports 1000baseT . The Cwnd figures are smaller than for the built-in Ethernets that manage much faster overall transfer rates. Example where 192.168.1.112 has the USB3 EtherNet based adapter in use and 192.168.1.120 has built-in EtherNet that can do 900 Mbit/s+ on the network: # iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.112, port 20519 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.112 port = 44212 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec =20 [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 2.00-3.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 6.00-7.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 7.00-8.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec =20 [ 5] 10.00-10.19 sec 5.13 MBytes 231 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.19 sec 277 MBytes 228 Mbits/sec = receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.112, port 18711 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.112 port = 48624 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 22.5 MBytes 188 Mbits/sec 273 17.0 KBytes = =20 [ 5] 1.00-2.00 sec 19.0 MBytes 159 Mbits/sec 214 14.3 KBytes = =20 [ 5] 2.00-3.00 sec 22.6 MBytes 190 Mbits/sec 271 29.8 KBytes = =20 [ 5] 3.00-4.00 sec 10.6 MBytes 88.9 Mbits/sec 131 28.4 KBytes = =20 [ 5] 4.00-5.00 sec 28.2 MBytes 237 Mbits/sec 343 17.0 KBytes = =20 [ 5] 5.00-6.01 sec 25.7 MBytes 214 Mbits/sec 310 14.3 KBytes = =20 [ 5] 6.01-7.00 sec 15.4 MBytes 130 Mbits/sec 178 19.8 KBytes = =20 [ 5] 7.00-8.00 sec 20.6 MBytes 173 Mbits/sec 229 21.3 KBytes = =20 [ 5] 8.00-9.00 sec 29.8 MBytes 250 Mbits/sec 345 19.8 KBytes = =20 [ 5] 9.00-10.00 sec 29.9 MBytes 251 Mbits/sec 325 17.0 KBytes = =20 [ 5] 10.00-10.19 sec 7.54 MBytes 332 Mbits/sec 89 2.83 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.19 sec 232 MBytes 191 Mbits/sec 2708 = sender ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- # iperf3 -c 192.168.1.120 Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.112 port 44212 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 29.0 MBytes 243 Mbits/sec 14 326 KBytes = =20 [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 2.00-3.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 6.00-7.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 7.00-8.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec 0 326 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 277 MBytes 233 Mbits/sec 14 = sender [ 5] 0.00-10.19 sec 277 MBytes 228 Mbits/sec = receiver # iperf3 -R -c 192.168.1.120 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.112 port 48624 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 23.9 MBytes 198 Mbits/sec =20 [ 5] 1.01-2.01 sec 17.6 MBytes 147 Mbits/sec =20 [ 5] 2.01-3.01 sec 22.6 MBytes 189 Mbits/sec =20 [ 5] 3.01-4.00 sec 17.0 MBytes 144 Mbits/sec =20 [ 5] 4.00-5.00 sec 29.4 MBytes 247 Mbits/sec =20 [ 5] 5.00-6.00 sec 20.7 MBytes 173 Mbits/sec =20 [ 5] 6.00-7.01 sec 16.8 MBytes 140 Mbits/sec =20 [ 5] 7.01-8.00 sec 22.9 MBytes 193 Mbits/sec =20 [ 5] 8.00-9.00 sec 31.0 MBytes 261 Mbits/sec =20 [ 5] 9.00-10.00 sec 29.9 MBytes 251 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.19 sec 232 MBytes 191 Mbits/sec 2708 = sender [ 5] 0.00-10.00 sec 232 MBytes 194 Mbits/sec = receiver I'll note that between machines with built-in EtherNet that can sustain fast transfers overall, the Cwnd figures tend to vary but can reach 1 MBytes+. The Retr counts tend to still exist. By contrast, when the USB3 EtherNet is receiving above, the maximum Cwnd reported above for the sender at the time was: 29.8 KBytes. I have not tried NetBSD, Windows 10, or Linux comparisons. =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 Jul 13 04:51:54 2020 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 2FC67358831 for ; Mon, 13 Jul 2020 04:51:54 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4rpc5sgFz4QD6 for ; Mon, 13 Jul 2020 04:51:52 +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 06D4pnGZ080221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Jul 2020 21:51:49 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06D4pnX5080220; Sun, 12 Jul 2020 21:51:49 -0700 (PDT) (envelope-from jmg) Date: Sun, 12 Jul 2020 21:51:49 -0700 From: John-Mark Gurney To: Mark Millard Cc: FreeBSD Current Subject: Re: slow USB 3.0 on -current Message-ID: <20200713045149.GL4213@funkthat.com> Mail-Followup-To: Mark Millard , FreeBSD Current References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> 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]); Sun, 12 Jul 2020 21:51:49 -0700 (PDT) X-Rspamd-Queue-Id: 4B4rpc5sgFz4QD6 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 [3.62 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.53)[0.534]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.973]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.92)[0.918]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; 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] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 04:51:54 -0000 Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: > John-Mark Gurney jmg at funkthat.com wrote on > Sat Jul 11 22:44:36 UTC 2020 : > > > I'm having issues getting good ethernet performance from a USB ethernet > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > adapter only gets around 10MB/sec performance. During the transfer, > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > 100MB/sec+ w/o troubles. > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > Any hints on how to fix this? > > > > This may be related, but I'm also having issues w/ booting when I have > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > and work. I have also attached a clip of the dmesg from that > > happening. > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > the performance issues? > > It might prove useful to use iperf3 with > > # iperf3 -s > > on one machine and doing > > # iperf3 -c ADDR > . . . > # iperf3 -R -c ADDR > . . . > > on the other. (That last swaps the > sender/receiver status.) > > All 3 commands will have output. The > -s one will produce output for each of > the -c ones. > > The outputs for the sender(s) will include Cwnd > (congestion window size) information that may > be relevant. It will report bit rate and > retry count sampling (and overall figures). Here is the results for FreeBSD w/ USB3 ure. .80 is the USB3 adapter side: gold,pts,/home/jmg,502$iperf3 -c 192.168.0.80 Connecting to host 192.168.0.80, port 5201 [ 5] local 192.168.0.2 port 50042 connected to 192.168.0.80 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 8.94 MBytes 75.0 Mbits/sec 931 15.5 KBytes [ 5] 1.00-2.00 sec 9.98 MBytes 83.7 Mbits/sec 919 27.3 KBytes [ 5] 2.00-3.00 sec 9.95 MBytes 83.5 Mbits/sec 954 5.71 KBytes [ 5] 3.00-4.00 sec 9.97 MBytes 83.7 Mbits/sec 939 28.7 KBytes [ 5] 4.00-5.00 sec 9.97 MBytes 83.6 Mbits/sec 951 17.3 KBytes [ 5] 5.00-6.00 sec 9.99 MBytes 83.8 Mbits/sec 913 31.5 KBytes [ 5] 6.00-7.00 sec 9.96 MBytes 83.5 Mbits/sec 956 20.1 KBytes [ 5] 7.00-8.00 sec 10.0 MBytes 83.9 Mbits/sec 913 33.0 KBytes [ 5] 8.00-9.00 sec 9.97 MBytes 83.6 Mbits/sec 945 24.4 KBytes [ 5] 9.00-10.00 sec 9.99 MBytes 83.8 Mbits/sec 916 34.4 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 98.7 MBytes 82.8 Mbits/sec 9337 sender [ 5] 0.00-10.25 sec 98.7 MBytes 80.8 Mbits/sec receiver iperf Done. gold,pts,/home/jmg,503$iperf3 -R -c 192.168.0.80 Connecting to host 192.168.0.80, port 5201 Reverse mode, remote host 192.168.0.80 is sending [ 5] local 192.168.0.2 port 51024 connected to 192.168.0.80 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 9.69 MBytes 81.3 Mbits/sec [ 5] 1.00-2.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 2.00-3.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 3.00-4.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 4.00-5.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 5.00-6.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 6.00-7.00 sec 10.7 MBytes 89.8 Mbits/sec [ 5] 7.00-8.00 sec 10.4 MBytes 87.6 Mbits/sec [ 5] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec [ 5] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 106 MBytes 88.9 Mbits/sec 1381 sender [ 5] 0.00-10.00 sec 106 MBytes 88.7 Mbits/sec receiver iperf Done. As you can see, it matches what I measured earlier. And just to prove that the machine CAN move 100MB/sec, I've run iperf3 using the onboard wired ethernet... I need multiple interfaces, which is why I'm bothering trying to get USB3 ethernet working. This is using the onboard bge interface. It's IP is .79: gold,pts,/home/jmg,507$iperf3 -c 192.168.0.79 Connecting to host 192.168.0.79, port 5201 [ 5] local 192.168.0.2 port 61500 connected to 192.168.0.79 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 101 MBytes 850 Mbits/sec 0 488 KBytes [ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0 488 KBytes [ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 731 KBytes [ 5] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 731 KBytes [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 731 KBytes [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 731 KBytes [ 5] 6.00-7.00 sec 112 MBytes 940 Mbits/sec 0 731 KBytes [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 0 731 KBytes [ 5] 8.00-9.00 sec 112 MBytes 940 Mbits/sec 0 731 KBytes [ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 731 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 932 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 1.08 GBytes 931 Mbits/sec receiver iperf Done. gold,pts,/home/jmg,508$iperf3 -R -c 192.168.0.79 Connecting to host 192.168.0.79, port 5201 Reverse mode, remote host 192.168.0.79 is sending [ 5] local 192.168.0.2 port 61726 connected to 192.168.0.79 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 97.0 MBytes 814 Mbits/sec [ 5] 1.00-2.00 sec 109 MBytes 917 Mbits/sec [ 5] 2.00-3.00 sec 110 MBytes 920 Mbits/sec [ 5] 3.00-4.00 sec 109 MBytes 917 Mbits/sec [ 5] 4.00-5.00 sec 110 MBytes 920 Mbits/sec [ 5] 5.00-6.00 sec 109 MBytes 916 Mbits/sec [ 5] 6.00-7.00 sec 110 MBytes 919 Mbits/sec [ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec [ 5] 8.00-9.00 sec 110 MBytes 919 Mbits/sec [ 5] 9.00-10.00 sec 109 MBytes 916 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.03 sec 1.06 GBytes 905 Mbits/sec 2866 sender [ 5] 0.00-10.00 sec 1.06 GBytes 907 Mbits/sec receiver iperf Done. > Comparing the output of using iperf3 under > NetBSD 9.0 or Windows 10 could be instructive. And NetBSD 9.0. Here, NetBSD got assigned .50, but it's also using the USB3 adapter. gold,pts,/home/jmg,505$iperf3 -c 192.168.0.50 Connecting to host 192.168.0.50, port 5201 [ 5] local 192.168.0.2 port 55535 connected to 192.168.0.50 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 96.7 MBytes 811 Mbits/sec 0 50.9 KBytes [ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 0 82.1 KBytes [ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 14 114 KBytes [ 5] 3.00-4.00 sec 110 MBytes 924 Mbits/sec 60 146 KBytes [ 5] 4.00-5.00 sec 112 MBytes 938 Mbits/sec 107 178 KBytes [ 5] 5.00-6.00 sec 112 MBytes 939 Mbits/sec 122 193 KBytes [ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 144 193 KBytes [ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 165 193 KBytes [ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 144 193 KBytes [ 5] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 165 193 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec 921 sender [ 5] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec receiver iperf Done. gold,pts,/home/jmg,506$iperf3 -R -c 192.168.0.50 Connecting to host 192.168.0.50, port 5201 Reverse mode, remote host 192.168.0.50 is sending [ 5] local 192.168.0.2 port 55691 connected to 192.168.0.50 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 78.3 MBytes 657 Mbits/sec [ 5] 1.00-2.00 sec 88.4 MBytes 742 Mbits/sec [ 5] 2.00-3.00 sec 88.5 MBytes 742 Mbits/sec [ 5] 3.00-4.00 sec 88.4 MBytes 741 Mbits/sec [ 5] 4.00-5.00 sec 88.7 MBytes 744 Mbits/sec [ 5] 5.00-6.00 sec 88.2 MBytes 740 Mbits/sec [ 5] 6.00-7.00 sec 87.8 MBytes 737 Mbits/sec [ 5] 7.00-8.00 sec 88.5 MBytes 742 Mbits/sec [ 5] 8.00-9.00 sec 89.0 MBytes 746 Mbits/sec [ 5] 9.00-10.00 sec 88.8 MBytes 745 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 875 MBytes 734 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 874 MBytes 734 Mbits/sec receiver iperf Done. As you can see, both match approximately what I measured other methods, so, it's definitely not the way I measured performance. > My observation would be that neither type > of USB3 Ethernet adapter that I've tried What is the chipset that you tried? One of the earlier ones that I tried was an axe iirc, and was limited to around 500Mbps or so... > (different chipsets) get anywhere near > 100 MByte/s when ifconfig reports > 1000baseT . The Cwnd figures > are smaller than for the built-in Ethernets > that manage much faster overall transfer > rates. [...] > I'll note that between machines with built-in EtherNet > that can sustain fast transfers overall, the Cwnd figures > tend to vary but can reach 1 MBytes+. The Retr counts > tend to still exist. > > By contrast, when the USB3 EtherNet is receiving above, > the maximum Cwnd reported above for the sender at the > time was: 29.8 KBytes. > > I have not tried NetBSD, Windows 10, or Linux comparisons. As you can see above, NetBSD easily achieves around 8-10x the speed using the exact same USB3 device as FreeBSD does, so the hardware CAN push the speeds, just FreeBSD cannot. Hence, my original post, what can I do to possibly get FreeBSD's performance up to what the hardware can achieve? -- 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 Jul 13 07:44:09 2020 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 808EB35BDBD for ; Mon, 13 Jul 2020 07:44:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (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 4B4wdN3Ynsz4XtY for ; Mon, 13 Jul 2020 07:44:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Ei.7EnEVM1mjWONkhy7iS22p5bVwhzS_I.FcWWYgWaHktgCTN9hn9wOIqgv8ApO A3Hz8K7yN9pL7kIak9GHPCq4wCFNRNFvzes5ITbMPkSH9uD3YupVLvrJW_k7y6POlPCv2VWjDkHm ouEPNZK4xz2JpdtskBAbZ_iysEAd8Ke2zM3CX03zFS28Dq955pE6Z4MsmRdsqKORtbJyBWw2A3Vr L_Pi1Zt4zOrfsXOo.ykxLYIys6n4EsDT996upBz7oGmH9sgv7O3zBx5FfBwXF9Xt3rKo2xgxvwuJ uw6NrkPe6p.5m5iLELD0bZ_V6Zod.zbBFybFN8PeuCoDUCcWWaxAZ7hJizn6XtPSHx9t.dJl0wUi hizRsou3SWs1Ixgh.ubSnvvQmaSLrbD.OeRbxWVr3FQoDyb4dd8fphJhAKbSu9qLy_XuwjQK0Tgt GKTH8Q2_oPb2lUhKJr26DaOCzmV1nlvnPtz5UH.Povu_.h4pDLBiD0M7WjRdVz6mtnjsk2rCTvdh Lz.fnI9Q6oSGemlrK5E.YMmZw.wToUHfyz3MHXuCl5MukpPBEN15mg9wOV.hho1qcwGF7C6_BkNi lgQLBRreHv0YFRxcpIkevtT1thGwGg79W2BJ7bF2MZo.CJ1m87GrvuaV7XMA3LK94um3AqVlIhIl sEC1_a.XW4squgiosGu_vEyXb5fFsD25CSAV9jskWt5SwvLiIoJJeT2WOcYogoPkNZSQWOZJLkfX 7n1RT8zjGq83cW2Pc_KXN5xUM92UGujCa2quVma6stBX2H7N2Qo3DO1u1dPSrmd7.BBukskQjz9B 5a5gVMeHZTnJ9ynrFRBcq7ks557ZrC.MEjqTqe9UBPtcKIWhF.3Gh_qagauB6.DjXUq2pTqbSBKJ FnOEQWFUlFpQ0SIJ39_OWCGpZ2VpdyF4IPEbBa3d980D8sWicVk5Iv.N_lArbSMXjAjsrcYxi62X uQQpaj27ikQ5hLQec3f3EGGnBt1gNaR11pFWo19BqR9oZ7n6fh6a4OvdMAp6nmBy5hKV98H7fsbv RQ714vO3SKvUdLuwYKwfRgwitGfjyQqLjCCEnCm_QWqJ_EmiRE3wke05Eak4x4sWm5LDFZAB9Q4Q ERbTGXA4hhnxd6tFf9_pw6vt.G2FzvCND029QTG855KlwttjIaLHeQF5t1dvvBBmx_Vy2tNP14r1 vDPgFg_GImx.MdZSgj58LBIutptM.Vo.mBBC31D620X6XWhiOWZTnBtGJRBpAIlhSBZeolitTnVV 9Lw6wXFWe_HUqxVHQXhYnmJvWQ5KCBRKhxCSotfvJLEqG5gsnjwtzCgEF2__qZAinkkInhywfTOF WdsxLFrDQ73hhB52pjUuoX2CvxJwohNSRP3GlHSd9vgla0bWAvLVS85USxqLBgHniTtyqrq6SzvR BYKWX78Pfo7In98a2GTsomkR42b3Gkt5pmu3dFZWY8yPkzDcSISLIwMfnWkM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Jul 2020 07:44:06 +0000 Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 802c6e00640156d2aaa020c5511e02ea; Mon, 13 Jul 2020 07:44:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: slow USB 3.0 on -current From: Mark Millard In-Reply-To: <20200713045149.GL4213@funkthat.com> Date: Mon, 13 Jul 2020 00:44:02 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> <20200713045149.GL4213@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B4wdN3Ynsz4XtY X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.11 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-1.02)[-1.017]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; NEURAL_HAM_SHORT(-0.60)[-0.600]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 07:44:09 -0000 On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: > Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: >> John-Mark Gurney jmg at funkthat.com wrote on >> Sat Jul 11 22:44:36 UTC 2020 : >>=20 >>> I'm having issues getting good ethernet performance from a USB = ethernet >>> adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's = an >>> AMD PRO A10-8700B based system using the AMD A78 FCH chipset. >>>=20 >>> Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB >>> adapter only gets around 10MB/sec performance. During the transfer, >>> the CPU usage is only around 3-5%, so it's definitely not CPU bound. >>>=20 >>> I have tested Windows 10 and NetBSD 9.0 performance, and both = provide >>> 100MB/sec+ w/o troubles. >>>=20 >>> I have attached dmesg from both FreeBSD -current and NetBSD 9.0. >>>=20 >>> Any hints on how to fix this? >>>=20 >>> This may be related, but I'm also having issues w/ booting when I = have >>> both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 = ports. >>>=20 >>> If I move the SD card reader to USB 2.0, the umass device will = attach >>> and work. I have also attached a clip of the dmesg from that >>> happening. >>>=20 >>> Has anyone else seen this issue? Ideas or thoughts on how to = resolve >>> the performance issues? >>=20 >> It might prove useful to use iperf3 with >>=20 >> # iperf3 -s >>=20 >> on one machine and doing >>=20 >> # iperf3 -c ADDR >> . . . >> # iperf3 -R -c ADDR >> . . . >>=20 >> on the other. (That last swaps the >> sender/receiver status.) >>=20 >> All 3 commands will have output. The >> -s one will produce output for each of >> the -c ones. >>=20 >> The outputs for the sender(s) will include Cwnd >> (congestion window size) information that may >> be relevant. It will report bit rate and >> retry count sampling (and overall figures). >=20 > Here is the results for FreeBSD w/ USB3 ure. .80 is the USB3 > adapter side: > gold,pts,/home/jmg,502$iperf3 -c 192.168.0.80 > Connecting to host 192.168.0.80, port 5201 > [ 5] local 192.168.0.2 port 50042 connected to 192.168.0.80 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 8.94 MBytes 75.0 Mbits/sec 931 15.5 = KBytes > [ 5] 1.00-2.00 sec 9.98 MBytes 83.7 Mbits/sec 919 27.3 = KBytes > [ 5] 2.00-3.00 sec 9.95 MBytes 83.5 Mbits/sec 954 5.71 = KBytes > [ 5] 3.00-4.00 sec 9.97 MBytes 83.7 Mbits/sec 939 28.7 = KBytes > [ 5] 4.00-5.00 sec 9.97 MBytes 83.6 Mbits/sec 951 17.3 = KBytes > [ 5] 5.00-6.00 sec 9.99 MBytes 83.8 Mbits/sec 913 31.5 = KBytes > [ 5] 6.00-7.00 sec 9.96 MBytes 83.5 Mbits/sec 956 20.1 = KBytes > [ 5] 7.00-8.00 sec 10.0 MBytes 83.9 Mbits/sec 913 33.0 = KBytes > [ 5] 8.00-9.00 sec 9.97 MBytes 83.6 Mbits/sec 945 24.4 = KBytes > [ 5] 9.00-10.00 sec 9.99 MBytes 83.8 Mbits/sec 916 34.4 = KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 98.7 MBytes 82.8 Mbits/sec 9337 = sender > [ 5] 0.00-10.25 sec 98.7 MBytes 80.8 Mbits/sec = receiver >=20 > iperf Done. > gold,pts,/home/jmg,503$iperf3 -R -c 192.168.0.80 > Connecting to host 192.168.0.80, port 5201 > Reverse mode, remote host 192.168.0.80 is sending > [ 5] local 192.168.0.2 port 51024 connected to 192.168.0.80 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 9.69 MBytes 81.3 Mbits/sec > [ 5] 1.00-2.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 2.00-3.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 3.00-4.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 4.00-5.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 5.00-6.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 6.00-7.00 sec 10.7 MBytes 89.8 Mbits/sec > [ 5] 7.00-8.00 sec 10.4 MBytes 87.6 Mbits/sec > [ 5] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec > [ 5] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 106 MBytes 88.9 Mbits/sec 1381 = sender > [ 5] 0.00-10.00 sec 106 MBytes 88.7 Mbits/sec = receiver >=20 > iperf Done. The "iperf3 -s" should have had output with the Cwnd figures for the "Reverse mode" case above (and the distribution for the 1381 Retr total). They might not match when the earlier figures that you did report for the non-Reverse mode. > As you can see, it matches what I measured earlier. >=20 > And just to prove that the machine CAN move 100MB/sec, I've run iperf3 > using the onboard wired ethernet... I need multiple interfaces, which = is > why I'm bothering trying to get USB3 ethernet working. >=20 > This is using the onboard bge interface. It's IP is .79: > gold,pts,/home/jmg,507$iperf3 -c 192.168.0.79 > Connecting to host 192.168.0.79, port 5201 > [ 5] local 192.168.0.2 port 61500 connected to 192.168.0.79 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 101 MBytes 850 Mbits/sec 0 488 = KBytes > [ 5] 1.00-2.00 sec 112 MBytes 940 Mbits/sec 0 488 = KBytes > [ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 731 = KBytes > [ 5] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 731 = KBytes > [ 5] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 731 = KBytes > [ 5] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 731 = KBytes > [ 5] 6.00-7.00 sec 112 MBytes 940 Mbits/sec 0 731 = KBytes > [ 5] 7.00-8.00 sec 112 MBytes 941 Mbits/sec 0 731 = KBytes > [ 5] 8.00-9.00 sec 112 MBytes 940 Mbits/sec 0 731 = KBytes > [ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec 0 731 = KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.08 GBytes 932 Mbits/sec 0 = sender > [ 5] 0.00-10.01 sec 1.08 GBytes 931 Mbits/sec = receiver >=20 > iperf Done. > gold,pts,/home/jmg,508$iperf3 -R -c 192.168.0.79 > Connecting to host 192.168.0.79, port 5201 > Reverse mode, remote host 192.168.0.79 is sending > [ 5] local 192.168.0.2 port 61726 connected to 192.168.0.79 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 97.0 MBytes 814 Mbits/sec > [ 5] 1.00-2.00 sec 109 MBytes 917 Mbits/sec > [ 5] 2.00-3.00 sec 110 MBytes 920 Mbits/sec > [ 5] 3.00-4.00 sec 109 MBytes 917 Mbits/sec > [ 5] 4.00-5.00 sec 110 MBytes 920 Mbits/sec > [ 5] 5.00-6.00 sec 109 MBytes 916 Mbits/sec > [ 5] 6.00-7.00 sec 110 MBytes 919 Mbits/sec > [ 5] 7.00-8.00 sec 109 MBytes 917 Mbits/sec > [ 5] 8.00-9.00 sec 110 MBytes 919 Mbits/sec > [ 5] 9.00-10.00 sec 109 MBytes 916 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.03 sec 1.06 GBytes 905 Mbits/sec 2866 = sender > [ 5] 0.00-10.00 sec 1.06 GBytes 907 Mbits/sec = receiver >=20 > iperf Done. Similar "iperf3 -s" output point here. >> Comparing the output of using iperf3 under >> NetBSD 9.0 or Windows 10 could be instructive. >=20 > And NetBSD 9.0. Here, NetBSD got assigned .50, but it's also using > the USB3 adapter. >=20 > gold,pts,/home/jmg,505$iperf3 -c 192.168.0.50 > Connecting to host 192.168.0.50, port 5201 > [ 5] local 192.168.0.2 port 55535 connected to 192.168.0.50 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 96.7 MBytes 811 Mbits/sec 0 50.9 = KBytes > [ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 0 82.1 = KBytes > [ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 14 114 = KBytes > [ 5] 3.00-4.00 sec 110 MBytes 924 Mbits/sec 60 146 = KBytes > [ 5] 4.00-5.00 sec 112 MBytes 938 Mbits/sec 107 178 = KBytes > [ 5] 5.00-6.00 sec 112 MBytes 939 Mbits/sec 122 193 = KBytes > [ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 144 193 = KBytes > [ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 165 193 = KBytes > [ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 144 193 = KBytes > [ 5] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 165 193 = KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec 921 = sender > [ 5] 0.00-10.00 sec 1.08 GBytes 924 Mbits/sec = receiver >=20 > iperf Done. > gold,pts,/home/jmg,506$iperf3 -R -c 192.168.0.50 > Connecting to host 192.168.0.50, port 5201 > Reverse mode, remote host 192.168.0.50 is sending > [ 5] local 192.168.0.2 port 55691 connected to 192.168.0.50 port 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 78.3 MBytes 657 Mbits/sec > [ 5] 1.00-2.00 sec 88.4 MBytes 742 Mbits/sec > [ 5] 2.00-3.00 sec 88.5 MBytes 742 Mbits/sec > [ 5] 3.00-4.00 sec 88.4 MBytes 741 Mbits/sec > [ 5] 4.00-5.00 sec 88.7 MBytes 744 Mbits/sec > [ 5] 5.00-6.00 sec 88.2 MBytes 740 Mbits/sec > [ 5] 6.00-7.00 sec 87.8 MBytes 737 Mbits/sec > [ 5] 7.00-8.00 sec 88.5 MBytes 742 Mbits/sec > [ 5] 8.00-9.00 sec 89.0 MBytes 746 Mbits/sec > [ 5] 9.00-10.00 sec 88.8 MBytes 745 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 875 MBytes 734 Mbits/sec 0 = sender > [ 5] 0.00-10.00 sec 874 MBytes 734 Mbits/sec = receiver >=20 > iperf Done. Similar "iperf3 -s" output point here. > As you can see, both match approximately what I measured other = methods, > so, it's definitely not the way I measured performance. >=20 >> My observation would be that neither type >> of USB3 Ethernet adapter that I've tried >=20 > What is the chipset that you tried? One of the earlier ones that I > tried was an axe iirc, and was limited to around 500Mbps or so... Hmm. I only seem to be able to find one type. Its been a while since I've used the other and I do not know where it is at. For what I found: ugen0.2: at usbus0 axge0 on uhub0 axge0: on usbus0 miibus1: on axge0 rgephy0: PHY 3 on = miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow (I have access to more than one instance of the above.) The iperf3 output that I reported was for using of of the above. Note that when the USB3 EtherNet was reciveing Cwnd was reported as 29.8 KBytes or smaller for the example run, much like your output reporting 34.4 KBytes or less for the example run. This may suggest some common constraint across various USB3 EtherNet devices. The Cwnd figures are probably too small to get near 900 Mbit/s+. But, even with a (smaller but) similar Cwnd figure my example was getting faster transfers than your example. I got smaller Retr figures as well. It leaves me wondering if there are packets being rejected in your context that are not in my context. If what I reported would still be too slow, there may be two (or more) points to be addressed to get things going fast enough for you. You might be able to avoid one of the points by using a type of device that already does somewhat better. May be ask for the fastest examples folks have observed? >> (different chipsets) get anywhere near >> 100 MByte/s when ifconfig reports >> 1000baseT . The Cwnd figures >> are smaller than for the built-in Ethernets >> that manage much faster overall transfer >> rates. >=20 > [...] >=20 >> I'll note that between machines with built-in EtherNet >> that can sustain fast transfers overall, the Cwnd figures >> tend to vary but can reach 1 MBytes+. The Retr counts >> tend to still exist. >>=20 >> By contrast, when the USB3 EtherNet is receiving above, >> the maximum Cwnd reported above for the sender at the >> time was: 29.8 KBytes. >>=20 >> I have not tried NetBSD, Windows 10, or Linux comparisons. >=20 > As you can see above, NetBSD easily achieves around 8-10x the > speed using the exact same USB3 device as FreeBSD does, so the > hardware CAN push the speeds, just FreeBSD cannot. The small Cwnd figures like 34.4 KBytes suggest that a small receiver window (Rwnd) might be specified in the TCP header that the destination provided for that transfer direction. Cwnd can increase up to the Rwnd unless duplicate ACKs or timeouts occur, as I understand. (I'm no expert.) This is part of the reason I thought that posting the output (with Cwnd) for both transfer directions could be of use: it gives a hint about what is controlling the Cwnd if the two directions have widely different figures vs. if both directions get similarly small figures. Comparisons with the other OS's figures in both directions could possibly also be suggestive, or so I hoped. May be the comparison with the figures that I reported gives someone some hints about what might be going on in the two contexts. > Hence, my original post, what can I do to possibly get FreeBSD's > performance up to what the hardware can achieve? >=20 Hopefully my notes prove of some use --but I'm not likely to directly solve the problem. It would be handy for me if USB3 EtherNet performed significantly better than I have observed. =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 Jul 13 08:50:33 2020 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 E978E35D325; Mon, 13 Jul 2020 08:50:33 +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 4B4y611gb5z4c3M; Mon, 13 Jul 2020 08:50:32 +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 382E6260564; Mon, 13 Jul 2020 10:50:24 +0200 (CEST) Subject: Re: slow USB 3.0 on -current To: Kevin Oberman , "freebsd-usb@FreeBSD.org" , FreeBSD Current References: <20200711224426.GC4213@funkthat.com> <20200712215449.GI4213@funkthat.com> <20200713010240.GJ4213@funkthat.com> From: Hans Petter Selasky Message-ID: <50d00b19-9e27-4d0f-f3d1-af0574687c14@selasky.org> Date: Mon, 13 Jul 2020 10:50:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200713010240.GJ4213@funkthat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B4y611gb5z4c3M X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.13 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.05)[0.047]; NEURAL_HAM_LONG(-0.94)[-0.941]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.941]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 08:50:34 -0000 On 2020-07-13 03:02, John-Mark Gurney wrote: > MB means megabytes.. I would use Mbps for bits... so, on Win10 and > NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, > I'm only getting a tenth the capability of gige at 9-10 MBytes/sec... > > I'll note that fetch reports numbers of MBps, which is one of the tools > I've been using for testing. Hi, Could you have a look at the traffic pattern, when using iperf? usbdump -i usbusX -f Y Where X and Y are the numbers after ugen . Many of the network USB drivers are single buffered, because that's what older USB host controllers support. Then the IRQ rate 8000 for USB 2.0/3.0 and 1000 for USB 1.0, limits the number of packets per second. --HPS From owner-freebsd-current@freebsd.org Mon Jul 13 13:58:25 2020 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 1EB05364990 for ; Mon, 13 Jul 2020 13:58:25 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B54xF04Wqz3xC7; Mon, 13 Jul 2020 13:58:25 +0000 (UTC) (envelope-from gjb@freebsd.org) 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 A82C6D7A9; Mon, 13 Jul 2020 13:58:24 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 13 Jul 2020 13:58:21 +0000 From: Glen Barber To: freebsd-current@freebsd.org Subject: arm64 panic: reaper-related? Message-ID: <20200713135821.GS61041@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/k2pzXB1sdSS/P9" Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 13:58:25 -0000 --W/k2pzXB1sdSS/P9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, This morning, one of our arm64 build machines panicked. It looks like it is somehow reaper-related, but I am not entirely sure. Backtrace follows. Any thoughts? I'm not quite sure where to go from here... Thanks in advance for any input. db> set $lines 0 db> bt Tracing pid 11 tid 100003 td 0xfffffd0001634000 db_trace_self() at db_stack_trace+0xf8 pc = 0xffff00000075fdac lr = 0xffff000000103e78 sp = 0xffff00011eca89b0 fp = 0xffff00011eca89e0 db_stack_trace() at db_command+0x228 pc = 0xffff000000103e78 lr = 0xffff000000103af0 sp = 0xffff00011eca89f0 fp = 0xffff00011eca8ad0 db_command() at db_command_loop+0x58 pc = 0xffff000000103af0 lr = 0xffff000000103898 sp = 0xffff00011eca8ae0 fp = 0xffff00011eca8b00 db_command_loop() at db_trap+0xf4 pc = 0xffff000000103898 lr = 0xffff000000106c0c sp = 0xffff00011eca8b10 fp = 0xffff00011eca8d30 db_trap() at kdb pc = 0xffff000000106c0c lr = 0xffff000000463b0c sp = 0xffff00011eca8d40 fp = 0xffff00011eca8df0 kdb_trap() at do_el1h_sync+0xf4 pc = 0xffff000000463b0c lr = 0xffff00000077b448 sp = 0xffff00011eca8e00 fp = 0xffff00011eca8e30 do_el1h_sync() at handle_el1h_sync+0x78 pc = 0xffff00000077b448 lr = 0xffff000000762878 sp = 0xffff00011eca8e40 fp = 0xffff00011eca8f50 handle_el1h_sync() at kdb_enter+0x34 pc = 0xffff000000762878 lr = 0xffff000000463168 sp = 0xffff00011eca8f60 fp = 0xffff00011eca8ff0 kdb_enter() at vpanic+0x1b0 pc = 0xffff000000463168 lr = 0xffff000000417a74 sp = 0xffff00011eca9000 fp = 0xffff00011eca90b0 vpanic() at panic+0x44 pc = 0xffff000000417a74 lr = 0xffff0000004178c0 sp = 0xffff00011eca90c0 fp = 0xffff00011eca9140 panic() at __stack_chk_fail+0x10 pc = 0xffff0000004178c0 lr = 0xffff00000044ab6c sp = 0xffff00011eca9150 fp = 0xffff00011eca9150 __stack_chk_fail() at putchar+0x2bc pc = 0xffff00000044ab6c lr = 0xffff000000469ce8 sp = 0xffff00011eca9160 fp = 0xffff00011eca91e0 putchar() at 0x106 pc = 0xffff000000469ce8 lr = 0x0000000000000106 sp = 0xffff00011eca91f0 fp = 0x0000000000000000 db> show proc 11 Process 11 (idle) at 0xfffffd0001630000: state: NORMAL uid: 0 gids: 0 parent: pid 0 at 0xffff0000010fae40 ABI: null reaper: 0xffff0000010fae40 reapsubtree: 11 sigparent: 20 vmspace: 0xffff000001109200 (map 0xffff000001109200) (map.pmap 0xffff0000011092c0) (pmap 0xffff000001109320) threads: 48 100003 Run CPU -1 [idle: cpu0] 100004 Run CPU 1 [idle: cpu1] 100005 Run CPU 2 [idle: cpu2] 100006 Run CPU 3 [idle: cpu3] 100007 Run CPU 4 [idle: cpu4] 100008 Run CPU 5 [idle: cpu5] 100009 Run CPU 6 [idle: cpu6] 100010 Run CPU 7 [idle: cpu7] 100011 Run CPU 8 [idle: cpu8] 100012 CanRun [idle: cpu9] 100013 Run CPU 10 [idle: cpu10] 100014 Run CPU 11 [idle: cpu11] 100015 Run CPU 12 [idle: cpu12] 100016 Run CPU 13 [idle: cpu13] 100017 Run CPU 14 [idle: cpu14] 100018 Run CPU 15 [idle: cpu15] 100019 Run CPU 16 [idle: cpu16] 100020 Run CPU 17 [idle: cpu17] 100021 Run CPU 18 [idle: cpu18] 100022 Run CPU 19 [idle: cpu19] 100023 Run CPU 20 [idle: cpu20] 100024 Run CPU 21 [idle: cpu21] 100025 Run CPU 22 [idle: cpu22] 100026 Run CPU 23 [idle: cpu23] 100027 Run CPU 24 [idle: cpu24] 100028 Run CPU 25 [idle: cpu25] 100029 Run CPU 26 [idle: cpu26] 100030 CanRun [idle: cpu27] 100031 Run CPU 28 [idle: cpu28] 100032 Run CPU 29 [idle: cpu29] 100033 Run CPU 30 [idle: cpu30] 100034 Run CPU 31 [idle: cpu31] 100035 Run CPU 32 [idle: cpu32] 100036 Run CPU 33 [idle: cpu33] 100037 Run CPU 34 [idle: cpu34] 100038 Run CPU 35 [idle: cpu35] 100039 Run CPU 36 [idle: cpu36] 100040 Run CPU 37 [idle: cpu37] 100041 Run CPU 38 [idle: cpu38] 100042 Run CPU 39 [idle: cpu39] 100043 Run CPU 40 [idle: cpu40] 100044 Run CPU 41 [idle: cpu41] 100045 Run CPU 42 [idle: cpu42] 100046 Run CPU 43 [idle: cpu43] 100047 Run CPU 44 [idle: cpu44] 100048 Run CPU 45 [idle: cpu45] 100049 Run CPU 46 [idle: cpu46] 100050 Run CPU 47 [idle: cpu47] Glen --W/k2pzXB1sdSS/P9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl8MaHkACgkQAxRYpUeP 4pPfnw/+MMkP5fmbf7Ct+ruUssTJRKRDtO7yKCcnwasKbbXPUZUFlnVFrJMdiwZ7 gIiQecxhf3F7xJsCBISHTt7Pei5lEUlhi/+OraWtLJ2Gf2AXQmgp+tsoA855XP5S CLNycMUvRDoLDiBE0y6IJ9zGWiF+jNTqTagIBUgg3VethCAJOm4wADXE00/LF4wS vNZjIkL8H9hwr4atGgcARKK7HTYEPVA+ttOAq7XDoDhsmd6FyCuqG/QzDcqU57I2 CKDg589maH3eYEBTf+qOisVvgrT1UKWQD31ARk8IzmC45gGlFA/Yzy7uNCldsx6w 7bKARVxHg5gTH3RF164tNKnLrwvJBAfLuXSZPYDuaJ0ZsLadY1fhq2K3RcDJ1H+h jrvb8160SoE1VwRyUyAW8x1xWE1ohhYP5KJ65p+vYHuUZdyeJeKfz9y2OGSKfh+o UWrjwosZ+akvraRfdVU/JltIz1jSqrK3LZ3TCYHlXoGv8cntZWH1nvczbOLJVzh7 2vV8pwRCHI2xlOsZLugk4CFR+UhNNqd2Ls4/B/Zu+1gDsCOfFwLe494/1dQGEc2J 53sOdYtsJkJI7ufLq8mYD8cAGqHZUh3Mgtt5CDjFUHiPBCX8bYHC11dPgSEb5Q50 Kf+60jBghX+y9oqcSBHoWRK357/YgkEgdYYciYMdx9IjMFxH7/o= =i08o -----END PGP SIGNATURE----- --W/k2pzXB1sdSS/P9-- From owner-freebsd-current@freebsd.org Mon Jul 13 14:05:41 2020 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 07C82364E9F for ; Mon, 13 Jul 2020 14:05:41 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B555c6QLxz3yjm; Mon, 13 Jul 2020 14:05:40 +0000 (UTC) (envelope-from gjb@freebsd.org) 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 9E2CFD962; Mon, 13 Jul 2020 14:05:40 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 13 Jul 2020 14:05:38 +0000 From: Glen Barber To: freebsd-current@freebsd.org Subject: Re: arm64 panic: reaper-related? Message-ID: <20200713140538.GA46078@FreeBSD.org> References: <20200713135821.GS61041@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20200713135821.GS61041@FreeBSD.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 14:05:41 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2020 at 01:58:21PM +0000, Glen Barber wrote: > Hi, >=20 > This morning, one of our arm64 build machines panicked. It looks like > it is somehow reaper-related, but I am not entirely sure. Backtrace > follows. Any thoughts? I'm not quite sure where to go from here... > Thanks in advance for any input. >=20 > db> set $lines 0 > db> bt > Tracing pid 11 tid 100003 td 0xfffffd0001634000 > db_trace_self() at db_stack_trace+0xf8 > pc =3D 0xffff00000075fdac lr =3D 0xffff000000103e78 > sp =3D 0xffff00011eca89b0 fp =3D 0xffff00011eca89e0 >=20 > db_stack_trace() at db_command+0x228 > pc =3D 0xffff000000103e78 lr =3D 0xffff000000103af0 > sp =3D 0xffff00011eca89f0 fp =3D 0xffff00011eca8ad0 >=20 > db_command() at db_command_loop+0x58 > pc =3D 0xffff000000103af0 lr =3D 0xffff000000103898 > sp =3D 0xffff00011eca8ae0 fp =3D 0xffff00011eca8b00 >=20 > db_command_loop() at db_trap+0xf4 > pc =3D 0xffff000000103898 lr =3D 0xffff000000106c0c > sp =3D 0xffff00011eca8b10 fp =3D 0xffff00011eca8d30 >=20 > db_trap() at kdb pc =3D 0xffff000000106c0c lr =3D 0xffff00000046= 3b0c > sp =3D 0xffff00011eca8d40 fp =3D 0xffff00011eca8df0 >=20 > kdb_trap() at do_el1h_sync+0xf4 > pc =3D 0xffff000000463b0c lr =3D 0xffff00000077b448 > sp =3D 0xffff00011eca8e00 fp =3D 0xffff00011eca8e30 >=20 > do_el1h_sync() at handle_el1h_sync+0x78 > pc =3D 0xffff00000077b448 lr =3D 0xffff000000762878 > sp =3D 0xffff00011eca8e40 fp =3D 0xffff00011eca8f50 >=20 > handle_el1h_sync() at kdb_enter+0x34 > pc =3D 0xffff000000762878 lr =3D 0xffff000000463168 > sp =3D 0xffff00011eca8f60 fp =3D 0xffff00011eca8ff0 >=20 > kdb_enter() at vpanic+0x1b0 > pc =3D 0xffff000000463168 lr =3D 0xffff000000417a74 > sp =3D 0xffff00011eca9000 fp =3D 0xffff00011eca90b0 >=20 > vpanic() at panic+0x44 > pc =3D 0xffff000000417a74 lr =3D 0xffff0000004178c0 > sp =3D 0xffff00011eca90c0 fp =3D 0xffff00011eca9140 >=20 > panic() at __stack_chk_fail+0x10 > pc =3D 0xffff0000004178c0 lr =3D 0xffff00000044ab6c > sp =3D 0xffff00011eca9150 fp =3D 0xffff00011eca9150 >=20 > __stack_chk_fail() at putchar+0x2bc > pc =3D 0xffff00000044ab6c lr =3D 0xffff000000469ce8 > sp =3D 0xffff00011eca9160 fp =3D 0xffff00011eca91e0 >=20 > putchar() at 0x106 > pc =3D 0xffff000000469ce8 lr =3D 0x0000000000000106 > sp =3D 0xffff00011eca91f0 fp =3D 0x0000000000000000 >=20 > db> show proc 11 > Process 11 (idle) at 0xfffffd0001630000: > state: NORMAL > uid: 0 gids: 0 > parent: pid 0 at 0xffff0000010fae40 > ABI: null > reaper: 0xffff0000010fae40 reapsubtree: 11 > sigparent: 20 > vmspace: 0xffff000001109200 > (map 0xffff000001109200) > (map.pmap 0xffff0000011092c0) > (pmap 0xffff000001109320) > threads: 48 > 100003 Run CPU -1 [idle: cpu0] > 100004 Run CPU 1 [idle: cpu1] > 100005 Run CPU 2 [idle: cpu2] > 100006 Run CPU 3 [idle: cpu3] > 100007 Run CPU 4 [idle: cpu4] > 100008 Run CPU 5 [idle: cpu5] > 100009 Run CPU 6 [idle: cpu6] > 100010 Run CPU 7 [idle: cpu7] > 100011 Run CPU 8 [idle: cpu8] > 100012 CanRun [idle: cpu9] > 100013 Run CPU 10 [idle: cpu10] > 100014 Run CPU 11 [idle: cpu11] > 100015 Run CPU 12 [idle: cpu12] > 100016 Run CPU 13 [idle: cpu13] > 100017 Run CPU 14 [idle: cpu14] > 100018 Run CPU 15 [idle: cpu15] > 100019 Run CPU 16 [idle: cpu16] > 100020 Run CPU 17 [idle: cpu17] > 100021 Run CPU 18 [idle: cpu18] > 100022 Run CPU 19 [idle: cpu19] > 100023 Run CPU 20 [idle: cpu20] > 100024 Run CPU 21 [idle: cpu21] > 100025 Run CPU 22 [idle: cpu22] > 100026 Run CPU 23 [idle: cpu23] > 100027 Run CPU 24 [idle: cpu24] > 100028 Run CPU 25 [idle: cpu25] > 100029 Run CPU 26 [idle: cpu26] > 100030 CanRun [idle: cpu27] > 100031 Run CPU 28 [idle: cpu28] > 100032 Run CPU 29 [idle: cpu29] > 100033 Run CPU 30 [idle: cpu30] > 100034 Run CPU 31 [idle: cpu31] > 100035 Run CPU 32 [idle: cpu32] > 100036 Run CPU 33 [idle: cpu33] > 100037 Run CPU 34 [idle: cpu34] > 100038 Run CPU 35 [idle: cpu35] > 100039 Run CPU 36 [idle: cpu36] > 100040 Run CPU 37 [idle: cpu37] > 100041 Run CPU 38 [idle: cpu38] > 100042 Run CPU 39 [idle: cpu39] > 100043 Run CPU 40 [idle: cpu40] > 100044 Run CPU 41 [idle: cpu41] > 100045 Run CPU 42 [idle: cpu42] > 100046 Run CPU 43 [idle: cpu43] > 100047 Run CPU 44 [idle: cpu44] > 100048 Run CPU 45 [idle: cpu45] > 100049 Run CPU 46 [idle: cpu46] > 100050 Run CPU 47 [idle: cpu47] >=20 >=20 I should have included this as well... db> show panic panic: Misaligned access from kernel space! Glen --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl8MajIACgkQAxRYpUeP 4pOx/w/+PgyAiPug8GYiPczaIULc8S1+Q4g/B8R+kLV/dA8LVmBuQ3rvJO3U/UvF SkEv55MCAj+3MzAl5cigTmgsQRJoL7tx9c4WFFFaltcca8n7DFbRQOkSYlVSXcyg W8wYIim4zaXWPn1cEQDLy14XpLeqU3OWp2P9ehXtowwtqVM+uY8w9UBO82tFBreA RKQKIbMttEGDW7/oEMwzj9C4TEwKZ3/oALcoRk7oSPneoNxjr7ymD5x0S/OCs6kQ 2ONhg4WVe/gtWbepGyW4AX4YesnrzqwZRazFBFbNSgGmSyWhVST8o1QZh+i71++O qnli5w6D4D6nsHKLuW4QLajE/SGM6An7+FF0doZfEr84JSV9had3aWpyEKizp9ch p3NJdMJJN2ihcHKa3hD1d+AX4Ql0hewOayH+B6SyNZc5MzpZdnxo0lH05feVY0al z44XqKANInkn0+B8kuLBTr9LeXvtvAB9ra+tOha1YJ2OFRKZhNi0Uz7MDpDo8iyO mQ3APYTdMuY41v+b8nPio3SsAeKSWfGUd8NI/yE0PRAXUEw1HKznPWCKUJ8A9SZ4 CkTeef0cULDnhno8Lhyx3VtHj9G/BF0OYLDJl7WWivKR3Q7PrruIEuDu1jYe8C0c 2yNWs2XcTCMfRQMKceI5j61KbaSsavynPy7sPegkd+PBRDXz2z4= =W1le -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@freebsd.org Mon Jul 13 17:27:20 2020 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 2E90C36B038; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B59ZJ0TtSz4G6Z; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E14BB2FC09; Mon, 13 Jul 2020 17:27:19 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f41.google.com with SMTP id g139so9540624lfd.10; Mon, 13 Jul 2020 10:27:19 -0700 (PDT) X-Gm-Message-State: AOAM530CBzn5362d8ZkxsvvELYsKWsBX50PZOGery4Z1yoPOYy3iPums r8PZV4bAbh+nVKWCVFSIc5Gxd/2qIfFZmtxim7g= X-Google-Smtp-Source: ABdhPJx27xPiexmBFm2IppULhgxJHDxbmT+4h4zYmbzee1ZEKh1k00d4Va3rPc4oxES60biSZQaQlJa/0PKLXz5muvM= X-Received: by 2002:a19:a8c:: with SMTP id 134mr139172lfk.128.1594661238368; Mon, 13 Jul 2020 10:27:18 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Mon, 13 Jul 2020 10:27:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: CFT for vendor openzfs - week 2 reminder To: freebsd-current , freebsd-fs , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 17:27:20 -0000 On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. ========================================================== NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. Thanks in advance for your time. -M From owner-freebsd-current@freebsd.org Mon Jul 13 17:33:24 2020 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 992F736B8DE; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B59jJ3cfSz4Gtp; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 5A2D52FC9B; Mon, 13 Jul 2020 17:33:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-vs1-f44.google.com with SMTP id q15so7025564vso.9; Mon, 13 Jul 2020 10:33:24 -0700 (PDT) X-Gm-Message-State: AOAM5306R1o2NxPKOb91irwSUY966oxcqPWslD1LZMpN04EmTXZjlaCp YD/FHKAVYlqhov/cjbR+7yHF6HoLeNmrv9oWSuE= X-Google-Smtp-Source: ABdhPJxLP+ZFemGV2UDvUVqZph6aaR1h0y2+4eQBMZda/iTy0C7aXY85dvUWuPef+Co/tB6BIKkmK6n0QeQRd+VSg+g= X-Received: by 2002:a67:8a4a:: with SMTP id m71mr376954vsd.59.1594661603722; Mon, 13 Jul 2020 10:33:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Mon, 13 Jul 2020 12:33:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 2 reminder To: Matthew Macy Cc: freebsd-current , freebsd-fs , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 17:33:24 -0000 On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy wrote: > > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The current *tentative* merge date is > August 10th. I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > I've had no problems with this on a couple amd64 systems; I did note that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/ but I'm told a compat sysctl is on the TODO list to ease the transition. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Mon Jul 13 19:03:54 2020 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 AC47336DE41 for ; Mon, 13 Jul 2020 19:03:54 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5Cjj4M0tz4NJM for ; Mon, 13 Jul 2020 19:03:52 +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 06DJ3o4L010051 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Jul 2020 12:03:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06DJ3nbr010049; Mon, 13 Jul 2020 12:03:49 -0700 (PDT) (envelope-from jmg) Date: Mon, 13 Jul 2020 12:03:49 -0700 From: John-Mark Gurney To: Mark Millard Cc: FreeBSD Current Subject: Re: slow USB 3.0 on -current Message-ID: <20200713190349.GM4213@funkthat.com> Mail-Followup-To: Mark Millard , FreeBSD Current References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> <20200713045149.GL4213@funkthat.com> <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> 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, 13 Jul 2020 12:03:50 -0700 (PDT) X-Rspamd-Queue-Id: 4B5Cjj4M0tz4NJM 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 [3.39 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.981]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.29)[0.295]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.92)[0.918]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; 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] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 19:03:54 -0000 Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: > On 2020-Jul-12, at 21:51, John-Mark Gurney wrote: > > > Mark Millard wrote this message on Sun, Jul 12, 2020 at 18:26 -0700: > >> John-Mark Gurney jmg at funkthat.com wrote on > >> Sat Jul 11 22:44:36 UTC 2020 : > >> > >>> I'm having issues getting good ethernet performance from a USB ethernet > >>> adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > >>> AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > >>> > >>> Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > >>> adapter only gets around 10MB/sec performance. During the transfer, > >>> the CPU usage is only around 3-5%, so it's definitely not CPU bound. > >>> > >>> I have tested Windows 10 and NetBSD 9.0 performance, and both provide > >>> 100MB/sec+ w/o troubles. > >>> > >>> I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > >>> > >>> Any hints on how to fix this? > >>> > >>> This may be related, but I'm also having issues w/ booting when I have > >>> both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > >>> > >>> If I move the SD card reader to USB 2.0, the umass device will attach > >>> and work. I have also attached a clip of the dmesg from that > >>> happening. > >>> > >>> Has anyone else seen this issue? Ideas or thoughts on how to resolve > >>> the performance issues? > >> > >> It might prove useful to use iperf3 with > >> > >> # iperf3 -s > >> > >> on one machine and doing > >> > >> # iperf3 -c ADDR > >> . . . > >> # iperf3 -R -c ADDR > >> . . . > >> > >> on the other. (That last swaps the > >> sender/receiver status.) > >> > >> All 3 commands will have output. The > >> -s one will produce output for each of > >> the -c ones. > >> > >> The outputs for the sender(s) will include Cwnd > >> (congestion window size) information that may > >> be relevant. It will report bit rate and > >> retry count sampling (and overall figures). [...] > The "iperf3 -s" should have had output with the Cwnd > figures for the "Reverse mode" case above (and the > distribution for the 1381 Retr total). They might > not match when the earlier figures that you did report > for the non-Reverse mode. If you can tell how the Cwnd figures would help you figure out how to make the USB3 bus run faster, I'll spend the time to retest and give you the numbers, but I don't see how they can... [...] > > As you can see, both match approximately what I measured other methods, > > so, it's definitely not the way I measured performance. > > > >> My observation would be that neither type > >> of USB3 Ethernet adapter that I've tried > > > > What is the chipset that you tried? One of the earlier ones that I > > tried was an axe iirc, and was limited to around 500Mbps or so... > > Hmm. I only seem to be able to find one type. Its been a > while since I've used the other and I do not know where > it is at. For what I found: > > ugen0.2: at usbus0 > axge0 on uhub0 > axge0: on usbus0 > miibus1: on axge0 > rgephy0: PHY 3 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > (I have access to more than one instance of the above.) Yeah, these are the ones that are known to not be able to get close to gige speeds, unlike the RealTek one that I am using now... I forgot that axge is the gigabit version of axe... > The iperf3 output that I reported was for using > of of the above. Note that when the USB3 EtherNet > was reciveing Cwnd was reported as 29.8 KBytes > or smaller for the example run, much like your > output reporting 34.4 KBytes or less for the > example run. They grew to match the speeds that the link could do.. > This may suggest some common constraint across various > USB3 EtherNet devices. The Cwnd figures are probably > too small to get near 900 Mbit/s+. As you can see, the NetBSD results was able to grow the Cwnd large enough to obtain performance... The stats that I provided were from the non-USB3 machine, and for tx'ing to matches the issue I raised in the original post... I could provide the Cwnd, but I don't see how that will debug a USB3 speed issue... The stats show that the Cwnd can grow on other OS's (NetBSD), and on wired (bge) fine. > But, even with a (smaller but) similar Cwnd figure > my example was getting faster transfers than your > example. I got smaller Retr figures as well. It > leaves me wondering if there are packets being > rejected in your context that are not in my > context. ping times to the machine via USB3 is higher than native gige, but that isn't too surprising due to the extra latency introduced by them.. it's: round-trip min/avg/max/stddev = 0.743/0.826/0.963/0.074 ms Where as to a slower machine (PINE A64-LTS, arm64) with a couple extra switches in between: round-trip min/avg/max/stddev = 0.199/0.230/0.254/0.019 ms > If what I reported would still be too slow, there > may be two (or more) points to be addressed to > get things going fast enough for you. You > might be able to avoid one of the points by > using a type of device that already does somewhat > better. May be ask for the fastest examples > folks have observed? > > >> (different chipsets) get anywhere near > >> 100 MByte/s when ifconfig reports > >> 1000baseT . The Cwnd figures > >> are smaller than for the built-in Ethernets > >> that manage much faster overall transfer > >> rates. > > > > [...] > > > >> I'll note that between machines with built-in EtherNet > >> that can sustain fast transfers overall, the Cwnd figures > >> tend to vary but can reach 1 MBytes+. The Retr counts > >> tend to still exist. > >> > >> By contrast, when the USB3 EtherNet is receiving above, > >> the maximum Cwnd reported above for the sender at the > >> time was: 29.8 KBytes. > >> > >> I have not tried NetBSD, Windows 10, or Linux comparisons. > > > > As you can see above, NetBSD easily achieves around 8-10x the > > speed using the exact same USB3 device as FreeBSD does, so the > > hardware CAN push the speeds, just FreeBSD cannot. > > The small Cwnd figures like 34.4 KBytes suggest that a > small receiver window (Rwnd) might be specified in the > TCP header that the destination provided for that > transfer direction. Cwnd can increase up to the > Rwnd unless duplicate ACKs or timeouts occur, as I > understand. (I'm no expert.) > > This is part of the reason I thought that posting the > output (with Cwnd) for both transfer directions could > be of use: it gives a hint about what is controlling > the Cwnd if the two directions have widely different > figures vs. if both directions get similarly small > figures. Comparisons with the other OS's figures in > both directions could possibly also be suggestive, > or so I hoped. > > May be the comparison with the figures that I reported > gives someone some hints about what might be going on > in the two contexts. > > > Hence, my original post, what can I do to possibly get FreeBSD's > > performance up to what the hardware can achieve? > > > > Hopefully my notes prove of some use --but I'm not likely > to directly solve the problem. It would be handy for > me if USB3 EtherNet performed significantly better than > I have observed. Just for giggles, I used iperf3 to test UDP performance to eliminate TCP, and yep, the physical interface is limited to about 91.1Mbps... When usb3 interface transmits, I get: gold,pts,/home/jmg,506$iperf3 -R -u -b 1000M -c 192.168.0.80 Connecting to host 192.168.0.80, port 5201 Reverse mode, remote host 192.168.0.80 is sending [ 5] local 192.168.0.2 port 42932 connected to 192.168.0.80 port 5201 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 11.0 MBytes 92.1 Mbits/sec 0.271 ms 773186/781071 (99%) [ 5] 1.00-2.00 sec 10.9 MBytes 91.1 Mbits/sec 0.303 ms 235306/243103 (97%) [ 5] 2.00-3.00 sec 10.9 MBytes 91.1 Mbits/sec 0.345 ms 236328/244125 (97%) [ 5] 3.00-4.00 sec 10.9 MBytes 91.1 Mbits/sec 0.354 ms 235799/243598 (97%) [ 5] 4.00-5.00 sec 10.9 MBytes 91.1 Mbits/sec 0.404 ms 233614/241411 (97%) [ 5] 5.00-6.00 sec 10.9 MBytes 91.1 Mbits/sec 0.464 ms 235559/243356 (97%) [ 5] 6.00-7.00 sec 10.9 MBytes 91.1 Mbits/sec 0.515 ms 236272/244070 (97%) [ 5] 7.00-8.00 sec 10.9 MBytes 91.1 Mbits/sec 0.139 ms 234354/242152 (97%) [ 5] 8.00-9.00 sec 10.9 MBytes 91.1 Mbits/sec 0.150 ms 236887/244684 (97%) [ 5] 9.00-10.00 sec 10.9 MBytes 91.1 Mbits/sec 0.149 ms 236459/244257 (97%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-12.22 sec 133 MBytes 91.1 Mbits/sec 0.000 ms 0/2974757 (0%) sender [ 5] 0.00-10.00 sec 109 MBytes 91.2 Mbits/sec 0.149 ms 2893764/2971827 (97%) receiver iperf Done. and when the USB3 ethernet receives: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.0.2, port 20603 [ 5] local 192.168.0.80 port 5201 connected to 192.168.0.2 port 25350 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 9.42 MBytes 79.0 Mbits/sec 0.186 ms 111653/118418 (94%) [ 5] 1.00-2.00 sec 10.9 MBytes 91.1 Mbits/sec 0.165 ms 229690/237489 (97%) [ 5] 2.00-3.00 sec 10.9 MBytes 91.1 Mbits/sec 0.459 ms 236066/243864 (97%) [ 5] 3.00-4.00 sec 10.9 MBytes 91.1 Mbits/sec 0.219 ms 228274/236072 (97%) [ 5] 4.00-5.00 sec 10.9 MBytes 91.1 Mbits/sec 0.168 ms 224079/231877 (97%) [ 5] 5.00-6.00 sec 10.9 MBytes 91.1 Mbits/sec 0.157 ms 233127/240924 (97%) [ 5] 6.00-7.00 sec 10.9 MBytes 91.1 Mbits/sec 0.157 ms 232302/240100 (97%) [ 5] 7.00-8.00 sec 10.9 MBytes 91.1 Mbits/sec 0.376 ms 232491/240289 (97%) [ 5] 8.00-9.00 sec 10.9 MBytes 91.1 Mbits/sec 0.197 ms 230407/238205 (97%) [ 5] 9.00-10.00 sec 10.9 MBytes 91.1 Mbits/sec 0.158 ms 243574/251372 (97%) [ 5] 10.00-10.38 sec 1.42 MBytes 31.6 Mbits/sec 0.136 ms 30894/31914 (97%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.38 sec 109 MBytes 87.8 Mbits/sec 0.136 ms 2232557/2310524 (97%) receiver The transmitter reports: [ 5] 0.00-10.00 sec 1.12 GBytes 959 Mbits/sec 0.000 ms 0/2311155 (0%) sender so, it is able to transmit at close to gigabit speed. -- 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 Jul 13 19:46:38 2020 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 7D58436F396 for ; Mon, 13 Jul 2020 19:46:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4B5Dg06Qwlz4RKD for ; Mon, 13 Jul 2020 19:46:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VOI4GS4VM1nOuAzsJhr.B5hJUx45PtONULTE8NX1UHmNiU4qZOSntdItUOrszFb lVi6WdYC5qqVB4Yy4eavRG_ZYJAPOdLe6ZOOflsXL.zPa0FgIgbYLw5HbzLRfAw_f8zJUGVlXz1S T_HE712CAdLnAsPpFexjuol1cq9yUNtDJpHR6QfO7KhoU6e294NkEJswyLY7zi70FBv7pBnrA6rw gfwZ8bsSCkpxsrv.wM_WnxB4kALnv2wGe0q.lHOjduINQfAroPmJm3Dv21.ZDvXkVDVQs.PWm_9Q lBhxm4ibD00maaEGk4pD29dkYthIVE7okRgDqEtC7tGrdvWBzS8FUD8BGwoB2HDWoQTsY8c464TZ f7b2obPaNZQnxDQK6stlE6GiK4C6dAxZVcolq0MNb7SZxhAoKvi8Mfjv4heZ.AuA6Gzl9b8DBe2N cXibtzPtdR7AR1OaEPfVCsoZnqZWfuVsPHVEubRoJGOcZGNyXWYWddxdPGisjHgLTu8dOjIkWser cCKWwWTR10mbYbSXJHP4wirlWT4u8xPXgE0_PSdOlwt4iltIdVenp2s9pElevm7Xh5gW8EGd8R4F Y5MIJvl6us3c_gVxfnvSrCPfHr7Gf2qw7iJ26WDy46lR0YB687OQ.SDRYtqze51EVXIISkujuRpd 9ryCYI1pzIMJHCTVbOJy.OWS1VvEEnHdP2WEk5HO2pTBPPVgfgeaOxcjL9j2wFiNiKqQRtZ2f_z9 hl1OqK.C8VH7OBE8Bn06W4oPwoDpD4lJ6ldmCkBFaZCpujcDIfSVXpLcZiWTZA04XjJJ.cnX_nwi lyEvmlwwWYqtxVvil4rM8Nmodn_FD3PijQpS6t4DPAmwRdtDZhkYAZl1RJATD.C97_D6xOrEeNiy 9MQyZ0AY5Q2GBKLJZAJWtD9AEnBil3z5TxbneC3aqT1VqYRNvr3HeXbYyISemrmETuoifN0fTMus wAqOlwjZpfwpHejb1VKFOECF4vdMxfg65pcCFtyPCggzUAVBphzsuLkx_v0yqPQ4w7aRmH7JJs3Q JaJFl1KUgSUiBGFdFvEMmtSoiT3WMv7yaKJsz2QCE8i0iPaTurvCajy2IBqjtiWRhowQGp2WQT5p kYngEkt_fYPATb2aEVfneNNMC3utqYtgq71l2v_Sxns567hBf_.Paeo.l_Qxh6EOp8JDRChSkELy wOwbtBpmAqEuK2d0pqUsCaK.jxBr_lHEgX5xd16y18SlWnqvuILtw5uZHTyb7pGeZWwxovNey8wb bTSH9zoLxPX3ipocnjSoBkGr8sL6sQV0thyFe1R3jD0s5vg438ZryzbtZBV6DuNrpkSFAaFi8gYi 3l6c_UBKihkJHlt1uQx83rzH8m.kEuiwc9NIzocx_HVS.r4kNMbOxPVKThVr229X07EfrI8.yqR. x.PuHzxpc.sxL77lbGoyRR5hm Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Jul 2020 19:46:35 +0000 Received: by smtp428.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6a1d2fdd95f3dbfbda464e8e34f1143d; Mon, 13 Jul 2020 19:46:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: slow USB 3.0 on -current From: Mark Millard In-Reply-To: <20200713190349.GM4213@funkthat.com> Date: Mon, 13 Jul 2020 12:46:32 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> <20200713045149.GL4213@funkthat.com> <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> <20200713190349.GM4213@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B5Dg06Qwlz4RKD X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; NEURAL_HAM_SHORT(-0.52)[-0.523]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 19:46:38 -0000 On 2020-Jul-13, at 12:03, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: >> On 2020-Jul-12, at 21:51, John-Mark Gurney = wrote: >>=20 >>> . . . >>=20 >> Hmm. I only seem to be able to find one type. Its been a >> while since I've used the other and I do not know where >> it is at. For what I found: >>=20 >> ugen0.2: at usbus0 >> axge0 on uhub0 >> axge0: on usbus0 >> miibus1: on axge0 >> rgephy0: PHY 3 on = miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >>=20 >> (I have access to more than one instance of the above.) >=20 > Yeah, these are the ones that are known to not be able to get close > to gige speeds, unlike the RealTek one that I am using now... Hmm, in one direction anyway? NetBSD current testing on a RPi4 for iperf3 -R -c 192.168.1.120 -B 192.168.1.140 : Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.140, port 65525 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port = 65524 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 33.7 MBytes 282 Mbits/sec 0 33.9 KBytes = =20 [ 5] 1.00-2.00 sec 96.0 MBytes 805 Mbits/sec 2 48.9 KBytes = =20 [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 12 81.9 KBytes = =20 [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec 18 114 KBytes = =20 [ 5] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec 42 145 KBytes = =20 [ 5] 5.00-6.00 sec 84.8 MBytes 712 Mbits/sec 50 178 KBytes = =20 [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 40 194 KBytes = =20 [ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 40 194 KBytes = =20 [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 47 194 KBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 927 Mbits/sec 50 193 KBytes = =20 [ 5] 10.00-10.62 sec 68.4 MBytes 929 Mbits/sec 46 193 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender and as seen on the receiver: # iperf3 -R -c 192.168.1.120 -B 192.168.1.140 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.140 port 65524 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 87.8 MBytes 736 Mbits/sec =20 [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec =20 [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec =20 [ 5] 3.00-4.00 sec 83.6 MBytes 701 Mbits/sec =20 [ 5] 4.00-5.00 sec 84.8 MBytes 711 Mbits/sec =20 [ 5] 5.00-6.00 sec 111 MBytes 931 Mbits/sec =20 [ 5] 6.00-7.00 sec 83.4 MBytes 700 Mbits/sec =20 [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec =20 [ 5] 9.00-10.00 sec 111 MBytes 929 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender [ 5] 0.00-10.00 sec 977 MBytes 819 Mbits/sec = receiver This is faster than the built-in EtherNet results. (But the built-in is also USB based.) As for iperf3 -c 192.168.1.120 -B 192.168.1.140 it is slower: Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.140 port 65526 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 62.5 MBytes 522 Mbits/sec 0 4.00 MBytes = =20 [ 5] 1.00-2.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 MBytes = =20 [ 5] 2.01-3.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 MBytes = =20 [ 5] 3.01-4.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 MBytes = =20 [ 5] 4.01-5.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 MBytes = =20 [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec 0 4.00 MBytes = =20 [ 5] 6.01-7.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 MBytes = =20 [ 5] 7.01-8.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 MBytes = =20 [ 5] 8.01-9.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 MBytes = =20 [ 5] 9.01-10.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 625 MBytes 524 Mbits/sec 0 = sender [ 5] 0.00-10.62 sec 625 MBytes 494 Mbits/sec = receiver This is again faster than the built-in EtherNet results. =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 Jul 13 20:10:23 2020 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 D610036F6E5; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5FBR53JHz4Sch; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 99DD214877; Mon, 13 Jul 2020 20:10:23 +0000 (UTC) Date: Mon, 13 Jul 2020 20:10:23 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-07-12 Message-ID: <20200713201023.GA65411@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 20:10:23 -0000 FreeBSD CI Weekly Report 2020-07-12 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-07-06 to 2020-07-12. During this period, we have: * 1964 builds (95.7% (+0.0) passed, 4.3% (+0.0) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 225 test runs (86.7% (-4.7) passed, 13.3% (+6.1) unstable, 0.0% (-1.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 36 doc and www builds (100% (+4.3) passed) Test case status (on 2020-07-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | ------- | | head/amd64 | 7859 (+2) | 7767 (+5) | 0 (0) | 92 (-3) | | head/i386 | 7857 (+2) | 7758 (+5) | 0 (0) | 99 (-3) | | 12-STABLE/amd64 | 7617 (0) | 7557 (+1) | 0 (0) | 60 (-1) | | 12-STABLE/i386 | 7615 (0) | 7547 (+1) | 0 (0) | 68 (-1) | | 11-STABLE/amd64 | 6912 (0) | 6861 (0) | 0 (0) | 51 (0) | | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200712 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 ## Issues ### Cause build fails * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Mon Jul 13 20:18:59 2020 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 BBE5E370212 for ; Mon, 13 Jul 2020 20:18:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4B5FNL52YDz4TJY for ; Mon, 13 Jul 2020 20:18:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: j8nhyMYVM1lkffll62ImFbRHjKfx9qd5omYSnh5o2A4DRIw2trUgaamvF7VZG7t XW3VBSDDA41IykKzh0vq.Yt3_OJVmPxWHMdQupCsFQnWlTpRPzJkZL.Dagz81gyMca4CdDv2Nofi 7rwxij22guSLnaihkP0BlY5CaFjzPSsBFjI81o.5rZvDXjz7oKOUWH7ZH2jd.9HhRSvPzASx3jNu loN_K6OfJZm1HY9_bYnPixQlrgsVE0bhaXfCAGLRV67rC1tXKbfsCEWBRn9YCyngclBxG8VV.oW2 qyq6cLYW841iB8Civ_x3i0VnTPeKEvXFxgrFbz8DuCJHAzpZNzqlavM1LbHBDfI._rX_kI6npghM 2sORCImeWCPY2v7AWZQnLG3eaftH9L__xUTS4J6x317IoY18w0xI8tv9yc5X4RqlIswMrs07Xaa4 5Rv8gsAA95TWlqBir2cdD2j8kMLO0_jhaGLpzRkXG5pOVQQUZuFxxJD.XLixfDL.R651_1R1f1HF 5ZlO4qTtJT7SAk76eIULgVgdh4miXCetK4Gw4xWhBD3y5r6UPPXLeehkJYCz3IkNi.L0EV1y_Onf SEeZ0Jz8ti6LDJqdupVRAJz3IKRt_c.m69HS.fJKGQabdp07msXTG6BKAP_KtuZcatIam61k0n_I ZulVR7k3dSQt7V0hrbqLav2QQUPiUqk5efBO._9WKm_bqY4nBhpu8U.64PT98is69eErMRA8_k7E Cl0oO31oHSbqKWbKKZdKwJi68TCDCxKGj0Wh4tQJHV876HuhurUm0shBFgfgWmLjxnmbEgw2LeFZ Wh6.JuKTAV9ayAn3x1WBwowPLNaD_60W3i1pTcAkbEl7yV6_j4ivVCRtFAPaCjjueKoRWJDwiyj0 rXt1V3RkN3Ql8s8XeSvpJlIOMsEPCbfy8G7kl3YitS6KOu_xijvS9Y_ab9VYKkYE5G6RLjOGw6jw Fukh3pQbfBB7El0tTT5HfFYCiczgvcHLVLWrJpKETr7MXC2bxM6SD3xdfjjv2pawcXAltGoPz5.P 3uEwqUPEYMMYM_R22qAoYA1zC3GPO07W0aeP72WLoz8sMd067f70irR7fIo7SZyoAdPOuVxL0art Xz9KlOga9D_pevQVVd1ilOPow6DAEQUxSXCXMdilWw.tSCZkNPRO76F8HTP5sp_X14mFyBXXZj3p IuO07ZhJposFDPToj5iPAVuDM02S3zuy4LOuPGwBhcEsnekRQQMPwFLY89XyHLZyR9pSsFvQ9N0Z qMbopzG8QzN1FDim.JHWkll9y1n5OAs0GEsoQ0YAnyQDHS9B_.BAiKe1dMUFlnIxdQBpFf9a9NIL ULluVEli66LRmtjQJ7lxpYV4cY4dKWNESCMjk426cnRAA9kge0PX2BbQQtruMCI31UYuFESyi0RG nydqLG2CDs21cF.EQS8lIuTuF2MXa_rp_zVXhxGi9tOfm04y_xG.mUsi6G9MZ2Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Jul 2020 20:18:57 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c59024b1283cab288be4ed44750016ba; Mon, 13 Jul 2020 20:18:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: slow USB 3.0 on -current From: Mark Millard In-Reply-To: Date: Mon, 13 Jul 2020 13:18:54 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> <20200713045149.GL4213@funkthat.com> <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> <20200713190349.GM4213@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B5FNL52YDz4TJY X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; NEURAL_HAM_SHORT(-0.52)[-0.524]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 20:18:59 -0000 [Just a correction to a side comment.] On 2020-Jul-13, at 12:46, Mark Millard wrote: > On 2020-Jul-13, at 12:03, John-Mark Gurney = wrote: >=20 >> Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: >>> On 2020-Jul-12, at 21:51, John-Mark Gurney = wrote: >>>=20 >>>> . . . >>>=20 >>> Hmm. I only seem to be able to find one type. Its been a >>> while since I've used the other and I do not know where >>> it is at. For what I found: >>>=20 >>> ugen0.2: at usbus0 >>> axge0 on uhub0 >>> axge0: on usbus0 >>> miibus1: on axge0 >>> rgephy0: PHY 3 on = miibus1 >>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >>>=20 >>> (I have access to more than one instance of the above.) >>=20 >> Yeah, these are the ones that are known to not be able to get close >> to gige speeds, unlike the RealTek one that I am using now... >=20 > Hmm, in one direction anyway? >=20 > NetBSD current testing on a RPi4 for > iperf3 -R -c 192.168.1.120 -B 192.168.1.140 : >=20 > Server listening on 5201 > ----------------------------------------------------------- > Accepted connection from 192.168.1.140, port 65525 > [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port = 65524 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 33.7 MBytes 282 Mbits/sec 0 33.9 = KBytes =20 > [ 5] 1.00-2.00 sec 96.0 MBytes 805 Mbits/sec 2 48.9 = KBytes =20 > [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 12 81.9 = KBytes =20 > [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec 18 114 = KBytes =20 > [ 5] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec 42 145 = KBytes =20 > [ 5] 5.00-6.00 sec 84.8 MBytes 712 Mbits/sec 50 178 = KBytes =20 > [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 40 194 = KBytes =20 > [ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 40 194 = KBytes =20 > [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 47 194 = KBytes =20 > [ 5] 9.00-10.00 sec 111 MBytes 927 Mbits/sec 50 193 = KBytes =20 > [ 5] 10.00-10.62 sec 68.4 MBytes 929 Mbits/sec 46 193 = KBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender >=20 > and as seen on the receiver: >=20 > # iperf3 -R -c 192.168.1.120 -B 192.168.1.140 > Connecting to host 192.168.1.120, port 5201 > Reverse mode, remote host 192.168.1.120 is sending > [ 5] local 192.168.1.140 port 65524 connected to 192.168.1.120 port = 5201 > [ ID] Interval Transfer Bitrate > [ 5] 0.00-1.00 sec 87.8 MBytes 736 Mbits/sec =20= > [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec =20= > [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec =20= > [ 5] 3.00-4.00 sec 83.6 MBytes 701 Mbits/sec =20= > [ 5] 4.00-5.00 sec 84.8 MBytes 711 Mbits/sec =20= > [ 5] 5.00-6.00 sec 111 MBytes 931 Mbits/sec =20= > [ 5] 6.00-7.00 sec 83.4 MBytes 700 Mbits/sec =20= > [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec =20= > [ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec =20= > [ 5] 9.00-10.00 sec 111 MBytes 929 Mbits/sec =20= > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender > [ 5] 0.00-10.00 sec 977 MBytes 819 Mbits/sec = receiver >=20 > This is faster than the built-in EtherNet results. > (But the built-in is also USB based.) The built-in EtherNet does not show in usbdevs output. I got the context wrong for the ()'d note. > As for iperf3 -c 192.168.1.120 -B 192.168.1.140 it is > slower: >=20 > Connecting to host 192.168.1.120, port 5201 > [ 5] local 192.168.1.140 port 65526 connected to 192.168.1.120 port = 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 62.5 MBytes 522 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 1.00-2.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 2.01-3.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 3.01-4.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 4.01-5.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 6.01-7.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 7.01-8.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 8.01-9.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 > [ 5] 9.01-10.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.01 sec 625 MBytes 524 Mbits/sec 0 = sender > [ 5] 0.00-10.62 sec 625 MBytes 494 Mbits/sec = receiver >=20 > This is again faster than the built-in EtherNet results. =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 Jul 13 21:50:18 2020 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 A214B371BBD for ; Mon, 13 Jul 2020 21:50:18 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 4B5HPh5Tmnz4YmW for ; Mon, 13 Jul 2020 21:50:16 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9E983433C2; Mon, 13 Jul 2020 23:50:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-oWErj-MHnv; Mon, 13 Jul 2020 23:50:06 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (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 smtp.digiware.nl (Postfix) with ESMTPSA id D2A4A433C1 for ; Mon, 13 Jul 2020 23:50:06 +0200 (CEST) To: freebsd current From: Willem Jan Withagen Subject: Current panics on connecting disks to a LSI-3108 controller Message-ID: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> Date: Mon, 13 Jul 2020 23:50:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Language: en-GB X-Rspamd-Queue-Id: 4B5HPh5Tmnz4YmW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 2001:4cb8:90:ffff::3 as permitted sender) smtp.mailfrom=wjw@digiware.nl X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[digiware.nl]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.986]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.498]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 21:50:18 -0000 Hi, I have this Supermicro SUPERSERVER®2028TP Which hold four nodes each with a X10DRT-PT motherboard and a LSI-3108 SAS controller connecting to 6 disks. Trying to run the most recent current snapshot on it. # uname -a FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r363032: Thu Jul  9 04:13:17 UTC 2020 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I have installed the OS on a SATA flash DOM. Booting works fine as long as there are no disks connected to LSI-3108 controller. Booting with SAS disks connected results in a panic. Attaching a SAS disk to the LSI-3108 controller give a panic as well. AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd mfi0: port 0x6000-0x60ff mem 0xc7300000-0xc730ffff,0xc7200000-0xc72fffff irq 26 at device 0.0 numa-domain 0 on pci3 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: FW MaxCmds = 928, limiting to 128 mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 ..... mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started (PCI ID 005d/1000/0809/15d9) pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firmware version 4.290.00-4536 I have posted screenshots of the panic at:     www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 But basically it crashes in     mfi_tbolt_send_frame() +0x132 So is there anybody out there that can help me with analyzing and fixing this panic? Thanx, --WjW From owner-freebsd-current@freebsd.org Mon Jul 13 22:39:24 2020 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 8B0AB374081; Mon, 13 Jul 2020 22:39:24 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5JVM40P7z4cw1; Mon, 13 Jul 2020 22:39:23 +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 06DMdL2i020625 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Jul 2020 15:39:21 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 06DMdKKK020623; Mon, 13 Jul 2020 15:39:20 -0700 (PDT) (envelope-from jmg) Date: Mon, 13 Jul 2020 15:39:20 -0700 From: John-Mark Gurney To: Hans Petter Selasky Cc: Kevin Oberman , "freebsd-usb@FreeBSD.org" , FreeBSD Current Subject: Re: slow USB 3.0 on -current Message-ID: <20200713223920.GO4213@funkthat.com> Mail-Followup-To: Hans Petter Selasky , Kevin Oberman , "freebsd-usb@FreeBSD.org" , FreeBSD Current References: <20200711224426.GC4213@funkthat.com> <20200712215449.GI4213@funkthat.com> <20200713010240.GJ4213@funkthat.com> <50d00b19-9e27-4d0f-f3d1-af0574687c14@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50d00b19-9e27-4d0f-f3d1-af0574687c14@selasky.org> 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, 13 Jul 2020 15:39:21 -0700 (PDT) X-Rspamd-Queue-Id: 4B5JVM40P7z4cw1 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.79 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.11)[-0.113]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.16)[-0.162]; NEURAL_HAM_MEDIUM(-0.14)[-0.140]; 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]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 22:39:24 -0000 Hans Petter Selasky wrote this message on Mon, Jul 13, 2020 at 10:50 +0200: > On 2020-07-13 03:02, John-Mark Gurney wrote: > > MB means megabytes.. I would use Mbps for bits... so, on Win10 and > > NetBSD, I'm able to get 100 MBytes/sec on Win10/NetBSD, and FreeBSD, > > I'm only getting a tenth the capability of gige at 9-10 MBytes/sec... > > > > I'll note that fetch reports numbers of MBps, which is one of the tools > > I've been using for testing. > > Could you have a look at the traffic pattern, when using iperf? > > usbdump -i usbusX -f Y > > Where X and Y are the numbers after ugen . > > Many of the network USB drivers are single buffered, because that's what > older USB host controllers support. Then the IRQ rate 8000 for USB > 2.0/3.0 and 1000 for USB 1.0, limits the number of packets per second. Hmm... now that I do the math, that sounds very likely what the problem is: 8000 int/s * 1480 bytes/int * 8 bits/byte /1000/1000 == 94.72 Mbps add in the delay to swap buffers... and this is very close to the speed that I'm seeing... I wasn't sure what to look for, but the output is here: https://www.funkthat.com/~jmg/FreeBSD/usb.a78/usbdump.0.4.txt.xz Also, the output does not match what the man page says.. It implies that OUT or IN, but I'm seeing SUBM and DONE instead, and the delimiters between the feels don't make sense... This was running: gold,pts,/home/jmg,521$iperf3 -b 240m -u -c 192.168.0.80 Connecting to host 192.168.0.80, port 5201 [ 5] local 192.168.0.2 port 65117 connected to 192.168.0.80 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 28.6 MBytes 240 Mbits/sec 20531 [ 5] 1.00-2.00 sec 28.6 MBytes 240 Mbits/sec 20548 [ 5] 2.00-3.00 sec 28.6 MBytes 240 Mbits/sec 20550 [ 5] 3.00-4.00 sec 28.6 MBytes 240 Mbits/sec 20546 [ 5] 4.00-5.00 sec 28.6 MBytes 240 Mbits/sec 20551 [ 5] 5.00-6.00 sec 28.6 MBytes 240 Mbits/sec 20545 [ 5] 6.00-7.00 sec 28.6 MBytes 240 Mbits/sec 20548 [ 5] 7.00-8.01 sec 28.1 MBytes 234 Mbits/sec 20175 [ 5] 8.01-9.00 sec 29.1 MBytes 246 Mbits/sec 20921 [ 5] 9.00-10.00 sec 28.6 MBytes 240 Mbits/sec 20548 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 286 MBytes 240 Mbits/sec 0.000 ms 0/205463 (0%) sender [ 5] 0.00-10.35 sec 107 MBytes 87.1 Mbits/sec 0.172 ms 128298/205436 (62%) receiver Which is trying to send 240Mbps UDP traffic to the USB3 ethernet machine, and the machine only receives the usual 91Mbps... I have also published: https://www.funkthat.com/~jmg/FreeBSD/usb.a78/umass.debug.txt.xz Which shows the umass issue that I've been having where any umass device on this system almost never attaches... This was takes w/ hw.usb.umass.debug=-1 hw.usb.xhci.debug=17 I set those sysctl's, then attached the umass device (as USB3.0 SD card reader), waited for the five retries.. -- 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 Jul 13 22:39:45 2020 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 9EC96373E31 for ; Mon, 13 Jul 2020 22:39:45 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [IPv6:2a02:2770::216:3eff:fee1:cf9]) (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 4B5JVl5Ggrz4cyW; Mon, 13 Jul 2020 22:39:43 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (localhost [IPv6:::1]) by yggdrasil.evilham.com (Postfix) with ESMTP id 4B5JVb281bzypJ; Tue, 14 Jul 2020 00:39:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=evilham.com; h=from:to:cc :subject:references:in-reply-to:date:message-id:mime-version :content-type; s=mail; bh=/sRE+rma83cvLMUU0k6GDDt8aSk=; b=dGokak t0VP+UC2SLEkzPT5BIW7o91DkCqEUx7njrO/NZ6TBQXg82MyEjvOi9FMxv3HcDX7 N06KfUOdWnnqCtWvbSUaKjAA/qePuEwTBVFZQVKy7/yDxTTVEG0yfg9ESsiTDVk6 7ytZRCTK7Wx9b4Jb2mS94l0l4LHVaUds9qjWs= Received: from yggdrasil.evilham.com (unknown [IPv6:2a0a:e5c1:121:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by yggdrasil.evilham.com (Postfix) with ESMTPSA id 4B5JVZ5N7pzypH; Tue, 14 Jul 2020 00:39:34 +0200 (CEST) From: Evilham To: freebsd-current@freebsd.org Cc: Matthew Macy Subject: Re: CFT for vendor openzfs - week 2 reminder References: In-reply-to: Date: Tue, 14 Jul 2020 00:39:33 +0200 Message-ID: <772a8068-cf16-4fb8-8cb9-5592b6d92490@yggdrasil.evilham.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 4B5JVl5Ggrz4cyW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=evilham.com header.s=mail header.b=dGokak t; dmarc=pass (policy=none) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 2a02:2770::216:3eff:fee1:cf9 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-3.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_REJECT(0.00)[evilham.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.017]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[evilham.com:-]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[evilham.com,none]; NEURAL_HAM_SHORT(-0.21)[-0.213]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:196752, ipnet:2a02:2770::/32, country:NL] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 22:39:45 -0000 On dl., jul. 13 2020, Kyle Evans wrote: > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy > wrote: >> >> On Wednesday, July 8th I issued the initial call for testing >> for the >> update to HEAD to vendored openzfs. We'd like to give users >> roughly a >> month to test before merging. The current *tentative* merge >> date is >> August 10th. I hope it's not terribly controversial to point >> out that >> it really rests with users of non amd64 platforms to test to >> avoid any >> unpleasant surprises the next time they update their trees >> following >> the merge. >> > > I've had no problems with this on a couple amd64 systems; I did > note > that my loader.conf's needed a good > s/vfs.zfs.arc_max/vfs.zfs.arc.max/ > but I'm told a compat sysctl is on the TODO list to ease the > transition. I've also been using this on amd64 for a few days without any issues, it's even fixed a bug I've been trying to figure out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544 I have noticed a thing though: Previously observed behaviour: 1. A new zpool is made available (e.g. geli attach) 2. The zpool is imported 3. Something happens (e.g. system reboot) and the zpool is not available anymore but also not exported 4. The zpool is made available again 5. The zpool is *still* imported 6. The zpool must be manually mounted With the patches for OpenZFS, number 5 and 6 are instead: 5. The data zpool is not imported 6. The zpool must be manually re-imported It is different behaviour, but I am very unsure about whether or not that is to be considered a bug and needs a PR. -- Evilham From owner-freebsd-current@freebsd.org Mon Jul 13 22:48:04 2020 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 A532937471F for ; Mon, 13 Jul 2020 22:48:04 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 4B5JhM3Pdfz4f1y for ; Mon, 13 Jul 2020 22:48:03 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 9650E580355; Mon, 13 Jul 2020 18:48:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 13 Jul 2020 18:48:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=0 JrWMGXCn8YsRPBukGBu9cnOQmq+/sqB56B8EB7SMrg=; b=Q/lyGT/LmijShujXo 9wEKA8MnhVsxpJEL8HHWwOBeNkJdwlAC6WZ/DDu9TPW7STUrd6vNQwEBx6E7bmFs NrfRVYTW0FJkTr1gk8RZ+d0TRr3BracS6eadhmbChcBEvfLpYklZYKsOKr32ANSx nAtrXDWnXT/+Z3ZUV518bprS27Svcn6aJOuJ/s90rIfvn6ksa0z1JwRPSgypBzKx gnecmptlZUGORMopLRrSJEhIeINvRM+x28WlN2r7IKQFqWzAtoVft0lw+9mfwIr1 VjoJFav5TXsPdzaoEIpTdhxe4dTNxfVzBCuMVtQEveVPLbEBKcybac2BjZ6PjzTd NBP+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=0JrWMGXCn8YsRPBukGBu9cnOQmq+/sqB56B8EB7SM rg=; b=IJB3B8//CpAaEhm3QMjIXqS2rrdM+ZECA86N9UPBhX49TmP2oR0Y+o8Ca Y6DTk28LK0+wILdvG1Qqa/Pxg2Pw1ENflqtlVeZDLZP0i9jP9QgtjPJIKGIBEevs +aVmQZhlNBWBcMDVQIOSuRf09tz3Dh1O3+7UHhE8uQLX2FGiKugNHINRxj6um6v8 8faoT89AETn0bv6VhfAqkviQptLaNyDZWiwnFVdMyMq2CxMEg0i+eolcyX1OURiT JwpewbM18xRoDikgFHbevKdcik+koburPAwVafpj6GqRHxoltz22S0SH6TfqbhuF JZZQEp/W/yU4O0i/eBCWmDulWYCBQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeehnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepjeegfefhfffgudetfffggfegledtteevveelkeevtdejffetvdeifffhkeegvdfg necuffhomhgrihhnpeguihhgihifrghrvgdrnhhlpdhtvghgvghnsghoshgthhdvkedrnh hlnecukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 42FCA30600A9; Mon, 13 Jul 2020 18:48:01 -0400 (EDT) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Willem Jan Withagen , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> From: Yuri Pankov Message-ID: <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> Date: Tue, 14 Jul 2020 01:47:59 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B5JhM3Pdfz4f1y X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=Q/lyGT/L; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=IJB3B8//; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 66.111.4.221 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [-3.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.221:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.221]; NEURAL_HAM_LONG(-1.01)[-1.015]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[yuripv.dev]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.13)[-1.130]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.221:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 22:48:04 -0000 Willem Jan Withagen wrote: > Hi, > > I have this Supermicro SUPERSERVER®2028TP > Which hold four nodes each with a X10DRT-PT motherboard > and a LSI-3108 SAS controller connecting to 6 disks. > > Trying to run the most recent current snapshot on it. > # uname -a > FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > r363032: Thu Jul  9 04:13:17 UTC 2020 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > I have installed the OS on a SATA flash DOM. > Booting works fine as long as there are no disks connected to LSI-3108 > controller. > Booting with SAS disks connected results in a panic. > Attaching a SAS disk to the LSI-3108 controller give a panic as well. > > > > AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd > mfi0: port 0x6000-0x60ff mem > 0xc7300000-0xc730ffff,0xc7200000-0xc72fffff irq 26 at device > 0.0 numa-domain 0 on pci3 > mfi0: Using MSI > mfi0: Megaraid SAS driver Ver 4.23 > mfi0: FW MaxCmds = 928, limiting to 128 > mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 > ..... > mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started > (PCI ID 005d/1000/0809/15d9) > pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - > Firmware version 4.290.00-4536 > > > I have posted screenshots of the panic at: >     www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 > > But basically it crashes in >     mfi_tbolt_send_frame() +0x132 > > So is there anybody out there that can help me with analyzing and fixing > this panic? I guess it's not the answer you are looking for, but you could try the mrsas driver and check if it's behaves better for you, by setting 'set hw.mfi.mrsas_enable=1' from loader prompt. From owner-freebsd-current@freebsd.org Mon Jul 13 23:39:33 2020 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 9E9933752D2 for ; Mon, 13 Jul 2020 23:39:33 +0000 (UTC) (envelope-from mmacy@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5Kqn3ZKxz3S7C for ; Mon, 13 Jul 2020 23:39:33 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 55EBE12049 for ; Mon, 13 Jul 2020 23:39:33 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lj1-f170.google.com with SMTP id s9so20217928ljm.11 for ; Mon, 13 Jul 2020 16:39:33 -0700 (PDT) X-Gm-Message-State: AOAM532IlUccSOOMZbLXvOrIGiX3uunVIfDqc0dH4qEXNK/HKg+gK2B3 saJkSuEETFX9NvE6NYciW38ZPXgASbM6z366hqI= X-Google-Smtp-Source: ABdhPJynqYRRz7BK/MxpvZCYvAEHZHySPaq94Ww3aX+/ESbxUpaAS7oZ9ypIWq8MN1Vm4xxQBTPRoDWVvBuDjM9v8gY= X-Received: by 2002:a2e:943:: with SMTP id 64mr861677ljj.445.1594683571818; Mon, 13 Jul 2020 16:39:31 -0700 (PDT) MIME-Version: 1.0 References: <772a8068-cf16-4fb8-8cb9-5592b6d92490@yggdrasil.evilham.com> In-Reply-To: <772a8068-cf16-4fb8-8cb9-5592b6d92490@yggdrasil.evilham.com> From: Matthew Macy Date: Mon, 13 Jul 2020 16:39:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 2 reminder To: Evilham Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 23:39:33 -0000 To help us keep track, please file an issue https://github.com/zfsonfreebsd/zof/issues Thanks. On Mon, Jul 13, 2020 at 3:39 PM Evilham wrote: > > On dl., jul. 13 2020, Kyle Evans wrote: > > > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy > > wrote: > >> > >> On Wednesday, July 8th I issued the initial call for testing > >> for the > >> update to HEAD to vendored openzfs. We'd like to give users > >> roughly a > >> month to test before merging. The current *tentative* merge > >> date is > >> August 10th. I hope it's not terribly controversial to point > >> out that > >> it really rests with users of non amd64 platforms to test to > >> avoid any > >> unpleasant surprises the next time they update their trees > >> following > >> the merge. > >> > > > > I've had no problems with this on a couple amd64 systems; I did > > note > > that my loader.conf's needed a good > > s/vfs.zfs.arc_max/vfs.zfs.arc.max/ > > but I'm told a compat sysctl is on the TODO list to ease the > > transition. > > > I've also been using this on amd64 for a few days without any > issues, it's even fixed a bug I've been trying to figure out: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544 > > I have noticed a thing though: > > Previously observed behaviour: > 1. A new zpool is made available (e.g. geli attach) > 2. The zpool is imported > 3. Something happens (e.g. system reboot) and the zpool is not > available anymore but also not exported > 4. The zpool is made available again > 5. The zpool is *still* imported > 6. The zpool must be manually mounted > > With the patches for OpenZFS, number 5 and 6 are instead: > 5. The data zpool is not imported > 6. The zpool must be manually re-imported > > It is different behaviour, but I am very unsure about whether or > not that is to be considered a bug and needs a PR. > -- > Evilham From owner-freebsd-current@freebsd.org Mon Jul 13 23:42:00 2020 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 E3FF53759A8 for ; Mon, 13 Jul 2020 23:42:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5Ktc0ckrz3Skv for ; Mon, 13 Jul 2020 23:41:59 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.160] (cpe-23-243-161-111.socal.res.rr.com [23.243.161.111]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 55c58ee8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 13 Jul 2020 23:41:59 +0000 (UTC) Subject: Re: -CURRENT and drm-devel-kmod To: Andreas Nilsson , Emmanuel Vadot Cc: Current FreeBSD References: <20200711000320.6df86038c8d61b9235475f95@bidouilliste.com> From: Pete Wright Message-ID: <3c2afe40-47d8-45aa-fc2a-0025ea0ea9d5@nomadlogic.org> Date: Mon, 13 Jul 2020 16:41:58 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4B5Ktc0ckrz3Skv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-1.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-0.96)[-0.961]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_MEDIUM(-0.93)[-0.935]; NEURAL_SPAM_SHORT(0.39)[0.393]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,bidouilliste.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[23.243.161.111:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 13 Jul 2020 23:42:00 -0000 On 7/11/20 6:55 AM, Andreas Nilsson wrote: > >>> However, when I load i915kms from -devel >>> the console stops refreshing. It only refreshes when I switch >>> (Ctrl+alt+Fx). I see it refresh and display the new content just before >>> switching to the requested console. >> add hw.i915kms.enable_psr=0 to /boot/loader.conf >> This is a bug that none of my hardware have and I don't really know >> what's happening for now. >> > Thanks, setting that fixed the problem! > ah thanks for asking this question Andreas (and the pointer Manu)! I've had this issue for a while but have been just blindly typing my login and xinit wrapper. interestingly enough, I've found if I start then exit Xorg the console starts updating again. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Jul 14 00:39:25 2020 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 1804B376730 for ; Tue, 14 Jul 2020 00:39:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 4B5M8q6GXhz3VVk for ; Tue, 14 Jul 2020 00:39:23 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 7DC007124E; Tue, 14 Jul 2020 02:39:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXYFjPE9QQPY; Tue, 14 Jul 2020 02:39:20 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (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 smtp.digiware.nl (Postfix) with ESMTPSA id 9AB067124B; Tue, 14 Jul 2020 02:39:20 +0200 (CEST) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> From: Willem Jan Withagen Message-ID: <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> Date: Tue, 14 Jul 2020 02:39:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl X-Rspamd-Queue-Id: 4B5M8q6GXhz3VVk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 176.74.240.9 as permitted sender) smtp.mailfrom=wjw@digiware.nl X-Spamd-Result: default: False [-2.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[digiware.nl]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[176.74.240.9:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.15)[-0.148]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:28878, ipnet:176.74.224.0/19, country:NL]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 00:39:25 -0000 On 14-7-2020 00:47, Yuri Pankov wrote: > Willem Jan Withagen wrote: >> Hi, >> >> I have this Supermicro SUPERSERVER®2028TP >> Which hold four nodes each with a X10DRT-PT motherboard >> and a LSI-3108 SAS controller connecting to 6 disks. >> >> Trying to run the most recent current snapshot on it. >> # uname -a >> FreeBSD quadbox-d.digiware.nl 13.0-CURRENT FreeBSD 13.0-CURRENT #0 >> r363032: Thu Jul  9 04:13:17 UTC 2020 >> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> I have installed the OS on a SATA flash DOM. >> Booting works fine as long as there are no disks connected to >> LSI-3108 controller. >> Booting with SAS disks connected results in a panic. >> Attaching a SAS disk to the LSI-3108 controller give a panic as well. >> >> >> >> AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd >> mfi0: port 0x6000-0x60ff mem >> 0xc7300000-0xc730ffff,0xc7200000-0xc72fffff irq 26 at device >> 0.0 numa-domain 0 on pci3 >> mfi0: Using MSI >> mfi0: Megaraid SAS driver Ver 4.23 >> mfi0: FW MaxCmds = 928, limiting to 128 >> mfi0: MaxCmd = 928, Drv MaxCmd = 128, MaxSgl = 70, state = 0xb73c03a0 >> ..... >> mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started >> (PCI ID 005d/1000/0809/15d9) >> pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - >> Firmware version 4.290.00-4536 >> >> >> I have posted screenshots of the panic at: >>      www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 >> >> But basically it crashes in >>      mfi_tbolt_send_frame() +0x132 >> >> So is there anybody out there that can help me with analyzing and >> fixing this panic? > > I guess it's not the answer you are looking for, but you could try the > mrsas driver and check if it's behaves better for you, by setting 'set > hw.mfi.mrsas_enable=1' from loader prompt. That was a great suggestion. And what I read from the manual page, mrsas plays even nicer with CAM which is a plus. I guess that there are reason not to do this by default. So one gets mrsas unless it does not attach to that specific card in the system? --WjW From owner-freebsd-current@freebsd.org Tue Jul 14 04:59:57 2020 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 0E87B354FF5; Tue, 14 Jul 2020 04:59:57 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5SxR2KtZz4Km6; Tue, 14 Jul 2020 04:59:55 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 06E4xmGs062844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2020 05:59:48 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 06E4xm79062842; Tue, 14 Jul 2020 05:59:48 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202007140459.06E4xm79062842@donotpassgo.dyslexicfish.net> Date: Tue, 14 Jul 2020 05:59:48 +0100 Organization: Dyslexic Fish To: mmacy@freebsd.org, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: CFT for vendor openzfs - week 2 reminder References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Tue, 14 Jul 2020 05:59:48 +0100 (BST) X-Rspamd-Queue-Id: 4B5SxR2KtZz4Km6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.983]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.243]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 04:59:57 -0000 Can anyone using the new vendor openzfs let us know if it fixes the "mmp_thread_enter" bug recently MFC'ed to STABLE? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247829 Cheers From owner-freebsd-current@freebsd.org Tue Jul 14 05:45:25 2020 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 D6F053567FA for ; Tue, 14 Jul 2020 05:45:25 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.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 4B5Txw5QmMz4Tbb for ; Tue, 14 Jul 2020 05:45:24 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f180.google.com with SMTP id e8so21001860ljb.0 for ; Mon, 13 Jul 2020 22:45:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lzg4rQoPST1BaCmuZekJVe0LVwZ6ts9dvNYPLfZv6Xo=; b=KBki2GJTJQHIOVI7ty4uYEmVROa06bAdRPoxrWGhUujtWa1wh6xI/oO1gV6YCQ5QAU a8d1PueLv3SmhaZxmnm/1F9qq8Rj91Xy/x05x48XMwLrkH0iIcB3gzcAFmdmcqQsffRU Qrv2Awwct3oYJnR1FMEbHYkuZWDxKfxjPgAoJcGpiQRQljEVP7oXCBMUWmOsjBLsLVVE H3xCGXuQmapZ9cBwY9IOQKoGRpEnqkKA6sIl6qJssSN4rdU8xoFrWRQ5f4tSv3ooIbhB NSMM5ia1Y7nOZLWP+Y1kLSA78ChV6zwWDAFAzIq8C1879Q40/OgMF9EAzUPLkkBajxAd a4EA== X-Gm-Message-State: AOAM531mLDuB4LzIZJjG4hrJbm62xBen3jJOji4FOOl4n7BKSJ+k4O6/ VMtjpIhF/lC5rABOiEbrFu52EBH1k2k= X-Google-Smtp-Source: ABdhPJxN8HVRpOpgnI+1z2nrtz3Ot0m44yHcH8xdt57l2HVvpuldUS048d7lr1PzkrwUCtIVHZtbMg== X-Received: by 2002:a2e:9c3:: with SMTP id 186mr1480968ljj.293.1594705522496; Mon, 13 Jul 2020 22:45:22 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id p14sm5045112lfh.32.2020.07.13.22.45.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 22:45:21 -0700 (PDT) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Willem Jan Withagen , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Tue, 14 Jul 2020 08:45:20 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B5Txw5QmMz4Tbb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.88)[-0.876]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.10)[-0.100]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.180:from]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.180: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)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[93.72.151.96:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 05:45:25 -0000 On 14/07/2020 03:39, Willem Jan Withagen wrote: > And what I read from the manual page, mrsas plays even nicer with CAM which is a > plus. If by "nicer" you mean that mfi does not integrate with CAM at all, then you are right :-) Also, last I looked mfi has some pretty serious bugs in its direct interface to GEOM. We've seen all kinds of crashes with mfi at work. Whatever the reason why mrsas is not always preferred over mfi, it must pretty nebulous like POLA for existing users. From technical point of view, mrsas appears to be superior. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Jul 14 06:20:47 2020 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 1C83935796F for ; Tue, 14 Jul 2020 06:20:47 +0000 (UTC) (envelope-from adrian.chadd@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 4B5Vkk6Jcgz4bHf for ; Tue, 14 Jul 2020 06:20:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id D85AC35757B; Tue, 14 Jul 2020 06:20:46 +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 D7F5135796E; Tue, 14 Jul 2020 06:20:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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 4B5Vkj6Vh7z4bNN; Tue, 14 Jul 2020 06:20:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qk1-f174.google.com with SMTP id k18so14616047qke.4; Mon, 13 Jul 2020 23:20:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LH9kK4F8k74vIEGczlX1Sp/15vlM79tZ9OCipNcrO98=; b=lWKfdM+XsgrBWA/RPAnljQ//3hMlxBt0AQABFVOxpH6WWho1NiL5fGMHZh9mnbWrEN /qBhXorXhHWAZ6c6p0G/x2F1F6k6cPeQsCmqI0mm0+3EqVXu845uvySFSCoYlekV13Ug rtIR1fe1Ij58i42Dck+IMuUqZjtAREIDYz2PjIs8bmS1LUAws7H/36oaD6b3F1oV5J0i QDecov/FDySWOHY8XWCszTYc9UL4pjidGdT6rUsMNhW+xu9+j3aUYusofVkn8hHHPiLb yqMiwfMECKTbeBHNXSKKSTxeQyShI305ZAssFoYkUuiJYfckbxqCcYEiwFM3OaLWG5UI xYnA== X-Gm-Message-State: AOAM53209eJOpYhEmIWf6KsFc4WdmpQ3oDovxssktlV2DG9fszXrxpud 7OzJzeB085j12Ekg8hHpt2PsKDnL36xKc9bTI983WA== X-Google-Smtp-Source: ABdhPJz7yqEJlPL+Ixhdc2FaJ0j5txwHcmphicqKi3ESSXwXjUB8xjEkxk0CpMYeVW4o3LW4urdyAJYaxc/h53qF6FM= X-Received: by 2002:a37:aa03:: with SMTP id t3mr3157523qke.152.1594707644618; Mon, 13 Jul 2020 23:20:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Chadd Date: Mon, 13 Jul 2020 23:20:32 -0700 Message-ID: Subject: Re: driver for cp2112 (USB GPIO and I2C gadget) To: Andriy Gapon Cc: usb@freebsd.org, FreeBSD Hackers , FreeBSD Current X-Rspamd-Queue-Id: 4B5Vkj6Vh7z4bNN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-1.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.84)[-0.845]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.25)[0.254]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.174:from]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.174: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:+,1:+,2:~]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 06:20:47 -0000 hi! On Wed, 8 Jul 2020 at 02:39, Andriy Gapon wrote: > On 19/06/2020 17:14, Andriy Gapon wrote: > > > > If anyone interested in reviewing a new driver please help yourself to: > > https://reviews.freebsd.org/D25359 > > https://reviews.freebsd.org/D25360 > > What might be curious about it is that there are usb, i2c and gpio mixed > together. > Any interest at all? > I am still torn about which of the approaches to take. > I prefer the non monolithic one. i left comments on that one. :-) -adrian > -- > Andriy Gapon > _______________________________________________ > 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 Jul 14 09:14:40 2020 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 580C835B754 for ; Tue, 14 Jul 2020 09:14:40 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 4B5ZbM6vk4z41Dy; Tue, 14 Jul 2020 09:14:39 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E6F71A522; Tue, 14 Jul 2020 11:14:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiJ37LFh7whK; Tue, 14 Jul 2020 11:14:35 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (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 smtp.digiware.nl (Postfix) with ESMTPSA id 36466A51F; Tue, 14 Jul 2020 11:14:35 +0200 (CEST) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Andriy Gapon , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> From: Willem Jan Withagen Message-ID: <22f905c8-40fc-793f-fc84-6bf2a8d3111a@digiware.nl> Date: Tue, 14 Jul 2020 11:14:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl X-Rspamd-Queue-Id: 4B5ZbM6vk4z41Dy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 09:14:40 -0000 On 14-7-2020 07:45, Andriy Gapon wrote: > On 14/07/2020 03:39, Willem Jan Withagen wrote: >> And what I read from the manual page, mrsas plays even nicer with CAM which is a >> plus. > If by "nicer" you mean that mfi does not integrate with CAM at all, then you are > right :-) > Also, last I looked mfi has some pretty serious bugs in its direct interface to > GEOM. We've seen all kinds of crashes with mfi at work. Right that was what I meant. Disadvantage is that mfiutil no longer works. But then if you JBOD, it does not really matter. Unless it still uses caching for JBODs and then I'd like to know the state of the battery. > Whatever the reason why mrsas is not always preferred over mfi, it must pretty > nebulous like POLA for existing users. From technical point of view, mrsas > appears to be superior Right, the Pola argument... Least it would warrant for is a warning in the mfi/mfiutil manpage that mrsas is a lot more modern and that it should be prefered is user has no specific reason to select mfi. And perhaps it is too complicated in the build of the boot images for isos and sticks, but there it would help a lot. Now booting with this controller and disk in the system leads to a panic. And a heavy one which requires hard reset/power-cycle, since the console is dead. --WjW From owner-freebsd-current@freebsd.org Tue Jul 14 09:18:35 2020 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 2C98D35C009 for ; Tue, 14 Jul 2020 09:18:35 +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 4B5Zgt2GjMz449P for ; Tue, 14 Jul 2020 09:18:34 +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 7D7BA260191; Tue, 14 Jul 2020 11:18:26 +0200 (CEST) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Willem Jan Withagen , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> From: Hans Petter Selasky Message-ID: <0d712d95-e6eb-fdbc-4548-97ae99c92fdd@selasky.org> Date: Tue, 14 Jul 2020 11:18:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B5Zgt2GjMz449P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-0.95)[-0.947]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-0.90)[-0.896]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.15)[-0.153]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 09:18:35 -0000 On 2020-07-14 02:39, Willem Jan Withagen wrote: > I guess that there are reason not to do this by default. I've seen the exact same panic. +1 for fixing it :-) --HPS From owner-freebsd-current@freebsd.org Tue Jul 14 09:42:43 2020 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 A4F4B35C8C7 for ; Tue, 14 Jul 2020 09:42:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 4B5bCk5ncbz4VMK for ; Tue, 14 Jul 2020 09:42:42 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id BE14B1036F; Tue, 14 Jul 2020 11:42:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by0Qim5KIGgL; Tue, 14 Jul 2020 11:42:39 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (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 smtp.digiware.nl (Postfix) with ESMTPSA id 23B2A1036E; Tue, 14 Jul 2020 11:42:39 +0200 (CEST) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Hans Petter Selasky , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> <0d712d95-e6eb-fdbc-4548-97ae99c92fdd@selasky.org> From: Willem Jan Withagen Message-ID: Date: Tue, 14 Jul 2020 11:42:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0d712d95-e6eb-fdbc-4548-97ae99c92fdd@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl X-Rspamd-Queue-Id: 4B5bCk5ncbz4VMK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 2001:4cb8:90:ffff::3 as permitted sender) smtp.mailfrom=wjw@digiware.nl X-Spamd-Result: default: False [-3.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.96)[-0.965]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[digiware.nl]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.01)[-1.013]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 09:42:43 -0000 On 14-7-2020 11:18, Hans Petter Selasky wrote: > On 2020-07-14 02:39, Willem Jan Withagen wrote: >> I guess that there are reason not to do this by default. > > I've seen the exact same panic. > > +1 for fixing it :-) I do not have the knowledge to fix this panic. So the only thing I/we can do is: Get extra information in the mfi manpages. And perhaps get the preference reverted for mrsas <> mfi but I would not know where to start that discussion? --WjW From owner-freebsd-current@freebsd.org Tue Jul 14 19:12:51 2020 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 41EE036C6AE for ; Tue, 14 Jul 2020 19:12:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5qsY1ThRz3RWM; Tue, 14 Jul 2020 19:12:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.12] (cpc91220-cmbg18-2-0-cust60.5-4.cable.virginm.net [81.104.142.61]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 101A64E6E3; Tue, 14 Jul 2020 19:12:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1594753962; bh=e72AOu00NdsjDaro9oqvvYQ8NDsDSmKzShMoREfJWnw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=URqdfDOzhRBysXbFNnV8eHtiqPMZDG1O7lNZwk4v+HK1C0nadvLynrrBwTq99UF7t xEysBIKQmZ300DDwaDnyLhJ1eUiXsGCuATjj4j4Un1LIzawMSQW0SjcDsqpvzmT3nm dGgk6wXRdbyJ7v9oLFXtKhyPrvlAkCpBiU++vWJgaj8cOVvRdhArRlmO9QjrS67hHP ucvsq7SMMiw+Xe3g0yxIV0praipjWKoCYHELgbdC+714p1ry1z0c7QWDPm1NCv9yE2 tnCCeFNL71hrYUfAGDNu+jD91a1egKEU0zDJwzxaqUsxC+VEXoGOdNLA5MEYgfrrpC ZLVBFsYZ7qVFnZ6zfweXvvnTgFz4JxcfdtGEQ80QChf52y7cnp2kiRNFFLusu+c3zf bNrGXLZZmBXV7ema++FlmQVK1S3D9FTvHI4IfbCGS2xu8s1UjUzLCDtCG7eqYxf+BR rcnOMvtboRSYRD5wUOTrikDzcKO+reXeteo8HURH0lSFYULTzgUN2cE976Sljm0rnn C4ofXaL1xeXmktgchT4HOQdgnPFq2yg6d6NKf5ICGPyYsT39RxsbLKhY5+ND03cCqk XdcvziGtAuBzQT+7FW/RcbCpBb6ThfTa+lDXFbFosgI+oPN1RzgK3wCYfGWeMgBB6s ei95BiHIMZGxg3hlTCt1DgBQ= From: Andrew Turner Message-Id: Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: arm64 panic: reaper-related? Date: Tue, 14 Jul 2020 20:12:41 +0100 In-Reply-To: <20200713140538.GA46078@FreeBSD.org> Cc: freebsd-current@freebsd.org To: Glen Barber References: <20200713135821.GS61041@FreeBSD.org> <20200713140538.GA46078@FreeBSD.org> X-Mailer: Apple Mail (2.3445.104.14) X-Rspamd-Queue-Id: 4B5qsY1ThRz3RWM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=URqdfDOz; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.95)[-0.951]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; NEURAL_HAM_SHORT(-0.46)[-0.462]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[81.104.142.61:received] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 19:12:51 -0000 > On 13 Jul 2020, at 15:05, Glen Barber wrote: >=20 > On Mon, Jul 13, 2020 at 01:58:21PM +0000, Glen Barber wrote: >> Hi, >>=20 >> This morning, one of our arm64 build machines panicked. It looks = like >> it is somehow reaper-related, but I am not entirely sure. Backtrace >> follows. Any thoughts? I'm not quite sure where to go from here... >> Thanks in advance for any input. >>=20 >> db> set $lines 0 >> db> bt >> Tracing pid 11 tid 100003 td 0xfffffd0001634000 >> db_trace_self() at db_stack_trace+0xf8 >> pc =3D 0xffff00000075fdac lr =3D 0xffff000000103e78 >> sp =3D 0xffff00011eca89b0 fp =3D 0xffff00011eca89e0 >>=20 >> db_stack_trace() at db_command+0x228 >> pc =3D 0xffff000000103e78 lr =3D 0xffff000000103af0 >> sp =3D 0xffff00011eca89f0 fp =3D 0xffff00011eca8ad0 >>=20 >> db_command() at db_command_loop+0x58 >> pc =3D 0xffff000000103af0 lr =3D 0xffff000000103898 >> sp =3D 0xffff00011eca8ae0 fp =3D 0xffff00011eca8b00 >>=20 >> db_command_loop() at db_trap+0xf4 >> pc =3D 0xffff000000103898 lr =3D 0xffff000000106c0c >> sp =3D 0xffff00011eca8b10 fp =3D 0xffff00011eca8d30 >>=20 >> db_trap() at kdb pc =3D 0xffff000000106c0c lr =3D = 0xffff000000463b0c >> sp =3D 0xffff00011eca8d40 fp =3D 0xffff00011eca8df0 >>=20 >> kdb_trap() at do_el1h_sync+0xf4 >> pc =3D 0xffff000000463b0c lr =3D 0xffff00000077b448 >> sp =3D 0xffff00011eca8e00 fp =3D 0xffff00011eca8e30 >>=20 >> do_el1h_sync() at handle_el1h_sync+0x78 >> pc =3D 0xffff00000077b448 lr =3D 0xffff000000762878 >> sp =3D 0xffff00011eca8e40 fp =3D 0xffff00011eca8f50 >>=20 >> handle_el1h_sync() at kdb_enter+0x34 >> pc =3D 0xffff000000762878 lr =3D 0xffff000000463168 >> sp =3D 0xffff00011eca8f60 fp =3D 0xffff00011eca8ff0 >>=20 >> kdb_enter() at vpanic+0x1b0 >> pc =3D 0xffff000000463168 lr =3D 0xffff000000417a74 >> sp =3D 0xffff00011eca9000 fp =3D 0xffff00011eca90b0 >>=20 >> vpanic() at panic+0x44 >> pc =3D 0xffff000000417a74 lr =3D 0xffff0000004178c0 >> sp =3D 0xffff00011eca90c0 fp =3D 0xffff00011eca9140 >>=20 >> panic() at __stack_chk_fail+0x10 >> pc =3D 0xffff0000004178c0 lr =3D 0xffff00000044ab6c >> sp =3D 0xffff00011eca9150 fp =3D 0xffff00011eca9150 >>=20 >> __stack_chk_fail() at putchar+0x2bc >> pc =3D 0xffff00000044ab6c lr =3D 0xffff000000469ce8 >> sp =3D 0xffff00011eca9160 fp =3D 0xffff00011eca91e0 >>=20 >> putchar() at 0x106 >> pc =3D 0xffff000000469ce8 lr =3D 0x0000000000000106 >> sp =3D 0xffff00011eca91f0 fp =3D 0x0000000000000000 >>=20 >> db> show proc 11 >> Process 11 (idle) at 0xfffffd0001630000: >> state: NORMAL >> uid: 0 gids: 0 >> parent: pid 0 at 0xffff0000010fae40 >> ABI: null >> reaper: 0xffff0000010fae40 reapsubtree: 11 >> sigparent: 20 >> vmspace: 0xffff000001109200 >> (map 0xffff000001109200) >> (map.pmap 0xffff0000011092c0) >> (pmap 0xffff000001109320) >> threads: 48 >> 100003 Run CPU -1 [idle: = cpu0] >> 100004 Run CPU 1 [idle: = cpu1] >> 100005 Run CPU 2 [idle: = cpu2] >> 100006 Run CPU 3 [idle: = cpu3] >> 100007 Run CPU 4 [idle: = cpu4] >> 100008 Run CPU 5 [idle: = cpu5] >> 100009 Run CPU 6 [idle: = cpu6] >> 100010 Run CPU 7 [idle: = cpu7] >> 100011 Run CPU 8 [idle: = cpu8] >> 100012 CanRun [idle: = cpu9] >> 100013 Run CPU 10 [idle: = cpu10] >> 100014 Run CPU 11 [idle: = cpu11] >> 100015 Run CPU 12 [idle: = cpu12] >> 100016 Run CPU 13 [idle: = cpu13] >> 100017 Run CPU 14 [idle: = cpu14] >> 100018 Run CPU 15 [idle: = cpu15] >> 100019 Run CPU 16 [idle: = cpu16] >> 100020 Run CPU 17 [idle: = cpu17] >> 100021 Run CPU 18 [idle: = cpu18] >> 100022 Run CPU 19 [idle: = cpu19] >> 100023 Run CPU 20 [idle: = cpu20] >> 100024 Run CPU 21 [idle: = cpu21] >> 100025 Run CPU 22 [idle: = cpu22] >> 100026 Run CPU 23 [idle: = cpu23] >> 100027 Run CPU 24 [idle: = cpu24] >> 100028 Run CPU 25 [idle: = cpu25] >> 100029 Run CPU 26 [idle: = cpu26] >> 100030 CanRun [idle: = cpu27] >> 100031 Run CPU 28 [idle: = cpu28] >> 100032 Run CPU 29 [idle: = cpu29] >> 100033 Run CPU 30 [idle: = cpu30] >> 100034 Run CPU 31 [idle: = cpu31] >> 100035 Run CPU 32 [idle: = cpu32] >> 100036 Run CPU 33 [idle: = cpu33] >> 100037 Run CPU 34 [idle: = cpu34] >> 100038 Run CPU 35 [idle: = cpu35] >> 100039 Run CPU 36 [idle: = cpu36] >> 100040 Run CPU 37 [idle: = cpu37] >> 100041 Run CPU 38 [idle: = cpu38] >> 100042 Run CPU 39 [idle: = cpu39] >> 100043 Run CPU 40 [idle: = cpu40] >> 100044 Run CPU 41 [idle: = cpu41] >> 100045 Run CPU 42 [idle: = cpu42] >> 100046 Run CPU 43 [idle: = cpu43] >> 100047 Run CPU 44 [idle: = cpu44] >> 100048 Run CPU 45 [idle: = cpu45] >> 100049 Run CPU 46 [idle: = cpu46] >> 100050 Run CPU 47 [idle: = cpu47] >>=20 >>=20 >=20 > I should have included this as well... >=20 > db> show panic > panic: Misaligned access from kernel space! How reproducible is this? The backtrace and panic messages don=E2=80=99t = line up, but that may be related __stack_chk_fail being in the trace. = This is called when a stack overflow is detected. I added more diagnostics to the kernel in r363191. Is it possible to try = upgrading the kernel to that? Andrew From owner-freebsd-current@freebsd.org Tue Jul 14 19:22:33 2020 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 DC19D36CCF6 for ; Tue, 14 Jul 2020 19:22:33 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5r4n2H6lz3gLG; Tue, 14 Jul 2020 19:22:33 +0000 (UTC) (envelope-from gjb@freebsd.org) 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 D7C68EE95; Tue, 14 Jul 2020 19:22:32 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Tue, 14 Jul 2020 19:22:30 +0000 From: Glen Barber To: Andrew Turner Cc: freebsd-current@freebsd.org Subject: Re: arm64 panic: reaper-related? Message-ID: <20200714192230.GX61041@FreeBSD.org> References: <20200713135821.GS61041@FreeBSD.org> <20200713140538.GA46078@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5mu1Tvth33Vj8K2q" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 19:22:34 -0000 --5mu1Tvth33Vj8K2q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2020 at 08:12:41PM +0100, Andrew Turner wrote: > How reproducible is this? The backtrace and panic messages don=E2=80=99t > line up, but that may be related __stack_chk_fail being in the > trace. This is called when a stack overflow is detected. >=20 I do not yet know how reproducible it is, as this is the first time I have observed this particular panic. > I added more diagnostics to the kernel in r363191. Is it possible > to try upgrading the kernel to that? >=20 Yes, I should be able to upgrade the system at some point this week. Thank you for taking a look. Glen --5mu1Tvth33Vj8K2q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl8OBfEACgkQAxRYpUeP 4pPRpw//T6QzAhD6cvgKbUwWZaioQibjNqOO/0SG8cacDKPztDpBtPBAFBIUuxrJ t6yu3mzVl8+q0x+wsveZkZKIXiUKp7wbhfv0YPL8umgLXiUfWvMJY7y21fk9kHfr 930K1Eo1e84QcCs0CPeSawDVUfbX0NJBfGOAqIxuOo78JmWT17XZ501WbLNfwPuO Ibp2KKtEAsuBMFMGEYLzeLYk1pfggnuyYjy58q/yCV5CiFdKezFYvtpTRyK7PX/x G8P+n9ZCbA6bO/sYdTM93SiQakS7W5G0kw1vGGyY4cDP5/eKOyQcCiO9rULamUW3 01FTB67CvP1vgof9QIvIc5+IMOBr6sTPV/ZK6c9TlsHNM5PkPJ24Xou5m1Od2psQ f/cS2wLcTjRwQOaMMr5Q9JXh3TpH9QhYdOSGCVQq7M6kwZC8YvC2RZIbhhGCUQYJ sBMRoOhmf4ZVZV1SW+uuGGS6TqwbOwclUMohP4j1Z46eDSQS/kW+MeOYVbgBO45E HwLbdDSaTiKH95/Us4y/P5UfbN5ldQe9eV1xUlVrmM7/jCnUENl8RO5Vx8yWAt4K BgaZhQ86y8rlS7RE9EEVuEQBBAcME8/BzdUL/iVgaSCGx2P+7m2MF43flWToKCid Pw30RjnL6al9SDC9PrwZGIcSBmiAZ2ob3lOmMEvLQ3ViMv2jaoE= =LRo9 -----END PGP SIGNATURE----- --5mu1Tvth33Vj8K2q-- From owner-freebsd-current@freebsd.org Tue Jul 14 20:59:28 2020 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 EEBA236EF76 for ; Tue, 14 Jul 2020 20:59:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [IPv6:2607:f3e0:0:3::19]) (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 "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5tDb2bchz4bM8; Tue, 14 Jul 2020 20:59:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:2521:2f6a:8b45:aacf] ([IPv6:2607:f3e0:0:4:2521:2f6a:8b45:aacf]) by pyroxene2a.sentex.ca (8.15.2/8.15.2) with ESMTPS id 06EKxEJg082402 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 14 Jul 2020 16:59:20 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Willem Jan Withagen , Andriy Gapon , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> <22f905c8-40fc-793f-fc84-6bf2a8d3111a@digiware.nl> From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= mQENBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAG0HW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+iQFUBBMBCAA+FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAlywzOYCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ eVOEFl5WrMhnPAf7Bf+ola0V9t4i8rwCMGvzkssGaxY/5zNSZO9BgSgfN0WzgmBEOy/3R4km Yn5KH94NltJYAAE5hqkFmAwK6psOqAR9cxHrRfU+gV2KO8pCDc6K/htkQcd/mclJYpCHp6Eq EVJOiAxcNaYuHZkeMdXDuvvI5Rk82VHk84BGgxIqIrhLlkguoPbXOOa+8c/Mpb1sRAGZEOuX EzKNC49+GS9gKW6ISbanyPsGEcFyP7GKMzcHBPf3cPrewZQZ6gBoNscasL6IJeAQDqzQAxbU GjO0qBSMRgnLXK7+DJlxrYdHGXqNbV6AYsmHJ6c2WWWiuRviFBqXinlgJ2FnYebZPAfWiQ== Message-ID: Date: Tue, 14 Jul 2020 16:59:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <22f905c8-40fc-793f-fc84-6bf2a8d3111a@digiware.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4B5tDb2bchz4bM8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::19 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-1.44 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; NEURAL_HAM_LONG(-0.92)[-0.918]; MIME_GOOD(-0.10)[text/plain]; HFILTER_HELO_IP_A(1.00)[pyroxene2a.sentex.ca]; HFILTER_HELO_NORES_A_OR_MX(0.30)[pyroxene2a.sentex.ca]; DMARC_NA(0.00)[sentex.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.52)[-0.524]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 20:59:29 -0000 On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: > On 14-7-2020 07:45, Andriy Gapon wrote: >> On 14/07/2020 03:39, Willem Jan Withagen wrote: >>> And what I read from the manual page, mrsas plays even nicer with >>> CAM which is a >>> plus. >> If by "nicer" you mean that mfi does not integrate with CAM at all, >> then you are >> right :-) >> Also, last I looked mfi has some pretty serious bugs in its direct >> interface to >> GEOM.  We've seen all kinds of crashes with mfi at work. > Right that was what I meant. > Disadvantage is that mfiutil no longer works. > But then if you JBOD, it does not really matter. > Unless it still uses caching for JBODs and then I'd like to know the > state of the > battery. > Take a look from the ports storcli or MegaCli You can do pretty well everything you need with those 2 tools to talk to mrsas attached disks eg MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 or storcli /c0 show all storcli /c0 show help storcli /c0 set jbod=on (enable jbod mode for drives) storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) From owner-freebsd-current@freebsd.org Tue Jul 14 21:56:01 2020 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 56E4A350CCF for ; Tue, 14 Jul 2020 21:56:01 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5vTr2xNJz3c0W; Tue, 14 Jul 2020 21:55:59 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from lrrr.mouf.net (cpe-76-182-16-135.nc.res.rr.com [76.182.16.135]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id 06ELtf6k025507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Jul 2020 21:55:46 GMT (envelope-from swills@FreeBSD.org) Subject: Re: svn commit: r352558 - head/usr.bin/top To: Yuri Pankov , Mark Millard Cc: "daichi@freebsd.org" , FreeBSD Current , Hiroki Sato References: <1BDFB387-930D-4F4D-8729-A5850F1C15B9.ref@yahoo.com> <1BDFB387-930D-4F4D-8729-A5850F1C15B9@yahoo.com> <61107ecc-6f9b-a4db-7b1e-ec75f73939ee@FreeBSD.org> From: Steve Wills Message-ID: <2fef261e-7d73-5904-ca1e-fb29445d9015@FreeBSD.org> Date: Tue, 14 Jul 2020 17:55:36 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Tue, 14 Jul 2020 21:55:47 +0000 (UTC) X-Spam-Status: No, score=0.3 required=4.5 tests=KHOP_HELO_FCRDNS, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4B5vTr2xNJz3c0W 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:36236, ipnet:2607:fc50::/36, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 21:56:01 -0000 Hi, On 7/10/20 7:12 PM, Yuri Pankov wrote: > > Thanks. > > The attached diff seems to take care of the issue for me, adding VIS_TAB > and removing VIS_SAFE, which can be blamed for passing through the > following: > > VIS_SAFE   Currently this form allows space, tab, newline, backspace, >            bell, and return — in addition to all graphic characters — >            unencoded. That does seem to fix it for me. Please commit. :) Thanks, Steve From owner-freebsd-current@freebsd.org Tue Jul 14 22:45:52 2020 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 06BE5351CDB for ; Tue, 14 Jul 2020 22:45:52 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (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 4B5wbL1Ndsz43ll; Tue, 14 Jul 2020 22:45:49 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D04B258012B; Tue, 14 Jul 2020 18:45:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 14 Jul 2020 18:45:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=1 uglvgECDD4EJPYX1hMI3IzwVjB/MY2P319H2I4jUW8=; b=LHsYdFrud7jZfcmwj KxTw3g5bKe2Zun8GuN7PotddrmuFTfA8b3cn77PjJtXTv7jcvo561UEylDeyziJ0 daVM4wRlGHjkGjVPHQ0t2iLcazeQHU2Nq/NRpKpUulMgGqdQDnbzzx8WFo55bryw bPFY4mnYAFMd7YtODfQV5+i4yeMAiUKGG2SFlIbC9Dz77K/BHEVcxX8P16j9lB/u b0Kk1Bcxq9DF4wHRo9ZYKD4eZMniCgzdbCWOLDvdNpgsiFr4Y0O4m/vQBAg83v7d ba0oy+DhabmrNRKBbi8RPyhGAAiHnLhki8pYaBSEiNAF5RLya3nFt1PoTnRf9+C5 3a6YA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=1uglvgECDD4EJPYX1hMI3IzwVjB/MY2P319H2I4jU W8=; b=ZodYaR6EAjZUK1xiYRzzrLlAuH/FMmAlwvEcOW78+Uia4Rt0yQa7uOGGG vWjLBvjOAHUy2O2ALmTnXOKUA8jkPv8KBzfGgyNqw/yTAPfdr/EUjohhlf3JPWJ1 +hpe6p4LcWAEbGwiXcYAUG0l6sM0G6ZTotaLjMuvwUgIgG3lgJizOsjMRXr40GzU Qe3cSr/rA/LNaoKQyfnLySbtLRTnnTNV3ayMvOVBownJwEkkKrSSKkpvFSkylZV1 YBn7aLuRFQpFgS25aot8V9sbrEZmL6xGXRI7a/+G3ERASYJQzb47RO5gJano1m25 e4vvdWF346yo7Pay0EWsDklG6NpEA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepudeuffegtdehffdtffefkefhgfelieeitefghfeugeelfeduffegtdeufeekgfdv necukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 653BB30600A6; Tue, 14 Jul 2020 18:45:47 -0400 (EDT) Subject: Re: svn commit: r352558 - head/usr.bin/top To: Steve Wills , Mark Millard Cc: "daichi@freebsd.org" , FreeBSD Current , Hiroki Sato References: <1BDFB387-930D-4F4D-8729-A5850F1C15B9.ref@yahoo.com> <1BDFB387-930D-4F4D-8729-A5850F1C15B9@yahoo.com> <61107ecc-6f9b-a4db-7b1e-ec75f73939ee@FreeBSD.org> <2fef261e-7d73-5904-ca1e-fb29445d9015@FreeBSD.org> From: Yuri Pankov Message-ID: Date: Wed, 15 Jul 2020 01:45:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2fef261e-7d73-5904-ca1e-fb29445d9015@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4B5wbL1Ndsz43ll X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=LHsYdFru; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ZodYaR6E; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 66.111.4.229 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.229]; NEURAL_HAM_LONG(-0.98)[-0.984]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[yuripv.dev]; NEURAL_HAM_MEDIUM(-1.03)[-1.034]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.88)[-0.880]; FREEMAIL_TO(0.00)[FreeBSD.org,yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[66.111.4.229:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.229:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 14 Jul 2020 22:45:52 -0000 Steve Wills wrote: > Hi, > > On 7/10/20 7:12 PM, Yuri Pankov wrote: > >> >> Thanks. >> >> The attached diff seems to take care of the issue for me, adding >> VIS_TAB and removing VIS_SAFE, which can be blamed for passing through >> the following: >> >> VIS_SAFE   Currently this form allows space, tab, newline, backspace, >>             bell, and return — in addition to all graphic characters — >>             unencoded. > > That does seem to fix it for me. Please commit. :) Done, please report if it's still not completely fixed. From owner-freebsd-current@freebsd.org Wed Jul 15 09:56:49 2020 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 9D74436092C for ; Wed, 15 Jul 2020 09:56:49 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 4B6CTX38vTz3Zfj; Wed, 15 Jul 2020 09:56:48 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id C08B929DBC; Wed, 15 Jul 2020 11:56:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUZ5CBLVw42m; Wed, 15 Jul 2020 11:56:45 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (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 smtp.digiware.nl (Postfix) with ESMTPSA id 3CBF629DB7; Wed, 15 Jul 2020 11:56:45 +0200 (CEST) Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: mike tancsa , Andriy Gapon , Yuri Pankov , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> <22f905c8-40fc-793f-fc84-6bf2a8d3111a@digiware.nl> From: Willem Jan Withagen Message-ID: Date: Wed, 15 Jul 2020 11:56:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl X-Rspamd-Queue-Id: 4B6CTX38vTz3Zfj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 2001:4cb8:90:ffff::3 as permitted sender) smtp.mailfrom=wjw@digiware.nl X-Spamd-Result: default: False [-2.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.046]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ptr]; NEURAL_HAM_LONG(-0.96)[-0.963]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[digiware.nl]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.26)[-0.262]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 09:56:49 -0000 On 14-7-2020 22:59, mike tancsa wrote: > On 7/14/2020 5:14 AM, Willem Jan Withagen wrote: >> On 14-7-2020 07:45, Andriy Gapon wrote: >>> On 14/07/2020 03:39, Willem Jan Withagen wrote: >>>> And what I read from the manual page, mrsas plays even nicer with >>>> CAM which is a >>>> plus. >>> If by "nicer" you mean that mfi does not integrate with CAM at all, >>> then you are >>> right :-) >>> Also, last I looked mfi has some pretty serious bugs in its direct >>> interface to >>> GEOM.  We've seen all kinds of crashes with mfi at work. >> Right that was what I meant. >> Disadvantage is that mfiutil no longer works. >> But then if you JBOD, it does not really matter. >> Unless it still uses caching for JBODs and then I'd like to know the >> state of the >> battery. >> > Take a look from the ports storcli or MegaCli > > You can do pretty well everything you need with those 2 tools to talk to > mrsas attached disks > > eg > > MegaCli -CfgEachDskRaid0 WT NORA Direct CachedBadBBU -Automatic -a0 > or > storcli /c0 show all > storcli /c0 show help > storcli /c0 set jbod=on (enable jbod mode for drives) > storcli /c0/e252/s0 set jbod (sets a disk into jbod mode) Great suggestion. Seems storcli is a followup on MegaCli. So I just got the last one. A bit of a pain, since PKG does not do it, but it also does not tell you why. But you need to manually fetch the tar from Broadcom first. But then it works like a charm, actual upgrading whilest the system is running of that controller: root@quad-a:/usr/ports/sysutils/storcli # storcli /c0 download file=/tmp/smc3108.rom Download Completed. Flashing image to adapter... CLI Version = 007.1211.0000.0000 Nov 07, 2019 Operating system = FreeBSD 13.0-CURRENT Controller = 0 Status = Success Description = F/W Flash Completed. Please reboot the system for the changes to take effect Current package version = 24.9.0-0022 New package version = 24.21.0-0100 Thanx, --WjW From owner-freebsd-current@freebsd.org Wed Jul 15 19:36:23 2020 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 15CB536DF1F for ; Wed, 15 Jul 2020 19:36:23 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6SLD6BRPz4tyT; Wed, 15 Jul 2020 19:36:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id DDA4613E42; Wed, 15 Jul 2020 19:36:18 +0000 (UTC) Date: Wed, 15 Jul 2020 19:36:17 +0000 From: Mark Linimon To: Willem Jan Withagen Cc: mike tancsa , Andriy Gapon , Yuri Pankov , freebsd current Subject: Re: Current panics on connecting disks to a LSI-3108 controller Message-ID: <20200715193617.GA15659@lonesome.com> References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> <80510d48-adfe-3f9c-a7cd-81a7e88d9d71@digiware.nl> <22f905c8-40fc-793f-fc84-6bf2a8d3111a@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 4B6SLD6BRPz4tyT X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [2.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.73)[0.727]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.42)[0.417]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.222.6.11:from]; NEURAL_SPAM_LONG(0.68)[0.683]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 19:36:23 -0000 On Wed, Jul 15, 2020 at 11:56:43AM +0200, Willem Jan Withagen wrote: > A bit of a pain, since pkg does not do it because ... > you need to manually fetch the tar from Broadcom first. Finally: > [pkg] also does not tell you why Just ask it: portsjail% cd sysutils/storcli portsjail% make -V IGNORE You must manually fetch the distribution file (007.1211.0000.0000_Unified_StorCLI.zip) from https://docs.broadcom.com/docs-and-downloads/raid-controllers/raid-controllers-common-files/007.1211.0000.0000_Unified_StorCLI.zip, place it in /home/linimon/ports/default/distfiles and then run make again portsjail% make -V LICENSE storcli portsjail% make -V LICENSE_TEXT Source recipient must acknowledge license. Reproduction or redistribution prohibited. See https://www.broadcom.com/cs/Satellite?pagename=AVG2/Utilities/EulaMsg mcl From owner-freebsd-current@freebsd.org Wed Jul 15 20:46:47 2020 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 4613536F670 for ; Wed, 15 Jul 2020 20:46:47 +0000 (UTC) (envelope-from lev@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6TvT6zvdz4DH0; Wed, 15 Jul 2020 20:46:45 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2E08F26959; Wed, 15 Jul 2020 20:46:45 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.230] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 1AAF3125E4; Wed, 15 Jul 2020 23:46:42 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Current panics on connecting disks to a LSI-3108 controller To: Yuri Pankov , Willem Jan Withagen , freebsd current References: <1406943a-6028-26ae-012f-e83903f2b299@digiware.nl> <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> From: Lev Serebryakov Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGwBBMBCABDAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEWIQT5bRygtfQxi2dLMwrqsDxYv9xHjwUCW/03kQUJDwW3xgAh CRDqsDxYv9xHjxYhBPltHKC19DGLZ0szCuqwPFi/3EePHxkP+wWNrAyks2fQctY/Gl7TMh+Y Q9uX0hAuZ2Vvi0LswBl/R85SsS7IvI9b3ogOWA8CAlHAxkvgH6sWrwRTNcCPS1MzulYxS914 0CSkdwwbv1JyDOOWYU6s8PfT9+BZr+9eNXStmEdEL5XcA1k2YncQtlR3m+oLkqlAOtteZWti pitMIX9BGYIVKyl0t0RnIx+m/QPVGU9gu02j0I3NSRnKQPyFxZqYK0nPBu+FKaEhIAqdKPOv GL4/ijansdiWO3mXy18G0Mkr8yYRSidpGgXGY6lmGzQ3R6ZS30bLI8DkskOOvfErwhZv5dH5 w4+JH5sQ7bIL5HEXs//ZU9UzMdQwcURMjcFfKGyfL0hSLRqzP8m7SL1k9ZL161OQ6C5zVO/M bSCmeeLkbfOj1NW1ZIv6UjVVWE/LS4+gqg/04C+Y24vj+7vMpBVEevdwmIEdmVciFudklcnN omuocb29GKbquRZRDGiE+mhqkwmp5e59AnePp3+AvkewSCsXlR1sfjEP/Tn5OsYerJ7eAAOj DjxO374TAqJG5ftW4BA/nVmx9FGKV1/A9Yc1UuH6LdQfLf7pmTck1Cxg4kdH+3qKGD63sAR0 Wh27XDjnBKXJUN7J+nctWMZJMvw4OhTXdTyVhWt6USKEzw8M5plY4sFqxBEAe8igQXlq1Xjd ISV7wYhT4l3FzsFNBFKbGksBEAC0a9wfjo2P3JyT7Lc+QlbFVshGbSbazb4ma7QYG5IZZD5v fLBFkePoG6cnrn3WCXp4A43hszAynCwe4eXyAkv4+gPF3ZSeNE5Wz3zYG+jh2nm2iGCkyaVy kfbA+2chor2DKH5tHpuNMBlF+wSJHZKJmlo/sFIktAnV1NBVg4/cL+9/hIpvl82cl3hYCD7/ e7/qRE+w38CpAAzn65FvbODn7xlY3fsJt+cHPBJ4EBM9KnTwcce+F+72RQMZQEl7vIAwSRmL dgZHN0MFC533l62SVoKjT0eaOOIBrvesmojhWjfwugibXr+WRF/tGcW77Bxwe2eQLbEVESqW eMORxRxocx7Q7aACoHmf4G4U1Vzx7zUEfNfHjfjZeQVfAURf/MoUelZSW/BmMIfKCg3lRlWA t+Pq2h2UADPVqAZze45beE/c8z8LZsOZiGoRhYL8NSg6+ziLTdmYLWdtFGAuZhqOtNp5h6tG j21OksBotcaIa5YjbCmmnImIjGlSBkUKvIhq/RXth5b2gNwaQdu+Yv4AlZVHRsuVywL/skDF L5+We11bDK6MQ5PzvmntRJcgbyoisn1hiV04OV1LpJJMkJn1j8VlBqDQNT/z+BjB0ru/0anv +5uLj7v0ck06rEo4yiXT/ZAcBM76j7V7FaGbkoba6bUUCQ2H5YYBOKpikjCnpwARAQABwsGT BBgBCAAmAhsMFiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlv9N7IFCQ8Ft+cAIQkQ6rA8WL/c R48WIQT5bRygtfQxi2dLMwrqsDxYv9xHj3CnD/9btCtkcphRYRUe08tUyVwzV/syDCdiUhF7 8jqDKTC+3zuyrFJi7t4fF9follHYz1Ri5RixxJHnuDFcq7ZTOprPYqO8QhckLAJOy5dmORDX 2guEA+y5zDYBwwjpio9dtnuE7QyHyMx4nMPq8O/HfO+6dDEZChkrGvcG9FTI7s0JhsDs3xxw jcROZ2OP0lNu2571ZpR4YuzMUOIhOaQBIF2wrTvLjKUsAnNQYK9gsFTeDHRsE4HZLxJvEdiZ CWN7COi9un4xtP4Khc3Fmn6ANEyh0bIgx1Eii2RGINuA2XRVYhPRJLUZRSVQcrND9k9S+m+T oaqz9JgFLusFA1KhdeYnE1bojpq1U1bsmEicLW2QfEGVumKTgUrTsno0cVPH73KDILFvHA0D 8t4UaQveRTRUVdHZ02IBVt655Q8Xq1TkHJ7l+2Ckso5IBujWD74QpSRzzffn/ihhEExwYSTj FSs0C/OgU+EDZbcq2SWu4n1OGsW337/80HnJKVWBPAZYy4EmiyQSY05MG/fj9RA9Qi4TjFLD LrIf6dFAmiiIwWjlAKiyyUk+XDJXrc1L2VhcHqfdBY4I/qwV1YAI1QI4W/i6TstB1j0GwKa3 ZORwu4eahL5+9R6xBedhXZpCL0dyKuI8iPaC8npaOCJoL8+l4+KXR/PKt8b8kzIcvSpyCZii PQ== Organization: FreeBSD Message-ID: <3e4b85bc-e605-5a60-759f-c250cbe28a0a@FreeBSD.org> Date: Wed, 15 Jul 2020 23:46:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <266ce56a-0d95-b61a-4757-4ccdc2533ae2@yuripv.dev> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OdNqU5Kj9mlijAEummkyV2hiQqDZmFAZR" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 20:46:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OdNqU5Kj9mlijAEummkyV2hiQqDZmFAZR Content-Type: multipart/mixed; boundary="oOWBdmlUmdWwUS2kBUKsDMwOtUAy0HVkS" --oOWBdmlUmdWwUS2kBUKsDMwOtUAy0HVkS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 14.07.2020 1:47, Yuri Pankov wrote: >> AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd >> mfi0: port 0x6000-0x60ff mem 0xc7300000-0xc730ffff,0xc720000= 0-0xc72fffff irq 26 at device >> 0.0 numa-domain 0 on pci3 >> mfi0: Using MSI >> mfi0: Megaraid SAS driver Ver 4.23 >> mfi0: FW MaxCmds =3D 928, limiting to 128 >> mfi0: MaxCmd =3D 928, Drv MaxCmd =3D 128, MaxSgl =3D 70, state =3D 0xb= 73c03a0 >> ..... >> mfi0: 54944 (boot + 6s/0x0020/info) - Firmware initialization started = (PCI ID 005d/1000/0809/15d9) >> pcib4: mfi0: 54945 (boot + 6s/0x0020/info) - Firm= ware version 4.290.00-4536 >> >> >> I have posted screenshots of the panic at: >> =C2=A0=C2=A0=C2=A0=C2=A0 www.tegenbosch28.nl/FreeBSD/Crash-LSI3108 >> >> But basically it crashes in >> =C2=A0=C2=A0=C2=A0=C2=A0 mfi_tbolt_send_frame() +0x132 >> >> So is there anybody out there that can help me with analyzing and fixi= ng this panic? >=20 > I guess it's not the answer you are looking for, but you could try the = mrsas driver and check if it's behaves better for you, by setting 'set hw= =2Emfi.mrsas_enable=3D1' from loader prompt. I'm puzzled. I'm have SuperMicro add-on card based on LSI/Avago/Broadcom= 3008. An I'm using "mpr" driver: mpr0: port 0xe000-0xe0ff mem 0xf724000= 0-0xf724ffff,0xf7200000-0xf723ffff irq 16 at device 0.0 on pci1 mpr0: Firmware: 14.00.00.00, Driver: 23.00.00.00-fbsd mpr0: IOCCapabilities: 7a85c "man mpr" mentions LSI-3108 too, and "man mfi" doesn't mention LSI-3xxx = chips. Why does "mfi" attaches to LSI-3xxx? What is proper driver for the= se chips? --=20 // Lev Serebryakov --oOWBdmlUmdWwUS2kBUKsDMwOtUAy0HVkS-- --OdNqU5Kj9mlijAEummkyV2hiQqDZmFAZR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAl8PaypfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R49Dxg//TKpvK6aMMWGZmab8/TjSbpfRZbSmaTpm32ycz9gq3v/24HSFeBZIAPmu wy6NKy5Fm3chP5n4q3hxYs1IqxsCZhvZIMjoIT9H1CoAFE6pg3Q5zGjYIHSnn/j+ ZWjzYLn7cIx1ejq+hiakrtIhofKIC6ezAwR4DM18GvM1Q1snkNCaWBoTOpMZLECM cht7pcxeJgxO/krT097QeAHK7iIHtM0z04Rp+6T3YVIwa0zm2EBXM0kgcWRZ1jIY +hN0pRlVxPIDfKSZHDb6V6DYf63Bo2hixbPF/7sNsBemxW9ApaDBKFWGYOVN2DNR XOlnntKUIj1w8fIohjQcRb0VVzimzoV4IG+kT+BwJ4Gdp9YvyWSUJLgPLy9sxNuh w1gdcvwj7KL/cWmZMOYeWlUDC9fHqgX9GwG2WHAWFhERy0kyVb3umk29ruNguir1 hQcT7AurmlDEUaAPLRhOl7KP/DX7Gw27I3/7LgSJ7McbKEj2fq/wTuVSSsRHGy/r tC2dS2NDc/yGVwk2ra+KuU36vXckPJ7kJ6I4nzUppKkcbfzBZ7ZxVof3be9wyRHx 7eGW4DdvGdruQP0LHFa6S/8zoQ/eLy59rmrmJlRIqL2gSnr35qXPrXeS/lUJcnSq WkrkYe80bOILFje59ytE5HuBbBFOLVg2Mh8haQr943YKqPDNTCI= =dgH8 -----END PGP SIGNATURE----- --OdNqU5Kj9mlijAEummkyV2hiQqDZmFAZR-- From owner-freebsd-current@freebsd.org Wed Jul 15 22:25:16 2020 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 C9E723705F9; Wed, 15 Jul 2020 22:25:16 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6X580J4tz4JJX; Wed, 15 Jul 2020 22:25:16 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id BA40A1561C; Wed, 15 Jul 2020 22:25:15 +0000 (UTC) Date: Thu, 16 Jul 2020 00:25:13 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2020 Message-ID: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zpkl3mlsiuohrpr7" Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 22:25:17 -0000 --zpkl3mlsiuohrpr7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="report-2020-04-2020-06.txt" Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Second Quarter 2020 Introduction This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland and ports, as well to third-party work. Some hilights picked with the roll of a d100 include, but are not limited to, the ability to forcibly unmounting UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things. As a little treat, readers can also get a rare report from the quarterly team. Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. His contributions not just the quarterly reports themselves, but also the surrounding tooling to many-fold ease the work, are immeassurable. We hope you find the report as interesting as we have, Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office Hours * Quarterly Status Reports Team Projects * FreeBSD on Microsoft HyperV and Azure * Git Migration Working Group * Lua Usage in FreeBSD * Linux compatibility layer update * NFS over TLS implementation Kernel * SoC audio framework and more audio drivers * bhyve - NVMe emulation improvements * Bluetooth Support * DRM Drivers Update * DTS Update * ENA FreeBSD Driver Update * Forcible Unmount of UFS/FFS Filesystems on Disk Failure * i.MX 8M support * Intel wireless and 11ac update * amd64 5-Level Paging Structures support * Not-transparent superpages * NXP ARM64 SoC support * amd64 pmap Fine-grained pv lists locking * Lockless routing lookups and scalable multipath * ZSTD Compression in ZFS * CheriBSD 2020 Q2 Architectures * Continuous Integration on !x86 * FreeBSD/RISC-V Project Userland Programs * Import of new implementation of bc and dc * Binutils Retirement * Run-Time Dynamic Linker improvements * VHDX support in mkimg(1) Ports * Bastille * KDE on FreeBSD * Haskell on FreeBSD * rtsx - Porting driver for Realtek SD card reader from OpenBSD * Valgrind updates Documentation * FreeBSD Translations on Weblate Miscellaneous * FreshPorts * PCI passthrough with bhyve on Intel and for OpenBSD guests * SageMath Third-Party Projects * chaifi - a tool to simplify joining public WiFi networks * MixerTUI * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. Fundraising Efforts Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We'd like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include: * WiFi improvements * Linuxulator application compatibility * DRM / Graphics driver updates * Zstd compression for OpenZFS * Online RAID-Z expansion * if_bridge performance improvements You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) improvements * Improved FreeBSD support on Microsoft HyperV and Azure * Fine-grained locking for amd64 pmap * 5-level paging structures for amd64 * Non-transparent superpages * Migration to a Git repository * Tool chain modernization Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation. A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Silver sponsor of BSDCan 2020. The event was held virtually, June 2-6, 2020 * Community Sponsor of Rootconf 2020. The event was held virtually, June 19-20, 2020 * Annual FreeBSD Day, June 19. This year's celebration was postponed in support of Juneteeth. However the activities surrounding FreeBSD Day have been transformed into an ongoing series of online sessions. See FreeBSD Fridays below for more information. * Presented 27 Years of FreeBSD and Why You Should Get Involved as part of a Linux Professional Institute series of webinars on June 24, 2020. * Attended and presented at the virtual Open Source Summit 2020. * Announced FreeBSD Fridays: A series of 101 classes designed to get you started with FreeBSD. Find out more in the announcement * Participated as an Admin for Google Summer of Code 2020 * Participated in the new FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * 5x if_bridge Performance Improvement * My Experience as a FreeBSD Foundation Co-Op Student Keep up to date with our latest work in our Bi-Monthly newsletters. Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site. You can find out more about events we attended and upcoming events. We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3. Foundation Board Meeting Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months. The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project. Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities. Results of the director and officer elections were: * Justin Gibbs (President) * Benedict Reuschling (Vice President) * Kirk McKusick (Treasurer) * Philip Paeps (Secretary) * Deb Goodkin (Assistant Secretary) * Robert Watson (Director) * Hiroki Sato (Director) * George Neville-Neil (Director) Find out more about the FreeBSD Foundation Board of Directors on our website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting: * Deb requested guidance on how the Foundation can support the community. Core and Foundation members believe that more developer support is necessary to fill gaps in areas where commercial customers do not provide backing. The clearest example of such a gap is the desktop experience, including graphics and wireless support. What makes this request different from past requests is that rather than support for one-time projects, ongoing positions are necessary for a consistently high-quality desktop experience. "FreeBSD not being able to run on your laptop is the first step to irrelevance." Ed Maste * Both teams discussed topics for upcoming sessions of FreeBSD Office Hours, informal FreeBSD video conferences that anyone can attend. Everyone agreed that the Office Hours have been a useful way for different parts of the Project to engage with each other and with the wider community. Kudos to Allan Jude for initiating the Office Hours and for everyone who has helped make them a success by hosting or attending sessions. * Both teams agreed that they should meet once per quarter. The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon. The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository. Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html). The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are: * Sean Chittenden (seanc, incumbent) * Baptiste Daroussin (bapt) * Kyle Evans (kevans) * Mark Johnston (markj) * Scott Long (scottl) * Warner Losh (imp, incumbent) * Ed Maste (emaste) * George V. Neville-Neil (gnn) * Hiroki Sato (hrs, incumbent) A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE announcement=20 URL: https://www.freebsd.org/releases/11.4R/announce.html FreeBSD 11.4-RELEASE schedule=20 URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD development snapshots=20 URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code slushes, and maintaining the respective branches, among other things. During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release. The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all x86 ref- and universe-machines * Setup Amsterdam (PKT) mirror * Solve hardware issue for bugzilla and svnweb backend * Setup public beta git server * Decommission CyberOne Data (CYB) mirror * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group * Check new hardware requirement from other teams * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All -test jobs will run tests under /usr/tests, previously only x86 architectures doing this. See the Continuous Integration on !x86 section in this report for more information. * Compression algorithm of disk images on the artifact server has been changed to zstd to speed up compression and decompression. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Work in progress: * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Setting up a builder dedicated to run jobs using provisioned VMs. * Setting up the CI stage environment and putting the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs. During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@. A few default versions got bumped: * Java (new) at 8 * Lazarus to 2.0.8 It is now possible to write pkg scripts in Lua instead of sh. They have two advantages over their sh versions: * they run in a Capsicum sandbox * they respect rootdir, the directory which pkg will use as the starting point to install all packages under. Some user-facing packages were also updated: * pkg to 1.14.6 * Firefox to 78.0.1 * Thunderbird to 68.10.0 * Chromium to 83.0.4103.116 * Ruby to 2.5.8, 2.6.6, and 2.7.1 * Qt5 to 5.14.2 During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f. __________________________________________________________________ FreeBSD Office Hours Links Office Hours on the FreeBSD Wiki=20 URL: https://wiki.freebsd.org/OfficeHours Poll: What time would you prefer Office Hours be at=20 URL: https://forms.gle/3HjjRx9KMcM3SL4H7 live.FreeBSD.org: Aggregation of Live streams=20 URL: https://live.freebsd.org/ Contact: Allan Jude Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people. On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held. Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel. If you would like to host an office hours session, please contact: * Allan Jude * Anne Dickison Sponsor: ScaleEngine Inc. (video streaming) __________________________________________________________________ Quarterly Status Reports Team Links Quarterly status reports=20 URL: https://www.freebsd.org/news/status/ Git repository =20 URL: https://github.com/freebsd/freebsd-quarterly Contact: Quarterly Status Reports Contact: Daniel Ebdrup Jensen The Quarterly Status Reports Team collects and publish the reports that you are reading right now. Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports. * Reports are now built using Makefiles. Among the many advantages, this allows us to easily sort reports logically. Indeed, starting with 2019Q4, all reports are sorted logically, while before they were sorted alphabetically within each category. * The conversion from markdown to docbook was performed using a python script, with some known bugs. Salvadore has rewritten the script using perl fixing most of the bugs. Some features are missing and many improvements are possible, but the script is very unlikely to receive any change since it will become obsolete as soon as the conversion to Hugo/AsciiDoctor is completed. * Another perl script to ease the preparation of the mail version of the reports was written. * One more perl script has been written to allow the quarterly team to send quarterly calls automatically using a cron job. We used it this quarter for the first time. * As you might have noticed, last quarterly calls have been sent to freebsd-quarterly-calls@: this is a new mailing list to which you can subscribe to receive calls for quarterly reports. Please note this is a moderated list, with very low traffic and a high signal to noise ratio. * If you read carefully the last quarterly calls, you should have noticed that we now ask you to send reports to quarterly-submissions@ instead of quarterly@. This was done to help the quarterly team distinguishing internal discussions from submissions. Please keep in mind however that the quarterly team prefers receiving pull requests, as they ease the administrative work. We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki=20 URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV =20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests. Details of HyperV Socket is available here. This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=F6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo. We are now working on updating FreeBSD processes and documentation. This includes: * Writing a Git Primer, akin to the existing Subversion primer * Updates to the Security Team's tools and processes * Release engineering updates * Ports and packages process updates Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We expect to be ready for the migration in the next quarter. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Lua Usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage: * /usr/libexec/flua is now installed for internal usage * makesyscalls.sh was rewritten in Lua * pkg has gained support for lua scripts * lldb in the base system now supports lua scripting FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations. Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libjail * libnv * libxo __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2). There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 500 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon. Third party testing would be appreciated. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and more audio drivers Links rk3399_audio=20 URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko SoC audio framework made a good progress since last report. Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip). To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback. Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro). __________________________________________________________________ bhyve - NVMe emulation improvements Links bhyve NVMe reviews=20 URL: https://reviews.freebsd.org/search/query/xvbcF20W__Km/ Contact: Chuck Tuffli The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include: * implement Flush command * implement Format NVM command * implement AER support * implement Namespace Identification Descriptor * fix Active Namespace list * fix queue creation and deletion * validate Deallocate range values * handle zero length DSM ranges * fix Get Log Page command * implement SMART data I/O statistics * validate the LBA start and count * add basic Firmware Commit support * add more compliant Get/Set Features * add Feature, Interrupt Vector Config * fix Get Features, Predictable Latency This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes * convert logging statements to parameterized macros * refactor I/O command handling * add locks around queue accesses * consolidate CQ update * base pci_nvme_ioreq size on advertised MDTS You can help by testing and/or commenting on the code reviews. __________________________________________________________________ Bluetooth Support Contact: Marc Veldman Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors. FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support. During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed. Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support. __________________________________________________________________ DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4). The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Fixes for Rx refill to improve stability on low memory conditions (also released as an errata notice for FreeBSD-12.1) * Upstream of the v2.2.0 driver, introducing: + Add driver support for the upcoming HW features (reporting Tx drops, disabling meta caching) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Driver is now marked as epoch ready + Default RSS key is created using RNG to improve security + Other minor fixes and improvements * MFC of the ENA v2.2.0 driver to the FreeBSD 11.4 Sponsor: Amazon.com Inc __________________________________________________________________ Forcible Unmount of UFS/FFS Filesystems on Disk Failure Links Phabricator Details=20 URL: https://reviews.freebsd.org/D24088 Contact: Chuck Silvers Contact: Kirk McKusick Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged. The rest of this report describes in more detail how forcible unmounts are done. Suprisingly, less than 500 lines of file system code were added or changed. The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system. There are two cases for disk I/O errors: * ENXIO, which means that this disk is gone and the lower layers of the storage stack already guarantee that no future I/O to this disk will succeed. * EIO (or most other errors), which means that this particular I/O request has failed but subsequent I/O requests to this disk might still succeed. For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount. This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer. Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk. Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk. The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent. Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors. Sponsor: Netflix __________________________________________________________________ i.MX 8M support Links D25274=20 URL: https://reviews.freebsd.org/D25274 Contact: Oleksandr Tymoshenko i.MX 8M is the family of application processors from NXP based on Arm=AE Cortex=AE-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings. With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC. __________________________________________________________________ Intel wireless and 11ac update Links Initial project announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-wireless/2020-April/00= 9055.html The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless cards are one of the most commonly used and ask for in FreeBSD notebooks. This project has three main goals: * newer Intel Wireless device support, * newer WiFi standards support for Intel Wireless, * integration of 802.11ac client support and infrastructure in FreeBSD. The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed. One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back. At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year. If you want to help testing, please watch the freebsd-wireless list. Sponsor: The FreeBSD Foundation __________________________________________________________________ amd64 5-Level Paging Structures support Links Patch=20 URL: https://reviews.freebsd.org/D25273 Intel SDM=20 URL: https://software.intel.com/content/www/us/en/develop/articles/inte= l-sdm.html Intel whitepaper=20 URL: https://software.intel.com/content/www/us/en/develop/download/5-le= vel-paging-and-5-level-ept-white-paper.html Contact: Konstantin Belousov Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits. In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 =3D 512 times more virtual memory. The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57. The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This neccessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode. I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful. After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde(). Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note. Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware. Sponsor: The FreeBSD Foundation __________________________________________________________________ Not-transparent superpages Links Patch=20 URL: https://reviews.freebsd.org/D24652 Contact: Konstantin Belousov FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to proactively prevent fragmentation, reserves contigous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage. The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used. The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages. The new type of the shared memory objects are backed by modified a physical pager, which only allocates contigous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it. Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes. Sponsor: The FreeBSD Foundation __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Improve code in a couple of review cycles and merge following new features to the FreeBSD-HEAD (r361458 - r361464): + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC Todo: * Upstreaming of the QorIQ SDHCI driver - it is expected to be submitted/merged to HEAD in the Q3 of 2020. Sponsor: Alstom Group __________________________________________________________________ amd64 pmap Fine-grained pv lists locking Links Patch=20 URL: https://reviews.freebsd.org/D24217 Contact: Konstantin Belousov FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging). The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list. Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU =3D=3D 256 locks hashed by = the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations typically cause adjasted pages to come from the same superpage. The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time. One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes. Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page. To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines. Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen). Sponsor: The FreeBSD Foundation __________________________________________________________________ Lockless routing lookups and scalable multipath Links Implementation of scalable multipath=20 URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Contact: Alexander Chernikov The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups. Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes. Background The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years. Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt. Implementation overview Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation. Multipath implementation extends nexthop concept further by introducing nexthop groups. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation. Status * Nexthop objects [ DONE ] * Introduction of nexthop objects [ DONE ] * Conversion of old KPI users to the new one [ DONE ] * Conversion of route caching to nexthop caching [ DONE ] * Conversion of struct rtentry field access to nhop field access [ DONE ] * Eliminating old lookup KPI and hiding struct rtentry [ DONE ] Multipath [ IN PROGRESS ] * Switch control plane consumers to use (rtentry, nhop) pairs instead of rtentry to allow multipath changes happen transparently [ 90% DONE ] * Introduce nexthop group objects * Add mutipath support for the rib (routing information base) manipulation functions * Add flowid generation for outbound traffic to enable load balancing Modular longest-prefix-match lookup algorithm [ IN PROGRESS ] * Design control plane framework for attaching algorithms [ 90% DONE ] * Port IPv6 lockless lookup algorithm [ DONE ] * Port IPv4 lockless lookup algorithm __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation. Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Extend ZFS to support compression algorithms with large numbers of levels * Solve issues around the inheritence of compression settings * Restore compression level when reading blocks from disk * Create a future-proofing scheme to handle changing versions of ZSTD * Extend ZFS replication to handle backwards compatibility with pools that do not yet support ZSTD * Resolve issues around backwards compatibility when ZSTD is configured but not used Sponsor: The FreeBSD Foundation __________________________________________________________________ CheriBSD 2020 Q2 Links CHERI-CPU =20 URL: http://www.cheri-cpu.org DARPA FETT Bug Bounty Program=20 URL: https://fett.darpa.mil Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions. Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for: * dynamically linked binaries (previously only statically-linked binaries were supported) * C++ including exceptions * sealed return address and function pointer capabilities ("sentries") which provide additional CFI protection * initial MMU protections for loading and storing tags At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS. Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program). In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A. We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM. For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Continuous Integration on !x86 Contact: Edward Tomasz Napierala For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International. The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk. On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/t= estReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild= /testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/= testReport/). For POWER, and RISC-V the results are not available yet. Remaining work: * Failing regression tests need to be fixed. * The tests are quite slow on QEMU, for example the ARM64 run takes about five hours. Running them automatically after each commit would quickly overload the CI cluster. A solution would be to e.g. run them daily. * Some of the jobs still fail to produce results: powerpc64 deadlocks at the end of regression test suite due to an unkillable process, riscv64 panics randomly, and on mips64 kyua(1) often crashes on jemalloc assertion. Those might be fixed by an upcoming QEMU port update. Sponsor: DARPA __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability. This quarter saw a number of improvements to the boot process. The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger. Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available. There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Import of new implementation of bc and dc Links Official repository =20 URL: https://git.yzena.com/gavin/bc Repository mirror on GitHub=20 URL: https://github.com/gavinhoward/bc/ Contact: Stefan Esser Contact: Gavin D. Howard A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=3Dyes" to be set in /etc/src.conf). This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator). Additional features: * High performance (up to more than a factor of 100 faster than the current FreeBSD implementation in some tests) * support of message catalogs with a large number of languages supported in the current release (contributions of further translations are welcome). * Extra built-in functions and operators. * Extended library of advanced math functions * Detailed man-page explaining standard conformant and extended features * One shared binary for bc and dc (bc is not just a pre-processor that relies on dc for the actual computations) The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have. This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release. __________________________________________________________________ Binutils Retirement Links GPL in Base wiki page=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as. Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package. The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file. Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0. TODO The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8). Sponsor: The FreeBSD Foundation __________________________________________________________________ Run-Time Dynamic Linker improvements Contact: Konstantin Belousov Rtld gets some number of small bug fixes and improvements. RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc. Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary. The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact. In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation. Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all. With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them. Sponsor: The FreeBSD Foundation __________________________________________________________________ VHDX support in mkimg(1) Contact: Oleksandr Tymoshenko VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures. VHDX is the required format for 2nd generation Hyper-V VMs. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Bastille Links Bastille GitHub =20 URL: https://github.com/bastillebsd/bastille Bastille Templates=20 URL: https://gitlab.com/bastillebsd-templates Bastille Website =20 URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports at sysutils/bastille. Q2 2020 Status In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include: * experimental support for new Bastillefile template syntax * added mount and umount sub-commands * added a default Vagrantfile for simple testing * experimental support for empty containers * improvements to VNET DHCP support * cosmetic bugfixes in error output * extended config file documentation * updated bastille help output * option to (-f) force destroy container sysutils/bastille was updated to 0.6.20200414 (latest). New Bastille templates added this quarter include: * Percona database server * Asterisk SIP server * dnsmasq DNS/DHCP server (VNET required) * nginx pkg server for poudriere Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine. This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team: * Restored a patch that closes down a remote TCP held by X11 applications that use the ICE library. Thanks to Colin Percival for reporting it. It went missing in one of the port updates. To prevent this in the future, the patch has been upstreamed. PR 229772. * Chased KDE-adjacent software like CMake, Cutelyst, Latte-dock and Nheko through new releases. In particular CMake takes a lot of effort every time because it is a build-time dependency of over 2000 ports. * graphics/poppler was updated to the latest upstream release. This is a low-level dependency for many document-viewing applications, and like CMake requires chasing a lot of other software. Poppler is one of the components shared between various software stacks (and "desktop environments") under the desktop@ group, in which kde@ participates. * KDE Frameworks release like clockwork, reaching KDE Frameworks 5.70 mid-may. * KDE Applications -- the KDE release service, really, which delivers libraries, applications, and add-ons -- had one large release, with 20.04.1 landing in the ports tree also mid-may and its monthly update 20.04.2 in mid-june. * Some new Wayland support for KDE Plasma -- we have not tested this on FreeBSD -- has appeared and has been duly packaged. * A great deal of preparation has gone into Qt 5.15. Many ports have been pre-emptively patched for this new -- and last -- LTS release of Qt 5. The update itself has not yet landed, pending a few last bits of fallout. The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine. The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71. __________________________________________________________________ Haskell on FreeBSD Links Haskell language homepage=20 URL: http://www.haskell.org/ Ports development repo =20 URL: https://github.com/freebsd/freebsd-ports-haskell Contact: Gleb Popov Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language. This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too. All existing ports of Haskell applications were migrated to USES=3Dcabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed. Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome. __________________________________________________________________ rtsx - Porting driver for Realtek SD card reader from OpenBSD Links rtsx =20 URL: https://github.com/hlh-restart/rtsx PR204521=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204521 Contact: Henri Hennebert The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port. From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart. The driver has been successfully tested with: * RTS5209 under head (Lenovo ThinkPad L520) * RTS5227 under stable/11 and releng/12.1 (HP ProBook 430 g2, Lenovo ThinkPad T450/T450s) * RTS5229 under releng/12.1 (Lenovo IdeaPad 120S-14IAP) * RTS522A under releng/12.1 and head (Intel NUC8i5BE, Lenovo ThinkPad P50s) * RTS525A under releng/12.1 (Dell Latitude E5570) * RTL8411B under stable/12 (Acer Aspire E 15 E5-576-77W6) The driver should also work for Realtek RTS5249, RTL8402 and RTL8411. More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks. PR204521 contains the bulk of exchanges for completion of the code. __________________________________________________________________ Valgrind updates Links Patch for valgrind=20 URL: https://reviews.freebsd.org/D25452 Contact: Paul Floyd Contact: Kyle Evans A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind. The devel/valgrind-devel port is in the process of being updated to point at the new work. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki=20 URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance=20 URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR). We are looking forward to receive more languages and translators to the project as well. Q2 2020 Status * 10 languages (No new languages) * 80 registered users (33 new users since last quarter) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ Miscellaneous Objects that defy categorization. FreshPorts Links FreshPorts =20 URL: http://freshports.org/ FreshPorts blog=20 URL: http://news.freshports.org/ Contact: Dan Langille FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website. Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort. The next step include: * incorporate a that script the automated processes of FreshPorts * migrate to new test & stage versions of FreshPorts * test * get ready for prod Help wanted git is not far away now. I could use helpers to * review code * watch the commits on the devgit websites * catch missing stuff Thank you Packages FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built. Dependency lines Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: acme.sh>0:security/acme.sh Libraries are also covered by this feature. Python ports were recently adjusted to display ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv instead of py37-virtualenv>0:devel/py-virtualenv You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73). Watch ports I maintain The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain. This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report. From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change. Repology links Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page. Further reading Based upon things you didn't know FreshPorts can do There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post: * provides example dependency line. e.g. p5-XML-RSS>0:textproc/p5-XML-RSS * list of dependencies for a port * list of ports depending upon this port * see default configuration options * what packages install a given file (e.g. bin/unzip) * find out what ports a person maintains * find Makefiles which contain references to bunzip * search results can be plain-text consisting of a list of foo/bar ports * the Maximum Effort checkbox on the search page does nothing * committers can be notified of sanity test failures after the commit * find a commit, any commit, based on SVN revision number, e.g. : https://www.freshports.org/commit.php?revision=3D352332 Javascript help wanted We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key. Sponsor: hardware provided by iXsystems __________________________________________________________________ PCI passthrough with bhyve on Intel and for OpenBSD guests Links bhyve Intel bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229852 bhyve OpenBSD bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245392 PCI passthrough with bhyve (FreeBSD wiki article)=20 URL: https://wiki.freebsd.org/bhyve/pci_passthru Contact: Anatoli Contact: Callum Contact: Peter Grehan bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use. For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors. The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host. During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version. The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link). A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server. With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host. Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware). In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways. __________________________________________________________________ SageMath Links SageMath site=20 URL: https://www.sagemath.org/ Contact: Thierry Thomas SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers. The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages. If you are interested, it would be nice to create a team of maintainers * to maintain some of the dependencies; * to maintain SageMath itself and prepare the next release (9.2 is coming!). __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. chaifi - a tool to simplify joining public WiFi networks Links chaifi=20 URL: https://github.com/gonzoua/chaifi Contact: Oleksandr Tymoshenko chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time. __________________________________________________________________ MixerTUI Links mixertui=20 URL: https://gitlab.com/alfix/mixertui Contact: Alfonso Sabato Siciliano MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on. MixerTUI can be installed via the audio/mixertui port. I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project. __________________________________________________________________ Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: Stephan Lichtenauer pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer. Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided. The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes. As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome! __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =A9 1995-2020 The FreeBSD Project. All rights reserved. --zpkl3mlsiuohrpr7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PgklfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qDswf/W+zBAaGAkCuf/c3/TG+HE5hCCt6Qyth9BNn+rih+lNGDMwW7UtXD+DU4 0RTm4Hzmn0y4scqZPr1JloLAarGUhsoEd6GGSUqyv52cMoz1RyZ8lkSeu0HaIbkX mUJdNFwEwVLWtk8kzLWXaIuiV9ROMOojT1ZwRzChKCULx7jj5vLvKtntks1WVe8r mK5DMTlihnbaGSh8o5UnCFVUv9W+kQRWrKqZa+demd1zaMfKeeKQ5njw5wsb6aq9 iZs8tkSjeqmB6Cp2Nk+ZN4HjCr/IMeoFOKzgXgl64uRe6PKhXPtCXSKfm/XgoSND eHGaKVdjP6Y3VqZX6pW47ncFbwHUcw== =jEeX -----END PGP SIGNATURE----- --zpkl3mlsiuohrpr7-- From owner-freebsd-current@freebsd.org Wed Jul 15 22:29:14 2020 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 BEA10370BEC; Wed, 15 Jul 2020 22:29:14 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (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 4B6X9j13Ddz4P8d; Wed, 15 Jul 2020 22:29:12 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 59EA258100C; Wed, 15 Jul 2020 18:29:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 18:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=E LGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAHX0=; b=buA8iYHjMGI7pGenB pcBN2UBXHx0De3HARkbpUaS+7BTZSmLDZwBZpEPrhxXuSNyf49EZyVE1RFdvhWHA v30l3X0WtxIrPV1NXZYrHqzzL0OH8b7HEFSngf/zYkhJN9gN+krxARk3lZSqhvWI IdCxRsp56EqWawN1Z41R2rFfAWUngNz0bJ9Wx4KfB+g9ybQBYUfaBiPBtRv5phV/ 3VsYfCQwVWYUwT5phfMddz1QqklfkKGPqVt2qrGbnYOKEz5PwA2Y+Zga7o5rIAUg +j1rEwkR9rKF+rtSt1WnqjFpCPT7vag9P/SSaZ1WLwrg64k2Y1fDFJomcAMFP3jW p3RRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ELGUs4n/WBH16Kw7woKSGvBg1VFX+D/v3+yQNeUAH X0=; b=UjTQtEqF8jv6abjN24I+nXNOoPGWOBHTXh13zB/sv5F3xnObfyks4mJEq VXnY4bUGbkwMlTMIl6nqnvwh7TgTjHbew6dPH0pc9hSIquqwoy2OZ17BQ/5VcH1b E5tyMPaM/cGVglfP+g8wGs5KsAHq/RQxxOY4yqhwaqGa5nl/wOqnnkX1T5Wyes2Z NdHtbG3i6jV63ci5QhfDFxa9T7e3TeiRXJULkDPRVl4bwzhuCjAdAmljo+TpfkGK kXp8cnjhfLJYC8IiiXTdVwZZY/HoUJzeXi6QmCwWW8u/FJtpSklc1ZV+U54MNiE4 s0waLLpNl/Jn0KkRzsT/uzqH9khUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeefgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeehnecuhfhrohhmpegjuhhrihcu rfgrnhhkohhvuceohihurhhiphhvseihuhhrihhpvhdruggvvheqnecuggftrfgrthhtvg hrnhepffdvudffheegffejjeekieduffffgefgjefftedugeeiudfhheetfffhvefgtefg necukfhppeeluddrvdegtddruddvgedrudefjeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihhpvheshihurhhiphhvrdguvghv X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 2CCD33060067; Wed, 15 Jul 2020 18:29:10 -0400 (EDT) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2020 To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> From: Yuri Pankov Message-ID: <7025a36e-52bf-ca18-185f-3c9adebdf26b@yuripv.dev> Date: Thu, 16 Jul 2020 01:29:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200715222513.jnsjdzklmhrgjch4@nerd-thinkpad.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B6X9j13Ddz4P8d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 22:29:14 -0000 Daniel Ebdrup Jensen wrote: [nothing] At least in Thunderbird the text is not inline, and rather shows as attachment. From owner-freebsd-current@freebsd.org Wed Jul 15 22:33:27 2020 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 06339371683; Wed, 15 Jul 2020 22:33:27 +0000 (UTC) (envelope-from debdrup@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6XGZ2SFLz4VXn; Wed, 15 Jul 2020 22:33:26 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 73DCC1E1DF; Wed, 15 Jul 2020 22:33:25 +0000 (UTC) Date: Thu, 16 Jul 2020 00:33:23 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2020 [Inlined] Message-ID: <20200715223323.6cx65wzodfpmrfh5@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="psc724i6dgwcog6o" Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 15 Jul 2020 22:33:27 -0000 --psc724i6dgwcog6o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Second Quarter 2020 Introduction This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland and ports, as well to third-party work. Some hilights picked with the roll of a d100 include, but are not limited to, the ability to forcibly unmounting UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things. As a little treat, readers can also get a rare report from the quarterly team. Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. His contributions not just the quarterly reports themselves, but also the surrounding tooling to many-fold ease the work, are immeassurable. We hope you find the report as interesting as we have, Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office Hours * Quarterly Status Reports Team Projects * FreeBSD on Microsoft HyperV and Azure * Git Migration Working Group * Lua Usage in FreeBSD * Linux compatibility layer update * NFS over TLS implementation Kernel * SoC audio framework and more audio drivers * bhyve - NVMe emulation improvements * Bluetooth Support * DRM Drivers Update * DTS Update * ENA FreeBSD Driver Update * Forcible Unmount of UFS/FFS Filesystems on Disk Failure * i.MX 8M support * Intel wireless and 11ac update * amd64 5-Level Paging Structures support * Not-transparent superpages * NXP ARM64 SoC support * amd64 pmap Fine-grained pv lists locking * Lockless routing lookups and scalable multipath * ZSTD Compression in ZFS * CheriBSD 2020 Q2 Architectures * Continuous Integration on !x86 * FreeBSD/RISC-V Project Userland Programs * Import of new implementation of bc and dc * Binutils Retirement * Run-Time Dynamic Linker improvements * VHDX support in mkimg(1) Ports * Bastille * KDE on FreeBSD * Haskell on FreeBSD * rtsx - Porting driver for Realtek SD card reader from OpenBSD * Valgrind updates Documentation * FreeBSD Translations on Weblate Miscellaneous * FreshPorts * PCI passthrough with bhyve on Intel and for OpenBSD guests * SageMath Third-Party Projects * chaifi - a tool to simplify joining public WiFi networks * MixerTUI * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. Fundraising Efforts Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We'd like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include: * WiFi improvements * Linuxulator application compatibility * DRM / Graphics driver updates * Zstd compression for OpenZFS * Online RAID-Z expansion * if_bridge performance improvements You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) improvements * Improved FreeBSD support on Microsoft HyperV and Azure * Fine-grained locking for amd64 pmap * 5-level paging structures for amd64 * Non-transparent superpages * Migration to a Git repository * Tool chain modernization Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation. A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: * Silver sponsor of BSDCan 2020. The event was held virtually, June 2-6, 2020 * Community Sponsor of Rootconf 2020. The event was held virtually, June 19-20, 2020 * Annual FreeBSD Day, June 19. This year's celebration was postponed in support of Juneteeth. However the activities surrounding FreeBSD Day have been transformed into an ongoing series of online sessions. See FreeBSD Fridays below for more information. * Presented 27 Years of FreeBSD and Why You Should Get Involved as part of a Linux Professional Institute series of webinars on June 24, 2020. * Attended and presented at the virtual Open Source Summit 2020. * Announced FreeBSD Fridays: A series of 101 classes designed to get you started with FreeBSD. Find out more in the announcement * Participated as an Admin for Google Summer of Code 2020 * Participated in the new FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * 5x if_bridge Performance Improvement * My Experience as a FreeBSD Foundation Co-Op Student Keep up to date with our latest work in our Bi-Monthly newsletters. Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site. You can find out more about events we attended and upcoming events. We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3. Foundation Board Meeting Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months. The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project. Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities. Results of the director and officer elections were: * Justin Gibbs (President) * Benedict Reuschling (Vice President) * Kirk McKusick (Treasurer) * Philip Paeps (Secretary) * Deb Goodkin (Assistant Secretary) * Robert Watson (Director) * Hiroki Sato (Director) * George Neville-Neil (Director) Find out more about the FreeBSD Foundation Board of Directors on our website. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting: * Deb requested guidance on how the Foundation can support the community. Core and Foundation members believe that more developer support is necessary to fill gaps in areas where commercial customers do not provide backing. The clearest example of such a gap is the desktop experience, including graphics and wireless support. What makes this request different from past requests is that rather than support for one-time projects, ongoing positions are necessary for a consistently high-quality desktop experience. "FreeBSD not being able to run on your laptop is the first step to irrelevance." Ed Maste * Both teams discussed topics for upcoming sessions of FreeBSD Office Hours, informal FreeBSD video conferences that anyone can attend. Everyone agreed that the Office Hours have been a useful way for different parts of the Project to engage with each other and with the wider community. Kudos to Allan Jude for initiating the Office Hours and for everyone who has helped make them a success by hosting or attending sessions. * Both teams agreed that they should meet once per quarter. The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon. The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository. Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html). The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are: * Sean Chittenden (seanc, incumbent) * Baptiste Daroussin (bapt) * Kyle Evans (kevans) * Mark Johnston (markj) * Scott Long (scottl) * Warner Losh (imp, incumbent) * Ed Maste (emaste) * George V. Neville-Neil (gnn) * Hiroki Sato (hrs, incumbent) A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE announcement=20 URL: https://www.freebsd.org/releases/11.4R/announce.html FreeBSD 11.4-RELEASE schedule=20 URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD development snapshots=20 URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code slushes, and maintaining the respective branches, among other things. During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release. The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all x86 ref- and universe-machines * Setup Amsterdam (PKT) mirror * Solve hardware issue for bugzilla and svnweb backend * Setup public beta git server * Decommission CyberOne Data (CYB) mirror * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group * Check new hardware requirement from other teams * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All -test jobs will run tests under /usr/tests, previously only x86 architectures doing this. See the Continuous Integration on !x86 section in this report for more information. * Compression algorithm of disk images on the artifact server has been changed to zstd to speed up compression and decompression. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-armv7-test/ * https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/ * https://ci.freebsd.org/job/FreeBSD-head-mips64-test/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/ Work in progress: * Collecting and sorting CI tasks and ideas here * Testing and merging pull requests in the the FreeBSD-ci repo * Setting up a builder dedicated to run jobs using provisioned VMs. * Setting up the CI stage environment and putting the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building tests against -CURRENT * Planning to run ztest and network stack tests * Adding external toolchain related jobs * Improving the hardware lab to be more mature and adding more hardware * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs. During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@. A few default versions got bumped: * Java (new) at 8 * Lazarus to 2.0.8 It is now possible to write pkg scripts in Lua instead of sh. They have two advantages over their sh versions: * they run in a Capsicum sandbox * they respect rootdir, the directory which pkg will use as the starting point to install all packages under. Some user-facing packages were also updated: * pkg to 1.14.6 * Firefox to 78.0.1 * Thunderbird to 68.10.0 * Chromium to 83.0.4103.116 * Ruby to 2.5.8, 2.6.6, and 2.7.1 * Qt5 to 5.14.2 During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f. __________________________________________________________________ FreeBSD Office Hours Links Office Hours on the FreeBSD Wiki=20 URL: https://wiki.freebsd.org/OfficeHours Poll: What time would you prefer Office Hours be at=20 URL: https://forms.gle/3HjjRx9KMcM3SL4H7 live.FreeBSD.org: Aggregation of Live streams=20 URL: https://live.freebsd.org/ Contact: Allan Jude Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people. On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held. Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel. If you would like to host an office hours session, please contact: * Allan Jude * Anne Dickison Sponsor: ScaleEngine Inc. (video streaming) __________________________________________________________________ Quarterly Status Reports Team Links Quarterly status reports=20 URL: https://www.freebsd.org/news/status/ Git repository =20 URL: https://github.com/freebsd/freebsd-quarterly Contact: Quarterly Status Reports Contact: Daniel Ebdrup Jensen The Quarterly Status Reports Team collects and publish the reports that you are reading right now. Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports. * Reports are now built using Makefiles. Among the many advantages, this allows us to easily sort reports logically. Indeed, starting with 2019Q4, all reports are sorted logically, while before they were sorted alphabetically within each category. * The conversion from markdown to docbook was performed using a python script, with some known bugs. Salvadore has rewritten the script using perl fixing most of the bugs. Some features are missing and many improvements are possible, but the script is very unlikely to receive any change since it will become obsolete as soon as the conversion to Hugo/AsciiDoctor is completed. * Another perl script to ease the preparation of the mail version of the reports was written. * One more perl script has been written to allow the quarterly team to send quarterly calls automatically using a cron job. We used it this quarter for the first time. * As you might have noticed, last quarterly calls have been sent to freebsd-quarterly-calls@: this is a new mailing list to which you can subscribe to receive calls for quarterly reports. Please note this is a moderated list, with very low traffic and a high signal to noise ratio. * If you read carefully the last quarterly calls, you should have noticed that we now ask you to send reports to quarterly-submissions@ instead of quarterly@. This was done to help the quarterly team distinguishing internal discussions from submissions. Please keep in mind however that the quarterly team prefers receiving pull requests, as they ease the administrative work. We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki=20 URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV =20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests. Details of HyperV Socket is available here. This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=F6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo. We are now working on updating FreeBSD processes and documentation. This includes: * Writing a Git Primer, akin to the existing Subversion primer * Updates to the Security Team's tools and processes * Release engineering updates * Ports and packages process updates Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We expect to be ready for the migration in the next quarter. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Lua Usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage: * /usr/libexec/flua is now installed for internal usage * makesyscalls.sh was rewritten in Lua * pkg has gained support for lua scripts * lldb in the base system now supports lua scripting FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations. Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libjail * libnv * libxo __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2). There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 500 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon. Third party testing would be appreciated. __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. SoC audio framework and more audio drivers Links rk3399_audio=20 URL: https://github.com/gonzoua/freebsd/tree/rk3399_audio Contact: Oleksandr Tymoshenko SoC audio framework made a good progress since last report. Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip). To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback. Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro). __________________________________________________________________ bhyve - NVMe emulation improvements Links bhyve NVMe reviews=20 URL: https://reviews.freebsd.org/search/query/xvbcF20W__Km/ Contact: Chuck Tuffli The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include: * implement Flush command * implement Format NVM command * implement AER support * implement Namespace Identification Descriptor * fix Active Namespace list * fix queue creation and deletion * validate Deallocate range values * handle zero length DSM ranges * fix Get Log Page command * implement SMART data I/O statistics * validate the LBA start and count * add basic Firmware Commit support * add more compliant Get/Set Features * add Feature, Interrupt Vector Config * fix Get Features, Predictable Latency This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes * convert logging statements to parameterized macros * refactor I/O command handling * add locks around queue accesses * consolidate CQ update * base pci_nvme_ioreq size on advertised MDTS You can help by testing and/or commenting on the code reviews. __________________________________________________________________ Bluetooth Support Contact: Marc Veldman Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors. FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support. During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed. Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support. __________________________________________________________________ DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4). The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Fixes for Rx refill to improve stability on low memory conditions (also released as an errata notice for FreeBSD-12.1) * Upstream of the v2.2.0 driver, introducing: + Add driver support for the upcoming HW features (reporting Tx drops, disabling meta caching) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Driver is now marked as epoch ready + Default RSS key is created using RNG to improve security + Other minor fixes and improvements * MFC of the ENA v2.2.0 driver to the FreeBSD 11.4 Sponsor: Amazon.com Inc __________________________________________________________________ Forcible Unmount of UFS/FFS Filesystems on Disk Failure Links Phabricator Details=20 URL: https://reviews.freebsd.org/D24088 Contact: Chuck Silvers Contact: Kirk McKusick Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged. The rest of this report describes in more detail how forcible unmounts are done. Suprisingly, less than 500 lines of file system code were added or changed. The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system. There are two cases for disk I/O errors: * ENXIO, which means that this disk is gone and the lower layers of the storage stack already guarantee that no future I/O to this disk will succeed. * EIO (or most other errors), which means that this particular I/O request has failed but subsequent I/O requests to this disk might still succeed. For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount. This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer. Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk. Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk. The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent. Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors. Sponsor: Netflix __________________________________________________________________ i.MX 8M support Links D25274=20 URL: https://reviews.freebsd.org/D25274 Contact: Oleksandr Tymoshenko i.MX 8M is the family of application processors from NXP based on Arm=AE Cortex=AE-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings. With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC. __________________________________________________________________ Intel wireless and 11ac update Links Initial project announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-wireless/2020-April/00= 9055.html The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless Contact: Bjoern A. Zeeb The Intel Wireless cards are one of the most commonly used and ask for in FreeBSD notebooks. This project has three main goals: * newer Intel Wireless device support, * newer WiFi standards support for Intel Wireless, * integration of 802.11ac client support and infrastructure in FreeBSD. The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed. One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back. At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year. If you want to help testing, please watch the freebsd-wireless list. Sponsor: The FreeBSD Foundation __________________________________________________________________ amd64 5-Level Paging Structures support Links Patch=20 URL: https://reviews.freebsd.org/D25273 Intel SDM=20 URL: https://software.intel.com/content/www/us/en/develop/articles/inte= l-sdm.html Intel whitepaper=20 URL: https://software.intel.com/content/www/us/en/develop/download/5-le= vel-paging-and-5-level-ept-white-paper.html Contact: Konstantin Belousov Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits. In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 =3D 512 times more virtual memory. The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57. The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This neccessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode. I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful. After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde(). Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note. Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware. Sponsor: The FreeBSD Foundation __________________________________________________________________ Not-transparent superpages Links Patch=20 URL: https://reviews.freebsd.org/D24652 Contact: Konstantin Belousov FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to proactively prevent fragmentation, reserves contigous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage. The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used. The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages. The new type of the shared memory objects are backed by modified a physical pager, which only allocates contigous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it. Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes. Sponsor: The FreeBSD Foundation __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Improve code in a couple of review cycles and merge following new features to the FreeBSD-HEAD (r361458 - r361464): + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC Todo: * Upstreaming of the QorIQ SDHCI driver - it is expected to be submitted/merged to HEAD in the Q3 of 2020. Sponsor: Alstom Group __________________________________________________________________ amd64 pmap Fine-grained pv lists locking Links Patch=20 URL: https://reviews.freebsd.org/D24217 Contact: Konstantin Belousov FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging). The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list. Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU =3D=3D 256 locks hashed by = the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations typically cause adjasted pages to come from the same superpage. The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time. One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes. Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page. To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines. Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen). Sponsor: The FreeBSD Foundation __________________________________________________________________ Lockless routing lookups and scalable multipath Links Implementation of scalable multipath=20 URL: https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7 Contact: Alexander Chernikov The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups. Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes. Background The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years. Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt. Implementation overview Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation. Multipath implementation extends nexthop concept further by introducing nexthop groups. Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation. A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation. Status * Nexthop objects [ DONE ] * Introduction of nexthop objects [ DONE ] * Conversion of old KPI users to the new one [ DONE ] * Conversion of route caching to nexthop caching [ DONE ] * Conversion of struct rtentry field access to nhop field access [ DONE ] * Eliminating old lookup KPI and hiding struct rtentry [ DONE ] Multipath [ IN PROGRESS ] * Switch control plane consumers to use (rtentry, nhop) pairs instead of rtentry to allow multipath changes happen transparently [ 90% DONE ] * Introduce nexthop group objects * Add mutipath support for the rib (routing information base) manipulation functions * Add flowid generation for outbound traffic to enable load balancing Modular longest-prefix-match lookup algorithm [ IN PROGRESS ] * Design control plane framework for attaching algorithms [ 90% DONE ] * Port IPv6 lockless lookup algorithm [ DONE ] * Port IPv4 lockless lookup algorithm __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation. Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Extend ZFS to support compression algorithms with large numbers of levels * Solve issues around the inheritence of compression settings * Restore compression level when reading blocks from disk * Create a future-proofing scheme to handle changing versions of ZSTD * Extend ZFS replication to handle backwards compatibility with pools that do not yet support ZSTD * Resolve issues around backwards compatibility when ZSTD is configured but not used Sponsor: The FreeBSD Foundation __________________________________________________________________ CheriBSD 2020 Q2 Links CHERI-CPU =20 URL: http://www.cheri-cpu.org DARPA FETT Bug Bounty Program=20 URL: https://fett.darpa.mil Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions. Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for: * dynamically linked binaries (previously only statically-linked binaries were supported) * C++ including exceptions * sealed return address and function pointer capabilities ("sentries") which provide additional CFI protection * initial MMU protections for loading and storing tags At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS. Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program). In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A. We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM. For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Continuous Integration on !x86 Contact: Edward Tomasz Napierala For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International. The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk. On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/t= estReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild= /testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/= testReport/). For POWER, and RISC-V the results are not available yet. Remaining work: * Failing regression tests need to be fixed. * The tests are quite slow on QEMU, for example the ARM64 run takes about five hours. Running them automatically after each commit would quickly overload the CI cluster. A solution would be to e.g. run them daily. * Some of the jobs still fail to produce results: powerpc64 deadlocks at the end of regression test suite due to an unkillable process, riscv64 panics randomly, and on mips64 kyua(1) often crashes on jemalloc assertion. Those might be fixed by an upcoming QEMU port update. Sponsor: DARPA __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability. This quarter saw a number of improvements to the boot process. The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger. Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available. There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported. __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Import of new implementation of bc and dc Links Official repository =20 URL: https://git.yzena.com/gavin/bc Repository mirror on GitHub=20 URL: https://github.com/gavinhoward/bc/ Contact: Stefan Esser Contact: Gavin D. Howard A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=3Dyes" to be set in /etc/src.conf). This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator). Additional features: * High performance (up to more than a factor of 100 faster than the current FreeBSD implementation in some tests) * support of message catalogs with a large number of languages supported in the current release (contributions of further translations are welcome). * Extra built-in functions and operators. * Extended library of advanced math functions * Detailed man-page explaining standard conformant and extended features * One shared binary for bc and dc (bc is not just a pre-processor that relies on dc for the actual computations) The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have. This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release. __________________________________________________________________ Binutils Retirement Links GPL in Base wiki page=20 URL: https://wiki.freebsd.org/GPLinBase Contact: Ed Maste We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as. Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package. The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file. Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0. TODO The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8). Sponsor: The FreeBSD Foundation __________________________________________________________________ Run-Time Dynamic Linker improvements Contact: Konstantin Belousov Rtld gets some number of small bug fixes and improvements. RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc. Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary. The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact. In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation. Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all. With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them. Sponsor: The FreeBSD Foundation __________________________________________________________________ VHDX support in mkimg(1) Contact: Oleksandr Tymoshenko VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures. VHDX is the required format for 2nd generation Hyper-V VMs. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Bastille Links Bastille GitHub =20 URL: https://github.com/bastillebsd/bastille Bastille Templates=20 URL: https://gitlab.com/bastillebsd-templates Bastille Website =20 URL: https://bastillebsd.org Contact: Christer Edwards Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD. Bastille Templates automate container setup allowing you to easily reproduce containers as needed. Bastille is available in ports at sysutils/bastille. Q2 2020 Status In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include: * experimental support for new Bastillefile template syntax * added mount and umount sub-commands * added a default Vagrantfile for simple testing * experimental support for empty containers * improvements to VNET DHCP support * cosmetic bugfixes in error output * extended config file documentation * updated bastille help output * option to (-f) force destroy container sysutils/bastille was updated to 0.6.20200414 (latest). New Bastille templates added this quarter include: * Percona database server * Asterisk SIP server * dnsmasq DNS/DHCP server (VNET required) * nginx pkg server for poudriere Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine. This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team: * Restored a patch that closes down a remote TCP held by X11 applications that use the ICE library. Thanks to Colin Percival for reporting it. It went missing in one of the port updates. To prevent this in the future, the patch has been upstreamed. PR 229772. * Chased KDE-adjacent software like CMake, Cutelyst, Latte-dock and Nheko through new releases. In particular CMake takes a lot of effort every time because it is a build-time dependency of over 2000 ports. * graphics/poppler was updated to the latest upstream release. This is a low-level dependency for many document-viewing applications, and like CMake requires chasing a lot of other software. Poppler is one of the components shared between various software stacks (and "desktop environments") under the desktop@ group, in which kde@ participates. * KDE Frameworks release like clockwork, reaching KDE Frameworks 5.70 mid-may. * KDE Applications -- the KDE release service, really, which delivers libraries, applications, and add-ons -- had one large release, with 20.04.1 landing in the ports tree also mid-may and its monthly update 20.04.2 in mid-june. * Some new Wayland support for KDE Plasma -- we have not tested this on FreeBSD -- has appeared and has been duly packaged. * A great deal of preparation has gone into Qt 5.15. Many ports have been pre-emptively patched for this new -- and last -- LTS release of Qt 5. The update itself has not yet landed, pending a few last bits of fallout. The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine. The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71. __________________________________________________________________ Haskell on FreeBSD Links Haskell language homepage=20 URL: http://www.haskell.org/ Ports development repo =20 URL: https://github.com/freebsd/freebsd-ports-haskell Contact: Gleb Popov Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language. This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too. All existing ports of Haskell applications were migrated to USES=3Dcabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed. Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome. __________________________________________________________________ rtsx - Porting driver for Realtek SD card reader from OpenBSD Links rtsx =20 URL: https://github.com/hlh-restart/rtsx PR204521=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204521 Contact: Henri Hennebert The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port. From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart. The driver has been successfully tested with: * RTS5209 under head (Lenovo ThinkPad L520) * RTS5227 under stable/11 and releng/12.1 (HP ProBook 430 g2, Lenovo ThinkPad T450/T450s) * RTS5229 under releng/12.1 (Lenovo IdeaPad 120S-14IAP) * RTS522A under releng/12.1 and head (Intel NUC8i5BE, Lenovo ThinkPad P50s) * RTS525A under releng/12.1 (Dell Latitude E5570) * RTL8411B under stable/12 (Acer Aspire E 15 E5-576-77W6) The driver should also work for Realtek RTS5249, RTL8402 and RTL8411. More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks. PR204521 contains the bulk of exchanges for completion of the code. __________________________________________________________________ Valgrind updates Links Patch for valgrind=20 URL: https://reviews.freebsd.org/D25452 Contact: Paul Floyd Contact: Kyle Evans A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind. The devel/valgrind-devel port is in the process of being updated to point at the new work. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki=20 URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance=20 URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR). We are looking forward to receive more languages and translators to the project as well. Q2 2020 Status * 10 languages (No new languages) * 80 registered users (33 new users since last quarter) Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) * French (fr_FR) * German (de_DE) * Italian (it_IT) * Norwegian (nb_NO) * Persian (fa_IR) * Portuguese (pt_BR) * Spanish (es_ES) * Turkish (tr-TR) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ Miscellaneous Objects that defy categorization. FreshPorts Links FreshPorts =20 URL: http://freshports.org/ FreshPorts blog=20 URL: http://news.freshports.org/ Contact: Dan Langille FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports. FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017. git Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website. Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort. The next step include: * incorporate a that script the automated processes of FreshPorts * migrate to new test & stage versions of FreshPorts * test * get ready for prod Help wanted git is not far away now. I could use helpers to * review code * watch the commits on the devgit websites * catch missing stuff Thank you Packages FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built. Dependency lines Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: acme.sh>0:security/acme.sh Libraries are also covered by this feature. Python ports were recently adjusted to display ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv instead of py37-virtualenv>0:devel/py-virtualenv You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73). Watch ports I maintain The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain. This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report. From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change. Repology links Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page. Further reading Based upon things you didn't know FreshPorts can do There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post: * provides example dependency line. e.g. p5-XML-RSS>0:textproc/p5-XML-RSS * list of dependencies for a port * list of ports depending upon this port * see default configuration options * what packages install a given file (e.g. bin/unzip) * find out what ports a person maintains * find Makefiles which contain references to bunzip * search results can be plain-text consisting of a list of foo/bar ports * the Maximum Effort checkbox on the search page does nothing * committers can be notified of sanity test failures after the commit * find a commit, any commit, based on SVN revision number, e.g. : https://www.freshports.org/commit.php?revision=3D352332 Javascript help wanted We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key. Sponsor: hardware provided by iXsystems __________________________________________________________________ PCI passthrough with bhyve on Intel and for OpenBSD guests Links bhyve Intel bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229852 bhyve OpenBSD bug report=20 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245392 PCI passthrough with bhyve (FreeBSD wiki article)=20 URL: https://wiki.freebsd.org/bhyve/pci_passthru Contact: Anatoli Contact: Callum Contact: Peter Grehan bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use. For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors. The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host. During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version. The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link). A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server. With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host. Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware). In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways. __________________________________________________________________ SageMath Links SageMath site=20 URL: https://www.sagemath.org/ Contact: Thierry Thomas SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers. The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab. This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages. If you are interested, it would be nice to create a team of maintainers * to maintain some of the dependencies; * to maintain SageMath itself and prepare the next release (9.2 is coming!). __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. chaifi - a tool to simplify joining public WiFi networks Links chaifi=20 URL: https://github.com/gonzoua/chaifi Contact: Oleksandr Tymoshenko chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time. __________________________________________________________________ MixerTUI Links mixertui=20 URL: https://gitlab.com/alfix/mixertui Contact: Alfonso Sabato Siciliano MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on. MixerTUI can be installed via the audio/mixertui port. I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project. __________________________________________________________________ Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: Stephan Lichtenauer pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer. Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided. The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes. As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome! __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =A9 1995-2020 The FreeBSD Project. All rights reserved. --psc724i6dgwcog6o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl8PhDNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87q0pgf+ORZtgQTDGH9iCasAtK/BAm+eFWE2eNcsZzRPMa5+Ixki4udFJYbMyYDc gxFVN5yjXtHZchSAM77IARAKCQqrNylokXcy7mFpqLWJybIdmUaXpdoMgawQq78e sUuB/trl/DOBXHCZxx9RiN5r0QZ0Rx0UtE/Gg0b0GNylYC7ul0JDrZPJVmH0IvkZ fD9KcBeo3S/uPzfb/6QsDzYbZkv7hHXcxTTgXwKk7lfwDT+2CoDN34AgrJz/JZSx 3yxHClupkYkiq3JrgT4ySk3x+l626PpGjaccGJgHlW2fbvB7wEXikwiBApzQKQxu jBnucUx4HJBQ4Qqrynod69SJea2tYg== =Kiys -----END PGP SIGNATURE----- --psc724i6dgwcog6o-- From owner-freebsd-current@freebsd.org Thu Jul 16 16:48:30 2020 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 5DEB1366FA3 for ; Thu, 16 Jul 2020 16:48:30 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B70Z615XRz3X2s; Thu, 16 Jul 2020 16:48:29 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:dd8e:c67c:526f:23e8] (unknown [IPv6:2a02:8109:1140:c3d:dd8e:c67c:526f:23e8]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7AA297220CCF5; Thu, 16 Jul 2020 18:48:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: ? ????? ??: vnc can't connect to socket From: Michael Tuexen In-Reply-To: <3E06883E-BAB1-4E1A-AB20-06DD1F812057@freebsd.org> Date: Thu, 16 Jul 2020 18:48:24 +0200 Cc: Ian Lepore , "bergerkos@yahoo.co.uk" , "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9D2DC5CD-5003-4142-A0AA-B2F8B354C488@freebsd.org> References: <202006212112.05LLCKQR006977@gndrsh.dnsmgr.net> <3E06883E-BAB1-4E1A-AB20-06DD1F812057@freebsd.org> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4B70Z615XRz3X2s X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 16 Jul 2020 16:48:30 -0000 > On 22. Jun 2020, at 15:55, Michael Tuexen wrote: >=20 >> On 21. Jun 2020, at 23:12, Rodney W. Grimes = wrote: >>=20 >>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote: >>>>>> On 21. Jun 2020, at 14:28, Kostya Berger >>>>>> wrote: >>>>>>=20 >>>>>> Ok, it turns out, it gives the previously mentioned error only if = I >>>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC >>>>>> client.But when replaced with127.0.0.1:5900it connects all right. >>>>>=20 >>>>> I don't hink 0.0.0.0 is a valid destination address you can use in >>>>> connect(). Using 127.0.0.1 should >>>>> be fine. >>>=20 >>> I do not believe that this is a destination address when your = talking >>> about 0.0.0.0:5900 on the VNC server side, that is a wild card = accept >>> any address and if this has been broken.. it must be fixed! >>>=20 >>>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the >>>>> relevant commit here. >>>>>=20 >>>>=20 >>>> *BSD has always accepted 0 as a synonym for localhost (and iirc, = linux >>>> does not). If this no longer works, it's a regression which is = going >>>> to cause existing applications and scripts to fail. At the very = least >>>> it deserves an entry in UPDATING. >>>=20 >>> I am not aware of that, but can not deny it either, and just = confirmed >>> it to be true: >>> root {1002}# telnet 0.0.0.0 22 >>> Trying 0.0.0.0... >>> Connected to 0.0.0.0. >>> Escape character is '^]'. >>> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909 >>=20 >> And to add the netstat data to show what connected: >> tcp4 0 0 127.0.0.1.22 127.0.0.1.43135 = ESTABLISHED >> tcp4 38 0 127.0.0.1.43135 127.0.0.1.22 = ESTABLISHED >>=20 >> Can we back this commit out, discuss it in next weeks call, >> and then find a way forward? >>=20 >>>=20 >>> INADDR_ANY is the wildcard listen address, but as a destination what = code remapped >>> it to 127.0.0.1? >>>=20 >>> We should very seriously consider restoring this behavior. > Reallowing 0.0.0.0 is covered by https://reviews.freebsd.org/D25401 Fixed in https://svnweb.freebsd.org/changeset/base/363256 Best regards Michael >=20 > Best regards > Michael >>>=20 >>>> -- Ian >>>>=20 >>>>> Best regards >>>>> Michael >>>>>> ?????????? ?? Yahoo ????? ??? Android=20 >>>>>>=20 >>>>>> ??, 21 ???. 2020 ? 9:40 Kostya Berger >>>>>> ???????(-?): Hi,upgraded to 362292 via buildworld.Now I cannot >>>>>> connect to my bhyve guest as I used to: neither via VNC nor via >>>>>> RDP.VNC gets error: unable to connect the socket. Address family >>>>>> not supported by protocol family (47). >>>>>> Neither can I ping my bhyve IP (it uses a separate NIC and should >>>>>> have no problems) >>>>>> Internet connectivity is ok and I can ping other hosts on my >>>>>> network. >>>>>> In 359997 all works fine. >>>>>> ?????????? ?? Yahoo ????? ??? Android =20 >>>>>> _______________________________________________ >>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>>>=20 >>>> _______________________________________________ >>>> 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 >>>>=20 >>>=20 >>> --=20 >>> Rod Grimes = rgrimes@freebsd.org >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>>=20 >>=20 >> --=20 >> Rod Grimes = rgrimes@freebsd.org >=20 > _______________________________________________ > 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 Jul 16 22:17:04 2020 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 3754236F0C1; Thu, 16 Jul 2020 22:17:04 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 4B77sB5bF4z49F1; Thu, 16 Jul 2020 22:17:02 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-lj1-x241.google.com with SMTP id r19so10099019ljn.12; Thu, 16 Jul 2020 15:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=6UCbe2Qv1tYdbIEymS9JZBAgOpOkcD4XvuzG0sNPDw4=; b=Sq/2swDKbUiTfRHf8jYDY9SCwNM7gvQLuotoRrL1L9ir9GTCqZq6a6Ee+k/hvVWVUa cq0EizZRyVfxxImYaMcZ4+8W9ovOSUdY154tx95pdKLRahB7eWzTEy0Ui6wVVuqwonJu zaOrw8MUrbNsJA/1DGaxn8nSdHh/Pl5tiWGqiSbMlDPtLsF294IDiW8juN3xatQxYE9y kyl27KD88Cjmsju0cub8+dlQl29oq+XNgOYNmTLiPuhBa9qVcXY285jARR/wbP9YU+Fp kEFzC3+13AY525nfokqs0eOdxnplSbaDjDhPn8s5BbbIYPmIBnksKLnD5EonpgMjpDtP nSsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=6UCbe2Qv1tYdbIEymS9JZBAgOpOkcD4XvuzG0sNPDw4=; b=sp+q0K+YoEh6CopNsQUMffcrLpqBB/YQEeSGG7Lr9EATNQ+Fyjzn4oniX62PL4X0V8 krCXJl+KuPKUeM3HhAGPKTVAd3zEusLcPLnzmkbhlssrOReS1zsEmOfdRcw45RQjdOkS z7ZP1BVGU7Lyfu02CVWRm8ChMNDOCjwUsTgkbV7Sra54EGrrTBLRqguNUDQQjHBEvTL4 ouPGM/vO0o5thLMKpYEJa8Yz9AfVeC11Toy7jTPYricSY5X9wnqio7/JnTDg+JLn53Hf 53cvo/Lw+F+SqvyqzOxQEm85hMv13PBaVEOE3D/Hf8KxT5X++0KT22Ybn/QvdvwoUI7i SmMw== X-Gm-Message-State: AOAM532riybbL+FcqXm/i/Q4/i/adqkHSyqFLuQX4R1kqP7qXdgdCV1c Pg6FkM2EIhpeu7uUH1wqk1Q1BQEJpsA= X-Google-Smtp-Source: ABdhPJwzCfluiJGDBAvzl0wFfqNwYMC3KQPUu1MPtV8bTpuOGzzAqAgc+cxu25TIu49n3u13XyM8mQ== X-Received: by 2002:a2e:5d8:: with SMTP id 207mr2941544ljf.257.1594937820332; Thu, 16 Jul 2020 15:17:00 -0700 (PDT) Received: from [172.20.10.5] (188.147.114.226.nat.umts.dynamic.t-mobile.pl. [188.147.114.226]) by smtp.gmail.com with ESMTPSA id a16sm1541208ljj.108.2020.07.16.15.16.59 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Jul 2020 15:16:59 -0700 (PDT) From: Daniel Dettlaff Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Kernel panic on recent 12.1 on bridge creation. Message-Id: Date: Fri, 17 Jul 2020 00:16:57 +0200 To: "freebsd-current@freebsd.org" , freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Rspamd-Queue-Id: 4B77sB5bF4z49F1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Sq/2swDK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmilith@gmail.com designates 2a00:1450:4864:20::241 as permitted sender) smtp.mailfrom=dmilith@gmail.com X-Spamd-Result: default: False [-2.23 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; 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]; RECEIVED_SPAMHAUS_PBL(0.00)[188.147.114.226:received]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.25)[0.247]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::241:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 16 Jul 2020 22:17:04 -0000 Hello, I heard it's known? I built recent system from stable/12 branch and either "ifconfig bridge0 = create" and `cloned_interfaces=3D"bridge0"` + = `ifconfig_bridge0_aliases=3D"inet 172.16.7.1/16` in rc.conf.local causes = instant KP and system reboot. kind regards Daniel Dettlaff= From owner-freebsd-current@freebsd.org Thu Jul 16 22:26:32 2020 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 7CCDE36F81F; Thu, 16 Jul 2020 22:26:32 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4B784670kkz4B4N; Thu, 16 Jul 2020 22:26:30 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-lj1-x22c.google.com with SMTP id j11so10190154ljo.7; Thu, 16 Jul 2020 15:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4sK+Im7RKwbz4exWgYfIT5cAB5egEb+GATnvIvDoNO8=; b=QLhlAV37JUYwZhHJfndYYspwBCqDMDvsXyLO4Zj91bx6ZMLiWQY2dQhERQjtg7nT5y k0Zf1EIKagLqwm7USYuPM/m6YN1uoRCFGiStyTA60feQGyYl2iUHVriXIELZjoP9cNkN WQ00yfyrFnwbW8iZnnApHlC862e8q/tJHs8I3LkyLWov9ySaQgbfEcdAj1QF5znLutUU xcw5gFkUwVWZJEG2cuXZ3RzuyBDuux/XlRPWvwez8Glss3VYjEvH24T8gCr5OMQ2vWfr ZRjn0cac2OImiSqlXiXl7I3mz5bnDu2O+SzlHAgvhDMjgmNG86U/Xk0OgPaBXawIXgbV qjFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4sK+Im7RKwbz4exWgYfIT5cAB5egEb+GATnvIvDoNO8=; b=os+x2lZU0O/MV8TYmcvXEGWSyvcBWPydVEpEKVbJeNuNWBoOIH0E8CDjQMOzv0bUwA JkQ2ZD7bU0kE+7vV7Ee+DksVPCQzmevVOupmZ71QoSmoEjuQhcq2N7aOJz6fvpaLLfBG 9tc7M05ZhBx+JKTnrexdXkDqVFfIqhK9CcJb42xY3NBxJC6AwwBoWaqvMhsVQhAjDGBr X09zz61RilWg6ZWHFx2/LOeGNQaaDrRCc3i+Vc3TIwgVIHQE8C48culTPUf36ZmJm8vR efzvq7OFS4mf19BfYDmiGfBkF2RPQ9N2NGoTy8OkhyrIPgADDeaUzUZCG8Uqq+NK8OBz wNyQ== X-Gm-Message-State: AOAM532fy7eF5mqMv3mnEDcoZiiS6I73GLemDH4EgfmNsTrtiVNcxwcw lHy9vebNv8Ea2cxMG+I1yXZxe8wC03k= X-Google-Smtp-Source: ABdhPJxfwk5JzE/XiMLl8wD9v7dGY4SiwzzFoGQf6BFE2APHKupGQ79MjtanmYqT9IPBaOi6M5IIGw== X-Received: by 2002:a2e:5746:: with SMTP id r6mr3191825ljd.205.1594938387760; Thu, 16 Jul 2020 15:26:27 -0700 (PDT) Received: from [172.20.10.5] (188.147.114.226.nat.umts.dynamic.t-mobile.pl. [188.147.114.226]) by smtp.gmail.com with ESMTPSA id l5sm1291813ljh.56.2020.07.16.15.26.26 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Jul 2020 15:26:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Kernel panic on recent 12.1 on bridge creation. From: Daniel Dettlaff In-Reply-To: Date: Fri, 17 Jul 2020 00:26:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "freebsd-current@freebsd.org" , freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3124) X-Rspamd-Queue-Id: 4B784670kkz4B4N X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QLhlAV37; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmilith@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=dmilith@gmail.com X-Spamd-Result: default: False [-2.26 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; 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]; RECEIVED_SPAMHAUS_PBL(0.00)[188.147.114.226:received]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.990]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.22)[0.219]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 16 Jul 2020 22:26:32 -0000 > On 17.07.2020, at 00:16, Daniel Dettlaff wrote: >=20 > Hello, I heard it's known? >=20 > I built recent system from stable/12 branch and either "ifconfig = bridge0 create" and `cloned_interfaces=3D"bridge0"` + = `ifconfig_bridge0_aliases=3D"inet 172.16.7.1/16` in rc.conf.local causes = instant KP and system reboot. >=20 > kind regards > Daniel Dettlaff will just add screenshots from cause: = http://s.verknowsys.com/6eade44caec93c46b134ec81c8597081.png it's = production kernel build so no symbols.= From owner-freebsd-current@freebsd.org Fri Jul 17 04:06:14 2020 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 A158F375EB4 for ; Fri, 17 Jul 2020 04:06:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4B7Hc5434Lz4TJn for ; Fri, 17 Jul 2020 04:06:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: eZYAoYMVM1leB0UhfVXlG626Lk1LxH0lMLhuM3mZtBETJFLP43CoLjp5YayD0.P AiTOfDBJVsnPw4OAQCe2v21pwwQtlP8lXQKsXEp5SvhntQ.yA7NnDs5J1FFZgd416SnCi0ja.p6D MZb3Pj1__fUiJ4H7t_Uj3.WvC75IguHfQz3txs2C86YBDVGKjq8iyDlORsLG.PxLaywa6qfSDjiF GtaOzhWaCMg8dCId1c1jw6J.EdcQUK2bITeYJ.TQwVaKOHG_WyoQijO.VRI1fHvv3NIIivEqSfvl GioXqRonWIOcJHf_qZl7De6Rpjk10KSVw6WWpMsmXl5_k79LVU4svj0wz138OE1999UeSbCUBXI8 k3gvOXuMBhjevprj25bIrOvdK.IQVNNEAt8bUb9SDebaNK33Jl6DuylufwvGdDk.5gHNHAzoPLaf uHCODnQ6dOBLBo0mSefc6oEOfJiHY3WpXMvOeFVneHw29Rc8o3jqV_PJREH9N9J__H_pVxsRjl7y 3rTe9dxD2r8oKNUS.pCzXNMQsT6W78fpj3xxzctkgIaJK438cqupsBqV6vAfzOYNy8xNND95fghz ojUT4uA_Wvb3lTxm4hkNu2AZw3Rd95m8.m4iBcYYB7NLyBW_AnUN.zPyqSVWqF6phZvgXOiUQPuw e28.e8e5rYXckGiYhGfjO.n4WlYN.4MwBESsy4UCUzQslkiRiKDxWWQjvDYWpx4rxaazMuSennHM C4y9ridAdspcTokx2KtnNqD7MQCseDkQcc7M_n5mC6X.kMdvgFijMzx73nwdIu86PuJzF.SMHtA_ 695Nb63NL8kIpJL__wjxo3iuDriMtiYf.55ygY3dtkIyK38BooNZqiwlMT2z8Fa4A3ClN4UpvaMI Viri7L4sECX28LI.6vULEyaG5sRBtJSHCyhh39za7JfoB3vl0X2MxmYMDRXTZlRdVBNjEfy.zL3E vM.bP1KY9.w6wGhodxrnd_w7WTh2uvtaAesDWQnj9Le95Fmg2pXKKCL_PAppQZ_Pntt1IFuepDQo 0iuWFzeyk85xgeoctHCNowlN7GcXy6GMu6kEdQGof6Yvqieura1CDpi9ILoGrNylCWVIecUXJwvH aWGkhlG43mamH40B81JThnUAww1JCuChEywvhC78.TGsPJVZfKbymEmAGmKQz_4WPjthd5.q6jMa mh7G17op7PfvRl2FDkwjE3ADsiY99QgURmonPYVihNvYnJeO63FhFsfAM_.oLVlg2fd7MFYGbM7b ZU_ZWfS5_It7IM2T2opow8vlZZyrMN1AyY4o9SjwW7ylej911445fZf7_Wp47XJr.w133QtsDUD_ C3STJ3cl.OjuZB_hVtunyOESnJwX6wDLVB9oILgVTKaTp7wL8MMKT8Kj0mvwiNPUKNqTYRujTxtx cQufyVkp.HZjc3N3e4q2aTotj3yePAn4EpNite3S4BmBTXcp1zZwvvQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Jul 2020 04:06:11 +0000 Received: by smtp427.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 685a4ec50c3437fffe312779386b99f9; Fri, 17 Jul 2020 04:06:10 +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 13.4 \(3608.80.23.2.2\)) Subject: Pine64+2GB unable to boot after attempted update, failure very early: efipart_readwrite: rw=1,  blk=... size=32 status=7; RPi3 has no problem Message-Id: Date: Thu, 16 Jul 2020 21:06:09 -0700 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 4B7Hc5434Lz4TJn X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.24 / 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.79)[-0.785]; 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:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-0.97)[-0.970]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_NEEDS_ENCODING(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Jul 2020 04:06:14 -0000 Note: The media involved (microsd card and USB SSD) is also configured to boot a RPi3B and that is still working when plugged into the RPi3B. This should have the implication that EFI/BOOT/bootaa64.efi is okay for how the RPi3B ends up using it, for example. The failed boot attempts look like the below (but I've removed a bunch of "[?25h" for readability). I do not remember if "alloc space exhausted" is normal or not. U-Boot SPL 2020.07 (Jul 13 2020 - 12:12:14 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.3(): NOTICE: BL31: Built : 23:56:54, Apr 26 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4092b68, model: Pine64+ NOTICE: PSCI: System suspend is unavailable alloc space exhausted U-Boot 2020.07 (Jul 13 2020 - 12:12:14 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1b400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1b000 for devices... 3 USB Device(s) found scanning bus usb@1c1b400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 38612 bytes read in 4 ms (9.2 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi Scanning disk mmc@1c0f000.blk... ** Unrecognized filesystem type ** Scanning disk usb_mass_storage.lun0... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Found 7 disks =1B7=1B[r=1B[999;999H=1B[6n=1B8BootOrder not defined EFI boot manager: Cannot load any image 695648 bytes read in 33 ms (20.1 MiB/s) =1B[2J=1B[1;1H=1B[2J=1B[1;1H=1BC=1Bo=1Bn=1Bs=1Bo=1Bl=1Be=1Bs=1B:=1B = =1BE=1BF=1BI=1B =1Bc=1Bo=1Bn=1Bs=1Bo=1Bl=1Be=1B =1B =1B =1B =1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\= =1B=08=1B|=1B=08=1B =1B =1B =1B =1BR=1Be=1Ba=1Bd=1Bi=1Bn=1Bg=1B = =1Bl=1Bo=1Ba=1Bd=1Be=1Br=1B =1Be=1Bn=1Bv=1B =1Bv=1Ba=1Br=1Bs=1B = =1Bf=1Br=1Bo=1Bm=1B =1B/=1Be=1Bf=1Bi=1B/=1Bf=1Br=1Be=1Be=1Bb=1Bs=1Bd=1B/=1B= l=1Bo=1Ba=1Bd=1Be=1Br=1B.=1Be=1Bn=1Bv=1B =1B =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B =1B =1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1BF=1Br=1Be=1B= e=1BB=1BS=1BD=1B/=1Ba=1Br=1Bm=1B6=1B4=1B =1BE=1BF=1BI=1B =1Bl=1Bo=1Ba=1Bd=1B= e=1Br=1B,=1B =1BR=1Be=1Bv=1Bi=1Bs=1Bi=1Bo=1Bn=1B =1B1=1B.=1B1=1B =1B =1B =1B =1B =1B =1B =1BC=1Bo=1Bm=1Bm=1Ba=1Bn=1Bd=1B =1Bl=1Bi=1Bn=1Be=1B = =1Ba=1Br=1Bg=1Bu=1Bm=1Be=1Bn=1Bt=1Bs=1B:=1B =1Bl=1Bo=1Ba=1Bd=1Be=1Br=1B.=1B= e=1Bf=1Bi=1B =1B =1B =1B =1B =1BI=1Bm=1Ba=1Bg=1Be=1B =1Bb=1Ba=1Bs=1Be=1B:=1B = =1B0=1Bx=1Bb=1B8=1Be=1B6=1B3=1B0=1B0=1B0=1B =1B =1B =1B =1B =1BE=1BF=1BI=1B =1Bv=1Be=1Br=1Bs=1Bi=1Bo=1Bn=1B:=1B = =1B2=1B.=1B8=1B0=1B =1B =1B =1B =1B =1BE=1BF=1BI=1B =1BF=1Bi=1Br=1Bm=1Bw=1Ba=1Br=1Be=1B:=1B = =1BD=1Ba=1Bs=1B =1BU=1B-=1BB=1Bo=1Bo=1Bt=1B =1B(=1Br=1Be=1Bv=1B = =1B8=1B2=1B2=1B4=1B.=1B1=1B7=1B9=1B2=1B)=1B =1B =1B =1B =1B =1BC=1Bo=1Bn=1Bs=1Bo=1Bl=1Be=1B:=1B =1Bc=1Bo=1Bm=1Bc=1Bo=1Bn=1B= s=1Bo=1Bl=1Be=1B =1B(=1B0=1B)=1B =1B =1B =1B =1B =1BL=1Bo=1Ba=1Bd=1B =1BP=1Ba=1Bt=1Bh=1B:=1B = =1B/=1Be=1Bf=1Bi=1B\=1Bb=1Bo=1Bo=1Bt=1B\=1Bb=1Bo=1Bo=1Bt=1Ba=1Ba=1B6=1B4=1B= .=1Be=1Bf=1Bi=1B =1B =1B =1B =1B =1BL=1Bo=1Ba=1Bd=1B =1BD=1Be=1Bv=1Bi=1Bc=1Be=1B:=1B = =1B/=1BV=1Be=1Bn=1BH=1Bw=1B(=1Be=1B6=1B1=1Bd=1B7=1B3=1Bb=1B9=1B-=1Ba=1B3=1B= 8=1B4=1B-=1B4=1Ba=1Bc=1Bc=1B-=1Ba=1Be=1Ba=1Bb=1B-=1B8=1B2=1Be=1B8=1B2=1B8=1B= f=1B3=1B6=1B2=1B8=1Bb=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B= /=1BH=1BD=1B(=1B1=1B,=1B0=1Bx=1B0=1B1=1B,=1B0=1B,=1B0=1Bx=1B4=1B0=1B3=1Bb=1B= ,=1B0=1Bx=1B1=1Bf=1Bf=1Be=1B0=1B)=1B =1B =1BT=1Br=1By=1Bi=1Bn=1Bg=1B =1BE=1BS=1BP=1B:=1B = =1B/=1BV=1Be=1Bn=1BH=1Bw=1B(=1Be=1B6=1B1=1Bd=1B7=1B3=1Bb=1B9=1B-=1Ba=1B3=1B= 8=1B4=1B-=1B4=1Ba=1Bc=1Bc=1B-=1Ba=1Be=1Ba=1Bb=1B-=1B8=1B2=1Be=1B8=1B2=1B8=1B= f=1B3=1B6=1B2=1B8=1Bb=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B= /=1BH=1BD=1B(=1B1=1B,=1B0=1Bx=1B0=1B1=1B,=1B0=1B,=1B0=1Bx=1B4=1B0=1B3=1Bb=1B= ,=1B0=1Bx=1B1=1Bf=1Bf=1Be=1B0=1B)=1B =1B =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B1=1B:=1B =1B =1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-= =1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1BT=1Br=1By=1Bi=1Bn=1Bg=1B:= =1B = =1B/=1BV=1Be=1Bn=1BH=1Bw=1B(=1Be=1B6=1B1=1Bd=1B7=1B3=1Bb=1B9=1B-=1Ba=1B3=1B= 8=1B4=1B-=1B4=1Ba=1Bc=1Bc=1B-=1Ba=1Be=1Ba=1Bb=1B-=1B8=1B2=1Be=1B8=1B2=1B8=1B= f=1B3=1B6=1B2=1B8=1Bb=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B/=1BS=1BD=1B(=1B0=1B)=1B= /=1BH=1BD=1B(=1B2=1B,=1B0=1Bx=1B0=1B1=1B,=1B0=1B,=1B0=1Bx=1B2=1B4=1B4=1B0=1B= 0=1B,=1B0=1Bx=1Be=1B6=1B0=1B0=1B0=1B0=1B0=1B)=1B =1B =1BS=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B= =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B:=1B =1B =1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1Be=1Bf=1Bi=1B= p=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt=1Be=1B:=1B =1Br=1Bw=1B=3D= =1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B2=1B3=1B2=1B4=1B4=1B2=1B2=1B4=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B7=1B =1B =1B/=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B6=1B= 0=1B8=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1B-=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B= 4=1B5=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt=1Be=1B:=1B= =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B4=1B5=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B7=1B =1B =1B\=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B6=1B= 0=1B8=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1B|=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B= 4=1B5=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt=1Be=1B:=1B= =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B4=1B5=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B7=1B =1B =1B/=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B6=1B= 0=1B8=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1B-=1B=08=1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt= =1Be=1B:=1B =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B= 4=1B5=1B =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B= 7=1B =1B =1Be=1Bf=1Bi=1Bp=1Ba=1Br=1Bt=1B_=1Br=1Be=1Ba=1Bd=1Bw=1Br=1Bi=1Bt=1Be=1B:=1B= =1Br=1Bw=1B=3D=1B1=1B,=1B =1Bb=1Bl=1Bk=1B=3D=1B1=1B4=1B8=1B5=1B4=1B5=1B = =1Bs=1Bi=1Bz=1Be=1B=3D=1B3=1B2=1B =1Bs=1Bt=1Ba=1Bt=1Bu=1Bs=1B=3D=1B7=1B =1B =1BE=1BR=1BR=1BO=1BR=1B:=1B =1Bc=1Ba=1Bn=1Bn=1Bo=1Bt=1B =1Bo=1Bp=1Be=1Bn=1B= =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bl=1Bu=1Ba=1B/=1Bl=1Bo=1Ba=1Bd=1Be=1Br=1B.=1Bl=1B= u=1Ba=1B:=1B =1Bn=1Bo=1B =1Bs=1Bu=1Bc=1Bh=1B =1Bf=1Bi=1Bl=1Be=1B =1Bo=1Br=1B= =1Bd=1Bi=1Br=1Be=1Bc=1Bt=1Bo=1Br=1By=1B.=1B =1B =1B =1B =1B =1B =1BT=1By=1Bp=1Be=1B =1B'=1B?=1B'=1B =1Bf=1Bo=1Br=1B =1Ba=1B =1Bl=1Bi=1Bs=1B= t=1B =1Bo=1Bf=1B =1Bc=1Bo=1Bm=1Bm=1Ba=1Bn=1Bd=1Bs=1B,=1B =1B'=1Bh=1Be=1Bl=1B= p=1B'=1B =1Bf=1Bo=1Br=1B =1Bm=1Bo=1Br=1Be=1B =1Bd=1Be=1Bt=1Ba=1Bi=1Bl=1Be=1B= d=1B =1Bh=1Be=1Bl=1Bp=1B.=1B =1B =1BO=1BK=1B =1B By contrast the RPi3 has no trouble with using d=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B: (it is the same media) . . . S=1Be=1Bt=1Bt=1Bi=1Bn=1Bg=1B =1Bc=1Bu=1Br=1Br=1Bd=1Be=1Bv=1B =1Bt=1Bo=1B = =1Bd=1Bi=1Bs=1Bk=1B0=1Bp=1B2=1B:=1B =1B = =1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-= =1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08= =1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/= =1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08= =1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|= =1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08= =1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\= =1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08= =1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-= =1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08= =1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/= =1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08= =1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1BL=1Bo=1Ba=1Bd=1Bi=1Bn=1Bg=1B = =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bd=1Be=1Bf=1Ba=1Bu=1Bl=1Bt=1Bs=1B/=1Bl=1Bo=1Ba=1B= d=1Be=1Br=1B.=1Bc=1Bo=1Bn=1Bf=1B /=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1BL=1B= o=1Ba=1Bd=1Bi=1Bn=1Bg=1B = =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bd=1Be=1Bf=1Ba=1Bu=1Bl=1Bt=1Bs=1B/=1Bl=1Bo=1Ba=1B= d=1Be=1Br=1B.=1Bc=1Bo=1Bn=1Bf=1B =1B =1BL=1Bo=1Ba=1Bd=1Bi=1Bn=1Bg=1B =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bd=1Be=1Bv=1Bi=1B= c=1Be=1B.=1Bh=1Bi=1Bn=1Bt=1Bs=1B =1B =1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\= =1B=08=1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1BL=1Bo=1Ba=1Bd=1Bi=1Bn=1Bg= =1B =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bl=1Bo=1Ba=1Bd=1Be=1Br=1B.=1Bc=1Bo=1Bn=1Bf=1B= =1B =1B|=1B=08=1B/=1B=08=1B-=1B=08=1B\=1B=08=1BL=1Bo=1Ba=1Bd=1Bi=1Bn=1Bg=1B = =1B/=1Bb=1Bo=1Bo=1Bt=1B/=1Bl=1Bo=1Ba=1Bd=1Be=1Br=1B.=1Bc=1Bo=1Bn=1Bf=1B.=1B= l=1Bo=1Bc=1Ba=1Bl=1B (And so on.) For reference: # gpart show -p =3D> 63 249737153 mmcsd0 MBR (119G) 63 16380 - free - (8.0M) 16443 131040 mmcsd0s1 fat32lba [active] (64M) 147483 997 - free - (499K) 148480 241172480 mmcsd0s2 freebsd (115G) 241320960 8416256 - free - (4.0G) =3D> 0 241172480 mmcsd0s2 BSD (115G) 0 230686720 mmcsd0s2a freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) =3D> 40 468862048 da0 GPT (224G) 40 2008 - free - (1.0M) 2048 413138944 da0p1 freebsd-ufs (197G) 413140992 6291456 da0p2 freebsd-swap (3.0G) 419432448 6291456 da0p4 freebsd-swap (3.0G) 425723904 43138184 - free - (21G) # find /boot/efi/ -print | sort | more /boot/efi/ /boot/efi/COPYING.linux /boot/efi/EFI /boot/efi/EFI/BOOT /boot/efi/EFI/BOOT/bootaa64.efi /boot/efi/LICENCE.broadcom /boot/efi/System Volume Information /boot/efi/System Volume Information/WPSettings.dat /boot/efi/armstub8.bin /boot/efi/bcm2710-rpi-2-b.dtb /boot/efi/bcm2710-rpi-3-b-plus.dtb /boot/efi/bcm2710-rpi-3-b.dtb /boot/efi/bcm2710-rpi-cm3.dtb /boot/efi/bootcode.bin /boot/efi/config.txt /boot/efi/dtb /boot/efi/dtb/allwinner /boot/efi/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/efi/dtb/allwinner/sun50i-a64-pine64-plus.dtb /boot/efi/dtb/allwinner/sun50i-a64-pine64.dtb /boot/efi/dtb/allwinner/sun50i-a64-pinebook.dtb /boot/efi/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb /boot/efi/dtb/overlays /boot/efi/dtb/overlays/spigen-rpi3.dtbo /boot/efi/dtb/overlays/sun50i-a64-opp.dtbo /boot/efi/dtb/overlays/sun50i-a64-pwm.dtbo /boot/efi/dtb/overlays/sun50i-a64-rpwm.dtbo /boot/efi/dtb/overlays/sun50i-a64-spi0-spigen.dtbo /boot/efi/dtb/overlays/sun50i-a64-timer.dtbo /boot/efi/fixup.dat /boot/efi/overlays /boot/efi/overlays/disable-bt.dtbo /boot/efi/overlays/mmc.dtbo /boot/efi/overlays/pwm.dtbo /boot/efi/start.elf /boot/efi/u-boot.bin (Where /boot/efi refers to /dev/mmcsd0s1 .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 17 06:16:00 2020 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 2C68435942B for ; Fri, 17 Jul 2020 06:16:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4B7LTp4LTnz4Zjd for ; Fri, 17 Jul 2020 06:15:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oZ35AlEVM1lgF.Iy1mVlr4rRTamQR.oh6q8iYH7hwBMZPkPr7cxXYKFzqOpcQ5Y 40cSlw5Mg0Eve6JWGtTwarsuo2GbcMAIkklme1YGP70mkG1VO5_HcSGX9dHlO8Ryew38E4Sqw8Uq VOvx8GFFUXz5emFrSXnd3AvU7l1L_YzhCO8R8JVlj7dj4hzf4CZ7G57Fiizd69K5zX.YeTkLAahG ub4lygEPN7n.D0KqBAyp22SNbqV96JYr4oBX2KlvrmNl.hie8WpYNIbH5ePWoERuwiRy1UByQa.4 .Z9z4G0tZC9ddGRcf8hjModPWuXlrcdNWgEG9rTceKdlr4j2_5CMOBla6an.U_JzeT2MRRMdY8j9 BudPgqhVZOjR3vzfoP._vPMY5N68mT9q6Q.mpEwAj_WTm2d5B_lwojBu4LkqxQLREbmi.6U0mtYx I8nkNItMM5ZEeLebWAIPgJ8ZBGmUzwjpG__CrVK4i0yM8nidIQxI06HQkbqfFL46sTf0O2uRYWHz 5ma3rYLx1rRW.Hx1gmrIFhAkZHJmWvD5a388ChGdAVcD_megYROt.jb_rG05KqX62.T3yNN80UO3 AYaP_SwpstQ6thR88zVBBCS82miR118_EdJhjUHOjsLmYGO4acfW2nZlll8bMt3XG_nOAIzV.O5l 3udest4IxWeYl2OzQB9j2abHgKN9dz4GdEC7I69D.8RbV8jaxEqqPA9ArZGA5wUJ3ly7_a7giLRb F9dxcwZd_YwL45yvBJm_OqwQjS_fGKK.hdsxIwsNZxVhk7VCw0OqtInZMUWvYjHUkPIQxLPHRpgg u3gz4k9DfNOm.BsU0ZYxhyJAMQWgwfdMrNbapG93n8_gYbP83GmQj_qptSGISKrnRRluhYTULzo. X1RTBDKR8mSnGgLxrfkfg4meBMkEJjcChxDK9cczY82lUtlB5v1v5dCHlfUcvmn2MfLVeLyAg59k 4zAv2c.SGV51hZnUx2icWQsSTkEMhfSMTN04HiL22PZq53NVN.V.dlCKyvOYM.BpP99SO6hVvA1a vRQEoXShBBVWlTrgn34_LQRRCdUJ0C.BVpWRgXEQl9DGB_TRuQ9KAjWnqWCKxEOLoPwquKuPHa.m XB0SkY50NXPI8895qTH0_2bTSwDpUckrRAEnJiGC5Tqdmqc7Y7LO8MovBA3y7iS091LR8cDiffST rCD.IHRk.qn4hsKwH0zvH4BQ6VyekV1ks2fgmW79800f1K4g08yESGBItn1eB2CPAlqgnPp0t8MN 10.huHaSy9aEoSRbSz8wpKemjx4RWCYc0vewpJiCVN42U4.h.APm1eS3nbghCSqjimCBThaCcwKE 7.n1DNdKeDZOdJuF6J1IW0_.GOtYmQ.WfmTGVzIKzEnN0mTILZfCj2ItFba.lGFkLAEaK.Sx7WJZ P9RdFJJyPJ65YMEEAIMNlLnUsFEf198QT9hltyt3nllpDxn4IXn0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Jul 2020 06:15:56 +0000 Received: by smtp416.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7d20795d1ff956f6b3da00661341e5f9; Fri, 17 Jul 2020 06:15:52 +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 13.4 \(3608.80.23.2.2\)) Subject: Re: Pine64+2GB unable to boot after attempted update, failure very early: efipart_readwrite: rw=1, blk=... size=32 status=7; RPi3 has no problem Date: Thu, 16 Jul 2020 23:15:50 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B7LTp4LTnz4Zjd X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.96 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.97)[-0.975]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; NEURAL_HAM_SHORT(-0.50)[-0.498]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Jul 2020 06:16:00 -0000 [Trying again: I missed removing a type of character (escape) beyond the [?25h removals. My choice of editor was not the best for the context and it was not obvious that the escapes were present.] I'll mostly just send the text that has the additional removals. The boot text with the error messages then is: U-Boot SPL 2020.07 (Jul 13 2020 - 12:12:14 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.3(): NOTICE: BL31: Built : 23:56:54, Apr 26 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4092b68, model: Pine64+ NOTICE: PSCI: System suspend is unavailable alloc space exhausted U-Boot 2020.07 (Jul 13 2020 - 12:12:14 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default = environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1b400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1b000 for devices... 3 USB Device(s) found scanning bus usb@1c1b400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 38612 bytes read in 4 ms (9.2 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi Scanning disk mmc@1c0f000.blk... ** Unrecognized filesystem type ** Scanning disk usb_mass_storage.lun0... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Found 7 disks 7[r[999;999H[6n8BootOrder not defined EFI boot manager: Cannot load any image 695648 bytes read in 33 ms (20.1 MiB/s) [2J[1;1H[2J[1;1HConsoles: EFI console =20 |/-\|/-\| Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: /-\|/-FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0xb8e63000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.1792) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403= b,0x1ffe0) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403= b,0x1ffe0) Setting currdev to disk0p1: \|/-\|/-\|/-Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x244= 00,0xe600000) Setting currdev to disk0p2: \|/-\|efipart_readwrite: rw=3D1, blk=3D123244224 size=3D32 status=3D7 /efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 -efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 \efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 |efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 /efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 -efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 ERROR: cannot open /boot/lua/loader.lua: no such file or directory. Type '?' for a list of commands, 'help' for more detailed help. OK=20 The contrasting RPi3B text near the area with first errors above: \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x244= 00,0xe600000) Setting currdev to disk0p2: = \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Lo= ading /boot/defaults/loader.conf /=08-=08\=08|=08/=08-=08\=08Loading /boot/defaults/loader.conf Loading /boot/device.hints |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08Loading = /boot/loader.conf |=08/=08-=08\=08Loading /boot/loader.conf.local (I'll not list more.) For reference: # gpart show -p =3D> 63 249737153 mmcsd0 MBR (119G) 63 16380 - free - (8.0M) 16443 131040 mmcsd0s1 fat32lba [active] (64M) 147483 997 - free - (499K) 148480 241172480 mmcsd0s2 freebsd (115G) 241320960 8416256 - free - (4.0G) =3D> 0 241172480 mmcsd0s2 BSD (115G) 0 230686720 mmcsd0s2a freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) =3D> 40 468862048 da0 GPT (224G) 40 2008 - free - (1.0M) 2048 413138944 da0p1 freebsd-ufs (197G) 413140992 6291456 da0p2 freebsd-swap (3.0G) 419432448 6291456 da0p4 freebsd-swap (3.0G) 425723904 43138184 - free - (21G) # find /boot/efi/ -print | sort | more /boot/efi/ /boot/efi/COPYING.linux /boot/efi/EFI /boot/efi/EFI/BOOT /boot/efi/EFI/BOOT/bootaa64.efi /boot/efi/LICENCE.broadcom /boot/efi/System Volume Information /boot/efi/System Volume Information/WPSettings.dat /boot/efi/armstub8.bin /boot/efi/bcm2710-rpi-2-b.dtb /boot/efi/bcm2710-rpi-3-b-plus.dtb /boot/efi/bcm2710-rpi-3-b.dtb /boot/efi/bcm2710-rpi-cm3.dtb /boot/efi/bootcode.bin /boot/efi/config.txt /boot/efi/dtb /boot/efi/dtb/allwinner /boot/efi/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/efi/dtb/allwinner/sun50i-a64-pine64-plus.dtb /boot/efi/dtb/allwinner/sun50i-a64-pine64.dtb /boot/efi/dtb/allwinner/sun50i-a64-pinebook.dtb /boot/efi/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb /boot/efi/dtb/overlays /boot/efi/dtb/overlays/spigen-rpi3.dtbo /boot/efi/dtb/overlays/sun50i-a64-opp.dtbo /boot/efi/dtb/overlays/sun50i-a64-pwm.dtbo /boot/efi/dtb/overlays/sun50i-a64-rpwm.dtbo /boot/efi/dtb/overlays/sun50i-a64-spi0-spigen.dtbo /boot/efi/dtb/overlays/sun50i-a64-timer.dtbo /boot/efi/fixup.dat /boot/efi/overlays /boot/efi/overlays/disable-bt.dtbo /boot/efi/overlays/mmc.dtbo /boot/efi/overlays/pwm.dtbo /boot/efi/start.elf /boot/efi/u-boot.bin (Where /boot/efi refers to /dev/mmcsd0s1 .) I forgot to indicate: that the context is based on head -r363123 FreeBSD and -r542111 ports. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Jul 17 11:37:26 2020 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 5C18236215F for ; Fri, 17 Jul 2020 11:37:26 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 4B7Tcj2MJ1z3xwP for ; Fri, 17 Jul 2020 11:37:25 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: by mail-ej1-x632.google.com with SMTP id br7so10377464ejb.5 for ; Fri, 17 Jul 2020 04:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2320AfWsVY/1NucEpezn+2MWEYHichvn6AubTjbfSDc=; b=BjvatSzNJW7jsoYjdfKknIsEAJxSp84HIzuBSBxfE9aF+hAIYpQQE2dOyvLCSD3Q0M dPDY1avjYAPF/tY9aft7kj5WzPSVCPElY+4OynONI77jotkrTyvz0RpThq26UpY3dvR+ q8dakV7wltyHSNeSGh8drbquzmjbaTZouMhsjqYhKyJapbxYZOORiN/igBNVEppJnozf whiP5OHoNzkvK9XMAdumG/1qS7TFPvpfaMMXpwDZ7wcybNA4V6qTx7faSgf+BrBp3v6B 3FTdCQAdn8jaZvg6BxT4CGsytcsPw+3s61u0dsqHddW8qSly6AppPvXcw7pILNhpC5s0 NiFQ== 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=2320AfWsVY/1NucEpezn+2MWEYHichvn6AubTjbfSDc=; b=LRlR3oaxvLB07on2neS+Ol2Vx9Twqy6St7vRNAoWwksHtuDxPDSmjftXsSUb+ejPuu SetzW8v4LtUlIArv986+mlrNfRkYaC+B43ABNmCqlgqiCoTYMX2SYLyjhHsTctycGTbV /XbCZ9UEVPODLMdaWzYA3+8ngiDthRlp/L+P5uyyH7f/DvQSGb9yqbfhnGoXEzXYIITx Eca5+OIVGAShO+0y3lqhx4/d3U50KeocyHD+kePPzf1ROCa69g4ZXu19eliQy0Y9bsHk cr6egZVt06qiCCZ+ERqtSqHn24I+TUWjscIoFOToqLsd5TL3GEaH3Ky9/pqvY35BW6Ei h12w== X-Gm-Message-State: AOAM530z3QX5KE9LTSlLr+Kr4pj1xx6glzySSZbhOnU92thQmSESiiZ+ Tl+zKnQ9Hcp/7f+nuRLRGx+J58ijKPPG3EN5as96tvjIkg== X-Google-Smtp-Source: ABdhPJwTxIpW3BZaLr81H9hJDzKdKsFPqbwpoN2+iuNoOIluJ503/wXGjDGKbR+oq6+yEI58MWtuLN5EuOhYCLv9FlE= X-Received: by 2002:a17:906:700f:: with SMTP id n15mr8587193ejj.390.1594985843408; Fri, 17 Jul 2020 04:37:23 -0700 (PDT) MIME-Version: 1.0 From: Cristian Cardoso Date: Fri, 17 Jul 2020 08:37:12 -0300 Message-ID: Subject: Freebsd-update To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4B7Tcj2MJ1z3xwP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=BjvatSzN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cristiancardoso11@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=cristiancardoso11@gmail.com X-Spamd-Result: default: False [-2.85 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.002]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; NEURAL_SPAM_SHORT(0.13)[0.132]; 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]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Jul 2020 11:37:26 -0000 Hello I would like to know if by chance in freeBSD there is some kind of log when the command freebsd-update fetch / install is executed? I looked in the documentation and found nothing about it. Does anyone know if this exists? From owner-freebsd-current@freebsd.org Fri Jul 17 14:39:34 2020 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 D25FA36683A for ; Fri, 17 Jul 2020 14:39:34 +0000 (UTC) (envelope-from freqlabs@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7Yft54l9z47st for ; Fri, 17 Jul 2020 14:39:34 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MBP.attlocal.net (unknown [IPv6:2600:1700:358a:c660:3cab:eb30:63d8:d9af]) (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 7BE1919A8D for ; Fri, 17 Jul 2020 14:39:34 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: Kernel panic on recent 12.1 on bridge creation. To: freebsd-current@freebsd.org References: From: Ryan Moeller Message-ID: <934d97b4-4739-c542-4830-a30dcc9f964c@FreeBSD.org> Date: Fri, 17 Jul 2020 10:39:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: 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.33 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, 17 Jul 2020 14:39:34 -0000 I've reproduced this on the latest snapshot build of stable/12 and created a PR here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248046 On 7/16/20 6:26 PM, Daniel Dettlaff wrote: >> On 17.07.2020, at 00:16, Daniel Dettlaff wrote: >> >> Hello, I heard it's known? >> >> I built recent system from stable/12 branch and either "ifconfig bridge0 create" and `cloned_interfaces="bridge0"` + `ifconfig_bridge0_aliases="inet 172.16.7.1/16` in rc.conf.local causes instant KP and system reboot. >> >> kind regards >> Daniel Dettlaff > will just add screenshots from cause: http://s.verknowsys.com/6eade44caec93c46b134ec81c8597081.png it's production kernel build so no symbols. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Jul 17 22:04:26 2020 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 74DFD370317 for ; Fri, 17 Jul 2020 22:04:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4B7lX93rNBz4blw for ; Fri, 17 Jul 2020 22:04:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VJbsL5UVM1krXhYiyoyuasFuX5SZorymkDUce9zAJ1z8lEvgNU3v199JOe6LwQf xgIG3VxR_sBOqZQGeNREMWbP39aN25pK7TJWUuCP7cFt9k1bAmlvK80ZuekKpKDnfsoxkP5VD8rS 9NpN.2iT7a9kPtGG9vwx0QRPVcaYhjCj76yKse26f1Jf.wXPmslzYm4.bnlJ.rEbzBePaha6ExQj fhafe3.TxU3g2gbxCRuYkzwQ44FBtju0QE33dkt6ZDg44lbGBuPoc9tZXwMvHExNlNgAsUqmqj3a i7SUvlgNOmN2B.nrQBPNoW8Dg_QuW0irYYRrfGdTlmzmPD..z3hb6829NZoqQV_lZmtjwS53oX28 1YLDCwaM5OLq9WDGx1TtmpNaSyOZQh7vdn.qioNOBPi87kpXrg6W0sXS0AhayBmh.TP07Yk6cmbR rkKkRVhlpWRETLd4xOzwaAxdht6GO6LNAXS_Yr3Hnk78S_l9ZxxQ7CgydXarsCty58eFBN7wirnn mGGf0rZhwBcizgmsX9U64wfoDSGd.pMFRE5wiIhw1wMAKi8gcoa78cpMCIdxE9beF9YvKv9y8j4q EsOg.e2HkdLHT.IX1jMqdIF_4BBNj24rmh2A8xhOHNLCmydJQnbWd10YT460KuuTHz_hxp9sJEEE 2o0MCN_8nKy8DfXg22GgbvpocOGDL5A8s0vac34Ylbwboy0AP55mTejPogZnKKB_7FfrY2b9NsEp 7yuNPfklsRn4.FP6okLDPMBRhJQ..J6kVKtMboMP6j8xZ4ktvv9z.PG_0Yt_hS74WmhyGL8Fj.sC nVeGvtAel8PcPgMZoZysNB_s4QY7oPgO5b5ToQ1RHFVPlnDKWlzoOOUolZwTcAS111jayk5FOn_1 XXNDO2p1vw9xg5Fhe8vbPjpd395Hs.KhVK7akZEExOwkMQpsiODvHsiZt8wnMEDCVQN2pysJrh86 bzJqv4.WdHbFCyrsrdDmHdmCIjHYlTHY2Y1An_hMFqHzIKq4OXQRgU2CkE5lHS1cBy3Upp9yXry_ NtBpaPj6SbDOxSmp2HVjzagYNnZRjHKAqRkNfXlkrw9BxlTr7eO6eRoYgi_UmwElQBktSDtIDUqr fCiY3TvI4.jDQkiR..boWfI0DJvE2WZC0By2ADBW1UTY9QriU1VqEaVaWOcyLzWWFXmuT_2e5LPN rmKwa0khRjuMX7zhl7a5zZkD2QLiaLSqh.lJuOSDnjOSVa29s3xurlIi30TkdavewfpIVcUKDEAb 2F3UXJ2agCP95Gf.MEdjt9CbbIrvDL_RRHnK2FJWHA4BEO8wAYgaXnltRYEKHOefegIvRWuFKE7r LYs0gBswjySCqahu7u_pkHN9RVViy4J6anHN6q6gnd2cGqkqykCOIMMYHGcVBQOrmbB0skvWPWxf glMpskUT34ZiZSXvbV3HvwOTsQMoa3Q3_W1CKAiZ6DtoO_5aGpXWjtXw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Jul 2020 22:04:18 +0000 Received: by smtp431.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID af2867ed9d668ed2476cf32978a55690; Fri, 17 Jul 2020 22:04:16 +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 13.4 \(3608.80.23.2.2\)) Subject: Re: Pine64+2GB unable to boot after attempted update, failure very early: efipart_readwrite: rw=1, blk=... size=32 status=7; RPi3 has no problem Date: Fri, 17 Jul 2020 15:04:15 -0700 References: To: freebsd-arm , FreeBSD Current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B7lX93rNBz4blw X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.86 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.98)[-0.975]; NEURAL_HAM_MEDIUM(-1.04)[-1.044]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-0.34)[-0.344]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Jul 2020 22:04:26 -0000 On 2020-Jul-16, at 23:15, Mark Millard wrote: > [Trying again: I missed removing a type of character (escape) > beyond the [?25h removals. My choice of editor was not the > best for the context and it was not obvious that the > escapes were present.] >=20 > I'll mostly just send the text that has the > additional removals. The boot text with the error > messages then is: >=20 >=20 > U-Boot SPL 2020.07 (Jul 13 2020 - 12:12:14 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > NOTICE: BL31: v2.3(): > NOTICE: BL31: Built : 23:56:54, Apr 26 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4092b68, model: Pine64+ > NOTICE: PSCI: System suspend is unavailable > alloc space exhausted >=20 >=20 > U-Boot 2020.07 (Jul 13 2020 - 12:12:14 +0000) Allwinner Technology >=20 > CPU: Allwinner A64 (SUN50I) > Model: Pine64+ > DRAM: 2 GiB > MMC: mmc@1c0f000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default = environment >=20 > In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c30000 > starting USB... > Bus usb@1c1a000: USB EHCI 1.00 > Bus usb@1c1a400: USB OHCI 1.0 > Bus usb@1c1b000: USB EHCI 1.00 > Bus usb@1c1b400: USB OHCI 1.0 > scanning bus usb@1c1a000 for devices... 1 USB Device(s) found > scanning bus usb@1c1a400 for devices... 1 USB Device(s) found > scanning bus usb@1c1b000 for devices... 3 USB Device(s) found > scanning bus usb@1c1b400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 2 =08=08=08 1 =08=08=08 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > 38612 bytes read in 4 ms (9.2 MiB/s) > Found EFI removable media binary efi/boot/bootaa64.efi > Scanning disk mmc@1c0f000.blk... > ** Unrecognized filesystem type ** > Scanning disk usb_mass_storage.lun0... > ** Unrecognized filesystem type ** > ** Unrecognized filesystem type ** > ** Unrecognized filesystem type ** > Found 7 disks > 7[r[999;999H[6n8BootOrder not defined > EFI boot manager: Cannot load any image > 695648 bytes read in 33 ms (20.1 MiB/s) > [2J[1;1H[2J[1;1HConsoles: EFI console =20 >=20 >=20 > |/-\|/-\| Reading loader env vars from /efi/freebsd/loader.env >=20 >=20 > Setting currdev to disk0p1: >=20 >=20 > /-\|/-FreeBSD/arm64 EFI loader, Revision 1.1 >=20 >=20 >=20 >=20 >=20 > Command line arguments: loader.efi >=20 >=20 > Image base: 0xb8e63000 >=20 >=20 > EFI version: 2.80 >=20 >=20 > EFI Firmware: Das U-Boot (rev 8224.1792) >=20 >=20 > Console: comconsole (0) >=20 >=20 > Load Path: /efi\boot\bootaa64.efi >=20 >=20 > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403= b,0x1ffe0) >=20 >=20 > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403= b,0x1ffe0) >=20 >=20 > Setting currdev to disk0p1: >=20 >=20 > \|/-\|/-\|/-Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x244= 00,0xe600000) >=20 >=20 > Setting currdev to disk0p2: >=20 >=20 > \|/-\|efipart_readwrite: rw=3D1, blk=3D123244224 size=3D32 status=3D7 >=20 >=20 > /efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 >=20 >=20 > -efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > \efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 >=20 >=20 > |efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > /efipart_readwrite: rw=3D1, blk=3D148608 size=3D32 status=3D7 >=20 >=20 > -efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > efipart_readwrite: rw=3D1, blk=3D148545 size=3D32 status=3D7 >=20 >=20 > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Type '?' for a list of commands, 'help' for more detailed help. >=20 >=20 > OK=20 >=20 >=20 >=20 >=20 >=20 > The contrasting RPi3B text near the area with first errors above: >=20 >=20 >=20 > \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x244= 00,0xe600000) >=20 >=20 > Setting currdev to disk0p2: >=20 >=20 > = \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08Lo= ading /boot/defaults/loader.conf >=20 >=20 > /=08-=08\=08|=08/=08-=08\=08Loading /boot/defaults/loader.conf >=20 >=20 > Loading /boot/device.hints >=20 >=20 > |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08Loading = /boot/loader.conf >=20 >=20 > |=08/=08-=08\=08Loading /boot/loader.conf.local >=20 >=20 >=20 > (I'll not list more.) >=20 > For reference: >=20 > # gpart show -p > =3D> 63 249737153 mmcsd0 MBR (119G) > 63 16380 - free - (8.0M) > 16443 131040 mmcsd0s1 fat32lba [active] (64M) > 147483 997 - free - (499K) > 148480 241172480 mmcsd0s2 freebsd (115G) > 241320960 8416256 - free - (4.0G) >=20 > =3D> 0 241172480 mmcsd0s2 BSD (115G) > 0 230686720 mmcsd0s2a freebsd-ufs (110G) > 230686720 10485760 - free - (5.0G) >=20 > =3D> 40 468862048 da0 GPT (224G) > 40 2008 - free - (1.0M) > 2048 413138944 da0p1 freebsd-ufs (197G) > 413140992 6291456 da0p2 freebsd-swap (3.0G) > 419432448 6291456 da0p4 freebsd-swap (3.0G) > 425723904 43138184 - free - (21G) >=20 > # find /boot/efi/ -print | sort | more > /boot/efi/ > /boot/efi/COPYING.linux > /boot/efi/EFI > /boot/efi/EFI/BOOT > /boot/efi/EFI/BOOT/bootaa64.efi > /boot/efi/LICENCE.broadcom > /boot/efi/System Volume Information > /boot/efi/System Volume Information/WPSettings.dat > /boot/efi/armstub8.bin > /boot/efi/bcm2710-rpi-2-b.dtb > /boot/efi/bcm2710-rpi-3-b-plus.dtb > /boot/efi/bcm2710-rpi-3-b.dtb > /boot/efi/bcm2710-rpi-cm3.dtb > /boot/efi/bootcode.bin > /boot/efi/config.txt > /boot/efi/dtb > /boot/efi/dtb/allwinner > /boot/efi/dtb/allwinner/sun50i-a64-pine64-lts.dtb > /boot/efi/dtb/allwinner/sun50i-a64-pine64-plus.dtb > /boot/efi/dtb/allwinner/sun50i-a64-pine64.dtb > /boot/efi/dtb/allwinner/sun50i-a64-pinebook.dtb > /boot/efi/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb > /boot/efi/dtb/overlays > /boot/efi/dtb/overlays/spigen-rpi3.dtbo > /boot/efi/dtb/overlays/sun50i-a64-opp.dtbo > /boot/efi/dtb/overlays/sun50i-a64-pwm.dtbo > /boot/efi/dtb/overlays/sun50i-a64-rpwm.dtbo > /boot/efi/dtb/overlays/sun50i-a64-spi0-spigen.dtbo > /boot/efi/dtb/overlays/sun50i-a64-timer.dtbo > /boot/efi/fixup.dat > /boot/efi/overlays > /boot/efi/overlays/disable-bt.dtbo > /boot/efi/overlays/mmc.dtbo > /boot/efi/overlays/pwm.dtbo > /boot/efi/start.elf > /boot/efi/u-boot.bin >=20 > (Where /boot/efi refers to /dev/mmcsd0s1 .) >=20 > I forgot to indicate: that the context is based > on head -r363123 FreeBSD and -r542111 ports. >=20 Well, I've had back-to-back boot attempts go from fails to works, same media. It may just be the old Pine64+2GB is no longer reliable (in one or more ways). Outside the Pine64+2GB context, I've no evidence of the microsd card being problematical. I've some past evidence of USB failing on occasion on the Pine64+2GB. Difficult to tell if such hardware problems are the overall issue. The timing of the the recent boot failure failures starting also might point at the updated sysutils/u-boot-pine64 material. (FreeBSD had been updated previous to the u-boot update.) Using the RPi3B I'd moved where mmcsd0s2 started on the microsd card after the prior reports, but that had made no difference in the behavior for a time and so is not likely to be related to the boot attempt that worked. For now I'm going to ignore such Pine64+2GB boot failures relative to list reporting. (That still leaves me with Rock64 booting being broken buy head -r363122 / -r363213 . powerpc64 and 32-bit powerpc are still untested for head -r363123. Given problems with 32-bit powerpc having the kernel zero-out pages of user-process memory [known problem], I'm not so sure it will get any testing.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jul 18 00:26:38 2020 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 78236372F72 for ; Sat, 18 Jul 2020 00:26:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.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 4B7phD51GDz4lHq for ; Sat, 18 Jul 2020 00:26:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Db9OJWcVM1kp5wYxzOIjSDLm8taORKPQiuDmSjWlBAhmlYw0ZRwaykgJifOR8lR ecvDSBkmqI.PsdCaRSixgbzm1vU_0earjQ.Jr.fAdjITWXGEM9i77sMPlolgCpfo0XzyXwypV9U. f9eKVQaOwjL0hX0XoUN6cf8v6359NVMF_VYKxrcP1bHyVjCz_ZMVAz1W5dU.V.jJBl6cPpFqzc18 38Y64YM7bT0DgEkcqBocog9FRxAq2BOAij.qmwGg58a_rBUlyGd3bwKCiuq8L.7LciOp.7ZjNYHo 59wC9miGMWFtt5d_PMJb_pQ4bpli9itsq_wjYft9iRm9n1BgZLAvhZkiUD1Ff8xknj5jfopU_GdN 2w1in.Nh95lqNu6hNpXrWae77NXLhf55Fng2vZRauZXH1cUeP2XIQxWySNUgXVW00QzIp.Zm3g5j Cxvy9JzPgIgH1PcYQdb_r6sPzm2QrS5idah2gWoZ0IAUSaL880S6GO8e9lcjS6UdNQe7Hb6sTL1U R8WF3X8psDk4Q.IgrEU31py3gK5lmAy_maiDWUObU_XTMEvpVVayEJJhIhMUwt4vD3qud75bHt7X JmwIUzgSlg.BhEcaKEZVMnA9YE0CBx6vZW_weVw1IPx_mMNr99z_yS0orC9Jlsp3oSQd2J7_zADV _FAOgUXK5p9lvm02EUw7Xf4D2vOu90JoGA4Wcy3KHAvGOFhNJ.lnn..WyCp0hXKfpqdqGj5lv0tX 7gHrJJzl0xxRij.vadbP2FiOn5s2iFa0QKMok6YfprkloXqoWu_BgAB8VCUbHMsrGmbdxFSFeMoA bRUU0PLPJj5lfZ7j0I_UKUCYCOKe_w_zCBmPDxk3qJc89NuuYFtpDLKYnt_c3lOD.gZVLFbIiWFe EI.y_Aa_6lAYoQ2XYW.veuHdcXfNu3zWoie2NxQBsPI2D5ge9dRi5RuXngxltN9nXRrEvbcS0akM IcmSZF4_gKFlQHGd6XeOLwxkvbqB4EeBcAhvQFI5mznLa.YtoOoLY9wboZfs_RqXSpYKHc4NazuI 8TmlA7uYRIOV8Qa7bAJsUhrmdufJ1XIej9SS0j7TlDUL6TcPs6spHv4X2A.fBqSEk6KJanDcBcul VpJu_yLiyrCCBWKNUb6GUgVECt9S3b0ZpTu2Ooa_y7_mAui9F3QQ6BOCPv9NlJMTNnzDD4u2XLp3 Kz5sFTW2p62vwFBAZXw6qg5ZEM2547nQgXr0d22IvyrHV47lhsYuhOvBzp3P21rEhDvonzQvGWxN rGx_uffE_7w0IsAVcH4zEBeAgl3bYam4NnIUE._n7FeK2ipH.Z1mCc_AhI1WgvoEWpKyDBdDZc_T ylH2CrZF5ePCNpa2i4n1UI6cH3WOUUF19uvHV4MUowBIjkr.dSLicU2XrLkwtKv3G.X2MyLkSCnB ublbOOcey0ae5uR44vON94YRz9Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Jul 2020 00:26:35 +0000 Received: by smtp420.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9f25cd07be33d63b2d1819d614e6ac12; Sat, 18 Jul 2020 00:26:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: slow USB 3.0 on -current From: Mark Millard In-Reply-To: Date: Fri, 17 Jul 2020 17:26:31 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <4AAB4780-7A46-46CF-A5C1-8F5590CE5455@yahoo.com> References: <9D8F806C-2F11-4338-9905-E91BBCDEFC01.ref@yahoo.com> <9D8F806C-2F11-4338-9905-E91BBCDEFC01@yahoo.com> <20200713045149.GL4213@funkthat.com> <1F4704D0-DD42-4DD2-A15C-D89FEF2FA382@yahoo.com> <20200713190349.GM4213@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B7phD51GDz4lHq X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.98)[-0.976]; NEURAL_HAM_MEDIUM(-1.04)[-1.044]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; NEURAL_HAM_SHORT(-0.86)[-0.859]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Jul 2020 00:26:38 -0000 On 2020-Jul-13, at 13:18, Mark Millard wrote: > [Just a correction to a side comment.] >=20 > On 2020-Jul-13, at 12:46, Mark Millard wrote: >=20 >> On 2020-Jul-13, at 12:03, John-Mark Gurney = wrote: >>=20 >>> Mark Millard wrote this message on Mon, Jul 13, 2020 at 00:44 -0700: >>>> On 2020-Jul-12, at 21:51, John-Mark Gurney = wrote: >>>>=20 >>>>> . . . >>>>=20 >>>> Hmm. I only seem to be able to find one type. Its been a >>>> while since I've used the other and I do not know where >>>> it is at. For what I found: >>>>=20 >>>> ugen0.2: at usbus0 >>>> axge0 on uhub0 >>>> axge0: on usbus0 >>>> miibus1: on axge0 >>>> rgephy0: PHY 3 on = miibus1 >>>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >>>>=20 >>>> (I have access to more than one instance of the above.) >>>=20 >>> Yeah, these are the ones that are known to not be able to get close >>> to gige speeds, unlike the RealTek one that I am using now... >>=20 >> Hmm, in one direction anyway? >>=20 >> NetBSD current testing on a RPi4 for >> iperf3 -R -c 192.168.1.120 -B 192.168.1.140 : >>=20 >> Server listening on 5201 >> ----------------------------------------------------------- >> Accepted connection from 192.168.1.140, port 65525 >> [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port = 65524 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 33.7 MBytes 282 Mbits/sec 0 33.9 = KBytes =20 >> [ 5] 1.00-2.00 sec 96.0 MBytes 805 Mbits/sec 2 48.9 = KBytes =20 >> [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 12 81.9 = KBytes =20 >> [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec 18 114 = KBytes =20 >> [ 5] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec 42 145 = KBytes =20 >> [ 5] 5.00-6.00 sec 84.8 MBytes 712 Mbits/sec 50 178 = KBytes =20 >> [ 5] 6.00-7.00 sec 111 MBytes 929 Mbits/sec 40 194 = KBytes =20 >> [ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 40 194 = KBytes =20 >> [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 47 194 = KBytes =20 >> [ 5] 9.00-10.00 sec 111 MBytes 927 Mbits/sec 50 193 = KBytes =20 >> [ 5] 10.00-10.62 sec 68.4 MBytes 929 Mbits/sec 46 193 = KBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender >>=20 >> and as seen on the receiver: >>=20 >> # iperf3 -R -c 192.168.1.120 -B 192.168.1.140 >> Connecting to host 192.168.1.120, port 5201 >> Reverse mode, remote host 192.168.1.120 is sending >> [ 5] local 192.168.1.140 port 65524 connected to 192.168.1.120 port = 5201 >> [ ID] Interval Transfer Bitrate >> [ 5] 0.00-1.00 sec 87.8 MBytes 736 Mbits/sec =20= >> [ 5] 1.00-2.00 sec 110 MBytes 924 Mbits/sec =20= >> [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec =20= >> [ 5] 3.00-4.00 sec 83.6 MBytes 701 Mbits/sec =20= >> [ 5] 4.00-5.00 sec 84.8 MBytes 711 Mbits/sec =20= >> [ 5] 5.00-6.00 sec 111 MBytes 931 Mbits/sec =20= >> [ 5] 6.00-7.00 sec 83.4 MBytes 700 Mbits/sec =20= >> [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec =20= >> [ 5] 8.00-9.00 sec 111 MBytes 929 Mbits/sec =20= >> [ 5] 9.00-10.00 sec 111 MBytes 929 Mbits/sec =20= >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.62 sec 977 MBytes 772 Mbits/sec 347 = sender >> [ 5] 0.00-10.00 sec 977 MBytes 819 Mbits/sec = receiver >>=20 >> This is faster than the built-in EtherNet results. >> (But the built-in is also USB based.) >=20 > The built-in EtherNet does not show in usbdevs output. > I got the context wrong for the ()'d note. >=20 >> As for iperf3 -c 192.168.1.120 -B 192.168.1.140 it is >> slower: >>=20 >> Connecting to host 192.168.1.120, port 5201 >> [ 5] local 192.168.1.140 port 65526 connected to 192.168.1.120 port = 5201 >> [ ID] Interval Transfer Bitrate Retr Cwnd >> [ 5] 0.00-1.00 sec 62.5 MBytes 522 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 1.00-2.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 2.01-3.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 3.01-4.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 4.01-5.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 6.01-7.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 7.01-8.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 8.01-9.01 sec 62.5 MBytes 524 Mbits/sec 0 4.00 = MBytes =20 >> [ 5] 9.01-10.01 sec 62.5 MBytes 525 Mbits/sec 0 4.00 = MBytes =20 >> - - - - - - - - - - - - - - - - - - - - - - - - - >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.01 sec 625 MBytes 524 Mbits/sec 0 = sender >> [ 5] 0.00-10.62 sec 625 MBytes 494 Mbits/sec = receiver >>=20 >> This is again faster than the built-in EtherNet results. >=20 I got my hands on a (shown via NetBSD -current): [ 240486.8559968] ure0 at uhub0 port 1 [ 240486.8559968] ure0: Realtek (0x0bda) USB 10/100/1000 LAN (0x8153), = rev 3.00/30.00, addr 5 [ 240486.8659983] ure0: RTL8153 ver 5c30 [ 240486.9260031] rgephy0 at ure0 phy 0: RTL8251 1000BASE-T media = interface, rev. 0 [ 240486.9360031] rgephy0: 10baseT, 10baseT-FDX, 100baseTX, = 100baseTX-FDX, 1000baseT-FDX, auto [ 240486.9471347] ure0: Ethernet address a0:ce:c8:d6:8f:dc NetBSD on a RPi4 reports for such: # iperf3 -c 192.168.1.120 --get-server-output -B 192.168.1.143 Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.143 port 65528 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.02 sec 67.2 MBytes 555 Mbits/sec 0 4.00 MBytes = =20 [ 5] 1.02-2.01 sec 74.9 MBytes 633 Mbits/sec 0 4.00 MBytes = =20 [ 5] 2.01-3.00 sec 74.9 MBytes 633 Mbits/sec 0 4.00 MBytes = =20 [ 5] 3.00-4.01 sec 76.4 MBytes 634 Mbits/sec 0 4.00 MBytes = =20 [ 5] 4.01-5.00 sec 74.8 MBytes 634 Mbits/sec 0 4.00 MBytes = =20 [ 5] 5.00-6.01 sec 76.1 MBytes 634 Mbits/sec 0 4.00 MBytes = =20 [ 5] 6.01-7.00 sec 75.1 MBytes 634 Mbits/sec 0 4.00 MBytes = =20 [ 5] 7.00-8.01 sec 76.2 MBytes 634 Mbits/sec 0 4.00 MBytes = =20 [ 5] 8.01-9.00 sec 74.8 MBytes 633 Mbits/sec 0 4.00 MBytes = =20 [ 5] 9.00-10.01 sec 75.5 MBytes 629 Mbits/sec 0 4.00 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 746 MBytes 625 Mbits/sec 0 = sender [ 5] 0.00-10.63 sec 746 MBytes 589 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.143, port 65529 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.143 port = 65528 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 23.4 MBytes 196 Mbits/sec =20 [ 5] 1.00-2.00 sec 71.2 MBytes 597 Mbits/sec =20 [ 5] 2.00-3.00 sec 75.5 MBytes 633 Mbits/sec =20 [ 5] 3.00-4.00 sec 75.5 MBytes 634 Mbits/sec =20 [ 5] 4.00-5.00 sec 75.5 MBytes 634 Mbits/sec =20 [ 5] 5.00-6.00 sec 75.6 MBytes 634 Mbits/sec =20 [ 5] 6.00-7.00 sec 75.6 MBytes 634 Mbits/sec =20 [ 5] 7.00-8.00 sec 75.6 MBytes 634 Mbits/sec =20 [ 5] 8.00-9.00 sec 75.6 MBytes 634 Mbits/sec =20 [ 5] 9.00-10.00 sec 75.1 MBytes 630 Mbits/sec =20 [ 5] 10.00-10.63 sec 47.4 MBytes 632 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.63 sec 746 MBytes 589 Mbits/sec = receiver iperf Done. (I'll note that the axge0 sometimes also ends up with figures about 630 Mbits/sec. The 520 Mbits/sec range figures were the lowest I'd observed. I'll include output of such at the end of the note.) # iperf3 -R -c 192.168.1.120 --get-server-output -B 192.168.1.143 Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.143 port 65530 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 106 MBytes 893 Mbits/sec =20 [ 5] 1.00-2.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 2.00-3.00 sec 111 MBytes 929 Mbits/sec =20 [ 5] 3.00-4.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 4.00-5.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 5.00-6.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 6.00-7.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec =20 [ 5] 9.00-10.00 sec 111 MBytes 930 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 1.08 GBytes 873 Mbits/sec 249 = sender [ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.143, port 65531 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.143 port = 65530 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 38.7 MBytes 325 Mbits/sec 0 65.0 KBytes = =20 [ 5] 1.00-2.00 sec 110 MBytes 926 Mbits/sec 34 96.8 KBytes = =20 [ 5] 2.00-3.00 sec 111 MBytes 930 Mbits/sec 30 129 KBytes = =20 [ 5] 3.00-4.00 sec 111 MBytes 929 Mbits/sec 24 162 KBytes = =20 [ 5] 4.00-5.00 sec 111 MBytes 930 Mbits/sec 26 193 KBytes = =20 [ 5] 5.00-6.00 sec 111 MBytes 930 Mbits/sec 23 194 KBytes = =20 [ 5] 6.00-7.00 sec 111 MBytes 930 Mbits/sec 25 193 KBytes = =20 [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec 25 193 KBytes = =20 [ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 25 194 KBytes = =20 [ 5] 9.00-10.00 sec 111 MBytes 930 Mbits/sec 37 193 KBytes = =20 [ 5] 10.00-10.62 sec 68.5 MBytes 932 Mbits/sec 0 193 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.62 sec 1.08 GBytes 873 Mbits/sec 249 = sender iperf Done. (So far in this direction it does seem to get into the 900's more than the axge0 did.) Interestingly, NetBSD goes faster in one direction with either of these chipsets via USB3 than it does with the built-in EtherNet on the RPi4 (see the -R run below). # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.131 port 65534 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.01 sec 69.2 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 1.01-2.01 sec 68.9 MBytes 577 Mbits/sec 0 4.00 MBytes = =20 [ 5] 2.01-3.01 sec 68.3 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 3.01-4.01 sec 69.2 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 4.01-5.00 sec 68.1 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 5.00-6.00 sec 68.5 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 6.00-7.00 sec 68.6 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 7.00-8.01 sec 69.2 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 [ 5] 8.01-9.01 sec 68.9 MBytes 577 Mbits/sec 0 4.00 MBytes = =20 [ 5] 9.01-10.00 sec 68.3 MBytes 576 Mbits/sec 0 4.00 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 687 MBytes 576 Mbits/sec 0 = sender [ 5] 0.00-10.62 sec 687 MBytes 543 Mbits/sec = receiver Server output: Accepted connection from 192.168.1.131, port 65535 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.131 port = 65534 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 26.3 MBytes 220 Mbits/sec =20 [ 5] 1.00-2.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 2.00-3.00 sec 68.7 MBytes 577 Mbits/sec =20 [ 5] 3.00-4.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 4.00-5.00 sec 68.6 MBytes 576 Mbits/sec =20 [ 5] 5.00-6.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 6.00-7.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 7.00-8.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 8.00-9.00 sec 68.7 MBytes 576 Mbits/sec =20 [ 5] 9.00-10.00 sec 68.7 MBytes 577 Mbits/sec =20 [ 5] 10.00-10.62 sec 42.6 MBytes 576 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.62 sec 687 MBytes 543 Mbits/sec = receiver iperf Done. # iperf3 -R -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.131 port 65532 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 59.6 MBytes 500 Mbits/sec =20 [ 5] 1.00-2.00 sec 58.7 MBytes 493 Mbits/sec =20 [ 5] 2.00-3.00 sec 76.9 MBytes 644 Mbits/sec =20 [ 5] 3.00-4.00 sec 66.4 MBytes 557 Mbits/sec =20 [ 5] 4.00-5.00 sec 69.3 MBytes 581 Mbits/sec =20 [ 5] 5.00-6.00 sec 60.7 MBytes 510 Mbits/sec =20 [ 5] 6.00-7.00 sec 77.4 MBytes 649 Mbits/sec =20 [ 5] 7.00-8.00 sec 81.0 MBytes 678 Mbits/sec =20 [ 5] 8.00-9.00 sec 80.2 MBytes 675 Mbits/sec =20 [ 5] 9.00-10.00 sec 77.2 MBytes 647 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.63 sec 708 MBytes 559 Mbits/sec 1964 = sender [ 5] 0.00-10.00 sec 707 MBytes 593 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.131, port 65533 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.131 port = 65532 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 12.3 MBytes 103 Mbits/sec 42 34.1 KBytes = =20 [ 5] 1.00-2.00 sec 76.1 MBytes 638 Mbits/sec 227 29.5 KBytes = =20 [ 5] 2.00-3.00 sec 60.9 MBytes 511 Mbits/sec 148 69.6 KBytes = =20 [ 5] 3.00-4.00 sec 70.2 MBytes 589 Mbits/sec 189 36.9 KBytes = =20 [ 5] 4.00-5.00 sec 68.0 MBytes 570 Mbits/sec 157 29.8 KBytes = =20 [ 5] 5.00-6.00 sec 74.0 MBytes 621 Mbits/sec 177 51.0 KBytes = =20 [ 5] 6.00-7.00 sec 58.8 MBytes 493 Mbits/sec 205 17.0 KBytes = =20 [ 5] 7.00-8.00 sec 78.1 MBytes 655 Mbits/sec 246 34.1 KBytes = =20 [ 5] 8.00-9.00 sec 82.2 MBytes 689 Mbits/sec 144 34.1 KBytes = =20 [ 5] 9.00-10.00 sec 77.5 MBytes 650 Mbits/sec 270 15.6 KBytes = =20 [ 5] 10.00-10.63 sec 49.4 MBytes 662 Mbits/sec 159 19.8 KBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.63 sec 708 MBytes 559 Mbits/sec 1964 = sender iperf Done. As for axge0 for -c (no -R) getting in the 600 Mbits/sec range, an example was: # iperf3 -c 192.168.1.120 -B 192.168.1.140 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.140 port 65518 connected to 192.168.1.120 port = 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.01 sec 76.4 MBytes 633 Mbits/sec 0 4.00 MBytes = =20 [ 5] 1.01-2.01 sec 75.2 MBytes 633 Mbits/sec 0 4.00 MBytes = =20 [ 5] 2.01-3.01 sec 72.9 MBytes 613 Mbits/sec 0 4.00 MBytes = =20 [ 5] 3.01-4.01 sec 74.9 MBytes 628 Mbits/sec 0 4.00 MBytes = =20 [ 5] 4.01-5.01 sec 70.6 MBytes 590 Mbits/sec 0 4.00 MBytes = =20 [ 5] 5.01-6.01 sec 62.5 MBytes 523 Mbits/sec 0 4.00 MBytes = =20 [ 5] 6.01-7.02 sec 65.7 MBytes 551 Mbits/sec 0 4.00 MBytes = =20 [ 5] 7.02-8.01 sec 75.4 MBytes 637 Mbits/sec 0 4.00 MBytes = =20 [ 5] 8.01-9.01 sec 76.2 MBytes 638 Mbits/sec 0 4.00 MBytes = =20 [ 5] 9.01-10.02 sec 76.4 MBytes 637 Mbits/sec 0 4.00 MBytes = =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 726 MBytes 608 Mbits/sec 0 = sender [ 5] 0.00-10.63 sec 726 MBytes 573 Mbits/sec = receiver Server output: ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.140, port 65519 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.140 port = 65518 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 29.1 MBytes 244 Mbits/sec =20 [ 5] 1.00-2.00 sec 75.5 MBytes 633 Mbits/sec =20 [ 5] 2.00-3.00 sec 75.5 MBytes 633 Mbits/sec =20 [ 5] 3.00-4.00 sec 72.9 MBytes 611 Mbits/sec =20 [ 5] 4.00-5.00 sec 70.5 MBytes 592 Mbits/sec =20 [ 5] 5.00-6.00 sec 69.9 MBytes 586 Mbits/sec =20 [ 5] 6.00-7.00 sec 62.3 MBytes 523 Mbits/sec =20 [ 5] 7.00-8.00 sec 70.7 MBytes 593 Mbits/sec =20 [ 5] 8.00-9.00 sec 76.0 MBytes 638 Mbits/sec =20 [ 5] 9.00-10.00 sec 76.0 MBytes 638 Mbits/sec =20 [ 5] 10.00-10.63 sec 47.8 MBytes 637 Mbits/sec =20 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.63 sec 726 MBytes 573 Mbits/sec = receiver iperf Done. Performance from either or both chip sets similar to NetBSD's performance for either would be nice on FreeBSD compared to what FreeBSD gets now. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat Jul 18 11:22:31 2020 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 C73443652D7 for ; Sat, 18 Jul 2020 11:22:31 +0000 (UTC) (envelope-from me@anatoli.ws) Received: from out-mx.anatoli.ws (out-mx.anatoli.ws [177.54.157.124]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "out-mx.anatoli.ws", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B85F26jrWz48tc for ; Sat, 18 Jul 2020 11:22:30 +0000 (UTC) (envelope-from me@anatoli.ws) Received: from [192.168.0.1] (unknown [192.168.0.1]) by out-mx.oprbox.com (Postfix) with ESMTPSA id 02D691E00BCA for ; Sat, 18 Jul 2020 11:22:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=anatoli.ws; s=vnptcm0lqn; t=1595071342; bh=14PJkBZK0qy0Ajcu1rMjYMJr9go14yUfCQNj9hhZdRo=; h=To:From:Subject:Date; b=PB8I7ItUYXNlp10UGdMU0f80GmL8lbdZhPN/xGMAKQ851ppLgO+4hVcBaT8wk48UN B3HX8VaWzxByzZKZSRWrZDD2cpo/UZDummh1t1gpmwU8yRmVzpIGV+mx08mVvoBaGk UynZ1xI3PQTx6/xBf9ZoB07ybwgr48i+jMf7EFcMPAbjiB/yNYQ53q8Hi2RZRyphjr sXd0ZMx12bAyT01QrPwQz29ishv+jWY4QEpvFIPBTgUkCrLzZ3clV1prJ/mjCIHXWl 9qEVaC75OjVa09D+qRUNwcwecxsLkgJFKmLtELKvm4ox47PQWuxquM/pMqS84zAW6D cBGwyRZfNocVw== To: FreeBSD Current From: Anatoli Subject: PCI passthru now working for OpenBSD guests in FreeBSD bhyve Message-ID: <763c7ad3-6948-a20c-b0c8-8fedddeff3f7@anatoli.ws> Date: Sat, 18 Jul 2020 08:22:19 -0300 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B85F26jrWz48tc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anatoli.ws header.s=vnptcm0lqn header.b=PB8I7ItU; dmarc=pass (policy=reject) header.from=anatoli.ws; spf=pass (mx1.freebsd.org: domain of me@anatoli.ws designates 177.54.157.124 as permitted sender) smtp.mailfrom=me@anatoli.ws X-Spamd-Result: default: False [-2.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[anatoli.ws:s=vnptcm0lqn]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.99)[-0.988]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[anatoli.ws:+]; DMARC_POLICY_ALLOW(-0.50)[anatoli.ws,reject]; NEURAL_HAM_SHORT(-0.13)[-0.132]; R_SPF_ALLOW(-0.20)[+a:out-mx.anatoli.ws]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:262287, ipnet:177.54.156.0/22, country:BR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Jul 2020 11:22:31 -0000 Hi All, Just FYI, after years of PCI passthru* not working for OpenBSD guests in FreeBSD bhyve due to 2 bugs, a week ago the fixes were made available in FreeBSD 12.1-RELEASE-p7. Now it's possible to use an OpenBSD guest as a main firewall for a FreeBSD host, OpenBSD guest taking full control of the internet-connected NIC, isolating this way the host and other guests from unrestricted network flow. The details were recently published in the FreeBSD Quarterly Status Report - Second Quarter 2020: [1]. Regards, Anatoli * PCI devices passthru is a technique to pass host PCI devices to a virtual machine for its exclusive control and use. [1] https://www.freebsd.org/news/status/report-2020-04-2020-06.html#PCI-passthrough-with-bhyve-on-Intel-and-for-OpenBSD-guests From owner-freebsd-current@freebsd.org Sat Jul 18 13:22:45 2020 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 E52FF369B10 for ; Sat, 18 Jul 2020 13:22:45 +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 4B87vn3nG7z4Jdk for ; Sat, 18 Jul 2020 13:22:45 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.nyi.freebsd.org (Postfix) id 81D5336993D; Sat, 18 Jul 2020 13:22:45 +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 817A036993C; Sat, 18 Jul 2020 13:22:45 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward501j.mail.yandex.net (forward501j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::111]) (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 4B87vm3sN9z4Jdj; Sat, 18 Jul 2020 13:22:44 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback21j.mail.yandex.net (mxback21j.mail.yandex.net [IPv6:2a02:6b8:0:1619::221]) by forward501j.mail.yandex.net (Yandex) with ESMTP id 6953033803CA; Sat, 18 Jul 2020 16:22:40 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback21j.mail.yandex.net (mxback/Yandex) with ESMTP id XNbbiEPLmd-Mdxu8ehd; Sat, 18 Jul 2020 16:22:39 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1595078559; bh=7Uo7YJbzSQOjJB8+biMens1fD2Jak8MLUdDyNSQEmIM=; h=Message-Id:Date:Subject:To:From; b=ClnIejOCTIyS+J6SFWWs30MV+kfdyghTAEmaOUUv6u+HFCWC1HbLuTG0G27iSbg1Q OdANjA0PAdYvnLw99UtCWcqxV+5QY0ybaOfpd2Yv5t9lT/HfY4g3lRAqHUhpTMzN8Y xJZ2mRFGMSxLnKYMA906nWj3W3JmYb0oqmRcN8Jw= Received: by myt4-01544bcb68a1.qloud-c.yandex.net with HTTP; Sat, 18 Jul 2020 16:22:39 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: "current@FreeBSD.org" , FreeBSD Stable Mailing List , net Subject: net.add_addr_allfibs=1 behaviour deprecation MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 18 Jul 2020 14:22:39 +0100 Message-Id: <236161595078191@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4B87vm3sN9z4Jdj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=ClnIejOC; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:801:2::111 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-2.82 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0::/52:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.018]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[ipfw.ru:+]; NEURAL_HAM_SHORT(-0.52)[-0.519]; FORGED_SENDER(0.30)[melifaro@freebsd.org,melifaro@ipfw.ru]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:0:801:2::111:from]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; FROM_NEQ_ENVFROM(0.00)[melifaro@freebsd.org,melifaro@ipfw.ru] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Jul 2020 13:22:46 -0000 Dear FreeBSD users, I would like to make net.add_addr_allfibs=0 as the default system behaviour and remove net.add_addr_allfibs. To do so, I would like to collect use cases with net.add_addr_allfibs=1 and multiple fibs, to ensure they can still be supported after removal. Background: Multi-fib support was added in r178888 [1], 12 years ago. Addition of interface addresses to all fibs was a feature from day 1. The `net.add_addr_allfibs` sysctl  was added in r180840 [2], 12 years ago. Problem: The goal of the fib support is to provide multiple independent routing tables, isolated from each other. `net.add_addr_allfibs` default tries to shift gears in the opposite direction, unconditionally inserting all addresses to all of the fibs. It complicates the logic, kernel code and makes control plane performance decrease with the number of fibs. It make impossible to use the same prefixes in multiple fibs, which may be desired given shortage of IPv4 address space. I do understand that there are some cases where such behaviour is desired. For example, it can be used to achieve VRF route leaking or binding on address from different fibs. I would like to collect such cases to consider supporting them in a different way. The goal is to make net.add_addr_allfibs=0 default behaviour and remove net.add_addr_allfibs. It will simplify kernel fib-related code and allow bringing more fib-related features. It will also improve fib scaling. Timeline: Aug 1: summarising feedback and the usecases, decision on proceeding further Aug 20 (tentative):  patches for supported usecases Sep 15 (tentative):  net.add_addr_allfibs removal. [1]: [base Contents of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=178888&view=markup) [2]: [base Diff of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&) /Alexander