Subject: FPE (Re: 68LC040 FPE, PR #5133, UVM, and a security hole?)
To: None <rbraun@cstone.net>
From: Ken Nakata <kenn@synap.ne.jp>
List: port-mac68k
Date: 05/08/1998 10:58:15
On Thu, 7 May 1998 16:06:56 -0400,
rbraun@cstone.net (Rolf Braun) wrote:
> 
> >Are you sure that you don't have a buggy LC040?  I would expect the FPE
> >errors to be consistent.  Your report makes it sound rather like you are
> >seeing almost random failures.  To recap, some LC040 revisions have a
> >hardware bug in the exception processing of F-line traps.  There is no
> >workaround that I know of.
> 
> I know, about last year I was discussing the hardware bug on the list with
> Ken and some others. The workaround in that case is -msoft-float.

I'd be surprised if it helped.  But I've heard from someone it helped
(someone in UK actually compiled the whole system with -msoft-float).
Hmm...  Why?  Because NetBSD comes with libgcc2 routines necessary for
-msoft-float, but they do use FPU instructions.  That means, even if
you compiled your whole system with -msoft-float, some FPU
instructions would still be used.

Ah...  Yes, *some* FPU instructions would still be used but FMOVEM
would not be one of them.  That can help.

Side note: I'm converting FPE to use double as the internal floating
point number representation (in order to reuse libm source), instead
of Sparc FPE internal format (112-bit significand).  But kernel won't
compile without the soft-float routines mentioned above.  And they
have to be absolutely free of FPU instruction.

> They're consistent in that they occur at relatively the same frequencies in
> the same binaries. They don't always occur in the same place.

That's puzzling me, too.  I'm starting to suspect that there may be a
problem in someplace other than FPE (a la the stack frame size bug
found and fixed by Kelly Campbell).

> If the bug was indeed fixed by Moto before Apple canned the 040, then I'd
> expect that it is fixed in the 630 series, since that was one of the last
> 040 models produced.

However, I've seen an LC630 and an LC575 equipped with XC68LC040RC
(the XC prefix denotes engineering samples)...  The last 68k Macs
equipped with the earliest LC040 chips.

Although, IIRC, XC68LC040's don't have the F-line trap bug according
to Steve Allen.  The bug was made into a later mask revision when
Motorola shrank the die size.

> >I doubt that vi and dt use the FPU/FPE at all.  That would be why
> >they're more stable than ls or ps (which do divisions, at least).
> 
> I seem to remember that printf() uses FPU somehow...

Yes, it does.  Even if you call printf() with no floating point
arguments, it does FMOVEM which seems to be causing the `random'
segfaults.  Vi and dt may have calls to printf(), but I can imagine
they don't usually make the calls; Both programs are fairly screen
oriented.

Anyway, I got a loaner LC575, thanks to Kazunori Miura and Kobunsha,
and I'm actively working to fix FPE.

Ken