Intel SL3VS - Celeron 633 MHz Processor Specification page 60

®
INTEL CELERON® PROCESSOR SPECIFICATION UPDATE
C55. MCE Due to L2 Parity Error Gives L1 MCACOD.LL
If a Cache Reply Parity (CRP) error, Cache Address Parity (CAP) error, or Cache Synchronous
Problem:
Error (CSER) occurs on an access to the Celeron 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.
An L2 cache access error, other than an ECC error, will be improperly logged as an L1 cache
Implication:
error in MCACOD.LL.
None identified
Workaround:
For the steppings affected, see the Summary of Changes at the beginning of this section.
Status:
C56. EFLAGS Discrepancy on a Page Fault After a
Multiprocessor TLB Shootdown
This erratum may occur when the Celeron processor executes one of the following read-modify-
Problem:
write arithmetic instructions and a page fault occurs during the store of the memory operand: ADD, AND, BTC,
BTR, BTS, CMPXCHG, DEC, INC, NEG, NOT, OR, ROL/ROR, SAL/SAR/SHL/SHR, SHLD, SHRD, SUB,
XOR, and XADD. In this case, the EFLAGS value pushed onto the stack of the page fault handler may reflect
the status of the register after the instruction would have completed execution rather than before it. The
following conditions are required for the store to generate a page fault and call the operating system page fault
handler:
1. The store address entry must be evicted from the DTLB by speculative loads from other instructions that
hit the same way of the DTLB before the store has completed. DTLB eviction requires at least three-load
operations that have linear address bits 15:12 equal to each other and address bits 31:16 different from
each other in close physical proximity to the arithmetic operation.
2. The page table entry for the store address must have its permissions tightened during the very small
window of time between the DTLB eviction and execution of the store. Examples of page permission
tightening include from Present to Not Present or from Read/Write to Read Only, etc.
3. Another processor, without corresponding synchronization and TLB flush, must cause the permission
change.
This scenario may only occur on a multiprocessor platform running an operating system that
Implication:
performs "lazy" TLB shootdowns. The memory image of the EFLAGS register on the page fault handler's
stack prematurely contains the final arithmetic flag values although the instruction has not yet completed. Intel
has not identified any operating systems that inspect the arithmetic portion of the EFLAGS register during a
page fault nor observed this erratum in laboratory testing of software applications.
No workaround is needed upon normal restart of the instruction, since this erratum is
Workaround:
transparent to the faulting code and results in correct instruction behavior. Operating systems may ensure that
no processor is currently accessing a page that is scheduled to have its page permissions tightened or have a
page fault handler that ignores any incorrect state.
For the steppings affected, see the Summary of Changes at the beginning of this section.
Status:
52