multi CPU test fails / single CPU mode passes

[xerces8]

Hi!

I noticed that in multi CPU mode (the default) I get a lot of errors (starting in test #3, going over 65535 in few seconds) on my PC, but in single CPU mode it runs for long times with no errors detected (hours).

It is the same with v4.2.0 and the 4.3.0 beta.

I start them from CD.

HW details:
Intel Core i5-2320
Northbridge Intel Sandy Bridge rev. 09
Southbridge Intel H61 rev. B3

2x 2GB DDR3 1333 CL 9

Mainboard Model MS-7728 (MSI OEM, the PC is a Medion P5350 D (MD8895) )
gfx card : NVIDIA GeForce GT 530

Interestingly, the memtest86+ v5.0.0 RC1 behaves similarly. Maybe they share the same code?

[David (PassMark)]

The MemTest86+ code was split off a long time back, but a fair amount of it is still common, at least in the V4.2 releases. I can't really comment on the MemTest86+ V5.0 release as the MemTest86+ developer hasn't released any source code, in violation of the GPL license.

To start with,

1) Would it be possible to post or E-mail us a screen shot.

2) In the MemTest86 config window, can you turn on 'Individual errors', under the 'error report mode' setting. Then also press Scroll Lock to stop the display scrolling. Then the first error should be visible on screen. Can you also send / post a screen shot showing this first error.

3) Do you have any spare RAM available? As the initial error might be a real error. (i.e. 1 real error provokes all the other false errors). If you don't have any spare RAM, can you try 1 stick at a time and see if the behaviour is different between the sticks.

Do the above on V4.3 beta, rather than V4.2.

[xerces8]

3) Do you have any spare RAM available? As the initial error might be a real error. (i.e. 1 real error provokes all the other false errors). If you don't have any spare RAM, can you try 1 stick at a time and see if the behaviour is different between the sticks.

I have 2 sets of RAM (2x2GB and 2x4GB) and the 2x2GB should be not defective, I used them for a year.

The multi CPU error frenzy happens with them too. (and again, no error in single thread mode).

I'll post more info later today.

[David (PassMark)]

The multi CPU error frenzy happens with them to

Which set is 'them'? It isn't clear.

It is totally possible that you have 1 byte (from 4 billion bytes) that is defective and you haven't noticed up until now.

[xerces8]

The multi CPU problem happens with all RAM modules.

I just ran memtest86+ v4.2 the whole day (15 passes) with the 2x2GB RAM and no error detected. I used these for a year and run memtest a couple of times in past, never detected any errors.


Here is the screenshot from todays run:


Screenshot of multi cpu error:



Screenshot of same in Individual error report mode and scroll locked:


And as a bonus, this happened on one run of 4.3.0 beta in default mode, a few seconds after it started printing memory errors:


PS: I don't see the attachment manager anywhere??? I'll try to add the pictures in a minute.
PPS: I guess this is one of those "no file uploads" forums...

[David (PassMark)]

Thanks for that.
We'll do some investigation.

I did in fact try to turn on permissions to post images in the forum. I didn't work, for reasons unknown and I haven't had time to debug the forum software to work out why as yet.

[xerces8]

I did some more tests, running each test separately:
- start Memtest86 v4.3.0 beta in default mode
- press c 1 3 ... to select a single test

Results:
- single CPU tests run for hours without errors (tests 0, 1, and 10)
- all multi CPU tests fail in the first second (and keep counting errors fast), except tests 6 and 2, which:
- test 6 did not detect any error in 20 minutes of run time, then I stopped it
- test 2 ran 5 minutes without errors, then started reporting a lot of them

Here are screenshots of each test:

http://imgur.com/a/DGwwO

[xerces8]

Also I noticed that while multi CPU test are running, the keyboard is unresponsive.

[David (PassMark)]

Given that is happening across most of the tests and not just test #3, it make it less likely it is a coding bug in MemTest86. I guess there is a slim chance there is a bug in the multi-threading code, but someone else surely would have encounter this problem beforehand I think.

We went through the source code of Test #3 and couldn't find any fault in the code that would produce the effect you saw.

So I think it is worth trying to see if this is a real hardware fault. Maybe not with the RAM, but with the BIOS, MB or CPU. For example

1) How stable is this machine in Windows in normal use (I assume you are running Win7 64bit?)

2) Can you download the trial of BurnInTest for Windows and select just the CPU test to run, then select just the RAM test (both at 100% load). Is the machine stable under this load?

3) What the CPU temperatures like when under heavy load?

4) Are there any BIOS updates available for the machine?

[xerces8]

1.) I run Windows 8 64 bit. Before I had 7 and XP. No problems in daily usage.
2.) CPU test run OK, temp up to 68 C. No problems noticed.
RAM test passed OK, nothing special observed.
3.) I started 2 instances of the 7-zip built-in benchmark with 4 threads each and according to CoreTemp the CPU temperature climbed to 60-66 degrees Celsius in a minute and stayed there for the duration of the test.
4.) No BIOS updates are available, at least no official ones. (and I also don't know about any unofficial ones either)

[xerces8]

I run memtest 4.3.0beta in VMWare, just to see what happens. All tests run without detecting any errors (I run them only for a few minutes). I configured the VM to have 4 CPUs, so the multithreaded tests would execute as on real hardware.

[David (PassMark)]

OK, here is another test to try.

Can you go into the configuration window in MemTest86 and select to test just the top 2GB of RAM. ie. no testing on 0GB to 2GB.

[xerces8]

I set the lower address limit to 2g and something weird happened.
all 10 tests execute in about one second. See screenshot:

[David (PassMark)]

...something weird happened. all 10 tests execute in about one second.

Looks like this is a bug. Unrelated to the initial problem you have, but a bug nonetheless. We can see similar strange behaviour when we set a high limit for the starting memory address. As we can reproduce this here, it should be fixable quickly.

What country are you in? Is this your main PC? I am just wondering how easy it would be to get access to your machine for deeper testing?

[xerces8]

Slovenia, main PC.

What kind of access are you talking about?