fredb@cheops.OZ (Richard Bassett) (04/12/88)
Hardware: 80386 16Mhz (NEC Powermate-386)
80287-8 8MHz 16-bit coprocessor
O/S: Xenix-386 v2.2.1 or v2.46 (vpix update)
Problem: occasionally (order once per 10 seconds) the FPU
gives garbage output.
When: arises when more than one process is using the
287, eg 1 process writes floating-point numbers in
ASCII to a pipe, another process reads them & converts
them to binary.
Does not seem to arise when only 1 process is doing heavy
floating-point work.
Random digits in the data are garbage, eg 'U'.
Some calculated results are wrong, eg zero or 999.99*.
When the job is repeated, corruption will occur in a
different place.
Same software runs fine (but 5 times slower - what are
all the claims about a 386 in software being as fast as a
287?) if the FPU is removed. It's also unlikely that bugs
in printf() could cause the corrupted digits.
Note: Xenix-386 claims to support a 386-287 combination.
The 8MHz 287 was purchased from NEC.
I tried a second 287 - same result.
Question: Has anybody else had this problem? What can I do about it?
* Is it a hardware timing problem? -> Does Xenix behave OK
on other 386-287 harware? -> Would a 10MHz 287 fix it?
* Is it a software problem? Is Xenix not saving sufficient
FPU status data when it task-switches?
Thanks in advance,
--
R J Bassett, Dept of Textile Tech, Uni of NSW,
PO Box 1, Kensington, NSW 2033, AUSTRALIA : Ph. +61 2 697 4454
--
ACSnet: fredb@cheops.oz
ARPA: fredb@cheops.oz.au
UUCP: {uunet,mcvax}!cheops.oz!fredbdavidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/15/88)
I run a 386 287 combo without problems. My 287 is a 10MHz version. It
sounds to me as if Xenix isn't saving the 287 state. WHen you boot does
it say something about "287 installed?" Other than that no ideas. When I
doubt try a faster chip.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mechip@vector.UUCP (Chip Rosenthal) (04/16/88)
In article <10432@steinmetz.ge.com> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: > > I run a 386 287 combo without problems. My 287 is a 10MHz version. It >sounds to me as if Xenix isn't saving the 287 state. WHen you boot does >it say something about "287 installed?" Other than that no ideas. When I >doubt try a faster chip. I read the following rumors in a recent Computerworld: there is a co-processor bug in the '386 which Intel is working to fix, and as a result SCO is desupporting the math processor. I'm not sure if this is true or not. I'd hate to be the one to spread such inciteful gossip if it isn't; does anybody from SCO want to clarify?... -- Chip Rosenthal chip@vector.UUCP | But if you want to sing the Dallas Semiconductor (214) 450-0400 | blues, then boy you better {uunet!warble,sun!texsun!rpp386}!vector!chip | learn how to lose.
james@bigtex.uucp (James Van Artsdalen) (04/18/88)
IN article <256@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) wrote: > I read the following rumors in a recent Computerworld: there is a > co-processor bug in the '386 which Intel is working to fix, and as a > result SCO is desupporting the math processor. I'm not sure if this > is true or not. I'd hate to be the one to spread such inciteful gossip > if it isn't; does anybody from SCO want to clarify?... The Intel "fix" to the 287 consists of dropping support for the 386/287 altogether. I suspect this is more to "fix" sales of the 387 than for any technical issues... I understand Intel is switching over to the new 386 part in only a couple of months. All of the 386 system manufacturers who still use the 287 are going to have to dump their motherboards. May be some good fire sales out there. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
fredb@cheops.EECS.UNSW.OZ (Richard Bassett) (04/24/88)
/***
Attn davidsen@kbsvax.steinmetz.ge.com (and others):
Ye who do not believe .....
TRY THIS (assuming no other floating pt activity):
cc this_stuff
a.out & # run 1 in background
sleep a_while # enjoy the silence
a.out # make it 2 (or more)
# Now await fun error messages
# Also check what happens during hard disc activity
# Remove the 287 and try again
OUR HARDWARE:
NEC Powermate-386 16MHz 386, 4Mb memory
80287-10 <--- was 80287-8 before
O/S:
Xenix-386 SysV rel 2.2.1
------------ cut here ------------------ ***/
double
dabs( x )
double x;
{
return ( x >= 0.0 ? x : -x );
}
main()
{
int stat;
long pid;
long i;
double x, y;
double inc, inc_on1000;
char buf[ 256 ];
pid = getpid();
inc = 0.0001;
inc_on1000 = inc / 1000.0;
/* infinite loop: */
/* increment integer, avoids roundoff if repeating f.p addition */
/* let i overflow (if you wait that long) */
for (x = y = 0.0, i = 0L; ; ++i )
{
stat = 1;
x = i * inc;
/* convert x to ASCII and back again: */
sprintf(buf,"%22.14e", x);
if ( sscanf(buf,"%lf", &y) != 1)
{
printf("sscanf != 1");
stat = 0;
}
/* test if approx same: */
if ( dabs( y - x ) > inc_on1000)
{
printf("Conversion");
stat = 0;
}
if (!stat)
{
printf(" ERROR in pid %ld:\n", pid);
printf("buf \"%s\",x=%22.14e,y=%22.14e\n", buf, x, y);
}
}
}
/***
R J Bassett, Dept of Textile Tech, Uni of NSW,
PO Box 1, Kensington, NSW 2033, AUSTRALIA : Ph. +61 2 697 4454
--
ACSnet: fredb@cheops.unsw.oz
ARPA: fredb@cheops.unsw.oz.au
UUCP: {uunet,mcvax}!cheops.unsw.oz!fredb
***/