AMD potwierdza błędne działanie Ryzenów na niektórych PCtach z Linuksem
Autor: Wedelek | źródło: Phoronix | 06:44
(29)
Od kilku dni w sieci można przeczytać o problemach niektórych posiadaczy Ryzenów używających do pracy Linuxa. Niewielka grupa użytkowników donosi, że przy długotrwałym i intensywnym obciążeniu całego CPU sporadycznie występują tzw. problemy segmentacji. Istnienie takiego błędu potwierdziło samo AMD, które natychmiast po otrzymaniu pierwszych zgłoszeń zaczęło poszukiwania źródła problemu. Na razie jednak go nie odnaleziono, bo jak przyznaje sam producent cała sprawa jest dość skomplikowana. Wiadomo tylko, że błąd pojawia się u niewielkiej grupy użytkowników i dotyczy tylko pierwszych partii Ryzenów.
Threadrippery oraz Epyci mają go być całkowicie pozbawione. Co ciekawe bardzo trudno sprokurować sytuację, w której Ryzen zacząłby źle funkcjonować.
AMD poinformowało też zainteresowanych użytkowników, że problem dotyczy nie tylko samych Linuksów, ale i systemów z rodziny Unix. Jednocześnie producent zapowiedział szybkie wydanie stosownej poprawki i obiecał, że w przyszłości będzie więcej testów sprzętu pod Linuksem.
K O M E N T A R Z E
Poprzednio Intel, teraz AMD... (autor: Kenjiro | data: 9/08/17 | godz.: 08:06) Jeśli błąd występuje na FreeBSD i Linuksie, to tylko kwestią czasu jest wykrycie go na Windowsie. Z drugiej zaś strony dzisiejsze procesory są na tyle skomplikowane, że może to być problem np. nie do końca obsługiwanego procesora w kernelu, patrz np. poprawka dla FreeBSD sprzed tygodnia: https://svnweb.freebsd.org/...&revision=321899
Skandal, kompletnie nie do pomyślenia , Intel takich błędów nie ma (autor: Sony Vaio Surprise | data: 9/08/17 | godz.: 09:01) Jak zwykle amd struga procesory z patyków, potem coś nie działa, a fanboje się cieszą i mówią ze to zaleta. Intel jak coś wypuszcza, to jest to sprawdzone i użytkownik ma stuprocentowa gwarancje sprawności.
A ja się zastanawiam, (autor: muerte | data: 9/08/17 | godz.: 10:37) czy taki procesor wymieniają na gwarancji, jeśli jako powód podać błędne działanie np. Linuxa.
nieeee mozeee byc...... (autor: g5mark | data: 9/08/17 | godz.: 11:46) AMD....uwielbieniec swoich fanbojow ????To jawna niesprawiedliwosc, co na to Sue ?
niestety, (autor: angh | data: 9/08/17 | godz.: 13:47) widac pewne podobienstwa do Intela;)
Rabneli Intelowi projekt (autor: Wyrzym | data: 9/08/17 | godz.: 15:39) to i te same bledy maja, a co ^^
@1 nie zawsze to musi byc blad programowy... (autor: gantrithor | data: 9/08/17 | godz.: 16:21) ale tez specyficzne warunki dzialania samego procesora ,pamietacie moze pentium 4 northwood? okazal sie najlepszym procesorem z seri p4 i smialo konkurowal z athlonami , otoz posiadal on dosc specyficzny blad podczas podkrecania po przekroczeniu pewnej granicy napiecia procesor ten dawal ogromny skok w czestotliwosci taktowania ale bylo to okupione "syndromem naglej smierci nortwooda" prawdopodobnie po podniesieniu napiecia nastepowalo przebicie elektryczne gdzies w procesorze pozwalajac na wzrost taktowania ale to z kolei prowadzilo do degradacji ukladu.
@8. (autor: pwil2 | data: 9/08/17 | godz.: 16:51) To samo można było zaobserwować na Pentiumie Dual Core E5200 2.5@4+GHz. Procesory się dobrze kręciły, ale powyżej pewnej granicy szybko się degradowały i @2.5GHz wymagały podniesionego napięcia...
@1. (autor: pwil2 | data: 9/08/17 | godz.: 16:53) Były opisane sytuacje, gdzie pomagała zmiana - pamięci, zasilacza, płyty+AGESA, wyłączenie kilku optymalizacji. Pod Windowsem problem przy kompilacji nie występował, więc wnioski były, że to kwestia kernela.
c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:00) Po aktualizacji BIOS/AGESA u niektórych domyśne napięcie SOC uległo obniżeniu, stąd może wynikać część problemów.
c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:11) "A compile job forks a lot of processes each with their own layout. Try compiling without ASLR. "echo 0 > /proc/sys/kernel/randomize_va_space".
ops... it seems to do the trick for me
yesterday I left this machine compiling continuously gcc in a shell and mesa in another;
with randomize_va_space set to 1 or 2, mesa compilation fails quite always with the usual segfault in bash or in libc; with randomize_va_space set to 0, during the test, gcc was compiled 8 times and mesa 78 times with no segfault or whatever."
Tak, tak. Wina kernela, ASLR i Intela (autor: daver | data: 9/08/17 | godz.: 17:32) "I got the second RMA'd processor. As mcl00 already reported in #642, it has stepping 1 and UA 1725SUS printed on the processor while my original one has UA 1707PGT and the first RMA'd one has UA 1716PGT.
I tested more than 13 hours last night with stock BIOS settings and no workarounds (it means SMT enabled, uOP cache enabled, ASLR enabled), and got no segfaults." https://community.amd.com/...mment-2816648#2816648
Będą mieli problem, jeśli nie uda się workaround mikrokodem.
c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:48) "If there is a hardware bug depending on specific address in user address space it would make sense that compile jobs triggers it. Linux use address space layout randomization to put memory segments on different addresses on each run. A compile job forks a lot of processes each with their own layout. Try compiling without ASLR. "echo 0 > /proc/sys/kernel/randomize_va_space".
Thank you for the tip. ;-)
Just tried and run fine now without segfault when I build my cross environment
"make --jobs=16 MXE_TARGETS='x86_64-w64-mingw32.static i686-w64-mingw32.static' qt5" on my Debian Sid.
Before I saw a lot of "segfault at 10 ip 0000000000000010 sp 00007ffcdbc8df58 error 14 in cc1plus""
***
"Thank you very much. This workaround seemed to work for me. Before this setting, I could reproduce this problem at least once per ten kernel build by make -j16.
But that build worked fine during 100 times after this setting."
***
"Could you tell me why you think this problem is HT specific?
If the problem which you pointed out is the same as mine, SEGV should disappear if I disable SMT. However, when I did so,
SEGV still happened. On the other hand, when I disabled ASLR, which is expected to reduce the probability of the problem
you mentioned, SEGV disappeared at all."
***
"Mine freezes while doing practically nothing at all.
Sounds like the issues I had with my 1700 with early BIOS versions. It would survive torture tests, but then would randomly freeze, often while doing nothing. Hours of gaming and no freeze, then freeze on the desktop a few minutes later. After re-installing ubuntu and updating to a 1.0.0.4a series BIOS it's been up for weeks without issue at 3.8GHz and thoroughly stress tested. My motherboard (ASRock AB350 K4) hasn't released a 1.0.0.6 BIOS yet. Hoping problems don't return for me when they do as I'd like to update in hopes of better RAM speed/timings."
***
"I've managed to fix my freezes. Turns out it was CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL. These are enabled in Fedora. After enabling just these in my minimal config, there was no freeze. After disabling these in Fedora's config, I got a freeze. I don't know the reasoning but it seems quite conclusive. I don't yet know whether it's merely a workaround for some underlying issue or even whether it simply makes a freeze less likely. What's the best way to get this information across to AMD? @bridgman?
Interestingly, CONFIG_RCU_NOCB_CPU is not enabled in Debian. We haven't seen swarms of Debian users reporting freezes with Ryzen so perhaps this issue is specific to the motherboard or some other factor. I did want to try a prebuilt Debian kernel but I was surprised that I couldn't find anything newer than 4.10, even among Ubuntu, Mint, and Sid.
I previously said that I hadn't seen any segfaults. I did see some eventually but disabling ASLR fixed it. I am now booting with norandmaps to ensure that ASLR is disabled immediately on boot. Enabling CONFIG_COMPAT_BRK in the kernel doesn't actually disable ASLR entirely."
***
PS. Tak czytając fora Linuksowe mam wrażenie, że o ile jest tam pewnie wielu świetnych programistów, to większość z nich zna się w stopniu przeciętnym na sprzęcie (w tym podkręcaniu, szukaniu przyczyn niestabilności). Prędzej przekompilują cały kod źródłowy z dysku na inną architekturę, niż spróbują podnieść któreś z napięć.
Połowa przypadków problemów polega na tym, że gość idzie do sklepu, kupuje R7 1700 wraz z DDR4 3200 i zaczynają się problemy, których na jego poprzednim i5 SandyBridge nie było.
Na Intelu obsadzenie wszystkich banków na P55 wymagało czasem 1.25V napięcia IMC. Na Ivy Bridge do uzyskania wyższych taktowań pamięci (DDR3 2133C11) też trzeba było ruszać napięcia, albo szukać selekta procesora - moje 3 sztuki i7QM nie dały rady, a niektórym na i7-3840QM chodziło).
@14. (autor: pwil2 | data: 9/08/17 | godz.: 17:54) Inna sztuka procesora to inne domyślne napięcia. U mnie 3 sztuki i7 z pamięciami DDR3 2133C11 zachowywały się inaczej. Na jednym czarny ekran, na innym system startuje, ale zachowuje się "dziwnie", a kolejnym chodzi stabilnie do czasu maksymalnego obciążenia. Te same pamięci w parze z 1866C10 chodzą @1866C10 stabilnie z każdą sztuką.
c.d. (autor: pwil2 | data: 9/08/17 | godz.: 17:59) "I figured I'd throw a comment in here as i've seen all these errors at one point or another.
It seems that any memory speeds over 2666 require a vsoc voltage bump for me to get rid of errors ie: 1.225v currently
Also today was the hottest day of the year and I started getting the uop cache parity errors during a firefox compile on settings that were otherwise stable for over a month.
Heat could be a big factor for that. The ~1.4v turbo voltage is just intense.
1800x
gigabyte gaming K7
64GB ecc mem overclocked at 2933 (no errors)"
"I'd recommend that people who aren't overclocking, considering raising the vsoc a tad and see if it makes their issue go away.
I'm running the llc settings at "regular" because the vrm's get hot."
"Also worth noting the PWM fan control on my system is inverted.
So 0 is max speed and 255 is slowest speed.
I had to modify the fancontrol script to get this right and use a git version of the it87 module for the sensors output.
This could be very dangerous for some people if they don't notice, as the fans will spin slower as the cpu gets hotter."
angh dziwi Cię to? mnie wcale (autor: Sławekpl | data: 9/08/17 | godz.: 18:17) nie ma szans by tylko u jednego coś takiego się pojawiło skoro jedni od drugich zrzynają wszystko
także to nie żaden błąd, to ficzer, a skoro tak ... ;)
... to celowa implementacja aby obronić kompa przed coraz większą liczbą wirusów i innych cholerstw na Linuxa, tylko to tajne przez poufne rozwiązanie, przynajmniej do niedawna takie było, niestety jakaś plotkarska pierdoła nie wytrzymała i się musiała pochwalić przed innymi :P
@daver (autor: pwil2 | data: 9/08/17 | godz.: 18:20) "Some. A subset of users seems to benefit from upping the SoC voltage from ~.945 (auto) to 1.05-~1.1v. I'm fairly sure it's mostly an electrical issue, as exchanging processors doesn't seem to make any difference, but it's not yet led to AMD announcing any kind of fix."
Nawet jeśli zmiana procesora pomaga, może oznaczać lepszą sztukę kontrolera i zbyt niskie domyślne napięcie w UEFI/AGESA. Skoro część kompów z Ryzenami przechodzi testy, które wysypują się u innych zawsze, to sugeruje, że nie jest to bug w architekturze procesora.
@16 (autor: daver | data: 9/08/17 | godz.: 18:27) LOL, 3 procesory zachowywały się inaczej na, jak mniemam, wspieranych pamięciach? Pełna profeska, nie ma co. Proszę, nie wklejaj więcej internetów, bo zaczynam wątpić, czy ta platforma to zabawka na komunię dla małego majsterkowicza, czy stabilna platforma do pracy.
@slawekPL (autor: angh | data: 9/08/17 | godz.: 21:01) Musze zaczac dawac /s na koncu niektorych postow... ;)
Poziom skomplikowania hardware obecnie jest tak duzy, ze bledy sa nie do uniknienia. Kazda generacja Intela ma bledy, AMD zreszta rowniez mialo, wiec nie jest to nic zaskakujacego. Na szczescie zwykle pomaga upgrade Bios, a poza tym, to jest wlasnie powod dla ktorego nie kupuje sie pierwszej fali sprzetu;)
Nie zmienia to faktu, ze jest to swietny procesor i gdybym mial zmieniac to wybor bylby prosty.
Mam jedynie nadzieje, ze Vega nie zostanie przechwycona przez gornikow, bo akurat gpu chce zmienic i najchetniej na Vege wlasnie.
angh proszę wyjaśnij co ma dać "/s" (autor: Sławekpl | data: 10/08/17 | godz.: 00:58) na końcu postu bo nie łapie, pewnie przez późną porę ;)
też to przy premierze Zen pisałem, kupię kolejny ich procek gdy znajdą oraz uporają się z większością błędów
co do grafy / Vegi, ja nadal czekam na grafę od AMD zajmującą jeden slot i nisko profilową do HTPC, kupno wersji Pro za 1400 zł średnio mnie się uśmiecha
może się kiedyś doczekam, pewnie dopiero jak wyjdzie Navi w 7 nm :P
@20. (autor: pwil2 | data: 10/08/17 | godz.: 07:43) Dla Ryzena 1700:
"Memory Max Memory Speed
2667MHz"
Dla i7-7700K:
"Memory Types
DDR4-2133/2400, DDR3L-1333/1600 @ 1.35V"
Dla i7-6700K:
"Memory Types
DDR4-1866/2133, DDR3L-1333/1600 @ 1.35V"
pwil2 to oficjalne dane producentów (autor: Sławekpl | data: 10/08/17 | godz.: 08:48) jednak u jednych i drugich można użyć szybszych kości po OC, da to wymierne korzyści w praktycznie wszystkich zastosowaniach
warto dołożyć, czasem tylko kilka złotych do lepszych pamiątek ;)
@24. (autor: pwil2 | data: 10/08/17 | godz.: 14:32) OC = nie nie jest gwarantowane, a wsparcie polega na trzymaniu kciuków ;-)
PS Mam (z pamięci licząc) 32GB DDR4 3000, 48GB DDR4 2666, 32GB 2400, 64GB DDR4 2133 i garść wolniejszych/mniejszych pojemności, więc wiem coś o dokładaniu ;-)
edit (autor: pwil2 | data: 10/08/17 | godz.: 14:33) Jedno "nie" za dużo
pwil2 przy topowych pamięciach, zgadza się (autor: Sławekpl | data: 11/08/17 | godz.: 21:24) wręcz trzeba dać na mszę w tej intencji :E
ale jak kupisz o dwie, trzy podziałki szybsze to musisz mieć pecha by nie ruszyły, zwłaszcza markowe ;)
@27. (autor: pwil2 | data: 16/08/17 | godz.: 16:40) Miałem kości pamięci A-Daty 1333 zupełnie seryjne, 2 komplety i na Intelach trzeba się było nagimnastykować, by działały. Niby MemTest przechodził, ale nie do końca stabilnie na co dzień. Na niektórych płytach/procesorach zupełnie ok.
c.d. (autor: pwil2 | data: 16/08/17 | godz.: 16:43) W 2 laptopach sprawdzałem 3 sztuki i7QM i w różnym stopniu nie działały mi HyperX DDR3 2133C11, a podobno szczęściarzom z selektami i7-3840QM ruszały. Za to Cruciale 2133C11 chodziły z różnymi sztukami (szkoda mi było już kolejnej kasy wykładać na zamiany)
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
