Errata
60 Specification Update
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.
82. Shutdown and IERR# May Result Due to a Machine Check Exception
on a Hyper-Threading Technology
1
Enabled Processor
Problem: When a Machine Check Exception (MCE) occurs due to an internal error, both logical
processors on a Hyper-Threading Technology enabled processor normally vector to
the MCE handler. However, if one of the logical processors is in the “Wait-for-SIPI”
state, that logical processor will not have an MCE handler and will shut down and
assert IERR#.
Implication: A processor with a logical processor in the “Wait-for-SIPI” state will shut down when
an MCE occurs on the other thread.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
83. A 16-bit Address Wrap Resulting from a Near Branch (Jump or Call)
May Cause an Incorrect Address to Be Reported to the #GP Exception
Handler
Problem: If a 16-bit application executes a branch instruction that causes an address wrap to a
target address outside of the code segment, the address of the branch instruction
should be provided to the general protection exception handler. It is possible that, as
a result of this erratum, that the general protection handler may be called with the
address of the branch target.
Implication: The 16-bit software environment which is affected by this erratum, will see that the
address reported by the exception handler points to the target of the branch, rather
than the address of the branch instruction.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
To Next Page
Loading...
