From owner-freebsd-stable@FreeBSD.ORG Fri Dec 19 07:02:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B3E1065675; Fri, 19 Dec 2008 07:02:10 +0000 (UTC) (envelope-from yohimba@mail.ru) Received: from mx44.mail.ru (mx44.mail.ru [195.239.211.10]) by mx1.freebsd.org (Postfix) with ESMTP id B811A8FC1F; Fri, 19 Dec 2008 07:02:09 +0000 (UTC) (envelope-from yohimba@mail.ru) Received: from f217.mail.ru (f217.mail.ru [194.186.55.150]) by mx44.mail.ru (mPOP.Fallback_MX) with ESMTP id CD5FB38002535; Fri, 19 Dec 2008 09:51:59 +0300 (MSK) Received: from mail by f217.mail.ru with local id 1LDZDJ-000Gxg-00; Fri, 19 Dec 2008 09:51:57 +0300 Received: from [195.208.10.252] by win.mail.ru with HTTP; Fri, 19 Dec 2008 14:51:57 +0800 From: Vyacheslav I. To: freebsd-amd64@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [195.208.10.252] Date: Fri, 19 Dec 2008 14:51:57 +0800 X-Priority: 1 (High) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: OK Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, msmith@freebsd.org, freebsd-hardware@freebsd.org Subject: Problem with FreeBSD for AMD64 & Mylex AcceleRAID X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Vyacheslav I." List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 07:02:10 -0000 Hi! I used to use the FreeBSD on i386 architecture together with the controller Mylex AcceleRAID 170.There was RAID 0+1 configured on it out of 5 discs (Enhanced Mirroring). # pciconf -lvc ... mly0@pci0:6:1:0: class=0x010400 card=0x00521069 chip=0x00501069 rev=0x02 hdr=0x00 vendor = 'Mylex Corp' device = 'AcceleRAID Disk Array' class = mass storage subclass = RAID cap 01[80] = powerspec 2 supports D0 D3 current D0 I used this configuration on i386 architecture with the following versions FreeBSD: 4.x, 5.x, 6.x and 7.0. It always worked perfectly. But recently I got needed 8 GB RAM so I had to install the version FreeBSD for AMD64. First I tried the 7.0, and after all - RELENG_7_1 dated 12.12.2008. Both these systems work with the files system located on RAID unstablÅ! Meanwhile the same hardware on i386 architecture works with RELENG_7_1 perfectly. Hardware: MB INTEL DG33FB, CPU Intel(R) Core(TM)2 Quad CPU @ 2.40 GHz, RAM 8 GB. The base system is installed on a separate IDE disc. # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 496M 111M 345M 24% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad4s1d 3.9G 22K 3.6G 0% /tmp /dev/ad4s1f 333G 52G 255G 17% /usr /dev/ad4s1e 15G 41M 14G 0% /var /dev/da0s1d 70.7G 410K 70.1G 0% /mnt/da0/d I carried out the following test by creating 3 big sized files of 1 GB each, and then deleting them: # cd /mnt/da0/d # dd if=/dev/zero of=test1 bs=1024k count=1024 # dd if=/dev/zero of=test2 bs=1024k count=1024 # dd if=/dev/zero of=test5 bs=1024k count=1024 # rm test* After that I tried to unmount the files system, but I get a message of the kernel panic: # cd / # umount /mnt/da0/d ... bad block 123456789, ino 176 dev = da0s1d, block = 4, fs = /mnt/da0/d panic: ffs_blkfree: freeing free block cpuid = 3 Uptime: 34 min... The test was successful when using the i386 architecture with the same hardware Taking a piece of advice of my friend, I used a dirty patch: === [code] === diff -Nru src.orig/sys/cam/scsi/scsi_da.c src/sys/cam/scsi/scsi_da.c --- src.orig/sys/cam/scsi/scsi_da.c 2008-12-10 10:01:40.000000000 +0800 +++ src/sys/cam/scsi/scsi_da.c 2008-12-19 12:18:27.000000000 +0800 @@ -1187,7 +1187,7 @@ if (match != NULL) softc->quirks = ((struct da_quirk_entry *)match)->quirks; else - softc->quirks = DA_Q_NONE; + softc->quirks = DA_Q_NO_SYNC_CACHE; // Dirty hack for AMD64 /* Check if the SIM does not want 6 byte commands */ xpt_setup_ccb(&cpi.ccb_h, periph->path, /*priority*/1); === [/code] === This patch solved the problem and the systems stopped being panicking. But I assume that this solution is wrong as the hardware works on i386 architecture without this patch well.