• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

AMD Confirms Linux Marginality Problem, Doesn't Affect Epyc or Threadripper

R

rgMekanic

[H]ard|News
2FA
Joined
May 13, 2013
Messages
6,942
AMD is now able to confirm they have reproduced the Ryzen "segmentation fault issue" and are working with affected customers. AMD characterize it as a performance marginality problem exclusive to certain workloads on Linux. The faults are found to occur with many, parallel compilation workloads in particular -- certainly not the workloads most Linux users will be firing off on a frequent basis unless intentionally running scripts like ryzen-test/kill-ryzen.

Good on AMD to have been working on this issue and to have found it. I know many Linux users will be happy to know it isn't found on Epyc or Threadipper.

Ryzen customers believe to be affected by the problem can contact AMD Customer Care. Some of those who have contacted customer care about the segmentation faults have in turn been affected by thermal, power, or other problems, but AMD says they are committed to working with those encountering this performance marginality issue under Linux. AMD will also be stepping up their Linux testing/QA for future consumer products.
 
Last edited:
Whew dodged that bullet. Thankfully any Epyc server I may play with won't have this problem.
 
So what do the Intel fanboys say now? AMD actually acknowledges the problem and promises to work with customers. Honestly I’m surprised too but AMD actually seems to really want to get back into the good graces with the PC community. If only their GPUs were better.
 
-Strelok- said:
So what do the Intel fanboys say now? AMD actually acknowledges the problem and promises to work with customers. Honestly I’m surprised too but AMD actually seems to really want to get back into the good graces with the PC community. If only their GPUs were better.
Click to expand...

Wait a minute... So AMD makes defective CPUs and the people praise them for their ignoring the problem for two months and then finally admitting it? LOL!
 
Ocellaris said:
Wait a minute... So AMD makes defective CPUs and the people praise them for their ignoring the problem for two months and then finally admitting it? LOL!
Click to expand...

Actually the work around on this was known a long time ago disabling ASLR.

Meanwhile more people spreading false information
from the reddit thread:
OldKirkBoyR7 1700 | Asrock K4 | 32GB @ 2933Mhz C14 | GTX980 56 points 1 day ago*

Looks like his EPYC server is doing good, on Ryzen - no.

Never had a problem on my ryzen chip, and I do some heavy parallel compiling/transpiling with make -j16 or ninja while messing with clojure. Yesterday because of the drama I tried ryzen_sigev_test on ubuntu and I got a few segfaults using gcc6.3.0 and kernel 4.10. Did the same test on Arch with gcc7.1.1 and kernel 4.12.4 no problem there. The tests done by phoronix are bogus. So saying ryzen has a problem is untrue or at least very very unlikely, most likely the problem is software related.
Click to expand...

So it is not in every Ryzen cpu. Which was also already known.

Meanwhile AMD allows people to RMA the chip if you contact customer care:
http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

Ryzen customers believe to be affected by the problem can contact AMD Customer Care. Some of those who have contacted customer care about the segmentation faults have in turn been affected by thermal, power, or other problems, but AMD says they are committed to working with those encountering this performance marginality issue under Linux. AMD will also be stepping up their Linux testing/QA for future consumer products.
Click to expand...
 
shitty phoronix reporting...
This is more direct: https://community.amd.com/message/2816382#comment-2816382#2816382
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.
Click to expand...
 
Again I'd like to thank Ryzen beta testers. I just hope thread ripper 2.0 will be much better.
 
Derangel said:
Talk about commenting before reading the article or even paying attention to what is being talked about.
Click to expand...

This is the second thread on the same issue https://hardforum.com/threads/ryzen...vy-compilation-loads.1941234/#post-1043149017

I know exactly what's going on. AMD's focus is on their thread ripper chips now and they are trying to kill any known bugs for TR, but are not actually fixing the problems. They are doing the same thing they did with the athlon XP-> MP and FX-> opteron. Using bugs found in the former before releasing the latter.
 
LBJM said:
This is the second thread on the same issue https://hardforum.com/threads/ryzen...vy-compilation-loads.1941234/#post-1043149017

