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

[evil weasel]

Originariamente inviato da alexsky8

qualcuno che ha fatto il test con i parametri di default potrebbe gentilmente dire quanto era il Vsoc ?

sono spariti tutti ?

Il VSOC a default è sempre ~0.9 volt, vale per tutte le CPU.

Originariamente inviato da s12a

A proposito, dato che i processori AMD Ryzen sono dei SoC che integrano oltre a memory controller anche controller USB, SATA e PCIe, se c'è o c'è stato qualche problema in sede di produzione correlato alla parte "uncore"/SoC non è da escludere che possano eccezionalmente esserci anche effetti sul resto. In un paio di casi è stato riportato qualcosa di simile, almeno per quanto riguarda la parte USB (1, 2).

Magari aumentando Vsoc si risolve? (sarebbe interessante constatare anche se diminuendola la situazione peggiora)

No, non cambiava assolutamente niente aumentando la tensione di alimentazione del SOC.
All'inizio pensavo fosse colpa del cavo, cosa che tra l'altro mi era già capitata in passato, poi dopo aver sostituito il cavo ho supposto fosse colpa del disco.
Provando il disco su un altro PC il problema però non si presentava, quindi a sto punto io credo potesse essere veramente la CPU.
Appena rientra da RMA controllo se il problema continua ad esserci o per magia è sparito.

[CiccoMan]

Originariamente inviato da Sintara

Cioè se ho letto bene non hai un ryzen e hai aperto un thread su un bug del suddetto processore ?
Wow non mi era mai successo.

E guarda un po', in firma si legge che ha una cpu Intel ...GOMBLODDO

PS. Sono ironico ovviamente

[Nui_Mg]

Originariamente inviato da Sintara

Cioè se ho letto bene non hai un ryzen e hai aperto un thread su un bug del suddetto processore ?
Wow non mi era mai successo.

Sei l'unico a stupirsi di un'oggettiva banalità: da quando in qua è strano indagare a fondo per un possibile futuro acquisto? s12a si è dato da fare pubblicamente per quello che alcuni di noi stavano e/o stanno già facendo privatamente per l'ipotetico acquisto di un ryzen (io nel mio piccolo, per esempio, ho valutato tutto un discorso prestazioni I/O dell'offerta amd am4 rispetto agli intel z270, risultato a vantaggio di quest'ultima: sì, io prendo in considerazione pure questo, che c'è di male? Inoltre, non tutti quelli che acquistano intel devono per forza deliddare, potrebbero tenerselo a stock oppure overclockare anche di poco e ciò è gestibile tranquillamente pure con raffreddamento ad aria).

[alexsky8]

Originariamente inviato da Nautilu$

VSOC 0,9V con la ram a 2400MHz e cpu a 3,8GHz

Originariamente inviato da evil weasel

Il VSOC a default è sempre ~0.9 volt, vale per tutte le CPU.

ok perfetto, ho notato che alzandolo a 1,1V il problema pare non esserci mentre a default sì
così come disabilitando SMT pare non presentarsi neppure a voltaggi più bassi

[s12a]

Originariamente inviato da alexsky8

ok perfetto, ho notato che alzandolo a 1,1V il problema pare non esserci mentre a default sì
così come disabilitando SMT pare non presentarsi neppure a voltaggi più bassi

Invece a Vsoc default, SMT abilitato e memorie a velocità inferiori del minimo supportato di default con due banchi? Ad esempio 2133 o 1866 MHz.

[il_dottorino]

sto testando la cpu settimana 33 e non sembrerebbe buggata.. continuo nell'esecuzione del test, quanto tempo impiega a terminare il test? Il mio è fermo

[alexsky8]

Originariamente inviato da s12a

Invece a Vsoc default, SMT abilitato e memorie a velocità inferiori del minimo supportato di default con due banchi? Ad esempio 2133 o 1866 MHz.

con Vsoc a default SMT abilitato e memorie a 2133 è presente il bug

con SMT abilitato tende a scomparire con Vsoc a 1,1V
dovrei provare leggermente sotto ma fino a 1,06 c'è

[s12a]

Originariamente inviato da il_dottorino

sto testando la cpu settimana 33 e non sembrerebbe buggata.. continuo nell'esecuzione del test, quanto tempo impiega a terminare il test? Il mio è fermo

