Date: Tue, 16 Nov 2010 16:01:25 -0800 From: Matthew Jacob <mj@feral.com> To: freebsd-scsi@freebsd.org Subject: Re: SMP passthrough support for CAM and mps(4) Message-ID: <4CE31B55.2030603@feral.com> In-Reply-To: <20101116234053.GA78961@nargothrond.kdm.org> References: <20101116210507.GA35011@nargothrond.kdm.org> <4CE3109D.5090308@feral.com> <20101116234053.GA78961@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/16/2010 3:40 PM, Kenneth D. Merry wrote: > On Tue, Nov 16, 2010 at 15:15:41 -0800, Matthew Jacob wrote: >> + there are other, non-SMP things included (CAM_DIR_RESV -> CAM_DIR_BOTH) > That particular thing was intentional. CAM_DIR_BOTH is used when filling > in SMP commands, because data is transferred in both directions. (Request > and response.) Yes, but non-SMP commands can also now be bidirectional (viz OSD). >> + CAM_QUIRK_NOSERIAL got replaced with CAM_QUIRK_NOVPDS, fine >> >> + XPT_DEV_ADVINFO ought have a comment about what it is like the other >> commands. The pp below about advanced device info is hard to figure out. .. >> + The functions in smp_all.c should make clear distinctions about which >> version of SAS is being supported. > Will do, thanks. I based it on spl-r07, but I should make that explicit. > Most of the functions should be backwards-compatibile at least, because > they give the user the option to specify the long bit. I need to tweak at > least the smprg case in camcontrol (Report General) to detect the long bit > in the response and re-fetch with the long bit set to get the full > response. Ah. You might as well, at this point, go the extra mile and do SAS2 if you can. It's possible to tell from a REPORT GENERAL whether the device is SAS1 or SAS2, and if you do SAS2 you can get lists of phys instead of iterating over each. .... > One other goal is that for any given device in the topology, you'll be able > to have more than one protocol attached to it. e.g. if you have a SATA disk > in a SAS topology, you may be able to talk to it using SCSI or ATA. If you > have an expander, you may be able to talk it using SCSI or SMP. (In > reality, the expanders I've seen so far don't support SMP on the SAS > addresses that support SSP.) > Hmm. An expander is an SMP device only. It *may* have an SES portal to it, but SMP is in the SAS/SSP domain, not SMP. Another thing to keep in mind is that STP and SATA are in fact different. You tend to forget this when you use LSI HBAs which do the SATL work for you. The WWN of the STP (assigned by the expander) is different from a WWN for a SATA drive (wds 108..111 of modern SATA drives). This also gets horribly ugly when SAS/SATA dongles are used.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE31B55.2030603>