Subject: Re: Time to get off the fence.....
To: None <port-sparc@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 04/22/2000 00:28:28
> I have [...] an IPX and [] an SS1.

> So, my real question is....  Will NetBSD-1.4.2 sparc [work]?

For what it may be worth...my experience indicates that there is
something damnably subtle wrong with NetBSD on the SS1+, but not the
IPX.  I haven't had an opportunity to find out whether it's an issue on
an SS1 or not, but it well could be.

The symptom is that every once in a while, usually under relatively
high CPU load (multiple processes runnable), *something* will corrupt a
small amount of storage.  I don't know exactly what is going on; I
suspect the corruption actually applies to a window of registers rather
than a memory area per se, because it produces a coredump far more
often than would otherwise make sense.  The coredumps are usually
"impossible" (as in, foo() called through "if (i > 0) foo(i);" but i is
negative - and the code was compiled -O0).

This used to fairly regularly kill either Xsun or xc on my SS1+,
thereby taking down my X session; it still does at one of my jobs,
where the box on my desk is a 1+.  Since I started using an IPX at
home, it's *never* happened there, not once.  But once, when I was
using a 1+ to display pictures, I saw one of the pictures acquire a
small horizontal glitch, some 40 or 50 pixels were trashed - hence I'm
fairly sure it's not something like a totally trashed page of RAM.

But on the other hand, a co-loc 1+ that's handling one of my netlink
tunnels has been up for two weeks, significantly longer than the MTBF
for Xsun/xc.  But it has basically zero user-land load.

I've also seen some indications that the ELC shares this problem,
whatever it is, with the 1+.  The port-sparc archives should have
something about it, though I can't recall the subject line....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B