Intel Core 2 Duo U7500 U7500 User Manual

Specification Update 

 17 

This erratum may occur when the processor executes one of the following read-

modify-write arithmetic instructions and a page fault occurs during the store of the 

memory operand: ADD, AND, BTC, BTR, BTS, CMPXCHG, DEC, INC, NEG, NOT, OR, 

ROL/ROR, SAL/SAR/SHL/SHR, SHLD, SHRD, SUB, XOR, and XADD. In this case, the 

EFLAGS value pushed onto the stack of the page fault handler may reflect the status 

of the register after the instruction would have completed execution rather than 

before it. The following conditions are required for the store to generate a page fault 

and call the operating system page fault handler: 

 

 

1.  The store address entry must be evicted from the DTLB by speculative loads from 

other instructions that hit the same way of the DTLB before the store has 

completed. DTLB eviction requires at least three-load operations that have linear 

address bits 15:12 equal to each other and address bits 31:16 different from each 

other in close physical proximity to the arithmetic operation. 

2.  The page table entry for the store address must have its permissions tightened 

during the very small window of time between the DTLB eviction and execution of 

the store. Examples of page permission tightening include from Present to Not 

Present or from Read/Write to Read Only, etc. 

3.  Another processor, without corresponding synchronization and TLB flush, must 

cause the permission change. 

Implication:  This scenario may only occur on a multiprocessor platform running an operating 

system that performs “lazy” TLB shootdowns. The memory image of the EFLAGS 

register on the page fault handler's stack prematurely contains the final arithmetic flag 

values although the instruction has not yet completed. Intel has not identified any 

operating systems that inspect the arithmetic portion of the EFLAGS register during a 

page fault nor observed this erratum in laboratory testing of software applications.  

Workaround: No workaround is needed upon normal restart of the instruction, since this erratum is 

transparent to the faulting code and results in correct instruction behavior. Operating 

systems may ensure that no processor is currently accessing a page that is scheduled 

to have its page permissions tightened or have a page fault handler that ignores any 

incorrect state. 

For the steppings affected, see the Summary Tables of Changes.