Date: Sun, 25 Mar 2007 01:06:07 -0500 From: "Nikolas Britton" <nikolas.britton@gmail.com> To: "Jan Mikkelsen" <janm@transactionware.com> Cc: scottl@freebsd.org, Phillip Neumann <pneumann@gmail.com>, erich@areca.com.tw, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: Amd64 Unstable Areca Message-ID: <ef10de9a0703242306s6d1806a6l5856d5b757db36a@mail.gmail.com> In-Reply-To: <000b01c76e82$9e6f5a10$0502a8c0@IBMA618C20271E> References: <ef10de9a0703241853t2a06f651r3286423d3b1b5feb@mail.gmail.com> <000b01c76e82$9e6f5a10$0502a8c0@IBMA618C20271E>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/24/07, Jan Mikkelsen <janm@transactionware.com> wrote: > Nikolas Britton wrote: > > On 3/24/07, Jan Mikkelsen <janm@transactionware.com> wrote: > > > Hi, > > > > > > Nikolas Britton wrote: > > > > If that doesn't work move back down to 1.20.00.12: > > > > http://www.nbritton.org/uploads/areca/ > > > > > > I could consistently make 1.20.00.12 corrupt data. If you > > are going to go > > > back, that's probably a bad choice. 1.20.00.02 didn't seem to have > > > corruption problems. > > > > > > > The 1.20.00.12 driver I pointed to was a custom hack I did for my > > servers, It worked fine for the 7 months I was using it... I'm > > assuming we're talking about I/O load, the servers rarely see high cpu > > loads... the hardware: > > > > http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBE.cfm > > > > arcmsr0: <Areca SATA Host Adapter RAID Controller (RAID6 capable) > > ARECA RAID ADAPTER0: Driver Version 1.20.00.13 2006-8-18 > > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.41 2006-5-24 > > pass1 at arcmsr0 bus 0 target 16 lun 0 > > pass1: <Areca RAID controller R001> Fixed Processor SCSI-0 device > > da0 at arcmsr0 bus 0 target 0 lun 0 > > da0: <Areca ARC-1220-VOL#00 R001> Fixed Direct Access SCSI-3 device > > da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged > > Queueing Enabled > > da0: 1430511MB (2929687040 512 byte sectors: 255H 63S/T 182364C) > > > > I just upgraded them for the DST change. :-/ > > Interesting. How did you modify the 1.20.00.12 driver from Areca? > > Is the 1.20.00.13 driver mentioned above the one from 6.2-RELEASE? If so, > do you ever see g_vfs_done errors on this machine when it is under heavy I/O > load? > > From the machine I used to test the corruption issue (currently running > 6-STABLE): > > arcmsr0: <Areca SATA Host Adapter RAID Controller (RAID6 capable) > > mem 0xc8500000-0xc8500fff,0xc8c00000-0xc8ffffff irq 16 at device 14.0 on > pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > pass4 at arcmsr0 bus 0 target 16 lun 0 > pass4: <Areca RAID controller R001> Fixed Processor SCSI-0 device > > This is an ARC-1220 in a Supermicro X7DB8 based machine. > Yeah are hardware is nearly identical. I don't remember what I did to my custom driver, I know I fixed some syntax errors and merged in changes that were made on top of the 1.20.00.02 code base. I'm not sure but I think most of those changes were thrown out with the import of 1.20.00.13 and 14. Yes ..0.13 is the driver from 6.2-RELEASE-p2 and no I don't see any g_vfs errors, I do see a crap load of httpd errors that someone needs to investigate, lucky me. :-/ It's not likely I'd see them anyhow because the business slows way down during this time of year: > uptime: 11:53PM up 3 days, 8:56, 1 user, load averages: 0.00, 0.00, 0.00 I remember seeing that g_vfs error one time when one of the sata cables came loose. All hell broke loose and FreeBSD had a major brain fart, I've had several other sata cable 'incidents' but that's the only time FreeBSD croaked (with an areca card). The cable incidents happen with all are sata raid gear and it's not specific to areca products. I've come to the conclusion that the sata cables simply vibrate loose. I'm debating at the moment if we should move to sas multi-lane backplanes. The biggest problem I forsee is if one of the multi-lane cables comes loose, if that happened the array is toast .. anyhow... I simply rebooted the server, rebuilt the array, verified the array, and ran fsck. The file system corruption was typical of a power failure during disk write.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef10de9a0703242306s6d1806a6l5856d5b757db36a>