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

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

[Operapia]

@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?

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

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]

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]

@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]

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]

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]

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]

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.

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

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/showpost.php?p=45108749&postcount=146

[Alex656]

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/showpost.php?p=45108749&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]

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/showpost.php?p=45108749&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 :doh:

[animeserie]

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 :D ).

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]

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.

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

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/forum/hardware/processors-memory/976711-agesa-1-0-0-6b-might-fix-the-ryzen-linux-performance-marginality-problem?p=977081#post977081
https://www.phoronix.com/forums/forum/hardware/processors-memory/976711-agesa-1-0-0-6b-might-fix-the-ryzen-linux-performance-marginality-problem?p=977938#post977938

[Operapia]

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/forum/hardware/processors-memory/976711-agesa-1-0-0-6b-might-fix-the-ryzen-linux-performance-marginality-problem?p=977081#post977081
https://www.phoronix.com/forums/forum/hardware/processors-memory/976711-agesa-1-0-0-6b-might-fix-the-ryzen-linux-performance-marginality-problem?p=977938#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]

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

[Operapia]

Grazie, tu quale useresti, non mi va di provarli tutti.

[s12a]

Prova sempre da chiavetta USB con Ubuntu "stressapptest". Dotrebbe essere una ottima alternativa intensiva al solito memtest86. Ho modificato il commento con informazioni più chiare su come usarlo.

[Debern9093]

Salve ragazzi, il mio pacco rma è arrivato ieri ad AMD... Ora chiedo una cosa, come posso capire se è quando AMD mi spedisce il mio nuovo processore?

[Operapia]

Prova sempre da chiavetta USB con Ubuntu "stressapptest". Dotrebbe essere una ottima alternativa intensiva al solito memtest86. Ho modificato il commento con informazioni più chiare su come usarlo.

oook, grazie mille

[s12a]

Salve ragazzi, il mio pacco rma è arrivato ieri ad AMD... Ora chiedo una cosa, come posso capire se è quando AMD mi spedisce il mio nuovo processore?

Dovrebbero inviarti un numero di tracking a spedizione avvenuta.

[evil weasel]

Grazie, tu quale useresti, non mi va di provarli tutti.

Il problema nel tuo caso al 99.9% non sono le RAM in se ma il memory controller che ha bisogno di più volt per riuscire a pilotare correttamente banchi ad alta densità.
Stressapptest e memtest funzionano molto bene per trovare banchi di RAM fallati o instabili ad una determinata frequenza ma non altrettanto bene quando si deve testare la stabilità del memory controller.
Se dovessi testare la stabilità dell'intero sistema io userei il solito prime95, le ultime versioni le puoi trovare qui: http://www.mersenneforum.org/forumdisplay.php?f=10
A prescindere comunque questo è un discorso di overclock che poco ha a che fare con il thread in cui stiamo scrivendo.
È evidente che il test kill-ryzen va effettuato con tutte le componenti a default, ovvero quelle che si ottengono andando nel BIOS e caricando "Load optimized defaults".

[Debern9093]

Dovrebbero inviarti un numero di tracking a spedizione avvenuta.

Ah bene :) ma ovviamente non credo che spediscano sabato e domenica

[Operapia]

Il problema nel tuo caso al 99.9% non sono le RAM in se ma il memory controller che ha bisogno di più volt per riuscire a pilotare correttamente banchi ad alta densità.
Stressapptest e memtest funzionano molto bene per trovare banchi di RAM fallati o instabili ad una determinata frequenza ma non altrettanto bene quando si deve testare la stabilità del memory controller.
Se dovessi testare la stabilità dell'intero sistema io userei il solito prime95, le ultime versioni le puoi trovare qui: http://www.mersenneforum.org/forumdisplay.php?f=10
A prescindere comunque questo è un discorso di overclock che poco ha a che fare con il thread in cui stiamo scrivendo.
È evidente che il test kill-ryzen va effettuato con tutte le componenti a default, ovvero quelle che si ottengono andando nel BIOS e caricando "Load optimized defaults".

Io intento un test con stressapptest lo faccio.
Il memory controller [ integrato nella cpu giusto?
Quale opzione di prime 95 devo lanciare per le ram, visto che ho gi' l-ultima versione

[evil weasel]

Io intento un test con stressapptest lo faccio.
Il memory controller [ integrato nella cpu giusto?
Quale opzione di prime 95 devo lanciare per le ram, visto che ho gi' l-ultima versione

Personalmente uso l'impostazione "blend" specificando manualmente che voglio vengano utilizzati 31000 MB di RAM (sui 32 GB che ho a disposizione).

[SL45i]

Secondo me Amd non ci fa una bella figura con sta roba... fortunati quelli che hanno preso una cpu esente dal bug... ma così come me credo siano molti quelli che hanno abbandonato la piattaforma... perché non esiste e ripeto non esiste che io spendo tanti soldi e non ricevo un prodotto perfetto come i soldi che hanno incassato... È non m interessano Rma assistenza ecc perche mi generano solo perdite di tempo... come il tempo speso a far continui resi e riacquisti invano... mi auguro che in futuro migliorino il controllo qualità ma per ora ci sto ben lontano...

[bagnino89]

Secondo me Amd non ci fa una bella figura con sta roba... fortunati quelli che hanno preso una cpu esente dal bug... ma così come me credo siano molti quelli che hanno abbandonato la piattaforma... perché non esiste e ripeto non esiste che io spendo tanti soldi e non ricevo un prodotto perfetto come i soldi che hanno incassato... È non m interessano Rma assistenza ecc perche mi generano solo perdite di tempo... come il tempo speso a far continui resi e riacquisti invano... mi auguro che in futuro migliorino il controllo qualità ma per ora ci sto ben lontano...

Purtroppo i problemi capitano a tutti (Intel, AMD, Nvidia...).

[SL45i]

Purtroppo i problemi capitano a tutti (Intel, AMD, Nvidia...).

Vengo dal 3770, 4770k, 4790k, 5820k, con motherboard msi gigabyte asus ed asrock e con tutta sta trafila non mi sono mai trovato in un vortice del genere... ora come ben vedi la mia ultima cpu era il 5820k una delle ultime con ihs saldato... avevo preso amd perché seguiva questa politica e purtroppo sto tutt' ora passando le pene dell' inferno.. negli ultimi anni non avevo mai visto una cosa del genere..

[alexsky8]

Vengo dal 3770, 4770k, 4790k, 5820k, con motherboard msi gigabyte asus ed asrock e con tutta sta trafila non mi sono mai trovato in un vortice del genere... ora come ben vedi la mia ultima cpu era il 5820k una delle ultime con ihs saldato... avevo preso amd perché seguiva questa politica e purtroppo sto tutt' ora passando le pene dell' inferno.. negli ultimi anni non avevo mai visto una cosa del genere..

in che senso pene dell'inferno ?

la mia CPU ha il bug ma onestamente ci faccio di tutto
office
web
musica
analisi ad elementi finiti
autocad
e qualche rendering

e non ho mai avuto problemi

certo mi secca avere una CPU con il Bug ma per il resto fila benissimo

[bagnino89]

Vengo dal 3770, 4770k, 4790k, 5820k, con motherboard msi gigabyte asus ed asrock e con tutta sta trafila non mi sono mai trovato in un vortice del genere... ora come ben vedi la mia ultima cpu era il 5820k una delle ultime con ihs saldato... avevo preso amd perché seguiva questa politica e purtroppo sto tutt' ora passando le pene dell' inferno.. negli ultimi anni non avevo mai visto una cosa del genere..Il bug pregiudica il tuo utilizzo o no?

[KJx89]

in che senso pene dell'inferno ?

la mia CPU ha il bug ma onestamente ci faccio di tutto
office
web
musica
analisi ad elementi finiti
autocad
e qualche rendering

e non ho mai avuto problemi

certo mi secca avere una CPU con il Bug ma per il resto fila benissimo

Tu hai un post 25esima? Ricordo che la nuova CPU saliva molto bene.

Vengo dal 3770, 4770k, 4790k, 5820k, con motherboard msi gigabyte asus ed asrock e con tutta sta trafila non mi sono mai trovato in un vortice del genere... ora come ben vedi la mia ultima cpu era il 5820k una delle ultime con ihs saldato... avevo preso amd perché seguiva questa politica e purtroppo sto tutt' ora passando le pene dell' inferno.. negli ultimi anni non avevo mai visto una cosa del genere..

Guarda che io ci faccio di tutto e la tengo @4GHz...
Saluti
Kappa

[alexsky8]

Tu hai un post 25esima? Ricordo che la nuova CPU saliva molto bene.

sì settimana 33 e sale piuttosto bene
per ora lo tengo anche perchè non posso sostituirlo, ci penserò con ryzen 2

[SL45i]

Ci facevo tutto senza problemi... ma sono un po' paranoico, alla minima cosa strana pensavo al bug... ora per esempio non so se è la crosshair ad aver difetti oppure è a causa del bug che la motherboard si blocca sempre sul controllo ventole... di crosshair ne ho provate 3... come le cpu inoltre... tutte e tre col bug... È tutte le asus chi dopo pochi minuti chi dopo una mezza giornata mi sparavano le ventole al massimo... la prima motherboard si bloccava tutto d un tratto con il code 8 e mi sparava le ventole al 100x100... la seconda motherboard mi fermava dopo 10 minuti le ventole... l ultima motherboard mi fermava pure la pompa... possibile che mi siano capitate 3 motherboard difettose? Ho cambiato anche ventole e pompa per constatare incompatibilità ma tutto invano :( e la cosa brutta è che vorrei provare ancora una volta la fortuna con il ryzen 1700 :doh:

@dimenticavo... con tutto a default mi trovavo con la seconda e terza motherboard picchi di voltaggio ad 1.625v e su di li... Non mi sembrano comportamenti normali

[Nautilu$]

ti vendo il mio! :) Settimana 14 , esente dal bug! ;)

....a 890€ ! :D :Prrr:


...non ci voglio speculare , dai...... che passo a TR ! :D

[SL45i]

Minchia... ecco una cpu del genere come la tua a 3.8ghz con quel voltaggio mi darebbe tanta soddisfazione... :sofico:

Thread ripper è esente dal bug?

[Nautilu$]

mi pare che AMD stessa abbia confermato che non esistono TR con bug....


P.S.: la mia comunque non è particolarmente fortunata..... va benissimo fino a 3,8
ma già per 3,9 vuole 1,35V e le prestazioni non salgono neanche proporzionalmente ai 100Mhz in più...
i 3,95 stabili a fatica con 1,45V .... e i 4GHz utilizzabili li vede col binocolo! Neanche un Cinebench....

[evil weasel]

Potrebbe non centrare, ma sul PC con il Ryzen fallato i log del kernel venivano spammati da errori di questo genere:
[ 62.889870] ata1.00: failed command: WRITE FPDMA QUEUED
[ 62.889874] ata1.00: cmd 61/08:a8:70:f0:4a/00:00:0a:00:00/40 tag 21 ncq dma 4096 out
res 40/00:ac:70:f0:4a/00:00:0a:00:00/40 Emask 0x10 (ATA bus error)
[ 62.889876] ata1.00: status: { DRDY }
[ 62.889879] ata1: hard resetting link
[ 63.350082] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 63.350687] ata1.00: configured for UDMA/133
[ 63.350709] ata1: EH complete
A furia di andare avanti così dopo poco il disco veniva declassato a SATA 3 Gbit.
La cosa strana è che sia disco che il cavo SATA sono buoni.
Qualcuno di voi ha notato la stessa cosa?
Quando finalmente mi spediranno la CPU nuova farò dei test.

[Mister D]

Ci facevo tutto senza problemi... ma sono un po' paranoico, alla minima cosa strana pensavo al bug... ora per esempio non so se è la crosshair ad aver difetti oppure è a causa del bug che la motherboard si blocca sempre sul controllo ventole... di crosshair ne ho provate 3... come le cpu inoltre... tutte e tre col bug... È tutte le asus chi dopo pochi minuti chi dopo una mezza giornata mi sparavano le ventole al massimo... la prima motherboard si bloccava tutto d un tratto con il code 8 e mi sparava le ventole al 100x100... la seconda motherboard mi fermava dopo 10 minuti le ventole... l ultima motherboard mi fermava pure la pompa... possibile che mi siano capitate 3 motherboard difettose? Ho cambiato anche ventole e pompa per constatare incompatibilità ma tutto invano :( e la cosa brutta è che vorrei provare ancora una volta la fortuna con il ryzen 1700 :doh:

@dimenticavo... con tutto a default mi trovavo con la seconda e terza motherboard picchi di voltaggio ad 1.625v e su di li... Non mi sembrano comportamenti normali

I picchi sono fino a 1,525volt, il massimo con XFR attivo su 2 core. Solo che i software di monitoraggio non recepisco i continui cambi del precision boost e a te può sembrare di avere quel vcore su tutti i core.;)

[Operapia]

Non riesco a far partire stressapptest.
Qualche dritta please.

http://imageshack.com/a/img924/7967/5AnVMP.png

[alexsky8]

chi ha passato il test potrebbe scrivere che V soc ha ?

[s12a]

Non riesco a far partire stressapptest.
Qualche dritta please.

http://imageshack.com/a/img924/7967/5AnVMP.png

Avevo dato per scontato che fosse tutto già pronto come da Ubuntu WSL da Windows. Basta fare come segue:


Dal menu principale, cercare/digitare "software & updates":

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

Abilitare "universe" e poi cliccare "close", quindi "reload" quando lo chiede.

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

https://i.imgur.com/5rAkgfk.png

Ora si può installare con:

sudo apt-get install stressapptest

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




EDIT: è possibile che da Ubuntu live dia questo errore (od almeno, ho appena notato che succede in una virtual machine):

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

In tal caso oltre ai flag precedentemente suggeriti occorre specificare manualmente anche la quantità di memoria da testare con il flag -M n, dove n è il valore in megabyte.

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

[sgrinfia]

Ciao ragazzi, veramente non vi fatte paranoie , ho amici con Intel (non ricordo i modelli) che anno bug riconosciuti e mal grato ciò nella loro attività col pc non ci sono mai incappati . addirittura uno a un vecchio Amd phenom prima serie che a sentir lui avrebbe un grave bug ......ma lui ormai da anni che tiene la cpu non la mai riscontrato.

[s12a]

@sgrinfia: Il bug del segmentation fault lo hanno riscontrato principalmente coloro che effettuano compilazioni sotto Linux, e neanche così raramente. Non è ancora chiaro se report di problemi ad esempio hardware, crash o reboot che altri hanno in maniera specifica con AMD Ryzen sono correlati direttamente od indirettamente ad esso, anche se è alquanto possibile.

