Datasheet

Errata
60 Specification Update
AH47. 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.
AH48. 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.
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.
AH49. 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.
Implication: When the OS recovers from the second fault handler, the processor will no longer be
in VM86 mode. Normally, operating systems should prevent interrupt task switches
from faulting, thus the scenario should not occur under normal circumstances.
Workaround: None Identified.
Status: For the steppings affected, see the Summary Tables of Changes.