Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!network.ucsd.edu!romulan!rdante From: rdante@sdcc13.ucsd.edu (Rick Dante) Newsgroups: comp.os.386bsd.bugs Subject: Re: This is a strange one! Date: 17 Mar 1993 05:19:00 GMT Organization: Newsreaders Anonymous Lines: 41 Distribution: world Message-ID: <1o6cc4INNjuf@network.ucsd.edu> References: <C40400.9qv@veda.is> Reply-To: rdante@sdcc13.ucsd.edu NNTP-Posting-Host: dialin1-47-1.extern.ucsd.edu In article 9qv@veda.is, root@veda.is (Tree and Root) writes: > lessen@axion.bt.co.uk (Lee Essen) writes: > > >whenever I try to use any of those binaries (disklabel, dd or cat) with > >any parameters (not even accessing the drive) the core dumped. > > >I have to rebuild them to fix the problem! > > >Weird! - Anyone got an explaination for that! > Here's one possible explanation: > > The binaries are corrupted because other random fileblocks have replaced > parts of the binary file. This is reported to be due to the FS buffer cache > being inconsistent with the FS. It usually has no lasting effects and just > causes random failures, but unfortunately files do sometimes sustain real > and permanent damage. Temporary (but highly visible) damage is widespread > had to reboot or type 'make' several times (once after each compilation > error) or the machine just hung or crashed during the compile of libc.a. > > Do any solutions exist yet, or has the offending code at least been located? > Adam David (adam@veda.is) (much text deleted) Have you tried disabling your external cache? At the suggestion of a previous article I disabled my secondary cache and I am able to do a make in /usr/src straight through with no problems (except that it's 2.5 times slower :( ). Many people seem to have solved their problems by replacing cache chips. I did this 3 times without luck so I think it might be the cache controller but I'm not sure. I now have a good excuse to replace my motherboard (and get a 486). To test out the FS buffer cache corruption theory with my external cache enabled after getting compilation errors I would go into /tmp (which I have a memory filesystem mounted on) and copy big files until I hear disk swaping (which suggests that the FS buffer cache is being shrunken to make way for files in the MFS). I then start make again and no problems (where otherwise I would have to reboot). All this does is help confirm the FS buffer cache incoherency problem but I feel this problem is caused by the external cache of some machines and that alone. Other opinions might differ however. Rick Dante