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

[chithanh]

If it requires WSL to trigger the bug under Windows

Who claims that it requires WSL to trigger the problem? Instead, if the problem is not Linux specific, then WSL would give us a straightforward way to trigger the problem on Windows. Hence, it was tried and (again) confirmed that this problem is happening independently from the Linux kernel. In other words, either not a Linux bug or a bug which is shared between Windows, Linux, and various BSD kernels.

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.

So "Linux-specific workload" is where the goalposts are standing now?
In that case, you may want to move them further: The first public analysis from someone who encountered the bug came from DragonFlyBSD developer Matt Dillon, not from some Linux developer.

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.

This sentence fails to make sense. Neither the premise is true nor your conclusions follow from the premise.

[littleowl]

No. The system is stable with Windows. But according to you fanboys is it a fault with the hardware and not with Linux.

The fact it is easier to demonstrate it in Linux doesn't mean that there is no issue in Windows. Linux and gcc don't use anything what is not expected from X86_64 architecture according AMD's specification, so it is a HW bug. The HW bugs in the current Intel/AMD processors are not unusual, but unless AMD tells us what is the workaround, there is no way how the Linux developers can reliably fix this.

[sdack]

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.

It's not just Linux or Windows, it's worse. It's our planet and it will shortly explode.

Sorry if I fail to take you seriously.

If you'd put as much effort into fixing the kernel as you're putting into the attempt to of blaming AMD then you might already have a fix. Guess you're just not smart enough for that.

[duby229]

It's not just Linux or Windows, it's worse. It's our planet and it will shortly explode.

Sorry if I fail to take you seriously.

If you'd put as much effort into fixing the kernel as you're putting into the attempt to of blaming AMD then you might already have a fix. Guess you're just not smart enough for that.

Hope your steak tastes good. I suppose ignorance really is bliss huh?

EDIT: I'll admit that I'm an AMD fanboy and I've gone through all the phases that fanboys go through. And for quite a while now I've been at the phase where when AMD deserves blame that's what they're gonna get.

[ermo]

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!

Just a quick question: I was under the impression that sensors3 allows you to modify the formula you use to convert sensor values to temperature?

In this case, it sounds like all that is needed is for the conscientious user to look at the code in question and replace the formula with '<original formula> - 20' to get the correct temperature to show up in the 'sensors' output?

I can't say for certain (and I haven't looked into it in detail), but I would assume that the temp is measured by applying a known voltage to a temperature sensitive resistor and then measuring the voltage drop over the sensor and calculating the temp using a known formula that relates to the specification of the resistor used?

[pjssilva]

Just a quick question: I was under the impression that sensors3 allows you to modify the formula you use to convert sensor values to temperature?

In this case, it sounds like all that is needed is for the conscientious user to look at the code in question and replace the formula with '<original formula> - 20' to get the correct temperature to show up in the 'sensors' output?

I can't say for certain (and I haven't looked into it in detail), but I would assume that the temp is measured by applying a known voltage to a temperature sensitive resistor and then measuring the voltage drop over the sensor and calculating the temp using a known formula that relates to the specification of the resistor used?

Actually you can do this kind of stuff by suing a configuration file in /etc/sensors ou /etc/sensors.d but I do not remember the details. In this case the formula is no easy that I do it in my head. Note that the -20 C is only necessary for the X processors, like 1700X and 1800X. For a regular processor, like 1700, the temperature will be already correct. I forgot to mention that. Sorry.

[kaseki]

For an example of trying to make 'sensors' work with super I/O chips that are not documented (such as the 8665 used on Asus C6H) see https://github.com/groeck/it87

[shmerl]

Just for the reference, Asrock X370 Taichi works very well with sensors out of the box.

[sdack]

Hope your steak tastes good. I suppose ignorance really is bliss huh?

EDIT: I'll admit that I'm an AMD fanboy and I've gone through all the phases that fanboys go through. And for quite a while now I've been at the phase where when AMD deserves blame that's what they're gonna get.

Oh, neat, a Matrix analogy. *lol* I hope you realize you're Agent Smith in all of this.

I however can remember the days where I was running my first Linux, version 0.99 on a 486. The hardware issues were everywhere, and yet it felt great. No tears, no fears, only challenges. It's still the same today. Not a day goes by where I don't love Linux. I'm free of any hate for hardware makers, because this is how it's always been. So I wonder what's wrong with you. Where does your attitude come from? It sure isn't typical for Linux users.

[ermo]

Actually you can do this kind of stuff by suing a configuration file in /etc/sensors ou /etc/sensors.d but I do not remember the details. In this case the formula is no easy that I do it in my head. Note that the -20 C is only necessary for the X processors, like 1700X and 1800X. For a regular processor, like 1700, the temperature will be already correct. I forgot to mention that. Sorry.

The part about the configuration file was what I meant. But I don't know if the formula is visible in the configuration file by default or if you need to look up the C code for the chip in question to see the original formula, which you can then adapt in the sensors configuration file.