Download Print this page

Intel T8300 - Core 2 Duo 2.4GHz 800MHz 3MB Socket P Mobile CPU Documentation Update page 44

Intel core 2 extreme quad-core mobile processor, intel core2 quad mobile processor, intel core 2 extreme mobile processor, intel core 2 duo mobile processor, intel core 2 solo mobile processor and intel celeron processor on 45-nm process specification upd

Advertisement

AZ55.
An Enabled Debug Breakpoint or Single Step Trap May Be Taken after
MOV SS/POP SS Instruction if it is Followed by an Instruction That
Signals a Floating Point Exception
A MOV SS/POP SS instruction should inhibit all interrupts including debug breakpoints
Problem:
until after execution of the following instruction. This is intended to allow the sequential
execution of MOV SS/POP SS and MOV [r/e]SP, [r/e]BP instructions without having an
invalid stack during interrupt handling. However, an enabled debug breakpoint or single
step trap may be taken after MOV SS/POP SS if this instruction is followed by an
instruction that signals a floating point exception rather than a MOV [r/e]SP, [r/e]BP
instruction. This results in a debug exception being signaled on an unexpected instruction
boundary since the MOV SS/POP SS and the following instruction should be executed
atomically.
This can result in incorrect signaling of a debug exception and possibly a mismatched
Implication:
Stack Segment and Stack Pointer. If MOV SS/POP SS is not followed by a MOV [r/e]SP,
[r/e]BP, there may be a mismatched Stack Segment and Stack Pointer on any exception.
Intel has not observed this erratum with any commercially available software, or system.
Workaround: As recommended in the IA32 Intel® Architecture Software Developer‟s Manual, the use
of MOV SS/POP SS in conjunction with MOV [r/e]SP, [r/e]BP will avoid the failure since
the MOV [r/e]SP, [r/e]BP will not generate a floating point exception. Developers of
debug tools should be aware of the potential incorrect debug event signaling created by
this erratum.
Status:
For the steppings affected, see the Summary Tables of Changes.
AZ56.
Code Segment Limit/Canonical Faults on RSM May be Serviced before
Higher Priority Interrupts/Exceptions and May Push the Wrong Address
Onto the Stack
Normally, when the processor encounters a Segment Limit or Canonical Fault due to code
Problem:
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.
Operating systems may observe a #GP fault being serviced before higher priority
Implication:
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.
44
Errata
Specification Update

Advertisement

loading

This manual is also suitable for:

T8300 2 2.4ghz 800mhz 3mb