[Discussione] AMD Ryzen - problematiche di Segmentation Fault (segfault)

[s12a]

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:

• 2017-06-02 - Some Ryzen Linux Users Are Facing Issues With Heavy Compilation Loads
• 2017-08-04 - Ryzen-Test & Stress-Run Make It Easy To Cause Segmentation Faults On Zen CPUs
• 2017-08-07 - AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR
• 2017-08-24 - New Ryzen Is Running Solid Under Linux, No Compiler Segmentation Fault Issue
• 2017-09-13 - AGESA 1.0.0.6b Might Fix The Ryzen Linux Performance Marginality Problem

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:

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:

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 "Manufacturing 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:

Originariamente inviato da metal master

(Nota del 2017-10-21 di s12a: le istruzioni non sono più aggiornate alle ultime novità, come scritto sopra: se si usa Ubuntu 17.10 occorre usare una versione diversa del test disponibile qui: https://github.com/Oxalin/ryzen-test)



io per verificare l'errore sotto linux ho fatto cosi

1-ho inserito nel pc la mia chiavetta da 8gb
2-ho scaricato la iso di ubuntu qua: https://www.ubuntu-it.org/download
3-ho scaricato rufus: https://rufus.akeo.ie/downloads/rufus-2.17.exe
4-ho aperto rufus e selezionato l'iso di ubuntu creando una penna usb bootable
5-ho riavviato il pc con la penna inserita, ho selezionato come unita di boot la penna e poi ho scelto di non installare ubuntu ma di far partire la live.
6-una volta sotto ubuntu ho scaricato questo test: https://github.com/suaefar/ryzen-test e una volta scompattata la cartella sul deskop ho fatto partire il terminale dando poi il comando "./kill-ryzen.sh"
7.questo il risultato:
https://s25.postimg.org/7tw6yql73/image.png
https://s25.postimg.org/z4hi6x3m7/image.png
https://s25.postimg.org/4zt1ll8tr/image.png
https://s25.postimg.org/qnhzvm1dr/image.png

una volta segnalati gli screen al supporto tecnico amd, hanno autorizzato l'rma e domani dovrebbe passare il corriere per spedire il pacco in olanda.

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:

1. http://www.hwupgrade.it/forum/showpo...ostcount=19455 (Inizio)
2. http://www.hwupgrade.it/forum/showpo...ostcount=19609
3. http://www.hwupgrade.it/forum/showpo...ostcount=19668
4. http://www.hwupgrade.it/forum/showpo...&postcount=250
5. http://www.hwupgrade.it/forum/showpo...&postcount=524 (Fine)
6. http://www.hwupgrade.it/forum/showpo...&postcount=531 (Dettagli aggiuntivi)

RMA oppure no?
Opinione personale. In un commento di questa discussione io concludevo così:

Originariamente inviato da s12a

• 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:

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.

[s12a]

Post di servizio.

[Mister D]

Ottimo Ti recupero tutti i link di proronix, non del forum, proprio gli articoli con la risposta di amd data al loro redattore.

EDIT: eccoli in ordine cronolgico:
https://www.phoronix.com/scan.php?pa...-Segv-Response
https://www.phoronix.com/scan.php?pa...en-fixed&num=1
https://www.phoronix.com/scan.php?pa....0.0.6b-Update
aggiungo questo di reddit dove un'utente dimostra che nonostante agesa 1.0.06b il problema c'è ancora sulla sua cpu, a conferma che non è bug hardware in senso stretto risolvibile via fix bios con workaroung ma solo nuovo quality test di selezione cpu:
https://www.reddit.com/r/Amd/comment...q0&sh=acc76828

[metal master]

questo è il link alla discussione del problema, nella community ufficiale di amd: https://community.amd.com/thread/215773

[doctor who ?]

Ne è affetta tutta la famiglia dei ryzen ?

Sto assemblando un pc con un ryzen 1200, ho appena visto ed è 1724, preso su amazon

Originariamente inviato da doctor who ?

Ne è affetta tutta la famiglia dei ryzen ?

Sto assemblando un pc con un ryzen 1200, ho appena visto ed è 1724, preso su amazon

Si, devi fare il test e controllare.

[evil weasel]

Vedo che qualcuno si è fatto convincere ad aprire un thread separato.
Sarebbe il caso che venisse messo anche come sticky nella sezione Processori e soprattutto che fosse linkato nel primo post del thread ufficiale delle CPU Ryzen.

[Spitfire84]

...in condizioni di carico di tutti i core...

Il mio ha dato errore compilando su un solo core.

[s12a]

Originariamente inviato da Spitfire84

Il mio ha dato errore compilando su un solo core.

Addirittura solo con un core? Questo non sarebbe più una condizione di carico intensivo non facilmente osservabile in situazioni ordinarie. Non è che magari in questi casi sia un core in particolare a provocare il problema? Si intende sempre senza overclock, giusto?

[Spitfire84]

Originariamente inviato da s12a

Addirittura solo con un core? Questo non sarebbe più una condizione di carico intensivo non facilmente osservabile in situazioni ordinarie.

il test con le Gigabyte gira su più di un core solo se si cambia il kernel; io non l'ho cambiato, c'ha messo quasi mezz'ora, ma alla fine mi ha dato l'errore, per cui il carico su tutti i core non è una condizione necessaria per replicare l'errore.

Non è che magari in questi casi sia un core in particolare a provocare il problema?

Non saprei, ma se fosse sono stato fortunato a beccare quello che dà problemi.

Si intende sempre senza overclock, giusto?

ovviamente si, ho riportato la cpu a default. Solo le ram erano a 3200 MHz con timing a default, ma sono certificate ed ho fatto ore di memtest senza errori quindi non hanno problemi di stabilità.

Ho chiesto la sostituzione ad AMD, vediamo cosa mi rispondono.

[s12a]

Originariamente inviato da Spitfire84

Non saprei, ma se fosse sono stato fortunato a beccare quello che dà problemi.

I core non vengono normalmente usati a rotazione?

ovviamente si, ho riportato la cpu a default. Solo le ram erano a 3200 MHz con timing a default, ma sono certificate ed ho fatto ore di memtest senza errori quindi non hanno problemi di stabilità.

Ho chiesto la sostituzione ad AMD, vediamo cosa mi rispondono.

In teoria saresti comunque in overclock. Ufficialmente Ryzen supporta al massimo queste frequenze, anche se gli aggiornamenti successivi hanno migliorato la compatibilità:

Originariamente inviato da s12a

I core non vengono normalmente usati a rotazione?


In teoria saresti comunque in overclock. Ufficialmente Ryzen supporta al massimo queste frequenze, anche se gli aggiornamenti successivi hanno migliorato la compatibilità:

Il kernel ufficiale linux sulle Gigabyte riconosce un solo core, il core 0, in teoria.

[Spitfire84]

Originariamente inviato da s12a

In teoria saresti comunque in overclock. Ufficialmente Ryzen supporta al massimo queste frequenze, anche se gli aggiornamenti successivi hanno migliorato la compatibilità:

Ho sempre girato a 3200 MHz sulle ram fin dal primo bios rilasciato senza alcun problema, rispettando tutte le specifiche default delle ram. In più il mio Ryzen è della 7ima settimana per cui rietra tra quelli potenzialmente soggetti al baco.

Vediamo cosa mi risponde AMD.

[s12a]

Potrebbe essere interessante questo link:

https://community.amd.com/community/...lets-talk-dram

Beginning this month, as we promised to you, we began beta testing a new AGESA (v1.0.0.6) that is largely focused on aiding the stability of overclocked DRAM (>DDR4-2667).

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).

