🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.intel
Article #739

Intel bugs / bugged by Intel :-(

#739
From: Jeff Prothero
Date: Thu, 25 Oct 1990 22:54
96 lines
3406 bytes
I'm upset.  Twice in six months I've spent a week or so tracking down
a bug, only to find that it's in my '386 instead of in my code.
That's not why I'm upset -- I know this is the computer industry,
where defective merchandise doesn't entitle you to a repair, a
replacement, or even an apology :-).  I'm upset because (after a month
or so of playing ring-around-the-rosie, accumulating manuals I don't
need) I'm told that Intel considers known bugs in their chips to be
proprietary and confidential information.  

This policy strikes me as reprehensible and downright stupid.  There
are a *lot* of '386s out there, some of them in embedded systems
performing life-critical tasks.  It doesn't take much imagination to
construct a scenario leading from a deliberately suppressed bug report
to bodybag(s) to a massive lawsuit.



My questions:

Does anyone want to explain why Intel adopted this policy?

Does anyone want to *defend* this policy?

Is this SOP in the industry?  Do Motorola, AMD, NS ...  follow the
same policy?

Can I go to Motorola for a list of known Intel bugs, and vice versa?

Is there a net archive of known bugs?  Any interest in forming one?
Any other affordable source?  Any reports to contribute?



For the the record, the latest bug is that a POPAD followed by a MOV
ECX, [EDX+EDI] will clobber EAX.  It appears that Intel got a little
too aggressive on the pipelining here, and that the final POPAD cycle
(which restores EAX) is being trashed by the address unit computations
for [EDX+EDI].  Here's some code to reproduce the problem, provided
courtesy of John Lauro (jal@acc.flint.umich.edu).  The bug has been
detected on an old 16MHz '386 and a new 25MHz DX, and not on an SX.
We haven't checked any other machines.

 jsp@milton.u.washington.edu

---- Cut here ----
        .386

DATA    SEGMENT  USE16 PUBLIC
MOK     DB       'POPAD ok',13,10,'$'
MNOTOK  DB       '*** POPAD fails test ***',13,10,'$'
DATA    ENDS
;
;
STKSEG  SEGMENT  USE16 STACK
        DW       100 DUP(?)
STKSEG  ENDS
;
;
CODE    SEGMENT  USE16 PUBLIC
        ASSUME   CS:CODE,SS:STKSEG,DS:DATA
CODES   PROC     FAR
START:  MOV      AX,DATA
        MOV      DS,AX     

        mov       eax,12345678
        mov       edx, 0
        mov       edi, 0
        pushad
        popad

; The instruction immediately following popad is the critical
; instruction.  Simple fix, insert a NOP after popad.

        mov       ecx, [edx+edi]

        cmp       eax, 12345678
        je        ok
        mov       dx, offset mnotok
outmsg: mov       ah, 09h    ; ConStringOutput
        int       21h

        mov       ah, 4ch    ; Exit
        mov       al, 0
        int       21h

ok:     mov       dx, offset mok
        jmp       outmsg         

CODES   ENDP
CODE    ENDS
        END      START
----------------------------------
--

- Jeff   (S)
Technical Details
Message-ID: <JSP.90Oct25155458@glia.u.washington.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!milton.u.washington.edu!jsp

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!milton.u.washington.edu!jsp
From: jsp@glia.u.washington.edu (Jeff Prothero)
Newsgroups: comp.sys.intel,comp.arch
Subject: Intel bugs / bugged by Intel :-(
Message-ID: <JSP.90Oct25155458@glia.u.washington.edu>
Date: 25 Oct 90 22:54:58 GMT
Sender: news@milton.u.washington.edu
Organization: Biological Structure, U of Wash, Seattle
Lines: 96