[capitan_crasy]

Descrizione del Bug denominato "Erratum 298":

"The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."

Per maggiori informazioni Clicca qui...

Originariamente inviato da bjt2

Allora... Traduzione all buona...
Quando un processo deve scrivere una qualsiasi locazione di memoria, la CPU va a settare un bit nella page table entry corrispondente per dire che in quella pagina almeno un byte è stato modificato, così che se il SO deve buttarla fuori nel file di swap, la deve prima scrivere fisicamente su disco. Se nulla è stato modificato, può semplicemente sovrascriverla. Poi c'è anche il bit di accesso che dice se una pagina è stata acceduta di recente e serve per decidere se deve essere scartata, quindi è modificato ad ogni accesso anche in lettura. Teoricamente questa operazione dovrebbe essere atomica. Invece solo per la TLB di secondo livello, se avviene un altro accesso in memoria che richiede una nuova entry TLB nella TLB di livello 2, una entry deve essere buttata fuori e scritta in cache L3. Se la entry che deve essere buttata fuori è proprio quella appena modificata, può darsi che venga scritta la versione vecchia e non la nuova, corretta! Questo è in sintesi il baco.
La cosa importante è che il fix è almeno la disabilitazione del caching delle TLB, cosa che già è richiesta per uno dei due bachi noti a settembre. Se questa cosa è sufficiente, allora vuol dire che le BIOS attuali non contengono ancora il workaround per almeno uno dei due bugs di Settembre che ho menzionato, perchè in AMD dicono che ci vuole un aggiornamento, ergo le BIOS attuali ancora non lo contengono. Se il workaround non è solo questo, allora è possibile che i bugs di settembre siano stati corretti, ma comunque indipendentemente da questi è necessario un nuovo workaround aggiuntivo e comunque l'unico modo per sapere se i due bugs di settembre sono già corretti è chiedere ai produttori di MB (vero CORSINI?!?! )...

A questo punto io credo che nessun produttore di MB abbia ancora implementato nessuno dei workaround e questo calo del 10/20% è da attribuire ai workaround per tutti e tre i bugs e AMD tramite un'abile mossa di marketing sta facendo credere che il bug sia uno solo, anche perchè i non tecnici non se ne fregano se sono uno o 100... Sanno solo che ci sono...

Originariamente inviato da bjt2

Ho letto il proseguio del link passatomi dal capitano...

In pratica se i bit accessed e dirty non venissero toccati, il bug non si verificherebbe. La patch opera emulando i bit A e D in software: al primo accesso o alla prima scrittura viene generato un page fault e i bit A e D simulati vengono memorizzati dal SO (e non dalla CPU in automatico) in altri bit liberi della page table entry. Quindi c'è un calo di prestazioni perchè è come se i bit li dovesse scrivere il SO e non la CPU in hardware, ma è contenuto perchè deve essere fatto solo per il primo accesso in lettura o il primo accesso in scrittura... ma invece di farlo la CPU al volo, deve essere chiamata una routine del SO, quindi invece di 1-2 cicli di clock, ce ne vogliono qualche decina (forse anche un centinaio)... Ma solo per il primo accesso in lettura e uno in scrittura. Poichè il biti di accesso è azzerato periodicamente e quello Dirty è azzerato quando la pagina è scritta fisicamente su disco, ogni tanto qualche pagina sperimenta questo overhead... Si spera una volta ogni qualche secondo...

Domanda di MonsterMash:

Io non capisco...
Tutti i test visti fino ad oggi non avevano castrazione da parte del bios, eppure erano deludenti. L'introduzione del workaround (per chi vorrà usarlo) abbasserà ulteriormente le prestazioni.
Lo step b3 renderà semplicemente non necessario l'uso del workaround, ma non vedo proprio perchè dovrebbe andare meglio del b2. A meno che non introduca anche ottimizzazioni di altro genere (ma ne dubito molto fortemente, perchè queste non sono cose che si fanno tra uno step e un altro...).

Originariamente inviato da bjt2

Perchè lo step B2 ha altri due bug scoperti PRIMA di settembre, data a cui risale il documento contenente gli errata e che NON CONTIENE il bug 298, scoperto, sembra, a metà novembre, che si corregge ora. Io supposi, e lo suppongo ancora, che i BIOS attuali correggano quei due bug di settembre, che comunque sono gravi. Questo è un bug aggiuntivo e AMD ha colto la palla al balzo per unificare i 3 bug, dal punto di vista mediatico... Quindi lo step B3 correggerà tutti i bugs gravi, e non ci sarà più bisogno di quei workaround...

P.S.: AMD ha specificato di NON mettere nel BIOS l'opzione per disabilitare il workaround, perchè lo farà della utility OverDrive...

Domanda di MonsterMash:

A quanto ho capito io invece li risolve tutti e tre:
E cmq, anche gli altri due bug non dovrebbero pesare sulle prestazioni, ma solo sulla stabilità.

Originariamente inviato da bjt2