Continua fino a che non si esaurisce la memoria libera, con inequivocabili avvisi quando questo avviene; se non ricordo male con 16GB ci vuole circa un'ora. Prima di ciò non dovrebbero apparire altri messaggi oltre a sporadici avvisi dal kernel Linux che non dovrebbero solitamente indicare problemi correlati ai segmentation fault.

Originariamente inviato da alexsky8

con Vsoc a default SMT abilitato e memorie a 2133 è presente il bug

con SMT abilitato tende a scomparire con Vsoc a 1,1V
dovrei provare leggermente sotto ma fino a 1,06 c'è

Per scrupolo e curiosità, potresti provare anche a 1866 MHz? Anche se 2133 MHz sarebbe comunque già abbastanza al di sotto della soglia accettabile per risolvere eventuali problemi a riguardo.

[alexsky8]

Originariamente inviato da s12a

Per scrupolo e curiosità, potresti provare anche a 1866 MHz? Anche se 2133 MHz sarebbe comunque già abbastanza al di sotto della soglia accettabile per risolvere eventuali problemi a riguardo.

provato non cambia nulla entro pochi minuti va in segfault come a 2133

è proprio solo incrementando il Vsoc o disabilitando l'SMT che si riesce ad incidere sull'errore o quantomeno mitigarlo

[s12a]

Originariamente inviato da alexsky8

provato non cambia nulla entro pochi minuti va in segfault come a 2133

è proprio solo incrementando il Vsoc o disabilitando l'SMT che si riesce ad incidere sull'errore o quantomeno mitigarlo

Dal punto di vista hardware. Pare che anche disabilitando il µOpCache da BIOS si possa mitigare in maniera simile; non so se la tua scheda madre lo permetta fra le opzioni della CPU.



Dal punto di vista software Randa71 qui nel thread come altri utenti ad esempio su Phoronix ha suggerito di disabilitare l'Address Space Layout Randomization (ASLR) con il seguente comando da Linux (che si può impartire prima di iniziare il test):

sudo sysctl -w kernel.randomize_va_space=0

Tuttavia ho letto che non risolve la questione in maniera definitiva. Potrebbe semplicemente impiegarci più tempo per apparire, probabilmente come con Windows usando kill-ryzen-win, e non è chiaro se questo risolverebbe eventuali (non confermate?) problematiche correlate con l'hardware.

[Randa71]

Originariamente inviato da s12a

.....

Dal punto di vista software Randa71 qui nel thread come altri utenti ad esempio su Phoronix ha suggerito di disabilitare l'Address Space Layout Randomization (ASLR) con il seguente comando da Linux (che si può impartire prima di iniziare il test):

sudo sysctl -w kernel.randomize_va_space=0

Tuttavia ho letto che non risolve la questione in maniera definitiva. Potrebbe semplicemente impiegarci più tempo per apparire, probabilmente come con Windows usando kill-ryzen-win, e non è chiaro se questo risolverebbe eventuali (non confermate?) problematiche correlate con l'hardware.

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

[Operapia]

Ecco le prove con stressapptest:

http://imageshack.com/a/img924/333/Sgakv4.png
http://imageshack.com/a/img922/3719/2t7Icp.png

Il vsoc lo tengo a 1.0 quanto porto i 4 banchi a 2667. Ora farò un test di blender come suggeritomi da un utente qualche post fa.

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

[s12a]

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

Interessante, grazie per i test.

Potresti provare anche il Torture Test di Prime95 (mprime) per Linux con e senza ASLR abilitato? Alcuni utenti con CPU affette da segfault hanno riscontrato strani problemi con esso da Windows, che però di norma non dovrebbe fare uso di ASLR. Tuttavia sembra sia sensibile al reboot del sistema (a volte errori escono subito, altri no):

http://www.mersenne.org/ftp_root/gim...linux64.tar.gz

https://community.amd.com/message/28...825959#2825959 (commento #1686)
https://www.reddit.com/r/Amd/comment...ti&sh=39e8bad6

Originariamente inviato da Operapia

Ecco le prove con stressapptest:

http://imageshack.com/a/img924/333/Sgakv4.png
http://imageshack.com/a/img922/3719/2t7Icp.png

Il vsoc lo tengo a 1.0 quanto porto i 4 banchi a 2667. Ora farò un test di blender come suggeritomi da un utente qualche post fa.

No, credo fosse stato consigliato Prime95 con torture test in modalità "blend", non Blender. Questo si può fare anche da Windows.
EDIT: era qui http://www.hwupgrade.it/forum/showpo...&postcount=582

Originariamente inviato da evil weasel

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

