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

[Tcx]

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]

Originariamente inviato da Ozozuz

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]

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]

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

[Mister D]

Originariamente inviato da s12a

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]

Originariamente inviato da s12a

.
.
.
.

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.

.
.
.

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]

Originariamente inviato da Mister D

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]

Originariamente inviato da Mister D

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]

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

[Mister D]

Originariamente inviato da s12a

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]

Originariamente inviato da Mister D

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

Originariamente inviato da evil weasel

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]

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]

Originariamente inviato da Ozozuz

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 ?

Riavvia il pc e rifai il test ...pure a me mi ha fatto così una volta

[s12a]

Originariamente inviato da mavvy

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

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

Originariamente inviato da CiccoMan

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]

Originariamente inviato da Ozozuz

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]

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

[Mister D]

Originariamente inviato da s12a

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

[s12a]

Originariamente inviato da Mister D

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...200-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/a...top-processors

Originariamente inviato da Mister D

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

Originariamente inviato da Veradun

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

A me l errore lo da anche in oc

[s12a]

Originariamente inviato da papugo1980

A me l errore lo da anche in oc

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