From owner-freebsd-smp  Tue Jan 28 09:15:56 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA24557
          for smp-outgoing; Tue, 28 Jan 1997 09:15:56 -0800 (PST)
Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24550
          for <smp@freebsd.org>; Tue, 28 Jan 1997 09:15:52 -0800 (PST)
Received: (from ken@localhost)
          by housing1.stucen.gatech.edu (8.8.5/8.8.5) id MAA22280;
          Tue, 28 Jan 1997 12:15:27 -0500 (EST)
From: Kenneth Merry <ken@housing1.stucen.gatech.edu>
Message-Id: <199701281715.MAA22280@housing1.stucen.gatech.edu>
Subject: Re: Current SMP status inquiry
In-Reply-To: <199701280801.JAA15200@slibo.cc.uit.no> from Terje Normann Marthinussen at "Jan 28, 97 09:01:39 am"
To: Terje.N.Marthinussen@cc.uit.no (Terje Normann Marthinussen)
Date: Tue, 28 Jan 1997 12:15:26 -0500 (EST)
Cc: smp@csn.net, smp@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terje Normann Marthinussen wrote...
> >Hi,
> >
> >> What about the evil FP exception/FPU support problem? The one that
> >> locks everything up solid? I'd be happy to write up a description and
> >> workaround, but it may be that others don't believe it exists, or that
> >> it is simply a problem with my and a few others equipment.
> >
> >it definately seems to affect some hardware more  than others.  I recently
> >ran 3 copies of ico on X11 for 3-4 houres without a burp.  There has to
> >be a fair amout of FPU use going on during that.
> >
> >This does need to be pursued, but I have no time (or even an SMP machine)
> >to give to it right now, a "real job" has arrived...
> 
> I got our 4CPU pentium HP Netserver up on current early last week, and 
> during the weekend we had it chewing through 1GB+ of gzip'ed log data.
> Two processes fed with each half of the data, they grew to around 
> 50MB each (early memory inefficient version of the program and we "only" 
> have 128MB on it so 2 was enough). 
> 
> While not FPU intensive, it most certainly must have used quite a bit of 
> FPU during the ~15 hours the processes ran (well, actually two runs 
> of ~15 hours, a bug was discovered ;)). Didn't notice any problems at all.


	I agree, I can run FP intensive stuff, like ICO, OpenGL demos, and
all kinds of stuff without problems.  I've been running X without trouble,
ever since I figured out I needed to get rid of the FP emulation stuff in 
the kernel.  (I accidentally left it in my config file.)  The question,
though, is can you run this program successfully?

========================================================================
#include <sys/types.h>
#include <signal.h>
void blech() { exit(3); }
main()
{
	int i32;
	double f;
	int result = 0;
	signal(SIGFPE, blech);

	f = (double) 0x7fffffff;
	f = 10 * f;
	i32  = (int) f;

	if (i32 != (int) f)
		result |= 1;
	exit(result);
}
========================================================================

	That program locks my machine up solid.  (I got it from the perl5
configuration script, after several attempts to compile the port hung my
machine.)


Ken
-- 
Kenneth Merry
ken@ulc199.residence.gatech.edu
Disclaimer:  I don't speak for GTRI, GT, or Elvis.