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

[Mister D]

Originariamente inviato da evil weasel

Disattivare ASLR per evitare che una CPU fallata vada in errore è una non soluzione, mi viene in mente tutta la gente che disabilita SELinux perchè tanto non serve e fa casini con i programmi.
Oltre tutto, perchè fare test con RAM in overclock e VSOC fuori specifica?
La CPU, con due banchi di RAM single side operanti a frequenza inferiore o uguale a 2666 MHz, DEVE funzionare con tutte le tensioni a default, quindi VSOC 0.9 volt.

Disabilitare ASLR o aumentare le tensioni di funzionamento sono non soluzioni.

Single rank. Le ram potrebbero essere pure dual side ma essere single rank. Non è la stessa cosa

[evil weasel]

Originariamente inviato da Randa71

da quanto mi è stato risposto nel forum dal supporto tecnico di AMD il valore non è 0.9 ma 1...
non è come dici tu perché con le ram che ho, con la C6H caricando il optimized default me le imposta in automatico a 2400...con il vsoc a 1.05.....
sulla sicurezza hai ragione...sicuramente il bug c'è ma a me si presenta solo con la compilazione....se non compilo ma attivo ASLR problemi non ne ho...quindi è veramente una serie di concause che messe tutte insieme lo fanno scatenare...almeno ad oggi è così...

Sì, ho capito il tuo discorso, ma non sono d'accordo.
Disattivare delle impostazioni di sicurezza, che tra l'altro sono trasparenti per l'hardware, è una cosa che non prendo neanche lontanamente in considerazione.

Riguardo il VSOC non ne abbiamo la certezza perchè AMD non rilascia i datasheet, io rimango comunque dell'impressione che gli aumenti di tensione derivanti dalla modifica del moltiplicatore delle RAM siano decisi arbitrariamente dai produttori di schede madri.
Ad asus e soci non frega niente della CPU, loro vendono le schede madri ed hanno interesse che le RAM funzionino alla frequenza più alta possibile.
L'utonto medio che compra RAM con i Samsung B-Die garantite (dal produttore delle RAM, non da AMD o Asus) per operare a 3200 MHz vuole andare nel BIOS ad occhi chiusi, impostare il moltiplicatore delle RAM a 32.00 e fare save and exit.
Se il PC non parte questo va a lamentarsi con ASUS.
La cosa più facile per ASUS è quindi fare in modo che ad un aumento della frequenza delle RAM corrisponda un arbitrario ed assolutamente eccessivo aumento della tensione di alimentazione del SOC.

Non fosse per sta storia dei segfault io sarei molto soddisfatto della piattaforma AM4, dal punto di vista del rapporto prestazioni/prezzo è sicuramente stato uno dei miei migliori acquisti.
A posteriori non so se la avrei comprata, probabilmente sì perchè gli attuali Intel fanno onestamente cagare però boh, non è che qui sia tutto rose e fiori.
Un Intel 8700k che fa 90° C a default ed uscito pure con 6 mesi di ritardo rispetto a Ryzen 7 è una merda, ma anche dover stare 2 o 3 settimane senza CPU non è che sia una pacchia.

[Randa71]

Originariamente inviato da Sintara

Se parli di futuro acquisto sei in errore dal momento che ryzen 2 sarà esente dal "problema" (come già lo è adesso threadripper ed epyc). Sembra invece, in modo molto sottile, un sistema per tenere in prima pagina un thead dal momento che sicuramente tutte le prove che state facendo saranno state già fatte e non hanno portato a niente sennò tutti sapevamo già la causa, se ne esiste una e non sia come dice amd una selezione troppo blanda dei processori e anche se trovaste una soluzione software al problema sarebbe sempre il solito discorso "è una non soluzione la cpu è difettosa", quindi arrivo alla domanda, a che servono tante prove e tentativi se poi la mando ad amd e me la rimanda buona e come è successo magari senza pagare le spedizioni?
Dal momento che un utente chiede come fare i vari test, viene seguito per eseguirli al meglio e magari se la vuole sostituire aiutarlo nel fare un rma con amd poi mi sembrano solo parole dal momento che come è stato scritto da più utenti qualunque altro sistema non sarebbe valido come soluzione perchè il vero problema è la cpu difettata.
Boh con questo vi saluto e buona continuazione.

