Xref: utzoo comp.unix.microport:3028 comp.unix.questions:12428
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!rutgers!att!ulysses!sfsup!jbu
From: jbu@sfsup.UUCP (+Urban J.)
Newsgroups: comp.unix.microport,comp.unix.questions
Subject: Re: C bug causes double fault
Message-ID: <5023@sfsup.UUCP>
Date: 24 Mar 89 21:17:21 GMT
References: <244@tree.UUCP> <9884@smoke.BRL.MIL> <27245@cci632.UUCP> <9900@smoke.BRL.MIL> <660@micropen> <9910@smoke.BRL.MIL>
Reply-To: jbu@/guest2/jbuUUCP (xt1123-+Urban J.)
Organization: AT&T Information Systems
Lines: 23


The AT&T PC 6300 PLUS (which was a 80286) also had a similar problem in UNIX System
V Release 2.0 Version 2.

However, all these floating point panics were fixed (on the AT&T 6300 PLUS) in UNIX
System V Release 2.0 Version 2.5.

The basic problem was in the the floating point emulation code when a floating point
exception occured.  On UNIX System V Release 2.0, the floating point emulation code
ran in kernel mode, so when exception occured, the system panic'ed.  In UNIX System
V Release 2.0 Version 2.5  on the 80286, the floating point emulation code was moved
from the kernel stack/area into user space.  Therefore when a an exception occured,
only the user process core dumped and not the kernel panic.

On UNIX System V/386 Release 3.2 (for the 80386) the software emulation code is also
in the user space so when a floating point exception occurs, only the user's process
dies and not the kernel.

On the AT&T PC 6300 PLUS running UNIX System V Release 2.0, if a 80287 chip is present
the system will not panic (nor hang).

Sincerely,
John Urban