On Fri, 2019-02-22 at 17:37 +0100, Przemek Socha wrote:
> [ ... ]
> git bisect good 7cedffec8e759480f7f7a9be9cd0d7ebf0aafff2
> # first bad commit: [986d413b7c156e69198dfc80fb74aa18d0ddef44] blk-mq: Enable
> support for runtime power management
Hi Przemek,
This is weird. Neither scsi_device_quiesce() nor scsi_device_resume() are
called by the runtime power management callbacks in the SCSI core. Whether
or not runtime power management is enabled should not affect whether or not
the warning in scsi_device_resume() is triggered. The only explanation I
can think of is that a SCSI device disappeared and reappeared on the SCSI
bus during the suspend/resume cycle. If that analysis is correct the easiest
way to avoid that this warning appears is as follows:
[PATCH] Avoid that system resume triggers a kernel warning
This patch avoids that the following warning is triggered:
WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600
scsi_device_resume+0x4f/0x58
CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50
Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016
Workqueue: events_unbound async_run_entry_fn
Call Trace:
scsi_dev_type_resume+0x2e/0x60
async_run_entry_fn+0x32/0xd8
process_one_work+0x1f4/0x420
worker_thread+0x28/0x3c0
kthread+0x118/0x130
ret_from_fork+0x22/0x40
Reported-by: Przemek Socha <sop...@gmail.com>
Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably")
# v4.15
Signed-off-by: Bart Van Assche <bvanass...@acm.org>
---
drivers/scsi/scsi_lib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c77cb0d31dbc..c73045a5f739 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2541,7 +2541,6 @@ void scsi_device_resume(struct scsi_device *sdev)
* device deleted during suspend)
*/
mutex_lock(&sdev->state_mutex);
- WARN_ON_ONCE(!sdev->quiesced_by);
sdev->quiesced_by = NULL;
blk_clear_pm_only(sdev->request_queue);
if (sdev->sdev_state == SDEV_QUIESCE)
