git: d78d04b17cb2 - main - cam: Fail the disk if READ CAPACITY returns 4/2 asc/ascq

The branch main has been updated by imp:

URL: https://cgit.FreeBSD.org/src/commit/?id=d78d04b17cb2498186e8fd2681f224a760e75b28

commit d78d04b17cb2498186e8fd2681f224a760e75b28
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2025-07-10 15:56:26 +0000
Commit:     Warner Losh <imp@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;