onboard wireless on rpi4

[Mark Millard]

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 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’s 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=6 and arm_freq=2000, like for FreeBSD.

And so on: close match (other than the operating systems).

Mark

>     — RHC.
> 
> On Fri, Sep 4, 2020 at 20:19, Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
>> 
>> 
>> On 2020-Sep-4, at 10:44, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
>> >
>> > Hi Mark,
>> 
>> Hello.
>> 
>> > as far as I remember(didn’t work the last weeks on RPI-stuff)
>> > the dma-thing only failed on GENERIC-NODEBUG (unexpected controller detection loops) …
>> 
>> 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’ll 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’t yet merged to 13-current
>> > because of that unfixed issue…
>> > (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 at 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.
>> >>
>> >
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)