buck@siswat.UUCP (A. Lester Buck) (09/17/88)
There have been several postings in comp.unix.microport recently intimating that the "experts" know of a serious bug in the 80286. It seems some 80286 instructions are not restartable after a virtual memory fault, therefore a virtual memory operating system is impossible on the 80286. I happened to be interested in the 80286 buglist (Intel calls them Errata) for other reasons, but I stopped by my local Intel sales office a couple of weeks ago to get the latest information. The field applications engineer rumaged around for a while in their files and came up with an Errata Sheet Update for 80286 dated 16 January 1985, as part of Tech Bits issued Feb 22, 1985, reference no. MIP-19. These fourteen pages document 9 errata and 4 documentation changes for the B-2/B-3 stepping of the chip and 5 errata with 4 documentation changes for the C-2 stepping. (The 5 are a subset of the original 9.) I was told the current stepping (I forget what it is or when it arrived) has NO known errata. Here are the nine errata for the B-2/B-3 stepping: 1. Pullup BUSY and ERROR inputs 2. Coprocessor operand partially beyond limit of erc segment 3. CLK input requirements 4. POPF behavior 5. Don't remove interrupt signal early 6. Nested interrupts 7. Non-maskable interrupt 8. Protection Violations 9. Loading null selector values into ds or es registers Here are the four documentation changes: 1. Single-stepping the INT n instruction 2. LOCK signal during INTA cycles 3. instructions longer than 10 bytes 4. ARPL instruction I am not an 80286 expert, but the only thing that seems to effect virtual memory is #8, Protection Violations. [ begin Errata 8 excerpt] The protection violations involved usually indicate a probable software bug and restart is not desired if one of these violations occurs. In a Protected Mode 80286 system with wait states during any bus cycles, when certain protection violations are detected by the 80286 component, and the component transfers control to the exception handling routine, the contents of the CX register may be unreliable. (Whether CX contents are changed is a function of bus activity at the time interval microcode detects the protection violation.) Note that any "not present" exception when a CS, SS, DS, or ES segment is "not present" is entirely restartable, for virtual memory implementation. [ seven types of protection violation listed that no operating system should want to restart, like reading from execute-only code, or direct I/O at the wrong priority ] The following protection violation below may also lead to unreliable CX register contents. The following protection violation is designed to be restartable for dynamically growable stacks, but due to the errata, is not restartable on this stepping in a system which has wait states in any bus cycles (for example, refresh cycles in systems with dynamic memory): 8) exception #SS(0) from attempted "PUSH" below the defined limit of the stack segment (restart allows dynamically growable stack segments). Notation... exception #SS() = exception #12 = Stack Fault The value in parentheses indicates the type of error code pushed on exception handler's stack. [End of Errata 8 excerpt] It seems that a perfectly good virtual memory operating system could be written with all instructions restartable, except the feature of a dynamically growable stack segment would not be available. Is dynamic stack growth essential to Unix? Is Intel not reporting a serious errata on the 80286? It is hard for me to believe the 80286 has such a bad bug that entire sections of the manual are rendered useless. Let's have some hard facts to back up these rumors, if they are real. -- A. Lester Buck ...!uunet!nuchat!moray!siswat!buck
james@bigtex.uucp (James Van Artsdalen) (09/18/88)
Intel is not the only company producing the 286. Harris and AMD produce it also, and I'm sure others do too. Those chips have their own bugs which can be different from the Intel bugs. Systems designers cannot ignore bugs in those other chips. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
plocher@uport.UUCP (John Plocher) (09/19/88)
In article <326@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: >There have been several postings in comp.unix.microport recently >intimating that the "experts" know of a serious bug in the 80286. I'm not an expert here, but this is what I've been told by those (both here and elsewhere) who do know... > exception handling routine, the contents of the CX register may be > unreliable. (Whether CX contents are changed is a function of bus CX is used by many programs in REPeat loops, string copies, and the like. Having CX not be reliable in exception handling routines makes it hard to handle every case (trapping writes to screen is a major one, altho not really related to VM). > [ seven types of protection violation listed that no operating > system should want to restart, like reading from execute-only > code, or direct I/O at the wrong priority ] But the main problem is that since things are screwed up at this point (and are screwed up differently on different versions of the chip), writing an exception handler which is robust in the face of such "unknowns" is -what would be a good word?- non-trivial :-) >Is dynamic stack growth essential to Unix? Not really, but having it makes life easier. This is really moot, tho, because the 386 has none of these problems [but it has a few of its own], and a 386 box onow costs the same as a 286 system did a year ago. See also the points made about the "fun" involved in paging 64K segments in previous postings. >A. Lester Buck ...!uunet!nuchat!moray!siswat!buck -John (Not a 286 internals expert) Plocher
david@daisy.UUCP (David Schachter) (09/20/88)
Daisy's "DNIX" operating system is a virtual memory operating system for the '286. It has been around since mid 1985 and works fine. The only chip problem was a problem with the flags byte being trashed when attempts are made to write to read-only segments. This prevented us from emulating dirty bits by marking data read-only until the first attempted write. DNIX is a segment-swapping virtual memory operating system, with support built into the (real-time) kernel for window management and networking. Not bad, for a '286. (It also runs on the 8086, but without virtual memory, and much slower.) By the way, I'm writing this from an 80386 system running DNIX XV5.0.10, rlogin to a VAX 750 running 4.2 bsd Unix. -- David Schachter
vandys@hpindda.HP.COM (Andy Valencia) (09/20/88)
/ hpindda:comp.unix.microport / david@daisy.UUCP (David Schachter) / 2:38 pm Sep 19, 1988 / >Daisy's "DNIX" operating system is a virtual memory operating system >for the '286. It has been around since mid 1985 and works fine. Ok, I'll nibble. How much does it cost? Does it pass SVVS? Andy
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (09/21/88)
In article <326@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: | There have been several postings in comp.unix.microport recently | intimating that the "experts" know of a serious bug in the 80286. | It seems some 80286 instructions are not restartable after a virtual | memory fault, therefore a virtual memory operating system | is impossible on the 80286. I haven't tried OS/2 yet, but the documentation clearly claims that virtual memory is done in 64k chunks. I doubt that IBM would have let it out the door if there was a problem such as you describe, and I see nothing in the current buglist which would indicate problems restarting any pagefault. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
u-dmfloy%sunset.utah.edu@utah-cs.UUCP (Daniel M Floyd) (09/21/88)
Just a small comment on this topic. If you are the one that has to discover a bug in a processor, or rediscover, it doesn't make any difference how "significant" it is considered to be because the bug you find is the bug you hate ...significantly. I've found a processor bug once and I lost several weeks and pounds of hair. Dan Floyd 8<D=
david@daisy.UUCP (David Schachter) (09/23/88)
To clear up some confusion: A few days ago, I mentioned Daisy's proprietary Operating System "DNIX", a virtual memory, multi-window (multi-job, multi-tasking) networking operating system. I've gotten several requests for information on it. Daisy still supports DNIX, for the several thousand Daisy customers who have it. But DNIX is proprietary. Our marketing department probably has a pretty brochure full of generalities. But you can only get DNIX bundled with other Daisy software, and sometimes bundled with Daisy hardware. If you have specific questions about our implementation, please e-mail me. But since DNIX is targetted at the 80286, it is probably only of academic interest now, if that. Daisy is accessible from a number of usenet paths. The most general is probably: uunet!daisy!david. I apologize for any confusion caused by my earlier message. -- David Schachter (Now, if only I'd remember that "." isn't the way to exit vi's input mode....)