Alcuni utenti del forum di Gentoo comunque hanno verificato il problema anche con le memorie a 2133 MHz.

[scilvio]

un utente nel thread ufficiale di ryzen ha postato un link dove verificare dal SN sulla scatola la data di produzione http://amdsnv.amd.com/query.php purtroppo nel mio caso non trova nulla magari è utile come risorsa a qualcun'altro

[papugo1980]

Si l avevo postato sull' altra discussione...a quanto pare il.mio é stato prodotto il 10 maggio

[Spitfire84]

Reso autorizzato da AMD.

[malcom499]

[Imgur](https://i.imgur.com/dcHWs3J.png)


...ora che mi ero deciso a prendere un ryzen 1700 ....

[alexsky8]

Originariamente inviato da scilvio

un utente nel thread ufficiale di ryzen ha postato un link dove verificare dal SN sulla scatola la data di produzione http://amdsnv.amd.com/query.php purtroppo nel mio caso non trova nulla magari è utile come risorsa a qualcun'altro

Originariamente inviato da papugo1980

Si l avevo postato sull' altra discussione...a quanto pare il.mio é stato prodotto il 10 maggio

mettete il link nel messaggio iniziale potrebbe essere utile

http://amdsnv.amd.com/query.php

a me questa verifica da

MFG Date: 2017-09-05
sopra il processore ho settimana 33

quindi secondo questi calcoli la produzione delle CPU dovrebbe essere iniziata la terza settimana di gennaio

se qualcuno potesse verificare con altri dati sarebbe utile

[s12a]

Originariamente inviato da alexsky8

mettete il link nel messaggio iniziale potrebbe essere utile

http://amdsnv.amd.com/query.php

Linkata nel testo.

a me questa verifica da

MFG Date: 2017-09-05
sopra il processore ho settimana 33

Usando questo sito: https://www.timeanddate.com/date/weeknumber.html
Oppure la funzione WEEKNUM da Excel/Libreoffice Calc, risulta che la settimana di produzione dalla ricerca dal link sopra sia la numero 36, non 33. Le date dovrebbero essere correlate, ma non sono esattamente identiche.