a me servono solo per curiosità mia...
per la cronaca: è possibile avere il link dove AMD ha dichiarato che il problema delle CPU difettose è il binning delle stesse?
perché molto probabilmente me lo sono perso...

[evil weasel]

Originariamente inviato da Randa71

a me servono solo per curiosità mia...
per la cronaca: è possibile avere il link dove AMD ha dichiarato che il problema delle CPU difettose è il binning delle stesse?
perché molto probabilmente me lo sono perso...

Mi sa che non c'è, deve essere una fonte ufficiosa arrivata da phoronix.com.
Non mi pare ci sia nessun comunicato ufficiale nè tanto meno una spiegazione ufficiale del problema.

[Randa71]

Originariamente inviato da evil weasel

Sì, ho capito il tuo discorso, ma non sono d'accordo.
Disattivare delle impostazioni di sicurezza, che tra l'altro sono trasparenti per l'hardware, è una cosa che non prendo neanche lontanamente in considerazione.

Riguardo il VSOC non ne abbiamo la certezza perchè AMD non rilascia i datasheet, io rimango comunque dell'impressione che gli aumenti di tensione derivanti dalla modifica del moltiplicatore delle RAM siano decisi arbitrariamente dai produttori di schede madri.
Ad asus e soci non frega niente della CPU, loro vendono le schede madri ed hanno interesse che le RAM funzionino alla frequenza più alta possibile.
L'utonto medio che compra RAM con i Samsung B-Die garantite (dal produttore delle RAM, non da AMD o Asus) per operare a 3200 MHz vuole andare nel BIOS ad occhi chiusi, impostare il moltiplicatore delle RAM a 32.00 e fare save and exit.
Se il PC non parte questo va a lamentarsi con ASUS.
La cosa più facile per ASUS è quindi fare in modo che ad un aumento della frequenza delle RAM corrisponda un arbitrario ed assolutamente eccessivo aumento della tensione di alimentazione del SOC.

Non fosse per sta storia dei segfault io sarei molto soddisfatto della piattaforma AM4, dal punto di vista del rapporto prestazioni/prezzo è sicuramente stato uno dei miei migliori acquisti.
A posteriori onestamente non so se la avrei comprata, probabilmente sì perchè gli attuali Intel fanno onestamente cagare però boh, non è che qui sia tutto rose e fiori.
Un Intel 8700k che fa 90° C a default ed uscito pure con 6 mesi di ritardo rispetto a Ryzen 7 è una merda, ma anche dover stare 2 o 3 settimane senza CPU non è che sia una pacchia.

beh considera che Asus vende schede madri...quindi se fanno bios che friggono CPU rischiano danni d'immagine non da poco oltre che economici etc..quindi immagino che stiano attenti a certe cose....oltre al fatto che, come mi insegnò un ingegnere elettronico, quando fornisci le specifiche ai costruttori di schede su cui il componente gira, una delle prime cose che gli dici sono le tensioni di alimentazione...
quindi ok che tutti possono sbagliare, vedi Gigabyte che però ha subito corretto il problema con un bios nuovo...immagino che se da 6 mesi i voltaggi sono questi e per me non sono cambiati passando da bios a bios, sono buoni..

sul discorso Sicurezza hai ragione..se compili con ASLR va in crash...nulla da eccepire....

[Randa71]

Originariamente inviato da evil weasel

Mi sa che non c'è, deve essere una fonte ufficiosa arrivata da phoronix.com.
Non mi pare ci sia nessun comunicato ufficiale nè tanto meno una spiegazione ufficiale del problema.

ecco è qui che volevo arrivare...quindi la fonte ufficiosa potrebbe essere vera come non vera, concordi?...come non è vera la beeeeeppppppp che le CPU dopo la 25° settimana sono bug esenti...
ho letto in giro di gente che ha cpu dopo quella settimana e il prb c'è ancora...
con queste premesse, tutto quello che è stato scritto è vero come è vero il contrario...in realtà solo AMD sa dove sta effettivamente il problema...ma non l'ha comunicato....questa è la cosa che a me non piace....