Effettivamente è vero, non sono "soluzioni", al limite workaround per mitigare il bug.

Tuttavia queste prove sono utili anche per capire cosa effettivamente favorisce o riduce la sua insorgenza, e se nella pratica può continuare ad uscire fuori entro tempi ragionevolmente brevi anche dopo alcuni di questi interventi.

[Randa71]

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.

SE ti riferivi al mio post:
1) la ram è a 2400 quindi nelle specifiche AMD...il vsoc è impostato in automatico da Asus...e visto che non penso tu sia un ingegnere che progetta schede madri, sono solo tue opinioni che il Vsoc sia fuori specifica...portami un doc di AMD dove dice che il Vsoc deve stare a 0.9...ci saranno dei motivi per cui Asus il Vsoc lo imposta così?? che dici?
2) c'è palesemente un baco nella CPU che si scatena attivando ASLR...a me interessa la soluzione e capire....la cpu è palesemente buggata con ASLR attivo e la compilazione..perchè con ASLR attivo ma senza compilazione, Linux funziona benissimo...mia esperienza diretta...se poi per te non è una soluzione disattivarlo, pazienza, lo considero un workaround...disattivare ASLR mi serve per capire il problema e l'entità del problema.....ti sarai perso che negli ultimi anni le CPU hanno un numero di errata non da poco...Ryzen ha questo....e AMD ha gestito il problema sostituendo le CPU...quindi è un non problema....

[Randa71]

Originariamente inviato da s12a

Interessante, grazie per i test.

Potresti provare anche il Torture Test di Prime95 (mprime) per Linux con e senza ASLR abilitato? Alcuni utenti con CPU affette da segfault hanno riscontrato strani problemi con esso da Windows, che però di norma non dovrebbe fare uso di ASLR. Tuttavia sembra sia sensibile al reboot del sistema (a volte errori escono subito, altri no):

adesso lo provo...

[s12a]

Originariamente inviato da Randa71

1) la ram è a 2400 quindi nelle specifiche AMD...il vsoc è impostato in automatico da Asus...e visto che non penso tu sia un ingegnere che progetta schede madri, sono solo tue opinioni che il Vsoc sia fuori specifica...portami un doc di AMD dove dice che il Vsoc deve stare a 0.9....

Parentesi off-topic, esiste ad oggi un datasheet pubblicamente accessibile per AMD Ryzen? Credo che non sia noto ufficialmente neanche il valore massimo continuativo ammissibile di Vcore.

http://support.amd.com/en-us/search/tech-docs

[Randa71]

Originariamente inviato da s12a

Parentesi off-topic, esiste ad oggi un datasheet pubblicamente accessibile per AMD Ryzen? Credo che non sia noto ufficialmente neanche il valore massimo continuativo ammissibile di Vcore.

http://support.amd.com/en-us/search/tech-docs

che io sappia no....però io ho posto la domanda ad AMD...nel loro forum ufficiale e questa è la risposta...
https://community.amd.com/message/28...omment-2803469
quindi come vedi il default non è 0.9...come tutti credono...
AMDMATT è Technical Support Engineer...quindi la sua risposta ha valore...
molto più delle credenze che circolano in giro in rete
sostanzialmente valori fino a 1.175 sono "accettabili"...quindi il valore di 1.05 impostato da Asus è un valore conservativo...considera che AMD ufficialmente supporta 1866 2133 2400 e 2666 STOP... quindi ci sta che aumentando la velocità della ram aumenti il vsoc...in Asus non sono cretini...sbagliano come tutti ma se dopo 6 mesi in cui la piattaforma è fuori i voltaggi non sono cambiati di una virgola...(a me così erano all'inizio e così sono adesso) e la CPU funziona perfettamente, vuol dire che non sono sbagliati o dannosi...lo dico perché avevo letto in giro che ASUS sbagliava i voltaggi che erano troppo alti...alti ma solo x XFR....

[evil weasel]

Originariamente inviato da Randa71

SE ti riferivi al mio post:
1) la ram è a 2400 quindi nelle specifiche AMD...il vsoc è impostato in automatico da Asus...e visto che non penso tu sia un ingegnere che progetta schede madri, sono solo tue opinioni che il Vsoc sia fuori specifica...portami un doc di AMD dove dice che il Vsoc deve stare a 0.9...ci saranno dei motivi per cui Asus il Vsoc lo imposta così?? che dici?
2) c'è palesemente un baco nella CPU che si scatena attivando ASLR...a me interessa la soluzione e capire....la cpu è palesemente buggata con ASLR attivo e la compilazione..perchè con ASLR attivo ma senza compilazione, Linux funziona benissimo...mia esperienza diretta...se poi per te non è una soluzione disattivarlo, pazienza, lo considero un workaround...disattivare ASLR mi serve per capire il problema e l'entità del problema.....ti sarai perso che negli ultimi anni le CPU hanno un numero di errata non da poco...Ryzen ha questo....e AMD ha gestito il problema sostituendo le CPU...quindi è un non problema....

