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

[sinergine]

Ho spedito il 1700 ad AMD, è stato consegnato venerdì (ritarato da MO).
Non ho avuto più notizie, non avrebbero dovuto avvisarmi via mail della ricezione della CPU?

[Alex656]

Originariamente inviato da sinergine

Ho spedito il 1700 ad AMD, è stato consegnato venerdì (ritarato da MO).
Non ho avuto più notizie, non avrebbero dovuto avvisarmi via mail della ricezione della CPU?

La mail di solito parte nel momento in cui la cpu arriva al reparto che esegue il test visivo/meccanico che consente di accettare o scartare la RMA; se dovesse passare tempo ti consiglio di aprire un ticket e chiedere informazioni sullo stato della tua richiesta formendo il numero di RMA ed il tracking della spedizione che hai utilizzato per inviare; io ho fatto così e sono stati molto gentili.

[sinergine]

Come non detto.

Poco dopo il mio post ecco la mail di AMD:

VERIFICA/ISPEZIONE SUPERATA
Fasi successive
Quando il prodotto sarà pronto per essere spedito riceverai un'e-mail
di notifica.

Speriamo arrivi primi di Natale, anche la mail di notifica non sarebbe male per fare in modo che ci sia qualcuno a casa a ritirare il pacco; mi pare che nessuno l'abbia ricevuta però.

[Alex656]

Originariamente inviato da sinergine

Come non detto.

Poco dopo il mio post ecco la mail di AMD:

VERIFICA/ISPEZIONE SUPERATA
Fasi successive
Quando il prodotto sarà pronto per essere spedito riceverai un'e-mail
di notifica.

Speriamo arrivi primi di Natale, anche la mail di notifica non sarebbe male per fare in modo che ci sia qualcuno a casa a ritirare il pacco; mi pare che nessuno l'abbia ricevuta però.

Quasi sicuramente tra oggi e domani ti spediscono il nuovo ma senza fornirti tracking, a meno che non sia tu a richiederlo

[sinergine]

Speriamo

[ozlacs]

ciao gente, ho compilato un paio di kernel su Arch Linux, ho usato il config del kernel stock e non ho toccato niente, difatti un sacco di roba inutile e ci ha messo un sacco di tempo.
tutto liscio, può andare come test o compilo qualcosa di più pesante?
1600 liscio

[sinergine]

Se vuoi essere sicuro fai il test in prima pagina.

PS:
nonostante la mail di ieri nessuna spedizione nemmeno oggi. Potrebbero aver finito le scorte un'altra volta.

[Alex656]

Originariamente inviato da sinergine

PS:
nonostante la mail di ieri nessuna spedizione nemmeno oggi. Potrebbero aver finito le scorte un'altra volta.

Non è detto, di solito quando comunicano di aver fatto passare il test poi spediscono; sarà questione di poco probabilmente

[BuRn]

A me non hanno avvisato della spedizione ma ho trovato il pacchetto a casa...

[sinergine]

Arrivato da RMA un 1700 1739SUS.
Domani monto e faccio test.

Non pensavo mi mandassero un altro dissipatore

[LicSqualo]

Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'.
Batch processore 1709.
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1.
Un "golden" chip per la prima volta nella mia vita.
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa.
Bene, su un forum, mi hanno chiesto se ero segfault...
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via.
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh
E siamo pure sotto le feste...
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda .
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic

[Mister D]

Originariamente inviato da LicSqualo

Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'.
Batch processore 1709.
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1.
Un "golden" chip per la prima volta nella mia vita.
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa.
Bene, su un forum, mi hanno chiesto se ero segfault...
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via.
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh
E siamo pure sotto le feste...
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda .
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic

Ciao,
se fai RMA sicuramente ti danno una cpu esente da bug su compilazione su linux e ambienti linux su windows (WSL) e nella maggior parte dei casi una cpu che regge meglio frequenze/tensioni in oc (la maggior parte di utenti qui sopra hanno riportato di aver migliorato non di poco ricevendo la nuova cpu) però questo non toglie che come hai detto hai una probabilità (bassa) di ricevere cpu meno fortunata.
Tenuto conto di ciò io cambierei solo se nell'uso con linux compilo e in modo non saltuario, cioè se sono un programmatore e la maggior parte delle mie ore sono passate a compilare in c++ o altri linguaggi nativi di linux beh ovviamente mi conviene rischiare di beccare sì una cpu meno fortunata ma sicuramente stabile sempre.
Se invece compilo raramente posso provare quello riportato in pagina 1 e cioè:
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. 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 consiglia:
Quote:
Originariamente inviato da Mister D Guarda i messaggi
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 (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (1, 2). In un altro caso, 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 la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.

Per esempio l'utente randa71 ha riportato che solo agendo su ASLR ha eliminato il problema. Visto che è una funziona di sicurezza su linux che per es su windows è disabilitata, se funzionasse anche con te, potresti usarla qualora dovessi compilare.
Puoi disabilitare direttamente da riga di comando solo per il test di ryzen la ASLR e vedere se ti fa errore. Gli altri suggerimenti, tipo quello della LLC non te lo sto a ridire perché penso che avendola occata così bene tu abbia già trovato il modo di far droppare di meno la cpu. Per cui io ripeterei il test sotto linux con ASLR disabilitato con tutto a def (ram in auto così che usa il profilo JEDEC) e vedi il risultato. Se sparisce il problema puoi usare questo "trucco" mentre se il problema permane devi decidere te a seconda di quanto compili sotto linux e quindi capire la convenienza di mandare la cpu in RMA.

[Spitfire84]

Originariamente inviato da LicSqualo

Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'.
Batch processore 1709.
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1.
Un "golden" chip per la prima volta nella mia vita.
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa.
Bene, su un forum, mi hanno chiesto se ero segfault...
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via.
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh
E siamo pure sotto le feste...
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda .
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic

Hai provato a dare 1,2 V al Vsoc e rifare il test? Se il problema appare comunque segui gli altri consigli di Mister D.

Originariamente inviato da Mister D

Ciao,
se fai RMA sicuramente ti danno una cpu esente da bug su compilazione su linux e ambienti linux su windows (WSL) e nella maggior parte dei casi una cpu che regge meglio frequenze/tensioni in oc (la maggior parte di utenti qui sopra hanno riportato di aver migliorato non di poco ricevendo la nuova cpu) però questo non toglie che come hai detto hai una probabilità (bassa) di ricevere cpu meno fortunata.
Tenuto conto di ciò io cambierei solo se nell'uso con linux compilo e in modo non saltuario, cioè se sono un programmatore e la maggior parte delle mie ore sono passate a compilare in c++ o altri linguaggi nativi di linux beh ovviamente mi conviene rischiare di beccare sì una cpu meno fortunata ma sicuramente stabile sempre.
Se invece compilo raramente posso provare quello riportato in pagina 1 e cioè:
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. 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 consiglia:
Quote:
Originariamente inviato da Mister D Guarda i messaggi
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 (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (1, 2). In un altro caso, 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 la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.

Per esempio l'utente randa71 ha riportato che solo agendo su ASLR ha eliminato il problema. Visto che è una funziona di sicurezza su linux che per es su windows è disabilitata, se funzionasse anche con te, potresti usarla qualora dovessi compilare.
Puoi disabilitare direttamente da riga di comando solo per il test di ryzen la ASLR e vedere se ti fa errore. Gli altri suggerimenti, tipo quello della LLC non te lo sto a ridire perché penso che avendola occata così bene tu abbia già trovato il modo di far droppare di meno la cpu. Per cui io ripeterei il test sotto linux con ASLR disabilitato con tutto a def (ram in auto così che usa il profilo JEDEC) e vedi il risultato. Se sparisce il problema puoi usare questo "trucco" mentre se il problema permane devi decidere te a seconda di quanto compili sotto linux e quindi capire la convenienza di mandare la cpu in RMA.

La probabilità di ricevere cpu da RMA meno fortunate della sua non è così bassa. Ho visto 2 cpu tornare da RMA e sppure non sfigate da fare 3,8 GHz con 1,35 V erano nella media (circa 3,9 GHz con 1,32-1,33 V). Tutto dipende dal batch che si riceve...

[Mister D]

Originariamente inviato da Spitfire84

Hai provato a dare 1,2 V al Vsoc e rifare il test? Se il problema appare comunque segui gli altri consigli di Mister D.



La probabilità di ricevere cpu da RMA meno fortunate della sua non è così bassa. Ho visto 2 cpu tornare da RMA e sppure non sfigate da fare 3,8 GHz con 1,35 V erano nella media (circa 3,9 GHz con 1,32-1,33 V). Tutto dipende dal batch che si riceve...

Sì dipende tutto da quello che ricevi ma siccome non ho certamente numeri per fare una statistica e considerando che la sua cpu è fortunata ho espresso un giudizio qualitativo dicendo "bassa" ma può essere anche "media" la probabilità che riceva una cpu meno fortunata. Che cmq se anche dovesse essere meno fortunata e tenere solo i 4 ghz invece dei 4,1 che cosa cambierebbe? 4,1/4=1,025 cioè il +2,5% di differenza a favore dei 100 MHz in più. Se si notano e ho grossi dubbi che uno lo noti nell'uso normale. Per me la cosa più importante per decidere è capire quanto impatta il bug per il suo utilizzo. Se impatta tanto allora RMA, se impatta poco allora mi terrei una gran cpu (sono rare effettivamente quelle che tengono i 4,1).

[LicSqualo]

Grazie a tutti!
Già mi avete fatto fare un gran passo avanti. Su windows sono praticamente esente . Mi piacerebbe essere sicuro di esserlo.
Perché una macchina da dedicare a linux ce l'ho sempre. E se non capita nei prossimi due anni, sicuramente farò anche il passaggio a zen2, e il problema si risolve da solo, questa CPU NO LINUX.
Quindi tengo il mio prezioso "tesoro" (per me) stretto stretto. E solo con winzozz.
Si figurati se ci riesco, se lo tengo sicuro ci faccio i test su linux, se non fosse altro per verificare se con carichi REALI e non test regge o meno.
Comunque il segfault me lo ha dato a stock... Quindi su questo sono quasi certo. Come è certo che per i prossimi 15 giorni seguirò l'evolversi della situazione sui forum.


Di nuovo grazie a tutti.
lascio qualche foto (così provo anche questa funzione del sito).
solo 24,4 Kb... , Vi rimando su overclock.net, stesso nick sul thread di 1usmus ho postato sia foto di stabilità ram con HCI a 1000% che CPU con IBT max (4Gb).

[sinergine]

Sto testando il 1700 1739SUS arrivato da RMA, ho fatto due giri di kill ryzen fino al blocco del sistema per memoria satura.

Niente segfault ma ci sono errori pcieport che non avevo mai visto.

Farò ancora qualche giro di prova

Using 16 parallel processes
[KERN] -- Logs begin at Fri 2017-12-08 12:33:15 CET. --
[KERN] Dec 08 12:35:56 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00000080/00006000
[KERN] Dec 08 12:35:56 ubuntu kernel: pcieport 0000:00:01.3: [ 7] Bad DLLP
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Transmitter ID)
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00001000/00006000
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: [12] Replay Timer Timeout
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Transmitter ID)
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00001000/00006000
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: [12] Replay Timer Timeout
[loop-0] Fri Dec 8 12:37:35 CET 2017 start 0
[loop-1] Fri Dec 8 12:37:36 CET 2017 start 0
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Receiver ID)
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00000040/00006000
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: [ 6] Bad TLP
[loop-2] Fri Dec 8 12:37:37 CET 2017 start 0
[loop-3] Fri Dec 8 12:37:38 CET 2017 start 0
[loop-4] Fri Dec 8 12:37:39 CET 2017 start 0
[loop-5] Fri Dec 8 12:37:40 CET 2017 start 0
[loop-6] Fri Dec 8 12:37:41 CET 2017 start 0
[loop-7] Fri Dec 8 12:37:42 CET 2017 start 0
[loop-8] Fri Dec 8 12:37:43 CET 2017 start 0
[loop-9] Fri Dec 8 12:37:44 CET 2017 start 0
[loop-10] Fri Dec 8 12:37:45 CET 2017 start 0
[loop-11] Fri Dec 8 12:37:46 CET 2017 start 0
[loop-12] Fri Dec 8 12:37:47 CET 2017 start 0
[loop-13] Fri Dec 8 12:37:48 CET 2017 start 0
[loop-14] Fri Dec 8 12:37:49 CET 2017 start 0
[loop-15] Fri Dec 8 12:37:50 CET 2017 start 0
[KERN] Dec 08 13:14:50 ubuntu kernel: perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79750

[88fabio88]

che mi dite di questi screen

http://i63.tinypic.com/35k0eqb.png

http://i67.tinypic.com/2444rk2.png
http://i64.tinypic.com/2wdq9u1.png

http://i63.tinypic.com/2e5v1b7.png
http://i64.tinypic.com/6f5seo.png

[sinergine]

segfault da tutte le parti dopo pochi minuti.
Hai eseguito a default? Settimana CPU?

[88fabio88]

la settimana non la ricordo, ma tramite il seriale mi da 2017 03 08. quindi marzo . l ho preso nei primi periodi di uscita , praticamente a fine aprile

tutto a default, ho ripristinato i dati del bios a default, prima di avviare il tutto

lo mandero indietro, ma eventualmente oramai se ne parla dopo natale. non vorrei rischiare di stare un mese senza pc

[invincible88]

Tutto ad impostazioni di dafault dalla scheda madre, me lo da entro pochi minuti: