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

[papugo1980]

Originariamente inviato da bagnino89

Che problemi hai in DX12? Con che giochi?

https://youtu.be/XgnHcOmE1YA
All' inizio e alla fine ce un calo drastico( con blocchi)
Anche con the division in dx12 stesso problema
Una volta mi ha pure crashato con errore sulla directx

[bagnino89]

Originariamente inviato da papugo1980

https://youtu.be/XgnHcOmE1YA
All' inizio e alla fine ce un calo drastico( con blocchi)
Anche con the division in dx12 stesso problema
Una volta mi ha pure crashato con errore sulla directx

Mi sa più di problema dovuto a driver video che non alla CPU...

Qual è la tua configurazione completa? Che 1080 hai? A liquido?

Versione di Windows? Versione dei driver Nvidia? Provato a togliere tutto con DDU e a re-installare gli ultimi? Con DX11 hai problemi?

[papugo1980]

1080 evga FE messa a liquido
Ryzen 1700 a 3900
Asus crosshair hero
Ram 16 GB g skill flare x 3200mhz
Li i driver video erano i penultimi installati su Windows 10 pro pulito(senza driver video)
In Dx 11 tutto bene
La cpu é affetta da segfault perciò leggendo le pagine precedenti che poteva dare problemi in DX12 e Vulkan il problema lo avevo attribuito alla cpu

[bagnino89]

Originariamente inviato da papugo1980

1080 evga FE messa a liquido
Ryzen 1700 a 3900
Asus crosshair hero
Ram 16 GB g skill flare x 3200mhz
Li i driver video erano i penultimi installati su Windows 10 pro pulito(senza driver video)
In Dx 11 tutto bene
La cpu é affetta da segfault perciò leggendo le pagine precedenti che poteva dare problemi in DX12 e Vulkan il problema lo avevo attribuito alla cpu

E chi lo ha detto questo? Non credere a dichiarazioni non supportate in modo evidente e incontrovertibile dai fatti...

Per me non è la CPU, altrimenti avresti problemi pure con le DX11.

Comunque ho rivisto bene il video... Tranne l'inizio, in cui si vede chiaramente che l'occupazione GPU scende di brutto, negli altri punti è come se avessi micro-stuttering, ma non mi sembra la fine del mondo. Sicuro che non sia imputabile all'engine del gioco?

Io ci ho giocato a BF1 ma sempre in DX11 perché in DX12 non vedevo differenze/vantaggi. Idem Deus Ex HM, dove addirittura giocare in DX12 era peggio.

[s12a]

Originariamente inviato da Gioz

per darti un primo feedback: con impostazioni che nel test restituivano segfault pressoché istantaneamente qui non ho problemi, anche lato consumo e temperatura il carico non è particolarmente intensivo.

Grazie per aver tentato.

suppongo che non si verifichino quei cambi di stato in successione tali da innescare il problema.
credo sia improbabile tentare con script di varia natura senza conoscere l'esatta condizione che può portare all'errore e di conseguenza riuscire a far eseguire le istruzioni adeguate.

Era più che altro per vedere se in condizioni d'uso simili ma comunque di potenziale uso pratico potessero presentarsi problemi. Magari non necessariamente segfault dichiarati in maniera chiara, ma ad esempio avvisi di Windows tipo "cmd.exe ha smesso di funzionare..." (ecc), vedi ad esempio sotto.

a sinistra esecuzione "liscia" a destra "32 10000 1500", lanciati consecutivamente e non simultaneamente:
https://imgur.com/tyPwwBa

Per quello che può valere, io ho appena provato per curiosità ad abbassare la tensione della CPU ad un valore appena sufficiente per fare boot ed un paio di volte ha saltato uno dei cicli in cui sarebbe dovuto essere stato stampato a schermo il numero di immagini elaborate, per cui è possibile che la modalità di errore possa essere "silenziosa" per come questo script è stato scritto. Non sembra essere stato il tuo caso.

Mi aspetterei comunque che Windows si accorga di eventuali programmi che provino ad "uscire dal seminato". L'ideatore di kill-ryzen-win (se qualcuno a proposito voleva in precedenza esempi di dimostrazioni di simili problemi su Windows) aveva notato tali avvisi per cmd.exe, ad esempio.

