Date: Tue, 17 Jul 2001 17:00:07 -0700 (PDT) From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Message-ID: <200107180000.f6I007x12428@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/29045; it has been noted by GNATS. From: Ian Dowse <iedowse@maths.tcd.ie> To: Bill Moran <wmoran@iowna.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107180000.f6I007x12428>