Continuing To Stress Ryzen

[drSeehas]

Just out of curiosity - don't ECC DIMMs improve the situation?

There are people in the AMD Technical Support forum using ECC and facing the bug.

Which AM4 mainboard supports ECC DIMMs in ECC mode?

[RyzenNewbie]

For anyone interested testing the - in the FreeBSD's reports mentioned - programs/scripts, I've created and uploaded a USB image to:

https://ufile.io/h1r14



It's compressed - in order to get that onto your USB drive, execute something like that:


xzcat FreeBSD-11.1-RELEASE-amd64-memstick.ryzen_test.img.xz | dd of=<PathToUsbDrive> bs=1M


Then boot from it - doesn't matter if UEFI or legacy boot mode. Once it boots through, you should get a login; just enter "root" as username, and then a little instruction will be printed.



Thanks for your effort...

[Naib]

For anyone interested testing the - in the FreeBSD's reports mentioned - programs/scripts, I've created and uploaded a USB image to:

https://ufile.io/h1r14



It's compressed - in order to get that onto your USB drive, execute something like that:


xzcat FreeBSD-11.1-RELEASE-amd64-memstick.ryzen_test.img.xz | dd of=<PathToUsbDrive> bs=1M


Then boot from it - doesn't matter if UEFI or legacy boot mode. Once it boots through, you should get a login; just enter "root" as username, and then a little instruction will be printed.



Thanks for your effort...

Thats looking more BSD specific as linux does have a full guard page as oppose to a partial in BSD. Does this mitigate a CPU issue? probably but it isn't a new one & the CPU/RAM controller shouldn't be susceptable. But this side of things may have already been sorted in linux land.

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.

[k1e0x]

That isn't showing a bug in Ryzen. That is showing a repeatable crash.
What people are failing to grasp here is the fundamentals of rigorous root cause analysis.
The BSD lot have a better handle on this than linux where right now a linux news outlet has an irresponsible headline misrepresenting the situation, an article that is now linked to many a site...

The BSD have reduced the footprint of the testcase to narrow it down.
Linux hasn't even got past the brute force method
Windows... only report I have seen (BSOD) appears to be RAM timing related.

BSD lot are still looking into their testcase to narrow it down further. It may turn out to be a BSD specific case (has the testcase been tried/ported to linux? ) it may point towards Ryzen.

Personally I would go over the BSD case to replicate the testcase in linux to increase the number of machines trialling this method. IF it doesn't cause the same fault on linux then it is possibly a BSD specific issue. IF it causes it on linux then the testcase needs to be further narrowed down

Absolutely, I may have hit this on FreeBSD but I can't confirm yet. testing..

STOP tweaking your voltage and clock, set to default if you want to test. STOP setting weird compiler options. Set -march=x86-64 If you a user and you just want it to work use make -j1. (there is a way on gentoo to set it per package so you may only need it for some packages..)

Shit I've seen people on here talking about swapping thermal paste like that'd do anything. seriously? heh, they might as well spit on it.

[k1e0x]

https://bugs.freebsd.org/bugzilla/sh....cgi?id=219399

(Poudriere is their build system for compiling binaries for the OS packages.)

finally, finally, finally a complete poudriere run without any system freezes or unexpected reboots. :-) Take a look for yourself: -- 26020 packages built within 43 hours; as flawky as the Ryzen may be, but that thing is really fast (still running stock with slow RAM) - comparing to: -- I don't know the specs of the FreeBSD "beefy" servers; but I suggest that they'll try a Threadripper when they will be out. Don, I'm quite certain that you nailed the bug for what I've created that report here for. Thank you very, very much. And if it's really nailed and not a magic moment, then Matthew Dillon was right - all the time. He said that he sent a full test case to AMD in April. It's quite a shame that there is still no reaction from their side. I'm sure, Matthew would have told by now if they really did. Anyways, I'll start a poudriere run again to see how many of the failed ports can be built then. Don, is it possible to get your one-liner patch upstream, so that other FreeBSD Ryzen users may profitate from it?

[drSeehas]

"... sent a full test case to AMD in April."

No further comment.

[chithanh]

Which AM4 mainboard supports ECC DIMMs in ECC mode?

Offically, ASRock and Biostar support ECC memory in ECC mode on their AM4 mobos.
ASUS and Gigabyte do not officially support ECC function, however according to report from amd64_edac kernel driver, ECC function is enabled when you install ECC memory. This is despite both manufacturers' technical documentation claiming that ECC would operate in non-ECC mode.
About MSI I have no information.

[Naib]

For those doing builds? what -O is being used? -Os, -O, -O2, -O3

one of the differences between AMD and Intel is shared cache and independent cache. IIRC there were gentoo users, using older AMD chips where -O3 was being used and as such aspects could not fit into the cache resulting in a segfault.

my make.conf is very conservative but I have been using -O2 for years, even on my old system, an i7

[k1e0x]

"... sent a full test case to AMD in April."

No further comment.

Yea, well it has lots of drama and negative hype now (Thanks Linux) so maybe they will pay attention.

[k1e0x]

For those doing builds? what -O is being used? -Os, -O, -O2, -O3

one of the differences between AMD and Intel is shared cache and independent cache. IIRC there were gentoo users, using older AMD chips where -O3 was being used and as such aspects could not fit into the cache resulting in a segfault.

my make.conf is very conservative but I have been using -O2 for years, even on my old system, an i7

For FreeBSD you don't need to set anything in make.conf to get generic safe builds.
For Gentoo set:
CFLAGS="-O2 -march=x86-64 -mtune=generic -pipe"
CHOST="x86_64-pc-linux-gnu"

thats prob your best bet. znver1 and core2 and all that other crap is wrong at the moment, it either doesn't work or it a stub or its incorrect. it takes some time for the compilers to get updated.. I think LLVM 5 is the first that has any real Zen optimisations in it. Then.. umm.. I think its /etc/portage/env/?? to set makeopts for single ebuilds. You'll want to set that for.. prob GCC, Mesa and anything else that busting on you. set -j1 for them (you may be able to get away with -j9 not sure..) You can use -j17 for everything else (on R7)