MemTest86 v7.5 (Build 1001) released - 21/Feb/2018

[hhuey5]

getting same issues as streetwolf

i'm in Test #3 at 1:00:22 usually I be alot further in an hour
in v7.4 I be in test#7

I'm conducting memory test of my new build and I'm just getting used to v7.4 vs v5
cpu 7940x
mb AsRock x299 TaiChi XE
ram G.SKILL TridentZ Series 128GB F4-3200C16Q2-128GTZ

but v7.5 not doing well

[keith]

For those who are experiencing slowdowns with the recent v7.5 release, can you give this build a try:

http://www.passmark.com/ftp/memtest86-usb-7.5.1001.zip

We have found that when a core/thread has finished testing a memory segment, it is 'reset' before the next memory segment. This was initially added to make the testing more robust to core/thread errors but may be the reason for the slowdown if some machines don't implement the disable / reenable thread function correctly.

[sbakic]

I tried memtest 7.5 with Crosshair VI Hero (Wi-Fi) UEFI 3502, passed all 11 tests (it needed like an hour for all of these test to finish), but when i roll back UEFI to 1701 and tried memtest 7.5 it didn't want to load. This is probably because of UEFI firmware multiprocessor initialization.

Isn't UEFI 1701 version fixed of these problems because of this list https://www.passmark.com/forum/memte...election-modes. There is ASUS CROSSHAIR VI HERO, with UEFI 1107 only. Can you tell amd to fix it, I don't want to use 3502 because of wrong cpu clocks when OCed and unnecessary things happening?

[hhuey5]

i think v7.51001 ran 30 min faster than v7.4 for 128gb

[keith]

Thanks for the update. It sounds like the slowdown issue has been resolved.

By chance do you have the logs for both the v7.5.1001 and v7.4 runs. We would like to see what is causing the significant decrease in test time from v7.4.

[streetwolf]

I just ran v7.5 1001 and it ran fine. Seemingly as fast as 7.4. I've attached the log of some tests that were always slow in the original 7.5. I previously submitted logs from 7.4 and 7.5 so you should be able to compare them with 7.5 1001. Good job.

[David (PassMark)]

We built a new V7.5 package for public release, but we need to submit it to Microsoft for code signing so that it works with Secure Boot. So it might be another week before we can get the workaround into the main release.

[sbakic]

Question about AGESA, reading info about CPU and RAM

As everyone is ignoring me, I will ask again.

Before everthing know that there is not fault on any of part of PC. Temps are fine everthing works fine event OCed. I run same multiple tests on multiple applications.

1. Only question related to this thread. I tried memtest 7.5 with Crosshair VI Hero (Wi-Fi) UEFI 3502, passed all 11 tests (it needed like an hour for all of these tests to finish), but when I roll back UEFI to 1701 and tried memtest 7.5 it didn't want to load. Is this because of UEFI firmware multiprocessor initialization on UEFI 1701? Isn't UEFI 1701 version fixed of these problems because of this list https://www.passmark.com/forum/memte...election-modes? There is ASUS CROSSHAIR VI HERO, with UEFI 1107 only.

2. As I understood AGESA is a predefined set of instructions that initiate CPU, RAM, etc when UEFI is loading. Every new UEFI version could have new AGESA version. Could different versions of AGESA/UEFI have differenet impact on OCing CPU/RAM, like on one version I could get CPU at 3.9GHz and on the other one 4Ghz?

3. After UEFI comes OS Kernel and OS itself. I didn't search but I would like to know why they are different readings on CPU/RAM frequency even temps with different UEFI/AGESA versions? For example Crosshair VI Hero (WiFi) UEFI 1701 after OC CPU shows right frequency, but with UEFI 3008 and 3502 wrong (AEGSA respectively, 1.0.0.6b - 1072 - 1000a form oldest to newest) on some applications as well as task manager. Do applications that read info about CPU/RAM depend on AGESA/UEFI, why wrong readings?

4. When I do stress testing CPU/RAM with other applications (OCCT, prime95 etc) should pc go in sleep mode or turn off monitor mode, because I know when something is moving on the screen PC should not go to sleep mode, probably because of power features and voltages etc? I am asking this because I let OCCT Linpack stress test to run for 6 hours with default setting in UEFI (3502 latest version) and I set in Windows 10 to turn off monitor after an hour. When I came back I could hear PC still runing at full load, but I couldn't get any signal from monitor (keyboard was on and mouse as well) and Q-code on motherboard was 24 which means that everything is fine, but I needed to retstart pc to get everything back on (So not OCed system with monitor not responsive hm, but good Q-code 24, is it maybe because of turned monitor after an hour?). Second thing that happend before this is one one test when CPU was OCed and again i run OCCT Linpack for 2 hours, when it finished case fans still was on full load, even if every temp was fine. I need again to restart PC to make case fans quiet. Remember every other stress test was fine even OCCT Linpack but only two times failed (if you could call it fail) out of 10. What happened it these two cases?

Thanks for your time.

[David (PassMark)]

Sbakic,

According to the ASUS Firmware page, there was a Memtest86 fix in Version 1602, Date 2017/09/18.
https://www.asus.com/Motherboards/RO...HelpDesk_BIOS/

We don't know anything about AGESA. I don't think it has anything to do with Memtest86.

Clock speeds & CPU temps are generally measured directly on the CPU. But it is a slightly complex area. For example their are many different internal clocks in a PC. And the way to measure temperatures isn't standardized.

If you need help with OCCT, prime95 & Linpack then i suggest you contact the developers of those products. This topic was to discuss new Memtest86 releases.

[sbakic]

Thank you for you reply.

I will try again to run Memtest86 v7.5, on UEFI 1701. If it doesn't load test what should I do? Should I lower the Memtest86 version, or could I report this as a bug?

[David (PassMark)]

If newest ASUS firmware works with newest MemTest86, then it is all good. If you don't like the newest ASUS firmware due to some other bad overclocking behaviour, that isn't really our problem. You need to talk to ASUS,

If the old ASUS firmware doesn't work due to their (now corrected) bugs, then I don't think anyone is going to care, as the solution is already available.

[sbakic]

If newest ASUS firmware works with newest MemTest86, then it is all good. If you don't like the newest ASUS firmware due to some other bad overclocking behaviour, that isn't really our problem. You need to talk to ASUS,

If the old ASUS firmware doesn't work due to their (now corrected) bugs, then I don't think anyone is going to care, as the solution is already available.

Can there be any consequences later while working because of bugs on ASUS firmware, should I ignore them? I mean for 1701 UEFI witch is older version, I had stable OC and I didn't know there were some bugs till Memtest86 didn't want to load. Can we even call that bug because of bad/buggy UEFI firmware multiprocessor initialization and Memtest86 couldn't load because of that?

[David (PassMark)]

Can there be any consequences later while working because of bugs on ASUS firmware

Don't know. I haven't looked at all the fixes they included in later versions.

Can we even call that bug

We called it a bug. ASUS agreed it was a bug & then fixed it, at least for some of their motherboards. So yes it was a bug. It isn't a bug that should impact any software running in Windows however.

[Mark_Huang]

>> Added ECC detection/injection support for AMD Ryzen chipset
I saw this update in V7.5.

Does it include AMD V1000 processor? (https://www.amd.com/en/products/embe...n-v1000-series)

When I run it on AMD V1000 platform, it shows ECC Enabled: N/A(Unknown)

[David (PassMark)]

We've never done any testing on a AMD V1000 CPU.
ECC injection doesn't work on Ryzen, as AMD disabled it.
But there is a change ECC detection does work. Can't be certain without testing it.