Date: Sun, 20 Sep 2020 13:33:55 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: 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: <9A82725E-CE5C-4AD5-96D7-D04335DF9B23@yahoo.com> In-Reply-To: <B02E6A40-0901-47B6-AAEA-3941D1091D33@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> <473332B8-B0BC-41BB-A36F-500B9416BFBB@yahoo.com> <B02E6A40-0901-47B6-AAEA-3941D1091D33@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-20, at 06:15, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: >=20 >=20 >> Am 20.09.2020 um 03:32 schrieb Mark Millard <marklmi at yahoo.com>: >>=20 >> ...So: unrelated fixes. ... >=20 >> 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.) >=20 >=20 > Ah, O.K., thanks, got it... >=20 > ..the bug is that dma of 1GB is always safe but there is no = "OS-pre-implementation"=20 > for 3GB buffer in 64-bit for RPI4=E2=80=A6 while , the pcie-device = itself DOESN`t have the=20 > 1GB - limit like other peripherals.. > .. > NetBSD also did it that (OpenBSD-)way at first , not for other but the = same reason,=20 > I GUESS(!).. while , as you know,guessing(and dma) isn't really my = area of expertise ;-) : FYI: Here is what I found about OpenBSD's choice of its limit: "OpenBSD can deal with the 3GB limit. In fact it imposes a 1GB DMA = limit because there are additional DMA restrictions for the SD = controller." ( Mark Kettenis Aug 24, 2020; 4:29am Re: Discuss UEFI = settingsin arm64.html/INSTALL.arm64 ) (Not that I have background knowledge that would confirm or deny the = claim.) > = https://github.com/NetBSD/src/commit/5cb936da2a4720fa51984394998fa62c62aea= 7cd#diff-8e16a107fed72481ef0342727619cfa8 : >=20 > #define BCM2711_DMA_SIZE 0x3c000000 =E2=80=A6,( which is 1GB) >=20 > jmcneill seems to have then added some voodoo in NetBSD : > = https://github.com/NetBSD/src/commit/9bf4ec11d132c8b296a3926483aa0b8d43fa4= 3ad >=20 > the Tux has fixed it there : > = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dr= ivers/acpi/arm64/iort.c?h=3Dv5.8&id=3Dbcf876870b95592b52519ed4aafcf9d95999= bc9c#n1125 > ..they have things like dma_zone or so... >=20 > So hardcoding the 1GB constraint into = https://reviews.freebsd.org/D25219=20 > or > give it a fine grain dma range to 3GB should fix it... An interesting item from the Fedora 33 branch (late Oct. release = planned): Note below the 3 GiByte wide DMA32 range is listed as shifted by 1 = GiByte. This is for a 5.8.7-300.fc33.aarch64 kernel. (I used the uefi/ACPI v1.20 = to boot Fedora server, not limiting to 3072 MiB.) [ 0.000000] NUMA: Faking a node at [mem = 0x0000000000000000-0x00000001ffffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x1fefec8c0-0x1ff002fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] DMA32 [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Device empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem = 0x0000000000000000-0x00000000001fffff] [ 0.000000] node 0: [mem = 0x0000000000200000-0x00000000337d7fff] [ 0.000000] node 0: [mem = 0x00000000337d8000-0x000000003387ffff] [ 0.000000] node 0: [mem = 0x0000000033880000-0x000000003390ffff] [ 0.000000] node 0: [mem = 0x0000000033910000-0x000000003398ffff] [ 0.000000] node 0: [mem = 0x0000000033990000-0x00000000339affff] [ 0.000000] node 0: [mem = 0x00000000339b0000-0x0000000033a2ffff] [ 0.000000] node 0: [mem = 0x0000000033a30000-0x0000000036efffff] [ 0.000000] node 0: [mem = 0x0000000036f00000-0x00000000372dffff] [ 0.000000] node 0: [mem = 0x00000000372e0000-0x000000003b2fffff] [ 0.000000] node 0: [mem = 0x0000000040000000-0x00000000fbffffff] [ 0.000000] node 0: [mem = 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Zeroed struct page in unavailable ranges: 552 pages [ 0.000000] Initmem setup node 0 [mem = 0x0000000000000000-0x00000001ffffffff] I don't know enough to know if this indicates a problem in/for Fedora for an RPi4B or not. I just did a "yum update" and the 5.8.10-300.fc33.aarch64 kernel that resulted boots reporting the same for DMA32: [ 0.000000] NUMA: Faking a node at [mem = 0x0000000000000000-0x00000001ffffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x1fefed8c0-0x1ff003fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] DMA32 [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Device empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000001fffff] [ 0.000000] node 0: [mem 0x0000000000200000-0x00000000337e7fff] [ 0.000000] node 0: [mem 0x00000000337e8000-0x000000003388ffff] [ 0.000000] node 0: [mem 0x0000000033890000-0x000000003390ffff] [ 0.000000] node 0: [mem 0x0000000033910000-0x000000003398ffff] [ 0.000000] node 0: [mem 0x0000000033990000-0x00000000339affff] [ 0.000000] node 0: [mem 0x00000000339b0000-0x0000000033a2ffff] [ 0.000000] node 0: [mem 0x0000000033a30000-0x0000000036efffff] [ 0.000000] node 0: [mem 0x0000000036f00000-0x00000000372dffff] [ 0.000000] node 0: [mem 0x00000000372e0000-0x000000003b2fffff] [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000fbffffff] [ 0.000000] node 0: [mem 0x0000000100000000-0x00000001ffffffff] [ 0.000000] Zeroed struct page in unavailable ranges: 536 pages [ 0.000000] Initmem setup node 0 [mem = 0x0000000000000000-0x00000001ffffffff] =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?9A82725E-CE5C-4AD5-96D7-D04335DF9B23>