Non ho creato il thread con la finalità di lamentarmi od organizzare class action contro AMD; semplicemente per documentare e capire il problema che mi avrebbe potenzialmente riguardato per i miei ambiti d'uso, visto che ero inizialmente interessato ad acquistare un Ryzen 7 1700 (e sono sempre interessato, ma oramai aspetterò il prossimo refresh 12nm equivalente / R7 2700).

[sgrinfia]

@sgrinfia: Il bug del segmentation fault lo hanno riscontrato principalmente coloro che effettuano compilazioni sotto Linux, e neanche così raramente. Non è ancora chiaro se report di problemi ad esempio hardware, crash o reboot che altri hanno in maniera specifica con AMD Ryzen sono correlati direttamente od indirettamente ad esso, anche se è alquanto possibile.

Non ho creato il thread con la finalità di lamentarmi od organizzare class action contro AMD; semplicemente per documentare e capire il problema che mi avrebbe potenzialmente riguardato per i miei ambiti d'uso, visto che ero inizialmente interessato ad acquistare un Ryzen 7 1700 (e sono sempre interessato, ma oramai aspetterò il prossimo refresh 12nm equivalente / R7 2700).

Si quelloche affermi e giusto.
Però sembra che il bug della cpu sia stato risolto con un cambio con una cpu senza bug da parte di Amd .........quindi sembra fare la guerra ai mulini.

[s12a]

C'è chi la CPU non può o non vuole cambiarla facendo RMA o chi semplicemente è interessato agli aspetti tecnici della questione, dunque non è che visto che AMD offre la possibilità di sostituirla in garanzia allora non bisogna parlarne (attenzione poi che fino a qualche tempo fa la spedizione ad AMD era a carico dell'utente - per gli ultimi casi sembra che sia tutto prepagato).

Se dobbiamo metterla dal punto di vista de "il thread non è necessario, tanto AMD sostituisce gratuitamente", non posso fare altro che far presente che è più che giusto esigere che la CPU funzioni come debba al momento dell'acquisto, non 2-3 settimane dopo l'eventuale richiesta di sostituzione.

[sinergine]

Vero ciò che dici, ma la garanzia serve per questo. Se dovessero testare tutte le cpu prima di venderle costerebbero il doppio.

La cosa che mi da più da pensare è che non abbiano rilasciato un comunicato sulla faccenda

[sgrinfia]

s12a , e giusto parlarne per carità, ma se uno scopre che la sua cpu e bugata e non vuole cambiarla ...bè e un problema suo , visto che Amd la sostituisce .
Giusto anche che sia Amd a farsi carico delle spese di cambio cpu , visto che è un problema nativo.
Esigere che la CPU funzioni ....questo e il minimi visto che non è gratis , ma non penso che Amd l'abbia fatto a posta , e dopo tutto sta risolvendo la cosa.
Io non voglio metterla dal punto di vista de "il thread non è necessario, tanto AMD sostituisce gratuitamente", però quello che si doveva scrivere si è scritto ....tutto il resto poi è una cosa già detta.

[s12a]

Lo metto subito in chiaro qui come peraltro l'ho già fatto presente nell'altro thread prima di essere stato "cacciato via": più gente arriverà qui a fare intendere fra le righe che è meglio smetterla di discuterne perché "roba passata" (non lo è), più farò in modo che il thread avrà evidenza.

[sgrinfia]

Quello che voglio dire è che il problema non esiste piu visto che quelle difettose vengono sostituite , e che in prima pagina ce una chiaira descrizione del problema e la soluzione allo stesso.

[s12a]

Nel caso fosse necessario ripeterlo esplicitamente:


È possibile ancora oggi acquistare CPU di vecchia produzione che lo manifestano? Sì.
Si sa se le ultimissime CPU prodotte ne siano esenti o se lo saranno le future? No.
È chiaro quali possano essere altri ambiti o forme in cui potrebbe manifestarsi? No.
Ne è stata totalmente compresa la natura? No.
Sono stati rilasciati comunicati ufficiali da AMD a riguardo? No.
È argomento gradito nel "Thread Ufficiale Ryzen" in sezione? No.

Di incognite e dubbi ne rimangono ancora. Questi, oltre al mutuale supporto fra gli utenti interessati o potenzialmente tali, sono alcuni degli altri motivi per i quali questo thread esiste ed ha una sua funzione, se stai sottointendendo che si potrebbe anche chiudere e magari lasciare in evidenza per un certo periodo.

Il problema sarebbe considerabile non più esistente e la questione chiusa se non fosse più possibile acquistare CPU affette, oppure se un aggiornamento AGESA (https://en.wikipedia.org/wiki/AGESA)/BIOS lo risolvesse in maniera definitiva. Non penso che nessuno oggi si lamenti del fatto che con i BIOS disponibili al lancio non fosse assolutamente possibile usare le memorie oltre una certa frequenza...

(benché un supporto ufficiale non-overclock a frequenze superiori sia ben gradito; magari per Ryzen+)

[KJx89]

Lo metto subito in chiaro qui come peraltro l'ho già fatto presente nell'altro thread prima di essere stato "cacciato via": più gente arriverà qui a fare intendere fra le righe che è meglio smetterla di discuterne perché "roba passata" (non lo è), più farò in modo che il thread avrà evidenza.

Io ti ringrazio per il thread, a Novembre mi metterò anche io a testare e vedere se è il caso di fare la procedura e questo thread mi sarà sicuramente utile :)
Saluti
Kappa

[Mister D]

Nel caso fosse necessario ripeterlo esplicitamente:


È possibile ancora oggi acquistare CPU di vecchia produzione che lo manifestano? Sì.
Si sa se le ultimissime CPU prodotte ne siano esenti o se lo saranno le future? No.
È chiaro quali possano essere altri ambiti o forme in cui potrebbe manifestarsi? No.
Ne è stata totalmente compresa la natura? No.
Sono stati rilasciati comunicati ufficiali da AMD a riguardo? No.
È argomento gradito nel "Thread Ufficiale Ryzen" in sezione? No.

Di incognite e dubbi ne rimangono ancora. Questi, oltre al mutuale supporto fra gli utenti interessati o potenzialmente tali, sono alcuni degli altri motivi per i quali questo thread esiste ed ha una sua funzione, se stai sottointendendo che si potrebbe anche chiudere e magari lasciare in evidenza per un certo periodo.

Il problema sarebbe considerabile non più esistente e la questione chiusa se non fosse più possibile acquistare CPU affette, oppure se un aggiornamento AGESA (https://en.wikipedia.org/wiki/AGESA)/BIOS lo risolvesse in maniera definitiva. Non penso che nessuno oggi si lamenti del fatto che con i BIOS disponibili al lancio non fosse assolutamente possibile usare le memorie oltre una certa frequenza...

(benché un supporto ufficiale non-overclock a frequenze superiori sia ben gradito; magari per Ryzen+)

Ciao,
scusami tanto ma la seconda risposta è sbagliata. AMD ha dichiarato a phoronix di aver cambiato il test qualitativo di selezione per togliere il bug da tutte le cpu da una data in poi. Che poi questa data non sia stata dichiarata è un altro problema. Ma se già non si crede nemmeno a cosa scrive il maggior sito per linux con tanto di info riportate in via ufficiosa, a cosa dovremmo credere? Fino a prova contraria le parole del produttore, anche se in vai ufficiosa, devono avere un peso. Altrimenti smettiamo di comprare qualsiasi cosa perché sappiamo già che ci stanno mentendo e quindi fregando. E sottolineo che non è per difendere AMD, ma tutti i produttori.
Poi ultimissime per te cosa vuol dire? Io ho ipotizzato, con ragionamento logico deduttivo, che tutte le cpu prodotte da settembre in poi siano esenti (settimana 36) e per ora non mi pare che sia venuta fuori una cpu settimana >/= 36 con il problema. Se e quando ne avremo almeno una allora la mia ipotesi sarà scartata.

Poi ancora la questione AGESA/BIOS. Ma cosa non ti è chiaro che se NON tutte le cpu hanno il bug, il problema NON è aggirabile via AGESA/BIOS.
Se tutte le cpu erano affette, TUTTE, come per es con il bug sulla TLC nei phenom, allora sì che era aggirabile via workaround via aggiornamento bios e poi eliminato totalmente via nuovo step cpu (mi pare fosse da B2 a B3).
Ma in questo, essendo che non tutte le cpu mostrano (hanno mostrato il problema), perché AMD avrebbe dovuto azzoppare pure le sane????
Almeno una percentuale delle 95% dei die utilizzati per ryzen step B1 SONO esenti dal problema. Per questo AMD ha deciso di non aggiornare AGESA/BIOS. Boh, mi pareva fosse una fatto assodato questo.

NON vi aspettate nessun aggiornamento via bios per togliere il problema sulle cpu prodotte prima del cambio test.

Per il fatto invece di mantenere il thread non solo aperto e in evidenza, ma costantemente aggiornato sono d'accordo con te perché è purtroppo ancora probabile acquistare una cpu prodotta prima del cambio test e questa ha una X probabilità di essere affetta dal bug. Per cui sarebbe sbagliato chiudere il thread adesso.;)

[alexsky8]

chi ha passato il test potrebbe scrivere che V soc ha ?

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

sono spariti tutti ? :D

[s12a]

Ciao,
scusami tanto ma la seconda risposta è sbagliata. AMD ha dichiarato a phoronix di aver cambiato il test qualitativo di selezione per togliere il bug da tutte le cpu da una data in poi. Che poi questa data non sia stata dichiarata e altro problema. Ma se già non si crede nemmeno a cosa scrive il maggior sito per linux con tanto di info riportate in via ufficiosa, a cosa dovremmo credere?
Non si può fare altro che verificare nella pratica con le CPU acquistate dagli utenti. Per il momento sappiamo che il bug esiste anche con le CPU prodotte nella settimana 34 (http://www.hwupgrade.it/forum/showpost.php?p=45127973&postcount=534). Si pensava (in base agli RMA, iniziati qualche tempo dopo la constatazione ufficiosa dell'inconveniente a Phoronix) che inizialmente la soglia fosse la 25, ossia che già due mesi prima abbondanti fosse stato già risolto. Quanto potrebbe mai volerci ancora?

Poi ultimissime per te cosa vuol dire? Io ho ipotizzato, con ragionamento logico deduttivo, che tutte le cpu prodotte da settembre in poi siano esenti (settimana 36) e per ora non mi pare che sia venuta fuori una cpu settimana >/= 36 con il problema. Se e quando ne avremo almeno una allora la mia ipotesi sarà scartata.
Non ho purtroppo ancora avuto modo di leggere report positivi o negativi con CPU prodotte da metà Settembre in poi. Per "ultimissime" intendo nel corso di Ottobre.

Poi ancora la questione AGESA/BIOS. Ma cosa non ti è chiaro che se NON tutte le cpu hanno il bug, il problema NON è aggirabile via AGESA/BIOS.
Se tutte le cpu erano affette, TUTTE, come per es con il bug sulla TLC nei phenom, allora sì che era aggirabile via workaround via aggiornamento bios e poi eliminato totalmente via nuovo step cpu (mi pare fosse da B2 a B3).
Ma in questo, essendo che non tutte le cpu mostrano (hanno mostrato il problema), perché AMD avrebbe dovuto azzoppare pure le sane????
Almeno una percentuale delle 95% dei die utilizzati per ryzen step B1 SONO esenti dal problema. Per questo AMD ha deciso di non aggiornare AGESA/BIOS. Boh, mi pareva fosse una fatto assodato questo.
La percentuale esatta non è nota, ma molti di coloro che provano il test sembrano riportare segfault. Potrebbe essere una coincidenza ma anche sintomo del fatto che in realtà sia il bug più diffuso di quanto sia stato suggerito in passato. Suppongo anche io che correggerlo per tutti via BIOS effettivamente comporterebbe una perdita prestazionale da qualche parte (es. velocità massima ufficialmente supportata delle memorie), ma se uscisse fuori che una grossa percentuale delle CPU prodotte potrebbe in condizioni specifiche averlo sarebbe comunque giusto lasciare tutto com'è ora? Immagino che lo sarebbe per chi non riporta problemi di sorta; a nessuno piacerebbe osservare prestazioni inferiori dopo un aggiornamento.

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.
Quando avevo chiesto delucidazioni e provato a discutere a riguardo nell'altro thread, essendo interessato all'acquisto, mi era stato detto e ripetuto che il bug era roba vecchia, che era già stato tutto risolto e che non sarebbe stato più possibile oramai acquistare CPU affette. Dopo essermi informato accuratamente in merito ho constatato che non era veramente così, e con le informazioni collezionate in giro ho aperto un nuovo thread.

Perché non farlo, dato che le informazioni a riguardo nel thread ufficiale erano precedentemente errate od incomplete nel migliore dei casi?

[Nautilu$]

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

sono spariti tutti ? :D

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

[s12a]

Potrebbe non centrare, ma sul PC con il Ryzen fallato i log del kernel venivano spammati da errori di questo genere:
[ 62.889870] ata1.00: failed command: WRITE FPDMA QUEUED
[ 62.889874] ata1.00: cmd 61/08:a8:70:f0:4a/00:00:0a:00:00/40 tag 21 ncq dma 4096 out
res 40/00:ac:70:f0:4a/00:00:0a:00:00/40 Emask 0x10 (ATA bus error)
[ 62.889876] ata1.00: status: { DRDY }
[ 62.889879] ata1: hard resetting link
[ 63.350082] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 63.350687] ata1.00: configured for UDMA/133
[ 63.350709] ata1: EH complete
A furia di andare avanti così dopo poco il disco veniva declassato a SATA 3 Gbit.
La cosa strana è che sia disco che il cavo SATA sono buoni.
Qualcuno di voi ha notato la stessa cosa?
Quando finalmente mi spediranno la CPU nuova farò dei test.

A proposito, dato che i processori AMD Ryzen sono dei SoC che integrano oltre a memory controller anche controller USB, SATA e PCIe (https://www.pcworld.com/article/3124306/hardware/dont-call-amds-upcoming-zen-chip-a-cpu.html), 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 (https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr?p=980443#post980443), 2 (https://github.com/ClusterM/hakchi2/issues/620)).

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

[evil weasel]

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

sono spariti tutti ? :D

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

A proposito, dato che i processori AMD Ryzen sono dei SoC che integrano oltre a memory controller anche controller USB, SATA e PCIe (https://www.pcworld.com/article/3124306/hardware/dont-call-amds-upcoming-zen-chip-a-cpu.html), 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 (https://www.phoronix.com/forums/forum/phoronix/general-discussion/967913-amd-confirms-linux-performance-marginality-problem-affecting-some-doesn-t-affect-epyc-tr?p=980443#post980443), 2 (https://github.com/ClusterM/hakchi2/issues/620)).

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]

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 :nonsifa: :rotfl:

PS. Sono ironico ovviamente ;)

[Nui_Mg]

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]

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

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]

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]

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]

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.

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]

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]

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.