[Alex656]

Originariamente inviato da Randa71

Da quando ho disabilitato ASLR anche nel boot (di Linux, non da Bios), quindi dall'altro ieri, confermo che ad adesso, il bug non si è più ripresentato...e le prove le sto facendo...compreso il phoronix test suite dove il benchmark de build-php build-apache e build-linux-kernel andavano in errore...ora no, come non va in errore anche il ryzen test...questo almeno fino ad adesso
sicuramente ASLR ha comunque un impatto molto elevato per far uscire il bug...considerate che:
1) la CPU (1700X) nonostante sia 17/06 mai stata overclocckata...adesso sta con le ram profilo XMP a 2400....finalmente funziona bene su C6H bios 1701..
2) mentre vi sto scrivendo sta girando in background il phoronix x la compilazione del kernel...
3) se una suite di compilazione phoronix va in errore appare subito la scritta in rosso test ended with return code non equal a 0...almeno il senso è questo...
4) sta ancora girando...e ho aperto ancora chrome...da cui vi sto scrivendo;
5) la scheda madre per le 2400 automaticamente imposta il vsoc a 1.05....non ho provato adesso con le ram a default;
6) adesso vi posto output del test phoronix (concluso perfettamente):

Timed Linux Kernel Compilation 4.13:
pts/build-linux-kernel-1.8.0
Test 1 of 1
Estimated Trial Run Count: 3
Estimated Time To Completion: 11 Minutes [17:41 CET]
Running Pre-Test Script @ 17:30:33
Started Run 1 @ 17:30:46
Running Interim Test Script @ 17:32:21
Started Run 2 @ 17:32:25
Running Interim Test Script @ 17:33:56
Started Run 3 @ 17:34:00
Running Post-Test Script @ 17:35:31

Time To Compile:
94.018129110336
90.042171955109
89.851027965546

Average: 91.30 Seconds
Deviation: 2.58%

OpenBenchmarking.org Dynamic Comparison:
Seconds < Lower Is Better
Result ............. 91.30 |==================================================================================================
Antergos 17.10 ..... 82.16 |========================================================================================
Debian Testing ..... 82.07 |========================================================================================
Ubuntu 17.10 ....... 80.34 |======================================================================================
Fedora 26 .......... 76.36 |==================================================================================
Solus 3 ............ 73.87 |===============================================================================
Clear Linux 18320 .. 70.14 |===========================================================================
Result Reference: http://openbenchmarking.org/result/1...AL-COFFEELIN21

Prima andava in errore anche solo con 90 sec di compilazione..--uno dei run falliva...o del kernel o della compilazione del php o dell'apache..ora perfetti
Aggiungo che anche in Windows ho fatto prove di carico, visto che si era ipotizzato che la CPU non reggesse bene il carico:
1) lanciato boinc solo su CPU per 2h e 30..e facevo anche altro...nessun errore nessun crash;
2) lanciati 14 thread di prime 95 per 1 h e con 2 thread giocavo a witcher 3 e dishonored 2...tutto fluidissimo...senza nessun problema o crash dei programmi...
3) le prove che ho fatto in Linux durano tutte mediamente 45 minuti..poi lo fermo altrimenti i 16GB di ram vengono saturati...provato più volte....sia con chiavetta live che ubuntu 17.10 installata; nessun problema...considerate che prima dopo neanche 5 min di run apparivano i segfault;
4) Windows è stabilissimo.
5) memtest di passmark senza errori

Per la mia esperienza con le premesse che vi ho fatto sopra il problema ad oggi risiede nel ASLR, disabilitandolo ad oggi, dopo circa 2 gg di prove, saltuarie (nel senso che lo uso anche per altro) ma prove, non più un errore nella compilazione...e da quanto sò in Windows quel tipo di meccanismo era presente fino a Win7 compreso..dall'8 in poi non c'è più...
La reale difficoltà è capire da dove arriva errore, mi spiego: magari quelli che hanno il bug anche con aslr disabilitato hanno instabilità da altre parti, RAM o CPU in OC....
Ad oggi ripeto che con tutte le prove che ho fatto il problema sembra essere sparito....o quantomeno, se ancora presente, NON è assolutamente impattante...almeno per me....