Il mio era un commento generale, non mi riferivo solo a te.
Disabilitare ASLR va potenzialmente a minare la sicurezza del sistema, per questo motivo per quanto mi riguarda è una non soluzione.
Il VSOC default è 0.9 Volt perchè se fai "Load optimized defaults" nel BIOS quello è il valore della tensione di alimentazione del SOC.
Che poi, qualora si imposti manualmente una moltiplicatore delle RAM diverso da AUTO, alcune schede madri decidano di aumentare arbitrariamente la tensione di alimentazione di altri componenti è un discorso totalmente differente.
Le Gigabyte ad esempio sparano il VSOC a valori improponibili se questo viene lasciato su AUTO ed anche se lo si imposta su NORMAL (quando uno si aspetterebbe che normal voglia dire default, ma tant'è).
Questo non vuol dire però che la cosa abbia senso nè tantomeno che VSOC pari a 1.3 Volt sia l'impostazione di default.

Originariamente inviato da s12a

Parentesi off-topic, esiste ad oggi un datasheet pubblicamente accessibile per AMD Ryzen? Credo che non sia noto ufficialmente neanche il valore massimo continuativo ammissibile di Vcore.

http://support.amd.com/en-us/search/tech-docs

Mi sa di no, o almeno io non trovo nessun "Power and Thermal Data Sheet" relativo alla famiglia di CPU AMD 17h.
Se aspettano ancora un po' a rilasciarlo fa in tempo ad essere in vendita Ryzen 2.

[Randa71]

Originariamente inviato da evil weasel

Il mio era un commento generale, non mi riferivo solo a te.
Disabilitare ASLR va potenzialmente a minare la sicurezza del sistema, per questo motivo per quanto mi riguarda è una non soluzione.
Il VSOC default è 0.9 Volt perchè se fai "Load optimized defaults" nel BIOS quello è il valore della tensione di alimentazione del SOC.
Che poi, qualora si imposti manualmente una moltiplicatore delle RAM diverso da AUTO, alcune schede madri decidano di aumentare arbitrariamente la tensione di alimentazione di altri componenti è un discorso totalmente differente.
Le Gigabyte ad esempio sparano il VSOC a valori improponibili se questo viene lasciato su AUTO ed anche se lo si imposta su NORMAL (quando uno si aspetterebbe che normal voglia dire default, ma tant'è).
Questo non vuol dire però che la cosa abbia senso nè tantomeno che VSOC pari a 1.3 Volt sia l'impostazione di default.



Mi sa di no, o almeno io non trovo nessun "Power and Thermal Data Sheet" relativo alla famiglia di CPU AMD 17h.
Se aspettano ancora un po' a rilasciarlo fa in tempo ad essere in vendita Ryzen 2.

da quanto mi è stato risposto nel forum dal supporto tecnico di AMD il valore non è 0.9 ma 1...
e cmq per la cronaca con le kingston ddr4 2400 il load optimized default non le mette a 2133 con il vsoc a 0.9 ma a 2400 con il vsoc a 1.05.. Asus C6H bios 1701..
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ì...su Windows non ho mai avuto alcun problema....anzi Ryzen piattaforma molto più stabile dell'i7 3930K su P9X79PRO che avevo...
Mio personale parere: molti problemi che ci sono in giro secondo me sono dovuti a problemi di Ryzen nel digerire la RAM..(fai conto che io solo con il 1701 sono riuscito a far funzionare le ram con il profilo XMP...prima si frizzava la macchina) io che sembro aver raggiunto il nirvana (toccando ferro) per quanto riguarda accoppiata RAM e CPU e BIOS e AGESA, ad oggi l'unica problematica aperta per me è la compilazione con ASLR attivo...se non compilo ma ASLR attivo no problem...se compilo ma ASLR disattivo no problem...questo ad oggi....con tutto il resto funzionante perché problemi 0