diff options
| author | Vincent YUE <vince@palmit.com.au> | 2026-10-21 07:08:56 +1000 |
|---|---|---|
| committer | Martin K. Petersen (Oracle) <mkp@kernel.org> | 2026-10-30 20:56:13 -0400 |
| commit | d58e6d962e5b59297be24d908f41af93f20ec11f (patch) | |
| tree | 58d2bfd907367c892c13d93f1529f2b0fa241846 /scripts/dummy-tools/python3 | |
| parent | 503e6172fa74da6b4944ece458f5534681e51d21 (diff) | |
scsi: mpt3sas: Register devices during SANITIZE
A SAS disk being sanitized responds to TEST UNIT READY with NOT READY, ASC
0x04, ASCQ 0x1b. mpt3sas discovery maps this sense to DEVICE_START_UNIT and
issues START UNIT repeatedly. The drive stays NOT READY until the sanitize
operation completes, causing discovery to exhaust its retry budget and
decline SCSI device registration.
Allow registration only for the SANITIZE IN PROGRESS sense, so sd/sg can
expose the target while retaining its actual NOT READY state. All other
sense dispositions are unchanged.
On an LSI SAS3008 with an HGST HUH728080AL4200, unpatched Linux 7.2.11
retried discovery 145 times without registering the device. Linux 6.18.55
registered the same sanitizing drive. With the equivalent 7.2.11 fix the
disk registered as /dev/sda (0 B) and /dev/sg0 while TEST UNIT READY still
reported 02/04/1b and 47.32% SANITIZE progress. Another SAS drive continued
to enumerate.
This updated variant uses the named 0x041b sense constant introduced in
newer kernels. It passed static review on the current SCSI for-next branch
but has not been independently boot-tested there.
Fixes: aee682fad6cd ("scsi: mpt3sas: Improve device discovery and readiness handling for slow devices")
Assisted-by: LLM
Signed-off-by: Vincent YUE <vince@palmit.com.au>
Link: https://patch.msgid.link/20261020210856.42835-1-vince@palmit.com.au
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Diffstat (limited to 'scripts/dummy-tools/python3')
0 files changed, 0 insertions, 0 deletions
