Zdroj: Cnews.cz
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 01
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 03
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 05
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 04
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 02
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 06
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 07
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 08
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 10
Prezentace architektury procesoru Intel Ice Lake neboli Sunny Cove 09
Po vydání MacBooků s 10nm procesory Intel Ice Lake se začaly objevovat hlášení o pádech aplikací nebo celého systému, za nimiž možná stojí chyba v CPU.
Vypadá to, že Intel bude mít možná na krku další chybu v procesoru. Tentokrát nicméně nemluvíme o bezpečnostních zranitelnostech ze skupiny spekulativních či „timing“ útoků, které jsou spíše výsledkem architektury, nenavržené s ohledem na izolaci proti nim. Nejde o skutečné „bugy“ v logice čipu.
Taková logická chyba byla ale možná nyní nalezena v procesorech Ice Lake, kde má způsobovat pády programu nebo celého počítače/systému při běhu (naštěstí relativně nepočetných aplikací.
Pády a restarty MacBooků ve vývojářských prostředích
Potenciální hardwarový problém v procesorech Ice Lake se vynořil ve vývojářském prostředí IntelliJ IDEA 2020.1 používajícím Javu. To je mimochodem produktem v ČR sídlící a původně založené firmy JetBrains s. r.o. (dříve IntelliJ Software s. r.o.). Kromě samotného IDEA 2020 snad stejné problémy má i PHPStorm a PyCharm, což jsou zase IDE pro PHP a Python od stejné firmy. Problém hlásí uživatelé notebooků Apple s těmito procesory, nicméně po nějaké době se ukázalo, že chyba zřejmě nemusí být v MacOS.
Program IntelliJ IDEA s tímto procesorem, buď sám spadne, což se může stát, i když pracuje na pozadí bez interakce uživatele, zejména při indexování projektu. V některých případech ale chyba vezme sebou celý operační systém a notebook se sám restartuje, což indikuje hlubší problém mimo samotnou uživatelskou aplikaci.
Později byla chyba nahlášená i při běhu v Linuxu, virtualizovaném v Parallels nad MacOS, kdy chyba postihnuvší aplikací v hostovaném systému způsobila i skrz hypervizor pád a restart celého počítače, což by nemělo při virtualizaci nastat. Jde i o potenciální problém architektury, který by v serveru byl bezpečnostní zranitelností (možnost DoS útoku).
Indikátor pro to, že jde možná o průšvih procesoru samotného, by mohlo být, že se zřejmě chyba objevila i na Windows a zařízení Surface Pro od Microsoftu, které má také procesor Ice Lake (ovšem tam jde zatím jen o jedno hlášení, což může být i omyl).
Včera se už také ve vláknu k této chybě přihlásil zaměstnanec Intelu a potvrdil, že chyba v IntelliJ IDEA už je společností analyzována. Zatím ovšem bez toho, zda se už podařilo příčinu izolovat a ví se, jestli spočívá v chybě procesoru nebo platformy.
Hardwarová příčina ještě není plně potvrzená
Nemusí jít nutně o chybu v jádru CPU nebo podobný závažný problém architektury. Poměrně časté bývají různé problémy a omezení v integrovaných GPU, přičemž v případě Ice Lake se ví o některých slabých místech v iGPU, které dokážou systém sesypat.
Takové problémy pak normálně ošetří ovladač GPU a pro koncového uživatele po jejich obejití hardware bude fungovat bezproblémově. Je možné, že IDEA/Java ve skutečnosti naráží na podobný bug v integrovaném GPU, ne v CPU. Stejně tak může Intel mít chybu třeba jen ve firmwaru či mikrokódu.
Chyba bude pravděpodobně opravena aktualizací mikrokódu (pokud to nebude jen na opravu BIOSů/ovladačů). V posledních letech se podobná errata daří tímto způsobem obvykle řešit bez toho, aby byla CPU výrazně zpomalená, takže uživatelé Ice Lake asi nemají důvod panikařit. Viz například problém Ryzenů 1000 projevující se při extrémní zátěži instrukcemi FMA, který byl opraven až po vydání, nebo podobnou chybu ve Skylake na začátku roku 2016.
Zatím bych tedy čekal, že případné erratum v Ice Lake bude podobné a jeho oprava nebude vyžadovat snížení výkonu (natož třeba stahování CPU z trhu). V tuto chvíli ovšem není jasné, jak dlouho bude trvat, než Intel opravu vyvine a dostane do distribuce. Po samotném nalezení totiž asi patch bude ještě třeba nějaký čas testovat, takže by se na opravu mohlo čekat třeba i měsíc až tři.
Galerie: CPU architektura Sunny Cove v procesorech Intel Ice Lake
Zdroj: JetBrains, Via: Longhorn (Twitter)
Stahovani CPU z trhu me pobavilo 🙂 Fakt si nedokazu predstavit co by tam muselo byt aby to Intel stahnul, protoze i fatalni chyby v Atomech kdy proste procesor umre treba v Synology zustavaji dal, je ale otazka, jak moc to je vina Synology nebo Intelu, kdo rozhodnuti nechat to bejt a tesit tim uzivatele ucinil.
Já bych počkal dokud neotestují, že jde opravdu o chybu procesoru, pak můžeme soudit. Ale je fakt, že na Intel to dens docela pasuje a je samozřejmě první, na koho se ukáže prstem.
Ja myslim, ze prvni na koho se ukazuje je spolecnost produkujici SW (v tomto pripade aplikace / framework) 😉
A že by tohle mohla být pravda o tom HW problému. Lidé pod tlakem dělají chyby. V Intelu je ten tak je nyní obrovský.
Errata jako tohle se objevují pořád. Nejde to brát tak, že když se provalí bug, je to známka toho, že je něco ve firmě špatně.
Dnešní CPU jich při vydání mají přes 100, většina se jich neopraví, ale naštěstí jsou velmi, velmi vzácné (čímž se myslí, že nastanou za komplikovaných okolností). Pokud to fakt shazuje programy nebo OS/počítač, tak se v mikrokódu nebo BIOSu udělá workaround.
Tohle pravděpodobně nebude žádný zásadní problém. V posledních letech se akorát častěji na problémy, které vedou k pádům, přijde až po vydání, ale to může být prostě tím, že jsou ta jádra mnohem mnohem komplexnější a prostě se nedá všechno nasimulovat a podchytit testy před vydáním. Samozřejmě, selhání při testování se taky můžou stát (to byl asi případ toho RdRandu u AMD Ryzenů 3000)..
Tak to nebudu souhlasit. To že jim to uniklo ven a dopad je v tom, že se se sesype počítač je jasným dokladem, že je něco špatně. Vždy se něco testuje opravdu seriózně tak existuje to čemu se říká exit kritéria. To znamená třeba, že produkt bude ok když tam bude do 100 chyb s nízkým dopadem. Jestliže padne počítač tak to je pro men minimálně střední závažnost ne-li vysoká závažnost. Prostě si odmítám připustit, že Intel vědomě pustil tuhle chybu ven.
Takové chyby by podle mého názoru neměli projít do výroby chipů. Tohle zřejmě nezachytili práve proto, že jsou pod talkem a zkracují délku testování. Pro mne to je další zbytečné hazardování s kdysi tak skvělou pověstí Intelu.
Co je to chyba, co sposobuje pad aplikacie/pocitaca? Pre akukolvek (deterministicku) chybu mozem napisat kod, co ju zdetekuje a v pripade, ze tam je, sposobi pad. A ak sa taky kod dostane potom do povedzme novej dynamickej kniznice systemu, odrazu pada skoro vsetko. Takto to fakt definovat nejde. V skutocnosti jedine naozaj blbe chyby su, co sa nedaju patchnut na ziadnej sw urovni.
Teorie ako „by sa nieco malo zdetekovat“ su blaboly. V praxi 100% vylucit chyby nejde ani u radovo jednoduchsich veci.