Asrock X370 Fatal1ty Gaming K4 Support Thread

http://i.imgur.com/NDEfTY6.png[/URL]
X370 Fatal1ty Gaming K4 Support Thread


I've been in contact with my contacts so once again can offer up some support. If you have any problems with your Asrock X370 or B350 board post in this here thread, giving as much detail as you can give and I will investigate the problem and pass it along to my Asrock contacts for them to look in to. The BIOS guys are really busy right now so it might take a little while to get a reply from them but rest assured any issues reported to them will not be forgotten about and once I know something you will know something.

This thread is primarily for the K4 as the title would suggest but as I say you are most welcome to post your issue regardless of what Asrock X370 or B350 board you have. I could of started this thread sooner but once I had finalised the K4 review AGESA 1.0.0.6 was only a little while out so decided to have this thread ready to coincide with the release of the new UEFIs for a good foundation starting point.



Driver Package

This is an independent package I have put together consisting of the very latest drivers for Windows 10 64bit, occasionally I will try to find time to update it. As of now the package is for the Gaming K4 only but obviously any Asrock X370 or B350 board that shares the same hardware as the K4 will be able to make use of this package too. The package is a nuts and bolts flavour, no fluff, just what you need to get all of the hardware up and running without running in to any classic issues like the MS generic audio driver causing distorted audio in some cases.

Contained Drivers:

AMD Chipset Drivers: v17.30
Asmedia ASM1143 Driver: v1.16.47.2
Intel I211AT LAN Driver: v22.6
Realtek ALC1220 Audio Driver: v6.0.1.8245 (Should work for boards with other Realtek codecs as well.)