Ho provato a disabilitare ASLR, il segfault è venuto fuori ugualmente, solo che ci ha impiegato di più; sotto windows non ho mai avuto alcun problema nè con gli stress test nè con memtest.

[Randa71]

Originariamente inviato da Alex656

Ho provato a disabilitare ASLR, il segfault è venuto fuori ugualmente, solo che ci ha impiegato di più; sotto windows non ho mai avuto alcun problema nè con gli stress test nè con memtest.

ci ha impiegato di più? quanto tempo? così provo anche io
adesso lo rilancio per l'ennesima volta anche io

[s12a]

Originariamente inviato da Randa71

a me servono solo per curiosità mia...
per la cronaca: è possibile avere il link dove AMD ha dichiarato che il problema delle CPU difettose è il binning delle stesse?
perché molto probabilmente me lo sono perso...

https://www.phoronix.com/scan.php?pa...-Segv-Response

È possibile che sia stata una supposizione degli utenti osservando il comportamento delle CPU tornate indietro da RMA. I punti salienti su Phoronix sono stati i seguenti, parla solo di migliore "QA" per i futuri prodotti (CPU) consumer:

This morning [Michel Larabel of Phoronix.com] was on a call with AMD and they are now able to confirm they have reproduced the Ryzen "segmentation fault issue" and are working with affected customers.

[...] AMD was also able to confirm this issue is not present with AMD Epyc or AMD ThreadRipper processors, but isolated to these early Ryzen processors under Linux.

[...] AMD says they are committed to working with those encountering this performance marginality issue under Linux. AMD will also be stepping up their Linux testing/QA for future consumer products.

Non ricordo se ci sono state altre comunicazioni di questo genere. Forse ha aggiunto qualcosa Bridgman (John Bridgman di AMD) in via non ufficiale in qualche messaggio nel forum su Phoronix.

Originariamente inviato da Alex656

Ho provato a disabilitare ASLR, il segfault è venuto fuori ugualmente, solo che ci ha impiegato di più; sotto windows non ho mai avuto alcun problema nè con gli stress test nè con memtest.

Questa è l'esperienza che hanno avuto altri utenti, più o meno. Probabilmente dipende dall'esemplare e da altre impostazioni, forse principalmente Vsoc. A che valore è impostato sulla tua scheda madre?

[alexsky8]

Originariamente inviato da Randa71

ecco è qui che volevo arrivare...quindi la fonte ufficiosa potrebbe essere vera come non vera, concordi?...come non è vera la beeeeeppppppp che le CPU dopo la 25° settimana sono bug esenti...
ho letto in giro di gente che ha cpu dopo quella settimana e il prb c'è ancora...
con queste premesse, tutto quello che è stato scritto è vero come è vero il contrario...in realtà solo AMD sa dove sta effettivamente il problema...ma non l'ha comunicato....questa è la cosa che a me non piace....

Come già ampiamente riportato la mia cpu 1700 settimana 33 ha il bug quindi può essere che la % sia calata drasticamente ma non nulla
Per azzerarsi credo si dovrà attendere ancora qualche settimana oppure ancor meglio ryzen 2

[evil weasel]

Originariamente inviato da Randa71

beh considera che Asus vende schede madri...quindi se fanno bios che friggono CPU rischiano danni d'immagine non da poco oltre che economici etc..quindi immagino che stiano attenti a certe cose....oltre al fatto che, come mi insegnò un ingegnere elettronico, quando fornisci le specifiche ai costruttori di schede su cui il componente gira, una delle prime cose che gli dici sono le tensioni di alimentazione...
quindi ok che tutti possono sbagliare, vedi Gigabyte che però ha subito corretto il problema con un bios nuovo...immagino che se da 6 mesi i voltaggi sono questi e per me non sono cambiati passando da bios a bios, sono buoni..

sul discorso Sicurezza hai ragione..se compili con ASLR va in crash...nulla da eccepire....

