Alcuni processori AMD Ryzen di produzione antecedente alla 25esima settimana dell'anno 2017 possono presentare un particolare difetto di produzione per il quale, in determinate condizioni di carico intensive come ad esempio la compilazione di progetti complessi in C/C++, possono manifestare problemi di segmentation fault, abbreviato
segfault. Solitamente si intendono carichi impieganti tutti i core del processore contemporaneamente, ma
in un caso (
2) è riportato che ne può bastare anche solo uno. Molto interessanti ma altrettanto tecniche analisi di quello che accade esattamente sono state scritte da Hironori Fujii
nel suo blog e da Matt Dillon
nel forum di Phoronix.
Phoronix, noto sito web di attualità informatica specializzato in notizie e review riguardanti Linux, ha documentato con dettaglio l'argomento nel corso dei mesi passati:
I primi report pubblici dello stesso risalgono ad Aprile 2017
nel forum della distribuzione Linux Gentoo (
thread correlato). C'è anche un thread dedicato, ancora attivo,
nel forum di community support ufficiale AMD, dove la soglia della 25esima settimana di produzione per questo problema è stata dedotta dagli utenti osservando quella stampata sui processori sostitutivi inviati direttamente da AMD in seguito alle richieste di RMA.
Aggiornamento 2017-10-26: aggiunto link a
breve guida passo-passo su come effettuare il test di segfault nativamente su Windows con
kill-ryzen-win.
Aggiornamento 2017-10-21: ci sono sempre più frequenti commenti di utenti che riportano problemi con Ubuntu
17.10 usando il test originariamente scritto da
suaefar (
https://github.com/suaefar/ryzen-test) per verificare l'insorgenza di
segfault con i processori AMD Ryzen. Questa versione è stata ideata per Ubuntu
17.04 e non è
al momento pienamente compatibile con l'ultima versione del sistema operativo rilasciata il 2017-10-19. Il risultato è che fallisce sempre inevitabilmente (
senza segfault) dopo un certo periodo di tempo, solitamente relativamente lungo. Una versione aggiornata del test adattata per Ubuntu 17.10 è stata scritta da
Oxalin (
https://github.com/Oxalin/ryzen-test). Di questo se ne è scritto ampiamente qui e nella discussione.
Aggiornamento 2017-10-18: ci sono report, di cui qualcuno da HWUpgrade usando vari metodi, anche sotto Windows (settimana 33:
1,
2,
3; settimana 34 / 1734:
1,
2,
3), di processori prodotti dopo la settimana 25 e normalmente disponibili nel canale retail (ossia non ritornati da RMA) che continuano a manifestare il problema. Pertanto non c'è ancora sicurezza che acquistando un processore AMD Ryzen oggi si ottenga un esemplare esente da problematiche correlate.
Cos'è un segmentation fault?
Da Wikipedia:
Quote:
|
Un errore di segmentazione (in inglese segmentation fault, spesso abbreviato in segfault) è una particolare condizione di errore che può verificarsi durante l'esecuzione di un programma per computer. Un errore di segmentazione ha luogo quando un programma tenta di accedere ad una posizione di memoria alla quale non gli è permesso accedere, oppure quando tenta di accedervi in una maniera che non gli è concessa (ad esempio, scrivere su una posizione di sola lettura, oppure sovrascrivere parte del sistema operativo).
|
Come verificare che il proprio processore sia affetto?
Importante: accertarsi prima che il sistema non sia in condizioni di overclock, ripristinando prima del test le impostazioni iniziali della scheda madre dal BIOS (optimized defaults). Notare che benché alcuni utenti dal forum di Linux Gentoo abbiano comunque verificato il problema
anche con le memorie a 2133 MHz, usare memorie DDR4 ad una velocità superiore rispetto a quanto
ufficialmente supportato dal processore (2667 MHz con due moduli single ranked. Leggere
questa slide o le
specifiche tecniche dal sito web AMD) può essere considerabile overclock, anche se
successivi aggiornamenti firmware hanno migliorato il supporto a velocità superiori. A ribadire ciò, Robert Hallock di AMD riporta
null'ultimo link:
Quote:
|
Please note that values greater than DDR4-2667 is overclocking. Your mileage may vary (as noted by our big overclocking warning at the end of this blog).
|
Anche usare i profili XMP è considerabile overclock, ed
in almeno un caso è stato la causa di segfault. Leggere in particolare
questo commento di Mister D riguardo l'uso dei profili XMP con i processori AMD Ryzen. In sostanza: XMP, oltre ad essere un preset da overclock, è uno standard proprietario Intel che potrebbe risultare in impostazioni/timing non perfettamente stabili con AMD Ryzen; pertanto è consigliabile evitare di abilitarlo nel caso si voglia verificare l'insorgenza delle problematiche di segmentation fault.
Mettendo da parte l'argomento overclock, una condizione
necessaria ma non sufficiente è che il processore sia stato prodotto prima della 25-26esima settimana del 2017 (
Aggiornamento 2017-10-18: questa informazione potrebbe non essere accurata). Questa data è stampigliata sulla serigrafia dello heat spreader, la quale si può ovviamente leggere solo a processore smontato. Tuttavia dato che nella confezione originale il processore è a vista (esempi:
1,
2) questo significa che in caso di acquisto è possibile identificare subito la settimana di produzione del proprio esemplare, senza né toglierlo dalla stessa né danneggiando alcun sigillo.
In questo thread su Reddit viene spiegato in dettaglio come leggere tali valori. In sostanza, occorre leggere il valore numerico indicato qui nella seconda riga. Nella seguente foto 1707 indica "Anno 2017, Settimana 07", mostrando dunque un processore
potenzialmente affetto dal problema.
Papugo80 riporta che è possibile verificare il periodo di produzione effettuando una
interrogazione online del codice seriale stampato sulla confezione del processore. La voce "MFG Date" (
definizione standard per "
Manu
facturin
g Date"),
come lo screenshot mostra, dovrebbe indicare la data di produzione del processore. Questo rende possibile conoscere tale informazione senza dover smontare il dissipatore se già installato sulla scheda madre, ma in alcuni casi
potrebbe non trovare nulla. Sembra inoltre che possano essere possibili discrepanze (
1,
2) fra la settimana di produzione ricavata dalla
MFG Date qui e quella sul processore, dunque il metodo più affidabile per determinarla rimane riferirsi a quest'ultima. È possibile che si riferisca al packaging piuttosto che al processore in sé.
Quanto alla verifica effettiva del problema (ancora, non tutti i processori lo manifestano, né tutti lo fanno con la medesima repentinità), tipicamente viene usato uno script sotto Linux chiamato "kill-ryzen". È disponibile tramite il seguente URL:
https://github.com/Oxalin/ryzen-test (versione da scaricare con Ubuntu 17.10)
Vecchia versione: https://github.com/suaefar/ryzen-test (versione valida per Ubuntu 17.04. Ha problemi con recenti distribuzioni di Linux, fra cui Ubuntu 17.10)
È possibile eseguire il test senza installare Linux nel proprio PC, usando una pendrive con installata sopra ad esempio una distribuzione live di Ubuntu.
Nota: a causa di incompatibilità con il kernel Linux fornito di default, alcune schede madri Gigabyte B350/X370 necessitano di una modifica alla procedura di avvio usando Ubuntu 17.04 (occorre disabilitare ACPI). Lo screenshot in basso esemplifica come. In alcuni casi sembra sia necessario modificare direttamente file di configurazione del bootloader della distribuzione live [dettagli?]. Può anche essere possibile risolvere cambiando la modalità di avvio della scheda madre da UEFI a BIOS (Legacy), come suggerito qui.
Ubuntu 17.10, rilasciato il 19 Ottobre 2017, dovrebbe avere un diverso Kernel che risolve le incompatibilità con le schede madri Gigabyte. In alternativa si possono usare altre distribuzioni Live di Linux esenti da questo inconveniente (es. Fedora), con variazioni minime nella procedura di test descritta più sotto.
Aggiornamento 2017-10-19: da test personalmente effettuati mediante una Virtual Machine, Fedora Live potrebbe non essere in grado out-of-the-box di permettere la verifica del problema, dunque attenzione (1, 2).
Il test va scaricato dal browser web mediante Ubuntu ed eseguito lì seguendo le istruzioni riportate nella pagina di origine. Fallisce se termina entro qualche minuto (esempi:
1,
2,
3) con un errore di
segfault come mostrato nel seguente screenshot. Sono possibili anche errori di
invalid opcode (
esempio da Phoronix e HWUpgrade) o di
general protection (
qui). È stato riportato che può talvolta impiegarci anche qualche ora (continuativa) o che gli errori
potrebbero non uscire fuori in maniera regolare (un altro report simile
qui e potenzialmente anche
qui). Per questo motivo è consigliabile riavviare il PC e fare ripartire il test dopo grossomodo un'ora senza esito negativo. Se continua a non succedere nulla dopo due o tre riavvii allora con buone probabilità il processore non dovrebbe avere problemi.
Nota 1: un possibile punto di confusione (anche qui) è che il test possa apparire bloccarsi a "Loop-15" (od altri valori simili). Se dal "System Monitor" di Ubuntu (o di un altro equivalente monitor risorse in altre distribuzioni Linux) l'occupazione del processore rimane al 100% e si continuano a vedere un'enorme quantità di processi da nomi simili venire creati e terminati dopo un po', lo script sta facendo quello che deve fare. I loop non vengono eseguiti sequenzialmente, ma tutti contemporaneamente, dunque non è giusto dire che il test si ferma ad un certo loop.
Nota 2: il test può continuare senza errori fino a che la memoria non viene completamente occupata (poiché effettua ad impostazioni di default la compilazione in un ramdisk); sembra ci vogliano circa 45-60 minuti con 16 GB di RAM. Con 8 GB ce ne vogliono poco più di 20. È possibile cambiare le impostazioni di avvio di ryzen-test per prevenire interruzioni correlate; la sezione "requirements" nella pagina di download indica come.
Nota 3: possono in alcuni casi anche accadere entro breve tempo crash ed interruzioni non correlati con il problema (senza avvisi di invalid opcode o segfault dal kernel, quando eseguiti sotto Linux), tipicamente causati da librerie di sistema non trovate o diversi tipi di errore da segfault ed affini, dunque nel dubbio meglio riportare i risultati qui nel forum. Ho scritto un commento che mostra in dettaglio (usando una Virtual Machine) un test fallito per motivi diversi dal segfault. Avvisi di "interrupt took too long" (spiegazione qui) non indicano problemi con la CPU e sono normali.
Io ho postato istruzioni guidate passo-passo con screenshot su come verificare l'inconveniente su
Ubuntu 17.10 in
questo commento.
Attenzione che qualcuno degli screenshot mostra erroneamente l'URL di una diversa versione del test che non è adatta per Ubuntu 17.10. Nello stesso commento, oltre che altrove, è fornito il link alla versione corretta da usare.
Aggiornamento 2017-10-19 15:00: ho constatato che il compilatore incluso in Ubuntu 17.10 potrebbe avere problemi a compilare correttamente i sorgenti che la versione originale di ryzen-test va a scaricare. Si rende quindi necessaria una modifica alla procedura. La modifica consiste semplicemente nell'usare un fork con lievi modifiche allo script, by Oxalin.
Metal Master ha postato concise instruzioni nel thread principale di HWUpgrade dei processori AMD Ryzen su come verificare l'errore con Ubuntu 17.04:
Quote:
Originariamente inviato da metal master
|
Evil Weasel in HWUpgrade giugno scorso suggeriva una procedura simile, sempre sotto Linux, ma senza usare il test automatizzato
ryzen-test che rende più semplice l'operazione:
http://www.hwupgrade.it/forum/showpo...ostcount=11258
È possibile effettuare un test simile direttamente da Windows con
kill-ryzen-win, ma dalla discussione
in questo thread su Reddit da parte dell'autore e di altri utenti non sembra essere affidabile o veloce come il test su Linux. Dato che per eseguire il test su Windows occorre scaricare ed installarsi Visual Studio Community, alla fine non credo che si risparmi tempo rispetto ad usare una distribuzione live di Linux, a meno di averlo già installato. Alcune note tecniche dell'autore riguardo i crash su Windows
qui. Ho postato istruzioni dettagliate passo-passo su come eseguire il test su windows con
kill-ryzen-win in
questo commento. Ancora, tenere bene a mente che non è affidabile come il test su Linux.
Alternative da Windows includono l'uso di virtual machine (confermato anche da un report
qui nel forum), l'uso di Ubuntu od altre distribuzioni mediante il Windows Subsystem for Linux (WSL), od addirittura Cygwin. Ognuna ha i suo pro e contro. Usare una distribuzione live di Linux è un modo più semplice, standardizzato e poco invasivo per riprodurre il difetto.
Il problema mi riguarda? Non effettuo compilazioni sotto Linux
È possibile osservarlo anche da Windows,
usando il Windows Subsystem for Linux (WSL), o con script simili a
Ryzen-test che usano Microsoft Visual Studio (MSVC) come ad esempio il precedentemente menzionato
kill-ryzen-win.
Sembra inoltre che previe opportune modifiche,
Ryzen-test si possa anche eseguire con esito positivo con Cygwin. Questo conferma dunque che l'inconveniente non è limitato solo a sistemi Linux od al compilatore GCC usato da
Ryzen-test.
Non è ancora stato rilasciato un comunicato ufficiale o product errata da parte di AMD a riguardo (esistono post da parte di dipendenti AMD su forum come Phoronix o resoconti di terze parti che citano fonti AMD da comunicazioni private, ma non sono realmente considerabili ufficiali). Notare che non si sa ancora come e quando il problema accada esattamente, solo come replicarlo con relativa certezza; non è detto che non accada anche altrove (o che non possa farlo in futuro quando i programmi sfrutteranno il multithreading in maniera più consistente) e che la modalità di errore sia necessariamente visibile in maniera evidente.
Se errori di segmentation fault sono possibili, è plausibile che durante determinate operazioni intensive le applicazioni possano andare leggere o scrivere in zone di memoria concesse ma non corrette. Questo può portare potenzialmente a corruzioni silenziose dei dati manipolati senza errori di segmentation fault. Un altro possibile scenario è che il medesimo problema possa essere usato per exploit di vario genere da malware ed affini una volta che le condizioni per osservarlo verranno comprese nel dettaglio. Tuttavia non sono ancora noti casi in cui ciò sia accaduto.
Ad un livello più pratico, la mera presenza del difetto contribuisce a rendere potenzialmente ambigua l'origine di eventuali problemi od inconvenienti osservati durante l'uso del pc. Dato che i processori AMD Ryzen sono dei SoC che integrano
oltre a memory controller anche controller USB, SATA e PCIe, se c'è o c'è stato qualche problema in sede di produzione correlato alla parte "uncore"/SoC non è da escludere che possano eccezionalmente esserci anche effetti sul resto.
Alcuni commenti di un utente
in un thread dedicato nel forum di Phoronix lasciano intendere che problemi di reboot casuali e di hardware che lui osservava siano stati causati indirettamente dalla CPU difettosa che manifestava segfault durante la compilazione intensiva. Problemi di comunicazione USB limitati ad alcuni processori Ryzen usando Hakchi2 sotto Windows 10 potrebbero anch'essi essere causati dallo stesso che provoca segfault su Linux (
1,
2,
3,
4). Un report
qui su HWUpgrade di una CPU affetta da segfault potrebbe mostrare problemi SATA correlati (nota: da confermare).
Chi effettua overclock potrebbe essere interessato al fatto che le CPU prodotte dopo la settimana di soglia del problema (nb: od almeno, quelle ritornate da RMA) sembrano richiedere meno tensione a parità di clock rispetto a quelle che tendono a generare segfault. Oltre ad alcuni report su HWUpgrade (
esempio,
2) ce ne sono anche altri in forum internazionali (
esempio nel forum ASUS ROG, oppure
questa discussione su Reddit, riassunti in
questo commento su HWUpgrade) che osservano miglioramenti generali in overclock, oltre che miglioramenti con le temperature, in seguito alla sostituzione. È probabile che ci sia una correlazione inversa fra qualità della CPU e possibilità di osservare il problema e/o che le nuove CPU siano generalmente selezionate in maniera migliore.
È ancora possibile acquistare processori affetti dal problema?
Sembra di sì. Ad oggi (2017-10-15) ci sono alcuni report di utenti che in seguito ad acquisti ad esempio da Amazon.it hanno ricevuto processori prodotti prima della 25esima settimana del 2017, anche dopo resi (esempi:
1,
2,
3,
4, ma
anche questo con un 1700 non-X prodotto il 1715 ricevuto il 2017-10-19).
Internazionalmente parlando, alla fine di Agosto 2017, NewEgg (un grande store americano) vendeva ancora 1700X prodotti ad inizio Marzo. È facile che questo riguardi maggiormente i modelli meno venduti (1500X, 1600X, 1700X) per i quali le scorte potrebbero essere più lente ad esaurirsi.
Come posso risolvere?
Benché si sia pensato per un po' che si potesse risolvere definitivamente via aggiornamento firmware (AGESA 1.0.0.6b), vari report utente (
come ad esempio questo su Reddit) hanno rapidamente evidenziato che così non è stato. Per risolvere con certezza l'inconveniente, se non è possibile farsi inviare in sostituzione dal venditore dove lo si è acquistato un processore sicuramente prodotto dopo la 25esima settimana del 2017 (cosa che però da sola, in base alle ultime informazioni, potrebbe non risolvere il problema), è necessario contattare il supporto tecnico AMD per aprire una
procedura di RMA e farsene inviare uno [quasi] sicuramente funzionante in garanzia, spedendo prima a proprie spese (
esempio) quello vecchio ad uno dei loro centri di assistenza (tuttavia ad alcuni utenti,
come ad esempio Evil weasel oppure
Debern9093 od
Ozozuz qui nella discussione, è stata offerta una spedizione prepagata).
Metal Master ha documentato l'iter in alcuni post scritti nel thread ufficiale di AMD Ryzen in HWupgrade oltre che in questo thread:
- http://www.hwupgrade.it/forum/showpo...ostcount=19455 (Inizio)
- http://www.hwupgrade.it/forum/showpo...ostcount=19609
- http://www.hwupgrade.it/forum/showpo...ostcount=19668
- http://www.hwupgrade.it/forum/showpo...&postcount=250
- http://www.hwupgrade.it/forum/showpo...&postcount=524 (Fine)
- http://www.hwupgrade.it/forum/showpo...&postcount=531 (Dettagli aggiuntivi)
RMA oppure no?
Opinione personale.
In un commento di questa discussione io concludevo così:
Quote:
Originariamente inviato da s12a
Quote:
Originariamente inviato da Debern9093
secondo te mi conviene stare senza processore per giorni e fare rma? nel caso, a quale indirizzo devo spedire? ti inviano una cpu nuova? c'è il rischio di ricevere una cpu con lo stesso problema?
|
- Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
- Pensi che potrebbe essere un problema in futuro?
- Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
|
È possibile che il problema continui a manifestarsi anche con processori prodotti in date successive alla 1725?
La probabilità che ciò accada dovrebbe sulla carta essere bassa, ma non è nulla. C'è
almeno un report secondo cui lo stesso si può manifestare con un processore prodotto nella 26esima settimana.
Secondo un altro, un processore prodotto durante la 33esima e tornato indietro da RMA continua a farlo.
In questa lista dei processori di alcuni utenti del forum di community support AMD (principalmente), lo stesso accade con un esemplare prodotto 30esima settimana, anche se generalmente parlando dei processori ritornati da RMA, tutti prodotti dopo la 25esima, il problema appare risolto.
C'è la possibilità che i processori che AMD invia in sostituzione in seguito all'apertura di procedura di RMA siano pre-testati manualmente da un operatore in maniera specifica da non mostrare il problema. Le condizioni atipiche
riportate da alcuni utenti degli imballi e delle CPU ricevuti in seguito a tali richieste fanno presupporre ciò. In tal caso potrebbe non essere garantito che le CPU prodotte dopo la 25esima settimana e disponibili nei normali canali retail siano esenti da problemi.
Mitigazione del problema
Nel caso non sia possibile o non si voglia effettuare RMA sono possibili alcuni interventi per ridurre la possibilità che l'errore insorga. Nel forum di Phoronix a fine Agosto
un utente ha riassunto la situazione in maniera concisa. Tradotto qui in basso:
Interventi confermati avere qualche effetto- Disabilitazione µOP cache
Sembra rimuovere il problema o renderlo molto più difficile da osservare
- Disabilitazione SMT (symmetrical multithreading)
Aumenta il tempo fra un segfault all'altro da minuti ad ore
- Disabilitazione funzionalità ASLR del kernel (Address Space Layout Randomization)
Simile alla precedente
Interventi che potrebbero funzionare per alcuni utenti, ma non per altri- Disabilitazione profili XMP e rilassamento clock/timing delle memorie a valori più sicuri
- Abilitazione LLC (Load Line Calibration)
- Aumento tensione SoC della CPU
Mister D
in questo stesso thread consiglia:
Quote:
Originariamente inviato da Mister D
Certamente, io cmq farei così:
1) disabiliterei kernel ASRL
2) userei LLC per trovare il miglior settaggio che faccia droppare meno la cpu, cioè in test come prime95 occt ecc quando la cpu va in full deve perdere meno di 0,05 volt
3) non userei XMP (che è una tecnologia intel per profili ram su MC intel) e imposterei in manuale la ram abbassando se mai la frequenza
4) imposterei il vsoc tra 1 volt e 1,15 volt.
Se anche così tutto a def (che vuol dire tenere boost, smt attivo, vcore auto e impostazioni "optimized defualt setting" caricata) il test mi da errore farei rma con amd.
|
Alcuni utenti in questa discussione hanno avuto qualche successo
aumentando la tensione di SoC a 1.2V (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (
1,
2).
In un altro caso, un esemplare prodotto in data 1734 (acquistato da Amazon) sembrava dare sporadici segfault ad impostazioni di default, ma impostare vSoC a 1.1V sembra avere risolto il problema.
In un caso la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.