farhad@corwin.usc.edu (Farhad Khansefid) (11/04/87)
Hi
We recently purchased a 386 machine with hopes of running the sco
xenix-386 on it. It turned out that the 386 chip inside was one of the
early Intel 386 chips that had the "16 bit S/W Only" stamp on it. I
believe this was because of a 32-bit multiply problem or some other
bug in early designs of chips.
I recently got a hold of another 386 chip that does not have the above
stamp on it. But it also lacks any other indication that the chip is indeed
a 32-bit chip (i.e. no EE or Double Sigma mark).
My question is now this: Is there a quick and easy way to test the
chip from DOS (without having to go through installation of xenix).
The system I am using comes with MSDOS 3.2, 80Meg HD, 80387 and 1Meg
Memory and is a 16MHz machine. Note that both processors, for obvious reasons
run DOS perfectly. But my objective is to ultimately buy and install sco xenix
386.
Any comments are appreciated. Please respond directly to
farhad@usc.corwin.edu
who would route the message to me. Thanks, B. Nadjiclewis@lsuc.UUCP (11/09/87)
In article <5011@oberon.USC.EDU> farhad@corwin.usc.edu (Farhad Khansefid) writes: Regarding early revs of 386's which had a low incidence of 32bit multiply problems... >My question is now this: Is there a quick and easy way to test the >chip from DOS (without having to go through installation of xenix). Yes, there is a DOS program that will do this, but unfortunately, I don't have access to it anymore, nor am I sure what Intel's policy regarding posting It's quite small - the copy I had was on floppy contained source, documentation and a binary. Say INTEL are you listening? It would really be nice if you posted the chip testing program! If it doesn't get posted shortly try contacting a local Intel rep, they should have it. BTW: I wouldn't worry a heck of a lot about the possibility of a chip from those batches causing a problem. We ran 5 or so machines with UNIX V (ISC's) with 386's from that era - the probability of a given chip from those batches being bad is relatively low. None of our machines were affected. It's not a design problem, but a fabrication screening problem and I think that the incidence was about 10% or less. Either way, if you get a bad one, Intel will replace it free (I don't think that the offer has expired yet)
wtm@neoucom.UUCP (Bill Mayhew) (11/11/87)
The early batches of '386 CPUs from Intel a\had about a 10% failure rate on 32 bit multiplies. It is my understanding that the faliure was caused by a bug in the manufacturing quality control testing procedure.-- NOT a flaw in the architecture of the chip. Intel has a program that you can run to test your '386 CPU (I don't have a '386 here, so I haven't gone looking for the program). I'd imagine that your local intel sales rep ought to be able to get you a copy of the program. The suspect chips are marked only as "Intel 80386 CPU c. 1986" or some such. These chips could be either good or bad. Intel was selling known bad chips too (can you say "lets make a fast buck"?). The bad ones are typically marked in white ink: "16 BIT SOFTWARE ONLY". If you have one of these, Intel isn't being terribly sympathetic, I hear. Known good '386s have two capital sigmas stamped (probably on the lower left side) in black ink. According to an article in Infoworld (they could be right or wrong), Intel will made good with a replacement if you send in your dud '386. They aren't going to start until after the first quarter 1988, according to the article. I've looked at about 5 different '386 machines at several dealers in the area, and all I've seen have the two-sigma variety chip. Bill (wtm@neoucom.UUCP)
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (11/12/87)
In article <2139@lsuc.UUCP> clewis@lsuc.UUCP (Chris Lewis) writes: |In article <5011@oberon.USC.EDU> farhad@corwin.usc.edu (Farhad Khansefid) writes: | |Regarding early revs of 386's which had a low incidence of 32bit multiply |problems... |>My question is now this: Is there a quick and easy way to test the |>chip from DOS (without having to go through installation of xenix). | |Yes, there is a DOS program that will do this, but unfortunately, I don't |have access to it anymore, nor am I sure what Intel's policy regarding posting |It's quite small - the copy I had was on floppy contained source, documentation |and a binary. | |Say INTEL are you listening? It would really be nice if you posted the |chip testing program! After I posted the test program to the 386 mailing list I got a note from Intel saying that the test had to be performed over a range of temperatures and frequencies. If your chip fails the test it's bad, but if it "passes" it is not known to be good. Most chips pass under normal conditions, then fail when (something) changes. Since there is no way to change clock and temperature via software, this "test" is only slightly better than nothing, maybe worse if it gives a false assurance. I won't post it again because it's known not to be reliable. If someone else does then blame them for the results. BTW: 80386 mailing list: 386users-request@udel.edu (ARPA/UUCP) -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
hundt@wind.bellcore.com (tom hundt) (11/17/87)
>After I posted the test program to the 386 mailing list I got a note >from Intel saying that the test had to be performed over a range of >temperatures and frequencies. If your chip fails the test it's bad, but > >Since there is no way to change clock and temperature via software, this >"test" is only slightly better than nothing, maybe worse if it gives a >false assurance. I won't post it again because it's known not to be >reliable. If someone else does then blame them for the results. > Yes, but... say I want to know if *my* 386 has the bug or not. I would only care about whether or not it runs in *my* machine. So, I'd run the test on normal speed, on turbo speed (if the machine has multiple speeds), at "cold" (ie. just after power-on) and at "warm" (after running for an hour [perhaps getting caught up on today's comp.sys.ibm.pc postings]) temperatures, and that would about cover all situations I care about. If I wanted to get carried away, I could take my hairdryer to it and really let it have it... I maintain that having a test is better than none at all; the user must realize that it's a "positive yes, maybe no" situation. ("An educated consumer is our best customer" and all that.) Please post the test again. We promise not to "blame you for the results". /-^-\ Thomas M. Hundt / BELLCORE Morristown NJ / hundt@bellcore.bellcore.com | | {seismo|ihnp4|ucbvax|decvax|ulysses|allegra|clyde}!bellcore!hundt /--_--\
jru@etn-rad.UUCP (John Unekis) (11/17/87)
In article <752@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >The early batches of '386 CPUs from Intel a\had about a 10% failure >rate on 32 bit multiplies. It is my understanding that the faliure >was caused by a bug in the manufacturing quality control testing >procedure.-- NOT a flaw in the architecture of the chip. ... Nice try, but I dont think this is accurate. I beleive that the flaw was in the chip design. The gates in the multiply ALU were packed too closely together, and a zero bit surrounded by ones would be turned into a one by the induced charge from the surrounding cells. The design flaw was not found before the chips were sold due to a lack in intels quality control procedure- apparently no one in their QC department thought of testing the ALU with alternating bit patterns. A defective chip cannot be caused by poor QC procedures. What intel could have done, had their QC department been a little quicker on the draw, would have been to remove the chips that actually failed from the production stream. They could have sold potentially defective chips that didnt actually fail, and no one would have noticed while they fixed their design internnaly. But look at it from intels point of view, Western Electric had the WE32000, National had the 32032, motorola had the 68020, all 32-bit processors. All intel had was the 16-bit lineup . They just had to get something out to market to catch up with the competition. Under pressure like that it is understandable that mistakes might occur.