onboard wireless on rpi4

[Robert Crowston]

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?

— 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)
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"