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. Would appreciate any suggestions or issues with this approach. Thanks, Malahal. Luben Tuikov [ltuikov@xxxxxxxxx] wrote: > --- malahal@xxxxxxxxxx wrote: > > 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. > > Malahal, > > If you go back in the archives, and take a look at the SAS Stack > as I submitted it last year, you'll notice that this is exactly how > the code is: there is a separate event thread and a separate > discovery thread. > > That is, from inception, my code has always had two separate threads, > one for events and one for discovery. > > I wasn't aware that the code had been changed such that a single > thread handles events and discovery. This is a very naive approach, > and a regression over the original code. > > > 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. > > Indeed, the situation presented in such circumstances is tricky. > These "races" have been dealt with in my (original) code. Currently, > I don't experience any problems with my SAS Stack, as I maintain it. > > If any of my original comments are still left in the code or the README > files, that would give you a hint of how such "races" are handled. > > > 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! - 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
