From: Damien Le Moal <dlemoal@kernel.org>
To: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Paul Ausbeck <paula@soe.ucsc.edu>,
Thorsten Leemhuis <regressions@leemhuis.info>,
TW <dalzot@gmail.com>,
regressions@lists.linux.dev, Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH] ata,scsi: do not issue START STOP UNIT on resume
Date: Wed, 2 Aug 2023 17:05:05 +0900 [thread overview]
Message-ID: <b7431ae0-e6a1-a9b3-9941-bfe84801b324@kernel.org> (raw)
In-Reply-To: <20230731003956.572414-1-dlemoal@kernel.org>
On 7/31/23 09:39, Damien Le Moal wrote:
> During system resume, ata_port_pm_resume() triggers ata EH to
> 1) Resume the controller
> 2) Reset and rescan the ports
> 3) Revalidate devices
> This EH execution is started asynchronously from ata_port_pm_resume(),
> which means that when sd_resume() is executed, none or only part of the
> above processing may have been executed. However, sd_resume() issues a
> START STOP UNIT to wake up the drive from sleep mode. This command is
> translated to ATA with ata_scsi_start_stop_xlat() and issued to the
> device. However, depending on the state of execution of the EH process
> and revalidation triggerred by ata_port_pm_resume(), two things may
> happen:
> 1) The START STOP UNIT fails if it is received before the controller has
> been reenabled at the beginning of the EH execution. This is visible
> with error messages like:
>
> ata10.00: device reported invalid CHS sector 0
> sd 9:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK
> sd 9:0:0:0: [sdc] Sense Key : Illegal Request [current]
> sd 9:0:0:0: [sdc] Add. Sense: Unaligned write command
> sd 9:0:0:0: PM: dpm_run_callback(): scsi_bus_resume+0x0/0x90 returns -5
> sd 9:0:0:0: PM: failed to resume async: error -5
>
> 2) The START STOP UNIT command is received while the EH process is
> on-going, which mean that it is stopped and must wait for its
> completion, at which point the command is rather useless as the drive
> is already fully spun up already. This case results also in a
> significant delay in sd_resume() which is observable by users as
> the entire system resume completion is delayed.
>
> Given that ATA devices will be woken up by libata activity on resume,
> sd_resume() has no need to issue a START STOP UNIT command, which solves
> the above mentioned problems. Do not issue this command by introducing
> the new scsi_device flag no_start_on_resume and setting this flag to 1
> in ata_scsi_dev_config(). sd_resume() is modified to issue a START STOP
> UNIT command only if this flag is not set.
Martin,
Are you OK with this patch ? Can I get your Acked-by please ?
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-08-02 8:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 0:39 [PATCH] ata,scsi: do not issue START STOP UNIT on resume Damien Le Moal
2023-07-31 3:48 ` TW
2023-07-31 4:44 ` Damien Le Moal
2023-07-31 5:47 ` Tanner Watkins
2023-07-31 16:13 ` Hannes Reinecke
2023-08-01 3:44 ` Damien Le Moal
2023-08-01 6:16 ` Hannes Reinecke
2023-07-31 19:43 ` Paul Ausbeck
2023-08-01 18:36 ` Bart Van Assche
2023-08-02 8:05 ` Damien Le Moal [this message]
2023-08-24 18:28 ` Rodrigo Vivi
2023-08-24 23:42 ` Damien Le Moal
2023-08-25 1:31 ` Martin K. Petersen
2023-08-25 1:33 ` Damien Le Moal
2023-08-25 17:09 ` Rodrigo Vivi
2023-08-25 22:06 ` Damien Le Moal
2023-08-29 6:17 ` Damien Le Moal
2023-08-30 22:14 ` Rodrigo Vivi
2023-08-31 0:32 ` Damien Le Moal
2023-08-31 1:48 ` Vivi, Rodrigo
2023-08-31 3:06 ` Damien Le Moal
2023-09-05 5:20 ` Damien Le Moal
2023-09-05 17:17 ` Rodrigo Vivi
2023-09-06 1:07 ` Damien Le Moal
2023-08-31 6:55 ` Damien Le Moal
2023-08-25 12:19 ` Damien Le Moal
2023-09-12 17:39 ` Geert Uytterhoeven
2023-09-12 22:58 ` Damien Le Moal
2023-09-13 10:21 ` Geert Uytterhoeven
2023-09-13 10:34 ` Geert Uytterhoeven
2023-09-13 22:07 ` Damien Le Moal
2023-09-14 6:59 ` Geert Uytterhoeven
2023-09-13 22:03 ` Damien Le Moal
2023-09-14 6:53 ` Geert Uytterhoeven
2023-09-14 6:58 ` Damien Le Moal
2023-09-14 15:29 ` 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=b7431ae0-e6a1-a9b3-9941-bfe84801b324@kernel.org \
--to=dlemoal@kernel.org \
--cc=bvanassche@acm.org \
--cc=dalzot@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=paula@soe.ucsc.edu \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
/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