Hanging 5.0_BETA

[Johnny Billquist <bqt%softjar.se@localhost>]

I don't know if this is relevant and related or not, but I think it 
might be something that could help to know anyway.
Bear with me if this becomes a bit winded, and feel free to ask for any 
clarifications.

My setup is like this:

One PC running NetBSD acts as NFS and YP server (along with a lot of 
other services). On my network I then have one VAX and one Alpha that 
are configured more or less the same way.
That is: local disk that it boots from. /usr/src is exported from the 
PC. User accounts are in NIS.

When I build 5.0, I start by doing a cvs update on the PC, to have the 
latest sources. I then log into the build machine (VAX or Alpha) via 
ssh. I start build.sh in /usr/src, and redirect the output to a log 
file. In the same window (on the same machine) I then do a tail -f logfile.

I also start a second ssh session to the same machine. In this second 
window, I run a "systat vmstat" which I use to monitor the activity on 
the machine while the build is running.

So, it is more or less:

ssh session 1:

sudo tcsh
cd /usr/src
./build.sh -u build kernel=Junk >& u.log &
tail -f u.log


ssh session 2:
systat vmstat


On the VAX, this has worked fine in the past. On the Alpha this works 
fine with 5.0 as well.
However, on the VAX, I can observe a few very peculiar things. systat 
normally do a screen update every five seconds. On the VAX, when 
build.sh is running, I have observed as much as a minute and a half 
between screen updates. It seems related to how busy the machine is with 
the current command. When make comes to libc, it takes about a minute 
and a half to suck in and process all the dependencies, and nothing 
happens in systat during this.
Another thing is that the interrupt counters are weird. I can run a ping 
towards the VAX during this, and response times are fine the whole time. 
However, the interrupt counters in systat don't report any interrupts. 
They probably do show up later, but there is some kind of delay going on 
here. I have no idea exactly how this all works out, but I find it strange.

It's like process preemption isn't working right. But it also feels like 
there is something else wrong here as well.

Anyway, this might give you something more to ponder.

Also, perhaps someone else can try to see if they can repeat this 
observed behaviour?

        Johnny