AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR

[sdack]

No it isn't. Linux is a kernel and WSL shows the same bug while running the windows kernel. You might be able to say that it's bug in the userspace, but that hasn't been shown yet. You say that it hasn't been demonstrated on Windows, but you forgot to use the word "yet" The only one delusional here is you. At every point you misunderstood the facts.

Yes, it's working. You're just being an idiot. You may as well stand on the street and proclaim the world will end in a year. Who can argue with you? Only another idiot could. You're simply too stupid to accept that when it's working it's also not faulty.

And yes, Linux is a kernel and not just any piece of software. It's the main job of a kernel to make the hardware work and not vice versa. To claim it to be the other way around shows that you lack the most basic understanding of what an Operating System (OS) is.

[duby229]

Yes, it's working. You're just being an idiot. You may as well stand on the street and proclaim the world will end in a year. Who can argue with you? Only another idiot could. You're simply too stupid to accept that when it's working it's also not faulty.

And yes, Linux is a kernel and not just any piece of software. It's the main job of a kernel to make the hardware work and not vice versa. To claim it to be the other way around shows that you lack the most basic understanding of what an Operating System (OS) is.

Fine then, but don't be a hypocrite. It also shows the same exact bug on WSL, which runs the -Windows Kernel- Not Linux. If it's a linux bug then tell me how do you explain WSL?

Let's be realistic here, if WSL shows the bug, then in -FACT- the windows kernel is affected by it too. That alone is proof that it's a hardware bug.

[pjssilva]

It's unfortunate that there's no way to track Ryzen CPU temps in Linux at the moment (unless somebody knows otherwise?) because I have a feeling I'm hitting the thermal limit of about 85 C and that's why my system just shuts down.

It depends on your motherboard. Mine is a MSI B350 Tomahawk, you can get the temperatures if you do

sudo modprobe nct6775 force_id=0xd120

After that just use sensors as usul. The CPU temperature is in SMBUSMASTER (with a 20 C offset). Mine is now showing 74.5 C (that minus 20 is 54.5 C) when running kill-ryzen.sh. I am testing the new BIOS option that allows me to turn off OpCache (it seems to improve matters a lot for me, even better than turning off SMT).

To make sure that your system is really free of the bug you should run kill-ryzen.sh for at least 48 hours or one or two days more. But I confess that my system always should the bug in at most 4 hours.

Good luck!

Obs: Don't feed the troll, let him rot in his dark cave! :-)

[sdack]

Fine then, but don't be a hypocrite. It also shows the same exact bug on WSL, which runs the -Windows Kernel- Not Linux. If it's a linux bug then tell me how do you explain WSL?

Let's be realistic here, if WSL shows the bug, then in -FACT- the windows kernel is affected by it too. That alone is proof that it's a hardware bug.

*lol* I'm no hypocrite, but you're a fear-mongerer. First you want AMD to confirm your worst fears, and when it's not happening, but they rather tell you it doesn't affect Windows and it's only a rare case found only under Linux, which we knew all along, do you choose not to believe AMD, but want to hold on to your fears. Very smooth of you ... *lol*

If I'm the one sitting in a cave then it sure isn't as dark as yours.

[scorpio810]

When I saw the very very long time needed to compil the same software in a Windows environment ....I prefer cross-compiling my Windows packages directly on my Debian ...
I build also the same software in a macOS VM and it take the same time +1% than Debian compil ...

I understand why this problem not affect Windows, uhuhu

[chithanh]

sdack duby229
The problem happens on Linux and can be reliably triggered on broken CPUs by compiling software. For Gentoo users, the problem is very common, not rare. (You might argue that Gentoo users are rare, and you might have a point there, but generally distros compiled from source are more common that you might think.)
The problem also happens on BSD. We had Matt Dillon's report in the original Phoronix thread.
And the problem happens on Windows Subsystem for Linux, which does not share any code with Linux.

Fear-mongering or not, what duby229 said is 100% factually correct, and AMD's claim that the problem is "exclusive to certain workloads on Linux" is partially false because it is not exclusive to Linux.

[duby229]

*lol* I'm no hypocrite, but you're a fear-mongerer. First you want AMD to confirm your worst fears, and when it's not happening, but they rather tell you it doesn't affect Windows and it's only a rare case found only under Linux, which we knew all along, do you choose not to believe AMD, but want to hold on to your fears. Very smooth of you ... *lol*