[Gioz]

Originariamente inviato da s12a

Grazie per aver tentato.


Era più che altro per vedere se in condizioni d'uso simili ma comunque di potenziale uso pratico potessero presentarsi problemi. Magari non necessariamente segfault, ma ad esempio avvisi di Windows tipo "cmd.exe ha smesso di funzionare..." (ecc), vedi ad esempio sotto.

credo che la chiave del discorso sia "simili", purtroppo o per fortuna (dipende da casi e punti di vista) sta molto a cosa significa questo.
se per determinate istruzioni si innesca una particolare condizione di stato in cui c'è qualcosa che non va (tipo dei transistor che commutano in modo sbagliato per via di rumore o altro, e non necessariamente lato core) e in un altro caso questo non può accadere perchè quello stato macchina non è fisicamente contemplato dalla procedura di esecuzione allora le due condizioni sono estremamente diverse anche se macroscopicamente possiamo ritenerle simili.
è sicuramente utile fare prove di varia natura perchè se si incappa di anomalie correlate questo può aiutare a comprendere meglio il problema ed è la ragione per cui ho voluto provare il test restituendo un feedback - restiamo in attesa di altri per valutare la cosa - , il problema è che non conoscendo la fisica esatta dei fatti è un'equazione di sole incognite ed è sempre e comunque difficile farsi un'idea di quanto e come eventualmente possa dare noie con altri tipi di utilizzi.

[Nautilu$]

Originariamente inviato da s12a

Quello che appare delinearsi in seguito ad altri report simili è che chi non ha proprio segfault dopo lunghi periodi di test non sembra avere problemi a riguardo neanche in overclock. Hai provato con impostazioni di overclock non 100% stabili (ma neanche immediatamente instabili) per vedere che succede?

Eccoti accontentato!

Ho alzato la frequenza di 100mhz senza aumentare la tensione cpu....
In Windows basta per far resettare il pc durante Cinebench....

....stessa cosa con RyzenTest su Ubuntu:
Nessun Segfault... solo un reset improvviso con schermo nero.
Ho fatto un video:
ZIP

[alexsky8]

a me proprio non parte il test
mi da questo errore

C:\Users\ALEX\Desktop\1>python worker.py
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000028d0 (most recent call first):

[Gioz]

Originariamente inviato da alexsky8

a me proprio non parte il test
mi da questo errore

C:\Users\ALEX\Desktop\1>python worker.py
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000028d0 (most recent call first):

installa la versione amd64 di python 3.6 e spunta le voci sulle variabili ambientali e i path di esecuzione, credo tu abbia un errore perché non hai il pacchetto adeguato o le corrette impostazioni di setup.

[ccmarco2004]

Originariamente inviato da s12a

Durante l'operazione viene creato e terminato un numero significativo di processi (principalmente cmd.exe, magick.exe; quelli di python.exe sono fissi), situazione simile a quella che avviene durante la compilazione con GCC, MSVC, ecc.

Più la dimensione delle immagini è alta più memoria verrà occupata e più ogni worker richiederà tempo per ciascuna immagine, quindi attenzione a non esagerare per non saturare tutta la RAM ed oltre. Consiglio di usare almeno qualche worker in più dei core logici della CPU.

Al di là del parallelismo, mi aspetto che una buona percentuale del workload di magick sia costituito da operazioni in floating point, mentre gcc dovrebbe lavorare per lo più ad interi.

Non credo che questa condizione di lavoro sia equivalente a quella che triggera il segfault sotto linux.

Riguardo invece al test di compilazione con Visual Studio, è stata trovata una correlazione con i risultati ottenuti sotto Linux sulla stessa macchina?

[Mister D]

Originariamente inviato da s12a

Grazie per aver tentato.


Era più che altro per vedere se in condizioni d'uso simili ma comunque di potenziale uso pratico potessero presentarsi problemi. Magari non necessariamente segfault dichiarati in maniera chiara, ma ad esempio avvisi di Windows tipo "cmd.exe ha smesso di funzionare..." (ecc), vedi ad esempio sotto.


