Un bug per Ryzen in abbinamento a Linux, ma AMD è al lavoro

[ctoks]

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

[ziobepi]

Originariamente inviato da ctoks

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.

[Micene.1]

Originariamente inviato da ziobepi

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

seeeeee

perche l'architettura si giudica dai bug

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 ) all'uscita delle cpu

[Folgore 101]

Originariamente inviato da Micene.1

seeeeee

perche l'architettura si giudica dai bug

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 ) 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.

[turcone]

Originariamente inviato da lucusta

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

[riuzasan]

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.a...a-Debian_15714

https://www.swzone.it/Bug-nei-chip-I...ker-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

[nn020]

Originariamente inviato da Marco71

...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?
un saluto

[demos88]

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

[turcone]

Originariamente inviato da riuzasan

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.a...a-Debian_15714

https://www.swzone.it/Bug-nei-chip-I...ker-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 ?

[tuttodigitale]

Originariamente inviato da AleLinuxBSD

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.

[tuttodigitale]

Originariamente inviato da turcone

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.

[aqua84]

Originariamente inviato da tuttodigitale

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?

[riuzasan]

Originariamente inviato da turcone

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

[blackshard]

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.

Originariamente inviato da turcone

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

Non assumono neanche te, se è per questo

[pabloski]

Originariamente inviato da blackshard

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.

[!fazz]

Originariamente inviato da riuzasan

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

Originariamente inviato da turcone

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

datevi una calmata, ammonizione

[turcone]

Originariamente inviato da tuttodigitale

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

[turcone]

Originariamente inviato da !fazz

datevi una calmata, ammonizione

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

[Folgore 101]

Originariamente inviato da pabloski

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

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

Originariamente inviato da turcone

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.

[pabloski]

Originariamente inviato da turcone

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.