suaefar / ryzen-test Goto Github PK

If you are getting segfaults with kill-ryzen double check your RAM settings, on my Taichi X370 motherboard with my UA1733PGS when you load default settings, RAM will drop to 2133MHz and VDDCR_SOC will go down to 0.880V with DRAM at 1.2V. If kill-ryzen is run on this setting, you get a segfault in a couple of minutes.

However loading 2933MHz XMP profile, will bump VDDCR_SOC to 1.096V & DRAM Voltage to 1.368V, and kill-ryzen is then able to run for many hours with zero issues.

Voltage is probably far too low, especially on default SOC for such an extensive test.

More info can be found here: https://www.reddit.com/r/Amd/comments/7ho4uv/is_the_culprit_of_linux_segfault_on_ryzen_cpu/

Make sure to double check your settings or you might think you have a faulty CPU, when it's not, especially if it's made after week 25.

Might be a good idea to add some of this information to the readme? I've read many forum posts recommending running this script on 2133MHz and default settings, which can be a problem.

Can this bug be fixed by gcc update？
It‘s too trouble to RMA my ryzen cpu.

I have used your program to check my Ryzen 7 and got the error on segmentation.
Thanks

Using the latest GIT version I get this in the terminal:

$ ./kill-ryzen.sh
Install required packages
[sudo] password for keantoken:
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version (12.3).
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.
Create compressed ramdisk
64G
mount: wrong fs type, bad option, bad superblock on /dev/zram0,
missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

~$ inxi -bxx
System:    Host: ronin Kernel: 4.12.0-10.1-liquorix-amd64 x86_64 bits: 64 gcc: 6.4.0
           Desktop: Xfce 4.12.3 (Gtk 2.24.31) dm: lightdm Distro: Debian GNU/Linux buster/sid
Machine:   Device: desktop Mobo: ASUSTeK model: ROG STRIX B350-F GAMING v: Rev X.0x
           UEFI [Legacy]: American Megatrends v: 0809 date: 08/01/2017
CPU:       Quad core AMD Ryzen 5 1500X (-HT-MCP-) arch: Zen rev.1 speed: 3500 MHz (max)
Graphics:  Card: NVIDIA GK208 [GeForce GT 730] bus-ID: 26:00.0 chip-ID: 10de:1287
           Display Server: x11 (X.Org 1.19.3 ) driver: nvidia Resolution: [email protected]
           OpenGL: renderer: GeForce GT 730/PCIe/SSE2 version: 4.5.0 NVIDIA 375.82 Direct Render: Yes
Network:   Card: Intel I211 Gigabit Network Connection
           driver: igb v: 5.4.0-k port: e000 bus-ID: 1e:00.0 chip-ID: 8086:1539
Drives:    HDD Total Size: 370.1GB (49.8% used)
Info:      Processes: 355 Uptime: 9 min Memory: 2932.9/7985.5MB
           Init: systemd v: 234 runlevel: 5 default: 2 Gcc sys: 7.2.0 alt: 4.4/4.6/4.8/4.9/5/6
           Client: Shell (bash 4.4.121 running in xfce4-terminal) inxi: 2.3.34 

I'm a Ryzen linux user and wanted to try and reproduce what you are seeing with segfaults.

However, I noticed in buildloop.sh, you are using make -j 1

I'm surprised this is happening with only one thread, most reported the errors when using make -j 16 (for ryzens with 8 cores)

Can't get past loop-11 and it just freezes and does nothing anymore

