The branch main has been updated by imp:
URL:
https://cgit.FreeBSD.org/src/commit/?id=d78d04b17cb2498186e8fd2681f224a760e75b28
commit d78d04b17cb2498186e8fd2681f224a760e75b28
Author: Warner Losh <i...@freebsd.org>
AuthorDate: 2025-07-10 15:56:26 +0000
Commit: Warner Losh <i...@freebsd.org>
CommitDate: 2025-07-10 16:17:01 +0000
cam: Fail the disk if READ CAPACITY returns 4/2 asc/ascq
HGST disks that are sick are returning 44/0 for START UNIT (which we
ignore) and then 4/2 on READ CAPACITY. START UNIT should be enough for
READ CAPACITY to succeed or UNIT ATTENTION. However, we get NOT_READ +
4/2 back. I've seen this on several models of HGST drives. Invalidate
the peripheral when we detect this condition. This is likely the least
bad thing we can do: It removes access to daX, but leaves passY so logs
may be extracted (if awkwardly). Removing daX access removes the disk
device that causes problems to geom outlined below.
Although the timeout is 5s for READ_CAPACITY, we wait the full 30s for
READ_CAPACITY_16. This causes us to stall booting as we start to taste
as soon as we release the final hold... but the tasting means
g_wait_idle() takes now takes over 5 minutes to clear since we do this
for all the opens. Even using a timeout of 3s instead of 30s leads to
boot times of almost 5 minutes in these cases, so there are other,
downstream operations that are taking a while, so it's not just a matter
of adjusting the timeout. Failing the periph early solves the bulk of
this problem (the tasting related delays). What the HBA does is HBA
specific and some have firmwares that are also confused by this when
they enumerate or discover the drive, leading to long (but still shorter
than 5 minute) delays. This patch won't solve that aspect of startup
delays with sick disks.
Perhaps we should fail the periph when START UNIT fails with the same
codes we check in the read capacity path. I'm reluctant to do such a
global change since it's in cam_periph, and there seems no good way to
flag that we want this behavior. It's also a bit magical when it runs
(some drive report 44/0 always, and some just report it on START UNIT,
and these HGST drive fall into the latter category).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D51218
---
sys/cam/scsi/scsi_da.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c
index 9eda664ee7b0..d02750aaacaf 100644
--- a/sys/cam/scsi/scsi_da.c
+++ b/sys/cam/scsi/scsi_da.c
@@ -5073,6 +5073,18 @@ dadone_proberc(struct cam_periph *periph, union ccb
*done_ccb)
* behind a SATL translation that's fallen into a
* terminally fatal state.
*
+ * 4/2 happens on some HGST drives that are quite
+ * ill. We've already sent the start unit command (for
+ * which we ignore a 44/0 asc/ascq, which I'm hesitant
+ * to change since it's so basic and there's other error
+ * conditions to the START UNIT we should ignore). So to
+ * require initialization at this point when it should
+ * be fine implies to me, at least, that we should
+ * invalidate. Since we do read capacity in geom tasting
+ * a lot, and since this timeout is long, this leads to
+ * up to a 10 minute delay in booting.
+ *
+ * 4/2: LOGICAL UNIT NOT READY, INITIALIZING COMMAND
REQUIRED
* 25/0: LOGICAL UNIT NOT SUPPORTED
* 44/0: INTERNAL TARGET FAILURE
* 44/1: PERSISTENT RESERVATION INFORMATION LOST
@@ -5080,6 +5092,7 @@ dadone_proberc(struct cam_periph *periph, union ccb
*done_ccb)
*/
if ((have_sense)
&& (asc != 0x25) && (asc != 0x44)
+ && (asc != 0x04 && ascq != 0x02)
&& (error_code == SSD_CURRENT_ERROR
|| error_code == SSD_DESC_CURRENT_ERROR)) {
const char *sense_key_desc;
