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

[s12a]

👉 Non so se sia evidente a sufficienza, ma il primo post del thread è sempre in fase di aggiornamento con nuove informazioni e link mano a mano che vengono postati nella discussione. Al momento sono 28.5 kilobyte fra testo e BBCode.

[Gioz]

Originariamente inviato da alexsky8

ah ok ma 1,2 in effetti mi sembra altino

di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.

in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.

se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.

[Mister D]

Originariamente inviato da Gioz

di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.

in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.

se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.

Grazie Gioz, ma confidi troppo nella mia memoria
Non mi ricordo la video guida ma mi ricordo di asus e i 1,2 volt e di altri che dicevano 1,15 come daily use più safe con ram SR oltre i 2666.

[alexsky8]

Originariamente inviato da Mister D

Dubito fortemente che AMD si metta a fare step produttivi per ryzen prima generazione:

sì era per dire un passaggio successivo sia esso revisione o p.p. a 12nm

[alexsky8]

Originariamente inviato da Gioz

di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.

in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.

se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.

sì si capisco bene, giustamente stavi cercando una soluzione al problema è giusto che ciascuno possa riportare una propria esperienza per cercare di risolvere o mitigare la questione

[bagnino89]

Originariamente inviato da alexsky8

è chiaro che sta storia andrà avanti fino al prossimo step produttivo

Lo penso anche io. Se poi AMD non rende chiara e pubblica la questione...

Originariamente inviato da moob1

Per legge, dopo aver riscontrato un difetto hai massimo 2 mesi per restituire il prodotto, altrimenti perdi il diritto alla garanzia su quel difetto...

Se AMD non dichiara nulla ufficialmente, io potrei benissimo accorgermi dell'errore ad 1 mese dalla scadenza della garanzia...

Originariamente inviato da alexsky8

comunque attendo la revisione 2 di ryzen e poi chiamo AMazon

Originariamente inviato da alexsky8

ci mancherebbe ma qua sarebbe ben peggio farsi sostituire 10 CPU per averne una buona e aprire 10 sigilli; credo che la soluzione migliore per tutti sia attendere Ryzen 2 o comunque una revisione

10gg senza CPU per fare RMA da AMD per ora non ci penso neppure

Quoto.

Di sicuro non è una soluzione per tutti (magari chi ha bisogno di assoluta stabilità sin da subito se la fa sostituire il prima possibile), ma nel mio caso non vedo questa imminente necessità. Chiaro che, se risconterò problemi, provvederò immediatamente anche io.

Poi sta di fatto che, in ogni caso, avere hardware con bug non è mai consigliabile.

[alexsky8]

Originariamente inviato da moob1

Installato, ho fatto l'upgrade della 17.04. Sono anche in overclock a 4GHz @ 1.33v e vSOC a 1.1v

Originariamente inviato da moob1

Quasi 10 minuti, tutto a default, nessun errore.

ho INSTALLATO (no live quindi) UBUNTU 17.10 su SSD, ho fatto partire il test Oxalin con tutti e 16 i core attivi, sta girando da 13 minuti e nessun errore (per ora)
con la live mediamente dopo 2-3 minuti mi dava errore....lascio girare ancora per vedere se va in segfault

[Mister D]

Originariamente inviato da alexsky8

sì era per dire un passaggio successivo sia esso revisione o p.p. a 12nm

Ok ma il fatto di passare a pinnacle ridge non è correlato con questo bug in quanto già ora le cpu prodotte dopo il nuovo quality test sono esenti dal problema e che pinnacle ridge, come tutte le altre cpu di questa terra, avrà anch'esso dei bug. Ovviamente mi pare lapalissiano che se già ora hanno sistemato la selezione per le nuove cpu, sarebbe da fessi avere lo stesso problema di selezioni per le nuove cpu.
Cmq visto che agesa 1.0.0.7 già parla di supporto a pinnacle ridge direi che hai una conferma indiretta che revisioni non ce ne saranno dei ryzen 1000 ma ci saranno i nuovi su p.p. a 12nm.

[SL45i]

ragazzi per quanto riguarda il test ho installato una macchina virtuale ed ho installato ubuntu va bene lo stesso il test nella macchina virtuale?

