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

[Spitfire84]

Originariamente inviato da evil weasel

Ho mandato indietro un 1700X che avevo e che era fallato.
Non so se è merito dell'email aziendale dal nome altisonante o solo fortuna ma mi hanno offerto una spedizione prepagata con DHL.

se è quella di ritorno, la offrono a tutti.
E' la spedizione in Olanda che dovresti pagare...se non paghi neanche quella, meglio per te, risparmi 18€

[evil weasel]

Originariamente inviato da Spitfire84

se è quella di ritorno, la offrono a tutti.
E' la spedizione in Olanda che dovresti pagare...se non paghi neanche quella, meglio per te, risparmi 18€

Intendevo proprio quella di andata, mi hanno dato un codice prepagato per l'invio a carico di AMD.

[AmuroRei_2]

Oggi ho aperto una RMA con Tao, dato che avevo fatto anche l'opzione acquisti
sicuri dovrebbero mandarmi in sostituzione se ne hanno in stock un 1700 nuovo
e loro si arrangiano per l'rma alla AMD.

[malcom499]

Originariamente inviato da sinergine

Proprio ora che ero intenzionato a prendere un 1700.
Nessuno li ha presi di recente da tao? Sono ok?

Io sto aspettando un 1700 liscio da Amazon. Sarebbe dovuto arrivare domani, mercoledì ma oggi mi è arrivato un loro avviso di ritardo di 1/2 giorni, cmq entro venerdì arriva...ah la cpu è in viaggio dall'inghilterra...speriamo bene!

[papugo1980]

Originariamente inviato da malcom499

Io sto aspettando un 1700 liscio da Amazon. Sarebbe dovuto arrivare domani, mercoledì ma oggi mi è arrivato un loro avviso di ritardo di 1/2 giorni, cmq entro venerdì arriva...ah la cpu è in viaggio dall'inghilterra...speriamo bene!

A me arriva tra lunedì e martedì...
Vediamo che mi mandano...

[s12a]

Originariamente inviato da Ozozuz

Provato ora un R5 1600 settimana 34, crashato subito. O la VM sfancula qualcosa oppure bho, provo su una live di fedora

Il processore era nuovo o proveniente da RMA? (EDIT: scambio dal negozio come avevi menzionato in precedenza)
Overclock? Hai provato con le memorie a 2133 MHz?

Nel forum AMD c'è un utente che ieri ha postato di avere provato un 1800X settimana 37 ritornato da RMA. Segfault con le memorie a 3066 MHz, ma nessun problema, apparentemente, a 2400 MHz. A differenza di altri utenti, la confezione in questo caso non sembrava essere stata già aperta (cosa che sembrava implicare una sorta di controllo individuale prima dell'invio).

https://community.amd.com/message/28...828641#2828641 (post 1791-1792)

Got the new processor, it did not appear to have been opened or tested.

Batch UA-1737SUS

Still segfaults, but after 35 minutes now. That was tested at 3066Mhz memory speed on 3200Mhz chips (32GB of 16GBx2 DualRank). Technically, this is still overclocked, so I'm retesting now at 2400Mhz. I know they offically changed supported memory speeds with latest BIOS, but haven't seen the speed chart.

Anybody seen that?

I wonder if they are just sending these out now hoping they pass without any extra binning. If this still segfaults at this memory speed, I'll ask for advanced shipping instead of cross-ship.

New 1800X running kill_ryzen for over 4 hours without problems with memory at 2400Mhz. Previous cpu died within minutes at 2133Mhz.

Couldn't find official AMD memory support list, https://www.amd.com/system/files/201...rt-list-en.pdf has been removed. Can't find any copies anywhere. Anyway, ASRock lists 2933Mhz offically for my memory (GSkill F4-3200C14-16GTZ) I'll retest at that speed.

Has anybody had luck reducing segfaults with higher ram voltage?

[s12a]

E se invece di una distribuzione live provassi il Linux Subsystem for Linux (aka "Linux on Windows". Non è una virtual machine) ed eseguire il test da lì? A partire dal Fall Creators Update si installa mediante il Windows Store.



A questo punto credo però che i processori che non danno problemi siano solo quelli con binning migliore (e conseguentemente che si overcloccano meglio).

[bagnino89]

Comunque non è chiara 'sta cavolo di situazione...

