Continuing To Stress Ryzen

[phoronix]

Phoronix: 50+ Segmentation Faults Per Hour: Continuing To Stress Ryzen

In direct continuation of yesterday's article about easily causing segmentation faults on AMD Zen CPUs, I have carried out another battery of tests for 24 hours and have more information to report today on the ability to trivially cause segmentation faults and in some cases system lock-ups with Ryzen CPUs.

http://www.phoronix.com/vr.php?view=25016

[qsmcomp]

Upgrading BIOS to newest beta and you might find a "opcache" option. Disable it and have a retry.

[kenjo]

So why not load the core file into gdb and find out what is actually executing when the segmentation fault happens ?

[Darksurf]

Man, this sucks. I've got an AM4 system half built just awaiting GPU and CPU. I sure hope they find a solution to the problem.

[cybernard]

I know Ryzen had the pink screen of death on vmware esxi, and the temporary fix is to disable SMP in the BIOS. Does have any effect on the situation?

[Michael]

I know Ryzen had the pink screen of death on vmware esxi, and the temporary fix is to disable SMP in the BIOS. Does have any effect on the situation?

As already covered, disabling SMT doesn't help the situation.

[duby229]

I love the ending. How many can you get? It seems like it should be so wrong, but it's not.

[puleglot]

AFAIK conftest segfaults are pretty normal. You probably should count only segfaults of bash, gcc itself, etc..

[Hadrian]

Very informative article, as usual.
Thank you for your good work, Michael! Much appreciated.

[pjssilva]

I am rebooting my machine now to run the test under Antergos. I have a theory that once the bug is reached you have to let the machine "cool down" before trying again otherwise the bug will just come too often. It is like the CPU enters into a bad state or something. I'll try to reproduce that in a consistent manner during the weekend and report back.