From: Alan Stern <stern@rowland.harvard.edu>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Martin Kepplinger <martin.kepplinger@puri.sm>,
jejb@linux.ibm.com, Can Guo <cang@codeaurora.org>,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@puri.sm
Subject: Re: [PATCH] scsi: sd: add runtime pm to open / release
Date: Fri, 26 Jun 2020 11:44:41 -0400 [thread overview]
Message-ID: <20200626154441.GA296771@rowland.harvard.edu> (raw)
In-Reply-To: <1379e21d-c51a-3710-e185-c2d7a9681fb7@acm.org>
On Fri, Jun 26, 2020 at 08:07:51AM -0700, Bart Van Assche wrote:
> On 2020-06-25 01:16, Martin Kepplinger wrote:
> > here's roughly what happens when enabling runtime PM in sysfs (again,
> > because sd_probe() calls autopm_put() and thus allows it:
> >
> > [ 27.384446] sd 0:0:0:0: scsi_runtime_suspend
> > [ 27.432282] blk_pre_runtime_suspend
> > [ 27.435783] sd_suspend_common
> > [ 27.438782] blk_post_runtime_suspend
> > [ 27.442427] scsi target0:0:0: scsi_runtime_suspend
> > [ 27.447303] scsi host0: scsi_runtime_suspend
> >
> > then I "mount /dev/sda1 /mnt" and none of the resume() functions get
> > called. To me it looks like the sd driver should initiate resuming, and
> > that's not implemented.
> >
> > what am I doing wrong or overlooking? how exactly does (or should) the
> > block layer initiate resume here?
>
> As far as I know runtime power management support in the sd driver is working
> fine and is being used intensively by the UFS driver. The following commit was
> submitted to fix a bug encountered by an UFS developer: 05d18ae1cc8a ("scsi:
> pm: Balance pm_only counter of request queue during system resume") # v5.7.
I just looked at that commit for the first time.
Instead of making the SCSI driver do the work of deciding what routine to
call, why not redefine blk_set_runtime_active(q) to simply call
blk_post_runtime_resume(q, 0)? Or vice versa: if err == 0 have
blk_post_runtime_resume call blk_set_runtime_active?
After all, the two routines do almost the same thing -- and the bug
addressed by this commit was caused by the difference in their behaviors.
If the device was already runtime-active during the system suspend, doing
an extra clear of the pm_only counter won't hurt anything.
> I'm not sure which bug is causing trouble on your setup but I think it's likely
> that the root cause is somewhere else than in the block layer, the SCSI core
> or the SCSI sd driver.
>
> Bart.
Martin's best approach would be to add some debugging code to find out why
blk_queue_enter() isn't calling bkl_pm_request_resume(), or why that call
doesn't lead to pm_request_resume().
Alan Stern
next prev parent reply other threads:[~2020-06-26 15:44 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 11:10 [PATCH] scsi: sd: add runtime pm to open / release Martin Kepplinger
2020-06-24 13:33 ` Bart Van Assche
2020-06-25 8:16 ` Martin Kepplinger
2020-06-25 14:52 ` Alan Stern
2020-06-26 3:53 ` Bart Van Assche
2020-06-26 15:07 ` Bart Van Assche
2020-06-26 15:44 ` Alan Stern [this message]
2020-06-28 2:37 ` Bart Van Assche
2020-06-28 13:10 ` Alan Stern
2020-06-29 9:42 ` Martin Kepplinger
2020-06-29 16:15 ` Alan Stern
2020-06-29 16:56 ` Bart Van Assche
2020-06-29 17:40 ` Alan Stern
2020-06-30 3:33 ` Martin Kepplinger
2020-06-30 13:38 ` Alan Stern
2020-06-30 15:59 ` Bart Van Assche
2020-06-30 18:02 ` Alan Stern
2020-06-30 19:23 ` Bart Van Assche
2020-06-30 19:38 ` Alan Stern
2020-06-30 23:31 ` Bart Van Assche
2020-07-01 0:49 ` Alan Stern
2020-07-06 16:41 ` Alan Stern
2020-07-28 7:02 ` Martin Kepplinger
2020-07-28 20:02 ` Alan Stern
2020-07-29 14:12 ` Martin Kepplinger
2020-07-29 14:32 ` Alan Stern
2020-07-29 14:44 ` Martin K. Petersen
2020-07-29 14:56 ` Alan Stern
2020-07-29 14:46 ` James Bottomley
2020-07-29 14:53 ` James Bottomley
2020-07-29 15:40 ` Martin Kepplinger
2020-07-29 15:44 ` James Bottomley
2020-07-29 16:43 ` Martin Kepplinger
2020-07-29 18:25 ` Alan Stern
2020-07-29 18:29 ` James Bottomley
2020-07-30 8:52 ` Martin Kepplinger
2020-07-30 8:54 ` Martin Kepplinger
2020-07-30 15:10 ` Alan Stern
2020-08-04 9:39 ` Martin Kepplinger
2020-08-07 9:51 ` Martin Kepplinger
2020-08-07 14:30 ` Alan Stern
2020-08-08 6:59 ` Martin Kepplinger
2020-08-08 15:05 ` Alan Stern
2020-08-09 9:20 ` Martin Kepplinger
2020-08-09 15:26 ` Alan Stern
2020-08-10 12:03 ` Martin Kepplinger
2020-08-10 14:13 ` Alan Stern
2020-08-11 7:55 ` Martin Kepplinger
2020-08-11 13:48 ` Alan Stern
2020-08-23 14:57 ` [PATCH] block: Fix bug in runtime-resume handling Alan Stern
2020-08-24 17:48 ` Bart Van Assche
2020-08-24 20:13 ` Alan Stern
2020-08-26 7:48 ` Martin Kepplinger
2020-08-27 17:42 ` Martin Kepplinger
2020-08-27 20:29 ` Alan Stern
2020-08-29 7:24 ` Martin Kepplinger
2020-08-29 15:26 ` Alan Stern
2020-08-29 16:33 ` Martin Kepplinger
2020-08-29 18:56 ` Alan Stern
2020-08-30 0:38 ` Bart Van Assche
2020-08-30 1:06 ` Alan Stern
2020-07-29 15:40 ` [PATCH] scsi: sd: add runtime pm to open / release Alan Stern
2020-07-29 15:49 ` James Bottomley
2020-07-29 16:17 ` Alan Stern
2020-07-29 15:52 ` Martin Kepplinger
2020-07-29 18:10 ` Douglas Gilbert
2020-07-30 8:05 ` Martin Kepplinger
2020-07-30 15:14 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200626154441.GA296771@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=jejb@linux.ibm.com \
--cc=kernel@puri.sm \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.kepplinger@puri.sm \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.