Link alla notizia: http://www.hwupgrade.it/news/cpu/un-bug-per-ryzen-in-abbinamento-a-linux-ma-amd-e-al-lavoro_70430.html

In particolari condizioni di forte stress test con sistema operativo Linux i processori Ryzen, ma non quelli Ryzen Threadripper e EPYC, manifestano un potenziale malfunzionamento

Click sul link per visualizzare la notizia.

In particolari condizioni di forte stress test con sistema operativo Linux i processori Ryzen, ma non quelli Ryzen Threadripper e EPYC, manifestano un potenziale malfunzionamento


E' il motivo per il quale mi sono astenuto dal giudicare Ryzen fino ad ora.
E' ancora troppo presto. :O

Io lo faccio... La compilazione in parallelo e' il mio pane quotidiano e sono un utente, quindi dipende da cosa si intende per utente.

Per me un utente e' chi usa il computer. Se uno i programmi li usa o li crea e' un dettaglio, a mio avviso, e sono consapevole del fatto che chi crea i programmi (ed ha bisogno di compilazioni parallele) e' una minoranza, ma una minoranza non trascurabile. Se ho un baco in una compilazione poi me lo porto dietro nel programma che deve essere distribuito (a parte che compili, che non sembra essere questo il caso).

...da sperare che sia correggibile con semplice aggiornamento di microcodice (in grado di contenere comunque un numero limitato di microistruzioni) altrimenti revisione dell'insieme di fotomaschere.
E dato che interessa il multithreading simultaneo noto presso Intel come HyperThreading potrebbe manifestarsi anche durante l'utilizzo base del s.o ormai multithreading massivamente.
Tecnicamente quello del processore non è un firmware ma un microcodice usato per le macroistruzioni che secondo la vecchia tassonomia Pentium Pro non si traducono in un certo numero (in P6 4) massimo di microistruzioni.

Marco71.

appena uscito ryzen si vociferavano problemi e bug però le testate che lo scrivevano venivano tacciate di essere pagate da intel :P

avevo programmato il passaggio da i5 4690 a ryzen r7 1700 però dopo i problemi con le ram ho rimandato e questo conferma i miei dubbi aspetto la prima revisione del processore per fare il passaggio

Considerato il tipo di bug e il fatto che si presenti solo in determinati momenti, scommetto che la causa e' un qualche tipo di race condition.

E temo non sara' limitato a Linux, visto che un problema delle cpu.

edit

...dato che i "micro" processori sono enormi macchine a stati "finiti"...se si verificano le condizioni necessarie e sufficienti per insieme di ingressi, uscite arrivi in un determinato stato della "macchina" contrassegnato da anche possibili blocchi di sistema. L'idillio degli informatici (ingegneri e ex laureati scienze dell'informazione) prevede poi che tutto si possa aggiustare sempre riscrivendo linee di codice...in questo caso, sì, forse dipende dalla lunghezza del microcodice...altrimenti revisione di processo e maschere.

Marco71.

edit

la cpu funziona benissimo su tutto. non è un che un micro problema peraltro risolvibile da amd coi prossimi bios renda meno valida una cpu capolavoro. siete proprio fanboy intel. :rolleyes:

cazzo quante ne sai. :O :rolleyes:

Il troll ha editato... peccato :asd:

Ma rispondiamogli lo stesso. Non tutti usano il pc per facebook, quindi gli utenti che hanno acquistato ryzen proprio per usufruire di tutti i suoi core credo che abbiano il diritto di usufruire, altrimenti che senso ha?
La straordinarietà, pardon CAPOLAVORO dell'architettura amd sta proprio nel maggior numero di core rispetto a quella intel, visto che a parità di core intel è ancora più veloce.
Se una persona che compila su linux si ritrova dei segfault a causa di un bug nel processore ha ogni diritto di essere poco felice, confermo anche quanto detto da turcone, anche su questo forum c'è un utente che aveva avuto il problema, ma purtroppo la verità è stata fatta passare in secondo piano e l'utente come un visionario.
Infine amd non ha risolto il problema, non è detto che possa farlo con l'aggiornamento del microcode, si spera che possa farlo ma ad ora chi ha questo problema con linux se lo tiene.

