Newsgroup: it.comp.hardware.cpu
Titolo: Passo falso per AMD

Secondo una notizia pubblicata qui:
http://www.dinoxpc.com/News/news.asp?ID_News=7489&What=News
dinox dice:
Sul sito tedesco 3D Chips è stato riportato un bug sulle CPU AMD Opteron, a
causa del quale i sistemi basati su tale CPU si bloccano o producono un
risultato errato in una particolare situazione.
Il bug, stando al report, è relativo alle istruzioni REP MOVS che possono
causare il salto di istruzioni successive oppure provocare una dimensione
dell'indirizzo o dei dati da usare non corretta.
Comunque, gli utenti di processori Opteron sono stati avvisati da AMD che ha
consilgiato loro di contattare il proprio rivenditore AMD per informazioni
circa un aggiornamento di BIOS che dovrebbe risolvere in qualche modo il
problema. Inoltre la società di Sunnyvale ha anche detto di voler sistemare
questo bug.
---
In poche parole le cpu opteron (quindi anche gli A64-FX 51 e 53 e forse
anche gli A 64 normali) portebbero essere affetti da un bug nel calcolo.
Brutta notizia :-(((
-- 
Ciao
Tomalak
www.alientech.it
"Victory is life"


Stavo per postare la notozia pure io...;-)
Comunque in effetti ora anche AMD ha il suo "bel" bachetto...:-\
Ciao

 Brutta notizia :-(((
Mah, se secondo loro si può correggere con una patch al microcodice, non la
vedo così male... semmai dovranno spronare i produttori di schede madri a
rilasciare di corsa BIOS aggiornati, per mettere a tacere i detrattori.
-- 
ColdShine
"L'esperienza è un'insegnante severa: prima ci esamina e solo dopo ci fa
  lezione." - legge di Vernon Sanders
Athlon XP 2000+ Thorton @ Barton/1800 MHz/1,275V ||| Sapphire Radeon 9500
128 MB @ 9700 378/324 MHz ||| Jetway N2PAP-Ultra con mod JTPWR by me ||| 512
MB PC2100 CL2,5 @ 180 MHz/2,7V/2,5-3-3-11 ||| Enermax EG365P-VE @ EnerMOD by
me ||| Codegen CAT-9001-1 @ COLD-9001-1 by me ||| Foto in arrivo ;)


Questa č la cosa piů importante.
Ciao

 ColdShine
Ciao
ClaudeV8


Può essere che l'abbiano tenuto nascosto il più possibile per non creare
incertezza nei potenziali acquirenti...

 incertezza nei potenziali acquirenti...
Naa.. se fosse come dici tu l'avrebbero già risolto non credi?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.708 / Virus Database: 464 - Release Date: 18/06/2004

 Comunque in effetti ora anche AMD ha il suo "bel" bachetto...:-\
Sono convinto che ogni step di ogni cpu ha i suoi bachi più o meno gravi, di
certo questo non è il primo di AMD.. :-\



Concordo.
Ciao
Claudev8

 certo questo non è il primo di AMD.. :-\
Lo è per quello delle cpu a 64bit ;-)
Ciao

 rilasciare di corsa BIOS aggiornati, per mettere a tacere i detrattori.
Se basta una patch BIOS e` una 'cazzata'... Pero` i produttori di schede
madri sono dei minchioni, hanno in mano da mesi una patch per le schede
nvidia che hanno un baco sull'ACPI. Uno sviluppatore nvidia e` dovuto
andare sulla lkml a far presente questa cosa e a suggerire una soluzione,
cosi` il problema e` stato risolto.
Se il problema non si presenta con una certa frequenza, quelli non si
preoccupano neanche di rilasciare il bios nuovo... 
-- 
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: 
http://vvolonghi.blogspot.com
Home Page: 
http://xoomer.virgilio.it/dialtone/

 nvidia che hanno un baco sull'ACPI.
Questa mi è nuova... in che cosa consiste il baco?
E riguarda principalmente determinate schede video?
Ciao

 E riguarda principalmente determinate schede video?
Riguarda il routing degli IRQ dinamico sui canali IDE. Un baco per cui
nvidia aveva fornito una patch al BIOS ai produttori ma NESSUNO ha
patchato perche` su windows non dava problemi. (perche` ogni produttore
implementa ACPI come vuole e windows non rispetta, come al solito, gli
standard che la stessa microsoft fa approvare, come ACPI appunto).
Finche` uno sviluppatore nvidia non ha detto quale fosse il problema
(erano mesi che si andava avanti a cercare un fix per i lock-up, si
pensava fosse un problema di IO-APIC o chissa` cosa... O comunque un baco
del kernel)


 Per fare un esempio il kernel linux manco la usa mai.
Vabbè, ovvio che se fai il link con le librerie che implementano memcpy con
le MMX o
altre ottimizzazioni, la REP MOVSx non la usi mai...


 anche gli A 64 normali) portebbero essere affetti da un bug nel calcolo.
