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

[bagnino89]

Originariamente inviato da s12a

Inoltre: puoi riprovare lo stesso test su Windows facendolo partire il comando con "run.cmd -j 32" (oppure al posto di 32 un valore abbastanza superiore al numero di core logici del processore) e disattivando temporaneamente Windows Defender come spiegato nella mini-guida sopra?

Se può interessare, ho provato kill-ryzen-win per un'ora, impostati 24 workers (la mia CPU ha 12 thread), disattivata la protezione attiva di Defender, verificato da Task Manager che i processi che sfruttavano attivamente la CPU fossero solo la console di comando di VB e System.

Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia

PS. Una cosa che mi ha molto impressionato è la temperatura della CPU: non ha mai superato 56 °C.

[nicolarush]

mi unisco alla compagnia
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma

la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone

il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8
ovviamente anche lui con i suoi bei segfaults

[s12a]

Originariamente inviato da bagnino89

Se può interessare, ho provato kill-ryzen-win per un'ora, impostati 24 workers (la mia CPU ha 12 thread), disattivata la protezione attiva di Defender, verificato da Task Manager che i processi che sfruttavano attivamente la CPU fossero solo la console di comando di VB e System.

Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia

Nel thread correlato nel community forum AMD è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.

Originariamente inviato da nicolarush

mi unisco alla compagnia
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma

la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone

il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8
ovviamente anche lui con i suoi bei segfaults

Per curiosità, qual è stato in entrambi i casi il codice di produzione completo? Terminava per PGT, SUS od altro?

[Mister D]

Originariamente inviato da s12a

Nel thread correlato nel community forum AMD è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.

Questo potrebbe voler dire che in alcuni stabilimenti hanno applicato prima il nuovo test di qualità e quindi selezionano meglio le cpu (magari sono stabilimenti dove sono state fatti i test pilota per il cambio di validazione produttiva?).

[bagnino89]

Originariamente inviato da s12a

Nel thread correlato nel community forum AMD è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.

Dovrei togliere il dissipatore per controllare queste informazioni... Avrei dovuto fare una foto.

Ricordo sicuramente che era stato prodotto in Malaysia.

[s12a]

Probabilmente il codice termina per PGT.

https://www.reddit.com/r/Amd/comment...k9&sh=b6dd60e4

SKU: YD1700BBM88AE
BATCH: UA 1706PGT
SERIAL: 9R6xxxxxxxxxx

The Batch number consists of the UA and then a two part number of 2 digits each as well as the assembly location.

The first being the year the CPU was produced [17]=(2017) and the week [06] = (Week 6).

UA [2digits-YEAR][2digits-WEEK] [3letters-Assembly and Diffusion]

UA   1706       PGT
UA [YY][WW]  [1][2][3]

YY -> Year
WW -> Week

1 -> ATMP Location ([P]enang, Malaysia or [s]uzhou, China) (Exact factory addresses known )
2 -> Last letters of ATMP location.
3 -> Wafer Production ([s]aratoga or [T]exas) (addresses known)

[bagnino89]

Dovrei provare con Linux per essere sicuro al 100%.

[alexsky8]

Originariamente inviato da bagnino89

Dovrei togliere il dissipatore per controllare queste informazioni... Avrei dovuto fare una foto.

Ricordo sicuramente che era stato prodotto in Malaysia.

la mia settimana 33 è made in Malaysia
codice 1733PGS

[papugo1980]

Il mio con segfault 1714sus
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo

[s12a]

Originariamente inviato da papugo1980

Il mio con segfault 1714sus
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo

Allora niente: probabilmente le ultime tre lettere da sole non bastano per determinare in anticipo quali esemplari potrebbero manifestare segfault. Magari però per quelli prodotti dopo la settimana 25? Occorrerebbe vedere quelli di chi ha riscontrato segfault con processori recentemente prodotti ed acquistati nei canali retail.

EDIT: ho controllato nuovamente i link che ho postato in precedenza nel thread, e questo qui credo confermi che forse è solo una coincidenza; potrebbe dunque accadere con qualunque processore:

https://www.reddit.com/r/Amd/comment...13&sh=158f74a5