AMD dovrebbe rilasciare una dichiarazione ufficiale o qualcosa di simile, proponendo un test oggettivo e ripetibile per verificare la presenza o meno del bug.

Praticamente la settimana di produzione non vuol dire nulla...

[s12a]

Se installi il WSL ricorda di effettuare da una finestra di PowerShell con privilegi di amministratore, prima di avviare Bash:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

La fonte di questo comando è qui: https://msdn.microsoft.com/en-us/com...or=-2147217396

Una volta aperto bash/Ubuntu digita questo per aggiornare i repository (altrimenti ryzen-test fallisce subito):

sudo apt-get update

In ryzen-test.sh inoltre disabilita il ramdisk poiché non è supportato dal WSL. Apri il file (ad esempio con il comando "nano") e modifica la variabile USE_RAMDISK in:

USE_RAMDISK=false

Io ho scaricato ryzen-test con wget usando il seguente URL: https://github.com/suaefar/ryzen-tes...ive/master.zip
Ed ho scompattato l'archivio usando il comando unzip, che non è presente di default nella distribuzione. Andrà quindi fatto prima:

sudo apt-get install unzip

In alternativa puoi fare dal file manager di Windows, ma non è consigliabile accedere alla home da lì.

La home è accessibile dalla directory:

%localappdata%\lxss\home\

Il filesystem di Linux (ext4) usa un layer di compatibilità su NTFS ed è lento, dunque non ti sorprendere se ryzen-test sembrerà metterci una vita per estrarre i sorgenti di GCC.

Sto provando proprio adesso; a partire, parte. Non dovrebbero avvenire segfault sulla mia configurazione:

[s12a]

Da quanto io ricordi, se il problema è la memoria insufficiente, ryzen-test dovrebbe terminare con un errore diverso, non segfault. Inoltre questo non dovrebbe avvenire immediatamente od entro pochi minuti. (EDIT: da qualche parte nelle directory create dal test dovrebbe essere disponibile un file di log con i dettagli, magari sarebbe meglio controllare lì per confermare)

In ogni caso la stessa pagina indica anche come sia possibile, qualora sia necessario, diminuire il numero di loop/thread per far continuare il test a lungo anche su configurazioni con memoria RAM limitata. Riporto qui per completezza:

You can also try to run fewer loops but allow them to use more threads, e.g., 8 loops with 2 threads each.

    ./kill-ryzen.sh 8 2

However, with only 16Gb RAM, this configuration might still run out of memory. 4 loops with 4 threads each is a safe choice on machines with 16Gb RAM.

    ./kill-ryzen.sh 4 4

[s12a]

Originariamente inviato da Ozozuz

Edit:
https://image.prntscr.com/image/_Xp3...diDrSjIQew.png

Errore confermato, processore 34esima settimana

Non una buona notizia.

Puoi allegare le ultime righe dell'output del file di log di uno dei loop che ha fallito il test?

Dalla pagina di Ryzen-test:

Processes related to the build will eventually crash (e.g., segfault). Processes unrelated to the build process might crash as well. An example output of the script where the first process crashed after 153 seconds can be found in "example-output.txt". There, the "last words" from the build process were (logged to "/mnt/ramdisk/workdir/buildloop.d/loop-*/build.log"):

[Mister D]

Originariamente inviato da bagnino89

Comunque non è chiara 'sta cavolo di situazione...

AMD dovrebbe rilasciare una dichiarazione ufficiale o qualcosa di simile, proponendo un test oggettivo e ripetibile per verificare la presenza o meno del bug.

Praticamente la settimana di produzione non vuol dire nulla...

Al momento no perché evidentemente il riferimento della settimana 25 era proveniente da reddit o da phoronix ma era un'ipotesi perché magari a qualcuno hanno mandato una cpu da rma prodotta nella settimana 25 ma testata con il nuovo quality test. Purtroppo AMD ha solo detto di aver modificato il quality test per le nuove cpu ma non ha specificato da che settimana di produzione ciò è entrato in uso. E sono ormai convinto che AMD tenga un magazzino di cpu per le ram di lotti di differenti settimane di produzione e che ovviamente prima di mandarli all'utente finale li ritesta con il nuovo test. Questo perché sanno che non tutte le cpu prodotte prima del cambio del test hanno tale bug.
Sono anche più convinto che quelle binnate meglio siano proprio quelle esenti da bug, ergo AMD deve aver modificato il test di selezione, ergo tutte quelle nuove sono migliori dal punto di vista frequenze/vcore/vsoc.

