Új hozzászólás Aktív témák

• #113 XMI csendes tag

  Új Válasz 2017-08-29 20:19:01 #113

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  XMI

  csendes tag

  Egy pillanat!
  Itt igen sok téves állítást látok tényként leírva.
  Mivel alapvetően Linux-ot használok és szándékoztam Ryzen-t venni, kicsit közelebbről követtem a hiba körüli történet alakulását.

  Először is ajánlom figyelmébe minden érdeklődőnek az AMD community oldalán levő fórumtémát, jelen pillanatban itt találhatóak a leginkább elsőkéz-közeli információk: [link]

  Másodsorban ajánlom a folyamatosan frissülő követő táblázatot, ahol gyártási dátummal követik a hibás és hibátlan processzorokat: [link]

  Az AMD community thread alapján eddig ismert tények a következők:

  - Kétféle hiba van: a segfault és a machine check exception / random reboot. Ebből a segfault-os hiba kapott nagyobb hírverést.

  - Kezdem az egyszerűbbel: a machine check exception / random reboot hiba a gép üresjárati állapotában jön elő, egyértelműen energiagazdálkodási eredetű, van rá ismert workaround: a C-state-eket, vagyis energiatakarékos processzorállapotokat le kell tiltani BIOS-ban. Viszonylag kevés processzort érint.

  - A segfault hiba gcc vagy clang-os fordítással reprodukálható, más módszer egyelőre nem ismert, a processzor bármilyen más tesztben stabilnak mutatkozik. A kill-ryzen teszt [link] is ezzel a módszerrel provokálja.

  - A segfault hibát nemcsak Linux alatt lehet reprodukálni, kellően intenzív sokszálú gcc vagy clang fordítással Windows alatt is előjön.

  - A WSL esetén nincs Linux kernel sehol a rendszerben, ilyenkor a windows kernel látja el a Linux kernel szerepét. A legvalószínűbb következtetés, hogy a hiba nem oprendszer-specifikus.

  - Az ilyen fordítási terhelés egyáltalán nem "extrém" és nemcsak fanatikus Gentoo felhasználókat érint, akik mindent maguknak fordítanak, hanem például szoftverfejlesztőket is, akik munkához használnák build gépnek.

  - A segfault hibára eddig nem ismert workaround. Vannak akiknél az SMT vagyis a magonként kétszálas végrehajtás letiltása hozott javulást, vannak akiknél a BIOS-ban az uOpCache vagyis mikroművelet gyorsítótár tiltása segített valamennyit (5-7% teljesítménycsökkenés árán), vannak akiknél a Linux kernelben a címtartomány randomizációs biztonsági feature kikapcsolása javított a helyzeten. Általános megfigyelés, hogy egyik megoldás sem oldja meg teljesen a problémát, csak lecsökkenti az előfordulás gyakoriságát.

  - A processzor órajel-csökkentése, memória órajel-csökkentése, túlfeszelés a legtöbb felhasználónál nem oldja meg a problémát -> tehát nem arról van szó, hogy a hibás darabok túl magas modellszámot kaptak volna, nem tudom honnan veszik itt a fórumban ilyen sokan ezt az információt

  A hiba előfordulásáról:

  - Jelen pillanatban nincs olyan ismert eset, ahol boltban vásárolt Ryzen processzor átment volna a kill-ryzen teszten! Ez még nem feltétlen jelenti azt, hogy az összes Ryzen hibás lenne, hiszen akinek hibátlan jutott, az nem biztos hogy egyáltalán foglalkozik a problémával. De ezidáig senki nem állt elő ilyennel, ami legalábbis gyanús.

  - Bizonyítottan hibátlan Ryzen processzorhoz eddig csak RMA (gyártói garanciális) csere útján jutottak hozzá

  - A Threadripper és EPYC processzorokból eddig nem találtak hibásat

  - Az RMA-csereprocesszorok mind 25. hetiek vagy későbbi gyártásúak voltak

  - Már legalább két felhasználó jelezte, hogy 25. vagy későbbi gyártású processzor is hibás (az írás pillanatában is próbálják ellenőrizni, hogy nem más-e a hiba oka, pl XMP profil hibás kezelése miatt RAM instabilitása). Mindenesetre egyelőre nem jelenthető ki, hogy a 25. heti vagy későbbi példányok biztosan jók lennének.

  - A visszakapott RMA cserepéldányok közül jónéhány felhasználó jelezte, hogy a dobozában post-it cetlit találtak "Pass", "Passed", "Ok" feliratokkal. Vagyis igen valószínű, hogy a jó processzorok külön kézi tesztelésen mentek át.

  Jelen pillanatban ismert tények alapján sokan arra következtetnek, hogy az AMD valójában még nem tudta megbízhatóan megoldani a problémát, egyszerűen kézzel válogatják az RMA-hoz a véletlenül jól sikerült példányokat.

Új hozzászólás Aktív témák