LSI supported mps(4) driver available

[Dennis Glatting]

On Fri, 2012-01-20 at 13:44 -0700, Kenneth D. Merry wrote:
> The LSI-supported version of the mps(4) driver that supports their 6Gb SAS
> HBAs as well as WarpDrive controllers, is available here:
> 
> http://people.freebsd.org/~ken/lsi/mps_lsi.20120120.1.txt
> 
> I plan to check it in to head next week, and then MFC it into stable/9 a
> week after that most likely.
> 
> Please test it out and let me know if you run into any problems.
> 
> In addition to supporting WarpDrive, the driver also supports Integrated
> RAID.
> 
> Thanks to LSI for doing the work on this driver!
> 

Does this include the SAS2008 series chips? I have two systems, one a
Tyan FT48-B8812 with a S8812 MB and Interlagos chips, where I am
interested in using a driver under 9.0 amd64.


> I have added a number of other infrastructure changes that are necessary
> for the driver, and here is a brief summary:
> 
>  - A new Advanced Information buffer is now added to the EDT for drives
>    that support READ CAPACITY (16).  The da(4) driver updates this buffer
>    when it grabs new read capacity data from a drive.
>  - The mps(4) driver will look for Advanced Information state change async
>    events, and updates its table of drives with protection information
>    turned on accordingly.
>  - The size of struct scsi_read_capacity_data_long has been bumped up to
>    the amount specified in the latest SBC-3 draft.  The hope is to avoid
>    some future structure size bumps with that change.  The API for
>    scsi_read_capacity_16() has been changed to add a length argument.
>    Hopefully this will future-proof it somewhat.
>  - __FreeBSD_version bumped for the addition of the Advanced Information
>    buffer with the read capacity information.  The mps(4) driver has a
>    kludgy way of getting the information on versions of FreeBSD without
>    this change.
> 
> I believe that the CAM API changes are mild enough and beneficial enough
> for a merge into stable/9, but they are intertwined with the unmap changes
> in the da(4) driver, so those changes will have to go back to stable/9 as
> well in order to MFC the full set of changes.
> 
> Otherwise it'll just be the driver that gets merged into stable/9, and
> it'll use the kludgy method of getting the read capacity data for each
> drive.
> 
> A couple of notes about issues with this driver:
> 
>  - Unlike the current mps(4) driver, it probes sequentially.  If you have a
>    lot of drives in your system, it will take a while to probe them all.
>  - You may see warning messages like this:
> 
> _mapping_add_new_device: failed to add the device with handle 0x0019 to persiste
> nt table because there is no free space available
> _mapping_add_new_device: failed to add the device with handle 0x001a to persiste
> nt table because there is no free space available
> 
>  - The driver is not endian safe.  (It assumes a little endian machine.)
>    This is not new, the driver in the tree has the same issue.
> 
> The LSI folks know about these issues.  The driver has passed their testing
> process.
> 
> Many thanks to LSI for going through the effort to support FreeBSD.
> 
> Ken