Intel Celeron D Processor 300 Sequence on 90 nm Process

Errata
Specification Update 29
return data to the core, leaving the processor empty. IA32_MC0_STATUS MSR does
indicate that a hard fail response occurred.
The processor may hang when the following events occur and the machine check
exception is enabled, CR4.MCE=1. A processor that has it’s STPCLK# pin asserted
will internally enter the Stop Grant State and finally issue a Stop Grant Acknowledge
special cycle to the bus. If an uncorrectable error is generated during the Stop Grant
process it is possible for the Stop Grant special cycle to be issued to the bus before
the processor vectors to the machine check handler. Once the chipset receives its
last Stop Grant special cycle it is allowed to ignore any bus activity from the
processors. As a result, processor accesses to the machine check handler may not be
acknowledged, resulting in a processor hang.
Implication: The processor is unable to correctly report and/or recover from certain errors
Workaround: None identified
Status: For the steppings affected, see the Summary Tables of Changes
L6. Debug Mechanisms May Not Function As Expected
Problem: the first transaction of a locked sequence receives a HITM# and DEFER# during the
snoop phase it should be retried and the locked sequence restarted. However, if
BINIT# is also asserted during this transaction, the transaction will not be certain
debug mechanisms may not function as expected on the processor. The cases are as
follows:
When the following conditions occur: 1) An FLD instruction signals a stack overflow or
underflow, 2) the FLD instruction splits a page-boundary or a 64 byte cache line
boundary, 3) the instruction matches a Debug Register on the high page or cache
line respectively, and 4) the FLD has a stack fault and a memory fault on a split
access, the processor will only signal the stack fault and the debug exception will not
be taken.
When a data breakpoint is set on the ninth and/or tenth byte(s) of a floating point
store using the Extended Real data type, and an unmasked floating point exception
occurs on the store, the break point will not be captured.
When any instruction has multiple debug register matches, and any one of those
debug registers is enabled in DR7, all of the matches should be reported in DR6 when
the processor goes to the debug handler. This is not true during a REP instruction. As
an example, during execution of a REP MOVSW instruction the first iteration a load
matches DR0 and DR2 and sets DR6 as FFFF0FF5h. On a subsequent iteration of the
instruction, a load matches only DR0. The DR6 register is expected to still contain
FFFF0FF5h, but the processor will update DR6 to FFFF0FF1h.
A Data breakpoint that is set on a load to uncacheable memory may be ignored due
to an internal segment register access conflict. In this case the system will continue
to execute instructions, bypassing the intended breakpoint. Avoiding having
instructions that access segment descriptor registers e.g. LGDT, LIDT close to the UC
load, and avoiding serialized instructions before the UC load will reduce the
occurrence of this erratum
Implication: Certain debug mechanisms do not function as expected on the processor