Ryzen Hardware Defect

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

>>61732793
https://arstechnica.com/information-technology/2017/06/skylake-kaby-lake-chips-have-a-crash-bug-with-hyperthreading-enabled/

>>61732769
>hardware defect
This can be patched with microcode update. It's also been known for awhile now.

>>61732769
>IT'S TRUE
BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

BAAAAAAAAAAAAHAHAHAHAHA

File: ohwelles.jpg (89KB, 500x617px) Image search: [Google]

89KB, 500x617px

>the dilapidated shanty town of AMD

File: images(34).jpg (8KB, 228x221px) Image search: [Google]

8KB, 228x221px

>>61732769
HOLY SHIT
There goes the enterprise market

>>61732839
>critical bug
>known for a while
>still not fixed

AYYYMD SHILLS IN FULL DAMAGE CONTROL

http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run

>>61732769
>it's over
AyyMD BTFO!!

>>61732769
pleb this is easy to fix. all you need to do is neck yourself.

File: Capture.png (288KB, 916x721px) Image search: [Google]

288KB, 916x721px

>>61732769
>>61732793
>>61732863
>>61732879
>>61732888
>>61732889
>>61732895

File: images(8).jpg (10KB, 300x168px) Image search: [Google]

10KB, 300x168px

>>61732839
Just Wait© for that Fine wine®

>>61732769
DELET THIS RIGHT NOW SIT

>>61732769
>>61732793
>>61732863
>>61732879
>>61732888
>>61732889
>>61732895
>>61732916
t. beaweasome

>>61732769
>being this much of a shill
It's pretty rare and only happens to a few people running gcc on Linux.
In fact it's so rare no one is sure how widespread it is and people go through this whole song and dance just to test it: https://www.reddit.com/r/Amd/comments/6qyz83/threadripper_early_adopters_and_ryzen_gamers_can/dl1rtg4/

>>61732913
>only affects ocaml
this is the whole Linux stack, turbonigger

I BLAME THE JEWS!!!

Looks like FreeBSD and DragonflyBSD developers have debugged and fixed it in their kernels: https://svnweb.freebsd.org/base?view...evision=321899

It'll mostly affect hpc, don't imagine enterprise will be affected too much

File: 1490629541892.png (122KB, 416x436px) Image search: [Google]

122KB, 416x436px

>>61732941
The Intel bug affected anything with the particular instruction series, the Ocaml guys were just first to hit it.
The Ryzen bug is extremely rare and only happens in specific circumstances.
Which you would know if you weren't a dumb shill.

>>61732961
>no asmr

>>61732941
And yet the fix is the exact same.
A micro code update.

>>61732984
no you stupid shit, you're wrong its
caused by ocaml and it's "extra constraints" on the GCC compiler

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

though funny enough i sent my 1800x in for warranty replacement. it died after four months of running at purely STOCK settings. never touched the voltage or any cpu settings. all 100% stock. only thing I touched was ram where i set my kit to 2933mhz cas 14. out of know where started to get total system freezes. thought it was the ram, but then shortly after the freezes it turned into complete out of know where reboots. all of this happened in a span of two days. first day where freezes, second day was reboots. windows caught the reboots and reordered them in event viewer. under system i had critcial whea-errors. all where "cpu - cache hierarchy faults on acpi core 0 & core 15."

from everything i googled it all pointed to one thing, faulty cache on those processor cores. amd accepted my rma request without hesitation so i guess even they admitted cache hierarchy faults are bad. always kept my motherboard (crosshair) up to date with the latest greatest bios that overclock.net said was safe to use. at the time of explosion i was on 1403 for almost a month without hiccup.

pretty bummed out. took a week to ship my 1800x to them. they didn't get it until today. cali - fl on fedex standard shipping is slow as hell. figured amd probably won't ship me my new one until some time later next week. i'll probably won't get my new one until the end of august.

>>61732988
Which Intel already issued? lel

>>61733057
sucks dude, my assrock Mobo died and took my 6600k with it, Intel had me another in 2 days

I run mine overclocked and have all 16 threads at 90s to 100 at times and so far no issue. And with noctura d15 i do it at 50c max

>>61733106
>Install Gentoo
>get segfaults

>>61733148
>Implying anyone has actually ever installed Gentoo.

>>61733053
Are you retarded? The bug was triggered by certain loops using certain registers under some conditions. It's machine code thing, nothing to do with Ocaml nor GCC past the obvious correlation.

>>61733101
yeah i've read that a lot when i was looking into rmaing a processor. saw a lot of posts from intel users talking about how intel shipped them off a replacement before intel even received the original from the user.

i was hoping amd would have done the same. but at least amd paid for my fedex shipping. i don't mind if it takes a bit as long as they send me a new one without issues. i would imagine it would be a faster turnout if i didn't leave 3,000 miles away from their warranty center. which apparently is in Miami, FL.

>>61733184
man i can't spell for shit today

>turnout
turnaround
>leave
live

>>61733177
it clearly stated ocamls "extra constraints" on the GCC compiler.

File: Patrick Bateman, Check my dubs.jpg (9KB, 184x184px) Image search: [Google]

9KB, 184x184px

>>61733169
I have. Also, check these dubs.

>>61733184
...I did have to pay $20 and they charged my cc $160 so it would have been about the same time as yours if I did the "free" way

>>61733169
plenty of people compile their own software tho.

>>61733148
it's annoying as fuck. I had to compile gcc and some other big programs with MAKEOPTS="-j1". T-thanks AMD
Had to emerge --resume like 4 times

>>61733293
u use sysd? or virt-manager?

AYYMD IS FINISHED & BANKRUPT

AYYMDPOORFAGS CONFIRMED ON SUICIDE WATCH

