Re: head -r365677 and later do not have the xhci related DMA problem fixed
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2020-Sep-24, at 12:04, Mark Millard <marklmi at yahoo.com> wrote: > 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. > > 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: > > # 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 > > For reference: > > # 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 > > (So the over 10 GiByte original file is significantly larger than the > 8 GiByte RAM.) > 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. # 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 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. Making and testing a .alt2_tar copy: # 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 # So, with the 3072 MiByte limit: no evidence of a problem with duplicating the huge file and diff'ing the result. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"