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

[Mister D]

Originariamente inviato da Ozozuz

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

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]

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]

Originariamente inviato da evil weasel

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.

Originariamente inviato da digieffe

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

Originariamente inviato da SpongeJohn

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)

Originariamente inviato da digieffe

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

[digieffe]

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

[Gioz]

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]

Originariamente inviato da Mister D

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.

Originariamente inviato da SpongeJohn

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/2.../msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2.../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]

Originariamente inviato da evil weasel

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)

[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

[evil weasel]

Originariamente inviato da CiccoMan

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)

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

[paolo.oliva2]

Originariamente inviato da s12a

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]

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

Originariamente inviato da SpongeJohn

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/2.../msg00428.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00427.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00272.html
https://gcc.gnu.org/ml/gcc-patches/2.../msg00624.html

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

[Mister D]

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

Originariamente inviato da evil weasel

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]

Originariamente inviato da evil weasel

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]

Originariamente inviato da moob1

Sono ancora quelli i programmi, te lo assicuro

Originariamente inviato da Ozozuz

Purtroppo confermo

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

[SpongeJohn]

Originariamente inviato da digieffe

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]

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:

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.