alexsky8
20-10-2017, 12:15
confermo, dopo 40 minuti di test con SMT off nessun errore
View Full Version : [Discussione] AMD Ryzen - problematiche di Segmentation Fault (segfault)
alexsky8
20-10-2017, 12:17
Scusa moob1, non mi ricordavo che questa è la nuova CPU che hai ricevuto da Amazon (http://www.hwupgrade.it/forum/showthread.php?p=45108108#post45108108) e che sembra essere particolarmente fortunata in overclock (http://www.hwupgrade.it/forum/showpost.php?p=45108135&postcount=20732) rispetto alla precedente che mostrava il problema di segmentation fault. Allora non dovresti avere problemi.
anche la mia sale bene in OC ma presenta errore (con 16 core attivi) ed è più o meno della stessa settimana 33 vs 34
ora come ultimo tentativo proverò ad installare ubuntu su SSD invece che utilizzare una live
anche la mia sale bene in OC ma presenta errore (con 16 core attivi) ed è più o meno della stessa settimana 33 vs 34
ora come ultimo tentativo proverò ad installare ubuntu su SSD invece che utilizzare una live
s12a
20-10-2017, 12:20
confermo, dopo 40 minuti di test con SMT off nessun errore
Su Phoronix nel forum è stato riportato questo (https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue?p=973122#post973122) come riassunto delle informazioni ricavate dagli altri utenti:
The only setting that are confirmed by users to have an impact are
disable µOP cache - makes the problem go away, or at least much harder to trigger
disable SMT - increases time between segfaults from a couple minutes before, to at least several hours afterwards
disable kernel ASLR - similar as above
Not confirmed, but some individuals report improvement while others don't:
disable XMP profiles and relax memory clock/timings to safe values
enable LLC (load line calibration)
increase CPU SoC voltage
(Edit: thanks Anty for pointing out that it is not CPU Vcore, but actually SoC voltage where an increase might have an effect)
Far andare la CPU a 2/3 - 3/4 del dovuto potrebbe non essere accettabile per tutti, però.
Su Phoronix nel forum è stato riportato questo (https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue?p=973122#post973122) come riassunto delle informazioni ricavate dagli altri utenti:
The only setting that are confirmed by users to have an impact are
disable µOP cache - makes the problem go away, or at least much harder to trigger
disable SMT - increases time between segfaults from a couple minutes before, to at least several hours afterwards
disable kernel ASLR - similar as above
Not confirmed, but some individuals report improvement while others don't:
disable XMP profiles and relax memory clock/timings to safe values
enable LLC (load line calibration)
increase CPU SoC voltage
(Edit: thanks Anty for pointing out that it is not CPU Vcore, but actually SoC voltage where an increase might have an effect)
Far andare la CPU a 2/3 - 3/4 del dovuto potrebbe non essere accettabile per tutti, però.
Mister D
20-10-2017, 12:26
non posso permettermi la sostituzione con un altro prodotto potenzialmente affetto dall'errore perchè qua il problema è differente rispetto alla semplice selezione
se TR o Epyc ne sono esenti con uno step successivo attenderò anche Ryzen ad uno step successivo
Nonostante sia scritto in prima pagina lo ripeto:
Epyc step B2
Ryzen e TR step B1, diventano TR solo il 5% dei die funzionanti di ryzen.
Cmq la tua cpu te la sei fatta cambiare attraverso il venditore o amd? Se te la sei fatta cambiare attraverso il venditore perché non passi da AMD che te ne invia una sicuramente esente?
se TR o Epyc ne sono esenti con uno step successivo attenderò anche Ryzen ad uno step successivo
Nonostante sia scritto in prima pagina lo ripeto:
Epyc step B2
Ryzen e TR step B1, diventano TR solo il 5% dei die funzionanti di ryzen.
Cmq la tua cpu te la sei fatta cambiare attraverso il venditore o amd? Se te la sei fatta cambiare attraverso il venditore perché non passi da AMD che te ne invia una sicuramente esente?
Mister D
20-10-2017, 12:31
Su Phoronix nel forum è stato riportato questo (https://www.phoronix.com/forums/forum/hardware/processors-memory/971859-new-ryzen-is-running-solid-under-linux-no-compiler-segmentation-fault-issue?p=973122#post973122) come riassunto delle informazioni ricavate dagli altri utenti:
Far andare la CPU a 2/3 - 3/4 del dovuto potrebbe non essere accettabile per tutti, però.
Certamente, io cmq farei così:
1) disabiliterei kernel ASRL
2) userei LLC per trovare il miglior settaggio che faccia droppare meno la cpu, cioè in test come prime95 occt ecc quando la cpu va in full deve perdere meno di 0,05 volt
3) non userei XMP (che è una tecnologia intel per profili ram su MC intel) e imposterei in manuale la ram abbassando se mai la frequenza
4) imposterei il vsoc tra 1 volt e 1,15 volt.
Se anche così tutto a def (che vuol dire tenere boost, smt attivo, vcore auto e impostazioni "optimized defualt setting" caricata) il test mi da errore farei rma con amd.
Far andare la CPU a 2/3 - 3/4 del dovuto potrebbe non essere accettabile per tutti, però.
Certamente, io cmq farei così:
1) disabiliterei kernel ASRL
2) userei LLC per trovare il miglior settaggio che faccia droppare meno la cpu, cioè in test come prime95 occt ecc quando la cpu va in full deve perdere meno di 0,05 volt
3) non userei XMP (che è una tecnologia intel per profili ram su MC intel) e imposterei in manuale la ram abbassando se mai la frequenza
4) imposterei il vsoc tra 1 volt e 1,15 volt.
Se anche così tutto a def (che vuol dire tenere boost, smt attivo, vcore auto e impostazioni "optimized defualt setting" caricata) il test mi da errore farei rma con amd.
malcom499
20-10-2017, 12:35
[Imgur](https://i.imgur.com/9yiEzqp.jpg)
Appena arrivato da amazon...UA 1733SUS ...33esima settimana del 2017 giusto?
Finisco di assemblare il pc e faccio test..vi faccio sapere
Appena arrivato da amazon...UA 1733SUS ...33esima settimana del 2017 giusto?
Finisco di assemblare il pc e faccio test..vi faccio sapere
alexsky8
20-10-2017, 12:37
Nonostante sia scritto in prima pagina lo ripeto:
Epyc step B2
Ryzen e TR step B1, diventano TR solo il 5% dei die funzionanti di ryzen.
Cmq la tua cpu te la sei fatta cambiare attraverso il venditore o amd? Se te la sei fatta cambiare attraverso il venditore perché non passi da AMD che te ne invia una sicuramente esente?
attraverso il venditore (Amazon)
non passo attraverso AMD perchè non ho un PC muletto da utilizzare e mi serve anche per lavoro
attenderò uno step successivo per sostituirla
Epyc step B2
Ryzen e TR step B1, diventano TR solo il 5% dei die funzionanti di ryzen.
Cmq la tua cpu te la sei fatta cambiare attraverso il venditore o amd? Se te la sei fatta cambiare attraverso il venditore perché non passi da AMD che te ne invia una sicuramente esente?
attraverso il venditore (Amazon)
non passo attraverso AMD perchè non ho un PC muletto da utilizzare e mi serve anche per lavoro
attenderò uno step successivo per sostituirla
papugo1980
20-10-2017, 12:46
Scusate poi sul forum rog Asus ho letto di un utente che ha sostituito la cpu e quella bacata era prodotta in Taiwan e quella sostitutiva prodotta in China
Può centrare pure qualcosa?
Può centrare pure qualcosa?
alexsky8
20-10-2017, 12:49
la mia nuova in Malaysia
Mister D
20-10-2017, 12:50
attraverso il venditore (Amazon)
non passo attraverso AMD perchè non ho un PC muletto da utilizzare e mi serve anche per lavoro
attenderò uno step successivo per sostituirla
Dubito fortemente che AMD si metta a fare step produttivi per ryzen prima generazione:
1) a febbraio 2018 presenta con tutta probabilità pinnacle ridge sui 12 nm (14+) e agesa 1.0.0.7 è in distribuzione dai produttori di MB. Questo agesa rivede completamente la struttura del bios per essere più flessibile circa l'aggiornamento di cpu e da il supporto alle APU raven ridge e alle CPU pinnacle ridge. Ergo vuol dire che non siamo così lontani.
2) non avrebbe cmq senso fare un stepping per un problema di selezione delle cpu, visto che di questo si tratta dato che NON tutte le cpu prodotte inizialmente hanno mostrato questo noioso, e rilevante per alcuni, problema (utenti come darkangel e TCx non hanno segmentation fault e manco il redattore di phoronix con un 1700 di 3 settimana mi pare). Uno stepping viene fatto per motivi economici come resa superiore e per risolvere bug hardware che impattano su tutte le cpu e che non si possono risolvere con workaround da bios o che, anche se si possono risolvere con workaroung, generano una penalità prestazionale troppo elevata (es il bug sulla TLB dei primi phenom a 65 nm, risolto con uno stepping successivo). Visto che non si tratta di ciò, AMD penso proprio non farà nessun stepping ma, giustamente a parar mio, ha modificato il suo quality test di selezione cpu e assicurato RMA per tutti i clienti che hanno una cpu con questo bug (sottolineo condizione minima, visto che di legge).
Il problema, grave, è che uno poteva benissimo dichiarare da quale settimana di produzione si faceva partire la nuova selezione e due poteva già pubblicare tutti gli errata, e tre fare un programmino per determinare se la cpu è sana o no da mettere sul proprio sito. Io avrei fatto così per essere il più trasparente possibile e tutelare la fiducia dei miei clienti, che così facendo purtroppo può venire meno (ognuno di noi ha una percezione diversa della fidelizzazione e soddisfazione). IMHO;)
non passo attraverso AMD perchè non ho un PC muletto da utilizzare e mi serve anche per lavoro
attenderò uno step successivo per sostituirla
Dubito fortemente che AMD si metta a fare step produttivi per ryzen prima generazione:
1) a febbraio 2018 presenta con tutta probabilità pinnacle ridge sui 12 nm (14+) e agesa 1.0.0.7 è in distribuzione dai produttori di MB. Questo agesa rivede completamente la struttura del bios per essere più flessibile circa l'aggiornamento di cpu e da il supporto alle APU raven ridge e alle CPU pinnacle ridge. Ergo vuol dire che non siamo così lontani.
2) non avrebbe cmq senso fare un stepping per un problema di selezione delle cpu, visto che di questo si tratta dato che NON tutte le cpu prodotte inizialmente hanno mostrato questo noioso, e rilevante per alcuni, problema (utenti come darkangel e TCx non hanno segmentation fault e manco il redattore di phoronix con un 1700 di 3 settimana mi pare). Uno stepping viene fatto per motivi economici come resa superiore e per risolvere bug hardware che impattano su tutte le cpu e che non si possono risolvere con workaround da bios o che, anche se si possono risolvere con workaroung, generano una penalità prestazionale troppo elevata (es il bug sulla TLB dei primi phenom a 65 nm, risolto con uno stepping successivo). Visto che non si tratta di ciò, AMD penso proprio non farà nessun stepping ma, giustamente a parar mio, ha modificato il suo quality test di selezione cpu e assicurato RMA per tutti i clienti che hanno una cpu con questo bug (sottolineo condizione minima, visto che di legge).
Il problema, grave, è che uno poteva benissimo dichiarare da quale settimana di produzione si faceva partire la nuova selezione e due poteva già pubblicare tutti gli errata, e tre fare un programmino per determinare se la cpu è sana o no da mettere sul proprio sito. Io avrei fatto così per essere il più trasparente possibile e tutelare la fiducia dei miei clienti, che così facendo purtroppo può venire meno (ognuno di noi ha una percezione diversa della fidelizzazione e soddisfazione). IMHO;)
s12a
20-10-2017, 13:12
👉 Non so se sia evidente a sufficienza, ma il primo post del thread è sempre in fase di aggiornamento con nuove informazioni e link mano a mano che vengono postati nella discussione. Al momento sono 28.5 kilobyte fra testo e BBCode.
Gioz
20-10-2017, 13:13
ah ok ma 1,2 in effetti mi sembra altino
di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
Mister D
20-10-2017, 13:50
di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
Grazie Gioz, ma confidi troppo nella mia memoria :D
Non mi ricordo la video guida ma mi ricordo di asus e i 1,2 volt e di altri che dicevano 1,15 come daily use più safe con ram SR oltre i 2666.
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
Grazie Gioz, ma confidi troppo nella mia memoria :D
Non mi ricordo la video guida ma mi ricordo di asus e i 1,2 volt e di altri che dicevano 1,15 come daily use più safe con ram SR oltre i 2666.
alexsky8
20-10-2017, 13:54
Dubito fortemente che AMD si metta a fare step produttivi per ryzen prima generazione:
sì era per dire un passaggio successivo sia esso revisione o p.p. a 12nm
sì era per dire un passaggio successivo sia esso revisione o p.p. a 12nm
alexsky8
20-10-2017, 13:55
di default il vsoc si aggira tra 0.88V circa e 1.1V circa a seconda della ram installata, c'era stata poi una specie di videoguida in cui "non ricordo chi" suggeriva fino a 1.15 per usare memorie samsung b-die a 3200 (mrD sicuro se lo ricorda, mi sa che l'aveva postato lui quel video nel topic principale) ed asus tramite supporto suggeriva di non andare oltre 1.2V per l'uso quotidiano con ram veloci.
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
sì si capisco bene, giustamente stavi cercando una soluzione al problema è giusto che ciascuno possa riportare una propria esperienza per cercare di risolvere o mitigare la questione ;)
in quel caso ho settato cpu in overclock e downvolt (3600MHz contro i 3200 del boost all core e 1.156V contro i 1.187V stock) abbinato ad un forte overvolt del soc (1.2V contro gli 0.88V che imposterebbe in auto settando le ram a 2133), non intendevo suggerire a tutti di aumentare senza criterio il Vsoc come soluzione ma trovavo potenzialmente interessante valutare se questa situazione possa avere altri riscontri.
se uno ha la cpu che va in segfault la soluzione è l'rma tramite AMD, così da avere certezza di risolvere il problema, non sovra alimentare il soc.
sì si capisco bene, giustamente stavi cercando una soluzione al problema è giusto che ciascuno possa riportare una propria esperienza per cercare di risolvere o mitigare la questione ;)
bagnino89
20-10-2017, 13:55
è chiaro che sta storia andrà avanti fino al prossimo step produttivo
Lo penso anche io. Se poi AMD non rende chiara e pubblica la questione...
Per legge, dopo aver riscontrato un difetto hai massimo 2 mesi per restituire il prodotto, altrimenti perdi il diritto alla garanzia su quel difetto...
Se AMD non dichiara nulla ufficialmente, io potrei benissimo accorgermi dell'errore ad 1 mese dalla scadenza della garanzia...
comunque attendo la revisione 2 di ryzen e poi chiamo AMazon
:winner:
ci mancherebbe ma qua sarebbe ben peggio farsi sostituire 10 CPU per averne una buona e aprire 10 sigilli; credo che la soluzione migliore per tutti sia attendere Ryzen 2 o comunque una revisione
10gg senza CPU per fare RMA da AMD per ora non ci penso neppure
Quoto.
Di sicuro non è una soluzione per tutti (magari chi ha bisogno di assoluta stabilità sin da subito se la fa sostituire il prima possibile), ma nel mio caso non vedo questa imminente necessità. Chiaro che, se risconterò problemi, provvederò immediatamente anche io.
Poi sta di fatto che, in ogni caso, avere hardware con bug non è mai consigliabile.
Lo penso anche io. Se poi AMD non rende chiara e pubblica la questione...
Per legge, dopo aver riscontrato un difetto hai massimo 2 mesi per restituire il prodotto, altrimenti perdi il diritto alla garanzia su quel difetto...
Se AMD non dichiara nulla ufficialmente, io potrei benissimo accorgermi dell'errore ad 1 mese dalla scadenza della garanzia...
comunque attendo la revisione 2 di ryzen e poi chiamo AMazon
:winner:
ci mancherebbe ma qua sarebbe ben peggio farsi sostituire 10 CPU per averne una buona e aprire 10 sigilli; credo che la soluzione migliore per tutti sia attendere Ryzen 2 o comunque una revisione
10gg senza CPU per fare RMA da AMD per ora non ci penso neppure
Quoto.
Di sicuro non è una soluzione per tutti (magari chi ha bisogno di assoluta stabilità sin da subito se la fa sostituire il prima possibile), ma nel mio caso non vedo questa imminente necessità. Chiaro che, se risconterò problemi, provvederò immediatamente anche io.
Poi sta di fatto che, in ogni caso, avere hardware con bug non è mai consigliabile.
alexsky8
20-10-2017, 13:59
Installato, ho fatto l'upgrade della 17.04. Sono anche in overclock a 4GHz @ 1.33v e vSOC a 1.1v
Quasi 10 minuti, tutto a default, nessun errore.
ho INSTALLATO (no live quindi) UBUNTU 17.10 su SSD, ho fatto partire il test Oxalin con tutti e 16 i core attivi, sta girando da 13 minuti e nessun errore (per ora)
con la live mediamente dopo 2-3 minuti mi dava errore....lascio girare ancora per vedere se va in segfault
Quasi 10 minuti, tutto a default, nessun errore.
ho INSTALLATO (no live quindi) UBUNTU 17.10 su SSD, ho fatto partire il test Oxalin con tutti e 16 i core attivi, sta girando da 13 minuti e nessun errore (per ora)
con la live mediamente dopo 2-3 minuti mi dava errore....lascio girare ancora per vedere se va in segfault
Mister D
20-10-2017, 14:00
sì era per dire un passaggio successivo sia esso revisione o p.p. a 12nm
Ok ma il fatto di passare a pinnacle ridge non è correlato con questo bug in quanto già ora le cpu prodotte dopo il nuovo quality test sono esenti dal problema e che pinnacle ridge, come tutte le altre cpu di questa terra, avrà anch'esso dei bug. Ovviamente mi pare lapalissiano che se già ora hanno sistemato la selezione per le nuove cpu, sarebbe da fessi avere lo stesso problema di selezioni per le nuove cpu.
Cmq visto che agesa 1.0.0.7 già parla di supporto a pinnacle ridge direi che hai una conferma indiretta che revisioni non ce ne saranno dei ryzen 1000 ma ci saranno i nuovi su p.p. a 12nm.;)
Ok ma il fatto di passare a pinnacle ridge non è correlato con questo bug in quanto già ora le cpu prodotte dopo il nuovo quality test sono esenti dal problema e che pinnacle ridge, come tutte le altre cpu di questa terra, avrà anch'esso dei bug. Ovviamente mi pare lapalissiano che se già ora hanno sistemato la selezione per le nuove cpu, sarebbe da fessi avere lo stesso problema di selezioni per le nuove cpu.
Cmq visto che agesa 1.0.0.7 già parla di supporto a pinnacle ridge direi che hai una conferma indiretta che revisioni non ce ne saranno dei ryzen 1000 ma ci saranno i nuovi su p.p. a 12nm.;)
SL45i
20-10-2017, 14:03
ragazzi per quanto riguarda il test ho installato una macchina virtuale ed ho installato ubuntu va bene lo stesso il test nella macchina virtuale?
s12a
20-10-2017, 14:16
ragazzi per quanto riguarda il test ho installato una macchina virtuale ed ho installato ubuntu va bene lo stesso il test nella macchina virtuale?
Sì, dovrebbe, in particolar modo se la tua CPU ha le estensioni per la virtualizzazione attivate (in tal modo l'operazione è praticamente come eseguirla nativamente). Usare una distribuzione Live è semplicemente una "procedura standard" facilmente replicabile.
Il problema se esistente deve essere riproducibile anche in modi simili usando metodi diversi.
Sì, dovrebbe, in particolar modo se la tua CPU ha le estensioni per la virtualizzazione attivate (in tal modo l'operazione è praticamente come eseguirla nativamente). Usare una distribuzione Live è semplicemente una "procedura standard" facilmente replicabile.
Il problema se esistente deve essere riproducibile anche in modi simili usando metodi diversi.
alexsky8
20-10-2017, 14:30
adesso mi da un altro tipo di errore ma dopo 20 minuti
https://i.imgur.com/1vkeZes.png
https://i.imgur.com/1vkeZes.png
moob1
20-10-2017, 14:36
adesso mi da un altro tipo di errore ma dopo 20 minuti
https://i.imgur.com/1vkeZes.png
Non credo che la cpu sia affetta da segfault sinceramente.
https://i.imgur.com/1vkeZes.png
Non credo che la cpu sia affetta da segfault sinceramente.
s12a
20-10-2017, 14:42
adesso mi da un altro tipo di errore ma dopo 20 minuti
https://i.imgur.com/1vkeZesl.png
Alcuni degli avvisi (non veri e propri errori) come quello riportati dal kernel durante il test non dipendono dallo stato del test in sé e non sono indicativi di problemi con la CPU.
Il test dovrebbe continuare ad andare fino a che non dice "build failed". Da una rapida ricerca su Google:
https://bbs.archlinux.org/viewtopic.php?id=187636
I get:
perf interrupt took too long (2503 > 2495), lowering kernel.perf_event_max_sample_rate to 50100.
Every ~5 hours in dmesg. [...]
Any clue highly appreciated.
This is informational and nothing to worry about. It has to do with the Linux perf tool which is included in the kernel. The kernel automagically determines the sample rate that could be used without impacting system performance too much; and it logs this even when perf isn't active, or even installed. Messages like this are triggered by high(er) system load or a cpu that is scaling
EDIT: a proposito, puoi provare a digitare dal terminale questo comando e riportare il risultato?
sysctl kernel.randomize_va_space
Se risponde "2", lo Address Space Layout Randomization (ASLR) è abilitato. Magari sulla versione installata di Ubuntu 17.10 è disabilitato?
https://i.imgur.com/1vkeZesl.png
Alcuni degli avvisi (non veri e propri errori) come quello riportati dal kernel durante il test non dipendono dallo stato del test in sé e non sono indicativi di problemi con la CPU.
Il test dovrebbe continuare ad andare fino a che non dice "build failed". Da una rapida ricerca su Google:
https://bbs.archlinux.org/viewtopic.php?id=187636
I get:
perf interrupt took too long (2503 > 2495), lowering kernel.perf_event_max_sample_rate to 50100.
Every ~5 hours in dmesg. [...]
Any clue highly appreciated.
This is informational and nothing to worry about. It has to do with the Linux perf tool which is included in the kernel. The kernel automagically determines the sample rate that could be used without impacting system performance too much; and it logs this even when perf isn't active, or even installed. Messages like this are triggered by high(er) system load or a cpu that is scaling
EDIT: a proposito, puoi provare a digitare dal terminale questo comando e riportare il risultato?
sysctl kernel.randomize_va_space
Se risponde "2", lo Address Space Layout Randomization (ASLR) è abilitato. Magari sulla versione installata di Ubuntu 17.10 è disabilitato?
moob1
20-10-2017, 14:53
Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
Mister D
20-10-2017, 14:58
Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
:doh: novella 2000 colpisce ancora :asd:
Battuta ON
E qui date contro a quelli del thread ufficiale tacciati di voler insabbiare, quando là fuori è pure peggio :asd:
Battuta OFF
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
:doh: novella 2000 colpisce ancora :asd:
Battuta ON
E qui date contro a quelli del thread ufficiale tacciati di voler insabbiare, quando là fuori è pure peggio :asd:
Battuta OFF
evil weasel
20-10-2017, 15:00
Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
Povero italiano. :D
https://i.imgur.com/VhxLviT.png
Questo è il livello di competenza sugli altri forum, giudicate voi.
Povero italiano. :D
alexsky8
20-10-2017, 15:25
Se risponde "2", lo Address Space Layout Randomization (ASLR) è abilitato. Magari sulla versione installata di Ubuntu 17.10 è disabilitato?
mi da = 2 ma non capisco cosa significhi in pratica
https://i.imgur.com/u5uQzZg.png
l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%
mi da = 2 ma non capisco cosa significhi in pratica
https://i.imgur.com/u5uQzZg.png
l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%
CiccoMan
20-10-2017, 15:30
Scusate ma non resisto, ho provato a spiegare in un thread incentrato sull'overclock di un Ryzen sfortunato che poteva essere affetto da segfault, la conclusione del mod di sezione è stata:
[img]
Questo è il livello di competenza sugli altri forum, giudicate voi.
Membro dello staff :doh:
Dimmi dove abita, che per natale gli mando una tastiera... la sua deve essere rotta :asd:
[img]
Questo è il livello di competenza sugli altri forum, giudicate voi.
Membro dello staff :doh:
Dimmi dove abita, che per natale gli mando una tastiera... la sua deve essere rotta :asd:
s12a
20-10-2017, 15:31
mi da = 2 ma non capisco cosa significhi in pratica
https://i.imgur.com/u5uQzZg.png
L'ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization) è una funzionalità che si suppone aumenti la probabilità di osservare segfault e simili con Linux sulle CPU Ryzen. Se però il comando ti riporta "2" vuol dire che non è che non sembri più osservare segfault perché è disabilitata.
l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%
Vista dove?
Da Linux solitamente "free memory" ha un significato diverso quello che sembra:
https://www.linuxatemyram.com/
https://i.imgur.com/u5uQzZg.png
L'ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization) è una funzionalità che si suppone aumenti la probabilità di osservare segfault e simili con Linux sulle CPU Ryzen. Se però il comando ti riporta "2" vuol dire che non è che non sembri più osservare segfault perché è disabilitata.
l'unica cosa che ho notato è che l'occupazione della memoria era poco oltre il 90%
Vista dove?
Da Linux solitamente "free memory" ha un significato diverso quello che sembra:
https://www.linuxatemyram.com/
ccmarco2004
20-10-2017, 15:37
Povero italiano. :D
Esatto, sembra la trascrizione di un dialogo del GFV fatta dalla Gialappa's Band.
Sarebbe interessante creare una sorta di database con i dati relativi alle cpu soggette al problema (seriale, lotto, made in X, etc) e pubblicarne il contenuto sotto forma di tabella in testa al 3ad.
Magari è già stato fatto altrove.
Esatto, sembra la trascrizione di un dialogo del GFV fatta dalla Gialappa's Band.
Sarebbe interessante creare una sorta di database con i dati relativi alle cpu soggette al problema (seriale, lotto, made in X, etc) e pubblicarne il contenuto sotto forma di tabella in testa al 3ad.
Magari è già stato fatto altrove.
s12a
20-10-2017, 15:39
Sarebbe interessante creare una sorta di database con i dati relativi alle cpu soggette al problema (seriale, lotto, made in X, etc) e pubblicarne il contenuto sotto forma di tabella in testa al 3ad.
Magari è già stato fatto altrove.
Qualcuno l'ha fatto tempo fa per i processori di alcuni utenti del forum sul sito AMD e Reddit. Non credo che la lista sia aggiornata e/o esaustiva:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
EDIT: ed in parte anche qui:
https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit#gid=950983791
Magari è già stato fatto altrove.
Qualcuno l'ha fatto tempo fa per i processori di alcuni utenti del forum sul sito AMD e Reddit. Non credo che la lista sia aggiornata e/o esaustiva:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
EDIT: ed in parte anche qui:
https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit#gid=950983791
SL45i
20-10-2017, 15:51
ho fatto una prova in remoto e mi da l'errore opcode ma ho le ram overclockate, può essere questo?
s12a
20-10-2017, 15:53
ho fatto una prova in remoto e mi da l'errore opcode ma ho le ram overclockate, può essere questo?
È possibile; meglio testare con il PC a default e memorie in modalità fail-safe (2400 o addirittura 2133 MHZ).
È possibile; meglio testare con il PC a default e memorie in modalità fail-safe (2400 o addirittura 2133 MHZ).
alexsky8
20-10-2017, 16:24
L'ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization) è una funzionalità che si suppone aumenti la probabilità di osservare segfault e simili con Linux sulle CPU Ryzen. Se però il comando ti riporta "2" vuol dire che non è che non sembri più osservare segfault perché è disabilitata.
Vista dove?
Da Linux solitamente "free memory" ha un significato diverso quello che sembra:
https://www.linuxatemyram.com/
da cronologia memoria e swap
comunque l'errore ogni tanto esce random quindi inutile proseguire per ora vedremo il dafarsi con calma
https://i.imgur.com/5lvElaM.png
Vista dove?
Da Linux solitamente "free memory" ha un significato diverso quello che sembra:
https://www.linuxatemyram.com/
da cronologia memoria e swap
comunque l'errore ogni tanto esce random quindi inutile proseguire per ora vedremo il dafarsi con calma
https://i.imgur.com/5lvElaM.png
SL45i
20-10-2017, 16:47
È possibile; meglio testare con il PC a default e memorie in modalità fail-safe (2400 o addirittura 2133 MHZ).
grazie, sono davvero amareggiato, questa volta se anche questa cpu ha problemi mi sa che abbandono amd, questo cambio piattaforma è stato uno strazio... scusate lo sfogo, comunque sia l'unica cosa che non ho capito per certo è se questo problema alla fine è riscontrabile in windows oppure è solo una cosa di linux... :(
grazie, sono davvero amareggiato, questa volta se anche questa cpu ha problemi mi sa che abbandono amd, questo cambio piattaforma è stato uno strazio... scusate lo sfogo, comunque sia l'unica cosa che non ho capito per certo è se questo problema alla fine è riscontrabile in windows oppure è solo una cosa di linux... :(
s12a
20-10-2017, 16:53
da cronologia memoria e swap
comunque l'errore ogni tanto esce random quindi inutile proseguire per ora vedremo il dafarsi con calma
Se esce allora nulla da fare, l'installazione non varia il risultato.
grazie, sono davvero amareggiato, questa volta se anche questa cpu ha problemi mi sa che abbandono amd, questo cambio piattaforma è stato uno strazio... scusate lo sfogo, comunque sia l'unica cosa che non ho capito per certo è se questo problema alla fine è riscontrabile in windows oppure è solo una cosa di linux... :(
C'è una procedura per testarlo su Windows con i tool nativi di Windows, ma richiede Visual Studio Community 2017.
https://github.com/corngood/kill-ryzen-win
https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j8tw1usg&sh=e653ba6f
https://www.reddit.com/r/Amd/comments/6znui8/im_chasing_a_cmdexe_crash_in_win10_on_r7_1700_has/?st=j904jsgw&sh=c6fdc3f9
comunque l'errore ogni tanto esce random quindi inutile proseguire per ora vedremo il dafarsi con calma
Se esce allora nulla da fare, l'installazione non varia il risultato.
grazie, sono davvero amareggiato, questa volta se anche questa cpu ha problemi mi sa che abbandono amd, questo cambio piattaforma è stato uno strazio... scusate lo sfogo, comunque sia l'unica cosa che non ho capito per certo è se questo problema alla fine è riscontrabile in windows oppure è solo una cosa di linux... :(
C'è una procedura per testarlo su Windows con i tool nativi di Windows, ma richiede Visual Studio Community 2017.
https://github.com/corngood/kill-ryzen-win
https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j8tw1usg&sh=e653ba6f
https://www.reddit.com/r/Amd/comments/6znui8/im_chasing_a_cmdexe_crash_in_win10_on_r7_1700_has/?st=j904jsgw&sh=c6fdc3f9
Giorgio G
20-10-2017, 18:05
Ho fatto delle prove, la prima il 1700 a 3.7ghz e ram 3066mhz, dopo poco errore
https://s1.postimg.org/69mimt51q3/image.png (https://postimg.org/image/69mimt51q3/)
poi tutto a default, dopo poco errore
https://s1.postimg.org/383dzrhpuz/image.png (https://postimg.org/image/383dzrhpuz/)
in queste due prove avevo SMT (Hyper-Threading di Intel) abilitato (enable) da bios, poi le ho rifatte con SMT su Auto da bios e sia con il processore a Default (ram 2133mhz) e con il 1700 a 3.5ghz (ram 3066mhz) per mezz'ora che ce l'ho tenuto niente errori. Che vuol dire? Che smt su enable disturba il test?
https://s1.postimg.org/69mimt51q3/image.png (https://postimg.org/image/69mimt51q3/)
poi tutto a default, dopo poco errore
https://s1.postimg.org/383dzrhpuz/image.png (https://postimg.org/image/383dzrhpuz/)
in queste due prove avevo SMT (Hyper-Threading di Intel) abilitato (enable) da bios, poi le ho rifatte con SMT su Auto da bios e sia con il processore a Default (ram 2133mhz) e con il 1700 a 3.5ghz (ram 3066mhz) per mezz'ora che ce l'ho tenuto niente errori. Che vuol dire? Che smt su enable disturba il test?
evil weasel
20-10-2017, 18:13
Ho fatto delle prove, la prima il 1700 a 3.7ghz e ram 3066mhz, dopo poco errore
https://s1.postimg.org/69mimt51q3/image.png (https://postimg.org/image/69mimt51q3/)
poi tutto a default, dopo poco errore
https://s1.postimg.org/383dzrhpuz/image.png (https://postimg.org/image/383dzrhpuz/)
in queste due prove avevo SMT (Hyper-Threading di Intel) abilitato (enable) da bios, poi le ho rifatte con SMT su Auto da bios e sia con il processore a Default (ram 2133mhz) e con il 1700 a 3.5ghz (ram 3066mhz) per mezz'ora che ce l'ho tenuto niente errori. Che vuol dire? Che smt su enable disturba il test?
Riavvia il pc e riprova a fare il test, vedrai che anche se non al primo tentativo andrà in errore anche con SMT su auto.
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
https://s1.postimg.org/69mimt51q3/image.png (https://postimg.org/image/69mimt51q3/)
poi tutto a default, dopo poco errore
https://s1.postimg.org/383dzrhpuz/image.png (https://postimg.org/image/383dzrhpuz/)
in queste due prove avevo SMT (Hyper-Threading di Intel) abilitato (enable) da bios, poi le ho rifatte con SMT su Auto da bios e sia con il processore a Default (ram 2133mhz) e con il 1700 a 3.5ghz (ram 3066mhz) per mezz'ora che ce l'ho tenuto niente errori. Che vuol dire? Che smt su enable disturba il test?
Riavvia il pc e riprova a fare il test, vedrai che anche se non al primo tentativo andrà in errore anche con SMT su auto.
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
s12a
20-10-2017, 18:17
Di default non dovrebbe essere attivato in ogni caso?
Comunque, l'SMT contribuisce in maniera sostanziale a far uscire fuori i segfault, ma pare che alla lunga possano accadere lo stesso anche senza.
EDIT: non avevo capito correttamente che si chiedeva se ci fosse differenza fra auto ed enabled.
Comunque, l'SMT contribuisce in maniera sostanziale a far uscire fuori i segfault, ma pare che alla lunga possano accadere lo stesso anche senza.
EDIT: non avevo capito correttamente che si chiedeva se ci fosse differenza fra auto ed enabled.
Giorgio G
20-10-2017, 18:18
Riavvia il pc e riprova a fare il test, vedrai che anche se non al primo tentativo andrà in errore anche con SMT su auto.
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
Si è vero su Auto son sempre 8 core e 16 trhead, ma per quanto ce l'ho tenuto, mezz'ora, non ha dato errore, prima in tre prove, smt su enable, in circa 5 minuti sempre errore. Bho! Riprovo dopo e faccio sapere.
Di default non dovrebbe essere attivato in ogni caso?
Comunque, l'SMT contribuisce in maniera sostanziale a far uscire fuori i segfault, ma pare che alla lunga possano accadere lo stesso anche senza.
A default l'SMT è su Auto
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
Si è vero su Auto son sempre 8 core e 16 trhead, ma per quanto ce l'ho tenuto, mezz'ora, non ha dato errore, prima in tre prove, smt su enable, in circa 5 minuti sempre errore. Bho! Riprovo dopo e faccio sapere.
Di default non dovrebbe essere attivato in ogni caso?
Comunque, l'SMT contribuisce in maniera sostanziale a far uscire fuori i segfault, ma pare che alla lunga possano accadere lo stesso anche senza.
A default l'SMT è su Auto
Spitfire84
20-10-2017, 19:14
Per chi ha chiesto e ottenuto il cambio CPU in garanzia da AMD, quanti giorni sono passati da quando hanno ricevuto la CPU in Olanda a quando ve l'hanno rispedita? E vi hanno avvisato della rispedizione? Vi hanno dato un tracking per seguirla?
Giorgio G
20-10-2017, 19:21
Riavvia il pc e riprova a fare il test, vedrai che anche se non al primo tentativo andrà in errore anche con SMT su auto.
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
Mannaggia mi avete portato sfortuna
https://s1.postimg.org/1u1o7aum4r/image.png (https://postimg.org/image/1u1o7aum4r/)
è andato in errore in poco tempo, però prima per due volte mezz'ora senza errori.
Anche lasciando l'impostazione SMT su auto questo dovrebbe comunque essere attivo.
Mannaggia mi avete portato sfortuna
https://s1.postimg.org/1u1o7aum4r/image.png (https://postimg.org/image/1u1o7aum4r/)
è andato in errore in poco tempo, però prima per due volte mezz'ora senza errori.
s12a
20-10-2017, 19:25
è andato in errore in poco tempo, però prima per due volte mezz'ora senza errori.
Papugo80 aveva già menzionato (http://www.hwupgrade.it/forum/showpost.php?p=45100782&postcount=29) che a volte solo riavviando può accadere quasi subito, altre no:
Riguardo al test su Linux io l ho fatto 4 volte :
La prima e la seconda volta ha dato subito errore
La terza no infatti ero arrivato a 40 minuti e allora ho stoppato
La quarta volta anche subito l errore
Magari è lo stesso caso di alexsky8 (http://www.hwupgrade.it/forum/showpost.php?p=45113832&postcount=320), dove si pensava che installare Ubuntu 17.10 rendesse in qualche modo più difficile osservare il problema piuttosto che usando la distribuzione in modalità live.
Papugo80 aveva già menzionato (http://www.hwupgrade.it/forum/showpost.php?p=45100782&postcount=29) che a volte solo riavviando può accadere quasi subito, altre no:
Riguardo al test su Linux io l ho fatto 4 volte :
La prima e la seconda volta ha dato subito errore
La terza no infatti ero arrivato a 40 minuti e allora ho stoppato
La quarta volta anche subito l errore
Magari è lo stesso caso di alexsky8 (http://www.hwupgrade.it/forum/showpost.php?p=45113832&postcount=320), dove si pensava che installare Ubuntu 17.10 rendesse in qualche modo più difficile osservare il problema piuttosto che usando la distribuzione in modalità live.
alexsky8
20-10-2017, 19:30
Per me a furia di testare ne escono praticamente quasi tutte affette da questo problema
Dite che questo test sia replicabile con cpu intel ?
Sarei curioso di provare da mio padre a cui ho fatto un pc con g4560 ad inizio anno
Dite che questo test sia replicabile con cpu intel ?
Sarei curioso di provare da mio padre a cui ho fatto un pc con g4560 ad inizio anno
Giorgio G
20-10-2017, 19:50
La prova sopra l'ho fatta con il 1700 a 3.5ghz e ram 3066mhz, SMT su auto, errore quasi subito. Ora sto provando tutto a default e SMT su Auto, sono 25 minuti, senza errori.
Ubuntu 17.10 è installato.
Ma siamo sicuri che questa prova dimostri che il processore possa avere problemi? Penso che quelle cpu che non hanno errori sono quelle che non fanno il test, me sa :D
A parte questo cavolo di test, la mia cpu non ha nessunissimo problema, sale bene e non scalda.
Ubuntu 17.10 è installato.
Ma siamo sicuri che questa prova dimostri che il processore possa avere problemi? Penso che quelle cpu che non hanno errori sono quelle che non fanno il test, me sa :D
A parte questo cavolo di test, la mia cpu non ha nessunissimo problema, sale bene e non scalda.
Spitfire84
20-10-2017, 20:07
Guys ma qualcuno ha giá chiesto oppure é nel mezzo di una pratica rma ?
Ho inviato la richiesta il 18 ma ho non mi hanno ancora risposto, sabato e domenica immagino alle mail non rispondano.
Di questo passo che succede ? Gli spedisco la cpu tra una settimana e mi torna tra 2 mesi ? :confused:
Io sono in rma e sto attendendo il replacement. Pratica aperta domenica scorsa, lunedì pomeriggio avevo l'ok a spedirlo in Olanda. Spedito martedì, é arrivato ieri mattina e da allora non ho più avuto notizie...per questo chiedevo a chi c'è già passato quanto tempo hanno impiegato a spedire la cpu sostitutiva dopo aver ricevuto la cpu bacata.
Ho inviato la richiesta il 18 ma ho non mi hanno ancora risposto, sabato e domenica immagino alle mail non rispondano.
Di questo passo che succede ? Gli spedisco la cpu tra una settimana e mi torna tra 2 mesi ? :confused:
Io sono in rma e sto attendendo il replacement. Pratica aperta domenica scorsa, lunedì pomeriggio avevo l'ok a spedirlo in Olanda. Spedito martedì, é arrivato ieri mattina e da allora non ho più avuto notizie...per questo chiedevo a chi c'è già passato quanto tempo hanno impiegato a spedire la cpu sostitutiva dopo aver ricevuto la cpu bacata.
metal master
20-10-2017, 20:25
Io sono in rma e sto attendendo il replacement. Pratica aperta domenica scorsa, lunedì pomeriggio avevo l'ok a spedirlo in Olanda. Spedito martedì, é arrivato ieri mattina e da allora non ho più avuto notizie...per questo chiedevo a chi c'è già passato quanto tempo hanno impiegato a spedire la cpu sostitutiva dopo aver ricevuto la cpu bacata.
mi confermi che l'indirizzo di spedizione è questo?
AMD GCC c/o K+N (Kuehne + Nagel)
Pudongweg 1
1437 EM Rozenburg (NH)
The Netherlands
Contact name:
Phone : +31 (0)252-467 771
RMA number: xxxxxxxxx
mi confermi che l'indirizzo di spedizione è questo?
AMD GCC c/o K+N (Kuehne + Nagel)
Pudongweg 1
1437 EM Rozenburg (NH)
The Netherlands
Contact name:
Phone : +31 (0)252-467 771
RMA number: xxxxxxxxx
Debern9093
20-10-2017, 20:45
Allora ragazzi ho rifatto il test... Stavolta la prima volta mi ha dato errore di kernel.. La seconda volta si è feezato il sistema nn di muoveva il mouse e la terza volta credo sia un errore di segfault... Posto gli screen x conferma.. Però noto che non procede oltre il loop 11
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Mi sembra un problema molto più che raro eh...
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Mi sembra un problema molto più che raro eh...
nagashadow
20-10-2017, 20:58
Chiesto sostituzione per il 1700 ad Amazon..vediamo cosa mi mandano...
s12a
20-10-2017, 20:58
Allora ragazzi ho rifatto il test... Stavolta la prima volta mi ha dato errore di kernel.. La seconda volta si è feezato il sistema nn di muoveva il mouse e la terza volta credo sia un errore di segfault... Posto gli screen x conferma.. Però noto che non procede oltre il loop 11
Con le impostazioni di default del test è un loop per ogni core della CPU (partendo da zero); avrai quindi probabilmente un Ryzen 5 1600/1600X, 12 core.
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Sembra di sì. Un general protection fault (https://en.wikipedia.org/wiki/General_protection_fault) è un altro tipo di errore riconducibile alle stesse problematiche di accesso errato della memoria da parte della CPU, che per quanto visto fin'ora solitamente (ma non necessariamente) provoca segmentation fault con questo tipo di test, che comunque hai anche osservato.
Mi sembra un problema molto più che raro eh...
Dipende da quello che fai con il pc.
Con le impostazioni di default del test è un loop per ogni core della CPU (partendo da zero); avrai quindi probabilmente un Ryzen 5 1600/1600X, 12 core.
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Sembra di sì. Un general protection fault (https://en.wikipedia.org/wiki/General_protection_fault) è un altro tipo di errore riconducibile alle stesse problematiche di accesso errato della memoria da parte della CPU, che per quanto visto fin'ora solitamente (ma non necessariamente) provoca segmentation fault con questo tipo di test, che comunque hai anche osservato.
Mi sembra un problema molto più che raro eh...
Dipende da quello che fai con il pc.
alexsky8
20-10-2017, 20:59
Allora ragazzi ho rifatto il test... Stavolta la prima volta mi ha dato errore di kernel.. La seconda volta si è feezato il sistema nn di muoveva il mouse e la terza volta credo sia un errore di segfault... Posto gli screen x conferma.. Però noto che non procede oltre il loop 11
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Mi sembra un problema molto più che raro eh...
raro ? :D
per me è più raro chi non l'ha :D
comunque sì l'errore è quello segfault al secondo link loop-11
comunque per me non se ne esce fino a ryzen 2
https://ibb.co/fNzm36
https://ibb.co/ifBuqm
E affetto dal problema?
Mi sembra un problema molto più che raro eh...
raro ? :D
per me è più raro chi non l'ha :D
comunque sì l'errore è quello segfault al secondo link loop-11
comunque per me non se ne esce fino a ryzen 2
Spitfire84
20-10-2017, 21:07
Ma anche a te rispondevano al max una volta al giorno ? Tendenzialmente di mattina presto ? Perché di questo passo non si finisce piú :mad:
A me hanno mandato subito l'indirizzo per mandare su la cpu e poi l'ho spedita. Gli ho scritto un paio di voltes solo per aggiornarli sulla spedizione e mi hanno sempre risposto nel giro di qualche ora.
mi confermi che l'indirizzo di spedizione è questo?
AMD GCC c/o K+N (Kuehne + Nagel)
Pudongweg 1
1437 EM Rozenburg (NH)
The Netherlands
Contact name:
Phone : +31 (0)252-467 771
RMA number: xxxxxxxxx
Si, è corretto. Meglio se togli dal post precedente il contact name.
A me hanno mandato subito l'indirizzo per mandare su la cpu e poi l'ho spedita. Gli ho scritto un paio di voltes solo per aggiornarli sulla spedizione e mi hanno sempre risposto nel giro di qualche ora.
mi confermi che l'indirizzo di spedizione è questo?
AMD GCC c/o K+N (Kuehne + Nagel)
Pudongweg 1
1437 EM Rozenburg (NH)
The Netherlands
Contact name:
Phone : +31 (0)252-467 771
RMA number: xxxxxxxxx
Si, è corretto. Meglio se togli dal post precedente il contact name.
metal master
20-10-2017, 21:16
Si, è corretto. Meglio se togli dal post precedente il contact name.
ok, corretto
ok, corretto
ccmarco2004
20-10-2017, 21:34
Qualcuno l'ha fatto tempo fa per i processori di alcuni utenti del forum sul sito AMD e Reddit. Non credo che la lista sia aggiornata e/o esaustiva:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
EDIT: ed in parte anche qui:
https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit#gid=950983791
Immaginavo, grazie 1000.
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
EDIT: ed in parte anche qui:
https://docs.google.com/spreadsheets/d/1gzniXYcXm1uACXGoBLpbpq54KE6SlHxQ6M_wPnTkub8/edit#gid=950983791
Immaginavo, grazie 1000.
malcom499
21-10-2017, 00:58
ciao ragazzi, oggi mi è arrivato da amazon un ryzen 1700
[Imgur](https://i.imgur.com/9yiEzqp.jpg)
33esima settimana 2017
finito di assemblare ho fatto il test con ubuntu. Arrivato a loop-15 si è fermato ma dalle risorse si vedono che i core lavoravano al 100%.
[Imgur](https://i.imgur.com/uJWQ9q1.jpg)
Dopo una buona mezzora....
[Imgur](https://i.imgur.com/ZI61cng.jpg)
Fallato? è il caso di rifare altre prove?
edit..ho rifatto il test sempre uguale rimane fermo al loop 15 per 30/40 min poi [Imgur](https://i.imgur.com/ZI61cng.jpg)
[Imgur](https://i.imgur.com/9yiEzqp.jpg)
33esima settimana 2017
finito di assemblare ho fatto il test con ubuntu. Arrivato a loop-15 si è fermato ma dalle risorse si vedono che i core lavoravano al 100%.
[Imgur](https://i.imgur.com/uJWQ9q1.jpg)
Dopo una buona mezzora....
[Imgur](https://i.imgur.com/ZI61cng.jpg)
Fallato? è il caso di rifare altre prove?
edit..ho rifatto il test sempre uguale rimane fermo al loop 15 per 30/40 min poi [Imgur](https://i.imgur.com/ZI61cng.jpg)
s12a
21-10-2017, 05:05
ciao ragazzi, oggi mi è arrivato da amazon un ryzen 1700 [...]
Fallato? è il caso di rifare altre prove?
edit..ho rifatto il test sempre uguale rimane fermo al loop 15 per 30/40 min poi [...]
Hai letto bene il primo post od i post delle ultime pagine? (EDIT il tuo primo messaggio nel thread risale a qualche giorno fa. Ci sono stati aggiornamenti nel frattempo)
Dagli screenshot (questo (https://i.imgur.com/uJWQ9q1.jpg) in particolare) vedo che tu potresti avere usato il test originariamente scritto da suaefar (https://github.com/suaefar/ryzen-test). Una versione aggiornata del test adattata per Ubuntu 17.10 è stata prodotta da Oxalin (https://github.com/Oxalin/ryzen-test). Di questo se ne è scritto ampiamente qui.
È stato constatato che usando Ubuntu 17.10 con la vecchia versione i test falliscono sempre su tutti i loop dopo lo stesso tempo (senza segfault) a causa di incompatibilità con il codice sorgente scaricato dallo stesso con la nuova versione del compilatore usato inclusa nel sistema operativo. Sembra il tuo caso. Quale versione del test hai usato? Leggi anche questo commento scritto da me a riguardo (http://www.hwupgrade.it/forum/showpost.php?p=45112174&postcount=258).
Nota anche che:
I loop non vengono eseguiti sequenzialmente, ma tutti contemporaneamente, dunque non è giusto dire che il test si ferma al loop 15.
Se non ci sono errori di: segmentation fault/segfault, invalid opcode, general protection od altri errori simili a questi all'infuori di "build failed", non dovrebbero esserci problemi.
Ad occhio dunque la tua CPU dovrebbe essere a posto.
Fallato? è il caso di rifare altre prove?
edit..ho rifatto il test sempre uguale rimane fermo al loop 15 per 30/40 min poi [...]
Hai letto bene il primo post od i post delle ultime pagine? (EDIT il tuo primo messaggio nel thread risale a qualche giorno fa. Ci sono stati aggiornamenti nel frattempo)
Dagli screenshot (questo (https://i.imgur.com/uJWQ9q1.jpg) in particolare) vedo che tu potresti avere usato il test originariamente scritto da suaefar (https://github.com/suaefar/ryzen-test). Una versione aggiornata del test adattata per Ubuntu 17.10 è stata prodotta da Oxalin (https://github.com/Oxalin/ryzen-test). Di questo se ne è scritto ampiamente qui.
È stato constatato che usando Ubuntu 17.10 con la vecchia versione i test falliscono sempre su tutti i loop dopo lo stesso tempo (senza segfault) a causa di incompatibilità con il codice sorgente scaricato dallo stesso con la nuova versione del compilatore usato inclusa nel sistema operativo. Sembra il tuo caso. Quale versione del test hai usato? Leggi anche questo commento scritto da me a riguardo (http://www.hwupgrade.it/forum/showpost.php?p=45112174&postcount=258).
Nota anche che:
I loop non vengono eseguiti sequenzialmente, ma tutti contemporaneamente, dunque non è giusto dire che il test si ferma al loop 15.
Se non ci sono errori di: segmentation fault/segfault, invalid opcode, general protection od altri errori simili a questi all'infuori di "build failed", non dovrebbero esserci problemi.
Ad occhio dunque la tua CPU dovrebbe essere a posto.
beee
21-10-2017, 06:20
Ma fatemi capire.... si sfrutta questo bug per farsi cambiare cpu, che essendo piu recente, sarà probabilmente migliore in overclock (T piu basse, vcore minore... ). Chi ha veramente avuto problemi con questo bug??
Il mio ryzen 1700 ha resistito 5 minuti poi segfault..... ripetuto il test, sempre 5-6 minuti (il tutto @default).... ma normalmente non uso linux, e sotto windows regge conversioni video da 30' a 3.9ghz! Provato a compilare in c#, nessun problema, ma le compilazioni durano al massimo qualche secondo....
Boh.....
Il mio ryzen 1700 ha resistito 5 minuti poi segfault..... ripetuto il test, sempre 5-6 minuti (il tutto @default).... ma normalmente non uso linux, e sotto windows regge conversioni video da 30' a 3.9ghz! Provato a compilare in c#, nessun problema, ma le compilazioni durano al massimo qualche secondo....
Boh.....
malcom499
21-10-2017, 07:05
Hai letto bene il primo post od i post delle ultime pagine? (EDIT il tuo primo messaggio nel thread risale a qualche giorno fa. Ci sono stati aggiornamenti nel frattempo)
Dagli screenshot (questo (https://i.imgur.com/uJWQ9q1.jpg) in particolare) vedo che tu potresti avere usato il test originariamente scritto da suaefar (https://github.com/suaefar/ryzen-test). Una versione aggiornata del test adattata per Ubuntu 17.10 è stata prodotta da Oxalin (https://github.com/Oxalin/ryzen-test). Di questo se ne è scritto ampiamente qui.
È stato constatato che usando Ubuntu 17.10 con la vecchia versione i test falliscono sempre su tutti i loop dopo lo stesso tempo (senza segfault) a causa di incompatibilità con il codice sorgente scaricato dallo stesso con la nuova versione del compilatore usato inclusa nel sistema operativo. Sembra il tuo caso. Quale versione del test hai usato? Leggi anche questo commento scritto da me a riguardo (http://www.hwupgrade.it/forum/showpost.php?p=45112174&postcount=258).
Nota anche che:
I loop non vengono eseguiti sequenzialmente, ma tutti contemporaneamente, dunque non è giusto dire che il test si ferma al loop 15.
Se non ci sono errori di: segmentation fault/segfault, invalid opcode, general protection od altri errori simili a questi all'infuori di "build failed", non dovrebbero esserci problemi.
Ad occhio dunque la tua CPU dovrebbe essere a posto.
Ciao e grazie per la risposta, si ho usato il test https://github.com/suaefar/ryzen-test.
Provo https://github.com/Oxalin/ryzen-test
Dagli screenshot (questo (https://i.imgur.com/uJWQ9q1.jpg) in particolare) vedo che tu potresti avere usato il test originariamente scritto da suaefar (https://github.com/suaefar/ryzen-test). Una versione aggiornata del test adattata per Ubuntu 17.10 è stata prodotta da Oxalin (https://github.com/Oxalin/ryzen-test). Di questo se ne è scritto ampiamente qui.
È stato constatato che usando Ubuntu 17.10 con la vecchia versione i test falliscono sempre su tutti i loop dopo lo stesso tempo (senza segfault) a causa di incompatibilità con il codice sorgente scaricato dallo stesso con la nuova versione del compilatore usato inclusa nel sistema operativo. Sembra il tuo caso. Quale versione del test hai usato? Leggi anche questo commento scritto da me a riguardo (http://www.hwupgrade.it/forum/showpost.php?p=45112174&postcount=258).
Nota anche che:
I loop non vengono eseguiti sequenzialmente, ma tutti contemporaneamente, dunque non è giusto dire che il test si ferma al loop 15.
Se non ci sono errori di: segmentation fault/segfault, invalid opcode, general protection od altri errori simili a questi all'infuori di "build failed", non dovrebbero esserci problemi.
Ad occhio dunque la tua CPU dovrebbe essere a posto.
Ciao e grazie per la risposta, si ho usato il test https://github.com/suaefar/ryzen-test.
Provo https://github.com/Oxalin/ryzen-test
Debern9093
21-10-2017, 07:42
è possibile fare rma senza scatola originale? ho lo scontrino...
s12a
21-10-2017, 07:45
Ma fatemi capire.... si sfrutta questo bug per farsi cambiare cpu, che essendo piu recente, sarà probabilmente migliore in overclock (T piu basse, vcore minore... ). Chi ha veramente avuto problemi con questo bug??
Il mio ryzen 1700 ha resistito 5 minuti poi segfault..... ripetuto il test, sempre 5-6 minuti (il tutto @default).... ma normalmente non uso linux, e sotto windows regge conversioni video da 30' a 3.9ghz! Provato a compilare in c#, nessun problema, ma le compilazioni durano al massimo qualche secondo....
Boh.....
Non è compilando un file che si possono potenzialmente avere problemi. Ne vengono rilevati durante operazioni coinvolgenti un alto numero di thread o processi paralleli con CPU a pieno carico, come ad esempio la compilazione di progetti complessi in C/C++ da migliaia di file di codice per i quali normalmente ci vogliono decine di minuti o qualche ora per essere compilati da zero.
Deve essere una questione di probabilità principalmente correlata al numero di processi (o thread) aperti e chiusi in un certo lasso di tempo come nella compilazione di tali progetti, dunque probabilmente non accade facilmente durante la conversione video o anche rendering 3D, dove c'è solitamente un numero fisso di thread a lavorare continuamente. Non sono però stati effettuati test specifici a riguardo che io sappia.
Sarei veramente curioso di provare in diverse situazioni, ma non è abbia intenzione di spendere denaro appositamente per acquistare un processore difettoso ed effettuare i test che gli altri non fanno.
Sono stati in ogni caso riportati anche problemi di instabilità generale potenzialmente correlati al segfault (crash di programmi, freeze, riavvii del PC) all'infuori della compilazione intensiva ed in certi casi confermati essere risolti con un nuovo processore, quindi non è detto che la cosa riguardi poche persone. Alcuni ne ho citati nel primo post. C'è anche per questo un thread dedicato nel community forum AMD (https://community.amd.com/thread/216084) e sembra anche anche per questo AMD sostituisca i processori senza troppi problemi.
Tuttavia, se non noti stranezze nel funzionamento del PC nonostante i segfault rilevati con il test su Linux, è ragionevole pensare che con il tuo uso il problema per il momento non ti riguardi.
è possibile fare rma senza scatola originale? ho lo scontrino...
Che io sappia in caso di RMA AMD vuole solo il processore, non tutta la scatola.
Il mio ryzen 1700 ha resistito 5 minuti poi segfault..... ripetuto il test, sempre 5-6 minuti (il tutto @default).... ma normalmente non uso linux, e sotto windows regge conversioni video da 30' a 3.9ghz! Provato a compilare in c#, nessun problema, ma le compilazioni durano al massimo qualche secondo....
Boh.....
Non è compilando un file che si possono potenzialmente avere problemi. Ne vengono rilevati durante operazioni coinvolgenti un alto numero di thread o processi paralleli con CPU a pieno carico, come ad esempio la compilazione di progetti complessi in C/C++ da migliaia di file di codice per i quali normalmente ci vogliono decine di minuti o qualche ora per essere compilati da zero.
Deve essere una questione di probabilità principalmente correlata al numero di processi (o thread) aperti e chiusi in un certo lasso di tempo come nella compilazione di tali progetti, dunque probabilmente non accade facilmente durante la conversione video o anche rendering 3D, dove c'è solitamente un numero fisso di thread a lavorare continuamente. Non sono però stati effettuati test specifici a riguardo che io sappia.
Sarei veramente curioso di provare in diverse situazioni, ma non è abbia intenzione di spendere denaro appositamente per acquistare un processore difettoso ed effettuare i test che gli altri non fanno.
Sono stati in ogni caso riportati anche problemi di instabilità generale potenzialmente correlati al segfault (crash di programmi, freeze, riavvii del PC) all'infuori della compilazione intensiva ed in certi casi confermati essere risolti con un nuovo processore, quindi non è detto che la cosa riguardi poche persone. Alcuni ne ho citati nel primo post. C'è anche per questo un thread dedicato nel community forum AMD (https://community.amd.com/thread/216084) e sembra anche anche per questo AMD sostituisca i processori senza troppi problemi.
Tuttavia, se non noti stranezze nel funzionamento del PC nonostante i segfault rilevati con il test su Linux, è ragionevole pensare che con il tuo uso il problema per il momento non ti riguardi.
è possibile fare rma senza scatola originale? ho lo scontrino...
Che io sappia in caso di RMA AMD vuole solo il processore, non tutta la scatola.
Debern9093
21-10-2017, 07:52
Non è compilando un file che si possono potenzialmente avere problemi. Ne vengono rilevati durante operazioni coinvolgenti un alto numero di thread o processi paralleli con CPU a pieno carico, come ad esempio la compilazione di progetti complessi in C/C++ da migliaia di file di codice per i quali normalmente ci vogliono decine di minuti o qualche ora per essere compilati da zero.
Deve essere una questione di probabilità principalmente correlata al numero di processi (o thread) aperti e chiusi in un certo lasso di tempo come nella compilazione di tali progetti, dunque probabilmente non accade facilmente durante la conversione video o anche rendering 3D, dove c'è solitamente un numero fisso di thread a lavorare continuamente. Non sono però stati effettuati test specifici a riguardo che io sappia.
Sarei veramente curioso di provare in diverse situazioni, ma non è abbia intenzione di spendere denaro appositamente per acquistare un processore difettoso ed effettuare i test che gli altri non fanno.
Sono stati in ogni caso riportati anche problemi di instabilità generale potenzialmente correlati al segfault (crash di programmi, freeze, riavvii del PC) all'infuori della compilazione intensiva ed in certi casi confermati essere risolti con un nuovo processore, quindi non è detto che la cosa riguardi poche persone. Alcuni ne ho citati nel primo post. C'è anche per questo un thread dedicato nel community forum AMD (https://community.amd.com/thread/216084) e sembra anche anche per questo AMD sostituisca i processori senza troppi problemi.
Che io sappia in caso di RMA AMD vuole solo il processore, non tutta la scatola.
secondo te mi conviene stare senza processore per giorni e fare rma? nel caso, a quale indirizzo devo spedire? ti inviano una cpu nuova? c'è il rischio di ricevere una cpu con lo stesso problema?
Deve essere una questione di probabilità principalmente correlata al numero di processi (o thread) aperti e chiusi in un certo lasso di tempo come nella compilazione di tali progetti, dunque probabilmente non accade facilmente durante la conversione video o anche rendering 3D, dove c'è solitamente un numero fisso di thread a lavorare continuamente. Non sono però stati effettuati test specifici a riguardo che io sappia.
Sarei veramente curioso di provare in diverse situazioni, ma non è abbia intenzione di spendere denaro appositamente per acquistare un processore difettoso ed effettuare i test che gli altri non fanno.
Sono stati in ogni caso riportati anche problemi di instabilità generale potenzialmente correlati al segfault (crash di programmi, freeze, riavvii del PC) all'infuori della compilazione intensiva ed in certi casi confermati essere risolti con un nuovo processore, quindi non è detto che la cosa riguardi poche persone. Alcuni ne ho citati nel primo post. C'è anche per questo un thread dedicato nel community forum AMD (https://community.amd.com/thread/216084) e sembra anche anche per questo AMD sostituisca i processori senza troppi problemi.
Che io sappia in caso di RMA AMD vuole solo il processore, non tutta la scatola.
secondo te mi conviene stare senza processore per giorni e fare rma? nel caso, a quale indirizzo devo spedire? ti inviano una cpu nuova? c'è il rischio di ricevere una cpu con lo stesso problema?
s12a
21-10-2017, 08:00
secondo te mi conviene stare senza processore per giorni e fare rma?
Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
nel caso, a quale indirizzo devo spedire? ti inviano una cpu nuova? c'è il rischio di ricevere una cpu con lo stesso problema?
Nel dettaglio non so a quale indirizzo occorra spedire. Le informazioni in merito vengono fornite dal supporto tecnico AMD durante la richiesta.
Dovrebbero inviare una CPU nuova e probabilmente pre-testata manualmente da un operatore, secondo quanto osservato (http://www.hwupgrade.it/forum/showpost.php?p=45103525&postcount=81) da altri utenti nel forum AMD.
In un paio di casi (da questa lista (https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0)) tuttavia qualcuno ha continuato ad osservare segfault anche dopo l'RMA; non so come sia andata a finire poi la storia però (magari la colpa era di eventuali overclock? Bisogna effettuare il test con la CPU a default e memorie a 2400 MHz o velocità inferiori).
Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
nel caso, a quale indirizzo devo spedire? ti inviano una cpu nuova? c'è il rischio di ricevere una cpu con lo stesso problema?
Nel dettaglio non so a quale indirizzo occorra spedire. Le informazioni in merito vengono fornite dal supporto tecnico AMD durante la richiesta.
Dovrebbero inviare una CPU nuova e probabilmente pre-testata manualmente da un operatore, secondo quanto osservato (http://www.hwupgrade.it/forum/showpost.php?p=45103525&postcount=81) da altri utenti nel forum AMD.
In un paio di casi (da questa lista (https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0)) tuttavia qualcuno ha continuato ad osservare segfault anche dopo l'RMA; non so come sia andata a finire poi la storia però (magari la colpa era di eventuali overclock? Bisogna effettuare il test con la CPU a default e memorie a 2400 MHz o velocità inferiori).
malcom499
21-10-2017, 08:07
ok il pc è ancora in test da più di 1 ora con lo script https://github.com/Oxalin/ryzen-test
l'unico messaggio durante il test è quello che si vede in foto che da quanto ho letto non è un errore.
Vedo che la ram si sta saturando penso che presto si fermerà.
[Imgur](https://i.imgur.com/ZceNswV.jpg)
Dite che posso stare tranquillo o faccio ulteriori test?
grazie
l'unico messaggio durante il test è quello che si vede in foto che da quanto ho letto non è un errore.
Vedo che la ram si sta saturando penso che presto si fermerà.
[Imgur](https://i.imgur.com/ZceNswV.jpg)
Dite che posso stare tranquillo o faccio ulteriori test?
grazie
Debern9093
21-10-2017, 08:09
Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
Nel dettaglio non so a quale indirizzo occorra spedire. Le informazioni in merito vengono fornite dal supporto tecnico AMD durante la richiesta.
Dovrebbero inviare una CPU nuova e probabilmente pre-testata manualmente da un operatore, secondo quanto osservato (http://www.hwupgrade.it/forum/showpost.php?p=45103525&postcount=81) da altri utenti nel forum AMD.
In un paio di casi (da questa lista (https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0)) tuttavia qualcuno ha continuato ad osservare segfault anche dopo l'RMA; non so come sia andata a finire poi la storia però (magari la colpa era di eventuali overclock? Bisogna effettuare il test con la CPU a default e memorie a 2400 MHz o velocità inferiori).
al momento non ho instabilità... col pc ci gioco e gioco anche bene... volevo una cpu esente da qualsiasi problema, tutto qua... però ho il timore di restare senza pc e avere una nuova cpu fallata
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
Nel dettaglio non so a quale indirizzo occorra spedire. Le informazioni in merito vengono fornite dal supporto tecnico AMD durante la richiesta.
Dovrebbero inviare una CPU nuova e probabilmente pre-testata manualmente da un operatore, secondo quanto osservato (http://www.hwupgrade.it/forum/showpost.php?p=45103525&postcount=81) da altri utenti nel forum AMD.
In un paio di casi (da questa lista (https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0)) tuttavia qualcuno ha continuato ad osservare segfault anche dopo l'RMA; non so come sia andata a finire poi la storia però (magari la colpa era di eventuali overclock? Bisogna effettuare il test con la CPU a default e memorie a 2400 MHz o velocità inferiori).
al momento non ho instabilità... col pc ci gioco e gioco anche bene... volevo una cpu esente da qualsiasi problema, tutto qua... però ho il timore di restare senza pc e avere una nuova cpu fallata
s12a
21-10-2017, 08:12
ok il pc è ancora in test da più di 1 ora con lo script https://github.com/Oxalin/ryzen-test
l'unico messaggio durante il test è quello che si vede in foto che da quanto ho letto non è un errore.
Esatto, non è un errore, solo un avviso causato dal carico della CPU (http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309).
Vedo che la ram si sta saturando penso che presto si fermerà.
[Imgur](https://i.imgur.com/ZceNswV.jpg)
Dite che posso stare tranquillo o faccio ulteriori test?
grazie
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
[...] 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
l'unico messaggio durante il test è quello che si vede in foto che da quanto ho letto non è un errore.
Esatto, non è un errore, solo un avviso causato dal carico della CPU (http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309).
Vedo che la ram si sta saturando penso che presto si fermerà.
[Imgur](https://i.imgur.com/ZceNswV.jpg)
Dite che posso stare tranquillo o faccio ulteriori test?
grazie
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
[...] 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
malcom499
21-10-2017, 08:18
Esatto, non è un errore, solo un avviso causato dal carico della CPU (http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309).
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
Ok memoria saturata e ubuntu bloccato..faccio quest'ultima prova (4+4)...
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
Ok memoria saturata e ubuntu bloccato..faccio quest'ultima prova (4+4)...
malcom499
21-10-2017, 11:39
Considerá che a me senza parametri non da errori e a 4 4 va in seg fault, quindi occhio.
è andato a 4 4 per più di mezzora poi purtroppo son dovuto uscire e ho fermato il test. Adesso lo rieseguo, lo lascio andare fino ad esaurimento memoria? (ammesso che non mi dai errori prima).
è andato a 4 4 per più di mezzora poi purtroppo son dovuto uscire e ho fermato il test. Adesso lo rieseguo, lo lascio andare fino ad esaurimento memoria? (ammesso che non mi dai errori prima).
alexsky8
21-10-2017, 15:30
Domanda ma se la rimando ad amd tra un'anno con rma mi mandano una nuova a 12nm ?
forse se lo mandi fra 2 anni, fra un anno non credo
forse se lo mandi fra 2 anni, fra un anno non credo
BuRn
21-10-2017, 15:47
Per me a furia di testare ne escono praticamente quasi tutte affette da questo problema
Dite che questo test sia replicabile con cpu intel ?
Sarei curioso di provare da mio padre a cui ho fatto un pc con g4560 ad inizio anno
Ho provato sul mio i5 per sfizio, nessun errore, a parte che finisco in fretta la memoria e inizia a swappare azzerando l'uso della CPU (test Oxalin su Mint installato).
Dite che questo test sia replicabile con cpu intel ?
Sarei curioso di provare da mio padre a cui ho fatto un pc con g4560 ad inizio anno
Ho provato sul mio i5 per sfizio, nessun errore, a parte che finisco in fretta la memoria e inizia a swappare azzerando l'uso della CPU (test Oxalin su Mint installato).
alexsky8
21-10-2017, 16:00
Ho provato sul mio i5 per sfizio, nessun errore, a parte che finisco in fretta la memoria e inizia a swappare azzerando l'uso della CPU (test Oxalin su Mint installato).
bene magari farò delle prove pure io ;)
bene magari farò delle prove pure io ;)
jam71
21-10-2017, 17:36
Scusate una cosa,una volta denfro ubuntu apro firefox e cerco il link per scaricare il programmino per fare il test,lo scarico ma all-interno ci sono 4 file ma sembrano di lettura come faccio ad avviare il test_
s12a
21-10-2017, 17:43
Hai bisogno di leggere attentamente il primo post. È linkata la procedura passo-passo con tanto di screenshot.
papugo1980
21-10-2017, 17:45
Scusate una cosa,una volta denfro ubuntu apro firefox e cerco il link per scaricare il programmino per fare il test,lo scarico ma all-interno ci sono 4 file ma sembrano di lettura come faccio ad avviare il test_
Ina volta estratto il zip
Vai sulla cartella , tasto destro open terminal
Poi incolli la stringa kill ryzen é dai invio
Ina volta estratto il zip
Vai sulla cartella , tasto destro open terminal
Poi incolli la stringa kill ryzen é dai invio
s12a
21-10-2017, 17:47
@papugo1980: il primo post contiene anche note importanti sul test che è bene leggere con attenzione prima di inziare, ecco perché non ho riportato la "soluzione" nel commento precedente.
jam71
21-10-2017, 17:51
Hai bisogno di leggere attentamente il primo post. È linkata la procedura passo-passo con tanto di screenshot.
Si ho letto ma deve essermi sfuggito qualcosa,
Si ho letto ma deve essermi sfuggito qualcosa,
jam71
21-10-2017, 17:52
Ina volta estratto il zip
Vai sulla cartella , tasto destro open terminal
Poi incolli la stringa kill ryzen é dai invio
Ok perfetto! grazie.
Vai sulla cartella , tasto destro open terminal
Poi incolli la stringa kill ryzen é dai invio
Ok perfetto! grazie.
s12a
21-10-2017, 17:59
Hai bisogno di leggere attentamente il primo post. È linkata la procedura passo-passo con tanto di screenshot.
Si ho letto ma deve essermi sfuggito qualcosa,
For context:
https://i.imgur.com/051nzSP.png
Forse size="4" non basta, modificherò con size="6".
EDIT: era size="3" + grassetto prima; ora size="5" + grassetto.
Si ho letto ma deve essermi sfuggito qualcosa,
For context:
https://i.imgur.com/051nzSP.png
Forse size="4" non basta, modificherò con size="6".
EDIT: era size="3" + grassetto prima; ora size="5" + grassetto.
jam71
21-10-2017, 21:00
For context:
https://i.imgur.com/051nzSP.png
Forse size="4" non basta, modificherò con size="6".
EDIT: era size="3" + grassetto prima; ora size="5" + grassetto.
Ripeto che ho letto tutto ok? non c'è bisogno di fare del sarcasmo, prima di chiedere mi rileggo sempre tutte le pagine per vedere se trovo le info che mi servono,non sono qui da 2 giorni,conosco le regole e le rispetto, se ho chiesto è perché mi sfuggiva qualcosa che c'è di male?
Comunque ho risolto grazie alla dritta di Papugo1980 è proprio quello che mi serviva.
Edit. si adesso guardando meglio l'aveva gia' scritto l'utente spongejhon
https://i.imgur.com/051nzSP.png
Forse size="4" non basta, modificherò con size="6".
EDIT: era size="3" + grassetto prima; ora size="5" + grassetto.
Ripeto che ho letto tutto ok? non c'è bisogno di fare del sarcasmo, prima di chiedere mi rileggo sempre tutte le pagine per vedere se trovo le info che mi servono,non sono qui da 2 giorni,conosco le regole e le rispetto, se ho chiesto è perché mi sfuggiva qualcosa che c'è di male?
Comunque ho risolto grazie alla dritta di Papugo1980 è proprio quello che mi serviva.
Edit. si adesso guardando meglio l'aveva gia' scritto l'utente spongejhon
Mikkinen
22-10-2017, 10:39
Ciao, grazie per la guida...
ho eseguito il test (con ubuntu 17.04,ora sto preparando il 17.10 sempre da usb) ma non so se è valido... qualcuno mi può confermare il risultato per favore?
https://s1.postimg.org/560r1fpa9n/1700.jpg (https://postimg.org/image/560r1fpa9n/)
ho eseguito il test (con ubuntu 17.04,ora sto preparando il 17.10 sempre da usb) ma non so se è valido... qualcuno mi può confermare il risultato per favore?
https://s1.postimg.org/560r1fpa9n/1700.jpg (https://postimg.org/image/560r1fpa9n/)
s12a
22-10-2017, 10:51
https://s1.postimg.org/560r1fpa9n/1700.jpg (https://postimg.org/image/560r1fpa9n/)
Avviso di "build failed" seguito da un inequivocabile errore dal kernel [KERN] di segfault.
Sì, credo che il risultato sia confermato.
Gli altri errori dal kernel riguardanti "IPv6: ADDRCONF" non dovrebbero avere nulla a che vedere con il test; riguardano la configurazione dell'adattatore di rete wifi.
Avviso di "build failed" seguito da un inequivocabile errore dal kernel [KERN] di segfault.
Sì, credo che il risultato sia confermato.
Gli altri errori dal kernel riguardanti "IPv6: ADDRCONF" non dovrebbero avere nulla a che vedere con il test; riguardano la configurazione dell'adattatore di rete wifi.
Mikkinen
22-10-2017, 11:05
cut
Ah ok...grazie! ... Ora sto riprovando sul 17.10...anche se non dovrebbe servire...
Ah ok...grazie! ... Ora sto riprovando sul 17.10...anche se non dovrebbe servire...
Debern9093
22-10-2017, 11:35
Ma x chi gioca solamente con il pc o ne fa un uso basico vale veramente la pena cambiare CPU pur non avendo nessun tipo di problema di crash o instabilità che siano? Ad esempio io ho in r5 1600x con problemi di segfault ma ho addirittura temp ottime con un arctic freezer 33 (30 gradi anche meno a volte in idle e 49-50 massimi in game)
Mikkinen
22-10-2017, 11:52
cut
E' una domanda che mi sto ponendo anch'io...
E' una domanda che mi sto ponendo anch'io...
s12a
22-10-2017, 12:02
Non so che altro aggiungere a questo:
Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
Hai problemi in applicazioni specifiche o pensi di averne di imputabili al processore?
Pensi che potrebbe essere un problema in futuro?
Vuoi semplicemente un processore esente da problemi a prescindere dal fatto che questo ti riguardi direttamente o meno?
Se la risposta ad almeno una di queste domande è sì, probabilmente conviene, altrimenti no. In caso di dubbio forse è meglio fare RMA.
doctor who ?
22-10-2017, 12:34
Ma x chi gioca solamente con il pc o ne fa un uso basico vale veramente la pena cambiare CPU pur non avendo nessun tipo di problema di crash o instabilità che siano? Ad esempio io ho in r5 1600x con problemi di segfault ma ho addirittura temp ottime con un arctic freezer 33 (30 gradi anche meno a volte in idle e 49-50 massimi in game)
Può essere che non ti dia mai problemi, può capitare che lo cambi e il nuovo scalda di più e sale meno in oc, può essere che fra 7 mesi un gioco in particolare ti crasha per questo problema e smadonni perchè non sai da che dipende, la probabilità dei vari "può essere" non la sa nessuno, però se lo hai comprato in europa hai 2 anni di garanzia :p
Può essere che non ti dia mai problemi, può capitare che lo cambi e il nuovo scalda di più e sale meno in oc, può essere che fra 7 mesi un gioco in particolare ti crasha per questo problema e smadonni perchè non sai da che dipende, la probabilità dei vari "può essere" non la sa nessuno, però se lo hai comprato in europa hai 2 anni di garanzia :p
malcom499
22-10-2017, 13:44
Esatto, non è un errore, solo un avviso causato dal carico della CPU (http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309).
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
ciao, ieri ho fatto un test a 4 4 per una buona mezzora e nessun errore...
Oggi ho rieseguito il test sempre a 4 4 e sta ancora girando dopo un ora e 40 minuti circa. Dici che posso fermare il test oppure lo faccio girare ancora?
[Imgur](https://i.imgur.com/8WoZHKz.jpg)
Dovrebbe essere già la terza volta che non ti è uscito fuori nulla, secondo me dovresti essere a posto. Per scrupolo potresti provare il test per un tempo ancora più lungo usando impostazioni meno intensive che fanno saturare la memoria in meno tempo, come descritto in quella pagina:
https://github.com/Oxalin/ryzen-test#requirements
ciao, ieri ho fatto un test a 4 4 per una buona mezzora e nessun errore...
Oggi ho rieseguito il test sempre a 4 4 e sta ancora girando dopo un ora e 40 minuti circa. Dici che posso fermare il test oppure lo faccio girare ancora?
[Imgur](https://i.imgur.com/8WoZHKz.jpg)
s12a
22-10-2017, 13:52
Oramai dovrebbe bastare, anche se c'è chi per scrupolo lo lascia girare anche per diverse ore. Con le CPU affette da problema in maniera evidente i segfault o problemi correlati escono nell'arco di vari minuti, solitamente.
malcom499
22-10-2017, 14:22
Oramai dovrebbe bastare, anche se c'è chi per scrupolo lo lascia girare anche per diverse ore. Con le CPU affette da problema in maniera evidente i segfault o problemi correlati escono nell'arco di vari minuti, solitamente.
ok lascio girare ancora un paio d'ore...ora siamo a 2 ore e 5 minuti...rispetto al test normale il 4 4 sembra non riempire mai la Ram...
ok lascio girare ancora un paio d'ore...ora siamo a 2 ore e 5 minuti...rispetto al test normale il 4 4 sembra non riempire mai la Ram...
alexsky8
22-10-2017, 15:30
Oramai dovrebbe bastare, anche se c'è chi per scrupolo lo lascia girare anche per diverse ore. Con le CPU affette da problema in maniera evidente i segfault o problemi correlati escono nell'arco di vari minuti, solitamente.
nel mio caso bastano pochi minuti
nel mio caso bastano pochi minuti
jam71
22-10-2017, 15:43
Anche io comunque col ryzen 1600x ho il problema del segfault dopo pochi secondi,ho provato varie volte:( il pc gira bene ma credo che faro' rma,la cosa mi da molto fastidio.
s12a
22-10-2017, 16:14
Può essere che non ti dia mai problemi, può capitare che lo cambi e il nuovo scalda di più e sale meno in oc, può essere che fra 7 mesi un gioco in particolare ti crasha per questo problema e smadonni perchè non sai da che dipende, la probabilità dei vari "può essere" non la sa nessuno, però se lo hai comprato in europa hai 2 anni di garanzia :p
Una cosa ancora da verificare è se ad esempio alcuni problemi di stuttering nei giochi possano essere indirettamente correlati al segfault. Mi chiedo se qualcuno dopo l'RMA abbia notato cambiamenti in tal senso o altri miglioramenti a parità di impostazioni... anche se credo che chi è interessato al problema non sia generalmente un grande appasionato di gaming.
EDIT: ad esempio questo report potrebbe indicare migliorie anche in tal senso:
https://www.reddit.com/r/Amd/comments/7779az/my_amd_2017_experience_with_a_slightly_bumpy/?st=j92wc0xa&sh=5b431f73
[...]at the same time I decided to RMA my RYZEN CPU because of the segfault issue (my DX12 and Vulkan games were crashing and I found that other users were linking that to the segfault issue). I go ahead and RMA. Just about two weeks later I have my brand new replacement week 33 RYZEN CPU that performs better than my previous 1700 [...]
My OG Ryzen 1700 would overclock to a 3.7 clock with voltage @ 1.25. My new week 33 Ryzen 1700 is overclocked to 3.9ghz with voltage @ 1.30 (I haven't tried a lower voltage yet). My new Ryzen is running a lot smoother. And no more crashing in my DX12/Vulkan games.
Mainly Rise of the Tomb Raider after about 15-20min of gameplay. It seemed to always crash when I got to the exact same part. And for Vulkan Ashes of the Singularity started crashing out of nowhere.
200 MHz in più col nuovo processore da soli bastano a rendere i giochi molto più fluidi come riportato? EDIT: o magari intende solo "smoother" nel senso di "senza problemi".
Una cosa ancora da verificare è se ad esempio alcuni problemi di stuttering nei giochi possano essere indirettamente correlati al segfault. Mi chiedo se qualcuno dopo l'RMA abbia notato cambiamenti in tal senso o altri miglioramenti a parità di impostazioni... anche se credo che chi è interessato al problema non sia generalmente un grande appasionato di gaming.
EDIT: ad esempio questo report potrebbe indicare migliorie anche in tal senso:
https://www.reddit.com/r/Amd/comments/7779az/my_amd_2017_experience_with_a_slightly_bumpy/?st=j92wc0xa&sh=5b431f73
[...]at the same time I decided to RMA my RYZEN CPU because of the segfault issue (my DX12 and Vulkan games were crashing and I found that other users were linking that to the segfault issue). I go ahead and RMA. Just about two weeks later I have my brand new replacement week 33 RYZEN CPU that performs better than my previous 1700 [...]
My OG Ryzen 1700 would overclock to a 3.7 clock with voltage @ 1.25. My new week 33 Ryzen 1700 is overclocked to 3.9ghz with voltage @ 1.30 (I haven't tried a lower voltage yet). My new Ryzen is running a lot smoother. And no more crashing in my DX12/Vulkan games.
Mainly Rise of the Tomb Raider after about 15-20min of gameplay. It seemed to always crash when I got to the exact same part. And for Vulkan Ashes of the Singularity started crashing out of nowhere.
200 MHz in più col nuovo processore da soli bastano a rendere i giochi molto più fluidi come riportato? EDIT: o magari intende solo "smoother" nel senso di "senza problemi".
Debern9093
22-10-2017, 16:30
in ogni caso io ho acquistato la mia cpu da un negozio fisico un mese fa, è ancora possibile che se glie la riporto me la sostituisca? ovviamente certificando il tutto con i dovuti screen...
Per la questione gaming, avevo anche io dei rallentamenti solo nei caricamenti (ho provato solo rise of the tomb raider), avevo abbassato il voltaggio probabilmente è dovuto da questo, alzando di uno step i rallentamenti sono spariti... è probabile che siano causati dal vcore insufficiente
Per la questione gaming, avevo anche io dei rallentamenti solo nei caricamenti (ho provato solo rise of the tomb raider), avevo abbassato il voltaggio probabilmente è dovuto da questo, alzando di uno step i rallentamenti sono spariti... è probabile che siano causati dal vcore insufficiente
alexsky8
22-10-2017, 16:33
chi ha acquistato da Amazon e vuole fare sostituzione con loro consiglierei di attendere ancora qualche mesetto, la vicenda non è per nulla sistemata dopo la 25 esima settimana come invece sembrava fino a poco fa
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
Debern9093
22-10-2017, 16:37
chi ha acquistato da Amazon e vuole fare sostituzione con loro consiglierei di attendere ancora qualche mesetto, la vicenda non è per nulla sistemata dopo la 25 esima settimana come invece sembrava fino a poco fa
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
come mai affermi ciò? hai avuto problemi?
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
come mai affermi ciò? hai avuto problemi?
s12a
22-10-2017, 16:38
in ogni caso io ho acquistato la mia cpu da un negozio fisico un mese fa, è ancora possibile che se glie la riporto me la sostituisca? ovviamente certificando il tutto con i dovuti screen...
Non avevi menzionato di avere buttato via la scatola? Molto difficile, IMHO.
Per la questione gaming, avevo anche io dei rallentamenti solo nei caricamenti (ho provato solo rise of the tomb raider), avevo abbassato il voltaggio probabilmente è dovuto da questo, alzando di uno step i rallentamenti sono spariti... è probabile che siano causati dal vcore insufficiente
Non hai controllato se variando sia a salire che a scendere con vCore e vSoC i segfault dal solito test aumentano/diminuiscono?
Non avevi menzionato di avere buttato via la scatola? Molto difficile, IMHO.
Per la questione gaming, avevo anche io dei rallentamenti solo nei caricamenti (ho provato solo rise of the tomb raider), avevo abbassato il voltaggio probabilmente è dovuto da questo, alzando di uno step i rallentamenti sono spariti... è probabile che siano causati dal vcore insufficiente
Non hai controllato se variando sia a salire che a scendere con vCore e vSoC i segfault dal solito test aumentano/diminuiscono?
doctor who ?
22-10-2017, 16:40
come mai affermi ciò? hai avuto problemi?
Un utente si è ritrovato una cpu fallata anche se successiva alla settimana 25
Una cosa ancora da verificare è se ad esempio alcuni problemi di stuttering nei giochi possano essere indirettamente correlati al segfault. Mi chiedo se qualcuno dopo l'RMA abbia notato cambiamenti in tal senso o altri miglioramenti a parità di impostazioni... anche se credo che chi è interessato al problema non sia generalmente un grande appasionato di gaming.
EDIT: ad esempio questo report potrebbe indicare migliorie anche in tal senso:
https://www.reddit.com/r/Amd/comments/7779az/my_amd_2017_experience_with_a_slightly_bumpy/?st=j92wc0xa&sh=5b431f73
200 MHz in più col nuovo processore da soli bastano a rendere i giochi molto più fluidi come riportato? EDIT: o magari intende solo "smoother" nel senso di "senza problemi".
Boh guarda, la situazione non è per nulla chiara, anche perchè c'è anche gente che ha la cpu fallata ma non ha problemi descritti da altri, il che rende la cosa ancora più complicata :fagiano:
Un utente si è ritrovato una cpu fallata anche se successiva alla settimana 25
Una cosa ancora da verificare è se ad esempio alcuni problemi di stuttering nei giochi possano essere indirettamente correlati al segfault. Mi chiedo se qualcuno dopo l'RMA abbia notato cambiamenti in tal senso o altri miglioramenti a parità di impostazioni... anche se credo che chi è interessato al problema non sia generalmente un grande appasionato di gaming.
EDIT: ad esempio questo report potrebbe indicare migliorie anche in tal senso:
https://www.reddit.com/r/Amd/comments/7779az/my_amd_2017_experience_with_a_slightly_bumpy/?st=j92wc0xa&sh=5b431f73
200 MHz in più col nuovo processore da soli bastano a rendere i giochi molto più fluidi come riportato? EDIT: o magari intende solo "smoother" nel senso di "senza problemi".
Boh guarda, la situazione non è per nulla chiara, anche perchè c'è anche gente che ha la cpu fallata ma non ha problemi descritti da altri, il che rende la cosa ancora più complicata :fagiano:
alexsky8
22-10-2017, 16:42
come mai affermi ciò? hai avuto problemi?
semplice avevo un 1700 settimana 16 e ho chiesto sostituzione ad Amazon con un altro 1700 e mi è arrivato un settimana 33 anche lui con lo stesso problema seppur molto più efficiente lato OC
quindi a sto punto chiederò sostituzione alla prossima generazione quando dovrebbero aver sistemato (si spera) definitivamente il problema
RMA con AMD non posso farlo, il pc mi serve anche per lavoro non solo cazzeggio e 10gg senza pc non posso stare
semplice avevo un 1700 settimana 16 e ho chiesto sostituzione ad Amazon con un altro 1700 e mi è arrivato un settimana 33 anche lui con lo stesso problema seppur molto più efficiente lato OC
quindi a sto punto chiederò sostituzione alla prossima generazione quando dovrebbero aver sistemato (si spera) definitivamente il problema
RMA con AMD non posso farlo, il pc mi serve anche per lavoro non solo cazzeggio e 10gg senza pc non posso stare
papugo1980
22-10-2017, 16:43
@s12a quindi i problemi in dx12 possono essere causati dal segfault? Io pensavo che la colpa fosse di Nvidia...mi sembra anche a me una volta ha crashato il dx12 il gioco con un errore sulla directx
Debern9093
22-10-2017, 16:48
Non avevi menzionato di avere buttato via la scatola? Molto difficile, IMHO.
Non hai controllato se variando sia a salire che a scendere con vCore e vSoC i segfault dal solito test aumentano/diminuiscono?
no non ho controllato, posso sempre provare :) nel caso regga, cosa starebbe a significare? comunque il processore ha problemi di segfault no?
Non hai controllato se variando sia a salire che a scendere con vCore e vSoC i segfault dal solito test aumentano/diminuiscono?
no non ho controllato, posso sempre provare :) nel caso regga, cosa starebbe a significare? comunque il processore ha problemi di segfault no?
s12a
22-10-2017, 16:52
@s12a quindi i problemi in dx12 possono essere causati dal segfault? Io pensavo che la colpa fosse di Nvidia...mi sembra anche a me una volta ha crashato il dx12 il gioco con un errore sulla directx
Potrebbero, così come no. Non ci sono solo report segfault (et similia), ma anche - come al solito in particolare o comunque meglio osservati su Linux - di problemi di riavvii e crash in particolar modo correlati con l'attivazione dei C-State inferiori (C6) e comunque solo con gli AMD Ryzen. Potrebbe essere un problema indipendente dal segfault (c'è chi ha uno o l'altro, o entrambi i problemi), ma causato dalle stesse problematiche in sede di produzione del processore.
A volte potrebbe essere risolvibile con una patch specifica, come ad esempio sembra essere accaduto per Ashes of the Singularity. Notare che disabilitare l'SMT sembrava evitare i crash secondo quanto riportato dall'utente (come per i segfault):
https://community.amd.com/servlet/JiveServlet/showImage/2-2820964-124486/RYZEN_BUG_AOTS.jpg
no non ho controllato, posso sempre provare :) nel caso regga, cosa starebbe a significare? comunque il processore ha problemi di segfault no?
Il processore sarebbe sempre considerabile difettoso, ma avresti una soluzione pratica per aggirare l'errore nelle situazioni in cui si potrebbe potenzialmente verificare.
Potrebbero, così come no. Non ci sono solo report segfault (et similia), ma anche - come al solito in particolare o comunque meglio osservati su Linux - di problemi di riavvii e crash in particolar modo correlati con l'attivazione dei C-State inferiori (C6) e comunque solo con gli AMD Ryzen. Potrebbe essere un problema indipendente dal segfault (c'è chi ha uno o l'altro, o entrambi i problemi), ma causato dalle stesse problematiche in sede di produzione del processore.
A volte potrebbe essere risolvibile con una patch specifica, come ad esempio sembra essere accaduto per Ashes of the Singularity. Notare che disabilitare l'SMT sembrava evitare i crash secondo quanto riportato dall'utente (come per i segfault):
https://community.amd.com/servlet/JiveServlet/showImage/2-2820964-124486/RYZEN_BUG_AOTS.jpg
no non ho controllato, posso sempre provare :) nel caso regga, cosa starebbe a significare? comunque il processore ha problemi di segfault no?
Il processore sarebbe sempre considerabile difettoso, ma avresti una soluzione pratica per aggirare l'errore nelle situazioni in cui si potrebbe potenzialmente verificare.
alexsky8
22-10-2017, 17:02
dovrei fare ancora qualche test ma per ora disabilitando SMT non mi va in segfault mentre con SMT abilitato sì
Debern9093
22-10-2017, 17:02
Potrebbero, così come no. Non ci sono solo report segfault (et similia), ma anche - come al solito in particolare o comunque meglio osservati su Linux - di problemi di riavvii e crash in particolar modo correlati con l'attivazione dei C-State inferiori (C6) e comunque solo con gli AMD Ryzen. Potrebbe essere un problema indipendente dal segfault (c'è chi ha uno o l'altro, o entrambi i problemi), ma causato dalle stesse problematiche in sede di produzione del processore.
A volte potrebbe essere risolvibile con una patch specifica, come ad esempio sembra essere accaduto per Ashes of the Singularity. Notare che disabilitare l'SMT sembrava evitare i crash secondo quanto riportato dall'utente (come per i segfault):
https://community.amd.com/servlet/JiveServlet/showImage/2-2820964-124486/RYZEN_BUG_AOTS.jpg
Il processore sarebbe sempre considerabile difettoso, ma avresti una soluzione pratica per aggirare l'errore nelle situazioni in cui si potrebbe potenzialmente verificare.
capisco... comunque questa situazione non è sostenibile e personalmente sono abbastanza deluso da amd in quanto tutt'ora non è stato risolto il problema... non so se passerò ad intel a questo punto o aspettare ryzen 2
A volte potrebbe essere risolvibile con una patch specifica, come ad esempio sembra essere accaduto per Ashes of the Singularity. Notare che disabilitare l'SMT sembrava evitare i crash secondo quanto riportato dall'utente (come per i segfault):
https://community.amd.com/servlet/JiveServlet/showImage/2-2820964-124486/RYZEN_BUG_AOTS.jpg
Il processore sarebbe sempre considerabile difettoso, ma avresti una soluzione pratica per aggirare l'errore nelle situazioni in cui si potrebbe potenzialmente verificare.
capisco... comunque questa situazione non è sostenibile e personalmente sono abbastanza deluso da amd in quanto tutt'ora non è stato risolto il problema... non so se passerò ad intel a questo punto o aspettare ryzen 2
malcom499
22-10-2017, 17:30
chi ha acquistato da Amazon e vuole fare sostituzione con loro consiglierei di attendere ancora qualche mesetto, la vicenda non è per nulla sistemata dopo la 25 esima settimana come invece sembrava fino a poco fa
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
semplice avevo un 1700 settimana 16 e ho chiesto sostituzione ad Amazon con un altro 1700 e mi è arrivato un settimana 33 anche lui con lo stesso problema seppur molto più efficiente lato OC
quindi a sto punto chiederò sostituzione alla prossima generazione quando dovrebbero aver sistemato (si spera) definitivamente il problema
RMA con AMD non posso farlo, il pc mi serve anche per lavoro non solo cazzeggio e 10gg senza pc non posso stare
Anchio ho ricevuto venerdi da amazon questo [Imgur](https://i.imgur.com/9yiEzqp.jpg)
33esima settimana.
La mia non sembra fallata dopo 5 test completi su tutti i core e altri 2 test da 4 4 l'ultimo quello di oggi da 4 ore, mai nessun errore di segfault.
Per mettermi l'anima in pace e liberare la chiavetta da ubuntu :D poi ho fatto altri 2 test completi da 30 min in OC, dissi originale, 3.8 ghz, ram a 3200 con 1.21vcore, tutto liscio...oltretutto sembra una grande cpu in oc.
chi fa invece RMA con AMD deve essere consapevole delle tempistiche niente affatto brevi
semplice avevo un 1700 settimana 16 e ho chiesto sostituzione ad Amazon con un altro 1700 e mi è arrivato un settimana 33 anche lui con lo stesso problema seppur molto più efficiente lato OC
quindi a sto punto chiederò sostituzione alla prossima generazione quando dovrebbero aver sistemato (si spera) definitivamente il problema
RMA con AMD non posso farlo, il pc mi serve anche per lavoro non solo cazzeggio e 10gg senza pc non posso stare
Anchio ho ricevuto venerdi da amazon questo [Imgur](https://i.imgur.com/9yiEzqp.jpg)
33esima settimana.
La mia non sembra fallata dopo 5 test completi su tutti i core e altri 2 test da 4 4 l'ultimo quello di oggi da 4 ore, mai nessun errore di segfault.
Per mettermi l'anima in pace e liberare la chiavetta da ubuntu :D poi ho fatto altri 2 test completi da 30 min in OC, dissi originale, 3.8 ghz, ram a 3200 con 1.21vcore, tutto liscio...oltretutto sembra una grande cpu in oc.
Mister D
22-10-2017, 17:48
capisco... comunque questa situazione non è sostenibile e personalmente sono abbastanza deluso da amd in quanto tutt'ora non è stato risolto il problema... non so se passerò ad intel a questo punto o aspettare ryzen 2
Ciao,
capisco che tu possa essere deluso ma non puoi dire che non è stato risolto il problema perché non è vero, altrimenti tutti quelli che hanno fatto RMA con AMD avrebbero segnalato di avere ancora problemi.
Per il fatto che AMD invece non abbia rilasciato dichiarazione ufficiale né rilasciato la lista di tutti gli errata delle cpu ryzen /TR step b1 e epyc step b2 siamo d'accordo e sono anche io deluso.
Ma per favore cerchiamo di scrivere cose corrette perché se no si rischia di fare disinformazione e inutile allarmismo.
Per essere esplicito:
1) il problema esiste
2) AMD ha ammesso a phoronix e sul suo blog l'esistenza del problema e lo ha identificato in una errata selezione delle cpu, in particolare nel quality test:
2-A) da questo non tutte le cpu prodotte prima di una certa data (che era stata SOLO IPOTIZZATA da proronix nella 25a settimana) hanno tale problema. Non faccio numeri perché sarebbe ridicolo, in quanto solo AMD lo può sapere con esattezza. L'unico numero ufficiale è che almeno il 5%+x di cpu selezionate non lo ha, essendo il 5% le cpu TR.
2-B) AMD ha cambiato in una certa data il quality test e quindi da quella data possiamo avere la ragionevole certezza che tutte le cpu non hanno tale problema.
3) AMD ha correttamente dichiarato di sostituire tutte le cpu che mostrino il problema con RMA diretta (e come poteva dire di no visto che è una prassi di legge?) con una cpu da loro testata.
A fronte di ciò, come puoi dire che AMD non ha risolto il problema? Perché facendo reso con amazon/altro venditore, questo ti può mandare una cpu di lotto precedente al cambio del test? Ma certo che può succedere ed è per questo AMD ha consigliato RMA diretta. RMA diretta ha dei costi in termini monetari e di tempo? Sì come accade anche con altri componenti: solitamente la spedizione di andata è a carico del cliente finale e le tempistiche variano da produttore a produttore ma meno di una settimana / 10 giorni è difficile che riescano a sostituirti il componente (RAM e hd mi ci hanno sempre impiegato circa 2 settimane).
Se invece ti riferisci agli unici 2 casi in cui dopo RMA hanno ancora il problema, in quella tabella:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
non c'è scritto nulla di come è stato condotto il test (tipo erano con ram in oc o a 2133/2400?) o se sono stati i primi ad aver chiesto RMA e AMD ancora non aveva capito il problema ragion per cui gli ha mandato indietro 2 cpu senza essere testate.
Ripeto, hai tutto il sacrosanto diritto di essere deluso ma questo non toglie che AMD il suo dovere lo ha fatto, in modo poco trasparente (gli errata non pubblicati), ma lo ha fatto e se fai domanda di RMA, te l'accetta e ti manda una cpu testata esente da problema.
Ciao,
capisco che tu possa essere deluso ma non puoi dire che non è stato risolto il problema perché non è vero, altrimenti tutti quelli che hanno fatto RMA con AMD avrebbero segnalato di avere ancora problemi.
Per il fatto che AMD invece non abbia rilasciato dichiarazione ufficiale né rilasciato la lista di tutti gli errata delle cpu ryzen /TR step b1 e epyc step b2 siamo d'accordo e sono anche io deluso.
Ma per favore cerchiamo di scrivere cose corrette perché se no si rischia di fare disinformazione e inutile allarmismo.
Per essere esplicito:
1) il problema esiste
2) AMD ha ammesso a phoronix e sul suo blog l'esistenza del problema e lo ha identificato in una errata selezione delle cpu, in particolare nel quality test:
2-A) da questo non tutte le cpu prodotte prima di una certa data (che era stata SOLO IPOTIZZATA da proronix nella 25a settimana) hanno tale problema. Non faccio numeri perché sarebbe ridicolo, in quanto solo AMD lo può sapere con esattezza. L'unico numero ufficiale è che almeno il 5%+x di cpu selezionate non lo ha, essendo il 5% le cpu TR.
2-B) AMD ha cambiato in una certa data il quality test e quindi da quella data possiamo avere la ragionevole certezza che tutte le cpu non hanno tale problema.
3) AMD ha correttamente dichiarato di sostituire tutte le cpu che mostrino il problema con RMA diretta (e come poteva dire di no visto che è una prassi di legge?) con una cpu da loro testata.
A fronte di ciò, come puoi dire che AMD non ha risolto il problema? Perché facendo reso con amazon/altro venditore, questo ti può mandare una cpu di lotto precedente al cambio del test? Ma certo che può succedere ed è per questo AMD ha consigliato RMA diretta. RMA diretta ha dei costi in termini monetari e di tempo? Sì come accade anche con altri componenti: solitamente la spedizione di andata è a carico del cliente finale e le tempistiche variano da produttore a produttore ma meno di una settimana / 10 giorni è difficile che riescano a sostituirti il componente (RAM e hd mi ci hanno sempre impiegato circa 2 settimane).
Se invece ti riferisci agli unici 2 casi in cui dopo RMA hanno ancora il problema, in quella tabella:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
non c'è scritto nulla di come è stato condotto il test (tipo erano con ram in oc o a 2133/2400?) o se sono stati i primi ad aver chiesto RMA e AMD ancora non aveva capito il problema ragion per cui gli ha mandato indietro 2 cpu senza essere testate.
Ripeto, hai tutto il sacrosanto diritto di essere deluso ma questo non toglie che AMD il suo dovere lo ha fatto, in modo poco trasparente (gli errata non pubblicati), ma lo ha fatto e se fai domanda di RMA, te l'accetta e ti manda una cpu testata esente da problema.
Gioz
22-10-2017, 18:16
La mia non sembra fallata dopo 5 test completi su tutti i core e altri 2 test da 4 4 l'ultimo quello di oggi da 4 ore, mai nessun errore di segfault.
solo per precisazione, se si esegue il test senza fornire argomenti vengono istanziate 16 build parallele, se passi 4 4 vengono istanziate 4 build a cui sono assegnati 4 thread hardware quindi funzionano 8 core 16 th, se passi 8 2 richiedi 8 build da svoglere con 2 thread hardware.
quei valori sono suggeriti perché in questa maniera richiede meno memoria e quindi risulta eseguibile anche avendo 16gb o meno di ram perchè sono di fatto stai istanziando un numero minore di compilazioni simultanee ma la cpu può lavorare a pieno carico ugualmente.
per impiegare 4 core dovresti passare, ad esempio, 2 2.
solo per precisazione, se si esegue il test senza fornire argomenti vengono istanziate 16 build parallele, se passi 4 4 vengono istanziate 4 build a cui sono assegnati 4 thread hardware quindi funzionano 8 core 16 th, se passi 8 2 richiedi 8 build da svoglere con 2 thread hardware.
quei valori sono suggeriti perché in questa maniera richiede meno memoria e quindi risulta eseguibile anche avendo 16gb o meno di ram perchè sono di fatto stai istanziando un numero minore di compilazioni simultanee ma la cpu può lavorare a pieno carico ugualmente.
per impiegare 4 core dovresti passare, ad esempio, 2 2.
malcom499
22-10-2017, 18:43
solo per precisazione, se si esegue il test senza fornire argomenti vengono istanziate 16 build parallele, se passi 4 4 vengono istanziate 4 build a cui sono assegnati 4 thread hardware quindi funzionano 8 core 16 th, se passi 8 2 richiedi 8 build da svoglere con 2 thread hardware.
quei valori sono suggeriti perché in questa maniera richiede meno memoria e quindi risulta eseguibile anche avendo 16gb o meno di ram perchè sono di fatto stai istanziando un numero minore di compilazioni simultanee ma la cpu può lavorare a pieno carico ugualmente.
per impiegare 4 core dovresti passare, ad esempio, 2 2.
....e stavo per cancellare ubuntu dalla chiavetta...ecco qua :D
non mi costa niente, provo anche 2 2 ..
quei valori sono suggeriti perché in questa maniera richiede meno memoria e quindi risulta eseguibile anche avendo 16gb o meno di ram perchè sono di fatto stai istanziando un numero minore di compilazioni simultanee ma la cpu può lavorare a pieno carico ugualmente.
per impiegare 4 core dovresti passare, ad esempio, 2 2.
....e stavo per cancellare ubuntu dalla chiavetta...ecco qua :D
non mi costa niente, provo anche 2 2 ..
alexsky8
22-10-2017, 19:17
A fronte di ciò, come puoi dire che AMD non ha risolto il problema? Perché facendo reso con amazon/altro venditore, questo ti può mandare una cpu di lotto precedente al cambio del test? Ma certo che può succedere ed è per questo AMD ha consigliato RMA diretta. RMA diretta ha dei costi in termini monetari e di tempo? Sì come accade anche con altri componenti: solitamente la spedizione di andata è a carico del cliente finale e le tempistiche variano da produttore a produttore ma meno di una settimana / 10 giorni è difficile che riescano a sostituirti il componente (RAM e hd mi ci hanno sempre impiegato circa 2 settimane).
Se invece ti riferisci agli unici 2 casi in cui dopo RMA hanno ancora il problema, in quella tabella:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
non c'è scritto nulla di come è stato condotto il test (tipo erano con ram in oc o a 2133/2400?) o se sono stati i primi ad aver chiesto RMA e AMD ancora non aveva capito il problema ragion per cui gli ha mandato indietro 2 cpu senza essere testate.
Ripeto, hai tutto il sacrosanto diritto di essere deluso ma questo non toglie che AMD il suo dovere lo ha fatto, in modo poco trasparente (gli errata non pubblicati), ma lo ha fatto e se fai domanda di RMA, te l'accetta e ti manda una cpu testata esente da problema.
capisco tutto ma inizialmente sembrava che il problema fosse circoscritto alle settimane 1->25 e invece così non è perchè l'errore si presenta anche ben oltre e questo nonostante AMD sapesse l'esistenza del problema
chi acquista da AMAZON lo fa per avere una sostituzione celere nei 2 anni anche a costo a volte di pagare qualcosa in più rispetto ad altri venditori; questo è una manna per chi si costruisce un PC anche per lavoro perchè ti consente di non rimanere a piedi per giorni e giorni con RMA del produttore
se però in questo caso il problema del controllo da parte di AMD non è stato risolto vorrà dire che attenderò la futura generazione per la sostituzione visto che ho tempo sino ad Ottobre 2019 per la garanzia legale
Se invece ti riferisci agli unici 2 casi in cui dopo RMA hanno ancora il problema, in quella tabella:
https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0
non c'è scritto nulla di come è stato condotto il test (tipo erano con ram in oc o a 2133/2400?) o se sono stati i primi ad aver chiesto RMA e AMD ancora non aveva capito il problema ragion per cui gli ha mandato indietro 2 cpu senza essere testate.
Ripeto, hai tutto il sacrosanto diritto di essere deluso ma questo non toglie che AMD il suo dovere lo ha fatto, in modo poco trasparente (gli errata non pubblicati), ma lo ha fatto e se fai domanda di RMA, te l'accetta e ti manda una cpu testata esente da problema.
capisco tutto ma inizialmente sembrava che il problema fosse circoscritto alle settimane 1->25 e invece così non è perchè l'errore si presenta anche ben oltre e questo nonostante AMD sapesse l'esistenza del problema
chi acquista da AMAZON lo fa per avere una sostituzione celere nei 2 anni anche a costo a volte di pagare qualcosa in più rispetto ad altri venditori; questo è una manna per chi si costruisce un PC anche per lavoro perchè ti consente di non rimanere a piedi per giorni e giorni con RMA del produttore
se però in questo caso il problema del controllo da parte di AMD non è stato risolto vorrà dire che attenderò la futura generazione per la sostituzione visto che ho tempo sino ad Ottobre 2019 per la garanzia legale
papugo1980
22-10-2017, 20:01
@s12a ecco il problema in DX12 al minuto 0.09 e 3.13
https://youtu.be/XgnHcOmE1YA
Cmq lunedì i martedì mi arriva il 1700 sostitutivo e vediamo
https://youtu.be/XgnHcOmE1YA
Cmq lunedì i martedì mi arriva il 1700 sostitutivo e vediamo
Mister D
22-10-2017, 22:35
capisco tutto ma inizialmente sembrava che il problema fosse circoscritto alle settimane 1->25 e invece così non è perchè l'errore si presenta anche ben oltre e questo nonostante AMD sapesse l'esistenza del problema
Quella ipotesi l'hanno fatta su phoronix e non viene da AMD, che purtroppo, non ha specificato quando ha fatto il cambio di test di qualità.
https://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1
AMD has not provided an official public explanation of the fundamental problem, but from those in our forums and elsewhere, it appears to affect Ryzen CPUs manufactured prior to week 25.
Ma se ci pensi ha poco senso logico visto che il 7 agosto 2018 phoronix riceveva e scriveva della conferma dei test interni di amd:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response
Se il 7 agosto AMD dichiarava ufficiosamente di aver trovato il problema a quelli di phorinx è lecito e ragionevole ipotizzare che:
1) fino all'inizio di agosto AMD ha continuato ad utilizzare il vecchio test di qualità
2) da una certa settimana di agosto o ancora meglio da settembre AMD ha cambiato sto cavolo di test per le sue cpu e quindi solo da far data in avanti le cpu saranno esenti, tutte.
3) i magazzini dei vari distributori/venditori impiegheranno a smaltire le vecchie cpu già ricevute, per questo AMD ha rassicurato la propria clientela per la procedura di RMA da fare diretta con loro.
Come fai a dire quanto ti ho sottolineato in grassetto??? Che prove hai per dirlo?
Senza polemica ma AMD per me proprio non lo sapeva e si vede pure dal fatto di averci messo del tempo con l'investigazione. Il primo articolo di phoronix risale a giugno e AMD non aveva dato risposta, anzi aveva detto che avrebbe indagato sul problema. Sarebbe gravissimo se avesse saputo e non avesse ottemperato alla sostituzione con cpu esenti (ho più di un sospetto che ai primi che hanno fatto richiesta di RMA AMD manco sapesse del problema e ha spedito cpu di ritorno che erano identiche alle altre ma è un mio sospetto senza prove: nel doc sul google c'è solo un indizio e cioè uno che risolve il problema alla seconda RMA).
chi acquista da AMAZON lo fa per avere una sostituzione celere nei 2 anni anche a costo a volte di pagare qualcosa in più rispetto ad altri venditori; questo è una manna per chi si costruisce un PC anche per lavoro perchè ti consente di non rimanere a piedi per giorni e giorni con RMA del produttore
se però in questo caso il problema del controllo da parte di AMD non è stato risolto vorrà dire che attenderò la futura generazione per la sostituzione visto che ho tempo sino ad Ottobre 2019 per la garanzia legale
Capisco benissimo il problema del fermo macchina e dell'utilità del servizio di reso di amazon. Ma amazon in questo caso non può fare nulla (se non quella di cercare di rispettare la richiesta dell'utente nella sostituzione, es voglio una cpu prodotta da settembre in poi cioè settimana 36) e per un problema del genere spetta ad AMD, cioè il produttore, perché sa come testare la cpu per sostituirla con una sicuramente esente da difetto. La garanzia legale del venditore e quella commerciale del produttore sono 2 cose ben diverse che non vanno a sostituirsi l'una all'altra:
https://www.laleggepertutti.it/78035_garanzia-legale-di-conformita-e-del-produttore-regole-e-differenze
Aggiungo che la garanzia legale del venditore si riduce ad un anno per acquisti fatti con partita IVA perché c'è, purtroppo, la presunzione che essendo usati per lavoro, i prodotti verranno usati di più (ma questa è un altra storia - per chi vuole basta che si cerca su google la norma comunitaria per la garanzia legale e troverà il comma che esplicita la riduzione ad un anno per chi acquista con PIVA. L'ultima volta che ho controllato però qualche anno fa, non so se sia cambiato qualcosa in meglio).;)
Quella ipotesi l'hanno fatta su phoronix e non viene da AMD, che purtroppo, non ha specificato quando ha fatto il cambio di test di qualità.
https://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1
AMD has not provided an official public explanation of the fundamental problem, but from those in our forums and elsewhere, it appears to affect Ryzen CPUs manufactured prior to week 25.
Ma se ci pensi ha poco senso logico visto che il 7 agosto 2018 phoronix riceveva e scriveva della conferma dei test interni di amd:
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response
Se il 7 agosto AMD dichiarava ufficiosamente di aver trovato il problema a quelli di phorinx è lecito e ragionevole ipotizzare che:
1) fino all'inizio di agosto AMD ha continuato ad utilizzare il vecchio test di qualità
2) da una certa settimana di agosto o ancora meglio da settembre AMD ha cambiato sto cavolo di test per le sue cpu e quindi solo da far data in avanti le cpu saranno esenti, tutte.
3) i magazzini dei vari distributori/venditori impiegheranno a smaltire le vecchie cpu già ricevute, per questo AMD ha rassicurato la propria clientela per la procedura di RMA da fare diretta con loro.
Come fai a dire quanto ti ho sottolineato in grassetto??? Che prove hai per dirlo?
Senza polemica ma AMD per me proprio non lo sapeva e si vede pure dal fatto di averci messo del tempo con l'investigazione. Il primo articolo di phoronix risale a giugno e AMD non aveva dato risposta, anzi aveva detto che avrebbe indagato sul problema. Sarebbe gravissimo se avesse saputo e non avesse ottemperato alla sostituzione con cpu esenti (ho più di un sospetto che ai primi che hanno fatto richiesta di RMA AMD manco sapesse del problema e ha spedito cpu di ritorno che erano identiche alle altre ma è un mio sospetto senza prove: nel doc sul google c'è solo un indizio e cioè uno che risolve il problema alla seconda RMA).
chi acquista da AMAZON lo fa per avere una sostituzione celere nei 2 anni anche a costo a volte di pagare qualcosa in più rispetto ad altri venditori; questo è una manna per chi si costruisce un PC anche per lavoro perchè ti consente di non rimanere a piedi per giorni e giorni con RMA del produttore
se però in questo caso il problema del controllo da parte di AMD non è stato risolto vorrà dire che attenderò la futura generazione per la sostituzione visto che ho tempo sino ad Ottobre 2019 per la garanzia legale
Capisco benissimo il problema del fermo macchina e dell'utilità del servizio di reso di amazon. Ma amazon in questo caso non può fare nulla (se non quella di cercare di rispettare la richiesta dell'utente nella sostituzione, es voglio una cpu prodotta da settembre in poi cioè settimana 36) e per un problema del genere spetta ad AMD, cioè il produttore, perché sa come testare la cpu per sostituirla con una sicuramente esente da difetto. La garanzia legale del venditore e quella commerciale del produttore sono 2 cose ben diverse che non vanno a sostituirsi l'una all'altra:
https://www.laleggepertutti.it/78035_garanzia-legale-di-conformita-e-del-produttore-regole-e-differenze
Aggiungo che la garanzia legale del venditore si riduce ad un anno per acquisti fatti con partita IVA perché c'è, purtroppo, la presunzione che essendo usati per lavoro, i prodotti verranno usati di più (ma questa è un altra storia - per chi vuole basta che si cerca su google la norma comunitaria per la garanzia legale e troverà il comma che esplicita la riduzione ad un anno per chi acquista con PIVA. L'ultima volta che ho controllato però qualche anno fa, non so se sia cambiato qualcosa in meglio).;)
alexsky8
23-10-2017, 08:25
Se il 7 agosto AMD dichiarava ufficiosamente di aver trovato il problema a quelli di phorinx è lecito e ragionevole ipotizzare che:
1) fino all'inizio di agosto AMD ha continuato ad utilizzare il vecchio test di qualità
2) da una certa settimana di agosto o ancora meglio da settembre AMD ha cambiato sto cavolo di test per le sue cpu e quindi solo da far data in avanti le cpu saranno esenti, tutte.
il mio settimana 33 prodotto ad inizio settembre ne è affetto
Processor OPN: YD1700BBAEBOX
Packing Type: P
Delivery Date: 2017-09-06
MFG Date: 2017-09-05
comunque vediamo, per ora non cambio attenderò ryzen 2 e poi chiederò sostituzione o cambio la prossima primavera inoltrata
1) fino all'inizio di agosto AMD ha continuato ad utilizzare il vecchio test di qualità
2) da una certa settimana di agosto o ancora meglio da settembre AMD ha cambiato sto cavolo di test per le sue cpu e quindi solo da far data in avanti le cpu saranno esenti, tutte.
il mio settimana 33 prodotto ad inizio settembre ne è affetto
Processor OPN: YD1700BBAEBOX
Packing Type: P
Delivery Date: 2017-09-06
MFG Date: 2017-09-05
comunque vediamo, per ora non cambio attenderò ryzen 2 e poi chiederò sostituzione o cambio la prossima primavera inoltrata
Mister D
23-10-2017, 09:05
il mio settimana 33 prodotto ad inizio settembre ne è affetto
Processor OPN: YD1700BBAEBOX
Packing Type: P
Delivery Date: 2017-09-06
MFG Date: 2017-09-05
comunque vediamo, per ora non cambio attenderò ryzen 2 e poi chiederò sostituzione o cambio la prossima primavera inoltrata
Quel delivery date e mfg date per me dicono solo che è stato impachettato a settembre ma il die è stato prodotto nella settimana 33 che a casa mia è la settimana di ferragosto. Non so quando venga fatto il test di selezione, ma per me viene fatto sul die e non una volta mandato per l'assemblaggio sul pcb e saldatura his. Immagino che non abbia molto senso fare la selezione una volta già assemblata la cpu.
Inoltre purtroppo facendolo sostituire da amazon (e capisco la tua necessità) purtroppo non puoi avere la certezza di avere una cpu esente da problemi. Amd invece avrà nel suo magazzino cpu anche delle prime settimane di produzione per le rma ma te la testa prima di mandarla a te cliente.
Processor OPN: YD1700BBAEBOX
Packing Type: P
Delivery Date: 2017-09-06
MFG Date: 2017-09-05
comunque vediamo, per ora non cambio attenderò ryzen 2 e poi chiederò sostituzione o cambio la prossima primavera inoltrata
Quel delivery date e mfg date per me dicono solo che è stato impachettato a settembre ma il die è stato prodotto nella settimana 33 che a casa mia è la settimana di ferragosto. Non so quando venga fatto il test di selezione, ma per me viene fatto sul die e non una volta mandato per l'assemblaggio sul pcb e saldatura his. Immagino che non abbia molto senso fare la selezione una volta già assemblata la cpu.
Inoltre purtroppo facendolo sostituire da amazon (e capisco la tua necessità) purtroppo non puoi avere la certezza di avere una cpu esente da problemi. Amd invece avrà nel suo magazzino cpu anche delle prime settimane di produzione per le rma ma te la testa prima di mandarla a te cliente.
alexsky8
23-10-2017, 09:48
spero solo che con Ryzen 2 il problema possa essere risolto definitivamente ;)
paolo.oliva2
23-10-2017, 10:25
Sinceramente credo che il problema non sia nella selezione del procio in sè, quanto più nel settore di destinazione del procio, cioè se desktop, TR o Epyc.
Facendo OC, l'RS di Zen (X8) è molto dipendente dal SOC e L3 in rapporto al carico.
Abbiamo visto tutti del limite di 4,140GHz con Cinebench e programmi similari, mentre invece con altro si poteva tenerlo a 4,2GHz con stabilità simili.
Che le cache hanno la stessa frequenza dei core, ok, è ufficiale e lo aveva già riportato AMD stessa, ma "dietro" ci deve essere altro... perchè il comportamento (ed i valori) rilevato su un X8 3GHz ed un X8 @4GHz, hanno un incremento del 33% lato core coerente (4GHz è +33% vs 3GHz) ma lato cache e sollecitazione SOC è di gran lunga superiore.
Personalmente ho visto che dalle prime release del bios, le velocità delle cache L1/L2 e L3 erano aumentate, per poi calare. Addirittura per la CH6 con gli ultimi bios le cache vanno più piano rispetto ai primissimi bios.
Ora... non credo che la cosa dipenda dalle varie case produttrici di mobo e relativo bios, quanto, invece, di AMD stessa con l'AGESA (credo che sia proprio l'Agesa che parametrizzi il tutto), e qui ci sta che con le varie versioni Agesa se da una parte migliora il supporto alle DDR4, dall'altra il rapporto tra frequenza core e cache debba rilassarsi.
A spannella, mi sembra che la L3 di un 8700K occato a @4,7GHz raschi i 400GB/s, Zen a @4GHz raschia i 500GB/s, quindi sarei dell'idea che da una parte Intel abbia portato le frequenze core al max, ma anche AMD, nell'AM4, ha cercato il max del max con tutto l'I/O, visto che di certo non poteva competere con Intel con la max frequenza core.
------
P.S.
Personalmente, io sfrutto un X8/16TH al massimo delle capacità, caricando più programmi contemporaneamente. Una cosa è portare 8 core al massimo dei TH con 1 programma, tutt'altro la stessa situazione con più programmi contemporaneamente. Per evitare fraintendimenti, non sto dicendo che ho prb RS a 4GHz, però "sento" che il procio ha un funzionamento più fluido stracaricandolo con parametri più "rilassati", cioè il problema non è l'OC a 4GHz di per sè, e nemmeno le DDR4 3600 prese singolarmente, ma l'insieme ivi compreso l'utilizzo. Forse @4GHz e DDR4 3600 si potranno anche tenere per il gioco, ma se fai parallelizzazione e sfrutti il procio al 100%, il problema è' tutto nella velocità L3 e in connessione SOC e DDR4.
Facendo OC, l'RS di Zen (X8) è molto dipendente dal SOC e L3 in rapporto al carico.
Abbiamo visto tutti del limite di 4,140GHz con Cinebench e programmi similari, mentre invece con altro si poteva tenerlo a 4,2GHz con stabilità simili.
Che le cache hanno la stessa frequenza dei core, ok, è ufficiale e lo aveva già riportato AMD stessa, ma "dietro" ci deve essere altro... perchè il comportamento (ed i valori) rilevato su un X8 3GHz ed un X8 @4GHz, hanno un incremento del 33% lato core coerente (4GHz è +33% vs 3GHz) ma lato cache e sollecitazione SOC è di gran lunga superiore.
Personalmente ho visto che dalle prime release del bios, le velocità delle cache L1/L2 e L3 erano aumentate, per poi calare. Addirittura per la CH6 con gli ultimi bios le cache vanno più piano rispetto ai primissimi bios.
Ora... non credo che la cosa dipenda dalle varie case produttrici di mobo e relativo bios, quanto, invece, di AMD stessa con l'AGESA (credo che sia proprio l'Agesa che parametrizzi il tutto), e qui ci sta che con le varie versioni Agesa se da una parte migliora il supporto alle DDR4, dall'altra il rapporto tra frequenza core e cache debba rilassarsi.
A spannella, mi sembra che la L3 di un 8700K occato a @4,7GHz raschi i 400GB/s, Zen a @4GHz raschia i 500GB/s, quindi sarei dell'idea che da una parte Intel abbia portato le frequenze core al max, ma anche AMD, nell'AM4, ha cercato il max del max con tutto l'I/O, visto che di certo non poteva competere con Intel con la max frequenza core.
------
P.S.
Personalmente, io sfrutto un X8/16TH al massimo delle capacità, caricando più programmi contemporaneamente. Una cosa è portare 8 core al massimo dei TH con 1 programma, tutt'altro la stessa situazione con più programmi contemporaneamente. Per evitare fraintendimenti, non sto dicendo che ho prb RS a 4GHz, però "sento" che il procio ha un funzionamento più fluido stracaricandolo con parametri più "rilassati", cioè il problema non è l'OC a 4GHz di per sè, e nemmeno le DDR4 3600 prese singolarmente, ma l'insieme ivi compreso l'utilizzo. Forse @4GHz e DDR4 3600 si potranno anche tenere per il gioco, ma se fai parallelizzazione e sfrutti il procio al 100%, il problema è' tutto nella velocità L3 e in connessione SOC e DDR4.
Debern9093
23-10-2017, 10:41
Ragazzi probabilmente effettuo rma anche io.. Il sito AMD mi chiede part number e serial number della CPU, dove si possono recuperare? Anche senza smontare la CPU e possibile?
papugo1980
23-10-2017, 13:31
Mi è arrivato il 1700 sostitutivo e non l ho potuto ritirare:muro:
Allucinante la cosa..per poco non lo preso a schiaffi a quello della posta..:mad:
Allucinante la cosa..per poco non lo preso a schiaffi a quello della posta..:mad:
Debern9093
23-10-2017, 13:32
Mi è arrivato il 1700 sostitutivo e non l ho potuto ritirare:muro:
Allucinante la cosa..per poco non lo preso a schiaffi a quello della posta..:mad:
Perdonami sapresti indicarmi dove reperire part number e serial number per fare rma?
Allucinante la cosa..per poco non lo preso a schiaffi a quello della posta..:mad:
Perdonami sapresti indicarmi dove reperire part number e serial number per fare rma?
alexsky8
23-10-2017, 13:35
Perdonami sapresti indicarmi dove reperire part number e serial number per fare rma?
sulla scatola dove c'è il sigillo bianco
sulla scatola dove c'è il sigillo bianco
papugo1980
23-10-2017, 13:36
Perdonami sapresti indicarmi dove reperire part number e serial number per fare rma?
Sulla scatola ce il serial number SN#: e il codice
Part number credo inserendo il SN sul sito amd che sta in prima pagina
Edit: part number anche sulla scatola
Sulla scatola ce il serial number SN#: e il codice
Part number credo inserendo il SN sul sito amd che sta in prima pagina
Edit: part number anche sulla scatola
metal master
23-10-2017, 13:37
Perdonami sapresti indicarmi dove reperire part number e serial number per fare rma?
nell'etichetta sul pacco
https://www.io-tech.fi/wp-content/uploads/2017/03/ryzen-1800x-4.jpg
sn# e part#
nell'etichetta sul pacco
https://www.io-tech.fi/wp-content/uploads/2017/03/ryzen-1800x-4.jpg
sn# e part#
Debern9093
23-10-2017, 13:42
Purtroppo non ho più la scatola.. E possibile reperire sul processore stesso?
AmuroRei_2
23-10-2017, 13:58
Certo :)
Debern9093
23-10-2017, 14:00
Certo :)
fatto :) grazie
fatto :) grazie
AmuroRei_2
23-10-2017, 14:02
Ottimo forum informativo, proprio ieri un ragazzo mi ha detto con non voleva amd che ha letto che hanno un monte di problemi e non voleva avete problemi mentre gioca con la sua 1060. :help:
Era solo a scopo informativo sul messaggio che riceve un utente normale che deve cambiare pc.
Buona continuazione :D
E questo utente normale dove ha letto di tutti questi problemi con Ryzen! :rolleyes:
Era solo a scopo informativo sul messaggio che riceve un utente normale che deve cambiare pc.
Buona continuazione :D
E questo utente normale dove ha letto di tutti questi problemi con Ryzen! :rolleyes:
Bscity
23-10-2017, 14:37
Se uno non ha più la scatola è possibile fare rma direttamente da Amd?
Cioè lo spedisco senza scatola me lo accetterebbero?
Cioè lo spedisco senza scatola me lo accetterebbero?
beee
23-10-2017, 17:42
Basta cercare su Google e trovi una marea di post del forum che ci sta ospitando e tra questi nelle varie sezioni si legge continuamente dei BUG di RYZEN.
Ps l'utente medio non si assembla il pc ma fa ricerche tramite Google
Appena fatta la ricerca con chiave 'bug ryzen'.... se l'utente medio non è utOnto capirà che il bug è irrilevante! Con questa ricerca saltano fuori anche i recenti bug intel con l'HyperThreading su Skylake e Kaby Lake....
Insomma, come ho scritto qualche giorno fa, mi sembra solo una corsa a farsi sostituire la cpu con una piu recente e probabilmente con silicio migliore!
Ps l'utente medio non si assembla il pc ma fa ricerche tramite Google
Appena fatta la ricerca con chiave 'bug ryzen'.... se l'utente medio non è utOnto capirà che il bug è irrilevante! Con questa ricerca saltano fuori anche i recenti bug intel con l'HyperThreading su Skylake e Kaby Lake....
Insomma, come ho scritto qualche giorno fa, mi sembra solo una corsa a farsi sostituire la cpu con una piu recente e probabilmente con silicio migliore!
paolo.oliva2
23-10-2017, 19:26
Appena fatta la ricerca con chiave 'bug ryzen'.... se l'utente medio non è utOnto capirà che il bug è irrilevante! Con questa ricerca saltano fuori anche i recenti bug intel con l'HyperThreading su Skylake e Kaby Lake....
Insomma, come ho scritto qualche giorno fa, mi sembra solo una corsa a farsi sostituire la cpu con una piu recente e probabilmente con silicio migliore!
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Insomma, come ho scritto qualche giorno fa, mi sembra solo una corsa a farsi sostituire la cpu con una piu recente e probabilmente con silicio migliore!
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
beee
23-10-2017, 20:03
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Come non quotarti!! :cincin:
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Come non quotarti!! :cincin:
papugo1980
23-10-2017, 20:25
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Pensa che ho letto pure di un utente che chiedeva se la scheda madre x370 gigabyte che monta (scheda di rete intel) se era compatibile con AMD :doh:
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Pensa che ho letto pure di un utente che chiedeva se la scheda madre x370 gigabyte che monta (scheda di rete intel) se era compatibile con AMD :doh:
AmuroRei_2
23-10-2017, 21:01
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Scusate ma qui il quote ci sta tutto!!! :sofico:
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Scusate ma qui il quote ci sta tutto!!! :sofico:
CiccoMan
23-10-2017, 22:19
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Non sono leggende metropolitane... era dall'Athlon64 che AMD non sfornava una cpu competitiva... non fraintendere, per il 90% degli utenti, avere una cpu piuttosto che un'altra non fa differenza, ma obiettivamente negli ultimi anni AMD ha un po' sonnecchiato, lasciando strada libera alla concorrenza.
Ora, Ryzen rappresenta un momento di rinascita per la Rossa (che poi sarebbe Verde, ma vabbuo' :fagiano: ) e il successo che sta avendo è pienamente meritato. Sta storia del Segmentation riguarda solo noi nerd appassionati ed palesemente solo un pretesto che gli heater usano per trollare... per la massa questo problema è inesistente, come è giusto che sia.
L'unico mio rimpianto è di non aver preso Threadripper... non mi sarebbe venuta la smania di cambiare :muro:
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Non sono leggende metropolitane... era dall'Athlon64 che AMD non sfornava una cpu competitiva... non fraintendere, per il 90% degli utenti, avere una cpu piuttosto che un'altra non fa differenza, ma obiettivamente negli ultimi anni AMD ha un po' sonnecchiato, lasciando strada libera alla concorrenza.
Ora, Ryzen rappresenta un momento di rinascita per la Rossa (che poi sarebbe Verde, ma vabbuo' :fagiano: ) e il successo che sta avendo è pienamente meritato. Sta storia del Segmentation riguarda solo noi nerd appassionati ed palesemente solo un pretesto che gli heater usano per trollare... per la massa questo problema è inesistente, come è giusto che sia.
L'unico mio rimpianto è di non aver preso Threadripper... non mi sarebbe venuta la smania di cambiare :muro:
Nautilu$
23-10-2017, 22:20
Il mio 1700 è di metà Aprile...... 14a settimana ..... Sto facendo il test da quasi 1 ora senza problemi....e anche a 3,8Ghz! :D
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
s12a
24-10-2017, 05:24
Il mio 1700 è di metà Aprile...... 14a settimana ..... Sto facendo il test da quasi 1 ora senza problemi....e anche a 3,8Ghz! :D
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
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?
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
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?
papugo1980
24-10-2017, 08:05
Arrivata Cpu sostitutiva 1733SUS
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Nautilu$
24-10-2017, 08:10
Hai provato con impostazioni di overclock non 100% stabili (ma neanche immediatamente instabili) per vedere che succede?
Lo vedrei come test inutile..... Se dopo un po' si bloccasse.... sarebbe più che normale..... come lo farebbe sotto Windows....
Lo vedrei come test inutile..... Se dopo un po' si bloccasse.... sarebbe più che normale..... come lo farebbe sotto Windows....
s12a
24-10-2017, 08:18
Lo vedrei come test inutile..... Se dopo un po' si bloccasse.... sarebbe più che normale..... come lo farebbe sotto Windows....
Il dubbio è: si bloccherebbe con i soliti avvisi di segfault? Oppure qualcosa di diverso od altre modalità?
Il dubbio è: si bloccherebbe con i soliti avvisi di segfault? Oppure qualcosa di diverso od altre modalità?
malcom499
24-10-2017, 08:50
Arrivata Cpu sostitutiva 1733SUS
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Ciao la mia arrivata venerdi da amazon è:
Delivery Date:2017-09-30
MFG Date:2017-09-29
Made in China
Ho visto un utente che ha le stesse date mie ma "made in malesia" e ha segfault.
io 9 test completi alcuni da 30/40min altri fino ad usura ram, un paio 15/20 min, 3 test 4 4 da 60/90/120min, 2 test 2 2 uno da un ora e l'altro di 3 ore e 45 minuti. Alcuni test li ho fatti in OC 3.8 ghz ram a 3200.
Mai Nessun stop (solo per ram esaurita) o errore, solo qualche avviso di carico Cpu.
http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309
Posso affermare al 100% che la mia cpu non è affetta da segfault?
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Ciao la mia arrivata venerdi da amazon è:
Delivery Date:2017-09-30
MFG Date:2017-09-29
Made in China
Ho visto un utente che ha le stesse date mie ma "made in malesia" e ha segfault.
io 9 test completi alcuni da 30/40min altri fino ad usura ram, un paio 15/20 min, 3 test 4 4 da 60/90/120min, 2 test 2 2 uno da un ora e l'altro di 3 ore e 45 minuti. Alcuni test li ho fatti in OC 3.8 ghz ram a 3200.
Mai Nessun stop (solo per ram esaurita) o errore, solo qualche avviso di carico Cpu.
http://www.hwupgrade.it/forum/showpost.php?p=45113591&postcount=309
Posso affermare al 100% che la mia cpu non è affetta da segfault?
papugo1980
24-10-2017, 09:01
Beh credo di si. Conta che quella che ho ora( che devo smontare) fa errore dopo pochi secondi che é partito il test
Operapia
24-10-2017, 11:05
Spero di non offendere nessun fanatico ;) con queste domande:
A chi è tornata la cpu direttamente da AMD? Quanto ci hanno messo
tra test e spedizioni varie?
A chi è tornata la cpu direttamente da AMD? Quanto ci hanno messo
tra test e spedizioni varie?
animeserie
24-10-2017, 11:22
Il problema è che dopo anni di leggende metropolitane del tipo "AMD non va bene per giocare", "AMD non è perfettamente compatibile", il tutto è tutto fuorchè razionale.
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Ma cosa c'entrano adesso Intel, il delid, la piattaforma Amd che accetterà 3 gen di CPU, il rapporto q/p o che AMD offra il doppio dei cores allo stesso prezzo della concorrente ? :doh: Non c'entrano un bel niente.
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
Detto tra noi, se in molti sono felici e contenti di acquistare Intel, che lo facciano, anzi, lo devono fare!!!
A me va benissimo acquistare UNA mobo per 3 release di procio, mi va bene avere 2 core AMD al posto di 1 Intel, mi va bene avere un procio pronto per l'uso e non da deliddare per tenerlo a def con tamb >20°, mi va bene di non acquistare dissipazioni industriali e mi va pure bene consumare la metà per le stesse prestazioni.
Per chi non interessa ciò perchè lo reputa insignificante, Intel aspetta a braccia aperte.
Ma cosa c'entrano adesso Intel, il delid, la piattaforma Amd che accetterà 3 gen di CPU, il rapporto q/p o che AMD offra il doppio dei cores allo stesso prezzo della concorrente ? :doh: Non c'entrano un bel niente.
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
digieffe
24-10-2017, 11:40
Ma cosa c'entrano adesso Intel, il delid, la piattaforma Amd che accetterà 3 gen di CPU, il rapporto q/p o che AMD offra il doppio dei cores allo stesso prezzo della concorrente ? :doh: Non c'entrano un bel niente.
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
quoto
questo tipo di interventi dovrebbero stare nel thread ufficiale.
questo è un thread tecnico inutile inquinarlo.
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
quoto
questo tipo di interventi dovrebbero stare nel thread ufficiale.
questo è un thread tecnico inutile inquinarlo.
Debern9093
24-10-2017, 11:47
Beh credo di si. Conta che quella che ho ora( che devo smontare) fa errore dopo pochi secondi che é partito il test
Scusami, ma non hai prima spedito la tua CPU ad AMD e più re ne manda una sostitutiva?
Scusami, ma non hai prima spedito la tua CPU ad AMD e più re ne manda una sostitutiva?
papugo1980
24-10-2017, 11:52
Scusami, ma non hai prima spedito la tua CPU ad AMD e più re ne manda una sostitutiva?
No.dato che non ho un pc muletto e dato che sono neanche 30 giorni che ho effettuato l acquisto, me la sono fatta sostituire dall' ammazzone specificando il problema (chiedendo anche di non mandarmi un fondo di magazzino ma un nuovo stock)Per provare ad evitare il problema.
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
No.dato che non ho un pc muletto e dato che sono neanche 30 giorni che ho effettuato l acquisto, me la sono fatta sostituire dall' ammazzone specificando il problema (chiedendo anche di non mandarmi un fondo di magazzino ma un nuovo stock)Per provare ad evitare il problema.
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
Debern9093
24-10-2017, 11:54
No.dato che non ho un pc muletto e dato che sono neanche 30 giorni che ho effettuato l acquisto, me la sono fatta sostituire dall' ammazzone specificando il problema (chiedendo anche di non mandarmi un fondo di magazzino ma un nuovo stock)Per provare ad evitare il problema.
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
Ricevuto, grazie :)
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
Ricevuto, grazie :)
alexsky8
24-10-2017, 11:59
Ma cosa c'entrano adesso Intel, il delid, la piattaforma Amd che accetterà 3 gen di CPU, il rapporto q/p o che AMD offra il doppio dei cores allo stesso prezzo della concorrente ? :doh: Non c'entrano un bel niente.
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
infatti come consumatori dovremmo tifare al nostro portafoglio ed ai nostri diritti non certo ad Intel o AMD
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Qui si parla di un bug ben preciso su una CPU, punto.
Ed effettivamente AMD sostituisce senza problemi (se lo fa, significa che è conscia del problema).
Come si fa a non vedere neppure questo, aldilà della portata del problema ?
infatti come consumatori dovremmo tifare al nostro portafoglio ed ai nostri diritti non certo ad Intel o AMD
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Spitfire84
24-10-2017, 12:00
Arrivata Cpu sostitutiva 1733SUS
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Hai fatto il reso in garanzia con AMD? Quanto c'hanno messo a rispedirtela? Io l'ho inviata ad AMD lunedì della settimana scorsa, ma non mi hanno ancora rispedita la CPU nuova.
Delivery Date:2017-09-13
MFG Date:2017-09-11
Made in China
Appena posso smonto tutto e testo se è affetta
Hai fatto il reso in garanzia con AMD? Quanto c'hanno messo a rispedirtela? Io l'ho inviata ad AMD lunedì della settimana scorsa, ma non mi hanno ancora rispedita la CPU nuova.
papugo1980
24-10-2017, 12:02
Hai fatto il reso in garanzia con AMD? Quanto c'hanno messo a rispedirtela? Io l'ho inviata ad AMD lunedì della settimana scorsa, ma non mi hanno ancora rispedita la CPU nuova.
No no.Ho risposto poco sopra ;)
No no.Ho risposto poco sopra ;)
alexsky8
24-10-2017, 12:07
No.dato che non ho un pc muletto e dato che sono neanche 30 giorni che ho effettuato l acquisto, me la sono fatta sostituire dall' ammazzone specificando il problema (chiedendo anche di non mandarmi un fondo di magazzino ma un nuovo stock)Per provare ad evitare il problema.
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
la mia dopo sostituzione è ancora affetta
fare RMA ad AMD significa perdere probabilmente 2 settimane ed è impensabile rimanere senza PC per quel tempo
attenderò ryzen 2 per il prossimo reso, non voglio più rischiare
Se questa pure è affetta mi dovrò organizzare e fare poi RMA direttamente a AMD
la mia dopo sostituzione è ancora affetta
fare RMA ad AMD significa perdere probabilmente 2 settimane ed è impensabile rimanere senza PC per quel tempo
attenderò ryzen 2 per il prossimo reso, non voglio più rischiare
Debern9093
24-10-2017, 12:53
Vi aggiorno sulla mia situazione.. Ho fatto richiesta rma ieri ad AMD e oggi mi hanno già risposto inviando tutto il necessario per spedire.. Rma quindi confermata :D ora mi chiedo, posso inviare tranquillamente la CPU senza scatola originale? Nell'email mi dice soltanto di boxare bene la CPU per non farla danneggiare probabilmente
s12a
24-10-2017, 13:04
Vi aggiorno sulla mia situazione.. Ho fatto richiesta rma ieri ad AMD e oggi mi hanno già risposto inviando tutto il necessario per spedire.. Rma quindi confermata :D
Spese di spedizione a tuo carico o da parte di AMD?
ora mi chiedo, posso inviare tranquillamente la CPU senza scatola originale? Nell'email mi dice soltanto di boxare bene la CPU per non farla danneggiare probabilmente
Per quanto ne sappia vogliono solo il processore, senza necessariamente la scatola originale. Suppongo sarebbe stato opportuno usare almeno il blister originale per proteggere i pin.
https://i.imgur.com/fEjnZVC.jpg
Spese di spedizione a tuo carico o da parte di AMD?
ora mi chiedo, posso inviare tranquillamente la CPU senza scatola originale? Nell'email mi dice soltanto di boxare bene la CPU per non farla danneggiare probabilmente
Per quanto ne sappia vogliono solo il processore, senza necessariamente la scatola originale. Suppongo sarebbe stato opportuno usare almeno il blister originale per proteggere i pin.
https://i.imgur.com/fEjnZVC.jpg
Zino
24-10-2017, 13:11
Che bello! Proprio adesso che mi stavo decidento a prendere un 1600, vedo questo bel topic che mi fa cadere la voglia .... :rolleyes:
s12a
24-10-2017, 13:21
Puoi anche optare di fare finta di nulla e non controllare neanche se ci sia alcun bug - molti sembrano usare il loro processore Ryzen senza apparentemente problemi nell'uso normale anche così.
Mister D
24-10-2017, 13:23
infatti come consumatori dovremmo tifare al nostro portafoglio ed ai nostri diritti non certo ad Intel o AMD
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Cosa non ti è chiaro dopo che sono passate 22 pagine di questa discussione, che il creatore del thread ha scritto tutto e aggiornato costantemente la prima pagina e io rispiegato almeno 3/4 volte la cosa?
Veramente non riesco a capire.:confused:
AMD ha risolto la cosa CAMBIANDO il test di selezione da una certa data di agosto in poi (QUESTA è un MIA ipotesi perché AMD NON ha dichiarato l'esatta data di cambio test selettivo).
Da quella data in poi TUTTE le cpu sono esenti. Solo che i vari distributori/venditore hanno in giro cpu più vecchie.
Tu allora so dove vuoi andare a parare e ti starai chiedendo: "Perché AMD allora non le ha ritirate tutte?"
Risposta ennesima sulla questione: perché NON tutte le cpu prodotte con il primo test di selezione die sono afflitte da sto bug, per cui hanno deciso che era una spesa inutile far un rientro di tutte le cpu se non tutte le cpu sono fallate. Chiaro ora?
Il mio 1700 è di metà Aprile...... 14a settimana ..... Sto facendo il test da quasi 1 ora senza problemi....e anche a 3,8Ghz! :D
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
E come lui sopra anche Tcx e DarkAngel hanno cpu delle prime settimane esenti da problema, come capitato a Phoronix. Ok saranno pochissime in tutto il mondo ma ci sono e questo è il perché AMD non ha ritirato tutte le cpu né elaborato un workaround via bios con aggiornamento AGESA.
Magari saranno un 60% delle 95% prodotte prima del cambio test, forse un 75% di quelle 95% ma questo non toglie che la scelta di AMD possa essere condivisibile. Io non farei mai un rientro totale se non sono coinvolte tutte le cpu e mi pare ci sia poco da discutere con questo.
Che poi te, per non avere il fermo macchina dovuto a RMA diretta con AMD, vuoi aspettare altro mese prima di ritentare da amazon (o direttamente ryzen 2 ma non capisco sinceramente perché tenersi una cpu fallata se ti serve per lavoro) mi pare giusto e convisibile ma su questo non ha colpe AMD. Almeno io la vedo così;)
PS: 95% e non 100% perché i die per TR sono selezionati al 5% dell'intera produzione ryzen e siccome tutte le cpu TR sono esenti (parola di AMD) allora a rigor di logica il totale delle cpu prodotte prima del cambio del test che POSSONO avere il problema è il 95% e non il 100%.;)
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Cosa non ti è chiaro dopo che sono passate 22 pagine di questa discussione, che il creatore del thread ha scritto tutto e aggiornato costantemente la prima pagina e io rispiegato almeno 3/4 volte la cosa?
Veramente non riesco a capire.:confused:
AMD ha risolto la cosa CAMBIANDO il test di selezione da una certa data di agosto in poi (QUESTA è un MIA ipotesi perché AMD NON ha dichiarato l'esatta data di cambio test selettivo).
Da quella data in poi TUTTE le cpu sono esenti. Solo che i vari distributori/venditore hanno in giro cpu più vecchie.
Tu allora so dove vuoi andare a parare e ti starai chiedendo: "Perché AMD allora non le ha ritirate tutte?"
Risposta ennesima sulla questione: perché NON tutte le cpu prodotte con il primo test di selezione die sono afflitte da sto bug, per cui hanno deciso che era una spesa inutile far un rientro di tutte le cpu se non tutte le cpu sono fallate. Chiaro ora?
Il mio 1700 è di metà Aprile...... 14a settimana ..... Sto facendo il test da quasi 1 ora senza problemi....e anche a 3,8Ghz! :D
...che dite?:)
https://www.dropbox.com/s/utfnn3q97o1j31f/IMG_20171023_231830.jpg?dl=0
E come lui sopra anche Tcx e DarkAngel hanno cpu delle prime settimane esenti da problema, come capitato a Phoronix. Ok saranno pochissime in tutto il mondo ma ci sono e questo è il perché AMD non ha ritirato tutte le cpu né elaborato un workaround via bios con aggiornamento AGESA.
Magari saranno un 60% delle 95% prodotte prima del cambio test, forse un 75% di quelle 95% ma questo non toglie che la scelta di AMD possa essere condivisibile. Io non farei mai un rientro totale se non sono coinvolte tutte le cpu e mi pare ci sia poco da discutere con questo.
Che poi te, per non avere il fermo macchina dovuto a RMA diretta con AMD, vuoi aspettare altro mese prima di ritentare da amazon (o direttamente ryzen 2 ma non capisco sinceramente perché tenersi una cpu fallata se ti serve per lavoro) mi pare giusto e convisibile ma su questo non ha colpe AMD. Almeno io la vedo così;)
PS: 95% e non 100% perché i die per TR sono selezionati al 5% dell'intera produzione ryzen e siccome tutte le cpu TR sono esenti (parola di AMD) allora a rigor di logica il totale delle cpu prodotte prima del cambio del test che POSSONO avere il problema è il 95% e non il 100%.;)
CiccoMan
24-10-2017, 13:24
Puoi anche optare di fare finta di nulla e non controllare neanche se ci sia alcun bug - tutti sembrano usare il loro processore Ryzen senza apparentemente problemi nell'uso normale anche così.
Fixed... :asd:
Fixed... :asd:
Mister D
24-10-2017, 13:30
Che bello! Proprio adesso che mi stavo decidento a prendere un 1600, vedo questo bel topic che mi fa cadere la voglia .... :rolleyes:
Oltre quanto ti ha detto s12a ti ricordo, se ce ne fosse bisogno, che se compri una cpu ora hai due possibilità:
1) ti capita una cpu prodotta da settembre in poi (settimana 36 sulla serigrafia del HIS) e qui sei sicuro al 99,99999% di non avere il bug
2) ti capita una cpu prodotta prima di settembre e qui hai una certa probabilità che la cpu pescata possa avere il problema. NON hai il 100% di possibilità avere il bug perché non tutte le cpu lo hanno (vedi altri utenti che qui e sul thread ufficiale hanno mostrato le loro cpu passare il test e sono cpu prese nelle prime settimane). In questo caso testi e se poi ha il bug fai RMA con il venditore (e speri ti mandino una cpu >/= 36) o fai RMA con AMD (e avrai una cpu esente).
Poi altra cosa:
1) devi programmare?
2) userai la cpu su linux?
3) sei una persona che gli da fastidio solo il sapere che la tua cpu può avere il bug anche se poi non lo replicherai mai per il tuo utilizzo?
Bene se per una di queste domande è sì ti conviene aspettare altre settimane ed avere più chance di avere una cpu prodotta dopo la settimana 36 (mia ipotesi di data "sicuramente cpu sane").
Oltre quanto ti ha detto s12a ti ricordo, se ce ne fosse bisogno, che se compri una cpu ora hai due possibilità:
1) ti capita una cpu prodotta da settembre in poi (settimana 36 sulla serigrafia del HIS) e qui sei sicuro al 99,99999% di non avere il bug
2) ti capita una cpu prodotta prima di settembre e qui hai una certa probabilità che la cpu pescata possa avere il problema. NON hai il 100% di possibilità avere il bug perché non tutte le cpu lo hanno (vedi altri utenti che qui e sul thread ufficiale hanno mostrato le loro cpu passare il test e sono cpu prese nelle prime settimane). In questo caso testi e se poi ha il bug fai RMA con il venditore (e speri ti mandino una cpu >/= 36) o fai RMA con AMD (e avrai una cpu esente).
Poi altra cosa:
1) devi programmare?
2) userai la cpu su linux?
3) sei una persona che gli da fastidio solo il sapere che la tua cpu può avere il bug anche se poi non lo replicherai mai per il tuo utilizzo?
Bene se per una di queste domande è sì ti conviene aspettare altre settimane ed avere più chance di avere una cpu prodotta dopo la settimana 36 (mia ipotesi di data "sicuramente cpu sane").
Debern9093
24-10-2017, 14:29
Spese di spedizione a tuo carico o da parte di AMD?
Per quanto ne sappia vogliono solo il processore, senza necessariamente la scatola originale. Suppongo sarebbe stato opportuno usare almeno il blister originale per proteggere i pin.
https://i.imgur.com/fEjnZVC.jpg
Sisi il blister originale cel ho tt ok allora grazie :)
Per quanto ne sappia vogliono solo il processore, senza necessariamente la scatola originale. Suppongo sarebbe stato opportuno usare almeno il blister originale per proteggere i pin.
https://i.imgur.com/fEjnZVC.jpg
Sisi il blister originale cel ho tt ok allora grazie :)
s12a
24-10-2017, 14:34
Sisi il blister originale cel ho tt ok allora grazie :)
E per la spedizione, come ti è stato detto di organizzarti?
E per la spedizione, come ti è stato detto di organizzarti?
Debern9093
24-10-2017, 14:40
E per la spedizione, come ti è stato detto di organizzarti?
Questo è quanto mi è stato detto a quanto ho capito basta assicurare la CPU in un pacco protetto
"Please securely package your CPU in box with the RMA confirmation number xxxxxxxx and return shipping address clearly written on the outside of the box."
Questo è quanto mi è stato detto a quanto ho capito basta assicurare la CPU in un pacco protetto
"Please securely package your CPU in box with the RMA confirmation number xxxxxxxx and return shipping address clearly written on the outside of the box."
s12a
24-10-2017, 14:43
Questo è quanto mi è stato detto a quanto ho capito basta assicurare la CPU in un pacco protetto
"Please securely package your CPU in box with the RMA confirmation number xxxxxxxx and return shipping address clearly written on the outside of the box."
Devi pagare ed organizzare te la spedizione (come in questo caso (http://www.hwupgrade.it/forum/showpost.php?p=45111862&postcount=250)) oppure ci pensa AMD (come in quest'altro (http://www.hwupgrade.it/forum/showpost.php?p=45105655&postcount=86))?
"Please securely package your CPU in box with the RMA confirmation number xxxxxxxx and return shipping address clearly written on the outside of the box."
Devi pagare ed organizzare te la spedizione (come in questo caso (http://www.hwupgrade.it/forum/showpost.php?p=45111862&postcount=250)) oppure ci pensa AMD (come in quest'altro (http://www.hwupgrade.it/forum/showpost.php?p=45105655&postcount=86))?
Debern9093
24-10-2017, 14:53
Devi pagare ed organizzare te la spedizione (come in questo caso (http://www.hwupgrade.it/forum/showpost.php?p=45111862&postcount=250)) oppure ci pensa AMD (come in quest'altro (http://www.hwupgrade.it/forum/showpost.php?p=45105655&postcount=86))?
Mi ha offerto sia l'uno che l'altro privilegio stava me decidere
Mi ha offerto sia l'uno che l'altro privilegio stava me decidere
nagashadow
24-10-2017, 15:29
Arrivata anche a me da Amazon un 1700 settimana 33
Debern9093
24-10-2017, 17:09
Spedizione effettuata, aspettiamo che arrivi e che mi spediscano il nuovo 1600x
papugo1980
24-10-2017, 17:17
Arrivata anche a me da Amazon un 1700 settimana 33
China o Taiwan?
Facci sapere come va;)
China o Taiwan?
Facci sapere come va;)
jam71
24-10-2017, 17:26
infatti come consumatori dovremmo tifare al nostro portafoglio ed ai nostri diritti non certo ad Intel o AMD
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Io purtroppo l'ho comprata su uno eshop non molto veloce con le pratiche rma quindi dovro' mandarlo ad amd direttamente ma aspetto ancora .
qua si segnala un problema ben preciso, Intel avrà altri problemi che saranno segnalati nelle discussioni ad hoc
sul discorso sostituzione OK ma quello che a me non piace e che vi siano ancora CPU affette dal problema in vendita quando a livello produttivo avrebbero dovuto sistemare la questione
l'RMA è l'ultima spiaggia e che danneggia il consumatore perchè non usufruisce del prodotto per diversi giorni
Io purtroppo l'ho comprata su uno eshop non molto veloce con le pratiche rma quindi dovro' mandarlo ad amd direttamente ma aspetto ancora .
beee
24-10-2017, 17:38
E in piu' dobbiamo sborsare altre 20 euro per la spedizione quando molti hanno aspettato che calasse di prezzo per acquistarlo:doh:,dovrebbero cambiarlo senza far pagare la spedizione;)
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
SL45i
24-10-2017, 17:44
Alla fine io ho reso il 1800x ed anche l asus x370 crossair... Secondo me comunque dopo la mia esperienza ora capisco tante cose... posso capire bug risolvibili con firmware, aggiornamenti bios e quant altro... ma non esiste che nel mio caso su due cpu nuove ognuna di esse ha problemi.. con il 1600x si bloccavano i dischi e ricevevo l errore 8... con il 1800x il segfault dopo aver speso quasi 500 euro di cpu... ed anche se questo segfault non l avrei mai notato a me da un fastidio enorme sapere che ci sia... ci sono rimasto davvero malissimo oltre che un mese a sbattermi e sistematicamente a restare senza pc... credo che abbia semplicemente deciso di acquistarlo nel momento meno opportuno...ed infine torno a malincuore ad intel che avrei voluto snobbare per via della pasta del capitano ma sono stanco di giocare con amd alla roulette russa... perdo sempre io... detto questo giudico il ritorno di amd ottimo e da quello che ho potuto vedere se la cava bene in ogni reparto... certo delle cose avrei voluto fossero diverse, ovvero l overclock ed i voltaggi spropositati nonchè il muro dei 4ghz... ma comunque sorvolabili come aspetti, invece spero vivamente in un miglioramento in futuro nel controllo qualità.
doctor who ?
24-10-2017, 17:47
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Ma anche no, non è che se compro una cpu solo per giocare ai pokemon allora tutto il resto diventa un optional.
Qui si compra il pezzo di silicio non il servizio, il pezzo di silicio deve fare tutto a prescindere, poi possiamo parlare fino a domani mattina della effettiva gravità del problema per l'utente medio, ma questo è un altro discorso.
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Ma anche no, non è che se compro una cpu solo per giocare ai pokemon allora tutto il resto diventa un optional.
Qui si compra il pezzo di silicio non il servizio, il pezzo di silicio deve fare tutto a prescindere, poi possiamo parlare fino a domani mattina della effettiva gravità del problema per l'utente medio, ma questo è un altro discorso.
beee
24-10-2017, 17:55
Ma anche no, non è che se compro una cpu solo per giocare ai pokemon allora tutto il resto diventa un optional.
Qui si compra il pezzo di silicio non il servizio, il pezzo di silicio deve fare tutto a prescindere, poi possiamo parlare fino a domani mattina della effettiva gravità del problema per l'utente medio, ma questo è un altro discorso.
Ma ti sembra che un problema scoperto per puro caso dopo mesi dall'uscita di ryzen sia effettivamente da considerare un bug?? Credo che nell'utilizzo normale della cpu mai e poi mai si verrà a creare la condizione per il bug! Se poi qualcuno usa il pc solo per fare bench e/o per stressare il sistema, credo si dovrà adattare....
Qui si compra il pezzo di silicio non il servizio, il pezzo di silicio deve fare tutto a prescindere, poi possiamo parlare fino a domani mattina della effettiva gravità del problema per l'utente medio, ma questo è un altro discorso.
Ma ti sembra che un problema scoperto per puro caso dopo mesi dall'uscita di ryzen sia effettivamente da considerare un bug?? Credo che nell'utilizzo normale della cpu mai e poi mai si verrà a creare la condizione per il bug! Se poi qualcuno usa il pc solo per fare bench e/o per stressare il sistema, credo si dovrà adattare....
s12a
24-10-2017, 17:56
Non è un bench:
https://i.imgur.com/6sH2tyx.png
Farebbe comodo poter fare "make -j16" senza problemi.
https://i.imgur.com/6sH2tyx.png
Farebbe comodo poter fare "make -j16" senza problemi.
beee
24-10-2017, 19:11
Ma stai scherzando o sei serio ? :asd:
Perché nel caso fossi serio, fermati ti prego.
A conferma del fatto che non stavi scherzando, ma anche che non sai di cosa stai parlando.
Ok, spiegami che problemi provoca il bug, naturalmente escludendo script che lo tirano fuori con le pinze!
Perché nel caso fossi serio, fermati ti prego.
A conferma del fatto che non stavi scherzando, ma anche che non sai di cosa stai parlando.
Ok, spiegami che problemi provoca il bug, naturalmente escludendo script che lo tirano fuori con le pinze!
nagashadow
24-10-2017, 19:30
China o Taiwan?
Facci sapere come va;)
Quello di prima settimana 14 Malesia,quello nuovo china....ho notato subito temperature più basse sia idle che in full
Facci sapere come va;)
Quello di prima settimana 14 Malesia,quello nuovo china....ho notato subito temperature più basse sia idle che in full
papugo1980
24-10-2017, 19:44
Quello di prima settimana 14 Malesia,quello nuovo china....ho notato subito temperature più basse sia idle che in full
Ok grazie
L hai testato per vedere se è affetto?
P.s qualcuno tra voi che ha una CPU affetta da segfault può provare un gioco in DX12 (specialmente con vga Nvidia)
Per vedere se ha il mio stesso problema?
Grazie
Ok grazie
L hai testato per vedere se è affetto?
P.s qualcuno tra voi che ha una CPU affetta da segfault può provare un gioco in DX12 (specialmente con vga Nvidia)
Per vedere se ha il mio stesso problema?
Grazie
alexsky8
24-10-2017, 19:48
Io purtroppo l'ho comprata su uno eshop non molto veloce con le pratiche rma quindi dovro' mandarlo ad amd direttamente ma aspetto ancora .
Fai bene ad attendere ancora anzi io aspetterei la prossima primavera inoltrata per avere un quadro più completo del problema o di altri problemi correlati
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Ecco hai proprio cannato
Come ho già scritto PER ESPERIENZA DIRETTA e non per sentito dire non cambia solo in OC ma anche con la cpu stock le temperature calano di un 5 10 gradi e il Vcore di un 10% non parliamo di noccioline ma quasi di 2 generazioni di cpu differenti
E se in un primo momento pareva fosse correlato direttamente ho poi visto che anche cpu ben riuscite potevano avere il problema
La mia cpu settimana 33 va benissimo anche in oc ma presenta il problema di segfault
Fai bene ad attendere ancora anzi io aspetterei la prossima primavera inoltrata per avere un quadro più completo del problema o di altri problemi correlati
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Ecco hai proprio cannato
Come ho già scritto PER ESPERIENZA DIRETTA e non per sentito dire non cambia solo in OC ma anche con la cpu stock le temperature calano di un 5 10 gradi e il Vcore di un 10% non parliamo di noccioline ma quasi di 2 generazioni di cpu differenti
E se in un primo momento pareva fosse correlato direttamente ho poi visto che anche cpu ben riuscite potevano avere il problema
La mia cpu settimana 33 va benissimo anche in oc ma presenta il problema di segfault
nagashadow
24-10-2017, 20:04
Si confermo temperature nettamente inferiori.....Alex la tua dov'è stata prodotto?
papugo1980
24-10-2017, 20:11
Da controllare sarebbe anche la prima lettera dopo la settimana che sarebbe dove é stato prodotto il wafer
Edit: ho sbagliato..la terza indica la provenienza del wafer
Edit: ho sbagliato..la terza indica la provenienza del wafer
alexsky8
24-10-2017, 20:42
Si confermo temperature nettamente inferiori.....Alex la tua dov'è stata prodotto?
made in Malaysia
codice 1733PGS
made in Malaysia
codice 1733PGS
SpongeJohn
24-10-2017, 21:00
:
Ah, ovviamente ci sono stati casi e segnalazioni al di fuori del macroblocco linux+compilazione/programmazioni che invece riguardando il normale utilizzo windows o addirittura alcuni giochi dx12, di questi parlo per sentito dire perché non ho mai riscontrato problemi, semplicemente sono moolto piú randomici e difficili da delineare.
Ed é qui che casca l'asino. Prove delle vostre affermazioni con bench che falliscono con configurazioni a default e build soft/hardware sotto win e dx quelle che volete e per di piú stabili: non ne avete.
Altrimenti fornireste i link.
Capisco chi sviluppa software con linux e quelli a cui piace moddare il proprio software (sempre sotto linux, erché prove concrete di instabilità sotto win, a costo di ripetermi: NON LE AVETE ANCORA FORNITE) , ma al resto del mondo?
fornitemi bench e prove varie. non chiacchiere da bar, e per inciso, ancora una volta: chi vi dice che il carico software (totalmente legato alle righe di codice e marginalmente all'hardware) legato alla compliazione diverrà roba di tutti i giorni. Vi sta dicenco una cazzata bella e buona, legata al loro desiderio di sentirsi "professionisti".
Pfff compilare e win... ma che vi siete fumati?
Detto questo, addio.
edit: allo stesso livello di delirio si arrivò ( se mai verrà dimostrato scientificamente che l'errore é puramente legato all'architettura della cpu) ad averlo coi pentium ed il famoso errore in floating point.
Errore che affliggeva il 2% deigli scenarii di utilizzo per le quali le cpu venivano vendute e che costó ad intel svariati inutili milioni.
Ah, ovviamente ci sono stati casi e segnalazioni al di fuori del macroblocco linux+compilazione/programmazioni che invece riguardando il normale utilizzo windows o addirittura alcuni giochi dx12, di questi parlo per sentito dire perché non ho mai riscontrato problemi, semplicemente sono moolto piú randomici e difficili da delineare.
Ed é qui che casca l'asino. Prove delle vostre affermazioni con bench che falliscono con configurazioni a default e build soft/hardware sotto win e dx quelle che volete e per di piú stabili: non ne avete.
Altrimenti fornireste i link.
Capisco chi sviluppa software con linux e quelli a cui piace moddare il proprio software (sempre sotto linux, erché prove concrete di instabilità sotto win, a costo di ripetermi: NON LE AVETE ANCORA FORNITE) , ma al resto del mondo?
fornitemi bench e prove varie. non chiacchiere da bar, e per inciso, ancora una volta: chi vi dice che il carico software (totalmente legato alle righe di codice e marginalmente all'hardware) legato alla compliazione diverrà roba di tutti i giorni. Vi sta dicenco una cazzata bella e buona, legata al loro desiderio di sentirsi "professionisti".
Pfff compilare e win... ma che vi siete fumati?
Detto questo, addio.
edit: allo stesso livello di delirio si arrivò ( se mai verrà dimostrato scientificamente che l'errore é puramente legato all'architettura della cpu) ad averlo coi pentium ed il famoso errore in floating point.
Errore che affliggeva il 2% deigli scenarii di utilizzo per le quali le cpu venivano vendute e che costó ad intel svariati inutili milioni.
mavvy
24-10-2017, 21:18
Anche io sono affetto dal bug. Ma al momento il sistema è stabile, non ho problemi di sorta, uso prevalenetemente Windows ed i sistemi Linux vanno lisci come l'olio. Per ora... Quindi apsetto l'evolvere della situazione, come si muoverà anche AMD e quello che succederà con il parco software. Ho due anni di garanzia e magari aspettare qualche mese può giovare anche per l'affineamento della loro produzione e test :)
metal master
24-10-2017, 21:51
ragazzi scusate ma vedo che sta cosa del bug da fastidio a qualcuno.
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.
l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....
dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)
p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.
l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....
dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)
p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773
BuRn
25-10-2017, 00:16
Ok, spiegami che problemi provoca il bug, naturalmente escludendo script che lo tirano fuori con le pinze!
Il bug sembra causare l'esecuzione di un'istruzione a un indirizzo errato, per cui o punti a un'istruzione fuori dall'area di memoria riservata all'applicazione (segfault) o punti a un indirizzo che non è l'inizio di un'istruzione (invalid opcode) o punti l'istruzione sbagliata (e possono succedere cose varie, dal niente al crash dell'applicazione).
Non è chiaro se il problema si verifichi solo compilando: la logica non usclude che possa accadere altrove, il test di compilazione viene utilizzato perchè in quel caso il problema si verifica con una certa regolarità. Ma ripeto, questo non esclude che possa accadere altrove.
A riguardo, nel topic si parla anche questo, capire se chi ha verificato di avere problemi di compilazione con il test ha riscontrato problemi anche altrove. Purtroppo non è semplice avere dei risultati coerenti dalle prove degli utenti perchè larga parte delle persone che scrivono qui hanno smanettato (giustamente) con overclock, overclock della ram, voltaggi, timings, ecc. e quindi quando un utente riporta un problema (specie su una piattaforma nuova come Ryzen), sarà il bug o saranno settaggi non completamente stabili? Sì cerca di capire un po' alla volta e di aiutarsi a vicenda. :)
Non prendete la discussione come un attacco personale eh: pare che quando si discute di argomenti come questi salti fuori la solita vecchia storia che chi ha comprato un prodotto lo deve difendere oltre ogni logica, in virtù di non si sa quale orgoglio. :mbe:
Il bug sembra causare l'esecuzione di un'istruzione a un indirizzo errato, per cui o punti a un'istruzione fuori dall'area di memoria riservata all'applicazione (segfault) o punti a un indirizzo che non è l'inizio di un'istruzione (invalid opcode) o punti l'istruzione sbagliata (e possono succedere cose varie, dal niente al crash dell'applicazione).
Non è chiaro se il problema si verifichi solo compilando: la logica non usclude che possa accadere altrove, il test di compilazione viene utilizzato perchè in quel caso il problema si verifica con una certa regolarità. Ma ripeto, questo non esclude che possa accadere altrove.
A riguardo, nel topic si parla anche questo, capire se chi ha verificato di avere problemi di compilazione con il test ha riscontrato problemi anche altrove. Purtroppo non è semplice avere dei risultati coerenti dalle prove degli utenti perchè larga parte delle persone che scrivono qui hanno smanettato (giustamente) con overclock, overclock della ram, voltaggi, timings, ecc. e quindi quando un utente riporta un problema (specie su una piattaforma nuova come Ryzen), sarà il bug o saranno settaggi non completamente stabili? Sì cerca di capire un po' alla volta e di aiutarsi a vicenda. :)
Non prendete la discussione come un attacco personale eh: pare che quando si discute di argomenti come questi salti fuori la solita vecchia storia che chi ha comprato un prodotto lo deve difendere oltre ogni logica, in virtù di non si sa quale orgoglio. :mbe:
ccmarco2004
25-10-2017, 01:32
Non sono d'accordo! Appurato che il bug è irrilevante, la RMA si fa solamente per avere una cpu migliore, con silicio migliore.... e se paghi ti arrangi!
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Non hai la minima idea di cosa stai parlando.
Nei panni dell'OP mi cadrebbero le braccia, nonostante lo sbattimento organizzativo del 3ad, continuano ad arrivare perle come questa ad alimentare la campagna di minimizzazione.
Tutti azionisti AMD ?
La cpu 'nuova', andrà esattamente come la 'vecchia', le uniche differenze si vedranno in overclock. Se AMD decidesse di cambiare solo le cpu i cui proprietari
dovranno dimostrare di lanciare normalmente per lavoro o per hobby 4 istanze di un compilatore C, compilando programmi abnormi..... beh, non ci sarebbe da meravigliarsi, io lo troverei normale!
Ripeto per chi non ci sente: il bug è irrilevante!
Non hai la minima idea di cosa stai parlando.
Nei panni dell'OP mi cadrebbero le braccia, nonostante lo sbattimento organizzativo del 3ad, continuano ad arrivare perle come questa ad alimentare la campagna di minimizzazione.
Tutti azionisti AMD ?
Operapia
25-10-2017, 05:01
ragazzi scusate ma vedo che sta cosa del bug da fastidio a qualcuno.
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.
l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....
dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)
p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773
Hai capito perchè prima che aprissero questa discussione i risultati tel mio test te li ho mandati in privato? Era proprio per evitare discussioni assurde come queste.
Vedo però che neanche aprendo una discussione idonea si evitano sterili polemiche. Francamente non capisco cosa ci sia di male a farsi sostituire una cpu che AMD stessa dichiara portatrice di un problema. mah
si sta dicendo tranquillamente che amd è a conoscenza del problema e che cambia le cpu col problema, che il problema si verifica solo sotto particolari condizioni e che quasi sicuramente chi utilizza il pc in modo normale il problema forse non lo verificherà ne adesso ne mai, però è anche vero che chi vuole può farsi cambiare la cpu perchè è la stessa amd che dopo verifiche consiglia l'rma.
l'autore del thread ha spiegato il tutto in maniera perfetta in prima pagina, e ancora c'è chi non si rassegna.....
dei problemi di intel sinceramente in questo topic a noi non interessa, interessa solo che amd risolva i suoi (e li sta risolvendo)
p.s: di questo problema se ne parla proprio nel forum ufficiale di amd, ed il thread è stato flaggato pure come utile: https://community.amd.com/thread/215773
Hai capito perchè prima che aprissero questa discussione i risultati tel mio test te li ho mandati in privato? Era proprio per evitare discussioni assurde come queste.
Vedo però che neanche aprendo una discussione idonea si evitano sterili polemiche. Francamente non capisco cosa ci sia di male a farsi sostituire una cpu che AMD stessa dichiara portatrice di un problema. mah
Mikkinen
25-10-2017, 05:05
Qualcuno di voi che ora ha la cpu perfetta che tipo di ram monta?
Ci sono stati miglioramenti? In particolare riguardanti hynix...
Potrebbe essere legata la cosa?
Ci sono stati miglioramenti? In particolare riguardanti hynix...
Potrebbe essere legata la cosa?
s12a
25-10-2017, 07:09
Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.
Servono Python 3.6+ (https://www.python.org/) ed ImageMagick (https://www.imagemagick.org/script/download.php) (un programma in riga di comando per la conversione ed elaborazione immagini in vari formati) in versione 64bit portable (link diretto qui (https://www.imagemagick.org/download/binaries/ImageMagick-7.0.7-8-portable-Q16-x64.zip)).
Di ImageMagick serve solo magick.exe. Dalla directory di installazione di Python servono i file sotto elencati oltre a magick.exe
https://i.imgur.com/S5CbYwd.png
Se vi fidate (ma suggerisco di non fidarvi) qui c'è un pacchetto completo e pronto in formato zip:
https://mega.nz/#!OpQGGYgS!_1pOyoeGFkSF1NOaj7JcpCUSCWR7WfAzYyyn7_KReC4
Il codice Python è il seguente:
# -*- coding: utf-8 -*-
"""
Created on Wed Oct 25 02:52:15 2017
@author: s12a
"""
import multiprocessing as mp
import subprocess
import time
import sys
magick = "magick.exe"
time_0 = time.time()
def worker(n, size):
subprocess.run(f"{magick} xc: +noise Random -resize {size} png:>NUL", shell=True)
if n % 50 == 0:
print(f"{n}:{int(time.time() - time_0)}", flush=True, end='')
else:
print(".", flush=True, end='')
if __name__ == "__main__":
if len(sys.argv) >= 3:
workers, jobs, size = sys.argv[1:]
# Sanitizing values
try:
workers = int(workers)
jobs = int(jobs)
size = int(size)
except ValueError:
print("Error parsing command line arguments.")
sys.exit(-1)
else:
workers=mp.cpu_count()
jobs=5000
size=3000
print("\n"
"=========================================\n"
"To stop the script press Ctrl+Break/Pause\n"
"=========================================\n")
print(f"Workers: {workers}, Images: {jobs}, Image size: {size}px\n")
pool = mp.Pool(processes=workers)
[pool.apply_async(worker, args=(n, size)) for n in range(jobs)]
pool.close()
pool.join()
Nella pratica viene creata un'immagine con rumore casuale, ingrandita a n pixel di larghezza, e questo si ripete per x volte su un numero di worker di default equivalente al numero di core logici della CPU. Il test dovrebbe emulare la conversione parallela di un grande numero di file.
Per eseguirlo, una volta che i file sono tutti nella stessa directory, da riga di comando va fatto:
python.exe worker.py
In assenza di argomenti da linea di comando vengono usati tutti i core della CPU, 5000 immagini in totale ridimensionate ad una larghezza di 3000 pixel. Se vengono aggiunti argomenti alla linea di comando, occorre specificarli tutti; ad esempio:
python.exe worker.py 20 10000 1500
Questo vuol dire 20 worker, 10000 immagini in totale, ridimensionate a 1500 pixel di dimensione.
Le immagini non vengono salvate da nessuna parte; finiscono nell'equivalente Windows di /dev/null.
Non devono accadere errori durante l'operazione, che è piuttosto intensiva. (occhio anche alla temperatura della CPU)
https://i.imgur.com/b2Hd333.png
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.
Servono Python 3.6+ (https://www.python.org/) ed ImageMagick (https://www.imagemagick.org/script/download.php) (un programma in riga di comando per la conversione ed elaborazione immagini in vari formati) in versione 64bit portable (link diretto qui (https://www.imagemagick.org/download/binaries/ImageMagick-7.0.7-8-portable-Q16-x64.zip)).
Di ImageMagick serve solo magick.exe. Dalla directory di installazione di Python servono i file sotto elencati oltre a magick.exe
https://i.imgur.com/S5CbYwd.png
Se vi fidate (ma suggerisco di non fidarvi) qui c'è un pacchetto completo e pronto in formato zip:
https://mega.nz/#!OpQGGYgS!_1pOyoeGFkSF1NOaj7JcpCUSCWR7WfAzYyyn7_KReC4
Il codice Python è il seguente:
# -*- coding: utf-8 -*-
"""
Created on Wed Oct 25 02:52:15 2017
@author: s12a
"""
import multiprocessing as mp
import subprocess
import time
import sys
magick = "magick.exe"
time_0 = time.time()
def worker(n, size):
subprocess.run(f"{magick} xc: +noise Random -resize {size} png:>NUL", shell=True)
if n % 50 == 0:
print(f"{n}:{int(time.time() - time_0)}", flush=True, end='')
else:
print(".", flush=True, end='')
if __name__ == "__main__":
if len(sys.argv) >= 3:
workers, jobs, size = sys.argv[1:]
# Sanitizing values
try:
workers = int(workers)
jobs = int(jobs)
size = int(size)
except ValueError:
print("Error parsing command line arguments.")
sys.exit(-1)
else:
workers=mp.cpu_count()
jobs=5000
size=3000
print("\n"
"=========================================\n"
"To stop the script press Ctrl+Break/Pause\n"
"=========================================\n")
print(f"Workers: {workers}, Images: {jobs}, Image size: {size}px\n")
pool = mp.Pool(processes=workers)
[pool.apply_async(worker, args=(n, size)) for n in range(jobs)]
pool.close()
pool.join()
Nella pratica viene creata un'immagine con rumore casuale, ingrandita a n pixel di larghezza, e questo si ripete per x volte su un numero di worker di default equivalente al numero di core logici della CPU. Il test dovrebbe emulare la conversione parallela di un grande numero di file.
Per eseguirlo, una volta che i file sono tutti nella stessa directory, da riga di comando va fatto:
python.exe worker.py
In assenza di argomenti da linea di comando vengono usati tutti i core della CPU, 5000 immagini in totale ridimensionate ad una larghezza di 3000 pixel. Se vengono aggiunti argomenti alla linea di comando, occorre specificarli tutti; ad esempio:
python.exe worker.py 20 10000 1500
Questo vuol dire 20 worker, 10000 immagini in totale, ridimensionate a 1500 pixel di dimensione.
Le immagini non vengono salvate da nessuna parte; finiscono nell'equivalente Windows di /dev/null.
Non devono accadere errori durante l'operazione, che è piuttosto intensiva. (occhio anche alla temperatura della CPU)
https://i.imgur.com/b2Hd333.png
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.
BuRn
25-10-2017, 08:20
Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.
--
Mi hai battuto sul tempo! :D
Avevo pensato di mettere su lo stesso identico test, solo con Node.JS al posto che con Python.
Ora non resta che vedere che risultati da. ;)
--
Mi hai battuto sul tempo! :D
Avevo pensato di mettere su lo stesso identico test, solo con Node.JS al posto che con Python.
Ora non resta che vedere che risultati da. ;)
bagnino89
25-10-2017, 08:32
Stasera provo il test, grazie.
fedexx2
25-10-2017, 08:40
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 :D
Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene :D
papugo1980
25-10-2017, 08:46
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 :D
Ciao per caso avevi riscontrato problemi in DX12?
Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene :D
Ciao per caso avevi riscontrato problemi in DX12?
fedexx2
25-10-2017, 08:51
Ciao per caso avevi riscontrato problemi in DX12?
Ciao, Non ho provato nessun gioco DX12...
Però qualche encoding video pesante con diversi filtri avisynth sopra mi ha dato dei crash random
Ciao, Non ho provato nessun gioco DX12...
Però qualche encoding video pesante con diversi filtri avisynth sopra mi ha dato dei crash random
Gioz
25-10-2017, 08:54
Ho provato ad ideare un semplice test per verificare se chi ha il segfault può avere problematiche in condizioni di carico simili (ma in ambiti differenti) su Windows.
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.
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.
a sinistra esecuzione "liscia" a destra "32 10000 1500", lanciati consecutivamente e non simultaneamente:
https://imgur.com/tyPwwBa
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.
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.
a sinistra esecuzione "liscia" a destra "32 10000 1500", lanciati consecutivamente e non simultaneamente:
https://imgur.com/tyPwwBa
bagnino89
25-10-2017, 08:56
Ciao per caso avevi riscontrato problemi in DX12?
Che problemi hai in DX12? Con che giochi?
Che problemi hai in DX12? Con che giochi?
papugo1980
25-10-2017, 09:02
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
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
25-10-2017, 09:10
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?
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
25-10-2017, 09:16
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
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
25-10-2017, 09:31
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.
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
25-10-2017, 09:49
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 (https://github.com/corngood/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.
https://i.imgur.com/EBT7GhF.png
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 (https://github.com/corngood/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.
https://i.imgur.com/EBT7GhF.png
Gioz
25-10-2017, 10:00
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.
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$
25-10-2017, 10:01
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 (https://www.mediafire.com/file/sqds8buyzthy11s/Ryzen%20test.zip)
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 (https://www.mediafire.com/file/sqds8buyzthy11s/Ryzen%20test.zip)
alexsky8
25-10-2017, 10:12
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):
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
25-10-2017, 10:22
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.
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
25-10-2017, 10:25
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?
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
25-10-2017, 10:27
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 (https://github.com/corngood/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.
https://i.imgur.com/EBT7GhF.png
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;)
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 (https://github.com/corngood/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.
https://i.imgur.com/EBT7GhF.png
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
25-10-2017, 11:07
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.
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.
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 (https://github.com/corngood/kill-ryzen-win/issues/1) oltre che su Reddit (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/).
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.
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.
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.
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 (https://github.com/corngood/kill-ryzen-win/issues/1) oltre che su Reddit (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/).
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
25-10-2017, 11:29
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.
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
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
25-10-2017, 13:20
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-ryzen-win/archive/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-you-downloading-visual-studio/?sku=BuildTools&rel=15
Fonte: https://www.visualstudio.com/downloads/?q=build+tools#build-tools-for-visual-studio-2017
Eseguire "vs_buildtools.exe"
https://i.imgur.com/SYPadyX.png
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)
https://i.imgur.com/PkWJAO9.png
Installazione...
https://i.imgur.com/wQnfMjY.png
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
https://i.imgur.com/XhrB8RB.png
run.cmd
(Ctrl+C per terminare)
https://i.imgur.com/XsLHuME.png
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 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dmzyxny/?st=j970z4al&sh=8132e160) (2 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dnepmwg/?st=j970zxwn&sh=31569530), 3 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dn2azrh/?st=j9710gyr&sh=bb6d4667), 4 (I reproduced it on a clean windows install and updated the README with info on how to install VS community edition with the right components. On my system it crashes 100% within a minute. On our other Ryzen system it crashed once after a few minutes and then ran fine for three hours. Both machines crashed in the gcc test (ubuntu live-usb) within a couple of minutes. Thanks for testing it.). Fonte (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j9712u68&sh=64e1eac6)), 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>
https://i.imgur.com/EBT7GhFl.png (https://i.imgur.com/EBT7GhF.png)
https://i.imgur.com/EVuR2EL.png
5) Note aggiuntive
Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.
https://i.imgur.com/KoHmSEKl.png (https://i.imgur.com/KoHmSEK.png)
Provvedere a disabilitarlo temporaneamente:
Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)
https://i.imgur.com/OUoYHlw.png
Cliccare "Virus & Threat Protection Settings"
https://i.imgur.com/xds9U3H.png
Real-Time Protection -> Off
https://i.imgur.com/UArCsQu.png
Ricordarsi di riattivarlo ad operazione ultimata.
1) Scaricare kill-ryzen-win
Download: https://github.com/corngood/kill-ryzen-win/archive/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-you-downloading-visual-studio/?sku=BuildTools&rel=15
Fonte: https://www.visualstudio.com/downloads/?q=build+tools#build-tools-for-visual-studio-2017
Eseguire "vs_buildtools.exe"
https://i.imgur.com/SYPadyX.png
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)
https://i.imgur.com/PkWJAO9.png
Installazione...
https://i.imgur.com/wQnfMjY.png
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
https://i.imgur.com/XhrB8RB.png
run.cmd
(Ctrl+C per terminare)
https://i.imgur.com/XsLHuME.png
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 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dmzyxny/?st=j970z4al&sh=8132e160) (2 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dnepmwg/?st=j970zxwn&sh=31569530), 3 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dn2azrh/?st=j9710gyr&sh=bb6d4667), 4 (I reproduced it on a clean windows install and updated the README with info on how to install VS community edition with the right components. On my system it crashes 100% within a minute. On our other Ryzen system it crashed once after a few minutes and then ran fine for three hours. Both machines crashed in the gcc test (ubuntu live-usb) within a couple of minutes. Thanks for testing it.). Fonte (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j9712u68&sh=64e1eac6)), 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>
https://i.imgur.com/EBT7GhFl.png (https://i.imgur.com/EBT7GhF.png)
https://i.imgur.com/EVuR2EL.png
5) Note aggiuntive
Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.
https://i.imgur.com/KoHmSEKl.png (https://i.imgur.com/KoHmSEK.png)
Provvedere a disabilitarlo temporaneamente:
Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)
https://i.imgur.com/OUoYHlw.png
Cliccare "Virus & Threat Protection Settings"
https://i.imgur.com/xds9U3H.png
Real-Time Protection -> Off
https://i.imgur.com/UArCsQu.png
Ricordarsi di riattivarlo ad operazione ultimata.
Giorgio G
25-10-2017, 13:54
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 :D
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.
Per tappare il buco e non rimanere fermo col pc ho preso un R3 1200 datato "1725PGT" che più tardi testerò per bene :D
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
25-10-2017, 14:45
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.
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
25-10-2017, 16:31
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-ryzen-win/archive/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-you-downloading-visual-studio/?sku=BuildTools&rel=15
Fonte: https://www.visualstudio.com/downloads/?q=build+tools#build-tools-for-visual-studio-2017
Eseguire "vs_buildtools.exe"
https://i.imgur.com/SYPadyX.png
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)
https://i.imgur.com/PkWJAO9.png
Installazione...
https://i.imgur.com/wQnfMjY.png
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
https://i.imgur.com/XhrB8RB.png
run.cmd
(Ctrl+C per terminare)
https://i.imgur.com/XsLHuME.png
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 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dmzyxny/?st=j970z4al&sh=8132e160) (2 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dnepmwg/?st=j970zxwn&sh=31569530), 3 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dn2azrh/?st=j9710gyr&sh=bb6d4667), 4 (I reproduced it on a clean windows install and updated the README with info on how to install VS community edition with the right components. On my system it crashes 100% within a minute. On our other Ryzen system it crashed once after a few minutes and then ran fine for three hours. Both machines crashed in the gcc test (ubuntu live-usb) within a couple of minutes. Thanks for testing it.). Fonte (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j9712u68&sh=64e1eac6)), 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>
https://i.imgur.com/EBT7GhFl.png (https://i.imgur.com/EBT7GhF.png)
https://i.imgur.com/EVuR2EL.png
5) Note aggiuntive
Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.
https://i.imgur.com/KoHmSEKl.png (https://i.imgur.com/KoHmSEK.png)
Provvedere a disabilitarlo temporaneamente:
Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)
https://i.imgur.com/OUoYHlw.png
Cliccare "Virus & Threat Protection Settings"
https://i.imgur.com/xds9U3H.png
Real-Time Protection -> Off
https://i.imgur.com/UArCsQu.png
Ricordarsi di riattivarlo ad operazione ultimata.
A me con questa procedura non dava nulla.
Sotto linux invece sbam, errore
1) Scaricare kill-ryzen-win
Download: https://github.com/corngood/kill-ryzen-win/archive/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-you-downloading-visual-studio/?sku=BuildTools&rel=15
Fonte: https://www.visualstudio.com/downloads/?q=build+tools#build-tools-for-visual-studio-2017
Eseguire "vs_buildtools.exe"
https://i.imgur.com/SYPadyX.png
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)
https://i.imgur.com/PkWJAO9.png
Installazione...
https://i.imgur.com/wQnfMjY.png
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
https://i.imgur.com/XhrB8RB.png
run.cmd
(Ctrl+C per terminare)
https://i.imgur.com/XsLHuME.png
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 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dmzyxny/?st=j970z4al&sh=8132e160) (2 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dnepmwg/?st=j970zxwn&sh=31569530), 3 (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/dn2azrh/?st=j9710gyr&sh=bb6d4667), 4 (I reproduced it on a clean windows install and updated the README with info on how to install VS community edition with the right components. On my system it crashes 100% within a minute. On our other Ryzen system it crashed once after a few minutes and then ran fine for three hours. Both machines crashed in the gcc test (ubuntu live-usb) within a couple of minutes. Thanks for testing it.). Fonte (https://www.reddit.com/r/AMDHelp/comments/6zuos7/can_anyone_help_test_ryzen_instability_on_windows/?st=j9712u68&sh=64e1eac6)), 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>
https://i.imgur.com/EBT7GhFl.png (https://i.imgur.com/EBT7GhF.png)
https://i.imgur.com/EVuR2EL.png
5) Note aggiuntive
Ho personalmente notato che Windows Defender interferisce pesantemente con l'operazione.
https://i.imgur.com/KoHmSEKl.png (https://i.imgur.com/KoHmSEK.png)
Provvedere a disabilitarlo temporaneamente:
Start > Digitare/Selezionare "Windows Defender Security Center"
Cliccare "Virus & Threat Protection" (o equivalente in italiano)
https://i.imgur.com/OUoYHlw.png
Cliccare "Virus & Threat Protection Settings"
https://i.imgur.com/xds9U3H.png
Real-Time Protection -> Off
https://i.imgur.com/UArCsQu.png
Ricordarsi di riattivarlo ad operazione ultimata.
A me con questa procedura non dava nulla.
Sotto linux invece sbam, errore
s12a
25-10-2017, 16:35
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?
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
25-10-2017, 17:06
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 :mad:
ho paura che con la mia fortuna ti becco ancora uno con problemi, fai sapere comunque come va il test :)
L'ho preso da amazon 3 giorni fa.
Grazie intanto, mi sa che aspetto a prenderlo, tre giorni fa e ancora 25° settimana :mad:
ho paura che con la mia fortuna ti becco ancora uno con problemi, fai sapere comunque come va il test :)
s12a
25-10-2017, 17:08
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.
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.
bagnino89
25-10-2017, 20:09
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?
Se può interessare, ho provato kill-ryzen-win per un'ora, impostati 24 workers (la mia CPU ha 12 thread), disattivata la protezione attiva di Defender, verificato da Task Manager che i processi che sfruttavano attivamente la CPU fossero solo la console di comando di VB e System.
Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia :asd:
PS. Una cosa che mi ha molto impressionato è la temperatura della CPU: non ha mai superato 56 °C.
Se può interessare, ho provato kill-ryzen-win per un'ora, impostati 24 workers (la mia CPU ha 12 thread), disattivata la protezione attiva di Defender, verificato da Task Manager che i processi che sfruttavano attivamente la CPU fossero solo la console di comando di VB e System.
Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia :asd:
PS. Una cosa che mi ha molto impressionato è la temperatura della CPU: non ha mai superato 56 °C.
nicolarush
25-10-2017, 20:24
mi unisco alla compagnia :D
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma
la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone
il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8 :muro:
ovviamente anche lui con i suoi bei segfaults :mc:
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma
la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone
il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8 :muro:
ovviamente anche lui con i suoi bei segfaults :mc:
s12a
26-10-2017, 10:55
Se può interessare, ho provato kill-ryzen-win per un'ora, impostati 24 workers (la mia CPU ha 12 thread), disattivata la protezione attiva di Defender, verificato da Task Manager che i processi che sfruttavano attivamente la CPU fossero solo la console di comando di VB e System.
Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia :asd:
Nel thread correlato nel community forum AMD (https://community.amd.com/message/2829887#comment-2829887#2829887) è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.
mi unisco alla compagnia :D
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma
la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone
il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8 :muro:
ovviamente anche lui con i suoi bei segfaults :mc:
Per curiosità, qual è stato in entrambi i casi il codice di produzione completo? Terminava per PGT, SUS od altro?
Non sembrano esserci bug. CPU a default, acquistata in aprile. Dovrei provare con Linux ma non ho molta voglia :asd:
Nel thread correlato nel community forum AMD (https://community.amd.com/message/2829887#comment-2829887#2829887) è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.
mi unisco alla compagnia :D
1700X della settimana 8 che presenta il problema "segfaults": ho appena richiesto rma
la cosa triste è che sapendo di dover fare rma e non rimanere senza questo pc ho preso un 1700 sull'amazzone
il 1700 mi è arrivato oggi, nuovo sigillato e.... settimana 8 :muro:
ovviamente anche lui con i suoi bei segfaults :mc:
Per curiosità, qual è stato in entrambi i casi il codice di produzione completo? Terminava per PGT, SUS od altro?
Mister D
26-10-2017, 11:04
Nel thread correlato nel community forum AMD (https://community.amd.com/message/2829887#comment-2829887#2829887) è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.
Questo potrebbe voler dire che in alcuni stabilimenti hanno applicato prima il nuovo test di qualità e quindi selezionano meglio le cpu (magari sono stabilimenti dove sono state fatti i test pilota per il cambio di validazione produttiva?).
Questo potrebbe voler dire che in alcuni stabilimenti hanno applicato prima il nuovo test di qualità e quindi selezionano meglio le cpu (magari sono stabilimenti dove sono state fatti i test pilota per il cambio di validazione produttiva?).
bagnino89
26-10-2017, 11:26
Nel thread correlato nel community forum AMD (https://community.amd.com/message/2829887#comment-2829887#2829887) è stato fatto notare che le CPU tornate indietro da RMA hanno il codice di produzione che termina con SUS, per cui potrebbe non essere (solo?) una questione di settimana, ma anche di stabilimento di produzione. Nella stessa pagina c'è una persona che riporta di avere acquistato un processore con codice **1733PGT, produce segfault. Il processore ritornato da RMA è UA1733SUS, non produce segfault.
Dovrei togliere il dissipatore per controllare queste informazioni... Avrei dovuto fare una foto.
Ricordo sicuramente che era stato prodotto in Malaysia.
Dovrei togliere il dissipatore per controllare queste informazioni... Avrei dovuto fare una foto.
Ricordo sicuramente che era stato prodotto in Malaysia.
s12a
26-10-2017, 11:40
Probabilmente il codice termina per PGT.
https://www.reddit.com/r/Amd/comments/6scnlg/ryzen_reading_your_production_batch_number/?st=j98c3kk9&sh=b6dd60e4
SKU: YD1700BBM88AE
BATCH: UA 1706PGT
SERIAL: 9R6xxxxxxxxxx
The Batch number consists of the UA and then a two part number of 2 digits each as well as the assembly location.
The first being the year the CPU was produced [17]=(2017) and the week [06] = (Week 6).
UA [2digits-YEAR][2digits-WEEK] [3letters-Assembly and Diffusion]
UA 1706 PGT
UA [YY][WW] [1][2][3]
YY -> Year
WW -> Week
1 -> ATMP Location ([P]enang, Malaysia or [S]uzhou, China) (Exact factory addresses known )
2 -> Last letters of ATMP location.
3 -> Wafer Production ([S]aratoga or [T]exas) (addresses known)
https://www.reddit.com/r/Amd/comments/6scnlg/ryzen_reading_your_production_batch_number/?st=j98c3kk9&sh=b6dd60e4
SKU: YD1700BBM88AE
BATCH: UA 1706PGT
SERIAL: 9R6xxxxxxxxxx
The Batch number consists of the UA and then a two part number of 2 digits each as well as the assembly location.
The first being the year the CPU was produced [17]=(2017) and the week [06] = (Week 6).
UA [2digits-YEAR][2digits-WEEK] [3letters-Assembly and Diffusion]
UA 1706 PGT
UA [YY][WW] [1][2][3]
YY -> Year
WW -> Week
1 -> ATMP Location ([P]enang, Malaysia or [S]uzhou, China) (Exact factory addresses known )
2 -> Last letters of ATMP location.
3 -> Wafer Production ([S]aratoga or [T]exas) (addresses known)
bagnino89
26-10-2017, 11:45
Dovrei provare con Linux per essere sicuro al 100%.
alexsky8
26-10-2017, 11:46
Dovrei togliere il dissipatore per controllare queste informazioni... Avrei dovuto fare una foto.
Ricordo sicuramente che era stato prodotto in Malaysia.
la mia settimana 33 è made in Malaysia
codice 1733PGS
Ricordo sicuramente che era stato prodotto in Malaysia.
la mia settimana 33 è made in Malaysia
codice 1733PGS
papugo1980
26-10-2017, 11:52
Il mio con segfault 1714sus
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
s12a
26-10-2017, 11:56
Il mio con segfault 1714sus
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
Allora niente: probabilmente le ultime tre lettere da sole non bastano per determinare in anticipo quali esemplari potrebbero manifestare segfault. Magari però per quelli prodotti dopo la settimana 25? Occorrerebbe vedere quelli di chi ha riscontrato segfault con processori recentemente prodotti ed acquistati nei canali retail.
EDIT: ho controllato nuovamente i link che ho postato in precedenza nel thread, e questo qui credo confermi che forse è solo una coincidenza; potrebbe dunque accadere con qualunque processore:
https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/?st=j8ucho13&sh=158f74a5
(Si potrebbe opinare che forse il processore è overcloccato, ma ancora non c'è stata conferma che solo overcloccando possano apparire segfault. Servono più test - ad esempio variando vSoC e frequenza memorie assieme - ma questo qui riportato qualche commento fa (http://www.hwupgrade.it/forum/showpost.php?p=45124570&postcount=495) da Nautilu$ indica che potrebbe non accadere con i processori apparentemente esenti dal problema)
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
Allora niente: probabilmente le ultime tre lettere da sole non bastano per determinare in anticipo quali esemplari potrebbero manifestare segfault. Magari però per quelli prodotti dopo la settimana 25? Occorrerebbe vedere quelli di chi ha riscontrato segfault con processori recentemente prodotti ed acquistati nei canali retail.
EDIT: ho controllato nuovamente i link che ho postato in precedenza nel thread, e questo qui credo confermi che forse è solo una coincidenza; potrebbe dunque accadere con qualunque processore:
https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/?st=j8ucho13&sh=158f74a5
(Si potrebbe opinare che forse il processore è overcloccato, ma ancora non c'è stata conferma che solo overcloccando possano apparire segfault. Servono più test - ad esempio variando vSoC e frequenza memorie assieme - ma questo qui riportato qualche commento fa (http://www.hwupgrade.it/forum/showpost.php?p=45124570&postcount=495) da Nautilu$ indica che potrebbe non accadere con i processori apparentemente esenti dal problema)
papugo1980
26-10-2017, 12:29
Test partito da più di 20 minuti e sembra essere tutto regolare...
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo
s12a
26-10-2017, 12:37
Test partito da più di 20 minuti e sembra essere tutto regolare...
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo
Diminuendo vSoC od esagerando un po' con la frequenza della memoria, ma senza toccare vCore o moltiplicatore CPU, escono fuori segfault nel solito test oppure appare solo una schermata nera come nel caso di Nautilu$?
Anche in overclock ho provato prima un Po e sembra essere migliore.
L.altro murava a 3900 mhz con 1.350 di vcore( per i 4 GHz non c era verso neanche con 1.425)
Questo con 1.350 regge i 4 GHz forse ha l IMC un Po più scarso perché mi crea stabilità alla ram 3200
Dopo lo setto bene e vediamo
Diminuendo vSoC od esagerando un po' con la frequenza della memoria, ma senza toccare vCore o moltiplicatore CPU, escono fuori segfault nel solito test oppure appare solo una schermata nera come nel caso di Nautilu$?
alexsky8
26-10-2017, 12:44
https://www.reddit.com/r/Amd/comments/76q7ne/got_a_defective_ryzen_7_1700_on_rma_process/dofye3u/?st=j8ucho13&sh=158f74a5
no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ? :eek:
no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ? :eek:
metal master
26-10-2017, 12:50
arrivato poco fa con dhl un nuovo ryzen 7 1700 scatolato e sigillato.
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.
nicolarush
26-10-2017, 12:52
Per curiosità, qual è stato in entrambi i casi il codice di produzione completo? Terminava per PGT, SUS od altro?
il 1700X è PGT
il 1700 e SUT
con la differenza che il 1700X è stato preso al day1 mentre il 1700 ieri... trovare ancora settimana 8 mi ha veramente sorpreso :mc:
il 1700X è PGT
il 1700 e SUT
con la differenza che il 1700X è stato preso al day1 mentre il 1700 ieri... trovare ancora settimana 8 mi ha veramente sorpreso :mc:
s12a
26-10-2017, 12:54
no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ? :eek:
Sì, così riporta. Qualcun altro ha riscontrato lo stesso nel forum AMD in seguito all'RMA, ma in un caso il motivo può essere stato causato da eccessivo clock della memoria; con 4 moduli la frequenza massima supportata ufficialmente con AMD Ryzen è inferiore che con 2 (2133 MHz single rank / 1866 MHz dual rank).
https://community.amd.com/message/2823637#comment-2823637#2823637
#1484 ed alcuni dei commenti successivi
Sì, così riporta. Qualcun altro ha riscontrato lo stesso nel forum AMD in seguito all'RMA, ma in un caso il motivo può essere stato causato da eccessivo clock della memoria; con 4 moduli la frequenza massima supportata ufficialmente con AMD Ryzen è inferiore che con 2 (2133 MHz single rank / 1866 MHz dual rank).
https://community.amd.com/message/2823637#comment-2823637#2823637
#1484 ed alcuni dei commenti successivi
papugo1980
26-10-2017, 12:55
no ma ho letto veloce io oppure addirittura anche quella CPU (proveniente da RMA) ne è affetta ? :eek:
Credo intenda Rma dallo store e non da Amd
@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750
Credo intenda Rma dallo store e non da Amd
@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750
alexsky8
26-10-2017, 12:59
arrivato poco fa con dhl un nuovo ryzen 7 1700 scatolato e sigillato.
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.
quindi quanti giorni hai impiegato complessivamente ?
il processore è made in china è il batch è UA 1739SUS
comunque l'assistenza amd è da 10 e lode: mi hanno seguito passo passo e sono stati di una gentilezza unica.
quindi quanti giorni hai impiegato complessivamente ?
s12a
26-10-2017, 13:03
Credo intenda Rma dallo store e non da Amd
L'utente che ho linkato dal forum AMD aveva aperto una procedura di RMA con AMD. Riporta segfault, ma solo aumentando la frequenza della memoria usando il profilo XMP. Per questo ero curioso di sapere se effettuando overclock in tal senso (o diminuendo il vSoC, che pare sia correlato alla stabilità di memoria ed affini) potessero iniziare ad apparire segfault con le solite modalità, anche con processori che a default non mostrano nulla:
https://community.amd.com/message/2822644#comment-2822644#2822644 (#1347)
After 3 weeks and half my replacement 1700X arrived today. I can't blame the delay on AMD. The problem was Brazilian customs.
It is also a 1725SUS (diffused in USA and made in China). It was certainly pre-tested as there are some small dents in the corners (it looks like they attached the cooler too tight). I hope they did not damage the CPU in any sense. I have just put the CPU back on my computer and started the kill-ryzen.sh test. I will report back in 48 hours.
https://community.amd.com/message/2823637#comment-2823637#2823637 (#1484)
Bad news from my front. I have an RMAed CPU of week 25. It sustained 3 days of kill-ryzen.sh using BIOS defaults. After that I updated my BIOS and changed my memory profile to use XMP 2 (2400 instead of 2100 from Bios default).* Unfortunately, under this conditions I got a new failure in one of the loops:
*
-----------------
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c: In function 'int standard_sse_constant_p(rtx, machine_mode)':
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c:11699:8: internal compiler error: Segmentation fault
** mode = GET_MODE (x);
0x11ac5ec crash_signal
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/toplev.c:337
0x104058c create_output_operand
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/optabs.h:94
-----------------
*
I will now revert back memory to BIOS default. I think I read somewhere that Ryzen only officially supports 2100Hz when dealing with 64Gb.
*
I have to admit that I am really tired of this. It will be hard to really trust this CPU after so many problems.
.
@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750
Questo è normale e non indica problemi con il processore.
L'utente che ho linkato dal forum AMD aveva aperto una procedura di RMA con AMD. Riporta segfault, ma solo aumentando la frequenza della memoria usando il profilo XMP. Per questo ero curioso di sapere se effettuando overclock in tal senso (o diminuendo il vSoC, che pare sia correlato alla stabilità di memoria ed affini) potessero iniziare ad apparire segfault con le solite modalità, anche con processori che a default non mostrano nulla:
https://community.amd.com/message/2822644#comment-2822644#2822644 (#1347)
After 3 weeks and half my replacement 1700X arrived today. I can't blame the delay on AMD. The problem was Brazilian customs.
It is also a 1725SUS (diffused in USA and made in China). It was certainly pre-tested as there are some small dents in the corners (it looks like they attached the cooler too tight). I hope they did not damage the CPU in any sense. I have just put the CPU back on my computer and started the kill-ryzen.sh test. I will report back in 48 hours.
https://community.amd.com/message/2823637#comment-2823637#2823637 (#1484)
Bad news from my front. I have an RMAed CPU of week 25. It sustained 3 days of kill-ryzen.sh using BIOS defaults. After that I updated my BIOS and changed my memory profile to use XMP 2 (2400 instead of 2100 from Bios default).* Unfortunately, under this conditions I got a new failure in one of the loops:
*
-----------------
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c: In function 'int standard_sse_constant_p(rtx, machine_mode)':
/mnt/ramdisk/workdir/gcc-7.1.0/gcc/config/i386/i386.c:11699:8: internal compiler error: Segmentation fault
** mode = GET_MODE (x);
0x11ac5ec crash_signal
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/toplev.c:337
0x104058c create_output_operand
*** /mnt/ramdisk/workdir/gcc-7.1.0/gcc/optabs.h:94
-----------------
*
I will now revert back memory to BIOS default. I think I read somewhere that Ryzen only officially supports 2100Hz when dealing with 64Gb.
*
I have to admit that I am really tired of this. It will be hard to really trust this CPU after so many problems.
.
@s12a il test è arrivato a 50 minuti e ancora va avanti
Al minuto 32 è apparso
Ubuntu kernel: perf: interrupt took too long (2501>2500), Lowering kerneL.perf_event nax sample rate to 79750
Questo è normale e non indica problemi con il processore.
papugo1980
26-10-2017, 13:15
Ok allora ora metto tutto a default e carico il profilo Xmp e testo
Cmq per me il test (tutto a default ) é superato.
L altro mi faceva errore subito
Cmq per me il test (tutto a default ) é superato.
L altro mi faceva errore subito
metal master
26-10-2017, 13:30
quindi quanti giorni hai impiegato complessivamente ?
circa 20gg.
il mio caso è anche particolare, praticamente ho dovuto pagare la spedizione d'andata ed il pacco spedito con corriere gls il giorno 9/10 è giunto in olanda il 13/10 ed è rimasto fermo in qualche magazzino gls non si sa per quale motivo.
dopo che li ho contattati hanno deciso di inviarmi una cpu sostitutiva in attesa che il pacco che ho mandato riesca a raggiungere l'indirizzo che mi hanno comunicato.
circa 20gg.
il mio caso è anche particolare, praticamente ho dovuto pagare la spedizione d'andata ed il pacco spedito con corriere gls il giorno 9/10 è giunto in olanda il 13/10 ed è rimasto fermo in qualche magazzino gls non si sa per quale motivo.
dopo che li ho contattati hanno deciso di inviarmi una cpu sostitutiva in attesa che il pacco che ho mandato riesca a raggiungere l'indirizzo che mi hanno comunicato.
Mister D
26-10-2017, 13:36
Io vorrei precisare sulla questione ram, perché magari la maggior parte di chi passa di qui non è addentro come la maggior parte di noi iscritti qua:
1) lo std RAM è dell'ente JEDEC.
2) i memory controller di amd, intel e qualsiasi altro produttore di cpu (x86, risc, arm, mips ecc) deve sottostare allo std e dichiarare compatibilità per un certo numero di frequenze JEDEC.
3) tutte le frequenze SOPRA il supporto ufficiale dato da intel o amd SONO da considerasi OVERCLOCK ergo come tutti gli oc è soggetto alla tolleranza data dalla bontà dei chip montati sui kit ram (ICs) e dalla bontà dei MC di quell'esemplare di cpu e dalla bontà della scheda madre utilizzata in particolar modo come BIOS/UEFI
4) INTEL XMP è uno standard proprietario inventato da intel per le SUE cpu con particolari moduli ram certificati XMP (in varie versioni. per es ora siamo a XMP 2.0). Questo std non fa altro che abilitare profili ram NON JEDEC (frequenza, timing, tensione ram, tensione MC) per consentire frequenze più elevate quando supportate dal produttore MB che assicura il test e la scrittura di appositi bios. Il che vuol dire che XMP non è sicuro manco su intel, figurarsi su AMD. E' stato fatto per venire incontro alle esigenze degli utenti meno scafati che vogliono oc ram o cpu con un solo click ergo NON ci si può aspettare che funzioni sempre e comunque.
5) i profili STD JEDEC non solo sono "SAFE" ma vengono letti e configurati al primo avvio della scheda madre SENZA nessun intervento dell'utente e garantiscono la massima compatibilità e stabilità.
6) è prassi dei produttori ram produrre kit con STESSO P/N ma con revisioni di pcb e ICs diverse; ergo anche se hanno la sigla XMP certified questo dovrebbe farvi capire che, nonostante due kit possano sembrare UGUALI questi, siano in realtà DIFFERENTI e abbiano comportamenti differenti, tanto che alcuni produttori di MB (ASUS per es) scrivono nei loro QVL anche la versione di kit ram testata.
Ora che dovrebbe essere chiaro tutto ciò, mi pare evidente che impostare XMP su AMD può portare ad instabilità che a sua volta può portare a crash freeze o a non superare il test di segmentation per verificare sto bug. Ergo mi stupisco come anche sui forum stranieri non si verifichi la presenza del bug SOLO in condizioni DEF con ram impostate su profilo JEDEC standar, proprio per escludere instabilità dovute ad oc.
@s12a se vuoi riportare un estratto di questo post per far capire l'importanza di testare tutto a def nel prima pagina fai pure. Io lo metterei come NOTA RAM.
1) lo std RAM è dell'ente JEDEC.
2) i memory controller di amd, intel e qualsiasi altro produttore di cpu (x86, risc, arm, mips ecc) deve sottostare allo std e dichiarare compatibilità per un certo numero di frequenze JEDEC.
3) tutte le frequenze SOPRA il supporto ufficiale dato da intel o amd SONO da considerasi OVERCLOCK ergo come tutti gli oc è soggetto alla tolleranza data dalla bontà dei chip montati sui kit ram (ICs) e dalla bontà dei MC di quell'esemplare di cpu e dalla bontà della scheda madre utilizzata in particolar modo come BIOS/UEFI
4) INTEL XMP è uno standard proprietario inventato da intel per le SUE cpu con particolari moduli ram certificati XMP (in varie versioni. per es ora siamo a XMP 2.0). Questo std non fa altro che abilitare profili ram NON JEDEC (frequenza, timing, tensione ram, tensione MC) per consentire frequenze più elevate quando supportate dal produttore MB che assicura il test e la scrittura di appositi bios. Il che vuol dire che XMP non è sicuro manco su intel, figurarsi su AMD. E' stato fatto per venire incontro alle esigenze degli utenti meno scafati che vogliono oc ram o cpu con un solo click ergo NON ci si può aspettare che funzioni sempre e comunque.
5) i profili STD JEDEC non solo sono "SAFE" ma vengono letti e configurati al primo avvio della scheda madre SENZA nessun intervento dell'utente e garantiscono la massima compatibilità e stabilità.
6) è prassi dei produttori ram produrre kit con STESSO P/N ma con revisioni di pcb e ICs diverse; ergo anche se hanno la sigla XMP certified questo dovrebbe farvi capire che, nonostante due kit possano sembrare UGUALI questi, siano in realtà DIFFERENTI e abbiano comportamenti differenti, tanto che alcuni produttori di MB (ASUS per es) scrivono nei loro QVL anche la versione di kit ram testata.
Ora che dovrebbe essere chiaro tutto ciò, mi pare evidente che impostare XMP su AMD può portare ad instabilità che a sua volta può portare a crash freeze o a non superare il test di segmentation per verificare sto bug. Ergo mi stupisco come anche sui forum stranieri non si verifichi la presenza del bug SOLO in condizioni DEF con ram impostate su profilo JEDEC standar, proprio per escludere instabilità dovute ad oc.
@s12a se vuoi riportare un estratto di questo post per far capire l'importanza di testare tutto a def nel prima pagina fai pure. Io lo metterei come NOTA RAM.
s12a
26-10-2017, 14:02
@Mister D: aggiunta nota e link al commento assieme alle altre sull'overclock.
s12a
26-10-2017, 14:16
[...] Tuttavia se con gli stessi settaggi alzo il v-soc da ~0,8v a 1.1v diventa stabilissimo e non da errori.
Credo che 1.1V di vSoC sia ancora accettabile, tutto sommato. Se basta questo per risolvere la questione nella maggior parte dei casi con i processori di recente produzione che mostrano l'inconveniente, è possibile che possa diventare lo standard con un update BIOS/firmware futuro.
Credo che 1.1V di vSoC sia ancora accettabile, tutto sommato. Se basta questo per risolvere la questione nella maggior parte dei casi con i processori di recente produzione che mostrano l'inconveniente, è possibile che possa diventare lo standard con un update BIOS/firmware futuro.
papugo1980
26-10-2017, 14:24
@s12a testato con il profilo Xmp (nel BIOS si chiama DOCP)
A 3200 un ora di test e nessun errore
A 3200 un ora di test e nessun errore
Operapia
26-10-2017, 14:27
Io vorrei precisare sulla questione ram, perché magari la maggior parte di chi passa di qui non è addentro come la maggior parte di noi iscritti qua:
1) lo std RAM è dell'ente JEDEC.
2) i memory controller di amd, intel e qualsiasi altro produttore di cpu (x86, risc, arm, mips ecc) deve sottostare allo std e dichiarare compatibilità per un certo numero di frequenze JEDEC.
3) tutte le frequenze SOPRA il supporto ufficiale dato da intel o amd SONO da considerasi OVERCLOCK ergo come tutti gli oc è soggetto alla tolleranza data dalla bontà dei chip montati sui kit ram (ICs) e dalla bontà dei MC di quell'esemplare di cpu e dalla bontà della scheda madre utilizzata in particolar modo come BIOS/UEFI
4) INTEL XMP è uno standard proprietario inventato da intel per le SUE cpu con particolari moduli ram certificati XMP (in varie versioni. per es ora siamo a XMP 2.0). Questo std non fa altro che abilitare profili ram NON JEDEC (frequenza, timing, tensione ram, tensione MC) per consentire frequenze più elevate quando supportate dal produttore MB che assicura il test e la scrittura di appositi bios. Il che vuol dire che XMP non è sicuro manco su intel, figurarsi su AMD. E' stato fatto per venire incontro alle esigenze degli utenti meno scafati che vogliono oc ram o cpu con un solo click ergo NON ci si può aspettare che funzioni sempre e comunque.
5) i profili STD JEDEC non solo sono "SAFE" ma vengono letti e configurati al primo avvio della scheda madre SENZA nessun intervento dell'utente e garantiscono la massima compatibilità e stabilità.
6) è prassi dei produttori ram produrre kit con STESSO P/N ma con revisioni di pcb e ICs diverse; ergo anche se hanno la sigla XMP certified questo dovrebbe farvi capire che, nonostante due kit possano sembrare UGUALI questi, siano in realtà DIFFERENTI e abbiano comportamenti differenti, tanto che alcuni produttori di MB (ASUS per es) scrivono nei loro QVL anche la versione di kit ram testata.
Ora che dovrebbe essere chiaro tutto ciò, mi pare evidente che impostare XMP su AMD può portare ad instabilità che a sua volta può portare a crash freeze o a non superare il test di segmentation per verificare sto bug. Ergo mi stupisco come anche sui forum stranieri non si verifichi la presenza del bug SOLO in condizioni DEF con ram impostate su profilo JEDEC standar, proprio per escludere instabilità dovute ad oc.
@s12a se vuoi riportare un estratto di questo post per far capire l'importanza di testare tutto a def nel prima pagina fai pure. Io lo metterei come NOTA RAM.
Ah, ora che ci penso quando ho fatto il test avevo il mio 1600x impostato su 36.00 manualmente e le ram a 2667...non era a default. Mi sa che questa sera lo ripeto.
1) lo std RAM è dell'ente JEDEC.
2) i memory controller di amd, intel e qualsiasi altro produttore di cpu (x86, risc, arm, mips ecc) deve sottostare allo std e dichiarare compatibilità per un certo numero di frequenze JEDEC.
3) tutte le frequenze SOPRA il supporto ufficiale dato da intel o amd SONO da considerasi OVERCLOCK ergo come tutti gli oc è soggetto alla tolleranza data dalla bontà dei chip montati sui kit ram (ICs) e dalla bontà dei MC di quell'esemplare di cpu e dalla bontà della scheda madre utilizzata in particolar modo come BIOS/UEFI
4) INTEL XMP è uno standard proprietario inventato da intel per le SUE cpu con particolari moduli ram certificati XMP (in varie versioni. per es ora siamo a XMP 2.0). Questo std non fa altro che abilitare profili ram NON JEDEC (frequenza, timing, tensione ram, tensione MC) per consentire frequenze più elevate quando supportate dal produttore MB che assicura il test e la scrittura di appositi bios. Il che vuol dire che XMP non è sicuro manco su intel, figurarsi su AMD. E' stato fatto per venire incontro alle esigenze degli utenti meno scafati che vogliono oc ram o cpu con un solo click ergo NON ci si può aspettare che funzioni sempre e comunque.
5) i profili STD JEDEC non solo sono "SAFE" ma vengono letti e configurati al primo avvio della scheda madre SENZA nessun intervento dell'utente e garantiscono la massima compatibilità e stabilità.
6) è prassi dei produttori ram produrre kit con STESSO P/N ma con revisioni di pcb e ICs diverse; ergo anche se hanno la sigla XMP certified questo dovrebbe farvi capire che, nonostante due kit possano sembrare UGUALI questi, siano in realtà DIFFERENTI e abbiano comportamenti differenti, tanto che alcuni produttori di MB (ASUS per es) scrivono nei loro QVL anche la versione di kit ram testata.
Ora che dovrebbe essere chiaro tutto ciò, mi pare evidente che impostare XMP su AMD può portare ad instabilità che a sua volta può portare a crash freeze o a non superare il test di segmentation per verificare sto bug. Ergo mi stupisco come anche sui forum stranieri non si verifichi la presenza del bug SOLO in condizioni DEF con ram impostate su profilo JEDEC standar, proprio per escludere instabilità dovute ad oc.
@s12a se vuoi riportare un estratto di questo post per far capire l'importanza di testare tutto a def nel prima pagina fai pure. Io lo metterei come NOTA RAM.
Ah, ora che ci penso quando ho fatto il test avevo il mio 1600x impostato su 36.00 manualmente e le ram a 2667...non era a default. Mi sa che questa sera lo ripeto.
Mister D
26-10-2017, 14:40
Ah, ora che ci penso quando ho fatto il test avevo il mio 1600x impostato su 36.00 manualmente e le ram a 2667...non era a default. Mi sa che questa sera lo ripeto.
Vedendo le tue ram in firma:
https://www.kingston.com/datasheets/HX428C14PB2K4_16.pdf
XMP TIMING PARAMETERS
• JEDEC: DDR4-2133 CL15-15-15 @1.2V
• XMP Profile #1: DDR4-2800 CL14-15-15 @1.35V
• XMP Profile #2: DDR4-2666 CL14-14-14 @1.35V
E dato che sono single rank ufficialmente amd ti supporta:
1) 2667 MHz (impostati ovviamente in manuale visto che potrebbe non funzionare XMP profilo 2) se usi 2 moduli su 4 del tuo kit
2) 2133 se usi tutti e 4 i moduli del tuo kit e qui la scheda madre imposta in automatico il profilo jedec 2133 15-15-15.
Visto che in oc è ancora più difficile stabilizzare 4 moduli invece di 2 perché il rumore elettrico destabilizza il MC e visto che ryzen soffre parecchio il rumore elettrico, per il test ti conviene usare le ram su auto e lasciare che si imposti il profilo jedec. Poi puoi provare a impostare in manuale come hai fatto i 2666 passando anche dai 2400 provando varie combinazioni di timing, vdimm, vsoc e anche altra voce:
https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram
CLDO_VDDP (tra 0,8v e 0,9v molti hanno trovato la pace dei sensi con ram che non volevano saperne)
e
ProcODT (CPU on-die termination) tra 50 e 60 ohm ma molti si sono trovati bene con 60 sempre per far bootare ram che non partivano nemmeno se non jedec.
E direi che il test di segmentation potrebbe essere un buon indicatore di instabilità tra MC e ram.;)
Vedendo le tue ram in firma:
https://www.kingston.com/datasheets/HX428C14PB2K4_16.pdf
XMP TIMING PARAMETERS
• JEDEC: DDR4-2133 CL15-15-15 @1.2V
• XMP Profile #1: DDR4-2800 CL14-15-15 @1.35V
• XMP Profile #2: DDR4-2666 CL14-14-14 @1.35V
E dato che sono single rank ufficialmente amd ti supporta:
1) 2667 MHz (impostati ovviamente in manuale visto che potrebbe non funzionare XMP profilo 2) se usi 2 moduli su 4 del tuo kit
2) 2133 se usi tutti e 4 i moduli del tuo kit e qui la scheda madre imposta in automatico il profilo jedec 2133 15-15-15.
Visto che in oc è ancora più difficile stabilizzare 4 moduli invece di 2 perché il rumore elettrico destabilizza il MC e visto che ryzen soffre parecchio il rumore elettrico, per il test ti conviene usare le ram su auto e lasciare che si imposti il profilo jedec. Poi puoi provare a impostare in manuale come hai fatto i 2666 passando anche dai 2400 provando varie combinazioni di timing, vdimm, vsoc e anche altra voce:
https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram
CLDO_VDDP (tra 0,8v e 0,9v molti hanno trovato la pace dei sensi con ram che non volevano saperne)
e
ProcODT (CPU on-die termination) tra 50 e 60 ohm ma molti si sono trovati bene con 60 sempre per far bootare ram che non partivano nemmeno se non jedec.
E direi che il test di segmentation potrebbe essere un buon indicatore di instabilità tra MC e ram.;)
Operapia
26-10-2017, 15:47
Vedendo le tue ram in firma:
https://www.kingston.com/datasheets/HX428C14PB2K4_16.pdf
XMP TIMING PARAMETERS
• JEDEC: DDR4-2133 CL15-15-15 @1.2V
• XMP Profile #1: DDR4-2800 CL14-15-15 @1.35V
• XMP Profile #2: DDR4-2666 CL14-14-14 @1.35V
E dato che sono single rank ufficialmente amd ti supporta:
1) 2667 MHz (impostati ovviamente in manuale visto che potrebbe non funzionare XMP profilo 2) se usi 2 moduli su 4 del tuo kit
2) 2133 se usi tutti e 4 i moduli del tuo kit e qui la scheda madre imposta in automatico il profilo jedec 2133 15-15-15.
Visto che in oc è ancora più difficile stabilizzare 4 moduli invece di 2 perché il rumore elettrico destabilizza il MC e visto che ryzen soffre parecchio il rumore elettrico, per il test ti conviene usare le ram su auto e lasciare che si imposti il profilo jedec. Poi puoi provare a impostare in manuale come hai fatto i 2666 passando anche dai 2400 provando varie combinazioni di timing, vdimm, vsoc e anche altra voce:
https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram
CLDO_VDDP (tra 0,8v e 0,9v molti hanno trovato la pace dei sensi con ram che non volevano saperne)
e
ProcODT (CPU on-die termination) tra 50 e 60 ohm ma molti si sono trovati bene con 60 sempre per far bootare ram che non partivano nemmeno se non jedec.
E direi che il test di segmentation potrebbe essere un buon indicatore di instabilità tra MC e ram.;)
Grazie per le info. Ho intenzione di rifare il test mettendo tutto il BIOS a default. Le RAM andranno a 2133 quindi. C'è da dire che la frequenza di 2667 me la tiene dal secondo aggiornamento del BIOS. Mi è bastato semplicemente impostare a 1 il vsoc e la frequenza ovviamente. I timing non li avevo toccati: tutto su auto. Solo in un secondo momento ho impostato quelli indicati dal produttore. Farò più test comunque, anche con soli due banchi.
https://www.kingston.com/datasheets/HX428C14PB2K4_16.pdf
XMP TIMING PARAMETERS
• JEDEC: DDR4-2133 CL15-15-15 @1.2V
• XMP Profile #1: DDR4-2800 CL14-15-15 @1.35V
• XMP Profile #2: DDR4-2666 CL14-14-14 @1.35V
E dato che sono single rank ufficialmente amd ti supporta:
1) 2667 MHz (impostati ovviamente in manuale visto che potrebbe non funzionare XMP profilo 2) se usi 2 moduli su 4 del tuo kit
2) 2133 se usi tutti e 4 i moduli del tuo kit e qui la scheda madre imposta in automatico il profilo jedec 2133 15-15-15.
Visto che in oc è ancora più difficile stabilizzare 4 moduli invece di 2 perché il rumore elettrico destabilizza il MC e visto che ryzen soffre parecchio il rumore elettrico, per il test ti conviene usare le ram su auto e lasciare che si imposti il profilo jedec. Poi puoi provare a impostare in manuale come hai fatto i 2666 passando anche dai 2400 provando varie combinazioni di timing, vdimm, vsoc e anche altra voce:
https://community.amd.com/community/gaming/blog/2017/05/25/community-update-4-lets-talk-dram
CLDO_VDDP (tra 0,8v e 0,9v molti hanno trovato la pace dei sensi con ram che non volevano saperne)
e
ProcODT (CPU on-die termination) tra 50 e 60 ohm ma molti si sono trovati bene con 60 sempre per far bootare ram che non partivano nemmeno se non jedec.
E direi che il test di segmentation potrebbe essere un buon indicatore di instabilità tra MC e ram.;)
Grazie per le info. Ho intenzione di rifare il test mettendo tutto il BIOS a default. Le RAM andranno a 2133 quindi. C'è da dire che la frequenza di 2667 me la tiene dal secondo aggiornamento del BIOS. Mi è bastato semplicemente impostare a 1 il vsoc e la frequenza ovviamente. I timing non li avevo toccati: tutto su auto. Solo in un secondo momento ho impostato quelli indicati dal produttore. Farò più test comunque, anche con soli due banchi.
nicolarush
26-10-2017, 17:25
Il mio con segfault 1714sus
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
domanda:
hai spedito senza dissipatore e quello che ti hanno mandato è arrivato con dissipatore?
Quello sostitutivo 1733sus
Ora preparo la chiavetta e provo
domanda:
hai spedito senza dissipatore e quello che ti hanno mandato è arrivato con dissipatore?
sinergine
26-10-2017, 17:30
Ricevuto ieri un 1700 da Amazon
UA 1721PGT
Made in Malaysia
Lo apro e lo testo oppure é meglio fare il reso?
Sì é capito quanto é la percentuale di cpu con il bug?
Inviato dal mio KFDOWI utilizzando Tapatalk
UA 1721PGT
Made in Malaysia
Lo apro e lo testo oppure é meglio fare il reso?
Sì é capito quanto é la percentuale di cpu con il bug?
Inviato dal mio KFDOWI utilizzando Tapatalk
doctor who ?
26-10-2017, 17:48
Ricevuto ieri un 1700 da Amazon
UA 1721PGT
Made in Malaysia
Lo apro e lo testo oppure é meglio fare il reso?
Sì é capito quanto é la percentuale di cpu con il bug?
Inviato dal mio KFDOWI utilizzando Tapatalk
Va bene che è sbagliato comportarsi da fan boy e far finta che non ci sia il problema, ma anche questo approccio così tragico è esagerato :p
Testala, se usi il dissipatore stock poi è semplicissimo da montare\smontare
UA 1721PGT
Made in Malaysia
Lo apro e lo testo oppure é meglio fare il reso?
Sì é capito quanto é la percentuale di cpu con il bug?
Inviato dal mio KFDOWI utilizzando Tapatalk
Va bene che è sbagliato comportarsi da fan boy e far finta che non ci sia il problema, ma anche questo approccio così tragico è esagerato :p
Testala, se usi il dissipatore stock poi è semplicissimo da montare\smontare
nicolarush
26-10-2017, 17:48
Lo apro e lo testo oppure é meglio fare il reso?
beh se anche fosse stato 33 a salire lo avresti testato no?
direi di aprire e testare :)
io il mio settimana 8 l'ho testato, se fosse senza problemi lo terrei senza pensarci due volte
anzi mi sono riservato di ritestarlo bene perchè nel cambio cpu ho anche messo su altre memorie ma non ho fatto un clear cmos :mc:
beh se anche fosse stato 33 a salire lo avresti testato no?
direi di aprire e testare :)
io il mio settimana 8 l'ho testato, se fosse senza problemi lo terrei senza pensarci due volte
anzi mi sono riservato di ritestarlo bene perchè nel cambio cpu ho anche messo su altre memorie ma non ho fatto un clear cmos :mc:
sinergine
26-10-2017, 17:59
L'intenzione era quella di provarlo comunque... :D :D :D
Vi aggiornerò...
Vi aggiornerò...
papugo1980
26-10-2017, 18:02
domanda:
hai spedito senza dissipatore e quello che ti hanno mandato è arrivato con dissipatore?
L ho sostituito tramite l ammazzone.non ho fatto rma con AMD.
hai spedito senza dissipatore e quello che ti hanno mandato è arrivato con dissipatore?
L ho sostituito tramite l ammazzone.non ho fatto rma con AMD.
nagashadow
26-10-2017, 20:18
Ragazzi sapete dove trovare qualche guida per overclokkare il 1700 con scheda madre MSI x370?
Operapia
26-10-2017, 20:49
Il test quando va a buon fine come deve essere. Ora si ferma al loop 11
Niente, mi ha dato un errore tipo "kernel bug" e si è bloccato tutto ubunto. Ho dovuto resettare. Che strano però, lo stesso test non mi aveva dato questo problema l'altra volta.
Niente, mi ha dato un errore tipo "kernel bug" e si è bloccato tutto ubunto. Ho dovuto resettare. Che strano però, lo stesso test non mi aveva dato questo problema l'altra volta.
papugo1980
26-10-2017, 21:13
Il test quando va a buon fine come deve essere. Ora si ferma al loop 11
Niente, mi ha dato un errore tipo "kernel bug" e si è bloccato tutto ubunto. Ho dovuto resettare. Che strano però, lo stesso test non mi aveva dato questo problema l'altra volta.
Ti si ferma al loop 11 (però in realtà sta lavorando)
Lo puoi vedere cin system monitor
Niente, mi ha dato un errore tipo "kernel bug" e si è bloccato tutto ubunto. Ho dovuto resettare. Che strano però, lo stesso test non mi aveva dato questo problema l'altra volta.
Ti si ferma al loop 11 (però in realtà sta lavorando)
Lo puoi vedere cin system monitor
Operapia
26-10-2017, 21:58
Ti si ferma al loop 11 (però in realtà sta lavorando)
Lo puoi vedere cin system monitor
Quindi il test è andato bene? L'ho fatto girare un'altra volta e si è bloccato ancora, solo che questa volta pare abbia saturato la RAM. Se riesco vi posto questa sera la foto che ho fatto, se no ci vuole domani. Comunque il test è superato giusto?
Lo puoi vedere cin system monitor
Quindi il test è andato bene? L'ho fatto girare un'altra volta e si è bloccato ancora, solo che questa volta pare abbia saturato la RAM. Se riesco vi posto questa sera la foto che ho fatto, se no ci vuole domani. Comunque il test è superato giusto?
papugo1980
26-10-2017, 22:41
Si superato :D
Operapia
27-10-2017, 09:23
Buon giorno,
allora, questi erano i risultati della prima volta che feci il test, con le ram (4x4) a 2666.
http://imagizer.imageshack.us/v2/xq90/922/YkRmEW.png (https://imageshack.com/i/pmYkRmEWp)
http://imagizer.imageshack.us/v2/xq90/923/84QGop.png (https://imageshack.com/i/pn84QGopp)
http://imagizer.imageshack.us/v2/xq90/924/QzeGyi.png (https://imageshack.com/i/poQzeGyip)
Questo invece il risultato del test di ieri sera con le ram (2x4) a default.
http://imagizer.imageshack.us/v2/xq90/924/gFjimi.jpg (https://imageshack.com/i/pogFjimij)
COme mi spiegavano 4 banchi di ram a 2666 sono in overclock per ryzen e quindi instabili.
Comunque miglio così, mi risparmio 20 euro di spedizione ad amd e quando voglio posso vendere il processore tranquillamente.
allora, questi erano i risultati della prima volta che feci il test, con le ram (4x4) a 2666.
http://imagizer.imageshack.us/v2/xq90/922/YkRmEW.png (https://imageshack.com/i/pmYkRmEWp)
http://imagizer.imageshack.us/v2/xq90/923/84QGop.png (https://imageshack.com/i/pn84QGopp)
http://imagizer.imageshack.us/v2/xq90/924/QzeGyi.png (https://imageshack.com/i/poQzeGyip)
Questo invece il risultato del test di ieri sera con le ram (2x4) a default.
http://imagizer.imageshack.us/v2/xq90/924/gFjimi.jpg (https://imageshack.com/i/pogFjimij)
COme mi spiegavano 4 banchi di ram a 2666 sono in overclock per ryzen e quindi instabili.
Comunque miglio così, mi risparmio 20 euro di spedizione ad amd e quando voglio posso vendere il processore tranquillamente.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.