AMD Zen/Ryzen thread

wrc1944 · Posted: Sun Aug 27, 2017 6:04 pm Post subject:

On my backup AM3+ FX 8320 box, I compiled gcc-7.2.0 and moved to it from 7.1 when it appeared in my @world updates, and am running it normally.

However, on the two Gentoo systems on my Ryzen/AM4 box, I can't compile gcc-7.2.0 ( get Internal compiler error, MCE errors, and segfaults even with ASLR and Opcache disabled, and SMT disabled or not). No thermal issues. Also failed to compile kernel 4.12.9 until I disabled ASLR. It's curious that previously I had not run into these problems, but they have started to appear in the last 2-3 weeks, including an occasional random freeze and/or lockup, even when idle.

After reading a myriad of long detailed threads on the subject (including on the week of the Ryzen cpu manufacture and RMA's) It's become obvious I'm now suffering from the same problems. From what some Ryzen owners are saying, the AMD RMA process is quite involved in that they make you file a ticket and go through various AMD ordered testing and detailed time consuming questioning and otherwise "proving" to them you actually have a problem.

Then you have to hope you are RMA'd a cpu from at least week 25 of manufacture, which according to all those getting that far, may or may not work. Some have even done multiple RMA's and still not resolved the problems, along with weeks of downtime on the specific box.

Not the ideal situation, to say the least. I was going to RMA, but for now guess I'll just see if I can get along with the bios tweaks, and wait until AMD issues a real fix and/or a new stepping, hopefully in a few months, and RMA then, (if still possible). To be fair, there are reports of some RMA chips not having the problems, but it seems pretty random.

This seems to be more of a problem for us Gentoo users, or anyone who needs to do a lot of compiling. BTW, anyone have any thoughts/experience on the LLC settings in the bios to help in this (mentioned as a possible aid in reducing problems.

Bottom line: In my opinion AMD needs to be doing Ryzen RMA's for anyone having a week 30 2017 or earlier chip, no questions asked, and immediate shipment. Or even expand that to any week chip manufactured and sold BEFORE they announce a definitive and guaranteed resolution, with a detailed explanation as to the real cause of the problem.

Come on, AMD. We bought these chips and paid in good faith expecting that they actually worked well for the intended purpose. For users doing heavy compiling, this is not working out. Constant segfaults, freezes, and random ICE's render Ryzen problematic for Gentoo users.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

fcl · Tux's lil' helper Joined: 31 Dec 2016 Posts: 77

Disabling OPCache helped some on my Ryzen 1600 but I still had occasional segfaults. Running memory at default 2133 helped a bit further. Upgrading to gcc-7.2 got rid of almost all segfaults. It's still not 100% stable so I'm buying a new chip. I made a deal with a vendor and they're willing to make sure that they send a CPU that's manifactured after week 25. I can't be bothered to RMA the current CPU so I'm selling it to my buddy (he doesn't use Linux much and ~never compiles stuff such as mesa/gcc).

A bit bothersome.. but I do like the performance of Ryzen so that's that.

mir3x · Guru Joined: 02 Jun 2012 Posts: 455

For idle freezes in kernel:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

It seems im quite lucky that gcc7.1 is flawless for me

( just chrome doesnt like gcc7 ...)
I tested gcc7.2 with aslr disabled but it changes nothing for me. Maybe there is some option in gcc to stop agreesive memory usage ?

EDIT: ill try gcc 7.2 wihtout -pipe
_________________
Sent from Windows

wrc1944 · Posted: Sun Aug 27, 2017 7:38 pm Post subject:

fcl,
Interesting about your gcc-7.2.0 experience. So far, I can't get 7.2 to compile on both Ryzen systems. I was thinking maybe it wasn't possible yet to compile 7.2 on Ryzen systems yet, but your comment gives me new hope.

Guess I'll try temporarily dropping my GSkill 3200 Flare memory down to 2133 along with disabled ALSR, SMT, and OPcache and maybe even setting -j1 or j-2 in make.conf and see if I can get 7.2 on the Ryzen systems. I also read that with ASLR disabled, enabling SMT actually was better than disabled. Who knows without trying it yourself.

From what I read on a huge 240 page thread last night, even week 25 chips are still basically a crap shoot. All those comments by people really testing out these chips didn't give me much confidence about week 25. One guy said they sent him a week 30, but I think I'll hold off for at least 2 more months, unless AMD issues an announcement all is fixed in post week (whatever ) chips.

BTW, for several kernel versions now I have set:
CONFIG_RCU_NOCB_CPU - y
and RCU_NOCB_CPU_ALL

That was before my problem started to really show up big time. I need more info on the LLC options, and also read about disabling C states might help. The quest continues. :roll:

If anyone else has gcc-7.2.0 running on their Ryzen system, please post and offer some tips.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Chewi · Posted: Sun Aug 27, 2017 7:55 pm Post subject:

NeddySeagoon · Posted: Sun Aug 27, 2017 7:57 pm Post subject:

wrc1944,

AMD won't announce a fix. That's the same as announcing that some Ryzen CPUs are faulty.
That would be met with demands for a recall.
It won't happen, look how hard Intel resisted a recall of the Pentiums with the FDIV bug.

If you want to go down the RMA path, may as well get started.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Naib · Posted: Sun Aug 27, 2017 8:22 pm Post subject:

thumper · Guru Joined: 06 Dec 2002 Posts: 552 Location: Venice FL

Naib · Posted: Sun Aug 27, 2017 9:22 pm Post subject:

Chewi · Posted: Sun Aug 27, 2017 9:26 pm Post subject:

There does seem to be a common theme here, most of us had managed to work around the issues for a while and they've only just started coming back. I haven't done a full world update since mid-June. It's only since updating the kernel or possibly GCC that I've started seeing issues again. I'd need to go back to 4.11.6 to fully convince myself but it looks as though the problematic change is something that was introduced in 4.12 and backported to 4.11. Incidentally the fix I mentioned above is one such change.

wrc1944 · Posted: Sun Aug 27, 2017 11:31 pm Post subject:

I just tried to compile gcc-7.2.0 yet again, with ASRL, OPcache disabled, and with SMT (enabled or disabled) doesn't solve it. Got a segfault again, but the last error was one I hadn't seen before:

wrc1944 · Posted: Mon Aug 28, 2017 2:42 am Post subject:

For anyone wishing a source of info generated by Ryzen users, here's that actively ongoing " gcc segmentation faults on Ryzen / Linux" 248 page thead from amd:

https://community.amd.com/thread/215773?start=15&tstart=0

Some Gentoo users there too, plus lots of detailed testing results/discussions by lots of very seriously dedicated AMD users. I'm learning some good stuff.
This thread should yield some really good info soon because a lot of users who already RMA'd will be updating us with their new testing results.

User udamanfunks is kindly archiving info in a nice spreadsheet: https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Tony0945 · Posted: Mon Aug 28, 2017 4:13 pm Post subject:

I'm really disgusted with this situation and AMD's lack of explanation. Then I saw this picture: http://www.phoronix.com/image-viewer.php?id=amd-tr-1950x&image=amd_tr1950x_1_lrg Made in China. All my good AMD's were fabbed in Dresden. Some people are reported AMD as cooperative in RMA, others are complaining they have to jump through hoops. Then besides the seg fault problem there is the random freeze problem. I'm really glad I was too busy yesterday to finalize my order at Newegg. Today I decided to buy a Kabylake instead, then I found that I have to start a search for a suitable heat sink all over again. Maybe I'll just wait for coffeeelake. Maybe I'll just stick with the old Athlon II. It's slow but it doesn't crash when I build and it doesn't freeze randomly. AMD hasn't been worth spit since they hired that CEO who destroyed Motorola Semiconductor. Maybe if they hadn't fired Jim Keller, Zen would actually work.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

I'm really glad I resisted the temptation to buy one of these at launch, but then again after the hardware issues of first-gen FX and Phenom chips I was pretty much expecting a trainwreck here too. I could wait for a Ryzen 2 but at this point I'd rather abandon x86 entirely, it's becoming a choice between malice or incompetence.

Tony0945 · Posted: Mon Aug 28, 2017 7:39 pm Post subject:

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

wrc1944 · Posted: Mon Aug 28, 2017 10:36 pm Post subject:

After realizing I foolishly forgot to disable 'Cool 'n Quite, I did so but again gcc-7.2.0 failed to compile, same segfault after about 15 minutes, but saw less warnings before that happened.

I then decided to try a toolchain rebuild:

mir3x · Guru Joined: 02 Jun 2012 Posts: 455

wrc1944 · Posted: Tue Aug 29, 2017 7:36 pm Post subject:

mir3x,
I reviewed some general info on overclocking ryzen cpus, not that I plan on overclocking, but just in hopes of a slight tweak or two to help address the segfault issue preventing the emerge of gcc-7.2.0. Seems like the SOC default on my ASrock 370 k4 was set at 1.1, and the max on it and other boards is said to be 1.3 (unless you're on liquid nitrogen coolers), so I figured 1.2 was OK to try. Since it still didn't allow me to emerge 7.2 and I had the same segfault, guess I'll revert to auto. I noticed no increase in tmps at 1.2.

I'm still thinking it's a bug in gcc-7.2.0, but then again fcl upgraded to 7.2.0, so it's apparently possible on some Ryzen systems.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Naib · Posted: Tue Aug 29, 2017 7:50 pm Post subject:

Naib · Posted: Wed Aug 30, 2017 9:10 am Post subject:

Well a double build of the toolchain with 7.2 followed by an emerge -e @system completed fine
_________________

wrc1944 · Posted: Wed Aug 30, 2017 10:11 am Post subject:

Naib,
I'd sure like to know your settings that allowed you to get that far. Congrats!

(make.conf. settings, or any bios tweaks?)

I just ran an emerge -e @ system (458 packages) after a toolchain rebuild, finished perfectly (on 7.1.0-r1) in 2 hrs and 40 min. I figured I'd clean up @system first cause I did recently update glibc and wanted to eliminate that as any possible problem.

Then once again tried gcc-7.2.0 and still got the same problem at the usual 15-20 minutes into the compile:

mir3x · Guru Joined: 02 Jun 2012 Posts: 455

If u really want to check 7.2 then u can try that way ( i noticed that often seg fault doens't happen with -ggdb on my personal project,
it really hard to find bug then, its not ryzen specific)
compile gcc with -ggdb -O0
revert to -O2
rebuild your toolchain
test it

but its not worth time wasting.

I got 7.2, first thing i did was emerge -e system ... it failed in 374/375 package (at cmake )
then i tried emerge mesa and it failed instantly, so i reverted to 7.1.

( I wont be suprised if gcc7.2 would work perfectly with -ggdb and -O0 but it would be 20-40% performance loss, or maybe not so big ?
In most project half time is spent on automake ... my personal project with 300 files on automake compiles in more than minute, in cmake with ninja less than 10 secs ...)
_________________
Sent from Windows

Bloot · Posted: Wed Aug 30, 2017 1:02 pm Post subject:

GCC 7.2 compiled just fine here, using GCC 6.4. My chip is a week 07 Made in China.

Chewi · Posted: Wed Aug 30, 2017 7:53 pm Post subject:

I haven't moved off this flaky 4.11.12 kernel yet but the behaviour I'm seeing is really starting to unsettle me. Java dies a lot. Tabs in Vivaldi occasionally die. Just now, I had git die on me, leaving it in an odd state. Trying to recover from this state made it even worse. The files mentioned here have nothing to do with what I was working on and the rename looks crazy.