cpcahil@virtech.uucp (Conor P. Cahill) (01/29/91)
In article <1991Jan29.005023.4628@gtisqr.uucp> rick@gtisqr.uucp (Hendrik Groeneveld) writes: >I recently installed a 387 to see if it would improve performance >with X11. After running a few tests, I removed the 387 (We bought >it for a dos machine), and now floating point no longer works. >All jumpers are in the correct position for running without the >387, and setup shows the 387 not installed. I am running ISC v2.2. This is a problem know to exist for some hardware/bios combinations. Attached is a copy of an old article posted by Rick Richardson which contains a program that will fix the problem. > Article 4661 of comp.unix.i386: > Path: virtech!uunet!pcrat!rick > From: rick@pcrat.uucp (Rick Richardson) > Newsgroups: comp.unix.i386 > Subject: Re: awk divides by zero 386/ix 2.0.2 > Keywords: FPU error Phoenix BIOS Micronics motherboard > Message-ID: <1990May18.123911.1073@pcrat.uucp> > Date: 18 May 90 12:39:11 GMT > References: <1460@ssbn.WLK.COM> > Reply-To: rick@pcrat.UUCP (Rick Richardson) > Organization: PC Research, Inc., Tinton Falls, NJ > Lines: 249 In article <1460@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >Yesterday I changed out the old 16MHz for a new 33MHz caching model. >The old awk divide by zero was back, so I called Micronics. They >gave me a short section of code (below) to run in DOS to fix it once >and for all. Yecch! Boot DOS? Not when you can do it from UNIX. The following shar will show you how to manipulate CMOS RAM (what a poor name) from UNIX. Of course, you'll still need to reboot after you make any changes. #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh <file", e.g.. If this archive is complete, you # will see the following message at the end: # "End of shell archive." # Contents: README README.lef makefile cram287fix.c fptype.c # Wrapped by rick@pcroe on Fri May 18 08:17:15 1990 PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f 'README' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'README'\" else echo shar: Extracting \"'README'\" \(1294 characters\) sed "s/^X//" >'README' <<'END_OF_FILE' X X Lawrence Freil sent me the original version of these programs, X to diagnose and fix CMOS RAM so that 386/ix will correctly determine X the floating point co-processor type when an 80287 is installed. X X His original instructions (in README.lef) indicated that you should X let the BIOS SETUP routine recompute the checksum. I found that X my BIOS (AMI) would restore the CMOS location 0x14 value to 0x43 X (cram287fix tries to set it to 0x41). X X Checking my genuine IBM AT tech. ref, I found that bit 0x02 is the X co-processor present bit. Indeed, I do have a coprocessor present, X albeit an 80287. I guess that doesn't count with 386/ix, because X when the bit is turned off, all of my floating point problems go X away. Pic arrowheads now work; the X xclock hands are the correct X size, the X basicwin program works, etc. etc. etc. X X Anyhow, since my BIOS SETUP routines wouldn't let me turn off the X coprocessor present bit, I hacked Lawrence's program to recompute X the checksum. I also made it just turn off the 0x02 bit, instead X of writing the entire location with what might not be entirely X correct. So all you need to do is run "cram287fix" and then X reboot. Then run "fptype" to be sure that the coprocessor type X is correct. X X Oh yeah, I added a makefile, too. X X Rick Richardson X END_OF_FILE if test 1294 -ne `wc -c <'README'`; then echo shar: \"'README'\" unpacked with wrong size! fi # end of 'README' fi if test -f 'README.lef' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'README.lef'\" else echo shar: Extracting \"'README.lef'\" \(1389 characters\) sed "s/^X//" >'README.lef' <<'END_OF_FILE' X X Date: Tue, 10 Oct 89 09:52:49 EDT X From: uunet!cs.utexas.edu!gatech!dogwood.atl.ga.us!lef (Lawrence Freil) X Subject: Problem with Interactive/ix 287 under X-windows. X X I had what sounds like same problem with a couple of our 386 systems X (With 287). We also had several systems from the same vendor all X configured alike which worked fine. I eventually tracked the problem X down to a bit in CMOS. Byte 0x14 of cmos should be a 0x43 for a 80387 X and a 0x41 for 80287. Nobody sets these bits so it is just random X chance if any 287 will work correctly or not. The following program X will check with the operating system to determine the co-processor X type. If you have this problem then it will say you have a 387 X instead of a 287. The reason for the bad clock hands is that a 387 X has hardware Cosine and Sine and the library routines try to use the X instructions if it thinks you have one. All Sines and Cosines will X return the input value without an error if this is your problem. X The second program will attempt to patch the cmos to the correct X co-processor type (if you run it as super-user). You will need to X bring you system down and re-run you manufacture setup program to X re-calculate the checksum after using the cramfix because I don't feel X like looking up the checksum algorithm for a one-time patch. When you X reboot unix everything should work correctly. X END_OF_FILE if test 1389 -ne `wc -c <'README.lef'`; then echo shar: \"'README.lef'\" unpacked with wrong size! fi # end of 'README.lef' fi if test -f 'makefile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'makefile'\" else echo shar: Extracting \"'makefile'\" \(173 characters\) sed "s/^X//" >'makefile' <<'END_OF_FILE' XPROGS= fptype cram287fix X Xall: $(PROGS) X Xinstall: all X cp $(PROGS) /etc X Xclean: X -rm -f *.o X Xclobber: clean X -rm -f $(PROGS) X Xshar: X shar README* makefile *.c > 287fix.shar END_OF_FILE if test 173 -ne `wc -c <'makefile'`; then echo shar: \"'makefile'\" unpacked with wrong size! fi # end of 'makefile' fi if test -f 'cram287fix.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'cram287fix.c'\" else echo shar: Extracting \"'cram287fix.c'\" \(1483 characters\) sed "s/^X//" >'cram287fix.c' <<'END_OF_FILE' X/* X * cram287fix.c X * : patch cmos memory on a 386/AT clone under Interactive 386/ix X * : This program patches byte 0x14 to 0x41 to indicate that X * : the math co-processor is an 80287. X * : For an 80387 the value should be 0x43. X */ X X#include <stdio.h> X#include <sys/cram.h> X#include <fcntl.h> X#include <errno.h> X Xmain() X{ X struct { X unsigned char adrs; X unsigned char value; X } X cram_arg; X register int cmosfile; X unsigned short cksum; X unsigned char loc14; X int i; X X cmosfile = open("/dev/cram", O_RDWR); X if (cmosfile < 0) { X fprintf(stderr, "Can't open /dev/cram driver, errno = %d\n", X errno); X exit(1); X } X cram_arg.adrs = 0x14; X ioctl(cmosfile, CMOSREAD, &cram_arg); X loc14 = cram_arg.value; X if ( (loc14 & 2) == 0) X { X printf("Co-processor bit already is off\n"); X printf("386/ix should already think an 80287 is present\n"); X exit(0); X } X else X { X printf("Co-processor bit is on!\n"); X printf("386/ix thinks there is an 80387 is present.\n"); X printf("I'll now turn the bit off for 80287.\n"); X } X X cram_arg.adrs = 0x14; X cram_arg.value = loc14 & ~2; X ioctl(cmosfile, CMOSWRITE, &cram_arg); X X /* X * Recompute checksum X */ X for (cksum = 0, i = 0x10; i <= 0x20; ++i) X { X cram_arg.adrs = i; X ioctl(cmosfile, CMOSREAD, &cram_arg); X cksum += cram_arg.value; X } X cram_arg.adrs = 0x2e; X cram_arg.value = cksum>>8; X ioctl(cmosfile, CMOSWRITE, &cram_arg); X cram_arg.adrs = 0x2f; X cram_arg.value = cksum; X ioctl(cmosfile, CMOSWRITE, &cram_arg); X exit(0); X} END_OF_FILE if test 1483 -ne `wc -c <'cram287fix.c'`; then echo shar: \"'cram287fix.c'\" unpacked with wrong size! fi # end of 'cram287fix.c' fi if test -f 'fptype.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'fptype.c'\" else echo shar: Extracting \"'fptype.c'\" \(514 characters\) sed "s/^X//" >'fptype.c' <<'END_OF_FILE' X#include <stdio.h> X#include <sys/types.h> X#include <sys/sysi86.h> X#include <sys/fp.h> X Xmain() X{ X int i; X X sysi86(SI86FPHW, &i); X X switch (i) { X case FP_NO: X printf("No floating point supported at all\n"); X break; X case FP_SW: X printf("Floating point emulation in software\n"); X break; X case FP_287: X printf("Floating point done by 80287\n"); X break; X case FP_387: X printf("Floating point done by 80387\n"); X break; X default: X printf("ERROR! Floating point value none of thoses listed\n"); X break; X } X} END_OF_FILE if test 514 -ne `wc -c <'fptype.c'`; then echo shar: \"'fptype.c'\" unpacked with wrong size! fi # end of 'fptype.c' fi echo shar: End of shell archive. exit 0 -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bill@unixland.uucp (Bill Heiser) (01/30/91)
In article <1991Jan29.005023.4628@gtisqr.uucp> rick@gtisqr.uucp (Hendrik Groeneveld) writes: >I recently installed a 387 to see if it would improve performance >with X11. After running a few tests, I removed the 387 (We bought Does this imply that the 386 did NOT improve performance with X11? -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp Public Access Unix - Esix SYSVR3 508-655-3848(12/24) 508-651-8723(12/24/96-HST) 508-651-8733(12/24/96-PEP-V32) other: heiser@world.std.com