Datasheet

R
Specification Update 29
V38. Changes to CR3 Register do not Fence Pending Instruction Page Walks
Problem: When software writes to the CR3 register, it is expected that all previous/outstanding code, data accesses
and page walks are completed using the previous value in CR3 register. Due to this erratum, it is
possible that a pending instruction page walk is still in progress, resulting in an access (to the PDE
portion of the page table) that may be directed to an incorrect memory address.
Implication: The results of the access to the PDE will not be consumed by the processor so the return of incorrect data
is benign. However, the system may hang if the access to the PDE does not complete with data (e.g.
infinite number of retries).
Workaround: It is possible for the BIOS to have a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.
V39. System Bus Interrupt Messages without Data that Receive a HardFailure
Response May Hang the Processor
Problem: When a system bus agent (processor or chipset) issues an interrupt transaction without data onto the
system bus and the transaction receives a HardFailure response, a potential processor hang can occur.
The processor, which generates an inter-processor interrupt (IPI) that receives the HardFailure response,
will still log the MCA error event cause as HardFailure, even if the APIC causes a hang. Other
processors, which are true targets of the IPI, will also hang on hardfail-without-data, but will not record
an MCA HardFailure event as the cause. If a HardFailure response occurs on a system bus interrupt
message with data, the APIC will complete the operation so as not to hang the processor.
Implication: The processor may hang.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
V40. Memory Type of the Load Lock Different from its Corresponding Store Unlock
Problem: A use-once protocol is employed to ensure that the processor in a multi-agent system may access data
that is loaded into its cache on a Read-for-Ownership operation at least once before it is snooped out by
another agent. This protocol is necessary to avoid a multi-agent livelock scenario in which the processor
cannot gain ownership of a line and modify it before that data is snooped out by another agent. In the
case of this erratum, split load lock instructions incorrectly trigger the use-once protocol. 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 introduce any functional failures such as system hangs or memory corruption.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.