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

View Full Version : [Discussione] AMD Ryzen - problematiche di Segmentation Fault (segfault)

Pagine : [1] 2 3 4

s12a

15-10-2017, 18:06

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 (http://www.hwupgrade.it/forum/showpost.php?p=45100152&postcount=8) (2 (http://www.hwupgrade.it/forum/showpost.php?p=45100243&postcount=10)) è 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 (http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/) e da Matt Dillon nel forum di Phoronix (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498).

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 (https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Compiler-Issues)
2017-08-04 - Ryzen-Test & Stress-Run Make It Easy To Cause Segmentation Faults On Zen CPUs (https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run)
2017-08-07 - AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR (https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response)
2017-08-24 - New Ryzen Is Running Solid Under Linux, No Compiler Segmentation Fault Issue (https://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1)
2017-09-13 - AGESA 1.0.0.6b Might Fix The Ryzen Linux Performance Marginality Problem (https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update)
I primi report pubblici dello stesso risalgono ad Aprile 2017 nel forum della distribuzione Linux Gentoo (https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-postorder-asc-start-0.html) (thread correlato (https://forums.gentoo.org/viewtopic-t-1069652-start-125-postdays-0-postorder-asc-highlight-.html)). C'è anche un thread dedicato, ancora attivo, nel forum di community support ufficiale AMD (https://community.amd.com/thread/215773), 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 (http://www.hwupgrade.it/forum/showpost.php?p=45125200&postcount=502) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45112479&postcount=260), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45112567&postcount=262), 3 (http://www.hwupgrade.it/forum/showpost.php?p=45117879&postcount=390); settimana 34 / 1734: 1 (http://www.hwupgrade.it/forum/showpost.php?p=45107102&postcount=100), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45107327&postcount=106), 3 (http://www.hwupgrade.it/forum/showpost.php?p=45117879&postcount=390)), 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 (https://it.wikipedia.org/wiki/Errore_di_segmentazione):
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 (https://forums.gentoo.org/viewtopic-p-8052348.html?sid=59a27fcbaf26e4dbf3652ecddc322162#8052348), usare memorie DDR4 ad una velocità superiore rispetto a quanto ufficialmente supportato dal processore (2667 MHz con due moduli single ranked. Leggere questa slide (https://i.imgur.com/ObjVRpJ.png) o le specifiche tecniche dal sito web AMD (http://products.amd.com/en-us/search?k=DesktopProcessors#Default=%7B%22k%22%3A%22ryzen%20-threadripper%22%2C%22r%22%3A%5B%7B%22n%22%3A%22PlatformOWSCHCM%22%2C%22t%22%3A%5B%22%5C%22%C7%82%C7%824465736b746f70%5C%22%22%5D%2C%22o%22%3A%22OR%22%2C%22k%22%3Afalse%2C%22m%22%3A%7B%22%5C%22%C7%82%C7%824465736b746f70%5C%22%22%3A%22Desktop%22%7D%7D%5D%7D)) può essere considerabile overclock, anche se successivi aggiornamenti firmware (https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram) hanno migliorato il supporto a velocità superiori. A ribadire ciò, Robert Hallock di AMD riporta null'ultimo link (https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram):
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 (http://www.hwupgrade.it/forum/showpost.php?p=45127783&postcount=529) è stato la causa di segfault. Leggere in particolare questo commento di Mister D (http://www.hwupgrade.it/forum/showpost.php?p=45127876&postcount=532) 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 (https://i.imgur.com/YbDMpkk.png), 2 (https://i.imgur.com/0w7EXWw.png)) 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 (https://www.reddit.com/r/Amd/comments/6scnlg/ryzen_reading_your_production_batch_number/) 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.

https://i.imgur.com/J3WY1He.png

Papugo80 riporta (http://www.hwupgrade.it/forum/showpost.php?p=45100486&postcount=20544) che è possibile verificare il periodo di produzione effettuando una interrogazione online (http://amdsnv.amd.com/query.php) del codice seriale stampato sulla confezione del processore. La voce "MFG Date" (definizione standard (https://www.quora.com/Why-is-MFG-used-as-short-form-for-manufactured-when-the-letter-G-doesnt-come-in-the-word) per "Manufacturing Date"), come lo screenshot mostra (https://i.imgur.com/gfI7REL.png), 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 (http://www.hwupgrade.it/forum/showpost.php?p=45100556&postcount=15). Sembra inoltre che possano essere possibili discrepanze (1 (http://www.hwupgrade.it/forum/showpost.php?p=45100672&postcount=20), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45100719&postcount=24)) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45099794&postcount=20531).

https://i.imgur.com/UrKRtCP.png

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 (http://www.hwupgrade.it/forum/showpost.php?p=45108205&postcount=134), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45108593&postcount=141)).

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 (http://www.hwupgrade.it/forum/showpost.php?p=45100908&postcount=37), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45100939&postcount=39), 3 (http://www.hwupgrade.it/forum/showpost.php?p=45101001&postcount=40)) con un errore di segfault come mostrato nel seguente screenshot. Sono possibili anche errori di invalid opcode (esempio da Phoronix e HWUpgrade (http://www.hwupgrade.it/forum/showpost.php?p=45108793&postcount=147)) o di general protection (qui (http://www.hwupgrade.it/forum/showpost.php?p=45114047&postcount=323)). È stato riportato che può talvolta impiegarci anche qualche ora (continuativa) o che gli errori potrebbero non uscire fuori in maniera regolare (http://www.hwupgrade.it/forum/showpost.php?p=45100782&postcount=29) (un altro report simile qui (http://www.hwupgrade.it/forum/showpost.php?p=45114198&postcount=328) e potenzialmente anche qui (http://www.hwupgrade.it/forum/showpost.php?p=45113832&postcount=320)). 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.

https://i.imgur.com/LMoeZ40.png

Nota 1: un possibile punto di confusione (http://www.hwupgrade.it/forum/showpost.php?p=45102369&postcount=70) (anche qui (http://www.hwupgrade.it/forum/showpost.php?p=45114725&postcount=344)) è 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 (http://www.hwupgrade.it/forum/showpost.php?p=45111047&postcount=225). È possibile cambiare le impostazioni di avvio di ryzen-test per prevenire interruzioni correlate; la sezione "requirements" (https://github.com/Oxalin/ryzen-test#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 (http://www.hwupgrade.it/forum/showpost.php?p=45112174&postcount=258) che mostra in dettaglio (usando una Virtual Machine) un test fallito per motivi diversi dal segfault. Avvisi di "interrupt took too long" (spiegazione qui (http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309)) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45108749&postcount=146). 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 (http://www.hwupgrade.it/forum/showpost.php?p=45110515&postcount=203) 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 (https://github.com/Oxalin/ryzen-test), 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:

(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/showpost.php?p=44784009&postcount=11258

È possibile effettuare un test simile direttamente da Windows con kill-ryzen-win (https://github.com/corngood/kill-ryzen-win), ma dalla discussione in questo thread su Reddit (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j8tw1usg&sh=e653ba6f) 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 (https://github.com/corngood/kill-ryzen-win/wiki/Crash-Notes). Ho postato istruzioni dettagliate passo-passo su come eseguire il test su windows con kill-ryzen-win in questo commento (http://www.hwupgrade.it/forum/showpost.php?p=45125200&postcount=502). 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 (http://www.hwupgrade.it/forum/showpost.php?p=45103092&postcount=77)), 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) (https://www.reddit.com/r/Amd/comments/6zfvcp/ryzen_segmentation_fault/dmvnh00/?st=j8txkhn1&sh=d7410e3f), o con script simili a Ryzen-test che usano Microsoft Visual Studio (MSVC) come ad esempio il precedentemente menzionato kill-ryzen-win (https://github.com/corngood/kill-ryzen-win). Sembra inoltre che (https://community.amd.com/message/2823568#comment-2823568) 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 (https://www.pcworld.com/article/3124306/hardware/dont-call-amds-upcoming-zen-chip-a-cpu.html), 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 (https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr/page15) 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 (https://github.com/ClusterM/hakchi2/issues/620), 2 (https://github.com/ClusterM/hakchi2/issues/728), 3 (https://github.com/ClusterM/hakchi2/issues/825), 4 (https://www.reddit.com/r/nesclassicmods/comments/65sn6p/hakchi2_v216/dgddbqw/?st=j8u1slg1&sh=240e494b)). Un report qui su HWUpgrade (http://www.hwupgrade.it/forum/showpost.php?p=45132966&postcount=594) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45100810&postcount=34), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45100827&postcount=20548)) ce ne sono anche altri in forum internazionali (esempio nel forum ASUS ROG (https://rog.asus.com/forum/showthread.php?96420-1700-C6H-OC-quot-bug-consistency-quot-issues-manufacturing-date-linked), oppure questa discussione su Reddit (https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/?st=j8vanxyl&sh=68e88c78), riassunti in questo commento su HWUpgrade (http://www.hwupgrade.it/forum/showpost.php?p=45105445&postcount=83)) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45092959&postcount=20292), 2 (http://www.hwupgrade.it/forum/showthread.php?p=45098073#post45098073), 3 (http://www.hwupgrade.it/forum/showpost.php?p=45098108&postcount=20442), 4 (http://www.hwupgrade.it/forum/showpost.php?p=45101277&postcount=20564), ma anche questo (http://www.hwupgrade.it/forum/showpost.php?p=45110042&postcount=20794) con un 1700 non-X prodotto il 1715 ricevuto il 2017-10-19). Internazionalmente parlando (https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue?p=972847#post972847), 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 (https://www.reddit.com/r/Amd/comments/6zz3pe/agesa_1006b_might_fix_the_ryzen_linux_performance/?st=j88lovq0&sh=acc76828)) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45111862&postcount=250)) quello vecchio ad uno dei loro centri di assistenza (tuttavia ad alcuni utenti, come ad esempio Evil weasel (http://www.hwupgrade.it/forum/showpost.php?p=45105655&postcount=86) oppure Debern9093 (http://www.hwupgrade.it/forum/showpost.php?p=45122753&postcount=454) od Ozozuz (http://www.hwupgrade.it/forum/showpost.php?p=45125867&postcount=507) 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/showpost.php?p=45062725&postcount=19455 (Inizio)
http://www.hwupgrade.it/forum/showpost.php?p=45068822&postcount=19609
http://www.hwupgrade.it/forum/showpost.php?p=45070991&postcount=19668
http://www.hwupgrade.it/forum/showpost.php?p=45111862&postcount=250
http://www.hwupgrade.it/forum/showpost.php?p=45127733&postcount=524 (Fine)
http://www.hwupgrade.it/forum/showpost.php?p=45127854&postcount=531 (Dettagli aggiuntivi)

RMA oppure no?
Opinione personale. In un commento (http://www.hwupgrade.it/forum/showpost.php?p=45114852&postcount=351) di questa discussione io concludevo così:
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 (https://www.reddit.com/r/Amd/comments/74y4wv/still_getting_segfaults_after_warranty_claim/do2leei/?st=j8t00xmx&sh=50f3f0fa) secondo cui lo stesso si può manifestare con un processore prodotto nella 26esima settimana. Secondo un altro (https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/?st=j8ucho13&sh=158f74a5), un processore prodotto durante la 33esima e tornato indietro da RMA continua a farlo. In questa lista (https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0) 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 (http://www.hwupgrade.it/forum/showpost.php?p=45103525&postcount=81) 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 (https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue?p=973122#post973122). 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 (http://www.hwupgrade.it/forum/showpost.php?p=45113196&postcount=291) consiglia:
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 (http://www.hwupgrade.it/forum/showpost.php?p=45111262&postcount=232) (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (1 (http://www.hwupgrade.it/forum/showpost.php?p=45112815&postcount=273), 2 (http://www.hwupgrade.it/forum/showpost.php?p=45113151&postcount=287)). In un altro caso (http://www.hwupgrade.it/forum/showpost.php?p=45127973&postcount=534), 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 (http://www.hwupgrade.it/forum/showpost.php?p=45131170&postcount=567) la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.

s12a

15-10-2017, 18:06

Post di servizio.

Mister D

15-10-2017, 18:29

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?page=news_item&px=Ryzen-Segv-Response
https://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1
https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.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/comments/6zz3pe/agesa_1006b_might_fix_the_ryzen_linux_performance/?st=j88lovq0&sh=acc76828

metal master

15-10-2017, 18:37

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

doctor who ?

15-10-2017, 18:56

Ne è affetta tutta la famiglia dei ryzen ?

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

moob1

15-10-2017, 19:19

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

15-10-2017, 20:53

Vedo che qualcuno si è fatto convincere ad aprire un thread separato. :D
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

15-10-2017, 20:56

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

Il mio ha dato errore compilando su un solo core.

s12a

15-10-2017, 21:31

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

15-10-2017, 21:46

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

15-10-2017, 21:53

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

https://i.imgur.com/ObjVRpJ.png

moob1

15-10-2017, 21:59

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

https://i.imgur.com/ObjVRpJ.png

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

Spitfire84

15-10-2017, 22:17

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

https://i.imgur.com/ObjVRpJ.png

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

16-10-2017, 06:29

Potrebbe essere interessante questo link:

https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-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 (https://forums.gentoo.org/viewtopic-p-8052348.html?sid=59a27fcbaf26e4dbf3652ecddc322162#8052348).

scilvio

16-10-2017, 07:56

papugo1980

16-10-2017, 08:02

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

Spitfire84

16-10-2017, 08:26

Reso autorizzato da AMD. :)

malcom499

16-10-2017, 08:31

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

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

alexsky8

16-10-2017, 08:32

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

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

16-10-2017, 08:42

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.

papugo1980

16-10-2017, 08:51

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

Ah ok
Vabe cmq il mio 1700 l ho testato a default ed é soggetto a bug
Ho richiesto la sostituzione all' ammazzone con un altro prodotto in una data più recente...
Vediamo un Po...

paolo.oliva2

16-10-2017, 08:57

Questi sono i miei proci. Entrambi sono anteriori alla 25a settimana.

Ho usato il link dando il SN sulla scatola senza andare sul procio.
http://amdsnv.amd.com/query.php

1700x

Serial Number:
Processor OPN: YD170XBCAEWOF
Packing Type: P
Delivery Date: 2017-05-10
MFG Date: 2017-04-28

1800X

Serial Number:
Processor OPN: YD180XBCAEWOF
Packing Type: P
Delivery Date: 2017-03-21
MFG Date: 2017-03-18

doctor who ?

16-10-2017, 08:57

Provato il mio 1200

17/24 sulla cpu
MFG Date: 2017-07-26 (che sarebbe la trentesima settimana ?)

Sarebbe potenzialmente fallato nel primo caso e potenzialmente pulito nel secondo o sbaglio ? :fagiano:

Alex656

16-10-2017, 08:59

...
Alcuni utenti del forum di Gentoo comunque hanno verificato il problema anche con le memorie a 2133 MHz (https://forums.gentoo.org/viewtopic-p-8052348.html?sid=59a27fcbaf26e4dbf3652ecddc322162#8052348).

Anche per me stessa cosa, con le ram a 2133 non cambia nulla, l'errore si presenta entro i 2 minuti.

Giusto per conoscenza vorrei riportare il link della notizia riportata su questo sito il giorno 8/8/2017 dove si ipotizzava un aggiornamento che in realtà avrebbe dovuto riguardare il firmware del processore tramite aggiornamento bios ma, a quanto pare, non si è potuta percorrere questa strada.
http://www.hwupgrade.it/news/cpu/un-bug-per-ryzen-in-abbinamento-a-linux-ma-amd-e-al-lavoro_70430.html

papugo1980

16-10-2017, 09:01

s12a

16-10-2017, 09:04

La procedura sotto win quanto va fatta girare per riscontrare il problema?

L'autore ha riportato che ci voleva qualche minuto sul suo sistema, ma anche che in altri ci mette più tempo, e che comunque sembra manifestarsi più velocemente su Linux. Altri utenti nello stesso thread hanno riportato che talvolta può magari accadere subito, ma poi continuare per ore senza mostrare nulla.

https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j8tw1usg&sh=e653ba6f

Giusto per conoscenza vorrei riportare il link della notizia riportata su questo sito il giorno 8/8/2017 dove si ipotizzava un aggiornamento che in realtà avrebbe dovuto riguardare il firmware del processore tramite aggiornamento bios ma, a quanto pare, non si è potuta percorrere questa strada.
http://www.hwupgrade.it/news/cpu/un-bug-per-ryzen-in-abbinamento-a-linux-ma-amd-e-al-lavoro_70430.html
L'ho menzionato nel post verso la conclusione ma non mi sono messo a linkare tutte le fonti che avevano riportato la notizia della possibile risoluzione con questo update.

Provato il mio 1200

17/24 sulla cpu
MFG Date: 2017-07-26 (che sarebbe la trentesima settimana ?)

Sarebbe potenzialmente fallato nel primo caso e potenzialmente pulito nel secondo o sbaglio ? :fagiano:
Credo che valga la data sulla CPU. La MFG Date potrebbe essere la data di imballaggio.

paolo.oliva2

16-10-2017, 09:04

papugo1980

16-10-2017, 09:14

Riguardo al test su Linux io l ho fatto 4 volte :
La prima e la seconda volta ha dato subito errore
La terza no infatti ero arrivato a 40 minuti e allora ho stoppato
La quarta volta anche subito l errore

doctor who ?

16-10-2017, 09:15

SpongeJohn

16-10-2017, 09:16

alexsky8

16-10-2017, 09:16

Chiedo se ci fosse la possibilità di creare una immagine da caricare su una penna e fare il boot e che lanci automaticamente la procedura.

Cioè... io mi sto perdendo... linux live da scaricare da una parte, una riga di comando da digitare... una bella immagine con stile DOS autoexec.bat? :D

è scritto in prima pagine di questa discussione, la procedura è abbastanza semplice se poi non hai una Gigabyte è ancor più semplice

Originariamente inviato da metal master Guarda i messaggi
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

papugo1980

16-10-2017, 09:20

Intendi proprio stoppato e riavviato ?

Si riavviato anche il pc

alexsky8

16-10-2017, 09:22

Ho.trovato questo link a riguardo di come cambiano anche a livello (di cpu fortunelle)
https://rog.asus.com/forum/showthread.php?96420-1700-C6H-OC-quot-bug-consistency-quot-issues-manufacturing-date-linked

stessa cosa con il mio vecchio 1700 settimana 16 avevo un andamento termico non costante e anomalo anche in idle oltre che voltaggi più alti e temperature superiori per carichi medio alti e ovviamente il bug linux (lo rilevava dopo pochi secondi)

con il mio ultimo 1700 settimana 33 no bug, temperature in idle stabili, temperature sotto carico medio alto inferiori di 7 e anche 10°C (sempre con dissipatore stock) e voltaggi inferiori del 10%

insomma sembrano 2 CPU differenti quindi controllate bene perchè CPU meno fortunate potrebbero essere una spia del problema

bagnino89

16-10-2017, 09:34

Ottimo thread, consiglio all'autore di chiedere ai moderatori di metterlo in evidenza.

CiccoMan

16-10-2017, 09:49

Ma il.test da Windows non è affidabile?

Inviato dal mio Pixel utilizzando Tapatalk

SpongeJohn

16-10-2017, 09:52

Ottimo thread, consiglio all'autore di chiedere ai moderatori di metterlo in evidenza.

^ concordo. Ottimo lavoro. :)

Per chi volesse saperlo anche il mio 1600X (settimana 17) va in segfault dopo pochi minuti. Ho provato sia con bios a default che per scrupolo con i miei settings (memoria a 3200 e timings del profilo safe by Stilt, configurazione che passa 200% di stabilità con 16 run di memtest a 850mb).

https://s1.postimg.org/868ywi5oi7/Screenshot_from_2017-10-16_08-24-22.png

Rma compilato dieci minuti fa. Mi tocca rispolverare il buldozzerino nel mentre :|

s12a

16-10-2017, 09:58

Ma il.test da Windows non è affidabile?

Dalla discussione in questo thread su Reddit (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j8tw1usg&sh=e653ba6f) 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 specifiche dell'autore riguardo i crash su Windows qui (https://github.com/corngood/kill-ryzen-win/wiki/Crash-Notes).

alexsky8

16-10-2017, 09:58

Ma il.test da Windows non è affidabile?

consiglio quello su Linux

con il test in Windows non mi dava errore dopo 20 minuti, in Ubuntu me lo dava dopo pochissimo loop 0 :D

http://i64.tinypic.com/2eb7aiw.png

papugo1980

16-10-2017, 10:13

rifatto anche io
http://thumbs.imagebam.com/ca/81/2a/8d6f75628354983.jpg (http://www.imagebam.com/image/8d6f75628354983)

Spitfire84

16-10-2017, 10:15

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

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

Se la cpu è stata prodotta di recente non avrai alcun problema ;) ...come in realtà non ne avrai se è stata prodotta prima (a meno che non lo usi sotto linux).

Tcx

16-10-2017, 10:20

Ottimo thread...

ho un 1700x di metà marzo (la settimana precisa non la so) perciò potenzialmente fallato...uso il pc sopratutto in linux (ma non ubuntu) e non mi ha mai dato problemi...per scrupolo ho eseguito 3 volte il test e nessun problema...

Specifico inoltre che la mia cpu non è molto fortunella visto che per i 3,8Ghz ha bisogno di 1,32v come vcore (per 3,9Ghz vuole 1,375v)...

Ovviamente i test li ho eseguiti a default (anzi la cpu la tengo a default ho fatto solo delle prove in oc per verificare come si comportava)...

s12a

16-10-2017, 10:43

Il negozio da cui ho preso il Ryzen5 1600 mi ha offerto in rma uno scambio con una cpu avente seriale UA 1732SUS.

Tutto questo in una settimanella, senza passare per amd, vado sul sicuro con lui ?
A rigor di logica, se il problema fosse semplicemente la settimana di produzione, non dovrebbero esserci problemi. Rimane però una piccola possibilità che i processori che AMD invia in sostituzione siano testati in maniera specifica da non mostrare il problema. Credo di aver letto altrove che chi ha ricevuto tali processori da AMD abbia riscontrato che la confezione non avesse i soliti sigilli, ma non ho una fonte precisa al momento della cosa.

mavvy

16-10-2017, 10:46

Sto provando a fare il test sotto una live ubuntu 17.04 e, nel momento di creare spazio Ram Disk, si blocca con errore tee: /sys/block/zram0/disksize: Device or resource busy Ho provato a disabilitare la ramdisk dallo script ma non mi fido del risultato, in quando si blocca ad un certo punto senza restituire errori di sorta. La chiavetta usata per la live è da 8gb. Come posso risolvere?

mavvy

16-10-2017, 10:53

Mister D

16-10-2017, 10:53

A rigor di logica, se il problema fosse semplicemente la settimana di produzione, non dovrebbero esserci problemi. Rimane però una piccola possibilità che i processori che AMD invia in sostituzione siano testati in maniera specifica da non mostrare il problema. Credo di aver letto altrove che chi ha ricevuto tali processori da AMD abbia riscontrato che la confezione non avesse i soliti sigilli, ma non ho una fonte precisa al momento della cosa.

A rigor di logica tutte le cpu che vengono testate con il nuovo test QA revisionato sono esenti da problema. Magari AMD, sapendo che quelle prodotte prima di una settimana non sono tutte da scartare (e questo lo ha espresso chiaramente al red di phoronix e diversi utenti lo testimoniano), usa anche cpu con settimane precedenti ma ritestate secondo il nuovo test e se la cpu è sana viene mandata al cliente. Ipotesi mia. Altrimenti prende tutte cpu prodotte dopo il cambio del quality test.

Un po' come gli HardDisk mandati in rma, non vi è mai capitato un hd ritornato con la scritta "Certified repaired" corrispondente al nostro rigenerato? Io sì. Non è proprio la stessa cosa ma AMD potrebbe usare lo stesso concetto e prendere una cpu antecedente al cambio test e ritestarla con le nuove specifiche.;)

alexsky8

16-10-2017, 10:54

.
.
.
.
Nota: a causa di incompatibilità con il kernel Linux fornito di default, alcune schede 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 (http://www.hwupgrade.it/forum/showpost.php?p=45099794&postcount=20531).

https://i.imgur.com/UrKRtCP.png
.
.
.

avevo letto di utenti che con la nuova Ubuntu 17.10 non vi siano più problemi con le Gigabyte o altre mobo

giovedì 19 rilasciano ufficialmente la 17.10 quindi consiglierei di attendere ancora qualche giorno

alexsky8

16-10-2017, 10:56

A rigor di logica tutte le cpu che vengono testate con il nuovo test QA revisionato sono esenti da problema. Magari AMD, sapendo che quelle prodotte prima di una settimana non sono tutte da scartare (e questo lo ha espresso chiaramente al red di phoronix e diversi utenti lo testimoniano), usa anche cpu con settimane precedenti ma ritestate secondo il nuovo test e se la cpu è sana viene mandata al cliente. Ipotesi mia. Altrimenti prende tutte cpu prodotte dopo il cambio del quality test.

Un po' come gli HardDisk mandati in rma, non vi è mai capitato un hd ritornato con la scritta "Certified repaired" corrispondente al nostro rigenerato? Io sì. Non è proprio la stessa cosa ma AMD potrebbe usare lo stesso concetto e prendere una cpu antecedente al cambio test e ritestarla con le nuove specifiche.;)

è per questo che non so fino a che punto sia meglio mandare direttamente ad AMD o farsi dare una CPU prodotta nelle ultime settimane quando lo stesso venditore si presta a fornirne una sigillata post 30esima settimana

s12a

16-10-2017, 11:05

A rigor di logica tutte le cpu che vengono testate con il nuovo test QA revisionato sono esenti da problema. Magari AMD, sapendo che quelle prodotte prima di una settimana non sono tutte da scartare (e questo lo ha espresso chiaramente al red di phoronix e diversi utenti lo testimoniano), usa anche cpu con settimane precedenti ma ritestate secondo il nuovo test e se la cpu è sana viene mandata al cliente. Ipotesi mia. Altrimenti prende tutte cpu prodotte dopo il cambio del quality test.

Potrebbe essere stato un difetto corretto in produzione in seguito al quale tutte le CPU prodotte oltre una certa data sono migliorate in maniera permanente, ma se è "solo" una questione di binning, non credo che sia sostenibile per l'azienda offire CPU selezionate al livello del 1800x o dei Threadripper a tutti coloro che fanno richiesta di RMA e gli altri nel canale retail, e/o continuare a farlo per un periodo di tempo prolungato.

evil weasel

16-10-2017, 11:11

Ma se al posto di usare ubuntu usassimo Fedora? Ha un kernel più aggiornato e non da problemi come invece fa ubuntu.

Mister D

16-10-2017, 11:29

Potrebbe essere stato un difetto corretto in produzione in seguito al quale tutte le CPU prodotte oltre una certa data sono migliorate in maniera permanente, ma se è "solo" una questione di binning, non credo che sia sostenibile per l'azienda offire CPU selezionate al livello del 1800x o dei Threadripper a tutti coloro che fanno richiesta di RMA e gli altri nel canale retail, e/o continuare a farlo per un periodo di tempo prolungato.

NO! Te lo escludo per vari motivi di logica:
1) te ne saresti accordo perché le nuove cpu avrebbero avuto un nuovo step produttivo e basta cpu-z per accorgersene
2) Threadripper, che è binnato al 5% cioè solo il 5% di ryzen 1800X diventano buoni per formare il MCM die di TR, hanno lo stesso step produttivo di ryzen e non presenta il bug ergo questo già basta a dire che è un problema di selezione cpu che di progettazione/produzione cpu.
3) EPYC ha un nuovo step ergo se fosse come ipotizzi avrebbero fatto presto e usato lo step più nuovo degli EPYC. Invece no.
4) se il difetto fosse stato produttivo allora TUTTE le cpu prima di una data avrebbero evidenziato il problema e costretto amd ad un richiamo (stile bug hardware fpu intel pentim 4) e utenti come DarkAngel e TCx non avrebbero cpu sane.

Ergo l'ipotesi più semplice è che il problema sia solo di selezione, come poi ha confermato AMD stessa.

s12a

16-10-2017, 11:45

[...] Ergo l'ipotesi più semplice è che il problema sia solo di selezione, come poi ha confermato AMD stessa.
Quindi dici che ad esempio processori che sarebbero dovuti essere magari Ryzen 3 1400 previa disabilitazione delle opportune parti sono diventati per errore Ryzen 7 1700 (e viceversa), o qualcosa su questa falsariga?

Ma se al posto di usare ubuntu usassimo Fedora? Ha un kernel più aggiornato e non da problemi come invece fa ubuntu.

Qualunque distribuzione funzioni con sicurezza. Ubuntu è in genere più familiare anche per chi non conosce Linux.
Se fra qualche giorno esce la 17.10 che risolve i problemi forse non c'è tutta questa necessità di cambiare, comunque.

CiccoMan

16-10-2017, 11:59

Infatti mi chiedevo: Se faccio il test, dopo quanto è lecito affermare che la cpu non è affetta dal difetto?

Mi sembra di capire che non ci sia un tempo definito... quindi che faccio, lascio la cpu sotto test per un giorno (sempre sia possibile... non conosco il bench)?

papugo1980

16-10-2017, 12:17

Guys, situazione anomala.
L'altro giorno avevo effettuato il test, 54 secondi e seg-fault.
Oggi dopo aver richiesto l'rma per scrupolo faccio nuovamente il test.. nada.
Ne da vm con 12thread 100% cap, ne da ubuntu live.
Che puó essere ?
La cpu é una delle primissime, comprata al day one, puó essere stato un falso errore ?
https://image.prntscr.com/image/7fb3GuN0Sc6z2FA9DJw-_g.png
Riavvia il pc e rifai il test ...pure a me mi ha fatto così una volta

s12a

16-10-2017, 12:44

Dimenticavo: cercando di modificare con Hackchi una SNES mini, durante la scrittura del kernel modificato va in errore. Su reddit scopro che chi ha questo problema ha cpu Ryzen, infatti con il notebook intel tutto fila liscio. A questo punto mi chiedo se sia correlato al bug, e magari se qualcuno di voi ha già una cpu "sana" ed un SNES mini da modificare... :D

Sembra che non tutti i processori AMD Ryzen abbiano il problema, dunque è possibile che sia causato dallo stesso che provoca segfault su Linux.

https://github.com/ClusterM/hakchi2/issues/620

Infatti mi chiedevo: Se faccio il test, dopo quanto è lecito affermare che la cpu non è affetta dal difetto?

Mi sembra di capire che non ci sia un tempo definito... quindi che faccio, lascio la cpu sotto test per un giorno (sempre sia possibile... non conosco il bench)?

Non credo sia necessario far lasciare andare il test per tutto questo tempo, almeno quello per Linux. Proverei come suggerito da Papugo sopra a riavviare e farlo ripartire un paio di volte dopo un'ora o circa di test senza risultati. Se continua a non succedere nulla allora con buone probabilità il processore non dovrebbe avere problemi.

Operapia

16-10-2017, 14:01

Il negozio da cui ho preso il Ryzen5 1600 mi ha offerto in rma uno scambio con una cpu avente seriale UA 1732SUS.

Tutto questo in una settimanella, senza passare per amd, vado sul sicuro con lui ?

Mi diresti in privato da quale negozio hai comprato per cortesia? Ancora non ho deciso dove mandarlo in rma
e se quello dove ho comprato io è lo stesso opterei per questa soluzione

andreamit

16-10-2017, 14:08

conoscete qualche shop online dove prendere un 1600x e andare sul sicuro senza rischiare di averne uno di una settimana vecchia?

Mister D

16-10-2017, 14:29

Quindi dici che ad esempio processori che sarebbero dovuti essere magari Ryzen 3 1400 previa disabilitazione delle opportune parti sono diventati per errore Ryzen 7 1700 (e viceversa), o qualcosa su questa falsariga?

Dico semplicemente che il test rev iniziale non assicurava una completa stabilità con la compilazione sotto linux: magari da qualche parte qualche transistor non era completamente stabile e restituisce un valore errato, un po' come con prime95 quando fai oc il test esegue la successione di numeri di mersenn e vede se i numeri calcolati dalla cpu sono validi o no, se non sono validi vuol dire che la cpu non è stabile ergo da qualche parte una serie di transistor scazza.
Detto questo e tenendo presente che 1) alcune cpu sono sane, 2) che la miglior selezione dei TR (5% di die dei ryzen) rende esenti tutte le cpu, mi viene da ipotizzare che il nuovo test qualità oltre verificare i requisiti elettrici e di potenza (tipo vid e frequenze per ogni power state) verifica anche questo problema sotto linux oppure già rivedendo le tolleranze su le tensioni/frequenze/latenze di commutazione hanno risolto e tutte le cpu vengono fuori esenti da questo bug e non solo il 5% + una parte del restante 95%.
Sul fatto che dei ryzen 3 possano diventare ryzen 7 direi che ho seri dubbi. AMD usa un solo die composto da 2 ccx con 2 core e poi a seconda della qualità dei core decide di farli diventare:
ryzen 7 -> 2 CCX con 4 core attivi e che rispettino le tolleranze per 1800X, 1700X e 1700
ryzen 5 6 core -> 2 CCX con uno completamento attivo e uno con 2 core disattivi che rispettino le tolleranze per 1600X e 1600
ryzen 5 4 core -> 2 CCX attivi con 2 core disattivi che rispettino le tolleranze per 1500X e 1400
ryzen 3 4 core SMT disattivo -> idem come sopra.

Viene da se che magari dei ryzen 7 che su un solo core non rispettavano le tolleranze sui consumi e TDP sono diventati dei ryzen 5 o 3 ma che dei 3 possano essere stati selezionati per sbaglio e diventati dei 7 è a rigor di logica impossibile, perché è una catena a scendere.
ryzen 7 migliori caratteristiche
ryzen 5 un po' meno
ryzen 3 un po' meno ancora

Poi per mantenere il giusto volume si potrebbe ipotizzare che dopo svariati mesi (quando le rese aumentano automaticamente perché il processo litografico migliora) magari AMD invece di tagliare i ryzen 3 prende dei ryzen 5 che avrebbero passato la selezione e li usa lo stesso come 3. In tal caso per amd perde denaro.

Io infatti mi aspetto che appena usciranno le APU raven ridge i ryzen 3 magari spariscano proprio di listino. Avrebbe senso per non sprecare die buoni per essere dei ryzen 5;)

Spero che ti sia di chiarimento come avviene il processo di selezione delle cpu e così fa pure intel con le debite differenze architetturali. Fanno come i contadini: del maiale non si butta via niente :asd:

s12a

16-10-2017, 15:08

Sul fatto che dei ryzen 3 possano diventare ryzen 7 direi che ho seri dubbi. AMD usa un solo die composto da 2 ccx con 2 core e poi a seconda della qualità dei core decide di farli diventare:
ryzen 7 -> 2 CCX con 4 core attivi e che rispettino le tolleranze per 1800X, 1700X e 1700
ryzen 5 6 core -> 2 CCX con uno completamento attivo e uno con 2 core disattivi che rispettino le tolleranze per 1600X e 1600
ryzen 5 4 core -> 1 CCX attivo con 4 core e uno disattivo che rispettino le tolleranze per 1500X e 1400
ryzen 3 4 core SMT disattivo -> idem come sopra.

Qui è riportato che i Ryzen 3 hanno comunque 2 CCX. :
https://www.anandtech.com/show/11658/the-amd-ryzen-3-1300x-ryzen-3-1200-cpu-review

In order to get down to four cores from eight, AMD has two possible solutions each with their pros and cons:

- Cut off one CCX, and leave one CCX available (4+0)
- Disable two cores per CCX, leaving two cores per CCX (2+2)
- Disable one core in one CCX, and three cores in the other CCX (1+3)

[...]

With Number 2, the main advantage is going to be with thermals – with two CCXes in play with some silicon between them, the chip can run cores on opposite ends at a much higher power each without affecting each other as much, leading to potentially higher performance. The downside is core-to-core latency, as the CPU would have extended latency between neighboring cores and those in the different CCX, and it goes back to the non-uniform memory access argument with the Ryzen 7 CPUs.

AMD decided to go with the 2+2 arrangement for the quad core Ryzen parts, following on from the 3+3 arrangement on the hex-core Ryzen 5 CPUs.

Mi ricordo le discussioni di utenti su Techpowerup che avrebbero voluto un processore con un singolo CCX per eliminare i problemi di latenza:
https://www.techpowerup.com/235529/amd-announces-the-ryzen-3-series-desktop-processors

Spero che ti sia di chiarimento come avviene il processo di selezione delle cpu e così fa pure intel con le debite differenze architetturali. Fanno come i contadini: del maiale non si butta via niente
Mi è chiaro come il binning funzioni, mi sembra strano che la risoluzione di eventuali problemi dello stesso renda a costo zero molte delle nuove CPU prodotte (tutte?) significativamente migliori delle precedenti (almeno secondo i report degli utenti) quanto a tensioni e temperature.

Se questo è la nuova normalità, benissimo! Se AMD invece sta vendendo processori selezionati generalmente molto meglio di quanto faceva prima per evitare il problema, vuol dire che ora ci saranno più scarti che andranno usati da qualche parte. I Ryzen 7 1700, dove si può manifestare, sono già i modelli con le frequenze base più basse.

Dato che tutti i processori Ryzen hanno 2 CCX - stando a quanto riportato nelle review dai siti maggiori - non escludevo problemi di selezione "random".

Tutto ciò fra le altre cose è indirettamente validato dal fatto che chi è in OC a quanto pare non risente del problema, perché chi è in OC ovviamente stresstesta la CPU con la coppia tensione/frequenza scelta e se non lo fa altrettanto ovviamente non da la colpa alle tensioni di default ma cerca quelle stabili.
Su Phoronix un utente ha riportato (https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr/page15) che alzando il vcore aveva risolto, anche se alla fine ha fatto comunque richiesta di sostituzione. Mi chiedo se qualcuno qui con il problema abbia già provato.

papugo1980

16-10-2017, 15:12

A me l errore lo da anche in oc

s12a

16-10-2017, 15:19

A me l errore lo da anche in oc

Ed alzando solo Vcore e Vsoc senza aumentare la frequenza (o addirittura diminuendola leggermente)?

Gioz

16-10-2017, 15:29

Mi è chiaro come il binning funzioni, mi sembra strano che la risoluzione di eventuali problemi dello stesso renda a costo zero molte delle nuove CPU prodotte (tutte?) significativamente migliori delle precedenti (almeno secondo i report degli utenti) quanto a tensioni e temperature.
il problema potrebbe essere legato ad uno dei controller del soc, considerato come lo si "scatena".
è possibile che per questo potenzialmente siano affette cpu di ogni serie ed in questo senso per selezione potrebbe non essere intesa la coppia frequenza/tensione dei core quanto invece un controllo più oculato sull'uncore che probabilmente inizialmente non era fatto adeguatamente - ovviamente parlo per ipotesi dato che come fisicamente emerga il guaio non è dichiarato nello specifico.
se così fosse, ed escludendo che sia architetturale (altrimenti tutti i chip lo presenterebbero) credo che semplicemente entri in gioco l'accordo/contratto con GF ed AMD si possa rivalere sulla fonderia classificando il pezzo come fallato in quanto non rispetta le specifiche tecniche - ma non conosco approfonditamente gli aspetti commerciali della questione -.

papugo1980

16-10-2017, 15:30

Non ho provato a modificare i voltaggi che avevo impostato per l OC dato che avevo superato 4 ore di Occt linpack ho dato per scontato che il sistema fosse stabile..cmq proverò
Ma la cosa é strana che funzioni dato che a default il voltaggio sul vcore lo spara bello alto già di suo

Operapia

16-10-2017, 15:48

conoscete qualche shop online dove prendere un 1600x e andare sul sicuro senza rischiare di averne uno di una settimana vecchia?

Sinceramente no. Poi il 1600x non è il più gettonato. I fondi di magazzino sono più probabili.

Operapia

16-10-2017, 15:55

stessa cosa con il mio vecchio 1700 settimana 16 avevo un andamento termico non costante e anomalo anche in idle oltre che voltaggi più alti e temperature superiori per carichi medio alti e ovviamente il bug linux (lo rilevava dopo pochi secondi)

con il mio ultimo 1700 settimana 33 no bug, temperature in idle stabili, temperature sotto carico medio alto inferiori di 7 e anche 10°C (sempre con dissipatore stock) e voltaggi inferiori del 10%

insomma sembrano 2 CPU differenti quindi controllate bene perchè CPU meno fortunate potrebbero essere una spia del problema

Sembra tu stia parlando del mio 1600x:(

Giorgio G

16-10-2017, 16:28

Scusate ho fatto il test su ubuntu, dopo che è partito, dopo circa 5 minuti, è arrivato al "loop 15" e poi si è fermato, ho aspettato un po ma non si è più mosso da lì, è normale?

https://s1.postimg.org/13uyg7wdqj/image.png (https://postimg.org/image/13uyg7wdqj/) https://s1.postimg.org/1ie5l99wkr/image.png (https://postimg.org/image/1ie5l99wkr/)

sotto win (kill-ryzen-win-master) andava avanti all'infinito, o almeno fino quando andava in errore, su ubuntu come dicevo sopra una volta che è arrivato al loop 15 mi si ferma.

papugo1980

16-10-2017, 16:36

Non ti fa l errore

s12a

16-10-2017, 18:31

Stavo leggendo rapidamente il thread del problema nel community forum AMD. Se si può riprodurre usando Cygwin da Windows come riportato nel messaggio #1471 qui sotto (il linking diretto non sembra funzionare correttamente), non dovrebbe essere più comodo così che usare una distribuzione live di Linux?

https://community.amd.com/message/2823568#comment-2823568

The issue is reproducible in Windows. If you have an affected CPU, install cygwin and start compiling stuff. The kill-ryzen script, with a few minor tweaks, works just as well in cygwin on Windows as it does in Linux for the purposes of generating a build failure during gcc compilation. It took a little longer to reproduce the issue under Windows, but it's still there. Taxing affected CPUs in a particular way makes the result unreliable.

Mister D

16-10-2017, 19:27

Qui è riportato che i Ryzen 3 hanno comunque 2 CCX. :
https://www.anandtech.com/show/11658/the-amd-ryzen-3-1300x-ryzen-3-1200-cpu-review

Sì errore mio, non so come ma ho scritto diverso da come l'avevo pensato (ora oltre la memoria, la disgrafia:doh: ).
Sia ryzen 5 1500X e 1400 che ryzen 1300X e 1200 hanno 2 CCX con 2 core attivi ciascuno e solo i 3 con smt disattivo.
Chissà perché ho scritto così:help:

Giorgio G

16-10-2017, 19:33

s12a

16-10-2017, 20:05

Bene, ma è normale che arriva al 15 loop e poi si ferma? Lo deve fare?
Credo che indichi semplicemente il numero di thread occupati a compilare in continuazione (in loop continuo). 0-15 = 16 thread, come quelli del tuo processore. Se dal "System Monitor" di Ubuntu l'occupazione del processore rimane al 100% e continui a vedere processi (credo "make") venire creati e terminati dopo un po', sta facendo quello che deve fare. Se ci sono segfault, terminerà con un errore.

Il test può anche continuare fino a che la memoria non viene completamente occupata (poiché effettua ad impostazioni di default la compilazione in un ramdisk); mi sembra ci vogliano entro 30 e 60 minuti con 16 GB.

papugo1980

16-10-2017, 20:14

Puoi verificare che sta ancora lavorando(quindi non é fermo a 15) aprendo monitor in ubuntu cbe sarebbe una sorta dibtaak manager

Giorgio G

16-10-2017, 20:46

Credo che indichi semplicemente il numero di thread occupati a compilare in continuazione (in loop continuo). 0-15 = 16 thread, come quelli del tuo processore. Se dal "System Monitor" di Ubuntu l'occupazione del processore rimane al 100% e continui a vedere processi (credo "make") venire creati e terminati dopo un po', sta facendo quello che deve fare. Se ci sono segfault, terminerà con un errore.

Il test può anche continuare fino a che la memoria non viene completamente occupata (poiché effettua ad impostazioni di default la compilazione in un ramdisk); mi sembra ci vogliano entro 30 e 60 minuti con 16 GB.

Ho controllato come mi hai detto dal Monitor di Sistema, confermo quello che hai detto :)
Grazie anche per la spiegazione, non ho errori :D

Puoi verificare che sta ancora lavorando(quindi non é fermo a 15) aprendo monitor in ubuntu cbe sarebbe una sorta dibtaak manager

Come sopra, grazie anche a te :)

evil weasel

16-10-2017, 21:36

Edit2: Visto che non c'é 2 senza 3 ho fatto subito dopo un riavvio ed un altro test, ora di nuovo sembra reggere.
Aiut ? :stordita:

Usa un'altra distro come ad esempio fedora.

s12a

17-10-2017, 05:08

Diversi post fa (http://www.hwupgrade.it/forum/showpost.php?p=45101125&postcount=44) avevo menzionato di ricordare di avere letto utenti scrivere che il loro processore ritornato da RMA sembrava stato essere pre-testato manualmente. Erano report dal forum di community support AMD.

https://community.amd.com/message/2821180#comment-2821180

Today my exchange processor arrived.(R5 1600X) BUT without stickers "passed" or something like that. Completely sealed! So AMD probably declared this whole batch to be faultless. I did some short tests (just 30 min. ,the old one produced segfaults always after 80 sec.), I'm not going to make long term tests, I'm not going to let it exchange again. On default settings and also RAM on XMP 2666, no errors occurred and everything is stable, so far. I'd say the new one's OK. The old one had really everything, segfaults, crashes, freezes, mce errors...

https://community.amd.com/message/2821210#comment-2821210

I have received replacement CPU from AMD. Whole RMA process took exactly one calendar week here in Europe.
I received fully sealed retail package from AMD, no sticky notes about "passed" or the like, BUT I inspected CPU carefully and I'm quite sure that it was opened before sending to me. Firstly, an "opening corner" was bent (e.g. opened before) on a small little plastic box where CPU is packaged, secondly, on the CPU itself there were traces of thermal paste. Traces were on CPU pins, which is quite unusual, even putting CPU on paper sheet left tiny traces of paste. I cleaned that up, all is fine
Why I'm telling You this - it seems that AMD is actually testing the chips before sending them to us, whether they put a sticker on the package or not seems to be optional.

https://community.amd.com/message/2821233#comment-2821233

was there a sticker on the bottom?* On mine, the top was sealed but the bottom didn't have a sticker like the retail units.

https://community.amd.com/message/2821284#comment-2821284

I've had my new RMA'd 1700 ( 1730SUS) for a week now. I've only compiled gcc for about 12 hours, but no errors.
*
My replacement had no sticker on the bottom and no note. It also has some discoloration on the corners of the lid which appeared to be thermal compound residue. It wouldn't come of with 70% alcohol. No big deal though.

https://community.amd.com/message/2821376#comment-2821376

Sticker was on top only (w/ AMD hologram and QR code), like retail.
It's good You asked, because I checked bottom and it seems that the big box was opened from bottom side
*
Actually AMD did great, testing each unit, thumbs up

https://community.amd.com/message/2824435#comment-2824435

Got my RMA CPU today. It's a Ryzen 1700 with batch code UA1733SUS. Running it on a Crosshair VI Hero; will be running compilation tests over the next few days. Will add my results to this post (or a later one if there's significant discussion between then and now). There wasn't any visible opening of the box or residue on the CPU -- it seemed completely sealed. There is, however, a notable circle shaped dip in the lower left on the heatspreader (img). The support person who helped me said he'd get it shipped out as soon as possible 8 days ago; it got shipped 3 days ago. I first opened my ticket on the 22nd of August; bulk of wait time was waiting for responses from support.
*
Edit: Made it through two ~6 hour runs of kill-ryzen-win. But I do get MCE errors while compiling? Not experiencing any instability, though? Leaving it to run ryzen-kill through tonight...

paolo.oliva2

17-10-2017, 16:41

Ieri avevo scaricato tutto, ma quando sono andato per fare la penna di boot, rufus mi ha detto che servivano 2 file... Internet a casa non l'ho, rinviato ad oggi. Ho fatto tutto, vediamo questa sera.

s12a

17-10-2017, 17:31

Se continui ad avere problemi con Rufus, recentemente io ho usato con successo Unetbootin per creare una distribuzione live di Lubuntu per un netbook:

http://unetbootin.github.io/

Quanto al segfault, in generale sembra che le CPU che salgono bene in overclock non lo manifestano, oppure che le CPU tornate indietro da RMA siano particolarmente fortunate. Oltre agli esempi precedentemente postati, in questo thread su Reddit (https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/) sono stati postati diversi risultati in overclock prima e dopo l'RMA; quasi nessuno sembra avere allegato anche la settimana di produzione, però:

https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/dnjie25/?st=j8vtz6y3&sh=305ff150
R5 1600 - 3.9@1.375V before
R5 1600 - 4.0@1.400V after

https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/dnjyn7l/?st=j8ud2qtd&sh=f4be5c3f
R7 1700 - 3.7@1.350V before
R7 1700 - 3.9@1.225V after

https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/dnjrnd4/?st=j8ud3cj8&sh=2aeb07f8
R7 1700 - 3.7@1.265V before
R7 1700 - 3.7@1.160V after

https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/dnjzsse/?st=j8ud3k89&sh=c113ae54
R7 1800X - 4.0@1.485V before
R7 1800X - 4.0@1.250V after

https://www.reddit.com/r/Amd/comments/72m4h0/for_those_with_segfault_rmad_cpus_has_your/dnno27k/?st=j8ud3qhn&sh=7730897a
R7 1700 - 3.7GHz@1.275V before
R7 1700 - 3.8GHz@1.175V after

Operapia

17-10-2017, 17:48

Il negozio dove ho comprato la cpu mi ha appena risposto che loro si limitano a mandarlo in rma da amd e che quindi mi conveniva direttamente mandarlo per i fatti miei. Pilatiano responso quindi.
Beh, alla fine a me cambia poco, ma questo la dice lunga sulla disponibilità nei confronti del cliente. Una bella X di sopra dunque.

papugo1980

17-10-2017, 17:56

Io ho scaricato l iso di Ubuntu e poi l ho preparata con questo tool www.linuxliveusb.com

evil weasel

17-10-2017, 18:35

Ho mandato indietro un 1700X che avevo e che era fallato.
Non so se è merito dell'email aziendale dal nome altisonante o solo fortuna ma mi hanno offerto una spedizione prepagata con DHL.

sinergine

17-10-2017, 20:48

Proprio ora che ero intenzionato a prendere un 1700.
Nessuno li ha presi di recente da tao? Sono ok?

Spitfire84

17-10-2017, 21:32

Ho mandato indietro un 1700X che avevo e che era fallato.
Non so se è merito dell'email aziendale dal nome altisonante o solo fortuna ma mi hanno offerto una spedizione prepagata con DHL.

se è quella di ritorno, la offrono a tutti.
E' la spedizione in Olanda che dovresti pagare...se non paghi neanche quella, meglio per te, risparmi 18€ :)

evil weasel

17-10-2017, 21:48

se è quella di ritorno, la offrono a tutti.
E' la spedizione in Olanda che dovresti pagare...se non paghi neanche quella, meglio per te, risparmi 18€ :)

Intendevo proprio quella di andata, mi hanno dato un codice prepagato per l'invio a carico di AMD.

AmuroRei_2

17-10-2017, 22:19

Oggi ho aperto una RMA con Tao, dato che avevo fatto anche l'opzione acquisti
sicuri dovrebbero mandarmi in sostituzione se ne hanno in stock un 1700 nuovo
e loro si arrangiano per l'rma alla AMD.

:sperem: :)

malcom499

17-10-2017, 22:26

Proprio ora che ero intenzionato a prendere un 1700.
Nessuno li ha presi di recente da tao? Sono ok?

Io sto aspettando un 1700 liscio da Amazon. Sarebbe dovuto arrivare domani, mercoledì ma oggi mi è arrivato un loro avviso di ritardo di 1/2 giorni, cmq entro venerdì arriva...ah la cpu è in viaggio dall'inghilterra...speriamo bene!

papugo1980

17-10-2017, 22:29

Io sto aspettando un 1700 liscio da Amazon. Sarebbe dovuto arrivare domani, mercoledì ma oggi mi è arrivato un loro avviso di ritardo di 1/2 giorni, cmq entro venerdì arriva...ah la cpu è in viaggio dall'inghilterra...speriamo bene!

A me arriva tra lunedì e martedì...
Vediamo che mi mandano...

s12a

18-10-2017, 09:22

Provato ora un R5 1600 settimana 34, crashato subito. O la VM sfancula qualcosa oppure bho, provo su una live di fedora :cry:

Il processore era nuovo o proveniente da RMA? (EDIT: scambio dal negozio come avevi menzionato in precedenza (http://www.hwupgrade.it/forum/showpost.php?p=45101098&postcount=43))
Overclock? Hai provato con le memorie a 2133 MHz?

Nel forum AMD c'è un utente che ieri ha postato di avere provato un 1800X settimana 37 ritornato da RMA. Segfault con le memorie a 3066 MHz, ma nessun problema, apparentemente, a 2400 MHz. A differenza di altri utenti, la confezione in questo caso non sembrava essere stata già aperta (cosa che sembrava implicare una sorta di controllo individuale prima dell'invio).

https://community.amd.com/message/2828641#comment-2828641#2828641 (post 1791-1792)

Got the new processor, it did not appear to have been opened or tested.

Batch UA-1737SUS

Still segfaults, but after 35 minutes now. That was tested at 3066Mhz memory speed on 3200Mhz chips (32GB of 16GBx2 DualRank). Technically, this is still overclocked, so I'm retesting now at 2400Mhz. I know they offically changed supported memory speeds with latest BIOS, but haven't seen the speed chart.

Anybody seen that?

I wonder if they are just sending these out now hoping they pass without any extra binning. If this still segfaults at this memory speed, I'll ask for advanced shipping instead of cross-ship.
New 1800X running kill_ryzen for over 4 hours without problems with memory at 2400Mhz. Previous cpu died within minutes at 2133Mhz.

Couldn't find official AMD memory support list, https://www.amd.com/system/files/2017-06/am4-motherboard-memory-support-list-en.pdf has been removed. Can't find any copies anywhere. Anyway, ASRock lists 2933Mhz offically for my memory (GSkill F4-3200C14-16GTZ) I'll retest at that speed.

Has anybody had luck reducing segfaults with higher ram voltage?

s12a

18-10-2017, 09:42

E se invece di una distribuzione live provassi il Linux Subsystem for Linux (aka "Linux on Windows". Non è una virtual machine) ed eseguire il test da lì? A partire dal Fall Creators Update si installa mediante il Windows Store.

https://i.imgur.com/Ka3DRcd.png

A questo punto credo però che i processori che non danno problemi siano solo quelli con binning migliore (e conseguentemente che si overcloccano meglio).

bagnino89

18-10-2017, 09:47

s12a

18-10-2017, 10:13

Se installi il WSL ricorda di effettuare da una finestra di PowerShell con privilegi di amministratore, prima di avviare Bash:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
La fonte di questo comando è qui: https://msdn.microsoft.com/en-us/commandline/wsl/install_guide?f=255&MSPPError=-2147217396

Una volta aperto bash/Ubuntu digita questo per aggiornare i repository (altrimenti ryzen-test fallisce subito):

sudo apt-get update

In ryzen-test.sh inoltre disabilita il ramdisk poiché non è supportato dal WSL. Apri il file (ad esempio con il comando "nano") e modifica la variabile USE_RAMDISK in:

USE_RAMDISK=false

Io ho scaricato ryzen-test con wget usando il seguente URL: https://github.com/suaefar/ryzen-test/archive/master.zip
Ed ho scompattato l'archivio usando il comando unzip, che non è presente di default nella distribuzione. Andrà quindi fatto prima:

sudo apt-get install unzip

In alternativa puoi fare dal file manager di Windows, ma non è consigliabile accedere alla home da lì.

La home è accessibile dalla directory:

%localappdata%\lxss\home\

Il filesystem di Linux (ext4) usa un layer di compatibilità su NTFS ed è lento, dunque non ti sorprendere se ryzen-test sembrerà metterci una vita per estrarre i sorgenti di GCC.

Sto provando proprio adesso; a partire, parte. Non dovrebbero avvenire segfault sulla mia configurazione:

https://i.imgur.com/o0BG9pq.png

s12a

18-10-2017, 10:57

Da quanto io ricordi, se il problema è la memoria insufficiente, ryzen-test dovrebbe terminare con un errore diverso, non segfault. Inoltre questo non dovrebbe avvenire immediatamente od entro pochi minuti. (EDIT: da qualche parte nelle directory create dal test dovrebbe essere disponibile un file di log con i dettagli, magari sarebbe meglio controllare lì per confermare)

In ogni caso la stessa pagina indica anche come sia possibile, qualora sia necessario, diminuire il numero di loop/thread per far continuare il test a lungo anche su configurazioni con memoria RAM limitata. Riporto qui per completezza:

You can also try to run fewer loops but allow them to use more threads, e.g., 8 loops with 2 threads each.

./kill-ryzen.sh 8 2

However, with only 16Gb RAM, this configuration might still run out of memory. 4 loops with 4 threads each is a safe choice on machines with 16Gb RAM.

./kill-ryzen.sh 4 4

s12a

18-10-2017, 11:07

Edit:
https://image.prntscr.com/image/_Xp33SsZTgi0diDrSjIQew.png

Errore confermato, processore 34esima settimana

Non una buona notizia.

Puoi allegare le ultime righe dell'output del file di log di uno dei loop che ha fallito il test?

Dalla pagina di Ryzen-test:

Processes related to the build will eventually crash (e.g., segfault). Processes unrelated to the build process might crash as well. An example output of the script where the first process crashed after 153 seconds can be found in "example-output.txt". There, the "last words" from the build process were (logged to "/mnt/ramdisk/workdir/buildloop.d/loop-*/build.log"):

Makefile:761: recipe for target 'get_patches.lo' failed make[5]: *** [get_patches.lo] Segmentation fault (core dumped)

Mister D

18-10-2017, 11:37

Comunque non è chiara 'sta cavolo di situazione...

AMD dovrebbe rilasciare una dichiarazione ufficiale o qualcosa di simile, proponendo un test oggettivo e ripetibile per verificare la presenza o meno del bug.

Praticamente la settimana di produzione non vuol dire nulla...

Al momento no perché evidentemente il riferimento della settimana 25 era proveniente da reddit o da phoronix ma era un'ipotesi perché magari a qualcuno hanno mandato una cpu da rma prodotta nella settimana 25 ma testata con il nuovo quality test. Purtroppo AMD ha solo detto di aver modificato il quality test per le nuove cpu ma non ha specificato da che settimana di produzione ciò è entrato in uso. E sono ormai convinto che AMD tenga un magazzino di cpu per le ram di lotti di differenti settimane di produzione e che ovviamente prima di mandarli all'utente finale li ritesta con il nuovo test. Questo perché sanno che non tutte le cpu prodotte prima del cambio del test hanno tale bug.
Sono anche più convinto che quelle binnate meglio siano proprio quelle esenti da bug, ergo AMD deve aver modificato il test di selezione, ergo tutte quelle nuove sono migliori dal punto di vista frequenze/vcore/vsoc.

Cmq visto che la conferma del problema è data il 07/08/2017 immagino che sicuramente le cpu prodotte da settembre (se non prima tipo metà agosto) passino già la nuova selezione e quindi non abbiano il problema. Facendo la conta calendario alla mano direi che è probabile che dalla settimana 36 (dal 4/09 al 10/09) si possa avere la certezza che AMD abbia già fatto partire il nuovo quality test.;) Ma è una mia ipotesi;)

s12a

18-10-2017, 11:38

@Ozozuz: ho il sospetto che dato che con il WSL non c'è un kernel Linux vero e proprio gli errori siano diversi o che non venga emesso esplicitamente all'utente un errore di segfault come direttamente da Linux. Tuttavia dato che dallo screenshot che mostri sopra ci sono righe consecutive del comando dato per compilare GCC, l'interruzione dovrebbe essere stata causata dallo stesso problema. A me non è successo ancora nulla dopo circa 15 minuti di test.

Puoi anche accedere a quella directory da Windows Explorer; è modificare i file che può dare problemi di corruzione.

Oppure, aprendo un'altra console mentre una sta compilando, invece di usare nano puoi usare il comando tail -n x dove x è il numero di righe a partire dalla fine del file da mostrare.

Per velocizzare la procedura ripetendola nuovamente puoi eliminare commentandole con un "#" le righe dallo script kill-ryzen.sh che fanno scaricare e scompattare GCC. Eliminerei anche la directory buildloop.d prima di ripetere il test.

bagnino89

18-10-2017, 11:56

Al momento no perché evidentemente il riferimento della settimana 25 era proveniente da reddit o da phoronix ma era un'ipotesi perché magari a qualcuno hanno mandato una cpu da rma prodotta nella settimana 25 ma testata con il nuovo quality test. Purtroppo AMD ha solo detto di aver modificato il quality test per le nuove cpu ma non ha specificato da che settimana di produzione ciò è entrato in uso. E sono ormai convinto che AMD tenga un magazzino di cpu per le ram di lotti di differenti settimane di produzione e che ovviamente prima di mandarli all'utente finale li ritesta con il nuovo test. Questo perché sanno che non tutte le cpu prodotte prima del cambio del test hanno tale bug.
Sono anche più convinto che quelle binnate meglio siano proprio quelle esenti da bug, ergo AMD deve aver modificato il test di selezione, ergo tutte quelle nuove sono migliori dal punto di vista frequenze/vcore/vsoc.

Cmq visto che la conferma del problema è data il 07/08/2017 immagino che sicuramente le cpu prodotte da settembre (se non prima tipo metà agosto) passino già la nuova selezione e quindi non abbiano il problema. Facendo la conta calendario alla mano direi che è probabile che dalla settimana 36 (dal 4/09 al 10/09) si possa avere la certezza che AMD abbia già fatto partire il nuovo quality test.;) Ma è una mia ipotesi;)

Appunto, sono ipotesi (seppur sensate), AMD dovrebbe chiarire e chiudere la faccenda una volta per tutte.

Sarà anche un problema insignificante, ma è comunque un problema esistente ed appurato. La questione va gestita in modo trasparente.

Mister D

18-10-2017, 12:52

Appunto, sono ipotesi (seppur sensate), AMD dovrebbe chiarire e chiudere la faccenda una volta per tutte.

Sarà anche un problema insignificante, ma è comunque un problema esistente ed appurato. La questione va gestita in modo trasparente.

Sì hai ragione ma se non lo fa nemmeno intel a volte come puoi aspettarti che lo faccia uno più piccolo? E con questo NON giustifico né AMD né Intel:
https://www.tomshw.it/cpu-intel-recenti-scoperto-bug-dell-hyper-threading-86594

Questo mi sembra abbastanza importante o no? Pero sfido a trovarmi quanti possessori di intel ne fossero a conoscenza prima che tom's e altri siti lo pubblicassero e intel ovviamente lo aveva pubblicato negli errata. Tutti puritani poi si scopre che i datasheet intel non li legge nessuno. Ok AMD ancora non li ha pubblicati e questo lo trovo gravissimo, perché con tutti gli altri processori gli errata erano stati pubblicati nel bios development kit. Mentre purtroppo ancora non l'ho visto sul sito di amd, magari i produttori di mb (certamente immagino) lo hanno ma non capisco perché non pubblicarlo per tutti come si faceva prima.;)

s12a

18-10-2017, 12:57

Ho rifatto il test, questa volta dando errore su un loop differente ad una diversa iterazione, il log é pressappoco identico.
Ho fatto anche una nuova prova, ovvero sempre da VM ma disabilitando il RAMDISK e ha dato ""correttamente"" segafault.
https://image.prntscr.com/image/bNWyQNIWRP6585uTJBTJeA.png

Mentre questo é il log del loop7 che é crashato nell'ultimo tentativo.
https://image.prntscr.com/image/68DAx4kgRXqgAFo44327tw.png
Per scrupolo e curiosità, tempo permettendo puoi provare a far partire il test con diverse impostazioni di ryzen-test, limitando il numero di loop e thread? Ad esempio 4 loop da un thread ciascuno, oppure 1 loop da 16 thread, o magari anche 1 loop da 1 o 2 thread, per vedere se il problema è solo il tipo di workload, o proprio il carico della CPU. Ovviamente ci metterà più tempo (penso).

Gioz

18-10-2017, 13:11

https://image.prntscr.com/image/3CC3mcXyQwuCc-cNNHxWAg.png
per me l'errore con integrato "all-recursive" significa che hai saturato la memoria eseguendo ricorsivamente operazioni che ne allocano "tot".
se anche scrivi una funzione che non fa niente e richiama se stessa all'infinito puoi saturare la memoria.
dovresti provare disattivando il ramdisk o passando come argomento una coppia diversa, nel readme suggerisce "4 4".

s12a

18-10-2017, 13:12

Disabilitando il ramdisk non dovrebbe essere superfluo ?
Dopotutto non usando al ram puó anche caricare tutto al massimo, anche perché la cpu é perfettamente stabile sia a default che in oc "ora ovviamente é a default"
Il ramdisk dovrebbe servire solo per i risultati della compilazione, log, ecc. Il processo vero e proprio è comunque svolto interamente dalla CPU ed in memoria.

Se controlli ad esempio il Task Manager di Windows durante l'operazione (usando Ubuntu tramite il WSL) noterai una quantità enorme di processi venire creati e terminati, od almeno io già ne vedo solo con 4 core, posso solo immaginare con 16 e le impostazioni di default del test (EDIT: appena provato, sono effettivamente molti di più. Per il momento non mi sembra di avere problemi di memoria insufficiente o simili, o non ne noto. EDIT2: nessun inconveniente dopo 15 minuti di ./ryzen-test.sh 16 16).

evil weasel

18-10-2017, 13:32

Il messaggio "TIME TO FAIL: xxx" può comparire, oltre che ovviamente nel caso di un segfault, anche se si verifica una delle due seguenti condizioni:
1. si satura totalmente la RAM;
2. si satura completamente il RAMDISK o, nel caso in cui non lo si usi, la partizione su cui sono presenti i sorgenti da compilare.

Nel caso della mia macchina con 32 GB di RAM e RAMDISK da 16 GB il tempo impiegato per saturare la memoria è superiore ai 10 minuti.
Quando eseguite il test potete controllare la quantità di RAM utilizzata/libera con il comandi:
1. free;
2. htop (questo va installato su ubuntu credo, per farlo eseguire: sudo apt-get install htop);
3. top.

Per controllare invece quanto spazio è utilizzato sul RAMDISK si può usare il comando "df -h".
Nello specifico, se si vuole rieseguire il comando df ogni secondo in modo da tenere meglio sotto controllo la situazione si può usare il seguente comando: "watch -n 1 df -h"

Solitamente mi sembra di vedere che, in caso di CPU fallata, il test fallisce entro poche decine di secondi quando di RAM non allocata ce ne è ancora parecchia.
Se si vuole lasciare eseguire il test per ore bisogna istruire lo script in modo che vengano lanciate un numero inferiori di compilazioni simultanee; ad esempio, come scritto nel readme, per avere 4 compilazioni contemporanee con 4 core allocati ciascuna lanciare: "sh kill-ryzen.sh 4 4"

moob1

18-10-2017, 13:42

A me entrambe le CPU provate fallivano entro 30 secondi...

ccmarco2004

18-10-2017, 13:50

Sarà anche un problema insignificante, -cut

non si può propio dire che sia insignificante, coinvolge in primo luogo una fascia di utenti che fa un utilizzo "non ludico" del personal computer e che ha scelto Ryzen in virtù dell'alto numero di cores per velocizzare le fasi di compilazione di codice sorgente saturando le risorse del processore.

Io direi che è un problema importante.

s12a

18-10-2017, 13:54

Il tempo massimo trascorso prima dell'errore é stato di 8 minuti, altre volte come da screen succede entro i 5, immagino siano tutte conferme del fatto che la cpu sia fallata no ? Posso inviare AMD senza paura che facciano storie ?
Non dovrebbero fare storie. Le Virtual Machine sono usate in ambiti seri potenzialmente per gli stessi tipi di workload. L'errore è lo stesso che hanno altri usando Linux direttamente, e non dovrebbe accadere.

edit: 4 4 anche qui
https://image.prntscr.com/image/Zuo8F3T9QBq8fKc7zl59nA.png
E diminuendo ulteriormente loop e processi? Direi che sia fallata, comunque.

ccmarco2004

18-10-2017, 14:11

Sì hai ragione ma se non lo fa nemmeno intel a volte come puoi aspettarti che lo faccia uno più piccolo? E con questo NON giustifico né AMD né Intel:
https://www.tomshw.it/cpu-intel-recenti-scoperto-bug-dell-hyper-threading-86594
-cut

Nella fattispecie Intel oltre a pubblicare il technical sheet ha risolto il problema con una modifica del microcodice prontamente distribuita ai produttori di mainboard, il confronto che porti non regge.

Ritengo lodevole la creazione di questo 3ad, dopo i vari attacchi ed il denial perpetrato nel 3ad principale questo è l'unico modo per fare un'informazione obiettiva riguardo a questo bug, in un clima "sereno".

moob1

18-10-2017, 14:12

Tcx

18-10-2017, 14:14

Attenzione su distribuzioni diverse da ubuntu l'errore potrebbe anche non essere il segfault...ma magari qualche pacchetto/libreria che manca o qualcosa del genere...ad esempio a me su Fedora crashava subito ma dal log ho scoperto che non crashava la compilazione ma la configurazione perchè non trovava un "pacchetto"...una volta installato è partito e non mi ha dato problemi (o meglio dopo circa 50 minuti è andato in errore ma aveva saturato il ramdisk...ho 16Gb di ram). Per sicurezza ho provato anche da live ubuntu...

s12a

18-10-2017, 14:16

Resta il fatto che la VM con ubuntu a paritá di settaggi non crasha, c'é da dire che quella con Mint porta la cpu a 90% mentre quella con ubuntu al ~40, quindi immagino sia sua la colpa.

Strano per Ubuntu. Per sicurezza, hai controllato le impostazioni per quella VM? Il seguente comando da terminale (usato da kill-ryzen.sh) quanti core rileva?

cat /proc/cpuinfo | grep -i -E "(model name|microcode)"

Usando VMWare Workstation 14 Player con una VM di OpenSUSE Tumbleweed mi vengono rilevati 4 core (quelli del effettivi processore ed assegnati), e 4 ne usa durante il test (cpu occupata al 100% - cosa che anche Windows mostra).

Attenzione su distribuzioni diverse da ubuntu l'errore potrebbe anche non essere il segfault...ma magari qualche pacchetto/libreria che manca o qualcosa del genere...ad esempio a me su Fedora crashava subito ma dal log ho scoperto che non crashava la compilazione ma la configurazione perchè non trovava un "pacchetto"...una volta installato è partito e non mi ha dato problemi (o meglio dopo circa 50 minuti è andato in errore ma aveva saturato il ramdisk...ho 16Gb di ram). Per sicurezza ho provato anche da live ubuntu...

Confermo e successo anche a me con OpenSUSE.

evil weasel

18-10-2017, 14:22

Il tempo massimo trascorso prima dell'errore é stato di 8 minuti, altre volte come da screen succede entro i 5, immagino siano tutte conferme del fatto che la cpu sia fallata no ? Posso inviare AMD senza paura che facciano storie ?

edit: 4 4 anche qui
https://image.prntscr.com/image/Zuo8F3T9QBq8fKc7zl59nA.pnghttps://image.prntscr.com/image/cgsDMrnVTl2K_zmks9uQ9A.png

Per avere la certezza dovresti appunto controllare che quando crasha non sia satura la memoria.
Il fatto che il problema si prensenti una volta a 5 minuti ed una ad 8 mi fa pensare che la tua CPU sia fallata ed il crash non dipenda dalla RAM piena.

p.s. non capisco perchè vi ostiniate ad usare quella porcheria di ubuntu quando fedora è ugualmente facile da usare e funziona correttamente.

moob1

18-10-2017, 14:45

Arrivato Ryzen 7 1700 da Amazon. Settimana 34 :D

alexsky8

18-10-2017, 14:54

Arrivato Ryzen 7 1700 da Amazon. Settimana 34 :D

facci saper come ti va rispetto al vecchio :sofico:

papugo1980

18-10-2017, 15:02

Arrivato Ryzen 7 1700 da Amazon. Settimana 34 :D

Per favore controlla pure online se corrisponde la settimana di produzione tramite seriale

Alex656

18-10-2017, 15:02

Troppi fanboy nel thread principale :asd:

Credo di saperne qualcosa :)

Gioz

18-10-2017, 15:07

ramdisk é disabilitato, in entrambi i test.:mad:
btw questo é un 4 4 su VM

https://image.prntscr.com/image/gymCrDiMRECEVhaf5MbKHA.png
questo dovrebbe essere il risultato "positivo" al test.

moob1

18-10-2017, 15:11

Per favore controlla pure online se corrisponde la settimana di produzione tramite seriale

Delivery Date: 2017-09-30
MFG Date: 2017-09-29

sembra molto recente.

edit: 10 minuti di test senza alcun problema. Prima l'errore arrivava in pochi secondi.

edit2: in overclock un altro livello: http://www.hwupgrade.it/forum/showpost.php?p=45108135&postcount=20732

s12a

18-10-2017, 16:07

p.s. non capisco perchè vi ostiniate ad usare quella porcheria di ubuntu quando fedora è ugualmente facile da usare e funziona correttamente.
L'idea era usare una procedura standardizzata, testata, ed il più semplice possibile con qualcosa che bene o male più utenti hanno esperienza di utilizzo o familiarità. Credo che lo script sia stato testato principalmente con Ubuntu, sia dall'autore che dagli utenti.

Ad esempio, poco fa ho provato con Mint Cinnamon (che dovrebbe essere molto simile ad Ubuntu) in modalità "live" in una VM ed ho incontrato problemi a causa del fatto che i repository di default non erano aggiornati (risolti con un "apt-get update").

Ho provato anche Fedora in VM (installata), ma per qualche motivo - suppongo versioni dei pacchetti diverse da quelle usate da Ubuntu - il test fallisce poco prima che inizi effettivamente a compilare, dopo la fase di "configure"; non ho voluto perdere troppo tempo a capire perché (EDIT: alla fine ho risolto, era un pacchetto mancante: "gcc-c++").

Visto che la maggior parte degli utenti non ha dimestichezza con Linux e che anche chi ha un po' di esperienza potrebbe avere problemi, meglio evitarne di ulteriori che diluiscano gli sforzi e facciano perdere tempo.

Gioz

18-10-2017, 16:15

Quindi solo io ho beccato un week 34 piú fallato di uno della 7 ?:mad:
è possibile, la questione "settimana" è stata derivata da utenti come noi analizzando le cpu che restituiscono il segfault e quelle ricevuta come rma, non è scontato che tutte le cpu recenti siano esenti.

s12a

18-10-2017, 16:37

edit: 10 minuti di test senza alcun problema. Prima l'errore arrivava in pochi secondi.
edit2: in overclock un altro livello: http://www.hwupgrade.it/forum/showpost.php?p=45108135&postcount=20732
Per curiosità, in overclock lo mostra il segfault durante il test di compilazione?
Chissà se non sia anche un ottimo modo per verificare la stabilità effettiva della CPU in tale condizione.

evil weasel

18-10-2017, 16:39

Sarà anche una distro certificata per alcuni sistemi ma, diciamocela tutta, funziona dimmerda con ryzen. :D
Poi oh, liberi di fare come preferite, io avevo proposto di usare un'altra distro perchè testare la CPU con un sistema operativo che riesce ad usare un solo core non mi sembra una idea geniale.

s12a

18-10-2017, 16:46

SpongeJohn

18-10-2017, 17:14

Nella fattispecie Intel oltre a pubblicare il technical sheet ha risolto il problema con una modifica del microcodice prontamente distribuita ai produttori di mainboard, il confronto che porti non regge.

Ritengo lodevole la creazione di questo 3ad, dopo i vari attacchi ed il denial perpetrato nel 3ad principale questo è l'unico modo per fare un'informazione obiettiva riguardo a questo bug, in un clima "sereno".

Veramente, da che fu scoperto quel bug alla pubblicazine del fix, passò circa un'anno, e da intel non venne rilasciata nessuna comunicazione. Chi ha scoperto quel bug ha saputo del fix solo leggendo poi dei "bugfix" pubblicati da intel a giugno.
https://lists.debian.org/debian-devel/2017/06/msg00308.html
Ed aggiungo da Tom's:

"Difficile comunque stabilire la gravità del bug, dato che è stato riscontrato da un "toolchain developer" di OCaml e dalla comunità, che ha indagato per circa un anno."

Quanto scritto sopra non giustifica AMD. Però va aggiunto quanto segue (sempre da Tom's):

"Se siete un utente comune non è il caso che vi facciate prendere dal panico: se tutti i vostri software hanno funzionato a dovere sino a oggi, potete continuare a usare il PC come al solito."

s12a

18-10-2017, 18:16

Il discorso è giusto, ma servono istruzioni replicabili, e con facilità. Fedora live ad esempio di default potrebbe non funzionare di default con il ryzen-test - non ho ancora provato però (avevo scaricato la NetInstall perché sono 480 MB contro 1.5GB).

Per la cronaca, ho provato con Fedora Live: il file system della partizione di root dopo un po' che si iniziano a scaricare le dipendenze necessarie per far partire ryzen-test va in sola lettura per eccessivo spazio occupato ed il processo si blocca. L'ultima daily build di Ubuntu 17.10 (http://cdimage.ubuntu.com/daily-live/current/), sempre in modalità live (prima del rilascio ufficiale di domani, immagino) procede senza problemi con il test. Impiega inoltre tutta la CPU.

https://i.imgur.com/rRUskoS.png

paolo.oliva2

18-10-2017, 18:43

Domanda da.... idiota.

Ieri sera ho fatto tutto, bootato dalla penna, ho messo i file di test in un'altra penna... tutto ok, mi boota e vedo i file... ma con che mazza li carico? Io li ho visti con l'editor e altro... ma non ho trovato come caricarli per eseguirli.

Che programma è?

Gioz

18-10-2017, 19:06

s12a

18-10-2017, 19:15

EDIT: attenzione, con Ubuntu 17.10 occorre usare questo zip:
https://github.com/Oxalin/ryzen-test/archive/master.zip

Proveniente da questo fork di Oxalin:
https://github.com/Oxalin/ryzen-test/

Domanda da.... idiota.

Ieri sera ho fatto tutto, bootato dalla penna, ho messo i file di test in un'altra penna... tutto ok, mi boota e vedo i file... ma con che mazza li carico? Io li ho visti con l'editor e altro... ma non ho trovato come caricarli per eseguirli.

Che programma è?

https://imgur.com/a/sv5r3

Mi sono appena reso conto che le istruzioni date in precedenza erano forse troppo sommarie e danno troppe cose per scontato. Ecco istruzioni passo-passo che usano Ubuntu 17.10 che ho linkato poco sopra in versione beta (dovrebbe uscire domani). Non dovrebbero esserci troppe differenze con la 17.04.

È più pratico se invece di usare una seconda chiavetta USB il file "https://github.com/Oxalin/ryzen-test/archive/master.zip" lo scarichi da Firefox su Ubuntu e lo apri usando l'interfaccia grafica, facendo "Open With".

https://i.imgur.com/JCuLpXc.png

https://i.imgur.com/BUAqKCg.png

Poi clicca extract, ed estrai nella directory di default (la "home")

https://i.imgur.com/KtsazWt.png

https://i.imgur.com/wqgAgwP.png

Poi clicca "show files"

https://i.imgur.com/SHtJ1Bz.png

Clicca sulla cartella creata

https://i.imgur.com/VzqA6Op.png

Premi tasto destro nello spazio vuoto e poi "open in terminal"

https://i.imgur.com/HLE8IR9.png

Per eseguire lo script digita:

./kill-ryzen.sh

https://i.imgur.com/DDEgp8Y.png

Poi rispondi "Y" alla domanda che fa; deve scaricare dei file. Una volta fatto, inizerà il test.

https://i.imgur.com/a2k35ny.png

https://i.imgur.com/9fdSLM0.png

https://i.imgur.com/XsIyXu2.png

s12a

18-10-2017, 19:26

Ho notato che alla fine anche ubuntu crasha, ma l'errore é diverso. Non si parla di seg-fault ma "tra le altre cose" di coredump.
La conclusione é sempre la stessa ? Non mi ritrovo AMD che tra un paio di settimane mi dice che tutto funziona e mi rimanda la stessa cpu indietro ? :c

https://image.prntscr.com/image/xe88zBtyR2W0qstg5OEQMw.png
https://image.prntscr.com/image/CVgPWg1OQcGBWEo63lVXXQ.png

Credo sia sempre un errore correlato. Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode (https://en.wikipedia.org/wiki/Opcode)) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Su Phoronix c'era uno screenshot con un errore simile nello stesso test (invalid opcode).

https://i.imgur.com/yFovv9W.jpg

(fonte: https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run)

alexsky8

18-10-2017, 19:28

https://imgur.com/a/sv5r3

Mi sono appena reso conto che le istruzioni date in precedenza erano forse troppo sommarie e danno troppe cose per scontato. Ecco istruzioni passo-passo che usano Ubuntu 17.10 che ho linkato poco sopra in versione beta (dovrebbe uscire domani). Non dovrebbero esserci troppe differenze con la 17.04.

È più pratico se invece di usare una seconda chiavetta USB il file "https://github.com/suaefar/ryzen-test/archive/master.zip" lo scarichi da Firefox su Ubuntu e lo scompatti ad esempio in Downloads usando l'interfaccia grafica, facendo "Open With".

provato ora la 17.10 live su chiavetta con la scheda Gigabyte Gaming 5 e finalmente zero problemi cosa che invece la 17.04 dava

quindi chi ha gigabyte o ha problemi scarichi subito la 17.10 segnalata da s12a ;)

https://i.imgur.com/U48KXHt.png

alexsky8

18-10-2017, 19:50

fra l altro e stato eliminato anche il problema che vedeva 1 o pochi core
ora li vede tutti 16

https://i.imgur.com/OV4Lg6q.png

ho rifatto il test anche in OC CPU e RAM e per ora sta girando senza problemi

s12a

18-10-2017, 19:53

Provata la 17.10 da live e non da VM e non crasha, cosa vuol dire questo, che tutti gli errori di prima venivano da altro e non dal bug? Non capisco :/

Papugo1980 aveva riportato che non si presenta in maniera regolare; dipenderà dal tipo di carico e dalle condizioni del PC (con una VM ad esempio ci sono anche i processi del sistema host. Ipotesi)

http://www.hwupgrade.it/forum/showpost.php?p=45100782&postcount=29

Riguardo al test su Linux io l ho fatto 4 volte :
La prima e la seconda volta ha dato subito errore
La terza no infatti ero arrivato a 40 minuti e allora ho stoppato
La quarta volta anche subito l errore

BuRn

18-10-2017, 20:30

Credo sia sempre un errore correlato. Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode (https://en.wikipedia.org/wiki/Opcode)) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Su Phoronix c'era uno screenshot con un errore simile nello stesso test (invalid opcode).

https://i.imgur.com/yFovv9W.jpg

(fonte: https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run)

Ciao, scrivo da interessato all'acquisto di 1700 e per ora mi sto trattenendo perchè tra i miei utilizzi ci sarebbero sicuramente quelli incriminati (mi occupo di sviluppo sw e avere tanti core su cui far partire immagini docker mi farebbe comodo).

Premesso che non mi occupo di sistemi operativi, l'utilizzo di linguaggi dove si agisce direttamente sulla memoria è un lontano ricordo e la conoscenza di come funziona una CPU sono quelle mere basi dei corsi universitari, secondo me il problema sta venendo sminuito.

La CPU non sa di star eseguendo istruzioni su Linux o di star compilando con gcc, la CPU processa le istruzioni e basta. Come diceva s12a, se si va a toccare una zona di memoria al di fuori di quella riservata dal kernel si ottiene un segfault, ma se si sbaglia indirizzo e il kernel non interviene possono succedere altre cose spiacevoli, si potrebbero ad esempio saltare delle istruzioni, causando dei crash all'avere qualche risultato sbagliato (pare che l'errore stia nell'indirizzo contenuto nel registro del program counter).

Probabilmente gcc presenta dei pattern di istruzioni che rendono probabile che il problema si manifesti, ma questo non esclude in alcun modo che non si presenti altrove.

Qui c'è un articolo blog-post:
http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/

E qui c'è un post su phoronix di Matt Dillon, uno degli sviluppatori che per primo ha tracciato il bug:
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

Sono cose che circolano da un po', comunque buona lettura. ;)

Sarei curioso di capire alcune cose:
- Dillon parlava di un bug relativo all'SMT, non ho capito tra le decine di post sui forum se chi riscontra il problema lo riscontra anche con l'SMT disabilitato, perchè nel caso sarebbero due anomalie distinte (non necessariamente entrambe legate alla CPU, come sottolineava Dillon, ha potuto fare i test solo sulla sua configurazione)
- Quante persone riscontravano instabilità nel daily use che sono scomparse dopo l'RMA: Ryzen ha avuto i suoi problemi con le memorie, con i bios e con le schede madri, ma magari non tutti i problemi che gli utenti riscontravano erano legati a quello, magari una parte erano legati a questo problema
- Quante sono percentualmente le CPU bacate: sembra che la maggior parte di chi fa il test con cpu più "vecchie" scopre di avere il bug

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti. :)

moob1

18-10-2017, 20:44

--

Se compri su Amazon il 1700 sicuramente avrai uno post settimana 25 che da come sembra per la maggior parte sono esenti da bug (io ho ricevuto un ottimo esemplare settimana 34 proprio oggi),

Con questa nuova CPU la stabilità, per quanto assurdo sembra migliore, voltaggi più bassi, temperature più basse. Tra l'altro io penso che un buon 80% se non anche 90% di cpu prodotte nei primi mesi siano affette dal bug. Personalmente ne ho provate 2, entrambe con bug.

Gioz

18-10-2017, 20:45

So cos'é un coredump :asd: ma non riesco a immaginare da cosa possa essere stato provocato, la memoria era libera e 169secondi sono troppo pochi per saturare 8gb a quanto ho capito
scusami, avevo interpretato male il tuo post, ma ogni volta si interrompe in questo modo?

alexsky8

18-10-2017, 20:57

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti. :)

la mia era una CPU settimana 16 ed aveva il bug
non riscontravo alcuna anomalia nell'operatività ma avevo notato anomalia nella gestione delle temperature e Vcore cosa che con l'ultima CPU settimana 33 non ho

un consiglio però lo darei
andrei tranquillamente ad acquistare un sistema ryzen ma magari nel tuo caso lo farei con Amazon vista la politica semplificata nella gestione dei resi

s12a

18-10-2017, 20:59

Sarei curioso di capire alcune cose:
- Dillon parlava di un bug relativo all'SMT, non ho capito tra le decine di post sui forum se chi riscontra il problema lo riscontra anche con l'SMT disabilitato, perchè nel caso sarebbero due anomalie distinte (non necessariamente entrambe legate alla CPU, come sottolineava Dillon, ha potuto fare i test solo sulla sua configurazione)
Sembra che disabilitare il µOpCache aiuti più di disabilitare l'SMT. Tuttavia non tutte le schede madri permettono la prima opzione.

https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue/page4
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/dltske1/?st=j8vc138w&sh=ede4db77
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/dltske1/?st=j8xgg9iu&sh=63037a3a
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/dnnoys5/?st=j8xgg6bt&sh=501d2e0e
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/dnlflv9/?st=j8xgg43l&sh=f885717c
https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/dlvy82n/?st=j8xgjpx5&sh=634348ed

alexsky8

18-10-2017, 21:00

Se compri su Amazon il 1700 sicuramente avrai uno post settimana 25 che da come sembra per la maggior parte sono esenti da bug (io ho ricevuto un ottimo esemplare settimana 34 proprio oggi),

Con questa nuova CPU la stabilità, per quanto assurdo sembra migliore, voltaggi più bassi, temperature più basse. Tra l'altro io penso che un buon 80% se non anche 90% di cpu prodotte nei primi mesi siano affette dal bug. Personalmente ne ho provate 2, entrambe con bug.

lo penso pure io ad ogni modo ad oggi sussiste la correlazione fra BUG e CPU uscite "meno bene"

ccmarco2004

18-10-2017, 22:07

Un segmentation fault è per definizione quando il programma legge o (scrive) in una zona di memoria non autorizzata (ed il kernel del sistema operativo se ne accorge). Se questo tipo di errore accade, può anche succedere che lo stesso avvenga in una zona di memoria autorizzata ma comunque non valida. Il tuo output dice che è stata trovata un'istruzione in linguaggio macchina (opcode (https://en.wikipedia.org/wiki/Opcode)) non valida. La tipologia di errore è la stessa, ma è diversa la manifestazione.

Invalid Opcode e Memory Segfault sono due eccezioni di tipo differente, "trappate" da vettori separati, che a seconda delle opzioni di esecuzione del Kernel possono conseguire in un memory dump.

E' però vero che condividono molti meccanismi scatenanti ed in entrambi i casi il thread interessato viene "ucciso".

Finezze a parte, penso che ci sia una profonda differenza tra l'eseguire una distro di linux sotto VM e la sua esecuzione esclusiva sulla stessa macchina, in entrambi casi la procedura è troppo lunga e soggetta a troppe varianti.

E' plausibile pensare che in AMD abbiano sviluppato un tool software molto più sbrigativo per evidenziare il bug, magari sarebbe ora di distribuirlo, così come è successo quando Intel è stata messa all'angolo dai media ai tempi del Pentium DIV bug.

digieffe

18-10-2017, 22:50

secondo me il problema sta venendo sminuito.

La CPU non sa di star eseguendo istruzioni su Linux o di star compilando con gcc, la CPU processa le istruzioni e basta. Come diceva s12a, se si va a toccare una zona di memoria al di fuori di quella riservata dal kernel si ottiene un segfault, ma se si sbaglia indirizzo e il kernel non interviene possono succedere altre cose spiacevoli, si potrebbero ad esempio saltare delle istruzioni, causando dei crash all'avere qualche risultato sbagliato (pare che l'errore stia nell'indirizzo contenuto nel registro del program counter).

Probabilmente gcc presenta dei pattern di istruzioni che rendono probabile che il problema si manifesti, ma questo non esclude in alcun modo che non si presenti altrove.

Difficile fare una statistica su un forum, ma comunque i vostri commenti sono ben accetti. :)

... e quei pattern di istruzioni si potranno presentare anche in software futuri. Soprattutto se non verrà pubblicato qual'è/quali sono il pattern che lo genera/no.

Ps: non mi date dell'hater di amd, questo mio onesto pensiero (già espresso da tempo), che BuRn ha precisato meglio, è solo DOVUTO alle "minimizzazioni".
Se dovessi parlare di amd relativamente a questo bug avrei ben altri dubbi da sollevare, ma non sono un hater né ho tempo da spendere, lascio il tempo ad amd di sistemare.

SpongeJohn

19-10-2017, 02:11

s12a

19-10-2017, 06:31

Provata la 17.10 da live e non da VM e non crasha, cosa vuol dire questo, che tutti gli errori di prima venivano da altro e non dal bug? Non capisco :/

Da Windows mediante il WSL con Ubuntu o mediante VM, puoi verificare se prima di eseguire il test, digitando la seguente riga il problema viene mitigato notevolmente?

sudo sysctl kernel.randomize_va_space=0

Così si disabilita l'Address Space Layout Randomization (https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/). Sembra che (http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/) sia una feature che accentua notevolmente l'insorgenza di questi errori di segfault su Linux. È attiva di default (valore=2), ma non so se abbia veramente effetto quando l'OS non gira nativamente sulla macchina. Wikipedia riporta che Windows usa questa feature solo in particolari casi (https://en.wikipedia.org/wiki/Address_space_layout_randomization#Microsoft_Windows).

Se ne controlla lo stato mediante uno dei seguenti comandi (non è rilevante, ma ho notato che kill-ryzen.sh usa il secondo; solitamente riporta "2", dunque attivato):

sysctl kernel.randomize_va_space
cat /proc/sys/kernel/randomize_va_space

digieffe

19-10-2017, 08:57

... e si continua a minimizzare e fare confronti con intel e con altre situazioni che non c'entrano nulla. Perchè quest'ultima necessità? mal comune (bug irrisolti) mezzo gaudio?

si parla di ottimizzazioni generiche per BD o amd, ma cosa centra? una cpu deve poter eseguire anche codice non ottimizzato!

e si parla di linux e/o di gcc quando se pur in maniera minima il problema compare è riproducibile in altri ambiti! (wsl, cygwin e visualstudio ?)

dalle ultime informazioni di è visto che si verifica anche con l'utilizzo di un solo core.

è chiaro cosa sia un pattern di istruzioni? da quanto si legge sembra proprio di no. Spero che qualcuno abbia voglia di spiegarlo adeguatamente.

pattern di istruzioni, motivo per il quale si potrà presentare anche in software futuri di qualsiasi natura che presentino la stessa situazione.

Non ancora è chiaro in quale status della cpu l'errore emerga, ma soprattutto non si sa se l'errore si presenta su base probabilistica o deterministica. Il che la dice tutta sulla natura di quest'errore!

e per favore basta con le minimizzazioni :)