Download Link: [url=https://mega.nz/#!X0g0wTIY!jJs4pJ64wdxH5LpnNn28IfeHNZRFIIN3tc-6uyVhkFE[/url] (432MB)




Asrock X370 Fatal1ty Gaming K4 UEFIs

Pretty explanatory, this is a repository of all the Fatal1ty K4 UEFI images for use with Instant Update unless otherwise noted. Note that I personally do NOT recommend updating the UEFI through Windows only use Instant Update or update the UEFI through pure DOS with a bootable USB stick. Change log is included with each download.

How to Update UEFI: DOS Method

1. Download RUFUS from HERE.
2. Insert a USB stick, run Rufus
3. Place DOS .exe file on the USB stick
4. Reboot, select to boot from the USB stick from the boot menu (or change boot order in the UEFI)
5. Once freeDOS loads type; dir then press enter
6. Look for the filename for the UEFI exe file, type that then press enter
7. Sit back, follow any prompts. The rest is automated.
8. I strongly recommend resetting the UEFI manually by removing the power cord, CMOS battery, and setting the CMOS jumper to the "clear" position.

UEFI Update: Instant Update Method

1. Place UEFI image on a USB stick, reboot
2. Press F2 or Del key to enter UEFI, go to and select Instant Update
3. Select your USB stick from the drop down menu if it isn?t already selected
4. Select the UEFI update file, click to continue
5. The rest is automated.
6. I strongly recommend resetting the UEFI manually by removing the power cord, CMOS battery, and setting the CMOS jumper to the "clear" position.


UEFI 1.2: DOWNLOAD
UEFI 1.3: DOWNLOAD
UEFI 1.4: DOWNLOAD
UEFI 1.5: DOWNLOAD
UEFI 1.6: DOWNLOAD DOS only
UEFI 2.0: DOWNLOAD
UEFI 2.1: DOWNLOAD
UEFI 2.2: DOWNLOAD <- Minimum recommended version
UEFI 2.3: DOWNLOAD
UEFI 2.4: DOWNLOAD
UEFI 2.5: DOWNLOAD
UEFI 3.0: DOWNLOAD <- My minimum recommended version
UEFI 3.1: DOWNLOAD

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.

2. Roccat Kulo 7.1 headsets will not always be initialised properly if they are left plugged in to a USB port when the system is booted.

Possible Solution: Try the latest Asmedia USB drivers, along with updating the drivers for your audio card. Contact Roccat to see if they have a updated driver.

3. Front panel audio problems in the form of sometimes experiencing peculiar high pitch sounds with the Arctis 3 headphones.

Possible Solution: Update Asmedia USB and audio drivers.


3066-3200MHz Memory Tested - X370 K4

This will be a collaberative community effort as I definitely don't have enough time to test a load of memory kits but anyone who wants to partake in this effort there are some strict guidelines to follow;

HCI Memtest MUST be used, with enough instances open to fully utilise installed memory. Free or paid for version is ok (paid for version is only like $5).
HCI MUST be run for a minimum of 15 hours.
All changed options to attain stability need to be provided.
A screenshot with all instances of HCI running plus task manager open on the "Performance" tab needs to be provided for verification.

Results from people will be added here, hopefully aiding those having issues. EDIT: Testing is finished with the current timings I was working on so heres the first kit that can be added to the 3200MHz list for the K4;

F4-3200C15D-16GVK (2x8GB) - Samsung B-Die.

Tested Timings: 16-15-15-15-35, tMAW.MAC 1, tRC 75, Gear Down Disabled, AM4 Advanced Boot Training Disabled

Note: My aim was to find some timings that should be absolutely stable on the X370 K4, if you want to experiment a bit try 16-14-14-14-25, tRC 65.

http://i.imgur.com/O10oOGE.jpg

Quote:

---

Originally Posted by Ket

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 mode

---

Nope, failed both SuperPi 32 MB (I don't have USB stick with Memtest at the moment) and OCCT after just some seconds :(

Well. Geardown does 0 for stability...just lets you use odd CL....trc 52 in most cases is more than loose enough.

Tmac?...many of us leave it @ 0 and can run prime stable over 3200...

Tfaw....trfc... Twcl...trtp and of course primary timings are far more likely to impact stability.

No clue where the info for that other stuff is coming from..it is certainly not ryzen specific knowledge.

Xmp is intel...should not even waste time with it on amd.

Quote:

---

Originally Posted by chew*

Well. Geardown does 0 for stability...just lets you use odd CL....trc 52 in most cases is more than loose enough.

Tmac?...many of us leave it @ 0 and can run prime stable over 3200...

Tfaw....trfc... Twcl...trtp and of course primary timings are far more likely to impact stability.

No clue where the info for that other stuff is coming from..it is certainly not ryzen specific knowledge.

Xmp is intel...should not even waste time with it on amd.

---

You're probably right... I've tried everything though... DRAM Voltage, ProcODT, VDDCR_SOC, VPPM

Tried manual trfc? Flare x is weird on taichi im getting rather odd results with trfc. 132/192/312 is stable. Flare has some rather odd trfc via xmp...

I will plug a set of flare x in tomorrow see what i can come up with but i know default xmp failed prime on taichi a few bios's back.

It has to be some oddball issue. Trident-z same spd passed fine. Basically...your not crazy...it is being more annoying then it should be.

XMP tRFC @ 3200 is 560/416/256 and what you said for 2400 MHz, but yeah DIMMs failed again

there's not a single 3000+ DIMM in the QVL
http://www.asrock.com/MB/AMD/Fatal1t...dex.asp#Memory

frankly, I haven't seen this board run high-speed DIMMs (3200+) of any brand without errors

makes my head spin cause AB350 K4 ($95) runs everything smoothly out of the box

You are not alone...heard same about killer and from what i can tell....same pcb.

Quote:

---

Originally Posted by chew*

Well. Geardown does 0 for stability...just lets you use odd CL....trc 52 in most cases is more than loose enough.

Tmac?...many of us leave it @ 0 and can run prime stable over 3200...

Tfaw....trfc... Twcl...trtp and of course primary timings are far more likely to impact stability.

No clue where the info for that other stuff is coming from..it is certainly not ryzen specific knowledge.

Xmp is intel...should not even waste time with it on amd.

---

Yet there are a lot of people who will carry over their memory kit from a intel build to a AMD one which is why a best possible solution is required. In my own testing setting a tRC of 75, tMAW.MAC to 1 and disabling Gear Down is the difference between memory stability of only a few minutes @ 3200 to several hours. Somewhere between 7 and 11 (overnight HCI run). Disabling Gear Down also switches the Command Rate from 1T to 2T, doesn't hit bandwidth too hard either so yes it will do something for stability in some cases at least. Using the actual Command Rate option in the UEFI doesn't work though stays at 1T regardless.

Quote:

---

Originally Posted by celerity

XMP tRFC @ 3200 is 560/416/256 and what you said for 2400 MHz, but yeah DIMMs failed again

there's not a single 3000+ DIMM in the QVL
http://www.asrock.com/MB/AMD/Fatal1t...dex.asp#Memory

frankly, I haven't seen this board run high-speed DIMMs (3200+) of any brand without errors

makes my head spin cause AB350 K4 ($95) runs everything smoothly out of the box

---

When I reviewed the K4 the QVL had 1 or 2 3200MHz kits on (I mean literally 1 or 2). Either way the kit I'm currently testing does do better with UEFI 2.5 compared to any earlier versions, 3066MHz @ 14-14-14-14-25 1T. Older UEFIs were limited to 2933MHz. I was surprised to see a option for 3066MHz if I'm honest though as it is a weird divider / strap to have.

Did you test performance? Guy with 64 gig in yet another "mainstream that notoriously cannot do 3200" x370 ran off some aida last night. 2933 performance was much better @ 2933 with looser timings vs 3066.

Some straps have a performance hole. If performance goes down then i see no reason for it not to pass stability tests unless it went down due to being unstable.

Stilts RTC tool still shows 1T geardown enabled/disabled. Literally only difference i see is odd cas works with it.

The RipjawsV kit I used for testing G.Skill rate for 2T anyway but I always aim for 1T stability first. On the K4 1T stability @ 3200 is just not possible at least right now but the kit did pass 17 hours of HCI @ 3066 14-14-14-25 1T. To get 3200 stable switching to 2T is necessary with minor tweaks to the timings; 16-15-15-15-35, tMAW.MAC 1, tRC 75, Gear Down Disabled, AM4 Advanced Boot Training Disabled. It's probably not necessary to switch tMAW.MAC to 1 but in my testing it did add a small but noticeable improvement to stability. I also did a quick 3333MHz benchmark test with the same timings in AIDA64. Heres a quick chart I knocked up comparing the semi stable 3200 results from the K4 review, 100% stable 3200 2T results and the quick 3333 bench run;

http://img.photobucket.com/albums/v1...pspnlrbxx5.jpg

For sure you have to fight with the K4 a lot more than you should have to right now to get 3200 running smoothly but once you find the magic number its all smooth sailing with even some OC wiggle room :).

I think its pcb tbh. Other mainstream boards are exhibiting similar issues. That or intentional nerfing to sell higher tier products.

B350s are doing way better than mainstream. Near top tier x370 speeds but at the cost of inability to max out 8c cpu's reliably.

rumours are K4 has been discontinued and will be replaced by Gaming X

the board changes tWR and tRC

tWR 22, board sets 34
tRC 48, board sets 72

something I'm doing wrong or UEFI bug?

Quote:

---

Originally Posted by celerity

rumours are K4 has been discontinued and will be replaced by Gaming X

---

I would ignore those rumors none of my Asrock contacts have said any such thing, quite the contrary in fact they are currently working on memory compatibility with the K4.

Quote:

---

Originally Posted by celerity

the board changes tWR and tRC

tWR 22, board sets 34
tRC 48, board sets 72

something I'm doing wrong or UEFI bug?

---

I don't think so it is the UEFI trying to automatically set the right timings for the board. Asrock and G.Skill are looking in to matters like this as I type. That FlareX memory kit you have, can you give me the model code printed on the back of them along with the G.Skill code (in your case the latter will start with F4-3200). Also, what is the maximum stable speed and timings you can get the modules to run at with UEFI 2.5? Once I have that info I can pass it on to my contacts to look in to :up:

Quote:

---

Originally Posted by chew*

I think its pcb tbh. Other mainstream boards are exhibiting similar issues. That or intentional nerfing to sell higher tier products.

B350s are doing way better than mainstream. Near top tier x370 speeds but at the cost of inability to max out 8c cpu's reliably.

---

The testing I've done with the X370 K4 would suggest Asrock at least are not doing this the RipjawsV kit I'm testing isn't even on the QVL for the K4 but even prior to AGESA 1.0.0.6 the kit ran like a champ @ 2933 14-14-14-14-25 1T and it manages the same results up to 3066MHz with AGESA 1.0.0.6. So far, issues at and above 3200 appear to be a case of some UEFI fine tuning that needs to be done. When I know more, you guys will know more :up:

Quote:

---

Originally Posted by Ket

I would ignore those rumors none of my Asrock contacts have said any such thing, quite the contrary in fact they are currently working on memory compatibility with the K4.

---

Quote:

---

"Sales is saying they are putting the K4 as EOL and replacing it with the Gaming X citing some component changes. I am starting to believe this is in fact true and there is a hardware issue with the K4."

---

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

but if ASRock are working on DIMM compatibility that's good

Quote:

---

I don't think so it is the UEFI trying to automatically set the right timings for the board. Asrock and G.Skill are looking in to matters like this as I type. That FlareX memory kit you have, can you give me the model code printed on the back of them along with the G.Skill code (in your case the latter will start with F4-3200). Also, what is the maximum stable speed and timings you can get the modules to run at with UEFI 2.5? Once I have that info I can pass it on to my contacts to look in to :up:

---

F4-3200C14D-16GFX not sure about what's written on the DIMMs themselves cause I'm to lazy to look xD

highest stable I can get is 2933 MHz 14-14-14-34 @ 1.35 V, SoC 1.1 V. What I consider stable is 8 h Realbench, SuperPi32MB, 3 h OCCT + 1 h each Linpack, 3D, PSU. so very stable.

i did however manage to run SPI32MB @ 3200 MHz (1.4 V) yesterday, that's some success

http://i67.tinypic.com/fbi5b9.png

Quote:

---

Originally Posted by celerity

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

but if ASRock are working on DIMM compatibility that's good


F4-3200C14D-16GFX not sure about what's written on the DIMMs themselves cause I'm to lazy to look xD

highest stable I can get is 2933 MHz 14-14-14-34 @ 1.35 V, SoC 1.1 V. What I consider stable is 8 h Realbench, SuperPi32MB, 3 h OCCT + 1 h each Linpack, 3D, PSU. so very stable.

i did however manage to run SPI32MB @ 3200 MHz (1.4 V) yesterday, that's some success

http://i67.tinypic.com/fbi5b9.png

---

If any potential K4 buyers have concerns about the board being EOL let me know and I can check with my contacts but based on what my contacts have said to me that is not the case. Once you get that info from the back og your Flares I can pass it on to be looked in to :up:

@Celerity, forgot to ask, when you tested your memory was that with the CPU OCd or at stock settings? Also, has your memory issues improved or got worse with UEFI 2.5 compared to say UEFI 2.4? Either way what results did you get? My contacts are very interested in these points so they can investigate further.

Quote:

---

Originally Posted by Ket

If any potential K4 buyers have concerns about the board being EOL let me know and I can check with my contacts but based on what my contacts have said to me that is not the case. Once you get that info from the back og your Flares I can pass it on to be looked in to :up:

---

Quote:

---

Originally Posted by Ket

@Celerity, forgot to ask, when you tested your memory was that with the CPU OCd or at stock settings? Also, has your memory issues improved or got worse with UEFI 2.5 compared to say UEFI 2.4? Either way what results did you get? My contacts are very interested in these points so they can investigate further.

---

CPU @ stock when memtest, with 2.40 crashed during boot, with 2.50 I can boot Win10 (but crash when using) - so slightly better

i let you know g.skill s/n shortly

i'm currently investigating a CPU OC stability issue, will let you know as well

Quote:

---

Originally Posted by celerity

CPU @ stock when memtest, with 2.40 crashed during boot, with 2.50 I can boot Win10 (but crash when using) - so slightly better

i let you know g.skill s/n shortly

i'm currently investigating a CPU OC stability issue, will let you know as well

---

Alright great :up:

Quote:

---

Originally Posted by Ket

Alright great :up:

---

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.

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..
;)

