Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads

[BitMaster]

**edit: just saw the post above....double post then baaahhhh


As of today, we are informed INTEL has a similar bug in Skylake and Kaby Lake chips, from Pentiums up to Xeons of those product lines, brought to attention by Debian Group.

It affects ALL operating systems.

The only available fix right now for most of those CPUs is to disable HT, unless you have a certain series of Kaby Lake, where Intel already has a microcode fix available.

Read it on guru3d.com

 

[Shintai]

**edit: just saw the post above....double post then baaahhhh


As of today, we are informed INTEL has a similar bug in Skylake and Kaby Lake chips, from Pentiums up to Xeons of those product lines, brought to attention by Debian Group.

It affects ALL operating systems.

The only available fix right now for most of those CPUs is to disable HT, unless you have a certain series of Kaby Lake, where Intel already has a microcode fix available.

That issue was already resolved.

 

[juanrga]

**edit: just saw the post above....double post then baaahhhh


As of today, we are informed INTEL has a similar bug in Skylake and Kaby Lake chips, from Pentiums up to Xeons of those product lines, brought to attention by Debian Group.

It affects ALL operating systems.

The only available fix right now for most of those CPUs is to disable HT, unless you have a certain series of Kaby Lake, where Intel already has a microcode fix available.

Read it on guru3d.com

Nope, an April fix that solves this bug has been available, together with instructions to install them. Latest Kernel update already includes the fix

THE MICROCODE PACKAGES FROM THE RECENT STABLE RELEASE (June 17th, 2017)
ALREADY HAVE THE SKYLAKE FIX, BUT YOU MAY HAVE TO INSTALL THEM.

You have it all here

https://lists.debian.org/debian-devel/2017/06/msg00308.html

On the other hand, I have checked the status of the last RyZen bug, and it continues without being fixed

https://community.amd.com/message/2807153?tstart=0#2807153

 

[Gideon]

Hmm yet the media ignore this supposed Ryzen bug. Oh wait that is right its just a forum post not a reported issue from a organization.

 

[lolfail9001]

Hmm yet the media ignore this supposed Ryzen bug. Oh wait that is right its just a forum post not a reported issue from a organization.

That's okay, media will get to reporting on it after AMD releases a fix. Of course they won't mention that bug is few months old at this point, but w/e.

 

[Gideon]

That's okay, media will get to reporting on it after AMD releases a fix. Of course they won't mention that bug is few months old at this point, but w/e.

The Intel bug is a few months old so whatever.... The FUD you guys like to bring is entertaining.

 

[lolfail9001]

The Intel bug is a few months old so whatever.... The FUD you guys like to bring is entertaining.

The Intel bug is few years old and it's fix is few months old.

Want to know why it was only found half a year ago? It was related to some hardcore legacy code in stupidly short loops.

This bug so far is well... not even close.

 

[Gideon]

The Intel bug is few years old and it's fix is few months old.

That didnt make it look better my man but I was just referring to the fix. Not how long the errata has existed.

 

[lolfail9001]

but I was just referring to the fix.

Sure, AMD without a fix look better here.

 

[Gideon]

Sure, AMD without a fix look better here.

There is no bug confirmed by any organization on Ryzen unlike Intel. Why do you think its in the news sherlock. A forum posting is not a official confirmation of a bug. If Debian came out and said there was a issue with Ryzen then we would have news posted on it. The 3 of you well you know what you look like.

 

[lolfail9001]

There is no bug confirmed by any organization on Ryzen unlike Intel.

And just like Intel, AMD won't acknowledge it's existence until they prepare a fix. Get it yet?

A forum posting is not a official confirmation of a bug.

So, why did everyone write news about a fucking mailing list? Because that's what message that sourced that recent info is. Please, we all know how clickbaits work.

 

[Gideon]

And just like Intel, AMD won't acknowledge it's existence until they prepare a fix. Get it yet?

So, why did everyone write news about a fucking mailing list? Because that's what message that sourced that recent info is. Please, we all know how clickbaits work.

