Intel E6600 Specification Update - Page 39

VM Bit is Cleared on Second Fault Handled by Task Switch

Get Intel E6600 - Core 2 Duo Dual-Core Processor PDF manuals and user guides
UPC - 735858184625
View all Intel E6600 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 39 highlights

Errata 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. Intel® Core™2 Extreme Processor X6800 and Intel® Core™2 Duo Desktop Processor E6000 and E4000 Sequence 39 Specification Update

  • 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
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
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.