Quote:

---

Originally Posted by chew*

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..
;)

---

what are you banging on about

Here is what i am "banging on about"

http://i1253.photobucket.com/albums/...psndxmuy0o.jpg

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

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

Quote:

---

Originally Posted by chew*

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

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...
http://i1253.photobucket.com/albums/...psdxfkfqof.jpg

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?

Wrong thread for that.

Quote:

---

Originally Posted by celerity

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 :up: 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.

Quote:

---

Originally Posted by chew*

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 :up:.

Quote:

---

Originally Posted by Ket

Thanks I will pass that info on :up: 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

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/

Quote:

---

Originally Posted by 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/

---

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

Quote:

---

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?

Quote:

---

Originally Posted by Kobaltrock

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

Quote:

---

Originally Posted by celerity

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.

---

Quote:

---

Originally Posted by 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...
http://i1253.photobucket.com/albums/...psdxfkfqof.jpg

---

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.

Quote:

---

Originally Posted by celerity

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.

Quote:

---

Originally Posted by Kobaltrock

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.

Quote:

---

Originally Posted by Ket

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

---

tried p-state oc, failed as well

Quote:

---

Originally Posted by celerity

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.

http://i.imgur.com/8N18v4N.png

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.

http://i.imgur.com/1FPQgF9.png

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.

Quote:

---

Originally Posted by Ket

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!

Quote:

---

Originally Posted by celerity

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 :up: 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.

Quote:

---

Originally Posted by Ket

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 :up: 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

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.

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 :up:

Quote:

---

Originally Posted by 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 :up:

---

:up:

UEFI 3.0 just released also :yepp:

Quote:

---

Update AGESA to 1.0.0.6a

---

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. :down:

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).

Quote:

---

Originally Posted by Ket

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

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.

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.

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...

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

I have a huge list.

You care to explain a bug that happens on ln2? Ever used ln2?

Would you be able to explain it while being able to describe the insulation methods someone else used to remove all doubt it was not user error?

If not then ;) I got this.

Updated driver package in first post. Will try to catch up on anything I need to over the next few days folks.