Dual-Core Intel Xeon Processor 2.80 GHz Specification Update

Dual-Core Intel
®
Xeon
®
Processor 2.80 GHz Specification Update 13
Errata
Errata
D1. Transaction is not retired after BINIT#
Problem: If the first transaction of a locked sequence receives a HITM# and DEFER# during the snoop phase
it should be retried and the locked sequence restarted. However, if BINIT# is also asserted during
this transaction, the transaction will not be retried.
Implication: When this erratum occurs, locked transactions will not be retried.
Workaround: None identified.
Status: For the steppings affected, see the Summary Table of Changes.
D2. Invalid opcode 0FFFh requires a ModRM byte
Problem: Some invalid opcodes require a ModRM byte and other following bytes, while others do not. The
invalid opcode 0FFFh did not require a ModRM in previous generation microprocessors such as
Pentium® II or Pentium III processors, but it is required in the Intel
®
Xeon
®
processor.
Implication: The use of an invalid opcode 0FFFh without the ModRM byte may result in a page or limit fault on
the Intel Xeon processor. When this erratum occurs, locked transactions will not be retried.
Workaround: To avoid this erratum use ModRM byte with invalid 0FFFh opcode.
Status: For the steppings affected, see the Summary Table of Changes.
D3. Processor may hang due to speculative page walks to non-existent system
memory
Problem: A load operation that misses the data translation lookaside buffer (DTLB) will result in a pagewalk.
If the page-walk loads the page directory entry (PDE) from cacheable memory and that PDE load
returns data that points to a valid page table entry (PTE) in uncacheable memory the processor will
access the address referenced by the PTE. If the address referenced does not exist the processor will
hang with no response from system memory.
Implication: Processor may hang due to speculative page walks to non-existent system memory.
Workaround: Page directories and page tables in UC memory space must point to system memory that exists.
Status: For the steppings affected, see the Summary Table of Changes.
D4. Memory type of the load lock different from its corresponding store unlock
Problem: The Intel Xeon Processor employs a use-once protocol to ensure that a processor in a
multiprocessor system may access data that are loaded into its cache on a Read-for-Ownership
operation at least once before it is snooped out by another processor. This protocol is necessary to
avoid a dual processor livelock scenario where no processor in the system can gain ownership of a
line and modify it before those data are snooped out by another processor. In the case of this
erratum, the use-once protocol incorrectly activates for split load lock instructions. A load lock
operation accesses data that split across a page boundary with both pages of WB memory type. The
use-once protocol activates and the memory type for the split halves get forced to UC. Since use-
once does not apply to stores, the store unlock instructions go out as WB memory type. The full
sequence on the Bus is: locked partial read (UC), partial read (UC), partial write (WB), locked
partial write (WB). The Use-once protocol should not be applied to Load locks.
Implication: When this erratum occurs, the memory type of the load lock will be different than the memory type
of the store unlock operation. This behavior (Load Locks and Store Unlocks having different