Memtest passes on faulty RAM

[spammy]

I'm using the Memtest that comes with AntiX (I can determine the version if required).

After 3 rounds of 8 passes, no errors were found.

However an issue with the PC has been narrowed to the RAM. The issue is repeatable by running checksums recursively on a tree of many large-ish binary files. In one instance I was seeing the following:

$ sudo sha256sum ./data/8/8952
47fe0ee39112782911a19075d32d4f3b532c2193dcf3249855a9d01e87b4914d ./data/8/8952
$ sudo sha256sum ./data/8/8952
b0f3033153d64ebfe288ab92050921c491a0752321499215dc16af9dc2f1ddc4 ./data/8/8952
$ sudo sha256sum ./data/8/8952
5c727ef68f4b787e9a3251266af100ac3009325fdf9f08994b6856cd8b26e2a4 ./data/8/8952
$ sudo sha256sum ./data/8/8952
2fb7d971b3bf45bc14fb8b7687b42dbb888cd34077a4c6315462efb028708d32 ./data/8/8952​

Replacing the RAM results in a stable system.

Whether the RAM is faulty or incompatible or if the error lies elsewhere in the system, should we expect Memtest to pick up on this kind of issue?

[David (PassMark)]

You might be confused. As far as we know MemTest86 isn't included with AntiX.
Maybe it was some other memory testing application you are using (maybe the forked MemTest86+ version).

If the error only happens reading files, then it might be a DMA transfer error. Our software has a DMA test, but the less functional MemTest86+ version doesn't.

[spammy]

To clarify this is the AntiX Live Boot USB as per: https://antixlinux.com/the-most-exte...-on-the-planet. I just booted with it and the boot entry is labelled "64-bit UEFI" and loads up "Passmark Memtest86 V7.3 Free".

In (T)est selection there are 14 tests available and selected that were run for 8 passes. I'm not sure which is the DMA test but they all pass.

Edit: Just downloaded v11.1 and see an "experimental" DMA test. I've enabled it and am running.

[spammy]

Ran 4x DMA test passes with no errors.

[David (PassMark)]

There is also a chance the the bad RAM

1. Is in an area that isn't able to be tested. Some RAM is reserved by BIOS for it's own use and other hardware. See example below. Only the free memory can be tested. This can amount to around 5% of total RAM. But having RAM errors in the reserved areas can still cause system instability.
2. Only manifests itself under high system load. For example the system temperatures might be hotter once you are in Windows with the system under load. Or it might be EMI effects from the other systems components (disk, network, GPU) that are more active when in Windows. For this you might want to try BurnInTest as it contains a RAM test and can also provide general system load.
3. Isn't really bad RAM. But it is some device driver in Windows corrupting memory. But if you have replace the RAM with identical RAM and done testing in identical circumstances, this is less likely.

Example of a typical memory map

[spammy]

Thanks - I'm running Linux (debian), and see the issue across other distributions. I'll note the burn in test for next time, although FYI the console output from the OP was on an idle system.

This report was mainly for academic reasons as I am am switching the RAM, and if memtest is purely to test for idle failures then that makes sense. I guess I've learned that that may not be the full story and passing does not mean the ram will perform without errors under real life workloads.

Thanks for the tool and engagement.