W czerwcu tego roku pojawiły się pierwsze doniesienia o tym, żekompilacje większych programów na komputerach z Ryzenem 7 kończąsię komunikatem o naruszeniu ochrony pamięci (segmentation fault).Problem dotyczył tylko kompilatora GCC w różnych wersjach, nieudało się go odtworzyć na kompilatorze LLVM/Clang. Co więcej, niewystępował uniwersalnie – jedynie niektórzy z posiadaczy nowychprocesorów go zgłaszali.
Skala występowania tego sprzętowego problemu jest jednak napewno zaniżona niszowością scenariusza – nawet przeciętnyużytkownik Linuksa nie kompiluje sobie dziś za częstooprogramowania (nie licząc fanów Arch Linuksa czy Gentoo). AMDogłosiło więc, że wzięło się za analizę problemu,niewątpliwie związanego z procesorem – udało się wykluczyćwszystkie inne przyczyny, takie jak czipset czy RAM.
Ostatecznie AMD potwierdziło, że naruszenia ochrony pamięci naRyzenach 7 faktycznie się zdarzają, zarazem nie dotyczą czipówThreadripper ani EPYC. Nie podano powodu usterki, jednak najwyraźniejmusi on dotyczyć procesu produkcyjnego – wszystkie dotknięte niąprocesory pochodziły z pierwszych partii, wyprodukowanych do 25tygodnia 2017 roku.
Software’owej erraty nie będzie, naprawić się tego za pomocąaktualizacji mikrokodu nie da, jak to na przykład ostatnio było zprocesorami Intel Skylake, które zawieszałysię w trakcie wykonywania złożonych obciążeń roboczych(czytaj: benchmarka Prime95).Łatkę dostarczono wtedy przy pomocy partnerów, jako aktualizacjęfirmware dotkniętych problemem komputerów. W wypadku AMD koniecznabędzie wymianacałego procesora na pochodzący z nowszej partii.
Jeśli zauważyliście u siebieproblemy ze stabilnością pracy swojego Ryzena, powinniściesprawdzić na Linuksie skrypt kill-ryzen.sh,który przeprowadza za pomocą GCC kompilację tego kompilatora.Stare Ryzeny powinny zgłosić wówczas naruszenie ochrony pamięci.Wówczas należy skontaktować się z producentem poprzez formularzna stronieinternetowej – AMD obiecuje wymienić na swój koszt procesorkażdemu, kto zgłosi się z tym problemem.
