Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!purdue!ames!olivea!uunet!psinntp!dg-rtp!ponds!rivers
From: rivers@ponds.uucp (Thomas David Rivers)
Newsgroups: comp.unix.bsd
Subject: Re: Hang up on heavy disk load (Re: Adaptec SCSI bug?)
Message-ID: <1992Aug7.113158.9036@ponds.uucp>
Date: 7 Aug 92 11:31:58 GMT
Article-I.D.: ponds.1992Aug7.113158.9036
References: <1992Aug3.195717.26165@aio.jsc.nasa.gov> <scott.712957192@pita> <15mv6cINN1o7@agate.berkeley.edu>
Lines: 78
>From dg-rtp!psinntp!rpi!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!soda.berkeley.edu!wjolitz Fri Aug 7 07:16:13 EDT 1992
Article: 3496 of comp.unix.bsd
Path: ponds!dg-rtp!psinntp!rpi!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!soda.berkeley.edu!wjolitz
From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: Re: Hang up on heavy disk load (Re: Adaptec SCSI bug?)
Message-ID: <15mv6cINN1o7@agate.berkeley.edu>
Date: 4 Aug 92 22:09:16 GMT
References: <1992Aug3.150008.188@cotton.nc.u-tokyo.ac.jp> <1992Aug3.195717.26165@aio.jsc.nasa.gov> <scott.712957192@pita>
Organization: U.C. Berkeley, CS Undergraduate Association
Lines: 21
NNTP-Posting-Host: soda.berkeley.edu
In article <15mv6cINN1o7@agate.berkeley.edu> wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
>In article <scott.712957192@pita> scott@pita.cns.ucla.edu (Scott Burris) writes:
>>...
>>Well, if this is the same problem I've been having, the kernel is deadlocking
>>sleeping on something called "temp" which appears to be a temporary
>>memory allocator. I've seen problems when I've built a new kernel
>>and immediately try copying it into the root filesystem. If I do a
>>sync first and wait for it to complete, there's no problem.
>>
>>I'm running a 486/33 Opti chipset with 16M of memory, both IDE and SCSI
>>disks.
>
>The quick fix for this problem is to insert before line 170 of machdep.c
>the following line:
>
> bufpages = min(NKMEMCLUSTERS/2, bufpages);
>
>In a nutshell, the dynamically-allocated kernel memory is becoming too
>fragmented. The correct fix for this problem is the subject of 386BSD
>Release 0.2.
>
>Bill.
>
>
Well, I hurriedly ran home to install this fix; but was bitten by a
hang up before the kernel could be rebuilt.
Unfortunately, I had changed the ROMs in the machine, and was bitten by
the bzero() problem in wd.c; init died and then my root partition was
trashed by the panic.
So, after re-loading everything...
Last night I put in simply the bzero() patch to wd.c, and this correction.
I started the following shell script (in a temporary /sys/compile/DUMMY
directory):
while true
do
date; rm -f *.o
make
done
and went to bed, hoping to find the machine merrily humming along in the
morning.
Unfortunately, when I awoke, the machine had indeed hung. There is no
message, etc... and the date I had thoughtly provided had scrolled off
the screen (so much for thoughtful provisions.)
I'm going to try with the rlist fixes from 0.0; the change about computing
the size of a free block was made; but the rlist_alloc() and rlist_free()
routines (in kern/subr_rlist.c) can still loose elements of the list.
(This was discovered by guido@gvr.win.tue.nl (Guido van Rooij)) I sent
Lynne a BUGNFIX for the problem, it is easy to get the 0.0 patches and
apply them (by hand) to kern/subr_rlist.c. Perhaps, that will help...
report later.
By the way, is 0.2 going to be a new release, or will there be a
diff against 0.1. I have to get everthing over a modem, at 2400 baud,
or bribe my wife to put it on floppies (I don't have internet access at work,
but she does.) - so a diff would be appreciated.