Ryzen 7 upgrade 1700-> 3700x on x370 board questions

[wrc1944]

I'm running a multiboot linux/windows10 ~amd64system , with 2 Gentoo ~amd64system USE="experimental" installs, and 4-5 other distros on sda HDD, and Windows 10 on an sdb Samsung Evo 850 250GB SSD.

Motherboard is an AMD/Fatal1ty X370 Gaming K4 with a Ryzen 7 1700, current BIOS is 3.50. GCC is 9.2.0-r3.

I'm planning on going to a Ryzen 7 3700x, which should be a pretty straight forward drop-in replacement since I'm not changing the MOBO at this time, but I'd like some other opinions as to my procedure, outlined below.

step 1. Before changing out the cpu, build two new kernels, with the "zen2" gcc opts instead of my current "native" gcc setting, and one generic x_64.

(Last time, with a 8320 piledriver -> to the Ryzen 1700 and new MOBO, I had big problems with my kernels in rebooting. I had assumed a piledriver kernel would also boot a Ryzen system as in similar amd build upgrades over the years that had always worked. Big mistake! Had to chroot in and build new Gentoo kernels, but all the other distros (binary) and windows detected the new hardware including mobo with no problems).

step 2. With the 1700 still in the system, update current BIOS 350 to 5.10,and then again to the needed 5.40, as outlined here. https://www.asrock.com/mb/AMD/Fatal1ty% ... s.asp#BIOS

Also, update the windows SSD driver to: "AMD all in 1 with VGA driver ver:18.50.16.01_WHQL" or a later version before updating to this BIOS.

step 3. At this point, swap out the old cpu to the 3700x, and reboot, and expect normal operations with new cpu with old mobo.

Some questions:
Has anyone done a Ryzen 1700 -> 3700x upgrade on an x370 mobo (the same board) with only doing the BIOS update first?

Do I need to fully reboot the system on each of the two new successive BIOS updates, or just reboot into the new bios, and update that bios to the final 5.40?

Can I build he new kernels for zen2 while still using the 1700 before installing the new 3700x, and are the new zen2 kernel opts absolutely needed to boot the new system?

My Ryzen 1700 cpu flag info is:

Code: Select all

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca 

Can someone running a new Ryzen 37000x or equivalent system please post their cat /proc/cpuinfo for comparison?

Any obvious thing I'm missing? Thanks much in advance!

[Ant P.]

Here's a 3900X:

Code: Select all

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca

Doing a diff it looks like recompiling isn't necessary, the new CPU isn't missing any features from the old one:

Code: Select all

@@ -62,0 +63 @@
+ibs
@@ -72,0 +74,2 @@
+cat_l3
+cdp_l3
@@ -75,0 +79 @@
+mba
@@ -76,0 +81,2 @@
+ibpb
+stibp
@@ -82,0 +89,2 @@
+cqm
+rdt_a
@@ -86,0 +95 @@
+clwb
@@ -91,0 +101,4 @@
+cqm_llc
+cqm_occup_llc
+cqm_mbm_total
+cqm_mbm_local
@@ -94,0 +108,2 @@
+rdpru
+wbnoinvd
@@ -108,0 +124,2 @@
+umip
+rdpid

My advice is do the BIOS update first while using the old CPU, verify you haven't bricked it there, then do a CMOS reset at the same time you put the new one in. It should do all the necessary rebooting itself between updates but it doesn't hurt to do extra.

[wrc1944]

Ant P.,
Thanks for the diff.

This makes me feel that the 3700x Ryzen might boot right up on any of my current kernels compiled with the gcc opt "native" option set in my config, as long as I get the 5.40 BIOS before I install the new 3700x, which requires going to the 5.10 BIOS first. Do you concur? And as you mentioned, there's no need to build a zen2, or generic x64 kernel (I'm still doing it though)

However, as an early Ryzen adopter my original BIOS was 2.20, and I had some difficulties and after several updates I finally got the 3.50 "bridge" bios working. Also had to RMA the Ryzen 1700 as the early ones had some serious segfault/lockup problems. After the RMA to a newer version 1700, no problems.

But on the Bios stuff, after I got the 3.50 going I seem to recall I tried updating to the 5.10, and couldn't boot with the 1700. Had to revert to 3.50.

So, if that still holds, I won't be able to do a full reboot and will be forced to commit to the 5.10 and reboot direct to 5.10 and direct to 5.40 bios update, which says:

If the current BIOS version is older than P5.10, please update BIOS to P5.10(PinnaclePI-AM4_1.0.0.6) before updating this version.
**** User will not able to flash previous BIOS once upgrading to this BIOS version

