summaryrefslogtreecommitdiff
path: root/scripts/dummy-tools/python3
diff options
context:
space:
mode:
authorVincent YUE <vince@palmit.com.au>2026-10-21 07:08:56 +1000
committerMartin K. Petersen (Oracle) <mkp@kernel.org>2026-10-30 20:56:13 -0400
commitd58e6d962e5b59297be24d908f41af93f20ec11f (patch)
tree58d2bfd907367c892c13d93f1529f2b0fa241846 /scripts/dummy-tools/python3
parent503e6172fa74da6b4944ece458f5534681e51d21 (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