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 23
—Intel
®
Xeon™ Processor with 800 MHz System Bus
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.
S4 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 is loaded into its
cache on a read-for-ownership (RFO) 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 that data is 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 splits 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 memory types) does not however
introduce any functional failures such as system hangs or memory corruption.
Workaround:None at this time.
Status: For the steppings affected, see the Summary Table of Changes.
S5 Machine Check Architecture error reporting and recovery may
not work as expected
Problem: When the processor detects errors it should attempt to report and/or recover
from the error. In the situations described below, the processor does not
report and/or recover from the error(s) as intended.
• When a transaction is deferred during the snoop phase and subsequently receives a
Hard Failure response, the transaction should be removed from the bus queue so that
the processor may proceed. Instead, the transaction is not properly removed from the
bus queue, the bus queue is blocked, and the processor will hang.
• When a hardware prefetch results in an uncorrectable tag error in the L2 cache,
MC0_STATUS.UNCOR and MC0_STATUS.PCC are set but no machine check exception
(MCE) is signaled. No data loss or corruption occurs because the data being prefetched
has not been used. If the data location with the uncorrectable tag error is subsequently
accessed, an MCE will occur. However, upon this MCE, or any other subsequent MCE, the
information for that error will not be logged because MC0_STATUS.UNCOR has already
been set and the MCA status registers will not contain information about the error which
caused the MCE assertion but instead will contain information about the prefetch error
event.
• When the reporting of errors is disabled for machine check architecture (MCA) Bank 2
by setting all MC2_CTL register bits to 0, uncorrectable errors should be logged in the
IA32_MC2_STATUS register but no machine-check exception should be generated.
Uncorrectable loads on bank 2, which would normally be logged in the
IA32_MC2_STATUS register, are not logged.
• When one half of a 64 byte instruction fetch from the L2 cache has an uncorrectable
error and the other 32 byte half of the same fetch from the L2 cache has a correctable