E' il motivo per il quale mi sono astenuto dal giudicare Ryzen fino ad ora.
E' ancora troppo presto. :O

giusto, fare sessioni parallele di compilazione è una cosa di tutti i giorni, mentre i bug sull'Hyperthreading di sky e kaby sono cose che succedono assai raramente con qualsiasi sistema e quando usi entrambe le ALU di un core in modo intensivo...

stà perla di saggezza mi mancava.

:mc:

giusto, fare sessioni parallele di compilazione è una cosa di tutti i giorni, mentre i bug sull'Hyperthreading di sky e kaby sono cose che succedono assai raramente con qualsiasi sistema e quando usi entrambe le ALU di un core in modo intensivo...

stà perla di saggezza mi mancava.

:mc:

beh di che ti stupisci i proni e succubi fanboy intel aspettano la minima sbavatura per idolatrare il loro padrone.

Il troll ha editato... peccato :asd:

Ma rispondiamogli lo stesso. Non tutti usano il pc per facebook, quindi gli utenti che hanno acquistato ryzen proprio per usufruire di tutti i suoi core credo che abbiano il diritto di usufruire, altrimenti che senso ha?
La straordinarietà, pardon CAPOLAVORO dell'architettura amd sta proprio nel maggior numero di core rispetto a quella intel, visto che a parità di core intel è ancora più veloce.
Se una persona che compila su linux si ritrova dei segfault a causa di un bug nel processore ha ogni diritto di essere poco felice, confermo anche quanto detto da turcone, anche su questo forum c'è un utente che aveva avuto il problema, ma purtroppo la verità è stata fatta passare in secondo piano e l'utente come un visionario.
Infine amd non ha risolto il problema, non è detto che possa farlo con l'aggiornamento del microcode, si spera che possa farlo ma ad ora chi ha questo problema con linux se lo tiene.
Non se lo tiene il problema visto che c'è scritto di rivolgersi al servizio assistenza AMD.

Non se lo tiene il problema visto che c'è scritto di rivolgersi al servizio assistenza AMD.

Ottimo, se amd sostituisce i processori fallati, niente da dire, comportamento impeccabile!

giusto, fare sessioni parallele di compilazione è una cosa di tutti i giorni, mentre i bug sull'Hyperthreading di sky e kaby sono cose che succedono assai raramente con qualsiasi sistema e quando usi entrambe le ALU di un core in modo intensivo...

stà perla di saggezza mi mancava.

:mc:

che p@lle ste difese alla grillina : quando sbagliano noi la giustificazione è dire anche gli altri sbagliano ....
il problema c'è e bisogna risolverlo vediamo quanto ci mette per giudicare amd cmq sempre più convinto della mia logica di aspettare sempre il secondo modello di una cpu prima di comprarla che sia intel o amd

E' il motivo per il quale mi sono astenuto dal giudicare Ryzen fino ad ora.
E' ancora troppo presto. :O
il bug per fortuna corretto al SMT di skylake X e Kaby lake X, è solo l'ultimo dei bug noti che hanno interessato le CPU di Intel in questi anni.
Nulla di cui preoccuparsi, tanto più che TR e Epyc sembrano esenti dal bug.

premesso che anche il famoso bug del TLB di Agena, la cui soluzione ha ammazzato le prestazioni dei Phenom, era un evento raro.
Ma come dice turcone


il problema c'è e bisogna risolverlo
:ave:


stà perla di saggezza mi mancava.

:mc:
deve ancora riprendersi.
http://i67.tinypic.com/5v38g0.jpg

Ho letto di questo problema è la cosa non la trovo da sottovalutare.

sono bug sulla concorrenza dei registri.
sono semplici da risolvere se riesci a capire quale siano le istruzioni che vanno in concorrenza (basta un "pause" momentaneo finchè il reg non è libero).

che ne sia assente il TR fa anche riflettere sulla consistenza del problema, comunque, perchè significa rendere assai difficile l'identificazione delle istruzioni che lo procurano (piu' core, meno possibilità che le due istruzioni che lo determinano stiano sullo stesso core, nello stesso momento).

