From owner-freebsd-bugs Thu Jul 26 17:10: 9 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 DD98F37B401 for ; Thu, 26 Jul 2001 17:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f6R0A1020956; Thu, 26 Jul 2001 17:10:01 -0700 (PDT) (envelope-from gnats) Date: Thu, 26 Jul 2001 17:10:01 -0700 (PDT) Message-Id: <200107270010.f6R0A1020956@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bill Moran Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Reply-To: Bill Moran 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: Bill Moran To: Ian Dowse 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. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message