E` molto meno grave di quanto di possa pensare. Prima di tutto devono
verificarsi delle condizioni deterministiche (e questo ci puo` stare),
ma ci sono in gioco anche dei fattori temporali del tutto casuali.
Luca
-- 
Home: 
http://kronoz.cjb.net
Non capisco tutta questa eccitazione per il Multitasking: 
io sono anni che leggo in bagno.

 questo bug.
Bhe oddio, se si risolve con un aggiornamento del bios non e' una cosa poi
cosi' tragica (sperando che jetway muova il fondoschiena)...
cut
-- 
To start press any key... Where is the any key?


Già....
Ciao

 certo questo non è il primo di AMD.. :-\
ehehhe....cosa vuoi che sia....pure intel non scherza comuque!

 calcolo. Brutta notizia :-(((
Ma scusate... come fa qualcuno a dire che la situazione non č grave? Dal
punto di vista del problema in sé, forse... ma mica la cosa č tutta lě!
Ricordiamoci che gli Opteron sono processori destinato ad un certo mercato:
server, workstation, mainframe... Un bug del genere č gravissimo, non tanto
per la patch, quanto per l'immagine di AMD! Non sempre c'č gente abbastanza
esperta e scaltra da capire che si tratta di una cosa da poco, piuttosto
pensa: "AMD? No, ha processori che fanno errori, mai piů!".
MaxArt

 
Io personalmente intendevo che non era grave il baco in se (se si risolve
con un aggiornamento del bios non e' una tragedia).
Comunque mi auguro che in un'azienda seria che compra macchine piuttosto
grosse l'opinione del reparto tecnico abbia un peso molto influente, senno'
puoi stare tranquillo che prendevano intel comunque.


 ha scritto nel messaggio
news:2jt6k7F...@uni-berlin.de...

Seguendo questo ragionamento nessuno avrebbe piů dovuto comprare un
processore Intel, visto che c'era stato il baco del particolare calcolo
floating point errato (se ben ricordo) in alcuni Pentium. "Intel? No, ha
processori che fanno errori, mai piů!". Per non parlare poi del software...
Se ogni volta che si trova un baco non si comprasse piů dal produttore di
quel software... non si userebbe piů i PC   ;)
Ciao
ClaudeV8

 floating point errato (se ben ricordo) in alcuni Pentium. 
Quello è solo il baco più antico e noto; ce ne sono stati altri, anche
recentemente, ovviamente di entità minore.
Credo che parlare di passo falso sia un'esagerazione, considerato che da
molti anni (dai K6) AMD non metteva in circolazione CPU bacate. Prima o
poi sarebbe dovuto accadere di nuovo, l'importante è che non capiti di
frequente.
Saluti.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

 i PC   ;)
Ai tempi del baco FP dei primi Pentium (60, 66 e forse 75 MHz, se non erro)
la Intel non si era ancora fatta strada nel segmento server e workstation
con gli Xeon, ed in ogni caso i Pentium erano processori che avevano ben
altro target. Si poteva comunque pensare che la Intel ponesse molta piů
attenzione al mercato server. Ed in effetti, tra le CPU che ha creato per
quel segmento non mi pare ci siamo mai stati bug. Processori di scarse
prestazioni magari sě, ma senza bachi.
Cosa accadrebbe se venisse scoperto un bug negli Itanium? Apriti cielo!
MaxArt

 Ai tempi del baco FP dei primi Pentium (60, 66 e forse 75 MHz, se non erro)
Valerio HT:
No, si trattava dei 60, 66 e la prima serie a 90 Mhz (quindi sono
esistiti Pentium-S a 90 Mhz col baco e altri senza). Il 75 Mhz non era 
affetto dal baco, esso è uscito addirittura lievemente dopo il 100 Mhz. 
Saluti

scusate non ho capito bene, il problema affligge solo le cpu opteron o tutti
i processori a 64bit (athlon 64)?

 Cosa accadrebbe se venisse scoperto un bug negli Itanium? Apriti cielo!
Intel Itanium Processor Specification Update:
http://www.intel.com/design/itanium/downloads/249720.htm


 Intel Itanium Processor Specification Update:
E non basta:
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)
***      La macchina di Turing ha un baco nel programma      ***
***             e noi l'aggiusteremo con il C++!             ***

 E non basta:
http://h21007.wwhttp://
h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,5159,00.htmlw2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,5159,00.html
Saluti (scusate il doppio post)


Ecco, non so come ma ho fatto un casino :P
Il link giusto è: 
http://h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,5159,00.html
Saluti.


 
http://www.intel.com/design/itanium/downloads/249720.htm
Ah! Annamo bene! ;-)
E gli UltraSPARC, Power4... hanno mai avuto di problemi del genere?
MaxArt

 i processori a 64bit (athlon 64)?