A meno di aumenti veramente folli (come il doppio rispetto al voltaggio base) è dura friggere una CPU, soprattutto nel breve periodo.
Il loro unico interesse è avere meno rogne possibili, se possono farlo aumentando di un 10/20% le tensioni stock lo fanno senza problemi.
Se AMD si degnasse di pubblicare sti benedetti datasheet non sarebbe male...

Originariamente inviato da Randa71

ecco è qui che volevo arrivare...quindi la fonte ufficiosa potrebbe essere vera come non vera, concordi?...come non è vera la beeeeeppppppp che le CPU dopo la 25° settimana sono bug esenti...
ho letto in giro di gente che ha cpu dopo quella settimana e il prb c'è ancora...
con queste premesse, tutto quello che è stato scritto è vero come è vero il contrario...in realtà solo AMD sa dove sta effettivamente il problema...ma non l'ha comunicato....questa è la cosa che a me non piace....

Io non mi stupirei se nemmeno AMD sappia da cosa derivi il problema, ci sono svariate persone che hanno riportato come le CPU tornate da RMA fossero sporche o leggermente segnate.
Vien da pensare che vengano testate una ad una per essere sicuri che siano buone, anche per questo motivo probabilmente ci mettono del tempo a sostituire e rispedire la CPU.

[Operapia]

Ho impostato il vsoc ad 1.1 è la frequenza a 2667. Blend sta girando da 45 minuti. Quanto devo farlo andare ancora?

[s12a]

A voi hanno fatto fare questi test?

http://www.overclock.net/t/1635749/p...#post_26340773
http://www.overclock.net/t/1635749/p...#post_26340815

Originariamente inviato da Mysticial

Just to give an update to everyone. I initiated the RMA process and it looks like AMD gave me a pretty comprehensive to-do list to debug it.

They first asked me to send them pictures of the build and BIOS settings as well as all the part #'s to make sure I'm not doing anything stupid. So I did that and they were satisfied with the way the box was built. And seemed convinced that I know what I'm doing.

Now they're asking me to lock the vcore and SOC to 1.3625v and 1.1v respectively. This is different from what everyone else here has suggested since nobody here mentioned locking down the vcore as well. Then they suggested increasing the vcore to as high as 1.425v.

So vcore/SOC of 1.425/1.1v is actually higher than I've ever tested. 1.1v SOC is also the limit of what my motherboard allows. I'll run down their to-do list tomorrow night after work.

This to-do list that AMD sent is actually quite exhaustive and I can't imagine too many people willing to go along with it. I'll play along for now. Since I'm also genuinely interested in seeing how AMD is diagnosing these.

L' utente su overclock.net (Mysticial) è programmatore ed ha avuto problemi di segfault anche su Windows con del codice proprietario; ha scritto diversi commenti interessanti, eccone altri dallo stesso thread. Alla fine si è fatto cambiare la CPU:

http://www.overclock.net/t/1635749/p...#post_26309166
http://www.overclock.net/t/1635749/p...#post_26309685
http://www.overclock.net/t/1635749/p...#post_26309710
http://www.overclock.net/t/1635749/p...#post_26309865
http://www.overclock.net/t/1635749/p...#post_26309906
http://www.overclock.net/t/1635749/p...#post_26310236
http://www.overclock.net/t/1635749/p...#post_26311041
http://www.overclock.net/t/1635749/p...#post_26311055
http://www.overclock.net/t/1635749/p...#post_26311109
http://www.overclock.net/t/1635749/p...#post_26311149
http://www.overclock.net/t/1635749/p...#post_26312017
http://www.overclock.net/t/1635749/p...#post_26312035
http://www.overclock.net/t/1635749/p...#post_26312272
http://www.overclock.net/t/1635749/p...#post_26312286
http://www.overclock.net/t/1635749/p...#post_26314315
http://www.overclock.net/t/1635749/p...#post_26316194
http://www.overclock.net/t/1635749/p...#post_26340851
http://www.overclock.net/t/1635749/p...#post_26353608

Originariamente inviato da Operapia

