From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 15:04:38 2007 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE92016A46D for ; Tue, 6 Nov 2007 15:04:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 638C113C4B3 for ; Tue, 6 Nov 2007 15:04:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA6F2raM060636; Tue, 6 Nov 2007 08:02:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4730821B.3060403@samsco.org> Date: Tue, 06 Nov 2007 08:02:51 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Doug Ambrisko References: <200711052127.lA5LRblV035714@ambrisko.com> In-Reply-To: <200711052127.lA5LRblV035714@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 06 Nov 2007 08:02:54 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2007 15:04:38 -0000 Doug Ambrisko wrote: > Scott Long writes: > | The passthrough interface is really only meant for doing management > | tasks like SMART monitoring and firmware flashes. I've also seen it > | used for low-duty devices like tape drives. I do not recommend using it > | to directly control disks in a primary fashion. However, since this is > | open source, I won't prevent you from trying =-) Try the following > | patch: > | > | --- mfi_cam.c 12 Oct 2007 16:52:55 -0000 1.3 > | +++ mfi_cam.c 31 Oct 2007 03:42:25 -0000 > | @@ -344,9 +344,11 @@ > | command = ccb->csio.cdb_io.cdb_bytes[0]; > | if (command == INQUIRY) { > | device = ccb->csio.data_ptr[0] & 0x1f; > | +#if 0 > | if ((device == T_DIRECT) || (device == > | T_PROCESSOR)) > | csio->data_ptr[0] = > | (device & 0xe0) | T_NODEVICE; > | +#endif > | } > | break; > | } > > BTW, it works great in this mode if you know what you are doing :-) > Can you explain what that means? I recommend against it because it's not a well-tested configuration either in FreeBSD or in Dell. It's not clear, at least to me, how basic things like i/o errors get handled; does SCSI sense data get consumed by the controller firmware, or is it passed through to the OS without problem? > | I do believe that Dell does sell a direct attached disk option for > | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS > | controller that directly replaces the PERC5/i card that you have now. > | It should be able to control all 6 disk slots, and can do both SAS > | and SATA. > > I've been told the PERC5/e and PERC5/i are the same except for PCI > sub-device ID and are both the mfi(4) RAID controllers. They do > have a mpt(4) based card but it only supports 4 bays. I'm not sure > what it's real name is but we have some lying around for random > testing. I don't leave them in machines. > We should get a definitive answer on this. Scott