Date: Thu, 24 Sep 2020 14:04:17 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: head -r365677 and later do not have the xhci related DMA problem fixed Message-ID: <7CB42754-9EF1-468F-B9C1-8993CB5C0F40@yahoo.com> In-Reply-To: <4432F794-FB30-49A6-B88D-93FF954BDB99@yahoo.com> References: <5A60B29E-0D24-480C-807D-4A5E92D9C92A@yahoo.com> <4432F794-FB30-49A6-B88D-93FF954BDB99@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-24, at 13:24, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Sep-24, at 12:04, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> I finally got around to updating the systems that I have access >> to, including the 8 GiByte RPi4B, from head -r363590 to -r363932 . >> This puts the sytem after then head -r365677 check in of the >> attempted DMA fix that involved restricting the xhci DMA range to >> 1 GiByte. >>=20 >> I've tested head -r363932 under uefi/ACPI v1.20 with the >> 3072 limit disabled and it failed the large file duplicate >> and diff/cmp test: >>=20 >> # cp -aRx /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt_tar >> # diff /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt_tar >> Binary files /usr/obj/clang-armv7-on-aarch64.tar and = /usr/obj/clang-armv7-on-aarch64.alt_tar differ >> # cmp -l /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt_tar | head -30 >> 2633269249 3 0 >> 2633269251 3 0 >> 2633269252 55 0 >> 2633269253 6 0 >> 2633269254 21 0 >> 2633269255 227 0 >> 2633269256 1 0 >> 2633269257 135 0 >> 2633269258 336 0 >> 2633269259 22 140 >> 2633269260 0 100 >> 2633269261 346 0 >> 2633269262 353 0 >> 2633269265 227 0 >> 2633269266 1 160 >> 2633269267 170 140 >> 2633269268 336 100 >> 2633269269 22 0 >> 2633269271 362 0 >> 2633269272 353 0 >> 2633269275 227 0 >> 2633269276 1 0 >> 2633269277 225 0 >> 2633269278 336 0 >> 2633269279 22 0 >> 2633269281 376 0 >> 2633269282 353 1 >> 2633269285 0 1 >> 2633269289 0 223 >> 2633269290 0 321 >>=20 >> For reference: >>=20 >> # ls -ldT /usr/obj/clang-armv7-on-aarch64* >> -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 = /usr/obj/clang-armv7-on-aarch64.alt_tar >> -rw-r--r-- 1 root wheel 11570948096 Jul 18 18:32:37 2020 = /usr/obj/clang-armv7-on-aarch64.tar >>=20 >> (So the over 10 GiByte original file is significantly larger than the >> 8 GiByte RAM.) >>=20 >=20 > I figured I'd gather some more evidence by putting back the > 3072 MiByte limit and diff'ing/cmp'ing the above files and > then making another duplicate and diff'ing it. >=20 > # diff /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt_tar=20 > Binary files /usr/obj/clang-armv7-on-aarch64.tar and = /usr/obj/clang-armv7-on-aarch64.alt_tar differ > # cmp -l /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt_tar | head -30 > 2633269249 3 0 > 2633269251 3 0 > 2633269252 55 0 > 2633269253 6 0 > 2633269254 21 0 > 2633269255 227 0 > 2633269256 1 0 > 2633269257 135 0 > 2633269258 336 0 > 2633269259 22 140 > 2633269260 0 100 > 2633269261 346 0 > 2633269262 353 0 > 2633269265 227 0 > 2633269266 1 160 > 2633269267 170 140 > 2633269268 336 100 > 2633269269 22 0 > 2633269271 362 0 > 2633269272 353 0 > 2633269275 227 0 > 2633269276 1 0 > 2633269277 225 0 > 2633269278 336 0 > 2633269279 22 0 > 2633269281 376 0 > 2633269282 353 1 > 2633269285 0 1 > 2633269289 0 223 > 2633269290 0 321 >=20 > So the copy made without the 3072 MiByte limit appears to be > corrupt as written: it looks like the error is not just at > diff/cmp time. >=20 > Making and testing a .alt2_tar copy: >=20 > # cp -aRx /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt2_tar > # cp -aRx /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt2_tar > # diff /usr/obj/clang-armv7-on-aarch64.tar = /usr/obj/clang-armv7-on-aarch64.alt2_tar=20 > #=20 The duplicated cp line is a copy/paste error: I had copied/pasted the cp line before it finished and copied/pasted the 3 lines after the diff completed --but I did not replace the original cp line like I should have. Only noted so that the structure of my test procedure can be followed as it actually was executed. > So, with the 3072 MiByte limit: no evidence of a problem with = duplicating > the huge file and diff'ing the result. =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?7CB42754-9EF1-468F-B9C1-8993CB5C0F40>