Path: utzoo!attcan!uunet!cs.utexas.edu!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.arch Subject: Re: Claimed bug in 80286 Summary: yep, that's the bug--and it's old Message-ID: <16006@vail.ICO.ISC.COM> Date: 10 Aug 89 23:51:17 GMT References: <1717@brwa.inmos.co.uk> <15963@vail.ICO.ISC.COM> <852@scaup.cl.cam.ac.uk> Organization: Interactive Systems Corp, Boulder, CO Lines: 46 scc@cl.cam.ac.uk (Stephen Crawley) writes: > "Computing", another UK trade rag, treats this somewhat more rationally. >... > "Intel chip bug delays software plan". > > Software developers have discovered a bug in an early version > of the Intel 286 chip which has caused several weeks of delay > on a software development project. Note that the bug is in an early version of the chip. However, this probably means that it's NOT safe to assume that you don't have to worry about it any more, unless you are in a position to control what chips are used. (If you control the hardware, you just specify a hardware require- ment for chips recent enough. If you're running on an AT, you have to worry about it.) ... > The bug means that problems arise when two interrupts -- signals > sent from the hardware to the operating system -- occur simultaneously, It's not even that. If the second interrupt request is present before the time the first instruction of interrupt handling starts to execute, the bug will manifest itself. Since there's potentially a lot of stacking going on, this is a big window. When we were testing, we had no trouble causing it once we knew what it took. The bug doesn't cause any catastrophic failure (like a screwed-up stack); things just happen in the wrong order. This might cause you to miss timing windows, but my point is that you've got some reasonable hope of identifying it. > Ian Wilson, product marketting manager at Intel said Alsys was > using a non-Intel emulator. `Alsys is running a 286 which is over > 4 years old. Errors were cured years ago.' The $2^16 question for me is why someone would be writing new interrupt- level code for the 286 in 1989! > This whole thing sound to me like Alsys' marketting making excuses > for a delayed project. Could be, but it shouldn't be hard enough to fix that you could use it as an excuse for more than a minor delay. Once you find you've got a bug in interrupt handling, you try to trace it down. If it looks like hard- ware, you find a list of errata for the chip you're using. (*However*, this may not be a trivial exercise.) -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Are you making this up as you go along?