Intel SL6NQ Specification Update - Page 27

Errata

Page 27 highlights

Errata Errata P1 UC Code in same line as write back (WB) data may lead to data corruption Problem: This erratum occurs when both code (being accessed as uncacheable [UC] or write combining [WC]) and data (being accessed as write back [WB]) are placed in the same cache line. The UC fetch will cause the processor to self-snoop and generate an implicit WB. The data supplied by this implicit WB may be corrupted due to the way the processor is currently handling self-modifying code. Implication: UC code located in the same cache line as WB data may lead to data corruption. Workaround: UC or WC code should not be located in the same 64-byte cache line as any location that is being stored to with WB data. Status: For the steppings effected, see the Summary Table of Changes. P2 Transaction is not retried after BINIT# Problem: If the first transaction of a locked sequence receives a HITM# and DEFER# during the snoop phase it should be retried and the locked sequence restarted. However, if BINIT# is also asserted during this transaction, the transaction will not be retried. Implication: When this erratum occurs, locked transactions will not be retried. Workaround: None at this time. Status: For the steppings effected, see the Summary Table of Changes. P3 Invalid opcode 0FFFh requires a ModRM byte Problem: Some invalid opcodes require a ModRM byte and other following bytes, while others do not. The invalid opcode 0FFFh did not require a ModRM in previous generation microprocessors such as Pentium II or Pentium III processors, but it is required in the Intel Xeon processor Implication: The use of an invalid opcode 0FFFh without the ModRM byte may result in a page or limit fault on the Intel Xeon processor. Workaround: To avoid this erratum use ModRM byte with invalid 0FFFh opcode. Status: For the steppings affected, see the Summary Table of Changes. P4 When in no-fill mode (CR0.CD=1) the memory type of large (PSE-4M and PAE-2M) pages are wrongly forced to uncacheable Problem: When the processor is operating in no-fill mode (CR0.CD=1), the page miss hardware incorrectly forces the memory type of large (PSE-4M and PAE-2M) pages to UC memory type regardless of the MTRR settings. By forcing the memory type of these pages to UC, load operations, which should hit valid data in the L1 cache, are forced to load the data from system memory. Some applications will lose the performance advantage associated with the caching permitted by other memory types. Implication: This erratum may result in some performance degradation when using no-fill mode with large pages. Workaround: None at this time. Status: For the steppings affected, see the Summary Table of Changes Intel® Xeon® Processor Specification Update 27

  • 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
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56

Intel
®
Xeon
®
Processor Specification Update
27
Errata
Errata
P1
UC Code in same line as write back (WB) data may lead to data corruption
Problem:
This erratum occurs when both code (being accessed as uncacheable [UC] or write combining
[WC]) and data (being accessed as write back [WB]) are placed in the same cache line. The UC
fetch will cause the processor to self-snoop and generate an implicit WB. The data supplied by this
implicit WB may be corrupted due to the way the processor is currently handling self-modifying
code.
Implication:
UC code located in the same cache line as WB data may lead to data corruption.
Workaround:
UC or WC code should not be located in the same 64-byte cache line as any location that is being
stored to with WB data.
Status:
For the steppings effected, see the
Summary Table of Changes
.
P2
Transaction is not retried after BINIT#
Problem:
If the first transaction of a locked sequence receives a HITM# and DEFER# during the snoop phase
it should be retried and the locked sequence restarted. However, if BINIT# is also asserted during
this transaction, the transaction will not be retried.
Implication:
When this erratum occurs, locked transactions will not be retried.
Workaround:
None at this time.
Status:
For the steppings effected, see the
Summary Table of Changes
.
P3
Invalid opcode 0FFFh requires a ModRM byte
Problem:
Some invalid opcodes require a ModRM byte and other following bytes, while others do not. The
invalid opcode 0FFFh did not require a ModRM in previous generation microprocessors such as
Pentium II or Pentium III processors, but it is required in the Intel Xeon processor
Implication:
The use of an invalid opcode 0FFFh without the ModRM byte may result in a page or limit fault on
the Intel Xeon processor.
Workaround:
To avoid this erratum use ModRM byte with invalid 0FFFh opcode.
Status:
For the steppings affected, see the
Summary Table of Changes
.
P4
When in no-fill mode (CR0.CD=1) the memory type of large (PSE-4M and
PAE-2M) pages are wrongly forced to uncacheable
Problem:
When the processor is operating in no-fill mode (CR0.CD=1), the page miss hardware incorrectly
forces the memory type of large (PSE-4M and PAE-2M) pages to UC memory type regardless of
the MTRR settings. By forcing the memory type of these pages to UC, load operations, which
should hit valid data in the L1 cache, are forced to load the data from system memory. Some
applications will lose the performance advantage associated with the caching permitted by other
memory types.
Implication:
This erratum may result in some performance degradation when using no-fill mode with large
pages.
Workaround:
None at this time.
Status:
For the steppings affected, see the
Summary Table of Changes