(Si potrebbe opinare che forse il processore è overcloccato, ma ancora non c'è stata conferma che solo overcloccando possano apparire segfault. Servono più test - ad esempio variando vSoC e frequenza memorie assieme - ma questo qui riportato qualche commento fa da Nautilu$ indica che potrebbe non accadere con i processori apparentemente esenti dal problema)

[papugo1980]

Test partito da più di 20 minuti e sembra essere tutto regolare...
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo

[s12a]

Originariamente inviato da papugo1980

Test partito da più di 20 minuti e sembra essere tutto regolare...
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo

Diminuendo vSoC od esagerando un po' con la frequenza della memoria, ma senza toccare vCore o moltiplicatore CPU, escono fuori segfault nel solito test oppure appare solo una schermata nera come nel caso di Nautilu$?

[alexsky8]

Originariamente inviato da s12a

https://www.reddit.com/r/Amd/comment...13&sh=158f74a5

no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ?

[metal master]

arrivato poco fa con dhl un nuovo ryzen 7 1700 scatolato e sigillato.
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.

[nicolarush]

Originariamente inviato da s12a

Per curiosità, qual è stato in entrambi i casi il codice di produzione completo? Terminava per PGT, SUS od altro?

il 1700X è PGT

il 1700 e SUT

con la differenza che il 1700X è stato preso al day1 mentre il 1700 ieri... trovare ancora settimana 8 mi ha veramente sorpreso

[s12a]

Originariamente inviato da alexsky8

no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ?

Sì, così riporta. Qualcun altro ha riscontrato lo stesso nel forum AMD in seguito all'RMA, ma in un caso il motivo può essere stato causato da eccessivo clock della memoria; con 4 moduli la frequenza massima supportata ufficialmente con AMD Ryzen è inferiore che con 2 (2133 MHz single rank / 1866 MHz dual rank).

https://community.amd.com/message/28...823637#2823637
#1484 ed alcuni dei commenti successivi

[papugo1980]

Originariamente inviato da alexsky8

no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ?

Credo intenda Rma dallo store e non da Amd

@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750

[alexsky8]

Originariamente inviato da metal master

arrivato poco fa con dhl un nuovo ryzen 7 1700 scatolato e sigillato.
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.

quindi quanti giorni hai impiegato complessivamente ?

[s12a]

Originariamente inviato da papugo1980

Credo intenda Rma dallo store e non da Amd

L'utente che ho linkato dal forum AMD aveva aperto una procedura di RMA con AMD. Riporta segfault, ma solo aumentando la frequenza della memoria usando il profilo XMP. Per questo ero curioso di sapere se effettuando overclock in tal senso (o diminuendo il vSoC, che pare sia correlato alla stabilità di memoria ed affini) potessero iniziare ad apparire segfault con le solite modalità, anche con processori che a default non mostrano nulla:

https://community.amd.com/message/28...822644#2822644 (#1347)

After 3 weeks and half my replacement 1700X arrived today. I can't blame the delay on AMD. The problem was Brazilian customs.

It is also a 1725SUS (diffused in USA and made in China). It was certainly pre-tested as there are some small dents in the corners (it looks like they attached the cooler too tight). I hope they did not damage the CPU in any sense. I have just put the CPU back on my computer and started the kill-ryzen.sh test. I will report back in 48 hours.

https://community.amd.com/message/28...823637#2823637 (#1484)

Bad news from my front. I have an RMAed CPU of week 25. It sustained 3 days of kill-ryzen.sh using BIOS defaults. After that I updated my BIOS and changed my memory profile to use XMP 2 (2400 instead of 2100 from Bios default).* Unfortunately, under this conditions I got a new failure in one of the loops:
*
-----------------
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c: In function 'int standard_sse_constant_p(rtx, machine_mode)':
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c:11699:8: internal compiler error: Segmentation fault
** mode = GET_MODE (x);
0x11ac5ec crash_signal
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/toplev.c:337
0x104058c create_output_operand
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/optabs.h:94
-----------------
*
I will now revert back memory to BIOS default. I think I read somewhere that Ryzen only officially supports 2100Hz when dealing with 64Gb.
*
I have to admit that I am really tired of this. It will be hard to really trust this CPU after so many problems.

.

Originariamente inviato da papugo1980

@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750

Questo è normale e non indica problemi con il processore.

[papugo1980]

Ok allora ora metto tutto a default e carico il profilo Xmp e testo
Cmq per me il test (tutto a default ) é superato.
L altro mi faceva errore subito