Ps: mi scuso se non ho tempo di argomentare nei dettagli, spero che qualcuno se ne prenda la briga.

s12a

19-10-2017, 09:45

Il primo screenshot, che non riporta errori dal kernel, potrebbe essere correlato a problemi di saturazione memoria o di spazio nel filesystem temporaneo creato per la root dal sistema, anche se il ramdisk creato dal test è ben lungi dall'essere riempito (non ho investigato il motivo, ma credo sia il motivo principale per il quale eseguire a lungo il test tramite Live porta inevitabilmente ad interruzioni di questo genere. Puoi monitorare la situazione con il comando 'df'). Il secondo invece sembra proprio il problema della CPU.

Nelle varie prove che ho fatto ieri mediante VM usando varie distro Live ho notato che i problemi di memoria o esaurimento spazio si ripetono sempre dopo circa lo stesso tempo di esecuzione del test, a seconda delle impostazioni iniziali di numero loop e thread dello stesso. Per cui mi sto un po' ricredendo sulla validità di una distribuzione Live come test come originariamente consigliato: sembra un po' troppo facile incappare in falsi positivi (o altri problemi), a meno di analizzare nel dettaglio l'errore.

Errori espliciti di segfault ed invalid opcode dovrebbero invece uscire fuori in maniera non deterministica ed essere indicativi del bug. Io non ne ho mai visti con la mia configurazione.

