[rescue] Sparcstation 20 - Dude, we're getting the band back together!

[Sanford Barton]

Guys thank you for the help.  I posted this to sunhelp a couple of
weeks ago and have been diligently working ever since.  This is the
current status:

I wanted to see if the issue persisted with Solaris 8, so I loaded a
fresh Solaris 8 2/02 + latest recommended. I had a hell of a time
getting the X11 install stable. There is a MAJOR XSun memory leak with
Solaris 8 on a SS20 using the CG14/SX graphics. Basically even with
all the available/latest XSun/kernel patches, the XSun process will
nibble your ram by about 2-3mb every few seconds until it starts
swapping, and then it's only a matter of time before your hosed. The
solution turned out to be using the
/usr/openwin/server/module/ddxSUNWcg14.so.1 from my Solaris 9 install
CD. That fixed the memoy leak.

So, everthing stable now using both SM81s on Solaris 8. Running all
the programs I want - Thunderbird, SeaMonkey(make sure you turn off
java/javascript), XChat, XMMS streaming a 56k mp3 stream, a few xterms
for a few hours now and no problems at all.

Amazed I can run all that and still be 85% idle on 2 85mhz processors
and STILL have 245M out of 448M free physical RAM.

So unless something else pops up, looks like mystery solved. Maybe one
day I can try Solaris 9 again, but I don't think I will unless I can
find a later HW release than the one I have.


On Sat, Sep 5, 2009 at 8:04 PM, der Mouse <mouse at rodents-montreal.org> wrote:
>>> Sparcstation 20.
>
>> Maybe try to track down a later HW rev of your graphics card?
>
> The message said cg14, so this isn't really very possible.  There is no
> graphics card as such; much of the cg14 is on the motherboard - and
> what isn't is physically conflated with the VSIMM and I would guess
> doesn't have all that many revs.  (Of course, I could well be wrong,
> especially about the "I would guess...".)
>
> My guess would be 2 (bad processors) or 4 (software issues, eg with
> cache).  I've had cache issues with the SS20 myself; I have pseudo-disk
> drivers for NetBSD that simply don't work on the 20 unless I add code
> to "manually" force everything out of the cache at critical points.
> Yes, this indicates bugs somewhere - but the same code "works fine" on
> other sparc32s, so it indicates that the SS20 is relatively demanding
> in regard of caches and such.  And as for the Ross difference, I've
> seen it said that the Ross processors have tiny caches but more muscle;
> if true, perhaps the same underlying problem exists but everything is
> being pushed out of the cache before the trouble has a chance to
> manifest?
>
> /~\ The ASCII                             Mouse
> \ / Ribbon Campaign
>  X  Against HTML                mouse at rodents-montreal.org
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue