zMeul
-
Posts
11,194 -
Joined
.thumb.gif.4ccdf0bb8e9c773fd62b0b5e1a1a8249.gif)
.thumb.jpg.575c76559dc7afa52399966ffa8132a9.jpg)
zMeul's Achievements
-
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 -
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
-
do you buy your computers at the grocery store? good luck to you if you do
-
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/
-
have you actually bothered to read the source? I'm done replying to this BS
-
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
-
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
-
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
-
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
-
it was discovered with EPYC and ThreadRipper
-
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: 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 1/2 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 ... new PSU is fucked that old PSU also fucked something else, probably mobo
.png)