`[pindacolada@moonman ryzen-test-master]$ ./kill-ryzen.sh
Create compressed ramdisk
64G
Download GCC sources
--2021-09-26 20:22:22-- ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-7.1.0/gcc-7.1.0.tar.bz2
=> 'gcc-7.1.0.tar.bz2'
Resolving ftp.fu-berlin.de (ftp.fu-berlin.de)... 130.133.3.130
Connecting to ftp.fu-berlin.de (ftp.fu-berlin.de)|130.133.3.130|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /unix/languages/gcc/releases/gcc-7.1.0 ... done.
==> SIZE gcc-7.1.0.tar.bz2 ... 84303533
==> PASV ... done. ==> RETR gcc-7.1.0.tar.bz2 ... done.
Length: 84303533 (80M) (unauthoritative)

gcc-7.1.0.tar.bz2 100%[=========================>] 80.40M 11.0MB/s in 9.3s

2021-09-26 20:22:31 (8.66 MB/s) - 'gcc-7.1.0.tar.bz2' saved [84303533]

Extract GCC sources
Download prerequisites
2021-09-26 20:22:47 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2 [2383840] -> "./gmp-6.1.0.tar.bz2" [1]
2021-09-26 20:22:49 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-3.1.4.tar.bz2 [1279284] -> "./mpfr-3.1.4.tar.bz2" [1]
2021-09-26 20:22:51 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.0.3.tar.gz [669925] -> "./mpc-1.0.3.tar.gz" [1]
2021-09-26 20:22:54 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.16.1.tar.bz2 [1626446] -> "./isl-0.16.1.tar.bz2" [1]
gmp-6.1.0.tar.bz2: OK
mpfr-3.1.4.tar.bz2: OK
mpc-1.0.3.tar.gz: OK
isl-0.16.1.tar.bz2: OK
All prerequisites downloaded successfully.
cat /proc/cpuinfo | grep -i -E "(model name|microcode)"
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
model name : AMD Ryzen 5 1600X Six-Core Processor
microcode : 0x8001138
sudo dmidecode -t memory | grep -i -E "(rank|speed|part)" | grep -v -i unknown
sudo: dmidecode: command not found
uname -a
Linux moonman 5.14.7-arch1-1 #1 SMP PREEMPT Wed, 22 Sep 2021 21:35:11 +0000 x86_64 GNU/Linux
cat /proc/sys/kernel/randomize_va_space
2
/ /mnt/ramdisk/workdir
/mnt/ramdisk/workdir
Using 12 parallel processes
[loop-0] Sun Sep 26 20:22:54 CEST 2021 start 0
[KERN] -- Journal begins at Wed 2021-05-12 23:12:39 CEST. --
[KERN] Sep 26 20:22:21 moonman kernel: audit: type=1101 audit(1632680541.607:170): pid=3182 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="pindacolada" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[KERN] Sep 26 20:22:21 moonman kernel: audit: type=1110 audit(1632680541.607:171): pid=3182 uid=1000 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[KERN] Sep 26 20:22:21 moonman kernel: audit: type=1105 audit(1632680541.607:172): pid=3182 uid=1000 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[KERN] Sep 26 20:22:21 moonman kernel: zram: Added device: zram0
[KERN] Sep 26 20:22:21 moonman kernel: audit: type=1106 audit(1632680541.614:173): pid=3182 uid=1000 auid=1000 ses=2 msg='op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[KERN] Sep 26 20:22:21 moonman kernel: audit: type=1104 audit(1632680541.614:174): pid=3182 uid=1000 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[KERN] Sep 26 20:22:21 moonman kernel: zram0: detected capacity change from 0 to 134217728
[KERN] Sep 26 20:22:22 moonman kernel: EXT4-fs (zram0): mounted filesystem with ordered data mode. Opts: discard. Quota mode: none.
[KERN] Sep 26 20:22:54 moonman kernel: kauditd_printk_skb: 27 callbacks suppressed
[KERN] Sep 26 20:22:54 moonman kernel: audit: type=1101 audit(1632680574.942:202): pid=3267 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="pindacolada" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
[loop-1] Sun Sep 26 20:22:55 CEST 2021 start 0
[loop-2] Sun Sep 26 20:22:56 CEST 2021 start 0
[loop-3] Sun Sep 26 20:22:57 CEST 2021 start 0
[loop-4] Sun Sep 26 20:22:58 CEST 2021 start 0
[loop-5] Sun Sep 26 20:22:59 CEST 2021 start 0
[loop-6] Sun Sep 26 20:23:00 CEST 2021 start 0
[loop-7] Sun Sep 26 20:23:01 CEST 2021 start 0
[loop-8] Sun Sep 26 20:23:02 CEST 2021 start 0
[loop-9] Sun Sep 26 20:23:03 CEST 2021 start 0
[loop-10] Sun Sep 26 20:23:04 CEST 2021 start 0
[loop-11] Sun Sep 26 20:23:05 CEST 2021 start 0`

