On Tue, 2006-09-19 at 13:59 -0700, malahal@xxxxxxxxxx wrote: > I am planning to process port/phy events in two phases. Phase-I sets up > asd_sas_port, asd_sas_phy lists and calls the LLDD with a correct > phy_mask. Phase-II is done in the thread context by queuing to the scsi > work queue that involves setting up sysfs objects. Still there would be > just one thread setting up/tearing down sysfs objects that should avoid > any races. Erm ... just a minute, I don't understand what the problem is. The reason you can handle both in a single event thread is because the PORTE_BYTES_DMAED event either triggers discovery or wide port formation (if it's the discovery of another phy in the port). It sounds like the scenario you have is that discovery is kicked off before the wide port is formed (I actually see this a bit in my LSI expander as well). This shouldn't be an issue: we're perfectly entitled to do discovery on a single phy if we so choose and not form the wide port until after discovery is completed. We really need to debug this. In your PS you wrote: > PS: I instrumented the code to use only a single PHY out of 4-phy wide > port by prematurely returning from sas_form_port() for all PHYs except > one. In other words, I ignored the PORTE_BYTES_DMAED event for all PHYs > but one. There were SCSI timeouts every time I did that except if the > PHY I was using is phy3. When I swapped cables, the PHY that worked > changed too. I believe, it goes with a specific Vitesse expander PHY. Is > it possible that the Vitesse expander uses a specific PHY to respond to > some SCSI requests even though the adapter uses a different PHY while > sending the request? Is this behavior of communicating on two different > PHYs for a single SCSI command is allowed in the spec? Also note that > the discovery commands (SMP) just work fine. However, SAS specs require us to open connections for SMP and receive the responses through the connection we opened. The target is specifically prohibited from responding outside of this protocol boundary. The theory behind this is that the Host controls port formation ... until we open multiple connections between the source and target ports, the actual connection remains narrow. All of this should support the current discovery model. I suppose the only way to confirm what's going on would be with a SAS analyser. Does the host send multiple OPEN's even before the PORTE_BYTES_DMAED is responded to? James - To unsubscribe from this list: 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