The TLB errata bug was acknowledge by AMD before they had a fix and that fix is famous since enabling it hurt performance.

Your still not getting it was a Organization that was reporting it and it was a official message from them warning people that use their software. A huge difference from a forum post where someone reports a issue. Past that I am done explaining it to you.

 

[lolfail9001]

The TLB errata bug was acknowledge by AMD before they had a fix and that fix is famous since enabling it hurt performance.

Yes, it was acknowledged by AMD on the freaking launch of Phenom.

Also Debian dev != Debian organization

 

[juanrga]

Hmm yet the media ignore this supposed Ryzen bug. Oh wait that is right its just a forum post not a reported issue from a organization.

The same media is making false headlines about the Skylake/Kabylsake bug?

Over the weekend, developers for the Linux distro, Debian, discovered a bug with Intel’s CPU microcode for Skylake and Kaby Lake. The issue can cause some systems to misbehave with Hyper-Threading enabled and lead to data corruption or loss. Given that Skylake and Kaby Lake have been around for quite some time, this isn’t an issue that is going to be widespread. However, the exact conditions that cause the error are unclear.

The Debian advisory says there's a simple fix to prevent any dangerous misbehaviour by your Skylake or Kaby Lake processor - disable Hyperthreading. Processors affected include Core processors for desktops and laptops, and Intel Xeon processors. Basically if it is from one of those families and it has Hyperthreading capabilities then it is affected.

When the Debian mail-list says that a fix has been available for months. In fact the fix is already packaged in last release of the distro:

THE MICROCODE PACKAGES FROM THE RECENT STABLE RELEASE (June 17th, 2017)
ALREADY HAVE THE SKYLAKE FIX, BUT YOU MAY HAVE TO INSTALL THEM.

 

[Gideon]

The same media is making false headlines about the Skylake/Kabylsake bug?





When the Debian mail-list says that a fix has been available for months. In fact the fix is already packaged in last release of the distro:

Yet the Bug has been available for years. Now the media and prime95 have it out for Intel, man it gets more fun each day.

 

[juanrga]

Updated thoughts

http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/

 

[funks]

The problem I'm running into and the compile bug may be related..

When I enable SMT on my System (RYZEN 1700X, Taichi, X370 with 2.40 BIOS, 32GB of RAM) - nothing overclocked, just default settings, I'm unable to run the "Ashes of Singularity - Escalation DX12 benchmark" - it basically crashes to desktop (runs for a bit but doesn't finish). It only happens when in DX12 mode, not DX11 (my assumption is that DX12 mode is stressing the CPU a bit more).

Replaced the board ( Gigabyte AB350 Gaming 3), Replaced the Video Card (GTX 1070 FE -> GTX1080TI), Power Supply, Tried all kinds of NVIDIA Drivers, Made sure any overlay or streaming is disabled, ,fresh installed Windows couple of times ), Temps are good (Corsair H110i and the temps are low), Installed the AMD 17.10 chipset drivers (and running Ryzen Balanced Power Plan). - only thing that prevents the benchmark from crashing is disabling SMT.

Otherwise, the system's been pretty stable aside from this benchmark ( Intel Burn Test, MemTest86, WIndows Mem Diagnostics, Prime 95, AIDA64, X264 encodes, etc etc). Considering multiple reviewers benched Ryzen with Ashes in DX12 mode, my assumption is that the 1700X I got is a bit bugged.

 

[Pieter3dnow]

The problem I'm running into and the compile bug may be related..

When I enable SMT on my System (RYZEN 1700X, Taichi, X370 with 2.40 BIOS, 32GB of RAM) - nothing overclocked, just default settings, I'm unable to run the "Ashes of Singularity - Escalation DX12 benchmark" - it basically crashes to desktop (runs for a bit but doesn't finish). It only happens when in DX12 mode, not DX11 (my assumption is that DX12 mode is stressing the CPU a bit more).

