Errata
Intel
®
Core™2 Extreme Processor X6800 and
Intel
®
Core™2 Duo Desktop Processor E6000 and E4000 Sequence 39
Specification Update
Implication: Non-bootstrap logical processors in the package that have not observed the
error condition may be disabled and may not respond to INIT#, SMI#, NMI#,
SIPI or other events.
Workaround: When this erratum occurs, RESET# must be asserted to restore multi-core
functionality.
Status: For the steppings affected, see the Summary Tables of Changes.
AI47. SYSCALL Immediately after Changing EFLAGS.TF May Not Behave
According to the New EFLAGS.TF
Problem: If a SYSCALL instruction follows immediately after EFLAGS.TF was updated
and IA32_FMASK.TF (bit 8) is cleared, then under certain circumstances
SYSCALL may behave according to the previous EFLAGS.TF.
Implication: When the problem occurs, SYSCALL may generate an unexpected debug
exception, or may skip an expected debug exception.
Workaround: Mask EFLAGS.TF by setting IA32_FMASK.TF (bit 8).
Status: For the steppings affected, see the Summary Tables of Changes.
AI48. Code Segment Limit/Canonical Faults on RSM May be Serviced before
Higher Priority Interrupts/Exceptions
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.)
Implication: Operating systems may observe a #GP fault being serviced before higher
priority Interrupts and Exceptions. Intel has not observed this erratum on any
commercially available software.
Workaround: None Identified.
Status: For the steppings affected, see the Summary Tables of Changes.
AI49. VM Bit is Cleared on Second Fault Handled by Task Switch from
Virtual-8086 (VM86)
Problem: Following a task switch to any fault handler that was initiated while the
processor was in VM86 mode, if there is an additional fault while servicing the
original task switch then the VM bit will be incorrectly cleared in EFLAGS, data
segments will not be pushed and the processor will not return to the correct
mode upon completion of the second fault handler via IRET.
To Next Page
Loading...
Need help?
General