Ho impostato il vsoc ad 1.1 è la frequenza a 2667. Blend sta girando da 45 minuti. Quanto devo farlo andare ancora?

Idealmente "quanto basta", solo che non è chiaro quanto questo sia esattamente con Prime95 - potenzialmente potrebbe essere ore. Se hai aumentato il Vsoc e sei su Linux ne approfitterei per far partire nuovamente ryzen-test per vedere se il nuovo valore di Vsoc questa volta permette di evitare segfault.

[Kernel32]

Ciao a tutti, un'informazione: dovrei prendere da un privato una di queste CPU presa e sostituita in garanzia da un rivenditore su Amazon per via del segfault. Per la garanzia come funziona? Mi posso rivolgere direttamente ad amd in caso di eventuali problemi?

[Alex656]

Originariamente inviato da Randa71

ci ha impiegato di più? quanto tempo? così provo anche io
adesso lo rilancio per l'ennesima volta anche io

Prima capitava entro 2 minuti, con lo script modificato entro i 10 minuti; disabilitando SMT invece sono arrivato indenne a 30 minuti, poi ho stoppato.

[Alex656]

Originariamente inviato da s12a

...
Questa è l'esperienza che hanno avuto altri utenti, più o meno. Probabilmente dipende dall'esemplare e da altre impostazioni, forse principalmente Vsoc. A che valore è impostato sulla tua scheda madre?

L'ho lasciato su auto; sul bios mi indica 1.155 V

[Randa71]

Originariamente inviato da Alex656

Prima capitava entro 2 minuti, con lo script modificato entro i 10 minuti; disabilitando SMT invece sono arrivato indenne a 30 minuti, poi ho stoppato.

Ieri come detto ho riprovato...stoppato al 35° minuto perché dovevo uscire. Nessun errore. Sempre con ASLR disattivato. Prima davvero con ASLR attivato erano rarissimi i casi in cui funzionava...SMT è attivo..non ho toccato impostazioni di config nei bios...solo disattivato ASLR anche nel boot del kernel.
Penso che complessivamente tra lo script di Ryzen e le compilazioni (che prima andavano in errore) con il Phoronix Suite più di 10 run li ho fatti in due giorni, senza errori....questa è la mia esperienza...con Ubuntu 17.10 sia installata su disco che da chiavetta live USB
Tra altro dalla conf che hai in firma vedo che è tutto uguale a parte la RAM e gli storage...Io con le Corsair e con Ryzen, nonostante fossero tra quelle OK detto sia da AMD che da Asus, le ddr4 2400 ad esempio non riuscivo a farle bootare a 2400...le Kingston si... sempre mia personale esperienza...le Corsair le resettava a 2133 punto...Tra l'altro a che clock tieni le RAM? Perché se le tieni oltre i 2666 cmq è overclock...quindi...già questa è una variabile significativa che potrebbe inficiare l'esito del test...poi magari ti andava in errore anche a 2133
Cmq la posizione ufficiosa ed ufficiale di AMD è che il problema degli errori di compilazione è riferibile solo a Linux e non a Windows.
https://community.amd.com/thread/221685
utente black_zion se non mi sbaglio fa parte cmq del supporto tecnico di AMD

Per tutti: mia personale opinione: secondo me molte volte gli errori presenti che ci possono essere anche in Windows arrivano da altre parti...non direttamente riferibili al problema relativo al Seg Fault. Solo che sapendo dell'esistenza del problema, la causa automaticamente diventa quella...

[Alex656]

Originariamente inviato da Randa71

