On Sat, Mar 15, 2014 at 2:47 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2014-03-14 at 13:11 -0700, Dan Williams wrote: >> On Mon, Mar 10, 2014 at 11:29 PM, James Bottomley >> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> > In the long game, though this whole debate is moot: setups with hard >> >> > wired start times adhere to them regardless of what the system does, so >> >> > they ignore start unit commands. Systems without hard wired start times >> >> > can usually be started at once, so us introducing a delay is unnecessary >> >> > in either case. >> >> >> >> Ok, then I'll let the patch stand as is. >> > >> > Sounds good. >> > >> > James >> > >> > >> >> Well, one more chirp about this. If the user has disabled async >> scanning by CONFIG_SCSI_SCAN_ASYNC=n or scsi_mod.scan != "async" then >> resume should follow suit. I'll include this in the next rev. > > Hm, OK, if this is tied at the hip to async scanning, why do you need > another async domain for it? Why not just use the current async > scanning domain ... it will actually probably resolve a few nasty (but > wholly manufactured) races where scanning races with suspend. I considered that initially, but it ends up destroying most/all of the benefit of doing it asynchronously. This is due to the fact that scsi_sd_probe_domain is flushed by the async_synchronize_full() performed in dpm_resume(). We want userspace to resume while the disk may still be starting. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
