Date: Fri, 20 Jul 2001 12:13:23 -0700 From: kachun@newsguy.com (Kachun Lee) To: wmoran@iowna.com Cc: freebsd-bugs@freebsd.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Message-ID: <200107201913.MAA05538@pathlink.net> In-Reply-To: <9j44pd$2ipo$1@FreeBSD.csie.NCTU.edu.tw> References: <9j44pd$2ipo$1@FreeBSD.csie.NCTU.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <9j44pd$2ipo$1@FreeBSD.csie.NCTU.edu.tw>, you say... > >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: Wed, 18 Jul 2001 09:50:13 -0400 > > Ian Dowse wrote: > > > > 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. > > Oddly enough, the md5ing I did last night did not cause a panic. In fact, > the rsync process ran at 3:00 AM successfully. > > I was just talking to the guy we got the hardware from, and my gut instinct > is to suspect the ata100 - controller or driver. We've got another system > here that needs to go into production in a few weeks, with the same mobo, > but a different HDD. We're going to set it up and run some tests to see if > we can get it to crash. > One thing that I thought about (feel free to support or refute this based > on your own experience) is that we're hitting this hardware hard enough > that we may be exposing driver bugs that others haven't seen. I guess > we'll find out (hopefully). > [snip] I had the same problems with the promise ATA controller and the IBM DTLA-307075 for the past several months. I don't believe that was related to hardware 'failure', since I had that happened to all 4 of our servers with the same configuration, only after I upgraded from IBM-DPTA-373420 to DTLA-307075. In addition to the ffs_blkfree: freeing free block panics, I also got 'ffs_valloc: dup alloc' and 'ufs_dirbad: bad dir' panics, which made me discount there was a filesystem bug. I tried quite a few different configurations already. Maybe, combinating our testings, we could find the problem and the solution faster... The MB of the servers are ASUS P2B-DS with the Promise as ata2 and ata3 and I originally had Promise U66 and one DPTA-373420 on each ata2/3, running FreeBSD 4.1-releng. The panics started when I replaced the 2 DPTA-373420 to DTLA-307075. Each servers (4 of them) panic'ed every other day or so. - Replaced the Promise U66 to U100... made no different - Single or Dual CPU... made no different - Upgraded to FreeBSD-stable every week... made no different - One Promise U100/IBM drives was replaced with 2940U2 controller/Cheetah 3 weeks ago... that server had not panic since. - Replaced the other 3 servers with SCSI controller with only 1 drive; left U100 and 1 IBM drive 2 weeks ago. 2 different servers panic once... panic reduced from every 2 days to over a week!? The next thing I was going to do was to put the IBM drive onto the ASUS ata controller, but if you are going to try that. I am going to wait... our servers are 50 miles away. The Promise/IBM solution is much more cost effective than the Adaptec/Cheetah and I had quite a few more servers to upgrade. Best regards 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?200107201913.MAA05538>