Continuing To Stress Ryzen

[scorpio810]

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

grep CONFIG_RCU_NOCB_CPU= /boot/config-4.11.12-vanilla
CONFIG_RCU_NOCB_CPU=y

grep CONFIG_RCU_NOCB_CPU_ALL= /boot/config-4.11.12-vanilla
CONFIG_RCU_NOCB_CPU_ALL=y

This options in kernel + disable core C6 can help when you have idle freezes.
Never see idle freezes since I added this options in my custom kernel.

[Beherit]

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.

As accurate as your post is, you probably just stepped on the toes of many open source fanboys.

For reasons I posted above, I still believe this to be a hardware bug. You're right though that no similar errors have been reported by developers using Windows. (no, dear fanboys, WSL doesn't count)

[sdack]

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.

So the newb couldn't reproduce it on an Intel box while others could reproduce it. How long are you going to ignore this? All you do is cry wolf and keep pointing at the hear-say of others. You want to blame AMD for a bug you fail to pin-point in hope they eventually tell you where to find it. Your kind disgusts me.

[m132]

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.

That's just stupid. Imagine you've installed Windows and Linux side by side on the same disk. The disk broke, leaving bad sectors on Linux partition, but Windows one is perfectly clean. Would you still believe, that read errors on Linux are purely a software issue, just because Windows doesn't support Linux filesystems at all?

[sdack]

And that this damage happens is totally AMD's fault. ...

That's pathetic.

[scorpio810]

As accurate as your post is, you probably just stepped on the toes of many open source fanboys.

For reasons I posted above, I still believe this to be a hardware bug. You're right though that no similar errors have been reported by developers using Windows. (no, dear fanboys, WSL doesn't count)

This is normal when you see the slowness to compile under Windows !
That's why I use a cross compilation environment for build my Qt 5 Windows packages, uhuhu !

[leipero]

As accurate as your post is, you probably just stepped on the toes of many open source fanboys.

For reasons I posted above, I still believe this to be a hardware bug. You're right though that no similar errors have been reported by developers using Windows. (no, dear fanboys, WSL doesn't count)

I doubt, I am first to be free software fanboy (I even refuse to use open source term most of the time), but if something can't be reproduced on one software, the first logical step is to assume software problem.

[sdack]

From the latest Update (5th August):

"As many readers have pointed out, BSD developers have also discovered a Ryzen bug. More details soon."

This is more nonsense. One developer believes to have found something... This is not the same as saying they have found a bug. If it is a bug within the CPU is only for AMD to say. The one dev might be misreading the specs or has run into a new feature without having the specs to it. He obviously doesn't know what's going on within the new CPU.

[Guest]

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.

Windows is much slower than Linux and *BSD and maybe it just doesn't hit these bugs.

[rvdboom]

For what it's worth, I've just compiled yesterday a whole kernel, mesa-git, scribus, wine, several dozen small packages, ffmpeg and vlc, on my Ryzen 1700 with the MSI Tomahawk B350 platform and 16GB of RAM. I bought GSkill RAM which do not run above 2133Ghz right now, but I'm fine with that.
No segfault at all. Haven't had a segfault compiling since I bought the equipment (almost at Ryzen's release, I was an early adopter). I had a few hangs at first that were solved by BIOS upgrades (I'm not even running the latest BIOS right now).
I'm running a slackware64-current system, and compile with the following options : "-O3 -fPIC -march=znver1 -mtune=znver1"
I use -j17 with make so I tend to use all cores extensively.
I also transcode a lot of 20+ GB videos files with 16 threads and never had an issue, even when the operation took 2+ hours. So it doesn't seem to be a stressing issue.
So my guess is :
- This seems specifically related to compilers
- It's triggered only in specific situations and in particular setups.
Which could be software or hardware-related, as far as I know.
It's good that Michael can reproduce so easily, it will be easier to debug for the devs.