系统：嵌入式、arm64 (4xCortexA53)、2GB LPDDR3、eMMC 内存、Linux、内核 5.4.17。
我遇到了随机系统崩溃的问题，在正常操作中，该问题会每 2 天到每“几周”发生一次，具体取决于设备或设置。我们将其范围缩小到以下可能触发根本原因的测试场景：
- 从文件系统（rootfs、只读分区）读取文件：/usr/bin/、/etc/、/usr/lib 等
- 从文件计算 md5sum 并将其写入 tmp/log 文件
- 重复循环 - 如果 md5sum 在下次运行时不同 - 保存“修改后的”文件。
看起来，经过多次循环后，文件开始有所不同，并且可能会发生在随机文件上：二进制文件、lib 或脚本。这种差异并非完全随机：只有每隔一个字节都是错误的。它可能是奇数或偶数字节，但绝不会是完全随机的混乱。我们无法追踪坏字节中的任何模式（即单个位翻转、混合其他文件等）。格式错误的块的大小也是随机的（无论如何都超过一页）。
要将文件恢复到“正常状态”，只需使用 echo 到 /proc/sys/vm/drop_caches 来清除页面缓存或 inode 缓存即可。因此，这不是 eMMC 内存的问题。定期清除缓存也无济于事 - 每次运行在某种程度上都是独立的，并且可能会导致问题。
我怀疑 DDR 设置/布局存在低级问题、页面缓存问题（可能性较小）或严重内存泄漏。
问题：
是否可以使用某些 Linux 工具获取已分配的格式错误页面的物理地址？我想有可能获得文件的 mmped 内存块，找到虚拟页面，将虚拟地址转换为物理地址 - 有任何单一工具可以帮助实现这一点吗？
DDR 刷新时序会在这里发挥作用吗？
我读过有关 DDR 中的“生锤”问题，但这似乎非常具体，也不太可能。有人有一些经验吗？
我将不胜感激任何提示。谢谢
答案1
禁用 DDR 自刷新会有所帮助。似乎与 CPU 和/或 DDR 供应商相关，而不是一般 DDR 问题。需要在 DDR 设置阶段在引导加载程序中完成。