Další hardwarové chyby procesorů. AMD má problém v Ryzenu, Intel u Skylake a Kaby Lake

39

Konkurence v oblasti procesorů se nám v poslední době zahustila, ovšem zdá se, že s větším náporem na inženýry také přicházejí chyby. Ty se v dnešních CPU nedají kvůli komplexitě eliminovat úplně, takže se za problém považují až tehdy, když ovlivní běžného uživatele. Vypadá to, že toto jaro se problémy našly u obou výrobců, u AMD v Ryzenech i u Intelu v architekturách Skylake a Kaby Lake.

 

Potíž s HT u Intelu

Erratum jader Skylake a Kaby Lake je zdá se čerstvě objevené a pravděpodobně se tudíž nebude vyskytovat příliš často, ačkoliv zpráva vývojářů distribuce Debian, která na něj upozornila, je relativně alarmistická. Tento problém, který byl identifikován díky kompilátoru OCaml a jeho vývojářům, postihuje zdá se všechny varianty Skylake, včetně těch pro pracovní stanice a Skylake-SP a Skylake-X, tedy novou highendovou a serverovou platformu. Chyba může za komplexní kombinace okolností v jádře způsobit nestabilitu („nepředvídatelný stav“) procesoru.

Problém nastává, pokud krátká smyčka (údajně musí mít 64 nebo méně instrukcí) použije některý z registrů RAX, RBX, RCX a RDX a zároveň k němu bude přistupovat ještě jako k jeho 16bitové verzi. Pokud se použije 16bitová verze registru, dovoluje architektura přístup individuálně k spodním a horním 8 bitům. Vyšší „MSB“ poloviny se označují AH, BH, CH a DH a právě přístup k nim při současném používání vyšších verzí těchto registrů (do architektonicky vyšších verzí registrů jsou vždy pro kompatibilitu vnořené ty nižší) je zdrojem nestability. Podmínkou ale je ještě, aby byly aktivní obě logická vlákna jádra, takže chybě lze předejít deaktivací HT a nevyskytuje se na procesorech, které HT nemají vůbec.

Popis chyby z dokumentace Intelu
Popis chyby z dokumentace Intelu

Čekejte aktualizace mikrokódu v BIOSech

Deaktivace HT je tedy prvním řešením tohoto problému, ovšem doufejme provizorním. Erratum u Skylake označené SKW144/SKL150/SKX150 a pro Kaby Lake KBL095 (v tabulce je defektů celkem 99, což ale není výjimečné číslo) má sice poznámku „no fix“, to ale znamená jen to, že se neplánuje oprava na úrovni křemíku. Podle Intelu lze chybu zřejmě ošetřit prostřednictvím aktualizace BIOSů (lépe řečeno UEFI) pro jednotlivé desky, pravděpodobně na úrovni mikrokódu CPU. Bohužel nemáme k dispozici jména verzí, ve kterých by chyba měla být opravena, snad se ale výrobci nebudou své zodpovědnosti vyhýbat a v horizontu dejme tomu dvou až tří měsíců potřebný mikrokód začlení. Pro některé procesory Skylake by snad mikrokód už teď měl být distribuován i jako aktualizace prostřednictvím operačního systému Linux, opravu dostal už v dubnu. Zda už je oprava u Intelu dostupná i pro Kaby Lake, není známo.

Snímek čtyřjádrového čipu Skylake
Snímek čtyřjádrového čipu Skylake

V případě, že aktualizace není k mání, se radí vypnout HT, nicméně asi bych se k této možnosti uchyloval jen na serverech a u kritických systémů, nebo pokud se vám problém v nějakém programu skutečně projevuje. Vypnutí HT stojí desítky procent vícevláknového výkonu a proto se asi většině běžných uživatelů nevyplatí, zvlášť pokud je výskyt chyby asi velmi vzácný, a tedy nejde o kritický problém.

SMT bude asi potřebovat opravu i u AMD, kvůli jiné chybě

Zdá se, že shodou okolností má problémy s SMT, tedy během dvou logických vláken na jednom jádře, také AMD v procesorech Ryzen. Tento problém je zdá se častější, jelikož je už od května hlášen uživateli, zatím ale toto erratum asi není oficiálně potvrzené. V tomto případě dochází k nestabilitě vícevláknových kompilačních úloh se softwarem GCC pod Linuxem. Podle všeho chyba nepostihuje operační systém Windows kvůli odlišenému stylu použití randomizace adres paměti (ASLR). Také zde by údajně mělo k chybě docházet „ve spolupráci“ s SMT.

AMD Ryzen
AMD Ryzen

