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

[s12a]

@Operapia: risultato interessante, in quanto conferma in un certo senso che gli errori di segfault potrebbero dipendere in gran parte da overclock memorie e/o tensione insufficiente lato memory controller (uncore/SoC, dunque?).

Con 4 banchi di memoria a 1866 MHz hai già provato?

[Operapia]

Originariamente inviato da s12a

@Operapia: risultato interessante, in quanto conferma in un certo senso che gli errori di segfault potrebbero dipendere in gran parte da overclock memorie e/o tensione insufficiente lato memory controller (uncore/SoC, dunque?).

Con 4 banchi di memoria a 1866 MHz hai già provato?

NO, non ho provato per mancanza di tempo. Allora questa sera, dopo che rimonto la ram che avevo tolto, prima di mandarla a 2667 la provo a 1866 e vi posto il risultato.
Resta da capire perché AMD faccia rma anche a processori il cui test sia stato svolto con memorie in oc.

[Mister D]

Originariamente inviato da Operapia

NO, non ho provato per mancanza di tempo. Allora questa sera, dopo che rimonto la ram che avevo tolto, prima di mandarla a 2667 la provo a 1866 e vi posto il risultato.
Resta da capire perché AMD faccia rma anche a processori il cui test sia stato svolto con memorie in oc.

Visto che i tuoi moduli sono single rank fino a 2133 dovrebbero andare senza troppi problemi. Prova, poi hai pure il profilo jedec std a 2133. Dovrebbe impostare la scheda madre i 2133 (1067 circa).

Non so, ipotizzo che magari AMD per non avere problemi d'immagine accetti RMA preventivamente quando uno dice di avere cpu affetta da questo bug e poi verifica lei. E magari se non sono troppi i casi di chi manda cpu esenti da bug ma testate in oc ram, fa contento il cliente rimandando una cpu sicuramente funzionante (tranne forse i primi casi in cui manco AMD sapeva che pesci friggere)

[papugo1980]

@MisterD secondo te allora perché a me con le RAM in OC il test non fallisce?

[Mister D]

Originariamente inviato da papugo1980

@MisterD secondo te allora perché a me con le RAM in OC il test non fallisce?

Risposta semi seria: "le vie dell'informatica sono più infinite di quelle del Signore, di un ordine molto superiore".
Risposta seria: cpu diverse corrispondono comportamenti diversi in oc proprio perché la litografia usata nel pp determina tutte cpu diverse, chi meglio chi peggio.

[il_dottorino]

con grande sorpresa è appena arrivata la cpu sostitutiva UA1733SUS.. speriamo bene

[Operapia]

Originariamente inviato da Mister D

Risposta semi seria: "le vie dell'informatica sono più infinite di quelle del Signore, di un ordine molto superiore".
Risposta seria: cpu diverse corrispondono comportamenti diversi in oc proprio perché la litografia usata nel pp determina tutte cpu diverse, chi meglio chi peggio.

Ti quoto la risposta seria.
la mia cpu scalda un botto e ci vogliono i 1.32 di vcore per i 3.8 giga.

Dopo pranzo ho provato a fare il test ma il terminale di ubuntu mi dice che non ho i permessi...ma che cazz0, si sarà sminchiata la pennetta. Ora mi tocca farne un'altra.

[animeserie]

Originariamente inviato da Operapia

Dopo pranzo ho provato a fare il test ma il terminale di ubuntu mi dice che non ho i permessi...ma che cazz0, si sarà sminchiata la pennetta. Ora mi tocca farne un'altra.

usando il comando "sudo" (Super User, che ti chiederà la password) non riesci neppure ?

[Alex656]

Anche io ero impazzito per un problema sui permessi durante il test; in realtà avevo scaricato male lo script perchè avviavo il download cliccando col destro sul file e facevo "salva oggetto con nome"; ho risolto scaricando direttamente tutta la cartella contenente il test e scompattandola poi sul desktop.

[Operapia]

Originariamente inviato da animeserie

usando il comando "sudo" (Super User, che ti chiederà la password) non riesci neppure ?

Spiegami che meglio please ed in ogni caso che password ci metto?

[s12a]

Originariamente inviato da Alex656

Anche io ero impazzito per un problema sui permessi durante il test; in realtà avevo scaricato male lo script perchè avviavo il download cliccando col destro sul file e facevo "salva oggetto con nome"; ho risolto scaricando direttamente tutta la cartella contenente il test e scompattandola poi sul desktop.

Originariamente inviato da Operapia

Spiegami che meglio please ed in ogni caso che password ci metto?

