DDR 메모리 오류 또는 페이지 캐시 손상이 있습니까?

시스템: 임베디드, arm64(4xCortexA53), 2GB LPDDR3, eMMC 메모리, Linux, 커널 5.4.17.

장치나 설정에 따라 정상 작동 시 2일마다 또는 "주"마다 발생하는 임의의 시스템 충돌이 발생합니다. 근본 원인을 유발할 수 있는 다음 테스트 시나리오로 범위를 좁혔습니다.

1. 파일 시스템(rootfs, 읽기 전용 파티션)에서 파일 읽기: /usr/bin/, /etc/, /usr/lib 등
2. 파일에서 md5sum을 계산하여 tmp/log 파일에 씁니다.
3. 루프를 반복합니다. 다음에 실행할 때 md5sum이 다른 경우 "수정된" 파일을 저장합니다.

많은 루프를 거친 후 파일이 다르게 보이기 시작하는 것으로 보이며 이는 바이너리, libs 또는 스크립트와 같은 임의의 파일에서 발생할 수 있습니다. 이 차이는 완전히 무작위가 아닙니다. 다른 모든 바이트만 잘못되었습니다. 홀수 또는 짝수 바이트일 수 있지만 완전히 무작위로 엉망이 되는 것은 아닙니다. 불량 바이트의 패턴(예: 단일 비트 뒤집기, 다른 파일과 혼합 등)을 추적할 수 없었습니다. 잘못된 블록의 크기도 무작위입니다(어쨌든 한 페이지 이상).

파일을 "정상 상태"로 복원하려면 /proc/sys/vm/drop_caches에 대한 에코를 사용하여 페이지 캐시 또는 inode 캐시를 지우십시오. 따라서 이는 eMMC 메모리의 문제가 아닙니다. 정기적으로 캐시를 지우는 것도 도움이 되지 않습니다. 각 실행은 다소 독립적이며 문제를 일으킬 수 있습니다.

DDR 설정/레이아웃과 관련된 낮은 수준의 문제, 페이지 캐시 문제(가능성은 낮음) 또는 심각한 메모리 누수가 의심됩니다.

질문:

1. 일부 Linux 도구를 사용하여 할당된 잘못된 페이지의 물리적 주소를 얻을 수 있습니까? 파일의 mmped 메모리 블록을 가져오고, 가상 페이지를 찾고, 가상 주소를 실제 주소로 변환하는 것이 가능하다고 생각하고 싶습니다. 이에 도움이 될 수 있는 단일 도구가 있습니까?

2. DDR 새로 고침 타이밍이 여기서 작동합니까?

3. DDR의 "원시 망치" 문제에 대해 읽었지만 이는 매우 구체적이고 가능성이 낮아 보입니다. 누구든지 경험이 있습니까?

어떤 조언이라도 감사하겠습니다. 감사해요