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?