gcc segmentation faults on Ryzen / Linux

Thanks for the post, I believe you opened a service request on this same issue. I will respond to your service request so we can continue the discussion there to save duplicating.

I understand, we're looking at the issue.

As a workaround, try to disable either SMT or the uOP cache via the CMOS setup of your mainboard. For your workload the latter will probably give you the smaller performance hit, but I don't know whether that specific setup item is exposed by your ASUS board.

In any case, AMD is most probably already aware of potential underlying issues.

In my case (I'm not a original questioner), uop could't change by BIOS and disabling

SMT couldn't resolve this issue. I issued a ticket 8200749112, it's not the Gentoo guy's

ticket which ahartmetz said, and it's not public . But, unfortunately, it hasn't updated recently.

I want to know whether anyone who in AMD handles this issue and how about the progress

(under reproducing, finding the root cause, fixing, and so on), especially the former.

In addition, I think sharing this kind of information in public (here?) is better to prevent

many duplicated private tickets for both AMD and users including me.

What's even better is for anyone with this issue report it to AMD > AMD Issue Reporting Form

We're still investigating the issue, once i have an update i will post about it here.

Here it is another victim of this problem, with a ryzen 1600. In Gentoo, just two parallel emerge (f.e gcc in a shell and mesa in another shell) with all core used (-j13) trigger the problem, with the compilation that fails suddenly with (usually) the following text in dmesg

segfault at 11 ip 0000000000406215 sp 00007ffcd77a2248 error 6 in bash[400000+ac000]

tried different memory kits with no result.

Just FYI, I opened my ticket from the following URL.

Support Ticket Process

Ok...try this one > Email Form

• Ryzen 7 1700
• ASRock AB350 Pro4 (AGESA 1.0.0.6)
• Windows 10 (Ubuntu 17.04 in VMWare)

I see the similar problem in different situation. I'm using Ubuntu in VMWare on Windows 10.I see the crash of gcc and bash while parallel-compiling WebKitGtk+.

Neither updating to the latest UEFI BIOS nor disabling SMT in UEFI BIOS settings solve the issue. I can't find uOP cache setting in my UEFI BIOS.

I found this web page <https://forums.gentoo.org/viewtopic-p-8069900.html?sid=2da2652865b21738ab70b247be4b90b3#8068952>, and I disabled Cool'n'Quiet in my BIOS. It seems that this solves the issue for me.

UPDATE:

• I found uOP cache setting in my UEFI (Advanced > AMD CBS > Zen Common Options > Opcache Control). I'll try disabling it. 
• Disabing CnQ haven't solve my problem. It'd changed nothing. I don't know what has lowered the reproduction rate of my system significantly.
• Updating to AGESA 1.0.0.6 changes nothing

UPDATE 2:

I tried to build gst-plugins-bad-1.10.4.tar.xz in three settings.

cache control: enabled

SMT: enabled

ASLR: on

2 failures in 881 builds

cache control: disabled

SMT: disabled

ASLR: on

3 failures in 852 builds

cache control: enabled

SMT: enabled

ASLR: off

0 failures in 554 builds

Disabling both uOP cache and SMT does nothing for me.

Disabling ASLR seems effective for me.

Here SMT or any other BIOS settings doesn't change a thing. Today the ryzen machine compiled 1290 packages and it had 15 segfaults, it means 1 segfault every 86 compilations. So, this machine is "unusable" and it should be a "working machine".

I opened a ticket and I am waiting for some answer, but my main interest is in understanding what is causing this problem: after having tried 4 MBs, 3 RAM kits and after having bought a brand new PSU, such in case the old one was the culprit, I don't know what to do. Is it a CPU problem? Should the users of ryzen CPUs with this problem RMA their CPUs? Is it fixable with an AGESA update? Or there is no solution atm at all?

Thanks in advance. A long long time AMD user.

There is no need to open new tickets on this issue. We are investigating and as soon as there is any updates, i will let you all know in this thread.