Problem with 128-bit random test on PRO version...

[g126]

Hi,

I have the 6.2 PRO version whcih I've always used to do memory testing on my computers, however, I recently came across an old Mac Book Air (late 2008 or MacBookAir 2,1) based on a Core 2 Duo chip with 2GB of Ram.

Right, so the machine was unstable and it turned out that cooling paste in between the cpu/gpu and heatsking had dried up.. Replaced it and voilá, rock solid stability again!

However, it will spill out hundreds of memory errors on Test 12 [Random number sequence, 128-bit]... All other memtests tests it runs fine! I've left it with Prime95 for days, no erros... I've run AHT extended test also no errors. I've downloaded v7.3 free version (that unfortunately does not include Test 12 [Random number sequence, 128-bit]) and no errors!

So... was there a BUG with Test 12 on version 6.2 that may explain this? Or maybe the Penryn chips had a problem executing SIMD instructions? It turns out I can download 6.3 to try out so I might give that a shot... If I could try 7.3 that would be awesome too... Unless someone can explain to me that Test12 will never work on this machine...

Cheers!

[g126]

So... went ahead and tried 6.3 PRO and had a similar result, many errors, but the weird thing was that it started later! In 6.2 the errors started appearing at the beginning of PASS 2/4 and in 6.3 they started to appear at the end of pass 2/4 (around 90% complete).

Thinking that perhaps the new algorithm in 7.3 would give me less erroneous results I went ahead and renewed support to get 7.3 and the result was... Well less erroneous... Only 4 errors that appeared at the end of pass 3/4 (around 938M/2G).

So does this suggest a BUG in TEST12 or simply that my RAM has problems that only appear in the exact conditions replicated by TEST12 at a specific address that the old TEST12 couldn't narrow down but the new test12 can?

If someone could shed some light on my situation I'd be very grateful! thanks.

[David (PassMark)]

There is no bug in Test #12 that we are aware of.

There was some recent changes in Test 12. One was to done to speed up the test, the other one was to avoid a (rare) system hang.

I think it is likely they are real hardware errors. But Test #12 uses SSE instructions. Which despite being available for 18 years, still aren't all that common in real world software. So the errors might not get provoked very often in real life.

[keith]

So... went ahead and tried 6.3 PRO and had a similar result, many errors, but the weird thing was that it started later! In 6.2 the errors started appearing at the beginning of PASS 2/4 and in 6.3 they started to appear at the end of pass 2/4 (around 90% complete).

Thinking that perhaps the new algorithm in 7.3 would give me less erroneous results I went ahead and renewed support to get 7.3 and the result was... Well less erroneous... Only 4 errors that appeared at the end of pass 3/4 (around 938M/2G).

So does this suggest a BUG in TEST12 or simply that my RAM has problems that only appear in the exact conditions replicated by TEST12 at a specific address that the old TEST12 couldn't narrow down but the new test12 can?

If someone could shed some light on my situation I'd be very grateful! thanks.

What are the specific memory errors you are seeing?

Can you send a copy of the MemTest86.log file under the EFI\BOOT\ directory of the USB drive.

[g126]

What are the specific memory errors you are seeing?

Can you send a copy of the MemTest86.log file under the EFI\BOOT\ directory of the USB drive.

Sure... here is the log file.

You can see the four errors I'm talking about at time index 2017-02-28 13:30:35 during pass 3/4 of just Test12.

After that I decided to run the whole batch of tests again at 2017-02-28 14:26:32 it finished the pass 1/4 without any errors, then at 2017-02-28 17:02:32 Test12 blew up again during pass 2/4...

It seems that when you do all of the tests the errors happen earlier... Is this normal? I mean, wouldn't you expect faulty RAM to give errors on all passes?

Another weird thing I've noticed is that the passes take progressively longer... You can clearly see that on the initial batch of tests:

13:23:08 - Starting pass #1 (of 4)
13:24:20 - Finished pass #1 (of 4) - 1m12s
13:24:20 - Starting pass #2 (of 4)
13:28:20 - Finished pass #2 (of 4) - 4m
13:28:21 - Starting pass #3 (of 4)
13:32:28 - Finished pass #3 (of 4) - 4m7s
13:32:28 - Starting pass #4 (of 4)
13:36:45 - Finished pass #4 (of 4) - 4m17s

On the whole batch of tests you can see that pass 1/4 took just under 1 hour, while pass 2/4 took around 2.5 hours before Test12 blew up on errors.

If the tests are the same and repeat the same steps, why do the subsequent passes take so much longer?

With regards to the length of time for each pass I see a similar behaviour on my 2006 Mac Pro (another machine with limited UEFI support)...

[g126]

There is no bug in Test #12 that we are aware of.

There was some recent changes in Test 12. One was to done to speed up the test, the other one was to avoid a (rare) system hang.

I think it is likely they are real hardware errors. But Test #12 uses SSE instructions. Which despite being available for 18 years, still aren't all that common in real world software. So the errors might not get provoked very often in real life.

OK... but in this case is it a RAM problem or a processor problem with the execution of the SIMD extensions? Test 11 is a similar test (also random numbers) and gives no error... But the extra test available on the pro version (Test12) does...

Do you know of a stress testing program that uses SMID extensions that I could try? Perhaps that could help identify where the problem is...

[David (PassMark)]

It is normal that the 1st pass is faster. It was designed this way, to allow a quick test.
We'll take a look at the log file.

[keith]

OK... but in this case is it a RAM problem or a processor problem with the execution of the SIMD extensions? Test 11 is a similar test (also random numbers) and gives no error... But the extra test available on the pro version (Test12) does...

Do you know of a stress testing program that uses SMID extensions that I could try? Perhaps that could help identify where the problem is...

We have a new build for you to try if you like. It fixes a slight bug in Test 12 and changed how 128-bit errors are output to screen and the log file.

If possible, can you send an e-mail to us and we can provide you the build.

[g126]

We have a new build for you to try if you like. It fixes a slight bug in Test 12 and changed how 128-bit errors are output to screen and the log file.

If possible, can you send an e-mail to us and we can provide you the build.

Thanks Keith! Just seen the email! Will run it now and sen you the log file.