(03-14-2018, 05:44 PM)z4v4l Wrote:Quote:I wonder why did the built in memtest not detect even a single one of these errors in my old device?maybe because it's a bad memtest?
Loooking at the sourcecode of it immediately shows the first obvious problem:
https://github.com/torvalds/linux/blob/m.../memtest.c
in line 52 the compiler optimization is totally alllowed to assume that if (*p == pattern) will always evaluate to true because it can prove it has just filled the same memory with pattern and nobody could have changed it in the mean time (compiler optimization can assume that variables and memory locations don't just change their values on their own, unless explicitly told otherwise), so the compiler can optimize away the entire code path below, it could even optimize away the first loop because it does not change the result of the computation, the entire function becomes a no-op with always the same result.
There should either be a compiler barrier like volatile asm("":::"memory") between the two loops to indicate that something could have changed the memory or the pointer should be declared volatile u64* p to indicate that this memory has the ability to change on its own. The latter would be cleaner and more portable.
(03-14-2018, 05:44 PM)z4v4l Wrote: I hope your new board is OK.
The new board seems OK (at least 1.8G of 2G are ok, cannot yet test the remaining RAM because of a lack of testing tools). memtester shows no errors in the unallocated RAM anymore and file copy does not corupt files anymore. I guess this device is most likely ok.