31 bug HW per Prescott

[Yagami]

Originariamente inviato da Thunder82
Come da titolo, alcuni sono risolvibili con update dei BIOS delle mobo, altri sono legati proprio alla CPU e possono essere risolti solo con un nuovo step del core.

http://www.intel.com/design/pentium4...t/30235203.pdf

R1 X X No Fix Transaction Is Not Retried after BINIT#
R2 X X No Fix Invalid Opcode 0FFFh Requires a ModRM Byte
R3 X X No Fix Processor May Hang Due to Speculative Page Walks to Non-Existent System Memory
R4 X X No Fix Memory Type of the Load Lock Different from Its Corresponding Store Unlock
R5 X X No Fix Machine Check Architecture Error Reporting and Recovery May Not Work As Expected
R6 X X No Fix Debug Mechanisms May Not Function as Expected
R7 X X No Fix Cascading of Performance Counters Does Not Work Correctly When Forced Overflow Is
Enabled
R8 X X No Fix EMON Event Counting of x87 Loads May Not Work As Expected
R9 X X No Fix System Bus Interrupt Messages without Data Which Receive a HardFailure Response May
Hang the Processor
R10 X X No Fix The Processor Signals Page-Fault Exception (#PF) Instead of Alignment Check Exception
(#AC) on an Unlocked CMPXCHG8B Instruction
R11 X X No Fix FSW May Not Be Completely Restored after Page Fault on FRSTOR or FLDENV Instructions
R12 X X No Fix Processor Issues Inconsistent Transaction Size Attributes for Locked Operation
R13 X X No Fix When the Processor Is in the System Management Mode (SMM), Debug Registers May Be
Fully Writeable
R14 X X No Fix Shutdown and IERR# May Result Due to a Machine Check Exception on a Hyper-Threading
Technology Enabled Processor
R15 X X No Fix Processor May Hang under Certain Frequencies and 12.5% STPCLK# Duty Cycle
R16 X X No Fix
System May Hang if a Fatal Cache Error Causes Bus Write Line (BWL) Transaction to Occur
to the Same Cache Line Address as an Outstanding Bus Read Line (BRL) or Bus Read-
Invalidate Line (BRIL}
R17 X X No Fix A Write to APIC Registers Sometimes May Appear to Have Not Occurred
R18 X Fixed Some Front Side Bus I/O Specifications are not Met
R19 X X No Fix Parity Error in the L1 Cache May Cause the Processor to Hang
R20 X Fixed BPM4# Signal Not Being Asserted According to Specification
R21 X X No Fix Sequence of Locked Operations Can Cause Two Threads to Receive Stale Data and Cause
Application Hang
R22 X X Plan Fix A 16-bit Address Wrap Resulting from a Near Branch (Jump or Call) May Cause an Incorrect
Address to be Reported to the #GP Exception Handler
R23 X X No Fix Bus Locks and SMC Detection May Cause the Processor to Temporarily Hang
R24 X Fixed PWRGOOD and TAP Signals Maximum Input Hysteresis Higher Than Specified
R25 X X Plan Fix Incorrect Physical Address Size Returned by CPUID Instruction
R26 X X No Fix Incorrect Debug Exception (#DB) May Occur When a Data Breakpoint is set on an FP
Instruction
R27 X X No Fix xAPIC May Not Report Some Illegal Vector Errors
R28 X X Plan Fix Enabling No-Eviction Mode (NEM) May Prevent the Operation of the Second Logical
Processor in a Hyper-Threading Technology Enabled Processor
R29 X X Plan Fix Incorrect Duty Cycle is Chosen when On-Demand Clock Modulation is Enabled in a Processor
Supporting Hyper-Threading Technology
R30 X X No Fix Memory Aliasing of Pages as Uncacheable Memory Type and Write Back (WB) May Hang the
System
R31 X X Plan Fix Interactions Between the Instruction Translation Lookaside Buffer (ITLB) and the Instruction
Streaming Buffer May Cause Unpredictable Software Behavior


Per le implicazioni leggete il .pdf

Ma alla fine, il prescott ha qualche lato positivo??
Sembra che per farlo rendere bisogna tenerlo moolto fresco e sotto oc, oppure tanto vale prendere il caro NW

[Necromachine]

Solo un altro motivo per non comprare un precotto ... comunque Intel è veramente alla frutta, spero che questo triste capitolo della sua storia delle CPU venga chiuso al più presto e ritorni ai fasti di un tempo ...

[Dumah Brazorf]

Cavolo, 1 bug per stadio delle pipeline!
Il caso a volte è geniale nel suo imperscutabile moto!
Ciao.

[Athlon 64 3000+]

Alla Intel mi sa che si sono spaccati in due.Mi chiedo come mai facciano così.
Fanno una CPU per Desktop che oltre ad essere un forno è anche più lento del Northwood ed ora ha anche parecchi bug.
Dall'Altra nel mercato mobile tira fuori una CPU con i Contro*******i come Il Pentium M banias e poi si migliora con il Dothan che è molto competitivo con L'Athlon 64 nel mercato mobile.

[zerothehero]

per gli esperti: è normale 31 bug per un processore o sono troppi?

[winnertaco]

Originariamente inviato da zerothehero
per gli esperti: è normale 31 bug per un processore o sono troppi?

sono sopra la media direi!

[Marco71]

Secondo me la quantità di errata presenti ad oggi nei vari stepping di nucleo Prescott non possono quantificare in nessun modo la bontà o meno del progetto...
Secondo me c'è troppa enfasi su questo elenco di "bug" sia da parte della stampa specializzata su carta od anche in giro per il web (sia in Italiano che all'estero)...
Vi stupireste se deste uno sguardo ad esempio alla quantità di "errata" presenti nelle varie release delle specifications update rilasciate da Intel per i numerosi stepping di Pentium III, in tutte le sue incarnazioni dallo slot 1 sino al nucleo Tualatin...
All'epoca però NON C'ERA tutto questo pandemonio solo chi si è letto nel corso del tempo le suddette "spec. update" si sarà reso conto di quanti errori fossero presenti...e moltissimi continuano hanno usato ed usano ad oggi tali processori sia dekstop che mobile (io sono uno di quelli con un Pentium III 866EB e vi posso garantire che quanto a stabilità (niente pratiche di overclock et simila) è granitica)...
L'enfasi per il Prescott è solo dovuta a due fattori:
1) l'esosità in termini di potenza assorbita (watt)
2) l'eccessiva penalità in termini di prestazioni dovuta principalmente ai 31 stadi di pipeline...
Sono sicuro che se fosse generalmente stato migliore da subito rispetto a Northwood (per non andare ald di fuori di Intel) ci sarebbe stata molta meno attenzione al fatto...
E poi ribadisco, ho dato una occhiata alla documentazione fornita dai costruttori di c.p.u sia con set di istruzioni x86 che non e devo dire che quanto a completezza solo Intel primeggia...
Non per dire ma davvero pensate che i processori di A.M.D non abbiano errata ? Il problema è che A.M.D ha molta meno documentazione disponibile all'utente finale...