Replaced the board ( Gigabyte AB350 Gaming 3), Replaced the Video Card (GTX 1070 FE -> GTX1080TI), Power Supply, Tried all kinds of NVIDIA Drivers, Made sure any overlay or streaming is disabled, ,fresh installed Windows couple of times ), Temps are good (Corsair H110i and the temps are low), Installed the AMD 17.10 chipset drivers (and running Ryzen Balanced Power Plan). - only thing that prevents the benchmark from crashing is disabling SMT.

Otherwise, the system's been pretty stable aside from this benchmark ( Intel Burn Test, MemTest86, WIndows Mem Diagnostics, Prime 95, AIDA64, X264 encodes, etc etc). Considering multiple reviewers benched Ryzen with Ashes in DX12 mode, my assumption is that the 1700X I got is a bit bugged.

Not to sure on what exactly is happening but in general DX12 uses more cpu cores to be able to send data to the gpu. From the google I did it seems that many people report DX12 crashing for them on ashes of the singularity. My guess is that if you would loop the demo without SMT it would still crash. Looping it on a B350 motherboard is something I would not do unless your VRM are cooled properly.

 

[juanrga]

Looping it on a B350 motherboard is something I would not do unless your VRM are cooled properly.

Why this insistence on B350 mobos? It has been demonstrated in this thread that the problem exists on X370 mobos and the user whom you are replying has a X370...

 

[funks]

Not to sure on what exactly is happening but in general DX12 uses more cpu cores to be able to send data to the gpu. From the google I did it seems that many people report DX12 crashing for them on ashes of the singularity. My guess is that if you would loop the demo without SMT it would still crash. Looping it on a B350 motherboard is something I would not do unless your VRM are cooled properly.

Tried this test 10 times (this past hour), alternating in between SMT ON and SMT OFF (only thing changed in the BIOS) - rebooting in-between each time then running the bench 2 minutes in after login. Just tried mutiple back to back runs on the DX12 bench with SMT off and that works fine as well.

100% failure rate for me running Ashes DX12 benchmark - SMT on leads to CTD. Running the DX11 Mode Bench thought with SMT on completes just fine.

 

[ManofGod]

The problem I'm running into and the compile bug may be related..

When I enable SMT on my System (RYZEN 1700X, Taichi, X370 with 2.40 BIOS, 32GB of RAM) - nothing overclocked, just default settings, I'm unable to run the "Ashes of Singularity - Escalation DX12 benchmark" - it basically crashes to desktop (runs for a bit but doesn't finish). It only happens when in DX12 mode, not DX11 (my assumption is that DX12 mode is stressing the CPU a bit more).

Replaced the board ( Gigabyte AB350 Gaming 3), Replaced the Video Card (GTX 1070 FE -> GTX1080TI), Power Supply, Tried all kinds of NVIDIA Drivers, Made sure any overlay or streaming is disabled, ,fresh installed Windows couple of times ), Temps are good (Corsair H110i and the temps are low), Installed the AMD 17.10 chipset drivers (and running Ryzen Balanced Power Plan). - only thing that prevents the benchmark from crashing is disabling SMT.

Otherwise, the system's been pretty stable aside from this benchmark ( Intel Burn Test, MemTest86, WIndows Mem Diagnostics, Prime 95, AIDA64, X264 encodes, etc etc). Considering multiple reviewers benched Ryzen with Ashes in DX12 mode, my assumption is that the 1700X I got is a bit bugged.

I have a fully AMD system with the Taichi mainboard, 1700X and 16GB of ram and my system is overclocked. I am not experiencing the issues you are at this time. The primary and common denominator on your system is the Nvidia hardware, not really sure why you would replace everything else just of this issue. (Unless, of course, you already had those parts lying around, then no biggie.)

Edit: Oh, and SMT is enabled.

 

[dragonstongue]

this thread is funny. AMD does the spec design i.e reference, if makers such as Asus or whatever could not be bothered to ensure that heavy load or overclocking result in crash or VRM burning up, that is the MAKERS fault, not AMD, remember AMD makes the cpu, not the motherboard in any way shape or form last that I checked.

Best part of it is /r/AMD going full denial over it.

