I see similar failures. Various gcc versions all the way from 4.4.7 up to 6.3. Various cross compile architectures. I tried with three motherboards (Gigabyte AB350 Gaming, Gigabyte AB350 Gaming 3, and MSI Tomahawk B350). 2 different sets of 4x8GB RAM (3000). Two different Ryzen 1700X CPUs. Various DRAM speed settings; all available BIOS versions I could get my hands on. Problem is always the same: Random internal compiler errors due to segmentation fauls in different source files.
Setting devices/system/cpu/cpu0/cpufreq/scaling_governor to "performance" seems to improve the situation a little, but not much.
Guenter
Segfaults during compilation on AMD Ryzen.
Message
I tried a fresh stage 3 in a chroot w/o any optimization at all, gcc-5.4.0, and stable most everything else and I was still seeing them.Keepco wrote:Can't seem to reproduce the gnutls failure, just tried recompiling it 15 times, worked every time. Guess my problems is elsewhere.c1pherx wrote:Yea. I spoke too soon. I've reduced the frequency of it happening, but it is still happening. On to the next ideas.
One pattern I'm noticing is that now it seems to be happening with builds that use libtool. This may just be a correlation, but my most recent failures were gnutls (first time that's happened) and libseccomp (first time here too). Both use Libtool.
EDIT: Just re-emerged GCC without -march=native it seems like that did the job.
I did get a BIOS update yesterday AM that seems to have helped, but I still see the occasional segfault. What's fascinating is that it's always during /bin/sh libtool ..... This could be a coincidence just by virtue of the fact that many large packages use libtool, but maybe it will be a clue for someone else.
bios update recommended
I just got a BIOS update for my Gigabyte board (AB350 Gaming 3, BIOS F6). With that BIOS, the segmentation faults seem to be gone. I would suggest for everyone to install the latest BIOS (it seems that several vendors released an update today) and check if that fixes the problems.
Update: I spoke too early. Still happens, but less often. Oh well
.
Update: I spoke too early. Still happens, but less often. Oh well
.I am a Debian user but I have observed very similar behavior on my 1800X running on an Asus B350 Plus. This has been the case for every BIOS release available, including the beta 0605 release. I have tried two processors, two sets of memory, replacing the motherboard with a Gigabyte AB350, and a different PSU. Neither the CPU nor memory are overclocked and temperatures are around 60 Celcius under load. Strangely enough, the machine can run mprime for days on end without any trouble. However, an average run of the Glasgow Haskell Compiler's testsuite exhibits a handful of failures (typically segmentation faults). Even stranger, if I run a few mprime threads alongside a run of GHC's testsuite, mprime will itself sometimes crash with a segmentation fault.
This sort of spooky action at a distance leads me to suspect that there is a rather nasty hardware bug lurking in this chip. I'm very glad to hear I'm not the only one seeing this behavior; I was beginning to think that I was just cursed.
This sort of spooky action at a distance leads me to suspect that there is a rather nasty hardware bug lurking in this chip. I'm very glad to hear I'm not the only one seeing this behavior; I was beginning to think that I was just cursed.
The recent wave of bios updates improve RAM timing and fix a OPcode error (that does cause windows to bsod ).
If you are saying a recent (ie last couple of days) bios update has improved stability i would not be surprised. As Gentoo is a src distribution we are more likely to be hit by these things via gcc
If you are saying a recent (ie last couple of days) bios update has improved stability i would not be surprised. As Gentoo is a src distribution we are more likely to be hit by these things via gcc
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
this is just great, i don't even have windows at home. How am i supposed to reproduce this in windows?groeck wrote:I wonder if anyone is able to reproduce the problems under Windows. So far all feedback I have received from board vendors is "we don't support Linux", with an optional "we'll be happy to help you if you can reproduce the problem with Windows".
I see the problem with literally dozens of different gcc versions, including "Ubuntu 5.4.0-6ubuntu1~16.04.4", which is the latest version available for the 16.04 release. I don't think the gcc version or the Linux distribution makes any difference.Naib wrote:The recent wave of bios updates improve RAM timing and fix a OPcode error (that does cause windows to bsod ).
If you are saying a recent (ie last couple of days) bios update has improved stability i would not be surprised. As Gentoo is a src distribution we are more likely to be hit by these things via gcc
Gcc does not have explicit Zen support until gcc 6. I'm running gcc 6.3.0 on an Athlon II box that I had planned to convert to ryzen until this segfault business surfaced. It's a deal breaker for me. Perhaps gcc 6.4 will fix it. But first they have to figure out why.groeck wrote:I don't think the gcc version or the Linux distribution makes any difference.
Please note that currently -march=znver1 is not tuned at all.Tony0945 wrote:Gcc does not have explicit Zen support until gcc 6. I'm running gcc 6.3.0 on an Athlon II box that I had planned to convert to ryzen until this segfault business surfaced. It's a deal breaker for me. Perhaps gcc 6.4 will fix it. But first they have to figure out why.groeck wrote:I don't think the gcc version or the Linux distribution makes any difference.
It is mostly a copy of bdver* and will generate unnecessary slow code in many cases.
I would not recommend using it until it gets properly tuned by AMD.
I see the problem when cross compiling. Also, even if there is no explicit zen support, gcc should not crash.Tony0945 wrote:Gcc does not have explicit Zen support until gcc 6. I'm running gcc 6.3.0 on an Athlon II box that I had planned to convert to ryzen until this segfault business surfaced. It's a deal breaker for me. Perhaps gcc 6.4 will fix it. But first they have to figure out why.groeck wrote:I don't think the gcc version or the Linux distribution makes any difference.
At least I'm not alone. I have two systems generating occasional segfaults during compiling:
- Asus B350M-A with Ryzen 5 1600 // 16GB (2x8GB), Kernel 4.10.8, latest BIOS
- Asus B350M-A with Ryzen 7 1700 // 16GB (2x8GB), Kernel 4.10.8, latest BIOS
Both systems show the same symptoms.
The systems do run fine, even under heavy load for hours. It seems only the compiling causes the segfaults.
- Asus B350M-A with Ryzen 5 1600 // 16GB (2x8GB), Kernel 4.10.8, latest BIOS
- Asus B350M-A with Ryzen 7 1700 // 16GB (2x8GB), Kernel 4.10.8, latest BIOS
Both systems show the same symptoms.
The systems do run fine, even under heavy load for hours. It seems only the compiling causes the segfaults.
People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect...
See this: http://www.phoronix.com/scan.php?page=a ... ver1&num=1
There are two bulldozer instructions that ryzen does not support and Phoronix reports "compilation failures" (segfaults?)
We (I) don't know what 5.4 detects for native on a Ryzen. I think there are some gcc commands to find out. Or try something like -march=k8-sse3
I would think that the flags gcc was compiled with would be the significant ones.
There are two bulldozer instructions that ryzen does not support and Phoronix reports "compilation failures" (segfaults?)
We (I) don't know what 5.4 detects for native on a Ryzen. I think there are some gcc commands to find out. Or try something like -march=k8-sse3
I would think that the flags gcc was compiled with would be the significant ones.
Thank you for your help.
In the meantime I found this page: https://wiki.gentoo.org/wiki/User:Maffb ... afts/Ryzen.
They suggest
I'll do two things now:
1) I'll try the "haswell" approach on the R5
2) I'll try gcc-6.3.0 on the R7.
I'll report back as soon as I have results.
In the meantime I found this page: https://wiki.gentoo.org/wiki/User:Maffb ... afts/Ryzen.
They suggest
Code: Select all
CFLAGS="-O2 -march=haswell"1) I'll try the "haswell" approach on the R5
2) I'll try gcc-6.3.0 on the R7.
I'll report back as soon as I have results.
People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect...
I really don't see why AMD's latest processor would have Intel optimizations.
IIRC there was a bug report that tlked of changing some tables in gcc. Scary stuff for me.
EDIT:
Comment 3 here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80313
IIRC there was a bug report that tlked of changing some tables in gcc. Scary stuff for me.
EDIT:
Comment 3 here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80313
that was my edit based upon the Gentoo chat ryzen thread https://forums.gentoo.org/viewtopic-p-8 ... ml#8056840drizzt wrote:Thank you for your help.
In the meantime I found this page: https://wiki.gentoo.org/wiki/User:Maffb ... afts/Ryzen.
They suggestI'll do two things now:Code: Select all
CFLAGS="-O2 -march=haswell"
1) I'll try the "haswell" approach on the R5
2) I'll try gcc-6.3.0 on the R7.
I'll report back as soon as I have results.
My Ryzen5 stuff arrives on Friday so i wanted to ensure all the bits of info i need exist
Last edited by Naib on Mon Apr 17, 2017 7:40 am, edited 1 time in total.
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
what march are you using gcc-6.3 has zen core but it is poorly optimised. Prior to gcc6.3 hasswell march appears the best.groeck wrote:I see the problem with literally dozens of different gcc versions, including "Ubuntu 5.4.0-6ubuntu1~16.04.4", which is the latest version available for the 16.04 release. I don't think the gcc version or the Linux distribution makes any difference.Naib wrote:The recent wave of bios updates improve RAM timing and fix a OPcode error (that does cause windows to bsod ).
If you are saying a recent (ie last couple of days) bios update has improved stability i would not be surprised. As Gentoo is a src distribution we are more likely to be hit by these things via gcc
If you pick something different gcc might inject opcode your CPU does not have
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;