Per quello che può valere, io ho appena provato per curiosità ad abbassare la tensione della CPU ad un valore appena sufficiente per fare boot ed un paio di volte ha saltato uno dei cicli in cui sarebbe dovuto essere stato stampato a schermo il numero di immagini elaborate, per cui è possibile che la modalità di errore possa essere "silenziosa" per come questo script è stato scritto. Non sembra essere stato il tuo caso.

Mi aspetterei comunque che Windows si accorga di eventuali programmi che provino ad "uscire dal seminato". L'ideatore di kill-ryzen-win (se qualcuno a proposito voleva in precedenza esempi di dimostrazioni di simili problemi su Windows) aveva notato tali avvisi per cmd.exe, ad esempio.

Scusami tanto ma cosa ti aspettavi da un test del genere? Scusa se te lo dico ma hai scoperto l'acqua calda.
I produttori di cpu usano dei test per stabilire il livello di vcore necessario per far sì che in qualsiasi operazione la cpu non salti dei cicli (che può provocare fino a freeze e crash). Solo che questo livello tiene conto di una media basata su n cpu che nascono diverse tra loro come qualità litografica e quindi qualità elettriche.
Per cui per X cpu il vcore sarà giusto mentre per tutte le altre sarà da lievemente abbondante a stra abbondante (e infatti molti downvoltano). Quante cpu avranno vcore stra abbondante lo decide il produttore in base alle rese e di conseguenza al prezzo che vuole applicare per la sua cpu. Ovvio che se determina un vcore troppo basso ci saranno più die che non riescono a superare il test e quindi le cpu buone costeranno di più mentre se sceglierà un vcore più alto il numero di cpu buone sarà maggiore e il prezzo minore ma si potrebbe scontrare con TDP e consumi elevati. Mi pare lapalissiano che sia un gioco di compromessi.
Gli stress test (come quello che ti sei inventato) non fanno altro che verificare la tenuta delle stabilità ed è chiaro che riducendo passo il vcore a frequenza fissa prima o poi incappi in alcuni test in problemi e questo vuol semplicemente dire che hai trovato il vcore minimo per la tua cpu (vcore di uno step più alto rispetto a quello che ti ha dato errore in almeno uno degli stress test, in questo caso il tuo).

Da tutto questo dovrebbe essere chiaro che magari il problema che appare prevalentemente in compilazione su linux o ambiente virtualizzato o "esteso" (passami il termine anche se non è esatto) come può essere il WSL è una particolare condizione di carico cpu che fa registrare errori in molte cpu. Da questo è molto verosimile che effettivamente AMD abbia cannato qualcosa nella selezione e per alcuni si risolve alzando vcore e vsoc e rilassando le ram mentre per altri non si risolve proprio e sono costretti a sostituire la cpu con altra con migliore e idonea selezione.

In conclusione quindi cosa mi può dire la prova di aumentare le frequenza a parità di vcore o diminuire il vcore a parità di frequenza se non che ad un certo punto renderò instabile la cpu la quale ovviamente non riuscirà ad eseguire quel test e manco quello su linux di compilazione? E che lo faranno pure le cpu sane?

Anche se prendessi una cpu testata da AMD per RMA (e quindi sicuramente esente da bug) e gli abbassi il vcore ad un certo punto non ti fa più qualsiasi test e va in crash inesorabilmente. Non capisco proprio dove vuoi andare a parare e cosa vorresti dimostrare. Con tutto che hai la mia stima per aver aperto il thread, chiarito ogni aspetto e portato una marea di link, prove, test ecc ecc e che costantemente aggiorni la prima pagina. Ma ad un certo punto o vai direttamente nei laboratori di AMD e chiedi di parlare con i loro ingegneri o sarà tempo perso cercare di capire ulteriormente il perché e il per come di questo bug. Poi sei libero ovviamente di fare tutte le prove che vuoi

[s12a]

Originariamente inviato da Nautilu$

Eccoti accontentato!

Ho alzato la frequenza di 100mhz senza aumentare la tensione cpu....
In Windows basta per far resettare il pc durante Cinebench....
....stessa cosa con RyzenTest su Ubuntu:[...]

Allora nulla, sembra proprio che un overclock instabile non sia sufficiente a provocare segfault.

Originariamente inviato da alexsky8

a me proprio non parte il test
mi da questo errore

