Hi Martin,
> That's very interesting. I received a couple of reports about USB
> devices from other vendors that had a similar problems with WP but I
> always assumed it to be a timing issue.
Your remark got me thinking that since you have gotten more reports
about this issue and it's not a one off, then perhaps I should dig
further to figure out a better solution, instead of simply adding an
UNUSUAL_DEVICE entry (just to get this specific device working since
it's been broken for more than a year).
First, I added a 5 second sleep right at the top of sd_do_mode_sense(),
just to verify that a delay isn't needed after the first SCSI command
has been issued. The device still reported write protect, so that
confirms it is not a timing issue.
Then, I proceeded to call scsi_mode_sense() multiple times inside
sd_do_mode_sense(), one right after the other, and to my surprise that
also did not clear WP.
I then called sd_revalidate_disk() multiple times and noticed that WP
was cleared only after the call to device_add_disk(). That led me to
figure out that this device needs a READ_10 command before WP is
disabled.
The following is enough to get the device to show up without WP:
--- /tmp/linux-6.6.5/drivers/scsi/sd.c 2023-12-08 09:52:25.000000000 +0200
+++ src/linux-6.6.5/drivers/scsi/sd.c 2023-12-11 03:23:22.109604623 +0200
@@ -2772,6 +2772,11 @@
}
if (sdp->use_192_bytes_for_3f) {
+ unsigned char cmd[10] = {READ_10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00};
+ unsigned char readbuf[512];
+ scsi_execute_cmd(sdkp->device, cmd, REQ_OP_DRV_IN, readbuf, sizeof(readbuf),
+ SD_TIMEOUT, sdkp->max_retries, NULL);
+
res = sd_do_mode_sense(sdkp, 0, 0x3F, buffer, 192, &data, NULL);
} else {
/*
which results in:
[ 56.050090] sd 10:0:0:0: [sdb] 61472768 512-byte logical blocks: (31.5 GB/29.3 GiB)
[ 56.062517] *** thread awakened
[ 56.062532] Command READ_10 (10 bytes)
[ 56.062543] bytes: 28 00 00 00 00 00 00 00 01 00
[ 56.062555] Bulk Command S 0x43425355 T 0x5 L 512 F 128 Trg 0 LUN 0 CL 10
[ 56.062570] xfer 31 bytes
[ 56.063137] Status code 0; transferred 31/31
[ 56.063152] -- transfer complete
[ 56.063159] Bulk command transfer result=0
[ 56.063168] xfer 512 bytes, 1 entries
[ 56.188566] Status code 0; transferred 512/512
[ 56.188586] -- transfer complete
[ 56.188594] Bulk data transfer result 0x0
[ 56.188602] Attempting to get CSW...
[ 56.188609] xfer 13 bytes
[ 56.190112] Status code 0; transferred 13/13
[ 56.190120] -- transfer complete
[ 56.190123] Bulk status result = 0
[ 56.190126] Bulk Status S 0x53425355 T 0x5 R 0 Stat 0x0
[ 56.190132] scsi cmd done, result=0x0
[ 56.190158] *** thread sleeping
[ 56.190245] *** thread awakened
[ 56.190255] Command MODE_SENSE (6 bytes)
[ 56.190265] bytes: 1a 00 3f 00 c0 00
[ 56.190276] Bulk Command S 0x43425355 T 0x6 L 192 F 128 Trg 0 LUN 0 CL 6
[ 56.190291] xfer 31 bytes
[ 56.190733] Status code 0; transferred 31/31
[ 56.190745] -- transfer complete
[ 56.190752] Bulk command transfer result=0
[ 56.190761] xfer 192 bytes, 1 entries
[ 56.191741] Status code -121; transferred 44/192
[ 56.191748] -- short read transfer
[ 56.191750] Bulk data transfer result 0x1
[ 56.191753] Attempting to get CSW...
[ 56.191756] xfer 13 bytes
[ 56.192072] Status code 0; transferred 13/13
[ 56.192077] -- transfer complete
[ 56.192079] Bulk status result = 0
[ 56.192082] Bulk Status S 0x53425355 T 0x6 R 148 Stat 0x0
[ 56.192087] scsi cmd done, result=0x0
[ 56.192111] *** thread sleeping
[ 56.192207] sd 10:0:0:0: [sdb] Write Protect is off
[ 56.197229] sd 10:0:0:0: [sdb] Mode Sense: 2b 00 00 08
It is worth noting that Windows 10 (2004) also performs this sequence:
- READ_CAPACITY (10)
- READ_10 (10) LBA: 0, Len: 1
- MODE_SENSE (6) page: 0x3f
I'm not sure how to proceed from here. Since there are other devices
affected, I am not sure this patch with the quirk should be applied. At
the very least though, I'd need to submit a V2 to correct the commit
message and comment.
On the other hand, I'm worried that by adding a READ_10 before every
mode sense, something else might break. If you do believe that adding a
READ_10 is the right way forward, I can try cleaning up the diff above
(with some advice) and submit it properly. Any suggestions are welcome.
--
Tasos
