#ident "@(#)issues 1.2 08/02/20 SAC" Issues for inception review -- dmk-1 Need more info on the synthetic address format for sata devices. (How is it constructed, why is it guaranteed to be unique?) Status: CLOSED Not guaranteed to be unique. MPXIO does this. Using a serial number and sata num is good enough. Vendor infor is not always there. Only a subset of the bits are used as all bits cannot be used. Not specifying the form of pg83 info this is dependent on. pg83 is a generic thing that gives a lot of granulaties and diff forms. For devids it is common betn user and kernel code. mpxio generates guid from the devid after generating it. It is not specified what part of pg83 is being used. Need to call out the descriptors in pg83 this is dependent on. New Comment: We are completely dropping the "SATA Identity" dmk-2 I still don't understand the PP,lun form of the unit address. - How does the phy + lun uniquely identify a target? Shouldn't it be PP,w[,lun] ? - I'm not sure that the phy# makes sense in the unit address. When I read the sas spec, it said that sw can assign phys to ports in different ways and the same phy can be used with one or more ports. Doesn't the logical port number make more sense from both a connectivity point of view and a user-friendly point of view? In either case, if the admin changes the configuration of the port, the pathnames can change. Either way is not particularly friendly since there doesn't seem to be a way to label port numbers on the connector. Status: CLOSED This behaves a lot like FC, if we move the disk it will break. dmk-3 Is there a transition plan for existing sas firmware and OS drivers? Are we actually going to change the way that existing sas devices already in the field report themselves and create problems for the user and the OS in this case? This needs to be considered and covered. For plug-in devices, I would imagine that they would continue to behave as they do today, unless the admin decides to upgrade the firmware on the plug-in card. For on-board devices, we probably need to make sure that we're not just arbitrarily changing the behavior of existing devices unless the admin decides that they want to do that since the device pathnames and drivers will change. How will the project manage this? Status: OPEN FCode is on a plugin card - it will not change unless vendor/Sun pushes out a new firmware Wont upgrade unless customer wants this and also have matching Solaris drivers. FCode is got in thru a MB device. Card with no FCode but has a drop-in driver. In the case of MB device Platform will get a new driver if they want it. With a single OBP image for all platforms, but still we should have different dropins. Existing platforms will keep the OBP dropins. New platforms will get the new drivers. Separate dropins for diff platforms. Possible to diff sets of dropins on diff platforms. Issue to work out with OBP and RE teams to make sure do the right thing. Not a FWARC issue. Need to solve before integration. New Comment: The issues regarding the selection of appropriate release vehicles for this interface have been directed to the appropriate product teams requesting this feature. At the moment we are planning to ship this interface only with new hardware. If any product teams require this feature for existing products there will probably bee additional ARC cases describing new interfaces required to select desired behavior, but they are not required as yet. dmk-4 N-Form of addressing Status: CLOSED In SAS 2.0 as part of the identify xchg, in addition to learning about the attach sas addr you learn about the attach name. It is not a sas addr and hence it is not interesting. It is a SAS 2.0 only feature. Make sure that we dont use this form of addressing. Look into this and make sure it applies to which version of SAS Add text describing whether or not will be used. Also specifically call out whether or not SAS 2.0 is covered by this spec or not. New Comment: This binding is targeted at SAS 1.1. If SAS 2.0 or later is incompatible with this interface then another FWARC case will be required to deal with those issues, though not likely. dmk-5 Sec 1.1.2.1 SAS addr represetation that refers the target port and phy-num representation uses input. 3.1.1.2.2 expects the other end to be a LUN. This only works for direct attached disk or a RAID device. Will not work if there is a expander. Improve the wording for section 3.1.1.2.2. Status: CLOSED Need to look into whether 3.1.1.2.2 is even needed ? NOTE: This is for legacy support and provide a way to generate devaliases for onboard disks. New Comment: Phy number addressing is only relevant for directly attached disks. Anything attached to a SAS expander needs to use the SASAddress form of addressing. The Phy number addressing is required for expanders such as PMC where the firmware does not provide synthetic SASAddresses for directly attached SATA disks, although in this case an enhancement to the specification such as the use of SATA WWIDs for SASAddresses if avail for directly attached disks should be permissable. dmk-6 Para 2 does not properly descripbe how we convert from pg83 logical unit name - how do we convert these bits into sssss... Status: CLOSED New Comment: We are completely dropping the "SATA Identity" dmk-7 issue about whether you want to use the port addresses or not. Status: OPEN New Comment: This issue does not have enought detail to address it. chris-1 Missing info on initiator port representation Status: OPEN There are valid configs defined by both SAS specs in which we want to have multiple paths to the same SAS addr. We want OBP to choose a port, but in Solaris we want to manage a port. In Solaris we want to direct traffic to a particular path by selecting a iniator path. HBA uses fake unit addresses. MVRAM on MPT remembers translation from the fake addr to target port and it also remembers initiator port on which you inject. Without the NVRAM we cannot have the FW present two ports. From MPXIO perspective we see only one port. It would be nice to be not divergent and make sure that the port rep is consistent between a Solaris and OBP. FW does not probe below the HBA. Does not work with NIC ports. Convergence wrt boot device and devinfo representation. NIC equiv of a port is a initiator port on SCSI. We want to hence not be divergent. This is workable provisionally. We need to revisit and see we need to address this. chris-2 we dont do the same thing as the OS, diff from MPXIO. We want to make sure that we dont things diff from what MPXIO is doing .. Status: OPEN ----------------------------------------- Commitment Issues - Aug 25, 2008 chris-1 The purpose of these comments is to acknowledge an 'iport' divergence between OBP and Solaris regarding device paths, and to bring up unpopular unit-address compatibility issues surrounding SAS1.0 and SAS2.0. A: 'iport' divergence: As part of support for SAS2.0, Solaris will be representing SCSI initiator ports in /devices paths. The FWARC 2008/013 case does not include 'iport' nodes. Solaris and OBP have agreed to diverge on 'iport' representation in paths. For Solaris, an API will be provided that allows SAS HBA drivers to dynamically manage the formation of SCSI initiator ports on the SAS transport. o Solaris code that needs to convert a /devices path to an OBP path will use the new 'obp-path' Solaris property being added to fix 6616427. o For NDI_PROMNAME paths, the Solaris resolve_pathname() implementation will need to be enhanced to resolve paths from OBP that don't contain initiator port path components. B: compatibility issue: SAS1.0.vs.SAS2.0 o generic name: I think "sas" is a more appropriate generic name than "scsi" for "sas" HBAs. Given that HBAs covered by 2008/013 will connect to both SAS devices (using SCSI protocol) and SATA devices (using ATA protocol), I think that using "scsi" as the generic name is unnecessarily confusing. o SATA unit-address issue: This has been the most contentious aspect of 2008/013. I know we thought we had put this issue to bed, but I have a few points I want to make. * During meetings discussing this topic, it was my understanding that the @PP form of unit address was *not* to be considered a canonical unit-address format. In subsequent communication with the project team, it seems they have chosen to make @PP canonical. * During meetings discussing this topic, there was a desire to select a unit-address based on device-identity, but we ended up compromising for SATA devices because of 'affiliations'. o We failed to recognize during these discussions that 'affiliations' are an expander issue, and don't pose a problem in choosing a identity-oriented unit-address for SATA devices directly connected to an HBA (specifically, an identity-oriented unit-address that uses the same algorithm that SAS2.0 defines for the 'device-name' of a SATA device) . o We failed to fully recognize during these discussions that SAS2.0 avoids affiliation issues by its definition of 'device-name' for SATA devices and communication of 'device-name' as an integral part of SAS discovery. The device name for SATA devices is described in section 4.2.7 of the SAS-2 draft spec (T10-1760D), revision 14c and is based on bytes 108-111 of ATA IDENTIFY-DEVICE data. I am revisiting this topic because I think that replacing a SAS1.0 HBA with a SAS2.0 HBA without breaking things would be of benefit, and with forethought is achievable. For A we have agreed to diverge. For B I expect my view to be in the minority, but I would like to request, at a minimum, a change in the IAM file case name to explicitly call out SAS1.0 instead of SAS. Status: OPEN hitu-1 In the specification section 2.2, definition of SASAddress have typos. Remove "name" and "followings" from the first line of the description. Also, replace "format" with the "address" in the second line. Status: OPEN hitu-2 Section 4.1.1, "local-wwid" property. I don't see this property in the interface table. The value of this property is derived from the System MAC address. Supernova's POR is to eliminate System MAC address from their system. There have been discussions in this area but if they want to support SCSI SAS on their system then they will either need system MAC address or we need to use some other MAC address. Status: CLOSED Supernova will provide system MAC addresses. hitu-3 In Interface table, exported interfaces, comments for "scsi-sas", replace "type" with "device_type". Status: OPEN tarl-1 Sec 3.1.1.1.2 phy number identification there are two form of identifcation, which one is canonical Status: OPEN