Intel SL3VS - Celeron 633 MHz Processor Specification page 61

C57. Mixed Cacheability of Lock Variables Is Problematic in MP
Systems
This errata only affects multiprocessor systems where a lock variable address is marked
Problem:
cacheable in one processor and uncacheable in any others. The processors which have it marked
uncacheable may stall indefinitely when accessing the lock variable. The stall is only encountered if:
•
One processor has the lock variable cached, and is attempting to execute a cache lock.
•
If the processor which has that address cached has it cached in its L2 only.
•
Other processors, meanwhile, issue back to back accesses to that same address on the bus.
MP systems where all processors either use cache locks or consistent locks to uncacheable
Implication:
space will not encounter this problem. If, however, a lock variable's cacheability varies in different processors,
and several processors are all attempting to perform the lock simultaneously, an indefinite stall may be
experienced by the processors which have it marked uncacheable in locking the variable (if the conditions
above are satisfied). Intel has only encountered this problem in focus testing with artificially generated external
events. Intel has not currently identified any commercial software which exhibits this problem.
Follow a homogenous model for the memory type range registers (MTRRs), ensuring that all
Workaround:
processors have the same cacheability attributes for each region of memory; do not use locks whose memory
type is cacheable on one processor, and uncacheable on others. Avoid page table aliasing, which may
produce a nonhomogenous memory model.
For the steppings affected, see the Summary of Changes at the beginning of this section.
Status:
C58. INT 1 with DR7.GD set does not clear DR7.GD
If the processor's general detect enable flag is set and an explicit call is made to the interrupt
Problem:
procedure via the INT 1 instruction, the general detect enable flag should be cleared prior to entering the
handler. As a result of this erratum, the flag is not cleared prior to entering the handler. If an access is made to
the debug registers while inside of the handler, the state of the general detect enable flag will cause a second
debug exception to be taken. The second debug exception clears the general detect enable flag and returns
control to the handler which is now able to access the debug registers.
This erratum will generate an unexpected debug exception upon accessing the debug registers
Implication:
while inside of the INT 1 handler.
Ignore the second debug exception that is taken as a result of this erratum.
Workaround:
For the steppings affected, see the Summary of Changes at the beginning of this section.
Status:
®
INTEL CELERON® PROCESSOR SPECIFICATION UPDATE
53