> I'm using -current everything, from a "make build" a few days ago.  I'll 
> double-check ld.so, though I'm sure it would've been installed as part of 
> the make install.  This is a SPARCstation 20 Model 71 (75MHz 
> SuperSPARC-II) if it makes any difference.  After looking at the core 
> dumps, I don't think any useful information could be obtained from them 
> since they occur in random places, and only occasionally.  Looks like any 
> program has the potential to crash under sun4m.

Those are the symptoms of a kernel bug that would make the system loose
track of the state of physical pages (referenced/modified bits) that
I've been seeing. In my case (Sparcstation Classic) this happened normally
only under heavy load. If you have a chance, try the little bugger below.
I'd be interested toknow how a SS20 behaves if you start a couple of
`./b.out &' ..

I've checked in a couple of fixes for pmap.c over the few last days.
You'll see these appearing (in sup/tar) when I've had a chance to
pull them down to the release branch (which will not happen until
after the weekend, I'm afraid).

On a Classic, I also used to see an occasional "trap 0x29" (causing a
SIGILL to be delivered to the process). This might be related to the
aforementioned bugs - i've not seen them for a couple of days now -
but a demonstrable cause escapes me so far..

-pk

---- bugger ----
> a.c cat << _EOF
main() { return 0; }
_EOF
> b.c cat << _EOF
main(){
        int n;
        int status;

        while(1) {
                n = fork();
                if (n == 0) {
                        execl("./a.out", "a.out", 0);
                        err(1, "execl");
                } else if (n == -1) {
                        err(1, "fork");
                }
                wait(&status);
        }
        return 0;
}
_EOF
cc a.c
cc -o b.out b.c