Link alla notizia: http://www.hwupgrade.it/news/cpu/21794.html

Una serie di bug scoperti e corretti nelle cpu Core 2 Duo, risalenti ad alcuni mesi fa, scatena polemiche tra esponenti di spicco della community Linux

Click sul link per visualizzare la notizia.

Che brutta cosa.

ma se uno non fa l'update? come i 30 milioni di persone che il pc lo comprano al mercato :asd:

la cosa peggiore è che per due guru dell'informatica come Theo de Raadt e Linux Torvalds (come l'hanno chiamato nell'articolo ahahhaha) il problema ha risvolti diametralmente opposti... è un po' disorientante: allora chi ha ragione? sono bug gravi o no?

ma soprattutto: come diavolo fanno due guru così ad essere in disaccordo su una questione meramente tecnica?

beh, senza gloria nè infamia, tanto il bios è aggiornato; :D

per me non è grave, alla fine è solo strumentalizzazione!!

31337

cavolo questa nn la pensavo, ne me l'aspettavo

mi ricorda la questione dei Pentium 60 e 66, che avevano all'interno un bug (credo nel calcolo in virgola mobile) che portava a risultati errati nei conti: Intel si era offerta di sostituire i processori per "tutelarsi" contro eventuali azioni legali dovute a problemi correlati al bug stesso ;)

Finchè non mi fanno 2 + 2 = 3 ...

la cosa peggiore è che per due guru dell'informatica come Theo de Raadt e Linux Torvalds (come l'hanno chiamato nell'articolo ahahhaha) il problema ha risvolti diametralmente opposti... è un po' disorientante: allora chi ha ragione? sono bug gravi o no?

ma soprattutto: come diavolo fanno due guru così ad essere in disaccordo su una questione meramente tecnica?

non so.. bisognerebbe vedere chi ha parlato per primo, l'altro ha logicamente detto il contrario :asd: tra guru non si è mai d'accordo :O

Tristissimo il finale della lettera di Theo de Raadt nel quale si arroga il diritto
di parlare per tutto il mondo dell`open source nonchè di star dando una
tirata d`orecchi pure ad AMD (quasi che qualcuno dicesse che le fiat sono
trappole infernali ed insicure e le renault hanno sospensioni dure pensando di
aver trattato entrambe nello stesso modo....)

I 30 milioni che il pc lo comprano al mercato è la volta buona che si svegliano

la cosa peggiore è che per due guru dell'informatica come Theo de Raadt e Linux Torvalds (come l'hanno chiamato nell'articolo ahahhaha) il problema ha risvolti diametralmente opposti... è un po' disorientante: allora chi ha ragione? sono bug gravi o no?

