Intel Xeon Processor MP Specification Update

Intel

Xeon

Processor MP Specification Update 19

Errata

O1 UC code in same line as write back (WB) data may lead to data corruption

Problem: This erratum occurs when both code (being accessed as uncacheable [UC] or write combining

[WC]) and data (being accessed as write back [WB]) are placed in the same cache line. The UC

fetch will cause the processor to self-snoop and generate an implicit WB. The data supplied by this

implicit WB may be corrupted due to the way the processor is currently handling self-modifying

code.

Implication: UC code located in the same cache line as WB data may lead to data corruption.

Workaround: UC or WC code should not be located in the same 64-byte cache line as any location that is being

stored to with WB data.

Status: For the steppings effected, see the Summary Table of Changes.

O2 Transaction is not retried 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 at this time.

Status: For the steppings effected, see the Summary Table of Changes.

O3 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 MP.

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 MP.

Workaround: To avoid this erratum use ModRM byte with invalid 0FFFh opcode.

Status: For the steppings effected, see the Summary Table of Changes.

O4 FSW may not be completely restored after page-fault on FRSTOR or

FLDENV instructions

Problem: If the FPU operating environment or FPU state (operating environment and register stack) being

loaded by an FLDENV or FRSTOR instruction wraps around a 64Kbyte or 4Gbyte boundary and a

page-fault (#PF) or segment limit fault (#GP or #SS) occurs on the instruction near the wrap

boundary, the upper byte of the FPU status word (FSW) might not be restored. If the fault handler

does not restart program execution at the faulting instruction, stale data may exist in the FSW.

Implication: When this erratum occurs, stale data will exist in the FSW.

Workaround: Ensure that the FPU operating environment and FPU state do not cross 64Kbyte or 4Gbyte

boundaries. Alternately, ensure that the page-fault handler restarts program execution at the

faulting instruction after correcting the paging problem.

Status: For the steppings effected, see the Summary Table of Changes.