Continuing To Stress Ryzen

[chithanh]

Where can I find these official links?
I couldn't find it neither on their websites nor in the manuals. At least for the ASRock Fatal1ty X370 Gaming K4. The manual of BIOSTAR X370GT7 Ver. 5.x (don't like the BIOSTAR as it doesn't have intel LAN) states "supports non-ECC 4/ 8/ 16 GB DDR4 module".

About ASRock, I asked in their official forums for the AB350M.

http://forum.asrock.com/forum_posts.asp?TID=4484&PID=24361&title=ecc-memory-on-ab350m#24361

Biostar I read from their mobo specs. Will have to look up.

[Michael]

Got off the phone with AMD a few minutes ago. They are able to confirm problem in the very heavily compilation workloads and will be working with affected users. More info in article shortly.

[RyzenNewbie]

Over time it seems that more "safe area" is required - presumably because each new CPU generation pre-fetches further ahead than the last one. In a sense Linux (and Windows I believe) got lucky by reserving a full guard page while BSD allocated a smaller guard area. As a result BSD has had to bump the guard area (to a full page) while other OSes did not.

thank you for the detailed explaination - appreciate it, seriously. I'll forward that to the FreeBSD devs as well. If that's all true it would haven very nice and kind to have been told earlier...

[RyzenNewbie]

Got off the phone with AMD a few minutes ago. They are able to confirm problem in the very heavily compilation workloads and will be working with affected users. More info in article shortly.

thank you, Michael; at least, there's some real progress going on now; and I think that all the hassle - even with my two buddies - could be worth it because that's more advancement than in the last four months...

[drSeehas]

About ASRock, I asked in their official forums for the AB350M.
http://forum.asrock.com/forum_posts....n-ab350m#24361 ...

???
"support DDR4 2667/2400/2133 ECC & non-ECC, un-buffered memory"
This means absolutely nothing!
Each ECC module is supported by every mainboard. But only in non-ECC mode.
I want an officially working ECC mode!

[kaseki]

I have spent a lot of time reading the forum at AMD: https://community.amd.com/thread/215...t=420&tstart=0. [This link may be to the thread point where I am so far.] There seem to be a few ameliorations that have been discovered, but they are not satisfactory for most in the long run. As my Ryzen PC is aimed at home theater, I am not likely to be affected very often by the segfault, but adopting Ryzen for other purposes would certainly bring this issue to the foreground.

Some "fixes" that have been noted include:

• turning off the RAM randomizing function via sudo echo 0 > /proc/sys/kernel/randomize_va_space (I haven't tested this yet, normally the value there should be 2.)
• disabling opcache (In the C6H, this is apparently in Advanced>AMD/CBS>Zen....>Opcache control
• disabling SMT (and making your CPU 8 cores and 8 threads)
• RMA the CPU (just another spin of the silicon lottery faro wheel)

Of specific interest to me is the discovery that along with kill-ryzen, there is a script called save-ryzen in the same package. Save-ryzen has the property of keeping the computational threads from wandering among the core threads. This was intended to potentially minimize the segfault problem or at least narrow the range of causes; however, I am running it now and there are 2 segfaults at start. This mode of compilation does make Mint's System Monitor's cpu utilization plot a lot less busy. I'll run it for a while to see if the total fault count is lower than for kill-ryzen.

It seems that if one has to do a heavy compilation under Linux and has a segfault problem keeping it from completing, then disabling SMT and taking a hit on speed is the best technique at present.

[Michael]

thank you, Michael; at least, there's some real progress going on now; and I think that all the hassle - even with my two buddies - could be worth it because that's more advancement than in the last four months...

They sound pretty committed now to getting the issue under control. (It may have been that the upper management wasn't aware of the Linux issues until splashing attention onto it in recent days.)

[shmerl]

Got off the phone with AMD a few minutes ago. They are able to confirm problem in the very heavily compilation workloads and will be working with affected users. More info in article shortly.

That is something already. Thanks for pinging them!

[scorpio810]

Hello. As a software guy, I compile a lot of code, and occasionally gcc crashes with a segmentation fault for no obvious reason. I seem to remember that

Same here, this machine is the nighlty packages builder ( Debian, Ubuntu, Windows, macOS) bought with user donations for a electrical opensource software, I dream of a new AGESA or firmware fix, without do RMA this CPU and try my luck again to a new silicon lotery. ;-)
https://qelectrotech.org/forum/viewt...pid=6405#p6405

[scorpio810]

https://community.amd.com/message/2816382#comment-2816382

amdmatt  7 août 2017 13:35 (en réponse à ahartmetz)
We have been working closely with a small but important subset of Linux users that have experienced segment faults when running heavy or looping compilations on their Ryzen CPU-based systems. The results of our testing and analysis indicate that segment faults can be caused by memory allocation, system configurations, thermal environments, and system marginality when running looping or heavy Linux compile workloads. The marginality is stimulated with very heavy workloads and when the system environment is not ideal. AMD is working with individual users to diagnose the issues.

We are confident that we can help each of you identify the source of the marginality and eliminate the segment faults. We encourage all of our Linux users who are experiencing segment faults under compile workloads to continue working with AMD Customer Care. We are committed to solving this issue for all of you.