Cmq visto che la conferma del problema è data il 07/08/2017 immagino che sicuramente le cpu prodotte da settembre (se non prima tipo metà agosto) passino già la nuova selezione e quindi non abbiano il problema. Facendo la conta calendario alla mano direi che è probabile che dalla settimana 36 (dal 4/09 al 10/09) si possa avere la certezza che AMD abbia già fatto partire il nuovo quality test. Ma è una mia ipotesi

[s12a]

@Ozozuz: ho il sospetto che dato che con il WSL non c'è un kernel Linux vero e proprio gli errori siano diversi o che non venga emesso esplicitamente all'utente un errore di segfault come direttamente da Linux. Tuttavia dato che dallo screenshot che mostri sopra ci sono righe consecutive del comando dato per compilare GCC, l'interruzione dovrebbe essere stata causata dallo stesso problema. A me non è successo ancora nulla dopo circa 15 minuti di test.


Puoi anche accedere a quella directory da Windows Explorer; è modificare i file che può dare problemi di corruzione.

Oppure, aprendo un'altra console mentre una sta compilando, invece di usare nano puoi usare il comando tail -n x dove x è il numero di righe a partire dalla fine del file da mostrare.

Per velocizzare la procedura ripetendola nuovamente puoi eliminare commentandole con un "#" le righe dallo script kill-ryzen.sh che fanno scaricare e scompattare GCC. Eliminerei anche la directory buildloop.d prima di ripetere il test.

[bagnino89]

Originariamente inviato da Mister D

Al momento no perché evidentemente il riferimento della settimana 25 era proveniente da reddit o da phoronix ma era un'ipotesi perché magari a qualcuno hanno mandato una cpu da rma prodotta nella settimana 25 ma testata con il nuovo quality test. Purtroppo AMD ha solo detto di aver modificato il quality test per le nuove cpu ma non ha specificato da che settimana di produzione ciò è entrato in uso. E sono ormai convinto che AMD tenga un magazzino di cpu per le ram di lotti di differenti settimane di produzione e che ovviamente prima di mandarli all'utente finale li ritesta con il nuovo test. Questo perché sanno che non tutte le cpu prodotte prima del cambio del test hanno tale bug.
Sono anche più convinto che quelle binnate meglio siano proprio quelle esenti da bug, ergo AMD deve aver modificato il test di selezione, ergo tutte quelle nuove sono migliori dal punto di vista frequenze/vcore/vsoc.

Cmq visto che la conferma del problema è data il 07/08/2017 immagino che sicuramente le cpu prodotte da settembre (se non prima tipo metà agosto) passino già la nuova selezione e quindi non abbiano il problema. Facendo la conta calendario alla mano direi che è probabile che dalla settimana 36 (dal 4/09 al 10/09) si possa avere la certezza che AMD abbia già fatto partire il nuovo quality test. Ma è una mia ipotesi

Appunto, sono ipotesi (seppur sensate), AMD dovrebbe chiarire e chiudere la faccenda una volta per tutte.

Sarà anche un problema insignificante, ma è comunque un problema esistente ed appurato. La questione va gestita in modo trasparente.

[Mister D]

Originariamente inviato da bagnino89

Appunto, sono ipotesi (seppur sensate), AMD dovrebbe chiarire e chiudere la faccenda una volta per tutte.

Sarà anche un problema insignificante, ma è comunque un problema esistente ed appurato. La questione va gestita in modo trasparente.

Sì hai ragione ma se non lo fa nemmeno intel a volte come puoi aspettarti che lo faccia uno più piccolo? E con questo NON giustifico né AMD né Intel:
https://www.tomshw.it/cpu-intel-rece...hreading-86594

Questo mi sembra abbastanza importante o no? Pero sfido a trovarmi quanti possessori di intel ne fossero a conoscenza prima che tom's e altri siti lo pubblicassero e intel ovviamente lo aveva pubblicato negli errata. Tutti puritani poi si scopre che i datasheet intel non li legge nessuno. Ok AMD ancora non li ha pubblicati e questo lo trovo gravissimo, perché con tutti gli altri processori gli errata erano stati pubblicati nel bios development kit. Mentre purtroppo ancora non l'ho visto sul sito di amd, magari i produttori di mb (certamente immagino) lo hanno ma non capisco perché non pubblicarlo per tutti come si faceva prima.

