From owner-freebsd-bugs Tue Jul 17 17: 0:10 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DB94E37B403 for ; Tue, 17 Jul 2001 17:00:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f6I007x12428; Tue, 17 Jul 2001 17:00:07 -0700 (PDT) (envelope-from gnats) Date: Tue, 17 Jul 2001 17:00:07 -0700 (PDT) Message-Id: <200107180000.f6I007x12428@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ian Dowse Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Reply-To: Ian Dowse Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR i386/29045; it has been noted by GNATS. From: Ian Dowse To: Bill Moran Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Date: Wed, 18 Jul 2001 00:53:35 +0100 In message <3B54C17D.F31029C2@iowna.com>, Bill Moran writes: >Errr ... I tried, but frame 2 considers those symbols undefined. >Did I misunderstand? Whoops, no I did. It was frame 3 that should contain these symbols, but now that you have an easier way to get corruption, that vmcore is of less interest. >I ran two tests during the "make buildworld" (one right after the other) >I ran a diff on the two resultant files and Lo and Behold! there are a >slew of differences in the hashes. Ok, that's progress anyway, even if it's not progress in the most desirable direction... I think you can pretty much rule out any filesystem bugs here; either the hardware is bad (disk, ATA controllers, RAM etc) or possibly there is something the ATA driver isn't doing right, such as missing a workaround for a known hardware bug. One thing that would be very useful is if you can collect a number of samples of "good" and "corrupted" versions of the same file. That may be tricky to do, because right now we don't know anything about where the data is being corrupted. Maybe try to make 2 copies of lots of files to another system, and then md5 each and look for differences. When you find two differing versions of the same file, say "file.good" and "file.bad", get a hex dump of the differences: hd file.good > file.good.hd hd file.bad > file.bad.hd diff -u file.good.hd file.bad.hd Do this for a few files and look for patterns; there might be something that would suggest where the corruption is happening. It would also be well worth trying swapping hardware components to see if you can isolate the cause. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message