cancel
Showing results for 
Search instead for 
Did you mean: 

Drivers & Software

sat
Adept III

Re: gcc segmentation faults on Ryzen / Linux

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

Support Ticket Process

0 Kudos
kingfish
MVP

Re: gcc segmentation faults on Ryzen / Linux

Ok...try this one > Email Form

0 Kudos
fujii
Adept I

Re: gcc segmentation faults on Ryzen / Linux

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

alfonsor
Adept II

Re: gcc segmentation faults on Ryzen / Linux

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.

0 Kudos
amdmatt
Community Manager
Community Manager

Re: gcc segmentation faults on Ryzen / Linux

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.

alfonsor
Adept II

Re: gcc segmentation faults on Ryzen / Linux

I finally found a way to make parallel compilation works (here): enabling LLC (Load Line Calibration) in BIOS. But it makes me very worried...

amdmatt
Community Manager
Community Manager

Re: gcc segmentation faults on Ryzen / Linux

Enabling low levels of LLC (Levels 1-2) is not dangerous, it just ensures less voltage droop when the processor is under heavy load.

maxrussell
Journeyman III

Re: gcc segmentation faults on Ryzen / Linux

Same problem here on CentOS (I'll try LLC option Tomorrow).

No problem on Win10.

0 Kudos
amdmatt
Community Manager
Community Manager

Re: gcc segmentation faults on Ryzen / Linux

Hi Folks,

I appreciate your patience and i have some suggestions you can try.

In the Asus BIOS there is an option called called OPCache Control. Disabling this may resolve this issue.

Another suggestion is to try disabling SMT. Look for an option in the Bios called 'Disable SMT'.

Please try one or both of the suggestions above depending on which Motherboard you have and let me know how you get on.

alfonsor
Adept II

Re: gcc segmentation faults on Ryzen / Linux

Not all the BIOS have the OPCache option, f.e. my Gygabyte K7 doesn't. Disabling SMT alleviates the problem, but it doesn't solve it. As well the LLC I cited, which greatly reduces the segfaults, but they are still present.

The problem is not about the time needed to solve the iusse ("patience"), but it is if there will ever be a solution. I am developing a sense of "this is how it is".