On Fri, May 27, 2011 at 8:14 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-05-27 at 17:41 -0700, Dan Williams wrote: >> On Tue, May 24, 2011 at 1:17 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> > During initial scan libsas drivers start their phys and notify libsas >> > with PORTE_BYTES_DMAED events as port links are established. This >> > notification in turn causes libsas to post DISCE_DISCOVER_DOMAIN events >> > to the queue. Calling scsi_flush_work() at the end of scan_finished >> > guarantees that all preceding PORTE_BYTES_DMAED events have been >> > registered in the queue, but it does not guarantee that the resulting >> > DISCE_DISCOVER_DOMAIN events have been processed because >> > flush_workqueue() explicitly avoids live-locking with incoming work. >> > >> > Introduce sas_flush_discovery() to guarantee that all initial discovery >> > events have completed. It is called after the driver determines all >> > initial PORTE_BYTES_DMAED events have had a chance to enter the queue. >> > This does not cover BCNs that are generated during expander bring up, >> > only the initial sas_discover_domain() event. >> >> I notice that scsi-misc picked up all the patches from the series, >> save this one. >> >> Oversight, or nak? > > Neither ... as I've said several times before, I want to use tejun's > drain infrastructure for this. > Apologies, for the disconnect. Found the drain_workqueue thread... -- Dan -- 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
