zMeul

16 hours ago, Nyarurin said:

But there is no message that drivers were restored (like as usually when drivers crash). And there is no stutter on the recording via shadowplay. Doesn't it contradicts this theory?

you can check the event viewer to be absolutely sure it's not a TDR event

one other thing you could do is to use TDR Manipulator to disable TDRs completely and see how the system behaves

https://www.wagnardsoft.com/forums/viewtopic.php?f=8&t=755&sid=c5c9b005d50ad2f18b819597eaf73de9

you can set up temp alarms within BIOS - depends on the mobo

12 minutes ago, leadeater said:

@zMeul Instead of marking my post funny you could actually try an answer my very simple question.

I find your post funny because you actually say the source, the developers who discovered and reported the issue, are wrong - if that was supposed to be a joke, it's quite funny

if it's not a joke ... well then, go in peace

2 minutes ago, dexT said:

Do they carry Ryzen at K-Mart? Perhaps you could test this IRL.

do you buy your computers at the grocery store? good luck to you if you do

20 minutes ago, Haaselh0ff said:

How long was AMD Ryzen rumored and in production for? Did they just throw something together in 2 months like Intel did in response to AMD?

sure mate, CPU manufacturers can develop new products in 1-2 months .... what parallel dimension are you from?

oh look, Skylake-X and KabyLake-X were talked about since at least 2016 .. https://benchlife.info/intel-study-skylake-x-kaby-lake-x-and-basin-falls-for-skylake-w-06022016/

3 minutes ago, leadeater said:

Yes that is what your quote is talking about, do you even read the stuff you post at all?

 

SMT...

have you actually bothered to read the source?

I'm done replying to this BS

1 minute ago, Haaselh0ff said:

This sounds incredibly arrogant and @BuckGup's response seems entirely fair. Criticizing people for supporting a new platform is not the way to go about this. Having concern over whether this is a major bug or if it can even be fixed with a simple update is reason for concern but no reason to bash buyers.

if putting other people's money into a defective platform is a thing for you, go ahead

I worked in the business for some time and I would not shove down a customer's throat a brand new uncertified product

2 minutes ago, leadeater said:

Yes I know that that's what I'm commenting on, this issue.

 

How? This IS a bug with SMT so how can it exist if it's turned off. Your source seems to be linking two issues as one.

no they aren't

I'm removing the phoronix link since it seems to create confusion - I only linked it in the 1st place to give them credit for the BSD discovery

2 minutes ago, ravenshrike said:

No, the people saying that are noting configuration segmentation faults are common across many processors. To wit from post #37

 

Also, I love how you managed to quote the completely wrong portion in your original post.

good god! I should not included the phoronix link since you people can't get it straight

Phoronix was not the original discoverer of the seg fault issue - it was discovered back in May by people compiling the Linux Kernel with GCC

24 minutes ago, leadeater said:

How is this happening when SMT is disabled when the issue been described is with SMT itself? The other mention of system stability seems to be a different problem.

 

This seems like a good explanation to the cause of some of the issues:

https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads/page7

Sounds like GCC needs some Ryzen optimizations and a lot of software recompiled and update versions pushed out.

 

Also there's an update to the Segfaults issue that points to potential improper testing.

 https://www.phoronix.com/scan.php?page=article&item=ryzen-segv-continues&num=1

wait a second or two

the original seg fault is a different issue that what the BSD team discovered

and the original seg fault issue is independent of SMT being disabled or not! new BIOSes have introduced a new option: OPcache control

but even with disabling OPcache it still seems to occur: https://community.amd.com/thread/215773

the original seg fault was not discovered running Phoronix's test suite but compiling Linux kernel with GCC

please get your ducks in a row

3 minutes ago, nerdslayer1 said:

not only ryzen

it was discovered with EPYC and ThreadRipper 

7 minutes ago, BuckGup said:

Yes zMuel because you are always right we should only listen to you....

you deny these issues exists?

no one has to listen to anything I "say", look at the sources I provide

the segmentation fault is 3 months old and AMD has yet to deal with it in one way or another

while at the same time they push server and workstation grade products that seem to be affected by the same issues the original desktop parts are - businesses will be thrilled that their new stations have unresolved HW issues

