From owner-freebsd-stable Tue Mar 5 10:15:27 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA12311 for stable-outgoing; Tue, 5 Mar 1996 10:15:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA12295 Tue, 5 Mar 1996 10:15:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08681; Tue, 5 Mar 1996 11:12:05 -0700 From: Terry Lambert Message-Id: <199603051812.LAA08681@phaeton.artisoft.com> Subject: Re: 2842 and the disappearing file-system :-( To: imb@scgt.oz.au (michael butler) Date: Tue, 5 Mar 1996 11:12:04 -0700 (MST) Cc: stable@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@FreeBSD.org Precedence: bulk > Without warning today, the recurrent collapse of -stable with "panic: > inconsistent xxx queue" managed to trash my root file-system beyond recovery > (/etc et al) and a substantial proportion of anything vaguely near a > file-subsystem root directory (i.e. /var, /usr and /home are all separate > file-systems and all were damaged to varying degrees). I presume that this > was just particularly bad timing as there was significant activity on all of > them at that moment (of the order of ~60 transfers second). Change: static int doasyncfree = 1; To: static int doasyncfree = 1; In /sys/ufs/ffs/ffs_alloc.c. This will resove the massive crash problem at some expense in synchronicity (the write clustering code pretty much sucks). > This particular failure, as I mentioned before on the -stable list, is > specific to the VESA controller (2842 rev C). It has never occurred with the > BT542B and I've established that the "cheap" version (i.e. non-enhanced) of > the Amd486DX4 that I'm using is only capable of running its internal cache > in write-thru mode. > > My question is this .. since -stable is presently unusable unless I want to > strangle my disk I/O (with news arriving at ~3 articles/second) and -release > too buggy for "heavy-duty" use, is -current likely to be any better ? Obviously your cache is not being updated correctly as a result of a DMA completion. Unfortunately, there is no way to compensate for bad motherboard wiring of cache notification pins other than to turn off the cache. All pentium motherboards with Saturn I (mask date prior to April 1994) chip sets can't maintain cache coherency on PCI -- ever wonder why the 60MHz Gateway systems were so cheap? Most VESA systems are worse, since they do not label information. Are you sure that the VESA controller is in a master slot? If it isn't, the VESA standard makes no guarantees regarding maintenance of cache coherency. Note that not all VESA motherboards even *have* master slots. For any given VESA system, it is most likely that the connector closest to the edge of the board is the master slot, if there is a master slot at all (VESA masters operate by stealing DRAM refresh cycles to achieve their high speed; you may need to adjust the bus on time down in the card setup, even if you correctly get it in a master slot -- Adaptec controllers are known to have aggressive bus-on times). In any case, it is a hardware problem related to bus mastering DMA and VESA, not a BSD problem. You may want to run an "advanced CMOS setup" or whatever passes for it in your BIOS, to ensure that you have a master slot and that mastering is enabled. You will *probably* need to run the Adaptec "bus-on time" setup, as described above. Alternately, jumper more wait states or go for 60 vs. 70ns RAM, etc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.