Intel Xeon Processor MP Specification Update

Intel
®
Xeon
®
Processor MP Specification Update 21
Errata
O8 Writing a performance counter may result in an incorrect counter value
Implication: Accessing a performance counter also enables the counter input so that writing one half of the
counter can cause the other half to increment. When a performance counter is written and the event
counter for the event being monitored is non-zero, the performance counter will be incremented by
the value on that event counter. Because the upper eight bits of the performance counter are not
written at the same time as the lower 32 bits, the increment due to the non-zero event counter may
cause a carry to the upper bits such that the performance counter contains a value higher than what
was written. The worst-case error caused by this can be about 4 billion counts.
Implication: When this erratum occurs, the performance counter will contain a different value from that which
was written.
Workaround: If the performance counter is set to select a null event and the counter configuration control register
(CCCR) for that counter has its compare bit set to zero, before the performance counter is written,
this erratum will not occur.
Status: For the steppings effected, see the Summary Table of Changes.
O9 Performance counter may contain incorrect value after being stopped
Problem: If a performance counter is stopped on the precise internal clock cycle where the intermediate carry
from the lower 32 bits of the counter to the upper eight bits occurs, the intermediate carry is lost.
Implication: When this erratum occurs, the performance counter may contain a value about 4 billion (
2
32) less
than it should.
Workaround: Since this erratum does not occur if the performance counters are read when running, a possible
workaround is to read the counter before stopping it.
Status: For the steppings effected, see the Summary Table of Changes.
O10 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 RFO 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 at this time
Status: For the steppings affected, see the Summary Tables of Changes.
O11 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