che p@lle ste difese alla grillina : quando sbagliano noi la giustificazione è dire anche gli altri sbagliano ....
il problema c'è e bisogna risolverlo vediamo quanto ci mette per giudicare amd cmq sempre più convinto della mia logica di aspettare sempre il secondo modello di una cpu prima di comprarla che sia intel o amd

non è una difesa ad oltranza, ma esclusivamente il discernere dal fanboysmo e la realtà dei fatti.
se sai da che dipende la natura del problema, devi solo identificare la causa e risolverla, come fanno tutti.

e ti svelo un segreto: ogni CPU a BUG, anche nei refresh; sono solo le revision HW che risolvono bug che non possono essere risolti via firmware, e si fanno solo per quei motivi.
finchè non c'e' un giustificato motivo di fare una nuova revision, potresti aspettare che si arrivi al refresh e quindi nuova maschera base e quindi nuovi BUG.

di processori realmente "cannati" nell'architettura se ne contano pochi, negli ultimi 30 anni (e per chi pensasse a bulldozer, non era cannata l'architettura, ma solo usata nell'ambito sbagliato in un periodo troppo estraneo per quel tipo di concezione).

Il baco e' stato analizzato in questo thread del forum di AMD

https://community.amd.com/thread/215773

Il baco si presenta anche compilando con Windows Subsystem for Linux, quindi e' presente anche su Windows.

Alcuni utenti Ryzen stanno donando tempo di calcolo per lo sviluppo del motore scacchistico Stockfish: registrano almeno un crash al giorno degli eseguibili che invece girano 24/365 senza problemi su tutte le altre CPU (Intel & AMD)

https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/ryzen%7Csort:relevance/fishcooking/1fFskLpQMWo/ALZaq7xSCwAJ

Alcuni utenti Ryzen stanno donando tempo di calcolo per lo sviluppo del motore scacchistico Stockfish: registrano almeno un crash al giorno degli eseguibili che invece girano 24/365 senza problemi su tutte le altre CPU (Intel & AMD)

Come mi aspettavo.
Compilazione multithread = integer multithread, stesso workload di un motore di scacchi. :O

E' il motivo per il quale mi sono astenuto dal giudicare Ryzen fino ad ora.
E' ancora troppo presto. :O

seeeeee

perche l'architettura si giudica dai bug :asd:

ogni tanto escono bug dovunque, dagli intel agli amd...ma nn è questo che giudica l'architettura

l'architettura amd (direi piu che buona) è stata gia giudicata (da tutto il mondo tranne te :asd:) all'uscita delle cpu

seeeeee

perche l'architettura si giudica dai bug :asd:

ogni tanto escono bug dovunque, dagli intel agli amd...ma nn è questo che giudica l'architettura

l'architettura amd (direi piu che buona) è stata gia giudicata (da tutto il mondo tranne te :asd:) all'uscita delle cpu

Non digli queste cose, potrebbe rimanere traumatizzato e non riprendersi più, con il rischio che peggiori pure.

Tranquillo ziobepi, Intel non sbaglia mai, chi sostiene il contrario non sa quello che dice.

PS: Hai razione ziobepi, è troppo presto per giudicare Ryzen, aspetta che esca la versione sui 2nm prima di scrivere altro, ti ringrazieranno in tanti.

non è una difesa ad oltranza, ma esclusivamente il discernere dal fanboysmo e la realtà dei fatti.
se sai da che dipende la natura del problema, devi solo identificare la causa e risolverla, come fanno tutti.

e ti svelo un segreto: ogni CPU a BUG, anche nei refresh; sono solo le revision HW che risolvono bug che non possono essere risolti via firmware, e si fanno solo per quei motivi.
finchè non c'e' un giustificato motivo di fare una nuova revision, potresti aspettare che si arrivi al refresh e quindi nuova maschera base e quindi nuovi BUG.

di processori realmente "cannati" nell'architettura se ne contano pochi, negli ultimi 30 anni (e per chi pensasse a bulldozer, non era cannata l'architettura, ma solo usata nell'ambito sbagliato in un periodo troppo estraneo per quel tipo di concezione).