Anyone know if a Ryzen 1700 boots OK with a kernel built with the kernel option of zen2 enabled, or if a 3700x Ryzen will for sure boot on a kernel built on a 1700 system with "native" gcc opts enabled?

After the piledriver -> Ryzen 1700 bothersome experiences, I really want to get it right first this time, as in "an ounce of prevention is worth a pound of cure"

[Ant P.]

Looking at the GCC manpage, it seems Piledriver supports some things (TBM, FMA4) that neither Zen option does. That'd explain the problems upgrading in place there, sounds similar to upgrading an AM3 Phenom to Piledriver - they removed 3DNow and similar problems happened. znver2 is a strict superset of znver1 though, so booting your old -march=native kernel should just work.

The BIOS really is the only awkward part here, if there's specific instructions for upgrading a CPU then ignore what I've said about it and go with those.

[wrc1944]

Thanks Ant P.,
Your mention of TBM, FMA4 reminded me that what finally helped me out before was a tip from Tony0945 about changing to

Code: Select all

CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -mno-fma4 -mno-tbm -mno-xop -mno-lwp"

and selecting CONFIG_MK8=y when migrating bulldozer systems to Zen.

It just never occurred to me when upgrading to a new cpu architecture I needed to first build and boot with a kernel using a much older kernel config option than my current cpu was using.

That much older k8 kernel booted right up into the new Ryzen system, and I could then build all future kernels with my usual

Code: Select all

CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -mno-fma4 -mno-tbm -mno-xop -mno-lwp"

Forgot about the https://wiki.gentoo.org/wiki/Ryzen thread. I feel confident now, but I'm still first building a zen2 AND a X_64 generic version before I swap out he cpu, just in case.

Guess the -mno-fma4 -mno-tbm -mno-xop -mno-lwp flags are likely no longer required.

[Ant P.]

-march=k8 is a synonym for -march=amd64, so it should be safe.

