On Sat, 15 Oct 2005, Rui Paulo wrote:

> Also, do you know if your CPUs have external cache? I think that
> information is only available from the PROM.

As I recall, the microSPARC-II does not and cannot have external cache.

Conversely, the HyperSPARC modules have ONLY external cache.  Later,
versions did have an (tiny) L1 cache , but those tend to be rare.  My
modules are the more common type.

So:  SS5-110 has internal cache but no external cache.
     SS20-2xHS150 has external cache but no internal cache.

I'll see what the PROMs say about each, but it will take some time to
get the SS20 data as it is currently busy formatting/testing disks
under Solaris 9...


In the meantime, I've rebuilt 'sh' with -mcpu=v8 -mtune=supersparc.  The
initial indications are that this did not help.  I got a segfault building
pkgtools/digest as the root dependency of an unpopulated /usr/pkg/...
Cleaning and building pkgtools/digest directly proceeded without problems.
I'm now re-re-building the first few packages again to see how it behaves.

Nope, no joy.  Building x11/rxvt elicits a Segmentation Fault from 'sh',
just like the -mcpu=v8 (only) version.  Bleah.  Word is sh built with
debugging symbols (-g) doesn't fault.  Will try that next...

Using ksh as 'sh' for pkgsrc works OK, but seems sluggish.  Using ksh as
sh to rebuild sh failed miserably.  the 'mkbuiltin' script blew up, but
didn't halt building everything else.  The resulting executable was useless.
Fortunately, I had the original sh tucked away in the DESTDIR from the
build phase, so I could use it to rebuild sh with the CPUFLAGS above.

Might this be an indication that my system, built entirely with
-mcpu=supersparc (except, now, for /bin/sh) is ultimately unstable?

-- 
John D. Baker, KN5UKS                    NetBSD     Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com                 OpenBSD            FreeBSD
BSD -- It just sits there and _works_!