[rescue] Sparcstation 20 - Dude, we're getting the band back together!
xc68000 at gmail.com
Sat Sep 5 21:36:24 CDT 2009
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
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
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
> /~\ 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
More information about the rescue