LSI supported mps(4) driver in stable/9 and stable/8

[Desai, Kashyap]

> -----Original Message-----
> From: owner-freebsd-stable at freebsd.org [mailto:owner-freebsd-
> stable at freebsd.org] On Behalf Of Johan Hendriks
> Sent: Monday, February 13, 2012 3:34 PM
> To: Kenneth D. Merry
> Cc: freebsd-stable
> Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8
> 
> Kenneth D. Merry schreef:
> > Hi folks,
> >
> > The LSI-supported version of the mps(4) driver that supports their 6Gb
> SAS
> > HBAs as well as WarpDrive controllers, is now in stable/9 and
> stable/8.
> >
> > Please test it out and let me and Kashyap (CCed) 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!
> >
> > Note that the CAM infrastructure changes that went into FreeBSD/head
> along
> > with this driver have not gone into either stable/9 or stable/8.  Only
> the
> > driver itself has been merged.
> >
> > The CAM infrastructure changes depend on some other da(4) driver
> changes
> > that will need to get merged before they can go back.  If that merge
> > happens, it will probably only be into stable/9.
> >
> > A couple of notes about issues with this driver:
> >
> >   - Unlike the previous 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 previous version of the driver had 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
> Hello all.
> 
> I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a
> 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6
> On FreeBSD 9.0RELEASE i have the following order.
> Seen from the front of the case.
> da3 da7 da11 da15
> da2 da6 da10 da14
> da1 da5 da9 da13
> da0 da4 da8 da12
> 
> But now it has shuffled the order.
> da8 da 14 da12 da10
> da9 da15 da13 da11
> da1 da6 da2 da5
> da0 da7 da3 da4
> 
> There is no logic at all, and it is very hard to figure out when a disk
> dies which one it is.

Can you attach dmesg logs ?
Basically now Drive will not ask CAM layer to add device using XPT_ASYC call.
It will ask CAM layer to rescan the bus. 

So how CAM layer detects Drives is beyond Low level driver and it is obviously no guaranty of sequence of daX.
If you have some X Drives attached to enclosure, target IDs of those Drive will be generated by Driver based on 
which mode mapping table is. 
1. Enclosure slot mapping
2. Device mapping.

For your case best choice will be Enclosure slot mapping. Assume you have Enclosure slop mapping.

Target ID assignment is part of Driver which will consistence across all reboot.
_but_ when Driver call rescan bus (as part of device add), it will scan bus in sequence and later peripher layer will assing device naming.
So it is completely unsure which device will get what device name.

e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, Drive-C and Drive-D. (Consider alphabetical order is mapped to slot number )
So Driver will assign below target id. (target id 0-7 is reserved for local port of HBA)

Drive- A Target ID -8 
Drive- B Target ID -9
Drive- C Target ID -10
Drive- D Target ID -11

You cannot expect Drive-A will be assigned to da0. (and similar Drive-D will get da3).

In summary, This behavior is visible just because of new change in driver, but it is never *must* follow condition for any driver.
Device naming is part of CAM layer.


> 
> 
> regards
> Johan Hendriks
> 
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe at freebsd.org"