Podle vývojáře DragonFly BSD Matthewa Dillona (viz komentář na Phoronixu) nastává nestabilita (projeví se obvykle hláškou segmentation fault) při aktivitě obou vláken na jednom jádře, když se některé z nich vrací z přerušení instrukcí IRETQ a druhé je zatíženo nějakými výpočty. V této situaci se prý vykonávání IRETQ někdy zasekne až do zastavení zátěže druhého vlákna a jádro je pak zřejmě nestabilní. Potíž je zdá se s návraty na vysoké adresy blízké stacku. To je zřejmě důvod, proč chyba není pozorována na Windows a zřejmě by tedy měla být softwarově „opravitelná“ i v ostatních operačních systémech. Není nicméně jisté, zda je tato diagnóza zcela přesná, AMD zatím přesné příčiny a dosahy chyby nepotvrdilo. Ne všichni uživatelé také problém pozorují, takže není jasné, zda nepřispívají třeba chyby BIOSů nebo špatná nastavení desek (uvažovat by se dalo o BIOSech chybně držících agresivní nastavení i po odstranění přetaktování, což by budilo dojem, že nestabilita přetrvává na výchozích taktech).

Nevíme tedy ještě, zda bude chyba opravitelná prostřednictvím aktualizace mikrokódu. Teoreticky by to mělo být možné, jelikož se projevuje s komplexní instrukcí implementovanou mikrokódem. Tím pádem by měl existovat prostor pro ošetření problematického stavu (například vložením NOPů pro snížení zátěže, či jinak), jelikož na rozdíl od nějakého problému nastávajícího deterministicky přímo ve výpočetním hardwaru (ALU, cache, TLB) se v případě mikrokódu jedná zvnějšku o aktualizovatelný program. Doufejme, že AMD situaci vyjasní pokud možno brzy.

Další hardwarové chyby procesorů. AMD má problém v Ryzenu, Intel u Skylake a Kaby Lake

Ohodnoťte tento článek!