digieffe

19-10-2017, 09:49

occhio ad ubuntu 17.10

qui http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/ tra i requisiti dice che è necessario che gcc e bash non siano PIE.

"Check your gcc and bash are not PIE (Position-independent executables). In Ubunt 17.04, gcc and bash aren’t PIE, but clang and dash are PIE."

ma nella 17.10 tutti gli eseguibili dovrebbero essere PIE. Per la verifica seguire le istruzioni nel link.

dunque non so in questa condizione "PIE" quanto sia valido il test.

s12a

19-10-2017, 10:00

"Check your gcc and bash are not PIE (Position-independent executables). In Ubunt 17.04, gcc and bash aren’t PIE, but clang and dash are PIE."
Mi sembra che dica "controllate che non lo siano".

I comandi dati per compilare GCC dal test sembrano forzarne la sua assenza con -fno-PIE (https://forums.gentoo.org/viewtopic-t-406175-view-next.html?sid=ce1475fd82ae490a190f3b546489920d) comunque (fermo restando che non ho idea delle implicazioni di questo). Ecco uno screenshot da un test che sto facendo in questo momento con OpenSUSE installata in una VM (aveva anch'essa delle librerie mancanti, sempre relative a "gcc-c++"):

https://i.imgur.com/IeVtT20.png

digieffe

19-10-2017, 10:12

Mi sembra che dica "controllate che non lo siano".

I comandi dati per compilare GCC dal test sembrano forzarne la sua assenza con -fno-PIE (https://forums.gentoo.org/viewtopic-t-406175-view-next.html?sid=ce1475fd82ae490a190f3b546489920d) comunque (fermo restando che non ho idea delle implicazioni di questo). Ecco uno screenshot da un test che sto facendo in questo momento con OpenSUSE installata in una VM (aveva anch'essa delle librerie mancanti, sempre relative a "gcc-c++"):

https://i.imgur.com/IeVtT20.png

se non stiamo equivocano stiamo dicendo la stessa cosa: verificare che gcc e bash non siano PIE, giusto?

nella 17.04 dovrebbero essere NON PIE alias EXEC, quindi ok (ho apena controllato).

nella 17.10 dovrebbero essere PIE alias DYN, quindi NON ok

comunque meglio verificare

s12a

19-10-2017, 10:18

Ubuntu anche da subsystem é sempre stato "particolare" come errori, mentre Mint schiaffava direttamente una seg-fault lui era piú fantasioso.
Erano entrambi 4 4 e quando son crashati a circa 2-3gb occupati su 16, mi pare strano possa essere lui.
Non mi riferisco a tutta memoria fisica, ma a quella assegnata alla root di sistema, che suppongo deve potere essere in grado di eseguire un numero limitato di scritture per file temporanei, eventuali pacchetti, ecc.

Il motivo è che usando una distribuzione Live non vengono effettuate scritture direttamente sul supporto di avvio. Da quello che mi sembra di capire, viene creato un ramdisk (non compresso) dedicato per la root, di dimensioni abbastanza limitate. Ipotizzo che le voci di log create durante l'operazione contribuiscano a diminuire lentamente lo spazio libero.

Anche perché é crashato dopo 7 minuti, il primo tentativo per crashare causa saturazione ce ne ha messi ~25

Se con le stesse impostazioni succede ad intervalli di tempo non regolari, è probabilmente il problema della CPU, ma è sempre meglio analizzare nel dettaglio la cosa.

Proprio adesso ad esempio, dopo circa 19 minuti di test mi è fallito il test su OpenSUSE, incomprensibilmente per un errore nel codice sorgente andando a controllare build.log (Non stavo usando un ramdisk, ma la ram assegnata era solo 4GB, senza swapfile; non mi sembrava fosse satura ma non ci ho fatto troppa attenzione). Niente segfault od errori di opcode, solo "build failed" su tutti i loop contemporaneamente.

evil weasel

19-10-2017, 10:42

Quanto sta accadendo ora é l'esatta riproduzione del non problema delle rx che assorbivano troppa potenza dallo slot pci. Un problema inesistente per il 99% della popolazione (perché vorrei ricordare che la percentuale di utilizzo di linux rispetto a win é dell'1%).

1% sono svariate migliaia di utenti, ti sembra un problema marginale?
A me no.

E no. L'errore in compilazione su win é assai molto piú raro e quasi non riproducibile.

Più raro ma non assente.
Il fatto che ora accada meno spesso non vuol dire che non sia un problema e soprattutto non vuol dire che in futuro il problema non possa presentarsi con una frequenza maggiore o anche in altri ambiti.

No: gcc e i kernel linux non sono ottimizzati per ryzen, una ricerca di due minuti e si viene a sapere che i kernel e gcc sono ottimizzati genericamente per "AMD" e solo per l'architettura bd... Non scherzo.

Questo è falso.
GCC permette, già dalla versione 6.*, di specificare march=znver1, le differenze passando da una impostazione MARCH ad un'altra sono presenti ed abbastanza significative.
Chi si lamentava di binari poco ottimizzati rispetto all'impostazione march=haswel usava GCC vecchio, in combinazione con altre impostazioni non consigliate (ad esempio -O3) a pochissima distanza dal lancio.
Aggiungo poi che malgrado march=hawsel producesse binari più efficienti lo faceva a discapito della stabilità.
Sul fatto che il kernel Linux sia poco ottimizzato per Ryzen io avrei da ridire, ad esempio XFR e C&Q hanno subito funzionato correttamente.
È Windows quello che ha avuto bisogno di un nuovo profilo energetico apposito e tutt'ora è comunque pieno di gente che bestemmia per far andare correttamente il C&Q.

E ancora: no, compilare in quel modo non é comune ne lo diverrà in futuro in nessun scenario d'utilizzo per l'utente comune ( ed ipotizzare che mandare in compilazione su tutti i core diventi di uso comune nell'uso quotidiano: é pura follia. Ma per favore...) che ripeto: corrisponde al 99% della popolazione che compra queste cpu.

Te lo ripeto, uso comune non vuol dire niente quando si parla di un prodotto distribuito nell'ordine delle decine/centinaia di migliaia di unità.
Anche fosse solo il 1% di utenti interessati siamo comunque di fronte a numeri esageratamente elevati.

A stare a sentire l'opinione dell'uomo comune anche le rx fondono gli slot pci. Peccato che non é cosí.

Questo, se possibile, è anche peggio perchè c'è il rischio di incendio.
Anche in questo caso, fosse solo il 1% la percentuale di schede utilizzate si parla di svariate migliaia di utenti.

Purtroppo io la cpu devo rivenderla su questo forum nel momento in cui decideró di cambiarla. Altrimenti con il cavolo che avrei fatto un rma, lo faccio solo perché l'utenza di un certo tipo va assecondata quando ti metti dalla parte del venditore, anche nelle psicosi.

Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Se dall'oggi al domani venisse fuori che é un errore software, dato che ad esempio il solo aver aperto hwinfo64 inficia la stabilità delle build a base ryzen ( e che quindi il kernel linux, ne il compilatore, che ripeto: non sono ottimizzati per niente: in realtà hanno probabilmente molto a che fare con la non stabilità del sistema) cosa dovremmo dire? Ennesimo: ops abbiamo dato addosso senza tregua ad amd mentre si sorvola sulle cappellate di intel?

GCC è open source, ti invito a scaricare i sorgenti e trovare l'errore software di cui millanti la presenza.
Aggiungo, perchè secondo me ti sfugge, che Linux e GCC sono entrambi progetti open source a cui partecipano attivamente le società interessate (Intel, AMD, etc).
AMD ha tutti gli strumenti per eventualmente correggere il presunto bug di GCC, migliorare il supporto a Ryzen da parte del kernel Linux, etc.
Il fatto che stiano cambiando le CPU senza dire bah è sintomatico del fatto che anche loro siano convinti che non sia un problema software.

Ci sono i link in questa discussione dove si evince (se solo la gente li leggesse...) Che l'ht su skylake e kaby inficia la stabilità del sistema su alcune operazioni sotto linux. Bug scoperto un'anno prima che intel lo correggesse senza nel mentre dare notizia al pippo franco di turno...

E a noi esattamente cosa interessa questo?
Io ho comprato 380 € di CPU da AMD, non Intel.

Se non mi credete, date uno sguardo al ng degli sviluppatori di gcc. Le generiche ottimizzazioni che vengono usate anche ora quando si ha una cpu amd: sono le vecchie usate per bd... Due cpu che non hanno niente in comune.

Posta i link, possibilmente non risalenti a 6 mesi fa.

SpongeJohn

19-10-2017, 10:58

... e si continua a minimizzare e fare confronti con intel e con altre situazioni che non c'entrano nulla. Perchè quest'ultima necessità? mal comune (bug irrisolti) mezzo gaudio.
..

Dimostrazione finale che i link manco li hai letti.
Non si tratta di "mal comune..." Ma di "due pesi, due misure" se vogliamo rimanere nell'ambito delle ovvietà dei detti popolari.

Prima di affermare che il suddetto "bug" si presenta anche con visualstudio, cygwin: vorrei leggere bug report dettagliati e chiarificatori. Link? O ancora meglio: fonte?

Ma anche fosse cosí, vogliamo tirare fuori i numeri di quanti usano una cpu per programmare e aggreghiamo i numeri di chi usa linux e win? A quanto ammontiamo come percentuale rispetto all'uso comune che si fa di un pc?

Intorno al 5%? Abbondiamo, 6?
Anche nel caso il problema si presenti sotto windows (e ripeto, le fonti di questa affermazione o le si posta ed é bene che siano affidabili, o la si finisce di ripeterlo), nessun programma di uso comune (anche in ambito lavorativo) non farà mai uso di quelle "istruzioni". Ci vogliamo inventare di sana pianta che dall'oggi al domani compilare diverrà cruciale per chi usa excel, photoshop, blender, firefox autocad etc etc?
Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai.
Stiamo parlando delle classiche paranoie da forum

Ultimo appunto, dichiarare che le ottimizzazioni (mancanti o errate) del compilatore o del kernel non contano perché qualsiasi cpu deve essere in grado di compilare in qualsiasi condizione: o lo dimostri ad esempio usando degli i5 e dandogli in pasto i comandi per BD e lo lasci compilare per anche 48 ore (beninteso, alcuni si lamentano che questa sono le condizioni alle quali si presentno i segfault: loop di 48 ore... Manco la nasa), usando un kerbel compilato per Bd.
Vediamo con queste condizioni, quante macchine passano il test.

s12a

19-10-2017, 11:01

se non stiamo equivocano stiamo dicendo la stessa cosa: verificare che gcc e bash non siano PIE, giusto?
L'equivoco era nato dal fatto che stavo guardando i flag di compilazione usati dal test invece del binario di gcc (e bash).

In ogni caso, pensavo che nel link dicesse che non devono essere PIE, ma da una distratta lettura non era chiaro. Mi sono alla fine andato a leggere su Wikipedia (https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables) cosa significhi esattamente. Fa parte delle funzionalità di Address Space Layout Randomization (ASLR). Gli eseguibili compilati in modalità Position-Independent-Executable (PIE) possono fare uso dell'ASLR, che è attivo di default su Linux.

Dato che è stato determinato in precedenza che questa funzionalità di ASLR aumenta significativamente le possibilità di osservare l'errore, allora vuol dire che gli eseguibili devono essere preferibilmente stati compilati in modalità PIE affinché esso esca fuori più rapidamente (disabilitare l' ASLR non elimina totalmente il problema).

EDIT: potrei stare capendo male, lascio comunque il testo qui per eventuali ripensamenti.

nella 17.04 dovrebbero essere NON PIE alias EXEC, quindi ok (ho apena controllato).

nella 17.10 dovrebbero essere PIE alias DYN, quindi NON ok

comunque meglio verificare

It’s PIE if the type is DYN, non-PIE if EXEC.

Usando il comando provvisto in quella pagina (http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/) ("readelf -h $(which bash)" oppure "readelf -h $(which gcc)"):

Su OpenSUSE Tumbleweed (installata da VM) che sto usando bash è DYN, mentre gcc è EXEC.
Su Ubuntu 16.04 LTS (WSL su Windows) sia bash che gcc sono EXEC.
Su Ubuntu 17.10 (Live da VM) sia bash che gcc (una volta installato) sono EXEC.

Ozozuz comunque ha osservato segfault anche su Ubuntu 17.10 live, sembra.

A proposito: anche dopo avere aumentato la memoria a 8 GB OpenSUSE mi falisce il test sempre dopo 19 minuti (senza segfault).

alexsky8

19-10-2017, 11:20

Anche fosse solo il 1% di utenti interessati siamo comunque di fronte a numeri esageratamente elevati.

il problema è marginale negli effetti perchè chi incappa in quell'errore non utilizza la CPU come il 99,999% degli utenti
ma secondo me le CPU affette da quell'errore sono molte ma molte più dell' 1% però ripeto nell'operatività normale "per ora" non sono segnalate anomalie

moob1

19-10-2017, 11:32

SpongeJohn

19-10-2017, 11:41

:read: :read:

La mia cpu a default passa 3 ore di blend test con prime 95 (oltre non vado dato che la corrente la pago), 10 cicli a very high di IBT e svariate e svariate sessioni di utillizzo per svariate ore: senza l'ombra di un problema.
Ergo: la mia cpu funziona.

Non farei RMA perchè come vedi non ne ho bisogno. MA visto che la cpu dovrò rivenderla: già so come andrebbe a finire se poi mi verrebbe chiesto: ma va in segfault?

Al che la mia contro-domanda sarebbe: ma usi linux? E vai col mambo.

moob1

19-10-2017, 11:49

La mia cpu a default passa 3 ore di blend test con prime 95 (oltre non vado dato che la corrente la pago), 10 cicli a very high di IBT e svariate e svariate sessioni di utillizzo per svariate ore: senza l'ombra di un problema.
Ergo: la mia cpu funziona.

Non farei RMA perchè come vedi non ne ho bisogno. MA visto che la cpu dovrò rivenderla: già so come andrebbe a finire se poi mi verrebbe chiesto: ma va in segfault?

Al che la mia contro-domanda sarebbe: ma usi linux? E vai col mambo.

Sono un programmatore, scrivo programmi cross platform e per compilare, per una questione pratica uso Linux. Se vuoi ti linko anche alcuni progetti open source belli pesanti a cui lavoro e ho lavorato ;)

