EGY BUG MIATT A MÁSODIK GENERÁCIÓS EPYC PROCESSZOROK SZABADSÁGRA MENNEK 34 HÓNAPNYI FOLYAMATOS MUNKA UTÁN

A hiba miatt ezek a szerverek biztosan nem indulhatnak a leghosszabb ideje folyamatosan működő konfigurációknak járó előkelő címért.
Víg Ferenc (J.o.k.e.r)
Víg Ferenc (J.o.k.e.r)
2023. jún. 6. 10:39
Egy bug miatt a második generációs EPYC processzorok szabadságra mennek 34 hónapnyi folyamatos munka után

Az AMD második generációs EPYC szerverprocesszorai, amelyek a ROME generációt erősítik és a 7002-es sorozatba tartoznak, egy meglehetősen érdekes bugot tartalmaznak, ami miatt a processzorok egyik magja egy idő után egyszerűen nem lép ki a CC6-os alvó állapotból, amin csak egy újraindítás segíthet. Az AMD illetékesei elismerték, a bug valóban létezik, ám javítása nem várható, de hogy pontosan miért, azt nem árulták el.

Hogy miről is van szó? Az AMD EPYC Rome sorozatú processzorok a gyártó állítása szerint 1044 napnyi folyamatos üzem után produkálják a fentebb említett hibát, amelynek eredményeként egy mag nem tér vissza az alvó állapotból (CC6). A 2,93 évnyi folyamatos üzem után jelentkező hiba az egyik redditező szerint igazából nem is 1044 nap, hanem 1042 nap és 12 óra, ugyanis a tényleges értéket a processzor a REFCLK alapján számítja a rendszer, ami 10 ns-os lépésközökkel dolgozik, ezeket egy 54-bites aláírt integerben tárolja, ami 1042,4999 nap után éri el a túlcsordulás állapotát, lényegében ez okozza a problémát. A processzormag zombivá válik, semmilyen parancsot vagy külső megszakítási kérelmet nem fogad, és ha nem történik újraindítás, akkor ebben az állapotban is marad. Ez a hiba természetesen a teljes processzor érinti, így eléggé kellemetlen dologról van szó. Az AMD szerint a pontos időpontot egyébként a Spread Spectrum és a REFCLK értéke adja meg – utóbbi alapján számítja az időt a CPU.

Galéria megnyitása

Az AMD nem tervezi a hiba javítását, mindössze néhány tanáccsal látta el az érintetteket. Egyrészt azt javasolják, hogy az AMD EPYC Rome processzorral szerelt szervereket még az 1044 napos „időzítő” lejárta előtt indítsák újra, vagy egyszerűen kapcsolják ki a CC6-os alvó állapot támogatását – mindkettő megszünteti a hibajelenséget. Azt nem árulták el, konkrétan miért nem készítenek javítást a hibára, ám könnyen lehet, hogy nem lehet költséghatékonyan javítani, illetve az is előfordulhat, egyszerűen nem tartják akkora problémának, amivel mindenképpen foglalkozni kell.

Az efféle hibák egyébként nem ritkák a processzorok szegmensében, sokszor a kereskedelmi forgalomba kerülő modellek is bőven tartalmaznak hibákat, ám ezeket utólag vagy új revízióval, vagy szoftveres és firmware alapú javításokkal próbálják foltozni. Érdekes példa erre az Intel 8. generációs Core sorozata, amelynek tagjai még mindig 150-nél is több hibával rendelkeznek, pedig azok a processzorok még 2017 folyamán jelentek meg. Az nem világos, hogy a Rome sorozatú EPYC szerverprocesszoroknál pontosan mennyi hibát kellett összesen javítani, ugyanis az AMD a már javított hibák bejegyzéseit törölni szokta, most pedig „csak” 39 ismert hibáról tudnak.

Galéria megnyitása

A processzorokban lévő hibák közül jellemzően csak azokat javítják, amelyek vagy kritikus biztonsági résnek minősülnek, vagy befolyásolják a termék és a rendszer működését – azok, amelyek nem jelentenek veszélyt és a teljesítményre sem gyakorolnak jelentősebb negatív hatást, egyszerűen sosem javítják. Azoknál a hibáknál, amelyek szoftveresen javíthatóak, jellemzően mérlegelni szokták, a javítás milyen hatást gyakorol a rendszer teljesítményére, majd ennek megfelelően járnak el.

Az AMD EPYC Rome sorozatú processzorokkal szerelt szerverek a fenti hiba miatt már nem vehetnek részt abban a versenyben, ami a leghosszabb időn át folyamatosan működő szerverek között zajlik. Itt a cél az újraindítás nélküli folyamatos üzem, a rekorder pedig a Voyager 2 fedélzetén helyet foglaló processzor, ami 16735 napja, azaz 48 évnél is több ideje üzemel megszakítás nélkül. A földi szerverek közül a rekorder egy 6014 napja, azaz nagyjából 16 éve működő rendszer.

Hírlevél feliratkozás
A feliratkozással elfogadom a Felhasználási feltételeket és az Adatvédelmi nyilatkozatot.

12 hozzászólás

A komment írásához előbb jelentkezz be!
axe
axe
2023. jún. 7. 0:40
#4

"a fenti hiba miatt már nem vehetnek részt abban a versenyben, ami a leghosszabb időn át folyamatosan működő szerverek között zajlik" miért nem?

kiberg
kiberg
2023. jún. 6. 16:12
#3

Csak azt felejtitek el hogy azalatt az idő alatt többet dolgozik a ryzen mint egy intel proci kb. egész életében

Mosdatlan_falusi
Mosdatlan_falusi
2023. jún. 7. 12:35

@kiberg persze, hogy többet dolgozik, valahogy be kell hoznia a lemaradást.

j4ni
j4ni
2023. jún. 6. 14:15
#2

Nagy jelentősége első pillantásra nincsen. Szokásos tech sajtó vihar a biliben. Az hogy egy mag nem tér vissza a 32-ból, tehát marad 31, a rendszer működik tovább, az inkább apró kellemetlenségnek hangzik.

Az ilyen processzorokkal szerelt gépek tipikusan virtualizált infrastruktúra részei, ahol a futó virtuális gépek tetszőlegesen pakolgathatóak a fizikai gépek között. A fizikai gépek tervezett szervíze/újraindítása sehogyan nem érinti a virtuális gépeket, hiszen a fizikai gépek a szervíz idejére kiürítésre kerülnek majd szervíz után újra felveszik a szerepüket a resource poolba tartozó VM-ek futtatásában.

Pld egy egyszerű Hypervisor upgrade ami azért megesik is igényelheti a fizikai gép kiürítését, újraindítását.

Dragon3k
Dragon3k
2023. jún. 6. 17:52

@j4ni  lehet, a magyar cikk alapján írtam, de 1 mag is sok, ez epyc itt nem egy CPU van használatban, hanem akár több ezer is.

mullerdavid
mullerdavid
2023. jún. 6. 13:20
#1

Google fordító?
"aláírt integer"

Signed integer az előjeles egész.

mullerdavid
mullerdavid
2023. jún. 7. 20:46

@ianbrenner Igen, utóbbi években már elég jó a google translate. Inkább szarkasztikusan a fordítás minőségére utaltam, remélem azért nem sértődik meg az illető. A DeepL-t meg nem ismertem, köszi a tippet.

Vissza az oldal tetejére