Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!convex!darwin.sura.net!howland.reston.ans.net!usc!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail From: burgess@hrd769.brooks.af.mil (Dave Burgess) Newsgroups: comp.os.386bsd.questions Subject: Re: Sorry, I lost the 'drive light on and locked' patch. Date: 25 Jul 1993 14:40:44 -0500 Organization: Armstrong Laboratory, Brooks AFB, TX Lines: 45 Message-ID: <22unka$7c@hrd769.brooks.af.mil> References: <22gd69$6j3@hrd769.brooks.af.mil> <22hu06$kr@moritz.in-berlin.de> <22jja0$b1@hrd769.brooks.af.mil> <22oqk1$8f@hrd769.brooks.af.mil> NNTP-Posting-Host: hrd769.brooks.af.mil In article <22oqk1$8f@hrd769.brooks.af.mil> burgess@hrd769.brooks.af.mil (Dave Burgess) writes: >All right... > >I made Theo's suggested change. > >It made the problem go away for about three days. Once my confidence >was up, I started trying to get the system back up to date. > >Something in gcc2 triggers the bug. It is getting to the point that I >can't even build a new kernel to fix this persistent problem. Oh well. >Another thing that seems to trigger the bug is writing a core.* file. >The multirecord write problem seems to be the culprit. It is certainly >a problem with timing. > >The 6 second time-out once a second still has me puzzled, and I suspect >that is ALSO part of the problem. > > I have been playing with this now for a solid week, and I have several things to report: 1) The timeout patches (one for 386bsd and one for NetBSD) will probably work if I ever get a new kernel built. 2) With the Kernel Debugging in wd.c included, it becomes a Heisenbug. 3) Once the kernel debugging code is enabled, the ONLY time the system locks up with the drive light on is during core dumps. 4) The new version of genassym is core dumping on me, but I will lick that one this afternoon (or die trying). 5) It occurred to me about 3:40 this morning (at least that is what was on the bedside pad) that I can limit coredump sizes to 0, which will inhibit core dump production, thus masking the last problem I think I am having. -- ------ TSgt Dave Burgess NCOIC AL/Management Information Systems Office Brooks AFB, TX