From owner-freebsd-hackers Mon Jul 24 18:08:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id SAA29552 for hackers-outgoing; Mon, 24 Jul 1995 18:08:27 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.11/8.6.6) with SMTP id SAA29532 for ; Mon, 24 Jul 1995 18:08:22 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <01699-0@bunyip.cc.uq.oz.au>; Tue, 25 Jul 1995 11:06:59 +1000 Received: from saturn.mincom.oz.au by minbne.mincom.oz.au with SMTP id AA27471 (5.65c/IDA-1.4.4 for freebsd-hackers@freebsd.org); Tue, 25 Jul 1995 09:43:00 +1000 Received: by saturn.mincom.oz.au id AA23551 (5.65c/IDA-1.4.4 for freebsd-hackers@freebsd.org); Tue, 25 Jul 1995 09:43:13 +1000 From: Ian Holland Message-Id: <199507242343.AA23551@saturn.mincom.oz.au> Subject: Who killed the cache? To: freebsd-hackers@freebsd.org Date: Tue, 25 Jul 1995 09:43:12 +1000 (EST) Reply-To: ianh@mincom.oz.au X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1820 Sender: hackers-owner@freebsd.org Precedence: bulk I thought I'd relate an experience that I've just had that may help others, as well as illuminate the vagarities of the hardware that FreeBSD has to put up with. The system I refer to is on cheap (relatively) hardware running FreeBSD 1.1.5. A while ago, I asked the questions list for possible causes of stray interrupts (especially during gcc execution) and occasional system reboots (not panics). The concensus appeared to be bad cache chips, or even a poorly designed motherboard. So, being the optimistic type, I tried disabling the cache, and things appeared to work okay. After several months of procrastination, I decided that I'd replace the cache, but wanted to totally convince myself that it *was* the cache. So I disabled the cache and began to thrash the machine (by repeatedly recompiling a shallow source tree). After six recompilations, gcc fell over with an interrupt. This was a tad surprising, and I must admit, a bit disappointing. By this stage I was beginning to resign myself to parting with some "readies" for replacement components, when I remembered that the system appeared more stable during winter (that's now folks). So, off came the cover, out came the pedestal fan, and with a large box and a bit off counterbalancing, I had an external cooling system. Ran the tests again, and after 30 odd cycles, my confidence was growing. Out came xv and xboard, still with the compilations in the background. After 300+ recompilations I was feeling a bit cocky. The upshot being that I thrashed the machine like it ain't been thrashed before, and it just sailed on through with nary a wimper. Now, all I need to do is find a more permanent cooling system. -- Ian Holland DOS - a case study in Mincom Pty Ltd cerebral ischaemia. ianh@mincom.oz.au