Non occorre inserire alcuna password facendo tutto correttamente con la distribuzione live da chiavetta USB.
Le istruzioni complete: http://www.hwupgrade.it/forum/showpo...&postcount=146

[Alex656]

Originariamente inviato da s12a

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

Non occorre inserire alcuna password facendo tutto correttamente con la distribuzione live da chiavetta USB.
Le istruzioni complete: http://www.hwupgrade.it/forum/showpo...&postcount=146

Confermo tutto, su quella live, essendo già superuser, non deve venir richiesta alcuna password o permesso, se succede si sta sbagliando qualcosa così come sbagliavo io.

[Operapia]

Originariamente inviato da s12a

Non occorre inserire alcuna password facendo tutto correttamente con la distribuzione live da chiavetta USB.
Le istruzioni complete: http://www.hwupgrade.it/forum/showpo...&postcount=146

Mi è sempre partito al primo colpo...si vede che nella pausa pranzo devo aver fatto qualcosa di diverso...forse sono sminchiato io non la chiavetta

[animeserie]

Originariamente inviato da Operapia

Spiegami che meglio please ed in ogni caso che password ci metto?

sudo in sostanza ti permette di eseguire un comando dalla shell, come super utente o altri (da impersonare)
in tal caso:

# sudo [nomeprogramma_o_batch]

e lui vuole eseguirtelo in super user (massimi privilegi).
a questo punto gli devi dare la password dell'utente "root". tu l'avrai definita da qualche parte no ?
(a meno che il tuo utente non appartenga già al gruppo root, in tal caso ti dovrebbe richiedere la conferma della password, ma è da un pò che non uso Linux ).

Qui per maggiori informazioni:
https://wiki.ubuntu-it.org/AmministrazioneSistema/Sudo

[Randa71]

ad oggi io il problema dei seg fault l'ho risolto disabilitando la randomizzazione della ram del kernel di linux

sudo sysctl -w kernel.randomize_va_space=0

risolto nel senso che tutte le volte in cui ho lanciato la compilazione con quel valore a 0, non ho mai avuto errori di SegFault.
se la riattivo si. (il default su linux è 2) errore mi si presenta molto velocemente...non supera i 5 min...mettendolo a 0 va avanti fino a che non lo stoppo io...
Premesso che la mia macchina è sempre stabile...mai avuto un problema diverso dal segfault (che cmq andavo a cercare appositamente). Quindi non è vero che è instabile anche sotto Windows....
state solo cercando fantasmi...
provate a lanciare lo script con quella riga di comando...
vi allego un pezzo dello script kill_ryzen con l'aggiunta della riga

# start journal process in different working directory
pushd /
journalctl -kf | sed 's/^/[KERN] /' &
popd
echo "Using ${NPROC} parallel processes"
# Randomizzazione eliminata della ram che dovrebbe risolvere il problema del SegFault
sudo sysctl -w kernel.randomize_va_space=0

START=$(date +%s)
for ((I=0;$I<$NPROC;I++)); do
(./buildloop.sh "loop-$I" "$TPROC" || echo "TIME TO FAIL: $(($(date +%s)-${START})) s") | sed "s/^/\[loop-${I}\] /" &
sleep 1
done

e ci sta anche sia errore che la risoluzione dello stesso visto quello che fa il randomize space...così ad oggi l'errore sembra essere sparito....
cmq andrò avanti a fare prove..

[sinergine]

Scrivo da Ubuntu 17.10 mentre sta facendo il test.

Ryzen 1700
Asus ROG STRIX X370-F GAMING
Crucial 8GBx2 2666 impostate a default 2400 (come voltaggio ha impostato 1,35)


ha scaricato questo. Va bene?
gcc-7.2.0.tar.xz 100%[=======================================================>] 59.43M 639KB/s in 2m 4s

Il test sta girando da 30 minuti e vedo questi che non dovrebbero essere errori di segfault

