Asrock X370 Fatal1ty Gaming K4 Support Thread

[chew*]

Here is what i am "banging on about"



Flare x is having issues @ 3200 on taichi as well...

But screw it..now i really don't care.

[celerity]

Flare x is having issues @ 3200 on taichi as well.

Coincidence? Doubt it.

well that's what we're trying to solve.. works fine on AB350 however

flare x is tailored for Ryzen and also on AMD's support list, of course we want it to work properly

https://www.amd.com/system/files/201...rt-list-en.pdf

[chew*]

I am aware of what it does/supposed to do...i was sent a kit from gskill.

I sent messages.

Meanwhile...i will shove in another board...

Here is a fail list...2 are on amd compat list...one amd sent...

[os2wiz]

Chew I am wondering if you have had a look at the ROG X370 Strix motherboard? I believe the vrm is different than on the Crosshair VI. Is it similar to the Titanium vrm? Other features are pretty much identical to Crosshair VI?

[chew*]

Wrong thread for that.

[Ket]

For Asrock:

G.Skill F4-3200C14D-16GFX, s/n 1712A5000835483, production date March 2017

ok, now some other stuff...

as soon as I enter CPU oc mode (i.e. anything above 3 GHz for 1700, no RAM oc) it fails OCCT CPU Large test after ~10 min (bluescreen, auto-restart etc.)

the weird thing is, say, I can run all kind of stress tests stable, like Realbench for 8 h, linpack for 1 h, cinebench, SuperPi32 etc. EXCEPT OCCT CPU Large - instant crash. Different frequencies, vcore, llc, soc, I think i tried everything even downgraded BIOS to 2.40 - same problem

disabling SMT seems to solve the problem... question is what's at fault here... board, software, cpu or something else

I would greatly appreciate if someone could run OCCT (v.4 5.0 latest) CPU Large test on Gaming K4 with an oc Ryzen and see if the crash can be replicated. Thank you.

Thanks I will pass that info on Regards your CPU, if you can run linpack for 3+ hours I wouldn't worry what OCCT says I've not used it in years where there are better tools to test for stability with. If I recall correctly the reason I stopped using it is because of results it would spit out that were totally out of whack with any other stress test I used.

You could try bumping up vcore a bit to fix any stability issues you are having. The lithography used for Zen is very predictable and scales very linearly in general up to just under 3.8GHz. For example; the 1700 I have can run 3.796GHz at 1.275v but the instant I hit and go over that "critical 1" point in the lithography (thats the point things start to not scale linearly) to 3.82GHz vcore has to be bumped to 1.325v, about a further .075v bump is then required for 3.9GHz, with 4GHz with SMT on proving a stumbling block but with SMT off 4GHz is easily achieved with about 1.3v.

How bout i just load xmp and confirm bsods on taichi as well.

I will send a message to frank @ gskill and nick @ asrock.

Something is not right or my sticks spontaneouly took a dive for no reason which i doubt is the case..

I'm not sure on the status of the Taichi when it comes to memory, I'll check and get back to you .

[celerity]

Thanks I will pass that info on Regards your CPU, if you can run linpack for 3+ hours I wouldn't worry what OCCT says I've not used it in years where there are better tools to test for stability with. If I recall correctly the reason I stopped using it is because of results it would spit out that were totally out of whack with any other stress test I used.

You could try bumping up vcore a bit to fix any stability issues you are having. The lithography used for Zen is very predictable and scales very linearly in general up to just under 3.8GHz. For example; the 1700 I have can run 3.796GHz at 1.275v but the instant I hit and go over that "critical 1" point in the lithography (thats the point things start to not scale linearly) to 3.82GHz vcore has to be bumped to 1.325v, about a further .075v bump is then required for 3.9GHz, with 4GHz with SMT on proving a stumbling block but with SMT off 4GHz is easily achieved with about 1.3v.

Right, although I don't think it has anything to do with oc stability

would be great if someone could tun OCCT CPU: Large test for 30 min on an oc rig tho

to figure out whether the problem is local or not

[celerity]

lol several people have now said this board is EOL

