Další hardwarové chyby procesorů. AMD má problém v Ryzenu, Intel u 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

Č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

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

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.