Subject: errors...

From: Alex deVries <[email-masked]>
Date: Thu, 7 May 1998 11:22:58 -0400 (EDT)

So, I was compiling .99 last night, and my machine hung.  I came in this
morning, and found reams of errors on the screen, all of which were:

Setting flush to zero for patch.
Unimplemented exception at 0x004057f0

This is 2.1.91 kernel I got from Ralf.  Maybe this is useless, since I'm
on my way to running .99 anyway.

- Alex

-- 
Alex deVries
"romantic engsoc guy who runs marathons" - [email-masked]
http://www.engsoc.carleton.ca/~adevries/ .

---

From: [email-masked]
Date: Thu, 7 May 1998 17:52:05 +0200

> Unimplemented exception at 0x004057f0

Still lacking the kernel math code for MIPS I implemented a cruel hack.
If we catch an unimplemented exception and flush-to-zero is cleared, we
set it and retry the instruction.  If flush-to-zero is already set, the
problem is beyond what we can deal with ...

The only mysterious thing for me is right now why patch is using floating
point.  Whatever, this error message is not directly related to the hang,
it's more telling people that fp results might be inaccurate or wrong.

Anybody with floating point experience and time to write this stuff?
What we need is basically a subset of a coprozessor emulation; there is
example code available in the NetBSD, OpenBSD and MACH MIPS assembler
code; the Sparc64 code is even written in C.

> on my way to running .99 anyway.

I'm interested to hear if .99 hangs again for you.  All I can say is
that I tested .99 by recompiling libc and that crashed ``No space left
on device'', so it must be good ;-)

  Ralf

---

From: [email-masked]
Date: Thu, 7 May 1998 19:21:45 +0200

On Thu, May 07, 1998 at 09:09:46AM -0700, David S. Miller wrote:

> Ralf did you fix GLIBC to init the FPU csr correctly?  It should be
> set to zero, and the code we had originally did not do this, it set it
> to a bunch of values which induced traps for operations where they
> shouldn't by default.  I fixed this in the Cobalt glibc tree a long
> time ago and we have no FPU emulator code in the kernel.

I've just taken a look at the sources and found that the various
architectures seem to handle this issue differently by default.
Sparc disables the exceptions, Intel enables all IEEE754 exceptions,
MIPS only division by zero and overflow and Alpha handles things a bit
different anyway ...

Seems there still is no common dominator on what should be default and
I don't think either 0x00000600 or 0x0 is clearly right or wrong.

Ok, without the kernel fp stuff zero is somewhat better, so I'm going
to use it.  From the kernel side new born processes default to $fcr31=0
already.  Whatever, this smells like making a kludge just a little bit
better ...

  Ralf