how old is this board? 3 months?

https://www.reddit.com/r/Amd/comment..._as_stated_by/

[Kobaltrock]

lol several people have now said this board is EOL

how old is this board? 3 months?

https://www.reddit.com/r/Amd/comment..._as_stated_by/

Well, the moderator of the ASROCK forums did say as such.
http://forum.asrock.com/forum_posts....1006-out#31566

I don't either. The X370 Gaming K4 is now EOL(End of Life) and as such BIOS support will begin to dwindle sooner rather than later I'm afraid.

So, apparently, this board has some kind of hardware issue that can't be fixed, and they EOLed it.
Otherwise, why would they EOL it so soon?

[celerity]

Well, the moderator of the ASROCK forums did say as such.
http://forum.asrock.com/forum_posts....1006-out#31566

So, apparently, this board has some kind of hardware issue that can't be fixed, and they EOLed it.
Otherwise, why would they EOL it so soon?

IMO Asrock should make an official statement. not good to keep customers in the dark

if it's a false rumour they should deny it ASAP

[Ket]

For Asrock:

G.Skill F4-3200C14D-16GFX, s/n 1712A5000835483, production date March 2017

ok, now some other stuff...

as soon as I enter CPU oc mode (i.e. anything above 3 GHz for 1700, no RAM oc) it fails OCCT CPU Large test after ~10 min (bluescreen, auto-restart etc.)

the weird thing is, say, I can run all kind of stress tests stable, like Realbench for 8 h, linpack for 1 h, cinebench, SuperPi32 etc. EXCEPT OCCT CPU Large - instant crash. Different frequencies, vcore, llc, soc, I think i tried everything even downgraded BIOS to 2.40 - same problem

disabling SMT seems to solve the problem... question is what's at fault here... board, software, cpu or something else

I would greatly appreciate if someone could run OCCT (v.4 5.0 latest) CPU Large test on Gaming K4 with an oc Ryzen and see if the crash can be replicated. Thank you.

I am aware of what it does/supposed to do...i was sent a kit from gskill.

I sent messages.

Meanwhile...i will shove in another board...

Here is a fail list...2 are on amd compat list...one amd sent...

Chew, what UEFI version did you use when testing those kits on the Taichi, and what was their maximum stable frequency? Once I know this R&D can look in to things.

Right, although I don't think it has anything to do with oc stability

would be great if someone could tun OCCT CPU: Large test for 30 min on an oc rig tho

to figure out whether the problem is local or not

Any success? I'll do a quick run with OCCT and let you know my results.

Well, the moderator of the ASROCK forums did say as such.
http://forum.asrock.com/forum_posts....1006-out#31566


So, apparently, this board has some kind of hardware issue that can't be fixed, and they EOLed it.
Otherwise, why would they EOL it so soon?

I'll directly ask my contacts about this to clear any confusion up but as I've said they have not said to me the K4 is EOL.

[celerity]

Any success? I'll do a quick run with OCCT and let you know my results.

tried p-state oc, failed as well

[Ket]

tried p-state oc, failed as well

I did some tests with OCCT, starting with my R7 1700 running clocks of 3.2GHz which it automatically boosts to when left to its own devices, left it running for 1 hour without any problems. Pushing anything above that speed is when OCCT starts to cause major problems in my case both screens would go blank and I'd have to hard reset.



Its important to note that OCCT doesn't actually read Zen CPUs properly at this time which is likely a factor in why the test is crashing. Both original clock frequency and overclock frequency are "unknown" as far as OCCT is concerned. Additionally OCCT appears to run a form of linpack to test for stability something which traditionally is only really meant to test intel CPU stability. If you try to run Intel Burn Test you will experience similar anomalous behaviour to what OCCT exhibits - this is not a coincidence, both stability tests use a form of linpack to test a CPU for stability. In the case of IBT while my system did not blank screen like with OCCT the test just would not run and immediately skip to saying the CPU is stable message.

