On Mon, May 21, 2018 at 09:44:33AM -0600, Keith Busch wrote: > On Mon, May 21, 2018 at 11:34:27PM +0800, Ming Lei wrote: > > nvme_dev_disable() quiesces queues first before killing queues. > > > > If queues are quiesced during or before nvme_wait_freeze() is run > > from the 2nd part of reset, the 2nd part can't move on, and IO hang > > is caused. Finally no reset can be scheduled at all. > > But this patch moves nvme_wait_freeze outside the reset path, so I'm > afraid I'm unable to follow how you've concluded the wait freeze is > somehow part of the reset. For example: 1) the 1st timeout event: - nvme_dev_disable() - reset - scan_work 2) the 2nd timeout event: nvme_dev_disable() may come just after nvme_start_queues() in the above reset of the 1st timeout. And nvme_timeout() won't schedule a new reset since the controller state is NVME_CTRL_CONNECTING. Then scan_work in 1st timeout still may hang for ever. Thanks, Ming