https://i.imgur.com/2DpYAKu.png

Dal punto di vista software Randa71 qui nel thread (http://www.hwupgrade.it/forum/showpost.php?p=45131170&postcount=567) 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]

.....

Dal punto di vista software Randa71 qui nel thread (http://www.hwupgrade.it/forum/showpost.php?p=45131170&postcount=567) 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/1710125-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]

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/gimps/p95v293.linux64.tar.gz

https://community.amd.com/message/2825959#comment-2825959#2825959 (commento #1686)
https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dog8vkx/?st=j918p4ti&sh=39e8bad6

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/showpost.php?p=45132807&postcount=582


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

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]

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]

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]

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/2803469#comment-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]

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.

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]

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

[Mister D]

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]

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]

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]

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]

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]

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]

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/1710125-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]

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]

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?page=news_item&px=Ryzen-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.

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]

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]

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

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/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/280_40#post_26340773
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/280_40#post_26340815

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/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/120_40#post_26309166
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/120_40#post_26309685
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/120_40#post_26309710
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26309865
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26309906
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26310236
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26311041
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26311055
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26311109
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/160_40#post_26311149
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/200_40#post_26312017
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/200_40#post_26312035
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/200_40#post_26312272
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/200_40#post_26312286
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/200_40#post_26314315
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/240_40#post_26316194
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/280_40#post_26340851
http://www.overclock.net/t/1635749/phoronix-segmentation-faults-on-zen-cpus-under-heavy-workloads/280_40#post_26353608

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]

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]

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

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]

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]

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/E36387/html/ol_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...

[KJx89]

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 ?

Ti hanno richiesto la ricevuta di acquisto? Perché io ho il 1800X boxed, ma senza ricevuta...
Saluti
Kappa

[alexsky8]

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.

come scritto da Randa71 una CPU a default non deve generare alcun errore al massimo lo potrà fare in OC ma non certo a default quindi lascia tutto come da fabbrica e fai il test
se modifichi il Vsoc o altri parametri varia il risultato su questo non ci piove
come già scritto la mia CPU a 1,1Vsoc non genera errore mentre a 1,06V sì così come disabilitando SMT non genera errore mentre abilitandolo lo genera

quindi alla fine la cpu ha il bug tutto il resto sono solo prove fatte da noi ma che nulla hanno a che vedere con la normalità del test

[Randa71]

riprovato adesso un'altra volta il kill ryzen senza ASLR..stoppato io dopo 40 minuti...nessun errore...Considero la questione chiusa...dopo tre gg di prove con ASLR=0 0 errori.
sono solo curioso che quelli a cui viene fuori errore nonostante abbiano ASLR disattivato se montassero le mie stesse RAM con la C6H bios 1701 ram impostate con il profilo XMP se errore viene fuori ancora...semplice curiosità...
nel caso io ho sopra le Kingston HyperX KHX2400C15/16G due banchi da 8...
Adesso me lo godo senza ansie :) ;) ;) che già quando l'ho presa la piattaforma le madonne che non sono scese quando non si accendeva neanche causa corsair 2400.....mamma mia che incazzatura..mi sembrava di essere tornato indietro di 10 anni...
ciao

[Mister D]

riprovato adesso un'altra volta il kill ryzen senza ASLR..stoppato io dopo 40 minuti...nessun errore...Considero la questione chiusa...dopo tre gg di prove con ASLR=0 0 errori.
sono solo curioso che quelli a cui viene fuori errore nonostante abbiano ASLR disattivato se montassero le mie stesse RAM con la C6H bios 1701 ram impostate con il profilo XMP se errore viene fuori ancora...semplice curiosità...
nel caso io ho sopra le Kingston HyperX KHX2400C15/16G due banchi da 8...
Adesso me lo godo senza ansie :) ;) ;) che già quando l'ho presa la piattaforma le madonne che non sono scese quando non si accendeva neanche causa corsair 2400.....mamma mia che incazzatura..mi sembrava di essere tornato indietro di 10 anni...
ciao

Scusami randa,
ma sono queste:
https://www.kingston.com/datasheets/HX424C15FBK2_16.pdf
JEDEC/XMP TIMING PARAMETERS
• JEDEC/PnP: DDR4-2400 CL15-15-15 @1.2V
DDR4-2133 CL14-14-14 @1.2V
•XMP Profile #1: DDR4-2400 CL15-15-15 @1.2V

Se le metti su auto non ti imposta da solo il profilo JEDEC 2400?;)

[Randa71]

Scusami randa,
ma sono queste:
https://www.kingston.com/datasheets/HX424C15FBK2_16.pdf
JEDEC/XMP TIMING PARAMETERS
• JEDEC/PnP: DDR4-2400 CL15-15-15 @1.2V
DDR4-2133 CL14-14-14 @1.2V
•XMP Profile #1: DDR4-2400 CL15-15-15 @1.2V

Se le metti su auto non ti imposta da solo il profilo JEDEC 2400?;)

yess sono queste...se imposto il profilo su auto non carica il DOCP automaticamente ma le imposta s con il profilo Jedec a 2400 a 15 15 15 36 56 il DOCP è 15 15 15 35 57
ma la cosa peggiore è che imposta il voltaggio delle ram a 1.35...mentre quelle sono a 1.20....
invece impostandole su docp standard carica tutti i valori...voltaggi compresi...poi io che sono un perfezionista :D :D :D imposto manualmente il valore a 57...in auto o docp lo imposta a 56...
fai conto che prima dei bios 1701 su docp standard non era stabile...freeze della CPU anche in windows con codice errore 08...e non era stabile a 2400 neanche su auto....con il 1701 un gioiellino..ovviamente le ram sono esattamente le stesse
per quello che "insisto" sul discorso ram... :)
PS: so che il profilo docp/xmp è per gli IMC di intel....però cosi si carica tutto automaticamente, e funziona! preferisco così

[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?
:help:

[Mister D]

yess sono queste...se imposto il profilo su auto non carica il DOCP automaticamente ma le imposta si a 2400 ma a 15 15 15 36 56 il DOCP è 15 15 15 35 57
ma la cosa peggiore è che imposta il voltaggio delle ram a 1.35...mentre quelle sono a 1.20....
invece impostandole su docp standard carica tutti i valori...voltaggi compresi...poi io che sono un perfezionista :D :D :D imposto manualmente il valore a 57...in auto o docp lo imposta a 56...
fai conto che prima dei bios 1701 su docp standard non era stabile...freeze della CPU anche in windows...con il 1701 un gioiellino..
per quello che "insisto" sul discorso ram... :)

Per forza che non era stabile. DOCP è una "mandracata" di asus per impostare il profilo XMP nato per intel, su mc amd. E infatti modifica a seconda del kit ram dei valori rispetto lo stesso profilo XMP memorizzato nel chip SPD della ram.

Per il TRC la regolina aurea è di non scendere mai sotto tRP+tRAS ergo nel tuo caso 15+35=51. Quindi da dove tiri fuori il 57? Anzi a dirla tutta, colonna e destra del datasheet:

Row Cycle Time (tRCmin) 46,75 ns (mini)

Se usi la regoletta inversa per ottenere la latenza in cicli di clock viene esattamente 56:
1200/1000*46,75= 56,1 clk che direi che è esattamente il 56 che ti imposta sia in auto quando ti carica il profilo JEDEC std o quando gli dici di caricarti il profilo XMP. Purtroppo il datasheet non riporta tutti i timing secondari ergo dovresti usare taiphoon burner per capire in cosa differisce il profilo JEDEC 2400 da quello XMP.
Io comunque ti consiglio di non usare XMP ma ti usare profilo JEDEC (se mai modificando la tensione ram 1,2 volt giustamente. Ed è veramente starano che ti imposti così ma da asus questo e altro per il rispetto degli std :D )

EDIT: ho letto dopo il tuo edit. OK in effetti se tutto ti funziona lascia pur così

[metal master]

:help:

se ci sono eventuali problemi con la cpu, contatti direttamente amd tramite questo link: https://support.amd.com/en-us/warranty/rma

dopo averlo compilato, inserito il seriale della cpu e descritto il problema sarai contattato da un responsabile tecnico e dopo alcune verifiche se ci sono problemi ti apriranno un rma e ti daranno istruzioni per l'invio del pacco al centro raccolta amd.

a loro consegnerai solo la cpu nel blister di plastica senza ventola e scatolo originale.
una volta che la cpu raggiunge il centro di raccolta, dopo verifiche visive e meccaniche ti viene mandata una nuova cpu.
la garanzia amd è di 36 mesi per cpu boxate.

[Randa71]

Per forza che non era stabile. DOCP è una "mandracata" di asus per impostare il profilo XMP nato per intel, su mc amd. E infatti modifica a seconda del kit ram dei valori rispetto lo stesso profilo XMP memorizzato nel chip SPD della ram.

Per il TRC la regolina aurea è di non scendere mai sotto tRP+tRAS ergo nel tuo caso 15+35=51. Quindi da dove tiri fuori il 57? Anzi a dirla tutta, colonna e destra del datasheet:

Row Cycle Time (tRCmin) 46,75 ns (mini)

Se usi la regoletta inversa per ottenere la latenza in cicli di clock viene esattamente 56:
1200/1000*46,75= 56,1 clk che direi che è esattamente il 56 che ti imposta sia in auto quando ti carica il profilo JEDEC std o quando gli dici di caricarti il profilo XMP. Purtroppo il datasheet non riporta tutti i timing secondari ergo dovresti usare taiphoon burner per capire in cosa differisce il profilo JEDEC 2400 da quello XMP.
Io comunque ti consiglio di non usare XMP ma ti usare profilo JEDEC (se mai modificando la tensione ram 1,2 volt giustamente. Ed è veramente starano che ti imposti così ma da asus questo e altro per il rispetto degli std :D )

EDIT: ho letto dopo il tuo edit. OK in effetti se tutto ti funziona lascia pur così

il valore 57 è nel profilo xmp delle ram. letto sia da cpuz che da aida che dalla scheda madre nei bios...cmq grazie per la formuletta...non la conoscevo :) :):)

[Kernel32]

se ci sono eventuali problemi con la cpu, contatti direttamente amd tramite questo link: https://support.amd.com/en-us/warranty/rma

dopo averlo compilato, inserito il seriale della cpu e descritto il problema sarai contattato da un responsabile tecnico e dopo alcune verifiche se ci sono problemi ti apriranno un rma e ti daranno istruzioni per l'invio del pacco al centro raccolta amd.

a loro consegnerai solo la cpu nel blister di plastica senza ventola e scatolo originale.
una volta che la cpu raggiunge il centro di raccolta, dopo verifiche visive e meccaniche ti viene mandata una nuova cpu.
la garanzia amd è di 36 mesi per cpu boxate.

Quindi mi confermi che non serve lo scontrino/fattura. Grazie, gentilissimo... E gran bel nick http://www.punkinfinland.net/forum/images/smilies/metal.gif

[metal master]

Quindi mi confermi che non serve lo scontrino/fattura. Grazie, gentilissimo... E gran bel nick http://www.punkinfinland.net/forum/images/smilies/metal.gif

a me non l'hanno chiesto/a

[KJx89]

se ci sono eventuali problemi con la cpu, contatti direttamente amd tramite questo link: https://support.amd.com/en-us/warranty/rma

dopo averlo compilato, inserito il seriale della cpu e descritto il problema sarai contattato da un responsabile tecnico e dopo alcune verifiche se ci sono problemi ti apriranno un rma e ti daranno istruzioni per l'invio del pacco al centro raccolta amd.

a loro consegnerai solo la cpu nel blister di plastica senza ventola e scatolo originale.
una volta che la cpu raggiunge il centro di raccolta, dopo verifiche visive e meccaniche ti viene mandata una nuova cpu.
la garanzia amd è di 36 mesi per cpu boxate.

Grazie, hai risposto anche a me, sono tranquillo allora :cincin:
Saluti
Kappa

[Operapia]

Finalmente ho fatto il test con il v core a 1.1. Lasciando le frequenze a 2667 non cambia il risultato purtroppo.

http://imageshack.com/a/img923/2408/E7s2df.png
http://imageshack.com/a/img924/7895/pw8pL1.png

Tra qualche settimana mi arrivano delle memorie nuove 2x8 e faro' altri test anche con vsoc a 1.15 e il vcore a 1.35, oltre non vado. Se anche cosi' mi fara' problemi penso che andro' di rma.
A proposito, che roba è l'ASLR e come lo trovo sulla mia mobo?

[Randa71]

Finalmente ho fatto il test con il v core a 1.1. Lasciando le frequenze a 2667 non cambia il risultato purtroppo.

http://imageshack.com/a/img923/2408/E7s2df.png
http://imageshack.com/a/img924/7895/pw8pL1.png

Tra qualche settimana mi arrivano delle memorie nuove 2x8 e faro' altri test anche con vsoc a 1.15 e il vcore a 1.35, oltre non vado. Se anche cosi' mi fara' problemi penso che andro' di rma.
A proposito, che roba è l'ASLR e come lo trovo sulla mia mobo?

https://it.wikipedia.org/wiki/ASLR
https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/
Google aiuta
non disattivarlo se c'è opzione dalla scheda madre...
disattivalo in Linux con questo comando:
sudo sysctl -w kernel.randomize_va_space=0
così è disabilitato
in Windows non è più utilizzato da Win8 in poi

[il_dottorino]

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.


Ah non lo sapevo... ho stoppato prima del previsto perchè pensato fosse bloccato. Dovrò eseguire nuovamente il test. Però almeno potevano mandare una cpu tra la 35esima e la 40esima:mad:

[Operapia]

https://it.wikipedia.org/wiki/ASLR
https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/
Google aiuta
non disattivarlo se c'è opzione dalla scheda madre...
disattivalo in Linux con questo comando:
sudo sysctl -w kernel.randomize_va_space=0
così è disabilitato
in Windows non è più utilizzato da Win8 in poi

Non ho cercato su google perchè credevo fosse una cosa complicata, come quando non mi funzionava il test sotto ubuntu e ci sono impazzito dietro una serata googolando senza concludere nulla. Fu poi il creatore della discussione a spiegarmi passo passo come fare.
Grazie per il tempo che mi hai dedicato.

[evil weasel]

