64-bit Intel Xeon Processor with 800 MHz System Bus (1MB and 2MB L2 Cache Versions) Specification Update

64-bit Intel
®
Xeon
®
Processor with 800 MHz System Bus (1 MB and 2 MB L2 Cache Versions)
August 2009 Specification Update
Order Number: 302402-024 25
—Intel
®
Xeon™ Processor with 800 MHz System Bus
• The processor should only log the address for L1 parity errors in the IA32_MC1_Status
register if a valid address is available. If a valid address is not available, the Address
Valid bit in the IA32_MC1_Status register should not be set. In instances where an L1
parity error occurs and the address is not available because the linear to physical
address translation is not complete or an internal resource conflict has occurred, the
Address Valid bit is incorrectly set.
• The processor may hang when an instruction code fetch receives a hard failure response
from the front side bus. This occurs because the bus control logic does not return data
to the core, leaving the processor empty. IA32_MC0_STATUS MSR does indicate that a
hard fail response occurred.
• The processor may hang when the following events occur and the machine check
exception is enabled, CR4.MCE=1. A processor that has it’s STPCLK# pin asserted will
internally enter the Stop Grant State and finally issue a Stop Grant Acknowledge special
cycle to the bus. If an uncorrectable error is generated during the Stop Grant process it
is possible for the Stop Grant special cycle to be issued to the bus before the processor
vectors to the machine check handler. Once the chipset receives its last Stop Grant
special cycle it is allowed to ignore any bus activity from the processors. As a result,
processor accesses to the machine check handler may not be acknowledged, resulting
in a processor hang.
Implication: The processor is unable to correctly report and/or recover from certain errors
Workaround:None at this time.
Status: For the steppings affected, see the Summary Table of Changes.
S6 Debug mechanisms may not function as expected
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 Certain debug mechanisms may not function as expected on the
processor. The cases are as follows:
• When the following conditions occur: 1) An FLD instruction signals a stack overflow or
underflow, 2) the FLD instruction splits a page-boundary or a 64 byte cache line
boundary, 3) the instruction matches a Debug Register on the high page or cache line
respectively, and 4) the FLD has a stack fault and a memory fault on a split access, the
processor will only signal the stack fault and the debug exception will not be taken.
• When a data breakpoint is set on the ninth and/or tenth byte(s) of a floating-point store
using the Extended Real data type, and an unmasked floating-point exception occurs on
the store, the break point will not be captured.
• When any instruction has multiple debug register matches, and any one of those debug
registers is enabled in DR7, all of the matches should be reported in DR6 when the
processor goes to the debug handler. This is not true during a REP instruction. As an
example, during execution of a REP MOVSW instruction the first iteration a load matches
DR0 and DR2 and sets DR6 as FFFF0FF5h. On a subsequent iteration of the instruction,
a load matches only DR0. The DR6 register is expected to still contain FFFF0FF5h, but
the processor will update DR6 to FFFF0FF1h.
A Data breakpoint that is set on a load to uncacheable memory may be ignored due to an
internal segment register access conflict. In this case the system will continue to execute
instructions, bypassing the intended breakpoint. Avoiding having instructions that access
segment descriptor registers e.g. LGDT, LIDT close to the UC load, and avoiding serialized
instructions before the UC load will reduce the occurrence of this erratum.
Implication: Certain debug mechanisms do not function as expected on the processor.
Workaround:None at this time.