Continuing To Stress Ryzen

[nasyt]

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

I remember one of these Linux trolls (endman, jake_lesser, etc...) claiming the opposite: That BSD is slower than windows....

(....which doesn't supprises me, since the Server version Windows is pretty well known to be exactly as fast Linux.)

[drSeehas]

... here is the ASRock X370 Taichi from the hardwarecanucks Ryzen ECC article: ...

Nothing in the manual too.
Far too expensive. For a few bucks more I could get a Threadripper board.
I'll wait.

[chithanh]

Which page in the Fatal1ty X370 Gaming K4 manual?

I haven't read the manual, but here is the ASRock X370 Taichi from the hardwarecanucks Ryzen ECC article:


(The rest of the article is not really worth reading, as hardwarecanucks spread misinformation about Linux memory error handling which they declined to correct even after I pointed it out to them)

[bridgman]

You could use the Linux documentation

https://bugs.freebsd.org/bugzilla/sh...id=219399#c215

[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/sh...id=219399#c216

Documentation, though, is another story...

[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]

(...) 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...

[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*

[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.

[pjssilva]

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