On Mon, 19 Nov 2007, Salyzyn, Mark wrote: > Alan Stern sez: > > Sure. But that won't do any good if the requests get held on > > the queue > > (or failed immediately) because the disk is supposedly "suspended". > > Somehow those requests have to be allowed to proceed while all others > > are forced to wait (or to fail). > > Not a failure. Not ready is reported back in a check condition on a > media based request, a spin-up request is issued, then a subsequent loop > sits there probing every second with a Test Unit ready to wait for the > drive to spin back up. There is ample time provided in this path for the > drive to spin-up. You're talking about what the stack does now, but I'm talking about what it will do once the dynamic power management code is in place. Commands won't even get sent to the low-level driver, never mind coming back with a check condition status. Here's how it will work: scsi_prep_state_check() will see that the device is in a suspended state (probably a substate of SDEV_QUIESCE). The return value will depend on the type of suspend: For manual suspend or system suspend, the routine simply returns BLKPREP_KILL. For autosuspend, the routine will submit a workqueue request to autoresume the device and will return BLKPREP_DEFER. The trick is somehow to allow the START-STOP UNIT commands get past this filter. Is this what the REQ_PREEMPT flag is intended for? Alan Stern - 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
