Intel SL8K2 Specification Update - Page 31

Memory Type of the Load Lock Different from Its Corresponding Store, Unlock

Page 31 highlights

Errata R R4. Memory Type of the Load Lock Different from Its Corresponding Store Unlock Problem: A use-once protocol is employed to ensure that the processor in a multi-agent system may access data that is loaded into its cache on a Read-for-Ownership operation at least once before it is snooped out by another agent. This protocol is necessary to avoid a multi-agent livelock scenario in which the processor cannot gain ownership of a line and modify it before that data is snooped out by another agent. In the case of this erratum, split load lock instructions incorrectly trigger the use-once protocol. A load lock operation accesses data that splits across a page boundary with both pages of WB memory type. The use-once protocol activates and the memory type for the split halves get forced to UC. Since use-once does not apply to stores, the store unlock instructions go out as WB memory type. The full sequence on the bus is: locked partial read (UC), partial read (UC), partial write (WB), locked partial write (WB). The use-once protocol should not be applied to load locks. Implication: When this erratum occurs, the memory type of the load lock will be different than the memory type of the store unlock operation. This behavior (load locks and store unlocks having different memory types) does not introduce any functional failures such as system hangs or memory corruption. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. R5. Problem: Machine Check Architecture Error Reporting and Recovery May Not Work As Expected When the processor detects errors it should attempt to report and/or recover from the error. In the situations described below, the processor does not report and/or recover from the error(s) as intended. • When a transaction is deferred during the snoop phase and subsequently receives a Hard Failure response, the transaction should be removed from the bus queue so that the processor may proceed. Instead, the transaction is not properly removed from the bus queue, the bus queue is blocked, and the processor will hang. • When a hardware prefetch results in an uncorrectable tag error in the L2 cache, MC0_STATUS.UNCOR and MC0_STATUS.PCC are set but no Machine Check Exception (MCE) is signaled. No data loss or corruption occurs because the data being prefetched has not been used. If the data location with the uncorrectable tag error is subsequently accessed, an MCE will occur. However, upon this MCE, or any other subsequent MCE, .the information for that error will not be logged because MC0_STATUS.UNCOR has already been set and the MCA status registers will not contain information about the error which caused the MCE assertion but instead will contain information about the prefetch error event. • When the reporting of errors is disabled for Machine Check Architecture (MCA) Bank 2 by setting all MC2_CTL register bits to 0, uncorrectable errors should be logged in the IA32_MC2_STATUS register but no machine-check exception should be generated. Uncorrectable loads on bank 2, which would normally be logged in the IA32_MC2_STATUS register, are not logged. Intel® Pentium® 4 Processor on 90 nm Process Specification Update 31

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75

Errata
R
Intel
®
Pentium
®
4 Processor on 90 nm Process Specification Update
31
R4.
Memory Type of the Load Lock Different from Its Corresponding Store
Unlock
Problem:
A use-once protocol is employed to ensure that the processor in a multi-agent system may access
data that is loaded into its cache on a Read-for-Ownership operation at least once before it is
snooped out by another agent. This protocol is necessary to avoid a multi-agent livelock scenario
in which the processor cannot gain ownership of a line and modify it before that data is snooped
out by another agent. In the case of this erratum, split load lock instructions incorrectly trigger the
use-once protocol. A load lock operation accesses data that splits across a page boundary with
both pages of WB memory type. The use-once protocol activates and the memory type for the
split halves get forced to UC. Since use-once does not apply to stores, the store unlock
instructions go out as WB memory type. The full sequence on the bus is: locked partial read
(UC), partial read (UC), partial write (WB), locked partial write (WB). The use-once protocol
should not be applied to load locks.
Implication:
When this erratum occurs, the memory type of the load lock will be different than the memory
type of the store unlock operation. This behavior (load locks and store unlocks having different
memory types) does not introduce any functional failures such as system hangs or memory
corruption.
Workaround:
None identified.
Status:
For the steppings affected, see the
Summary Tables of Changes.
R5.
Machine Check Architecture Error Reporting and Recovery May Not Work
As Expected
Problem:
When the processor detects errors it should attempt to report and/or recover from the error. In the
situations described below, the processor does not report and/or recover from the error(s) as
intended.
When a transaction is deferred during the snoop phase and subsequently receives a Hard
Failure response, the transaction should be removed from the bus queue so that the processor
may proceed. Instead, the transaction is not properly removed from the bus queue, the bus
queue is blocked, and the processor will hang.
When a hardware prefetch results in an uncorrectable tag error in the L2 cache,
MC0_STATUS.UNCOR and MC0_STATUS.PCC are set but no Machine Check Exception
(MCE) is signaled. No data loss or corruption occurs because the data being prefetched has
not been used. If the data location with the uncorrectable tag error is subsequently accessed,
an MCE will occur. However, upon this MCE, or any other subsequent MCE, .the
information for that error will not be logged because MC0_STATUS.UNCOR has already
been set and the MCA status registers will not contain information about the error which
caused the MCE assertion but instead will contain information about the prefetch error event.
When the reporting of errors is disabled for Machine Check Architecture (MCA) Bank 2 by
setting all MC2_CTL register bits to 0, uncorrectable errors should be logged in the
IA32_MC2_STATUS register but no machine-check exception should be generated.
Uncorrectable loads on bank 2, which would normally be logged in the
IA32_MC2_STATUS register, are not logged.