Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Hanging 5.0_BETA

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?


Home | Main Index | Thread Index | Old Index