Že by tedy s Threadrippery AMD opravdu zdařile jen vrtělo psem a donutilo Intel vydat nové Extreme i9?

Mam pocit ze zdejsi lidicky nechapou sarkasmus.. i kdyz uznavam, poslednich par let je dost tezke rozeznat kdo neco mysli vazne..

asi ti uniklo ze testy vsech prvnich engineering samplu co se objevily online byly na podtaktovanejch vzorkach.. polaris, ryzen i vega.. jak to asi bude s threadripperem..? staci trosku myslet.. (:

Po tom co několik zdrojů potvrdilo že výtěžnost bezchybných čipů je přes 80% tak nebudou stíhat? Neřekl bych že to bude tím, protože GF má dostatečné výrobní kapacity.

Obávám se, že tohle nemá s ovladači lautr nic společného. Snad možná, doufejme, v designu GCC.

Viz. poslední odstavec.

Očekává se, že AMD dá komunitě vědět jakmile bude řešení nalezeno. Některá dočasná obejití toho problému zahrnují "čachrování" s LLC v BIOSu, někteří uživatelé byli úspěšní jestliže zakázali SMT zatímco jiným ten problém stále přetrvává bez ohledu na vypnuté SMT ve svých Ryzenech 7. K problému dochází na různých verzích GCC, ale nesetkal jsem se s reporty během použití LLVM/Clang, příp. jiných kompilátorů.

Výše jsem dal odkaz na test 8. jádra, jedná se o podvrh.

Když si tam čtu v diskusi ty různé způsoby "řešení" pro různé uživatele, tak z toho mám dojem, že se jedná o standardní linuxové porodní bolesti u nových architektur, kdy to prostě nějaký čas trvá, než se dostatečně stabilizují geek distribuce. Nemyslím prostě, že by šlo o jednu závažnou chybu v hardwaru, ale sadu různých menších problémů v nekonečné kombinaci tunění kernelů, nastavení BIOSů a flagů GCC. Čili problémy budou mít pouze takoví šílenci s Gentoo, jako já. :)

Myslím, že každý, kdo strávil pár hodin procházením "make menuconfig", tak si musí klást otázku, kolik z nekonečného počtu kombinací nastavení vygeneruje kvalitní kernel a kolik polofunkční zmetek.

Prostě chce to počkat, až se poladí GCC, vydají se doporučené kompilační a optimalizační flagy, budou víc prověřené nové kernely a deskám budou ještě párkrát aktualizovány BIOSy.

BTW, GCC je také dost šílený projekt. Gentoo, které jinak rozhodně zpátečnické není, tak teprve nedávno stabilizovalo 5.4 řadu z 4.9. Váš bugreport je o řadě 6.3, která je unstable a to nehovořím o hard masked aktuální 7.1. ;-)

"O tom dost pochybuji, bugy v procesoru maji obvykle vzdy stejne symptomy. Dle toho co ctu na phoronix foru tak jsou symptomy vsude mozne, navic i "reseni" co funguji pro jednoho nefunguji pro druheho - to by u CPU bugu dost tezko nastalo."

Proti tomu lze ale vznést protiargument, že právě zákeřné chyby projevující se pouze v mezních situacích budou spíše mezi těmi, které při testování před uvedením na trh nebudou zachyceny. Viz třeba ten bug v procesoru od AMD nalezený vývojářem DragonBSD. Zdánlivé variace klidně můžou být jen důsledkem neidentičnosti jednotlivých systémů takového charakteru, že to má vliv na onu (zatím nevysvětlenou) chybu. Jinými slovy, dokud se to nevysvětli, samozřejmě, že nám to chování přijde divné. Až se přijde na to, čím to je, začne to dávat smysl.

To ale neznamená, že je to problém zastaralého kompilátoru. Jestli generuje problémovou sekvenci instrukcí, která podle ISA má být platná, ale proces potom nevysvětlitelně padá, určitě z toho nelze vinit kompilátor.