> The taskfile you are to pass to the hardware is created in > atapi_start_stop_xlat(), so you should not create a new taskfile in > ata_eh_maybe_verify() In order for resume to proceed without waiting for START to finish I need to complete and release READ VERIFY qc immediately. I can schedule EH action but it will be using a new qc and a new taskfile. > It is a clear laying violation to call out from the middle of a command > translation, to directly execute some EH actions. Remember, this is the > stage at which we are QUEUEING commands. There may be other commands in the > queue, or currently executing. If someone sends a READ VERIFY, we do not > want to IMMEDIATELY schedule EH, we want to execute an EH action when the > READ VERIFY command is ready to be executed. > > It is quite incorrect to assume that READ VERIFY will only be sent to libata > for execution during system resume. The removal of READ VERIFY translation > from ata_scsi_start_stop_xlat() is clearly wrong. > There is also ata_scsi_verify_xlat() that translates READ VERIFY. How can I tell in ata_scsi_start_stop_xlat() if this particular request is coming from system resume? Doesn't that mean I will have defer all START requests? Or I need a separate command instead of START_STOP to indicate that this request can be done asynchronously? Thanks, Maksim. -- 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
