twb@cbnewsh.att.com (thomas.w.beattie) (01/04/91)
In article <2804@sixhub.UUCP>, ibmbin-request@crdgw1.crd.ge.com writes: > This postings is a test program for a bug in the 386 processor. It > seems potentially serious. > > The submitter w8sdz@tacom-emh1.army.mil says: > > It seems that a new bug in some 386 processors has been discovered. > Mine failed the test and the system acted weird after running the > program. I think the bug messed up the stack or something. Everything > was ok again after I rebooted. I'm not real happy about having a > defective processor, Bill. You may wish to tell your 386 mailing list > about this bug. It looks serious. I tried this test on two 386 machines from different manufacturers and both failed. One is a 386DX/16, the other a 386DX/25, both double sigmas. The machines seem to work just fine however. What exactly is the bug? What kind of "potentially serious" problems are expected? --- Tom Beattie att!hoqaa!twb t.w.beattie@att.com
tcs@mailer.jhuapl.edu (Carl Schelin) (01/04/91)
I ran this on my IBM Model 80 here at work and on a new clone 386 25mhz (three months old) and they both failed. The one at home has a co-processor but the one here doesn't (80). Anyone know what this is supposed to do? I did a virus check before running and rebooted immediately after running (just to make sure). No problems so far. ????? Carl Schelin tcs@mailer.jhuapl.edu
bb16@prism.gatech.EDU (Scott Bostater) (01/04/91)
In article <336@aplcomm.JHUAPL.EDU> tcs@mailer.jhuapl.edu (Carl Schelin) writes: >I ran this on my IBM Model 80 here at work and on a new clone >386 25mhz (three months old) and they both failed. The one at home >has a co-processor but the one here doesn't (80). > >Anyone know what this is supposed to do? I did a virus check before >running and rebooted immediately after running (just to make sure). >No problems so far. We've run it on several 386's where I work and it fails on all of them. It has not failed on the one 486 that we have. I haven't yet tried it on a 386sx (anybody out there with a SX tried it??). It also shows up in both of the Sun 386i's that I have access to. As far as I can tell from running the code in Turbo Debug, the only error is that the EAX register gets cleared. As the code stated this can be corrected by placing a NOP after the POPAD command (or single stepping through the code :-). Looks like a microcode timing error. As far as ramifications of this bug, I personnally don't think its too major of a problem unless you want to program assembly code. In that case you'll just have to remember to add the NOP after the POPAD command. When programming in 286 assembly language I have had little reason to use the POPA command since I hardly ever need to push/pop ALL the registers. Its normally faster to push/pop just the required registers. There would be even less justification to push/pop all of the 32-bit registers. Since there has been a moderate amount of 32-bit code produced by now and this is the first that the bug has shown up, I don't think the POPAD command is getting used. Not having access to a any 32 bit compilers, I don't know if any of them generate the POPAD command, but I would doubt it unless you were optimizing for smallest code size (and we all optimize for fastest execution, right? :-) IMHO, the bottom line is that 1) yes, Intel has another bug 2) no, the average programmer probably doesn't need to worry about it 3) writers of 32-bit compilers and OS's should be aware of it Well, that's my $0.05 worth ($0.02 plus overhead :-) -- Scott Bostater Georgia Tech Research Institute - Radar Systems Analysis "My soul finds rest in God alone; my salvation comes from Him" -Ps 62.1 uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16 Internet: bb16@prism.gatech.edu
mlord@bwdls58.bnr.ca (Mark Lord) (01/04/91)
In article <...> bb16@prism.gatech.EDU (Scott Bostater) writes: < <We've run it on several 386's where I work and it fails on all of them. It has <not failed on the one 486 that we have. I haven't yet tried it on a 386sx <(anybody out there with a SX tried it??). It also shows up in both of the <Sun 386i's that I have access to. It also fails on my 386sx-16. <As far as ramifications of this bug, I personnally don't think its too major <of a problem unless you want to program assembly code. In that case you'll <just have to remember to add the NOP after the POPAD command. When programming <in 286 assembly language I have had little reason to use the POPA command <since I hardly ever need to push/pop ALL the registers. Its normally faster to <push/pop just the required registers. There would be even less justification to <push/pop all of the 32-bit registers. Since there has been a moderate amount <of 32-bit code produced by now and this is the first that the bug has shown up, <I don't think the POPAD command is getting used. Hmmm. So if it shows up anywhere, it'll be in windows3, os/2, Qemm386, and perhaps other 32-bit operating environments.. Might even explain the occaisional mysterious crashes seen in all of these. Not likely, though. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
mjf@cunixd.cc.columbia.edu (Michael J Flory) (01/05/91)
Tried the POPADBUG test on two clones -- my 20MHZ Tangent with 387 (about six months old) and a colleague's year-old Northgate (20MHz? with 387) -- both failed. Didn't get time to try it on a new '486... Anyone with a 386 that passed? I've run a suite of stat tests on my machine and the output is perfect, and I've never had mysterious crashes. Perhaps the compilers in use never load the stack in the manner tested by POPADBUG? (If that doesn't make sense it's because I'm well out of my depth...) BTW, both machines behaved fine after running the test. -- Michael Flory (mjf@cunixd.cc.columbia.edu)
gtoye@supernet.haus.com (Gene Toye) (01/05/91)
I have a 386sx/16 (being pushed to 20) and it passed on mine. So did
Intel turn out a bad batch of chips (both SX and DX), have they
redesigned the 386, or what is going on here?
Anybody know??? Anybody from Intel out there reading this ???
--
Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248
Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org
Usenet: uunet!{iex,ntvax}!supernet!gtoye
DISCLAIMER: My employer never knows what I am going to say next.shelby@sun1.ise.ufl.edu (Scott Preston) (01/05/91)
My SX failed the test of course! I think all 386s fail this test..is this a bug OR, a "feature" since sooooo many have this??
merckens@cana.sci.kun.nl (Merckens A) (01/05/91)
In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott Preston) writes: > > My SX failed the test of course! I think all 386s fail this test..is this >a bug OR, a "feature" since sooooo many have this?? Not all 386 fail this test: my 386SX passes, so not feature I'm afraid... Arjen.
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/05/91)
The POPAD bug is, I think, documented in the Intel Errata sheets. As near
as I can tell, some of the register contents are invalid at the instruction
just after a POPAD. You can insert a NOP, or any kind of branch and you're
OK.
The Intel guys probably missed it because they always did a
POPAD
IRET
or
POPAD
RET
which works fine.
Take a pill and chill, dudes. All 386en probably fail the POPAD test,
and it don't matter.
--
Kent Williams --- williams@umaxc.weeg.uiowa.edu
"'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams"
"This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"greg@turbo.atl.ga.us (Greg Montgomery) (01/05/91)
yjkim@viking.cs.uh.edu (Yeong-Joon Kim) writes: > In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott > > > > My SX failed the test of course! I think all 386s fail this test..is th > >a bug OR, a "feature" since sooooo many have this?? > > My 16MHz 386SX passed the test. It says, "papabug, OK." And after the > test it runs fine. Mine failed. I have an old Compaq 386s. I bought it when the 386SXs were just coming out. Maybe this bug is just in the old 386s?? ---- Greg Montgomery | Montgomery Consultants, Inc. | Atlanta, Georgia, U.S.A Internet: greg@turbo.atl.ga.us | Home of the '96 UUCP: {rutgers,ogcise,gatech}!emory!turbo!greg | Olympics!
dave@interlan.Interlan.COM (Dave Goldblatt) (01/06/91)
In article <3799@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu (Kent Williams) writes:
The POPAD bug is, I think, documented in the Intel Errata sheets. As near
as I can tell, some of the register contents are invalid at the instruction
just after a POPAD. You can insert a NOP, or any kind of branch and you're
OK.
This seems to be the case.
Take a pill and chill, dudes. All 386en probably fail the POPAD test,
and it don't matter.
It may not be cause for great concern, especially since there are very
few 386 compilers being used for production code.
HOWEVER, for those of us who program in assembler, this is definitely
something to be aware of. The 1990 version of the _386DX Programmer's
Reference Manual_ makes no statement of this. Not surprising (in fact,
par for the course), so you should regularly request the errata sheets.
But it *might* matter.
-dg-
--
"Never, I repeat never, * Dave Goldblatt [dave@interlan.com]
give peace a chance!" * Diagnostic Engineering
- _Zarlor Mercenary_, * Racal InterLan
Atari Corp. (Lynx) * Boxborough MA (508) 263-9929yjkim@viking.cs.uh.edu (Yeong-Joon Kim) (01/06/91)
In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott Preston) writes: > > My SX failed the test of course! I think all 386s fail this test..is this >a bug OR, a "feature" since sooooo many have this?? My 16MHz 386SX passed the test. It says, "papabug, OK." And after the test it runs fine.
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/06/91)
In article <DAVE.91Jan5170443@slam.InterLan.COM> dave@interlan.interlan.com writes: >HOWEVER, for those of us who program in assembler, this is definitely >something to be aware of. The 1990 version of the _386DX Programmer's >Reference Manual_ makes no statement of this. Not surprising (in fact, >par for the course), so you should regularly request the errata sheets. > Intel never corrects typos in their manuals, and they give out processor bug sheets only grudgingly. There are (I think) about thirty hardware bugs in the 386 and SX. Most of them are pretty trivial, but I wouldn't want to try and write any protected mode system software without knowing where they were. -- Kent Williams --- williams@umaxc.weeg.uiowa.edu "'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams" "This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/08/91)
In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott Preston) writes: | | My SX failed the test of course! I think all 386s fail this test..is this | a bug OR, a "feature" since sooooo many have this?? I have yet to see a DX pass or an SX (or 486) fail. That doesn't mean a lot, but I'd rather have a CPU which *words*. My major worry is not breaking code in a given program, although I like things to work, of course. My question is if there is any way this could be a point of attack to crash a protected mode app. I haven't been able to do it, but that doesn't mean it can't be done. The point of attack would be if a status register of seg register were wrong, could protection be violated? That doesn't *seem* to be true. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
vac223l@monu6.cc.monash.edu.au (Evan McLean) (01/08/91)
yjkim@viking.cs.uh.edu (Yeong-Joon Kim) writes: >In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott Preston) writes: >My 16MHz 386SX passed the test. It says, "papabug, OK." And after the >test it runs fine. Mine too. (386SX as well) ___ Who : Evan McLean Also known as Wendigo | Don't look back, <*,*> Where : vac223l@monu6.cc.monash.edu.au | the lemmings are [`S'] Super Was : Caulfield Institute of Technology | gaining :) -"-"- Owl Now : Monash University (Caulfield Campus) | -- ___ Who : Evan McLean Also known as Wendigo | Don't look back, <*,*> Where : vac223l@monu6.cc.monash.edu.au | the lemmings are [`S'] Super Was : Caulfield Institute of Technology | gaining :) -"-"- Owl Now : Monash University (Caulfield Campus) |
lev@suned1.Nswses.Navy.MIL (Lloyd E Vancil) (01/09/91)
(Scott Preston) writes: >>My 16MHz 386SX passed the test. It says, "papabug, OK." And after the >>test it runs fine. I have been very interested in this "bug" because of some of the things I've seen on the Windows group. Here's one for you programmers out there; could this "bug" be why some users of 386 machines have had sooo many problems with windows 3.0? My observation has been that those who come to the net with serious and mysterious problems have been; 1 running a 386. 2. often using aftermarket drivers etc. 3. experiencing problems in only certain parts of the WIN 3 environment. It occurs to ME, a decidedly Amature Programmer, that this could be the reason for some problems with some setups. -- * suned1!lev@elroy.JPL.Nasa.Gov sun!suntzu!suned1!lev . lev@suned1.nswses.navy.mil + . + * S.T.A.R.S.! The revolution has begun! * My employer has no opinions. These are mine!
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/09/91)
OK ENOUGH!
I have looked at Jeff Prothero's dos extender source. In it there is one
place where he puts a NOP after a POPAD, and comments that it is a workaround
for the POPAD bug. Elsewhere in this huge assembly code file there are
comments on other 386 bugs. NOWHERE does he say that he 'discovered' the
POPAD bug, and I've seen no proof from anyone that it is, in fact, a newly
discovered animal, OR that it is serious, OR that the people who write
extended applications like Windows 3.0 aren't aware of it.
If you're a big-time developer, and Microsoft is as big as they come, you're
into Intel's pants deep enough that you get all the bug sheets.
So guys, stop spazzing out. If you want to POPAD, put a NOP after it, and stop
acting like the sky is falling!
BTW, when I run the test program, my 386sx fails. If I run it under a debugger
it works, since the next instruction after the POPAD is the trap back to the
debugger.
--
Kent Williams --- williams@umaxc.weeg.uiowa.edu
"'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams"
"This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"pwilliam@axion.bt.co.uk (Philip Williams) (01/10/91)
From article <6952@suned1.Nswses.Navy.MIL>, by lev@suned1.Nswses.Navy.MIL (Lloyd E Vancil): > (Scott Preston) writes: > I have been very interested in this "bug" because of some of the things > I've seen on the Windows group. Here's one for you programmers out there; > could this "bug" be why some users of 386 machines have had sooo many > problems with windows 3.0? > My observation has been that those who come to the net with serious and > mysterious problems have been; 1 running a 386. 2. often using aftermarket > drivers etc. 3. experiencing problems in only certain parts of the WIN 3 > environment. > It occurs to ME, a decidedly Amature Programmer, that this could be the reason > for some problems with some setups. > > My 20 MHZ/386 clone fails the test but the only problem I have had with Windows 3 was a lock up when I was running mf2. I'm using a svga driver from the net. A hhappy user..... ;-) Philip ******************************************************************** P M Williams pwilliams@axion.bt.co.uk BTRL, Martlesham Heath, Ipswich, Suffolk, United Kingdom 'Phone 0473-642770 Message Pager 4226754 (bureau 0345 333111) ********************************************************************
shelby@sun1.ise.ufl.edu (Scott Preston) (01/10/91)
I just want to state that MY name has been associated in several posts
with several DIFFERENT peoples words!! My original post was two lines and
I have been posted as writing at least 3 and possibly 4 different messages
here! Try to be careful when including text and attributing to someone!!
I do have the "BUG", although I have been attributed to statements to the
contrary! I also did not post the windows & popad bug question.....
not that any of this matters!
shelby @ sun1.ise.ufl.edudcrowley@sunc.mqcc.mq.oz.au (David Crowley) (01/11/91)
In article <1991Jan5.044926.14501@eng.ufl.edu> shelby@sun1.ise.ufl.edu (Scott Preston) writes: > > My SX failed the test of course! I think all 386s fail this test..is this >a bug OR, a "feature" since sooooo many have this?? Your SX may have failed but mine at home didn't, but all the SX's and DX's at work failed. So it is actually a bug. I think it can be "fixed" by putting a NOP just after the POP (of the stack) - at least that is what I read in another article about this. David... -- -----------------=\|/= = = = = = = = = = = = = = = = = = = = = = = = = = = = = David Crowley --@-- Database Programmer, Macquarie University, Australia ----------------- /|\ email: dcrowley@suna.mqcc.mq.oz.au At MacUni - Phone = 61 2 805-8742 Room = EsevenB 238 ||