Date: Fri, 27 Jul 2001 10:27:28 +0200 (CEST) From: Søren Schmidt <sos@freebsd.dk> To: Bill Moran <wmoran@iowna.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Message-ID: <200107270830.f6R8U9423426@freebsd.dk> In-Reply-To: <200107270010.f6R0A1020956@freefall.freebsd.org> "from Bill Moran at Jul 26, 2001 05:10:01 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Bill Moran wrote: > The following reply was made to PR i386/29045; it has been noted by GNATS. > > From: Bill Moran <wmoran@iowna.com> > To: Ian Dowse <iedowse@maths.tcd.ie> > Cc: freebsd-gnats-submit@FreeBSD.org > Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree > Date: Thu, 26 Jul 2001 20:01:33 -0400 > > Update: > > On Saturday, July 21 I did some work on the machine that's > having this problem. > First, I attempted to establish a way to reliably crash the > machine so I could be sure if/when I fixed it. Unfortunately, > I was unable to do this. I tried using bonnie++ to cause the > crash, but it didn't cause any problems. The only thing I can > seem to get it to crash all the time is to copy and delete > ~30G of data (~50,000 files) 3 or 4 times. This almost always > crashes the system by the fourth time. > > What I did do, that will hopefully be some help in the resolution > of this PR, is remove the 80 conductor cable and install a 40 > conductor IDE cable (no other changes whatsoever). The mobo > BIOS faithfully throttled the drive to ata33. I then put the > machine back to work, but I've been running additional copy > operations on the drive whenever the system's not in use. Basically, > at this point the computer has seen drive activity in excess of 2x > what it normally takes to cause a panic and has not crashed. > > I then ran the md5 test as suggested earlier and had no problems > between the two runs. In other words, slowing the drive down to > ata33 seems to have solved the problem. > > My question now is: Is there anything more I can do to help isolate > what really caused this problem? I have a few theories currently: > > 1) ata100 simply doesn't really work > 2) either the Promise controller or the IBM HDD has a broken > ata100 implementation > 3) FreeBSD's ata driver doesn't do ata100 properly > 4) IBM is serious when they say the 80 conductor cable can't be > longer than 18" (the one I had was a few inches longer) > > If #3 is the case, I'd like to help fix the problem. > If #4 is the case, it shouldn't be too hard to avoid it in the future. > If #1 or 2 is the case, there's the possibility that the ata driver > can be modified to work around the problem. > > Regardless, it would be nice to be able to use ata100 in this and > future machines. I'm open to suggestions. You should *not* use cables that are longer than the spec'd length, it doesn't work. However you should only get ICRC errors, not data corruption. Another issue is that some IBM drives are very picky about power, if I put my DTLA's in drawers they will do occasional ICRC errors because of the somewhat lower voltage due to the power circuit in the drawer. I also have reports of DTLA's corrupting data in setups with bad power or low power as well, which is semilar to what you are seeing.. -Søren 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?200107270830.f6R8U9423426>