Change Details

Beyond creating, say, huge tar files ( such as of /usr/ports/ ) on RPi4B's, duplicating them, and diff'ing the two copies and some normal-operation without noticing problems: good question. I do use the patch in all my buildworld's that I install, not just for RPi4B's: ThreadRipper 1950X, HoneyComb, MACCHIATObin Double Shot, Rock64, OrangePi Plus 2ed, RPi3B, RPi2B. But, except for activity that happens to be buildworld or buildkernel, or poudriere bulk activity, my normal use is rather limited testing. I have the patch in my builds for main [so: 14], stable/13 , releng/13.1 , and releng/13.0 . I'm unsure if there is anything that FreeBSD supports besides a RPi4B B0T stepping that provides a way to have testing potentially fail by needing to use the new code (D25219 overall, not just my specific adjustment). Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration. I've never had access to Pi400's, C0T stepping or Rev 1.5 RPi4B's, or so on.

Beyond creating, say, huge tar files ( such as of /usr/ports/ ) on RPi4B's, duplicating them, and diff'ing the two copies and some normal-operation without noticing problems: good question. The modern cylinder related validations in UFS do make the failures of the existing FreeBSD code on 8 GiByte RPi4B's quickly obvious, unlike when I originally submitted material for this. I do boot a HoneyComb and a MACCHIATObin Double Shot that are ACPI based but do not have such odd DMA limitations. Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration. I've never had access to Pi400's or such. I do now have access to one "C0T" RPi4B 8 GiByte. I does turn out that the existing RPi4B EDK2 UEFI/ACPI (1.33) imposes the 3 GiByte DMA limit for XHCI use, even for "C0T" RPi4B's that do not need the limit. The EDK2 implementation has it hand coded to enforce that limit (or less) in its _DMA information and does not adjust. This somewhat constrains what testing RPi4B's can get.

Beyond creating, say, huge tar files ( such as of /usr/ports/ ) on RPi4B's, duplicating them, and diff'ing the two copies and some normal-operation without noticing problems: good question. I do use the patch in all my buildworld's that I install, not just for RPi4B's: ThreadRipper 1950X, HoneyComb, MACCHIATObin Double Shot, Rock64, OrangePi Plus 2ed, RPi3B, RPi2B. But, except for activity that happens to be buildworld or buildkernel, or poudriere bulk activity, my normal use is rather limited testing. I have the patch in my builds for main [so: 14], stable/13 The modern cylinder related validations in UFS do make the failures of the existing FreeBSD code on 8 GiByte RPi4B's quickly obvious, releng/13.1 ,unlike when I originally submitted material for this. and releng/13.0 I do boot a HoneyComb and a MACCHIATObin Double Shot that are ACPI based but do not have such odd DMA limitations. I'm unsure if there is anything that FreeBSD supports besides a RPi4B B0T stepping that provides a way to have testing potentially fail by needing to use the new code (D25219 overall,Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration. I've never had access to Pi400's or such. not just my specific adjustment)I do now have access to one "C0T" RPi4B 8 GiByte. Note: On RPi4B's with < 4 GiBytes of RAM, or EDK2 configured to limit themselves to 3 GiBytes, I've never seen problems, patched or not. Only 4 GiByte and 8 GiByte ones showed the problem, with or without D25219's patch. No other kind of system ever showed the problem in any configuration.I does turn out that the existing RPi4B EDK2 UEFI/ACPI (1.33) imposes the 3 GiByte DMA limit for XHCI use, I've never had access to Pi400's,even for "C0T" RPi4B's that do not need the limit. C0T stepping or Rev 1.5 RPi4B's,The EDK2 implementation has it hand coded to enforce that limit (or less) in its _DMA information and does not adjust. or so onThis somewhat constrains what testing RPi4B's can get.