Comunque come ti è stato detto il problema non è relativo a Linux ma relativo alla CPU e si presenta anche su Windows, quindi la tua domanda ha ben poco valore.

Mister D

19-10-2017, 11:58

Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

L'apoteosi è il tuo ragionamento se ho compreso bene dove vuoi arrivare.
In pratica per te visto che AMD, o intel, giustamente e in modo assolutamente sacrosanto, ti danno il diritto a poter sostituire la cpu non conforme con una conforme, l'utente è in dovere di farsela sostituire (quindi da un diritto diventa un obbligo)???? Ma in quale mondo vivi?

Non ci sta scritto da nessuna parte che se hai un diritto questo diventi automaticamente un dovere.
Per cui:
CASO A

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome non interessa il mio ambito di utilizzo e che quindi il mio pc è stabile da quando l'ho preso senza nessun problema, preferisco non avvalermi del mio diritto di RMA perché il pc rimarebbe fermo e perché probabilmente dovrò pagare le spese di andata.
Ha ragione? SI'

CASO B

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome ho diritto ad avere la cpu perfettamente conforme e mi da fastidio tenermi una cosa che potrebbe anche solo mostrare un giorno un problema e che non saperei se dipende o no d questo bug, di farmela sostituire.
Ha ragione? Ancora SI'