Partiamo dal presupposto dei documenti di Settembre 2007. In quei documenti erano elencati degli errata gravi, che portano anche a cali di prestazioni (le mie considerazioni le ha riportati il capitano in uno dei post in prima pagina). Quindi si ha:
- Quegli errata, se non corretti portano a corruzione di dati e blocchi di sistema.
- Sono stati scoperti prima di settembre 2007 e inclusi nel documento AMD.
- Il Phenom è uscito il 19 Novembre, quindi i produttori di MB hanno avuto tutto il tempo di preparare i BIOS.
- Poichè sono dei bachi che portano instabilità, dovrebbero essere corretti in un BIOS da produzione e per il daily use.
- I workaround portano a decrementi prestazionali: non ci sono santi. Perchè disabilitano delle funzionalità che accelerano le prestazioni.
- Nessun sistema ha esibito quei problemi, quindi si può supporre che i BIOS attuali abbiano quei due bugs corretti.
- Lo step B3 è esente da questi 3 bugs (e si spera anche di quello della divisione intera) e quindi non ha bisogno dei workaround, perciò dovrebbero essere più veloci.

Bug Step Ba "Barcelona":

Originariamente inviato da bjt2

Ecco i bachi del BA che non ci sono nel B2:

274 IDDIO Specification Exceeded During Power-Up Sequencing
Description
Processor current consumption may exceed the IDDIO maximum specified for C0/S0 operation during power-up sequencing.
Potential Effect on System
None expected if the VDDIO voltage regulator is sourced by a RUN (running) plane from the power supply during power-up sequencing. Otherwise, during power-up sequencing the VDDIO voltage regulator may shut down if IDDIO exceeds the platform budget or the power supply may shut down if
the SUS (suspend) rail current capacity is exceeded.
Suggested Workaround
Three options exist to ensure the VDDIO voltage regulator is sourced with sufficient current during processor power-up sequencing:
1. Enable the VDDIO voltage regulator after POWER_GOOD is asserted from the high-current (RUN) source rail.
2. Provide a path for a high-current (RUN) rail to source current to the VDDIO voltage regulator prior to POWER_GOOD assertion from the high-current (RUN) rail. This solution assumes the high-current (RUN) rail is enabled early enough relative to enabling the VDDIO voltage regulator.
3. Choose a power supply with increased capacity for the rail sourcing the VDDIO voltage regulator during power-up sequencing. The capacity required is system specific and should allocate 7 amps per processor in the power budget. The following is an example of a supply current capacity calculation assuming a 5 V suspend rail and 3 W rest of system power for a single-processor system. Other platform-specific factors such as power supply or regulator efficiencies should also be considered.
• Rest of system (non-processor) power = 3 W
• Processor power = 7 A/processor * 1 processor * 1.8 V = 12.6 W
• Source rail capacity = (rest of system power + processor power) / source rail voltage; (3 W + 12.6 W) / 5 V = 3.12 A
Fix Planned
Yes


Il fix non impatta le prestazioni: rende solo il boot un po' più complicato.


278 Incorrect Memory Controller Operation In Ganged Mode
Description
The DRAM controller 0 (DCT0) and DRAM controller 1 (DCT1) refresh counters may not be initialized to the same value using hardware controlled DRAM initialization when operating in ganged mode.
Potential Effect on System
Incorrect memory controller operation.
Suggested Workaround
BIOS should apply the following workaround prior to DRAM training when using hardwarecontrolled DRAM initialization and F2x110[4] (DctGangEn) is set to 1b.
1. Disable automatic refresh cycles by setting F2x08C[18] (DisAutoRefresh) to 1b.
2. Begin DRAM initialization by setting F2x090[0] to 1b.
3. Poll F2x090[0] until it reads 0b then wait at least 50 microseconds.
4. Enable automatic refresh cycles by clearing F2x08C[18] (DisAutoRefresh) to 0b.
5. Disable automatic refresh cycles by setting F2x08C[18] (DisAutoRefresh) to 1b.
6. Enable automatic refresh cycles by clearing F2x08C[18] (DisAutoRefresh) to 0b.
7. Begin DRAM training.
In addition, when resuming from S3, BIOS should apply the following workaround.
1. Disable automatic refresh cycles by setting F2x08C[18] (DisAutoRefresh) to 1b.
2. Initiate exit from self refresh by setting F2x090[1] to 1b.
3. Poll F2x090[1] until it reads 0b then wait at least 50 microseconds.
4. Enable automatic refresh cycles by clearing F2x08C[18] (DisAutoRefresh) to 0b.
5. Disable automatic refresh cycles by setting F2x08C[18] (DisAutoRefresh) to 1b.
6. Enable automatic refresh cycles by clearing F2x08C[18] (DisAutoRefresh) to 0b.
Fix Planned
Yes


Anche questo non impatta le prestazioni: rende più complicato il boot e il resume da standby, ma nulla di preoccupante



279 HyperTransport™ Link RTT and RON Specification Violations
Description
The RTT and RON specifications for the HyperTransport™ link may be violated on some processor revisions.
Potential Effect on System
These violations do not result in any other HyperTransport™ link electrical specification violations.
There are no known functional failures related to this problem.
Suggested Workaround
None required.
Fix Planned
Yes.

Questo errata non da particolari problemi...