[s12a]

Originariamente inviato da SL45i

ragazzi per quanto riguarda il test ho installato una macchina virtuale ed ho installato ubuntu va bene lo stesso il test nella macchina virtuale?

Sì, dovrebbe, in particolar modo se la tua CPU ha le estensioni per la virtualizzazione attivate (in tal modo l'operazione è praticamente come eseguirla nativamente). Usare una distribuzione Live è semplicemente una "procedura standard" facilmente replicabile.

Il problema se esistente deve essere riproducibile anche in modi simili usando metodi diversi.

[alexsky8]

adesso mi da un altro tipo di errore ma dopo 20 minuti

Originariamente inviato da alexsky8

adesso mi da un altro tipo di errore ma dopo 20 minuti

Non credo che la cpu sia affetta da segfault sinceramente.

[s12a]

Originariamente inviato da alexsky8

adesso mi da un altro tipo di errore ma dopo 20 minuti

Alcuni degli avvisi (non veri e propri errori) come quello riportati dal kernel durante il test non dipendono dallo stato del test in sé e non sono indicativi di problemi con la CPU.

Il test dovrebbe continuare ad andare fino a che non dice "build failed". Da una rapida ricerca su Google:

https://bbs.archlinux.org/viewtopic.php?id=187636

I get:
perf interrupt took too long (2503 > 2495), lowering kernel.perf_event_max_sample_rate to 50100.
Every ~5 hours in dmesg. [...]

Any clue highly appreciated.

This is informational and nothing to worry about. It has to do with the Linux perf tool which is included in the kernel. The kernel automagically determines the sample rate that could be used without impacting system performance too much; and it logs this even when perf isn't active, or even installed. Messages like this are triggered by high(er) system load or a cpu that is scaling

EDIT: a proposito, puoi provare a digitare dal terminale questo comando e riportare il risultato?

sysctl kernel.randomize_va_space

Se risponde "2", lo Address Space Layout Randomization (ASLR) è abilitato. Magari sulla versione installata di Ubuntu 17.10 è disabilitato?

Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:



Questo è il livello di competenza sugli altri forum, giudicate voi.

[Mister D]

Originariamente inviato da moob1

Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:



Questo è il livello di competenza sugli altri forum, giudicate voi.

novella 2000 colpisce ancora
Battuta ON
E qui date contro a quelli del thread ufficiale tacciati di voler insabbiare, quando là fuori è pure peggio
Battuta OFF

[evil weasel]

Originariamente inviato da moob1

Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:



Questo è il livello di competenza sugli altri forum, giudicate voi.

Povero italiano.

[alexsky8]

Originariamente inviato da s12a

Se risponde "2", lo Address Space Layout Randomization (ASLR) è abilitato. Magari sulla versione installata di Ubuntu 17.10 è disabilitato?

mi da = 2 ma non capisco cosa significhi in pratica




l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%

[CiccoMan]

Originariamente inviato da moob1

Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:

[img]

Questo è il livello di competenza sugli altri forum, giudicate voi.

Membro dello staff

Dimmi dove abita, che per natale gli mando una tastiera... la sua deve essere rotta

[s12a]

Originariamente inviato da alexsky8

mi da = 2 ma non capisco cosa significhi in pratica

https://i.imgur.com/u5uQzZg.png

L'ASLR è una funzionalità che si suppone aumenti la probabilità di osservare segfault e simili con Linux sulle CPU Ryzen. Se però il comando ti riporta "2" vuol dire che non è che non sembri più osservare segfault perché è disabilitata.

l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%

Vista dove?

Da Linux solitamente "free memory" ha un significato diverso quello che sembra:
https://www.linuxatemyram.com/

[ccmarco2004]

Originariamente inviato da evil weasel

Povero italiano.

Esatto, sembra la trascrizione di un dialogo del GFV fatta dalla Gialappa's Band.

Sarebbe interessante creare una sorta di database con i dati relativi alle cpu soggette al problema (seriale, lotto, made in X, etc) e pubblicarne il contenuto sotto forma di tabella in testa al 3ad.

Magari è già stato fatto altrove.