Date: Sat, 19 Sep 2020 18:32:05 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: Hans Petter Selasky <hps@selasky.org>, myfreeweb <greg@unrelenting.technology>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context Message-ID: <473332B8-B0BC-41BB-A36F-500B9416BFBB@yahoo.com> In-Reply-To: <8E916B11-83AB-4045-A501-8F64AD93AF8A@googlemail.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <D28FEE99-A2CA-484E-A5E9-312334CF3FE3@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <CE9D7856-0179-4C9B-8367-AFBD8EAD4CC2@yahoo.com> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> <3D0CFAD6-A93B-401E-82CD-831E22BD8D7A@yahoo.com> <486e827b-b868-abe1-0ac9-478227779a63@selasky.org> <8E916B11-83AB-4045-A501-8F64AD93AF8A@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-19, at 16:28, Klaus Cucinauomo <maciphone2@googlemail.com> = wrote: >=20 >> Am 19.09.2020 um 23:18 schrieb Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org>: >> The test booted just fine, no =E2=80=9EResetting controller=E2=80=9C = notices or the >> like. =E2=80=A6. >=20 >> Am 20.09.2020 um 00:38 schrieb Hans Petter Selasky <hps@selasky.org>: >>=20 >> Hi, >>=20 >> Here you go: >>=20 >> https://svnweb.freebsd.org/changeset/base/365918 >>=20 >> =E2=80=94HPS >=20 > from my understanding by only quickreading this thread : > yours rS365918 fixes it so that D25219 was a valid patch =20 > that can also be committed? If so, great ! >=20 head -r365928 is about avoiding having a misconfigured initial xhci "event ring" setup from part of the setup not being observed by the xhci when it needs to be: forcing local changes to propagate to everywhere needed first. (Nothing I've done has checked if reconfiguration of the event ring is possible via some other FreeBSD code or, if reconfiguration works if it is possible.) So: unrelated fixes. head -r365928 does nothing about the RPi4B failing the large file duplication and diff tests when the RPi4B has more than 3072 RAM configured. It has nothing to do with bus_dma_tags inability to describe even one valid range in the middle of RAM (2 invalid ranges, one at the beginning and one at the end), much less more complicated contexts. So far as I know, https://reviews.freebsd.org/D25219 is waiting on enough context to go with it that, for example, huge file duplication and diff'ing tests finally pass when UEFI/ACPI has more than 3072 MiB selected. D25219 may be necessary but is not sufficient last I tested such. For the u-boot context, my guess is that the patch that restricted the size of the DMA region to 1 GiByte or so to allow things to progress there is effectively a work around that avoids touching another bug(s) some place. (NetBSD and Linux do not have such a small size limit. OpenBSD choose its small limit for other reasons.) I've never figured out anything I could do to gain any useful evidence of the internal problem(s) when allowing more than 3072 MiB on a FreeBSD RPi4B. =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?473332B8-B0BC-41BB-A36F-500B9416BFBB>