MemTest86 hang during Round Robin and Sequential CPU tests

[capzfelix]

MemTest86 works on testing all my DDR3 RAM (12Gb total) under single and parallel CPUs mode. However, when I set Round Robin CPU, the test always failed during Hammer test and worst when set Sequential CPU, the test hang after 5 second running.

What could be the issue here? I am using the latest 6.1.0 version.

[keith]

Could be a BIOS firmware issue. Try to see if there is an updated BIOS.

You can also post or send us the MemTest86.log under EFI\BOOT\ in the USB drive

[capzfelix]

Log file uploaded https://www.dropbox.com/s/xjhjovfiui...est86.log?dl=0

Not sure if MemTest86 be able to log anything when the hang happened. The whole PC basically freeze when it happened and require hard-reset to reboot it.

[keith]

Thanks for uploading the log.

It looks like a firmware issue that affects Round Robin/Sequential CPU modes. It seems to freeze after cycling through all CPU's the first time. This can only be fixed by a firmware update, however.

[capzfelix]

Thanks for uploading the log.

It looks like a firmware issue that affects Round Robin/Sequential CPU modes. It seems to freeze after cycling through all CPU's the first time. This can only be fixed by a firmware update, however.

How does both modes work in term of cycling the cpu's? Why for round robin mode, it only hang at mid way of hammer test and for sequential mode, it hang after 5s of starting first test.

[capzfelix]

Thanks for uploading the log.

It looks like a firmware issue that affects Round Robin/Sequential CPU modes. It seems to freeze after cycling through all CPU's the first time. This can only be fixed by a firmware update, however.

I am using the latest BIOS revision available for my motherboard. It was released back in April this year. Why this could be due to BIOS issue? Could it be other factors like motherboard or CPU issue as well?

[David (PassMark)]

Just for the record, this is a Gigabyte Z97M-D3H motherboard and i7-4790K CPU, right?

[capzfelix]

Just for the record, this is a Gigabyte Z97M-D3H motherboard and i7-4790K CPU, right?

Yeah, you are right.

[tinstaafl]

Hello. I was searching for an answer to the same problem discussed in this thread ... "MemTest86 hang during Round Robin and Sequential CPU tests".

I did read the manual. It does make a point that multicore CPU support can be system dependent.

I have been able to reproduce this error at will on two PC's with the same motherboard, CPU, and latest UEFI BIOS version 1203. I can also avoid the error by either running MemTest86 v4.x or disabling Hyperthreading in my system before running MemTest86 v6.2.0.

In the second case, the CPU switching only occurs between the two real cores and not the virtual ones. In fact, without Hyperthreading enabled, MemTest86 can only "see" two CPU's, rather than 4.

My system specs are:
Intel Core i3-3240 Ivy Bridge LGA1155 (3.4GHz dual core + Hyperthreading for 4 virtual cpu)
ASUS H61M-A/USB3
System 1 8GB RAM: Kingston HyperX 4GBx2 SDRAM DDR3-1600 9-9-9-27
System 2 4GB RAM: Crucial Ballistix 2GBx2 SDRAM DDR3-1600 9-9-9-24

[keith]

It looks like it could be a UEFI BIOS firmware issue when switching between processors.

If you send us or post the MemTest86.log, we can confirm if that's the case.

[tinstaafl]

It looks like it could be a UEFI BIOS firmware issue when switching between processors.

If you send us or post the MemTest86.log, we can confirm if that's the case.

Yes, I agree that it could be a firmware issue, since it runs a clean Round Robin and Sequential test when the hyperthreading is disabled (Memtest86 v6.2 sees 2 cpu's). The cpu switching between the two physical cores presents no problem. However, when hyperthreading is enabled and the additional two virtual cores are presented (Memtest86 v6.2 now sees 4 cpu's) the system hangs during a cpu switch. The single and parallel test are ok with all 4.

Unfortunatley, I was running Memtest86 from .iso burned to CD-Rom, so no where to write the MemTest86.log.

