Specification Update

Errata
32 Specification Update
AM40 Values for LBR/BTS/BTM will be Incorrect after an Exit from SMM
Problem: After a return from SMM (System Management Mode), the CPU will incorrectly update
the LBR (Last Branch Record) and the BTS (Branch Trace Store), hence rendering
their data invalid. The corresponding data if sent out as a BTM on the system bus will
also be incorrect.
Note: This issue would only occur when one of the 3 above mentioned debug support
facilities are used.
Implication: The value of the LBR, BTS, and BTM immediately after an RSM operation should not
be used.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.
AM41 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.
AM42 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.