john@inthap.UUCP (04/22/86)
> > While experimenting with an asynchronous communication driver > for VENIX (in protected mode) on the IBM PC/AT, I > encountered some rather strange behavior that I now > attribute to a bug in the Intel 80286 processor. In > brief, I suspect that the "popf" instruction enables > interrupts under certain circumstances even though the > IF flag is 0 before the instruction is executed and set > to 0 by the "popf" instruction itself. Early 80286 chips (B step) did contain a problem like the one described here. These chips can be identified by the copyright notice marked on the chip. Chips bearing the notice: (C) INTEL '83 may suffer from the popf problem. Chips bearing a later copyright date (84 or beyond) do not suffer from this problem. While the B step 80286 has not been produced by Intel for some time they may exist in some older 80286 based machines such as early ATs. Since their are obviously machines out their with these older chips let me further describe both the problem and the workarounds. If a B step 80286 executes a POPF instruction while interrupts are disabled a pending maskable interrupt (INTR pin active) may be improperly recognized after executing the POPF instruction even if maskable interrupts were disabled before the POPF instruction and the value popped had IF=0. IF the interrupt is improperly recognized, it is processed correctly. The problem occurs in B step 80286s executing a POPF instruction while interrupts are disabled in either Real Address Mode, or in Protected Mode with CPL <= IOPL. Executing in Protected Mode with CPL <= IOPL implies that the processors Current Privilege Level (CPL) is numerically less than or equal to the IO Privilege Level (IOPL), that is, the currently executing code is privileged enough to enable/disable interrupts and do IO. The occurrence of this errata may be affected by the number of wait states during the data read bus cycle of the POPF, and by even or odd address alignment of the stack. Two wait states added to the memory read bus cycle will eliminate the problem. The problem can be avoided by replacing POPF with an alternate code sequence in code that may be susceptible to the problem. The original posting stated that the following code failed: > > 1) pop cx | return address > popf | new flags > pushf | dummy arg > jmp cx | return Recoding without using POPF produced the following working code: > > 7) pop cx > pop ax > push ax > test ax,#0x200 | Don't use popf! > bne Lsplx > cli > jmp cx > Lsplx: sti > jmp cx This illustrates one possible alternate code sequence for POPF which will work if AX need not be saved and if IF is the only flag of interest. Other more general alternatives to POPF are as follows: push cs push #popflags iret popflags: OR call popflags | must be a far call where the routine popflags is defined as follows popflags: iret John Casey Intel Corporation (516) 231-3300 ...!philabs!ron1!polyof!inthap!john
jer@peora (05/03/86)
> While experimenting with an asynchronous communication driver for VENIX > (in protected mode) on the IBM PC/AT, I encountered some rather strange > behavior that I now attribute to a bug in the Intel 80286 processor. There was also an article in the latest issue of this new newspaper that replaced _On_Communications_ (I forget the name, I think it might be _Network_World_) that claimed that a bug existed in the 286 which was causing network processors using that MPU to "lock up". Unfortunately, the article was very unclear on what was going on; and according to the article, Intel denied any problem existed, claiming manufacturers just hadn't followed the documentation properly, whereas the manufacturers interviewed claimed there was a bug in the processor. Does anybody know what is going on with that, and if it is the same problem referenced above? -- E. Roskos