LSI - MR-Fusion controller driver <mrsas> patch and man page

[Borja Marcos]

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!). 

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 
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 
pass2: 150.000MB/s transfers, Command Queueing Enabled


# camcontrol inq da14
pass16: <ATA Samsung SSD 840 BB0Q> Fixed Direct Access SCSI-6 device 
pass16: Serial Number S1D9NEADA08911Y     
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 
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=0x8<4K>

# camcontrol inq da16
pass18: <ATA OCZ-VERTEX4 1.5> Fixed Direct Access SCSI-6 device 
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.