Date: Thu, 27 Mar 2014 15:28:56 +0100 From: Borja Marcos <borjam@sarenet.es> To: Doug Ambrisko <ambrisko@cisco.com> Cc: "scottl@netflix.com" <scottl@netflix.com>, "Radford, Adam" <Adam.Radford@lsi.com>, "sean_bruno@yahoo.com" <sean_bruno@yahoo.com>, "Mankani, Krishnaraddi" <Krishnaraddi.Mankani@lsi.com>, "dwhite@ixsystems.com" <dwhite@ixsystems.com>, "Maloy, Joe" <Joe.Maloy@lsi.com>, "jpaetzel@freebsd.org" <jpaetzel@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "Kenneth D. Merry" <ken@kdm.org>, "McConnell, Stephen" <Stephen.McConnell@lsi.com> Subject: Re: LSI - MR-Fusion controller driver <mrsas> patch and man page Message-ID: <AB2BB10F-2BD9-49B9-91F2-A105683D3CBF@sarenet.es> In-Reply-To: <20140324174519.GA30345@cisco.com> References: <e59396595152456dbcde63d48f70aa8f@BN1PR07MB247.namprd07.prod.outlook.com> <20140107181139.GC2080@cisco.com> <20140124185356.GA28724@ambrisko.com> <20140124190047.GA34975@ambrisko.com> <9c3fd2b15e9b4c2cb967519a3b7f98ad@BN1PR07MB247.namprd07.prod.outlook.com> <20140318143738.GA65955@cisco.com> <20140320235534.GA92797@cisco.com> <C698AC2A-06A7-4408-9790-20B69FAF31C6@sarenet.es> <20140321160954.GB99545@cisco.com> <5C32A3C7-B28B-4E69-9DF0-EE53181085F7@sarenet.es> <20140324174519.GA30345@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 24, 2014, at 6:45 PM, Doug Ambrisko wrote:
> Nothing is planned to be removed from mfi. However, LSI would like =
mrsas
> to be used on newer cards. We've let people LSI know that people use
> the pass through mode and having the logical volumes come up as =
/dev/daX
> and pass through would be confusing. Granted mrsas doesn't support =
pass
> through so that isn't a problem.
I've just tried a Joe job with the mrsas driver, installing it on =
FreeBSD 10-STABLE.
NO CORRUPTION (and the disks are indeed assigned to the "da" driver, =
with trim and quirks working).
I have just had a problem (reading a disk's attributes with smartctl =
caused a disconnect and I had to
do a camcontrol rescan to see the disk again) but it can be due to the =
ugly kludge I've done to
be able to compile mrsas in 10-STABLE.
(Don't try this at home, kids, it was just a zero-effort shot which, =
surprisingly, has yielded good results ;) )
I've downloaded the latest driver, 6.602.01.00_MR_Free-BSD_Driver.tgz =
from the LSI website. I noticed the
release notes mention a bug that causes data corruption with syspd disks =
(bingo!).=20
So I installed it (copied the mrsas directories to /usr/src/sys/dev and =
/usr/src/sys/modules), updated the files list,
and compiled a kernel without the mfi driver.
In order to compile I had to edit mrsas_cam.c, seems that the flags =
have changed in recent versions.
% diff mrsas_cam.c*
419,420c419,420
< if (!(ccb_h->flags & CAM_DATA_PADDR)) { //Virtual data address =
BORJA
< if (!(ccb_h->flags & CAM_DATA_SG)) { // Borja asumi =
SCATTER_VALID es DATA_SG
---
> if (!(ccb_h->flags & CAM_DATA_PHYS)) { //Virtual data address
> if (!(ccb_h->flags & CAM_SCATTER_VALID)) {
I am pretty sure my flag substitutions are wrong, but all I wanted to do =
was a really quick test. The test has been successful and=20
at least in a couple of hours I haven't seen any data corruption at all. =
Just that dropping issue when using smartctl to read the SMART
data, but I wonder if it's caused by my obviously wrong kludge.
I still notice that, for some reason, the devices are still negotiating =
a low speed. It must be true, because the SSDs peak at around 200 MB/s =
with the Invader, reaching 400 MB/s with a flashed LSI2008 card (latest =
IT mode firmware).
# camcontrol inq ses0
pass2: <IBM-ESXS SAS EXP BP 61A6> Fixed Enclosure Services SCSI-4 device=20=
pass2: 150.000MB/s transfers, Command Queueing Enabled
# camcontrol inq da14
pass16: <ATA Samsung SSD 840 BB0Q> Fixed Direct Access SCSI-6 device=20
pass16: Serial Number S1D9NEADA08911Y =20
pass16: 150.000MB/s transfers, Command Queueing Enabled
I must also say, regarding my comments to LSI, that maybe I was wrong =
with some of them. I see that with the disks configured as SYSPD on
the Invader card they appear as "da" (alright, that I knew) *and* I can =
see the additional features such as TRIM (which works) and of course
disk quirks. Anyway of course I will insist that so-called syspd drives =
should have a guarantee of maximum transparency.
Mar 27 13:49:40 piruli kernel: da16 at mrsas0 bus 1 scbus2 target 23 lun =
0
Mar 27 13:49:40 piruli kernel: da16: <ATA OCZ-VERTEX4 1.5> Fixed Direct =
Access SCSI-6 device=20
Mar 27 13:49:40 piruli kernel: da16: Serial Number OCZ-SKC094QRU20F444P
Mar 27 13:49:40 piruli kernel: da16: 150.000MB/s transfers
Mar 27 13:49:40 piruli kernel: da16: 488386MB (1000215216 512 byte =
sectors: 255H 63S/T 62260C)
Mar 27 13:49:40 piruli kernel: da16: quirks=3D0x8<4K>
# camcontrol inq da16
pass18: <ATA OCZ-VERTEX4 1.5> Fixed Direct Access SCSI-6 device=20
pass18: Serial Number OCZ-SKC094QRU20F444P
pass18: 150.000MB/s transfers, Command Queueing Enabled
Still the negotiation seems to be failing, but I wonder if it's more of =
a firmware problem with the controller, expander or both.
Cheers,
Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AB2BB10F-2BD9-49B9-91F2-A105683D3CBF>