Date: Sat, 5 Sep 2020 22:40:38 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: Robert Crowston <crowston@protonmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: onboard wireless on rpi4 Message-ID: <CANCZdfqZZHRQFD2W5MqSpyR-eFGRABN-X37yRBcRNcxBzdtsPg@mail.gmail.com> In-Reply-To: <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> <CACNAnaHRn5VGM8G6_kxj7S%2B0LQOSG3CK9=umxj74Qc5v%2BNOLeA@mail.gmail.com> <BE2FA7D2-1266-496E-B808-55204B1AB21A@yahoo.com> <5AF83D16-2432-4EA9-BC2F-373DA8BC3360@googlemail.com> <4306A90D-97B9-4DE9-A05A-A91B6F4A587F@yahoo.com> <sinTekBDB_YOboAoJU0Uld7IaGBlIJ68dPgxuO3kcUuZpTH9KxyTquRgPxU7-0qlvofrr_8HzdCbNL-nRNaT6-OeIyIuLUUvYSGEwEzRVbc=@protonmail.com> <8037E5D3-E89E-4AED-8FFE-43D9D83B2BD3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 5, 2020, 10:17 PM Mark Millard via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > On 2020-Sep-5, at 01:59, Robert Crowston <crowston at protonmail.com> > 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 und= er > load. I think to do with the inbound/outbound memory view on the > controller, i.e. maybe there is crosstalk between inbound and outbound DM= A? > I can submit the patch I have but it=E2=80=99s not a 100% fix. > > > > 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). > I thought I read they added the busdma constraints we are missing... Warner > Mark > > > =E2=80=94 RHC. > > > > On Fri, Sep 4, 2020 at 20:19, Mark Millard via freebsd-arm < > freebsd-arm@freebsd.org> wrote: > >> > >> > >> On 2020-Sep-4, at 10:44, Klaus Cucinauomo <maciphone2 at googlemail.co= m> > wrote: > >> > > >> > Hi Mark, > >> > >> Hello. > >> > >> > 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 > >> > >> 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. > >> > >> It is not obvious what the actual file contents are where the > >> differences show up. > >> > >> 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. > >> > >> I have not tried this kind of test under a DBG kernel. > >> > >> The last I heard about the PCIe DMA handling for > 3072 MiB was > >> on 2020-Jul-19 from Robert Crowston: > >> > >> 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 > >> > >> I've not noticed anything go by that suggested to me that this > >> has been addressed. (But I could have just missed it.) > >> > >> > 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 < > freebsd-arm@freebsd.org>: > >> >>> > >> >> > >> >> 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. > >> >> > >> > > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqZZHRQFD2W5MqSpyR-eFGRABN-X37yRBcRNcxBzdtsPg>