C:\Users\ALEX\Desktop\1>python worker.py
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Sia Python che ImageMagick devono essere a 64bit, oppure entrambi a 32bit (ma la versione linkata di ImageMagic non va bene in tal caso). Devi inoltre eseguire il test nella stessa directory dove risiedono tutti i file necessari per lo stesso. Se poi hai già una diversa (magari più vecchia), installazione di Python nella PATH di sistema, potrebbe essere un motivo di problemi. Se invece hai fatto partire il test usando i file dello zip linkato (e che sconsigliavo usare per principio - non è bene far partire file exe altrui), non saprei su due piedi.

In ogni caso, se non escono fuori errori con l'esemplare di Gioz con cui i segfault accadono a quanto pare subito, probabilmente è inutile perderci tempo.

Originariamente inviato da ccmarco2004

Al di là del parallelismo, mi aspetto che una buona percentuale del workload di magick sia costituito da operazioni in floating point, mentre gcc dovrebbe lavorare per lo più ad interi.

Non credo che questa condizione di lavoro sia equivalente a quella che triggera il segfault sotto linux.

Io semplicemente ipotizzavo che potesse avere qualcosa a che vedere con l'apertura e chiusura di un notevole numero di processi per unità di tempo in condizioni di alto carico del processore, cosa che questo test effettivamente fa. Probabilmente non basta.

Riguardo invece al test di compilazione con Visual Studio, è stata trovata una correlazione con i risultati ottenuti sotto Linux sulla stessa macchina?

L'autore aveva questi problemi solo con i suoi sistemi dotati di CPU AMD Ryzen, i quali effettivamente mostravano anche segfault su linux. Così è riportato in questo link oltre che su Reddit.

Originariamente inviato da Mister D

Scusami tanto ma cosa ti aspettavi da un test del genere? Scusa se te lo dico ma hai scoperto l'acqua calda.[...]

Tutta questa manfrina sarebbe stata evitabile. Era semplicemente una prova per verificare, al di là degli aspetti teorici ipotizzati quando lo ho scritto, le possibili modalità di errore dello script in caso di CPU instabile, nel caso mi fosse sfuggito qualcosa.

[alexsky8]

Originariamente inviato da Gioz

installa la versione amd64 di python 3.6 e spunta le voci sulle variabili ambientali e i path di esecuzione, credo tu abbia un errore perché non hai il pacchetto adeguato o le corrette impostazioni di setup.

Originariamente inviato da s12a

Sia Python che ImageMagick devono essere a 64bit, oppure entrambi a 32bit (ma la versione linkata di ImageMagic non va bene in tal caso). Devi inoltre eseguire il test nella stessa directory dove risiedono tutti i file necessari per lo stesso. Se poi hai già una diversa (magari più vecchia), installazione di Python nella PATH di sistema, potrebbe essere un motivo di problemi. Se invece hai fatto partire il test usando i file dello zip linkato (e che sconsigliavo usare per principio - non è bene far partire file exe altrui), non saprei su due piedi.

sì ora che ho guardato probabilmente avevo scaricato python a 32 bit
e vabbe

[s12a]

Forse serve una procedura più collaudata per eseguire il test su Windows nativamente. Nell'altro thread fra un post e l'altro era stato spiegato come fare per kill-ryzen-win. Ecco nuovamente in un formato più accessibile e chiaro.


1) Scaricare kill-ryzen-win
Download: https://github.com/corngood/kill-ryz...ive/master.zip
Fonte: https://github.com/corngood/kill-ryzen-win

Scompattare il file .zip in una directory facilmente accessibile da riga di comando.


2) Scaricare ed installare Build Tools for Visual Studio 2017
Download: https://www.visualstudio.com/thank-y...ldTools&rel=15
Fonte: https://www.visualstudio.com/downloa...al-studio-2017

Eseguire "vs_buildtools.exe"



Selezionare le tre opzioni elencate e poi premere "install":

• Visual C++ build tools
• Web development build tools
• .NET Core build tools

5.26GB occupati a fine installazione (indicati dall'installer)
1.28GB da scaricare in totale (verificato)



Installazione...




3) Build&Run
Start Menu > digitare/selezionare "Developer Command Prompt for VS 2017"

Dalla finestra di riga di comando apparsa (sostituire a x:\downloads\ecc il percorso dove kill-ryzen-win è stato scompattato):

