Intel SL3QA - Pentium III 550 MHz Processor Specification page 45

Errata
Workaround: None identified.
Status: For the steppings affected see the Summary of Changes at the beginning of this
section.
E12. Machine
Successfully
Problem: An asynchronous machine check exception (MCE), such as a BINIT# event, which
occurs during an access that splits a 4 Kbyte page boundary, may leave some
internal registers in an indeterminate state. Thus, the MCE handler code may not
always run successfully if an asynchronous MCE has occurred previously.
Implication: An MCE may not always result in the successful execution of the MCE handler.
However, asynchronous MCEs usually occur upon detection of a catastrophic system
condition that would also hang the processor. Leaving MCEs disabled will result in the
condition which caused the asynchronous MCE instead causing the processor to enter
shutdown. Therefore, leaving MCEs disabled may not improve overall system
behavior.
Workaround: No workaround which would guarantee successful MCE handler execution under
this condition has been identified.
Status: For the steppings affected see the Summary of Changes at the beginning of this
section.
E13. MCE Due to L2 Parity Error Gives L1 MCACOD.LL
Problem: If a Cache Reply Parity (CRP) error, Cache Address Parity (CAP) error, or Cache
Synchronous Error (CSER) occurs on an access to the Pentium III processor's L2
cache, the resulting Machine Check Architectural Error Code (MCACOD) will be logged
with '01' in the LL field. This value indicates an L1 cache error; the value should be
'10', indicating an L2 cache error. Note that L2 ECC errors have the correct value of
'10' logged.
Implication: An L2 cache access error, other than an ECC error, will be improperly logged as an L1
cache error in MCACOD.LL.
Workaround: None identified.
Status: For the steppings affected see the Summary of Changes at the beginning of this
section.
E14. LBER May Be Corrupted After Some Events
Problem: The last branch record (LBR) and the last branch before exception record (LBER) can
be used to determine the source and destination information for previous branches or
exceptions. The LBR contains the source and destination addresses for the last
branch or exception, and the LBER contains similar information for the last branch
taken before the last exception. This information is typically used to determine the
location of a branch which leads to execution of code which causes an exception.
However, after a catastrophic bus condition which results in an assertion of BINIT#
and the re-initialization of the buses, the value in the LBER may be corrupted. Also,
Specification Update
Check Exception Handler May Not Always Execute
45