Tornato il 1700x da RMA, questa sembra buona, non riesco a riprodurre i segfault.
Settimana 41, made in china.
Tra l'altro si clocca da paura, sto facendo prime95 versione 29.3 su Linux a 40x GHz con VCORE 1.33 volt.

I problemi con il disco che avevo riportato in questo post (http://www.hwupgrade.it/forum/showthread.php?p=45132966#post45132966) continuano ad esserci, non dipende dalla CPU a questo punto.

[Mister D]

Tornato il 1700x da RMA, questa sembra buona, non riesco a riprodurre i segfault.
Settimana 41, made in china.
Tra l'altro si clocca da paura, sto facendo prime95 versione 29.3 su Linux a 40x GHz con VCORE 1.33 volt.

I problemi con il disco che avevo riportato in questo post (http://www.hwupgrade.it/forum/showthread.php?p=45132966#post45132966) continuano ad esserci, non dipende dalla CPU a questo punto.

Orca, settimana 41 è proprio di 2 settimane fa:D Una bella chiapetta:oink:

[evil weasel]

Orca, settimana 41 è proprio di 2 settimane fa:D Una bella chiapetta:oink:

Bilancia con tutte le volte in cui mi è andata male ed ho dovuto comprare 2 o 3 di CPU prima di beccarne una buona. :D

[evil weasel]

Arrivata ora cpu da RMA, settimana 33 (:cry:) SUS.
Ho avviato kill-ryzen, gli faccio fare un 20 minuti senza settaggi ed altri 20 in 4-4.

Non fasciarti la testa prima di rompertela, mi pare che ci sia solo un caso verificato di CPU tornata da RMA difettosa.
Sarebbe proprio il colmo della sfiga.

[Mister D]

Bilancia con tutte le volte in cui mi è andata male ed ho dovuto comprare 2 o 3 di CPU prima di beccarne una buona. :D

:sofico: e ora goditela per bene con n compilazioni dove n tende a infinito :ciapet: :ciapet: :Prrr:

[evil weasel]

Per ora ha superato senza 40 minuti di test, sembra buona :D
Da bios viene settata a 1.03v a default, quella di prima si prendeva 1.2 :o, promette bene in oc.

La mia è un'altra CPU, a parità di VCORE ho preso più di 200 MHz, ed il tutto senza segfault vari.

[evil weasel]

:sofico: e ora goditela per bene con n compilazioni dove n tende a infinito :ciapet: :ciapet: :Prrr:

Io non mi sono mai lamentato in maniera strumentale, per me i segfault sono un problema reale e tangibile.
Non sono mai stato un hater e sono sempre stato un ottimo cliente AMD, anche nei periodi bui con Bulldozer.
Nell'armadio ho ancora questo:

https://i.imgur.com/XQ5Dr4a.jpg

:D

[Mister D]

Io non mi sono mai lamentato in maniera strumentale, per me i segfault sono un problema reale e tangibile.
Non sono mai stato un hater e sono sempre stato un ottimo cliente AMD, anche nei periodi bui con Bulldozer.
Nell'armadio ho ancora questo:

cut...

:D

La mia era un battuta, se non si fosse capita. Il fatto che per te sia un problema reale e tangibile non lo metto in dubbio come per molti qui. Il problema, come sempre, è nel voler strumentalizzare la cosa per tirare cacchina su AMD. E non ne capisco proprio il motivo, sinceramente.
Cmq ti sto scrivendo dal fratellone maggiore del tuo FX (veri FX): FX-60 occato dal primo giorno. Ma non l'ho mai voluto delliddare. Alla fine mi ha fatto ad aria i 3,1 su DFI con un IFX14 (e tre ventole :D ) e i 2,8 su asrock (con 790gx).
Quelli erano altri tempi, dove veramente l'oc aveva il suo peso;)

[evil weasel]

La mia era un battuta, se non si fosse capita. Il fatto che per te sia un problema reale e tangibile non lo metto in dubbio come per molti qui. Il problema, come sempre, è nel voler strumentalizzare la cosa per tirare cacchina su AMD. E non ne capisco proprio il motivo, sinceramente.
Cmq ti sto scrivendo dal fratellone maggiore del tuo FX (veri FX): FX-60 occato dal primo giorno. Ma non l'ho mai voluto delliddare. Alla fine mi ha fatto ad aria i 3,1 su DFI con un IFX14 (e tre ventole :D ) e i 2,8 su asrock (con 790gx).
Quelli erano altri tempi, dove veramente l'oc aveva il suo peso;)

FX-60 mi è sempre piaciuto, poi però Intel si è messa di mezzo con i C2D Conroe. :D

[sinergine]

Per ora ha superato in tranquillitá 40 minuti di test, sembra buona :D
Da bios viene settata a 1.03v a default, quella di prima si prendeva 1.2 :o, promette bene in oc.

Dove vedete il voltaggi di default?

[animeserie]

La mia era un battuta, se non si fosse capita. Il fatto che per te sia un problema reale e tangibile non lo metto in dubbio come per molti qui. Il problema, come sempre, è nel voler strumentalizzare la cosa per tirare cacchina su AMD. E non ne capisco proprio il motivo, sinceramente.



Se è sbagliato strumentalizzare la cosa per tirare cacca su AMD è altrettanto sbagliato minimizzare ad ogni costo il problema (che esiste, non ce lo siamo inventati noi) come decine e decine di fanboys stanno facendo.
Concordi con me vero ?
In questo thread si doveva discutere del problema (e delle soluzioni) a livello tecnico, ma in realtà abbiamo assistito per la maggiore alla solita guerra tra Haters e Fanboys.

[SL45i]

Non ti ha obbligato nessuno a diventare un martire comprando un processore di serie b come ryzen, intel è felicissima di venderti una bella cpu che arriva a 90C e di regalarti le gioia di deliddare.


Ryzen non lo reputo assolutamente una cpu di serie b... ma un'ottima alternativa ai più costosi Intel... ed adoro anche il fatto che abbiano l'ihs saldato... inoltre odio il delid... sono ancora tentato nel prendere Ryzen 1700... e rischiarmela ancora... non sono un malato che si affeziona ad un marchio.

[alexsky8]

Per ora ha superato in tranquillitá 40 minuti di test, sembra buona :D
Da bios viene settata a 1.03v a default, quella di prima si prendeva 1.2 :o, promette bene in oc.

la mia vecchia prendeva 1,1875V quella nuova 1,008V entrambe buggate :sofico:

https://i.imgur.com/asN4e7a.jpg

Dove vedete il voltaggi di default?

da bios si leggono tutti i parametri

[Mister D]

Se è sbagliato strumentalizzare la cosa per tirare cacca su AMD è altrettanto sbagliato minimizzare ad ogni costo il problema (che esiste, non ce lo siamo inventati noi) come decine e decine di fanboys stanno facendo.
Concordi con me vero ?
In questo thread si doveva discutere del problema (e delle soluzioni) a livello tecnico, ma in realtà abbiamo assistito per la maggiore alla solita guerra tra Haters e Fanboys.

Certo che concordo, ma venire a dire, come qualcuno ha fatto, che sono stati costretti ad aprire un thread perché altrimenti nel thread ufficiale gli veniva preclusa la possibilità sacrosanta di parlare del problema, è una grandissima cavolata.
Se l'intento fosse quello di certo non avrebbero consigliato di aprire altro thread con soggetto il problema stesso e consigliare di farlo mettere pure in evidenza nelle sezione dal moderatore (mancante purtroppo).

Io come altri non abbiamo nascosto niente e anzi aiutato, ognuno per quello che può, a dipanare i dubbi. E come altri, sono dell'idea che non solo sia stato meglio aprire un thread apposito ma che sia giusto tenerlo aggiornato e in evidenza fino a che non ci siamo tolti il dubbio che ogni cpu venduta sia esente da problema e cmq tenerlo su anche dopo di certo non fa male, visto che fa parte della "memoria storica". Sono sempre stato uno a favore della massima trasparenza e del rispetto delle idee diverse altrui senza dover essere di parte o fanboy.
Che poi sono sempre stato fan di amd nel senso buono del termine ma non per questo NON la critico quando trovo giusto farlo. Si può essere fan di qualsiasi cosa senza avere il prosciutto sugli occhi, imho.

[Mister D]

FX-60 mi è sempre piaciuto, poi però Intel si è messa di mezzo con i C2D Conroe. :D

Yes. Q6600 cpu preferita come pure il 2600k. Non sono uno che per amore di una marca nega l'evidenza;)

[Debern9093]

Ragazzi scusate... AMD mi ha mandato una mail che dice che ho superato il test rma e che mi inviavano un'altra mail con il codice tracking.. Ma dal 30 che ho superato l'rma ad oggi che è 2 non mi è ancora arrivata nessun email

[nicolarush]

Ragazzi scusate... AMD mi ha mandato una mail che dice che ho superato il test rma e che mi inviavano un'altra mail con il codice tracking.. Ma dal 30 che ho superato l'rma ad oggi che è 2 non mi è ancora arrivata nessun email

in molti paesi questi sono giorni di festa, abbi pazienza (e controlla lo spam magari l'email è finita lì)

[il_dottorino]

a me ad esempio hanno mandato la cpu di sostituzione senza alcuna email di tracking

[jam71]

Ragazzi scusate... AMD mi ha mandato una mail che dice che ho superato il test rma e che mi inviavano un'altra mail con il codice tracking.. Ma dal 30 che ho superato l'rma ad oggi che è 2 non mi è ancora arrivata nessun email

In che cosa consisterebbe questo test rma?

[Debern9093]

In che cosa consisterebbe questo test rma?

Prima di spedirtene uno nuovo testano il tuo x verificare l'effettivo problema di cui è afflitta la tua cpu

[evil weasel]

a me ad esempio hanno mandato la cpu di sostituzione senza alcuna email di tracking

Stessa cosa anche qui, non hanno mandato nessuna email con il tracking.

[fedexx2]

Anche a me dopo la mail riguardante il test superato (del 30\10) non ho ricevuto altro,
ma con mia sorpresa ieri è arrivata la nuova CPU :D

Alla fine è stato tutto più veloce del previsto:
Pacco inviato: 26/10
Ricevuto da AMD : 27/10
Test passato: 30/10
Nuova CPU partita: 01/11
Nuova CPU arrivata: 03/11

Una settimana spaccata :D
Ciliegina sulla torta, anche il mio nuovo è un 1741SUS :sofico:

[metal master]

L'altro ieri ho avuto modo di provare il processore nuovo con lo script su ubuntu, e in quasi 2 ore non ho avuto nessun errore. (settando le memorie ram sia a 2133 mhz che a 2933)

nel vecchio processore dopo nemmeno 2 minuti invece mi dava segfault.

tra l'altro noto che la nuova cpu mantiene temperature più basse.

[metal master]

Certo che concordo, ma venire a dire, come qualcuno ha fatto, che sono stati costretti ad aprire un thread perché altrimenti nel thread ufficiale gli veniva preclusa la possibilità sacrosanta di parlare del problema, è una grandissima cavolata.


e invece non è una cavolata, si notava benissimo che quando si accennava al problema si voleva minimizzarlo o sminuirlo,e anche in questo thread ci sono stati interventi di qualche utente seccato dal sentire parlare di questo problema, che anche intel ne ha avuti e blablablabla...... ma a me cosa importa di intel, io i soldi li ho dati ad amd e se ci sono eventuali problemi con amd me la prendo e non con intel.

tra l'altro coi "nuovi" processori si sono avuti benefici anche a livello di voltaggi, temperature e altre cose, segno che con questi nuovi c'è stato un controllo qualità ed una selezione migliore rispetto ai primi lotti.

[Mister D]

e invece non è una cavolata, si notava benissimo che quando si accennava al problema si voleva minimizzarlo o sminuirlo,e anche in questo thread ci sono stati interventi di qualche utente seccato dal sentire parlare di questo problema, che anche intel ne ha avuti e blablablabla...... ma a me cosa importa di intel, io i soldi li ho dati ad amd e se ci sono eventuali problemi con amd me la prendo e non con intel.


Ah sì?! Quindi secondo il tuo ragionamento se uno vuole insabbiare un problema sul thread ufficiale consiglia:
1) si aprire altro thread nella stessa sezione SOLO per quel problema
2) di pinnare (mettere in evidenza) lo stesso thread.

Complimenti hai un ragionamento che dire logico deduttivo è fare un generoso complimento :asd: Ma siamo seri su.
Il fatto di portare es di problemi anche di intel l'ho fatto più volte io perché è un buon modo per ricordare che i problemi (gli errata) le hanno TUTTI e continueranno ad esserci. Non è che li ha solo AMD. Molti sono utenti che non hanno le conoscenze informatiche di pochi altri ergo poi possono formarsi pregiudizi (AMD= poco affidabile, intel= perfetta e sai quanti nei centri commerciali e nella vita reale dicono così? Vogliamo contribuire a continuare così?) dati solo dall'aver letto di questo bug. Non mi sembra di fare chissà quale astruso ragionamento.


tra l'altro coi "nuovi" processori si sono avuti benefici anche a livello di voltaggi, temperature e altre cose, segno che con questi nuovi c'è stato un controllo qualità ed una selezione migliore rispetto ai primi lotti.

Che la nuova selezione porti a miglioramenti ovvio che sia così ma i miglioramenti ci sarebbero cmq stati. E' nel logica del processo produttivo litografico.
Più passano i mesi e più la produzione migliora e le rese aumentano, al che il produttore ha diverse strade:
1) produrre più cpu con la tolleranza iniziale (3,6 GHz vid 1,35v tdp 95) e poter abbassare i prezzi
2) introdurre una nuova tolleranza (3,8GHz vid 1,35v tpd 95) e creare nuove SKU
E questo non si fa da oggi. Ma da l'alba dei tempi. Anzi AMD quando usa il processo litografico SOI aveva pure il CTI (continium transitor improvment) che permetteva ad ogni cpu di una nuova infornata di avere miglioramenti continui sulle caratteristiche elettriche. Tanto che se ti ricordi, all'epoca degli athlon X2 sui 65 nm, come anche sui 45 nm con i phenomII, venivano introdotti via via SKU con frequenza maggiore.;)

[metal master]

Ah sì?! Quindi secondo il tuo ragionamento se uno vuole insabbiare un problema sul thread ufficiale consiglia:
1) si aprire altro thread nella stessa sezione SOLO per quel problema
2) di pinnare (mettere in evidenza) lo stesso thread.

