What's your hardware configuration? Are you running the latest BIOS?
My machine was constantly freezing and I was very unhappy with my purchase. Now it's running perfectly. All I had to change was the "Typical Current Idle" setting in BIOS.
Asus A320m-k + Ryzen 5-1600x Have updated the BIOS to latest available and changed to "typical" profile as recommended. I still have ACPI issues especially when rebooting or waking machine. Either the fix doesn't work for everyone or Asus has been writing poor firmware code as of recent.
Well that is not that easy as you may think it is.
You should really think about the situation for the most board venrods right now.
They do *NOT* support Linux .. meaning the BIOS is written for Windows , the defaults
are meant for Windows , whatever custom interfaces are meant for Windows.
But that is NOT AMD .. is your board vendor decides what go in into the BIOS and how,
also what the defaults are and they decides what firmware they use.
The RYZEN/TR AMD platform is still new and so like for every new platform
OS integrators and developers need some time to implement features and drivers
in all OS'es. And like always we need be patient.
When I bought my Ryzen 7 1800X in mid March 2017, it was brand new.
In mid Nov 2017 I finally lost patience, and bought an i7-8700K, which was also at the time brand new. Having transferred everything that really mattered to me to the new machine, I RMA'd the Ryzen 7.
Both machines run a current Fedora and have ASUS motherboards. There are no prizes for guessing which one has worked reliably from day one.
It is no doubt true that each board vendor is responsible for their BIOS. However, whatever they support is limited by the support they get from the CPU vendor. The "Typical Current Idle" option is a feature of the AGESA (see AGESA - Wikipedia) software component, provided by AMD. The various board vendors have updated their BIOSes at different times. As far as I can see, the first Ryzen 7 CPUs were almost a year old at the time AMD released the version of AGESA with the "Typical Current Idle" option.
From a Linux perspective, it seems a shame that the "Typical Current Idle" seems not to be the default BIOS setting. You may well be correct that this is because Windows has some other way of avoiding whatever the underlying problem is, so the default is fine for Windows.
It seems to me that for Linux the "Typical Current Idle" option is required if you wish to avoid the "freeze when idle" problem. It's not obvious though, is it ?
I cannot find anything which tells me what the "Typical Current Idle" option actually does, or whether the Linux Kernel could implement same independently.
If you buy a Ryzen 7 today to run Linux, you are in for a surprise the first time you get a "freeze when idle". Sadly, the freeze looks a lot like a hardware issue, so you may waste your time fiddling with memory etc. (particularly if you are overclocking !) Eventually, you may stumble across this or other threads and discover the "Typical Current Idle" option. You may first stumble across other, earlier speculation and suggested work-arounds, which don't work. <sigh>
Who knows whether the more recent AMD CPUs do or do not suffer from similar problems ?
In response to a support ticket, AMD said first (a) that they recommend a PSU which supports 0A draw at 12V, and later (b) that I should try the "Typical Current Idle" option (when my motherboard supported it). I did upgrade to a more modern and more efficient PSU, which the manufacturer was happy to confirm supported 0A draw on all voltage rails. The new PSU was an improvement, but had no discernible effect on the "freeze when idle" problem.
Otherwise, AMD, the motherboard vendors and the Linux maintainers all remain silent on the topic -- correct me if I am wrong here. The "freeze when idle" problem is irritating. The silence is infuriating.
But, as you say, patience is a virtue. The next time I think of buying a brand new AMD CPU, I will remember that I ought to wait some time before expecting it to be usable. For the Ryzen 7 it seems I should have waited a little over a year. Once bitten, twice shy they say, so next time perhaps I should wait two years or so. Or longer. Maybe much longer.
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..
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
Perhaps the result of a golden sample.
But you are right, we have no insight in the statistics.
Are the problems mostly in the first Ryzen serie, or are they also present with the 2600/2700?
And is the Typical Current Idle the solution or not, is it good implemented on the earlier motherboards, or does it only work well in the latest serie (450/470) ?
Still hoping that the problem has disapeared with the latest hardware.
But we do not know the statistics, how many 2600/2700 owners are using Linux and how many of them have the problem .
I think AMD has some of the answers, but they are complete silent, and that worries me.
It does not just seem like a hardware problem.
I am using gentoo on AMD Ryzen 5 1600 Six-Core Processor. So I can play with kernels without being dependent on distrubutions.
The strange thing is: There are linux kernels that work without CMD-Line commands and without "Typical Current Idle".
For example 4.17.14 works wonderfully. Or from the git-sources 4.19_rc2. Really good. Without parameters, with default bios setting. Nice.
Other kernels are awful. 4.18.x can only be used with bios settings or CMD line options.
But in 4.18 the entire power management was redone. Take a look at "Linux Weather Forecast".
At the moment 4.18.7 is marked as stable. I am testing today and have no results yet.
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
Here is a recent discussion between Jon Bach from Puget Systems(stability oriented system builder) & Wendell (Linux guy) from Level1Techs.
They talk a bit about stability & the wobbling progress in CPU power management, in general, in 2018.
I've had the same problem described here with a Ryzen 5 1600 on an Asrock X470 Gaming K4 mainboard, microcode update 800F11/8001137. The system stopped while idle every one or two days. I set the "power supply idle control" to "typical current idle" 20 days ago and no hang since. So, this fixed it.
What I cannot confirm is that some Linux kernels work better than others. I've tried all kernels that came with Debian/testing from 4.14 to 4.18.6 and they all hung.