If you want to test for stability download BOINC and join one of their projects, hammer the CPU that way to test for stability. It's what I do, my R7 1700 every day runs 3.8GHz with the seti@home project hammering all cores and threads of the CPU to 100% with absolute stability while also simultaneously hammering my GTX980 @ 1.5GHz / 7.5GHz as well. While doing all of this I can also be playing any game (in this instance Mass Effect Andromeda) and still be completely stable.



If you have a intel CPU, test it for stability with IBT, if you have a Zen CPU for instance, test it for stability by running any BOINC project that will hammer all of the CPU cores and threads at the same time to 100%.

Bottom line: OCCT is a terrible test to use with Zen to test for stability and I've found it to be a terrible stability test application since the Athlon64 days.. showing inconsistent results completely out of whack with any other stability test I run. That should pretty much tell people everything they need to know about OCCT.

[celerity]

I did some tests with OCCT, starting with my R7 1700 running clocks of 3.2GHz which it automatically boosts to when left to its own devices, left it running for 1 hour without any problems. Pushing anything above that speed is when OCCT starts to cause major problems in my case both screens would go blank and I'd have to hard reset.

Its important to note that OCCT doesn't actually read Zen CPUs properly at this time which is likely a factor in why the test is crashing. Both original clock frequency and overclock frequency are "unknown" as far as OCCT is concerned. Additionally OCCT appears to run a form of linpack to test for stability something which traditionally is only really meant to test intel CPU stability. If you try to run Intel Burn Test you will experience similar anomalous behaviour to what OCCT exhibits - this is not a coincidence, both stability tests use a form of linpack to test a CPU for stability. In the case of IBT while my system did not blank screen like with OCCT the test just would not run and immediately skip to saying the CPU is stable message.

If you want to test for stability download BOINC and join one of their projects, hammer the CPU that way to test for stability. It's what I do, my R7 1700 every day runs 3.8GHz with the seti@home project hammering all cores and threads of the CPU to 100% with absolute stability while also simultaneously hammering my GTX980 @ 1.5GHz / 7.5GHz as well. While doing all of this I can also be playing any game (in this instance Mass Effect Andromeda) and still be completely stable.

If you have a intel CPU, test it for stability with IBT, if you have a Zen CPU for instance, test it for stability by running any BOINC project that will hammer all of the CPU cores and threads at the same time to 100%.

Bottom line: OCCT is a terrible test to use with Zen to test for stability and I've found it to be a terrible stability test application since the Athlon64 days.. showing inconsistent results completely out of whack with any other stability test I run. That should pretty much tell people everything they need to know about OCCT.

interesting Linpack based stress tests may have this effect on Zen, good to know!

im moving to Prime95 after this, latest version (291) is optimised for Zen too

this clears some things up!

[Ket]

interesting Linpack based stress tests may have this effect on Zen, good to know!

im moving to Prime95 after this, latest version (291) is optimised for Zen too

this clears some things up!

Alright, I'll bear Prime in mind my experiences have just bought me to BOINC simply because with the exception of IBT its the only sure test of system stability - if you are BOINC stable, you are good to go Bit the same when it comes to testing memory for stability, HCI memtest has never steered me or others I've suggested it to wrong. Even IBT while you can set how much RAM to use does not test the memory in the same way HCI does. IBT might give you a pass, where HCI will detect errors which is why I would recommend anyone run IBT/BOINC and HCI to test for stability all 3 apps are extremely consistent and reliable if they say something is wrong I've never seen a instance where they haven't been right.

[celerity]

Alright, I'll bear Prime in mind my experiences have just bought me to BOINC simply because with the exception of IBT its the only sure test of system stability - if you are BOINC stable, you are good to go Bit the same when it comes to testing memory for stability, HCI memtest has never steered me or others I've suggested it to wrong. Even IBT while you can set how much RAM to use does not test the memory in the same way HCI does. IBT might give you a pass, where HCI will detect errors which is why I would recommend anyone run IBT/BOINC and HCI to test for stability all 3 apps are extremely consistent and reliable if they say something is wrong I've never seen a instance where they haven't been right.

I may give it a try

Normally I use Prime95 + RealBench. IMO synthetic + real testing is a good combination.

...but as we discovered every platform needs to be stressed differently.

