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? > > 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..
