MEM TEST V10.6 run 49 hours error (Errors:10000)

[Candy Weng]

"It appears that I'm encountering failures during the MEM TEST V10.6, with errors consistently occurring after 49 hours. This issue has occurred across three instances, all displaying the same problem (as shown in the image). Could I kindly ask for assistance from experts to diagnose the underlying cause of this issue?"

[Richard (PassMark)]

Are the errors only occurring after 49 hours have passed? Or are there errors before then?

Maybe they are real errors?

Likely unrelated, but try testing with current release, if the error still persists, you can send in the debug logs and we can take a look.

[Candy Weng]

Hello, these errors seem to occur within a minute just after 49 hours have elapsed, as if there's some sort of pattern to it. I've uploaded the test report for your review. Thank you.

[David (PassMark)]

Maybe co-incidence or maybe not.
We have had one another report of a machine getting errors only after 49 hours of testing (49 hours and 4min to be exact). That report was in 2019 and was with a ATOM 3950 CPU. You are using a ATOM 3940 CPU. So this is really the same CPU.

Link to that other report is here
https://forums.passmark.com/memtest8...4265#post44265

That other customer was able to send in a log file and in their case it seemed to be a BIOS bug.

[Candy Weng]

Hi All
The platform I'm encountering issues with is Intel Atom® x5-E3940, but I don't know how to resolve it.

[David (PassMark)]

As suggested above, posting the debug logs would be a start.

But if it is a BIOS firmware bug, we aren't going to be able to fix it for you. You'll need to contact the system vendor.

[Candy Weng]

I am currently using version 10.6 PRO and I am seeking the update logs for each version. Version 10.7 has provided a detailed support list. Concerning the INTEL ATOM series, the CPU I am currently using is Apollo Lake, which does not appear in the list (only Elkhart Lake is listed).


According to past update logs, Apollo Lake received an update in version 7.3. I happen to have version 7.2 nearby and am currently conducting cross-validation. I want to confirm whether Memtest86 supports older versions. If after cross-validation, the issue is not present in the older version, what could be the possible cause of the problem?

[David (PassMark)]

...update logs for each version

You can find the list of What's new here
https://www.memtest86.com/whats-new.html

Version 10.7 has provided a detailed support list

The list you are referring to is just for reporting correct memory controller information. This is for correct reporting of current RAM clock speed & timings. It doesn't impact the actual RAM testing.

All x86 systems with UEFI are supported for RAM testing (and many ARM systems as well).

what could be the possible cause of the problem?

A BIOS bug is our best guess with the limited information.

[Candy Weng]

Without modification to the BIOS, we found that when running MEM TEST V10.6 with the CPU setting option set to "All CPUs", errors occur after 49 hours. However, if the CPU setting option is not set to "All CPUs" (only running on a single core), the test can pass smoothly, running for >100 hours without any failures. Have you encountered a similar situation? Can you provide any advice? Thank you.

[David (PassMark)]

Can you provide any advice

Only what we have already provided. A BIOS bug is our best guess with the limited information.

[David (PassMark)]

We got log files via Email.
The logs were from the old V7 release of the software, which we no longer support. V10.7 is the current release. See
https://www.memtest86.com/whats-new.html

But none the less, these lines were found in the log file.

MPSupportTestMPServices - AP dispatch test
MPSupportTestMPServices - Starting AP#1
MPSupportTestMPServices - Starting AP#2
MPSupportTestMPServices - Starting AP#3
MPSupportTestMPServices - Waiting for AP's to complete execution
MPSupportTestMPServices - CPU #3 completed but did not signal (event wait time = 1001ms)
MPSupportTestMPServices - CPU #1 completed but did not signal (event wait time = 1018ms)
MPSupportTestMPServices - CPU #2 completed but did not signal (event wait time = 1033ms)
MPSupportTestMPServices - AP dispatch test complete
MP test failed. Setting default CPU mode to SINGLE

MP = Multiprocessor
BSP = Bootstrap CPU (the main CPU core, which is started first)
AP = Application CPU (this is a CPU core)

So this system failed the Multi-process test. The software forced the CPU test mode to Single thread as a result. But the user overrode that setting and selected Multi-process testing anyway. Which unsurprisingly failed.

So this is a UEFI bug. You can also find some details of the issue here
https://forums.passmark.com/memtest8...election-modes
We have seen this before on older systems.