Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!omepd!intelisc!joel
From: joel@intelisc.UUCP (Joel Clark)
Newsgroups: comp.unix.microport
Subject: Re: MicroPort Unix V/AT (Clone disk and other problems)
Message-ID: <239@intelisc.UUCP>
Date: 4 Mar 88 16:38:06 GMT
References: <2495@ihuxv.ATT.COM> <481@spectrix.UUCP>
Reply-To: joel@intelisc.UUCP (Joel Clark)
Organization: Intel Scientific Computer, Beaverton, OR
Lines: 29
Keywords: Help with 286 DosMerge

In article <481@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes:
>Another gotcha: On 386 systems there is an "Intel-approved method" for 
>discovering whether you have a floating point chip (287 or 387) which 
>requires some cooperation from the BIOS.  Some BIOSes do not do this
>properly and falsely claim that a 287/387 exists.  When the UNIX is booting
>and trying to figure out whether you have a FPU, and the BIOS lies and tells
>UNIX one is there, the system will crash on the first FPU instruction because
>the kernel hasn't configured itself for FPU emulation.  
>
>The crash's diagnostics are a little hard to interpret, so if you think
>you might be having this problem, borrow a FPU and try again.  If this
>fixes it, sqawk at your UNIX and/or BIOS vendor.
>-- 
>Chris Lewis, Spectrix Microsystems Inc,
>UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis
>Phone: (416)-474-1955

We had this problem for a while.  The following command always reproduced it:
`awk '{print}' nonexist_file`

The problem only occured after a soft reset of the system.  After a power
cycle the problem did not occur.  The Bios was not resetting the 387 thus
the ERROR pin was not set and the 386 decided there was a 287 instead of
a 387 present.  The system would hang.  Phoenix Tech. Ltd's BIOS v1.00
fixed this for us.

Joel Clark
Intel Scientific Computers		joel@intelisc.UUCP
15201 S.W. Greenbrier Pkwy.		{tektronix}!ogcvax!intelisc!joel
Beaverton, Or 97006 			(503) 629-7732