Marco.

[Rojaus]

Anche amd fornisce documentazione sugli errata a seconda della cpu e della revisione !!

[Rojaus]

http://www.amd.com/us-en/assets/cont...docs/25759.pdf


questa e' la documentazione contenente gli errata x athlon 64

[Marco71]

Grazie Rojaus!
Quindi potete vedere che anche per A.M.D (come per qualsiasi altro costruttore di circuiti integrati complessi quali i microprocessori) ha parecchie errata presenti nelle sue c.p.u...
E se leggete bene per alcune di esse di parla di possibili situazioni di deadlock ecc.
Questo mette ancora più in risalto l'importanza di avere prima che un s.o "stabile" ed affidabile un livello sottostante hardware di pari se non maggiore affidabilità e stabilità.

Marco.

[ciccio88]

dire 31 è relativo, bisogna vedere in genere quanti sn i bug x un core di nuova produzione

[Dardalo]

Che si siano errori è normale.

Che questi possano o meno essere risolti con BIOS o step successivi anche.

Che un processore teoricamente nuovo vada peggio di uno vecchio quasi anche (in fondo Intel l'ha già fatto)

Che tutti si debba essere contenti di questo, francamente mi pare eccessivo...

[jappilas]

Originariamente inviato da Dardalo
Che tutti si debba essere contenti di questo, francamente mi pare eccessivo...

ho la sensazione che se tale lista fosse uscita da AMD, sarebbero tutti a strapparsi i capelli...

[Dr. Halo]

il problema è sempre il solito: dando per scontato che se compro una cpu nuova mi aspetto che questa funzioni al 100% per come doveva essere progettata ma nel 100% dei casi non lo fa (e questo per amd, intel, via e chi più ne ha più ne metta), e dando per scontato che la maggior parte degli errori che compie vengono aggirati dal bios per non farlgieli commettere, a me utente finale: che caspita me ne importa che abbia 1 errrata o 1000 errata... basta che per fare ciò che devo fare io vada bene. Se non da problemi tutto ok. Almeno io la vedo così.

[jappilas]

Originariamente inviato da Dr. Halo
il problema è sempre il solito: dando per scontato che se compro una cpu nuova mi aspetto che questa funzioni al 100% per come doveva essere progettata ma nel 100% dei casi non lo fa (e questo per amd, intel, via e chi più ne ha più ne metta), e dando per scontato che la maggior parte degli errori che compie vengono aggirati dal bios per non farlgieli commettere, a me utente finale: che caspita me ne importa che abbia 1 errrata o 1000 errata... basta che per fare ciò che devo fare io vada bene. Se non da problemi tutto ok. Almeno io la vedo così.

anche per me sarebbe tutto ok, finchè il sistema faccia girare i programmi che mi servono, e appunto per qualche bug del genere non venga compromessa apprezzabilemente la compatibilità ...
mi viene l' impressione che se i produttori non pubblicassero le liste degli errata, per gli utenti sarebbe meglio... tanto ci potrebbero fare ben poco, quindi sarebbero inc@zz@ture e "patemi" risparmiati...

[Marco71]

La documentazione con gli errata ed i possibili workaround viene resa di pubblico dominio secondo me in larga misura per i progettisti di schede madri e per i programmatori dei b.i.o.s...
La lista degli errata è una prassi da molto tempo, come minimo Intel la ha resa disponibile sul proprio sito a partire dall'80386 (se non prima ma all'epoca la diffusione era molto minore data la non ancora larghissima diffusione di connessioni ad Internet)...infatti la Intel stampava un mucchio di manualoni (io ad esempio ho i tre vol. del Pentium Pro che comunque non includono le errata).