(There's actually a 1st-edition Athlon 64 which lacked one instruction GCC assumes all amd64 chips to have by default. Would suck to be the owner of one of those...)

[paulo_cv]

I am currently running Ryzen7 3700x and I have been suffering from segfaults particularly with a high number of jobs.
I have been running stock settings which do not allow me to go to 3200Mhz in RAM and that seems to be more stable, when XMP is turned on it seems that the segfaults are more frequent.

I was also running MARCH="zenver2" but have since then gone back to native.

I have been doing lots of changes to try to solve the segfaults but not sure how it's going to go, there is always the change of faulty hardware but I am not too convinced that is the case since.

[paulo_cv]

Code: Select all

CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -mno-fma4 -mno-tbm -mno-xop -mno-lwp"

Tried these and got a successful webkit-gtk (one of the common offenders with the segfault) and it went through! This could be a solution or at least one step closer to it. Thanks!

[wrc1944]

paulo_cv,
Hope this segfault issue on your 3700x isn't like the problems with the series-1 Ryzen 1700. I just received my 3700x today.

What is your motherboard, and what bios are you using?
With my 1700 early version I had severe segfault and lock-up issues and had to RMA. the newer 1700 versions has been perfect.

Have you tried disabling the C6 state in the bios? That helped somewhat with the segfault issue in the 1700 I had. There were also some other bios settings a lot of people were trying with this problem.

I haven't seen any hardware problems mentioned about the 3700x ( or I would not have ordered one). I think it's more a problem of bios version and/or bios settings, or maybe an over heating the cpu issue?

I'm getting ready to update my bios and install the 3700x in a day or two, but still doing a little more research on other user's experiences in bios versions, etc. before I start.

[paulo_cv]

I have a cheap motherboard MSI B450M Pro-VDH Max

I haven't touched too much on the BIOS except this morning I disabled SMT as I found an old thread from AMD. Granted a lot of the stuff I have found has had to deal with those early problems AMD encountered and I would like to think those were solved in their newer releases and it's just a matter of configuration.

I haven't looked into C6 but I might check that out later, with the CFLAGS settings I changed earlier it appears it could be more stable as webkit-gtk failed consistently when I did more than -J2. I ran it earlier with -J16 and it was successful which gives me a lot of hopes as I had not been able to emerge with that number of jobs regardless of my settings. I might give it a try with a large package later to put it to test.

My temps don't go above 60C even when the segfaults show up so I don't think it's temperature.

[wrc1944]

I assume you have looked at this page. https://www.msi.com/Motherboard/B450M-PRO-VDH-MAX under the support -> bios tabs where the bios update versions are listed. Worth a look, if you still have the original bios, but it seems your board supports Ryzen 3000 processors out of the box, unless I missed something.

I was only using the CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -mno-fma4 -mno-tbm -mno-xop -mno-lwp" to chroot into gentoo and build a new kernel so I could boot after the piledriver 8320 -> Ryzen 7 1700 upgrade to new mobo failed with my older kernels. The problem was that my Piledriver series cpus kernels using "native" all had tbm lwp xop and fma4 enabled by default, and so Ryzen was unable to boot.

I didn't mean continue to use the -march=k8 kernel optiions setting after the Ryzen system was able to boot. Going to zen2 or native should do well then. I don't think in your case k8 would have even been relevant.

Sorry for any confusion.

Looked here https://www.newegg.com/msi-b450m-pro-vd ... 6813144265 and reviews and specs say ryzen 3000 compatible out of the box, so the bios version might or might not be a problem- need to research a bit more.

[paulo_cv]

Yes, I didn't have to do any BIOS upgrade to boot this when I first bought it, it was OK out of the box. I did update it later on while I was trying to troubleshoot the segfault issues.

I have been running these CFLAGS since earlier this morning when I saw this post and I have built several packages with 100% success so I am guessing one or several of these options helped with segfaults I was getting before:

Code: Select all

COMMON_FLAGS="-march=native -O2 -pipe -fomit-frame-pointer -mno-fma4 -mno-tbm -mno-xop -mno-lwp"

I might go back to -march=zenver2 to see if it brings any efficiencies but for now I am extremely happy that packages are compiling fine with -J16 and without errors.

[wrc1944]

Nice! Looks like you're making out OK. It's my understanding that the "native" option is in most cases better than a specific option like zen2, as native allows gcc to detect and utilize ALL features of the specific cpu, instead of a kernel maintainers choices, where some options may be left out.

I'm still curious as to which bios version your board came with. Apparently, the original was 7A38vB0 Release Date 2019-07-23 File Size 17.4 M

The latest one is: 7A38vB4 Release Date 2019-11-11 File Size 13.82 MB

So it's a version sequence of B0, B1, B2, B3, and B4, which being only five versions, is relatively very few. Just counted them, and my x370 asrock k4 has had literally 20 version updates since 2017.

Here's what I'm dealing with: https://www.asrock.com/mb/AMD/Fatal1ty% ... s.asp#BIOS

But with the bios, a good practice is aways: If it aint' broke, think very carefully before "fixing it."

[paulo_cv]

Yeah I don't remember the exact version though I seem to remember it was an April 2019 version. I did upgrade to the latest version though looking at the release notes I didn't see anything that seemed relevant for the problems I was having. I'll have to give it a little more time and see how it does.

[wrc1944]

I'm still on the 1700, and updated to the 5.10 bios on the way to the 5.80 3700x bios, and on the 5.10 bios defaults reboot into Gentoo for testing, an emerge -upDNv @world segfaulted immediately at calculating dependencies. Failed on several retries

Bios 5.10 does still support the 1700, so that wasn'r the problem.
I then recalled that what helped my original 1700 before the RMA replacement 1700 arrived was besides disabling the C6 state It was also recommended by some experts to also disable the OPcache.

I went back into the bios and did so, rebooted with XMP profile enabled, and all is now perfect.

If segfaults bother you again, you might try the OPcache fix. In my bios it's under common zen options, and IIRC so is C6.

Guess I'll do some more testing, and try later on this weekend to go to bios 5.80 and install the 3700x.

[salfter]

I'm planning on going to a Ryzen 7 3700x, which should be a pretty straight forward drop-in replacement since I'm not changing the MOBO at this time, but I'd like some other opinions as to my procedure, outlined below.

step 1. Before changing out the cpu, build two new kernels, with the "zen2" gcc opts instead of my current "native" gcc setting, and one generic x_64.

(Last time, with a 8320 piledriver -> to the Ryzen 1700 and new MOBO, I had big problems with my kernels in rebooting. I had assumed a piledriver kernel would also boot a Ryzen system as in similar amd build upgrades over the years that had always worked. Big mistake! Had to chroot in and build new Gentoo kernels, but all the other distros (binary) and windows detected the new hardware including mobo with no problems).

I recently upgraded from a Core i5 4690K to a Ryzen 7 3800X (different motherboards, obviously...new one's an MSI X570-A Pro), and didn't have to go through all of that to migrate. I have both Gentoo and Windows 10 on an NVMe M.2 stick, which got moved from the old board to the new. At first, the new system was unstable, but that was due to a bug in the ASM1062 SATA controller on the new board, into which a Blu-ray burner is plugged in. Adding libata.atapi_passthru16=0 to the kernel boot options fixed that. I then recompiled the whole system, and it's been running like a champ ever since.

[wrc1944]

My procedure as mentioned in step 1 above worked perfectly, no problems, my prebuilt "zen2" kernels booted fine, and systems run normally.
Now, all my kernels will be built with "native" and not "zen2" for the 3700x processor.