head -r365677 and later do not have the xhci related DMA problem fixed

[Mark Millard]

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)