mack@inco.UUCP (Dave Mack) (07/21/88)
The following problem description was posted on 7/18/88. The problem
solution was received via uucp mail from Bill Greene.
I am posting the problem description and the (correct) solution in
hope of saving time and money for other 80386/80387 Unix users.
===================================
Floating Point Problem Description
===================================
Posted Monday, 7/18/88 in comp.unix.microport
HELP !!!
I have a problem with C compiler floating point operations under
Microport Unix 386 Version 2.2. Any code that contains floating point
operations blows away both cc and lint. In some cases this also locks
up the computer such that I have to reboot. In other cases the "comp"
process spawned by cc just runs forever. I dont think that this is
an 80387 problem because the crash happens during the compile or
lint phase rather than during execution. There is no "core" file created
when I reboot or when I "kill -9" the comp process.
My version of Microport System V.3 is 2.2. DOS Merge/386 and Streams are also
installed. My system is an ALR 386/220 with the 80387 floating
point coprocessor, 2 MB of RAM, and a Seagate 80 Mb hard disk with
a Western Digital controller.
I took delivery of this system with the Microport operating system
on May 28, 1988 from Advanced System Concepts of Arlington, Va.
I reported this floating point problem to Microport (with examples
on floppy disk) on 6/21/88. Microport technical support acknowledged
receipt on 6/24 and have responded that they were unable to duplicate
my results. On 7/14 I contacted the Microport sales with some related
questions on their next release. I was told that Version 2.2 does not
include either 80387 support or 80387 emulation (i.e. no floating point
support); however, the next release scheduled about August 1 will
include these features in addition to the Green Hills C compiler.
I am still communicating with Microport on this problem and the
possible information discrepency between their sales and tech support.
This is not an attempt to complain about Microport. I feel that they
provided me with a reasonable System V.3 port; however, I am posting
this in hopes that someone else has encountered simular problems,
isolated the cause and discovered a workaround.
Please mail your responses to "uunet!bts!bill". I will summarize and
post the results.
A typical code segment that causes "comp" to run forever on "cc -c test.c"
follows:
/* test.c */
main()
{
float x,y,z;
z = 2.0;
x = 3.0;
y = x * z;
}
/* end test.c */
================================
FP SOLUTION FROM BILL GEREENE
================================
>From uucp Mon Jul 18 18:13 EDT 1988
>From csmunix.larc.nasa.gov!whg Mon Jul 18 14:57:37 1988 remote from uunet
To: bill%bts.uucp
Subject: Floating point problems
Bill,
I felt a certain deja vu reading your recent posting. I experienced a
similar problem running cc on System V/386 and nearly pulled my hair out
trying to understand it. I also sent a copy of my C program to Microport
and they were unable to reproduce the problem. The problem is in fact the
Eratum 21 (386/387/paging) bug. I know it seems a little strange that the
compiler is executing floating point instructions, but it does seem to be.
The symptoms you observe are identical to what I experienced. You can verify
that the problem is Eratum 21 by simply removing the 387 and doing your
compile or you can just get one of the math adapter boards from Bell Tech.
I think its overpriced at $ 145.00 but it does work. Good luck.
Bill Greene
=======================================
ADDITIONAL INFORMATION FROM BILL GREENE
=======================================
>From uucp Tue Jul 19 09:01 EDT 1988
>From csmunix.larc.nasa.gov!whg Mon Jul 18 22:43:11 1988 remote from uunet
To: bill%bts.uucp
Subject: More on Erratum 21
Bill,
Erratum 21 is an occasionally discussed bug in the 80386 that occurs
sometimes during floating point operations when paging is also occuring.
Intel has said that they have plans to fix this bug but I'm not sure if
that has happened yet. Some motherboard manufacturers (but not yours
or mine) have included circuitry on the board to work around the problem.
I think maybe the Compaq 386/20 is immune from this problem. As an alternative
Bell Technologies has been selling something they call the 386 Math Adapter
which will also cure the problem. It is just a small daughter board that
has a 386 socket and a single PAL on it. You just unplug your 386, plug
in the math adapter, and then plug the 386 back in on top. As I mentioned,
the price for all this hardware is $ 145.00. I've heard there is also another
company selling a similar product but I can't remember the name. Anyway, the
number for Bell Tech, if you don't have it handy, is 800-FOR-UNIX. Supposedly
they have slightly different configurations of this board to better fit your
particular motherboard. I mention this because the one I have is a very
tight fit in my box and one oriented 90 degrees would be a big help.
Anyway, glad you resolved your problem. I struggled with it for several
months and know how frustrating it can be. I'm very surprised with how little
discussion there is on the net about this problem. I guess most 386 Unix
users aren't using 387's. I posted an enquiry about a month ago soliciting
people's experiences with both 387's and 1167's under Unix and got only
a couple of responses. Regards.
Bill Greene
PS: I believe Microport is actually using these Bell Tech boards in
some of their machines, which may be why they can't reproduce the
problem. Doesn't explain, however, why they can't just suggest a
remedy when the symptoms are so obvious.
===============
POSTED BY
Bill Hatch
Computational Engineering
(formerly Business and Technological Systems)
14504 Greenview Drive Suite 500
Laurel, Maryland 20708
(301)470-3839
..uunet!bts!billkarl@njs.UUCP (karl) (07/22/88)
<-------------------------- FLAME ON!!!! --------------------------------> I have been responsible for four systems in the Milwaukee area which use (or try) to use Microport Unix. One of these systems is already in a junk pile with my customer asking for a refund. Let's examine some of my specific problems: - One of the systems, uses MP system V/386 with DOS merge. This system has a "pre-release" version of DOS merge. My customer wishs to use a logi-tech mouse (Which does not work) and the Ventura Publishing Package. Each time (Perhaps 10 phone calls) I call MP about the "pre-release" DOS merge, they tell me that some special person (Someone they refuse to give the name of) is not there, and is the ONLY person I can talk is never there and has never returned any of my phone calls. I've have had no choice but to buy them a different Publishing package, and fight with them about no mouse. If this special "SOMEBODY" is listening, perhaps they could bless me with a phone call. This problem has been going on for over four months now. - Another customer (This is the sad, angry one who wants their money back) has MP system V 386, with an unlimited login package. - First, before the system was purchased, I called MP to see which tape backup drive was suitible for use with their UNIX. I was told by their sales staff (The wisconsin REP) that the EVEREX 60M ev-810 was the one to buy, although I did have to pay extra for the driver. GUESS WHAT? when I got the package the tape drive didn't work. The documentation said "newer ev-810 will not work with our software". Well, I'm still fighting with various people to return the tape drive and the driver disk. - 2nd problem, and perhaps the reason I typed this in, is the SAME floating point problem as described by other people. The compiler crashed, programs won't run, and MP won't help. I called many times on this problem, was told that the 386 person only worked there two hours each day, and spent that time very busy with answering questions. Well, finaly, after a week of phone calls, the 386 man called me. He said they were aware of a BUG with floating point, and that they have already fixed it in house. He said, "I'll send you a pre-release version to help you out". Boy was I happy, my heart sang, my feet danced, and a renewed feeling about MP had come. GUESS WHAT? nothing was ever sent to the customer (Video Station - Milwaukee), not a disk, not a letter, not a phone call. My further attempts to reach the 386 person have failed. No one has EVER returned my phone calls. - Whatever happened to the "Greenhills" compiler that was advertised? My customer bought this over Bell-tech and others because of this feature. GUESS WHAT? no-Greenhills and a person telling me at MP that my customer MUST buy the support plan if they wish to get it. I have NEVER been able to get any of my customers to buy the support plan, based on the fact that they a package out of a box, with problems, and are NEVER helped. How can I tell them that support would be any better. PEOPLE WHO BUY SOFTWARE THAT IS BROKEN SHOULD NOT HAVE TO PAY FOR THE REPAIR ONE DAY AFTER THE PACKAGE IS RECEIVED! - Another problem with the same customer, is BAD BLOCKS. the installation procedure for MP/386 is defective if your hard disk has any bad sectors on it. Again, many calls were made, nobody could talk to me, nobody called me back. Finaly, I just looked around and found another drive with no defects. In summary, I have NEVER had any success with getting the right people on the phone, or that one time it did happen, I was LIED to and got no help in the end. LYING about the Green-hills compiler is even worse. A man named "John Plocher" sounds noble, and I hope he gets this message in a bottle. Maybe he can help? I am also concerned that the only person working on the 386 port is only there two hours each day. Heck I get two hours of Microport related complaints each day. ------------------------------------------------------------------------------ Karl Vollbrecht (414) 358-1180 (poor unused phone number) Vollbrecht & Associates 6515 N. 40th Street Milwaukee, WI 53209 ------------------------------------------------------------------------------
wes@obie.UUCP (Barnacle Wes) (07/23/88)
In article <2432@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes:
% >From uucp Tue Jul 19 09:01 EDT 1988
% >From csmunix.larc.nasa.gov!whg Mon Jul 18 22:43:11 1988 remote from uunet
% To: bill%bts.uucp
% Subject: More on Erratum 21
%
% [Discussion about problems compiling floating point code with cc on
% Microport System V/386]...
%
% Erratum 21 is an occasionally discussed bug in the 80386 that occurs
% sometimes during floating point operations when paging is also occuring.
% Intel has said that they have plans to fix this bug but I'm not sure if
% that has happened yet. Some motherboard manufacturers (but not yours
% or mine) have included circuitry on the board to work around the problem.
% I think maybe the Compaq 386/20 is immune from this problem.
Nope, the Compaq isn't immune to this bug. SCO got stung by this one
with Xenix V/386 - they were recommending the 386/20 as THE platform to
run Xenix V/386 on, and they were dying all over the place. Everyone
was blaming SCO, and of course, it wasn't their fault. Thanks, Intel.
--
{hpda, uwmcsd1}!sp7040!obie!wes
"Happiness lies in being priviledged to work hard for
long hours in doing whatever you think is worth doing."
-- Robert A. Heinlein --mikep@olgb1.oliv.co.uk (Mike Pellatt) (07/29/88)
In article <2432@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: > >From csmunix.larc.nasa.gov!whg Mon Jul 18 22:43:11 1988 remote from uunet > To: bill%bts.uucp > Subject: More on Erratum 21 > > Bill, > > Erratum 21 is an occasionally discussed bug in the 80386 that occurs > sometimes during floating point operations when paging is also occuring. > Intel has said that they have plans to fix this bug but I'm not sure if > ...... I think this one will be fixed in the 'D' stepping of the 80386 (when that finally hits the streets...) > Anyway, glad you resolved your problem. I struggled with it for several > months and know how frustrating it can be. I'm very surprised with how little > discussion there is on the net about this problem. I guess most 386 Unix > users aren't using 387's. I posted an enquiry about a month ago soliciting > people's experiences with both 387's and 1167's under Unix and got only I used to work for a company that manufactures 386-based AT baseboards (European Tech. Mktg. for it). We got REALLY burnt on this one, not just with Unix. The board had 512KB non-expandable on the baseboard, so to backfill to 640KB for DOMESTOS our customers had to use software like QEMM Or Phoenix's Control-386 to put the 386 in virtual-86 mode and usse the paging hardware to "move" 128KB from plug-in 32-bit memory, which sat in the address space from 1MB upwards. This blew out Autocad for one, with the 387 installed. My experience (up to Jan. this year) was that we didn't get problems with Xenix/Unix. Basically, I think, because the majority of customers ran DOMESTOS. Ho- hum. (Oh yes - for you guys the other side of the pond. DOMESTOS is the brand name of a bleach/lavatory cleaner in the UK. Hence the pun on MSDOS) Mike Pellatt - Xi Software Ltd. Sorry for the brief .sign - this is a uucp:...mcvax!ukc!uel!olgb1!mikep newsreading acct.
neighorn@qiclab.UUCP (Steve Neighorn) (08/05/88)
In article <543@olgb1.oliv.co.uk> mikep@olgb1.oliv.co.uk (Mike Pellatt) writes: <In article <2432@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: << >From csmunix.larc.nasa.gov!whg Mon Jul 18 22:43:11 1988 remote from uunet << To: bill%bts.uucp << Subject: More on Erratum 21 << << Bill, << << Erratum 21 is an occasionally discussed bug in the 80386 that occurs << sometimes during floating point operations when paging is also occuring. << Intel has said that they have plans to fix this bug but I'm not sure if << ...... < <I think this one will be fixed in the 'D' stepping of the 80386 <(when that finally hits the streets...) The latest disks from Interactive and Intel (Version 3.1) include a question about Erratum 21 in the installation procedure. Basically the INSTALL script asks whether the 80386 being used in the system has "D step" or after 80386. A special software patch which fixes the FP problems will be installed if you respond with a "Yes you want the patch applied." If you don't have a 80387, or have a D step 80386, the patch doesn't need to be applied. -- Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn Intel Corporation "Where we BUILD the Star Fighters that defend the Development Tools Operation frontier against Xur and the Ko-dan Armada"
rick@pcrat.UUCP (Rick Richardson) (08/06/88)
In article <1542@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes: > >If you don't have a 80387, or have a D step 80386, the patch doesn't >need to be applied. >-- >Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn >Intel Corporation "Where we BUILD the Star Fighters that defend the >Development Tools Operation frontier against Xur and the Ko-dan Armada" ^ Of course, you just build 'em. Us customers do the TESTING!!!!!! So, Steve, what is the procedure for us to trade in our bogus 80386's for a D step 386? Sure, maybe this one can be fixed in software, if we upgrade (at our cost!). And what kind of performance hit do we take. This is Intel's botch. Intel should fix it. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
neighorn@qiclab.UUCP (Steve Neighorn) (08/15/88)
In article <547@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes: >In article <1542@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes: >> >>If you don't have a 80387, or have a D step 80386, the patch doesn't >>need to be applied. > >So, Steve, what is the procedure for us to trade in our bogus 80386's for >a D step 386? Sure, maybe this one can be fixed in software, if we >upgrade (at our cost!). And what kind of performance hit do we take. > >This is Intel's botch. Intel should fix it. I will repeat what I said before : Release 3.1 of V/386 contains erratum 21 "Supression". I don't have any specific details on performance hits, if any, you might experience with the patch installed. On the machines I have used with the patch applied, I have not noticed any performance loss that can be directly attributable to the fix, but that is of course a subjective evaluation based only on what I am doing with the machines. Release 3.1 contains a full-house of performance improvements, including better system tuning, faster curses, client caching for RFS, an optional 2k block file system conversion, fancier sar, and a better C compiler. I have seen estimates of 30-50% application performance improvement via all the new stuff 3.1 offers. It really is faster, though I haven't experienced the 30-50% speedup myself. I am probably not using the right applications :-). As for your comments on the chip problems : I don't like it any better than you. I have two '386 machines of my own that must deal with this problem daily. I was lucky enough to avoid the multiply bug, but it was a simple case of timing, not anything else. I hear comments about the 386's problems all the time. I don't have nor will I make up any excuses. I am not a policy maker, I am an engineer. I have worked at Intel for 6 weeks now, SO DON'T FLAME ME! And making comments about .signature files? Come now! Release 3.1 seems to offer a viable path for pre-D-stop 80386 installations. It fixes the problem and adds a lot of nice features and improvements to boot. Don't ask me about upgrades either - ask Bell, Interactive, uport, or whomever you got your Unix from. I wish you luck, as I wish all of use using V/386 luck in getting all this resolved. -- Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn Intel Corporation "Where we BUILD the Star Fighters that defend the Development Tools Operation frontier against Xur and the Ko-dan Armada"