Date: Mon, 13 Feb 2012 16:12:33 +0530 From: "Desai, Kashyap" <Kashyap.Desai@lsi.com> To: Johan Hendriks <joh.hendriks@gmail.com>, "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: RE: LSI supported mps(4) driver in stable/9 and stable/8 Message-ID: <B2FD678A64EAAD45B089B123FDFC3ED72B96D340E1@inbmail01.lsi.com> In-Reply-To: <4F38E00B.2020408@gmail.com> References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@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 >=20 > 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. >=20 > 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 >=20 > But now it has shuffled the order. > da8 da 14 da12 da10 > da9 da15 da13 da11 > da1 da6 da2 da5 > da0 da7 da3 da4 >=20 > 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 cal= l. It will ask CAM layer to rescan the bus.=20 So how CAM layer detects Drives is beyond Low level driver and it is obviou= sly 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=20 which mode mapping table is.=20 1. Enclosure slot mapping 2. Device mapping. For your case best choice will be Enclosure slot mapping. Assume you have E= nclosure slop mapping. Target ID assignment is part of Driver which will consistence across all re= boot. _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=20 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 wil= l 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. >=20 >=20 > regards > Johan Hendriks >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2FD678A64EAAD45B089B123FDFC3ED72B96D340E1>