"AMD is recommending to disable SMT"

How is AMD going full denial over this, when they recomend disabling something till they can fix it? Did not take them that long IMO to start doing AGESA update, work on getting RAM speeds sorted out etc. Suppose some seem to forget that AMD not that long ago was on the losing end of not making much $ for YEARS, less and less engineers, software devs and so forth is the cost of that battle, to me, IMO, they are doing the very best they can to do what they can when they can, unlike some partners (which should of course get told to stop fk around make AMD look bad)
guess if a maker such as Asus fk up via THEIR motherboard design, it must be AMD fault automatically because of the chipset model number, instead of Asus etc who is the one makes/certifies the product and should have fully tested before releasing!

Hell mighty Intel has problems in many ways(often doing as much as possible to NOT admit and blame on something else, if not just saying sweet fk all) AMD does not seem to hide things, rather they tell users a problem how to fix or they know that problem is there and are working towards a solution. Do they make perfect products, not short sighted mistakes, of course not, but shitting on them for "small" issues that say Nvidia, or Intel make all the damn time is just stupid.

mentioning Intel, hmm, cream of the crop chips/motherboards, supposedly "make the best AMD cannot compete" Core i9 and x299, many boards are having overheat VRM issues, that is their best of the best, and not long ago, thin chips bending under heatsink pressure, piss poor excuse for thermal interface from them, cause you know spending an extra few $.01 would massively hurt the bottom line on hundreds $ finished products.

 

[funks]

I have a fully AMD system with the Taichi mainboard, 1700X and 16GB of ram and my system is overclocked. I am not experiencing the issues you are at this time. The primary and common denominator on your system is the Nvidia hardware, not really sure why you would replace everything else just of this issue. (Unless, of course, you already had those parts lying around, then no biggie.)

Edit: Oh, and SMT is enabled.

K, it's nice to know that the problem may be isolated to specific systems - only thing I haven't replaced so far is the CPU.

Will try getting a Warranty Replacement with AMD.

 

[Pieter3dnow]

Why this insistence on B350 mobos? It has been demonstrated in this thread that the problem exists on X370 mobos and the user whom you are replying has a X370...

Because you just fail badly at reading what people are saying ,

Replaced the board ( Gigabyte AB350 Gaming 3), Replaced the Video Card (GTX 1070 FE -> GTX1080TI), Power Supply, Tried all kinds of NVIDIA Drivers, Made sure any overlay or streaming is disabled, ,fresh installed Windows couple of times ), Temps are good (Corsair H110i and the temps are low), Installed the AMD 17.10 chipset drivers (and running Ryzen Balanced Power Plan). - only thing that prevents the benchmark from crashing is disabling SMT.

 

[Shintai]

Because you just fail badly at reading what people are saying ,

Since you mention reading.

The problem I'm running into and the compile bug may be related..

When I enable SMT on my System (RYZEN 1700X, Taichi, X370 with 2.40 BIOS, 32GB of RAM) - nothing overclocked, just default settings, I'm unable to run the "Ashes of Singularity - Escalation DX12 benchmark" - it basically crashes to desktop (runs for a bit but doesn't finish). It only happens when in DX12 mode, not DX11 (my assumption is that DX12 mode is stressing the CPU a bit more).

Replaced the board ( Gigabyte AB350 Gaming 3), Replaced the Video Card (GTX 1070 FE -> GTX1080TI), Power Supply, Tried all kinds of NVIDIA Drivers, Made sure any overlay or streaming is disabled, ,fresh installed Windows couple of times ), Temps are good (Corsair H110i and the temps are low), Installed the AMD 17.10 chipset drivers (and running Ryzen Balanced Power Plan). - only thing that prevents the benchmark from crashing is disabling SMT.

 

[Pieter3dnow]

Since you mention reading.

https://hardforum.com/threads/some-...pilation-loads.1936605/page-4#post-1043100637

good luck

 

[juanrga]