cd /D x:\downloads\kill-ryzen-win 
build.cmd

run.cmd

(Ctrl+C per terminare)




4) Note e commenti

• bzip2.c multipli per riga separati da un simbolo (@ oppure un riquadro, a seconda della lingua di sistema) sono OK.
  
• Errori di "Unhandled Exception" o crash di cmd.exe (Windows Command Processor) come visualizzato negli screenshot più giù oppure più raramente di cl.exe (Microsoft C Compiler) indicano possibili problemi di segfault.
  
• Errori di "Internal compiler error" poco prima di quelli di "Unhandled Exception" sono anch'essi indicativi di problemi hardware (segfault, ecc).
  
• Errori di "Internal compiler error" quando si preme CTRL+C invece non indicano problemi in tal senso.
  
• Secondo l'autore (2, 3, 4. Fonte), sulle CPU affette dal bug ci vuole più tempo rispetto all'altro test sotto Linux affinché gli errori escano fuori, dunque non abbiate troppa fretta.
  
• Una funzionalità non documentata è la possibilità di aumentare il numero di thread coinvolti nell'operazione. Questo si può fare con facendo seguire a run.cmd il flag -j n dove n è il numero di thread. Di default dovrebbe essere il numero di core logici del processore. Esempio:
  

  run.cmd -j 32

bzip2.c

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.Exception: FAIL
   at kill_ryzen_win.Program.<>c.<Main>b__0_0(Int32 x) in [...]\Program.cs:line 26
   at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
   at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Parallel.ForWorker[TLocal](Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Func`4 bodyWithLocal, Func`1 localInit, Action`1 localFinally)
   at System.Threading.Tasks.Parallel.For(Int32 fromInclusive, Int32 toExclusive, Action`1 body)
   at kill_ryzen_win.Program.Main(String[] args) in C:\Users\davidm\Downloads\kill-ryzen-win-master\Program.cs:line 34

kill-ryzen-win>

5) Note aggiuntive

Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.



Provvedere a disabilitarlo temporaneamente:

Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)



Cliccare "Virus & Threat Protection Settings"



Real-Time Protection -> Off



Ricordarsi di riattivarlo ad operazione ultimata.

[Giorgio G]

Originariamente inviato da fedexx2

Il mio 1700X datato "1717 SUT" ha presentato il bug e oggi parte per la sostituzione (spedizione di andata pagata da AMD).

Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene

Fai sapere se il ryzen 1200 risulta affetto dal problema? E poi gentilmente se puoi dire quando lo hai comprato (R3 1200 datato "1725PGT"), per regolarmi per un eventuale acquisto, dato che anche io lo voglio prendere per tamponare la mancanza del mio 1700.

[fedexx2]

Originariamente inviato da Giorgio G

Fai sapere se il ryzen 1200 risulta affetto dal problema? E poi gentilmente se puoi dire quando lo hai comprato (R3 1200 datato "1725PGT"), per regolarmi per un eventuale acquisto, dato che anche io lo voglio prendere per tamponare la mancanza del mio 1700.

Ho sotto test il Ryzen 1200 proprio ora, son passati circa 20 minuti e ancora nessun errore, quando invece il 1700x dava l'errore dopo nemmeno 1 minuto.
L'ho preso da amazon 3 giorni fa.

[Operapia]

Originariamente inviato da s12a

Forse serve una procedura più collaudata per eseguire il test su Windows nativamente. Nell'altro thread fra un post e l'altro era stato spiegato come fare per kill-ryzen-win. Ecco nuovamente in un formato più accessibile e chiaro.


1) Scaricare kill-ryzen-win
Download: https://github.com/corngood/kill-ryz...ive/master.zip
Fonte: https://github.com/corngood/kill-ryzen-win

Scompattare il file .zip in una directory facilmente accessibile da riga di comando.


2) Scaricare ed installare Build Tools for Visual Studio 2017
Download: https://www.visualstudio.com/thank-y...ldTools&rel=15
Fonte: https://www.visualstudio.com/downloa...al-studio-2017

Eseguire "vs_buildtools.exe"



Selezionare le tre opzioni elencate e poi premere "install":

• Visual C++ build tools
• Web development build tools
• .NET Core build tools

