On Wed, 2006-05-31 at 17:32 -0400, Douglas Gilbert wrote: > Alexis Bruemmer wrote: > > These patches look good and are running on our x260 and the ppc64 > > (power). I was just wondering about a few things under the sys/class/: > > > > there is a sas_device, sas_end_device, and a sas_expander dir. > > sas_device contains the same info as sas_end_device, and a sas_expander > > can we eliminate one or the other? Or was this a design choice? > > > > Also during the boot process on the x260 with an expander we see these > > printk's: > > sas: phy[n] matched wide port0 > > If we are going to print this then we better be sure that this is truly > > a wide port. It seems under the sys/class/ we have both a single > > port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n]. and > > although each phy seems to have the same sas_address the end_device > > attached to that phy have unique addresses. My understanding is that a > > wide port has multiple phys with the same sas address and are attached > > to one end device. > > A wide port is an abstraction just above the link > layer in which two or more links running between > the same two devices have phys with the same SAS > addresses associated with them. > > Assume we have two phys on a HBA connected to two > phys on an expander, then two other phys on the > expander connected to a dual ported SAS disk. > That is one wide port connection (between the > at HBA and the expander) and two narrow > port connections (between the expander and each > port on the SAS disk). > > This comes about because phys on a HBA share a > SAS address, phys on a expander share a SAS address > but phys of a dual ported SAS disk have distinct > SAS addresses. > [Could someone suggest an instructive diagram url > of this as the sas drafts are a bit complex.] This would be assume! > > You are probably aware of this distinction but my > guess is a lot of other people aren't. > > Put another way, seen from a LLD or discover process when > multiple phys on the same device have this tuple > <SAS_address, attached_SAS_address> equal then there is > a wide port connection. If this is the case then according to the below print out we do not have a wide port on this machine: sas: phy0 added to port0, phy_mask:0x1 [ 155.328494] sas: phy1 matched wide port0 [ 155.328499] sas: phy1 added to port0, phy_mask:0x3 [ 155.328516] sas: phy2 matched wide port0 [ 155.328520] sas: phy2 added to port0, phy_mask:0x7 [ 155.328541] sas: phy3 matched wide port0 [ 155.328548] sas: phy3 added to port0, phy_mask:0xf [ 155.328578] sas: DOING DISCOVERY on port 0, pid:1785 [ 155.328917] sas: ex 5005076a00000a40 phy00:T attached: 50010b9000021585 [ 155.328996] sas: ex 5005076a00000a40 phy01:T attached: 50010b9000021575 [ 155.329081] sas: ex 5005076a00000a40 phy02:T attached: 50010b900004b87e [ 155.329169] sas: ex 5005076a00000a40 phy03:S attached: 5005076a011061c0 The sas_address and the sas_attached_address are different > > This also means that it is possible to talk about > a narrow port in the absence of an established > link but not possible to talk about a wide port > until there are two or more established links. > > It may also be worth pointing out that there is not data > aggregation on a wide port, but there is command aggregation. > So a 2 phy wide port connection will not run a single SCSI > command twice as fast, but can run two co-incident SCSI > commands at full link speed (i.e. up to 3 Gbps currently). > > I believe that the expander situation is not the > > same as wide port. If this is the case then it is as simple as changing > > the printk statement to not say "wide port" > > > > I am more than happy to make these changes if everyone agrees that they > > should be made. > > It may also be useful to use the term "narrow" > sometimes, especially if there is a transition > from wide to narrow (e.g. due to a faulty cable > or a link reset on one of the links). > > Doug Gilbert > - > : send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html