Specification Update

R
Mobile IntelĀ® CeleronĀ® Processor Specification Update 55
Implication: When this erratum occurs, the values for FPUDataPointer in the saved floating point image or floating
point environment structure may appear to be random values. Executing any non-control FP instruction
with memory operand will initialize the FPUDataPointer. Intel has not observed this erratum with any
commercially available software.
Workaround: After initialization, do not expect the FPUDataPointer in a floating point state or floating point
environment saved memory image to be correct, until at least one non-control FP instruction with a
memory operand has been executed.
Status: For the steppings affected, see the Summary Tables of Changes.
M84. FSTP (Floating Point Store) Instruction Under Certain Conditions May Result In
Erroneously Setting a Valid Bit on an FP (Floating Point) Stack Register
Problem: An FSTP instruction with an PDE/PTE (Page Directory Entry/Page Table Entry) A/D bit update
followed by user mode access fault due to a code fetch to a page that has supervisor only access
permission may result in erroneously setting a valid bit of an FP stack register. The FP top of stack
pointer is unchanged.
Implication: This erratum may cause an unexpected stack overflow.
Workaround: User mode code should not count on being able to recover from illegal accesses to memory regions
protected with supervisor only access when using FP instructions.
Status: For the steppings affected, see the Summary Tables of Changes.
M85. Invalid Entries in Page-Directory-Pointer-Table Register (PDPTR) May Cause
General Protection (#GP) Exception if the Reserved Bits are Set to One
Problem: Invalid entries in the Page-Directory-Pointer-Table Register (PDPTR) that have the reserved bits set to
one may cause a General Protection (#GP) exception.
Implication: Intel has not observed this erratum with any commercially available software.
Workaround: Do not set the reserved bits to one when PDPTR entries are invalid.
M86. Writing the Local Vector Table (LVT) when an Interrupt is Pending May Cause an
Unexpected Interrupt
Problem: If a local interrupt is pending when the LVT entry is written, an interrupt may be taken on the
new interrupt vector even if the mask bit is set.
Implication: An interrupt may immediately be generated with the new vector when a LVT entry is written, even if the
new LVT entry has the mask bit set. If there is no Interrupt Service Routine (ISR) set up for that vector
the system will GP fault. If the ISR does not do an End of Interrupt (EOI) the bit for the vector will be
left set in the in-service register and mask all interrupts at the same or lower priority.
Workaround: Any vector programmed into an LVT entry must have an ISR associated with it, even if that vector was
programmed as masked. This ISR routine must do an EOI to clear any unexpected interrupts that may
occur. The ISR associated with the spurious vector does not generate an EOI, therefore the spurious
vector should not be used when writing the LVT.
Status: For the steppings affected, see the Summary Tables of Changes.