Specification Update
MOBILE INTEL
®
CELERON
®
PROCESSOR at 466 MHz, 433 MHz, 400 MHz,
366 MHz, 333 MHz, 300 MHz, 266 MHz SPECIFICATION UPDATE
45
H58. Memory Aliasing with Inconsistent A and D Bits May Cause
Processor Deadlock
Problem: In the event that software implements memory aliasing by having two Page Directory Entries(PDEs)
point to a common Page Table Entry (PTE) and the Accessed and Dirty bits for the two PDEs are allowed to
become inconsistent the processor may become deadlocked.
Implication: This erratum has not been observed with commercially available software.
Workaround: Software that needs to implement memory aliasing in this way should manage the consistency
of the Accessed and Dirty bits.
Status: For the steppings affected see the Summary of Changes at the beginning of this section.
H59. Use of Memory Aliasing with Inconsistent Memory Type May
Cause System Hang
Problem: Software that implements memory aliasing by having more than one linear addresses mapped to
the same physical page with different cache types may cause the system to hang. This would occur if one of the
addresses is non-cacheable used in code segment and the other a cacheable address. If the cacheable
address finds its way in instruction cache, and non-cacheable address is fetched in IFU, the processor may
invalidate the non-cacheable address from the fetch unit. Any micro-architectural event that causes instruction
restart will expect this instruction to still be in fetch unit and lack of it will cause system hang.
Implication: This erratum has not been observed with commercially available software.
Workaround: Although it is possible to have a single physical page mapped by two different linear addresses
with different memory types, Intel has strongly discouraged this practice as it may lead to undefined results.
Software that needs to implement memory aliasing should manage the memory type consistency.
Status: For the steppings affected see the Summary of Changes at the beginning of this section.
H60.
Processor may Report Invalid TSS Fault Instead of Double
Fault During Mode C Paging
Problem: When an operating system executes a task switch via a Task State Segment (TSS) the CR3
register is always updated from the new task TSS. In the mode C paging, once the CR3 is changed the
processor will attempt to load the PDPTRs. If the CR3 from the target task TSS or task switch handler TSS is
not valid then the new PDPTR will not be loaded. This will lead to the reporting of invalid TSS fault instead of
the expected Double fault.
Implication: Operating systems that access an invalid TSS may get invalid TSS fault instead of a Double
fault.
Workaround: Software needs to ensure any accessed TSS is valid.
Status: For the steppings affected see the Summary of Changes at the beginning of this section.