MemTest86 6.2.0 issues in parallel mode and certain CPU cores

[keith]

Hi, i have similar problem. logs and html attached
iam using v 6.2.0
https://drive.google.com/file/d/0B1Z...ew?usp=sharing
https://drive.google.com/file/d/0B1Z...ew?usp=sharing
sorry, i cant attached files in your file uplod( iam using google drive.
in single CPU mode pass 1 run without any errors.
in multiple CPU mode i have a lot of same errors in test 3. Than i stopped test.
Iam trying to change ram slot, it didnt help.
May be i need to test RAM with lower version of Memtest?
The reason for test is that i have problem like irql_not_less_or_equal, iam not writing code of error =( and i cheked HDD. HDD is OK.
PS. sorry for my eng =)

It looks like you may have buggy UEFI BIOS firmware which is causing problems when running MemTest86 in multi-CPU mode. So I would check to see if there is an updated BIOS from the motherboard vendor. I have added your board to the list here.

According to https://msdn.microsoft.com/en-us/library/ms854226.aspx:

This error usually occurs after the installation of a buggy device driver, system service, or BIOS.

So it seems more likely it is a driver or BIOS issue rather than defective RAM.

[mig]

Solution?

Is there some solution from within MT86 6.x that could overcome this Parallel issue? We can not expect that new BIOS-es will be released. Is there some kind of conclusion on this problem, as it is non existent when using non-UEFI v4.3.7 with all cores running in parallel

Kind regards

[keith]

The reason that it is difficult to workaround the reported multiprocessor issues is because of the platform differences between BIOS and UEFI.

The legacy BIOS platform specifies only the bare minimum in order to boot the operating system. This reduces the complexity that BIOS developers need to implement a fully functional BIOS. However, this also reduces the sophistication of applications that can run pre-OS boot (such as nice graphics, file system support, network support, etc.). Because there is no multiprocessor support provided the BIOS, handwritten assembly code was required to perform the necessary multiprocessor initializations in MemTest86 v4 in order to support the parallel, round robin and sequential modes. On the plus side, this allows us to fix the code directly if there are any issues with the multiprocessor functionality.

On the contrary, the newer UEFI is almost like a mini operating system that provides typical OS services such as disk, graphics, mouse + keyboard, network, disk (+ file system), and multiprocessing. This allows UEFI applications such as MemTest86 v6 to take advantage of the various UEFI services and offer functionality more similar to what you can run on an OS such as Windows. However, this puts the onus on the UEFI firmware developers to provide a proper implementation of the various UEFI services. So if there are bugs with the multiprocessor functionality of MemTest86 v6 as we have seen, it can only be fixed within the UEFI firmware itself as this is where the multiprocessor code lies.

This is a consequence of the complexity tradeoff between the BIOS and UEFI platforms.

[mig]

Well another peculiar issue with v6.3 so it is not a BIOS, 2 different boards on 6.3 now shows thousands of errors in multi-CPU selection:

Asus M5A97 Evo R2.0 and Gigabyte GA-970A-DS3P all with newest BIOS.

On v6.2 I've experianced blockage and on 6.3 errors. Everything is good on 1 CPU and in multi-CPU on 4.3.7. CPU was FX-8320.

Are you 100% sure that it is not the code to blame?

[David (PassMark)]

Mig,

Can you Email us the log of the errors.

A log file ('MemTest86.log') is automatically created and updated while MemTest86 v6 is running. This file is saved in the 'EFI/BOOT' directory in the USB drive's first partition.

[Harry]

CPU parallel test mode and address 0 errors: Check your CSM setting in UEFI BIOS!

Hi Guys

regarding CPU test mode "parallel" and strange "addr. 0" errors:

I own two ASRock Boards (Q1900B-ITX and Q2900-ITX, Quadcore Celeron/Pentium, latest BIOS installed), each fitted with 2 pairs of Corsair Vengeance 8GB DDR3L CMSX16GX3M2B1600C9 (so 16 GB in sum per Board).

In concern about very rare / sporatic occurring Win10 freezes (most times when using Firefox x64) I was going to check the RAM using MemTest86 6.3.0 (USB).

Result: Most times the test # 3, 4, 5, 7, 8, 9 and 13 has reported addr. 0 errors when using parallel CPU mode (never in single mode), and for 90% triggered by CPU 1. Curious: Just the LSB of the DWORD did differ between "expected" and "actual".

Example:



I couldn't beleave, that this was caused by the RAMs.

Then I could figure out by chance:
If "CSM" (Compatibility Support Module in UEFI BIOS) is set at "OFF", I get the errors.
If "ON", then there is absolutely no error coming up!

[keith]

Thanks for letting us know.

Yes, it seemed unlikely that the errors were caused by a RAM fault which consistently appeared in the LSB of address 0. It is more likely that the UEFI BIOS was erroneously using memory that it has marked "free" for use. I'm not sure what enabling "CSM" does internally in the BIOS code but it seems to be a functional workaround for the MemTest86 errors, as you demonstrated.

[Harry]

Yes, I think so too.

Today I've reported that problem to ASRock support because I'm very sure, that it's caused by UEFI and alike it happens on each of my 2 ASRock miniITX boards (they have slightly differend CPUs).

Side note - since I use Firefox x86, Win10 freezes did'n appear anymore by now. Or maybe it was fixed with M$ KB3156421 ... should check that out using Firefox x64 once more.