Addresses fail with many bits in error bit mask

[laq]

I have checked a computer with memtest 6.3.0 and reports no error. I tried with 4.3.7, and at some point, it exhibited errors with a big bitmask:

Error Confidence Value: 109
Lowest Error Address: 000a7df5380 - 2685.9MB
Higuest Error Address: 000a7df5384 - 2685.9MB
Bits in Error Mask: 72044056
Bits in Error - Total: 10 Min: 1 Max: 9 Avg: 5
Max Contiguous Errors: 2


As so many bits fail (total 16GB in the computer) in these small addresses, I thought that maybe it's not a RAM problem, but something else, like RAM being overwritten by a non-CPU element. Maybe Intel ME?

I also checked with the memtest86+ 5.01 with extra rowhammer https://github.com/CMU-SAFARI/rowhammer
It reports similar errors in the very same addresses, many bits in the bitmask, but only in the test 12 (Rowhammer test).

What can this be? Does it look like faulty RAM? This notebook manufactured by Lenovo (Z50-70) is reported by Lenovo to be tested against Rowhammer problems. https://support.lenovo.com/es/es/pro...ity/row_hammer

Thank you,
laq.

[keith]

Although we can't really comment on a MemTest86+ build that is managed independently of PassMark's MemTest86, the results show that the errors are from Test 3 and not the row hammer test. So I don't think the errors are related to the row hammer bug.

It is possible that there is a BIOS bug that incorrectly identifies a memory region as free memory when it is actually reserved for other use (eg. device memory, memory I/O, etc). So I would check for a BIOS update as well.

Can you also paste the memory map that is logged in the MemTest86.log file when you first ran MemTest86 v6.3. The file should be located under EFI\BOOT\ of the USB drive. It should look something like this in the log file:

2016-01-18 15:12:39 - 0x000000000000 - 0x000000007FFF (32KB) {Boot Services Code}
2016-01-18 15:12:39 - 0x000000008000 - 0x000000057FFF (320KB) {Free Memory}
2016-01-18 15:12:39 - 0x000000058000 - 0x000000058FFF (4KB) {Boot Services Data}
2016-01-18 15:12:39 - 0x000000059000 - 0x00000005EFFF (24KB) {Free Memory}
2016-01-18 15:12:39 - 0x00000005F000 - 0x00000005FFFF (4KB) {Boot Services Data}
2016-01-18 15:12:39 - 0x000000060000 - 0x00000009EFFF (252KB) {Boot Services Code}
2016-01-18 15:12:39 - 0x00000009F000 - 0x00000009FFFF (4KB) {Runtime Services Data}
2016-01-18 15:12:39 - 0x000000100000 - 0x000000FFFFFF (15MB) {Free Memory}
2016-01-18 15:12:39 - 0x000001000000 - 0x0000010FFFFF (1024KB) {Loader Data}
2016-01-18 15:12:39 - 0x000001100000 - 0x0000CDDFEFFF (3276MB) {Free Memory}
2016-01-18 15:12:39 - 0x0000CDDFF000 - 0x0000CDEDCFFF (888KB) {Loader Code}
2016-01-18 15:12:39 - 0x0000CDEDD000 - 0x0000D0034FFF (33MB) {Free Memory}
2016-01-18 15:12:39 - 0x0000D0035000 - 0x0000D0780FFF (7MB) {Boot Services Data}
2016-01-18 15:12:39 - 0x0000D0781000 - 0x0000D0DF4FFF (6MB) {Free Memory}
2016-01-18 15:12:39 - 0x0000D0DF5000 - 0x0000DCFF2FFF (193MB) {Boot Services Data}
2016-01-18 15:12:39 - 0x0000DCFF3000 - 0x0000DDAACFFF (10MB) {Free Memory}
...
etc

[laq]

address map

Notice that one of the screens is from your memtest86 4.3.7, and so is the text I copied. Only the second screen is from memtest86+.

I cannot save the memory map to a file because I only have memtest86 6.3.0 free version. I attach screens.

Thank you for your attention.

[laq]

It seems that 000a7df5384 is in the 0x0000a7df1000-0x0000aa08efff range of "Boot services Data". It would be a bug in memtest86 4.3.7 and memtest86+, maybe fixed in 6.3.0 (hence why it doesn't find anything wrong).

Can it be that the ranges are different in EFI boot and Legacy boot? Here we look at the ranges on EFI boot, and memtest86 6.3.0 doesn't fail at all. If I could see this map in BIOS boot, maybe it show up broken.