Continuing To Stress Ryzen

[sdack]

...
Shall I make this all about now?


Perhaps sdack should make a selfie, with him being on his knees and installing FreeBSD, applying a little kernel patch, running that program, running a poudriere build, struggling over strange system behaviours, make screenshots as well as log files, and send it to AMD ... just in case


you haven't read that much about the background of this thread, have you?

And yet do you only keep looking at Ryzen when you should be looking at Intel, too, and figure out why it crashes there, too. Yet you act like any scared bitch and get hysterical about Ryzen. You even call yourself RyzenNewbie to underline your cluelessness. Why do you get upset there when you know you're a newbie, I wonder?

It's of course normal for two different CPUs to show slight differences in the way the bug exposes itself. It wouldn't surprise you if it there was a difference between a Ryzen 5 and Ryzen 7, or only with different speeds, would it now? So why do you keep ranting and making this all about Ryzen when de facto you don't have a clue, RyzenNewbie? Or let me guess, you're still trying to figure that one out, too. *lol*

[bridgman]

Normal? Why? Can you explain that? How to avoid them?

https://www.redhat.com/archives/libv.../msg00930.html

Generally, this is not an issue. Autoconf tests INTENTIONALLY try to probe for broken systems, in order to work around brokenness, so a segfaulting conftest during ./configure just says that things are probing as expected.

[sdack]

ok I will not back to AMD after this.

And that's the real damage here. People getting hysterical and making this about Ryzen while they know it happens with some Intel CPUs, too. One might as well keep buying AMD and not go back to reading Phoronix.

[timofonic]

I really hate that bug and it's super annoying when it happens. If you happen to sit by the computer while it happens you're usually able to move the cursor around, but that's about the only thing you can do except doing a hard reboot. The sad part is I've seen something similar happen on an old Intel system where it started with Firefox suddenly going to 100% activity and the process was completely unstoppable (zombie process). After a while, the system got really unstable and then it became completely unresponsive. It never happened with the LTS of Ubuntu which the system was recently updated from.

Thinking about it the Ryzen bug could be affected by binaries being compiled with the pie option now and that could be why it's so hard to pinpoint. Disabling ASLR might not be enough.

That crap happens on my Intel [email protected] laptop (MSI GE62-2QD Apache Pro). I would like to know why that happens and how to avoid it. Do you have any advice? What should I do? Can someone do debugging to see if there's some bug on the hardware or whatever?

I'm using Archlinux right now. I update it frequently. If you need more info, request it and we could open a new forum thread about this. I see there are other people that had that similar problem.

I use the stock Archlinux kernel. I had no idea about what "config_rcu_nocb_cpu_all" was....

bridgman Thanks for the info about these segfaults

[V10lator]

And yet do you only keep looking at Ryzen when you should be looking at Intel, too, and figure out why it crashes there, too. Yet you act like any scared bitch and get hysterical about Ryzen. You even call yourself RyzenNewbie to underline your cluelessness. Why do you get upset there when you know you're a newbie, I wonder?

Why are you continously ignoring that RyzenNewbie did test on Intel but it failed on AMD only? And he wasn't the only one noticing this, the FreeBSD team speaks about it loud and clear: https://svnweb.freebsd.org/base?view...evision=321899 - And when we're at it, FreeBSD links to a DragonlfyBSD bug also pointing out that the problems are on Ryzen only: https://gitweb.dragonflybsd.org/drag...d301557fd9ac20

//EDIT: Also RyzenNewbie pointed out multiple times that you should try the FreeBSD bug for yourself on AMD and Intel CPUs but instead of doing so you keep telling he should do it while ignoring that he and multiple FreeBSD developers already did that.

[chithanh]

And that's the real damage here. People getting hysterical and making this about Ryzen while they know it happens with some Intel CPUs, too. One might as well keep buying AMD and not go back to reading Phoronix.

And that this damage happens is totally AMD's fault. I told them in the community forum thread that AMD urgently needs to lead this discussion. But AMD chose not to make public statements but instead to remain silent for months. Now reports are spiralling out of control and are confusing users. Someone wrote that they asked Kyle from HardOCP to run the Ryzen stress test on his Threadripper review samples. Is Kyle informed about the conftest problem? If not, shit's gonna hit the fan soon.

[carewolf]

This is starting to remind me of the infamous pentium bug, where people thought they could reproduce it, but were just reproducing expected inaccuracies in all binary floating points. There might be an issue, but using conftests is not the way to demonstate it.

[GreatEmerald]

That crap happens on my Intel [email protected] laptop (MSI GE62-2QD Apache Pro). I would like to know why that happens and how to avoid it. Do you have any advice? What should I do? Can someone do debugging to see if there's some bug on the hardware or whatever?

It happens on my Intel machine too when I run nouveau. In other words, just because everything freezes except for the cursor does not in any way mean that it's related to someone else's problem of that sort dmesg should tell you what really happened.

[leipero]

To cut story short (for those suggesting Intel is behind this directly or indirectly = I will not speculate or acuse anyone on anything), TR is getting out, and expect articles like this, does Ryzen have bugs? Yes probably, same as Intel..., Intel is known for dirty marketing and schemes in the past, and that is excilent reason to never buy their products, and to suspect at software FIRST.

Fact remains, Michel did some test, and (according to him) he got his system freeze at some point, ofc. that can happen due to the both software and hardware, it is on testing to show what was the reason for that. Does any of this stuff (freezing, system crash etc., not conf segfaults) happens on Windows? If not, it is very clear it is a software bug, if yes, then it's up to the users to make sure none of their actions led to instability, and latter (if before was true) for AMD or board partners to debug the problem with BIOS and/or microcode in the CPU.

For me things are very simple, and I still believe those crashes are caused by software, if it's fine on Windows, there's 0 reasons to believe there's anything wrong with hardware, that simple.

[Beherit]

Why are you continously ignoring that RyzenNewbie did test on Intel but it failed on AMD only? And he wasn't the only one noticing this, the FreeBSD team speaks about it loud and clear: https://svnweb.freebsd.org/base?view...evision=321899 - And when we're at it, FreeBSD links to a DragonlfyBSD bug also pointing out that the problems are on Ryzen only: https://gitweb.dragonflybsd.org/drag...d301557fd9ac20

//EDIT: Also RyzenNewbie pointed out multiple times that you should try the FreeBSD bug for yourself on AMD and Intel CPUs but instead of doing so you keep telling he should do it while ignoring that he and multiple FreeBSD developers already did that.

The quote by Matthew Dillon (DragonFlyBSD) in one of the links above confirms it's a cpu bug: https://www.phoronix.com/forums/foru...on-loads/page2

The bug is completely unrelated to overclocking. It is deterministically reproducable.

I sent a full test case off to AMD in April.

I wonder if all these errors/crashes reproducible in DragonFlyBSD, FreeBSD and Linux occur due to the same single bug, or occur of several different bugs.