[s12a]

Originariamente inviato da Ozozuz

Ho rifatto il test, questa volta dando errore su un loop differente ad una diversa iterazione, il log é pressappoco identico.
Ho fatto anche una nuova prova, ovvero sempre da VM ma disabilitando il RAMDISK e ha dato ""correttamente"" segafault.
https://image.prntscr.com/image/bNWy...85uTJBTJeA.png

Mentre questo é il log del loop7 che é crashato nell'ultimo tentativo.
https://image.prntscr.com/image/68DA...AFo44327tw.png

Per scrupolo e curiosità, tempo permettendo puoi provare a far partire il test con diverse impostazioni di ryzen-test, limitando il numero di loop e thread? Ad esempio 4 loop da un thread ciascuno, oppure 1 loop da 16 thread, o magari anche 1 loop da 1 o 2 thread, per vedere se il problema è solo il tipo di workload, o proprio il carico della CPU. Ovviamente ci metterà più tempo (penso).

[Gioz]

Originariamente inviato da Ozozuz

per me l'errore con integrato "all-recursive" significa che hai saturato la memoria eseguendo ricorsivamente operazioni che ne allocano "tot".
se anche scrivi una funzione che non fa niente e richiama se stessa all'infinito puoi saturare la memoria.
dovresti provare disattivando il ramdisk o passando come argomento una coppia diversa, nel readme suggerisce "4 4".

[s12a]

Originariamente inviato da Ozozuz

Disabilitando il ramdisk non dovrebbe essere superfluo ?
Dopotutto non usando al ram puó anche caricare tutto al massimo, anche perché la cpu é perfettamente stabile sia a default che in oc "ora ovviamente é a default"

Il ramdisk dovrebbe servire solo per i risultati della compilazione, log, ecc. Il processo vero e proprio è comunque svolto interamente dalla CPU ed in memoria.

Se controlli ad esempio il Task Manager di Windows durante l'operazione (usando Ubuntu tramite il WSL) noterai una quantità enorme di processi venire creati e terminati, od almeno io già ne vedo solo con 4 core, posso solo immaginare con 16 e le impostazioni di default del test (EDIT: appena provato, sono effettivamente molti di più. Per il momento non mi sembra di avere problemi di memoria insufficiente o simili, o non ne noto. EDIT2: nessun inconveniente dopo 15 minuti di ./ryzen-test.sh 16 16).

[evil weasel]

Il messaggio "TIME TO FAIL: xxx" può comparire, oltre che ovviamente nel caso di un segfault, anche se si verifica una delle due seguenti condizioni:
1. si satura totalmente la RAM;
2. si satura completamente il RAMDISK o, nel caso in cui non lo si usi, la partizione su cui sono presenti i sorgenti da compilare.

Nel caso della mia macchina con 32 GB di RAM e RAMDISK da 16 GB il tempo impiegato per saturare la memoria è superiore ai 10 minuti.
Quando eseguite il test potete controllare la quantità di RAM utilizzata/libera con il comandi:
1. free;
2. htop (questo va installato su ubuntu credo, per farlo eseguire: sudo apt-get install htop);
3. top.

Per controllare invece quanto spazio è utilizzato sul RAMDISK si può usare il comando "df -h".
Nello specifico, se si vuole rieseguire il comando df ogni secondo in modo da tenere meglio sotto controllo la situazione si può usare il seguente comando: "watch -n 1 df -h"

Solitamente mi sembra di vedere che, in caso di CPU fallata, il test fallisce entro poche decine di secondi quando di RAM non allocata ce ne è ancora parecchia.
Se si vuole lasciare eseguire il test per ore bisogna istruire lo script in modo che vengano lanciate un numero inferiori di compilazioni simultanee; ad esempio, come scritto nel readme, per avere 4 compilazioni contemporanee con 4 core allocati ciascuna lanciare: "sh kill-ryzen.sh 4 4"

A me entrambe le CPU provate fallivano entro 30 secondi...