Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Claimed bug in 80286
Summary: could be a very old one
Message-ID: <15963@vail.ICO.ISC.COM>
Date: 28 Jul 89 06:55:36 GMT
References: <1717@brwa.inmos.co.uk>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 63

In article <1717@brwa.inmos.co.uk>, davidb@inmos.co.uk (David Boreham) writes:

> The following appeared on the front page of a UK trade paper...
>...Headline (36pt bold) - "Design Fault Found in Processor Chip"  
. . .
>   `A company called "Alsys" (an ADA compiler house) says that there is
>   a bug in the 80286 involving interrupts. They have proved its existance
>   using software.'

I'm inclined to side with David's cynicism in what is reported here.  Gosh,
they found the bug with software!  Imagine that--the hardware isn't
working, so you write a program to find it!  (In the UK, it goes in a trade
rag...in the US they'd try to patent it as a debugging technique!)

There are some bugs in some versions ("steppings" they seem to call them)
of the 286.

In terms of interrupt handling, for example, I know of a bug which will
allow a one-instruction window at the start of interrupt processing during
which interrupts are not disabled.  The effect of this bug is that it can
allow a lower-priority interrupt to come in on top of a higher-priority
interrupt...so it certainly fits all the criteria David was able to supply
from the article to identify the bug.  Dealing with it causes major rectal
discomfort...because the solution is to study the stack before dispatching
to the interrupt handler, and if it has occurred, rearrange the stack to
make the interrupts appear to have occured in a plausible order (in effect
pretending that the lower-priority interrupt occurred first).  The code
itself is trivial, but the process of debugging that code which rearranges
interrupt stack frames is seriously unpleasant.

BUT--and here's the possible major objection to the article--when I had to
deal with this, it was early '87, and the bug was old news even then; I was
rewriting someone else's code to handle the bug.

> Although the journalist (Leon Clifford) obviously regarded the possibility
> of a bug in the 80286 as something to plaster over the front page (along
> with ominous comments about planes falling out of the air due to processor
> bugs), readers of this newsgroup will know that bugs in production revisions
> of devices are very common and don't really merrit all this frothing at the 
> mouth.

Trade rags are rags.  I'd be more interested in why Alsys is proclaiming
the bug.  In particular, I'd like to know enough about the nature of the
bug to see if it's one that's been known for a while.

> Now... Personally I think that you can't much lower than publishing
>   unsubstantiated claims about someone's device in a trade paper. 

That sentence no verb, but we know what you meant.  I think there are lots
of things lower, but I take your point.

> However... can anyone shed any informed light on  the matter (or
>   comment on the ethics of hopping up and down madly about actual
>   or possible bugs) ??

Let's hear more about the bug and we'll see if it's old or new and real or
not.

I think there are good reasons to hop up and down about some bugs, but it
depends on the bug.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Simpler is better.