If I get the time, and a spare USB stick to format, I may re-run from that to get the log, but no promises.

Thanks!

[tinstaafl]

I went back to review the original poster's MemTest86.log. Two things ([1] & [2]) below have jumped out at me.

[1] My test had the exact same behavior on the Round Robin test, except for my PC only has 4 logical cores vs the 8 shown in the OP's log below.

My test also hung on the second pass, when switching from 0 --> 1 the second time:
Proc# 0 --> 1
Proc# 1 --> 2
Proc# 2 --> 3
Proc# 3 --> 0
Proc# 0 --> 1 [hangs here]

=================== from OP's MemTest86.log ===============================
2015-08-13 21:29:12 - RunMemoryRangeTest - Switching BSP from Proc# 0 --> 1
2015-08-13 21:29:12 - RunMemoryRangeTest - Switching BSP from Proc# 1 --> 2
2015-08-13 21:29:12 - RunMemoryRangeTest - Switching BSP from Proc# 2 --> 3
2015-08-13 21:29:12 - RunMemoryRangeTest - Switching BSP from Proc# 3 --> 4
2015-08-13 21:29:13 - RunMemoryRangeTest - Switching BSP from Proc# 4 --> 5
2015-08-13 21:29:13 - RunMemoryRangeTest - Switching BSP from Proc# 5 --> 6
2015-08-13 21:29:13 - RunMemoryRangeTest - Switching BSP from Proc# 6 --> 7
2015-08-13 21:29:13 - RunMemoryRangeTest - Switching BSP from Proc# 7 --> 0
2015-08-13 21:29:13 - RunMemoryRangeTest - Switching BSP from Proc# 0 --> 1
=================== this is the last entry in the log =====================

[2] Comparing the two systems hardware architecture:
> Both are Intel based CPU and chipset
> My PC is Intel Ivy Bridge [3rd gen Core i3] vs. other is Intel Haswell [4th gen Core i7]
> My motherboard is Asus Intel-H61 vs other is Gigabyte Intel-Z97
> UEFI BIOS are from different vendors
> We are both runnning the latest firmware releases from our respective vendors
> Both systems have hyperthreading

Question: So if both PC's are having the exact same behavior, where might the problem be?

[keith]

My test also hung on the second pass, when switching from 0 --> 1 the second time:
Proc# 0 --> 1
Proc# 1 --> 2
Proc# 2 --> 3
Proc# 3 --> 0
Proc# 0 --> 1 [hangs here]

We've actually seen several cases of this, where it hangs after a cycle through all the processors. I think we were contacted by a vendor to help debug the issue, by creating a test program that simply cycles through the CPUs to prove that it freezes even without running the memory tests. The conclusion is that it is almost certainly a firmware issue.

The reason why the same behaviour occurs even when the vendors are different could be that their firmware implementations are using the same base code which contain the firmware bug.

I believe the only way to get the issue fixed is to pester their support department until they assign a firmware engineer to take a proper look at the issue.

[tinstaafl]

We've actually seen several cases of this, where it hangs after a cycle through all the processors. I think we were contacted by a vendor to help debug the issue, by creating a test program that simply cycles through the CPUs to prove that it freezes even without running the memory tests. The conclusion is that it is almost certainly a firmware issue.

The reason why the same behaviour occurs even when the vendors are different could be that their firmware implementations are using the same base code which contain the firmware bug.

I believe the only way to get the issue fixed is to pester their support department until they assign a firmware engineer to take a proper look at the issue.

Thanks for the feedback Keith! I really like your tool, and I know that just for now I need to stick to the single or parallel test.

As long as the firmware bug is only exposed during a certain test sequence, then I would hope that in the real world with an OS and drivers loaded it would never actually happen. I suppose if it does occur, it would be pretty random, and then by disabling hyperthreading one could rule that out.

So your tool was useful in any case, showing me that my memory is not at fault.