BTW. AGESA 1.0.0.6a incoming apparently:

http://forum.asrock.com/forum_posts....le=agesa-1006a

[Ket]

I haven't landed base with my asrock contacts in 5 days or so so I'm not sure whats going on with AGESA 1.0.0.6a. I did tell my contacts a week or so ago about some very unusual SMT behaviour so maybe the new AGESA is addressing that. Sods law though, I've just done a board swap where I'm working on a modded UEFI. Looks like I may be switching boards again sooner than I thought. Ho-hum.

[Ket]

Ok guys, I've been talking with my contacts and can confirm that the Fatal1ty Gaming K4 is EOL but the reason for it is nothing to do with memory. The reason for the board becoming EOL is purely down to components the board was made with becoming increasingly difficult to obtain due to supply shortages so Asrock just decided it would be better to respec the board and release it with a different name to keep things simpler. Rest assured though that the Gaming K4 will keep getting UEFI updates and support.

Hopefully this will clear up any confusion and rumors regarding the K4

[celerity]

Ok guys, I've been talking with my contacts and can confirm that the Fatal1ty Gaming K4 is EOL but the reason for it is nothing to do with memory. The reason for the board becoming EOL is purely down to components the board was made with becoming increasingly difficult to obtain due to supply shortages so Asrock just decided it would be better to respec the board and release it with a different name to keep things simpler. Rest assured though that the Gaming K4 will keep getting UEFI updates and support.

Hopefully this will clear up any confusion and rumors regarding the K4

UEFI 3.0 just released also

Update AGESA to 1.0.0.6a

[Ket]

Thats a large revision jump.. be interesting to see whats changed with such a large jump. A little off topic but I have also checked to see how Gigabyte are keeping pace with all the other manufacturers, not even a beta UEFI based on AGESA 1.0.0.6a for the Aorus Gaming 5. Every time I look in on Gigabyte they don't appear to even be doing the bare minimum to keep up with the competition. It's not like Gigabyte didn't have a grace period it's been (depending how you want to look at it) a extra 2-4 days for them. As AMD are the ones doing all the work all Gigabyte have to do is release a UEFI with the updated AGESA code which speaking as a UEFI / BIOS modder, is not that hard. It really does look like Gigabyte just could not give a flying pigs arse. Usually some lag between manufacturers isn't all that bad but with a platform as new as AM4 and all the improvements AMD are making particularly with RAM compatibility the last thing you want is a manufacturer being lackadaisical and dragging it's knuckles. Gigabyte earned that 67% score for the Aorus I gave, for all the wrong reasons.

EDIT: Added link to first post to download UEFI 3.0 for the X370 K4. Hopefully I'll find a bit of time to update the drivers package as well in the near future. Also fixed images (seriously folks, if you have a photobucket account use imgur instead).

[cbjaust]

Known Issues

1. Some G.Skill memory kits will not run their XMP 3200MHz profile stable.

Possible Solution: Set tRC to 75, tMAW.MAC to 1, Disable Gear Down and AM4 Boot Training.

<<snip>>

anyone got F4-3200C14D-16GFX Flare X running at rated speed and timings on this board? Stuck at 2933 here. Cheers

[Ket]

Have you tried UEFI 3.0 or 3.1? I should be testing 3.1 sometime this week, just need to clear a few excess things up to make the time.

[chew*]

The reason for prime testing is avx 512. Do not think boinc uses that.

As far as taichi goes i am already working with people on the board and and higher end models.

[Ket]

BOINC does support AVX instruction sets, the app running within BOINC automatically detects CPU capabilities itself. The rest is auto configured. It wouldn't actually make sense for any BOINC application to not support AVX instruction sets due to the speed increase a AVX/2/512 code path offers over older instruction set code paths such as the now legacy SSE, for example.

My contacts specifically asked for those Taichi details where it seems like they were going to put extra manpower in to it, but if you aren't going to pass those details on, ok. All I can do is tell them as such and they will have to muddle through, thus extending the solution process...

[Ket]

Updated first post with link for new UEFI, also working on updating driver package. Will be up later today.