If I'm the one sitting in a cave then it sure isn't as dark as yours.

Ok, and again that fine as well, but again don't be a hypocrite. We all know for an absolute fact that Linux is a kernel and WSL does not use the linux kernel. It's plainly obvious. Even for AMD and the fact that their marketing department/tech support guys misunderstood it is very telling all by itself. Hell, they knew about it for a fact since at least April, and honestly I'd be willing to bet they knew about since tape out. What you saw was obviously the fact that AMD doesn't even communicate with itself even internally. That's something I've been bitching about AMD for years. We already knew that for a long time.

[rstrube]

It depends on your motherboard. Mine is a MSI B350 Tomahawk, you can get the temperatures if you do

sudo modprobe nct6775 force_id=0xd120

After that just use sensors as usul. The CPU temperature is in SMBUSMASTER (with a 20 C offset). Mine is now showing 74.5 C (that minus 20 is 54.5 C) when running kill-ryzen.sh. I am testing the new BIOS option that allows me to turn off OpCache (it seems to improve matters a lot for me, even better than turning off SMT).

To make sure that your system is really free of the bug you should run kill-ryzen.sh for at least 48 hours or one or two days more. But I confess that my system always should the bug in at most 4 hours.

Good luck!

Obs: Don't feed the troll, let him rot in his dark cave! :-)

Hey thanks for the info! I happen to have the *exact* same motherboard so your advice was extremely helpful. I was able to make the module load permanent by following the instructions here: https://linuxconfig.org/monitor-amd-...kernel-modules

For reference I am running Fedora 26 with kernel 4.11. This kernel appears to have the nct6775 module built.

Interestingly enough at idle my SMBUSMASTER sensor is at 33 C, which means my idle temp is only 13 C? This seems pretty low. I'll going to stress the system again and see what it goes up to. I did wake up this morning to some application crashes from the stress test: fixdep, conftest, and make. The main terminal window in which I ran the stress test did not show any errors though, I only noticed in by going into the Fedora Problem Reporting application.

Does anyone know how is one able to get the detailed output that Michael shows in his screenshots?

Thanks!

[sdack]

sdack duby229
The problem happens on Linux and can be reliably triggered on broken CPUs by compiling software. For Gentoo users, the problem is very common, not rare. (You might argue that Gentoo users are rare, and you might have a point there, but generally distros compiled from source are more common that you might think.)
The problem also happens on BSD. We had Matt Dillon's report in the original Phoronix thread.
And the problem happens on Windows Subsystem for Linux, which does not share any code with Linux.

Fear-mongering or not, what duby229 said is 100% factually correct, and AMD's claim that the problem is "exclusive to certain workloads on Linux" is partially false because it is not exclusive to Linux.

*lol* If this forum was any kind of representation of the Linux community then Linux users would all be a bunch of whining, hardware-blaming and confirmation-seeking users. You'd have to ask yourself how Linux managed to become the best OS with this kind of attitude. So, yes, I'm aware of the situation... It's like you've turned into Windows users.

If it requires WSL to trigger the bug under Windows and cannot be triggered otherwise then it's proof of the fact that it is a Linux-specific workload and not the other way around. Or you might say it's a bug with our planet, because it happens here on Earth.

The amount of hurdles Linux had, and still has, to take to run on the wide variety of hardware it does today makes this into a non-issue and turns you into the worst Linux users ever.

[duby229]

*lol* If this forum was any kind of representation of the Linux community then Linux users would all be a bunch of whining, hardware-blaming and confirmation-seeking users. You'd have to ask yourself how Linux managed to become the best OS with this kind of attitude. So, yes, I'm aware of the situation... It's like you've turned into Windows users.

If it requires WSL to trigger the bug under Windows and cannot be triggered otherwise then it's proof of the fact that it is a Linux-specific workload and not the other way around. Or you might say it's a bug with our planet, because it happens here on Earth.

The amount of hurdles Linux had, and still has, to take to run on the wide variety of hardware it does today makes this into a non-issue and turns you into the worst Linux users ever.

WSL uses the windows kerenl, not linux at all. It proves the windows kernel is susceptible to this bug. Whether or not a windows userspace app has been found that exhibits it yet is irrelevant because WSL proved it.