Capisci che a volte entrambe le visioni sono corrette? O vuoi uniformare il pensiero degli altri al tuo? Forse non ti sei reso conto dell'assurdità di tale ragionamento: DIRITTO è diverso da DOVERE.

Poi per tutti quelli che dicono che si minimizza il problema. Ma dove? Ma se anche sul thread principale vi hanno consigliato di aprire un thread apposito e farlo pinnare in evidenza nella sezione questo vorrebbe dire mettere a tacere questa importante discussione? Ma siete seri????? Non ci posso credere.

Sarebbe stato molto peggio e forse equivalente ad insabbiarlo (poi con che movente me lo dovresti spiegare) tenere la discussione nel thread ufficiale facendo apposta non rispondervi e facendo passare con indifferenza il problema, in modo che il problema stesso fosse "insabbiato" dall'elevato numero di post del thread ufficiale.

Incomincio a sospettare che si stia perdendo il buon senso e la ragionevolezza.

AMD ha detto che esiste il problema, che ha fatto dei test, che per lei è un problema solo su linux e non su tutte le cpu, che ha modificato la selezione, che tutti hanno diritto a sacrosanta RMA e che verrà spedita cpu da loro testata, cos'altro doveva fare?
Sì una cosa avrebbe dovuto farla: pubblicare prima tutti gli errata e purtroppo ancora non lo ha fatto e questo sì che potete puntargli il dito addosso perché è un comportamento poco trasparente visto che con tutte le altre cpu ha sempre pubblicato il "revision guide".

