Intel E6320 Specification Update - Page 21
B0-B3 Bits in DR6 For Non-Enabled Breakpoints May be Incorrectly Set
UPC - 735858192576
View all Intel E6320 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 21 highlights
BJ4. Problem: B0-B3 Bits in DR6 For Non-Enabled Breakpoints May be Incorrectly Set Some of the B0-B3 bits (breakpoint conditions detect flags, bits [3:0]) in DR6 may be incorrectly set for non-enabled breakpoints when the following sequence happens: 1. MOV or POP instruction to SS (Stack Segment) selector. 2. Next instruction is FP (Floating Point) that gets FP assist. 3. Another instruction after the FP instruction completes successfully. 4. A breakpoint occurs due to either a data breakpoint on the preceding instruction or a code breakpoint on the next instruction. Due to this erratum a non-enabled breakpoint triggered on step 1 or step 2 may be reported in B0-B3 after the breakpoint occurs in step 4. Implication: Due to this erratum, B0-B3 bits in DR6 may be incorrectly set for non-enabled breakpoints. Workaround: Software should not execute a floating point instruction directly after a MOV SS or POP SS instruction. Status: For the steppings affected, see the Summary Tables of Changes. BJ5. Changing the Memory Type for an In-Use Page Translation May Lead to Memory-Ordering Violations Problem: Under complex microarchitectural conditions, if software changes the memory type for data being actively used and shared by multiple threads without the use of semaphores or barriers, software may see load operations execute out of order. Implication: Memory ordering may be violated. Intel has not observed this erratum with any commercially available software. Workaround: Software should ensure pages are not being actively used before requesting their memory type be changed. Status: For the steppings affected, see the Summary Tables of Changes. BJ6. 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. Specification Update 21