Intel SL8K2 Specification Update - Page 39

A 16-bit Address Wrap Resulting from a Near Branch Jump or Call May

Page 39 highlights

Errata R R20. BPM4# Signal Not Being Asserted According to Specification Problem: BPM4# signal is not being asserted according to the specification. This may cause incorrect operation of In-Target Debuggers, particularly at higher FSB frequencies. Implication: In-Target Debuggers may not function at higher than 133/533 MHz FSB. Workaround: One method is to reduce the FSB common clock frequency to 133 MHz or lower. For higher FSB speeds, In-Target Debuggers have a built-in function (test2010) that tells the hardware to ignore BPM4# assertions. This may degrade the debugger performance but will give correct results. Status: For the steppings affected, see the Summary Tables of Changes. R21. Sequence of Locked Operations Can Cause Two Threads to Receive Stale Data and Cause Application Hang Problem: While going through a sequence of locked operations, it is possible for the two threads to receive stale data. This is a violation of expected memory ordering rules and causes the application to hang. Implication: When this erratum occurs in an Hyper-Threading Technology enabled system, an application may hang. Workaround: It is possible for the BIOS to contain a workaround for this erratum. Status: For the steppings affected, see the Summary Tables of Changes. R22. A 16-bit Address Wrap Resulting from a Near Branch (Jump or Call) May Cause an Incorrect Address to Be Reported to the #GP Exception Handler Problem: If a 16-bit application executes a branch instruction that causes an address wrap to a target address outside of the code segment, the address of the branch instruction should be provided to the general protection exception handler. It is possible that, as a result of this erratum, that the general protection handler may be called with the address of the branch target. Implication: The 16-bit software environment which is affected by this erratum, will see that the address reported by the exception handler points to the target of the branch, rather than the address of the branch instruction. Workaround: None identified. Status: For the steppings affected, see the Summary Tables of Changes. Intel® Pentium® 4 Processor on 90 nm Process Specification Update 39

  • 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
39
R20.
BPM4# Signal Not Being Asserted According to Specification
Problem:
BPM4# signal is not being asserted according to the specification. This may cause incorrect
operation of In-Target Debuggers, particularly at higher FSB frequencies.
Implication:
In-Target Debuggers may not function at higher than 133/533 MHz FSB.
Workaround:
One method is to reduce the FSB common clock frequency to 133 MHz or lower. For higher FSB
speeds, In-Target Debuggers have a built-in function (test2010) that tells the hardware to ignore
BPM4# assertions. This may degrade the debugger performance but will give correct results.
Status:
For the steppings affected, see the
Summary Tables of Changes
.
R21.
Sequence of Locked Operations Can Cause Two Threads to Receive Stale
Data and Cause Application Hang
Problem:
While going through a sequence of locked operations, it is possible for the two threads to receive
stale data.
This is a violation of expected memory ordering rules and causes the application to
hang.
Implication:
When this erratum occurs in an Hyper-Threading Technology enabled system, an application may
hang.
Workaround:
It is possible for the BIOS to contain a workaround for this erratum.
Status:
For the steppings affected, see the
Summary Tables of Changes
.
R22.
A 16-bit Address Wrap Resulting from a Near Branch (Jump or Call) May
Cause an Incorrect Address to Be Reported to the #GP Exception Handler
Problem:
If a 16-bit application executes a branch instruction that causes an address wrap to a target
address outside of the code segment, the address of the branch instruction should be provided to
the general protection exception handler. It is possible that, as a result of this erratum, that the
general protection handler may be called with the address of the branch target.
Implication:
The 16-bit software environment which is affected by this erratum, will see that the address
reported by the exception handler points to the target of the branch, rather than the address of the
branch instruction.
Workaround:
None identified.
Status:
For the steppings affected, see the
Summary Tables of Changes.