s12a

19-10-2017, 11:59

il problema è marginale negli effetti perchè chi incappa in quell'errore non utilizza la CPU come il 99,999% degli utenti
ma secondo me le CPU affette da quell'errore sono molte ma molte più dell' 1% però ripeto nell'operatività normale "per ora" non sono segnalate anomalie

Provando a leggere in giro nel corso dei giorni passati ho notato report di problemi potenzialmente correlati al segfault, come ad esempio (Windows):

https://community.amd.com/message/2825959#comment-2825959#2825959

Had my setup for about three weeks, Ryzen 1600X on an MSI X370 Gaming Titanium, GSkill 3600 CL15 RAM, watercooled etc etc

After putting my rig through various stress tests while trying to find a stable overclock I was getting perplexed on why somedays I could be prime95 stable custom 14000mb for over 8 hours, but then the next day would fail instantly, then after a reboot would be stable for several hours etc etc

So I decided to try out the different tool available for testing if my CPU was also part of the 'fault' batches.

And here I am,

My 1600X segfaulted first after 136 seconds with the BIOS set at optimized default, so I thought id better manually key in the memory timings that I had been using that had tested stable with prime95.

Segfault after 148 seconds......

In un caso un utente ha riportato che la sostituzione del processore che mostrava segfault ha risolto problemi di reboot, errori hardware, etc (Linux):

https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr?p=980443#post980443

Sembra che alcuni (non tutti) utenti Ryzen abbiano problemi con un certo programma su Windows per inserire rom nella SNES Mini; potrebbe essere correlato al Segfault:

https://github.com/ClusterM/hakchi2/issues/620

Altri ad esempio dal forum sul sito AMD riguardante il segfault hanno anche problemi di reboot che a volte vengono risolti in parte disabilitando i C-state inferiori.

Non è chiaro se questi siano tutti riconducibili allo stesso inconveniente, o se siano qualcosa di diverso. Se rimane la possibilità, il dubbio rimane.

Per conto mio, io avevo intenzione non urgente di upgradare ad un processore 8C/16T per usarlo anche in ambiti come la compilazione in particolar modo di alcuni programmi grafici cross-platform che uso spesso (principalmente Krita, Blender), con la possibilità di testare anche frequentemente altri branch in sviluppo. Dunque farei parte di quello 0.X% di utenti potenzialmente interessato dal problema. Visto che sembrano essercene potenzialmente anche altri e che non è sicuro se sia stato totalmente risolto con la nuova produzione, non ho problemi a rinviare l'acquisto.

Mister D

19-10-2017, 12:02

Sono un programmatore, scrivo programmi cross platform e per compilare, per una questione pratica uso Linux. Se vuoi ti linko anche alcuni progetti open source belli pesanti a cui lavoro e ho lavorato ;)

Comunque come ti è stato detto il problema non è relativo a Linux ma relativo alla CPU e si presenta anche su Windows, quindi la tua domanda ha ben poco valore.

Tu sei un programmatore.
Lui non lo è.
Tu hai il diritto a fartela sostituire e te ne avvali.
Lui ha il diritto a farsela sostitutire e NON se ne avvale.

Per te c'è uno che sbaglia e uno che fa giusto? Per me no in quando entrambi fate bene. Cavolo è difficile da capire che entrambe le visioni sono corrette e condivisibili? No perché nel vostro mondo di perfezione se uno ha un diritto deve farsela sostituire, non è che può farsela sostituire. :confused: :confused: :confused: :confused: :confused: :confused: :confused:

Mister D

19-10-2017, 12:09

Io ho notato molto astio verso chi vuole farsi cambiare la cpu anche se non fa parte del nostro 1% di utilizzatori a cui il bug potrebbe effettivamente danneggiare la produttivitá, cosa a mio avviso incredibilmente sbagliata.
Ma si, tutte le scelte sono legittime, anche di quella del povero Pippo che ha pagato 300€ di cpu per giocare senza aver la piú pallida idea di cosa sia Linux ma vuole comunque farsi cambiare la cpu.

Io invece ho notato astio per chi ha il diritto di farsela sostituire ma decide di non farsela sostituire come fosse un cavolo di obbligo sociale!
Avete il sacrosanto diritto di essere incavolati, di farvela sostituire dal produttore ma non avete il diritto di far diventare un obbligo la sostituzione anche per chi non la pensa come voi. Questo è il succo.

Mister D

19-10-2017, 12:11

Io ho notato molto astio verso chi vuole farsi cambiare la cpu anche se non fa parte del nostro 1% di utilizzatori a cui il bug potrebbe effettivamente danneggiare la produttivitá, cosa a mio avviso incredibilmente sbagliata.
Ma si, tutte le scelte sono legittime, anche di quella del povero Pippo che ha pagato 300€ di cpu per giocare senza aver la piú pallida idea di cosa sia Linux ma vuole comunque farsi cambiare la cpu.

Edit - forse OT: Ho inviato la richiesta per l'rma ieri e sto ricevendo strane mail da AMD, non iniziamo bene :asd:
https://image.prntscr.com/image/d_dJqfGpQ4_dphaOApuPRg.png
https://image.prntscr.com/image/3prijQ6zTX2kmiv2OEXRCw.png

Quindi cosa vorrebbe dire questo? Che AMD lo sta facendo apposta perché non vuole sostituirtela e vuole risparmiarsi un reso? Spero sia una bella battuta :asd:

Mister D

19-10-2017, 12:15

Abbiamo avuto una percezione completamente opposta della cosa, siccome i piú saggi dicono come la veritá stia nel mezzo, pace fatta e chiudiamo questa diatriba :D

Io sono pronto a chiuderala, basta che poi non si attacchi nuovamente un'utente solo perché ha deciso di non farla sostituire e questa non è una percezione:
Quote:
Originariamente inviato da SpongeJohn Guarda i messaggi
Purtroppo io la cpu devo rivenderla su questo forum nel momento in cui decideró di cambiarla. Altrimenti con il cavolo che avrei fatto un rma, lo faccio solo perché l'utenza di un certo tipo va assecondata quando ti metti dalla parte del venditore, anche nelle psicosi.

risposta che suona come attacco personale per non aver deciso di sostituirla perché fallata, ma sostituita per futura rivendita:
Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Ora rispondi, ho percepito male? :asd: Per me è oggettivo cosa si scrive. verba volant, scripta manent.

SpongeJohn

19-10-2017, 12:16

1% sono svariate migliaia di utenti, ti sembra un problema marginale?
A me no.

Più raro ma non assente.
Il fatto che ora accada meno spesso non vuol dire che non sia un problema e soprattutto non vuol dire che in futuro il problema non possa presentarsi con una frequenza maggiore o anche in altri ambiti.

Questo è falso.
GCC permette, già dalla versione 6.*, di specificare march=znver1, le differenze passando da una impostazione MARCH ad un'altra sono presenti ed abbastanza significative.
Chi si lamentava di binari poco ottimizzati rispetto all'impostazione march=haswel usava GCC vecchio, in combinazione con altre impostazioni non consigliate (ad esempio -O3) a pochissima distanza dal lancio.
Aggiungo poi che malgrado march=hawsel producesse binari più efficienti lo faceva a discapito della stabilità.
Sul fatto che il kernel Linux sia poco ottimizzato per Ryzen io avrei da ridire, ad esempio XFR e C&Q hanno subito funzionato correttamente.
È Windows quello che ha avuto bisogno di un nuovo profilo energetico apposito e tutt'ora è comunque pieno di gente che bestemmia per far andare correttamente il C&Q.

Posta i link, possibilmente non risalenti a 6 mesi fa.

Non si sta parlando di win vs linux, detto questo ti rispondo (anche se dopo i tuoi insulti di qualche tempo fa, dovrei proprio evitare ma vuoi i link, quindi...)

Buona lettura.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00624.html

Ancora nessuno comunque mi ha spiegato perchè ad esempio se è assodato che un singolo programma (sotto win) che monitora temp/timings e frequenze (hwinfo64) può far andare in schermata blu una configurazione che passa ore di OCCT e compagnia cantata: perché non può essere un errore software in congiunzione con la scarsa ottimizzazione lato bios/kernel il problema dell'instabilità sotto linux.

P.s. l'uscita sui presunti incendi è da incorniciare. Nessuna scheda madre ha preso fuoco per colpa di una RX, era un'esagerazione di alcuni smartass riguardo all'assorbimento fuori specifica dallo slot Pci. Polemica assolutamente inutile ma che ha lasciato talmente il segno che per mesi si è sentito: Ma è sicuro montare una rx o brucio il pc?

Mister D

19-10-2017, 12:17

? Mai nemmeno accennato una cosa del genere :confused:, e poi parli di astio verso chi non vuole cambiare la cpu.
Semplicemente mi sta un po'stressando questa storia e volevo scherzarci su.

Edit: e magari sapere se qualcuno aveva giá avuto esperienza di RMA con AMD visto che per me é la prima volta al di fuori di amazon :asd:

Si ma se tu posti una cosa del genere sembra vuoi sottintendere qualcosa. Questo lo capisci vero? Infatti te l'ho chiesto e ora ho appurato che non lo hai fattoin cattiva fede, ma bensì in buona fede per riderci su ma qualcuno lo può leggere diversamente. Non trovi?

SpongeJohn

19-10-2017, 12:20

Io sono pronto a chiuderala, basta che poi non si attacchi nuovamente un'utente solo perché ha deciso di non farla sostituire e questa non è una percezione:
Quote:
Originariamente inviato da SpongeJohn Guarda i messaggi
Purtroppo io la cpu devo rivenderla su questo forum nel momento in cui decideró di cambiarla. Altrimenti con il cavolo che avrei fatto un rma, lo faccio solo perché l'utenza di un certo tipo va assecondata quando ti metti dalla parte del venditore, anche nelle psicosi.

risposta che suona come attacco personale per non aver deciso di sostituirla:
Qui siamo proprio all'apoteosi.
Tu quindi ti saresti tenuto una CPU fallata per far risparmiare un reso alla amata AMD?
Tu e gli altri fenomeni nel thread ufficiale avete un attaccamento anomalo a questa azienda, manco fosse un vostro parente.
Queste son multinazionali dai fatturati esagerati, se fanno una cappellata è giusto che sistemino il guaio a loro spese.

Ora rispondi, ho percepito male? :asd: Per me è oggettivo cosa si scrive. verba volant, scripta manent.

Per la cronaca: io ho deciso di fare RMA giorni fa, sono tra i primi ad aver postato in questo thread gli screenshot e la mia decisione (pagina 2?) ...

Il motivo l'ho spiegato più volte, di fare un piacere ad AMD non facendo RMA non mi passa manco per l'anticamera del cervello. La mia motivazione è sia una questione di correttezza verso chi acquisterà la mia cpu. Sia economica, visto che dovrei rivenderla come "presumibilmente difettata".

digieffe

19-10-2017, 12:21

Dimostrazione finale che i link manco li hai letti.
Non si tratta di "mal comune..." Ma di "due pesi, due misure" se vogliamo rimanere nell'ambito delle ovvietà dei detti popolari.

Prima di affermare che il suddetto "bug" si presenta anche con visualstudio, cygwin: vorrei leggere bug report dettagliati e chiarificatori. Link? O ancora meglio: fonte?

Ma anche fosse cosí, vogliamo tirare fuori i numeri di quanti usano una cpu per programmare e aggreghiamo i numeri di chi usa linux e win? A quanto ammontiamo come percentuale rispetto all'uso comune che si fa di un pc?

Intorno al 5%? Abbondiamo, 6?
Anche nel caso il problema si presenti sotto windows (e ripeto, le fonti di questa affermazione o le si posta ed é bene che siano affidabili, o la si finisce di ripeterlo), nessun programma di uso comune (anche in ambito lavorativo) non farà mai uso di quelle "istruzioni". Ci vogliamo inventare di sana pianta che dall'oggi al domani compilare diverrà cruciale per chi usa excel, photoshop, blender, firefox autocad etc etc?
Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai.
Stiamo parlando delle classiche paranoie da forum

Ultimo appunto, dichiarare che le ottimizzazioni (mancanti o errate) del compilatore o del kernel non contano perché qualsiasi cpu deve essere in grado di compilare in qualsiasi condizione: o lo dimostri ad esempio usando degli i5 e dandogli in pasto i comandi per BD e lo lasci compilare per anche 48 ore (beninteso, alcuni si lamentano che questa sono le condizioni alle quali si presentno i segfault: loop di 48 ore... Manco la nasa), usando un kerbel compilato per Bd.
Vediamo con queste condizioni, quante macchine passano il test.

John, con tutto il rispetto, ciò che ho scritto, pur senza spiegarlo sufficientemente, sarebbe ovvio per qualunque programmatore assembler con conoscenze di micro-architettura.
Col massimo rispetto, permettimi che faccia una supposizione, da ciò che scrivi sembra che tu non sia nè programmatore assembler, né conosca bene la micro-architettura dei calcolatori, mi confermi ciò?
(poi può benissimo essere che per motivi tuoi tu lo sia ma ti sei espresso in con contenuto ed modi impropri all'argomento tecnico).

ti dico ciò perché, in questo periodo il mio tempo libero scarseggia (e non sono stipendiato dalle due case che producono x86) e non vorrei trovarmi a fare un lavoro di ricerca di fonti e spiegazioni tecniche a fronte di tanti argomenti che a me sembrano non congrui: da come parli di istruzione (invece di pattern), di ottimizzazione, kernel, Nasa ecc. sembra che tu non abbia ben chiaro in profondità di cosa tu stia parlando
chiaro, sempre con rispetto :flower:

Ps: se non avessi letto i link come avrei fatto a mettere il post sul PIE?
Ps2: alla nasa utilizzano versioni "particolari di cpu" oltre alle verifiche formali.
Ps3: tutte le macchine in quelle condizioni DEVONO passare il test

avevo scritto il post come sopra ma non avevo fatto caso a questa frase
"Credici pure, se tu lo ritieni possibile. Peccato che nella vita reale non accadrà mai."
per formazione non avresti potuto mai scrivere una cosa del genrere, vero che non sei nè ingegnere nè informatico? :-/

cerca di scrivere cose coerenti così ne riparliamo :flower:

Mister D

19-10-2017, 12:24

Trovo che non mi aspettavo tutta questa malizia nella lettura di un commento, dopo 3 pagine di botta e risposta di test ho inviato la richiesta di rma e ho ricevuto delle mail strane in cui sembrava impazzito il loro server di posta e mi ha fatto ridere.

Perdonami ma tra fraintendere una semplice immagine fino ad arrivare ad un AMD lo sta facendo apposta perché non vuole sostituirtela e vuole risparmiarsi un reso? ce ne sta di differenza.

Comunque siamo tutti ot, un bel respiro e andiamo avanti :D

Ok sarò malizioso io e infatti ti ho anche scritto che te l'ho chiesto apposta e che dopo la tua risposta ho capito la tua buona fede per riderci sù. Cosa dire di più? Scusami per essere stato eccessivamente malizioso.;)

ccmarco2004

19-10-2017, 12:30

Vedo con dispiacere che agli integralisti non è bastato cacciare dal 3ad principale gli utenti interessati dalla tematica del bug del segfault, perchè non giova all'immagine della squadra.

Con la creazione del 3ad dedicato ora assistiamo alle incursioni di sabotaggio, negazione e minimizzazione.

animeserie

19-10-2017, 12:32

Più raro ma non assente.
Il fatto che ora accada meno spesso non vuol dire che non sia un problema e soprattutto non vuol dire che in futuro il problema non possa presentarsi con una frequenza maggiore o anche in altri ambiti.

... e si continua a minimizzare e fare confronti con intel e con altre situazioni che non c'entrano nulla. Perchè quest'ultima necessità? mal comune (bug irrisolti) mezzo gaudio?

si parla di ottimizzazioni generiche per BD o amd, ma cosa centra? una cpu deve poter eseguire anche codice non ottimizzato!

e si parla di linux e/o di gcc quando se pur in maniera minima il problema compare è riproducibile in altri ambiti! (wsl, cygwin e visualstudio ?)

dalle ultime informazioni di è visto che si verifica anche con l'utilizzo di un solo core.

è chiaro cosa sia un pattern di istruzioni? da quanto si legge sembra proprio di no. Spero che qualcuno abbia voglia di spiegarlo adeguatamente.

pattern di istruzioni, motivo per il quale si potrà presentare anche in software futuri di qualsiasi natura che presentino la stessa situazione.

Non ancora è chiaro in quale status della cpu l'errore emerga, ma soprattutto non si sa se l'errore si presenta su base probabilistica o deterministica. Il che la dice tutta sulla natura di quest'errore!

e per favore basta con le minimizzazioni :)

+1

digieffe

19-10-2017, 12:45

Ancora nessuno comunque mi ha spiegato perchè ad esempio se è assodato che un singolo programma (sotto win) che monitora temp/timings e frequenze (hwinfo64) può far andare in schermata blu una configurazione che passa ore di OCCT e compagnia cantata: perché non può essere un errore software in congiunzione con la scarsa ottimizzazione lato bios/kernel il problema dell'instabilità sotto linux.

come si fa a spiegare quando si dovrebbero avere le basi di:
Architettura dei calcolatori I e un po' del II + Sistemi operativi (sempre che non siano cambiati i programmi di studio)
e Pratica di programmazione assembler?

Edit: anche questa volta il termine ottimizzazione è stato utilizzato in modo non appropriato (e sono stato cortese)

moob1

19-10-2017, 12:47

come si fa a spiegare quando si dovrebbero avere le basi di:
Architettura dei calcolatori I e un po' del II + Sistemi operativi (sempre che non siano cambiati i programmi di studio)
Pratica di programmazione assembler?

Edit: anche questa volta il termine ottimizzazione è stato utilizzato in modo non appropriato (e sono stato cortese)

Sono ancora quelli i programmi, te lo assicuro :asd:

digieffe

19-10-2017, 12:55

se c'è qualcuno di buona volonta che abia un po' di tempo, prego di dare una spiegazione divulgativa alle domande poste :)

Gioz

19-10-2017, 13:01

un consiglio generale: non sfidatevi a dimostrare di aver ragione, indagate sulla questione, altrimenti il topic - che è impostato benissimo fin dal primo post - va verso allegre signorine poco vestite e di provenienza ignota ai margini della strada.

evil weasel

19-10-2017, 13:24

L'apoteosi è il tuo ragionamento se ho compreso bene dove vuoi arrivare.
In pratica per te visto che AMD, o intel, giustamente e in modo assolutamente sacrosanto, ti danno il diritto a poter sostituire la cpu non conforme con una conforme, l'utente è in dovere di farsela sostituire (quindi da un diritto diventa un obbligo)???? Ma in quale mondo vivi?

Non ci sta scritto da nessuna parte che se hai un diritto questo diventi automaticamente un dovere.
Per cui:
CASO A

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome non interessa il mio ambito di utilizzo e che quindi il mio pc è stabile da quando l'ho preso senza nessun problema, preferisco non avvalermi del mio diritto di RMA perché il pc rimarebbe fermo e perché probabilmente dovrò pagare le spese di andata.
Ha ragione? SI'

CASO B

Sono un utente che non programma, non usa linux, né VM, né WSL e scopro di questo bug.
Decido, che siccome ho diritto ad avere la cpu perfettamente conforme e mi da fastidio tenermi una cosa che potrebbe anche solo mostrare un giorno un problema e che non saperei se dipende o no d questo bug, di farmela sostituire.
Ha ragione? Ancora SI'

Capisci che a volte entrambe le visioni sono corrette? O vuoi uniformare il pensiero degli altri al tuo? Forse non ti sei reso conto dell'assurdità di tale ragionamento: DIRITTO è diverso da DOVERE.

Poi per tutti quelli che dicono che si minimizza il problema. Ma dove? Ma se anche sul thread principale vi hanno consigliato di aprire un thread apposito e farlo pinnare in evidenza nella sezione questo vorrebbe dire mettere a tacere questa importante discussione? Ma siete seri????? Non ci posso credere.

Sarebbe stato molto peggio e forse equivalente ad insabbiarlo (poi con che movente me lo dovresti spiegare) tenere la discussione nel thread ufficiale facendo apposta non rispondervi e facendo passare con indifferenza il problema, in modo che il problema stesso fosse "insabbiato" dall'elevato numero di post del thread ufficiale.

Incomincio a sospettare che si stia perdendo il buon senso e la ragionevolezza.

AMD ha detto che esiste il problema, che ha fatto dei test, che per lei è un problema solo su linux e non su tutte le cpu, che ha modificato la selezione, che tutti hanno diritto a sacrosanta RMA e che verrà spedita cpu da loro testata, cos'altro doveva fare?
Sì una cosa avrebbe dovuto farla: pubblicare prima tutti gli errata e purtroppo ancora non lo ha fatto e questo sì che potete puntargli il dito addosso perché è un comportamento poco trasparente visto che con tutte le altre cpu ha sempre pubblicato il "revision guide".

Ma ti è chiaro o no che il problema che ora si presenta solo durante la compilazione potrebbe espandersi anche ad altre applicazioni di uso comune?
Oltre tutto a giudicare da come rispondi quello a cui tira il culo sei tu, non noi.
L'avete menata per mesi, finalmente qualcuno si è preso la briga di aprire questo thread, evitate (tu e l'altro fenomeno) di inquinarlo con post senza senso.
Nessuno sano di mente sapendo di avere in mano una CPU buggata se la terrebbe.

Non si sta parlando di win vs linux, detto questo ti rispondo (anche se dopo i tuoi insulti di qualche tempo fa, dovrei proprio evitare ma vuoi i link, quindi...)

Buona lettura.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00624.html

Ancora nessuno comunque mi ha spiegato perchè ad esempio se è assodato che un singolo programma (sotto win) che monitora temp/timings e frequenze (hwinfo64) può far andare in schermata blu una configurazione che passa ore di OCCT e compagnia cantata: perché non può essere un errore software in congiunzione con la scarsa ottimizzazione lato bios/kernel il problema dell'instabilità sotto linux.

