Intel E5310 Specification Update - Page 30

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. AJ46. Shutdown Condition May Disable Non-Bootstrap Processors Problem: When a logical processor encounters an error resulting in shutdown, non-bootstrap processors in the package may be unexpectedly disabled. 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. AJ47. 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. AJ48. Debug Register May Contain Incorrect Information on a MOVSS or POPSS Instruction Followed by SYSRET Problem: In IA-32e mode, if a MOVSS or POPSS instruction with a debug breakpoint is followed by the SYSRET instruction, incorrect information may exist in the Debug Status Register (DR6). Implication: When debugging or when developing debuggers, this behavior should be noted. This erratum will not occur under normal usage of the MOVSS or POPSS instructions (i.e., following them with a MOV ESP instruction). Workaround: Do not attempt to put a breakpoint on MOVSS and POPSS instructions that are followed by a SYSRET. Status: For the steppings affected, see the Summary Tables of Changes. AJ49. 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. 30 Intel® Xeon® Processor 5300 Series Specification Update, December 2010