Mobile Intel Pentium 4 Processor Supporting Hyper-Threading Technology* on 90 nm Process Technology Specification Update

Specification Update 17

When a speculative load operation hits the L2 cache and receives a correctable error, the

IA32_MC1_Status Register may be updated with incorrect information. The IA32_MC1_Status Register

should not be updated for speculative loads.

The processor should only log the address for L1 parity errors in the IA32_MC1_Status register if a

valid address is available. If a valid address is not available, the Address Valid bit in the

IA32_MC1_Status register should not be set. In instances where an L1 parity error occurs and the

address is not available because the linear to physical address translation is not complete or an internal

resource conflict has occurred, the Address Valid bit is incorrectly set.

The processor may hang when an instruction code fetch receives a hard failure response from the Front

Side Bus. This occurs because the bus control logic does not 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 its 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.

Q6.

Debug Mechanisms May Not Function As Expected

Problem: 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

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.