I know exactly what's going on. AMD's focus is on their thread ripper chips now and they are trying to kill any known bugs for TR, but are not actually fixing the problems. They are doing the same thing they did with the athlon XP-> MP and FX-> opteron. Using bugs found in the former before releasing the latter.
Click to expand...

This bug does not effect Epyc or Threadripper. The faults Epyc was kicking back were due to a well known issue software, not hardware, problem. Threadripper releases in two days, there is no time to "use bugs found in the former". The bug on the consumer Ryzen chips seems more random and does not happen to everyone. If, as some people have speculated, it is an issue with early silicon it is something that will improve. New archs can have problems and growing pains. We've seen it from Intel as well. The results of the RMAs people have requested will be interesting to see.
 
Derangel said:
This bug does not effect Epyc or Threadripper. The faults Epyc was kicking back were due to a well known issue software, not hardware, problem. Threadripper releases in two days, there is no time to "use bugs found in the former". The bug on the consumer Ryzen chips seems more random and does not happen to everyone. If, as some people have speculated, it is an issue with early silicon it is something that will improve. New archs can have problems and growing pains. We've seen it from Intel as well. The results of the RMAs people have requested will be interesting to see.
Click to expand...

Nice way of giving AMD a pass. HT (kabe lake) issue already has a fix out.
Ryzen is the basis for Epyc and TR they were not developed in a vacuum. AMD has confirmed the problem meaning they can reproduce on Ryzen chips it's a bigger issue for those that compile software, the end user tends not to do this. The problem will manifest in the larger platforms if AMD has not fully fixed the issue.
 
LBJM said:
Nice way of giving AMD a pass. HT (kabe lake) issue already has a fix out.
Ryzen is the basis for Epyc and TR they were not developed in a vacuum. AMD has confirmed the problem meaning they can reproduce on Ryzen chips it's a bigger issue for those that compile software, the end user tends not to do this. The problem will manifest in the larger platforms if AMD has not fully fixed the issue.
Click to expand...

It's less of a pass and more of a "let's wait and see how the RMAs go and if it really is an early silicon problem". Since it doesn't happen to every chip, and does not seem to happen on Epyc and Threadripper, signs point to early silicon being a possible cause. We won't know if that is the case for a little bit, but we will get more of a picture in the next couple weeks when TR is released to the public.
 
Red Falcon said:
Considering 498 of the top 500 supercomputers in the world are running Linux, I would say this is kind of a big thing for AMD to take seriously.
Otherwise, bye bye enterprise market and all that...
Click to expand...
Super computers wouldn't be using Ryzen CPU. They would be using Xeons or Epyc CPU which don't have this issue.
 
vegeta535 said:
Super computers wouldn't be using Ryzen CPU. They would be using Xeons or Epyc CPU which don't have this issue.
Click to expand...
Its still a good wake up call regardless. Im sure it could influence their debugging procedures with their enterprise platform.
 
vegeta535 said:
Super computers wouldn't be using Ryzen CPU. They would be using Xeons or Epyc CPU which don't have this issue.
Click to expand...
It still shows that they have/had poor quality control on their mainstream CPUs, which in turn will reflect badly on the rest of their business, regardless of whether or not their other CPUs are affected by the bug or not.
 
This kind of makes it sound like AMD knew of this error long ago, and fixed it with a new stepping for Epic and Threadripper.

I hope they release a new stepping of Ryzen soon, it does seem to have many issues which don't seem fully fixable via AGESA updates.
 
LBJM said:
Nice way of giving AMD a pass. HT (kabe lake) issue already has a fix out.
Ryzen is the basis for Epyc and TR they were not developed in a vacuum. AMD has confirmed the problem meaning they can reproduce on Ryzen chips it's a bigger issue for those that compile software, the end user tends not to do this. The problem will manifest in the larger platforms if AMD has not fully fixed the issue.
Click to expand...
Noticed you didn't respond with real facts. The Intel issue went back to Q2 2016 so 1 year to fix. And considering their financials , it sure did take a while. And here you scoff at AMD who have only had a few months.
 
