• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

AMD Zen 2 (Ryzen 3000) - *** NO COMPETITOR HINTING ***

That 7C02v18 BIOS you linked to in your initial post looks the correct one, from what I’ve experienced you don’t need to do incremental updates on BIOSes, you can just go to the latest <stable> one regardless of the starting version.

The only suggestion I would have offered was to format the disk as NTFS but that’s already been mentioned.

I’m still waiting on a non-beta BIOS for my MSI board, otherwise I would have attempted the process myself and reported back.

I’ve had the shipping confirmation on my 3600, got my AM4 bracket for the cooler and NVME drive ready to go so just waiting on an official BIOS.

I’ll keep an eye out for any other suggestions.

I use Fat 32 for my USB sticks when flashing BIOS.
 
No idea, but an idle that high, seems high to me after coming from a 2700.
I can't decide if its the reported bad BIOS/Asus mess up with power, bad thermal paste/seating or is normal.
Once I've had some tea in a bit i'm gonna see if i can collate some data from different reviews to see what the averages are temp wise thus far.
if you're using an asus x570 board...probably this: https://www.overclock.net/forum/10-amd-cpus/1728758-strictly-technical-matisse-not-really.html
gonna have to wait for a bios update.

tl;dr - asus screwed up.
 
That 7C02v18 BIOS you linked to in your initial post looks the correct one, from what I’ve experienced you don’t need to do incremental updates on BIOSes, you can just go to the latest <stable> one regardless of the starting version.

The only suggestion I would have offered was to format the disk as NTFS but that’s already been mentioned.

I’m still waiting on a non-beta BIOS for my MSI board, otherwise I would have attempted the process myself and reported back.

I’ve had the shipping confirmation on my 3600, got my AM4 bracket for the cooler and NVME drive ready to go so just waiting on an official BIOS.

I’ll keep an eye out for any other suggestions.

