From owner-freebsd-scsi@FreeBSD.ORG Wed Aug 14 15:03:37 2013 Return-Path: Delivered-To: FreeBSD-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6EB28558; Wed, 14 Aug 2013 15:03:37 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4923420FB; Wed, 14 Aug 2013 15:03:37 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 Aug 2013 08:06:57 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r7EF3VS6041728; Wed, 14 Aug 2013 08:03:31 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r7EF3VAB041727; Wed, 14 Aug 2013 08:03:31 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 14 Aug 2013 08:03:31 -0700 From: Doug Ambrisko To: sbruno@freebsd.org Subject: Re: Dell H310, JBOD mode "hard error" Message-ID: <20130814150331.GB34825@ambrisko.com> References: <1373822621.1431.5.camel@localhost> <1376448416.1439.7.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1376448416.1439.7.camel@localhost> User-Agent: Mutt/1.4.2.3i Cc: "FreeBSD-scsi@freebsd.org" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:03:37 -0000 On Tue, Aug 13, 2013 at 07:46:56PM -0700, Sean Bruno wrote: | On Sun, 2013-07-14 at 10:23 -0700, Sean Bruno wrote: | > Not sure what to make of this. I've tested a lot of svn revisions of | > the thunderbolt code, but nothing looks obvious. | > | > When I use a single drive in "SYSPD" mode on a Dell H310 (falcon or | > skinny drake) I get a /dev/mfisyspd0 device. The JBOD mode *seems* to | > work just fine as long as I don't do multiple things at once to it, e.g. | > single user fsck works, but multiuser things die. | > | > I get a failure case that emits errors such as: | > | > g_vfs_done():error 27 in callback | > mfisyspd0p2[READ(offset=7176192, length=425984)]mfisyspd0: hard error | > error = 5 | > cmd=read 15360-16383 | > error 27 in callback | > g_vfs_done():mfisyspd0: hard error mfisyspd0p2[READ(offset=7602176, | > length=524288)]cmd=read error = 5 | > 16384-17407 | > error 27 in callback | > g_vfs_done():mfisyspd0: hard error mfisyspd0p2[READ(offset=8126464, | > length=524288)]cmd=read error = 5 | > 14560-15359 | > error 27 in callback | > g_vfs_done():mfisyspd0: hard error mfisyspd0p2[READ(offset=7192576, | > length=409600)]cmd=read error = 5 | > 15360-16383 | > | > | > Sean | | Ah, I see something that Yahoo! does that FreeBSD does not finally. We | tune MAXPHYS *up* to (512 * 1024) because of performance and available | memory. | | mfi(4) set's its own (MFI_MAXPHYS) to (128 * 1024) instead of using the | value from sys/param.h (btw, I don't quite get why, but whatever). | | Without a min() check in mfi_syspd.c that mimics the one in mfi_disk.c, | Yahoo code falls over in "SYSPD" mode (mfi(4) real jbod mode). | | Patch: | | Index: mfi_syspd.c | =================================================================== | --- mfi_syspd.c (revision 254313) | +++ mfi_syspd.c (working copy) | @@ -128,7 +128,9 @@ | sc->pd_disk->d_drv1 = sc; | sc->pd_disk->d_maxsize = sc->pd_controller->mfi_max_io * secsize; | sc->pd_disk->d_name = "mfisyspd"; | - sc->pd_disk->d_open = mfi_syspd_open; | + sc->pd_disk->d_maxsize = min(sc->pd_controller->mfi_max_io * secsize, | + (sc->pd_controller->mfi_max_sge - 1) * PAGE_SIZE); | + | sc->pd_disk->d_close = mfi_syspd_close; | sc->pd_disk->d_strategy = mfi_syspd_strategy; | sc->pd_disk->d_dump = mfi_syspd_dump; That change for d_maxsize looks okay but do you really want to get rid of d_open? I assume this is a cut-n-paste type error and the patch (hand editted) should be: Index: mfi_syspd.c =================================================================== --- mfi_syspd.c (revision 254313) +++ mfi_syspd.c (working copy) @@ -128,7 +128,8 @@ sc->pd_disk->d_drv1 = sc; - sc->pd_disk->d_maxsize = sc->pd_controller->mfi_max_io * secsize; + sc->pd_disk->d_maxsize = min(sc->pd_controller->mfi_max_io * secsize, + (sc->pd_controller->mfi_max_sge - 1) * PAGE_SIZE); sc->pd_disk->d_name = "mfisyspd"; sc->pd_disk->d_open = mfi_syspd_open; sc->pd_disk->d_close = mfi_syspd_close; sc->pd_disk->d_strategy = mfi_syspd_strategy; sc->pd_disk->d_dump = mfi_syspd_dump; BTW, has mfiutil been updated to create real JBODs versus the RAID per drive? I know someone was talking about doing that. A note on implementing it, it also requires JBOD to be enabled in the controller. I'm not sure if all controllers support it. I forget when I was playing with it. I've always wondering if we should change the name for the syspd disk node but I left it for compatibility with LSI. We could do an alias. It is good in away that it doesn't create /dev/mfid* nodes so that it is easier to track bugs. Thanks, Doug A.