Complimenti hai un ragionamento che dire logico deduttivo è fare un generoso complimento :asd: Ma siamo seri su.
Il fatto di portare es di problemi anche di intel l'ho fatto più volte io perché è un buon modo per ricordare che i problemi (gli errata) le hanno TUTTI e continueranno ad esserci. Non è che li ha solo AMD. Molti sono utenti che non hanno le conoscenze informatiche di pochi altri ergo poi possono formarsi pregiudizi (AMD= poco affidabile, intel= perfetta e sai quanti nei centri commerciali e nella vita reale dicono così? Vogliamo contribuire a continuare così?) dati solo dall'aver letto di questo bug. Non mi sembra di fare chissà quale astruso ragionamento.

dai si capisce benissimo che un pò davano e danno fastidio alcuni interventi sul problema, probabilmente perchè dal problema che si è avuto qualcuno può puntare l'indice su amd riguardo la qualità dei suoi prodotti (sento sempre i soliti discorsi ridicoli in giro riguardo amd: costano poco perchè valgono poco, sono inferiori a intel ecc. ecc.)

amd oltre a sfornare una ottima serie di processori ryzen, mi ha entusiasmato anche per quanto riguarda l'assistenza tecnica ai clienti.

sono stati di una gentilezza unica e mi hanno assistito alla grande.

[fedexx2]

Testata un po' la CPU, nessun problema riscontrato.
Sono riuscito a tirarla fino a 4150Mhz :sofico: veramente ottima.

Per il daily tengo 4Ghz a 1,25v :D

[jam71]

La garanzia dei processori amd è di due anni giusto? il mio 1600x è affetto dal bug segfault ma sinceramente per adesso non ho voglia di smontare e spedire,vorrei aspettare ancora un po'.......o conviene farsela cambiare subito?
poi volevo chiedere a chi l'ha spedita che cosa devo dire ad amd,come devo descrivere il problema grazie.

[Mister D]

La garanzia dei processori amd è di due anni giusto? il mio 1600x è affetto dal bug segfault ma sinceramente per adesso non ho voglia di smontare e spedire,vorrei aspettare ancora un po'.......o conviene farsela cambiare subito?
poi volevo chiedere a chi l'ha spedita che cosa devo dire ad amd,come devo descrivere il problema grazie.

I boxed mi pare ricordare 3 anni con AMD. Ma basta verificare sul sito di amd. Per chiedere devi compilare il form (è scritto tutto in prima pagina) e dire semplicemente che hai provato il test per il segfault e ti restituisce errore ergo la tua cpu è affetta da bug.
Loro ti approvano la cpu, ti danno un indirizzo dove spedire, la testano e poi te ne rispediscono una nuova.
Il test lo hai condotto a def, con settaggi def attivi (LOAD OPTIMIZED DEFAULT) e ram in auto con profilo JEDEC? Se sì allora sei sicuro, altrimenti se eri in oc o anche solo con ram con profilo XMP potresti anche non essere stabile e non superare il test per quel motivo.;)

[sgrinfia]

Ragazzi scusate ma io forse sono di coccio, non capisco . Amd sta risolvendo la questione del bug ....si... .ho....no, quindi?.
Anche il I7 3960x nella prima alla sua prima uscita (step c1) aveva un bug .....e Intel la risolto ?......si a risolto , però nessuno a aperto un thread sulla cosa .

[Spitfire84]

Per il daily tengo 4Ghz a 1,25v :D

Vogliamo le prove di stabilità! :read:
Sennò il mio tiene 4 GHz con 1 V! :Prrr:

[fedexx2]

Vogliamo le prove di stabilità! :read:
Sennò il mio tiene 4 GHz con 1 V! :Prrr:

Sìsì certo, per ora ho avuto tempo solo per qualche provetta veloce,
ma appena posso lo metto sotto torchio con OCCT :D

[sinergine]

Quando riportate il voltaggio a cosa vi riferite?
A quello impostato nel BIOS oppure al CPU Core Voltage (SVI2 TFN) rilevato da Windows

[evil weasel]

Ragazzi scusate ma io forse sono di coccio, non capisco . Amd sta risolvendo la questione del bug ....si... .ho....no, quindi?.
Anche il I7 3960x nella prima alla sua prima uscita (step c1) aveva un bug .....e Intel la risolto ?......si a risolto , però nessuno a aperto un thread sulla cosa .

Potevi aprilo tu il thread sul 3960x, nessuno si sarebbe lamentato.
Invece qui ogni 2 o 3 pagine arriva qualcuno che, come te, in maniera maldestra e sconclusionata, cerca di minimizzare o mette in dubbio l'utilità di questo thread.
Una piattaforma Ryzen 7 costa facilmente solo di CPU, scheda madre e RAM più di 600/700 €, è il caso che chi si imbarca nell'acquisto sappia che la possibilità di beccarsi una CPU fallata è elevata e che sarà quindi da preventivare un fermo macchina di almeno una settimana per sbrigare le pratiche di RMA.

[CiccoMan]

Ragazzi scusate ma io forse sono di coccio, non capisco . Amd sta risolvendo la questione del bug ....si... .ho....no, quindi?.

AMD sostituisce le CPU difettose. Direi che sta risolvendo.

Anche il I7 3960x nella prima alla sua prima uscita (step c1) aveva un bug .....e Intel la risolto ?......si a risolto , però nessuno a aperto un thread sulla cosa .

Quindi,se non è stato aperto un thread per il 3960x, non può più essere aperto un thread sui bug di un altra CPU?

Secondo me questa è una discussione molto utile per chi cerca info riguardo alla problematica o cerca aiuto per eseguire il test è eventualmente avviare la procedura di rma.


Inviato dal mio Pixel utilizzando Tapatalk

[jam71]

I boxed mi pare ricordare 3 anni con AMD. Ma basta verificare sul sito di amd. Per chiedere devi compilare il form (è scritto tutto in prima pagina) e dire semplicemente che hai provato il test per il segfault e ti restituisce errore ergo la tua cpu è affetta da bug.
Loro ti approvano la cpu, ti danno un indirizzo dove spedire, la testano e poi te ne rispediscono una nuova.
Il test lo hai condotto a def, con settaggi def attivi (LOAD OPTIMIZED DEFAULT) e ram in auto con profilo JEDEC? Se sì allora sei sicuro, altrimenti se eri in oc o anche solo con ram con profilo XMP potresti anche non essere stabile e non superare il test per quel motivo.;)

Si ho letto tutto in prima pagina e in realta' in tutte le pagine della discussione ma avevo capito che bisognava mandare anche screen che attestavano il problema della propria cpu,il test l'ho eseguito con tutto a default quindi sono sicuro, ma ripeto per adesso aspetto poi vedro' cosa fare,il pc funziona bene e per adesso non ho voglia di smontare e spedire ma è una cosa che va fatta prima o poi.Ho acquistato il 1600x in quanto lo uso per giocare e mi sembrava la scelta piu' giusta, ma con l'intento piu' avanti di fare upgrade quindi sicuramente lo vendero' e dev'essere privo di bug.

[Spitfire84]

Quando riportate il voltaggio a cosa vi riferite?
A quello impostato nel BIOS oppure al CPU Core Voltage (SVI2 TFN) rilevato da Windows

Giusta domanda anche perche nel mio caso c'è una differenza di circa 50-60 mV tra il Vcore e la CPU Core Voltage (es: Vcore 1,35 V, CPU Core Voltage 1,29 V).
Se non ricordo male la tensione massima daily consigliata da AMD di 1,35 V dovrebbe far riferimento al CPU Core Voltage, ma chiedo anch'io conferma.

[Krato§]

Ciao raga, acquistando oggi un 1600 liscio che probabilità ho di beccarne uno fallato?

[KJx89]

Ragazzi scusate ma io forse sono di coccio, non capisco . Amd sta risolvendo la questione del bug ....si... .ho....no, quindi?.
Anche il I7 3960x nella prima alla sua prima uscita (step c1) aveva un bug .....e Intel la risolto ?......si a risolto , però nessuno a aperto un thread sulla cosa .

A parte non capire la polemica...
Cosa vedono i miei occhi :muro: :muro: :muro:
Saluti
Kappa

[Nautilu$]

Adesso qualcuno ti risponderà: "su un forum si può scrivere in qualsiasi modo....contestare la grammatica è offtopic, parlane in privato....".
Il diretto interessato : "ho la tastiera rotta, è colpa del cellulare, mi sono appena alzato, ecc..."
Ma la realtà è che oltre alla perdita dei valori fondamentali si sta facendo strada anche l'indifferenza al vergognarsi della propria non cultura....neanche per la lingua di appartenenza... :(

[Randa71]

Potevi aprilo tu il thread sul 3960x, nessuno si sarebbe lamentato.
Invece qui ogni 2 o 3 pagine arriva qualcuno che, come te, in maniera maldestra e sconclusionata, cerca di minimizzare o mette in dubbio l'utilità di questo thread.
Una piattaforma Ryzen 7 costa facilmente solo di CPU, scheda madre e RAM più di 600/700 €, è il caso che chi si imbarca nell'acquisto sappia che la possibilità di beccarsi una CPU fallata è elevata e che sarà quindi da preventivare un fermo macchina di almeno una settimana per sbrigare le pratiche di RMA.

Fallata solo se compili sotto Linux....fermo macchina solo se compili sotto Linux...non diamo false informazioni....non creiamo falsi mostri...da come la stai mettendo sembra che se compri un Ryzen ora corri il rischio di avere una macchina che non funziona.....io il problema ce l'ho, sai come ho risolto, ma il BUG è limitato alla compilazione sotto Linux...Ad aprire il thread cmq si è fatto solo bene...semplicemente perché aiuta :)... sono 6 mesi che ho la macchina con il bug e non ho mai avuto problemi di alcun tipo...Inoltre penso sì che sia limitata solo a Linux...con tutte le CPU che hanno venduto pensi che nessuno compili sotto WIN? Oppure tutti quelli che compilano sotto WIN hanno avuto la CPU sostituita?? io non credo..il problema esiste ma è circoscritto....da come l'hai scritta sembra che se ti compri Ryzen non funziona un piffero...secondo me è importante specificare anche l'ambito del BUG...

[evil weasel]

Fallata solo se compili sotto Linux....fermo macchina solo se compili sotto Linux...non diamo false informazioni....non creiamo falsi mostri...da come la stai mettendo sembra che se compri un Ryzen ora corri il rischio di avere una macchina che non funziona.....io il problema ce l'ho, sai come ho risolto, ma il BUG è limitato alla compilazione sotto Linux...Ad aprire il thread cmq si è fatto solo bene...semplicemente perché aiuta :)... sono 6 mesi che ho la macchina con il bug e non ho mai avuto problemi di alcun tipo...Inoltre penso sì che sia limitata solo a Linux...con tutte le CPU che hanno venduto pensi che nessuno compili sotto WIN? Oppure tutti quelli che compilano sotto WIN hanno avuto la CPU sostituita?? io non credo..il problema esiste ma è circoscritto....da come l'hai scritta sembra che se ti compri Ryzen non funziona un piffero...secondo me è importante specificare anche l'ambito del BUG...

Il tipo di y-cruncher, programma che negli ultimi anni è stato usato più volte per infrangere i record di calcolo delle cifre del pigreco, ha rilevato il problema sotto Windows compilando il suo software in Visual Studio.
Quindi il problema non è circoscritto soltanto a GCC, GNU/Linux o Windows subsystem for Linux.
Il guaio in questo caso è che quando vedi un segfault pensi che ci sia qualche errore nel codice, che magari non hai scritto tu e che è molto complesso.
Un problema hardware e peggio ancora della CPU stessa è proprio l'ultimissima cosa che ti viene in mente, ammesso che ti venga proprio in mente.
Sempre il tipo di y-cruncher ci ha sbattuto la testa per svariato tempo pensando fosse colpa del suo codice.
Non mi stupirei se ci fossero svariate persone nella sua stessa condizione.
E non voglio tirare in ballo tutte le cose dette e ridette che evidentemente in pochi hanno letto o capito, di motivi per non minimizzare il problema ce ne sono molti altri.

[Randa71]

Il tipo di y-cruncher, programma che negli ultimi anni è stato usato più volte per infrangere i record di calcolo delle cifre del pigreco, ha rilevato il problema sotto Windows compilando il suo software in Visual Studio.
Quindi il problema non è circoscritto soltanto a GCC, GNU/Linux o Windows subsystem for Linux.
Il guaio in questo caso è che quando vedi un segfault pensi che ci sia qualche errore nel codice, che magari non hai scritto tu e che è molto complesso.
Un problema hardware e peggio ancora della CPU stessa è proprio l'ultimissima cosa che ti viene in mente, ammesso che ti venga proprio in mente.
Sempre il tipo di y-cruncher ci ha sbattuto la testa per svariato tempo pensando fosse colpa del suo codice.
Non mi stupirei se ci fossero svariate persone nella sua stessa condizione.
E non voglio tirare in ballo tutte le cose dette e ridette che evidentemente in pochi hanno letto o capito, di motivi per non minimizzare il problema ce ne sono molti altri.

c'è un link dove parla del problema? Sono curioso

[evil weasel]

c'è un link dove parla del problema? Sono curioso

Ha postato i link 2 o 3 pagine fa s12a: http://www.hwupgrade.it/forum/showpost.php?p=45134933&postcount=649

[Randa71]

Ha postato i link 2 o 3 pagine fa s12a: http://www.hwupgrade.it/forum/showpost.php?p=45134933&postcount=649

sorry non li avevo visti

[BuRn]

Preso il 1700 la scorsa settimana su Amazon e ieri mi è arrivata finalmente la scheda madre.

A parte un banco di ram che è arrivato KO (con un comportamento davvero strano, cioè che da BIOS lo vede ma l'OS no, quindi il BIOS vede 16 gb ma l'OS ne vede 8 e che col solo banco fallato il sistema non parte) la CPU è una settimana 21.

Ho fatto qualche test: anche se ci ha messo parecchio alla fine ha fallito, dando sia segfaults che invalid opcodes. L'aspetto interessante è che durante il test ci sono stati errori anche in altri processi non legati alla compilazione, mi pare relativi alla gestione dei DNS.

Morale: mi tocca aspettare il cambio della ram per verificare che il kit nuovo sia OK e poi procedere con l'RMA da AMD. :muro:

[beee]

Spedito il mio 1700 ad amd giovedì scorso, stamane è arrivato il sostituto! Che dire, rapidissimi, grazie AMD!!!
Settimana 38. Acceso da 5 minuti, stasera farò qualche test, ma pare scaldare meno dell'altro.....

[nicolarush]

idem come sopra
processore ritirato dal corriere giovedì e oggi è arrivato il sostituto :)
(un 1700X 1741SUS :cool: )

mi sa che per il 1700 procedo al reso :D

[jam71]

Nel sito di AMD per fare RMA ho notato che non c'è piu' la pagina in italiano,ora mi chiedo nella descrizione del problema posso scrivere in italiano o per forza in inglese?

