[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <d55400d247e5f00f7c72af2ba442da7b1bed760f.1695415885.git.mschiffer@universe-factory.net>
Date: Fri, 22 Sep 2023 22:55:16 +0200
From: Matthias Schiffer <mschiffer@...verse-factory.net>
To: Damien Le Moal <dlemoal@...nel.org>
Cc: linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
Matthias Schiffer <mschiffer@...verse-factory.net>
Subject: [PATCH] ata: libata: increase PMP SRST timeout to 10s
On certain SATA controllers, softreset fails after wakeup from S2RAM with
the message "softreset failed (1st FIS failed)", sometimes resulting in
drives not being detected again. With the increased timeout, this issue
is avoided. Instead, "softreset failed (device not ready)" is now
logged 1-2 times; this later failure seems to cause fewer problems
however, and the drives are detected reliably once they've spun up and
the probe is retried.
The issue was observed with the primary SATA controller of the QNAP
TS-453B, which is an "Intel Corporation Celeron/Pentium Silver Processor
SATA Controller [8086:31e3] (rev 06)" integrated in the Celeron J4125 CPU,
and the following drives:
- Seagate IronWolf ST12000VN0008
- Seagate IronWolf ST8000NE0004
The SATA controller seems to be more relevant to this issue than the
drives, as the same drives are always detected reliably on the secondary
SATA controller on the same board (an ASMedia 106x) without any "softreset
failed" errors even without the increased timeout.
Fixes: e7d3ef13d52a ("libata: change drive ready wait after hard reset to 5s")
Signed-off-by: Matthias Schiffer <mschiffer@...verse-factory.net>
---
include/linux/libata.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index f217327a779c..7c3e591a5fc9 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -256,7 +256,7 @@ enum {
* advised to wait only for the following duration before
* doing SRST.
*/
- ATA_TMOUT_PMP_SRST_WAIT = 5000,
+ ATA_TMOUT_PMP_SRST_WAIT = 10000,
/* When the LPM policy is set to ATA_LPM_MAX_POWER, there might
* be a spurious PHY event, so ignore the first PHY event that
--
2.42.0
Powered by blists - more mailing lists