I chased the time out problem and found that the PORTE_BYTES_DMAED port event must be responded with a call to lldd_port_formed() which will update PHY_IS_UP and port-links fields in DDB 0. As there is a single thread handling PHY/port events as well as discovery, we really can't handle PORTE_BYTES_DMAED event until the discovery is complete. This results in SCSI commands timing out in the discovery thread no matter what I do! This problem may be unique to Vitesse expander, read the PS section for details. Tried using two threads, one for events and the other for discovery. That avoided the timeout problems, but the discovery thread would die after few iterations due to the event thread and the discovery thread racing each other for setting up and tearing down of sysfs objects. I tried calling lldd_port_formed() with appropriate phy_mask from the notify_port_event() itself. That worked fine. It is just a hack for now! Any comments, suggestions? Thanks, Malahal. 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. - 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