is this an expected behavior and means that it failed or am i doing something wrong?

But not because of a segfault

./md-unwind-support.h: In function 'x86_64_fallback_frame_state':
./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type 'struct ucontext'
       sc = (struct sigcontext *) (void *) &uc_->uc_mcontext;
                                               ^~

Sounds like the gcc 7.2 sources should compile: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712

Hi, I'm using Arch Linux and there is no apt-get. For Arch users it should be "sudo pacman base-devel".
Maybe do something like:

if PKGMGR="$( which apt-get 2>/dev/null )"; then sudo "$PKGMGR" build-essential; fi
if PKGMGR="$( which pacman 2>/dev/null )"; then sudo "$PKGMGR" base-devel; fi
...

Install required packages
Reading package lists...
Building dependency tree...
Reading state information...
build-essential is already the newest version (12.4ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Create compressed ramdisk
64G
Download GCC sources
--2018-08-21 12:32:34-- ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-7.1.0/gcc-7.1.0.tar.bz2
=> ‘gcc-7.1.0.tar.bz2’
Resolving ftp.fu-berlin.de (ftp.fu-berlin.de)... 130.133.3.130
Connecting to ftp.fu-berlin.de (ftp.fu-berlin.de)|130.133.3.130|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /unix/languages/gcc/releases/gcc-7.1.0 ... done.
==> SIZE gcc-7.1.0.tar.bz2 ... 84303533
==> PASV ... done. ==> RETR gcc-7.1.0.tar.bz2 ... done.
Length: 84303533 (80M) (unauthoritative)

82300K .......... .......... ....... 100% 6,14M=30s

2018-08-21 12:33:08 (2,69 MB/s) - ‘gcc-7.1.0.tar.bz2’ saved [84303533]

Extract GCC sources
Download prerequisites
2018-08-21 12:33:24 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2 [2383840] -> "./gmp-6.1.0.tar.bz2" [1]
2018-08-21 12:33:28 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-3.1.4.tar.bz2 [1279284] -> "./mpfr-3.1.4.tar.bz2" [1]
2018-08-21 12:33:31 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.0.3.tar.gz [669925] -> "./mpc-1.0.3.tar.gz" [1]
2018-08-21 12:33:35 URL: ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.16.1.tar.bz2 [1626446] -> "./isl-0.16.1.tar.bz2" [1]
gmp-6.1.0.tar.bz2: OK
mpfr-3.1.4.tar.bz2: OK
mpc-1.0.3.tar.gz: OK
isl-0.16.1.tar.bz2: OK
All prerequisites downloaded successfully.
cat /proc/cpuinfo | grep -i -E "(model name|microcode)"
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
model name : AMD Ryzen 7 2700X Eight-Core Processor
microcode : 0x8008202
sudo dmidecode -t memory | grep -i -E "(rank|speed|part)" | grep -v -i unknown
Speed: 2133 MT/s
Part Number: F4-3200C14-16GTZR
Rank: 2
Configured Clock Speed: 1067 MT/s
Speed: 2133 MT/s
Part Number: F4-3200C14-16GTZR
Rank: 2
Configured Clock Speed: 1067 MT/s
uname -a
Linux home-pc 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
cat /proc/sys/kernel/randomize_va_space
2
/ /mnt/ramdisk/workdir
/mnt/ramdisk/workdir
Using 16 parallel processes
[loop-2] ter ago 21 12:33:37 -03 2018 start 0
[loop-2] ter ago 21 12:53:52 -03 2018 build failed
[loop-2] TIME TO FAIL: 1217 s
[loop-0] ter ago 21 12:33:35 -03 2018 start 0
[loop-0] ter ago 21 12:53:53 -03 2018 build failed
[loop-0] TIME TO FAIL: 1218 s
[loop-4] ter ago 21 12:33:39 -03 2018 start 0
[loop-4] ter ago 21 12:53:54 -03 2018 build failed
[loop-4] TIME TO FAIL: 1219 s
[loop-1] ter ago 21 12:33:36 -03 2018 start 0
[loop-1] ter ago 21 12:53:55 -03 2018 build failed
[loop-1] TIME TO FAIL: 1220 s
[loop-3] ter ago 21 12:33:38 -03 2018 start 0
[loop-3] ter ago 21 12:53:55 -03 2018 build failed
[loop-3] TIME TO FAIL: 1220 s
[loop-5] ter ago 21 12:33:40 -03 2018 start 0
[loop-5] ter ago 21 12:53:56 -03 2018 build failed
[loop-5] TIME TO FAIL: 1221 s
[loop-7] ter ago 21 12:33:42 -03 2018 start 0
[loop-7] ter ago 21 12:53:57 -03 2018 build failed
[loop-7] TIME TO FAIL: 1222 s
[loop-6] ter ago 21 12:33:41 -03 2018 start 0
[loop-6] ter ago 21 12:53:58 -03 2018 build failed
[loop-6] TIME TO FAIL: 1223 s
[loop-8] ter ago 21 12:33:43 -03 2018 start 0
[loop-8] ter ago 21 12:53:58 -03 2018 build failed
[loop-8] TIME TO FAIL: 1223 s
[loop-9] ter ago 21 12:33:44 -03 2018 start 0
[loop-9] ter ago 21 12:54:00 -03 2018 build failed
[loop-9] TIME TO FAIL: 1225 s
[loop-11] ter ago 21 12:33:46 -03 2018 start 0
[loop-11] ter ago 21 12:54:01 -03 2018 build failed
[loop-11] TIME TO FAIL: 1226 s
[loop-10] ter ago 21 12:33:45 -03 2018 start 0
[loop-10] ter ago 21 12:54:01 -03 2018 build failed
[loop-10] TIME TO FAIL: 1226 s
[loop-12] ter ago 21 12:33:47 -03 2018 start 0
[loop-12] ter ago 21 12:54:04 -03 2018 build failed
[loop-12] TIME TO FAIL: 1229 s
[loop-13] ter ago 21 12:33:48 -03 2018 start 0
[loop-13] ter ago 21 12:54:04 -03 2018 build failed
[loop-13] TIME TO FAIL: 1229 s
[loop-14] ter ago 21 12:33:49 -03 2018 start 0
[loop-14] ter ago 21 12:54:05 -03 2018 build failed
[loop-14] TIME TO FAIL: 1230 s
[loop-15] ter ago 21 12:33:50 -03 2018 start 0
[loop-15] ter ago 21 12:54:07 -03 2018 build failed
[loop-15] TIME TO FAIL: 1232 s

Hi, I have just tested this tool against a Ryzen 1500X 1746PGS and it seems to segfault when using the default settings on a Asus Prime X370-Pro (BIOS v.4012).

However, it seems that if I go to the AMD CBS config in the BIOS and set the OpCode Optimization setting to Disabled I am able to run the tool without any [KERN] segfault warning.

However, I get a "TIME TO FAIL: 671 s" (and then later ones for the rest of the processes, next ones are 674s, 1101s, 1120s...) but the previous line just says "build failed". I went to /mnt/ramdisk/workdir/buildloop.d/loop-0/build.log and found out a gcc error:

/mnt/ramdisk/workdir/buildloop.d/loop-0/./gcc/xgcc -B/mnt/ramdisk/workdir/buildloop.d/loop-0/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include    -g -O2 -O2  -g -O2 -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I/mnt/ramdisk/workdir/gcc-7.1.0/libgcc -I/mnt/ramdisk/workdir/gcc-7.1.0/libgcc/. -I/mnt/ramdisk/workdir/gcc-7.1.0/libgcc/../gcc -I/mnt/ramdisk/workdir/gcc-7.1.0/libgcc/../include -I/mnt/ramdisk/workdir/gcc-7.1.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /mnt/ramdisk/workdir/gcc-7.1.0/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /mnt/ramdisk/workdir/gcc-7.1.0/libgcc/unwind-dw2.c:403:0:
./md-unwind-support.h: In function 'x86_64_fallback_frame_state':
./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type 'struct ucontext'
       sc = (struct sigcontext *) (void *) &uc_->uc_mcontext;
                                               ^~
make[3]: *** [/mnt/ramdisk/workdir/gcc-7.1.0/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1
make[3]: Leaving directory '/mnt/ramdisk/workdir/buildloop.d/loop-0/x86_64-pc-linux-gnu/libgcc'
make[2]: *** [Makefile:21950: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/mnt/ramdisk/workdir/buildloop.d/loop-0'
make[1]: *** [Makefile:27079: stage1-bubble] Error 2
make[1]: Leaving directory '/mnt/ramdisk/workdir/buildloop.d/loop-0'
make: *** [Makefile:942: all] Error 2

Maybe we are building versions of gcc known not to work, but I am fearing whether the test's reproducitbility is jeopardized in any way.

Archlinux uses pacman instead of dnf and apt-get. The script exits when it tries to install required development packages.

Just leaving this here for anyone else:
Referring to issue #29 where the actual compile fails instead of it segfaulting, due to this bug:
https://stackoverflow.com/a/52513771/39334

Here's a diff to get going again, using gcc source 8.3.0:

# diff kill-ryzen-DIST.sh kill-ryzen.sh 
45c45
< wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-7.1.0/gcc-7.1.0.tar.bz2 || exit 1
---
> wget ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-8.3.0/gcc-8.3.0.tar.xz || exit 1
48c48
< tar xf gcc-7.1.0.tar.bz2 || exit 1
---
> tar xf gcc-8.3.0.tar.xz || exit 1
51c51
< (cd gcc-7.1.0/ && ./contrib/download_prerequisites)
---
> (cd gcc-8.3.0/ && ./contrib/download_prerequisites)

# diff buildloop-DIST.sh buildloop.sh 
18c18
<   ${CDIR}/gcc-7.1.0/configure --disable-multilib &> configure.log || error "configure"
---
>   ${CDIR}/gcc-8.3.0/configure --disable-multilib &> configure.log || error "configure"

It might be helpful for some people to compare your non segfaulting CPU output with theirs (like a counterpart the current example-output.txt)

I'm wondering if any can confirm if this is still a valid test? I downloaded 17.04 and ran the tests as described and can't make it more than 200 seconds running all stock settings. I'm on a week 43 Ryzen 1700 and I can't seem to make anything else fail. 8hrs of Prime95, 8hrs of Memtest86, etc.

I've played with the DRAM voltage as well as SoC voltage and it didn't have any affect. One thing I noticed was that my integrated wifi adapter would throw a message in syslog and as soon as that happened this kill ryzen script would fail. I disabled the wifi adapter in bios and that allowed it to run longer which makes me wonder if this script fails on false positives?

For instance, getting rid of the ramdisk, freeing up the disk space, etc.

Does someone have experience with Ubuntu LTS distributions like 16.04 for example? How fast do segfaults occur?

Since 17.04 is discontinued, most official mirrors do not offer downloading anymore. I could only find some US and China mirrors, which let's you download with something like 300 KB/s from Europe.

Additionally, I think it is also not the best practice to test with a discontinued OS.

So far I have tested Ubuntu 18.04 LTS (gcc7) on a pen drive and my regular Arch Linux (gcc8.1), but both fail after >= 1200s on all cores:

error: dereferencing pointer to incomplete type ‘struct ucontext’
       sc = (struct sigcontext *) (void *) &uc_->uc_mcontext;

...but this is because Removal of 'struct ucontext' in glibc >= 2.26. This also applies for Ubuntu 18.04.

Considering this, is there any suggested distribution besides 17.04?

btw: other builds, for example gcc-8.1, did not fail on Arch yet.

So my CPU used to crash all the time and be affected by this problem. The failures were under 10 minutes - with most happening in the first 2-3 minutes.

Fast forward to today, and I started the RMA process with AMD. They want a screenshot of what is happens when I run the test and it fails. But - One problem, I can't get my CPU to fail anymore.

I'm running Fedora 27, which has:

$ rpm -qa | grep gcc | sort
gcc-7.2.1-2.fc27.x86_64
gcc-c++-7.2.1-2.fc27.x86_64
gcc-gdb-plugin-7.2.1-2.fc27.x86_64
libgcc-7.2.1-2.fc27.i686
libgcc-7.2.1-2.fc27.x86_64

I've tried running with the args of 8 2 as well as 4 4 or even 8 4 - but nothing seems to cause the segfault.

Gigabyte have a newish 'opcache control' on the AB350 Gaming 3 mainboard - and that doesn't seem to make any combination fail - I've tried the same tests for 2+ hours with it set to all three options - Auto, Enabled, Disabled.

So, has this been fixed in software somehow? Has gcc fixed the compiler? has something else happened?

Thoughts?

Hey, I ran ryzen-test for more than one hour on this config:
EDIT: OS: Ubuntu 18.04 LTS
Ryzen 5 1600 @ stock speed
MSI B350 Tomahawk @ latest BIOS
2x4GB RAM @ default BIOS speeds/voltage (2133MHz)
IMPORTANT: My RAM is actually not officially supported on my motherboard according to its MSI page. The RAM model I have is CMK8GX4M2B3000C15. From time to time my PC makes 3 beeps and autorestarts upon powering on/manual restart.. probably it is because of this incompatibility, but the system runs with no problem except for this rare boot problem.

Can you please confirm that 'build failed' means segfault? (See picture below)
NOTEs: I actually built GMP, then NTL, then HElib, all of them while ryzen-test was running. After I started the NTL build ( I think) , the system became terribly unresponsive and hardly usable. It seemed to have come back to life after some of the ryzen-test processes failed, but then, even though all process had seemigly crashed, it went back to being almost unresponsive (I think all these lags were because the builds ate up all my RAM and the OS started to use swap space.. strangely enough, the RAM was not released after the processes failed apparently).
EDIT: the builds for those 3 libraries actually completed successfully... do you think it could have been them that lead to the failure of the ryzen-test processes? But even if they did, should that actually happen?

This is the picture of the result: https://imgur.com/a/vh25LH0
I also wanted to take a shot of the System Resources screen, but didn't have enough patience to stay through that terrible unresponsiveness anymore. In any case, what I last saw was that the RAM was like 7.7GB out of 7.8 consumed and the swap space was in use: ~700-800MB out of ~10GB (I set 10GB for this test.. because I read it needs around 16GB of RAM, but even that could be insufficient).

the script is has based on ubuntu? when i run it on arch linux ,it has to show some errors on terminal.

I only have 16GB of RAM. Will the test serve its purpose if I create a 16GB Ramdisk instead of 64GB? Or mount an empty partition and use the partition for the test?

When using daily Artful image, the test compilation fails due to a regular compilation error. Excuse me, I can't give the error message since I was using a live USB session. Maybe updating target GCC version (to 7.2) would help?