ma soprattutto: come diavolo fanno due guru così ad essere in disaccordo su una questione meramente tecnica?
C`è poco da parlare di "2 guru", de Raadt non è manco un decimo della
figura che è Linus Torvalds, il suo OpenBSD ha più volte lamentato
grossi problemi di carenza di sviluppo fino anche all`ammissione di aver
copiato (col cut-n-paste) porzioni di codice linux. (http://www.theinquirer.net/default.aspx?article=38746)

L`unica spiegazione possibile è che il sig. de Raadt abbia qualche rientro
economico da questo genere di sparate (come già puntualizzato su problemi
già risolti sia su Linux che su Windows).

Cos'è, alcuni si accorgono solo ora degli errata dei processori?

Cos'è, alcuni si accorgono solo ora degli errata dei processori?

bella domanda, forse molti pensavano le cpu come puro hardware e quindi indifferente ai progblemi normali per un software , ma invece i bug nelle cpu sono moltissimi, sommando tutti quelli dei processori fatti negli ultimi anni si arriva ad alcune centinaia quindi non vedo dove sta il problema visto che il tipo di bug trovato dei core 2 è simile a molti altri presenti in tutte le serie precedenti sia amd ibm o di altri produttori.

il modo migliore per aggiornare le cpu e il loro microcodice resta sempre il sistema operativo perche avere sempre il bios aggiornato all'ultima versione è una cosa rara e spesso la scheda madre appena diventa un po datata perde il supporto e quindi gli aggiornamenti.

il modo piu pratico è fare aggiornamenti software come ha fatto la MS con l'ultima patch http://support.microsoft.com/?kbid=936357 che non fa altro che aggiornare al boot del pc alcuni componenti delle cpu intel core 2 per risolvere un bug fastidioso.

per chi è interessato

http://webnews.html.it/news/stampa/6315/una-patch-per-le-cpu-intel-core-2/


per chi si chiedesse del perche si stenta molto a risolvere questi bug o si ripiega spesso su soluzioni tampone tramite il bios o il SO basta risordare che anche per una minima modifica al silicio di una cpu bisogna rifare completamente lo "stampo" della maschera che poi la va a generare tramite il processo di litografia, questa operazione costa molti milioni di $ e quindi si fa solo se sono gia in cantiere altre modifiche come ulteriori step per migliorare le prestazioni i consumi o il passaggio a litografia piu spinte.

Theo de Raadt ha torto a prescindere, anche solo per quel suo fare spocchioso.

ma + che altro speriamo che nelle rev future lo sistemano chi si è già preso il C2D adesso bene si prende i microcode ma almeno le future rev siano esenti da questo errore^^

la cosa peggiore è che per due guru dell'informatica come Theo de Raadt e Linux Torvalds (come l'hanno chiamato nell'articolo ahahhaha) il problema ha risvolti diametralmente opposti... è un po' disorientante: allora chi ha ragione? sono bug gravi o no?

ma soprattutto: come diavolo fanno due guru così ad essere in disaccordo su una questione meramente tecnica?

ma se quei due litigano in continuazione :asd:

Ora guardo subito se il bios è aggiornato, sono passato da AMD ad Intel in un brutto momento, speriamo che i bug non siano gravi, altrimenti prendo il mio e6600 e lo volo dalla finestra

beh, sul discorso di quelli che comprano il pc al mercato credo che gli importi poco dei bug........
sono gli stessi che quando gli arriva una mail con scritto "JLo nuda" o "Susanna ha tante cose da dirti e farti vedere" aprono l'allegato...
non c'è bisogno di andare a lavorare così in profondità per infettargli il pc.....

c'è una poiccola inesattezza nell'articolo.
Intel non ha fornito un BIOS aggiornato che corregge i bug, ma ha comunicato i bug ai produttori di BIOS, secondo quanto riportato qui:
http://notebookitalia.it/troppi-bug-nei-processori-intel-core-2-duo.html

W il buon vecchio Pentium D.....

ho un e6600... cavolo non potro' piu dormire sonni tranquilli ....
ROFL

senza scendere in commenti da stadio io penso che a prescindere dalla figura di de Raadt la sua lamentela fosse rivolta al fatto che Intel come AMD per questione di immagine tendono a nascondere e/o temporeggiare sul rilascio di buglist complete. Chiaramente simili exploit sono finesse non certo paragonabili allo spam o trojan da pornositi. Però c'è da ricordare che non tutti i sistemi vengono usati per far partire i giochilli o word o autocad... ci sono anche altri utilizzi per un pc e l'esecuzione di codice malevolo puo portare a problemi (ie. perdite sostanziali di denaro) non indifferenti.

Finchè non mi fanno 2 + 2 = 3 ...

:sbonk:

Io credo che un bug non sia nè piccolo, nè grande. Un bug è un errore che deve essere risolto al di la che sia sfruttato da malintenzionati o no... Perchè appena ti creano un malware ad hoc quel microbug diventa, guarda caso, un bug di enorme portata...
La "grandezza" di un bug non sta tanto nel tipo di errore fatto dagli sviluppatori, ma nei suoi effetti...

Secondo me non sono bug così importanti, se no qualcuno li avrebbe già sfruttati e si sarebbe saputo.. poi se sono stati aggiornati...

:sbonk:

ehm ehm
1.6 + 1.6 =3.2

Arrotondiamo all'intero più vicino:

2 + 2 = 3

Cavolo, ho un baco pure io (nella capa :D:D)

..."maremma zucchina"...
Queste note diramate a mio modesto avviso, ingenerano solo una sorta di pseudo "terrorismo, anche tra i cosiddetti "addetti ai lavori" o comunque anche eventualmente tra le persone con backgorund culturale "elettronico" e sui computer, elevato.
Per i processori a circuito integrato nelle forme che conosciamo noi oggi (escludendo computer utilizzanti altri paradigmi "hardware"/"software") le errata (ed eventualmente, corrige) sono sempre esistite sin dal 4004.
I primi 80386 avevano gravi "bug" a carico delle istruzioni IMUL che portavano ad esempio, a dissipazione abnorme di potenza.
Il famoso bug a carico della FDIV non era un vero e proprio "bug" od errore di progettazione per iu Pentium 90/100 MHertz: si trattò piuttosto di dimenticanza di un "ingegnere" della Intel che si dimenticò di caricare dei coefficienti in una P.L.A di lokkup table che doveva assistere il "nuovo" (allora) algoritmo FDIV I.E.E.E 754 di tipo S.R.T.
Non come accadeva per le f.p.u discrete/integrate sul modello Intel 80287/80387/80486DX utilizzanti l'algoritmo shift/add CO.R.D.I.C.
Tra parentesi Intel sostituì gratuitamente ogni processore.
Ho parlato solo di Intel ma è ovvio (e mi sembra scontato anche non dirlo) che le errata per i processori riguardano ogni architettura di processore ed ogni costruttore.
Se leggete le errata di ogni processore di classe "Pentium", P&, ecc. ecc. ne conterete a centinaia.
Per alcune sono previsti correzioni entro determinati step, per altre semplicemente non è prevista correzione.
Ci sono complicatissime combinazioni di livelli elettrici sui pin esterni, sugli stati delle reti interne ecc. che possono condurre a quelli che molto spesso vengono scambiati dall'utente esterno, come situazioni di deadlock ed imputate al sistema operativo.
Tra parentesi la possibilità di "patching" del microcodice (avete presente la famosa voce di molti b.i.o.s "Bios update" ?) fu introdotta proprio con il glorioso Pentium PRO per il quale venne condotta una campagna di test con set di vettori "esaustivo" per tutte le istruzioni in virgola mobile I.E.E.E 754/854 allo scopo di evitare problemi quali quelli del suo progenitore "Pentium".
Il 68040 di Motorola provvedeva a correzione delle errata riguardanti la f.p.u (semplificata rispetto ai 68881/68882) tramite ben note trap al sottosistema S.A.N.E.
E via di seguito potrei dire di Alpha, dei processori M.I.P.S dall' R2000 fino all'R10000, degli S.P.A.R.C, dei processori PowerPC I.B.M ecc.ecc.ecc.
Per mitigare l'impatto di tali "errata" basta agire tempestivamente, il più possibile e magari senza inutili "profezie di imminenti catastrofi".
Grazie.

Marco71.

Marco71.

Quest'uomo è un pozzo di storia processoristica :)

E chi è questo Torvalds? :D

X Marco71:
Senta professore visto che non mi risponde alla mail a che ora vengo domani all'esame?

...per curiosità di chi volesse ho alcuni programmi che provvedono proprio al test esaustivo I.E.E.E 754 elaborati proprio a partire da indicazioni di uno dei padri storici dello standard W. Kahn.
Volete "ridere", quando l'ho eseguito sul Pentium Overdrive che avevo sul mio vecchio (e primo "I.B.M" compatibile) ha riportato errori propri oa carico della istruzione FDIV.
L'unica maniera per rendere "visibile" all'utente se un errata per un processore "xyz" prodotto dal costruttore "xwq" (parlo di architetture x86 dal Pentium in poi e meglio se di classe P6) ha generato un determinato errore o deadlock di tutto il sistema, sarebbe quella di avere un sistema (magari proprio integrato nel s.o) che provvedesse a correlare i dati provenienti dalla machine check architecture del processore con l'evento verifcato...
Avete presente i blue screen of death, le frasi "il sistema è stato ripristinato in seguito ad un grave erroe" ecc. ecc.
Ecco quelli sono gli indizi del dialogo tra l'ambiente hardware/software "machine check architecture" ed il sovrastante sistema operativo.
L'ambiente M.C.A" tra parentesi è in grado di sopravvivere anche ai reset "a caldo" del sistema.
Mamma mia mi sembra di essere ritornato a G.O.N.F 3.0 che avo per Amiga e le sue guru meditations.

Marco71.

uhm ma la domanda sorge spontanea: l'articolo è del 22/06/07 quindi chi nn ha una versione del BIOS aggiornata DOPO tal data dovrebbe fixare il tutto con il knowledge pubblicato da MS?

...non ho capito..

Marco71.

visto che tra bsd e linux è guerra aperta... la cosa non mi stupisce...
ma visti i bug presenti in "open" bsd

perchè è tutt'altro che open in termini di sicurezza...
credo che Theo de Raadt abbia qualche freccia in più al suo arco..

...non ho capito..

Marco71.

mi riferisco a QUESTO (http://support.microsoft.com/?kbid=936357)

che strana cosa :mbe:

...è proprio inerente a ciò di cui stiamo discutendo...
Io sono stato titubante nei giorni scorsi non sapendo se potevo/dovevo scrivere di tale argomento sul forum.
Attenzione, se effettuate aggiornamenti dei vostri b.i.o.s non ci dovrebbe essere necessità di caricare tale "patch"...
analoghi aggiornamenti ci furono dopo SP2 per XP e sopratutto per chi aveva sistemi portatili con Speedstep.

Marco71.

mi riferisco a QUESTO (http://support.microsoft.com/?kbid=936357)
se hai uno dei processori affetti dai "bug" elencati e' consigliabile o aggiornare il bios o installare la patch.
L'ultima opzione dovrebbe essere comunque preferibile in quanto il sistema operativo e' in grado di fare l'override di alcune primitive del bios con la possibilita' quindi,per quanto remota, di incappare in una delle situazioni elencate nell'errata.

...è proprio inerente a ciò di cui stiamo discutendo...
Io sono stato titubante nei giorni scorsi non sapendo se potevo/dovevo scrivere di tale argomento sul forum.
Attenzione, se effettuate aggiornamenti dei vostri b.i.o.s non ci dovrebbe essere necessità di caricare tale "patch"...
analoghi aggiornamenti ci furono dopo SP2 per XP e sopratutto per chi aveva sistemi portatili con Speedstep.

Marco71.

si ma il problema è che i BIOS escono una volta ogni morto di papa ... e dubito che ci siano BIOS aggiornati POST 22/06 ... e cmq sto aggiornamento comprende qualche "stellina" incorporata? :P

(nn che abbia un win tarocco, semplice curiosità)

...è proprio inerente a ciò di cui stiamo discutendo...
Io sono stato titubante nei giorni scorsi non sapendo se potevo/dovevo scrivere di tale argomento sul forum.
Attenzione, se effettuate aggiornamenti dei vostri b.i.o.s non ci dovrebbe essere necessità di caricare tale "patch"...
analoghi aggiornamenti ci furono dopo SP2 per XP e sopratutto per chi aveva sistemi portatili con Speedstep.

Marco71.
Domanda..
il sistema operativo e' in grado di scavalcare il bios per alcune funzioni, giusto?
in questo caso che microcodice verrebbe caricato?

:confused:

...che Microsoft divulghi maggiori notizie in merito a tale microcode update.
Io per adesso avrei solo un E6320 step B2 da aggiornare eventualmente.
Da tenere presente che prima di installare l'update è buona norma effettuare un backup della partizione "attiva" di avvio.
Quello che mi lascia perplesso è come mai Microsoft lo consideri "facoltativo" invece di renderlo prioritario attraverso il meccanismo di updating automatico.


Marco71.

...che Microsoft divulghi maggiori notizie in merito a tale microcode update.
Io per adesso avrei solo un E6320 step B2 da aggiornare eventualmente.
Da tenere presente che prima di installare l'update è buona norma effettuare un backup della partizione "attiva" di avvio.
Quello che mi lascia perplesso è come mai Microsoft lo consideri "facoltativo" invece di renderlo prioritario attraverso il meccanismo di updating automatico.


Marco71.

già :what:...

...che un s.o di "classe N.T" che funzioni su un sottostante hardware che effettua lo shadowing di tutte le routine contenute nel b.i.o..s, non sia "è" in grado di caricare routine proprie che effettuano un bypass di quelle contenute nel suddetto.
Evidentemente c'è una mancata sincronizzazione tra sorgente (Intel in questo caso) produttori di schede madri e "produttori" di sistemi operativi.

Marco71.

si ma il problema è che i BIOS escono una volta ogni morto di papa ... e dubito che ci siano BIOS aggiornati POST 22/06 ... e cmq sto aggiornamento comprende qualche "stellina" incorporata? :P

(nn che abbia un win tarocco, semplice curiosità)

Questo bug è noto da aprile.

Cerca un qualsiasi BIOS dal produttore della tua scheda madre uscito dopo aprile con la dicitura "Microcode update" o "Reliability update" o simile e sei sicuro che è un bios che risolve il bug

Ciao

...che un s.o di "classe N.T" che funzioni su un sottostante hardware che effettua lo shadowing di tutte le routine contenute nel b.i.o..s, non sia "è" in grado di caricare routine proprie che effettuano un bypass di quelle contenute nel suddetto.
Evidentemente c'è una mancata sincronizzazione tra sorgente (Intel in questo caso) produttori di schede madri e "produttori" di sistemi operativi.

Marco71.

I SO a 32 bit o superiore non usano le routine del BIOS per accedere alle risorse HW , ma programmano le periferiche direttamente tramite i driver.

Qua il problema sta nel microcodice del processore che viene caricato all'avvio del PC nella micromemoria della CPU dal BIOS come procedura di inizializzazione.

Credo che le strategie che Microsoft possa aver adottato per far fronte al problema siano 2 :

- Update "a caldo" del microcodice della CPU, ossia sostituzione del microcodice della CPU con una versione aggiornata e corretta di Intel "dopo" che il sistema si è avviato

- Workaround specifico per evitare il problema, ad esempio, se il problema sta in un comportamento atipico della CPU rispetto a quello che ci si aspetterebbe in una determinata situazione, allora il SO sa che in quelle situazioni, con la CPU Intel Core 2 si dovrà comportare in modo diverso rispetto allo standard di tutte le altre CPU x86 .

Il secondo sistema mi sembra improbabile perchè : 1) Il comportamento della CPU affetta dal BUG deve essere sempre prevedibile (ossia anche se il comportamento è diverso dallo standard non deve essere casuale) 2) In caso di aggiornamento del Microcodice via BIOS le assunzioni fatte dal SO non sarebbero + valide, quindi io opterei per la prima.

Ciao

EDIT: Se qualcuno vuole scaricare il microcodice intel può trovarlo su questo sito. http://www.urbanmyth.org/microcode/

C'è anche una applicazione Linux (per coloro che hanno linux e il modulo "intel microcode update" compilato) che permette di upgradare a caldo il microcodice della CPU risolvendo il BUG (almeno credo, intel non rilascia Changelogs per il microcodice nè errata, ma il fatto che il microcodice risalga a fine aprile mi fa ben sperare) . In pratica fa quello che credo faccia anche la patch microsoft per Windows. Bisognerà riupgradare il microcodice ogni volta che si riavvia, quindi se volete farlo mettete il tutto in uno scriptino e fatelo partire all'avvio . Personalmente consiglio un upgrade del BIOS

Ri-Ciao

...purtroppo.
Ci sono delle errata che generano talvolta eventi che portano a blocco il sistema operativo e di cui lo stesso s.o ha "consapevolezza nulla".
Sono proprio le errata per i processori (di tutti i costruttori) che al dato step xx non hanno ricevuto correzione negli step seguenti e per cui non è prevista correzione.
Ovvio che i moderni sistemi operativi non possono poggiarsi sulle routine classiche dei b.i.o.s (come le INT 10h per la scrittura a video ecc.).
Sarebbe tutto molto inefficiente e lento, molto spesso.
Thanks.

Marco71.

...purtroppo.
Ci sono delle errata che generano talvolta eventi che portano a blocco il sistema operativo e di cui lo stesso s.o ha "consapevolezza nulla".
Sono proprio le errata per i processori (di tutti i costruttori) che al dato step xx non hanno ricevuto correzione negli step seguenti e per cui non è prevista correzione.
Ovvio che i moderni sistemi operativi non possono poggiarsi sulle routine classiche dei b.i.o.s (come le INT 10h per la scrittura a video ecc.).
Sarebbe tutto molto inefficiente e lento, molto spesso.
Thanks.

Marco71.

Infatti, certi bug riguardano proprio la gestione interna della CPU e non sono dipendenti dal SO, motivo in più che mi porta a pensare a un aggiornamento di microcodice a caldo.

I SO moderni non possono accedere alle routine del BIOS non solo perchè sono lente e inefficienti, ma anche perchè vengono disabilitate all'uso del programmatore non appena il processore entra in modalità protetta a 32 bit (o superiore)

Ciao

Un caso specifico: un pc con dual core e6000 e Vista mi ha fatto imapzzire per piu' di una settimana, bluescreen in determinate circostanze, sostituito ram, motherboard, riformattato....nulla dopo la patch Microsoft tutto e' tornato regolare.....mica poco per un bug di poco conto.

Un caso specifico: un pc con dual core e6000 e Vista mi ha fatto imapzzire per piu' di una settimana, bluescreen in determinate circostanze, sostituito ram, motherboard, riformattato....nulla dopo la patch Microsoft tutto e' tornato regolare.....mica poco per un bug di poco conto.

Strano, a sentire le fonti non dovrebbe essere un BUG molto facile da riscontrare

Ciao

flop

Eh..ma tanto se è risolvibile via Bios non sarà molto grave, immagino!

flop

Ma fate un corso per dare risposte cosi' irritanti e poco inerenti?
Ma che vuol dire flop? Che contributo puo' dare alla comunita' ?

Scusate lo sfogo, ma in tutte le discussioni l' "aristotele" c'e' sempre.
Articolo interessante, risposte esaurienti (complimenti a marco71 per la padronanza dell' argomento).

Boh...

Ora guardo subito se il bios è aggiornato, sono passato da AMD ad Intel in un brutto momento, speriamo che i bug non siano gravi, altrimenti prendo il mio e6600 e lo volo dalla finestraQuello che forse per alcuni di voi non è chiaro è che i processori AMD ne hanno altrettanti, se non peggiori, sicuramenti di ugual entità.

x MiKeLezZ

Dove hai letto che le CPU AMD sono affette da BUG così rilevanti? a me sembra che fino ad oggi non si sia mai sentito di BUG sulle CPU AMD!!!

Come al solito non si perde occasione x tirare in ballo la casa di Sunnyvalle

x MiKeLezZ

Dove hai letto che le CPU AMD sono affette da BUG così rilevanti? a me sembra che fino ad oggi non si sia mai sentito di BUG sulle CPU AMD!!!

Come al solito non si perde occasione x tirare in ballo la casa di Sunnyvalle

non le senti perche pochi ne parlano, hai sentito parlare delle 200 e piu bug nelle cpu dal pentium 4 ad oggi ?, immagino di no perche è un argomento che nessuno tratta tranne ora per questo caso specifico.

i bug sono ben documentati sui siti dei produttori basta andara nella sezione tecnica e scaricare i datasheet con gli "errata" delel cpu
esampio http://download.intel.com/design/processor/specupdt/31327914.pdf

..."Coschizza" e "MiKeLezZ" hanno perfettamente ragione.
Come ho già detto in un precedente post sempre relativamente a questa news, qualsiasi "prodotto dell'ingegno umano" ha degli "errata" (in senso generale)...
In particolare non esiste (e probabilmente sulla Terra non esisterà mai a meno di salti evoluzionistici) nessun processore ("micro", "nano" il prefisso che più sia attinente) esente da errori od sistematici ed inseriti già nelle prime fasi di progetto, oppure aggiunti in seguito in successive revisioni dalla moltitudine di step litografici necessari.
Bisognerebbe parlare di questi argomenti tralasciando l'umana natura di parteggiare per qualcuno o per qualche cosa...in poche parole esprimere comportamento neutro.
La gravità delle errata a "carico" processori A.M.D è sicuramente comparabile a quella insita ai processori, Core Intel nel caso di specie.
Un piccolo estratto di una prima pagina di data sheet:
The purpose of the Revision Guide for AMD NPT Family 0Fh Processors is to communicate updated
product information to designers of computer systems and software developers. This revision guide
includes information on the following products:
• AMD Athlon™ 64 processor
• AMD Athlon 64 X2 dual-core processor
• AMD Athlon 64 FX dual-core processor
• Dual-Core AMD Opteron™ processor
• AMD Turion™ 64 X2 Mobile Technology
• AMD Sempron™ processor
This guide consists of three major sections:
• Processor Identification: This section, starting on page 6, shows how to determine the processor
revision, program and display the processor name string, and construct the processor name string.
• Product Errata: This section, starting on page 13, provides a detailed description of product
errata, including potential effects on system operation and suggested workarounds. An erratum is
defined as a deviation from the product’s specification, and as such may cause the behavior of the
processor to deviate from the published specifications.

E via di seguito, basterebbe prima di esprimere impulsivamente affermazioni verificare la attendibilità delle informazioni in proprio possesso.
Grazie.

Marco71.

...proprio stamane il mio sistema Asus P5B Deluxe WiFi/AP e processore Intel E6320, potrebbe essere rimasto "vittima" del problema.
L'ultima versione di b.i.o.s disponibile per la suddetta motherboard è del 4 aprile 2007 (1101).
Sintomo occorso, riavvio (e sembra che i problemi di invalidazione della T.L.B generino proprio reboot "casuali").
Ora darò una occhiata di "sfuggita" al documento Intel.
Quello che è certo è che regna il marasma più completo.
Nessuno prende iniziativa "sicura" e certa.
Grazie.

Marco71.

...proprio stamane il mio sistema Asus P5B Deluxe WiFi/AP e processore Intel E6320, potrebbe essere rimasto "vittima" del problema.
Sintomo occorso, riavvio (e sembra che i problemi di invalidazione della T.L.B generino proprio reboot "casuali").se il sistema era entrato in SMM è probabile, dato che al rientro si possono avere dati prelevati da locazioni di memoria errateAE30: Global Pages in the Data Transaction Lookaside buffer may not be flushed by the RSM instruction before restoring the architectural state from SMRAM

...il problema secondo quanto sto leggendo dallo specification update è che siamo arrivati nel frattempo allo step L2 ed ancora abbiamo un "Plan to fix".
L'errata a cui ci riferiamo è lo AI21 a pagina 10 del documento .pdf Intel 31327914 che reca scritto:
"Global Pages in the Data Translation Look-Aside Buffer (DTLB) May Not
Be Flushed by RSM instruction before Restoring the Architectural State
from SMRAM".
Quello che mi preoccupa è l'inerzia con cui i produttori di motherboard (ad oggi) stanno affrontando il "problema" di integrare in una versione di b.i.o..s il fix (che da Intel è stato rilasciato nello scorso aprile).
Anche Microsoft non fa assolutamente la sua parte...
Perché non affida alla "stampa" specializzata (ad esempio) un comunicato ufficiale con dettagliata descrizione del problema e della "correzione" apportata dall'aggiornamento di microcodice presente sui suoi siti web ?
Grazie.

Marco71.

Asus p5w dh delux Bios 2103 rilasciato il 22/06

Ops dimenticavo.. anche se rilasciato il 22-06 la data nel bios è del 18-05-2007

Una domanda anche installando la patch nel link riportato sopra relativo al proprio O.S., questa patch va reinstallata eventualmente ad ogni nuova installazione del S.O. su medesima macchina? o basta eseguirla una sola volta?

Saluti

Ops dimenticavo.. anche se rilasciato il 22-06 la data nel bios è del 18-05-2007

Una domanda anche installando la patch nel link riportato sopra relativo al proprio O.S., questa patch va reinstallata eventualmente ad ogni nuova installazione del S.O. su medesima macchina? o basta eseguirla una sola volta?

Saluti

Va riapplicata ad ogni reinstallazione.

Il microcodice viene caricato dal BIOS all'avvio, poi la patch si preoccupa di "aggiornarlo" a PC acceso caricando la nuova versione nel processore, ma appena si spegne il PC , come in una memoria RAM, il microcodice caricato nel processore viene cancellato e viene ricaricato all' avvio.

Ciao

Grazie per la delucidazione Anonimo Veneziano..

la cosa peggiore è che per due guru dell'informatica come Theo de Raadt e Linux Torvalds (come l'hanno chiamato nell'articolo ahahhaha) il problema ha risvolti diametralmente opposti... è un po' disorientante: allora chi ha ragione? sono bug gravi o no?

ma soprattutto: come diavolo fanno due guru così ad essere in disaccordo su una questione meramente tecnica?

Il problema sono i media, che prendono due affermazioni di due persone che discutono su due tipologie di argomenti, le mescolano e magari dicono pure che ci hanno litigato su, quando ognuno magari parlava per fatti propri.
Hanno ragione entrambi: Torvalds parlava dei bug risolvibili dal BIOS, mentre de Raadt parlava di bug che NON sono risolvibili da BIOS e richiedono una nuova revisione della CPU.

mi ricorda la questione dei Pentium 60 e 66, che avevano all'interno un bug (credo nel calcolo in virgola mobile) che portava a risultati errati nei conti: Intel si era offerta di sostituire i processori per "tutelarsi" contro eventuali azioni legali dovute a problemi correlati al bug stesso ;)

Intel non si è "offerta" ma è stata costretta da una clausola che si chiama "garanzia". Le "azioni legali correlate al bug stesso" sono poi fattibili?

Le "azioni legali correlate al bug stesso" sono poi fattibili?

le azioni legali sono fattibili se il bug è grave a tal punto da compromettere il funzionamento del prodotto, come nel caso del bug del pentium 60 il bug non era evitabile è comprometteva i risultati in maniera sistematica rendendo quindi il prodotto difettoso.

nel caso dei bug "normali" presenti nelle cpu vanno considerati come i bug dei software quindi risolti nei limiti del possibile e comunque devono essere sempre documentati e avere delle via di uscita.

le azioni legali sono fattibili se il bug è grave a tal punto da compromettere il funzionamento del prodotto, come nel caso del bug del pentium 60 il bug non era evitabile è comprometteva i risultati in maniera sistematica rendendo quindi il prodotto difettoso.


Prodotto difettoso che però ha una garanzia riconosciuta dal produttore.
In questo caso "l'azione legale" la puoi intraprendere solo se il produttore non ti vuole sostituire il prodotto in garanzia, non perchè effettivamente c'è un problema sull'hardware in se.
Del resto stiamo parlando anche di materiale consumer.

...proprio stamane il mio sistema Asus P5B Deluxe WiFi/AP e processore Intel E6320, potrebbe essere rimasto "vittima" del problema.
L'ultima versione di b.i.o.s disponibile per la suddetta motherboard è del 4 aprile 2007 (1101).
Sintomo occorso, riavvio (e sembra che i problemi di invalidazione della T.L.B generino proprio reboot "casuali").
Ora darò una occhiata di "sfuggita" al documento Intel.
Quello che è certo è che regna il marasma più completo.
Nessuno prende iniziativa "sicura" e certa.
Grazie.

Marco71.

stessa cosa successa a me proprio ieri ... avevo appena avviato il pc, finito di bootare tutto si è riavviato ...

hai patchato tu Marco?

http://www.tgdaily.com/content/view/32745/118/

we can also look at AMD's errata from their aging AMD64 technology; as of this date there have been 169 documented errata by AMD

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf

Va riapplicata ad ogni reinstallazione.

Il microcodice viene caricato dal BIOS all'avvio, poi la patch si preoccupa di "aggiornarlo" a PC acceso caricando la nuova versione nel processore, ma appena si spegne il PC , come in una memoria RAM, il microcodice caricato nel processore viene cancellato e viene ricaricato all' avvio.

Ciao

cioè il microcode non è residente nella cpu? non ho capito.. :fagiano:

...sto come si suol dire "ancora alla finestra" ad oggi...
Asus per la nostra P5B Deluxe WiFi/AP sembra non avere ancora reso disponibile alcuna versione di b.i.o.s (nemmeno "beta").
E cosa soprattutto più grave, nessuno menziona esplicitamente nelle descrizioni di b.i.o.s, "patch" di vario ordine e grado esplicitamente come dovrebbe essere fatto se è stata prevista/effettuata correzione al "problema" in oggetto.
Nelle due righe "scarne" di descrizione della release 1101 ad esempio c'è scritto "tutto" fuorché se la suddetta release integra al proprio interno la "microcode patch".
Ad oggi c'è solo lassismo, inerzia...ritardo nell'affrontare il problema (se problema da affrontare c'è/ci sia).
Prima di installare patch di "sistema operativo" che poi agiscono su sottostanti livelli, preferisco attendere la buona novella di un file di b.i.o.s che aggiorni dal livello hardware più basso il microcodice (le patch in questo caso vengono caricate nelle primissime fasi di avvio del computer, nelle fasi seguenti all'ingresso in modalità protetta del processore).
Grazie.

Marco71.

...il "microcodice" che serve per le istruzioni "complesse" del set x86/x87 è residente in logica interna al processore (di classe P6 e seguenti).
Dal Pentium PRO in poi sono stati previsti meccanismi per effettuare il bypass della logica di P.L.A che implementa il suddetto microcodice (attraverso meccanismi di "trapping" del processore).
Per avere informazioni più dettagliate potete consultare il manuale hardware del Pentium PRO ad esempio.
Thanks.

Marco71.

Questo è uno dei motivi per cui non considero Asus una azienda seria e nemmeno lontanamente i suoi prodotti come prodotti di qualità. Ogni volta che serve un BIOS con Asus c'è da penare. Mi domando se poi hanno rilasciato quel fantomatico aggiornamento per le P5B Deluxe per poter utilizzare i quad core QX6800.... :muro:

boh x intanto oggi ha rilasciato un BIOS nuovo per la Commando ... :)

Questo è uno dei motivi per cui non considero Asus una azienda seria e nemmeno lontanamente i suoi prodotti come prodotti di qualità. Ogni volta che serve un BIOS con Asus c'è da penare. Mi domando se poi hanno rilasciato quel fantomatico aggiornamento per le P5B Deluxe per poter utilizzare i quad core QX6800.... :muro:
penso che ASUS come tutti gli altri costruttori pianifichino i rilasci delle versioni di b.i.o.s. in base all'impatto che possono avere sulla base installata (e alla complessita' dello sviluppo). Se una condizione documentata da un'errata ha una bassissima probabilita' di verificarsi e i sistemi operativi sul mercato hanno attuano gia' un workaround probabilmente a questo fix verra' data una priorita' bassa.
In questo caso non saprei dire se si tratti di ASUS che puo' aver sottostimato il problema o magari di Intel che ha inviato in ritardo il microcodice ai produttori di schede madri.

cioè il microcode non è residente nella cpu? non ho capito.. :fagiano:

quando è accesa si, ma se spegni il pc perde tutto perche non una flash interna, normalmente le cpu hanno una piccola ROM con l'ultima versione del microcodice disponibile in fase di produzione della cpu, eventuali aggiornamenti sono caricati alla fase di boot dal bios o dal so ogni volta, si parla di microcodice perche sono anche solo pochi byte, mica dei software complicati.

penso che ASUS come tutti gli altri costruttori pianifichino i rilasci delle versioni di b.i.o.s. in base all'impatto che possono avere sulla base installata (e alla complessita' dello sviluppo). Se una condizione documentata da un'errata ha una bassissima probabilita' di verificarsi e i sistemi operativi sul mercato hanno attuano gia' un workaround probabilmente a questo fix verra' data una priorita' bassa.
In questo caso non saprei dire se si tratti di ASUS che puo' aver sottostimato il problema o magari di Intel che ha inviato in ritardo il microcodice ai produttori di schede madri.

Io la vedo diversamente, un bug è sempre un bug, a prescindere dalla probabilità di verificarsi. :O E poi il non poter usare dei QX6800 su alcuni modelli semplicemente perchè non c'è un BIOS non la vedo una manovra a "basso impatto" ma a "bassa assistenza" del produttore.

Io la vedo diversamente, un bug è sempre un bug, a prescindere dalla probabilità di verificarsi. :O E poi il non poter usare dei QX6800 su alcuni modelli semplicemente perchè non c'è un BIOS non la vedo una manovra a "basso impatto" ma a "bassa assistenza" del produttore.
Ovviamente anch'io la vedo dalla prospettiva dell'utente e quindi resto deluso quando un produttore non rilascia versioni di BIOS aggiornate per supportare nuovi stepping di processori o anche piu' semplicemente hard disk di capacita' maggiore o RAM a densita' piu' elevata. In sostanza (bug a parte) vorrei poter utilizzare un sistema molto piu' a lungo; troncando il supporto costringono gli utenti a cambiare MB/CPU/RAM etc.
La cosa come sottolineato da tutti si fa piu' pesante se davvero bug di un processore limita l'utilizzo di un sistema nuovo.
:muro:

...parla di micro-codice non intendendo una "quantità piccola di codice".
E' stato posto il prefisso "micro" solo per definire il livello di astrazione in riferimento all'hardware che costituisce un processore.
Grazie.

Marco71.

...previo backup della partizione di avvio di Windows XP, ho testé proceduto ad aggiornamento.
Nelle primissime fasi di caricamento del sistema operativo, il processore (di classe "Core" nella fattispecie) riceve i dati aggiornati in base ai quali provvede ad effettuare i microsalti interni.
E' evidente quindi che nell'hardware interno dal Pentium PRO in poi, è stata prevista la presenza di una sorta di "scratchpad r.a.m" in grado di rendere adattivo ed "auto correttivo" (oltre che trasparente verso il mondo esterno) il comportamento della micro r.o.m che contiene il microcodice.
E' da sottolineare che comunque, a partire dall'80486 una sempre maggiore aliquota delle istruzioni del set x86 (almeno quelle che operano su 16 e 32 bit) è stata implementata in "hard wire logic" proprio nell'ottica di comportamento "ibrido" C.I.S.C/R.I.S.C (dove per progetto tutte le istruzioni hanno lunghezza "fissa" ed esecuzione in un ciclo di clock "macchina").
Ergo il ricorso al microcodice dovrebbe essere "limitato".
Grazie.

Marco71.