Date: Fri, 4 Sep 2020 12:19:10 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: onboard wireless on rpi4 Message-ID: <4306A90D-97B9-4DE9-A05A-A91B6F4A587F@yahoo.com> In-Reply-To: <5AF83D16-2432-4EA9-BC2F-373DA8BC3360@googlemail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-4, at 10:44, Klaus Cucinauomo <maciphone2@googlemail.com> = wrote: >=20 > 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=99= t yet merged to 13-current=20 > 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)=20 >=20 > Klaus >=20 >> Am 04.09.2020 um 19:33 schrieb Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org>: >>>=20 >>=20 >> 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 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4306A90D-97B9-4DE9-A05A-A91B6F4A587F>