On Mon, 6 Jan 2014, Phillip Susi wrote: > On 01/06/2014 10:38 AM, Alan Stern wrote: > > Indeed. I can't see any place where the SCSI or block layers > > would stop the queue of a device when it gets runtime suspended. > > Maybe some other layer is doing this. > > So I've stepped through it in qemu a good bit, and found some strange > things. At the time that sd_resume_system is called, the host is > still in the recovery state as a result of ata_port_resume, so this is > why scsi_request_fn doesn't dispatch the request. It requeues it for > after the eh finishes, but when the eh finishes and sets the state > back to running, scsi_request_fn calls blk_peek_request, and it > returns NULL rather than the requeued REQUEST SENSE. It's like the > request is lost rather than having been requeued. This raises two questions: Should the host's resume be allowed to complete while the host is still in error recovery? Wouldn't it be better to wait until the recovery is finished? How does the queue end up in a stopped state? (The stopped queue explains why blk_peek_request returns NULL.) You're in a better position than I am to answer these questions. 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
