Specification Update

R
Mobile Intel® Celeron® Processor Specification Update 29
Status: For the steppings affected see the Summary of Changes at the beginning of this section.
M9.
Machine Check Exception Handler May Not Always Execute Successfully
Problem: 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.
Implication: No workaround, which would guarantee successful MCE handler execution under this condition, has
been identified.
Workaround: If branch trap functionality is desired, BTMs must be disabled.
Status: For the steppings affected see the Summary of Changes at the beginning of this section.
M10.
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 mobile 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.
M11.
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, after either a CALL which
results in a fault or a software interrupt, the LBER and LBR will be updated to the same value, when the
LBER should not have been updated.
Implication: The LBER and LBR registers are used only for debugging purposes. When this erratum occurs, the
LBER will not contain reliable address information. The value of LBER should be used with caution
when debugging branching code; if the values in the LBR and LBER are the same, then the LBER value
is incorrect. Also, the value in the LBER should not be relied upon after a BINIT# event.
Workaround: None identified
Status: For the steppings affected see the Summary of Changes at the beginning of this section.