View Full Version : [Discussione] AMD Ryzen - problematiche di Segmentation Fault (segfault)
Tornato il 1600x dall'Olanda: 1740SUS
Montato, rispetto all'altro sembra più fluido e cmq fa quasi 10 gradi in meno dell'altro a stock con memorie a 3066.
Prime 95 fa 59 gradi.
Ragazzi ho provato il test ryzen killer più volte e mi ha dato questi errori
http://i66.tinypic.com/2eem0xk.png
http://i68.tinypic.com/spgn05.png
http://i68.tinypic.com/wmo8ep.png
http://i63.tinypic.com/330b408.png
Non sono usciti subito (a parte uno) e alcuni test si sono svolti senza problemi (4 core 4 treadh andato per 2 ore senza errori), cosa ne dite?
papugo1980
24-11-2017, 13:11
Ragazzi ho provato il test ryzen killer più volte e mi ha dato questi errori
http://i66.tinypic.com/2eem0xk.png
http://i68.tinypic.com/spgn05.png
http://i68.tinypic.com/wmo8ep.png
http://i63.tinypic.com/330b408.png
Non sono usciti subito (a parte uno) e alcuni test si sono svolti senza problemi (4 core 4 treadh andato per 2 ore senza errori), cosa ne dite?
Tranne uno screen il resto ce l errore segfault
Quickdany
24-11-2017, 14:31
Ci ragazzi, rieccomi mi sembrava gentile dare un aggiornamento a tutti.
Allora per quelli non esperti di corrieri confermo che la spedizione DHL pagata da AMD ci mette 1 giorno. Ossia se si spedisce il giovedì arriva il venerdì.
Per il mio caso spedita venerdì arrivata lunedì.
Ci hanno messo fino a mercoledi a dare la conferma del arrivo e dopo un paio di solleciti al ticket RMA aperto.
Giovedi spedito il processore nuovo ma nessuna email con il tracking mi è arrivata, scoperto dopo il sollecito al ticket dal quale ho ricevuto il tracking a spedizione già avvenuta. Il processore arrivato questa mattina (venerdì).
Ora sto facendo il test segfault su linux spero di non avere sorprese.
Cmq RMA di un 17 36 PGS, mi hanno mandato in sostituzione un 17 33 SUS
Allora per quelli non esperti di corrieri confermo che la spedizione DHL pagata da AMD ci mette 1 giorno......
Eh, magari, dipende dalla zona, non per tutti è così.
Comunque posso confermare che hanno ripreso a spedire i nuovi processori, sono riuscito a farmi dare anche il tracking :D
Quickdany
24-11-2017, 15:12
Oh si bravo, volevo scriverlo ma poi mi sono scordato.
Si essendo in Emilia sono in una zona con un ottimo servizio, quindi in giornata è su un volo. Cmq la tariffa express dovrebbe avere quelle tempistiche a parte zone sfortunate
Cmq non tutti processori sono affetti dal problema indipendentemente dalla settimana di produzione, mi sembra che si stia un po' generalizzando il mio ad esempio settima 7, comprato il 2 aprile non ha bug col test su Linux.
Il test è nato proprio questo, non mi pare si stia generalizzando.
Debern9093
24-11-2017, 21:12
Salve ragazzi, CPU tornata dall rma, r5 1600x 1740SUS, ho effettuato il test dalle 21:13 e si è interrotto alle 22:06, non mi sembra un segfault vi lascio lo screen, inoltre la CPU è più fresca di 10 gradi
https://imgur.com/mGSurp1
papugo1980
24-11-2017, 21:43
Salve ragazzi, CPU tornata dall rma, r5 1600x 1740SUS, ho effettuato il test dalle 21:13 e si è interrotto alle 22:06, non mi sembra un segfault vi lascio lo screen, inoltre la CPU è più fresca di 10 gradi
https://imgur.com/mGSurp1
Non è segfault.ottimo
Debern9093
24-11-2017, 22:00
Non è segfault.ottimo
Perfetto :D dovrebbe significare che ha terminato la memoria ram o sbaglio? Comunque ho notato anche un netto miglioramento della fluidità del sistema, quello che avevo prima che era un 1716 aveva dei rallentamenti notevoli nell'uso di Windows 10
Salve ragazzi, CPU tornata dall rma, r5 1600x 1740SUS, ho effettuato il test dalle 21:13 e si è interrotto alle 22:06, non mi sembra un segfault vi lascio lo screen, inoltre la CPU è più fresca di 10 gradi
https://imgur.com/mGSurp1
Come scrivevo prima anche a me 1600x 1740sus tornato Giovedì. Molto più fresco e secondo me più stabile, l'altro sotto W10 freezava come dici tu ogni tanto.
Il test non l'ho rifatto e non penso lo rifarò, mi sta bene così 😀:D
Testato per svariate ore il 1700 tornato dall'RMA, tutto OK! :winner:
Piccolo OT: col dissipatore stock a che temperatura si attestano i 1700 a stock? In idle il mio sta attorno ai 40°, mi sembrava che altri parlassero di temperature più basse...
Ragazzi voi per richiedere l'rma su sito amd avete compilato il AMD Warranty Request Form?
Ragazzi voi per richiedere l'rma su sito amd avete compilato il AMD Warranty Request Form?
Si!
Testato per svariate ore il 1700 tornato dall'RMA, tutto OK! :winner:
Piccolo OT: col dissipatore stock a che temperatura si attestano i 1700 a stock? In idle il mio sta attorno ai 40°, mi sembrava che altri parlassero di temperature più basse...
23° con 18.5° in camera. Temp. rilevata, evidentemente sballata, se in idle produce 10w, i 23° son pochi!
Debern9093
25-11-2017, 23:07
Ragazzi scusate se vado leggermente OT... Con il mio r5 1600x nuovo che col vecchio mandato in rma è scheda madre Asus prime b350m-k noto che le temperature hanno degli sbalzi anche di 10 gradi.. Ad esempio in idle sono a 27 gradi e non ho nessuna ventola installata nel case però all'improvviso sbalzato a 38 circa tt di un botto per poi riscendere gradualmente.. Insieme alla temperatura anche il vcore è ballerino.. E normale? Lo fa anche a voi?
23° con 18.5° in camera. Temp. rilevata, evidentemente sballata, se in idle produce 10w, i 23° son pochi!
Non avevo messo il profilo energetico bilanciato da Windows, ora scende di clock e vcore in idle, con conseguente abbassamento delle temp. Grazie & chiuso OT. :)
sinergine
27-11-2017, 08:54
Chiesta RMA ieri pomeriggio.
Questa mattina è arrivata la mail con RMA e acciunt DHL.
Devo quindi mettere la cpu nel blister rasparente e quindi in un'altra scatola? La scatola originale latengo io?
Scrivo indirizzo e N° RMA sul pacco e poi vado al centro DHL con la mail di AMD?
Chiesta RMA ieri pomeriggio.
Questa mattina è arrivata la mail con RMA e acciunt DHL.
Devo quindi mettere la cpu nel blister rasparente e quindi in un'altra scatola? La scatola originale latengo io?
Scrivo indirizzo e N° RMA sul pacco e poi vado al centro DHL con la mail di AMD?
Io ho inserito la cpu nel blister trasparente e poi ho utilizzato un sacchetto antistatico; per l'imballaggio ho utilizzato il nylon con le bolle e della carta per riempire il pacchetto; sul pacco è importante indicare indirizzo del destinatario con numero di RMA ed indirizzo a cui spedire il processore sostitutivo (return shipping address).
Al centro DHL dovrai fornire il numero dell'account che ti è stato inviato via mail per usufruire della spedizione prepagata.
Riporto qui la mia esperienza sulla RMA:
Inviato la vecchia cpu 1709SUT il 13/11; ricevuta la nuova 1742SUS dopo 2 settimane esatte, il 27/11.
Dopo aver soltanto sostituito la cpu, lasciando tutte le impostazioni com'erano sul bios (nessun overclock tranne la ram a 2933), test kill-ryzen in linux dopo più di un'ora: nessun errore, prima erano sufficienti meno di 2 minuti.
In windows, da ryzen master noto subito che non ho più l'andamento ballerino sulla tensione della cpu che prima dava picchi fino a 1,5V mentre ora arriva massimo ad 1.22; temperatura in idle a poco più di 30°, in full load con benchmark 7zip su tutti i core max 45°; c'è da dire anche che il Noctua NH-D15 con 2 ventole fa il suo dovere e la temperatura ambiente è di 20°; rispetto alla vecchia cpu avrò almeno 10° in meno.
2 settimane di fermo macchina ma direi che ne è decisamente valsa la pena!
alexsky8
28-11-2017, 09:05
Testato per svariate ore il 1700 tornato dall'RMA, tutto OK! :winner:
Piccolo OT: col dissipatore stock a che temperatura si attestano i 1700 a stock? In idle il mio sta attorno ai 40°, mi sembrava che altri parlassero di temperature più basse...
40°C in Idle non li avevo neppure ad inizio Agosto con quasi 30°C in camera
controlla se hai montato bene il dissipatore
alexsky8
28-11-2017, 09:08
Riporto qui la mia esperienza sulla RMA:
Inviato la vecchia cpu 1709SUT il 13/11; ricevuta la nuova 1742SUS dopo 2 settimane esatte, il 27/11.
Dopo aver soltanto sostituito la cpu, lasciando tutte le impostazioni com'erano sul bios (nessun overclock tranne la ram a 2933), test kill-ryzen in linux dopo più di un'ora: nessun errore, prima erano sufficienti meno di 2 minuti.
In windows, da ryzen master noto subito che non ho più l'andamento ballerino sulla tensione della cpu che prima dava picchi fino a 1,5V mentre ora arriva massimo ad 1.22; temperatura in idle a poco più di 30°, in full load con benchmark 7zip su tutti i core max 45°; c'è da dire anche che il Noctua NH-D15 con 2 ventole fa il suo dovere e la temperatura ambiente è di 20°; rispetto alla vecchia cpu avrò almeno 10° in meno.
2 settimane di fermo macchina ma direi che ne è decisamente valsa la pena!
la mia settimana 33 da errore segfault ma ha temperature basse e tensione stabile mentre quella che avevo prima era un settimana 17 dava errore ma aveva temperature alte e tensione ballerina
quindi i problemi di temperatura tensione ed errore segfault non sono correlati
la mia settimana 33 da errore segfault ma ha temperature basse e tensione stabile mentre quella che avevo prima era un settimana 17 dava errore ma aveva temperature alte e tensione ballerina
quindi i problemi di temperatura tensione ed errore segfault non sono correlati
I problemi non sono correlati ma mi sembra di capire che i processori di recentissima produzione abbiano un "silicio migliore"; il mio è un settimana 42 ed ho avuto miglioramenti notevoli su temperatura e tensione.
Debern9093
28-11-2017, 12:59
Se x tensione intendete i voltaggi ballerini con conseguente temperatura che sale e scende di botto è normale, è l xfr ke su due core quando la temperatura è bassa spara la frequenza al massimo (una sorta di turbo) x pochi secondi
Se x tensione intendete i voltaggi ballerini con conseguente temperatura che sale e scende di botto è normale, è l xfr ke su due core quando la temperatura è bassa spara la frequenza al massimo (una sorta di turbo) x pochi secondi
Sì ma quando i voltaggi vengono sparati a valori elevati è meno normale.
Debern9093
28-11-2017, 13:47
Sì ma quando i voltaggi vengono sparati a valori elevati è meno normale.
X niente.. È ovvio che se l xfr spara due core a 4-4,1 Ghz i voltaggi devono salire ampiamente anch'essi.. Così come le temperature.. Ma comunque i voltaggi alti che vedi non sono da considerare il voltaggio di tutta la cpu ma bensì solamente dei due core stessi
X niente.. È ovvio che se l xfr spara due core a 4-4,1 Ghz i voltaggi devono salire ampiamente anch'essi.. Così come le temperature.. Ma comunque i voltaggi alti che vedi non sono da considerare il voltaggio di tutta la cpu ma bensì solamente dei due core stessi
Resta il fatto che col vecchio processore vedevo superare addirittura gli 1,5v mentre ora, su 2 core con xfr, arrivo al massimo ad 1.22v senza aver modificato alcuna impostazione da bios nè da profilo energetico su windows.
Debern9093
28-11-2017, 16:27
Resta il fatto che col vecchio processore vedevo superare addirittura gli 1,5v mentre ora, su 2 core con xfr, arrivo al massimo ad 1.22v senza aver modificato alcuna impostazione da bios nè da profilo energetico su windows.
E nel bios che valore ti dà?
E nel bios che valore ti dà?
Sul bios ho cpu core= 1.264V e Vsoc=1.155; su windows, rilevando con ryzenmaster, dipende dal profilo energetico; se metto bilanciato varia tra 0.8 ed 1.2 circa; col ryzen balanced sembra restare sempre in tiro attorno agli 1.25 ma resto sempre ben lontano dai valori della cpu precedente.
Debern9093
28-11-2017, 23:07
Sul bios ho cpu core= 1.264V e Vsoc=1.155; su windows, rilevando con ryzenmaster, dipende dal profilo energetico; se metto bilanciato varia tra 0.8 ed 1.2 circa; col ryzen balanced sembra restare sempre in tiro attorno agli 1.25 ma resto sempre ben lontano dai valori della cpu precedente.
E se misuri con altri programmi tipo hwmonitor?
Mister D
29-11-2017, 07:58
Vorrei far notare che quello che state dicendo è lapalissiano.
Già più passa tempo che le rese aumentano e migliorano (seppur di poco) le caratteristiche elettriche del silicio (come coppie frequenze/tensioni), se poi per risolvere il bug AMD ha cambiato SELEZIONE, vuol dire che le nuove cpu (TUTTTE) vengono selezionate/scelte in base a criteri diversi e un effetto secondario è quello di avere cpu che reggono le medesime frequenze a tensioni più basse. Non so chi di voi ricorda le cpu AMD con silicio SOI che da quel punto di vista erano ancor meglio, perché ogni infornata successiva migliorava fino a permettere ad AMD di poter continuare ad introdurre cpu con frequenze maggiori (vedi per es i phenomII partiti con il 965 e arrivati al 980 se non sbaglio). Lì c'era il CTI (continium transistor improvment), caratteristiche del SOI, che permetteva quindi di migliorare continuamente. Con silicio bulk (anche in versione finfet) il miglioramento non è continuo ma avviene a step quando il produttore sceglie di cambiare la selezione in base alla rese e agli obiettivi di vendita. Le rese nel tempo aumentano sempre fino ad avere un andamento piatto, a quel punto il produttore può:
1) produrre più cpu "sane" e aumentare l'offerta che a parità di domanda fa abbassare il prezzo.
2) modificare la selezione, mantenendo le rese precedenti, introducendo una cpu con SKU nuova e maggiore frequenza (ergo prestazioni).
Questo per dire che è normale che le cpu che vengano rimandate indietro siano migliori come effetto secondario. Non è che vengono selezionate SOLO per non avere il bug;)
Io devo ancora fare test ed eventuale RMA, direi che ho fatto bene ad aspettare. Mi sa che questa settimana mi ci metto :)
Saluti
Kappa
Vorrei far notare che quello che state dicendo è lapalissiano.
Già più passa tempo che le rese aumentano e migliorano (seppur di poco) le caratteristiche elettriche del silicio (come coppie frequenze/tensioni), se poi per risolvere il bug AMD ha cambiato SELEZIONE, vuol dire che le nuove cpu (TUTTTE) vengono selezionate/scelte in base a criteri diversi e un effetto secondario è quello di avere cpu che reggono le medesime frequenze a tensioni più basse. Non so chi di voi ricorda le cpu AMD con silicio SOI che da quel punto di vista erano ancor meglio, perché ogni infornata successiva migliorava fino a permettere ad AMD di poter continuare ad introdurre cpu con frequenze maggiori (vedi per es i phenomII partiti con il 965 e arrivati al 980 se non sbaglio). Lì c'era il CTI (continium transistor improvment), caratteristiche del SOI, che permetteva quindi di migliorare continuamente. Con silicio bulk (anche in versione finfet) il miglioramento non è continuo ma avviene a step quando il produttore sceglie di cambiare la selezione in base alla rese e agli obiettivi di vendita. Le rese nel tempo aumentano sempre fino ad avere un andamento piatto, a quel punto il produttore può:
1) produrre più cpu "sane" e aumentare l'offerta che a parità di domanda fa abbassare il prezzo.
2) modificare la selezione, mantenendo le rese precedenti, introducendo una cpu con SKU nuova e maggiore frequenza (ergo prestazioni).
Questo per dire che è normale che le cpu che vengano rimandate indietro siano migliori come effetto secondario. Non è che vengono selezionate SOLO per non avere il bug;)
Ritengo utile che chi riceve le nuove cpu riporti la propria esperienza, sia per chi si appresta a richiedere RMA che per chi l'ha fatta ed ha ricevuto una cpu più vecchiotta, anche per avere un'idea di come stiano migliorando le rese; non è così?
Mister D
29-11-2017, 11:04
Ritengo utile che chi riceve le nuove cpu riporti la propria esperienza, sia per chi si appresta a richiedere RMA che per chi l'ha fatta ed ha ricevuto una cpu più vecchiotta, anche per avere un'idea di come stiano migliorando le rese; non è così?
Stai fraintendendo il senso del mio post. Non dico che non sia utile riportare la propria esperienza, ma sembra quasi che vi stupiate di una cosa che è così dall'alba dei tempi e quindi considerando che magari alcuni di voi sono neofiti, ho cercato di spiegare perché di questo comportamento. Non è che prima erano fallate perché "arrivavano a 1,5 volt su 2 core" ma perché davano il bug in compilazione. Anche perché qua dentro più di uno hanno riportato invece cpu di prime settimane esenti da problemi, pochi in relazione a tutti gli altri ma ci sono (e anche loro la cpu arriva sopra gli 1,4 con XFR su 2 core).
Inoltre mi è capitato di dare una mano ad alcuni utenti che riportavano questo "problema" con i ryzen usciti dopo i 7 e gli si è risolto applicando gli "optimized default setting" nel bios. Magari non è il tuo caso ma ad altri è bastato impostare i valori ottimizzati di def e la cpu è stata riconosciuta meglio, come se il bios al primo avvio settasse valori per altri ryzen.;)
il_dottorino
29-11-2017, 11:18
@Ozozuz hai scoperto un nuovo bug? Anche il mio procio è della 33esima settimana
Stai fraintendendo il senso del mio post. Non dico che non sia utile riportare la propria esperienza, ma sembra quasi che vi stupiate di una cosa che è così dall'alba dei tempi
Nessuno stupore, stavo solo constatando ed evidenziando tutto ciò che è cambiato tra la vecchia e la nuova cpu, senza ricondurre minor tensione/temperatura a segfault; questo per fare in modo che chi riceverà i processori di nuova produzione sappia un pò cosa aspettarsi; senza polemica :D
Debern9093
29-11-2017, 12:05
Anche la mia nuova CPU 1740sus su due core con xfr va sopra gli 1.4v.. Ma io credo che dipenda soprattutto dalla scheda madre in uso.. Infatti a me la MB imposta il vcore di default a 1.375
Anche la mia nuova CPU 1740sus su due core con xfr va sopra gli 1.4v.. Ma io credo che dipenda soprattutto dalla scheda madre in uso.. Infatti a me la MB imposta il vcore di default a 1.375
Che scheda e che versione bios hai ?
Debern9093
29-11-2017, 14:05
Che scheda e che versione bios hai ?
Ho una Asus prime b350m-k ultimo BIOS 3203
Mister D
29-11-2017, 18:36
"Sbagli".
Non é (o meglio, non ancora ad oggi) semplice discorso di raffinazione del processo produttivo, si tratta ancora di processori estremamente selezionati non rappresentati lo stadio evolutivo raggiunto dalla gen. attuale.
Il 33 che ho ricevuto da AMD richiede a paritá di frequenza quasi 0.15v meno di un 38 che ha ricevuto un mio amico qualche settimana fa, 38 che a sua volta é in linea con il 34,33,07 che ho avuto modo di provare personalmente.
Purtroppo siamo ancora anni luce lontani da vedere questo miglioramento (quello dei chip selezionati da AMD) nella produzione normale, probabilmente é un anticipazione della nuova generazione :D
FIXED
Io potrei anche sbagliarmi, nel senso che non so quando è stata imposta la nuova selezione a tutte le fabbriche di GF/AMD nel mondo (se non lo dichiara AMD quando ha revisionato il test di selezione sarà difficile stabilirlo noi qua con così pochi numeri). Detto questo, te che tiri fuori un (UNO) processore solo per far statistica mi fa sorridere. Per fare statistica servirebbero molte più unità e anche usando distribuzioni che richiedono un numero di campioni minori (come per es quella di Student rispetto alla più normale Guassiana) un solo processore settimana 38 non è per nulla indicativo. Anche perché dalla stessa settimana possono uscire cpu diverse, nate da wafer diversi o diverse perché prese in posizioni diverse dello stesso wafer. Magari quella del tuo amico era la peggior cpu di quel lotto della settimana 38. Poi non dici nemmeno se quelle che hai esaminato sono tutte stesse identiche SKU. Sai che un ryzen 5 1600X per es è qualitativamente inferiore ad un ryzen 7 1800X? Anche se potrebbe capitare un ryzen 1600X che regge meglio del peggior 1800X, in media i ryzen 5 sono scarti dei 7 come i 3 sono scarti di quelli sopra.
Magari le tue cpu erano tutte ryzen 7 mentre lui ha un ryzen 3 ed ecco scoperto perché ha quelle tensioni.;)
E se misuri con altri programmi tipo hwmonitor?
Controllato con Hwinfo64:
- in full load su tutti i cores mi dà max 1.081V
- in full load su un solo core con xfr a palla max 1.231V
Controllato con Hwinfo64:
- in full load su tutti i cores mi dà max 1.081V
- in full load su un solo core con xfr a palla max 1.231V
E l ho letto da più esperienze che le cpu prive del bug e più recenti abbiano vcore normali... il mio arrivava ad 1.580 o anche più e xfr o altro per me non era tanto salutare per la cpu che in quegli attimi aveva anche una bella impennata di temperatura... ora che ho consigliato ryzen ad un mio collega sono curioso di vedere se la cpu avrà il bug o meno e spero ovviamente di no per vedere come si comporta con il vcore
Debern9093
29-11-2017, 21:50
"Sbagli".
Non é (o meglio, non ancora ad oggi) semplice discorso di raffinazione del processo produttivo, si tratta ancora di processori estremamente selezionati non rappresentati lo stadio evolutivo raggiunto dalla gen. attuale.
Il 33 che ho ricevuto da AMD richiede a paritá di voltaggio quasi 0.15v meno di un 38 che ha ricevuto un mio amico qualche settimana fa, 38 che a sua volta é in linea con il 34,33,07 che ho avuto modo di provare personalmente.
Purtroppo siamo ancora anni luce lontani da vedere questo miglioramento (quello dei chip selezionati da AMD) nella produzione normale, probabilmente é un anticipazione della nuova generazione :D
No perche ? Ho rimandato il primo processore ricevuto da AMD per un problema di temperature ma era esente da seg-fault.
Ke problema di temperature avevi?
Mister D
30-11-2017, 08:51
Si, ovviamente intendevo a paritá di frequenza altrimenti la frase non avrebbe avuto senso.
Non ne sto tirando fuori uno, quindi non capisco cosa ti sia inventato o cosa faccia ridere, ne ho provati 3 retail, 2 da amd, assemblati almeno 3 e conosco almeno altre 5 persone personalmente con build ryzen , siamo a ~15 build ryzen montate o provate dal sottoscritto, mi sembra improbabile che tutti siano casualmente coerenti nei risultati no ? ( e la stessa opinione é ovviamente condivisa ovunque su reddit), quindi forse dovresti leggere meglio anziché ridere :asd:
Detto questo parlando di probabilitá, mi fa ridere sentirti a parlare di distribuzioni di probabilità quando io non ho mai fatto nemmeno cenno, sto solo usando dati e numeri ad oggi riscontrati.
Detto questo é OVVIO che una stessa settimana escano cpu diverse, secondo te le selezionate da dove vengono ? Mica le producono appositamente...:rolleyes:
Come é anche OVVIO che da un punto di puro silicio é praticamente certo che un 1600 sia peggiore di un 1800x, non capisco perché stai elencando banalitá note, non stanno rafforzando ne il mio ne il tuo discorso.
E no, perdonami ma so io che cpu ho installato ;)
Partiamo dal fondo.
Io NON ho scritto che NON SAI che cpu hai installato (ci mancherebbe altro, ti pare???), ho invece scritto che NON HAI DETTO (specificato) che cpu è quella del tuo amico (settimana 38 ma quale? Ryzen 5? 7? 3? ecc) rispetto invece quelle che hai avuto te (di cui sinceramente non mi ricordo se sono tutte ryzen 5 1600, sicuramente lo hai anche scritto ma non ho voglia di tornare indietro a vedere). E poi dici a me di leggere. Uhm magari farebbe comodo anche a te leggere visto che SAPERE è diverso da DIRE :asd:
Detto questo forse non mi sono spiegato bene.
Se avessi provato un numero significativo di cpu 38 (tipo una decina o anche di più) che abbiano tutte vcore più elevati della tua 33 ricevuta da AMD allora magari avresti pure ragione, anche se poi c'entra pure la scheda madre perché a parità di scheda madre ok ma con schede madri diverse capita che stessa cpu gli vengano applicate tensioni diverse (molti lo hanno notato qui sul forum).
Io ti sto dicendo che magari il tuo amico ha un ryzen 3 (ipotesi mia visto che potevi anche scriverlo invece di dirmi "so che cpu ho montato", ma grazie, il mio era un modo indiretto per chiederti di specificarlo, ripeto, mica un modo per dire che non sai manco che cpu monti. Secondo te potrei mai pensare una cosa del genere? Mah :help:) settimana 38 che essendo uno scarto dello scarto si comporta peggio come vcore rispetto il tuo ryzen 5 (altra ipotesi mia) settimana 33. Ecco perché ho tirato fuori il discorso che le cpu da SKU diverse (ryzen 5 vs 7) sono diverse perché AMD ovviamente sceglie di recuperare quelle che non passano la selezione per le SKU di fascia più alta. Poi il ryzen settimana 38 del tuo amico è esente da segfault? E sai che anche se lo fosse potrebbe benissimo essere una cpu selezionata come le prime (quindi come la tua 07) ma che per chiappa divina è esente da bug? Purtroppo non sappiamo quando AMD ha decido di cambiare e applicare a tutti il nuovo test (ne riparlo più avanti).
Inoltre ti ho fatto un discorso di distribuzioni di probabilità proprio per dirti "occhio a trarre deduzioni da numeri bassi di campione" (se non lo tiri fuori te, io non posso tirarlo fuori? Ho capito bene?).
Poi ancora io ho scritto "sorridere" non ridere, non sono la stessa cosa, mentre a te faccio ridere (hai usato te questo termine). Bene così:D
Poi sinceramente anche con i numeri non ti seguo. 3 ne hai provate te personalmente, poi dici assemblati almeno 3 (almeno 3 quindi a quanto equivale? 4? 5? 10?) e infine conosci almeno 5 persone con build ryzen (anche qui almeno che significa). Tutto questo per te fa circa 15. Bho sarò io a far male i conti perché 3+3+5=11 ma con gli almeno sei già arrivato a circa 15. Bene.
E di reddit sinceramente non mi fido mica tanto, rimaniamo con i tuoi numeri che sono sicuramente veri. Ti credo quando dici di averli provati e di aver dedotto quanto sopra, non sto dicendo che siccome me lo dici te allora non ti credo. E' solo che per me sono cmq pochi per fare statistica.
Detto questo non capisco cosa vuoi dire con "estremamente selezionati".
Io credo che siccome AMD ha parlato di cambio di quality test per eliminare il problema di insorgere del bug sulla maggior parte di cpu ha preso queste misure:
1) trovato nuovo test di selezione, provato e revisionato la procedura e distribuito alle varie fabbriche nel mondo. La data certa però, ripeto, la possiamo solo ipotizzare e con scarso successo direi fin'ora ma saperla esattamente è possibile SOLO se AMD la specifica ufficialmente (e temo che non lo farà mai)
2) predisposto per l'ufficio RMA di usare le cpu prodotte precedentemente e tenuto a magazzino per le RMA SOLO dopo averle ritestate (quindi ri-selezionate) con il nuovo test di selezione. E queste sono le cpu che vi hanno mandato indietro. Forse intendi con questo "cpu estremamente selezionate"?;)
Ovviamente la 2) continuerà ad essere valida finché non verrà svuotato il magazzino di cpu "vecchie" usate per le RMA. Appena avranno esaurito le scorte ovviamente rispediranno indietro SOLO cpu appena prodotte e già selezionate con il nuovo test (e quindi senza bisogno di fare nuovamente un test di selezione).
E di riflesso, sia quelle vecchie riselezionate che quelle nuove selezionate con nuovo test, hanno anche vcore più bassi e magari pure temp più basse (e qui lo avete detto chiaramente in molti, che le cpu rientrare da RMA vanno meglio). Ovviamente a parità di SKU. Quindi per essere preciso intendo che ryzen 7 post cambio test avranno mediamente valori più bassi di vcore e temp più basse rispetto a ryzen 7 prodotti prima del cambio test qualitativo. E così via. Capito?
E da qui, proprio per via del nuovo test qualitativo di selezione per tutte le cpu, ho spiegato che per me tutte le cpu prodotte e selezionate con il nuovo test avranno coppie frequenze/tensioni migliori delle precedenti, proprio a causa del nuovo test di selezione. Non mi sembra di aver fatto chissà quale ipotesi strampalata. E tu da qui hai asserito che sbaglio perché un settimana 38 del tuo amico si comporta come altre tue cpu 34,33 e 07. E se ti dicessi che magari hanno cambiato la selezione nella settimana 39 o 40? E che quindi il 38 è stato selezionato come i tuoi 34 33 07, di cui però non capito quali siano di ritorno da AMD o se siano tutti nuovi e comprati a suo tempo, ed è per questo che hanno lo stesso comportamento? Non lo sappiamo purtroppo.
Quello che è certo è che c'è una correlazione tra cpu senza bug e cpu che richiedono meno tensione. E la risposta indiretta ce l'ha fornita AMD: hanno cambiato test qualitativo di selezione. Quindi magari tutte le cpu che hanno il bug si comportano peggio dal punto di vista delle tensioni/temp rispetto a quelle vecchie che non lo hanno (poche, pochissime) e a quelle nuove selezionate con nuovo test (ripeto per l'ennesima volta: di cui NON sappiamo da che settimana di produzione partano).
In pratica è come se il problema di segfault avesse costretto AMD ha migliorare la produzione di cpu come solitamente si fa quando, a fronte di rese migliori, si creano nuove SKU. Capito ora?
Forse così ho spiegato meglio il mio punto di vista. Ma non voglio né farti cambiare idea né dirti che magari invece hai ragione te e AMD, ingiustificatamente, non ha cambiato nulla e seleziona SOLO le cpu da rispedire ai clienti che richiedono RMA per segfault.
Sinceramente per me sarebbe abbastanza grave che sotto sistema di qualità (AMD come tutte le aziende enormi possiedono sistemi di gestione della qualità certificati) scopra di avere un bug, di poterlo togliere con una nuova selezione ma non lo fa e continua a produrre cpu con bug e le seleziona solo per chi si accorge di avere tale problema. E' comportamento scorretto e anche punibile per me. Spero di aver ragione io e non te;) ma forse non lo potremo mai sapere :asd:
Mister D
30-11-2017, 09:01
Quindi adesso siamo al dunque che si fa rma per una selezione migliore non per segfault. Ho capito bene ?
No, semplicemente stiamo discutendo che magari c'è correlazione tra cpu senza bug e cpu che si comportano meglio come tensioni temp. E questo lo hanno verificato in molti qui dentro. Quindi se uno ha una cpu con bug, prende la palla al balzo per farsela cambiare e ne ottiene una che oltre a non avere il bug, ha pure un comportamento migliore.
Io sostengo che è ovvio che sia così visto il cambio di test qualitativo e che quindi che sia le cpu vecchie ritestate da AMD e rimandate indietro per far fronte alle RMA, che quelle nuove e prodotte dopo una certa data, hanno un comportamento migliore oltre che a non avere il bug.
Invece Ozozuz, se ho capito bene, penso intenda dire che sono cpu estremamente selezionate solo quelle di ritorno da rma. Ripeto, se ho capito bene il suo ragionamento.;)
sinergine
30-11-2017, 09:33
Torno da adesso da un DHL Point.
Oltre al numero di account per la spedizione volevano pure la lettera di vettura altrimenti non si poteva spedire.
Ho lasciato il pacco e passo in serata, nel frattempo sentivano l'assistenza per sentie come procedere.
Relativamente alle tensioni, quale range potrebbe essere considerato mediamente "normale" per queste cpu?
nicolarush
30-11-2017, 09:47
Torno da adesso da un DHL Point.
Oltre al numero di account per la spedizione volevano pure la lettera di vettura altrimenti non si poteva spedire.
Ho lasciato il pacco e passo in serata, nel frattempo sentivano l'assistenza per sentie come procedere.
dovrebbero dartela loro da compilare e attaccare al pacco
evil weasel
30-11-2017, 09:49
Che la tensione di alimentazione salga a più di 1.4 Volt quando si attiva XFR è normale.
Debern9093
30-11-2017, 13:23
Io ribadisco che le tensioni variano anche in base alla scheda madre che si possiede.. Io ho un Asus prime b350m-k molto economica e anche con il nuovo processore tornato da rma non sono stabile al di sotto degli 1,238v su tutti i core e ribadisco che la mia CPU non ha il bug.. La scheda madre credo che gestisca molto male le tensioni
sinergine
05-12-2017, 08:58
Ho spedito il 1700 ad AMD, è stato consegnato venerdì (ritarato da MO).
Non ho avuto più notizie, non avrebbero dovuto avvisarmi via mail della ricezione della CPU?
Ho spedito il 1700 ad AMD, è stato consegnato venerdì (ritarato da MO).
Non ho avuto più notizie, non avrebbero dovuto avvisarmi via mail della ricezione della CPU?
La mail di solito parte nel momento in cui la cpu arriva al reparto che esegue il test visivo/meccanico che consente di accettare o scartare la RMA; se dovesse passare tempo ti consiglio di aprire un ticket e chiedere informazioni sullo stato della tua richiesta formendo il numero di RMA ed il tracking della spedizione che hai utilizzato per inviare; io ho fatto così e sono stati molto gentili.
sinergine
05-12-2017, 09:57
Come non detto.
Poco dopo il mio post ecco la mail di AMD:
VERIFICA/ISPEZIONE SUPERATA
Fasi successive
Quando il prodotto sarà pronto per essere spedito riceverai un'e-mail
di notifica.
Speriamo arrivi primi di Natale, anche la mail di notifica non sarebbe male per fare in modo che ci sia qualcuno a casa a ritirare il pacco; mi pare che nessuno l'abbia ricevuta però.
Come non detto.
Poco dopo il mio post ecco la mail di AMD:
VERIFICA/ISPEZIONE SUPERATA
Fasi successive
Quando il prodotto sarà pronto per essere spedito riceverai un'e-mail
di notifica.
Speriamo arrivi primi di Natale, anche la mail di notifica non sarebbe male per fare in modo che ci sia qualcuno a casa a ritirare il pacco; mi pare che nessuno l'abbia ricevuta però.
Quasi sicuramente tra oggi e domani ti spediscono il nuovo ma senza fornirti tracking, a meno che non sia tu a richiederlo :)
sinergine
05-12-2017, 17:11
Speriamo :D
ciao gente, ho compilato un paio di kernel su Arch Linux, ho usato il config del kernel stock e non ho toccato niente, difatti un sacco di roba inutile e ci ha messo un sacco di tempo.
tutto liscio, può andare come test o compilo qualcosa di più pesante?
1600 liscio
sinergine
06-12-2017, 17:49
Se vuoi essere sicuro fai il test in prima pagina.
PS:
nonostante la mail di ieri nessuna spedizione nemmeno oggi. :cry: Potrebbero aver finito le scorte un'altra volta.
PS:
nonostante la mail di ieri nessuna spedizione nemmeno oggi. :cry: Potrebbero aver finito le scorte un'altra volta.
Non è detto, di solito quando comunicano di aver fatto passare il test poi spediscono; sarà questione di poco probabilmente
A me non hanno avvisato della spedizione ma ho trovato il pacchetto a casa... :boh:
sinergine
07-12-2017, 17:44
Arrivato da RMA un 1700 1739SUS.
Domani monto e faccio test.
Non pensavo mi mandassero un altro dissipatore :sofico:
LicSqualo
08-12-2017, 08:05
Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram :cry: ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'. :ciapet:
Batch processore 1709. :mc:
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1. :sofico:
Un "golden" chip per la prima volta nella mia vita.:ciapet:
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa. :cool:
Bene, su un forum, mi hanno chiesto se ero segfault... :confused:
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via. :mbe:
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh :cry:
E siamo pure sotto le feste... :muro:
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda :).
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic
Mister D
08-12-2017, 08:33
Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram :cry: ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'. :ciapet:
Batch processore 1709. :mc:
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1. :sofico:
Un "golden" chip per la prima volta nella mia vita.:ciapet:
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa. :cool:
Bene, su un forum, mi hanno chiesto se ero segfault... :confused:
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via. :mbe:
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh :cry:
E siamo pure sotto le feste... :muro:
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda :).
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic
Ciao,
se fai RMA sicuramente ti danno una cpu esente da bug su compilazione su linux e ambienti linux su windows (WSL) e nella maggior parte dei casi una cpu che regge meglio frequenze/tensioni in oc (la maggior parte di utenti qui sopra hanno riportato di aver migliorato non di poco ricevendo la nuova cpu) però questo non toglie che come hai detto hai una probabilità (bassa) di ricevere cpu meno fortunata.
Tenuto conto di ciò io cambierei solo se nell'uso con linux compilo e in modo non saltuario, cioè se sono un programmatore e la maggior parte delle mie ore sono passate a compilare in c++ o altri linguaggi nativi di linux beh ovviamente mi conviene rischiare di beccare sì una cpu meno fortunata ma sicuramente stabile sempre.
Se invece compilo raramente posso provare quello riportato in pagina 1 e cioè:
Mitigazione del problema
Nel caso non sia possibile o non si voglia effettuare RMA sono possibili alcuni interventi per ridurre la possibilità che l'errore insorga. Nel forum di Phoronix a fine Agosto un utente ha riassunto la situazione in maniera concisa. Tradotto qui in basso:
Interventi confermati avere qualche effetto
Disabilitazione µOP cache
Sembra rimuovere il problema o renderlo molto più difficile da osservare
Disabilitazione SMT (symmetrical multithreading)
Aumenta il tempo fra un segfault all'altro da minuti ad ore
Disabilitazione funzionalità ASLR del kernel (Address Space Layout Randomization)
Simile alla precedente
Interventi che potrebbero funzionare per alcuni utenti, ma non per altri
Disabilitazione profili XMP e rilassamento clock/timing delle memorie a valori più sicuri
Abilitazione LLC (Load Line Calibration)
Aumento tensione SoC della CPU
Mister D in questo stesso thread consiglia:
Quote:
Originariamente inviato da Mister D Guarda i messaggi
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.
Alcuni utenti in questa discussione hanno avuto qualche successo aumentando la tensione di SoC a 1.2V (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (1, 2). In un altro caso, un esemplare prodotto in data 1734 (acquistato da Amazon) sembrava dare sporadici segfault ad impostazioni di default, ma impostare vSoC a 1.1V sembra avere risolto il problema. In un caso la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.
Per esempio l'utente randa71 ha riportato che solo agendo su ASLR ha eliminato il problema. Visto che è una funziona di sicurezza su linux che per es su windows è disabilitata, se funzionasse anche con te, potresti usarla qualora dovessi compilare.
Puoi disabilitare direttamente da riga di comando solo per il test di ryzen la ASLR e vedere se ti fa errore. Gli altri suggerimenti, tipo quello della LLC non te lo sto a ridire perché penso che avendola occata così bene tu abbia già trovato il modo di far droppare di meno la cpu. Per cui io ripeterei il test sotto linux con ASLR disabilitato con tutto a def (ram in auto così che usa il profilo JEDEC) e vedi il risultato. Se sparisce il problema puoi usare questo "trucco" mentre se il problema permane devi decidere te a seconda di quanto compili sotto linux e quindi capire la convenienza di mandare la cpu in RMA.;)
Spitfire84
08-12-2017, 08:54
Salve a tutti,
seguo da poco questo forum e ringrazio tutti per il supporto che offrite alla comunità.
Assemblo PC da 28 anni (i primi per curiosità li smontavo più che assemblarli, ma è sempre stato divertente ricomporli) e acquisto AMD per principio etico.
Sono giunto al Ryzen ad Aprile, acquistando su Amazon il 1700. Scheda madre Asus C6H, ram tridentZ RGB 3600c16 (cambiata due volte per problemi di CRC, molto probabilmente causati da me facendo girare programmi che scrivevano e leggevano contemporaneamente senza "semafori" i dati dai banchi ram :cry: ). Ma sono stato più fortunato ancora perché amazon mi ha dato le C16 che non aveva più le C17)
Questa volta non ho voluto risparmiare su nulla, e la fortuna mi ha seguito per un po'. :ciapet:
Batch processore 1709. :mc:
FANTASTICO. Fino a qualche giorno fa ero la persona più felice e fortunata che conosco. 4,0 Ghz a 1,32V (sotto stress con IBT AVX o OCCT) con un paio di click sul bios, fin dal giorno 1. :sofico:
Un "golden" chip per la prima volta nella mia vita.:ciapet:
Oggi giro, a 4,1 Ghz con ram a 3500 C13. I miei voltaggi sono 1,44V-1,39V per la CPU e 1,405 per la ram. Foto e info disponibili a iosa. :cool:
Bene, su un forum, mi hanno chiesto se ero segfault... :confused:
UNA TRAGEDIA. Di quelle greche con tanto pathos.
Sono venuto qui sul forum "di corsa", cercato segfault, trovato il thread. Letto con molta attenzione e prima di fare il test su Linux ho "ampliato" un po' la ricerca su siti in madre lingua inglese.
Quindi, alla fine decido di fare il test. (non descrivo lo stato di ansia nel quale sono caduto).
Primo tentativo idiotico con overclock. Bene, reset valori stock e ritento.
A 150 secondi dopo l'inizio del test la parola "segfault" sul monitor mi ha ghiacciato letteralmente lì davanti. Screenshot disponibile dal cellulare.
Sono davvero indeciso. E' un ottimo processore, a parte questo test, che mi sta dando eccezionali prestazioni su windows, senza problemi particolari.
Ma il dubbio che si è insinuato e veramente ricorrente nei miei pensieri.
Per lavoro, fatte le premesse di cui sopra, sono legato non solo a sistemi operativi Client e Server (e quindi linux rientra tra questi e lo utilizzo, anche se salturiamente, sul PC principale di casa, all'occorrenza) ma anche a compiti intensivi da parte della CPU. E questo dubbio non aiuta, anzi ostacola insinuando una probabilità in una equazione dove questa variabile deve essere ridotta al minimo se non addirittura non esistere.
Quindi la decisione è semplice RMA e via. :mbe:
E qui mi viene un altro dubbio. Riceverò un processore almeno che si avvicini a questo? E se mi toccasse invece lo sfigato? Quello pigro che si ferma a 3,9 Ghz?
Può capitare... e se così fosse sicuramente mi pentirei di aver fatto RMA e di aver lasciato un processore così parsimonioso con i consumi e così scattante con i processi. 4,1 Ghz a 1,4V è incredibile (per me), considerando che è un 1700. Eppure ci giro tutti i giorni senza errori. A parte ryzen-kill.sh :cry:
E siamo pure sotto le feste... :muro:
Qualcuno mi ha consigliato di aspettare gennaio/febbraio e di tentare il grande colpo. RMA per prendere la pìù probabilmente esente da problemi CPU zen di 1a generazione o di seconda :).
Sinceramente la mia comprensione delle CPU non è così profonda, né tantomeno la conoscenza su come sono scritti i sistemi operativi.
Ma quello che so di certo è che la mia CPU "resiste" a ore di test tortura sotto windows senza errori.
Solo questo programma (kill-ryzen su linux) genera "orrore"! (e qualche altro, ma comunque legato ad una struttura di calcolo specifica su linux e suoi derivati) e su condizioni specifiche.
Mi date qualche altro spunto serio su cui ragionare per decidere cosa fare?
(chiaramente l'RMA è dietro l'angolo che aspetta)
Grazie per la lettura.
Lic
Hai provato a dare 1,2 V al Vsoc e rifare il test? Se il problema appare comunque segui gli altri consigli di Mister D.
Ciao,
se fai RMA sicuramente ti danno una cpu esente da bug su compilazione su linux e ambienti linux su windows (WSL) e nella maggior parte dei casi una cpu che regge meglio frequenze/tensioni in oc (la maggior parte di utenti qui sopra hanno riportato di aver migliorato non di poco ricevendo la nuova cpu) però questo non toglie che come hai detto hai una probabilità (bassa) di ricevere cpu meno fortunata.
Tenuto conto di ciò io cambierei solo se nell'uso con linux compilo e in modo non saltuario, cioè se sono un programmatore e la maggior parte delle mie ore sono passate a compilare in c++ o altri linguaggi nativi di linux beh ovviamente mi conviene rischiare di beccare sì una cpu meno fortunata ma sicuramente stabile sempre.
Se invece compilo raramente posso provare quello riportato in pagina 1 e cioè:
Mitigazione del problema
Nel caso non sia possibile o non si voglia effettuare RMA sono possibili alcuni interventi per ridurre la possibilità che l'errore insorga. Nel forum di Phoronix a fine Agosto un utente ha riassunto la situazione in maniera concisa. Tradotto qui in basso:
Interventi confermati avere qualche effetto
Disabilitazione µOP cache
Sembra rimuovere il problema o renderlo molto più difficile da osservare
Disabilitazione SMT (symmetrical multithreading)
Aumenta il tempo fra un segfault all'altro da minuti ad ore
Disabilitazione funzionalità ASLR del kernel (Address Space Layout Randomization)
Simile alla precedente
Interventi che potrebbero funzionare per alcuni utenti, ma non per altri
Disabilitazione profili XMP e rilassamento clock/timing delle memorie a valori più sicuri
Abilitazione LLC (Load Line Calibration)
Aumento tensione SoC della CPU
Mister D in questo stesso thread consiglia:
Quote:
Originariamente inviato da Mister D Guarda i messaggi
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.
Alcuni utenti in questa discussione hanno avuto qualche successo aumentando la tensione di SoC a 1.2V (attenzione che questo valore potrebbe essere un pelo troppo elevato), o disabilitando l'SMT (1, 2). In un altro caso, un esemplare prodotto in data 1734 (acquistato da Amazon) sembrava dare sporadici segfault ad impostazioni di default, ma impostare vSoC a 1.1V sembra avere risolto il problema. In un caso la disabilitazione dell'ASLR da Linux sembra avere avuto effetto positivo.
Per esempio l'utente randa71 ha riportato che solo agendo su ASLR ha eliminato il problema. Visto che è una funziona di sicurezza su linux che per es su windows è disabilitata, se funzionasse anche con te, potresti usarla qualora dovessi compilare.
Puoi disabilitare direttamente da riga di comando solo per il test di ryzen la ASLR e vedere se ti fa errore. Gli altri suggerimenti, tipo quello della LLC non te lo sto a ridire perché penso che avendola occata così bene tu abbia già trovato il modo di far droppare di meno la cpu. Per cui io ripeterei il test sotto linux con ASLR disabilitato con tutto a def (ram in auto così che usa il profilo JEDEC) e vedi il risultato. Se sparisce il problema puoi usare questo "trucco" mentre se il problema permane devi decidere te a seconda di quanto compili sotto linux e quindi capire la convenienza di mandare la cpu in RMA.;)
La probabilità di ricevere cpu da RMA meno fortunate della sua non è così bassa. Ho visto 2 cpu tornare da RMA e sppure non sfigate da fare 3,8 GHz con 1,35 V erano nella media (circa 3,9 GHz con 1,32-1,33 V). Tutto dipende dal batch che si riceve...
Mister D
08-12-2017, 09:30
Hai provato a dare 1,2 V al Vsoc e rifare il test? Se il problema appare comunque segui gli altri consigli di Mister D.
La probabilità di ricevere cpu da RMA meno fortunate della sua non è così bassa. Ho visto 2 cpu tornare da RMA e sppure non sfigate da fare 3,8 GHz con 1,35 V erano nella media (circa 3,9 GHz con 1,32-1,33 V). Tutto dipende dal batch che si riceve...
Sì dipende tutto da quello che ricevi ma siccome non ho certamente numeri per fare una statistica e considerando che la sua cpu è fortunata ho espresso un giudizio qualitativo dicendo "bassa" ma può essere anche "media" la probabilità che riceva una cpu meno fortunata. Che cmq se anche dovesse essere meno fortunata e tenere solo i 4 ghz invece dei 4,1 che cosa cambierebbe? 4,1/4=1,025 cioè il +2,5% di differenza a favore dei 100 MHz in più. Se si notano e ho grossi dubbi che uno lo noti nell'uso normale. Per me la cosa più importante per decidere è capire quanto impatta il bug per il suo utilizzo. Se impatta tanto allora RMA, se impatta poco allora mi terrei una gran cpu (sono rare effettivamente quelle che tengono i 4,1).;)
LicSqualo
08-12-2017, 12:08
Grazie a tutti!
Già mi avete fatto fare un gran passo avanti. :D Su windows sono praticamente esente :ciapet: . Mi piacerebbe essere sicuro di esserlo. :mc:
Perché una macchina da dedicare a linux ce l'ho sempre. :p E se non capita nei prossimi due anni, sicuramente farò anche il passaggio a zen2, e il problema si risolve da solo, questa CPU NO LINUX.
Quindi tengo il mio prezioso "tesoro" (per me) stretto stretto. E solo con winzozz. :D
:rolleyes: Si figurati se ci riesco, se lo tengo sicuro ci faccio i test su linux, se non fosse altro per verificare se con carichi REALI e non test regge o meno.
Comunque il segfault me lo ha dato a stock... Quindi su questo sono quasi certo. Come è certo che per i prossimi 15 giorni seguirò l'evolversi della situazione sui forum.
:)
Di nuovo grazie a tutti.
lascio qualche foto (così provo anche questa funzione del sito).
:help: solo 24,4 Kb... :mbe: , Vi rimando su overclock.net, stesso nick sul thread di 1usmus (http://www.overclock.net/t/1640919/lightbox/post/26418932/id/3142257) ho postato sia foto di stabilità ram con HCI a 1000% che CPU con IBT max (4Gb).
sinergine
08-12-2017, 13:54
Sto testando il 1700 1739SUS arrivato da RMA, ho fatto due giri di kill ryzen fino al blocco del sistema per memoria satura.
Niente segfault ma ci sono errori pcieport che non avevo mai visto. :mc:
Farò ancora qualche giro di prova
Using 16 parallel processes
[KERN] -- Logs begin at Fri 2017-12-08 12:33:15 CET. --
[KERN] Dec 08 12:35:56 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00000080/00006000
[KERN] Dec 08 12:35:56 ubuntu kernel: pcieport 0000:00:01.3: [ 7] Bad DLLP
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Transmitter ID)
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00001000/00006000
[KERN] Dec 08 12:36:22 ubuntu kernel: pcieport 0000:00:01.3: [12] Replay Timer Timeout
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Transmitter ID)
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00001000/00006000
[KERN] Dec 08 12:36:57 ubuntu kernel: pcieport 0000:00:01.3: [12] Replay Timer Timeout
[loop-0] Fri Dec 8 12:37:35 CET 2017 start 0
[loop-1] Fri Dec 8 12:37:36 CET 2017 start 0
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: AER: Corrected error received: id=0000
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=000b(Receiver ID)
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: device [1022:1453] error status/mask=00000040/00006000
[KERN] Dec 08 12:37:36 ubuntu kernel: pcieport 0000:00:01.3: [ 6] Bad TLP
[loop-2] Fri Dec 8 12:37:37 CET 2017 start 0
[loop-3] Fri Dec 8 12:37:38 CET 2017 start 0
[loop-4] Fri Dec 8 12:37:39 CET 2017 start 0
[loop-5] Fri Dec 8 12:37:40 CET 2017 start 0
[loop-6] Fri Dec 8 12:37:41 CET 2017 start 0
[loop-7] Fri Dec 8 12:37:42 CET 2017 start 0
[loop-8] Fri Dec 8 12:37:43 CET 2017 start 0
[loop-9] Fri Dec 8 12:37:44 CET 2017 start 0
[loop-10] Fri Dec 8 12:37:45 CET 2017 start 0
[loop-11] Fri Dec 8 12:37:46 CET 2017 start 0
[loop-12] Fri Dec 8 12:37:47 CET 2017 start 0
[loop-13] Fri Dec 8 12:37:48 CET 2017 start 0
[loop-14] Fri Dec 8 12:37:49 CET 2017 start 0
[loop-15] Fri Dec 8 12:37:50 CET 2017 start 0
[KERN] Dec 08 13:14:50 ubuntu kernel: perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
88fabio88
08-12-2017, 16:09
che mi dite di questi screen
http://i63.tinypic.com/35k0eqb.png
http://i67.tinypic.com/2444rk2.png
http://i64.tinypic.com/2wdq9u1.png
http://i63.tinypic.com/2e5v1b7.png
http://i64.tinypic.com/6f5seo.png
sinergine
08-12-2017, 17:24
segfault da tutte le parti dopo pochi minuti.
Hai eseguito a default? Settimana CPU?
88fabio88
08-12-2017, 17:40
la settimana non la ricordo, ma tramite il seriale mi da 2017 03 08. quindi marzo . l ho preso nei primi periodi di uscita , praticamente a fine aprile
tutto a default, ho ripristinato i dati del bios a default, prima di avviare il tutto
lo mandero indietro, ma eventualmente oramai se ne parla dopo natale. non vorrei rischiare di stare un mese senza pc
invincible88
08-12-2017, 21:08
Tutto ad impostazioni di dafault dalla scheda madre, me lo da entro pochi minuti:
http://imagizer.imageshack.us/v2/150x100q90/923/iHS1hJ.jpg (http://imageshack.com/f/pniHS1hJj)
bene, ieri mi sono deciso a testare con il ryzen killer.
primo tentativo, con settaggi che tengo normalmente, cpu a default e ram settate a 3200 tramite DOCP:
https://thumb.ibb.co/cMU7jb/IMG_20171209_131804.jpg (https://ibb.co/cMU7jb)
segfault dopo una quarantina di minuti.
subito dopo riavvio, entro nel bios, riporto le ram a default, e rilancio il test:
https://thumb.ibb.co/cWCSjb/IMG_20171209_153623.jpg (https://ibb.co/cWCSjb)
nessun segfault dopo quasi 2 ore.
riprovo stamattina, direttamente con ram a default:
https://thumb.ibb.co/g1P1AG/IMG_20171210_124217.jpg (https://ibb.co/g1P1AG)
build fail e segfault come se non ci fosse un domani dopo poco :D
presumo che debba ritenermi segfaultoso, d'altronde la cpu è stata presa a fine maggio.
non so la data di produzione stampata sulla cpu, e non mi va di smontare, ma facendo il check del seriale risulta come mfg date aprile.
per ora lo tengo, ci sono le feste di mezzo, poi con l'anno nuovo faccio rma, però è una scocciatura stare senza cpu :(
sinergine
10-12-2017, 13:03
Io ho consegnato la CPU giovedì 30 novembre al service point dhl e mi è stata consegnata giovedì 7 dicembre quella nuova.
Altrimenti puoi prendere una cpu temporanea durante il reso.
Ho giusto un 1300x da mettere in vendita :sofico:
invincible88
10-12-2017, 13:13
Io ho consegnato la CPU giovedì 30 novembre al service point dhl e mi è stata consegnata giovedì 7 dicembre quella nuova.
Altrimenti puoi prendere una cpu temporanea durante il reso.
Ho giusto un 1300x da mettere in vendita :sofico:
Ciao, mi potresti dare qualche info in più riguardo al tuo reso? dove ti hanno detto di consegnare la cpu? domani gli devo mandare la mia, se i tuoi tempi coincidono dovrei averla almeno entro natale quella nuova.
a me hanno dato questo indirizzo:
AMD c/o Kuehne + Nagel
RMA# 2000244323
1 Pudongweg
Rozenburg (NH),* 1437 EM
Paesi Bassi
A quanto ho capito questo indirizzo che mi hanno dato, fa riferimento a una loro sede che si occupa della logistica AMD, ma tu quando hai scritto "ho consegnato la cpu il 30 novembre e ho ricevuto la nuova il 7 dicembre", per consegna intendi quell'indirizzo che ho ricevuto io? o poi da quell'indirizzo dobbiamo attendere che glieli mandano in fabricare AMD? che non credo sia in uniore europea xD
PS: Ti hanno inviato una CPU nuova con scatolo?
Grazie
sinergine
10-12-2017, 13:28
Metti la CPU nel blister di plastica originale e la imballi per bene, nel pacco metti un foglio con il tuo indirizzo e il numero di RMA.
Sul pacco incolli un foglio con il tuo indirizzo, l'indirizzo che ti hanno dato e il numero di RMA.
Cerchi un punto DHL a cui consegnare il pacco https://locator.dhl.com/ServicePointLocator/index.jsp
Ti rechi li con il pacco e la mail di AMD dove c'è il numero account prepagato. La lettera di vettura l'hanno loro.
In 1/2 giorno il pacco ad arriva ad AMD.
In 1/2 giorni di rispondono se hanno accettato l'RMA.
In 1/2 giorni ti spediscono una CPU nuova imballata con eventuale dissipatore se è previsto. Qui non mi hanno comunicato nulla.
In 1/2 giorni ti arriva a casa.
Non le mandano in fabbrica, le verificano in Olanda e te ne spediscono un'altra.
Qualcuno ha aspettato di più perché avevano finito le scorte.
invincible88
10-12-2017, 13:47
Metti la CPU nel blister di plastica originale e la imballi per bene, nel pacco metti un foglio con il tuo indirizzo e il numero di RMA.
Sul pacco incolli un foglio con il tuo indirizzo, l'indirizzo che ti hanno dato e il numero di RMA.
Cerchi un punto DHL a cui consegnare il pacco https://locator.dhl.com/ServicePointLocator/index.jsp
Ti rechi li con il pacco e la mail di AMD dove c'è il numero account prepagato. La lettera di vettura l'hanno loro.
In 1/2 giorno il pacco ad arriva ad AMD.
In 1/2 giorni di rispondono se hanno accettato l'RMA.
In 1/2 giorni ti spediscono una CPU nuova imballata con eventuale dissipatore se è previsto. Qui non mi hanno comunicato nulla.
In 1/2 giorni ti arriva a casa.
Non le mandano in fabbrica, le verificano in Olanda e te ne spediscono un'altra.
Qualcuno ha aspettato di più perché avevano finito le scorte.
Tutto chiaro e preciso, ma per quanto riguarda l'account prepagato nell'email ricevuta non se ne parla...credo sarà a spese mie...grazie mille per la risposta.
sinergine
10-12-2017, 14:47
Perché a spese tue scusa? Se pagano loro la spedizione conviene approfittarne
invincible88
10-12-2017, 14:54
Perché a spese tue scusa? Se pagano loro la spedizione conviene approfittarne
No nel senso che nell'email da me ricevuta, non mi hanno parlato di conto prepagato, mi hanno solo consigliato di spedire o con dhl, federal o ups, dunque deduco che si tratti di spedire a spese mie.
Poi non saprei!
anni fà feci un rma con AMD, cpu morta in seguito a svampamento mobo, mi pare fosse un Phenom 9850.
la cpu morta la spedii a spese mie, ma dato che volevano la sola cpu, misi il blister di plastica arrotolato con un pò di pluriball, in una busta gialla imbottita, raccomandata internazionale (olanda ovviamente), intorno a 5 e in 3 giorni è arrivato sano e salvo
Io ho consegnato la CPU giovedì 30 novembre al service point dhl e mi è stata consegnata giovedì 7 dicembre quella nuova.
Altrimenti puoi prendere una cpu temporanea durante il reso.
Ho giusto un 1300x da mettere in vendita :sofico:
grazie ma nel caso prendo la cpu AM4 più economica possibile, tipo un Athlon X4 950, sulla cinquantina su amazon :D
ciao a tutti
ho un Ryzen 5 1600 .... ua 1737pgs malesia
potrebbe essere affetto dal bug ?
sinergine
10-12-2017, 17:51
Probabilmente no ma devi fare il test per essere sicuro
fabius21
11-12-2017, 14:30
Ho fatto bene ad aspettare , per via dei prezzi delle ram, visto che utilizzo di sopratutto gentoo :muro:
invincible88
12-12-2017, 17:19
Ieri ho spedito la cpu ad amd in Olanda con Ups, utilizzando il servizio più rapido, che prevede la consegna entro domani, al modico prezzo di 40 euro!
Alla faccia...ma se tutto va bene la prossima settimana potrei avere una cpu senza bug.
Speriamo...
Ieri ho spedito la cpu ad amd in Olanda con Ups, utilizzando il servizio più rapido, che prevede la consegna entro domani, al modico prezzo di 40 euro!
Alla faccia...ma se tutto va bene la prossima settimana potrei avere una cpu senza bug.
Speriamo...
Ma sei proprio sicuro che non ti abbiano offerto la spedizione prepagata? La stanno dando a tutti. All'inizio anche io pensavo di non averla, poi ho letto più attentamente un trafiletto su una delle mail e c'era indicato il numero di account da utilizzare.
nicolarush
13-12-2017, 16:02
Ma sei proprio sicuro che non ti abbiano offerto la spedizione prepagata? La stanno dando a tutti. All'inizio anche io pensavo di non averla, poi ho letto più attentamente un trafiletto su una delle mail e c'era indicato il numero di account da utilizzare.
a me l'email era finita nello spam :mc:
invincible88
13-12-2017, 16:03
Ma sei proprio sicuro che non ti abbiano offerto la spedizione prepagata? La stanno dando a tutti. All'inizio anche io pensavo di non averla, poi ho letto più attentamente un trafiletto su una delle mail e c'era indicato il numero di account da utilizzare.
Ho appena riletto tutte le comunicazioni e non ho trovato nulla riguardo all'account prepagato!
Ad ogni modo mi hanno risposto di aver ricevuto la cpu che ha superato l'ispezione...speriamo che entro venerdì spediscono quella nuova.
Ho appena riletto tutte le comunicazioni e non ho trovato nulla riguardo all'account prepagato!
Ad ogni modo mi hanno risposto di aver ricevuto la cpu che ha superato l'ispezione...speriamo che entro venerdì spediscono quella nuova.
Io avrei chiesto all'assistenza prima di spendere così tanto, comunque ormai è fatta, entro la prossima settimana, se hai compilato tutto correttamente, dovresti ricevere la nuova cpu.
88fabio88
14-12-2017, 22:34
Lunedì ho spedito la CPU con DHL, poiché a me avevano mandato anche la mail per mandare indietro la CPU a loro spese. Ora sto avendo problemi con la spedizione con DHL....
Come mi posso comportare in questo caso oltre che aspettare? Scrivere ad amd?
Tortellone
15-12-2017, 09:40
Lunedì ho spedito la CPU con DHL, poiché a me avevano mandato anche la mail per mandare indietro la CPU a loro spese. Ora sto avendo problemi con la spedizione con DHL....
Come mi posso comportare in questo caso oltre che aspettare? Scrivere ad amd?
Che ti aspetti sotto Natale ?
Amazon monopolizza tutti i corrieri :sofico:
invincible88
16-12-2017, 19:38
Oggi ho ricevuto la nuova CPU!!!! finalmente!!! e adesso che ho rilevato dove stavano i miei bug credo di aver terminato questa Build tanto combattuta!!
Comunque assistenza AMD top, vecchia CPU recapitata a loro Mercoledì, nuova CPU arrivata oggi dopo pranzo, tra l'altro inaspettato! bellissima sorpresa devo dire :D
elmakiko
20-12-2017, 17:31
Salve,ho appena preso un preassemblato con ryzen 1700,sicuramente come data di produzione sarà molto "giovane" e visto che utilizzerei solo windows,consigliate di fare il test?se affetto dal problema potrei avere qualche problema sotto carico?
Grazie.
88fabio88
22-12-2017, 11:05
Che ti aspetti sotto Natale ?
Amazon monopolizza tutti i corrieri :sofico:
il problema non era amazon o la troppa mole di lavoro, il problema è stata una errata compilazione del ddt da parte del dhl point, il che mi ha fatto bloccare la spedizione. la spedizione l'ho consegnata a dhl lunedi pomeriggio, ma è fisicamente partita venerdi pomeriggio/notte da roma. lunedi è stata consegnata ad amd, martedi è stata spedita la nuova cpu, 37 settimana, imballata completa di dissipatore e sigillo chiuso, e mercoledi mattina è arrivata.
come frequenze questa va decisamente meglio.
prima a 1,33 stavo a 3,9 e i 4 erano un miraggio.
ora con lo stesso voltaggio sto a 4 (e forse posso anche scendere) con l'ultimo bios 3008 della ch6
posso ritenermi soddisfatto
sapete se anche i ryzen 5 , nello specifico i 1600X può essere soggetto a tale problema o ne sono affetti solo i ryzen 7?
Tutte le varianti possono essere affette, solo i Threadripper dovrebbero essere garantiti.
Fino a quale settimana di produzione poi il problema si verifica sui Ryzen non è chiaro.
Mr.Lollo14
24-12-2017, 11:40
ricevuto da tao un 1700 della 40esima settimana.
sto facendo il test ma dopo 30 min siamo al loop 15..attendo almeno 1 ora..
in caso fallisca lo segnala, ok.
ma nel caso non fallisca come dovrebbe essere il terminale dopo loop 15?
sinergine
24-12-2017, 12:24
Non segnala niente.
Ad un certo punto si blocca il pc perché satura la ram. (se lo stai facendo con la live di ubuntu)
Mr.Lollo14
24-12-2017, 12:27
Ahahaha e io che mi sono pure scocciato che si era bloccato il pc!
Lo rifaccio ancora una volta per sicurezza a scanso di equivoci..
Grazie per la dritta!!
elmakiko
24-12-2017, 12:42
Salve,ho appena preso un preassemblato con ryzen 1700,sicuramente come data di produzione sarà molto "giovane" e visto che utilizzerei solo windows,consigliate di fare il test?se affetto dal problema potrei avere qualche problema sotto carico?
Grazie.
Qualche consiglio?grazie.
Mr.Lollo14
24-12-2017, 13:15
Leggi la prima pagina del post..
C'è scritto che pur non compilando in linux potresti incorrere in errori.
Detto ciò sta a te la scelta.
Ciao!
Mr.Lollo14
24-12-2017, 13:42
Posso ritenermi esente?
:confused:
https://thumb.ibb.co/iVGPX6/IMG_3274.jpg (https://ibb.co/iVGPX6)
Mr.Lollo14
25-12-2017, 21:15
Posso ritenermi esente?
:confused:
https://thumb.ibb.co/iVGPX6/IMG_3274.jpg (https://ibb.co/iVGPX6)
uppettino:D
uppettino:D
Direi di si, non c'è traccia di segfault, e oltre 70' son sufficienti.... se doveva uscire l'errore sarebbe uscito!
Mr.Lollo14
26-12-2017, 00:06
perfettissimo, grazie
gino123456
28-12-2017, 10:53
https://ibb.co/g2tyWb
https://ibb.co/g2tyWb
test fato con ubunto 17.10 e impostato lo script con meno di 16 gb di ram
sembra tutto ok giusto
sinergine
28-12-2017, 11:02
C'è un invalid opcode che potrebbe segnalare qualche problema.
Vedo solo i loop dallo 0 al 3 ma dovrebbero essere dallo 0 al 11 visto che il 1600X ha 12 unità di elaborazione.
Prova il test a default. Quando la RAM è quasi piena riavvia e riprova. Dopo 3-4 giri senza errori puoi stare tranquillo.
Settimana della CPU?
gino123456
28-12-2017, 14:55
C'è un invalid opcode che potrebbe segnalare qualche problema.
Vedo solo i loop dallo 0 al 3 ma dovrebbero essere dallo 0 al 11 visto che il 1600X ha 12 unità di elaborazione.
Prova il test a default. Quando la RAM è quasi piena riavvia e riprova. Dopo 3-4 giri senza errori puoi stare tranquillo.
Settimana della CPU?
domani smonto e vedo al settimana della cpu
come lo capisco quando è piena ? tempi ?
ora l'ho fatto girare per ore ed non si è più ripreso
sinergine
28-12-2017, 15:48
Deci aprire il system monitor per vedere la RAM. Se hai 16gb dovrebbe colerci poco più di un'ora credo.
Cosa intendi per non siè più ripreso? Se lo lasci girare quando la ram è piena il sistema si blocca e devi riavviarlo forzatamente.
Mentre fai il test puoi disattivare lo spegnimento delle schermo altrimenti se si blocca con lo schermo spento non vedi i messaggi a video quand il pc si blocca
gino123456
28-12-2017, 16:05
Deci aprire il system monitor per vedere la RAM. Se hai 16gb dovrebbe colerci poco più di un'ora credo.
Cosa intendi per non siè più ripreso? Se lo lasci girare quando la ram è piena il sistema si blocca e devi riavviarlo forzatamente.
Mentre fai il test puoi disattivare lo spegnimento delle schermo altrimenti se si blocca con lo schermo spento non vedi i messaggi a video quand il pc si blocca
...esatto non ho disattivato lo spegnimento delle schermo e quindi dopo ore tutto ko
cmq fatto un test su 1 ora
e tutto ok
https://ibb.co/n5211b
https://ibb.co/n5211b
qui tutto ok giusto ?
ora ne provo un altro paio
sinergine
28-12-2017, 17:27
Sì così è a ok
Mr.Lollo14
28-12-2017, 17:49
le ultime stringhe sono differenti dal mio postato qualche messaggio fa, mi devo preoccupare?
gino123456
28-12-2017, 23:53
Sì così è a ok
il secondo di un ora tutto ok
il 3 invece
https://ibb.co/hWTHsG
https://ibb.co/hWTHsG
:muro: è questo l'errore giusto ?devo cambiare la cpu se voglio levarmi questo problema ?
domani smonto e vedo la data
sinergine
29-12-2017, 08:16
Sì l'errore è proprio quello. Hai fatto tutto a default giusto?
Senza smontare tutto in prima pagina dovrebbe esserci un link per verificare la settimana di produzione partendo dal seriale.
Per sistemare devi fartela sostituire.
gino123456
29-12-2017, 14:56
Sì l'errore è proprio quello. Hai fatto tutto a default giusto?
Senza smontare tutto in prima pagina dovrebbe esserci un link per verificare la settimana di produzione partendo dal seriale.
Per sistemare devi fartela sostituire.
data 1724
ma porca devo trovare il link per rma amd
Mr.Lollo14
29-12-2017, 20:14
Per sicurezza ho rifatto il test anche al mio, ne avevo fatti 2, ne faccio altri per sicurezza, anche se ogni volta devo aspettare più di un ora..:doh:
Mr.Lollo14
30-12-2017, 08:47
rifatto il test altre 4 volte tra ieri e oggi (per un totale di 7-8 volte dall'acquisto) processore con data 1740 ricevuto da tao prima di natale.
il 3° test durante tutta la notte, mi sono svegliato stamattina con schermo nero e anche muovendo mouse-tastiera non ritorna alla schermata di ubuntu quindi presumo che sia andato a saturare 100% dei 16gb di ram e per questo non vedo nulla.
4° test stamattina, cercando di non far spegnere il monitor e arrivo fino a qui:
https://thumb.ibb.co/h3Mzrb/IMG_3304.jpg (https://ibb.co/h3Mzrb) https://thumb.ibb.co/joDerb/IMG_3305.jpg (https://ibb.co/joDerb)
Mi considero esente dal problema a meno che qualcuno di voi smentisca.
dopo aver atteso un mese per completare il pc, mi sarebbe mancato solo di dover rimandare la cpu indietro :)
LicSqualo
12-01-2018, 19:00
:D
CPU consegnata stasera da DHL. Ho richiesto l'RMA avanzato ma mi hanno risposto (gentilissimi!!!!) che potevano solo anticipare la partenza del processore non appena davo tracking number della spedizione.
Quindi lunedì pomeriggio ho spedito il mio processore in Olanda, che BRT ha consegnato solo stamattina :doh: .
Ma l'assistenza di AMD è stata fantastica. Me lo hanno rispedito ieri pomeriggio dall'Olanda ed è arrivato qui in Abruzzo oggi alle 17.00. 24 ore. FANTASTICO.
Purtroppo appena montato la CPU sulla mia Asus C6H ho aggiornato il bios all'ultima versione 3501 e non posso più overcloccare con PState.:muro:
Quindi dopo disperati tentativi tutti a vuoto :muro: :muro: :muro: (addirittura ho fatto girare il processore a stock!!!! :mbe: ) mi sono rassegnato e ho impostato (mai fatto prima) un sano profilo 4 ghz :fagiano: . Perfetto:confused: , partito senza problemi con voltaggio di 1,37 su bios e 1,31V con IBT AVX sotto carico :sofico:, mi aspettano giorni gloriosi!
Grazie ancora AMD. UN GRANDE GRAZIE a chi mi ha seguito ed ha iniziato questo thread, che è stata la mia guida. Licinio :D
gino123456
15-01-2018, 14:17
rma fatto spedizione mia lunedì e giovedì avevo già la cpu nuova
grazie a tutti
ora devo trovare una guida per provare overclock
Salve.
Ho fatto da poco questa bella "scoperta", visto che mi scoccia abbastanza, aver dato soldi buoni per una CPU forse fallata, ho provato a fare il test da live di Ubuntu, come detto in prima pagina.
Facendo il test sono venuti fuori questi risultati, per me indecifrabili.
https://ibb.co/cAMGu6
https://ibb.co/jZ2d7R
https://ibb.co/nadCZ6
Chiedo aiuto per capire il problema ed aver un risultato meno criptico.
Possiedo un ryzen 5 1600, acquistato dopo un mese e mezzo circa dal lancio, main Asus 370 prime pro e 16 giga di ram settati a 1333 mhz per fare sto benedetto test. (prima erano settate a 2933 e il risultato era il medesimo).
Ringrazio anticipatamente chi mi aiuterà.
sinergine
16-01-2018, 14:20
Il test da fare è questo:
https://www.hwupgrade.it/forum/showpost.php?p=45108749&postcount=146
Sembrano errori di configurazione quelli che vedo
kernelex
09-02-2018, 19:32
comprare una cpu in questi gg ci vuole fortuna o è un problema superato?
considerando che uso anche linux e di compilazione ne farei a millemila miliardi di righe
sgrinfia
09-02-2018, 20:40
comprare una cpu in questi gg ci vuole fortuna o è un problema superato?
considerando che uso anche linux e di compilazione ne farei a millemila miliardi di righe
Oramai superato......;)
kernelex
09-02-2018, 20:42
Oramai superato......;)
meno male, proprio domani dovrei acquistare
valeriocd
10-02-2018, 11:47
salve, ho effettuato il test su linux 17.10
per non riscontrare l' errore ho disabilitato smp e ram 2133, non so provo a rimetterle a 3200 e vedere se mi da errore.
Il mio processore è dell' 8ttava settimana.
Mi conviene inviarlo in rma?
newtechnology
10-02-2018, 14:06
salve, ho effettuato il test su linux 17.10
per non riscontrare l' errore ho disabilitato smp e ram 2133, non so provo a rimetterle a 3200 e vedere se mi da errore.
Il mio processore è dell' 8ttava settimana.
Mi conviene inviarlo in rma?
Se non riscontri errori con i parametri a default dubito che te lo cambino.
Non tutti sono buggati , io ho un 1800x della 22 settimana che passa tranquillamente il test con ram a 2666 MHz , altri invece no , ho testato anche un 1700 della 20 settimana che ok.
Certo i miei non danno errore con smp abilitato e ram settate in auto , certificate per ryzen a 2666 MHz
Salve ragazzi,
voglio segnalarvi una cosa interessante.
Ho comprato il processore Ryzen 7 1800X sull'amazzone tedesca e con mia grande delusione ieri mi è arrivato con questa sigla:
UA1718SUT
Sarebbe quindi della 18a settimana del 2017.
Veramente un fondo di magazzino.
Ho imprecato turco ma ho avuto una bella sorpresa: non è affetto dal segfault!
Ho fatto girare il test kill-ryzen-win per 2 volte:
. prima volta per 30 minuti
. seconda volta 65 minuti
Ho seguito nel dettaglio tutto quello che c'è scritto qui:
https://www.hwupgrade.it/forum/showpost.php?p=45125200&postcount=502
La mia configurazione è la seguente:
. scheda madre Asus Prime B-350 Plus;
. processore Ryzen 7 1800X;
. RAM Corsair CMK16GX4M2B3000C15 Vengeance LPX, Kit da 16 GB, 2 x 8 GB, DDR4, 3000 MHz (la ram gira a 2933 Mhz);
. SSD M.2 NVMe Samsung 960 PRO da 512 GB;
. Windows 10 Pro x64 (versione 1709)
sgrinfia
20-02-2018, 20:34
Salve ragazzi,
voglio segnalarvi una cosa interessante.
Ho comprato il processore Ryzen 7 1800X sull'amazzone tedesca e con mia grande delusione ieri mi è arrivato con questa sigla:
UA1718SUT
Sarebbe quindi della 18a settimana del 2017.
Veramente un fondo di magazzino.
Ho imprecato turco ma ho avuto una bella sorpresa: non è affetto dal segfault!
Ho fatto girare il test kill-ryzen-win per 2 volte:
. prima volta per 30 minuti
. seconda volta 65 minuti
Ho seguito nel dettaglio tutto quello che c'è scritto qui:
https://www.hwupgrade.it/forum/showpost.php?p=45125200&postcount=502
La mia configurazione è la seguente:
. scheda madre Asus Prime B-350 Plus;
. processore Ryzen 7 1800X;
. RAM Corsair CMK16GX4M2B3000C15 Vengeance LPX, Kit da 16 GB, 2 x 8 GB, DDR4, 3000 MHz (la ram gira a 2933 Mhz);
. SSD M.2 NVMe Samsung 960 PRO da 512 GB;
. Windows 10 Pro x64 (versione 1709)
Se hai provato due volte il test e lai passato , allora e ok.;)
Se hai provato due volte il test e lai passato , allora e ok.;)
Ok, allora sono salvo, grazie!
Mikkinen
24-02-2018, 08:32
Ciao a tutti, qualcuno che ha sostituito la cpu ha trovato anche più stabilità con le ram hynix oltre i 3000mhz?
Grazie.
Fabio1987
28-02-2018, 15:04
Ciao raga, ho startato ubuntu 17.04 in live ed ho eseguito la procedura come da programma (download del pacchetto per ubunri 17.04, apertura del terminale dalla cartella del pacchetto ed infine lancio del comando ./kill-ryzen.sh
Purtroppo mi sa che qualcosa non va in quanto ottengo questa schermata, idee?
Ps stessa medesima cosa con ubuntu live 17.10 ed apposito script :/https://uploads.tapatalk-cdn.com/20180228/fcb0ebe0313956afe097cc507d79066b.jpg
Inviato dal mio ONEPLUS A3010 utilizzando Tapatalk
valeriocd
01-03-2018, 10:33
arrivata nuova cpu da rma , oggi pomeriggio eseguo test a default e vediamo
Fabio1987
01-03-2018, 13:55
Ho rifatto il test varie volte, ecco l'ultimo screen:
ovviamente bios default ed ubuntu live
https://uploads.tapatalk-cdn.com/20180301/8c6e693c90958ce2fcb1f80bc18a306f.jpg
Inviato dal mio ONEPLUS A3010 utilizzando Tapatalk
sinergine
01-03-2018, 15:05
invalid opcode significa problemi di segfault.
Prova magari a fare il test altre volte ma dovrebbe essere buggata.
Settimana della cpu?
Nel primo screen non c'era niente di anomalo, ma nel secondo sì, invalid opcode è sintomo del bug.
Fabio1987
01-03-2018, 23:50
invalid opcode significa problemi di segfault.
Prova magari a fare il test altre volte ma dovrebbe essere buggata.
Settimana della cpu?
Guarda non ho avuto modo (tempo e voglia) di staccare il wb per vedere la settimana, tra l'altro dal sito non ricavo nulla inserendo il mio seriale, ma penso che avendo comprato la cpu il 18/4/17 possa essere tranquillamente tra i primi lotti in commercio... adesso riprovo il test comunque
EDIT: ho rifatto il test, continua a dare opcode ip error. Bastano questi screen per l'rma eventualmente? :o
https://uploads.tapatalk-cdn.com/20180302/4165f3b65e25a08fae20b804e6aaefd4.jpg
A me non è stato richiesto alcuno screen, però per fare l'RMA devi fornire il seriale della CPU, quindi o hai la scatola o altrimenti devi smontare il dissipatore per leggerlo.
Fabio1987
02-03-2018, 08:44
A me non è stato richiesto alcuno screen, però per fare l'RMA devi fornire il seriale della CPU, quindi o hai la scatola o altrimenti devi smontare il dissipatore per leggerlo.Sisi ho la scatola, semplicemente dal seriale non riesco a risalire alla settimana della cpu
EDIT: ho compilato il modulo per l'rma, attendiamo e vediamo che mi dicono ;)
Inviato dal mio ONEPLUS A3010 utilizzando Tapatalk
Fabio1987
02-03-2018, 18:50
A me non è stato richiesto alcuno screen, però per fare l'RMA devi fornire il seriale della CPU, quindi o hai la scatola o altrimenti devi smontare il dissipatore per leggerlo.
Dopo quanto tempo ti hanno risposto? io ho inviato il ticket rma oggi pomeriggio e non ho avuto risposta (precompilate a parte)
Mi pare un giorno, forse due.
kernelex
13-03-2018, 23:02
in quale parte della scatola si trova il seriale della cpu?
Sull'etichetta bianca posta sullo spigolo per sigillarla, quella con il codice a barre, appena sotto il codice a barre.
kernelex
14-03-2018, 08:28
Sull'etichetta bianca posta sullo spigolo per sigillarla, quella con il codice a barre, appena sotto il codice a barre.
perfetto, grazie.
sulla confezione ci sono millemila serie di codici.
https://imgur.com/a/9l88K
bartolino3200
17-03-2018, 19:31
se mando il seriale senza fare test loro lo sanno a priori o mi richiedono il test?
bartolino3200
17-03-2018, 22:05
Mi sa che il mio test non è nemmeno partito. cosa ho sbagliato?
https://preview.ibb.co/e0a7ec/2018_03_17_21_27_18.jpg (https://ibb.co/mKP0zc)
picture hosting (https://it.imgbb.com/)
Fabio1987
21-03-2018, 12:49
Aggiornamento sulla mia situazione:
Dopo aver contattato l'assistenza AMD ed aver atteso un paio di giorni sono stato ricontattato e mi è stato offerto di inviare la cpu a loro spese tramite DHL express. Per motivi personali ho potuto spedire la cpu solo qualche settimana dopo (venerdì 16/3) ed ho inviato il tracking del pacchetto tramite mail.
Il pacco è arrivato in olanda lunedì e sorpresa delle sorprese oggi ho ricevuto un pacco dhl con dentro il procio box nuovo, sigillato con tanto di dissipatore.
Ricapitolando: pacco inviato venerdì 16/03 e pacco ricevuto il 21/03.... se non è efficienza questa ditemi voi ;)
PS: la cpu nuova è della 38°settimana, devo ancora montarla per testarla ma non credo ci saranno problemi.
PPS: la garanzia del nuovo processore segue la scadenza della vecchia cpu? oppure la data viene aggiornata? grazie in anticipo
Fabio
PPS: la garanzia del nuovo processore segue la scadenza della vecchia cpu? oppure la data viene aggiornata? grazie in anticipo
Fabio
Quasi sicuramente non segue la scadenza della vecchia cpu ma quella della consegna recente, almeno cosi ricordo per il telefono cellulare NEXUS garanzia google.
PS Qualcuno può postare link per verifica seriale cpu dalla scatola e foto dove rilevare il numero grazie
:confused: Essendo la cpu ryzen 1700, acquistata 16.3.2017 da e....rice, secondo voi posso fare rma direttamente a e...rice solo per la produzione o mi conviene da AMD che già conoscono se la cpu ha il problema?
Non sono pratico per verificare se ha il problema oppure no e mi vorrei basare solo sulla produzione, è possibile?
Mister D
07-04-2018, 13:45
Quasi sicuramente non segue la scadenza della vecchia cpu ma quella della consegna recente, almeno cosi ricordo per il telefono cellulare NEXUS garanzia google.
PS Qualcuno può postare link per verifica seriale cpu dalla scatola e foto dove rilevare il numero grazie
:confused: Essendo la cpu ryzen 1700, acquistata 16.3.2017 da e....rice, secondo voi posso fare rma direttamente a e...rice solo per la produzione o mi conviene da AMD che già conoscono se la cpu ha il problema?
Non sono pratico per verificare se ha il problema oppure no e mi vorrei basare solo sulla produzione, è possibile?
No, non è possibile saperlo solo dalla data perché:
1) AMD non ha mai chiarito da quale data ufficialmente ha cambiato il test di qualità che permette di eliminare il problema.
2) una parte piccola di cpu prodotte PRIMA del cambio test da parte di AMD, SONO ESENTI da problema (e qua alcuni utenti lo hanno riportato chiaramente).
Per cui potresti beccare anche una cpu che non ha il problema (bassa probabilità) come beccare una cpu che ha il problema (alta probabilità).
Segui le istruzioni riportate in pagina 1 per verificare il problema. Se ti sembra troppo difficile, allora fatti una domanda: USI la cpu in linux (o in ambienti linux virtualizzati su windows o sulla parte di windows 10 con kernel linux) per programmare???? Se la risposta è NO, te ne puoi fregare e usarla senza problemi in windows per tutte le altre attività, in quanto questo bug di segfualt viene fuori solo programmando e compilando codice in ambiente linux (e qua è anche AMD ad averlo dichiarato a Phoronix o come cavolo si chiama).
No, non è possibile saperlo solo dalla data perché:
1) AMD non ha mai chiarito da quale data ufficialmente ha cambiato il test di qualità che permette di eliminare il problema.
2) una parte piccola di cpu prodotte PRIMA del cambio test da parte di AMD, SONO ESENTI da problema (e qua alcuni utenti lo hanno riportato chiaramente).
Per cui potresti beccare anche una cpu che non ha il problema (bassa probabilità) come beccare una cpu che ha il problema (alta probabilità).
Segui le istruzioni riportate in pagina 1 per verificare il problema. Se ti sembra troppo difficile, allora fatti una domanda: USI la cpu in linux (o in ambienti linux virtualizzati su windows o sulla parte di windows 10 con kernel linux) per programmare???? Se la risposta è NO, te ne puoi fregare e usarla senza problemi in windows per tutte le altre attività, in quanto questo bug di segfualt viene fuori solo programmando e compilando codice in ambiente linux (e qua è anche AMD ad averlo dichiarato a Phoronix o come cavolo si chiama).
Un sentito ringraziamento per la sintesi e la tua chiarezza ;)
Ieri ho mandato in rma il mio 1800x, senza nemmeno provarlo. Era 1710 (quindi che settimana bho?)
Rma accettata, dovrebbe arrivare a loro lunedì.
Più che altro l'ho fatto per una futura vendita.
Viper_80
13-04-2018, 08:42
Ieri ho mandato in rma il mio 1800x, senza nemmeno provarlo. Era 1710 (quindi che settimana bho?)
Rma accettata, dovrebbe arrivare a loro lunedì.
Più che altro l'ho fatto per una futura vendita.
1710= 17 anno 10 settimana
Quando tempo passa dalla ricezione del processore al controllo v/m?
E arrivato verso le 11, ancora niente email.
🤔
walter.caorle
19-04-2018, 04:29
Presente..:)
Preso al day one ed ora con lo scopo di venderlo a breve, ho fatto 3 volte il test. tutto @default e memoria a 2133...segfault error in tutti i casi.
MFG Date: 2017-02-22
Qualcuno si è rivolto direttamente ad Amazon???
Dopo quanti giorni arriva il processore dopo aver superato il test?
Più o meno...
Nel mio caso spedito al giovedì mattina, tornato sostituito al martedì!
Arrivata nuova cpu venerdì.
1737. Pensavo meglio.
Proverò a vedere se va meglio dell'altro.
Operapia
17-10-2018, 11:17
Buon giorno,
riuppo questa discussione perchè mi serve un chiarimento.
Ho fatto richiesta di rma riguardo il procio ed AMD l'ha accettata.
Nelle mail mi spiegava che la spedizione era pagata da loro
ed a tale proposito mi davano un account da esibire allo
spedizioniere autorizzato da DHL. E niente, io gli do 'sto numero
e lui dice che non gli risulta nulla. Ergo gli dovrei sganciare 50 euro.
Voi che esperienza avete avuto con la spedizione in RMA?
Perchè su reddit alcuni hanno dovuto ricontattare AMD e farsi mandare un link,
altri hanno usato solo quel numero.
Dall'Italia come funge?
nicolarush
17-10-2018, 11:47
Buon giorno,
riuppo questa discussione perchè mi serve un chiarimento.
Ho fatto richiesta di rma riguardo il procio ed AMD l'ha accettata.
Nelle mail mi spiegava che la spedizione era pagata da loro
ed a tale proposito mi davano un account da esibire allo
spedizioniere autorizzato da DHL. E niente, io gli do 'sto numero
e lui dice che non gli risulta nulla. Ergo gli dovrei sganciare 50 euro.
Voi che esperienza avete avuto con la spedizione in RMA?
Perchè su reddit alcuni hanno dovuto ricontattare AMD e farsi mandare un link,
altri hanno usato solo quel numero.
Dall'Italia come funge?
a me è bastato l'account che mi hanno dato :O
prova a cambiare dhl point
Operapia
17-10-2018, 16:23
a me è bastato l'account che mi hanno dato :O
prova a cambiare dhl point
Ok grazie, vedo di trovarne un altro. Online nessuno ha sbrigato questa pratica? Telefonicamente è un furto a mano armata purtroppo.
nicolarush
17-10-2018, 16:41
Ok grazie, vedo di trovarne un altro. Online nessuno ha sbrigato questa pratica? Telefonicamente è un furto a mano armata purtroppo.
ricordo che qualcuno aveva chiamato il numero verde
mi pare anche che on line si poteva fare la lettera di vettura e prenotare il ritiro
edit mi correggo il numero a pagamento (un 199)
Buongiorno, ho seguito con interesse la discussiine, essendo in procinto di acquistare un nuovo PC equipaggiato con Epyc, vorrei sapere se anche questi processori destinati ai server sono afflitti dal problema in argomento.
Grazie
nicolarush
22-10-2018, 18:30
Buongiorno, ho seguito con interesse la discussiine, essendo in procinto di acquistare un nuovo PC equipaggiato con Epyc, vorrei sapere se anche questi processori destinati ai server sono afflitti dal problema in argomento.
Grazie
no
il problema ha riguardato solo alcuni esemplari di ryzen 1xxx
poi amd ha risolto
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.