From owner-freebsd-current Wed Nov 13 07:43:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA24596 for current-outgoing; Wed, 13 Nov 1996 07:43:26 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA24563; Wed, 13 Nov 1996 07:42:38 -0800 (PST) Received: by sovcom.kiae.su id AA15233 (5.65.kiae-1 ); Wed, 13 Nov 1996 18:35:54 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 13 Nov 96 18:35:54 +0300 Received: (from ache@localhost) by nagual.ru (8.8.2/8.8.2) id SAA00239; Wed, 13 Nov 1996 18:34:26 +0300 (MSK) Message-Id: <199611131534.SAA00239@nagual.ru> Subject: Re: SCB paging is most dangerous option now! In-Reply-To: <199611122305.PAA02805@freefall.freebsd.org> from "Justin T. Gibbs" at "Nov 12, 96 03:05:48 pm" To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Wed, 13 Nov 1996 18:34:25 +0300 (MSK) Cc: current@freebsd.org, scsi@freebsd.org From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL28 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This sounds like a cache coherency bug with your motherboard. What kind > is it? OPTI895 VL/ISA-PB486P3 > 2) After I saw your bug report last night, I again attempted to reproduce > the error. I made my 2940 look as much like a 2842 as I could by making > the driver believe that it only has 4 SCBs. After about 30 minutes of > poinding my two disks with as many as 30 outstanding transactions at a > time, I gave up. I will try again tonight with my aic7850 card (3 SCBs) > as soon as I can rip the machine apart and rearange my disks. I don't even wait a minutes, I got inodes wipe on very _first_ write immediately. > If it is DMA related, it should be easy to see that by playing with your > cache settings and trying to reproduce the problem. If you are going to do > this, attempt to repro it *only in single user mode*, with your filesystems > mounted read only, by starting multiple processes acessing the disks. I > have yet to lose any disk data with this kind of testing, and this will > usually fail easily if the problem you are reporting still exists. If the > system starts to go south, note what the error messages are and hit the > reset button. Multiple dds (at least 8 to each drive) from the raw > partitions of your disks to /dev/null will work nicely. I read only mode I got the almost same result with SCB paging as without it. This bug affects _writing_only_, not reading. And I can't start 8 dds for each drive in both modes, 3 dds per drive is enough to cause "Queue Full" in both modes, but it is harmless due to read only. If I increase dds count, I got "timed out in dataout phase" for SCB mode or "timed out in message out phase" for non-SCB mode. -- Andrey A. Chernov http://www.nagual.ru/~ache/