Noise appears on VGA output after a few iterations

[steve90815]

PassMark-

I have an odd problem. We've been testing identical motherboard/CPU/RAM assemblies successfully for a while, and recently, a problem has cropped up.

We use a Gigabyte GA-H61N-USB3 motherboard, an Intel i7-3770k CPU, and Kingston KHX1600C9D3K2/8GX RAM.

The motherboard BIOS version is the same, and the other parts shouldn't have changed, since they're just hardware.

I start a test, and leave it alone for a while. Generally, it'll do 2 passes just fine. Then, sometime after that, I come back to it, and the VGA screen shows just some colored dots in the top 1/10th of the screen, mostly in the top-left corner of the screen.

I'm really stumped, since this never used to happen to us.

Also, for what it's worth, we previously used MT420 from memtest.org, and the same problem happened. (This is actually what brought us to you, instead of them).

My motherboard doesn't have UEFI, so I can't try your v5 program.

I just started considering that it might be the "screen blanking" feature that's causing the problem. Is that reasonable? Is there a way to disable that as a test?

Thank you,

Steve

[David (PassMark)]

What version of MemTest86 are you using?

This page claims your motherboard does in fact have UEFI.
http://www.gigabyte.com/fileupload/microsite/314/windows8.html

[steve90815]

David-

Thank you for your response. I'm running v4.3.0.

I actually made a beta v5.0 USB flash drive, but when I start it, I don't see the UEFI entry to boot from (as described on your forum), and when I start MemTest86, it reports v4.3.0.

I believe their information is not correct. If you go to the detail page on my motherboard, it does list some features, but UEFI is not one of them. It shows:

1. 2 x 32 Mbit flash
2. Use of licensed AWARD BIOS
3. Support for DualBIOS™
4. PnP 1.0a, DMI 2.0, SM BIOS 2.4, ACPI 1.0b

Thank you,

Steve

[David (PassMark)]

Are you running V4.3 in the default CPU mode (round robin)?

Repetitive Rubbish or noise on the screen is normally a sign that the memory testing algorithm is writing data into the video buffer (i.e. on to the screen). This should not normally happen as this area of memory should be excluded from testing. So either the memory map in BIOS is wrong, or some fault in MemTest86 caused it to write to the screen. This fault might be a bug, or it might be that the RAM/CPU is bad, and the program as gone off the rails as a result of bad hardware.

Two more things to try,
1) Updating your BIOS to the latest version. I note that one of the BIOS updates for this motherboard claimed, "Support GIGABYTE TouchBIOS", which is a UEFI feature.

2) Try using V5 and setting the "EFI CD/DVD Boot Option" in BIOS to EFI.

[steve90815]

We initially saw the error under v4.2.0, then it happened again under v4.3.0. Yes - we were running the default "round robin" mode. I then tried selecting boot option 6 for uniprocessor mode, and that seemed to do the same thing. However, I'm trying that again, since I thought the dots appearing might have coincided with my switching our KVM switch. If it's any help, we do change the default memory allocation to the onboard graphics to "480MB + 2MB for GTT". We are already running F8, which is the latest BIOS version. I'll investigate using TouchBIOS, and will do your suggestion #2 tomorrow. Thank you, Steve. (My spacebar isn't working now, so my formatting looks like I'm sending a text message!)

[steve90815]

David-

1) I installed "TouchBIOS", and it's just a Windows program that lets you make BIOS setting changes. My BIOS version (F is still the latest available for my motherboard.

2) I set "EFI CD/DVD Boot Option" in the BIOS to EFI, and my v5 USB flash drive still doesn't show the UEFI boot options in the boot menu, and launches v4.3.0.

I let v4.3.0 run overnight in single CPU mode (startup option 6), and it still did the same thing.

Is there any debugging stuff I could enable to help track this down?

Thank you,

Steve

[David (PassMark)]

Do you have spare hardware?
As it would be nice to try and rule out a hardware failure.
e.g. swap out the RAM and retest. Then swap out the CPU and retest. Then swap out the MB and retest.

Or alternatively if you are assembling PCs run the same tests on another PC with identical model hardware.

[steve90815]

David-

This has become a big issue recently because we built up three assemblies of motherboard/CPU/RAM, and they all did it.

I have unplugged the HD-SDI video board (a Blackmagic Designs Decklink Quad), and so far, it's run longer than I've seen in a while. This could be the problem.

I'd much rather be able to test memory with the video board installed. If it's causing the problem, is there any debugging stuff I can get you to figure out what the problem is?

Thank you,

Steve

[David (PassMark)]

Does the test stop/crash/lockup once you see the dots on the screen?
Or does the memory test continue to run?

I don't know anything about the Decklink card. Could be the card directly causes a problem. e.g. by corrupting memory, or it could be the card causes an indirect problem. For example by causing power supply issues or via EMI.

The BIOS version of MemTest86 is hard to debug. There is no debugger available to step through the code, no access to the hard drive for logging. If a problem only occurs hours into a test there isn't much that can be done remotely.

If we had a example system here that exhibited the problem here, we could probably do more. e.g. try and work out what memory addresses the video frame buffer is at and then try and work out if MemTest86 is writing to these addresses. Would be a slow tedious debugging process taking several days however.

[steve90815]

David-

Once I see the dots on the screen, that's all I see -- just dots on a black screen. However, the dots do appear to change somewhat, so the test might still be running.

I am in communications with Blackmagic. Is there anything I can ask them about the Decklink, to help diagnose this?

Thank you,

Steve

[steve90815]

David-

It finally failed, even without the Decklink board installed.

I'm not sure how else to proceed with this, but I appreciate all your help.

Thank you,

Steve

[David (PassMark)]

Maybe try some RAM / CPU stress testing in Windows to see if it is stable in Windows.