onboard wireless on rpi4

[Warner Losh]

On Sat, Sep 5, 2020, 10:17 PM Mark Millard via freebsd-arm <
freebsd-arm at 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 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).
>

I thought I read they added the busdma constraints we are missing...

Warner

> 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)
>
> _______________________________________________
> 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"
>