Continuing To Stress Ryzen

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

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

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

[oleyska]

Well make -j16 compilation does stress the CPU quite a bit, but it's nothing compared to mprime. My Ryzen goes up to 58°C (according to mobo sensor) when compiling for few hours. This guy is having temps such as 92.5°C. Sounds like a major problem with the heat sink installation

I see no temp difference between -j16 compilation and prime on ryzen, Intel however is a different story
Don't know if my cooling solution is the reason why there is no temp difference.

[soulsource]

Possibly stating the obvious here, but if the RMA didn't cover motherboard/RAM/etc., how can you conclude that the CPU might be from a bad batch?

A little more context for your thoughts on this might be in order?

There have been many independent reports on various mainboards with different chipsets, so I'd consider having the mainboard as a cause of the issue as very unlikely. The RAM cannot be ruled out yet, as there is little data on which memory brands were being used (I'll check the other two Ryzen machines where I could reproduce segfaults during mesa compilation, if they have by chance the same RAM as my own machine, or vastly different memory).
The fact that for some people the processor sent back by RMA does not show any issues on otherwise identical hardware is another hint in the direction that there might be working/non-working Ryzens out there.

[Hadrian]

Heil intel...

No way.
It's: Hail Mary!

And I prefer AMD. Still I've got no idea what your post has to do with my original one.

[mlau]

Note, that Ryzen X models report CPU temperatures 20°C higher than real ones.

See https://community.amd.com/community/...mmunity-update

Still, +72.2°C is pretty high for these chips. You probably need a better cooler.

The 90°C+ is probably junction temperature (min. 45, max I've seen is 94). All are taken from the superio chip: it has another reading labelled "CPUTIN" which never goes beyond 66°C. BUT, my main point was, that after improving cooling (i.e. Tj not immediately jumping to >92C on tiniest bits of load), the segfaults went away.

[mbello]

Michael, please, urgently change the title of your article. 50+ segfaults per hour is the rate of conftest segfaults and that shouldn't count.

Also, we know you want to advertise the use of the stress run functionality on PTS, but it has failed and is much worse that simply running the "ryzen kill" script for the purpose of reproducing the Ryzen bug. If you insist, then please remove the php test from the suggested command as that is the one with conftest segfaults which leads to false positives.

Please Michael, act quickly, your article as it stands is only adding noise to the Ryzen issue.

[caligula]

All that talk about temperatures is quite ridiculous, normal compiling is not a thermal stresstest. Actually, it's totally harmless compared to Prime95 or LinX (even without Intel's heating AVX).

Well make -j16 compilation does stress the CPU quite a bit, but it's nothing compared to mprime. My Ryzen goes up to 58°C (according to mobo sensor) when compiling for few hours. This guy is having temps such as 92.5°C. Sounds like a major problem with the heat sink installation

[kaseki]

please run that test with your Phenom on an upgraded Mint 18.1 with kernel 4.11.0-13. And, please, run that test with the same thread count as on the Ryzen; plus longer than 2 hours. Just to ensure a comparable environment.

agreed - that shouldn't be neccessary to get a stock system running stably, should it - meaning: just select "BIOS defaults" and everything is fine...

First, I just now had to kill the processes on the Phenom (this PC) after 3 hours (no seg. faults) because it slowly locked up my mouse when I tried to do other stuff in parallel. (Even the REISUB technique only broke the spell; it didn't by itself initiate a reboot.) The Phenom PC is my present "production" computer and I cannot divert it to an experiment beyond what I just tried at this time. I'm not even ready to upgrade it to Mint 18 and deal with any possible incompatibility consequences at the moment. Further, it is only a four-thread four-core machine. The kill-Ryzen program sets the number of threads to the number the CPU can support, so it can't do what you want of forcing 16 threads on the Phenom. Beyond that, the storage is different, the RAM is different, the MB and BIOS is different; in no real way are the two PCs comparable except being AMD based. La-de-dah. I'm not even sure I would call the AMD of then and the AMD of now comparable.

And LOL on stable. The Ryzen/Asus C6H OC beta BIOS boondoggle has a 25k+ message thread for a reason. While my initial hardware build of my Ryzen HTPC POSTed without problem on the shipped BIOS (one version past the bricking BIOS), and the Linux build was possible albeit with some GPU driver difficulties, attempts to get one's money's worth out of Ryzen and the DRAM required a lot of work by many people. (But I think you really already know this.)