[nicolarush]

Nel sito di AMD per fare RMA ho notato che non c'è piu' la pagina in italiano,ora mi chiedo nella descrizione del problema posso scrivere in italiano o per forza in inglese?

l'ultima pagina mi è sempre apparsa in inglese, io comunque ho descritto il problema in inglese (maccheronico :D )

[jam71]

l'ultima pagina mi è sempre apparsa in inglese, io comunque ho descritto il problema in inglese (maccheronico :D )
:D ok grazie,mi arrangero' in inglese allora:p

[nicolarush]

:D ok grazie,mi arrangero' in inglese allora:p

nel frattempo sto testando da ore la cpu e niente segfaults (col vecchio 1700x e col 1700 li avevo dopo pochi secondi), per quanto mi riguarda problema risolto :)

[beee]

nel frattempo sto testando da ore la cpu e niente segfaults (col vecchio 1700x e col 1700 li avevo dopo pochi secondi), per quanto mi riguarda problema risolto :)

Idem...

[nicolarush]

da una mezz'oretta sta rullando prime95 a 4.000mhz e 1,35v (su hwinfo il vcore oscilla tra 1,306-1,313) impostati con ryzen master: prima era schermo nero e riavvio istantaneo :D

confermo l'ottima riuscita dell'infornata 1741SUS
scaldano meno, consumano meno e salgono di più :read:

[sinergine]

Nessuno ha una cpu da prestarmi intanto che rendo la mia? :D

Gli ultimi che hanno fatto il reso hanno ricevuto il pagamento anche della spedizione di andata o si sono dovuti arrangiare?

[nicolarush]

Gli ultimi che hanno fatto il reso hanno ricevuto il pagamento anche della spedizione di andata o si sono dovuti arrangiare?

Ti danno un codice, puoi usarlo per contattare il corriere per il ritiro o portare il pacco in un service point dove il corriere passa a prendere il pacco

[evil weasel]

1741SUS sembra essere veramente un ottimo batch.

[Nautilu$]

Quasi mi dispiace che il mio non sembri avere problemi.....:D
Appena ho tempo rifaccio il test più a lungo va.....:Prrr:

[Debern9093]

Ragazzi ho inviato la mia CPU in rma ad AMD al loro indirizzo fornito via mail e il giorno 30/10 mi è arrivata una mail di superamento test rma. Oggi è 08/10 ma ancora non mi è arrivato nulla che tra l'altro non mi hanno nemmeno inviato la mail con il codice tracking.. E normale tutto ciò? A chi posso rivolgermi?

[Nautilu$]

ecco...questo non è bello... :(

[Debern9093]

Mi hanno risposto.. Hanno finito le scorte di magazzino per i 1600x :muro: però da un lato può essere un bene perché mi arriverà quasi sicuramente uno degli ultimi prodotti

[alexsky8]

Quasi mi dispiace che il mio non sembri avere problemi.....:D
Appena ho tempo rifaccio il test più a lungo va.....:Prrr:

fallo girare, il mio lo tengo in forno per Ryzen 2 inoltrato :sofico:

già me lo immagino il 2700 4Ghz @ 1,2V con dissipatore stock :sofico:

[_filippo_]

Ciao ieri ho montato un ryzen 5 1600, 1728 di amazon, malaysia, e fatto subito il test (sbagliando, ho usato quello di suaefar su ubuntu 17.10), in ogni caso mi ha dato un segfault su bash dopo breve tempo.

Ero di corsa, non mi sono salvato i log e ho spento, ora sto cercando di riprodurre il bug per mandare qualche prova ad AMD ma non si manifesta più... saefaer arriva a un problema di compilazione che non c'entra niente e si blocca lì. Oxalin continua per ore fino a riempire la ram ma niente segfault.

Il processore precedente, settimana 11 sempre malaysia, crashava in pochi minuti anche con saefaer, anche su ubuntu 17.10, sempre con sigsegv su bash.

Sto cominciando a pensare di aver avuto un'allucinazione e magari era un problema di compilazione e non un segfault.

Una cosa, per lasciarlo tante ore non posso usare i parametri di default che mi riempie la ram (16GB), a voi da il bug lanciandolo con "./kill-ryzen.sh 4 4" ?

[alexsky8]

il mio settimana 33 da errore con qualunque combinazione entro pochi minuti

non lo da solo se disattivo SMT o alzo Vsoc almeno a 1,1V

[Alex656]

Ciao ieri ho montato un ryzen 5 1600, 1728 di amazon, malaysia, e fatto subito il test (sbagliando, ho usato quello di suaefar su ubuntu 17.10), in ogni caso mi ha dato un segfault su bash dopo breve tempo.

Ero di corsa, non mi sono salvato i log e ho spento, ora sto cercando di riprodurre il bug per mandare qualche prova ad AMD ma non si manifesta più... saefaer arriva a un problema di compilazione che non c'entra niente e si blocca lì. Oxalin continua per ore fino a riempire la ram ma niente segfault.

Il processore precedente, settimana 11 sempre malaysia, crashava in pochi minuti anche con saefaer, anche su ubuntu 17.10, sempre con sigsegv su bash.

Sto cominciando a pensare di aver avuto un'allucinazione e magari era un problema di compilazione e non un segfault.

Una cosa, per lasciarlo tante ore non posso usare i parametri di default che mi riempie la ram (16GB), a voi da il bug lanciandolo con "./kill-ryzen.sh 4 4" ?

Se arriva a saturarti la ram mi sa che ti conviene ripetere più volte il test, soprattutto con ram a default; magari non era un segfault quello che hai visto, sembra strano che prima ti esca fuori quasi subito e poi non si manifesti più; a me salta fuori sempre entro i primi 2 minuti. con "./kill-ryzen.sh 4 4" non ho avuto bisogno neppure di tentare.

[_filippo_]

Se arriva a saturarti la ram mi sa che ti conviene ripetere più volte il test, soprattutto con ram a default; magari non era un segfault quello che hai visto, sembra strano che prima ti esca fuori quasi subito e poi non si manifesti più; a me salta fuori sempre entro i primi 2 minuti. con "./kill-ryzen.sh 4 4" non ho avuto bisogno neppure di tentare.

Ok che ero di fretta ma sono ragionevolmente sicuro di aver visto una bella riga rossa su dmesg e pensato, "strano... perchè crasha su bash?", tant'è che ho aperto subito un ticket con AMD. Stasera riprovo.
Comunque sui forum stranieri pare che il bug sia abbastanza imprevedibile, a volte arriva dopo poco a volte dopo ore, quindi non mi sembra così strano. L'altro crashava sistematicamente dopo circa 4 minuti però.

[Alex656]

Ok che ero di fretta ma sono ragionevolmente sicuro di aver visto una bella riga rossa su dmesg e pensato, "strano... perchè crasha su bash?", tant'è che ho aperto subito un ticket con AMD. Stasera riprovo.
Comunque sui forum stranieri pare che il bug sia abbastanza imprevedibile, a volte arriva dopo poco a volte dopo ore, quindi non mi sembra così strano. L'altro crashava sistematicamente dopo circa 4 minuti però.
Se il problema c'è esce fuori di nuovo, questione solo di tempo. Nel mio caso in realtà non è imprevedibile, basta sempre pochissimo, forse sarà un caso più evidente.

[_filippo_]

Ticket per richiesta RMA ? Mi puoi far sapere SE ed in quanto tempo ti rispondono ?

Compilato il form http://support.amd.com/en-us/warranty/rma ieri mattina, ricevuto comunicazione di RMA approvato stamattina con istruzioni per la spedizione prepagata con DHL.

[_filippo_]

Ma che senso ha, io é da giovedí che aspetto e non mi rispondono, ho aperto un secondo ticket e non rispondono manco a quello :confused:

Non saprei, leggo che sei passato dall'assistenza italiana, io ho scritto direttamente in inglese all'assistenza internazionale.

[_filippo_]

Dovrebbero essere due canali diversi, ho usato il tuo stesso form oltretutto selezionando la lingua inglese in entrambi i ticket aperti, in uno mi hanno risposto una sola volta dopo 5giorni, l'altro invece totalmente ignorato.

Allora è solo un caso, dipenderà da chi ti capita a gestire la pratica... non saprei, ti direi che son stato più persuasivo, ma dubito conti davvero qualcosa.

O forse hanno una lista di seriali/part number che sanno in anticipo che sono buggati e li approvano subito. Su internet si legge di gente che ha dovuto mandare i log, modificare le tensioni e rifare i test, fare foto all'interno del case... mi sembra davvero strano anche a me che l'abbiano approvata così in fretta.

[_filippo_]

Nemmeno a me avevano chiesto niente la prima volta ma probabilmente perché avevo preventivamente incluso tutto nella mia mail.
Qua non si tratta peró di approvare velocemente, io non sto ricevendo nessuna risposta da una settimana abbondante nonostante stia continuando a scrivere ed aprire ticket.

Ma la prima volta cosa ti hanno risposto?

[_filippo_]

il 7/10 (quindi a 5 giorni dall'apertura del ticket, 3 giorni escludendo festivi) mi ha chiesto un paio di foto del computer e con quale programma monitorassi temperature e voltaggi, fornito ovviamente entrambe subito e poi niente.

Il secondo ticket aperto invece non ha direttamente mai avuto risposta.

Bah... stranissimo, sempre più convinto che abbiano una qualche lista dei processori sicuramente fallati e per gli altri indaghino più a fondo.

[_filippo_]

Sto cominciando a pensare di aver avuto un'allucinazione e magari era un problema di compilazione e non un segfault.


Rifatto il test, segfault su bash in 141s con la versione di oxalin...

[Alex656]

Compilato il form http://support.amd.com/en-us/warranty/rma ieri mattina, ricevuto comunicazione di RMA approvato stamattina con istruzioni per la spedizione prepagata con DHL.
Anche io ho appena compilato il form però ho visto che molti dicono di aver dovuto inviare una mail con screenshots, descrizioni ecc.; è una mail che viene richiesta dopo la compilazione del form oppure avete aperto l'RMA in altro modo?

[_filippo_]

Anche io ho appena compilato il form però ho visto che molti dicono di aver dovuto inviare una mail con screenshots, descrizioni ecc.; è una mail che viene richiesta dopo la compilazione del form oppure avete aperto l'RMA in altro modo?

No nel caso ti chiedono tutto dopo. A me non hanno chiesto nulla, quindi aspetta la risposta prima di metterti il problema.

[Alex656]

No nel caso ti chiedono tutto dopo. A me non hanno chiesto nulla, quindi aspetta la risposta prima di metterti il problema.

RMA approvata all'istante, mi hanno già inviato email in italiano con istruzioni per spedire, senza chiedere ulteriori spiegazioni, avevo soltanto accennato del segfault; mi sa che in effetti, già dal seriale della cpu sanno se è da sostituire; unica cosa è che non vedo accenno a spedizione prepagata, mi consigliano di utilizzare corriere tracciabile.

[Alex656]

Come non detto: ricevuto anche email con istruzioni per contattare DHL con spedizione prepagata, raccomandano aggiornamento del bios ad agesa 1.0.0.6b per la nuova cpu.

[_filippo_]

Come non detto: ricevuto anche email con istruzioni per contattare DHL con spedizione prepagata, raccomandano aggiornamento del bios ad agesa 1.0.0.6b per la nuova cpu.

A proposito, qualcuno ha già provato a spedire con DHL dando il conto di AMD? qualche complicazione?

[beee]

A proposito, qualcuno ha già provato a spedire con DHL dando il conto di AMD? qualche complicazione?

Nessuna complicazione... dhl point con il pacchetto e la mail di amd, non serve niente altro!

[BuRn]

Anche a me hanno accettato l'RMA alla prima comunicazione, ho fatto riferimento al fatto che avevo riscontrato degli errori su Linux e con lo script per testare Ryzen mi aveva dato sia SEGFAULT che INVALID OPCODE.

Mi hanno offerto spedizione tramite DHL, per la quale ho provveduto stamani.

[Alex656]

Per la spedizione con DHL qualcuno ha potuto richiedere il ritiro a domicilio? purtroppo non ho sedi vicine.

[Alex656]

Mi rispondo da solo: chiamando il servizio clienti DHL al numero 199 199 345 bisogna fornire il numero di account di AMD fornito via mail e sarà possibile anche il ritiro a domicilio con la spedizione prepagata.

[evil weasel]

Il ritiro con DHL si può prenotare anche dal sito senza dover chiamare 199. :)

[Alex656]

Il ritiro con DHL si può prenotare anche dal sito senza dover chiamare 199. :)

Quando la pagina è online! stamattina mi usciva un errore che diceva di contattare l'amministratore di sistema, ora funziona.
https://www.mydhl.dhl.com/mydhl/appmanager/smep/customerDesktop?_nfpb=true&_pageLabel=smep_portal_page_login&utm_source=IT&utm_medium=hp_tc&utm_campaign=login_link#portletShippingOptions

[W_o_M]

Acquistato su Tao il 06/11/2017, inizio evasione, spedito il 08/11/2017, arrivato il 10/11/2017, lo devo ancora montare.

AMD Ryzen R7 1700 (in scatola con dissipatore)
Processor OPN: YD1700BBAEBOX
Packing Type: P
Delivery Date: 2017-09-05
MFG Date: 2017-09-01

UA 1733SUS - Diffused in USA - Made in China

[jam71]

RMA approvata all'istante, mi hanno già inviato email in italiano con istruzioni per spedire, senza chiedere ulteriori spiegazioni, avevo soltanto accennato del segfault; mi sa che in effetti, già dal seriale della cpu sanno se è da sostituire; unica cosa è che non vedo accenno a spedizione prepagata, mi consigliano di utilizzare corriere tracciabile.

Ciao,nel form da compilare avevi messo lingua italiana o inglese? e la descrizione del problema l'hai scritta in italiano o inglese? grazie.

[Alex656]

Ciao,nel form da compilare avevi messo lingua italiana o inglese? e la descrizione del problema l'hai scritta in italiano o inglese? grazie.
Sulla descrizione ho scritto semplicemente: segmentation fault under linux with gcc compiler, come lingua mi pare di aver messo italiano ma è rimasto tutto in inglese; ho ricevuto una prima mail in inglese poi una in italiano.

[jam71]

Sulla descrizione ho scritto semplicemente: segmentation fault under linux with gcc compiler, come lingua mi pare di aver messo italiano ma è rimasto tutto in inglese; ho ricevuto una prima mail in inglese poi una in italiano.

Ok perfetto ti ringrazio!

[sinergine]

Come mai la seconda volta? Ti avevano mandato una CPU che manifestava ancora il problema?