[loop-15] Fri Oct 27 17:49:57 UTC 2017 start 0
[KERN] Oct 27 17:59:32 ubuntu kernel: nouveau 0000:29:00.0: disp: 0x000062df[0]: INIT_GENERIC_CONDITON: unknown 0x07
[KERN] Oct 27 18:01:47 ubuntu kernel: ------------[ cut here ]------------
[KERN] Oct 27 18:01:47 ubuntu kernel: WARNING: CPU: 7 PID: 302 at /build/linux-XO_uEE/linux-4.13.0/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:169 nvkm_dp_train+0x77b/0x990 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: Modules linked in: zram snd_hda_codec_hdmi snd_hda_codec_realtek edac_mce_amd snd_hda_codec_generic snd_hda_intel kvm snd_hda_codec snd_hda_core snd_hwdep snd_pcm joydev input_leds irqbypass crct10dif_pclmul snd_seq_midi crc32_pclmul snd_seq_midi_event ghash_clmulni_intel pcbc snd_rawmidi snd_seq aesni_intel snd_seq_device snd_timer snd soundcore aes_x86_64 ccp eeepc_wmi crypto_simd glue_helper asus_wmi cryptd sparse_keymap shpchp 8250_dw wmi_bmof i2c_piix4 mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 overlay nls_iso8859_1 dm_mirror dm_region_hash dm_log uas usb_storage hid_generic usbhid hid nouveau mxm_wmi video ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops igb drm dca i2c_algo_bit ptp ahci pps_core libahci gpio_amdpt wmi gpio_generic
[KERN] Oct 27 18:01:47 ubuntu kernel: CPU: 7 PID: 302 Comm: kworker/u32:11 Not tainted 4.13.0-16-generic #19-Ubuntu
[KERN] Oct 27 18:01:47 ubuntu kernel: Hardware name: System manufacturer System Product Name/ROG STRIX X370-F GAMING, BIOS 0902 09/08/2017
[KERN] Oct 27 18:01:47 ubuntu kernel: Workqueue: nvkm-disp gf119_disp_super [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: task: ffff8ab1ffe30000 task.stack: ffffb603c2ba4000
[KERN] Oct 27 18:01:47 ubuntu kernel: RIP: 0010:nvkm_dp_train+0x77b/0x990 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: RSP: 0018:ffffb603c2ba7c60 EFLAGS: 00010297
[KERN] Oct 27 18:01:47 ubuntu kernel: RAX: 0000000000000000 RBX: ffff8ab200c2ac00 RCX: 0000000000000000
[KERN] Oct 27 18:01:47 ubuntu kernel: RDX: 0000000000000001 RSI: ffffb603c900d9a4 RDI: 0000000001009000
[KERN] Oct 27 18:01:47 ubuntu kernel: RBP: ffffb603c2ba7d38 R08: 00000000ffffffff R09: 0000000000000000
[KERN] Oct 27 18:01:47 ubuntu kernel: R10: 0000000000000000 R11: 0000000000000030 R12: ffff8ab20c598800
[KERN] Oct 27 18:01:47 ubuntu kernel: R13: ffff8ab200a1d000 R14: 0000000000120336 R15: 0000000000000000
[KERN] Oct 27 18:01:47 ubuntu kernel: FS: 0000000000000000(0000) GS:ffff8ab21edc0000(0000) knlGS:0000000000000000
[KERN] Oct 27 18:01:47 ubuntu kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[KERN] Oct 27 18:01:47 ubuntu kernel: CR2: 00007fded4c7d000 CR3: 0000000345b15000 CR4: 00000000003406e0
[KERN] Oct 27 18:01:47 ubuntu kernel: Call Trace:
[KERN] Oct 27 18:01:47 ubuntu kernel: ? freed_request+0x3d/0x60
[KERN] Oct 27 18:01:47 ubuntu kernel: ? __update_load_avg_se.isra.37+0x155/0x160
[KERN] Oct 27 18:01:47 ubuntu kernel: ? __update_load_avg_se.isra.37+0x155/0x160
[KERN] Oct 27 18:01:47 ubuntu kernel: nvkm_dp_acquire+0xd1/0x3a0 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: nv50_disp_super_2_2+0x5d/0x470 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: ? nvkm_outp_route+0xe5/0x150 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: gf119_disp_super+0x19c/0x2f0 [nouveau]
[KERN] Oct 27 18:01:47 ubuntu kernel: process_one_work+0x1e7/0x410
[KERN] Oct 27 18:01:47 ubuntu kernel: worker_thread+0x4a/0x410
[KERN] Oct 27 18:01:47 ubuntu kernel: kthread+0x125/0x140
[KERN] Oct 27 18:01:47 ubuntu kernel: ? process_one_work+0x410/0x410
[KERN] Oct 27 18:01:47 ubuntu kernel: ? kthread_create_on_node+0x70/0x70
[KERN] Oct 27 18:01:47 ubuntu kernel: ret_from_fork+0x25/0x30
[KERN] Oct 27 18:01:47 ubuntu kernel: Code: 4c 8d 85 74 ff ff ff b9 00 06 00 00 ba 09 00 00 00 be 01 00 00 00 4c 89 e7 e8 a2 8d fd ff 85 c0 75 77 80 bd 75 ff ff ff 01 74 02 <0f> ff 4c 89 e7 e8 8b 8b fd ff 0f b6 85 74 ff ff ff 89 c2 83 e2
[KERN] Oct 27 18:01:47 ubuntu kernel: ---[ end trace 1746d95a5af9f09b ]---
[KERN] Oct 27 18:01:47 ubuntu kernel: nouveau 0000:29:00.0: disp: outp 07:0006:0f82: training failed
[KERN] Oct 27 18:02:21 ubuntu kernel: nouveau 0000:29:00.0: disp: 0x000062df[0]: INIT_GENERIC_CONDITON: unknown 0x07

[Operapia]

Il test con quattro banchi di ram a 1866 è andato liscio, pure troppo che sembrava non finire mai e l'ho interrotto.

Per curiosità comunque prima avevo fatto anche un test con due banchi a 2667.
Mi si è frezzato due volte il pc, la terza volta ha partorito questo:

http://imageshack.com/a/img924/9662/fdhkp3.jpg
http://imageshack.com/a/img924/337/dbEqx9.jpg
http://imageshack.com/a/img923/236/zJ1oCM.jpg

[s12a]

Originariamente inviato da Randa71

ad oggi io il problema dei seg fault l'ho risolto disabilitando la randomizzazione della ram del kernel di linux

sudo sysctl -w kernel.randomize_va_space=0 [...]

La disabilitazione dell'ALSR era stata menzionata in precedenza oltre che nel primo post, ma nessuno l'aveva ancora provata qui. Non sembra corregga la problematica in maniera definitiva stando ai report online tuttavia; la rende più rara nel manifestarsi, cosa che comunque potrebbe bastare in molti casi, ma non risolve la questione alla radice.

Originariamente inviato da sinergine

Scrivo da Ubuntu 17.10 mentre sta facendo il test.

Ryzen 1700
Asus ROG STRIX X370-F GAMING
Crucial 8GBx2 2666 impostate a default 2400 (come voltaggio ha impostato 1,35)

Più che la tensione memoria probabilmente quella importante è quella SoC. Il problema sembra essere legato al memory controller od all'Infinity Fabric che in alcuni esemplari di CPU forse hanno avuto tolleranze di produzione troppo ampie.

ha scaricato questo. Va bene?
gcc-7.2.0.tar.xz 100%[=======================================================>] 59.43M 639KB/s in 2m 4s

Sì, 7.2.0.

Il test sta girando da 30 minuti e vedo questi che non dovrebbero essere errori di segfault

Nouveau è il driver open source della scheda video NVidia; non penso abbia a che vedere con il test o la problematica del thread, a patto che lo faccia sempre dopo più o meno dopo lo stesso tempo (ci sono stati report di apparenti problemi hardware correlati con il segfault e risolti con una nuova cpu).

Originariamente inviato da Operapia

Il test con quattro banchi di ram a 1866 è andato liscio, pure troppo che sembrava non finire mai e l'ho interrotto.

Per curiosità comunque prima avevo fatto anche un test con due banchi a 2667.
Mi si è frezzato due volte il pc, la terza volta ha partorito questo:

http://imageshack.com/a/img924/9662/fdhkp3.jpg
http://imageshack.com/a/img924/337/dbEqx9.jpg
http://imageshack.com/a/img923/236/zJ1oCM.jpg

Grazie per i test. Sembra dunque che non ti vengano digeriti i 2667 MHz.

Sarebbe interessante provare nuovamente (se ti va/tempo permettendo) impostando timing e frequenza manualmente (eventualmente usando timing leggermente più rilassati), e se il problema persiste provare ad aumentare la tensione di SoC (vSoC) ad esempio a 1.1V.

Nel primo caso si verificherebbe se il problema sia effettivamente il profilo XMP, nel secondo se come per altri utenti basta quello per risolvere la questione.

Sarebbe positivo poter circoscrivere la cosa a, nella pratica, RAM ed impostazioni correlate di compatibilità/stabilità.

In un caso ho letto di segfault essere imputati ad un banco di "ram difettosa", ma forse non è stato veramente così?

https://www.phoronix.com/forums/foru...081#post977081
https://www.phoronix.com/forums/foru...938#post977938

[Operapia]

Originariamente inviato da s12a

La disabilitazione dell'ALSR era stata menzionata in precedenza oltre che nel primo post, ma nessuno l'aveva ancora provata qui. Non sembra corregga la problematica in maniera definitiva stando ai report online tuttavia; la rende più rara nel manifestarsi, cosa che comunque potrebbe bastare in molti casi, ma non risolve la questione alla radice.


Più che la tensione memoria probabilmente quella importante è quella SoC. Il problema sembra essere legato al memory controller od all'Infinity Fabric che in alcuni esemplari di CPU forse hanno avuto tolleranze di produzione troppo ampie.


Sì, 7.2.0.


Nouveau è il driver open source della scheda video NVidia; non penso abbia a che vedere con il test o la problematica del thread, a patto che lo faccia sempre dopo più o meno dopo lo stesso tempo (ci sono stati report di apparenti problemi hardware correlati con il segfault e risolti con una nuova cpu).


Grazie per i test. Sembra dunque che non ti vengano digeriti i 2667 MHz.

Sarebbe interessante provare nuovamente (se ti va/tempo permettendo) impostando timing e frequenza manualmente (eventualmente usando timing leggermente più rilassati), e se il problema persiste provare ad aumentare la tensione di SoC (vSoC) ad esempio a 1.1V.

Nel primo caso si verificherebbe se il problema sia effettivamente il profilo XMP, nel secondo se come per altri utenti basta quello per risolvere la questione.

Sarebbe positivo poter circoscrivere la cosa a, nella pratica, RAM ed impostazioni correlate di compatibilità/stabilità.

In un caso ho letto di segfault essere imputati ad un banco di "ram difettosa", ma forse non è stato veramente così?

https://www.phoronix.com/forums/foru...081#post977081
https://www.phoronix.com/forums/foru...938#post977938

Farò un altro test con con i timing più blandi, ma le frequenze le imposta sempre manualmente, mai usato xmp.
Sono anche io curioso di vedere se i 2667 me li regge in qualche modo.
Ieri sera è durante il test non potevo fare neppure uno screeshot che il pc si bloccava e dovevo resettare.

Scrivo dall'ufficio e non ho sotto mano i memtest86 che ho fatto, ma tempo fa ho provato un banco alla volta per 20 cicli (9 ore circa) prima, poi tutti i banchi assieme per 10 cicli. A default la prima, a 2667 la seconda. Non c'è traccia di errore. Se ci sono strumenti più precisi per testare le ram dimmelo che li provo.

[s12a]

Originariamente inviato da Operapia

[...] Scrivo dall'ufficio e non ho sotto mano i memtest86 che ho fatto, ma tempo fa ho provato un banco alla volta per 20 cicli (9 ore circa) prima, poi tutti i banchi assieme per 10 cicli. A default la prima, a 2667 la seconda. Non c'è traccia di errore. Se ci sono strumenti più precisi per testare le ram dimmelo che li provo.

Oltre a Memtest86 c'è Memtest64 di Techpowerup; è un più rapido e potrebbe risultare più comodo da usare perché si può eseguire anche da Windows. Pare che a volte riesca a trovare errori che Memtest86 non rileva facilmente (credo che il problema principale di Memtest86 sia che le versioni più diffuse lavorano solo in modalità single thread, dunque potrebbero non mostrare problemi che magari avvengono solo a pieno carico): https://www.techpowerup.com/memtest64/

Secondo altri, HCI memtest ha simili qualità rispetto al solito Memtest86, ma non l'ho mai provato: http://hcidesign.com/memtest/


EDIT: tralascia quanto ho scritto sopra (non l'ho cancellato in quanto può sempre essere utile per altri). C'è questo tool che si può eseguire sempre da chiavetta USB con la distribuzione Live di Linux. Pare sia anche usato da Google per testare i loro server e che sia piuttosto intensivo; proverei a dargli un'occhiata:

https://github.com/stressapptest/stressapptest

Con Ubuntu non occorre scaricare niente da github come per ryzen-test. Si installa semplicemente scrivendo da terminale:

apt-get install stressapptest

in seguito parte scrivendo sempre da riga di comando:

stressapptest

Sono possibili varie opzioni di avvio. Con le opzioni base effettua un test su tutta la memoria disponibile per 20 secondi.

Dal sito sopra questa riga di comando effettua: "test 256MB, running 8 "warm copy" threads. Exit after 20 seconds".

stressapptest -s 20 -M 256 -m 8 -W

Se lo si vuole fare partire per 30 minuti (1800 secondi) con le altre impostazioni di default (tutta la memoria, numero di thread pari a quelli del processore) allora il comando sarà il seguente. Più il test dura, meglio sarà, presumibilmente. Lo si può terminare manualmente premendo CTRL+C (EDIT: ho notato che il flag -W aumenta effettivamente il carico del test, dunque è bene usarlo. Il flag --stop_on_errors termina automaticamente il test - facendo risparmiare tempo - qualora ci siano errori):

stressapptest -s 1800 -W --stop_on_errors

Si può usare anche da Ubuntu tramite il WSL (cosa piuttosto utile per testare la memoria da Windows). Se si lancia questo stressapptest con il flag --help sarà mostrato un elenco di tutte le opzioni disponibili.