tu parli di bug che non creano problemi invece questo ti blocca cosa simile successa all'atom avoton qui molto più grave ( cpu che volevo prendere per farmi un nas :( :( )
penso che ormai ryzen abbia bisogno di una revisione anche per tranquilizzare gli acquirenti dato i problemi in parte risolti con le ram

Ma quanto fanboysmo del beep.

A) è un bug come tanti altri che hanno anche i processori INTEL inclusi Skylake e Kaby X

https://www.ilsoftware.it/articoli.asp?tag=Bug-nei-processori-Intel-Skylake-X-e-Kaby-Lake-X-la-notizia-arriva-da-Debian_15714

https://www.swzone.it/Bug-nei-chip-Intel--migliaia-di-pc-aziendali-a-rischio-hacker-43766.html

e potrei continuare fino al 1986 ...

B) Si risolve come gli altri, con un update del microcode

C) fatevi una cultura invece di sparare disinformazione e ignoranza a palate

...dato che i "micro" processori sono enormi macchine a stati "finiti"...se si verificano le condizioni necessarie e sufficienti per insieme di ingressi, uscite arrivi in un determinato stato della "macchina" contrassegnato da anche possibili blocchi di sistema. L'idillio degli informatici (ingegneri e ex laureati scienze dell'informazione) prevede poi che tutto si possa aggiustare sempre riscrivendo linee di codice...in questo caso, sì, forse dipende dalla lunghezza del microcodice...altrimenti revisione di processo e maschere.

Marco71.

Marco71 il Maestro con la M maiuscola, come stanno i gufetti rotanti? :D
un saluto

Vabbè che sarà mai... è una architettura giovane.
A intel sono venuti fuori bug dopo anni dal rilascio.

Ma quanto fanboysmo del beep.

A) è un bug come tanti altri che hanno anche i processori INTEL inclusi Skylake e Kaby X

https://www.ilsoftware.it/articoli.asp?tag=Bug-nei-processori-Intel-Skylake-X-e-Kaby-Lake-X-la-notizia-arriva-da-Debian_15714

https://www.swzone.it/Bug-nei-chip-Intel--migliaia-di-pc-aziendali-a-rischio-hacker-43766.html

e potrei continuare fino al 1986 ...

B) Si risolve come gli altri, con un update del microcode

C) fatevi una cultura invece di sparare disinformazione e ignoranza a palate




vedo molti progettisti di cpu qua dentro chissà come mai intel e amd non vi assumono ?

Ho letto di questo problema è la cosa non la trovo da sottovalutare.

si tende a sottovalutarlo poichè la correzione via software di numerosi errata degli ultimi anni, non hanno portato apparentemente alla penalizzazione delle prestazioni.

Come detto da lucusta, la descrizione del problema è generica, quindi anche se la CPU si trova a gestire molti thread pesanti, non è condizione sufficiente per la verifica del bug.

D'altronde in Intel capita la stessa cosa:
descrizione generica del problema: con 2 thread attivi contemporaneamente su 1 core, con un loop composto da 64 o meno istruzioni macchina, con ampio utilizzo dei registi AH, BH, CH e DH e le loro varianti ampie, c'è il rischio di blocco...

ora con tutta la fantasia che uno può mettere: trovo veramente assurdo considerare le ipotesi che queste non siano condizioni tipiche...

skylake ha 8 porte nel back-end....con il SMT attivo le probabilità che 2 thread siano allo stesso tempo su due pipeline esecutive sono significative..

i problemi riguarderebbe l'uso di 4 registri General Purpose...se consideriamo che il codice x86-32 ne preveda in totale 8 per uso generale, le probabilità che il compilatore scelga di eseguire le istruzioni sui registri AH, BH, CH e DH è altissimo...

Nonostante la descrizione del problema apocalittica, problemi grossi le cpu intel non ne hanno dati.

