The bug has been observed with :
2.6.2 Re-execution of Instructions Due to Self-Modifying Code
Products Affected : B stepping
Normal Specified Operation: If the processor detects a potential self-modifying
code condition, the processor performs specific internal actions to ensure that
instruction execution occurs in the correct manner.
Non-conformance:
If:
o The target of a transfer control instruction is fetched and loaded into
the processor's Branch Target Cache (BTC)
o This transfer control instruction is speculatively executed and hits in
the BTC
o An instruction (Instruction "A") is executed that causes the processor to
detect a potential self-modifying code condition relative to the transfer
control target that resides in the BTC
o Instruction "A" is followed by a register-modifying instruction(s) in the
form of:
o A long-decoded instruction, or;
o One or two short-decoded instructions
o The transfer control instruction that was speculatively executed follows
the register-modifying instruction(s) within approximately 1-9
instructions
o Certain other relative internal pipeline timing conditions must occur
Then:
o The long-decoded instruction, or the short-decoded instruction(s), is
executed twice.
Potential Effect on System: If software is not affected by the re-execution
of the register-modifying instruction(s)- for instance, loading immediate
data into a general purpose register- then this erratum has no effect on the
system. However, if any of the instructions that are re-executed change the
state of the system from the state that would be achieved by the normal
specified operation- for instance, incrementing a register by one-then this
erratum can lead to unpredictable system behavior.
Suggested Workaround: None.
Resolution Status: This erratum will be corrected in a future stepping of the
AMD-K6 processor.
Due to the complexity of the microarchitecture of the AMD-K6 processor -- particularly the speculative and out-of-order execution capabilities of the processor -- all of the specific details surrounding the conditions necessary for an erratum to occur cannot be easily documented in the "Revision Guide." AMD provides the details of all conditions that are visible or under the control of our customers to help them in understanding the cause of an erratum, as well as work around the erratum, if possible. For those specific conditions that are not visible, cannot be controlled externally by our customers, or are very complex microarchitectural conditions, the explanations are provided in a more general manner. In the case of erratum 2.6.2, the statement "Certain other relative internal pipeline timing conditions must occur" is used because these specifictiming conditions are low-level microarchitectural conditions that cannot be directly related to a high-level activity. This in part explains why the cause of an erratum, and the effect of the erratum as observed by a user, may not seem to correlate. In addition, this makes it extremely difficult to suggest a reasonable workaround. For erratum 2.6.2, it is important to point out the word "potential" in the context of self-modifying code sequences. "Potential" means that the processor detects all actual self-modifying code sequences, as well as some sequences in which the processor "believes" that a self-modifying code situation is occurring, but in reality is not (referred to as "false" self-modifying code detection). This occurs because the processor does not check all 32 address bits when checking for self-modifying code. Therefore, the safe approach is to assume that any address match that takes place is indeed a self-modifying code sequence, in which case the appropriate corrective actions are supposed to occur for both actual and false detections. However, as described in the "Revision Guide," there are conditions under which the processor does not properly handle some "potential" self-modifying code sequences. As some users have noticed, this erratum is not occurring when using 32MB of memory, or less. This is because the likelihood of the processor detecting a "potential" self-modifying code sequence is much smaller when less memory is used in a system. In essence, there are fewer occurrences of false detections of self-modifying code. This explains why this erratum can occur even if actual self-modifying code sequences do not exist in the software.
AMD recently received reports from a limited number of users having intermittent problems while running core re-compiles of the Linux shareware operating system. Our systems engineering group has duplicated the observation and determined that it is related to a previously know erratum. Full technical details of this erratum are documented in section 2.6.2 of the AMD-K6 MMX Enhanced Processor Revision Guide on our website, www.amd.com. Users that feel they are being affected by this problem, should contact AMD's support line at (408) 749-3060 and ask for Dan Hingle or Glen Garcia.People living outside of the USA should contact their local AMD technical support.