Ieri come detto ho riprovato...stoppato al 35° minuto perché dovevo uscire. Nessun errore. Sempre con ASLR disattivato. Prima davvero con ASLR attivato erano rarissimi i casi in cui funzionava...SMT è attivo..non ho toccato impostazioni di config nei bios...solo disattivato ASLR anche nel boot del kernel.
Penso che complessivamente tra lo script di Ryzen e le compilazioni (che prima andavano in errore) con il Phoronix Suite più di 10 run li ho fatti in due giorni, senza errori....questa è la mia esperienza...con Ubuntu 17.10 sia installata su disco che da chiavetta live USB
Tra altro dalla conf che hai in firma vedo che è tutto uguale a parte la RAM e gli storage...Io con le Corsair e con Ryzen, nonostante fossero tra quelle OK detto sia da AMD che da Asus, le ddr4 2400 ad esempio non riuscivo a farle bootare a 2400...le Kingston si... sempre mia personale esperienza...le Corsair le resettava a 2133 punto...Tra l'altro a che clock tieni le RAM? Perché se le tieni oltre i 2666 cmq è overclock...quindi...già questa è una variabile significativa che potrebbe inficiare l'esito del test...poi magari ti andava in errore anche a 2133
Cmq la posizione ufficiosa ed ufficiale di AMD è che il problema degli errori di compilazione è riferibile solo a Linux e non a Windows.
https://community.amd.com/thread/221685
utente black_zion se non mi sbaglio fa parte cmq del supporto tecnico di AMD

Per tutti: mia personale opinione: secondo me molte volte gli errori presenti che ci possono essere anche in Windows arrivano da altre parti...non direttamente riferibili al problema relativo al Seg Fault. Solo che sapendo dell'esistenza del problema, la causa automaticamente diventa quella...

Le ram le tengo a 2933 solo per evitare fake boot, anche a 3200 sarei perfettamente stabile sotto windows; ad ogni modo, per essere sicuro di non avere problemi correlati alle memorie, ho fatto il test lasciando tutto a default (2133) ma non cambia nulla. Ogni processore sembra rispondere a modo proprio da quel che vedo in giro; nel mio caso basterebbe disabilitare SMT; dato che sotto windows, almeno per ora, sembra andare come un orologio svizzero, ho una mezza intenzione di aspettare il refresh a 12 Nm, passare al prossimo top di gamma (2800x?) e fare contestualmente RMA ad AMD in modo da poter sostituire il 1700x e rivenderlo poi come nuovo; avendo acquistato ad aprile 2017 dovrei rientrare tranquillamente con la garanzia; chiaro che se dovessi incorrere in un solo problema in windows che possa essere della stessa natura del segfault farei RMA all'istante; per ora posso lasciar girare per ore sia prime 95, con le impostazioni consigliate per l'overclock (che non ho) che Stability Test di Asus senza problemi; idem facendo girare 16 threads sul benchmark di 7zip o similari.

[Randa71]

Originariamente inviato da Ozozuz

Oggi dovrebbero spedirmi la cpu sostitutiva, volevo segnalare che oltre ad aver pagato loro le spedizione all'andata "dhl express, 1 giorno :o" mi dovrebbero fornire il tracking anche per la spedizione di ritorno, cosa che avevo letto spesso non facessero.

Una domanda per i test invece, una cpu 100% ESENTE da bug, dovrebbe non dare seg-fault od in generale errori di compilazione anche con v-soc a default "0.8v" oppure comunque é preferibile portarlo su a 1.1v ?

Una CPU che funziona funziona. Quindi non dovrebbe essere necessario modificare i parametri di funzionamento affinché sia stabile. Lasciala a def e vedi come si comporta.

[Randa71]

le prossima prova che farò sarà quella di lasciare abilitato ASLR per la macchina ma di disabilitarlo solo per il kill_ryzen, in Linux è possibile farlo:
setarch `uname -m` -R program [args ...]
setarch `uname -m` -R /home/utente/ryzen_test/kill_ryzen.sh
https://docs.oracle.com/cd/E37670_01..._aslr_sec.html
In poche parole il kernel solo per il processo kill_ryzen e relativi processi figli (tra cui la compilazione) non dovrebbe randomizzare gli indirizzi. Mentre per tutti gli altri processi si. In tal modo le possibilità di inoculazione di codice malevolo sarebbero ridotte al solo processo di compilazione, ma non per tutti gli altri processi attualmente attivi sulla macchina...
visto che il parametro attivo disattivo non richiede un reboot della macchina, mi aspetto che in fase di esecuzione dei processi il kernel verifica il flag e in base a quello che trova randomizza o non randomizza la ram o per tutti i processi o per un singolo processo tramite il comando...