(80386 and 80486 bugs)
There are a number of pre-pentium bugs that have been mostly discussed by
Robert L. Hummel in his book PC Magazine Programmer's Technical
Reference: The Processor and Coprocessor (Hummel). I
concentrate on the Intel 80386 and 80486 processor bugs although Hummel
also discusses previous versions of the Intel processors.
The following are some bugs for the 80386SX and 80386DX processors:
- When an IRET causes a task switch to TSS with a valid descriptor type
but an invalid limit, a double fault exception will be generated when, in
fact, an invalid TSS fault is supposed to be generated. Furthermore, if
the IDT entry for the invalid TSS fault is invalid for any reasons, a
processor shutdown will occur instead of the proper double fault abort.
- When a repeated MOVS instruction is executed while single-stepping
is enabled, the single-step trap is generated every two iterations
instead of every iteration. In the case that a data breakpoint is
satisfied during an odd iteration of REP MOVS, the breakpoint trap is not
taken until after a subsequent even iteration. However, if the REP MOVS
instruction ends with an odd number of iterations then the single-step or
breakpoint trap will occur properly after the final iteration. There is
no workaround for this bug.
- When, in V86 mode, an intersegment direct jump is located within 16
bytes of the end of a page and the next page is not cached in the TLB,
the jump instruction does not set the prefetch limit to the end of the
new code segment. In this case the limit is left at the end of the old
segment. If the old limit is bigger than the new limit then fetching can
happen past the end of the new segment and segment limit violation would
not occur. If the old limit is smaller than the new limit then a general
protection error can occur.
- When executing ESC instructions, accessing I/O addresses in the
range from 1000h to FFFFh can generate incorrect I/O addresses if paging
is enabled and the corresponding linear memory address is marked present
and dirty. However, this is not a problem for most of the PCs, for which
all I/O ports are typically restricted to addresses below 1000h.
- Breakpoints are missed when a data breakpoint is set to a mem16
operand of a VERR, VERW, LSL, or LAR instruction and the segment with the
selector at mem16 is not accessible. Also, breakpoints are missed when a
data breakpoint is set to the operand of the write cycle of a REP MOVS
instruction and the read cycle of the next iteration generates a fault.
Lastly, breakpoints are missed when a code or data breakpoint is set on
the instruction following a MOV or POP to SS and the instruction requires
more than two clocks.
- The processor microcode checks the TSS limit to ensure that it is at
least 101 bytes. However, the minimum size for the TSS is 103 bytes and
TSS limits of 101 and 102 bytes should, but don't, generate an invalid
TSS fault. This bug occurs in the 80486 processor too.
The following are some bugs for the 80486DX and the 80486SX/80487SX
- A code breakpoint that is set on an instruction like JMP, CALL,
etc., will clear the lower 4 bits of DR6 when satisfied. Another bug
will occur if a code breakpoint is set on an instruction that immediately
follows a RETN, JCXZ, intrasegment indirect CALL, or intrasegment
indirect JMP. In this case the breakpoint is taken even when the control
transfer instruction is executed. A code breakpoint set at the target
instruction will not be taken because the erroneous breakpoint will set
the RF flag. There is no workaround for this bug.
- When writing to TR5 with the control bits set to 01b, 10b, or 11b,
and if in the same time a prefetch is pending, this may cause the CPU to
- If a segment violation occurs on the target of a short jump and if
an external interrupt (NMI or INTR) occurs on the same CLK as the GP
fault, the 80486 will not correctly handle the GP fault. There is no
workaround for this bug.
- A bug in the FPU creates three cases when the FERR# error is
generated by a floating point operation, but it is not reported correctly.
- If an unmasked exception occurs when the numeric exception bit in
CR0 is clear and the IGNNE# pin is active, the performance of the FPU
will be retarded as long as the exception remains pending.