5.26GB occupati a fine installazione (indicati dall'installer)
1.28GB da scaricare in totale (verificato)



Installazione...




3) Build&Run
Start Menu > digitare/selezionare "Developer Command Prompt for VS 2017"

Dalla finestra di riga di comando apparsa (sostituire a x:\downloads\ecc il percorso dove kill-ryzen-win è stato scompattato):

cd /D x:\downloads\kill-ryzen-win 
build.cmd

run.cmd

(Ctrl+C per terminare)




4) Note e commenti

• bzip2.c multipli per riga separati da un simbolo (@ oppure un riquadro, a seconda della lingua di sistema) sono OK.
  
• Errori di "Unhandled Exception" o crash di cmd.exe (Windows Command Processor) come visualizzato negli screenshot più giù oppure più raramente di cl.exe (Microsoft C Compiler) indicano possibili problemi di segfault.
  
• Errori di "Internal compiler error" poco prima di quelli di "Unhandled Exception" sono anch'essi indicativi di problemi hardware (segfault, ecc).
  
• Errori di "Internal compiler error" quando si preme CTRL+C invece non indicano problemi in tal senso.
  
• Secondo l'autore (2, 3, 4. Fonte), sulle CPU affette dal bug ci vuole più tempo rispetto all'altro test sotto Linux affinché gli errori escano fuori, dunque non abbiate troppa fretta.
  
• Una funzionalità non documentata è la possibilità di aumentare il numero di thread coinvolti nell'operazione. Questo si può fare con facendo seguire a run.cmd il flag -j n dove n è il numero di thread. Di default dovrebbe essere il numero di core logici del processore. Esempio:
  

  run.cmd -j 32

bzip2.c

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.Exception: FAIL
   at kill_ryzen_win.Program.<>c.<Main>b__0_0(Int32 x) in [...]\Program.cs:line 26
   at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
   at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Parallel.ForWorker[TLocal](Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Func`4 bodyWithLocal, Func`1 localInit, Action`1 localFinally)
   at System.Threading.Tasks.Parallel.For(Int32 fromInclusive, Int32 toExclusive, Action`1 body)
   at kill_ryzen_win.Program.Main(String[] args) in C:\Users\davidm\Downloads\kill-ryzen-win-master\Program.cs:line 34

kill-ryzen-win>

5) Note aggiuntive

Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.



Provvedere a disabilitarlo temporaneamente:

Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)



Cliccare "Virus & Threat Protection Settings"



Real-Time Protection -> Off



Ricordarsi di riattivarlo ad operazione ultimata.

A me con questa procedura non dava nulla.
Sotto linux invece sbam, errore

[s12a]

Originariamente inviato da Operapia

A me con questa procedura non dava nulla.
Sotto linux invece sbam, errore

Puoi per favore rimuovere o ridurre sostanzialmente il quote (nel caso debba in futuro aggiornare il post, in maniera che non ci siano in giro versioni "vecchie" visibili)?

Inoltre: puoi riprovare lo stesso test su Windows facendolo partire il comando con "run.cmd -j 32" (oppure al posto di 32 un valore abbastanza superiore al numero di core logici del processore) e disattivando temporaneamente Windows Defender come spiegato nella mini-guida sopra?

[Giorgio G]

Originariamente inviato da fedexx2

Ho sotto test il Ryzen 1200 proprio ora, son passati circa 20 minuti e ancora nessun errore, quando invece il 1700x dava l'errore dopo nemmeno 1 minuto.
L'ho preso da amazon 3 giorni fa.

Grazie intanto, mi sa che aspetto a prenderlo, tre giorni fa e ancora 25° settimana
ho paura che con la mia fortuna ti becco ancora uno con problemi, fai sapere comunque come va il test

[s12a]

Originariamente inviato da Ozozuz

Per chi fosse interessato alle tempistiche di RMA, consegnato il pacco lunedí con DHL prepagato da AMD che mi ha fornito un account utente dal quale poi direttamente ad un dhl point hanno fatto partire il pacco.
Partito ieri, arrivato oggi in mattinata, vediamo quanto ci mettono a farmi sapere qualcosa e rispedirlo.

Avranno cambiato politica sulle spedizioni? Sei il terzo utente nel thread a cui viene offerta una spedizione prepagata in andata per l'RMA.