Marco.

[jappilas]

Originariamente inviato da Marco71
La documentazione con gli errata ed i possibili workaround viene resa di pubblico dominio secondo me in larga misura per i progettisti di schede madri e per i programmatori dei b.i.o.s...
La lista degli errata è una prassi da molto tempo, come minimo Intel la ha resa disponibile sul proprio sito a partire dall'80386 (se non prima ma all'epoca la diffusione era molto minore data la non ancora larghissima diffusione di connessioni ad Internet)...infatti la Intel stampava un mucchio di manualoni (io ad esempio ho i tre vol. del Pentium Pro che comunque non includono le errata).

Marco.

infatti..
... oltre i prog di bios, e designer delle MB, considererei anchegli sviluppatori di applicazioni (se io scrivo un sw di calcolo scientifico, mi può interessare che la cpu abbia o meno bug riguardanti l' unità FPU e se esistono o meno dei workaround)
però gli utenti normali (finali) di tali informazioni spesso non se ne fanno nulla, anche perchè a volte il bug avrebbe di suo un' incidenza oggettiva statisticamente irrilevante... in tali casi i media fanno sentire il problema maggiore di quanto non sia e l' unico effetto è di instillare false preoccupazioni e stimolare l' animosità di parte in alcuni

[Dardalo]

Originariamente inviato da jappilas
ho la sensazione che se tale lista fosse uscita da AMD, sarebbero tutti a strapparsi i capelli...

Non credo affatto che, fra chi i pc li conosce, sarebbe successo: concettualmente comunque il mio discorso era in generale sul prescott che, IMHO, mi ricorda tanto il willy, cioé il primo P4, più lento sempre e comunque del PIII che andava a sostituire...

Poi è migliorato, e anche molto, ma all'inizio lo si vendeva solo x' era intel...

Ovvio che una casa prodruttrice, dopo aver investito miliardi, sia costretta venderlo, affidandosi a chi di pc non capisce nulla e, andando al negozio o all'ipermercato, leggete "Nuovissimo Prescott 3,0 Ghz, 1 MB" magari scritto in neretto, e che costa solo 100 € in più dello stesso pc con il northwood...

Sono le stesse persone che comprano la 9200 (e prima ancora la GeForce 2 MX) associata ad un P4 (northwood magari ) da 3,2 Ghz...

O sbaglio di tanto?

[Goldrake_xyz]

Ok, grazie a Thunder82 x le informazioni, che sono sempre
molto apprezzate, e anche grazie a Marco71 x le sue precise
osservazioni...
Se non ci scambiamo informazioni importanti, questo diventerebbe
un forum di pettegolezzi ! ___

Secondo mè, la fase di testing di una cpu "dovrebbe" essere
un pò più approfondita ... ok ?
Visto e considerato che non è la prima volta che le grandi
factory di CPU cadono così facilmente in questi problemi.

Se da un lato, la proggettazione dei vecchi processori (8086)
non richiedeva particolari sforzi, vista anche la semplicità
di questi, è ben diversa la situazione sui nuovi prodotti !
E riguardo ai Bug, và detto per inciso, che si deve anche
considerare il grado di rischio degli stessi !

Se il Procio si pianta su un' istruzione MOV EAX,EBX
rivoglio indietro i soldi da Intel x Truffa aggravata !
Se invece sbaglia qualche instruzione, che in pratica non
verrà mai usata, allora ... bè ... mah ... però ... uhm...
In ogni caso i bug che danno come risultato l'hang up del
sistema sarebbe meglio evitarli ...!


Il problema fondamentale è che Intel non ha cambiato
il "core" delle instruzioni da Northwood a Precott (eccetto le sse3)
e quindi ci si attendeva un processore più stabile !
Diverso è il discorso x AMD che ha introdotto i 64 Bit ....

Ah, un ultimo commento .....
Questi sono i bug "UFFICIALI", ma .... quanti sono quelli
che sono stati "omessi ?" ....


Ciao....

[Marco71]

Thanks Goldrake_xyz! Meno male che il mio piccolo cervello qualche volta serve a qualche cosa!
Comunque per testare esaustivamente il funzionamento di un microprocessore bisognerebbe generare un insieme Universo contenente tutto il set di istruzioni eseguibili e per ognuna di esse utilizzare ogni possibile combinazione di operandi e modi di indirizzamento ecc., ecc.
Ad esempio ho ultimamente letto un interessantissimo articolo sulla verifica formale del Pentium 4 (la prima gen. su socket 423)...l'operatività funzionale della c.p.u è stata simulata su un cluster di computer dove ad ogni nodo veniva deputata la simulazione di un sottoinsieme del microprocessore...molto interessante ma anche sconfortante verificare che nemmeno dopo simulazioni, prove sul "campo" di campioni pre-serie ecc. sia possibile garantire la rispondenza della c.p.u al capitolato di progetto...come detto era semplice simulare l'8086 con circa 29000 transistors NMOS ma molto più complicato per c.p.u con decine di milioni di transistors...pensate al povero S.P.I.C.E che ne debba calcolare il punto di funzionamento!
Questo sarà sempre più un grosso problema...anche se devo dire che la logica di un microprocessore odierno è solo un subset piccolo tra l'altro...la maggior parte è circuiteria per memorie cache,p.l.l ecc.
Mi piacerebbe sapere se nessuno di voi conosce l'esatta costituzione della micro-r.o.m che anche nel Pentium 4 contiene il microprogramma per l'esecuzione delle istruzioni del set non traducibili in micro-ops...
Mi piacerebbe anche sapere quali sono cotali istruzioni dalla "enorme" complessità decodificativa...

Marco.