From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management
Date: Fri, 13 Oct 2023 10:36:25 -0400 [thread overview]
Message-ID: <871qdyh9na.fsf@vps.thesusis.net> (raw)
In-Reply-To: <672365d4-bdd6-47c9-b0be-6756f523db59@kernel.org>
Damien Le Moal <dlemoal@kernel.org> writes:
> Yes. I rechecked the specs regarding this and there is nothing preventing
> IDENTIFY from completing with the drive spun down. The only corner case is when
> PUIS is enabled, in which case IDENTIFY may return incomplete data. But that is
> handled already and that is not something we can get with a system
> suspend/resume or runtime suspend/resume.
It *IS* something we get on suspend/resume. During suspend the drive
loses power, and on resume, it regains power. As far as the drive is
concerned, the computer was shutdown and booted back up, so it powers up
in standby.
> From re-reading the specs and testing with all my drives, the port reset spins
> up the drives and IDENTIFY completes OK before the spinup completes, so there
> is no delay.
Interesting. I was under the impression that most disks have to read
their sererial number and possibly other information from the media in
order to report that in IDENTIFY, and therefore, they would have to
finish spinning up before they could return complete information.
> I CC-ed you a couple of patches that move the VERIFY command
> issuin to after revalidation (so execution of IDENTIFY, READ LOG etc). That
> works well. I also added a CHECK POWER MODE command to check if sending the
> verify is actually needed. And even while the disks are spinning up, I get
> power mode 0xFF indicating ACTIVE state, so no need to send the VERIFY command
> at all. The end result is that we get to finish the libata EH context doing the
> resume well before the disk finishes spinning up (which can take 10+ seconds).
>
> With this, the first read or write command following the resume will be delayed
> until the drive finishes spinning up. But that is fine given the default 30s
> tiemout and retries. I do not expect any problems with that.
That looks very good. I think I will try to adapt my old patch to allow
the eh to return -EAGAIN and leave the drive in standby rather than
force it to wake up with the VERIFY in the system resume path. The eh
can be retried later when the drive is actually accessed and that time
it can force it to spin up.
next prev parent reply other threads:[~2023-10-13 14:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c0b086ab-dcd5-4b7b-b931-4d407dd7ad47()kernel!org>
2023-10-12 19:01 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Phillip Susi
2023-10-13 0:57 ` Damien Le Moal
2023-10-13 14:36 ` Phillip Susi [this message]
2023-10-15 22:09 ` Damien Le Moal
2023-10-21 17:56 ` Phillip Susi
2023-10-23 5:49 ` Damien Le Moal
2023-11-03 18:05 ` Phillip Susi
2023-11-03 23:01 ` Phillip Susi
2023-11-06 2:32 ` Damien Le Moal
2023-11-07 13:27 ` Phillip Susi
2023-11-07 21:59 ` Damien Le Moal
2023-11-08 22:07 ` Phillip Susi
2023-11-06 3:00 ` Damien Le Moal
2023-11-07 13:45 ` Phillip Susi
2023-11-07 21:48 ` Phillip Susi
2023-11-07 23:11 ` Damien Le Moal
2023-11-08 22:15 ` Phillip Susi
2023-11-09 22:09 ` Phillip Susi
2023-11-09 22:57 ` Damien Le Moal
2023-11-10 16:41 ` Phillip Susi
2023-11-10 0:43 ` Damien Le Moal
2023-11-07 22:13 ` Damien Le Moal
2023-11-08 22:25 ` Phillip Susi
2023-09-27 14:18 [PATCH v8 00/23] Fix libata suspend/resume handling and code cleanup Damien Le Moal
2023-09-27 14:18 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Damien Le Moal
2023-09-27 19:50 ` Martin K. Petersen
2023-10-10 13:09 ` Phillip Susi
2023-10-10 14:04 ` Damien Le Moal
2023-10-15 16:14 ` Phillip Susi
2023-10-15 22:44 ` Damien Le Moal
2023-10-16 12:39 ` Phillip Susi
2023-10-16 12:55 ` Damien Le Moal
2023-10-17 18:03 ` Phillip Susi
2023-10-17 23:32 ` Damien Le Moal
2023-10-20 19:00 ` Phillip Susi
2023-10-18 6:16 ` Damien Le Moal
2023-10-20 21:23 ` Phillip Susi
2023-10-23 5:51 ` Damien Le Moal
2023-10-26 21:21 ` Phillip Susi
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=871qdyh9na.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox