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: Thu, 12 Oct 2023 15:01:53 -0400 [thread overview]
Message-ID: <87edhz3bry.fsf@vps.thesusis.net> (raw)
In-Reply-To: <c0b086ab-dcd5-4b7b-b931-4d407dd7ad47()kernel!org>
Damien Le Moal <dlemoal () kernel ! org> writes:
> In theory, yes, that was the intent. In practice, the verify was issued from
> scsi PM resume context while the actual drive port reset + revalidation is done
> in libata EH context, triggered from ATA port resume context which itself was
> not synchronized/ordered with the scsi disk resume. So we ended up with the
> verify command execution sometimes being attempted with the drive not even
> revalidated yet, or with the port/link not even active sometimes (depending on
> timing). So problems all over and deadlocks due to scsi revalidate using the
> device lock, which PM use too.
Yikes.
> See above. With the switch to async PM ops in scsi in kernel 5.16, things broke
> badly due to the lack of synchronization that sync PM provided before that.
Yes, but without async PM ops, the IDENTIFY command that was not
preceeded by a VERIFY worked just fine, right?
> ACS defines that only media access commands can get a drive out of standby mode
> back into active mode. So an IDENTIFY command would not (normally)
> spinup a
Right, it won't CAUSE the drive to spin up, but if it is already in the
process of spinning up ( due to the reset ), then the drive will finish
spinning up before answering the IDENTIFY command. Or do you think that
some drives may handle the IDENTIFY wrong if they are still in the
process of spinning up?
next parent reply other threads:[~2023-10-12 19:01 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 ` Phillip Susi [this message]
2023-10-13 0:57 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Damien Le Moal
2023-10-13 14:36 ` Phillip Susi
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=87edhz3bry.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).