Kdysi bývalo součástí počítačového folkloru, že Windows 95 a 98 vždy zatuhnou, pokud je necháte běžet dostatečně dlouho (mělo by to být po 49,7 dnech). To už se u dnešních OS nestane, ale něco podobného zřejmě postihuje AMD. V jeho procesorech byla nalezena chyba, kvůli které CPU zatuhne po uplynutí určité doby. Trvalo, zdá se, dost dlouho na to přijít, „uptime“ systému totiž musí být hodně dlouhý, aby se selhání spustilo.
Tato chyba se netýká aktuálních procesorů (nebo to alespoň ještě není známo), ale těch s architekturou Zen 2. Přesněji jejich serverové verze, Epycu 7002 „Rome“, který v roce 2019 odstartoval vzestup AMD v této oblasti, když porazil Intel stagnující na 14nm procesu výkonem 64 jader, funkcemi (PCIe 4.0) i energetickou efektivitou 7nm procesu.
Po téměř čtyřech letech na trhu ale AMD publikovalo erratum, podle kterého se za určitých okolností tato CPU kompletně zaseknou, což by bylo dost závažné selhání, ke kterému ale (snad) v praxi nemůže tak snadno dojít.
Podle popisu se chyba projevuje tak, že se procesor není schopen probrat z úsporného stavu CC6, pokud do něj vstoupil. Toto se stane, pokud od spuštění nebo posledního restartu uběhlo víc než 1044 dnů (mohlo by ale ve skutečnosti jít o zhruba 1042 dnů a 12 hodin, což sedí na 54bitovou hodnotu typu signed integer, pokud by udávala čas s 10ns granularitou). Chyba je deterministická a stane se v takovém případě vždy. Nastává ale také vždy až po uplynutí této doby, nejde tedy o případ, kdy se chyba projevuje náhodně.
Erratum, kvůli kterému procesory AMD Epyc 7002 zkolabují po cca 1042 dnech provozu
Podobně jako ve zmíněném případu Windows 98 (a 95 před nimi) jde patrně o situaci, kdy dojde (přeteče) rozsah nějaké proměnné, kterou procesor nebo firmware sledují délku běhu, a řízení CPU v takové chvíli neví, co dělat. Jádra procesoru se dostanou do stavu, kdy neodpovídají na žádná přerušení a s počítačem či serverem se nedá dělat nic jiného než provést restart. Po něm stoupají čítače zase od nuly, takže je opět do příštího selhání hodně času.
Oněch 1042 dnů vychází na zhruba 34 měsíců. Je velmi pravděpodobné, že téměř jakýkoliv server bude kvůli aktualizacím operačního systému nebo jinému servisu odstaven dříve, než dosáhne takového „uptimu“, takže je nepravděpodobné, že tato chyba bude mít větší praktický dosah. Pokud ale někdo provozoval nějaký nonstop systém s Epycem 7002, u kterého by k pravidelným odstávkám nikdy nedocházelo, mohlo by se mu toto vymstít.
Řešení chyby není podle seznamu errata v plánu. Nevíme, zda proto, že není možné provést ji ve firmwaru či kódu AGESA, jelikož je nedostačující proměnná a komponenty reagující na její přetečení někde na úrovni napevno zadrátovaného hardwaru, nebo kvůli nepravděpodobné konstelaci faktorů, které jsou potřebné k jejímu projevení.
Doporučené řešení je místo toho, aby se u systému, který nebude takto dlouho restartován, deaktivovalo uspávání jader do stavu CC6, což může provést i operační systém. Po takovém zásahu je možné pokračovat v běhu, ovšem je samozřejmě třeba, aby někdo dané nastavení změnil (a v prvé řadě věděl, že to musí udělat). Pokud totiž CPU do úsporného stavu nevstoupí, chyba se nevyskytne.
Průšvihy s podobným přetečením proměnné sledující dobu běhu nebo nějakou podobnou veličinu se občas stávají. V tomto případě je to ještě celkem benigní, ale už se stalo, že takto došly proměnné u disků s výsledkem, že úložiště kompletně přestalo fungovat a nešla z něj už vydolovat uložená data.
Více: Pozor, servery HPE měly kazítko v SSD. Kvůli chybě disky přesně po 3 a ¾ roku umřou
Zdroje: TechPowerUp, AMD
