80386 bugs:
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.

80486 bugs:
The following are some bugs for the 80486DX and the 80486SX/80487SX processors:

• 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 hang.
• 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.

• Main
• Pentium FDIV bug
• Pentium II / Pentium Pro FPU bug
• Pentium MMX bug
• Bibliography

---

koncadu@earlham.edu