Molto probabilmente tutti, visto che usano lo stesso core, gli FX direi che
lo hanno sicuramente.
-- 
Ciao
Tomalak
www.alientech.it
"Victory is life"

 da molti anni (dai K6) AMD non metteva in circolazione CPU bacate. 
infatti, non capisco perchè intel faccia parecchie schifezze prima di
arrivare ad una soluzione ottima o quasi e tutti li a comperare,
probabilmente amd non può ancora farlo

 probabilmente amd non può ancora farlo
E' proprio quello il punto: AMD non si può permettere troppi errori ;-).


 pensa: "AMD? No, ha processori che fanno errori, mai più!".
Primo: la cosa si risolve con un aggiornamento del bios
        (probabilmente viene aggiornato il microcodice della cpu)
        ed a quel punto non ci sono problemi.
Secondo: Hai letto in cosa consiste il bug ?
La situazione in cui avviene il bug e' la seguente:
1) EFLAGS.DF=1 ovvero il flag di incremento negativo e' settato;
2) il valore del contatore RCX (modalita a 64bit, ovvero
    CX o ECX nelle altre modalita) deve essere compreso tra 1 e 20;
3) l'istruzione REP MOVS e' preceduta da altre istruzioni "complesse"
    che vengono scomposte in piu macroOp
    e *che non hanno ancora completato l'esecuzione*
    quando inizia l'esecuzione di REP.
Le istruzioni "complesse" in oggetto sono quelle tipo
BOUND, CLI, LDS, LES, LFS, LGS, LSS, IDIV, e la maggior parte
delle istruzioni FPU x87 che non vengono
tradotte in una singola macroOp.
L'istruzione REP MOVS viene usata di solito con EFLAGS.DF=0
(incremento positivo dei registri RSI RDI), ha senso usarla
"ad incremento rovesciato" solo in casi in cui si deve fare
una copia tra due blocchi di memoria parzialmente sovrapposti
in cui il blocco destinazione inizia prima del blocco sorgente
(e di solito questo avviene in spezzoni di codice dove non ci sono
  calcoli in floating point, divisioni o altre istruzioni
  "complesse" che causano il bug).