[sinergine]

Sì ora ricordo. Ti avevo anche detto che secondo me era il precedente ad avere i sensori sballati. Mai visto una CPU che tiene la temperatura ambiente in idle.

Per il cross-shipping, a loro una cpu costa probabilmente molto poco e quindi ci perdono nulla.
Mi chiedo invece perché non offrano la sostituzione con l'invio da parte loro per primo in cambio della carta di credito, come fanno per gli hd

[Alex656]

Oggi ho smontato la cpu e preparato il pacco per il corriere; togliendo il dissipatore è venuto via anche il processore che era rimasto incollato; AM4 non ha meccanismo di blocco, non dovrei aver causato danno al socket vero?

[Mister D]

Tutti i ryzen che ho avuto modo di provare in idle tengono praticamente la Tamb... in particolare con un dissipatore da 250W :stordita:
Infatti dall'assistenza "salvo il discorso di non rispondermi per giorni", hanno accettato l'rma alla prima mail, speriamo bene.

Ed è fisicamente impossibile che un corpo emettitore di calore tenga la stessa temperature del fluido in cui è immerso, cioè l'aria. Si può avere con superficie infinita del dissipatore ma capisci pure te che è un limite non raggiungibile nella realtà.
Dagli FX AMD ha dichiarato che NON usa un scala lineare per la temperature ma un valore per calcolare il margine termico. Con zen non so se sia la stessa cosa, ma dai valori in idle direi di sì. In pratica con la cpu in full load la temperature tornano ad avere un senso, mentre in idle non hanno senso fisico. Ma non ci vole AMD a dirlo, basta essere stati attenti alle lezioni di fisica alla superiori :asd: o usare un briciolo di ragionamento logico.
Come può un processore da acceso avere la temperatura ambiente? Anche se di un SOLO grado dovrà differire per forza.

[bagnino89]

Ed è fisicamente impossibile che un corpo emettitore di calore tenga la stessa temperature del fluido in cui è immerso, cioè l'aria. Si può avere con superficie infinita del dissipatore ma capisci pure te che è un limite non raggiungibile nella realtà.
Dagli FX AMD ha dichiarato che NON usa un scala lineare per la temperature ma un valore per calcolare il margine termico. Con zen non so se sia la stessa cosa, ma dai valori in idle direi di sì. In pratica con la cpu in full load la temperature tornano ad avere un senso, mentre in idle non hanno senso fisico. Ma non ci vole AMD a dirlo, basta essere stati attenti alle lezioni di fisica alla superiori :asd: o usare un briciolo di ragionamento logico.
Come può un processore da acceso avere la temperatura ambiente? Anche se di un SOLO grado dovrà differire per forza.

Magari non hai considerato il caso banale: è spento :asd:

Scherzi a parte, quanto hai scritto è insindacabile, ma alcuni sono duri a capire.

[Mister D]

Tutto giusto se non fosse che hai cannato la base dell'intero ragionamento.
Non ho MAIdetto che in idle si trova a t.amb o meno, ho detto che in idle tiene praticamente temperatura ambiente, cosa possibilissima e comune con i Ryzen.
Tamb 20 -> idle 24<T<26 é uno scenario fisicamente possibile e comunissimo, anche con un rapido calcolo di superfìcie, potere dissipante e W consumati dal processore.

Altrettanto semplice é intuire che se un processore in idle, quindi con un consumo 15<W<20 si trova 20C sopra la temperatura ambiente, c'é palesemente un problema di sensori e/o scambio termico da qualche parte, direi che anziché sfruttare O le lezioni fisiche alle superiori O il buonsenso sarebbe utile utilizzare entrambe :asd:

Questo per dire, senza offesa, non ho proprio bisogno di nessun ripasso di fisica, o perlomeno sicuramente da nessuno in questo forum, in compenso la comprensione del testo é altrettanto utile come skill :D

Ok io posso avere interpretato male ma in italiano praticamente NON ha il significato che gli dai te come sinonimo di quasi, circa o simile.
Praticamente e cito il mio dizionario:
Praticamente avv CO 1. all'atto pratico, concretamente: affrontare p. un problema. 2 anche con valore attenuativo: in pratica, in realtà, in sostanza: l'estate è p. finita, ho detto p. tutto, sono p. sicuro di aver superato l'esame.
S: concretamente, in pratica,
E se cerchi con google trovi pure come sinonimi: in effetti, in concreto, alla prova dei fatti, in sostanza, essenzialmente, concretamente, effettivamente, realmente, in realtà.
Se sostituisci in realtà la frase viene: in idle tiene in realtà la temperatura ambiente.
Ecco perché ho interpretato male. Se avessi scritto tiene circa la temperatura ambiente non avrei detto nulla. E ora capisco che mi sbagliavo visto che sai che è fisicamente impossibile avere la medesima temperatura.
Detto questo, se misura così tanto sì, poteva benissimo essere un problema di sensori o meglio di scala di temp non lineare (il dubbio te lo toglierai con il prossimo che ti invieranno. Se avrà circa le stesse temp di quest'ultimo dubito che siano 2 cpu fallate ma piuttosto un comportamento normale di queste cpu come lo era con gli FX). Vedi qui:
https://www.gamersnexus.net/hwreviews/2822-amd-ryzen-r7-1800x-review-premiere-blender-fps-benchmarks/page-4
"Sam Naffziger, Corporate Fellow at AMD, confirmed to GamersNexus that the temperature output by Ryzen’s junction sensor is not a straight Celsius value indicative of real temperature. It is scaled by a formula of some sort, and we are not able to gain access to that formula"
(un ringraziamento è dovuto a SpongeJohn che me lo ha ricordato in privato).

Detto questo mi pare evidente che in tutti i casi è da prendere con le pinze il valore in idle e NON dargli un valore fisico perché è la stessa AMD a dirlo. Era pure riportato nei datasheet degli FX che la temp era solo usata per calcolare il margine termico e di non considerarla in idle. Addirittura mi sono ritrovato con degli FX che in idle andavano pure sotto la temperatura ambiente :asd:
La cosa migliore sarebbe usare un sensore tra HIS e base del dissipatore e così scoprire l'esatta temperatura della superficie dell'HIS. Però non tutti hanno voglia di complicarsi così la vita. Quello che più importante secondo me è la temperatura in full load.;)
Cmq pace :mano:

[Alex656]

Spedito il mio 1700 ad amd giovedì scorso, stamane è arrivato il sostituto! Che dire, rapidissimi, grazie AMD!!!
Settimana 38. Acceso da 5 minuti, stasera farò qualche test, ma pare scaldare meno dell'altro.....

Nel momento in cui AMD ha ricevuto il processore, ti ha informato via mail sullo stato di lavorazione oppure hai ricevuto direttamente senza alcun preavviso?

[beee]

Nel momento in cui AMD ha ricevuto il processore, ti ha informato via mail sullo stato di lavorazione oppure hai ricevuto direttamente senza alcun preavviso?

Mi ha informato 'leggermente'...
spedita giovedì
venerd' pomeriggio:
-cpu arrivata, sarà sottoposta a 'test'
dopo 10 minuti
-cpu ha passato test, sarà avvisato quando la spedizione partirà.

poi piu nessuna notizia fino a martedì mattina, quando la cpu 'nuova' è arrivata.
2-3 giorni fa è arrivata una mail con un piccolo questionario sull'assistenza amd.

[Quickdany]

Ciao ragazzi,
Ho appena finito di montare un 1600 ( datato 1736 ) sulla mia nuova build ho fatto il test con ./kill-ryzen.sh 4 4 come da guida per i 16gb di ram. bios nuovo tutto a default.

Ecco i risultati
https://thumb.ibb.co/eG71F6/Screenshot_from_2017_11_15_21_57_25.png (https://ibb.co/eG71F6) https://thumb.ibb.co/iuiaa6/Screenshot_from_2017_11_15_21_58_25.png (https://ibb.co/iuiaa6)

Questo e quello che sta andando ora per ora con questi strani errori
https://thumb.ibb.co/nkwE2m/Screenshot_from_2017_11_15_22_14_03.png (https://ibb.co/nkwE2m)https://thumb.ibb.co/girmF6/Screenshot_from_2017_11_15_22_21_53.png (https://ibb.co/girmF6)
Aggiorno perch[ ha finito con errori anche questo

Cosa dite?

[_filippo_]

Cosa dite?

Direi che non ci sono dubbi, senti AMD per la sostituzione!

[Alex656]

Ciao ragazzi,
Ho appena finito di montare un 1600 ( datato 1736 ) sulla mia nuova build ho fatto il test con ./kill-ryzen.sh 4 4 come da guida per i 16gb di ram. bios nuovo tutto a default.

.....

Cosa dite?

I segfault ci sono, io però mi accerterei di non avere instabilità altrove, magari facendo dei test tipo prime95 e/o asus stability test sotto windows, soprattutto perchè si parla di settimana 36.

[Quickdany]

I segfault ci sono, io però mi accerterei di non avere instabilità altrove, magari facendo dei test tipo prime95 e/o asus stability test sotto windows, soprattutto perchè si parla di settimana 36.

Infatti avevo visto settimana 36 prima di montarlo ed ero tranquillo. Dopo aver visto che facevo fatica a salire con le frequenze delle ram ho detto facciamo il test che ancora non avevo fatto e traccc...
Proverò un prime95 per tante ore, ma non credo di avere instabilità specie a tutto default. Cmq mi confermate che per RMA bisogna stare senza cpu una decina di gg?

[Alex656]

Infatti avevo visto settimana 36 prima di montarlo ed ero tranquillo. Dopo aver visto che facevo fatica a salire con le frequenze delle ram ho detto facciamo il test che ancora non avevo fatto e traccc...
Proverò un prime95 per tante ore, ma non credo di avere instabilità specie a tutto default. Cmq mi confermate che per RMA bisogna stare senza cpu una decina di gg?

C'è chi ha spedito di giovedì e già martedì aveva il processore nuovo, dipende dalla zona e probabilmente dal carico di lavoro del centro AMD; io ho spedito lunedì mattina dalla calabria, pacco recapitato mercordì alle 12 (DHL è un signor corriere) e non ho ricevuto ancora alcuna comunicazione sullo stato del reso.

[_filippo_]

I segfault ci sono, io però mi accerterei di non avere instabilità altrove, magari facendo dei test tipo prime95 e/o asus stability test sotto windows, soprattutto perchè si parla di settimana 36.

La storia della settimana era una supposizione messa in giro da Phoronix senza fondamento. Il primo processore rientrato dall'RMA era settimana 25 quindi tutti i processori dopo la 25 dovevano essere buoni...

Poi è diventata 26, e via così... ora forse siamo alla 33. Qualcuno dice che gli unici buoni sono i SUS (wafer prodotto a Saratoga e assemblato in Cina se non erro).

Non ci sono regole, probabilmente sono tutti difettosi tranne qualche raro caso fortunato e quelli rientrati dall'RMA (e a volte, pare, nemmeno quelli).

[il_dottorino]

il mio è 1733 e sembrerebbe non avere problemi dopo aver eseguito il suddetto test... ma vedo che cpu prodotte settimane successive sono affette dal bug, sarà un caso?

[cica88]

Ho provato a fare un test di 10 minuti sotto Windows con Visual Studio ( run.cmd -j 16 ) e non mi ha dato errori, solamente quando ho premuto CTRL + C mi ha dato errore ma da quanto ho capito è normale.
1800X @3.93Ghz + 3200Mhz preso verso fine luglio.

[Quickdany]

Arrivata conferma RMA da AMD in mezza giornata lavorativa, con codice DHL per spedire su loro conto, senza ulteriori richeste di test o altro.
Quindi confermo che il mio 1600 settimana 36 è qui sul tavolo pronto per essere spedito.
Direi che se hanno liste di quali partite essere a rischio bug potrebbe essere legato anche alla pianta di produzione come qualcuno scriveva a sto punto.

[Alex656]

Se spedisci lunedí secondo me é probabile che per venerdí tu la abbia giá indietro ( se usi la loro spedizione DHL che é velocissima ).

Arrivato il processore nuovo btw, di nuovo un settimana 33 e dal seriale pericolosamente vicino a quello che gli avevo rispedito indietro, non é fresco come il primissimo che gli avevo (che a questo punto immagino fosse bello fortunello) inviato ma le temp sono scese di almeno 6-7 gradi rispetto a quello dell'rma precedente.
Il mio processore risulta recapitato in Olanda mercoledì mattina ma, ad oggi, non ho ricevuto neppure la mail di conferma ricezione, non so se le tempistiche siano sempre così veloci; leggevo, qualche reply addietro, di qualcuno ancora in attesa perchè avevano terminato le scorte dei 1600; è sempre meglio mettere in conto qualche giorno in più, poi andrà anche un pò a fortuna.

[BuRn]

Il mio processore risulta recapitato in Olanda mercoledì mattina ma, ad oggi, non ho ricevuto neppure la mail di conferma ricezione, non so se le tempistiche siano sempre così veloci; leggevo, qualche reply addietro, di qualcuno ancora in attesa perchè avevano terminato le scorte dei 1600; è sempre meglio mettere in conto qualche giorno in più, poi andrà anche un pò a fortuna.

Stesso discorso, arrivato in Olanda mercoledì e per ora nessuna notizia. Ho provato a rispondere alla mail del ticket originale e il sistema di risposta automatico mi avvisava che il ticket era stato annullato e di aprirne uno nuovo.

Venerdì fa un mese che ho pagato per questa CPU (+ scheda madre e ram, ovviamente)... :muro:

[Alex656]

Stesso discorso, arrivato in Olanda mercoledì e per ora nessuna notizia. Ho provato a rispondere alla mail del ticket originale e il sistema di risposta automatico mi avvisava che il ticket era stato annullato e di aprirne uno nuovo.

Venerdì fa un mese che ho pagato per questa CPU (+ scheda madre e ram, ovviamente)... :muro:

Venerdì ho provato a chiedere notizie facendo il reply alla mail informativa sull'apertura del ticket originale (l'unica su cui potevo rispondere, le altre erano mail automatiche con tanto di noreply); mi è stato aperto un ulteriore ticket, nessuna risposta ad oggi tranne la chiusura del primo ticket perchè sono trascorsi i 10 giorni e l'invio del questionario sul grado di soddisfazione sull'assistenza AMD. Non mi preoccuperei tanto per qualche giorno in più ma vorrei almeno sapere che fine ha fatto la mia cpu.

[Alex656]

Ho il sospetto che il numero di RMA sia aumentato ed abbiano difficoltà a gestirle.

[BuRn]

Mah, non capisco che senso abbia chiudere un ticket per cui c'è un RMA in corso.

