In article <Pine.NEB.4.53.0510142036190.14253@david.technoskunk.fur>,
John D. Baker <jdbaker@mylinuxisp.com> wrote:
>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?

Where does it segfault? What does gdb say?

christos