Subject: 486-netbsd-current build grinds to halt
To: None <current-users@NetBSD.ORG>
From: None <>
List: current-users
Date: 08/04/1997 11:56:12

Lately, when trying to build netbsd-current on a i486 this machine
comes to a grinding halt now and then. The load seems to go sky-up
(I'm not sure how high, xload indicates a load of 3 or 4 before it
freezes competely, while systat last update generally shows the
system-cpu utilization is 99.8% or so), and interactivity goes down to
zero in a couple of minutes. Eventually all I can do (within my
lifespan) is to power-cycle/reset this machine. It's a bit strange,
but I managed to complete a make build without the above problem, only
when running a single (remote) login shell. 

The machine is used as a gateway (without a display), and I start the
build process remotely from my NetBSD-Alpha machine (running a rather
recent -current). The Alpha is NFS-server on an ethernet from which
the 486 mounts /usr/src and /usr/obj. I've seen the same behaviour on
another 486, so I'm pretty much sure it's not the hardware. When the
486 freezes, I can still ping it from the Alpha but starting a process
remotely on (or logging in at a serial-line attached terminal) the 486
takes time seemingly approaching infinity ( == my patience >= a couple
of minutes). Also when it is frozen it does not seem to produce
(much??) traffi on the Ether. I haven't seen this behaviour at other
times than when trying to build current, although it might be that
that's because it's the only time this machine is actually really busy
for some time...

I wonder whether one of you could give me some advice on how to close
in on this problem. The `freezing' is irregular in time and space, I
never know when it will start freezing (mostly when building libc
though). After noticing a drop in interactivity , I sometimes have
time to kill the make build and everything seems to go back to
normal. Unfortunately, I don't have a lot of time after the `freezing'
starts to find out what's actually going on or gather some info at
all. I've got the suspicion it's NFS is responsible for it, but I'm
pretty clueless on how to find out.


{ Feico Dillema,                                                        }
{ University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands }
{ Install NetBSD as first step in your MS-ware 12-step recovery program }