From the stuff being published online msi full release bios might take a while as there isn’t enough room on bios chip for click bios 3 and the coding needed for each generation and amd earlier apu cpu:( plus msi click bios is one of the larger bios out there from there own ui etc .
 
https://www.msi.com/blog/the-latest-bios-for-amd-300-400-series-motherboard

the beta bios for msi motherboards are there for ryzen 3000 series
Just my luck, there is none for msi b450 tomahawk.

I did try this one a few times now - 7C02v18, still no luck. Might be my 32gb USB stick, or I might need to update my BIOS, as its only 1.2 atm and im not sure how to update the BIOS to 1.3, then 1.4 etc, till I'm on the latest version. There is no updates like that on the site.
https://www.msi.com/Motherboard/support/B450-TOMAHAWK
 
Try it.... They are hynix ic so not the best for OC and I did not test that particular kit...

3200 to 3600 not as big a gain as previous gen in any case...

My priority is testing my own stuff and qualifying for systems..

Do you have any experience with Vengeance Pro 16GB DIMMs? I’m looking at getting a 3900X and 64GB of RAM, and I’m wondering how the 2666 performs and overclocks to 3200+.
 
Last edited:
Updated yes, along with BIOS and all other drives, pre-3900X upgrade.

re: power plan, tried it on both the generally recommended windows balanced, and with ryzen balanced too. Not really a lot of difference tbh.
That doesn't sound fun , are you watching the activity in hwinfo etc and can you see it clocking down.

You'd expect to see some big differences between Ryzen Balanced and Windows Balanced due to it not clocking down

Did I read one of the reviews mentioned heat more to the edge of the die on the 3900 ( debauer ? )
 
if you're using an asus x570 board...probably this: https://www.overclock.net/forum/10-amd-cpus/1728758-strictly-technical-matisse-not-really.html
gonna have to wait for a bios update.

tl;dr - asus screwed up.
Asus X470-F Gaming Strix.
Do we know if the problem is exclusive to the X570 boards, or did Asus mess up across the board? No pun intended.
That doesn't sound fun , are you watching the activity in hwinfo etc and can you see it clocking down.

You'd expect to see some big differences between Ryzen Balanced and Windows Balanced due to it not clocking down

Did I read one of the reviews mentioned heat more to the edge of the die on the 3900 ( debauer ? )
I am using HWInfo64, yes.
Can see it clock all the way down to 1800Mhz when on Windows balanced, whereas the Ryzen one never clocks down at all.
 
I use Fat 32 for my USB sticks when flashing BIOS.

FAT32 is the normal method, agreed, however I read a couple of posts on the MSI forum where guys have only got the file to appear by having the stick formatted to NTFS.

It is a bit disappointing that MSI seem to be a bit behind on the BIOS updates for the previous gen chipsets but as 8pack has mentioned, they’re obviously going to be putting the majority of resources into X570 to get that working as it should.

Saying that, everything is a little all over the place anyway.

Oh well, good things come to those who wait.
 
Strictly technical: Matisse (Not really)
07/08/2019 6:33 PM (GMT) - Update on the bios issue on Crosshair VIII Hero motherboard ("the thing").


Earlier today I received a response to my inquiries from ASUS. The response was rather technical and I cannot go into the specifics of what exactly it involved.
However, it confirmed my suspicions of what actually has caused the seen anomalies. A long story short; a mistake has been made and it has affected the results of multiple reviewers, including my own. In my own case, I ended
up discarding my own affected multithreaded results alltogether, before even releasing them. I'm still angry because of a lot of my own and other peoples work went to waste because of it. But like I said, mistakes do happen.
In this case all of the evidence and known facts suggest that this was indeed a mistake, caused by an extremely tight schedule and miscommunication between several different parties. Infact, all of the facts I can personally verify
indicate that despite the rather suspicious way this mistake happened, there never was any malicous intent involved.

ASUS also provided me a new bios versions for both Crosshair VIII Hero and Formula boards, which correct the mistake made in newer than the AMD approved 0066 bios builds.
Based on my own testing done on the 3900X SKU, the CPU now meets its specification in terms of the allowed power consumption (same way, as the approved 0066 build did). The new build has currently not been validated, so
it will take some time until its changes get reflected to builds available to the larger audience.

What kind of effects will the fixed bioses have then?

Based on my own testing (do note that silicon variation exists and that the sample size is one for 3900X):

- ~ 27W lower average power package power consumption (VDDCR_CPU & VDDCR_SoC, i.e. the main power rails)
- 7°C lower temperature (tDie, while using DeepCool Assassin II cooler)
- < 90MHz average frequency loss across all twelve cores in MT workloads

The above figures were recorded during Blender 2.80b runs, but they should translate almost directly to Cinebench R20 NT as well (based on my experience).

The peak power difference between the faulty and the fixed bioses is around 35W (Prime95).

Despite there is no question that a mistake was made, I'd still like to thank ASUS for two specific reasons: they didn't try to deny the existence of the issue (which btw. is the usual reponse within the industry), but also fixed it immediately.
I also do feel bad for the bios engineer, who had to stay over(over)-time to get the bios build done. Thanks for that. I also have to feel bad for ASUS, because this mistake might have smirched the reputation of their brand new Crosshair VIII -series motherboards.
And make no mistake, these are one of the best, if not the best X570 boards available at the market (a personal opinion).

At this point you should ask yourself if ASUS paid me off?
Everyone can be bought, its just the matter of the offered sum or bargain. Everyone claiming otherwise either lives in self-deception or frankly, is a moron.
I myself could definitely be bought. And rather cheaply too, I think. The thing is, just that at least until writing this, nobody has even tried to do so.

Besides of this statement, I also corrected an error AMD pointed out to me.
Despite the 3900X CPU has fused (factory programmed) Fmax ceiling of 4.65GHz, AMD only advertises 4.60GHz maximum boost.
I must admit that I was initially surprised to see the 3900X having 4.65GHz fused maximum boost limit, since AMD indeed only mentions 4.60GHz in their marketing materials.
Nevertheless, I'm yet to reach the advertised 4.6GHz either, so in that regard the only thing which changes is the CPU falling 25MHz short instead of 75MHz short of its advertised frequency.

Sauce - https://www.overclock.net/forum/10-amd-cpus/1728758-strictly-technical-matisse-not-really.html
 
Have people seen this:
https://www.techpowerup.com/257201/...ail-amds-zen2-backwards-compatibility-promise

AMD succeeded in delivering on its backwards-compatibility promise for the 3rd generation Ryzen processors on motherboards based on AMD 300-series and 400-series chipsets. This promise was very close to being derailed suggests a community thread on MSI forums. According to MSI representatives active on the forum, the capacity of the SPI flash EEPROM chip that stores the motherboard UEFI firmware is woefully limited to cram in the AGESA ComboAM4 1.0.0.3a microcode on many of its motherboards.

The company had to make several changes to its UEFI BIOS package that's currently being circulated as a "beta," to accommodate support for 3rd generation Ryzen processors along with AGESA ComboAM4 1.0.0.3a. First, it had to kick out support for A-series and Athlon processors based on the 28 nm "Bristol Ridge" silicon. Second, it had to [and this is a big one], kick the RAID module, breaking SATA RAID on many of its motherboards. Third, it had to replace its feature-rich Click BIOS 5 setup program with a barebones "GSE Lite" Click BIOS program, which lacks many of the features of the original program, and comes with a dull, low-resolution UI. This program still includes some essential MSI-exclusive features such as A-XMP (which translates Intel XMP profiles to AMD-compatible settings), Smart Fan, and M-Flash.The scary part? Many other motherboard brands appear to be using 16-megabyte EEPROMs on their older socket AM4 motherboards. These companies are bound to run into similar ROM capacity issues unless they keep their UEFI setup programs lightweight. Motherboards based on the latest X570 chipset feature 32-megabyte EEPROMs. The AMD X570 chipset lacks support for not just "Bristol Ridge," but also first-generation Ryzen "Summit Ridge" and "Raven Ridge" processors.

We recommend that unless you literally possess a 3rd generation Ryzen processor, do not update the BIOS of your older socket AM4 motherboard. You may risk losing features and break your RAID volumes. Find out the latest version of BIOS that has the classic AGESA PinnaclePI 1.0.0.6 microcode, and use that instead.
 
Another problem:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-3K-RdRand-Systemd-Maybe

As outlined yesterday, AMD's Ryzen 3000 processors are very fast but having issues booting newer Linux distributions. The exact issue causing that boot issue on 2019 Linux distribution releases doesn't appear to be firmly resolved yet but some are believing it is an RdRand instruction issue on these newer processors manifested by systemd.

For those that missed my launch day article, check it out for more details and then all the benchmarks for when running very performant on the likes of Ubuntu 18.04 LTS where the issue does not occur. What people are jumping on today are the old reports of AMD RdRand problems for using this hardware RNG instruction causing issues on older pre-Zen2 processors. It is possible though the RdRand support regressed even further and thus in worse shape with Zen 2, but I haven't seen that officially acknowledged by AMD nor if it firmly addresses the issue.

It does make some sense though as outlined yesterday newer Linux 5.0~5.2 kernels do boot on older Ubuntu 18.04 LTS era distributions, which are on older systemd releases. There is a change in the latest systemd that does help that was merged in May to eat bad RdRand values on AMD CPUs.

I was aware of the AMD RdRand issue on older CPUs and among my attempted debugging of the problem pre-launch was trying to blacklist the x86_64 crypto modules, AESNI_Intel, and related bits to no avail. But it's possible that this change made by systemd in May could workaround the issue. There hasn't been a new systemd release since April which would explain why rolling-release distributions like Arch Linux and Clear Linux still aren't able to boot these newest AMD processors.

Anyhow, right now it's looking like borked RdRand support is a feasible explanation if indeed accurate. There is the systemd workaround in systemd Git but hopefully it's something that can be addressed via a firmware/microcode update as otherwise no modern Linux distributions will be booting properly for these new AMD processors until the next rounds of releases -- it's unlikely we'd see say a Fedora or Ubuntu re-spin simply with the new systemd build integrated. But at least it it can be worked around in the microcode/firmware would allow existing Linux distributions to begin playing nicely with these shiny and powerful new AMD boxes.

More details when I have them; I'm away the next two days but will begin resuming more tests ASAP to try to confirm the RdRand behavior.
 
Back
Top Bottom