On Tue, Jun 06, 2017 at 09:12:23AM +0200, Christoph Hellwig wrote: > On Tue, Jun 06, 2017 at 10:10:45AM +0300, Sagi Grimberg wrote: > > > >>>> Note 7 here is NVME_SC_ABORT_REQ. Also we would avoid walking through > >>>> all power states inside the nvme_configure_apst as > >>>> nvme_set_latency_tolerance was called with value > >>>> PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT (-1) which sets > >>>> ctrl->ps_max_latency_us to U64_MAX and tries to send a sync command > >>>> which of course fails with error message. > >> > >> Even though this change from this patch does fix the hang, just tested > >> again and I can see above error message "failed to set APST feature 7" > >> while nvme_remove PID is getting executed. > >> > >> So, sync requests (while nvme_remove is executing) are going through > >> and not everything is handled well in .queue_rq while controller is > >> under deleting state or dead state. > > > > The error message is expected because queue_rq is failing the I/O, did > > you see it actually hang?
No hang. > > > > Personally I'm not too bothered with the error log, we can suppress it > > conditional on the ctrl state if it really annoys people, but if we're > > conditioning on the ctrl state, we can do it like you suggested anyway... > > Yeah. Or just remove the error printk entirely.. Thanks for input, lets ignore. Based on earlier message I guess this is already queued. If not it seems worth adding for 4.12-rc.
