Date: Tue, 5 Mar 1996 11:12:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: imb@scgt.oz.au (michael butler) Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: 2842 and the disappearing file-system :-( Message-ID: <199603051812.LAA08681@phaeton.artisoft.com> In-Reply-To: <199603051338.AAA14678@asstdc.scgt.oz.au> from "michael butler" at Mar 6, 96 00:38:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603051812.LAA08681>