this thread is funny. AMD does the spec design i.e reference, if makers such as Asus or whatever could not be bothered to ensure that heavy load or overclocking result in crash or VRM burning up, that is the MAKERS fault, not AMD, remember AMD makes the cpu, not the motherboard in any way shape or form last that I checked.

Why do you still insist on this is an overclocked motherboard fault, when the issue is being reproduced in people without any overclock. It is not a mobo problem. A bug on RyZen has been identified. Read the evidence given in the thread.

How is AMD going full denial over this, when they recomend disabling something till they can fix it?

Say that to the RyZen users that are complaining because AMD first ignored the problem, then closed the support tickets --when the problem is not solved-- and now remains fully silent. Some extracts from the AMD support links given in the OP:

I'm glad to hear, that I'm not alone. I'm sad that AMD does not want to answer this question. It would be ok if I have to change a component, but I really would love to know which. I've already switched the mainboard without any effect.

I would really appreciate a response as "This question is Assumed Answered." is not true. The problem exists, and even if disabling SMT "fixed" it (which I'll repeat - it doesn't) that isn't an answer.

And you find similar complains in other fora as well. Someone replied this to me time ago. I didn't quote it here, but I will quote him now:

Yes, it is annoying. AMD should officially acknowledge the issue.

We have two Ryzen machines in gcc compile farm and I've seen random non-reproducible
crashes on both of them (and also git corruptions).
Hopefully it is a rare μ-op-cache problem that could be fixed by a firmware update.
But it could also be too aggressive binning.

Note the latest reply in that thread. It is very interesting:

The Playstation 2 Dev units had an almost identical bug accessing the extra rambus ram that that the dev units had. The CPU would fault and a register would have an impossible value, but if you checked the address 64 megabytes lower you would fine that value.

The bug would happen when another access (the GPU) had opened that lower page and the access for the higher page would get that lower cache line instead of the 64 megabyte higher address.
It may have also involved a tight timing situation, both accesses happening in sequence, etc.

This would be why turning off SMT or ASLR reduces the frequency of crashes, fewer chances of identical low address bits on close accesses.

 

[juanrga]

https://hardforum.com/threads/some-...pilation-loads.1936605/page-4#post-1043100637

good luck

It shows how he mentions that has a problem on a X370 mobo, and you omitting that and repeating again the litany about B350 mobos. The same litany since your first post in this thread, and your second post, and your third post...

 

[juanrga]

I just checked AMD support forums to see the status of the bug. It has gone worse, with lots of hungry users. I didn't follow the whole discussion, but it seems that the bug only affects B1-stepping CPUs. AMD is emailing some users and suggesting to RMA the chip, but people is only gettinh broken chips replaced by broken chips. because all RyZen chips are B1 silicon. Some excerpts:

I would like to write it again, but this problem has not been answered, and regardless of the OS (even on Windows) Access Violation will occur.

AMD deceives ordinary users and continues to sell B1 stepping Ryzen.

Users who own Ryzen and have segmentation faults are highly disappointed with the actions of AMD.

We should try to establish the hastag #epicfail !

Support Ticket is opened, Amd is not really answering but asking usless questions like which was my second powersupply I used. Hey maybe I should try a third and a 4th one ...

I was realy an AMD Fanboy for years now, but all the love is gone, there is only frustration left. This is the worst reaction to usercomplaints I've ever seen by a reliable company.

AMD wants to keep selling the CPUs they've got in shops and in warehouses. They won't admit they need to release a new stepping so they can sell the current stock. Kids playing games on Windows don't run into these bugs. AMD is marketing these processors for gaming machines for kids. AMD doesn't care about Linux or FreeBSD. AMD cares about making money selling these CPUs to teenagers who play games on Windows.

This is very likely AMD's play. They've announced Ryzen Pro which is marketed with better quality. What if this better quality is the difference between the basic flawed Ryzen which segfaults and the Ryzen Pro?

AMD hasn't convinced me this isn't the case. They're not doing anything to help. RMAs don't help because you'll probably get a broken CPU.