source: https://svnweb.freebsd.org/base?view=revision&revision=321899

4 days ago the developers of FreeBSD have issued a report for a new issue they encountered with Ryzen CPUs:

Quote

Hi, Matt Dillon here. Yes, I did find what I believe to be a  hardware issue with Ryzen related to concurrent operations. In a nutshell, for any given hyperthread pair, if one hyperthread is in a cpu-bound loop of any kind (can be in user mode), and the other hyperthread is returning from an interrupt via IRETQ, the hyperthread issuing the IRETQ can stall indefinitely until the other hyperthread with the cpu-bound loop pauses (aka HLT until next interrupt). After this situation occurs, the system appears to destabilize. The situation does not occur if the cpu-bound loop is on a different core than the core doing the IRETQ. The %rip the IRETQ returns to (e.g. userland %rip address) matters a *LOT*. The problem occurs more often with high %rip addresses such as near the top of the user stack, which is where DragonFly's signal trampoline traditionally resides. So a user program taking a signal on one thread while another thread is cpu-bound can cause this behavior. Changing the location of the signal trampoline makes it more difficult to reproduce the problem. I have not been because the able to completely mitigate it. When a cpu-thread stalls in this manner it appears to stall INSIDE the microcode for IRETQ. It doesn't make it to the return pc, and the cpu thread cannot take any IPIs or other hardware interrupts while in this state.

the issue described has been observed on FreeBSD systems with SMT disabled

---

remember when me and others told "you" to stay away from Zen CPUs for at least ¹/₂ y? this is precisely why - AMD is dealing with new arch that is bound to have HW issues and some of them cannot be fixed with a micro-code update

on top of the segmentation fault, we now have this ... if this turns into a recall, AMD will be severely hit and not only financially

good job AMD for fixing your shit ^/s

Epyc CPUs confirmed to suffer from seg faults: 

as far as I know ThreadRipper uses Epyc cores, so .. TR seg faults too

---

from what I'm seeing, seems like AMD won't be fixing this via a microcode update and will need a HW stepping

recall!??!

it's a TDR event - Windows is resetting the video drivers

and since you said the previous PSU died ...

1. new PSU is fucked
2. that old PSU also fucked something else, probably mobo

120Hz at 1440p? GTX1080 at least

someone made a commercial product - it's as bad as expected

if it's not under the board it won't be a problem

but if it's under the board and makes contact where it shouldn't, there will be problems .. grave ones

why not cleaning it mounted?!

1 minute ago, Damascus said:

Oops, still counts.  Puget ran the titan on 2.0 X8 with no issues.

mate, again ... his bottom slot is a 4x gen 2 that equals a 2x gen 3

for god's sake

9 minutes ago, Damascus said:

Pcie x4 gen 3 = x16 gen 2

mate, wtf are you talking about?!

4x gen 3 is about 4GB/s in each direction

that equals a 8x gen 2 that's also 4GB/s each direction

while a 16x gen 2 is 8GB/s in each direction

get your facts straight

9 minutes ago, Damascus said:

Lol not really.

https://www.pugetsystems.com/labs/articles/Impact-of-PCI-E-Speed-on-Gaming-Performance-518/

yeah really

you fail to take into account that the 4x PCie gen 2 is about as a 2x gen 3; while your graphs only go 8x gen 2

@AuraDesru you should keep it in the top slot

but you can also test the differences for yourself

8 minutes ago, Damascus said:

Its physically x16 but it has x4 speeds.  Works fine, no performance degredation.

it will have some degradation

it's a 4x slot at PCIe gen 2 - that's a 2x at gen 3 

sound cards never went away

still rocking a X-Fi Fatality on PCI; with replaced caps

on-board RealTek are utter shit

Just now, porina said:

They only say some capture methods are no longer supported, but they also list many that still are. It doesn't stop you from capture/streaming if you are willing to use those methods that remain supported. If they wanted to block streaming there are alternate paths that may be more effective.

no there aren't alternate paths

even if they employ DHCP encryption, there will still be ways to bypass it

they are blocking the most common tools available to the "average joes"