While your point is correct, it isn't necessarily relevant, as ryzen is the consumer grade. Threadripper is the HPC/Racked segment.

Red Falcon said:
Considering 498 of the top 500 supercomputers in the world are running Linux, I would say this is kind of a big thing for AMD to take seriously.
Otherwise, bye bye enterprise market and all that...
Click to expand...
 
It boggles my mind how emotional people get one way or the other over some obscure use-case bug that will get sorted out soon enough. Props to AMD to stepping up, admitting it and dealing with it.

Stop being fanboys, one way or the other.
 
BloodyIron said:
While your point is correct, it isn't necessarily relevant, as ryzen is the consumer grade. Threadripper is the HPC/Racked segment.
Click to expand...
I understand that, and you are right, it's just that since one product line had poor quality control, it doesn't really bode well for other product lines from that company.
That's all I was really getting at. :)
 
Red Falcon said:
I understand that, and you are right, it's just that since one product line had poor quality control, it doesn't really bode well for other product lines from that company.
That's all I was really getting at. :)
Click to expand...

How do you know its a QC issue??
 
thesmokingman said:
lol, you still don't get it.
Click to expand...
It's a segmentation fault.

"AMD hasn't yet found the root cause of this issue, but given the spread of users affected, appears to be related to the processor itself."

Beyond that, care to explain?
 
Red Falcon said:
If it's not a "quality control issue", then what would you classify this as?
I'm legitimately asking.
Click to expand...

You sure u not trolling?

Cpu bugs are a fact of life. Cpus are made and designed by humans thus are prone to faults, flaws, what have you. Humans try to keep the faults to a minimum but sometimes a bug will never be discovered until it is found in the wild. Calling these issues a QC issue is really misunderstanding how this all works.
 
thesmokingman said:
You sure u not trolling?

Cpu bugs are a fact of life. Cpus are made and designed by humans thus are prone to faults, flaws, what have you. Humans try to keep the faults to a minimum but sometimes a bug will never be discovered until it is found in the wild. Calling these issues a QC issue is really misunderstanding how this all works.
Click to expand...
I understand CPU bugs have been around for since the 1970s and humans aren't perfect.
However, for such a big release, and considering the amount of testing and money put into this release, some might consider that to be a "quality control issue" of R&D, and by extension, quite the oversight from AMD, especially from a business and market standpoint.

No, I'm not trolling, I'm legitimately asking you to explain so I can understand where you are coming from, mainly since you are specifically saying it's not a quality control issue.
 
Red Falcon said:
I understand CPU bugs have been around for since the 1970s and humans aren't perfect.
However, for such a big release, and considering the amount of testing and money put into this release, some might consider that to be a "quality control issue" of R&D, and by extension, quite the oversight from AMD, especially from a business and market standpoint.

No, I'm not trolling, I'm legitimately asking you to explain so I can understand where you are coming from, mainly since you are specifically saying it's not a quality control issue.
Click to expand...

Now you're just going around in circles. As I suspected...
 
thesmokingman said:
Now you're just going around in circles. As I suspected...
Click to expand...

All of your responses to him are basically " Nu-uh. You're wrong. I'm not going to tell you why but your wrong". He's "going around in circles" because you refuse to actually answer his simple question.
 
Derangel said:
All of your responses to him are basically " Nu-uh. You're wrong. I'm not going to tell you why but your wrong". He's "going around in circles" because you refuse to actually answer his simple question.
Click to expand...

Seriously? Bugs... are bugs and often times they are not known until its too late. Equating that to QC is redonkulous. If we equate cpu bugs to QC issues, then where does that leave Intel and the rest of the industry? No one should release anything until its proven perfect? Bugs happen, just like shit happens. They will do what they can to fix or work around the issue just like Intel does. And the reason he's spinning circles is because he is choosing to ignore the fact that bugs happen, regardless of QC.
 
You must log in or register to reply here.
Back
Top