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

[SpongeJohn]

Originariamente inviato da evil weasel

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.

Originariamente inviato da evil weasel

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]

Originariamente inviato da Alex656

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]

Originariamente inviato da s12a

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

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

[s12a]

Originariamente inviato da alexsky8

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]

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 ?]

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

[animeserie]

Originariamente inviato da BuRn

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.

Condivido,
dalla prima all'ultima parola.

[s12a]

Originariamente inviato da doctor who ?

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 ?]

Originariamente inviato da s12a

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]

Originariamente inviato da Ozozuz

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

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

[doctor who ?]

Originariamente inviato da s12a

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

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]

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.

[doctor who ?]

Originariamente inviato da Gioz

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.

sempre per puro spirito sportivo, come si comporta la tua in oc ?

Originariamente inviato da Gioz

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]

Originariamente inviato da moob1

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]

Originariamente inviato da doctor who ?

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]

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]

Originariamente inviato da Ozozuz

Update

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.

Ubuntu 17.10 da live non ha dato errori.

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.

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 ?

ma che hai il negozio di cpu sotto casa?

[s12a]

Originariamente inviato da Ozozuz

Update

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 ?]

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