Everyone who's going through the RMA process could get something worse than what they have right now or just as bad. My Ryzen 7 1700 doesn't become unstable if left idle, but it runs into the segfaults. What if I get a Ryzen 7 1700 which is unstable, reboots if left idle or logs MCE errors in the cache? What if I get a Ryzen 7 1700 which doesn't segfault and doesn't log any MCE errors thanks to luck? What if AMD releases a new stepping which addresses all these issues and other issues later?

Didn't others report, that RMA didn't help, and they were still getting the problem?

I'm in that boat - I RMA'ed my processor and the replacement also exhibits the same behaviour (segfault while doing multithreaded compiles). That said, I have not yet given up - I'm still working with AMD support, who are in the process of testing a second replacement CPU for me with the same motherboard and RAM as mine to make sure it works before we go through the RMA process again.

AMD just contacted me. I will get my third CPU and we will try if this one works. Seems like a lottery to me if you get a working copy or not.

I will keep you informed.

One user is stating that EPYC is B2, but ThreadRipper is B1, which according to that AMD forums implies ThreadRipper will be similarly broken.

 

[Ocellaris]

I just checked AMD support forums to see the status of the bug. It has gone worse, with lots of hungry users. I didn't follow the whole discussion, but it seems that the bug only affects B1-stepping CPUs. AMD is emailing some users and suggesting to RMA the chip, but people is only gettinh broken chips replaced by broken chips. because all RyZen chips are B1 silicon. Some excerpts:













One user is stating that EPYC is B2, but ThreadRipper is B1, which according to that AMD forums implies ThreadRipper will be similarly broken.

Has anyone confirmed Epyc B2 actually fixed the issue?

As a side note the Intel HT issue, it looks like most 1151 motherboards have had BIOS updates with new microcode to fix the issue.

 

[juanrga]

Has anyone confirmed Epyc B2 actually fixed the issue?

In a fast reading of the AMD support forum, I found several people claiming that B2 silicon doesn't have this bug, but I wouldn't take that as confirmation.

 

[Gideon]

Oh look who it is again. B2 is Epyc, not sure if Threadripper is but likely. B1 is Ryzen, there is no B2 Ryzen since B2 only refers to Epyc. If B1 silicon had a problem with certain software then everyone would have it and thats not the case. A few people having a issue is likely a few bad chips that got through with 1 or 2 transistors not working properly. That happens on Intel and AMD and nothing is new about it, always sucks when it happens to you. They are RMAing the chip which is what they need to do. You keep stomping all you want Juanrga but no one sees this as a issue with Ryzen or in the media. Intel needed a microcode update cause they had a bug that effected everyone not a few. See ya in 4 or 5 days when you post the same drivel.

 

[juanrga]

People is RMAing the broken chip just to get another broken chip. But at least we are advancing; after months, four pages, and hundred of posts certain people is finally admitting that there is a problem with RyZen CPUs and that the problem wasn't on "B350 boards".

 

[Shintai]

People is RMAing the broken chip just to get another broken chip. But at least we are advancing; after months, four pages, and hundred of posts certain people is finally admitting that there is a problem with RyZen CPUs and that the problem wasn't on "B350 boards".

Zen bug list stays quite long. I sure hope AMD starts to solve some of them soon instead of people having to try RMAing etc and perhaps waiting for a later stepping that may or may not fix it. It could also end up like Barcelona.

 

[noko]

Zen bug list stays quite long. I sure hope AMD starts to solve some of them soon instead of people having to try RMAing etc and perhaps waiting for a later stepping that may or may not fix it. It could also end up like Barcelona.

Zen2

No problems here, both systems stable as a rock.

 

[juanrga]

Zen2

Zen2 is a new microarchitecture. It could solve all current bugs or introduce some new.

No problems here, both systems stable as a rock.

That is good for you, but it doesn't eliminate the bugs are affecting people that uses Zen for work.

 

[ManofGod]

Zen2

No problems here, both systems stable as a rock.

Yep, both my Ryzen R7 systems are rock solid stable as well at 3.8 Ghz. I would imagine that your Custom SFF case work station is fast too, right?

 