P.s. l'uscita sui presunti incendi è da incorniciare. Nessuna scheda madre ha preso fuoco per colpa di una RX, era un'esagerazione di alcuni smartass riguardo all'assorbimento fuori specifica dallo slot Pci. Polemica assolutamente inutile ma che ha lasciato talmente il segno che per mesi si è sentito: Ma è sicuro montare una rx o brucio il pc?

Devo aver colpito nel segno se te la sei presa a questo modo e ancora lo ricordi a distanza di ?mesi?

4 commit come ce ne sono a valanghe, cosa dovrebbero dimostrare?

Per la seconda volta:
1. è possibile che i crash siano determinati da un problema software, ma se questo fosse il caso secondo te AMD avrebbe messo in piedi tutto sto casino per sostituire le CPU?
2. se fosse un problema software tutte le CPU sarebbero affette, ma così non è.
È quindi evidente che il problema è di natura hardware, GCC, quei 4 commit come ce ne sono a migliaia, e Linux non centrano niente.
Queste cose le ho scritte già svariate volte, leggi i miei post oppure evita proprio di rispondermi.

p.s. Le piste e gli strati del PCB sono dimensionati per seguire gli standard, se ci passa una corrente maggiore si va incontro a tutta una serie di problematiche che possono portare anche ad un incendio.
Non centra comunque niente con la discussione, così come non centra niente il fatto che anche Intel faccia le sue cappellate.
Evita di inquinare il thread.

CiccoMan

19-10-2017, 13:33

Ma ti è chiaro o no che il bug che ora si presenta solo durante la compilazione potrebbe espandersi anche ad altre applicazioni di uso comune?
Oltre tutto a giudicare da come rispondi quello a cui tira il culo sei tu, non noi.
L'avete menata per mesi, finalmente qualcuno si è preso la briga di aprire questo thread, evitate (tu e l'altro fenomeno) di inquinarlo con post senza senso.
Nessuno sano di mente sapendo di avere in mano una CPU buggata se la terrebbe.

E' sicuro che le cpu di recente produzione non presentino tale bug? No perchè mi sembra di capire che la situazione sia nebulosa a riguardo.

Personalmente non faccio il reso (1800x 8th settimana) :ciapet:

s12a

19-10-2017, 13:37

Attenzione: ho il sospetto che gcc 7.2 (incluso - che abbia provato - in Ubuntu 17.10, Fedora 26, OpenSUSE Tumbleweed) abbia problemi a compilare i sorgenti di gcc 7.1.0 usati da ryzen-test. Ubuntu 17.04 usava gcc 6.x. Ubuntu 16.04 LTS (da WSL) usa gcc 5.4 e non mi da' il seguente errore, che accade sempre in maniera uguale su tutti i loop:

[...]In file included from /home/xxxxx/ryzen/ryzen-test-master/gcc-7.1.0/libgcc/unwind-dw2.c:403:0:
./md-unwind-support.h: In function 'x86_64_fallback_frame_state':
./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type 'struct ucontext'
sc = (struct sigcontext *) (void *) &uc_->uc_mcontext;
^~
make[3]: *** [/home/xxxxx/ryzen/ryzen-test-master/gcc-7.1.0/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/xxxxx/ryzen/ryzen-test-master/buildloop.d/loop-0/x86_64-pc-linux-gnu/libgcc'
make[2]: *** [Makefile:21950: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/home/xxxxx/ryzen/ryzen-test-master/buildloop.d/loop-0'
make[1]: *** [Makefile:27079: stage1-bubble] Error 2
make[1]: Leaving directory '/home/xxxxx/ryzen/ryzen-test-master/buildloop.d/loop-0'
make: *** [Makefile:942: all] Error 2

Con ./kill-ryzen.sh 2 2 mi fallisce (senza segfault) in circa 480 secondi (8 minuti), mentre con ./kill-ryzen 4 4 in circa 1150 secondi (~19 minuti).
Con Ubuntu 16.04 LTS (dal WSL) il test sembrava continuare indefinitamente.

In un modo o nell'altro serve qualche modifica nel procedimento riportato in precedenza. Distribuzione diversa, diverso sorgente da compilare od un modo per fargli usare una versione vecchia di gcc.

Al momento gli sto facendo compilare gcc 6.4.0, sembra continuare ad andare senza problemi per più cicli completi consecutivi. Questo richiederebbe la modifica di qualche riga nello script. Non è chiaro se i segfault anche con questo uscirebbero fuori (dovrebbero, sulla carta).

EDIT: Sembra sia questo problema, anche riportato da altri:
https://github.com/suaefar/ryzen-test/issues/17
https://github.com/suaefar/ryzen-test/issues/6

C'è un fork qui da un altro utente dello stesso test che dovrebbe andare:
https://github.com/Oxalin/ryzen-test

evil weasel

19-10-2017, 13:47

E' sicuro che le cpu di recente produzione non presentino tale bug? No perchè mi sembra di capire che la situazione sia nebulosa a riguardo.

Personalmente non faccio il reso (1800x 8th settimana) :ciapet:

Threadripper e Epyc non sono affetti dal problema, le CPU che tornano dal RMA sembrano essere buone.

paolo.oliva2

19-10-2017, 13:56

https://imgur.com/a/sv5r3

Mi sono appena reso conto che le istruzioni date in precedenza erano forse troppo sommarie e danno troppe cose per scontato. Ecco istruzioni passo-passo che usano Ubuntu 17.10 che ho linkato poco sopra in versione beta (dovrebbe uscire domani). Non dovrebbero esserci troppe differenze con la 17.04.

È più pratico se invece di usare una seconda chiavetta USB il file "https://github.com/suaefar/ryzen-test/archive/master.zip" lo scarichi da Firefox su Ubuntu e lo apri usando l'interfaccia grafica, facendo "Open With"....

Perfetto, questa sera lo provo (scusa la mia incompetenza).

Io avevo già scompattato il tutto su una seconda chiavetta.

Poi, siccome ho voglia di spataccare con il procio e non ho più nulla che mi attizza per ora, vorrei provare a risolvere l'errore se mi compare o far venire l'errore se non compare, dando per scontato che sia un prb di L3 e selezione.

Non dovrebbe essere difficile questa operazione... perchè se di selezione si tratta, basta impostare frequenza core (e di cascata la L3)/parametri DDR4 più conservativi o il contrario.

s12a

19-10-2017, 14:03

@paolo.oliva

Con lo stesso procedimento, usa questo di zip. L'altro ha problemi con Ubuntu 17.10 ed altre recenti distribuzioni di Linux. Provvederò ad aggiornare la prima pagina:

"https://github.com/Oxalin/ryzen-test/archive/master.zip"

digieffe

19-10-2017, 14:10

Non si sta parlando di win vs linux, detto questo ti rispondo (anche se dopo i tuoi insulti di qualche tempo fa, dovrei proprio evitare ma vuoi i link, quindi...)

Buona lettura.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00624.html

io li ho letti ora vorrei che tu mi spiegassi, uno alla volta, le correlazioni con il "bug" in questione

Mister D

19-10-2017, 14:10

Ma ti è chiaro o no che il problema che ora si presenta solo durante la compilazione potrebbe espandersi anche ad altre applicazioni di uso comune?
Oltre tutto a giudicare da come rispondi quello a cui tira il culo sei tu, non noi.
L'avete menata per mesi, finalmente qualcuno si è preso la briga di aprire questo thread, evitate (tu e l'altro fenomeno) di inquinarlo con post senza senso.
Nessuno sano di mente sapendo di avere in mano una CPU buggata se la terrebbe.

Sì mi è chiaro che per ora è un ipotesi (con ragione o no non sta a me dirlo) e mi è altrettanto chiaro che per ora il produttore dice che c'è solo compilando su linux (ma posso ragionevolmente pensare che capiti con visual basic o in ambiente linux WSL o VM).
Mi dispiace ma a me non da nessun fastidio parlarne visto che nel thread sia qui che in quello ufficiale io ho portato i link di phronix, se mi desse fastidio (usando altri termini più civili) non avrei manco partecipato o dato il mio contributo. Invece mi da fastidio constatare da parte tua che per te uno è sano di mente SOLO se se si fa sostituire la cpu fallata anche quando ti dice che non compilerà mai e non userà mai ambienti di sviluppo né in linux né in windows e che per tutto il tempo ha avuto un sistema stabile senza schermate. Altresì vedo che non mi hai risposto direttamente ma insisti ad insultare dando del pazzo a chi non la pensa come te. Perfetto. Da questo vedo che è inutile discutere con te ma almeno visto che il mio piccolo contributo l'ho dato in prima pagina, smetti di darmi del fenomeno ad inquinare il thread grazie.

paolo.oliva2

19-10-2017, 14:19

Threadripper e Epyc non sono affetti dal problema, le CPU che tornano dal RMA sembrano essere buone.

Quoto te per evidenziare una cosa.

Ho postato nel TH ufficiale uno screen di AIDA sulla banda della L1/L2/L3 di TR (dando per scontato un comportamento simile con Epyc) e risulta che TR ha valori pressappoco doppi (però con circa il -20%) a pari frequenza rispetto ad un AM4.

Cioè... dando per vero (e non credo ci sia da dubitare) l'affermazione di AMD che si tratti di un prb di selezione, supporrei che il casino venga quando tutti i core usino il totale dei TH e questo impatta sulla L3 e smistamento dei dati.

Avendo la L3 (ma anche L2 e L1) dei valori un >-20% (circa, a spannella), il problema di selezione di per sè è ininfluente, nel senso che io ad esempio a 4,050GHz su 1800X/AM4 ottengo >500 sulla L3, mentre un 1950X alla stessa frequenza da' circa 800, ma che diviso per 2 darebbe 400.

Non so gli Epyc, ma credo probabile che sulla stessa linea possano ottenere risultati doppi rispetto ad un TR, ma ancora più conservativi.

CiccoMan

19-10-2017, 14:20

Threadripper e Epyc non sono affetti dal problema, le CPU che tornano dal RMA sembrano essere buone.

Ripeto, la questione non mi tange, col pc ci gioco e basta (non ho nemmeno Office installato)... e tra l'altro è in arrivo main+cpu nuova e quindi Ryzen rimarrà nel mio case giusto ancora qualche giorno... però avere una soluzione certa farebbe piacere a chi intende, per diletto o per necessità, risolvere il problema.

animeserie

19-10-2017, 14:26

Sono ancora quelli i programmi, te lo assicuro :asd:

Purtroppo confermo :asd:

Uffa, ancora una volta mi sa che sono il più vecchietto :(
ai miei tempi non era "Arch. dei calcolatori" ma "Arch. degli elaboratori".. ma vabbè quelli sono :D

SpongeJohn

19-10-2017, 14:32

io li ho letti ora vorrei che tu mi spiegassi, uno alla volta, le correlazioni con il "bug" in questione

Evidentemente sei fuori pista.

Non sono link che ho fornito per te. In riferimento alla nostra discussione: ho postato nelle pagine precedenti dei link riferiti a quanto accadde con il problema Kaby/sky-lake linux ed Hypertreading. Forse farai bene a rileggerli ed a spiegarmi perchè ho provato a cercare uno script "kabylake killer" ma non ne ho trovato notizia...

Quei link sopra invece, servono a dimostrare che la presunta ottimizzazione al day one: non c'era. Tutt'altro topic.

Alex656

19-10-2017, 14:36

SpongeJohn

19-10-2017, 14:38

Ma ti è chiaro o no che il problema che ora si presenta solo durante la compilazione potrebbe espandersi anche ad altre applicazioni di uso comune?

Questa è una ipotesi campata per aria. Se mi fornsci delle prove serie, se ne può riparlare. Nel mentre però siamo nel campo dell'inutile allarmismo.

Devo aver colpito nel segno se te la sei presa a questo modo e ancora lo ricordi a distanza di ?mesi?

Questa è l'ultima risposta poi vai in ignore list. Se dai del fesso a qualcuno, quel "fesso" tende a ricordarselo.
Ripeto: il problema è che non c'è moderazione in questa sezione del forum, altrimenti i tuoi modi sarebbero preistoria.

s12a

19-10-2017, 14:41

Perdona la mia ignoranza, quindi è possibile che l'eventuale segfault in realtà non sia legato al processore? Io ho fatto il test su Ubuntu 17.10 ed il problema salta fuori quasi subito, su windows il sistema è un orologio svizzero con qualunque stability test, tranne quello del segfault che usa visual studio e non ho ancora provato.

No, questo non è un problema che provoca segfault. Se ti appare la dicitura "segfault" od "invalid opcode" hai comunque trovato il problema.

Semplificando, in questo caso al nuovo compilatore non piace una porzione (non tutto) del codice sorgente in C++ fornito. Con il problema del segfault è il compilatore stesso a fare cose che non dovrebbe fare.

Nel primo caso l'errore appare sempre nello stesso punto/dopo lo stesso tempo (a parità di impostazioni), nel secondo va a random.

alexsky8

19-10-2017, 14:42

s12a

19-10-2017, 14:46

OK quindi con la 17.04 dovrebbe essere ok il test, con la 17.10 servirebbero delle modifiche allo script
quindi per ora lasciamo in sospeso la questione ?
speriamo che qualcuno riesca a ricalibrare il tutto

C'è un fork qui che dovrebbe andare, già modificato come dovrebbe: https://github.com/Oxalin/ryzen-test

Lo ho provato con Fedora 26 (installata, live non va), dopo 40 minuti ho terminato manualmente il test. Prima si fermava sempre dopo 8 minuti (digitando ./kill_ryzen.sh 2 2)

Probabilmente lo script originale verrà aggiornato entro qualche giorno. Ai fini di testare il segfault, questo così com'è per il momento funziona.

EDIT: ho anche provato con Ubuntu 17.10 Live in VM con 8 GB di memoria assegnata, sempre con ./kill_ryzen.sh 2 2 . Il ramdisk dello script l'ho lasciato attivo. Dopo 60 minuti non si è ancora fermato (la mia non è una configurazione che dovrebbe causare segfault, che comunque non ho mai osservato qui), e non c'è alcun imminente problema di memoria. Dico che va bene.

BuRn

19-10-2017, 15:17

SpongeJohn, compilazioni lunghe giorni non sono poi così improbabili per chi usa il PC professionalmente.

Personalmente mi è capitato di compilare OpenCV (libreria per l'image processing) e ci volevano ore, in ufficio build scarna di Yocto Linux per dispositivi embedded e ho avuto il pc occupato per circa 13 ore. E per me è un'attività fuori dalla norma, c'è chi lo fa regolarmente. Poi certo, sono d'accordo che siamo una piccola minoranza, ma come dicevo non è del tutto chiaro se il bug sia limitato a questo contesto: su altri forum c'erano report ci chi riscontrava errori simili nel calcolo scientifico.

AMD ha classificato il bug come Performance Marginality Problem: è un termine che per me ha poco senso. Non è un problema di performance e non è propriamente marginale negli effetti.

Io capisco che AMD è in un momento delicato, è riuscita a lanciare una buona architettura con ottimi consumi dopo anni di difficoltà. Se saltasse fuori che un'alta percentuale di CPU sono fallate e dovesse imbarcarsi in una campagna di richiamo come fece Intel per l'FDIV del Pentium, sarebbe sicuramente una mazzata. Però la situazione è veramente confusa e stanno un po' facendo finta di niente, ma allo stesso tempo sostituiscono le CPU senza storie. Potrebbe anche essere vero che il bug è limitato alla compilazione su Linux, ma senza alcuna motivazione in merito a me riesce più facile credere che non sia così per un motivo di logica, cioè quello che scrivevo nell'altro post: non penso che la compilazione su Linux abbia niente di tanto speciale.

Ah, il tutto da grande simpatizzante di AMD, il mio attuale PC monta Intel, ma ho sicuramente avuto più CPU AMD che non Intel. :)

doctor who ?

19-10-2017, 15:51

sto per testare il 1200, avendo solo 8 gb di ram come mi conviene settare threads\loops ?

animeserie

19-10-2017, 15:58

s12a

19-10-2017, 16:00

sto per testare il 1200, avendo solo 8 gb di ram come mi conviene settare threads\loops ?

Prova con 4 4, che poi dovrebbe essere l'impostazione di default sul tuo processore. Altrimenti 4 2. Se la memoria sarà insufficiente ci sarà un avviso chiaro a riferirlo. Non terminerà subito per quello, ci metterà un (bel) po'.

Ricorda di scaricare il test da questo fork, se usi Ubuntu 17.10: https://github.com/Oxalin/ryzen-test

doctor who ?

19-10-2017, 16:04

Prova con 4 4, che poi dovrebbe essere l'impostazione di default sul tuo processore. Altrimenti 4 2. Se la memoria sarà insufficiente ci sarà un avviso chiaro a riferirlo. Non terminerà subito per quello, ci metterà un (bel) po'.

Ricorda di scaricare il test da questo fork, se usi Ubuntu 17.10: https://github.com/Oxalin/ryzen-test

.04 ho preso l'altro
l'ho fatto andare senza parametri , pare girare da mezz'ora senza problemi

s12a

19-10-2017, 16:25

Live 17.10 con il test di Oxalin sia senza parametri che 4 4 non sembra dare una errori... Che ha sta CPU non lo so:confused:

Da VM o bare metal?

EDIT: a proposito, con 16 16 a me ha dato avviso di memoria insufficiente dopo 23 minuti, con 8 GB di memoria (in VM).

https://i.imgur.com/NxTgX8N.png

doctor who ?

19-10-2017, 17:05

Da VM o bare metal?

EDIT: a proposito, con 16 16 a me ha dato avviso di memoria insufficiente dopo 23 minuti, con 8 GB di memoria (in VM).

https://i.imgur.com/NxTgX8N.png

saturare la memoria più velocemente potrebbe far comparire prima l'errore o non c'entra nulla ?
fatto un giro da un'ora e niente , riavvato e rifatto per mezz'ora e niente , mi sa che ne faccio un altro e mi metto l'anima in pace

Gioz

19-10-2017, 17:14

doctor who ?

19-10-2017, 17:15

moob1

19-10-2017, 17:16

provato anche io il test per puro spirito sportivo, ho un dubbio.
tutto default segfault quasi istantaneo con varie prove, oc segfault quasi istantaneo, vcore e vsoc sparati 1.35V/1.2V sta girando da 45 minuti.
qualcuno con esito positivo ha provato a forzare una tensione maggiore ritrovandosi nell'apparente situazione di non aver problemi?
lo lascio girare ancora un po' poi provo a settare vcore default lasciando il vsoc maggiorato per vedere cosa succede.

E' stato notato più volte che le CPU più fortunate sembrano NON essere affette da segfault, ne segue che, probabilmente per lo stesso principio, alzando il vcore ad una cpu affetta il problema si possa risolvere. Ma non è una vera e propria soluzione, è un workaround.

Sono pronto a scommettere che AMD per risolvere il problema non ha fatto altro che selezionare meglio le CPU.

Gioz

19-10-2017, 17:24

E' stato notato più volte che le CPU più fortunate sembrano NON essere affette da segfault, ne segue che, probabilmente per lo stesso principio, alzando il vcore ad una cpu affetta il problema si possa risolvere. Ma non è una vera e propria soluzione, è un workaround.

Sono pronto a scommettere che AMD per risolvere il problema non ha fatto altro che selezionare meglio le CPU.
questo lo so, mi riferivo al fatto che possa dipendere fortemente dall'uncore come supponevo in precedenza.

per quanto riguarda l'O.C. come scritto varie volte il mio tiene 3.6 a 1.156V, 3.7 a 1.2V, da 3.8 serve settare LLC3 e 1.25V, 3.9 1.33V, 4GHz circa a 1.4V, max boot per navigazione e calcolatrice 4125MHz. però a 4GHz è utilizzabile anche attorno ad 1.35V per varie operazioni ma è fortemente instabile.
dovrebbe essere decisamente nella media, non fortunato ma neanche da buttare.

s12a

19-10-2017, 17:33

saturare la memoria più velocemente potrebbe far comparire prima l'errore o non c'entra nulla ?
Dovrebbe far comparire prima l'errore, ma il fatto che la memoria si saturi più velocemente non è la causa scatenante (questo è piuttosto è un difetto / effetto collaterale di come è stato scritto lo script); il motivo è la quantità maggiore di processi paralleli a caricare la CPU.

fatto un giro da un'ora e niente , riavvato e rifatto per mezz'ora e niente , mi sa che ne faccio un altro e mi metto l'anima in pace
Tanto meglio!

Gioz

19-10-2017, 17:40

sempre per puro sport, ho provato a settare 3.6 1.156V con 1.2V di vsoc, per ora regge.
son sempre più convinto che il problema stia li, probabilmente per epyc e tr hanno effettuato una miglior selezione lato data fabric.

papugo1980

19-10-2017, 18:04

s12a

19-10-2017, 18:09

Update:D

Prima di andare con l'rma visto che amd non si fa sentire mi son fatto dare un altro processore ancora "sono pazzo lo so".
Settimana 34 anche lui, questa volta linux 17.10 da pennetta regge senza dare errori, stoppato dopo 20 minuti sia senza settaggi che 4 4.
Se prima con lo stesso test ed impostazioni dava errori, credo che sia indicativo di una CPU migliore.

Mint ha dato errore subito, ma a questo punto potrebbe essere un falso positivo visto che lo ha fatto con tutti quelli che mi sono passati tra le mani.
Subsystem ha dato anche un errore di build.
Senza analizzare esattamente l'errore e la modalità/tempistiche con le quali accade è difficile dire con certezza a che cosa sia stato dovuto. Con il mio processore io ho eseguito il test mediante Ubuntu 16.04 LTS (WSL) per circa un'ora senza alcun problema di sorta. Ho avuto problemi con Fedora e OpenSUSE per il compilatore più recente (poi risolti con una versione aggiornata del test, precedentemente linkata. Inoltre ho avuto problemi di pacchetti mancanti in entrambi i casi, ed impossibilità di scaricare tutte le dipendenze necessarie con Fedora Live). In ogni caso, ribadisco mai un segfault o qualcosa di riconducibile ad esso.

Diciamo che, in linea di massima, se sopravvive la live 17.10 con il test aggiornato Oxalin senza settaggi, 4 4, ramdisk=false almeno 20 minuti ciascuno posso stare tranquillo con questa cpu ?
Dagli innumerevoli test che ho effettuato, credo che tu possa anche evitare di impostare ramdisk=false; con una distribuzione Live il file system accessibile di default (con la home e le varie subdirectory) è già un ramdisk. Quello che crea il test ha la compressione abilitata (viene montato in /mnt/ramdisk) e dunque sulla carta dovrebbe gravare di meno sull'occupazione effettiva della memoria. L'allocazione dello stesso che imposta lo script è di tipo "sparso", dunque occupa memoria solo quando i dati vengono effettivamente scritti.

https://en.wikipedia.org/wiki/Zram

doctor who ?

19-10-2017, 18:21

Nada, ho provato anche in 16 16, anche se della settimana 24 il 1200 pare pulito.

Considerando che non vedrà mai linux, ne compilerà mai nulla, penso di averlo testato abbastanza, casomai in futuro dovesse sorgere qualche problema tra amd e amazon non penso ci saranno problemi

Gioz

19-10-2017, 18:33

https://imgur.com/h6s0Akg

3600@1.156V VSOC 1.2V ora 17:28(che va bhè, non mi sono accorto fosse impostata con il fuso errato) e script ./kill* 4 4 che registra come ultimo momento 16:54.

nel mio caso il vcore credo non conti, mentre sottoalimentare il soc restituisce segfault nell'immediato, dopo pochissimi secondi, per estensione del discorso sono convinto nella precedentemente formulata ipotesi che il problema risieda li.
intanto lo lascio girare ancora.

s12a

19-10-2017, 18:54

nel mio caso il vcore credo non conti, mentre sottoalimentare il soc restituisce segfault nell'immediato, dopo pochissimi secondi, per estensione del discorso sono convinto nella precedentemente formulata ipotesi che il problema risieda li.
intanto lo lascio girare ancora.
Ottima informazione; cercando in giro sembra comunque che 1.2V di Vsoc sia il massimo valore "sicuro" per un utilizzo continuativo. Non ho però trovato nulla di ufficiale - ammesso che ci sia (forse il primo link qui nella lista mostra informazioni "ufficiose" ma nulla di più, niente spec sheet).

https://www.reddit.com/r/Amd/comments/68s62b/robert_hallock_on_ryzen_overclocking/?st=j8yrorda&sh=0b83edfb
http://www.overclock.net/t/1624603/rog-crosshair-vi-overclocking-thread/0_20
https://community.amd.com/thread/216773
http://overclocking.guide/asus-rog-crosshair-vi-hero-extreme-overclocking-guide/#Safe_Voltage_Ranges
https://www.reddit.com/r/Amd/comments/6jxckt/what_are_safe_vsoc_voltages_for_247_builds/?st=j8yr722f&sh=658822c4
https://hardforum.com/threads/new-to-overclocking-on-ryzen.1927889/
https://seo-renderer.herokuapp.com/r/GAAB350/comments/6i8871/how_to_check_vsoc_voltage_in_hwmonitor/

Gioz

19-10-2017, 19:11

Ottima informazione; cercando in giro sembra comunque che 1.2V di Vsoc sia il massimo valore "sicuro" per un utilizzo continuativo. Non ho però trovato nulla di ufficiale - ammesso che ci sia (forse il primo link qui nella lista mostra informazioni "ufficiose" ma nulla di più, niente spec sheet).

l'ho settato per quello.
al lancio era il vsoc suggerito da asus come massimo day use per le ram fuori specifica.

Nui_Mg

19-10-2017, 20:06

SpongeJohn, compilazioni lunghe giorni non sono poi così improbabili per chi usa il PC professionalmente.
Ma non è solo questo: il punto base è che una cpu general purpose non deve mostrare alcun problema in tutti i possibili utilizzi; può andare di più o di meno a seconda di compiti/applicativi/istruzioni specifiche, ma non certo errori a runtime dipendenti da lei (inoltre, non tutti gli utenti sanno a priori in che comparti si cimenteranno nell'utilizzo, è appunto una cpu general purpose).
Grazie a s12a per aver aperto il thread.

BuRn

19-10-2017, 20:11

alexsky8

19-10-2017, 20:15

questo lo so, mi riferivo al fatto che possa dipendere fortemente dall'uncore come supponevo in precedenza.

per quanto riguarda l'O.C. come scritto varie volte il mio tiene 3.6 a 1.156V, 3.7 a 1.2V, da 3.8 serve settare LLC3 e 1.25V, 3.9 1.33V, 4GHz circa a 1.4V, max boot per navigazione e calcolatrice 4125MHz. però a 4GHz è utilizzabile anche attorno ad 1.35V per varie operazioni ma è fortemente instabile.
dovrebbe essere decisamente nella media, non fortunato ma neanche da buttare.

tutto sommato non male per essere una prima serie; la mia prima CPU 1700 (settimana 16) non riusciva a passare cinebench a 3,6GHz @1,1875V
però i test in Linux manco partivano, errore praticamente immediati :D

SPARTANO93

19-10-2017, 20:23

tutto sommato non male per essere una prima serie; la mia prima CPU 1700 (settimana 16) non riusciva a passare cinebench a 3,6GHz @1,1875V
però i test in Linux manco partivano, errore praticamente immediati :DSarà il 1700 che poi è arrivato a me... Settimana 16 e sfigatissimo in oc, ha bisogno di 1,22v per tenere 3,6ghz

Inviato dal mio SM-G930F utilizzando Tapatalk

alexsky8

19-10-2017, 20:36

Sarà il 1700 che poi è arrivato a me... Settimana 16 e sfigatissimo in oc, ha bisogno di 1,22v per tenere 3,6ghz

sì mi sa che è proprio quello :D
a me dava errori a ripetizione in linux
l'hai rispedito al mittente ?

alexsky8

19-10-2017, 20:39

Sarà il 1700 che poi è arrivato a me... Settimana 16 e sfigatissimo in oc, ha bisogno di 1,22v per tenere 3,6ghz

e pensa che quello attuale sotto 1,22 tiene tranquillamente i 3,8GHz e 7-8°C in meno di quello precedente a 3,6

2 mondi diversi

SPARTANO93

19-10-2017, 20:58

sì mi sa che è proprio quello :D
a me dava errori a ripetizione in linux
l'hai rispedito al mittente ?No, non posso rispedirlo indietro perché il pc non lo uso solo io e quindi non posso lasciarlo fermo per giorni
Lo tengo così come è
Inviato dal mio SM-G930F utilizzando Tapatalk

alexsky8

19-10-2017, 21:06

No, non posso rispedirlo indietro perché il pc non lo uso solo io e quindi non posso lasciarlo fermo per giorni
Lo tengo così come è

perchè fermo per giorni ?
fai il reso con Amazon, ne ordini uno nuovo, quando ti arriva rispedisci quello vecchio
il pc sta fermo 5 minuti, giusto il tempo di sostituire la cpu

SPARTANO93

19-10-2017, 21:09

perchè fermo per giorni ?
fai il reso con Amazon, ne ordini uno nuovo, quando ti arriva rispedisci quello vecchio
il pc sta fermo 5 minuti, giusto il tempo di sostituire la cpuL'ho preso da taocomputer non da Amazon e sono passati più di 30 giorni quindi per i resi è tardi.

Inviato dal mio SM-G930F utilizzando Tapatalk

alexsky8

19-10-2017, 21:14

L'ho preso da taocomputer non da Amazon e sono passati più di 30 giorni quindi per i resi è tardi.

ah ok allora non è il mio vecchio che avevo reso ad Amazon

metal master

19-10-2017, 21:17

in attesa del mio 1700 dall'olanda (seriale 1721), oggi ho provato il test con un ryzen 3 1200 (1726) preso su amazon e che girerò a mio fratello sul suo pc nuovo da assemblare non appena arriva il sostituto.

risultato con la live di ubuntu 17.10 e nuovo script: 50 minuti di test senza nessun errore, col mio 1700 dopo pochi secondi ha dato errore segfault.

altra cosa: con il precedente processore si sono verificati alcuni rari riavvi spontanei del sistema operativo (con schermata nera), ed inoltre con la suite office se aprivo ad esempio word ci metteva più tempo ad aprirsi mentre con questo 1200 è quasi istantaneo.

ora non so se col nuovo aggiornamento di windows che ho installato sia migliorata la compatibilita con ryzen, ma al momento noto queste migliorie.

p.s: la spedizione dell'rma del 1700 è ferma ad Utrecht in Olanda dal 13 e il tracking non si aggiorna.
Ho provveduto ad avvisare ecoparcel e attendo info a breve. Il pacco ovviamente è stato assicurato.

Da quello che leggo in giro c'è voluto anche quasi 1 mese per riottenere il tutto, e' questo e un grande punto a sfavore per chi usa il pc per lavoro, ergo se decidete di fare rma mettete in preventivo che ci vogliono minimo 15-20gg per completare tutta la procedura di sostituzione.

Tra l'altro ho fatto notare all'operatore di Amd nella mail che ad alcuni utenti è stato offerta la spedizione gratuita col conto DHL di Amd, mentre io ho dovuto spendere quasi 20 euro per inviare il tutto.
Mi ha risposto che le politiche di Amd Europa non prevedono di utilizzare un conto DHL AMD per spedizioni a carico di AMD, ma che in casi rari viene concessa questa opportunità.

Con Intel se non erro le 2 spedizioni sono a carico loro per rma.

SPARTANO93

19-10-2017, 21:31

ah ok allora non è il mio vecchio che avevo reso ad AmazonÈ suo fratello :D

Inviato dal mio SM-G930F utilizzando Tapatalk

Debern9093

19-10-2017, 22:21

papugo1980

19-10-2017, 22:47

Debern9093

19-10-2017, 23:12

Non vedo l errore segfault
Dovrebbe stare sotto a fail (magari lascialo fare un altro po)

E quel fail cos'è? L'errore me lo da solo se riavvio il test ma senza riavviare il pc credo sia normale... In ogni caso riproverò il test.. C'è probabilità che il mio processore sia fallato?

papugo1980

19-10-2017, 23:31

Potrebbe ma da quell' errore che vedo non sembra affetto
Perché riavvii il test?

Debern9093

19-10-2017, 23:39

Era una prova che ho effettuato x curiosità.. X riavviare il test riavvio tutto il pc è lo effettuo nuovamente .. Quindi è probabile che non sia affetto? E quel fail a cosa corrisponde?

papugo1980

19-10-2017, 23:45

Ma anche un errore del programma poteva essere...se ne sono viste tanti tipi nelle pagine precedenti
Rifai il test e vedi dopo fail cosa scrive (lascialo fare un altro po)

s12a

20-10-2017, 01:21

Ciao ragazzi mi inserisco anche io nella discussione in quanto ho appena effettuato il test x due volte sul mio ryzen 5 1600x e credo sia affetto dal segfault.. Posto due screen x conferma

https://imgur.com/a/vdRyc

https://imgur.com/a/vffu0

Altra domanda.. Ho acquistato il processore circa un mese fa ma nn ho più la scatola.. E possibile fare comunque rma?

1) Prima domanda: da quale URL hai scaricato ryzen-test? Quello fornito qualche giorno fa non va bene con Ubuntu 17.10 uscito oggi. Per il momento serve la versione (fork) di Oxalin, ossia quella disponibile qui: https://github.com/Oxalin/ryzen-test

(Non quella originale scritta da Suaefar, ossia questa: https://github.com/suaefar/ryzen-test)

2) Seconda domanda: quando l'errore accade, se apri un nuovo tab dal terminale (CTRL+SHIFT+T) e digiti:

tail -n 40 /mnt/ramdisk/workdir/buildloop.d/loop-0/build.log

Sostituendo al numero in "loop-0" il numero del loop che ti ha detto "build failed", che cosa esce fuori? Questo comando lo puoi digitare anche mentre l'altro tab continua a lavorare. È il log delle operazioni che fa; eventuali messaggi di errore dettagliati appaiono lì. Nota che il comando così com'è stampa le ultime 40 righe di quel file. Sostituendo a 40 (in "-n 40") un altro valore, stampa quel numero di righe.

Generalmente parlando, il fatto che il primo errore sia avvenuto dopo 71 secondi ed il secondo dopo il riavvio del PC (da quanto scrivi. Riavviare solo il test e stop può dare problemi con le impostazioni di default) invece dopo 294 secondi non dovrebbe indicare errori ordinari. Mi chiedo perché il kernel non ti indichi segfault però. È possibile che sia comunque successo un errore riconducibile ad esso, ma che non ha provocato segfault (avevo già evidenziato questa possibilità in precedenza; due volte di seguito mi sembra strano tuttavia).

Se però escono fuori riferimenti ad una versione "7.1.0" ed un errore causato dal codice sorgente in un file come qui sotto, hai scaricato la versione sbagliata del test:

https://i.imgur.com/KhhF3VL.png

Notare che usando la versione sbagliata riporta anche da me (in virtual machine) TIME TO FAIL senza errori dal kernel. Però da me falliscono tutti i loop contemporaneamente. Al momento non ho tempo per riprovare, ma dovrebbe ripetersi dopo lo stesso tempo in questo caso:

https://i.imgur.com/XHrix1P.png

EDIT: alla fine ho riprovato, ed ha fallito su tutti i loop con lo stesso errore dal log dopo 508 secondi. Non è comunque un segfault od un problema riconducibile a difetti od instabilità nella CPU.

Debern9093

20-10-2017, 04:16

Ciao grazie per la risposta, ho eseguito il test di oxalin.. Oggi riprovo e ti posto il log mi sembra strano anche a me che fallisce due volte di fila.. Mi scarica le gcc 7.2.0 se nn ricordo male

alexsky8

20-10-2017, 08:53

1) Prima domanda: da quale URL hai scaricato ryzen-test? Quello fornito qualche giorno fa non va bene con Ubuntu 17.10 uscito oggi. Per il momento serve la versione (fork) di Oxalin, ossia quella disponibile qui: https://github.com/Oxalin/ryzen-test

a me con questa versione Oxalin e Ubuntu 17.10 da errore

https://i.imgur.com/pqAsNbz.png

https://i.imgur.com/6yzz7mo.png

s12a

20-10-2017, 09:11

Un chiaro avviso di segfault è infatti proprio quello che si dovrebbe vedere in caso di problemi relativi al thread e la CPU.

alexsky8

20-10-2017, 09:22

Un chiaro avviso di segfault è infatti proprio quello che si dovrebbe vedere in caso di problemi relativi al thread e la CPU.

quindi ?
neppure una CPU uscita bene a sett 33 ne è esente :D

che conclusioni possiamo trarre ?

a sto punto sto pensando di non restituire più immediatamente la CPU ad Amazon ma attendere la prossima generazione a fare la sostituzione perchè il problema potrebbe essere di carattere differente rispetto alla semplice selezione

bagnino89

20-10-2017, 09:34

s12a

20-10-2017, 10:01

quindi ?
neppure una CPU uscita bene a sett 33 ne è esente :D

che conclusioni possiamo trarre ?

a sto punto sto pensando di non restituire più immediatamente la CPU ad Amazon ma attendere la prossima generazione a fare la sostituzione perchè il problema potrebbe essere di carattere differente rispetto alla semplice selezione

O magari è sempre un problema di selezione per questo stepping, ma nel senso che solo le CPU top-binned (casi fortunati o Threadripper) si salvano. Come scritto in precedenza però non penso però che in tal caso AMD possa permettersi di spedire a tutti ottime CPU; se a partire dalla data di produzione 1725 è migliorato qualcosa per tutti (o quasi) nel processo di selezione/binning, l'azienda potrebbe starci rimettendo rispetto a quanto previsto inizialmente.

Nel frattempo potresti provare come Gioz a vedere se aumentando la tensione SoC migliora la stabilità nel test. Da quello che leggo però 1.2V è veramente il limite massimo e forse è già fin troppo alto a quel livello. Di default dovrebbe essere fra 0.9 e 1.0V se ho letto correttamente.

alexsky8

20-10-2017, 10:07

Nel frattempo potresti provare come Gioz a vedere se aumentando la tensione SoC migliora la stabilità nel test. Da quello che leggo però 1.2V è veramente il limite massimo e forse è già fin troppo alto a quel livello. Di default dovrebbe essere fra 0.9 e 1.0V se ho letto correttamente.

dove l'hai letto ?

alexsky8

20-10-2017, 10:10

:winner:

è chiaro che sta storia andrà avanti fino al prossimo step produttivo

s12a

20-10-2017, 10:12

dove l'hai letto ?

Discussione nella pagina precedente:

http://www.hwupgrade.it/forum/showpost.php?p=45111395&postcount=237
http://www.hwupgrade.it/forum/showpost.php?p=45111440&postcount=238
http://www.hwupgrade.it/forum/showpost.php?p=45111491&postcount=239

moob1

20-10-2017, 10:15

alexsky8

20-10-2017, 10:18

Discussione nella pagina precedente:

http://www.hwupgrade.it/forum/showpost.php?p=45111395&postcount=237
http://www.hwupgrade.it/forum/showpost.php?p=45111440&postcount=238
http://www.hwupgrade.it/forum/showpost.php?p=45111491&postcount=239

ah ok ma 1,2 in effetti mi sembra altino

alexsky8

20-10-2017, 10:20

Per legge, dopo aver riscontrato un difetto hai massimo 2 mesi per restituire il prodotto, altrimenti perdi il diritto alla garanzia su quel difetto...

nei 24 mesi se c'è un difetto di fabbricazione che ne possa pregiudicare la corretta funzionalità credo sia abbia il diritto al rispetto della garanzia
comunque attendo la revisione 2 di ryzen e poi chiamo AMazon

moob1

20-10-2017, 10:23

nei 24 mesi se c'è un difetto di fabbricazione che ne possa pregiudicare la corretta funzionalità credo sia abbia il diritto al rispetto della garanzia
comunque attendo la revisione 2 di ryzen e poi chiamo AMazon

Una volta riscontrato hai 2 mesi di tempo per la restituzione però, essenzialmente non puoi fare come ti pare, proprio per evitare casi come il tuo.

alexsky8

20-10-2017, 10:27

Una volta riscontrato hai 2 mesi di tempo per la restituzione però, essenzialmente non puoi fare come ti pare, proprio per evitare casi come il tuo.

non posso permettermi la sostituzione con un altro prodotto potenzialmente affetto dall'errore perchè qua il problema è differente rispetto alla semplice selezione

se TR o Epyc ne sono esenti con uno step successivo attenderò anche Ryzen ad uno step successivo

Angelonero87

20-10-2017, 10:28

Ho fatto un po di test anche io in breve:
Default: segfault
OC: segfault
Default+Vsoc 1.1v: segfault
Default+smt off: PASS
OC+smt off: PASS
nel mio caso sembra essere l'smt ad avere problemi

doctor who ?

20-10-2017, 10:36

Una volta riscontrato hai 2 mesi di tempo per la restituzione però, essenzialmente non puoi fare come ti pare, proprio per evitare casi come il tuo.

come si può dire quando è stato riscontrato ?

alla fine dei conti sarei pronto a scommettere che la maggior parte della gente con la cpu fallata non ne sa nulla, se amd accetta rma senza pensarci troppo, mi viene da pensare che siano (relativamente) in pochi a verificare e chiedere la sostituzione.

Magari si sono fatti i conti ed hanno deciso che sostituire X cpu costa meno, sia economicamente sia sotto altri aspetti, rispetto ad un'eventuale class action/pubblicità negativa/ammissione del problema

moob1

20-10-2017, 10:41

come si può dire quando è stato riscontrato ?

alla fine dei conti sarei pronto a scommettere che la maggior parte della gente con la cpu fallata non ne sa nulla, se amd accetta rma senza pensarci troppo, mi viene da pensare che siano (relativamente) in pochi a verificare e chiedere la sostituzione.

Magari si sono fatti i conti ed hanno deciso che sostituire X cpu costa meno, sia economicamente sia sotto altri aspetti, rispetto ad un'eventuale class action/pubblicità negativa/ammissione del problema

Ovviamente quello sta al buon senso delle persone.

alexsky8

20-10-2017, 11:10

Ovviamente quello sta al buon senso delle persone.

ci mancherebbe ma qua sarebbe ben peggio farsi sostituire 10 CPU per averne una buona e aprire 10 sigilli; credo che la soluzione migliore per tutti sia attendere Ryzen 2 o comunque una revisione

10gg senza CPU per fare RMA da AMD per ora non ci penso neppure

moob1

20-10-2017, 11:25

Rifatto il test su ubuntu 17.10, sono 10 minuti che sta andando senza problemi.

alexsky8

20-10-2017, 11:25

Ho fatto un po di test anche io in breve:
Default: segfault
OC: segfault
Default+Vsoc 1.1v: segfault
Default+smt off: PASS
OC+smt off: PASS
nel mio caso sembra essere l'smt ad avere problemi

provo pure io a rifarlo disabilitando l' HT

alexsky8

20-10-2017, 11:26

Rifatto il test su ubuntu 17.10, sono 10 minuti che sta andando senza problemi.

con Oxalin o Suaefar ?

https://github.com/Oxalin/ryzen-test

https://github.com/suaefar/ryzen-test

moob1

20-10-2017, 11:27

con Oxalin o Suaefar ?

Oxalin

alexsky8

20-10-2017, 11:29

Oxalin

ok
con Ubuntu in live o installato ?

moob1

20-10-2017, 11:34

ok
con Ubuntu in live o installato ?

Installato, ho fatto l'upgrade della 17.04. Sono anche in overclock a 4GHz @ 1.33v e vSOC a 1.1v

s12a

20-10-2017, 11:35

Installato, ho fatto l'upgrade della 17.04. Sono anche in overclock a 4GHz @ 1.33v e vSOC a 1.1v

Se non è un problema per l'overclock, puoi provare con vSoC a default?

alexsky8

20-10-2017, 11:37

Installato, ho fatto l'upgrade della 17.04. Sono anche in overclock a 4GHz @ 1.33v e vSOC a 1.1v

ok proverò anche ad installarlo su SSD

per ora ho rifatto il test disabilitando l'HT e dopo 10 minuti non da errore come l'utente Angelonero87

sono tutto a default Ubuntu 17.10 live

moob1

20-10-2017, 11:51

Quasi 10 minuti, tutto a default, nessun errore.

s12a

20-10-2017, 12:05

Quasi 10 minuti, tutto a default, nessun errore.

Scusa moob1, non mi ricordavo che questa è la nuova CPU che hai ricevuto da Amazon (http://www.hwupgrade.it/forum/showthread.php?p=45108108#post45108108) e che sembra essere particolarmente fortunata in overclock (http://www.hwupgrade.it/forum/showpost.php?p=45108135&postcount=20732) rispetto alla precedente che mostrava il problema di segmentation fault. Allora non dovresti avere problemi.