Re: SuperSPARCvs HyperSPARC and SS20 stability

Hi Martin,

I think I have two different issues.

1) SS20 + HyperSparc + NetBSD 10: that caused system freezes, unusable 
system
2) SS20 + SuperSparc + NetBSD 10: "hangs of processes"

in addition, I noticed that I never experienced 1) in the past and it is 
not reproduceable using the same processors on the SS10 with NetBSD 9.4, 
neither did I experience 2) on 9.x using HyperSparcs.

Martin Husemann wrote:

> It causes userland processes (using pthreads) to do basically busy loops in
> some mutex operation and never make any process. Once you are in this
> state, the process never recovers. I think I could always (manually)
> kill them, but right now I am not 100% sure of that.

What do you mean by "busy loop" ? would you see 100% usage on the stuck 
process (or more processes?).

In my case the processes seem to be parked, waiting or otherwise 
stalled, I start building a package and after a while CPU drops to 0%.

Depending on the process it might or might not be Ctrl-C or SIGTERM, but 
it always ends with kill -9! so the system always recovers nicely there

> I have never seen them hang the whole machine (i.e. ddb on the console
> still works).

The process hang I speak about does not hang. Only the Combination 
SS20-HyperSparc-NetBSD10 did really crash.
So my guess that is another problem.. Either a strange CPU/ROM/BusSpeed 
issue where the SS10 and SS20 differ

>
> My reliable way to trigger this issue is: unpack a sparc userland from the
> autobuilds on any sparc64 SMP machine, chroot to it and run the ATF test
> suite. It will reliably stop making progress quickly when enough RUMP servers

Is there a simpler way I could try to run on a small space, limited 
machine like mines? can I get the ATF test suite somehow "alone"? as a 
port maybe?


Riccardo