Segfaults during compilation on AMD Ryzen.

boudin · n00b Joined: 15 May 2017 Posts: 4

I've installed the latest AGESA (1006) through this beta bios http://forum.gigabyte.us/thread/886/am4-beta-bios-thread?page=1

The situation is much better, but still had a few compilation errors (weird one though). I'm now running with the XMP profile of my DDR4 without changing the voltage, cool'n'quiet on with -j13 for MAKEOPTS. Before I wasn't able to build anything in this configuration and my whole system would become unstable once segfault will start to appear.
Now I've rebuilt randomly GCC and mesa a few times + some other stuff. I did had two compilation errors with mesa but overall it's much more stable. I'm gonna start again toying with my ram timings and voltage to see if it can reach a stable point.

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

mark_lagace · Posted: Wed May 31, 2017 8:35 pm Post subject:

TL;DR: Does anyone have a stable Ryzen 7 system?

I've been pulling my hair out trying to get the system stable for compiling and every option mentioned in this thread has so far not been successful.

My system:

I've tried:

In all cases, I will get random segfaults during compiles. They happen more frequently with large packages and higher levels of threading (i.e. -j16 segfaults more than -j8 ) but even with memory at 2133, SMT off and -j8, compiles will segfault. I've just compiled kernel 4.11.3 and will see if that makes any difference, but I'm not holding my breath.

Having gone through all of this, my question at this point is whether ANYONE has a stable, Ryzen 7 system?

FWIW, memtest86+ runs through multiple passes with no issues. Prime95 under Win10 in stress test mode with 16 helpers running also doesn't crash (at least for the 2-3 hours that I let it run).

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

trippels · Posted: Thu Jun 01, 2017 4:31 am Post subject:

It should also be noted that the crashing compiler is just a noisy symptom of a silent CPU corruption.
I have also seen git projects get corrupted on Ryzen (sha checksum issues).

So the point is you cannot trust your data on this CPU. It might be OK for a pure gaming PC,
but for everything else it is utterly unacceptable.

NeddySeagoon · Posted: Thu Jun 01, 2017 7:33 am Post subject:

trippels,

The only separation between code and data in a PC is context.
Why any PC CPU operate correctly executing code but not when processing data?

I have seen it on more exotic architectures that have separate busses and memory arrangements for CPU instructions and data but there is separation at the hardware level.
_________________
Regards,

NeddySeagoon

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

trippels · Posted: Thu Jun 01, 2017 8:39 am Post subject:

Naib · Posted: Thu Jun 01, 2017 8:53 am Post subject:

Harvard vs von Neumann architecture
_________________

NeddySeagoon · Posted: Thu Jun 01, 2017 9:00 am Post subject:

trippels,

trippels · Posted: Thu Jun 01, 2017 9:16 am Post subject:

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

roarinelk · Guru Joined: 04 Mar 2004 Posts: 520

krinn · Watchman Joined: 02 May 2003 Posts: 7470

isn't that the earlier ryzen are just all defective? Have a look (sorry guys, you will have to click here and there, zillions pubs! they deserve an award for top awful website)

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

here it is a gcc segfault, with no dmesg info; it happened during compilation of gcc 6.3.0 itself (with a parallel mesa emerging)

../../gcc-6.3.0/lto-plugin/lto-plugin.c: In function ‘process_symtab’:
../../gcc-6.3.0/lto-plugin/lto-plugin.c:945:1: internal compiler error: Segmentation fault

mark_lagace · Posted: Fri Jun 02, 2017 5:28 pm Post subject:

tuggbuss · Apprentice Joined: 20 Mar 2017 Posts: 222

Phoronics is mentioning this issue

http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Compiler-Issues

trippels · Posted: Sat Jun 03, 2017 4:57 am Post subject:

Looking at the https://community.amd.com/message/2796982 thread,
it seems to be an issue with the new micro-op cache. The AMD guy recommends
to disable it in the BIOS (OPCache Control).

roarinelk also reported "u-op cache crc mismatch" MCEs.

Bigfoot77 · n00b Joined: 15 Dec 2006 Posts: 16

Hmm, well I haven't read through every post, but I've gotten through at least half of them. Not sure if anyone else has mentioned this themselves yet, but I figured I'd at least throw it out there in case it's useful:

I built my Ryzen 7 1800X machine a week after launch day. Nothing was overclocked and was just running at stock speeds. My mobo's BIOS version at the time of initial install was v1.0. I (very sporadically) ran into the same segfaults when building larger packages on that initial install (identical to the first post in this thread), but for the most part everything seemed to build without issue and I didn't think much of the few segfaults. Not long after, I upgraded to BIOS v1.3 for my mobo which included the updated AGESA 1.0.0.4a code.

While running v1.3 of the BIOS. I needed to re-emerge world and during that re-emerge is when I started seeing the segfaults constantly. They started to happen more and more often as I got through the package list. By the end, I could no longer build mesa without segfaulting which became my standard for testing the segfaults. *sometimes* gcc would build without segfaulting, but pretty much any large package couldn't make it through. This went on for a few weeks. I was about to RMA the CPU and as a last ditch effort just before, I decided to try a fresh install on a new partition. Interestingly, that install worked completely flawlessly and built every package (mesa included). For the past 1.5 - 2 months, that install has continued to work without issue and is what I'm still currently using. I update almost every day and haven't had any segfaults no matter what gets built.

Has anyone tried a second install running a brand new BIOS to see what happens? I don't know the inner workings of GCC all that well, but is it possible that something during those early buggy BIOS releases causing something to build incorrectly (GCC, libtool, something?) that would always propagate to anything else that was built? The only difference between my initial install when I first built the machine and my current install is the BIOS version. No other hardware has changed. The BIOSes before v1.3 were pretty flaky for me and I didn't use the machine too much, so I can't comment if the segfaults were actually happening a lot during that time or not. I did see the few segfaults with v1.0 initially, so at least something was going on from the beginning.

For reference, my system specs are:

Ryzen 7 1800X
MSI Tomahawk B350 mobo
Kingston HyperX Fury 2400 MHz RAM
gcc 6.3.0 (CFLAGS=-O2 -pipe -march=native -fno-stack-protector)

Please let me know if anyone wants any other hardware/software info about my setup. I know this isn't a ton to go on, but it's worth mentioning (I sure hope I didn't jinx myself

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

Bigfoot77, yes I tried 3 times a complete gentoo installation and the problem is still there. But your story made me think I always used the same kernel configuration from my main installation... Did you change your kernel config during re-installing?

Naib · Posted: Sat Jun 03, 2017 9:28 am Post subject:

alfonsor · n00b Joined: 13 Oct 2007 Posts: 16

yup, everything was "fresh" here; just the kernel configuration

I am pretty sure it is not a kernel problem; my fixation is with cache coerence, anyway let's give it a try, what could be better then spending the weekend hacking ryzen segfaults?