Oltre a questo e' logico aspettarsi che la REP MOVS sia preceduta
da codice abbastanza codice che fa dei confronti sui puntatori (interi)
e jump condizionali per determinare se la copia va fatta "dritta" oppure
"rovesciata" quindi c'e' tutto il tempo per far "completare" le istruzioni
"complesse" non ancora ritirate dalle pipeline.
Se stai manipolando dati floating point o giocherellando con i registri
di segmento (che nei programmi in modalita a 32 e 64bit non vengono
mai toccati dal codice utente) eventuali istruzioni REP MOVS ad incremento
negativo *se vengono usate* sono molto distanti nella sequenza di
istruzioni (senza contare che molto probabilmente ci si arriva con
un jump condizionale eseguito molto raramente, quindi molto verosimilmente
mal predetto con conseguente pipeline flush che elimina alla radice
ogni potenziale problema).
Per questo nonostante tutti i test di regressione fatti con codice
applicativo a 16, 32 e 64bit sino ad ora tale bug non era stato
identificato (raro trovare codice che scateni il bug, ad occhio e croce
lo ha scoperto qualcuno che stava iper-ottimizzando a mano del codice
assembly).
L. Micheletto

 assembly).
Ti diro` di piu`, questo baco viene fuori SOLO se stai programmando in
asm. Non esiste compilatore che genera asm che possa far venire fuori quel
baco.


 tradotte in una singola macroOp.
Cacchio, una bella tombola, scovarlo! o__O
Mi chiedo se altri processori in realtà allora non nascondano dei bug del
genere, ma mai scovati. Tutto sta per AMD nel non dare eco alla cosa.
Comunque, che comportamento implica il bug, quando vi si incappa?
MaxArt

 Saluti.
C'è ne un bel po' anche per il Prescott...
http://www.theinquirer.net/?article=16823
Ciao
Claudio

 
http://www.theinquirer.net/?article=16823
Per par condicio, diciamo che sicuramente ce ne sono un bel po' anche nei
processori AMD: solo che la maggior parte non impediscono alla CPU di
funzionare sotto nessuna condizione (di solito si tratta di difetti
prestazionali: ad esempio certe istruzioni SSE che richiedono più cicli
del normale per essere eseguite).


 E' proprio quello il punto: AMD non si può permettere troppi errori ;-).
Su questo tema, pare che Intel abbia ritirato i chipset 915 rilasciati
qualche giorno fa. E pare che ci siano problemi anche con i Prescot a
90um.
Fonte The Inquirer:
http://www.theinquirer.net/?article=16840
http://www.theinquirer.net/?article=16823
Luca
-- 
Home: 
http://kronoz.cjb.net
La somma dell'intelligenza sulla terra e` una costante.
La popolazione e` in aumento.

 E pare che ci siano problemi anche con i Prescot a 90um.
Vuoi dire: *altri* problemi... :P
-- 
ColdShine
"L'esperienza è un'insegnante severa: prima ci esamina e solo dopo ci fa
  lezione." - legge di Vernon Sanders
Athlon XP 2000+ Thorton @ Barton/1800 MHz/1,275V ||| Sapphire Radeon 9500
128 MB @ 9700 378/324 MHz ||| Jetway N2PAP-Ultra con mod JTPWR by me ||| 512
MB PC2100 CL2,5 @ 180 MHz/2,7V/2,5-3-3-11 ||| Enermax EG365P-VE @ EnerMOD by
me ||| Codegen CAT-9001-1 @ COLD-9001-1 by me ||| Foto in arrivo ;)


Quando si incappa in quel bug la REP MOVS puo capitare che
venga usata la dimensione sbagliata di indirizzo, dato, segmento
sorgente oppure l'istruzione *successiva* alla REP MOVS viene
saltata.
Ad occhio e croce si tratta di un errore riguardante come
la REP MOVS viene "espansa" in macroOp quando EFLAGS.DF=1
(con conseguente incasinamento con altra roba "espansa"
  presente in pipeline).
L. Micheletto