Ma a chi è arrivata la CPU indietro, AMD ha dato conferma della sotituzione prima di spedire? Vi ha dato un tracking della spedizione di ritorno?

[Alex656]

Mah, non capisco che senso abbia chiudere un ticket per cui c'è un RMA in corso.

Ma a chi è arrivata la CPU indietro, AMD ha dato conferma della sotituzione prima di spedire? Vi ha dato un tracking della spedizione di ritorno?

Secondo la prassi, che mi pare sia stata rispettata per chi ha avuto la sostituzione, si dovrebbero ricevere 2 mail, una che attesta l'avvenuta ricezione e l'avvio dell'ispezione V/M (meccanica visiva) ed una che comunica se il processore verrà sostituito o rispedito indietro; nessuno ha ricevuto tracking.

La cosa strana per noi invece è il mancato invio anche della prima mail, nonostante la consegna del corriere risulti effettuata il 15/11. Proverò ad aprire un'ultima richiesta, anche se so che sarà inutile; se continuerò a non ricevere risposte prenderò i provvedimenti del caso.

[jexoz]

Secondo la prassi, che mi pare sia stata rispettata per chi ha avuto la sostituzione, si dovrebbero ricevere 2 mail, una che attesta l'avvenuta ricezione e l'avvio dell'ispezione V/M (meccanica visiva) ed una che comunica se il processore verrà sostituito o rispedito indietro; nessuno ha ricevuto tracking.

La cosa strana per noi invece è il mancato invio anche della prima mail, nonostante la consegna del corriere risulti effettuata il 15/11. Proverò ad aprire un'ultima richiesta, anche se so che sarà inutile; se continuerò a non ricevere risposte prenderò i provvedimenti del caso.

Per quanto mi riguarda il mio 1600x è in Olanda da martedì 14 (DHL). Venerdì su sollecito mi hanno risposto che devono ripristinare gli stock e dovrebbe avvenire questa settimana.

Gli ho riscritto oggi per cambiare indirizzo di spedizioni, vediamo ora cosa mi rispondono.

Nessuna comunicazione sul fatto che la CPU abbia superato test visivi (ma immagino di si visto che lo spediscono indietro appena è in stock).

Vediamo.

[Alex656]

Stavolta ho ricevuto risposta in italiano da un tecnico AMD partendo da questa pagina e selezionando italiano:
http://support.amd.com/en-us/contact/email-form

Mi è stato chiesto il tracking della spedizione con cui ho inviato la cpu.

[BuRn]

A me non hanno ancora risposto, comunque avevo fornito tutte le date e il tracking della spedizione tramite il form online, diamogli un po' di tempo.

[Mr.Lollo14]

Vorrei acquistare un 1700, pensavo di prenderlo da amazon.
non potendo prevedere che processore mi arrivi, conviene ordinarne due e rispedire indietro quello con la data più recente? (non credo uno possa montarlo pulirlo e spedirlo indietro:D )

[Alex656]

Mi pare che anche amazon abbia terminato le scorte al momento, tenderei a pensare che i prossimi arrivi siano di produzione recente e magari privi di bug.

[jok3r87]

Mi hanno aperto il ticket e dato il codice account AMD di DHL ma come faccio a prenotare il ritiro ? Sul sito DHL non trovo il menu per inserire il codice per prenotare il ritiro.

[Alex656]

Mi hanno aperto il ticket e dato il codice account AMD di DHL ma come faccio a prenotare il ritiro ? Sul sito DHL non trovo il menu per inserire il codice per prenotare il ritiro.
Se hai una sede vicina credo ti convenga spedire personalmente; io ho prenotato il ritiro telefonicamente allo 199 199 345, è un numero a pagamento ma almeno sono andato sul sicuro fornendo loro il numero account per la spedizione prepagata.

[beee]

Mi hanno aperto il ticket e dato il codice account AMD di DHL ma come faccio a prenotare il ritiro ? Sul sito DHL non trovo il menu per inserire il codice per prenotare il ritiro.

Io son andato ad un dhl center (ce ne sono tanti, tipo tabaccherie ed altri negozi, vedi sul sito dhl) col pacchetto e la mail di amd.... 2 firme e via!

[alexsky8]

Mi pare che anche amazon abbia terminato le scorte al momento, tenderei a pensare che i prossimi arrivi siano di produzione recente e magari privi di bug.


fra l'altro invece che diminuire sono aumentate di uno sproposito

[Alex656]

fra l'altro invece che diminuire sono aumentate di uno sproposito
Come prezzo intendi? Il 1700x oggi costa 100€ in meno rispetto a quanto l'ho pagato io ed è in pronta consegna al momento; a proposito di prezzi: http://www.hwupgrade.it/news/cpu/taglio-di-prezzo-in-vista-per-le-cpu-amd-ryzen_72474.html

[BuRn]

Stamane hanno risposto che avrebbero verificato il magazzino, ora hanno confermato che il prodotto è stato ricevuto e poi subito dopo che è stato superato il test visivo e mi avviseranno quando spediranno la nuova cpu.

[Alex656]

A me stamattina hanno semplicemente risposto che avrebbero contattato il reparto RMA e mi avrebbero fornito notizie non appena disponibili. Poi più nulla :mad:

[_filippo_]

Vorrei acquistare un 1700, pensavo di prenderlo da amazon.
non potendo prevedere che processore mi arrivi, conviene ordinarne due e rispedire indietro quello con la data più recente? (non credo uno possa montarlo pulirlo e spedirlo indietro:D )

Io ne ho rispedito uno indietro ad Amazon, settimana 11. Volevo mandarlo indietro da chiuso ma non ho resistito e l'ho provato. Buggato, restituito.

Nota che non ho fatto il semplice reso, ho contattato l'assistenza e gli ho spiegato del bug e chiesto che venisse segnalato al venditore e non rimesso in vendita così. Chissà se la cosa è stata ascoltata o sarà rimesso in vendita sporco di pasta termica.

Per come ho capito io il diritto di recesso comunque non c'è nessun problema a montarlo e poi cambiare idea e rimandarlo indietro senza motivazione. Ma qua stiamo parlando di processori difettosi.

Il sostituto era settimana 26, sempre buggato. Ho optato per l'RMA.

[Alex656]

Io ne ho rispedito uno indietro ad Amazon, settimana 11. Volevo mandarlo indietro da chiuso ma non ho resistito e l'ho provato. Buggato, restituito.

Nota che non ho fatto il semplice reso, ho contattato l'assistenza e gli ho spiegato del bug e chiesto che venisse segnalato al venditore e non rimesso in vendita così. Chissà se la cosa è stata ascoltata o sarà rimesso in vendita sporco di pasta termica.

Per come ho capito io il diritto di recesso comunque non c'è nessun problema a montarlo e poi cambiare idea e rimandarlo indietro senza motivazione. Ma qua stiamo parlando di processori difettosi.

Il sostituto era settimana 26, sempre buggato. Ho optato per l'RMA.

Anche io avrei voluto fare RMA ad Amazon ma purtroppo, allo stato attuale, non si ha alcuna sicurezza di ricevere poi un processore "bug free", soprattutto perchè la data di produzione non dà alcuna certezza; ho preferito il percorso più lungo, sperando che il dispendio di tempo non sia eccessivo.

[sgrinfia]

La concorrenza sta peggio::D

Falle di sicurezza nelle CPU Intel Core, Xeon, Atom e Celeron (milioni di PC). Il tool di verifica
Falle di sicurezza nelle CPU Intel Core, Xeon, Atom e Celeron (milioni di PC). Il tool di verifica

Gravi falle di sicurezza nella gran parte dei processori Intel in circolazione. Ad essere interessati sono alcuni processi attivi in background come Intel Management Engine, Server Platform Services e Trusted Execution Engine. Ecco il tool per capire se anche il vostro PC è soggetto al problema. Rilasciato un tool di diagnostica
di Alessandro Bordin pubblicato il 22 Novembre 2017 nel canale Processori
CeleronXeonCoreIntelAtom
AddThis Sharing Buttons
Share to FacebookShare to TwitterShare to Google+Share to LinkedInShare to WhatsAppShare to Più...


Intel ha segnalato un grave problema di sicurezza legato a buona parte della propria produzione CPU, relativo ad alcuni servizi in background attivi nei processori stessi in acune circostanze. Nello specifico sono emerse vulnerabilità in Intel Management Engine (IME), Server Platform Services (SPS) e Trusted Execution Engine (TXE), sebbene la criticità sia maggiore nel primo caso.

Si tratta di processi che possono essere eseguiti a basso livello, a monte del sistema operativo, di cui gli utenti (anche appassionati) non hanno probabilmente mai sentito parlare. Nelle mani sbagliate, però, questi processi costituirebbero di fatto una corsia preferenziale per attacchi informatici, qualora fossero vulnerabili. E il caso sembra proprio questo, essendo la stessa Intel a comunicarlo e quindi non servono conferme di nessun tipo. Quali sono i processori interessati? Parliamo potenzialmente di milioni di PC:

- Intel Core di sesta, settima e ottava generazione
- Intel Xeon E3-1200 v5 & v6
- Xeon serie Scalable
- Xeon serie W
- Atom serie C3000
- Serie Atom E3900 Apollo Lake
- Serie Pentium Apollo Lake
- Celeron serie N e J

Basta anche la prima voce dell'elenco per capire la portata del problema. Secondo lo US-CERT, United States Computer Emergency Readiness Team, le versioni vulnerabili sono quelle del firmware IME nelle versioni 11.0, 11.5, 11.6, 11.7, 11.10 e11.20 (ma non andate a controllare, c'è un tool che vi proponiamo fra poco per il check). Le versioni vulnerabili per quanto riguarda SPS e TXE sono rispettivamente le 4.0 e 3.0.

Ok, ma quali rischi si corrono?

Lo dice Intel stessa, con una lista di potenziali rischi non certo di poco conto. In primis un attacco mirato potrebbe permettere di "impersonare" i processi IME/SPS/TXE, di fatto dando il via libera a processi di ogni tipo perché il check di sicurezza verrebbe facilmente superato. Una conseguenza diretta, che vale come secondo punto, sarebbe la possibilità di caricare ed eseguire codice invisibile al sistema operativo e all'utente, operando su un livello inferiore. Possibili anche malfunzionamenti e crash, ma questo terzo punto sembra nulla rispetto alla gravità dei primi due.

Nonostante tutto Intel ha classificato il problema come "Importante" e non "Cruciale", quello più grave in assoluto, forse perché si tratta di processi che richiedono competenze molto elevate per essere attaccati e modificati. Resta il fatto che il problema esiste e dovrà essere risolto al più presto, specie ora che la notizia è pubblica.

Il mio PC è affetto dal problema?

C'è un modo per saperlo, visto che Intel ha rilasciato uno strumento di diagnostica apposito. Vista la lista dei processori interessati è molto probabile. Si può scaricare a questo indirizzo (11,59MB), sia in formato .zip per sistemi operativi Microsoft Windows sia in formato .gz per Linux. Una volta scaricato si dovrà scompattare il file in una cartella e scegliere se eseguire il test da riga di comando o il più comodo file "Intel-SA-00086-console.exe" presente nella cartella DiscoveryTool, da eseguire ovviamente come amministratore.

Si apre per qualche secondo la console e viene generato nella stessa cartella un file di log, con nome "SA-00086-XXXXXX-2017-11-22-08-50-48.log", dove al posto delle X ci sarà un codice diverso da PC a PC, così come differente potrà essere la data e l'ora. L'importante è il contenuto del messaggio, che nel nostro caso recitava così:

Sistema vulnerabile, come da attese.

Come si risolve?

Intel consiglia di contattare il produttore della scheda madre posseduta oppure il produttore OEM del PC per sapere se è disponibile una soluzione nella forma di un nuovo firmware cumulativo. Insomma, esistono soluzioni specifiche per modelli specifici, motivo per cui è davvero difficile che Intel da sola possa rilasciare centinaia di fix differenti: ogni partner svilupperà i propri. Gigabyte ha già annunciato di essere al lavoro per rilasciarne qualcuno davvero a breve, da utilizzare con le proprie schede madri serie Z370 e 200. Molto lecito attendersi che altre aziende siano al lavoro per fare lo stesso, in lotta contro il tempo.

[alexsky8]

Come prezzo intendi? Il 1700x oggi costa 100€ in meno rispetto a quanto l'ho pagato io ed è in pronta consegna al momento; a proposito di prezzi: http://www.hwupgrade.it/news/cpu/taglio-di-prezzo-in-vista-per-le-cpu-amd-ryzen_72474.html

io oggi su Amazon vedo il 1700 a 325€ mica noccioline

[Alex656]

Per quanto mi riguarda il mio 1600x è in Olanda da martedì 14 (DHL). Venerdì su sollecito mi hanno risposto che devono ripristinare gli stock e dovrebbe avvenire questa settimana.

Gli ho riscritto oggi per cambiare indirizzo di spedizioni, vediamo ora cosa mi rispondono.

Nessuna comunicazione sul fatto che la CPU abbia superato test visivi (ma immagino di si visto che lo spediscono indietro appena è in stock).

Vediamo.

Hai avuto più notizie?

[il_dottorino]

possibile bug?

http://i67.tinypic.com/2drhyjm.png

[BuRn]

Sono rincasato adesso e ho trovato il pacchetto di AMD lanciato oltre la cancellata: per fortuna le scatole hanno un buon imballaggio!

la nuova CPU è un 1738SUS, a breve monterò e poi vediamo.

[BuRn]

possibile bug?

http://i67.tinypic.com/2drhyjm.png

Sembra più un problema nel far partire il test, non ci sono messaggi del kernel.

[il_dottorino]

ubuntu 17.10 installato con oxalin... il bello è che ho fatto lo stesso test con ubuntu live nessun problema.....

[BuRn]

Secondo me manca qualche prerequisito per far girare il test, non ricordo bene ma mi sa che mi era capitato quando ho provato con Ubuntu 17.10, installandolo ex-novo.

Per toglierti il dubbio prova a dare i seguenti due comandi prima di lanciare il test:

sudo apt-get update
sudo apt-get install build-essential

Il primo aggiorna la lista dei pacchetti, il secondo ti scarica gli strumenti di compilazione. In teoria lo script dovrebbe scaricarseli da solo con dei comandi analoghi, ma provare non costa nulla.

Altro suggerimento, visto che stai testando col sistema installato, se apri il file kill-ryzen.sh con un editor di testo puoi settare a false la variabile USE_RAMDISK, così non ti mangia un sacco di memoria inutilmente e puoi far girare il test più a lungo.

[il_dottorino]

proverò a seguire il tuo consiglio... per ora è in esecuzione in ubuntu live