[Dermac]

Gotta say, my work 1700 and my home 1700 are stable with the stock coolers at 3.8ghz.

 

[funks]

If some of you guys have some free time, would it be possible for you guys to run the following test? No need to install Linux on the HDD (installing it on USB Flash Drive would do). My two Ryzen systems looks stable under Windows but fails compiling code under Linux when heavily loaded. A bunch of people on Reddit who tried it are running into the same problem.

Linux Compile Test Guide: for people wanting to test their Ryzen CPU's but don't want to install Linux on HDD. Please run the test for at least 8+ hours.

BIOS Setup: (may not have to do this for people with stable rigs)
Load Defaults (save and reboot)
Enable SVM (Virtualization)
Enable SMT (if it's disabled)
Save and reboot.

Pre-Requisites:

1) At least 16 Gigs of RAM
2) A 16 GB USB Flash Drive
3) Download RUFUS Tool for Windows

https://rufus.akeo.ie/downloads/rufus-2.16p.exe

4) Download artful-desktop-amd64.iso OR ubuntu-17.04-desktop-amd64.iso

http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso

Note: daily builds of Artful Aardvark comes with Kernel 4.11, while Zesty Zapus comes with Kernel 4.10.

5) Burn ISO image using RUFUS Tool onto USB FLash Drive

Note: Partition Scheme should be set to "MBR partition scheme for UEFI"

6) Download AOMEI Partition Assistant Standard (Free)

http://www.aomeisoftware.com/download/pa/PAssist_Std.exe

7) Run the Partition Assistant program and resize the FAT32 partition on the USB DRIVE to 4 Gigabytes, then apply the changes
8) Add a second partition with a file system type of "Unformatted" to the USB DRIVE, size it at 8 Gigabytes, then apply the changes.

Procedure:

1) Plug in USB Flash Drive
2) Boot to UEFI
3) In the UEFI screen, select Exit Tab -> Boot Override -> UEFI : USB Drive
4) In the GRUB screen, make sure "Try Ubuntu without installing" is highlighted, hit ''e" key.
5) Change the section with the words "quiet splash" to "nomodeset" then hit "F10" (note, only change those two words, only needs to be performed on GTX 1080, or 1080TI+).

6) It should take you to the ubuntu desktop
7) Turn off screen saver

Artful Aardvark (17.10):

System Settings -> Power -> Power Saving [Section] -> Blank screen = Never, then hit the [x] icon to close the window.

Zesty Zapus (17.04):

Navigate [Gear Icon] -> System Settings -> "Brightness & Lock" -> "Turn screen off when inactive for: " = Never, then hit [x] icon to close window

8) Right click on desktop and select "Open Terrminal"
9) In terminal, type "sudo su -"
10) It should log you in as root and change your working directory to /root
11) Type "free" - if it's showing you have 8 Gigs of SWAP then ignore SECTIONS 12 -> 15
12) Type "lsblk" to get a list of drives and partitions available in the system
13) Locate the block device alias for your USB DRIVE (in my system - it was /dev/sdb)
14) Type "mkswap /dev/sd?2" - replace the question mark with the correct device alias letter
15) Type "swapon /dev/sd?2" - replace the question mark with the correct device alias letter, this will use the secondary partition on the USB DRIVE as system swap space
16) type "wget http://funks.ddns.net:8080/tools/ryzen/testRyzenGCC.sh"
17) type "chmod 700 testRyzenGCC.sh"
18) type "./testRyzenGCC.sh" to startup the GCC 7.1.0 build loop which will download the pre-reqs
19) If the build loop crashes or stops (let it run for at least 8+ hours), then you got something funky going on with your system.

Note: may be a good idea to open up another terminal and run "top" to see what's going on while GCC is compiling. Bad practice to run things as as root but this is a live usb. My setup needed the "nomodeset" setting otherwise the GUI doesn't come up.

 

[Ocellaris]

If it takes that many steps for people to run a stability test, they simply won't care about it.