coprocessors for linux - seen on the net

[David G. Hough on validgh]

Article 709 (3 more) in comp.sys.ibm.pc.hardware:
From: hanwenablade.stack.urc.tue.nl (Han-Wen Nienhuys)
Newsgroups: comp.os.linux.help,comp.sys.ibm.pc.hardware
(SAME) Subject: Re: AMD 386DX-40 Board locks under Linux
Date: 21 Oct 93 10:46:10 GMT
Organization: MCGV Stack, Eindhoven University of Technology, the Netherlands.

In article <1993Oct20.081829.12493amonu6.cc.monash.edu.au>,
S. Oxley <rda986namdw030.cc.monash.edu.au> wrote:
>I recently upgraded my system from a 386SX-20 to an AMD 386DX-40. After
>I upgraded, I found that Linux would die violently, with no error
>messages - a total hardware lockup.
>loads (eg POV-RAY 2.0 using 4.5Mbytes, or X-Free86 using XV 3.00a).

Oppps... Floating point, heavy paging, combined with

>AMD 386DX-40, with ULSI 40MHz 80387 co-pro

An ULSI coprocessor. This doesn't work, buy a Cyrix or IIT coprocessor.

From: stevevamiser.uoregon.edu (Steve VanDevender)
Newsgroups: comp.os.linux
Subject: Re: ULSI 387DX40 + swap == crash ?? (was: coproc & swap ..)
Date: 13 Jul 93 06:07:23 GMT
Organization: University of Oregon Chemistry Stores

I have spoken to a person in ULSI tech support and there are two
different theories about why their parts fail under Linux:  his
and mine :-).
 
According to him, the ULSI chip does not correctly handle some
opcodes that are illegal or no-ops on the 80387.  For those of
you interested, here are the opcodes he gave me:

D9 D8-DF
DC D0-DF
DD C8-CF
DE D0-D7
DF C0-DF

He claimed that all of the problems they know of with their 387
clone come from execution of those opcodes.  Considering that
fcom st(1), st is in the set he gave me, I would think they'd
have a lot of problems.

My theory, based on some trace information given to me by
Christian Linhart that I was able to duplicate, is that the ULSI
chip does not properly handle some double-fault conditions,
particularly a coprocessor instruction that causes both a page
fault and a coprocessor fault (one that refers to memory in a
non-resident page and which was the first coprocessor instruction
executed after a task switch).  We found the system would halt
upon the fnsave instruction in the kernel routine
math_state_restore(), and this halt was triggered when two
processes each used the coprocessor and used enough memory to
begin to induce paging.

Since then I have obtained a Cyrix 387-40 and it works great.  I
have to second the recommendation to avoid the ULSI chips for
Linux -- although their tech support person was friendly and
helpful, their chips appear to be severely flawed.  According to
the tech support guy, they are working on an update of their part
because of the problems they've been having and this may be out
in a few months; hopefully this will resolve the compatibility
problems as well.
--
Steve VanDevender       stevevagreylady.uoregon.edu