summaryrefslogtreecommitdiff
path: root/drivers/powercap
diff options
context:
space:
mode:
authorMika Westerberg <mika.westerberg@linux.intel.com>2016-02-18 10:54:12 +0200
committerTejun Heo <tj@kernel.org>2016-02-19 10:52:45 -0500
commit356fd2663cff131fb9db573a3e45830778cfdbdd (patch)
treef940f3cfecd128b13f49df7bc308ef7e8245bcb3 /drivers/powercap
parentd07ab6d114774d7fcb53c57d7474aef459713451 (diff)
scsi: Set request queue runtime PM status back to active on resume
We treat system suspend of SCSI devices pretty much the same as runtime suspend. If the device is already runtime suspended we leave it to that state during system suspend. On resume from system sleep we then resume the device and correct the runtime PM status back to "active". There is a problem with this because runtime PM status of the request queue in question is not changed (it will be in "suspended" state). When SCSI disk driver (sd.c) resumes the disk it sends START message to the device and because the request queue is still in "suspended" state blk_pm_peek_request() returns NULL preventing resume of the disk. The issue can be reproduced with following commands: # echo auto > /sys/block/sda/device/power/control # echo 15000 > /sys/block/sda/device/power/autosuspend_delay_ms [ 57.191706] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 57.380015] sd 0:0:0:0: [sda] Stopping disk Now suspend the machine: # rtcwake -s10 -mmem This ends up in soft lockup because resume is not proceeding accordingly and userspace is never restarted. Also there is nothing printed to the console. Fix this by forcing request queue status to "active" before the disk is resumed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'drivers/powercap')
0 files changed, 0 insertions, 0 deletions