*BSD News Article 16284


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!not-for-mail
From: burgess@hrd769.brooks.af.mil (Dave Burgess)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: wd stops on update
Date: 19 May 1993 08:53:51 -0500
Organization: Armstrong Lab MIS, Brooks AFB TX
Lines: 59
Message-ID: <1tde5tINN6i@hrd769.brooks.af.mil>
References: <1tafgi$5s7@zaphod.axion.bt.co.uk> <cproto.737791950@marsh>
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <cproto.737791950@marsh> cproto@cs.curtin.edu.au (Computer Protocol) writes:
>lessen@axion.bt.co.uk (Lee Essen) writes:
>
>>This is a bit of a strange problem!  At completely random times, luckily with
>>a large MTBF, my wd light comes on and stays on and no more disk access is
>>permitted, the processes just block!
>
>>It appears that the problem occurs when 'update' sync's the drive, when I
>>reboot the filesystems are always clean (thank god!)
>
>I have the same problem. It seems related to a high rate of context
>switches e.g. running a large make in one xterm and doing some work
>in another xterm often causes the system to lock up as you describe
>it. I.e. processes not using the harddrive work fine (ping, X11, etc)
>but anything going near the disk just locks up.
>
>Regards - Tibor Sashegyi (cproto@cs.curtin.edu.au)
>
>BTW I use 386bsd-0.1 with selected patches applied.
>


I am using NetBSD 0.8 and I have been having precisely the same problem.  It
started when I loaded 'X' recently.  Perhaps it was a coindence, but I didn't
notice it until I installed 'X'.  It has been happening to me when I am
reading news in trn.  It also happens when /etc/daily tries to rebuild the 
whatis database.  When I first noticed that my /etc/daily job was running
about halfway through (past calendar, but never past whatis.db) I tried it,
logged in as root, by hand.  It dies with the hard drive light lit, just as
described.

This means that every morning, I have to check and see what broke during the
night.

I have been running 386bsd since last fall, and NetBSD for the past month,
and this is really starting to bug me.

NetBSD, as I understand, is already using the barsoom drivers, so that can't
help much.  

Could this have something to do with 'maxfdescs' from the config file?  I
first noticed it when the system was compiled using the default of 2048.
I tried rebuilding a kernel using 512, and it is no different.

The particulars of the machine:

  486/33 EISA with 32M of memory (which NetBSD correctly identifies as usable).
  NetBSD 0.8, recompiled from provided source, WITHOUT any patches whatsoever.
  An Ultrastore 24F card running in ISA emulation mode (as it has from the
	start)
  A WD8003E Ethernet card.

It does seem to happen more often if I am running with NFS (rsize=wsize=1024)
and I suspect that is a part of the problem.
-- 
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX