Polemiche sui bug delle cpu Core 2 Duo

Polemiche sui bug delle cpu Core 2 Duo

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

di pubblicata il , alle 15:56 nel canale Processori
 
I migliori sconti su Amazon oggi
-46%

Echo Dot (Ultimo modello) | Altoparlante intelligente Wi-Fi e Bluetooth, suono più potente e dinamico, con Alexa | Blu notte

64.99 34.99€ Compra ora
-50%

Ring Intercom di Amazon | Trasforma il tuo citofono in un sistema intelligente con apertura a distanza, audio bidirezionale, accesso per gli ospiti | Facile da installare | Compatibile con Alexa

99.99 49.99€ Compra ora
-8%

acer, notebook Portatile, Ryzen7 5700u, fino a 4,3 Ghz, Ram 32 Gb, SSD PCI Nvme da 512Gb, Display Led 15,6" FHD, 4 usb, wi-fi 6, lan, bt, hdmi Win11, Preconfigurato, garanzia Italia

599.00 549.00€ Compra ora
80 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Marco7104 Luglio 2007, 21:08 #71

Ciao K Reloaded...

...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.
Marco7104 Luglio 2007, 21:19 #72

Dunque...

...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.
mjordan05 Luglio 2007, 01:58 #73
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....
K Reloaded05 Luglio 2007, 02:48 #74
boh x intanto oggi ha rilasciato un BIOS nuovo per la Commando ...
Octane05 Luglio 2007, 09:29 #75
Originariamente inviato da: mjordan
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....

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.
coschizza05 Luglio 2007, 10:27 #76
Originariamente inviato da: Energy++
cioè il microcode non è residente nella cpu? non ho capito..


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.
mjordan05 Luglio 2007, 10:52 #77
Originariamente inviato da: Octane
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. 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.
Octane05 Luglio 2007, 11:02 #78
Originariamente inviato da: mjordan
Io la vedo diversamente, un bug è sempre un bug, a prescindere dalla probabilità di verificarsi. 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.
Marco7105 Luglio 2007, 11:15 #79

Si...

...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.
Marco7107 Luglio 2007, 15:32 #80

Piccolo aggiornamento...

...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.
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^