vedo molti progettisti di cpu qua dentro chissà come mai intel e amd non vi assumono ?
Non capisco il nesso sinceramente....
Moltissime persone che recensiscono HW non sono ingegneri, figurati se sono specialisti del campo.
Resta il fatto che secondo diverse fonti, il die utilizzato da Ryzen e threadripper è il medesimo.....quindi o hanno corretto il bug di Ryzen con una revisione minore, oppure grossi problemi non ne vedo....dopotutto tutte le caratteristiche HW del singolo die Ryzen vengono utilizzate in threadripper....
questo fa pensare che alla base ci sia proprio un problema risolvibile, senza penalizzare le prestazioni, via software.

D'altronde in Intel capita la stessa cosa:
descrizione generica del problema: con 2 thread attivi contemporaneamente su 1 core, con un loop composto da 64 o meno istruzioni macchina, con ampio utilizzo dei registi AH, BH, CH e DH e le loro varianti ampie, c'è il rischio di blocco...

ora con tutta la fantasia che uno può mettere: trovo veramente assurdo considerare le ipotesi che queste non siano condizioni tipiche...

skylake ha 8 porte nel back-end....con il SMT attivo le probabilità che 2 thread siano allo stesso tempo su due pipeline esecutive sono significative..

i problemi riguarderebbe l'uso di 4 registri General Purpose...se consideriamo che il codice x86-32 ne preveda in totale 8 per uso generale, le probabilità che il compilatore scelga di eseguire le istruzioni sui registri AH, BH, CH e DH è altissimo...

Nonostante la descrizione del problema apocalittica, problemi grossi le cpu intel non ne hanno dati.
ma infatti suppongo che il problema sia SOLO se questa cosa viene usata apposta per creare "danni".
altrimenti via software è possibile controllarne l'utilizzo, giusto?

vedo molti progettisti di cpu qua dentro chissà come mai intel e amd non vi assumono ?

Appunto, quindi invece di fare figure di merda, statti in silenzio

Comunque la news è riportata abbastanza male.

Il problema c'è, nel senso che durante compilazioni in parallelo si verificano dei segmentation fault, ma non su tutte le macchine: alcuni non hanno problemi, altri invece si.
Non è un bug relativo a SMT: disattivandolo non si risolve, al massimo capita più raramente.

vedo molti progettisti di cpu qua dentro chissà come mai intel e amd non vi assumono ?

Non assumono neanche te, se è per questo

Non è un bug relativo a SMT: disattivandolo non si risolve, al massimo capita più raramente.


Sicuro? Perche' se e' cosi' e' un pelino piu' grave.

Appunto, quindi invece di fare figure di merda, statti in silenzio

vedo molti progettisti di cpu qua dentro chissà come mai intel e amd non vi assumono ?

datevi una calmata, ammonizione

Non capisco il nesso sinceramente....
Moltissime persone che recensiscono HW non sono ingegneri, figurati se sono specialisti del campo.
Resta il fatto che secondo diverse fonti, il die utilizzato da Ryzen e threadripper è il medesimo.....quindi o hanno corretto il bug di Ryzen con una revisione minore, oppure grossi problemi non ne vedo....dopotutto tutte le caratteristiche HW del singolo die Ryzen vengono utilizzate in threadripper....
questo fa pensare che alla base ci sia proprio un problema risolvibile, senza penalizzare le prestazioni, via software.

finora amd non è riuscita a capire il problema difatti c'è un'app per mandare ad amd tutti i registri dopo un crash ma secondo le "tue fonti" tipo mio cuggino il problema è facilmente risolvibile
ho espresso quel commento dato che molti esprimono giudizi da capo ingegnere senior perchè sembrano conoscere perfettamente la cpu in se quando forse il capo tecnologie di amd ha quel livello di conoscenza

ho una news da mio cuggino sull'argomento : è colpa degli infiltrati di intel che le cpu amd hanno problemi sono loro che mettono il silicio cattivo nelle cpu

datevi una calmata, ammonizione

scusa se leggo commenti alla mio cuggino mi ha detto non posso rispondere ?

Sicuro? Perche' se e' cosi' e' un pelino piu' grave.

E perché è più grave? Il bug sempre quello rimane. :confused:

finora amd non è riuscita a capire il problema difatti c'è un'app per mandare ad amd tutti i registri dopo un crash ma secondo le "tue fonti" tipo mio cuggino il problema è facilmente risolvibile
ho espresso quel commento dato che molti esprimono giudizi da capo ingegnere senior perchè sembrano conoscere perfettamente la cpu in se quando forse il capo tecnologie di amd ha quel livello di conoscenza

ho una news da mio cuggino sull'argomento : è colpa degli infiltrati di intel che le cpu amd hanno problemi sono loro che mettono il silicio cattivo nelle cpu

Susa ma che ti cambia se è facilmente risolvibile o meno per AMD? Tu gli mandi la CPU fallata e loro te ne mandano una nuova che non ha problemi, l'importante è il risultato finale.

ho espresso quel commento dato che molti esprimono giudizi da capo ingegnere senior perchè sembrano conoscere perfettamente la cpu in se quando forse il capo tecnologie di amd ha quel livello di conoscenza


Non conosco le competenze dei commentatori, ma stando alle descrizioni del problema e considerando come sono realizzati i processori moderni, quasi tutti i problemi di questo tipo si risolvono con update del microcodice.

Una percentuale di bug molto ridotta e' riconducibile ad errori di progettazione hardware ed in quel caso si fa una nuova revisione del processore. E in quelli gia' venduti si agisce sempre tramite microcodice ( quasi sempre possibile ) per implementare un workaround che ovviamente castrera' prestazioni o altro.

E perché è più grave? Il bug sempre quello rimane. :confused:


Il risultato rimane lo stesso, ma la causa sarebbe da ricercarsi piu' in profondita'. Un bug nel meccanismo di gestione dei thread e' tappabile tramite microcodice, e' stato fatto pure da Intel quando ha avuto problemi simili.

Ma se il problema non sta li', probabilmente sta piu' giu' e potrebbe non bastare un aggiornamento del microcodice. E' un'ipotesi, visto che non sappiamo dove sta il problema e com'e' fatta l'architettura Zen.

Non conosco le competenze dei commentatori, ma stando alle descrizioni del problema e considerando come sono realizzati i processori moderni, quasi tutti i problemi di questo tipo si risolvono con update del microcodice.

Una percentuale di bug molto ridotta e' riconducibile ad errori di progettazione hardware ed in quel caso si fa una nuova revisione del processore. E in quelli gia' venduti si agisce sempre tramite microcodice ( quasi sempre possibile ) per implementare un workaround che ovviamente castrera' prestazioni o altro.

finalmente una risposta decente :P
quindi se uso linux potrei aver calo di prestazioni quando faccio le azioni che adesso generano i bug ?

finalmente una risposta decente :P
quindi se uso linux potrei aver calo di prestazioni quando faccio le azioni che adesso generano i bug ?

... ho capito il fanboysmo, ma ti rendi conto che Intel ha avuto ed ha da anni le medesime problematiche e nessuno si è strappato le vesti?
Gli Xeon E5 usatissimi su macchine server avevano un bug enorme nella gestione della sicurezza, ben più grave di questo bug dei Ryzen e nessuno ha fatto tante storie ... talmente grave che girava un programmino con cui bastava mandare una serie di pacchetti RDP malformati per far crashare un server ... non so se rendo l'idea.

Poi, nel caso ci fossero diminuzioni di prestazioni ... la vedo la gente che si frusta perchè lancia in parallelo 4 compilazioni (già un caso più che limite) e invece di 30sec ce ne mettono 30,2sec

quindi se uso linux potrei aver calo di prestazioni quando faccio le azioni che adesso generano i bug ?

Impossibile rispondere visto che non si sa nemmeno quale sia il problema.

Inoltre mi pare strano che il problema si verifichi solo con Linux. Linux c'entra perche' Michael Larabel di Phoronix e' stato tra i primi a scoprire questo bug, e lui fa test solo su Linux. Ma e' molto probabile che si presenti anche con Windows, BSD, MacOS, ecc...