39 KOMENTÁŘE

    • U GPU, zvlášť těch kde má architektura premiéru, bude podobné množství. Akorát že GPU se neprogramujou přímo jako CPU a neběží na nich OS, takže výrobce errata může schovat v ovladačích a nemusí se dokumentovat takhle veřejně.

    • Zvláštní, že nějakého člověka na jednom webu zabanují a za to je k srdci nenávidí i s jejich náklonností k jeho nenáviděné firmě, tak tam leze neustále znovu a znovu, a pak to ventiluje (čti trolluje) na webu jiném 😉

      • Wardo, zajdi za psychiatrem, protože trpíš asi Alzhairmem, když si nedokážeš zapamatovat, že pan Crha, guru IT na diit BAN nedostal, ale přestal tam chodit, protože nemělo cenu hlupákům vysvětlovat. Dělat osvětu mezi AMD funboys nevděčné a zbytečné stejně jako házení hrachu na stěnu, nebo házet perly sviním. Obzvláště pak pokud tomu redaktoři sami svou „nestraností“ nenapomáhají.

        • V tom případě si za ním zajdi sám, protože jsi to tu sám tvrdil, když jsi přilezl na tenhle server prudit a blít.

          Prej pan Crha, guru IT 😀 😀 😀
          Guru, co má mindrák z minulosti, kvůli své vlastní neschopnosti. Guru, co je věčně senilní, maximálně přes výběr náhradních zubů a hledání špíny na kde co a koho. Guru, co si věčně na něco stěžuje a nakonec guru, co tu neustále trolluje.

      • Celkem by mě zajímalo, kolik těch lidí na tom nejmenovaném webu zabanovali. Mně zrušili účet bez jediného varování, bez toho, abych urážel, jen proto, že se „pánubohu“ nelíbilo, že mám pravdu.
        Od té doby jsem omezil návštěvy tak o 95 %. Semtam se podívám, co zase vyplodil, ale přijde mi to čím dál smutnější.

        • na druhou stranu, ne vse na tom webu je špatného. Na mne jsou ty recenze třeba málo podrobne, ale najdou se tam i zajímavější věci. Pokud ale máš potíž čist v každém článku poznámku o tom jak Intel a NV nějak ojebava (ne ze by to třeba nebyla i pravda, ale opakuje se to zbytečného casto), tak to web pro tebe nebude :)),

          • Recenzí není nikdy dost, takže v tomto ohledu je dobře, že ten web existuje.
            Mně by ani snad nevadilo, že se naváží do Intelu nebo do nVidie. Mě tam vytáčí ty desítky vykřičníků a hlavně ta arogance. Kdyby napsal, že podle jeho názoru je tohle a tohle takové a makové, bylo by to naprosto v pohodě. Jenže on ještě dodá, že kdo nemá ten samý názor, je deb*l.

          • Jak rika kamarad..“Nezrobis nic“ :)) Hold ten web takovy je.
            Vis jak, chytry si i na takovem webu najde neco, co je treba zajimave. I na PCT v Obrmajerove recenzi se daji najit dobre kousky..byt je tam zase jiny hnuj.. 🙂

    • Nepsali o tom už dřív? Ta chyba v Zenu je známá už pár týdnů, takže je to spíš tak, že o ní píšeme dost pozdě (to je moje vina, trošku jsem se spoléhal, že se během pár dnů k tomu ještě něco dalšího ukáže/vyjasní, případně že už bude třeba přislíbená oprava, a pak do toho přišly další věci…)

        • Radek Holeček: Spousty lidí zabanovali, mě by spíš zajímalo kde skončil BTJ, že se neukáže ani tady je celkem divné.
          tombomino: Nebuď si tak jistý, ty jsi taky na diit a PCT provařená červená karkulka, i s červenými brýlemi a včetně ponožek a trenclí.
          KRoman47: Diskuze je veřejná, takže pokud tě můj příspěvek nezajímá, tak jej přeskoč a nečti ho. Nikdo tě nenutí si jej číst.
          Jan Olšan: No vidíš, ani to nedalo moc práce být nestraný a uvést obě dvě firmy v jednu chvíli se podobnými problémy. Na zmíněném webu máš třeba : „AMD Vega bude mít asi možná super cenu, sice nevíme jakou ale bude určitě dobrá“ pak “ fuj intel je rozbitej“ pak „AMD Vega bude mít velký výkon“ pak „nVidie zase něco pokakala“ pak „AMD EPYC je epický“
          …. jak pravil Radek Holeček, opravdu se z diit stává smutný prázdný web typu DD a jak by pravil BTJ: “ nikoho nezajímá že vyšla nějaká 0,5451tá verze nějaké linuxové distribuce“, kterou používají dva lidi na celé planetě (ano první je autor a druhý je Ježek).
          Souček: Oni jen překládají a když něco píšou tak jsou to jen doměnky.

          • Crha, ty jsi fakt komik trubka, ktery nestoji ani za ten komentar… Fascinuje mne, jak nekoho nazyvas cervenou karkulkou, pritom ja mam doma vic Intel HW nez ty si nastradal za cely svuj saskovsky zivot…

          • Tak na druhou stranu, ono není moc o čem psát. Recenzování je drahé (i když budou komponenty zdarma, tak je drahé na čas), překládání novinek dělá kde kdo, takže v čem být originální?

          • kromě Crhofilů, budu reagovat jen na ty, kteří si s Crhem nepřeměřují pindíka, protože na to nemají, ani finančně, ani rozumově.
            Radek Holeček: Překládání jim nevyčítám, ale i na PCT občas přidají vlastní nějaké měření. Ono když ti pošlou komponenty, ty si je vyzkoušíš ano je to drahé, ale když už ti je pošlou? Řada lidí se pohybuje v IT dost lidí dělá ve firmách kde se furt něco kupuje. Proč si tedy Ježek neudělá nějakej test RX480 pod linuxem? Proč když je to tak vysoko odborný web zabývající se fotomateriály si neudělají testy obrazovek, u kterých by opravdu měřili latence černá bílá a pod. Vem si že PCT uveřejňuje výsledky testů zdrojů, našli si prostě svůj specifickej sortiment a jedou v tom i když škemrají peníze, není to problém. Proč by se tedy diit nemohlo soustředit na obrazovky když teda se tak moc modlí k 10bitovým barvám? Neudělají to, radši budou dál razit že AMD je skvělé a intel je fuj.

    • Kdyz by jsi Crho nebyl jenom komik, tak by jsi vedel, ze ten problem s Intelovskym HT prave koluje i po jinych webech v nekolika jazycich a jinch kontinentech. Jenomze to by jsi musel delat i neco jineho nez tupe trolovat a ventilovat neustale svoje mindraky.

    • Pro Skylake v dubnu, ale to je vydání toho mikrokódu, pak záleží na dsitribuci. V Linuxu může být v repozitářích jako balíček, ale na jiném OS může být nutné čekat na dostupnost přes BIOS desky, což trvá déle, protože nové BIOSy se taky musí testovat/validovat.

  1. Kam se microcode ukládá? Do nějaké tomu určené pamětí v CPU nebo čipsetu v CPU nebo čipsetu na základce? Jak se nahrává? Tedy je stálé potom někde uložen?
    Jak to funguje při aktualizaci biosu? To se při aktualizaci biosu microcode nahraje do CPU? Tedy když bych potom vyměnil CPU za jiný tak bych musel znova flašovat bios jen kvůli CPUčku?

    • Neukládá se, není tam pro něj nevolatilní úložiště. Tudíž se musí nahrávat při každém bootu. funguje to tak, že ho při nabíhání do CPU nahraje deska ze svého BIOSu, kde má tu binárku uloženou. CPU při tom samozřejmě kontroluje podpis/hash a binárka je i zašifrovaná, obsah je dost přísně střeženej.

      Možnost nahrát tu aktualizaci má taky jádro operačního systému, takže to je druhá možnost. Opět je to nevolatilní a přetrvá to jen do vypnutí. Čili to CPU se aktualizací fyzicky nijak neovlivňuje, samo o sobě má jenom svojí starou verzi, co je napevno vypálená z výroby. Když ho přendáte do neaktualizové desky, bude se chyba zase ukazovat.
      Proto je sranda, když free software aktivisti jako Libreboot v rámci boje proti „blobům“ chcou u desek nahrávání mikrokódu deaktivovat . Nechcou mít „blob“ (i když je to blbost, ten program už je v CPU z výroby, jen starší verze), ale to, že dnešní CPU bez té aktualizace většinou korektně nefungují, to zdá se až tolik nevadí. Dneska hodně produkčního křemíku na nahrávání aktualizace mikrokódu vyloženě spoléhá, jinak mají hromadu errata navíc (a někdy asi i celkem závažných).