From owner-freebsd-arm@freebsd.org Sun Sep 6 04:17:19 2020 Return-Path: Delivered-To: freebsd-arm@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 A14863E0489 for ; Sun, 6 Sep 2020 04:17:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4BkdRL3sJMz4PYF for ; Sun, 6 Sep 2020 04:17:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: R2eOoIsVM1kivQMLaDpnLorLr8eRffvUptH0TbLNLGck0IZq_UDEOCgxmtjPgzD hgvhCx7XHgDDJN.zinSZp3MxjofO9jko4UOdpkl6BDhaZ1NQWemesdMRj03Irr8ik0RfsXB8Ovsw s3d0QPTOF98q.Y8VOIWDXEFHQDbVNSWTJCMKXamODeXM.REhpvkMxpNGiLwfYUtWY5POFfGaUqH2 7mbmUBMdZMU64fSZq8jEOJMFUkMDfzxpKo6rhPNu_FwRRliZOY5LrzTOxOEgm0GT3_fEcyJgfv8j uhL6bdmEnQ.hPxU7xXk3Ph4jgY9OhWwriPpCMJmi2y8M2h.Cr0KsU97JSxilJYjDjb6N.9K_un8_ MVWDK1ukVmBrz9EmXv5FsA3MjFxLqlvSx7DcBA65HoNRak1vZVimZ0e4um6cIjNSClOj.IX.wAIF 1QAO5HJi.QVYN9AOLUjIbVhWWHiVU1s0yv48Kc_RVEboxaIMGB.xFuIu4s_ccEWjI3_yDExz_A58 I0r1lmCoSvYZ8W4Sls7UH3RMSohossJ763kFIs5gzmhBF_dZPH9iU5.S2xlEl_Z4LxfVm0kiCwYC wOUf0eleuc26uX76jwmFtVp36lVqf7I.OOXwTXE1VzWZLWMxUIt68.vXtH9a3gBroyEcgoQPeI_G SAeTZ7bJr4X6Ses_vj5eU4X8iJt.XO0ZA1SNWmDU_cPOzlOJO42jZplPO33ST4lXP1K7rQT2d2AT .9NXKx5bdoRSR2J0NaAOsUmHYPvaY0n8YRCLd1QjxWSY7cFkFrU2ra3GH7wwvQH3.MlYEFNsnbBD 8lKiwMyQOHKhxX1Xqp.UJ9hJvjx5LyIG.EGrPuhLWdrAa3sFarO1sHM82uPvqgIMssnC9cDcQ3kE Ic_xTbbz5_j9A6ldjdquKOnUstG.e4Y_t1jBWMroC7AuKxcyE2YuJJYll3PkqvW3R_RqFrSJf5Vq 7VKWXsQiussdCGAWzCSqIcnna.K9VmaoXedlp8LiNwaDhTWCutVCd27hsh61FAQg7JkkJjAEXSXR T9PMkTs15sM2beDK.olPdUoydZpgd1njr3bsKeR0UJ_j7SsLGI9G3nqvv9yhDa1_gTlg9YZ6yV4l DdjHf7_D1hyowUCHwIVnt6HkpWDUgz6EAuiYmnnX0SoHgoXeARUDofHhu0qvQaOYo76o9u1QGZ1a bOtBtqIPUS5X2jThSy4DzIM_W6mfrSMDqlbQjk5BcB1rjvuPdQ1cXZVG1yOgLqtU0P_zlBAvw4Wr 3leZP50aEZFnauewvpi2BKPXqWE6tZfo.YvAV5j9QglGiioLHJ56mvkZUOMvMVUYhy1fTDH7wxC6 vHZFWkK7gilevjWklFvjTzq7T0.FgAhhSKgxq5YWKBvwu2YwGhOHTq6ciEU59q.Ahs.Pb1aujlTm 8Zg6jIC1VHtjD3OYweAPGYRpJSn1PT1a.F26msOwqpCkZ3p0fmXtML11VGOofXLGpdBfoYf5G4SH dqdCeEmyxSJAGBIUGPEx0ZxCQFIxgme8C..j9ssN8vj5Q1Ov5_Ufjj.vVvS5WKsvOBshclm2Hbfp pP8dsdHbm6IZB.NJk1EsfOHzkUnHrAlUl Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Sep 2020 04:17:16 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f723f8ceb3b1cde6c4597a4c26c80758; Sun, 06 Sep 2020 04:17:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: onboard wireless on rpi4 From: Mark Millard In-Reply-To: Date: Sat, 5 Sep 2020 21:17:10 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8037E5D3-E89E-4AED-8FFE-43D9D83B2BD3@yahoo.com> References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <20200904142255.GC80905@bastion.zyxst.net> <5AF83D16-2432-4EA9-BC2F-373DA8BC3360@googlemail.com> <4306A90D-97B9-4DE9-A05A-A91B6F4A587F@yahoo.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BkdRL3sJMz4PYF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.93)[-0.934]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.068]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.003]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2020 04:17:19 -0000 On 2020-Sep-5, at 01:59, Robert Crowston = wrote: > Regrettably the DMA problem is not fixed. After fixing the bus tag to = correctly represent the DMA limit of the device, it reduced the problem = incidence a lot but sometimes it still happens when the controller is = under load. I think to do with the inbound/outbound memory view on the = controller, i.e. maybe there is crosstalk between inbound and outbound = DMA? I can submit the patch I have but it=E2=80=99s not a 100% fix. >=20 > Did someone tell me this is *not* a problem at all on NetBSD/OpenBSD? Of the two contexts that you mention, I've only used the NetBSD context. Summary for NetBSD: I've never observed evidence of a DMA problem under NetBSD. I just tried making a duplicate of a huge file (11570948096 B) on the USB3 SSD and then diff'ing the result: no differences on a 4 GiByte RPI4B and none on a 8 GiByte RPi4B. (Not that I know the type of test is sufficiently analogous across operating systems to make solid conclusions.) Context: Same RPi4B's that I use with the FreeBSD USB3 SSD, distinct media for NetBSD. Same NetBSD media used for the 8 GiByte RPI4B used and the 4 GiByte RPi4B used. Same vintage uefi/ACPI as used with FreeBSD, but with the 3072 MiB limitation disabled. NetBSD does report the larger RAM sizes. Same type of USB3 SSD as is used for FreeBSD. No microsd card involved in operating the RPi4B, just like for FreeBSD. Use of over_voltage=3D6 and arm_freq=3D2000, like for FreeBSD. And so on: close match (other than the operating systems). Mark > =E2=80=94 RHC. >=20 > On Fri, Sep 4, 2020 at 20:19, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2020-Sep-4, at 10:44, Klaus Cucinauomo wrote: >> > >> > Hi Mark, >>=20 >> Hello. >>=20 >> > as far as I remember(didn=E2=80=99t work the last weeks on = RPI-stuff) >> > the dma-thing only failed on GENERIC-NODEBUG (unexpected controller = detection loops) =E2=80=A6 >>=20 >> Unless trying to help track down a problem at the time, I use NODBG >> kernels. So, for > 3072 MiB, I find that copying huge files and >> diffing/cmp'ing the copies reports mismatches. (I tend to use >> files larger than the RAM but that large has not been required.) >> Note: I boot from and use USB3 SSD without a microsd card being >> involved at any stage. >>=20 >> It is not obvious what the actual file contents are where the >> differences show up. >>=20 >> I've tended to create and use tar's of build trees, created under >> the 3072 MiB configuration to establish large files for such >> tests. Tests under the 3072 MiB configuration have not failed >> when I've tried such. >>=20 >> I have not tried this kind of test under a DBG kernel. >>=20 >> The last I heard about the PCIe DMA handling for > 3072 MiB was >> on 2020-Jul-19 from Robert Crowston: >>=20 >> QUOTE >> You are right that we are not handling the 3 GB DMA limit in the pcie = driver. Unfortunately, it did not seem easy to thread the appropriate = bus tag through without rewriting half the inherited driver stack, and = in my testing the USB driver always allocated its DMA buffers in the = lower 3 GB without being told. But obviously it is the wrong to rely on = luck, so I=E2=80=99ll have a think about it. >> END QUOTE >>=20 >> I've not noticed anything go by that suggested to me that this >> has been addressed. (But I could have just missed it.) >>=20 >> > But it worked on GENERIC and afaik Greg_unrelenting`s dma-fix = isn=E2=80=99t yet merged to 13-current >> > because of that unfixed issue=E2=80=A6 >> > (but you can apply his patch and test)..it should work under = GENERIC without the 3GB-limit(4GB & 8GB-models) >> > >> > Klaus >> > >> >> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm = : >> >>> >> >> >> >> Has the mishandling of the DMA been fixed? I'm still back >> >> at head -r363590 and it was not fixed as of then. I've >> >> had to use the 3072 MiB limit in the uefi/ACPI selections >> >> in order to have a reliable environment. >> >> >> > >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)