Inoltre mi pare strano che il problema si verifichi solo con Linux. Linux c'entra perche' Michael Larabel di Phoronix e' stato tra i primi a scoprire questo bug, e lui fa test solo su Linux. Ma e' molto probabile che si presenti anche con Windows, BSD, MacOS, ecc...

Esattamente.
Infatti, come ho già detto,
ci sono dei sospetti sui crash di Stockfish,
noto motore di scacchi opensource.

okyZ;44940514']... ho capito il fanboysmo, ma ti rendi conto che Intel ha avuto ed ha da anni le medesime problematiche e nessuno si è strappato le vesti?
Gli Xeon E5 usatissimi su macchine server avevano un bug enorme nella gestione della sicurezza, ben più grave di questo bug dei Ryzen e nessuno ha fatto tante storie ... talmente grave che girava un programmino con cui bastava mandare una serie di pacchetti RDP malformati per far crashare un server ... non so se rendo l'idea.

Poi, nel caso ci fossero diminuzioni di prestazioni ... la vedo la gente che si frusta perchè lancia in parallelo 4 compilazioni (già un caso più che limite) e invece di 30sec ce ne mettono 30,2sec

cavolo sempre grillinate .....

Impossibile rispondere visto che non si sa nemmeno quale sia il problema.

Inoltre mi pare strano che il problema si verifichi solo con Linux. Linux c'entra perche' Michael Larabel di Phoronix e' stato tra i primi a scoprire questo bug, e lui fa test solo su Linux. Ma e' molto probabile che si presenti anche con Windows, BSD, MacOS, ecc...


ok allora bisogna aspettare ...

Il risultato rimane lo stesso, ma la causa sarebbe da ricercarsi piu' in profondita'. Un bug nel meccanismo di gestione dei thread e' tappabile tramite microcodice, e' stato fatto pure da Intel quando ha avuto problemi simili.

Ma se il problema non sta li', probabilmente sta piu' giu' e potrebbe non bastare un aggiornamento del microcodice. E' un'ipotesi, visto che non sappiamo dove sta il problema e com'e' fatta l'architettura Zen.

Si ma per il momento si parla di sostituzione delle CPU che presentano il problema, perché non tutte ne soffrono, quindi non credo che rientri nelle correzioni tramite microcodice.
Sembrerebbe più un problema di selezione delle CPU, alcune sono passate ma evidentemente non dovevano, e quindi sistemabile solo tramite sostituzione.

Si ma per il momento si parla di sostituzione delle CPU che presentano il problema, perché non tutte ne soffrono, quindi non credo che rientri nelle correzioni tramite microcodice.
Sembrerebbe più un problema di selezione delle CPU, alcune sono passate ma evidentemente non dovevano, e quindi sistemabile solo tramite sostituzione.

QC da impalare in sala mensa :P

ho una news da mio cuggino sull'argomento : è colpa degli infiltrati di intel che le cpu amd hanno problemi sono loro che mettono il silicio cattivo nelle cpuVero, lo confermo. Sono gli stessi responsabili del FDIV bug sui Pentium, solo che ora vengono mandati 'in missione' presso la concorrenza. :asd:

Il problema sembra risolto http://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1

La nota negativa e' che probabilmente bisogna cambiare la cpu.

Il problema sembra risolto http://www.phoronix.com/scan.php?page=article&item=new-ryzen-fixed&num=1

La nota negativa e' che probabilmente bisogna cambiare la cpu.

allora hanno fatto una revisione del cpu
e quelli che sopra dicevano che basta un aggiornamento softwsare :mc:

allora hanno fatto una revisione del cpu

Non si sa. Puo' benissimo darsi che a Larabel abbiano spedito un'altra CPU per comodita'. Ed e' ovvio che produrrebbero comunque una revisione, con eventuali aggiornamenti/correzioni hardware ( se necessario ) o del microcodice.


e quelli che sopra dicevano che basta un aggiornamento softwsare :mc:

Vedremo nelle prossime settimane. Di certo si sono esposti parecchio. Anche se c'e' da dire che molti hanno detto semplicemente che il microcodice risolve in un buon numero di casi.

Poi c'e' il caso che proprio non va. E allora solo una modifica hardware puo' risolvere.