Errata
Specification Update
67
Implication:
An interrupt may immediately be generated with the new vector when a LVT entry is
written, even if the new LVT entry has the mask bit set. If there is no Interrupt
Service Routine (ISR) set up for that vector the system will GP fault. If the ISR does
not do an End of Interrupt (EOI) the bit for the vector will be left set in the in-service
register and mask all interrupts at the same or lower priority.
Workaround:
Any vector programmed into an LVT entry must have an ISR associated with it,
even if that vector was programmed as masked. This ISR routine must do an EOI to
clear any unexpected interrupts that may occur. The ISR associated with the spurious
vector does not generate an EOI, therefore the spurious vector should not be used
when writing the LVT.
Status:
For the steppings affected, see the
Summary Tables of Changes.
102.
Using 2M/4M Pages When A20M# Is Asserted May Result in
Incorrect Address Translations
Problem:
An external A20M# pin if enabled forces address bit 20 to be masked (forced to zero)
to emulates real-address mode address wraparound at 1 megabyte. However, if all of
the following conditions are met, address bit 20 may not be masked.
•
Paging is enabled
•
A linear address has bit 20 set
•
The address references a large page
•
A20M# is enabled
Implication:
When A20M# is enabled and an address references a large page the resulting
translated physical address may be incorrect. This erratum has not been observed
with any commercially available operating system.
Workaround:
Operating systems should not allow A20M# to be enabled if the masking of
address bit 20 could be applied to an address that references a large page. A20M# is
normally only used with the first megabyte of memory.
Status:
For the steppings affected, see the
Summary Tables of Changes.
103.
Writing Shared Unaligned Data that Crosses a Cache Line without
Proper Semaphores or Barriers May Expose a Memory Ordering Issue
Problem:
Software which is written so that multiple agents can modify the same shared
unaligned memory location at the same time may experience a memory ordering
issue if multiple loads access this shared data shortly thereafter. Exposure to this
problem requires the use of a data write which spans a cache line boundary.
Implication:
This erratum may cause loads to be observed out of order. Intel has not observed
this erratum with any commercially available software or system.
Workaround:
Software should ensure at least one of the following is true when modifying
shared data by multiple agents:
•
The shared data is aligned.
•
Proper semaphores or barriers are used in order to prevent concurrent data
accesses.