Date: Wed, 25 Jan 2012 20:47:37 -0800 From: Dennis Glatting <freebsd@penx.com> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: LSI supported mps(4) driver available Message-ID: <1327553257.19745.6.camel@btw.pki2.com> In-Reply-To: <20120120204459.GA51162@nargothrond.kdm.org> References: <20120120204459.GA51162@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1327553257.19745.6.camel>