File: Untitled.png (90KB, 381x362px) Image search: [Google]

90KB, 381x362px

Cool.

I'm sorry /g/, I failed you. I really tried to stop it, but there are too many shitters.

>>61733266
ooo, ok. yeah amd didn't give me an option to do that, but at the same time i didn't ask.

though did you do a rma with asrock? curious to know how well their warranty service is.

>>61732938
You should've noticed all the positive AMD talk by now. This is Intel shills desperately blowing up some news story which isn't going to be relevant after they fix it. They need every ounce of firepower they can get. It's funny seeing the over reaction and all caps desu senpai.

>>61733361
absolute shit. I now have an EVGA board I love.

>>61733325
systemd? I use it on my Arch Thinkpad and I've also tested Gentoo with it but I prefer OpenRC on Gentoo. I don't currently use any VMs although KVM/Qemu is really noice on Gentoo

>>61733368
Intel already issued the microcode B4 the ocaml fags realized it. Where's amds fix?

>>61733389
just curious as virt manager depends on sysd, and I'm too stupid for cli only virt stuff. I saw some Jap using it with open rc so who knows.

>>61733398
Wait for it

File: 1501532754415.jpg (204KB, 900x973px) Image search: [Google]

204KB, 900x973px

>>61732769

DELETE THIS YOU FUCKING ANTI-COMPETITIVE BRIBER FAGGOT

>>61733382
can't say i'm surprised. i would love an evga board solely for their warranty service. wish they made amd boards. also wish they made amd gpu's as well.

>>61733449
God yes I've lurked on the website hoping to see amd stuff, but it won't happen I'm afraid. The Mobo just feels more solid in your hand, and the components are top notch. Maybe it's a one off, but I gave them a chance and assrock burned me. Feel sorry for the Taichi fags in a year. I don't trust any of the big three after reading hundreds of reviews, I'll buy a supermicro or tyan EPYC board or something when the time comes.

>>61732769
>it’s difficult to reproduce the segmentation faults due to the low probability and the uncleared reproducibility conditions
Literally a non-issue. Kill yourself beawesome, you brazillian monkey.

>>61732839
AMD supposedly haven't been able to reproduce the bug internally.

File: 1478978326615.jpg (893KB, 1520x2688px) Image search: [Google]

893KB, 1520x2688px

>>61733357
v has officially taken ogre /g/

Remainder that both intel and amd hardware is backdoored.
https://libreboot.org/faq.html#amd
https://libreboot.org/faq.html#intel

>>61733537
>constant segfaults while compiling programs
>doesn't matter, muh games werk xD
bet you have never even installed Gentoo, filthy pleb

>>61733223
Full quote from https://lists.debian.org/debian-devel/2017/06/msg00308.html
>There were extra constraints
>being placed on gcc by OCaml, which would explain why gcc apparently
>rarely generates this pattern.

That's just an explanation of specific circumstances in this particular case. Any compiler can generate the code, it depends on how you configure it.

The Apple Macbook Pro with Retina Display doesn't have this problem.

>>61733766
>it’s difficult to reproduce the segmentation faults due to the low probability and the uncleared reproducibility conditions
>due to the low probability
>uncleared reproducibility
Still a non-issue, shill.

>>61733806
Well since it's a non-issue, don't expect a patch from amd

>>61733802
of course, it is powered by Intel® Core i5 processor :^)

>>61733398
That's because the Ryzen bug is very hard to reproduce. The site in OP literally says "Let’s compile repeatedly until it will fail." which should give you an idea of the kind of guessing game this is.

The Intel bug was more straightforward since it's a specific pattern which was reliably generated when compiling Ocaml compiler on GCC with certain settings.

>>61733802
They throttle like crazy, though :^)

>>61733806
You're assuming it only affects a very small amount of chips. That's not true. This has only been kept relatively under radar because it mostly rears its ugly head while under heavy compiling load. If it happened while gaming AMD stock would plummet and internet would be aflame. There just isn't that many Linux users, and not many of them compile all the time. For those of us that do compile a lot, this bug is common and it might become a big problem for AMD if they can't fix it quickly

>>61733878
>implying
It actually seems to be limited to gcc. For some reason it seems to trigger for some people while others never experience it.
Have you ever seen it happen with LLVM/clang or the Microsoft compiler on Windows?

>>61732769
>only on linux
kek, you cares

>>61734248
>>>/v/

>>61732769
>github.io
>.io
I ain't click this shit faggot

>>61733602
Who is that sexy fuck?

>>61735091
go back to lereddit

>>61732769
>2017/06/23
>/06/
how much damage control layers are you on right now, op?

File: 1487789493624.jpg (156KB, 633x758px) Image search: [Google]

156KB, 633x758px

>>61732769

File: 1481227499750.png (437KB, 541x538px) Image search: [Google]

437KB, 541x538px

>>61736117

>>61735831
back to r/amd pajeet

>>61732769
>Linux-specific
Wew, Intel shills are so very deseperate. They went from shitting on the socket screws (the ones that UP build quality) to this.

>>61732888
>There goes the enterprise market
Patched upstream in a week, enterprise runs FreeBSD anyways.

>>61733057
Should've been caught in binning. Shame they didn't let you keep it while a new one shipped, you probably could've disabled the core.

>>61732951
fuckin jews

File: image-10.jpg (55KB, 628x537px) Image search: [Google]

55KB, 628x537px

>>61736178
TR4 has 4094

>>61733398
isnt microcode that shitty thing that has to be reloaded after every reboot

>>61732769
>ALL RYZEN CPUS HAVE A HARDWARE DEFECT CAUSING SEGFAULTS UNDER HEAVY WORKLOADS
i've been having this problem on Linux