Article View: comp.sys.intel
Article #739Intel bugs / bugged by Intel :-(
From: Jeff Prothero
Date: Thu, 25 Oct 1990 22:54
Date: Thu, 25 Oct 1990 22:54
96 lines
3406 bytes
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!jspShow 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