imshalla, appreciate the well articulated post 
The silence around this issue is quite strange!
I used to wonder..that if AMD lets the cat out of the bag, then it could be subjected to do a massive recall. just like what it did for the "Performance marginality problem".
Then, why does it not show up so evidently on Windows ?.. Perhaps they worked with Microsoft & issued a patch, that is either proper or they made the windows kernel put a little load on the CPU, but then reported zero load to the kernel apis that ...say the Task Manager would invoke.or it could be such that the way windows works with Ryzen , would not push the CPU to this lock-up situation..
Still, all of these thoughts are just guesses.
Sometimes, I used to wonder if we ( just a handful), are the only ones who are facing this problem.
I am also so surprised to see that Micheal Larabel of Phoronix, who plays around 24/7 with Linux has not seemed to have faced this issue. (Note, that AFAIK, he was one of the few who popularized the performance marginality problem, which the eventually elicited a response from AMD)
Also wondering why we don't see any Thread Ripper or EPYC owners commenting about it here..
Yeah, the diversity of Linux distro's and having almost always a different kernel versions is not really helping in this case.
Problems and solutions are given for X (hardware), Y (used distro) which have a different Z (kernel).
And Z has usual specific compile options for Y, but also could or should have options for X.
Difficult to manage when something is not working with new X.
For sure when you are not a kernel specialist.
One thing is sure, it does not always work out of the box.
And I'm still thinking that AMD must take the leading light and guide us out of the misery 
I found this
& this
cpupower-monitor - Report processor frequency and idle statistics - Linux Man Pages (1)
And I highly believe that from
/sys/devices/system/cpu/cpu*/cpuidle/state*/
Some kind of monitoring is possible using information from there, and some how can write a script to reset the sleeping CPUs back to live? I don't know how to do this yet. But can members from this forum workout something and share pse? 
All,
Decided to chime in on this as this appears to be one of the longest running and most focused threads on this issue and maybe?? seen by AMD should really respond to this.
First some insight we deployed 15 AMD Ryzen systems in 2017 using various Kernels and they all ran idling some of the time and with vastly varying loads most of the time without any stability issues. What was common though with all 15 is since they needed every bit of performance so we modestly (about 200Mhz) over clocked them and I think most importantly after seeing a few lockups at 1.35V set the CPU voltage to 1.40V. So this had a very good track record (year+ now over many systems). I also did disable "Cool and Quiet" as it has a history of problems with Linux going back pre Ryzen. Besides those changes no other BIOS changes or Kernel paramaters. All these machines were Ryzen 1800, 1800X, or 1600. Most had no graphics running text mode only.
Move ahead to this year and due to updates to our software we no longer needed to overclock and figured this would save power and generate less heat (very important for 1 of the installs). These systems run processes that vary in load a lot all the way from idle (rarely) to it running full out. All 6 machines that we have delivered in this config have locked up infrequently, no log messages, no ping, needed reset/power cycle to recover and one of the systems has locked and does lock up frequently (every few days) even though we swapped the motherboard and CPU. I have not tried the fix that many here seems to solve (the Power Supply Idle Current). Some of these were 2700 Ryzen.
Much of what we are experiencing harkens back to the early Haswell days. It is my understanding although poorly documented by AMD 
that the Ryzen/TR/Epyc chips utilize a third level of voltage regulation on a substrate above the die that allows the chip (independent of C or P states) to set the voltage that each core sees. This is similar to what Haswell did and that Intel moved away from after Haswell (mostly due to heat problems on die). So for the CPU to see the right voltage it takes 12V from system power supply, regulates this down to the PState CPU voltage (typically 1.35 to 0.9V) and then can further regulate this down to whatever (some say as low as 0.6V). This is all fine but the problem that it creates is when you go from idle or near idle to near full the regulators must respond very quickly and if this dance does not happen right the CPU is voltage starved and hard locks. Doing this dance was an issue for Intel with Haswell and supposedly through both microcode and BIOS changes they eventually got it right.
I think AMD has to learn how to dance correctly!
I have some evidence of this where I connected a Scope to 12V rail of a EVGA 750W supply and at times the voltage would quickly drop to as little as 10V (2V drop) if I started a process instantly ramped up 16 full out threads. While with an intel CPU (4 core) going from idle to Max quickly resulted in less than a 0.5V drop and over a bit more time.
Going back to overclocking in this case from what I have read overclocking disables the internal per core VRM's on Ryzen leaving just the standard MOBO VRM it also sets this VRM to whatever you tell it as the only P-State. I also made the VRM voltage the Max at 1.40V. As a result static power ifs high (hot even when doing nothing) but as I noted above system seems stable regardless of load. Essentially it simplifies the dance making a Tango into a simple walk across the floor.
This BIOS option noted in this thread may indeed do much more than limit C States not sure and not sure how this helps the situation of going vastly varying CPU loads causing the hard lock which is I believe similar to the idle problem.
Plan to experiment more after the holidays and report what I find here.
