Intel X5472 Specification Update - Page 22

Code Segment Limit/Canonical Faults on RSM May be Serviced before

Page 22 highlights

Processors" the processor performs REP MOVS or REP STOS as fast strings. Due to this erratum fast string REP MOVS/REP STOS instructions that cross page boundaries from WB/WC memory types to UC/WP/WT memory types, may start using an incorrect data size or may observe memory ordering violations. Implication: Upon crossing the page boundary the following may occur, dependent on the new page memory type: • UC the data size of each write will now always be 8 bytes, as opposed to the original data size. • WP the data size of each write will now always be 8 bytes, as opposed to the original data size and there may be a memory ordering violation. • WT there may be a memory ordering violation. Workaround: Software should avoid crossing page boundaries from WB or WC memory type to UC, WP or WT memory type within a single REP MOVS or REP STOS instruction that will execute with fast strings enabled. Status: For the steppings affected, see the Summary Tables of Changes. AX16. Upper 32 bits of 'From' Address Reported through BTMs or BTSs May be Incorrect Problem: When a far transfer switches the processor from 32-bit mode to IA-32e mode, the upper 32 bits of the 'From' (source) addresses reported through the BTMs (Branch Trace Messages) or BTSs (Branch Trace Stores) may be incorrect. Implication: The upper 32 bits of the 'From' address debug information reported through BTMs or BTSs may be incorrect during this transition. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. AX17. Address Reported by Machine-Check Architecture (MCA) on Single-bit L2 ECC Errors May be Incorrect Problem: When correctable Single-bit ECC errors occur in the L2 cache, the address is logged in the MCA address register (MCi_ADDR). Under some scenarios, the address reported may be incorrect. Implication: Software should not rely on the value reported in MCi_ADDR, for Single-bit L2 ECC errors. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. AX18. Problem: Code Segment Limit/Canonical Faults on RSM May be Serviced before Higher Priority Interrupts/Exceptions and May Push the Wrong Address Onto the Stack Normally, when the processor encounters a Segment Limit or Canonical Fault due to code execution, a #GP (General Protection Exception) fault is generated after all higher priority Interrupts and exceptions are serviced. Due to this erratum, if RSM (Resume from System Management Mode) returns to execution flow that results in a Code Segment Limit or Canonical Fault, the #GP fault may be serviced before a higher priority Interrupt or Exception (e.g. NMI (Non-Maskable Interrupt), Debug break(#DB), Machine Check (#MC), etc.). If the RSM attempts to return to a non-canonical address, the address pushed onto the stack for this #GP fault may not match the non-canonical address that caused the fault. Intel® Xeon® Processor 5400 Series 22 Specification Update

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44

Intel® Xeon® Processor 5400 Series
22
Specification Update
Processors" the processor performs REP MOVS or REP STOS as fast strings. Due to this
erratum fast string REP MOVS/REP STOS instructions that cross page boundaries from
WB/WC memory types to UC/WP/WT memory types, may start using an incorrect data
size or may observe memory ordering violations.
Implication:
Upon crossing the page boundary the following may occur, dependent on the new page
memory type:
UC the data size of each write will now always be 8 bytes, as opposed to the
original data size.
WP the data size of each write will now always be 8 bytes, as opposed to the
original data size and there may be a memory ordering violation.
WT there may be a memory ordering violation.
Workaround:
Software should avoid crossing page boundaries from WB or WC memory type to UC,
WP or WT memory type within a single REP MOVS or REP STOS instruction that will
execute with fast strings enabled.
Status:
For the steppings affected, see the
Summary Tables of Changes
.
AX16.
Upper 32 bits of 'From' Address Reported through BTMs or BTSs May
be Incorrect
Problem:
When a far transfer switches the processor from 32-bit mode to IA-32e mode, the
upper 32 bits of the 'From' (source) addresses reported through the BTMs (Branch
Trace Messages) or BTSs (Branch Trace Stores) may be incorrect.
Implication:
The upper 32 bits of the 'From' address debug information reported through BTMs or
BTSs may be incorrect during this transition.
Workaround:
None identified.
Status:
For the steppings affected, see the
Summary Tables of Changes
.
AX17.
Address Reported by Machine-Check Architecture (MCA) on Single-bit
L2 ECC Errors May be Incorrect
Problem:
When correctable Single-bit ECC errors occur in the L2 cache, the address is logged in
the MCA address register (MCi_ADDR). Under some scenarios, the address reported
may be incorrect.
Implication:
Software should not rely on the value reported in MCi_ADDR, for Single-bit L2 ECC
errors.
Workaround:
None identified.
Status:
For the steppings affected, see the
Summary Tables of Changes
.
AX18.
Code Segment Limit/Canonical Faults on RSM May be Serviced before
Higher Priority Interrupts/Exceptions and May Push the Wrong
Address Onto the Stack
Problem:
Normally, when the processor encounters a Segment Limit or Canonical Fault due to
code execution, a #GP (General Protection Exception) fault is generated after all higher
priority Interrupts and exceptions are serviced. Due to this erratum, if RSM (Resume
from System Management Mode) returns to execution flow that results in a Code
Segment Limit or Canonical Fault, the #GP fault may be serviced before a higher
priority Interrupt or Exception (e.g. NMI (Non-Maskable Interrupt), Debug break(#DB),
Machine Check (#MC), etc.). If the RSM attempts to return to a non-canonical address,
the address pushed onto the stack for this #GP fault may not match the non-canonical
address that caused the fault.