Continuing To Stress Ryzen

[Hadrian]

Got off the phone with AMD a few minutes ago. They are able to confirm problem in the very heavily compilation workloads and will be working with affected users. More info in article shortly.

Great work, and good to finally see an official confirmation from AMD.

For new thread readers, the new Ryzen bug confirmation article is here:

https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

Those people here in the thread who insulted Michael and other brave testers for having encircled the Ryzen-when-heavy-load-on-Linux bug: a sincere apology would be due.

[nightmarex]

Great work, and good to finally see an official confirmation from AMD.

For new thread readers, the new Ryzen bug confirmation article is here:
https://www.phoronix.com/scan.php?pa...-Segv-Response

Those people here in the thread who insulted Michael and other brave testers for having encircled the Ryzen-when-heavy-load-on-Linux bug: a sincere apology would be due.

Wait... Can I join, Michael you Shintel... crap one second.. um, drama queen! That's all I got. Last few years Michael's been doing much better, however he was hard on AMD in the past and some people probably remember that. That said, people need to understand that these things could have been less nasty if AMD was more reassuring/acknowledging of the issue. Of course the counter problem is these annoying bastards are shouting in every forum about this "bug" situation which is what it is I guess.

[kaseki]

"Hello. As a software guy, I compile a lot of code, and occasionally gcc crashes with a segmentation fault for no obvious reason. I seem to remember that"]

Please note that that quote is not mine, but was extracted from the start of the link by the Phoronix forum link software. I'm more of a hardware guy, I would say. In any case, I had to kill the save-ryzen run because there were build failures without a cause given, and complaints of " ****stack smashing detected**** " -- a new one on me. Reads more like a bad day at Walmart than a CPU being abused.

[pjssilva]

Thank you, Michael. That is great news! Now that AMD is taking the problem seriously things must get back into track!

[chithanh]

This means absolutely nothing!
Each ECC module is supported by every mainboard. But only in non-ECC mode.
I want an officially working ECC mode!

ASRock AM4 UEFI setup does have ECC settings, like setting scrub rate.
With ASUS/Gigabyte there is not even an option to enable/disable ECC.

And amd64_edac driver confirms operation in ECC mode.

[drSeehas]

ASRock AM4 UEFI setup does have ECC settings, like setting scrub rate. ...

Which page in the Fatal1ty X370 Gaming K4 manual?
Find "scrub" with 0 results.
Find for "ECC" only these results:

• AMD Ryzen series CPUs support DDR4 2933+(OC)/
2667/2400/2133 ECC & non-ECC, un-buffered memory*
• AMD 7th Gen A-Series APUs support DDR4 2400/2133 ECC
& non-ECC, un-buffered memory*

[RyzenNewbie]

(...) set "kern.hz=1000" and started a fresh poudriere run - let's see how it goes...

and it froze; granted, I used only half of the shared-user-page patch, but at least, increasing the clock ticks frequency alone doesn't do anything, unfortunately. But was worth a try...

[RyzenNewbie]

(..) increasing the clock ticks frequency alone doesn't do anything

at least at that freeze/reboot part - I think I'll apply the full shared-user-page patch and try again with increased "kern.hz"...

[RyzenNewbie]

Are you talking about adding a guard page at the top of canonical userspace (the workaround Matt Dillon mentioned)?

Linux has had that for years, and I imagine Windows has as well:

http://elixir.free-electrons.com/lin...sm/processor.h

If BSD does not already have a guard page then I strongly recommend you add one because there are at least three older CPU families (two Intel and one AMD IIRC) which can exhibit unexpected behaviour when executing code in the top page of user space.

EDIT - looks like a guard page was just added to FreeBSD:

https://svnweb.freebsd.org/base?view...evision=321899

Just remembered that there was already a small (less than a page) guard region in BSDs but AFAIK other OSes went with a full page from the start.

yep, you're right - before r321899 there was no "guard page", wasn't neccessary - until now, I suppose:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c216

Documentation, though, is another story...

[bridgman]

You could use the Linux documentation

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c215