Intel 2ND GENERATION CORE PROCESSOR FAMILY DESKTOP - SPECIFICATION UPDATE 01-2011 Specification page 30

BJ48. PCI Express Graphics Receiver Error Reported When Receiver With
L0s Enabled and Link Retrain Performed
Problem: If the Processor PCI Express root port is the receiver with L0s enabled and the root port
itself initiates a transition to the recovery state via the retrain link configuration bit in
the 'Link Control' register (Bus 0; Device 1; Functions 0, 1, 2 and Device 6; Function 0;
Offset B0H; bit 5), then the root port may not mask the receiver or bad DLLP (Data
Link Layer Packet) errors as expected. These correctable errors should only be
considered valid during PCIe configuration and L0 but not L0s. This causes the
processor to falsely report correctable errors in the 'Device Status' register (Bus 0;
Device 1; Functions 0, 1, 2 and Device 6; Function 0; Offset AAH; bit 0) upon receiving
the first FTS (Fast Training Sequence) when exiting Receiver L0s. Under normal
conditions there is no reason for the Root Port to initiate a transition to Recovery. Note:
This issue is only exposed when a recovery event is initiated by the processor.
Implication: The processor does not comply with the PCI Express 2.0 Specification. This does not
impact functional compatibility or interoperability with other PCIe devices.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
BJ49. Unexpected #UD on VZEROALL/VZEROUPPER
Problem: Execution of the VZEROALL or VZEROUPPER instructions in 64-bit mode with VEX.W set
to 1 may erroneously cause a #UD (invalid-opcode exception).
Implication: The affected instructions may produce unexpected invalid-opcode exceptions in 64-bit
mode.
Workaround: Compilers should encode VEX.W = 0 for executions of the VZEROALL and VZEROUPPER
instructions in 64-bit mode to ensure future compatibility.
Status: For the steppings affected, see the Summary Tables of Changes.
BJ50. Perfmon Event LD_BLOCKS.STORE_FORWARD May Overcount
Problem: Perfmon LD_BLOCKS.STORE_FORWARD (event 3H, umask 01H) may overcount in the
cases of 4KB address aliasing and in some cases of blocked 32-byte AVX load
operations. 4KB address aliasing happens when unrelated load and store that have
different physical addresses appear to overlap due to partial address check done on the
lower 12 bits of the address. In some cases such memory aliasing can cause load
execution to be significantly delayed. Blocked AVX load operations refer to 32-byte AVX
loads that are blocked due to address conflict with an older store.
Implication: The perfmon event LD_BLOCKS.STORE_FORWARD may overcount for these cases.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
30 Specification Update