* [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
@ 2025-02-24 3:48 WangYuli
2025-02-24 18:11 ` Bart Van Assche
0 siblings, 1 reply; 8+ messages in thread
From: WangYuli @ 2025-02-24 3:48 UTC (permalink / raw)
To: James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, stern, bvanassche, zhanjun, niecheng1,
guanwentao, chenlinxuan, WangYuli, Xinwei Zhou, Xu Rao,
Yujing Ming
On some external USB hard drives, mounting can fail if "lshw" is
executed during the process.
This occurs because data sent to the device's output endpoint in
certain abnormal scenarios does not receive a response, leading to
a mount timeout.
[ Description of "use_192_bytes_for_3f" in the kernel code: ]
/*
* Many disks only accept MODE SENSE transfer lengths of
* 192 bytes (that's what Windows uses).
*/
sdev->use_192_bytes_for_3f = 1;
The kernel's SCSI driver, when handling devices with this attribute,
sends commands with a length of 192 bytes like this:
if (sdp->use_192_bytes_for_3f)
res = sd_do_mode_sense(sdp, 0, 0x3F, buffer, 192, &data, NULL);
However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
transmits data with a length of 0xff bytes via ioctl, which can cause
some hard drives to hang and become unusable.
To resolve this issue, prevent commands with a length of 0xff bytes
from being queued via ioctl when it detects the "use_192_bytes_for_3f"
attribute on the device.
The hard drive device identified with the issue is Lenovo USB 17ef:4531.
Tested on HONOR NBLK-WAX9X (C234) Notebook with AMD Ryzen 7 3700U.
[ Kernel logs: ]
2024-10-31 13:36:11 localhost kernel: [ 25.770091] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:36:11 localhost kernel: [ 25.798558] usb 2-2: New USB device found, idVendor=17ef, idProduct=4531, bcdDevice= 5.12
2024-10-31 13:36:11 localhost kernel: [ 25.798562] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2024-10-31 13:36:11 localhost kernel: [ 25.798564] usb 2-2: Product: Lenovo Portable HDD
2024-10-31 13:36:11 localhost kernel: [ 25.798566] usb 2-2: Manufacturer: Lenovo
2024-10-31 13:36:11 localhost kernel: [ 25.798567] usb 2-2: SerialNumber: 000000001E4C
2024-10-31 13:36:11 localhost kernel: [ 25.820244] usb-storage 2-2:1.0: USB Mass Storage device detected
2024-10-31 13:36:11 localhost kernel: [ 25.820457] scsi host0: usb-storage 2-2:1.0
2024-10-31 13:36:11 localhost kernel: [ 25.820633] usbcore: registered new interface driver usb-storage
2024-10-31 13:36:11 localhost kernel: [ 25.825598] usbcore: registered new interface driver uas
2024-10-31 13:36:14 localhost kernel: [ 28.852179] scsi 0:0:0:0: Direct-Access Lenovo USB Hard Drive 0006 PQ: 0 ANSI: 2
2024-10-31 13:36:14 localhost kernel: [ 28.852961] sd 0:0:0:0: Attached scsi generic sg0 type 0
2024-10-31 13:36:14 localhost kernel: [ 28.891218] sd 0:0:0:0: [sda] 976773164 512-byte logical blocks: (500 GB/466 GiB)
2024-10-31 13:36:14 localhost kernel: [ 28.906892] sd 0:0:0:0: [sda] Write Protect is off
2024-10-31 13:36:14 localhost kernel: [ 28.906896] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
2024-10-31 13:36:14 localhost kernel: [ 28.922606] sd 0:0:0:0: [sda] No Caching mode page found
2024-10-31 13:36:14 localhost kernel: [ 28.922612] sd 0:0:0:0: [sda] Assuming drive cache: write through
2024-10-31 13:36:14 localhost kernel: [ 29.007816] sda: sda1
2024-10-31 13:36:15 localhost kernel: [ 30.180380] sd 0:0:0:0: [sda] Attached SCSI disk
2024-10-31 13:36:16 localhost kernel: [ 30.722863] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
2024-10-31 13:36:16 localhost kernel: [ 30.734139] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
2024-10-31 13:36:17 localhost kernel: [ 31.396011] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:36:18 localhost kernel: [ 32.933537] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3
2024-10-31 13:36:18 localhost kernel: [ 32.933541] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2
2024-10-31 13:36:39 localhost kernel: [ 54.242220] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:36:50 localhost kernel: [ 64.408879] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:37:11 localhost kernel: [ 85.466479] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:37:11 localhost kernel: [ 85.490248] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
2024-10-31 13:37:11 localhost kernel: [ 85.490255] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 20 00 00 08 00
2024-10-31 13:37:11 localhost kernel: [ 85.490258] print_req_error: I/O error, dev sda, sector 32
2024-10-31 13:37:33 localhost kernel: [ 107.432186] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:37:41 localhost kernel: [ 116.194201] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:37:49 localhost kernel: [ 123.555484] dolphin[7271]: segfault at 10 ip 00007fcccc0d7f76 sp 00007ffe8004b860 error 4 in libKF5CoreAddons.so.5.102.0[7fcccc0a5000+83000]
2024-10-31 13:37:49 localhost kernel: [ 123.555502] Code: d6 90 66 90 41 54 41 89 d4 55 48 89 fd 53 48 89 f3 e8 8e 94 01 00 ba 04 00 00 00 48 89 de 48 89 c7 e8 4e 8f 01 00 84 c0 75 2a <48> 8b 7d 10 48 85 ff 74 21 45 89 e1 48 89 da 48 89 ee 5b 41 b8 01
2024-10-31 13:38:11 localhost kernel: [ 146.229510] usb 2-2: USB disconnect, device number 2
2024-10-31 13:38:11 localhost kernel: [ 146.237993] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238003] print_req_error: I/O error, dev sda, sector 32
2024-10-31 13:38:11 localhost kernel: [ 146.238009] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238029] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238030] print_req_error: I/O error, dev sda, sector 36
2024-10-31 13:38:11 localhost kernel: [ 146.238032] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238045] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238047] print_req_error: I/O error, dev sda, sector 6291480
2024-10-31 13:38:11 localhost kernel: [ 146.238062] Buffer I/O error on dev sda1, logical block 786431, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238168] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238170] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238175] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238176] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238184] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238185] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238199] Buffer I/O error on dev sda, logical block 40, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238201] Buffer I/O error on dev sda, logical block 41, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238205] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238206] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238210] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238211] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238215] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238217] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238220] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238221] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238224] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238226] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:12 localhost kernel: [ 146.482007] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
2024-10-31 13:38:12 localhost kernel: [ 146.494064] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
2024-10-31 13:38:15 localhost kernel: [ 150.065848] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3
2024-10-31 13:38:15 localhost kernel: [ 150.065852] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2
2024-10-31 13:38:26 localhost kernel: [ 160.433037] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:39:29 localhost kernel: [ 223.444589] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
Link: https://linux-hardware.org/?id=usb:17ef-4531
Link: https://lore.kernel.org/all/80ef917b-3680-4f85-93ba-c92d2b69ebaa@rowland.harvard.edu/
Link: https://lore.kernel.org/all/ad4bd008-8d0d-439b-879c-e9cf4c89ec56@acm.org/
Reported-by: Xinwei Zhou <zhouxinwei@uniontech.com>
Co-developed-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Tested-by: Yujing Ming <mingyujing@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
Changelog:
*v1->v2: Move the bugfix to the SCSI layer.
v2->v3: Optimize code style and comment readability.
---
drivers/scsi/scsi_lib.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index be0890e4e706..29371826fc85 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1565,6 +1565,7 @@ static void scsi_complete(struct request *rq)
static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
{
struct Scsi_Host *host = cmd->device->host;
+ struct scsi_device *sdev = cmd->device;
int rtn = 0;
atomic_inc(&cmd->device->iorequest_cnt);
@@ -1613,6 +1614,17 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
goto done;
}
+ /*
+ * Before we queue this command, check attribute use_192_bytes_for_3f.
+ * Because transmits data with a length of 0xff bytes via ioctl may
+ * cause some hard drives to hang and become unusable.
+ */
+ if (cmd->cmnd[0] == MODE_SENSE && sdev->use_192_bytes_for_3f &&
+ cmd->cmnd[2] == 0x3f && cmd->cmnd[4] != 192) {
+ cmd->result = DID_ABORT << 16;
+ goto done;
+ }
+
if (unlikely(host->shost_state == SHOST_DEL)) {
cmd->result = (DID_NO_CONNECT << 16);
goto done;
--
2.47.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-02-24 3:48 WangYuli
@ 2025-02-24 18:11 ` Bart Van Assche
2025-02-25 13:11 ` WangYuli
0 siblings, 1 reply; 8+ messages in thread
From: Bart Van Assche @ 2025-02-24 18:11 UTC (permalink / raw)
To: WangYuli, James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, stern, zhanjun, niecheng1, guanwentao,
chenlinxuan, Xinwei Zhou, Xu Rao, Yujing Ming
On 2/23/25 7:48 PM, WangYuli wrote:
> However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
> transmits data with a length of 0xff bytes via ioctl, which can cause
> some hard drives to hang and become unusable.
lshw is a user space utility. use_192_bytes_for_3f is not exposed to
user space as far as I know. So how can the above statement be correct?
> @@ -1613,6 +1614,17 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
> + /*
> + * Before we queue this command, check attribute use_192_bytes_for_3f.
> + * Because transmits data with a length of 0xff bytes via ioctl may
> + * cause some hard drives to hang and become unusable.
> + */
> + if (cmd->cmnd[0] == MODE_SENSE && sdev->use_192_bytes_for_3f &&
> + cmd->cmnd[2] == 0x3f && cmd->cmnd[4] != 192) {
> + cmd->result = DID_ABORT << 16;
> + goto done;
> + }
From include/scsi/scsi_device.h:
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
The above code uses use_192_bytes_for_3f for another purpose. Please
respect the purpose of the use_192_bytes_for_3f bitfield.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-02-24 18:11 ` Bart Van Assche
@ 2025-02-25 13:11 ` WangYuli
2025-02-25 20:54 ` Bart Van Assche
0 siblings, 1 reply; 8+ messages in thread
From: WangYuli @ 2025-02-25 13:11 UTC (permalink / raw)
To: Bart Van Assche, James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, stern, zhanjun, niecheng1, guanwentao,
chenlinxuan, Xinwei Zhou, Xu Rao, Yujing Ming
[-- Attachment #1.1.1: Type: text/plain, Size: 1262 bytes --]
Hi Bart Van Assche,
On 2025/2/25 02:11, Bart Van Assche wrote:
> lshw is a user space utility. use_192_bytes_for_3f is not exposed to
> user space as far as I know. So how can the above statement be correct?
>
Disks have the attribute use_192_bytes_for_3f, which means that disks only accept MODE SENSE transfer lengths of 192 bytes
However, when lshw sends MODE SENSE command to disks, use_192_bytes_for_3f will not be considered, which will cause some disks with use_192_bytes_for_3f to be unusable
To solve this problem, it is necessary to determine whether the device has the use_192_bytes_for_3f attribute at the scsi level. If the device has use_192_bytes_for_3f, when lshw or other applications send MODE SENSE command through ioctl, the command with the data length field of 0xff needs to be filtered out to avoid device abnormality.
>
> From include/scsi/scsi_device.h:
>
> unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
>
> The above code uses use_192_bytes_for_3f for another purpose. Please
> respect the purpose of the use_192_bytes_for_3f bitfield.
>
> Thanks,
>
> Bart.
>
>
Thanks,
--
WangYuli
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-02-25 13:11 ` WangYuli
@ 2025-02-25 20:54 ` Bart Van Assche
2025-02-26 2:31 ` WangYuli
0 siblings, 1 reply; 8+ messages in thread
From: Bart Van Assche @ 2025-02-25 20:54 UTC (permalink / raw)
To: WangYuli, James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, stern, zhanjun, niecheng1, guanwentao,
chenlinxuan, Xinwei Zhou, Xu Rao, Yujing Ming
On 2/25/25 5:11 AM, WangYuli wrote:
> Disks have the attribute use_192_bytes_for_3f, which means that disks
> only accept MODE SENSE transfer lengths of 192 bytes>
> However, when lshw sends MODE SENSE command to disks,
> use_192_bytes_for_3f will not be considered, which will cause some
> disks with use_192_bytes_for_3f to be unusable
>
> To solve this problem, it is necessary to determine whether the
> device has the use_192_bytes_for_3f attribute at the scsi level. If
> the device has use_192_bytes_for_3f, when lshw or other applications
> send MODE SENSE command through ioctl, the command with the data
> length field of 0xff needs to be filtered out to avoid device
> abnormality.
Has it been considered to truncate the MODE SENSE buffer to 192 bytes
instead of rejecting the MODE SENSE command?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-02-25 20:54 ` Bart Van Assche
@ 2025-02-26 2:31 ` WangYuli
0 siblings, 0 replies; 8+ messages in thread
From: WangYuli @ 2025-02-26 2:31 UTC (permalink / raw)
To: Bart Van Assche, James.Bottomley, martin.petersen, Alan Stern
Cc: linux-scsi, linux-kernel, stern, zhanjun, niecheng1, guanwentao,
chenlinxuan, Xinwei Zhou, Xu Rao, Yujing Ming
[-- Attachment #1.1.1: Type: text/plain, Size: 1314 bytes --]
Hi Bart,
On 2025/2/26 04:54, Bart Van Assche wrote:
>
> Has it been considered to truncate the MODE SENSE buffer to 192 bytes
> instead of rejecting the MODE SENSE command?
>
>
Alan Stern has raised a related issue before. My take on this is
outlined below.
I personally think that it is not appropriate to modify it directly
to 192. After all, it is called by the user through ioctl, and the
kernel itself will not construct such a data frame. As shown in the
following code:
sd_read_write_protect_flag(struct scsi_disk *sdkp, unsigned char *buffer)
{
int res;
struct scsi_device *sdp = sdkp->device;
struct scsi_mode_data data;
int old_wp = sdkp->write_prot;
set_disk_ro(sdkp->disk, 0);
if (sdp->skip_ms_page_3f) {
sd_first_printk(KERN_NOTICE, sdkp, "Assuming Write Enabled\n");
return;
}
if (sdp->use_192_bytes_for_3f) {
res = sd_do_mode_sense(sdp, 0, 0x3F, buffer, 192, &data, NULL);
Link:
https://lore.kernel.org/all/137902FEE03CCB3B+6130227f-9ddc-4043-9945-da465c28d9d1@uniontech.com/
--
WangYuli
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
@ 2025-03-18 6:11 WangYuli
2025-03-21 1:08 ` Martin K. Petersen
0 siblings, 1 reply; 8+ messages in thread
From: WangYuli @ 2025-03-18 6:11 UTC (permalink / raw)
To: James.Bottomley, martin.petersen
Cc: linux-scsi, linux-kernel, stern, bvanassche, zhanjun, niecheng1,
guanwentao, WangYuli, Xinwei Zhou, Xu Rao, Yujing Ming
On some external USB hard drives, mounting can fail if "lshw" is
executed during the process.
This occurs because data sent to the device's output endpoint in
certain abnormal scenarios does not receive a response, leading to
a mount timeout.
[ Description of "use_192_bytes_for_3f" in the kernel code: ]
/*
* Many disks only accept MODE SENSE transfer lengths of
* 192 bytes (that's what Windows uses).
*/
sdev->use_192_bytes_for_3f = 1;
The kernel's SCSI driver, when handling devices with this attribute,
sends commands with a length of 192 bytes like this:
if (sdp->use_192_bytes_for_3f)
res = sd_do_mode_sense(sdp, 0, 0x3F, buffer, 192, &data, NULL);
However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
transmits data with a length of 0xff bytes via ioctl, which can cause
some hard drives to hang and become unusable.
To resolve this issue, prevent commands with a length of 0xff bytes
from being queued via ioctl when it detects the "use_192_bytes_for_3f"
attribute on the device.
The hard drive device identified with the issue is Lenovo USB 17ef:4531.
Tested on HONOR NBLK-WAX9X (C234) Notebook with AMD Ryzen 7 3700U.
[ Kernel logs: ]
2024-10-31 13:36:11 localhost kernel: [ 25.770091] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:36:11 localhost kernel: [ 25.798558] usb 2-2: New USB device found, idVendor=17ef, idProduct=4531, bcdDevice= 5.12
2024-10-31 13:36:11 localhost kernel: [ 25.798562] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2024-10-31 13:36:11 localhost kernel: [ 25.798564] usb 2-2: Product: Lenovo Portable HDD
2024-10-31 13:36:11 localhost kernel: [ 25.798566] usb 2-2: Manufacturer: Lenovo
2024-10-31 13:36:11 localhost kernel: [ 25.798567] usb 2-2: SerialNumber: 000000001E4C
2024-10-31 13:36:11 localhost kernel: [ 25.820244] usb-storage 2-2:1.0: USB Mass Storage device detected
2024-10-31 13:36:11 localhost kernel: [ 25.820457] scsi host0: usb-storage 2-2:1.0
2024-10-31 13:36:11 localhost kernel: [ 25.820633] usbcore: registered new interface driver usb-storage
2024-10-31 13:36:11 localhost kernel: [ 25.825598] usbcore: registered new interface driver uas
2024-10-31 13:36:14 localhost kernel: [ 28.852179] scsi 0:0:0:0: Direct-Access Lenovo USB Hard Drive 0006 PQ: 0 ANSI: 2
2024-10-31 13:36:14 localhost kernel: [ 28.852961] sd 0:0:0:0: Attached scsi generic sg0 type 0
2024-10-31 13:36:14 localhost kernel: [ 28.891218] sd 0:0:0:0: [sda] 976773164 512-byte logical blocks: (500 GB/466 GiB)
2024-10-31 13:36:14 localhost kernel: [ 28.906892] sd 0:0:0:0: [sda] Write Protect is off
2024-10-31 13:36:14 localhost kernel: [ 28.906896] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
2024-10-31 13:36:14 localhost kernel: [ 28.922606] sd 0:0:0:0: [sda] No Caching mode page found
2024-10-31 13:36:14 localhost kernel: [ 28.922612] sd 0:0:0:0: [sda] Assuming drive cache: write through
2024-10-31 13:36:14 localhost kernel: [ 29.007816] sda: sda1
2024-10-31 13:36:15 localhost kernel: [ 30.180380] sd 0:0:0:0: [sda] Attached SCSI disk
2024-10-31 13:36:16 localhost kernel: [ 30.722863] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
2024-10-31 13:36:16 localhost kernel: [ 30.734139] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
2024-10-31 13:36:17 localhost kernel: [ 31.396011] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:36:18 localhost kernel: [ 32.933537] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3
2024-10-31 13:36:18 localhost kernel: [ 32.933541] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2
2024-10-31 13:36:39 localhost kernel: [ 54.242220] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:36:50 localhost kernel: [ 64.408879] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:37:11 localhost kernel: [ 85.466479] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:37:11 localhost kernel: [ 85.490248] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
2024-10-31 13:37:11 localhost kernel: [ 85.490255] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 20 00 00 08 00
2024-10-31 13:37:11 localhost kernel: [ 85.490258] print_req_error: I/O error, dev sda, sector 32
2024-10-31 13:37:33 localhost kernel: [ 107.432186] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:37:41 localhost kernel: [ 116.194201] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
2024-10-31 13:37:49 localhost kernel: [ 123.555484] dolphin[7271]: segfault at 10 ip 00007fcccc0d7f76 sp 00007ffe8004b860 error 4 in libKF5CoreAddons.so.5.102.0[7fcccc0a5000+83000]
2024-10-31 13:37:49 localhost kernel: [ 123.555502] Code: d6 90 66 90 41 54 41 89 d4 55 48 89 fd 53 48 89 f3 e8 8e 94 01 00 ba 04 00 00 00 48 89 de 48 89 c7 e8 4e 8f 01 00 84 c0 75 2a <48> 8b 7d 10 48 85 ff 74 21 45 89 e1 48 89 da 48 89 ee 5b 41 b8 01
2024-10-31 13:38:11 localhost kernel: [ 146.229510] usb 2-2: USB disconnect, device number 2
2024-10-31 13:38:11 localhost kernel: [ 146.237993] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238003] print_req_error: I/O error, dev sda, sector 32
2024-10-31 13:38:11 localhost kernel: [ 146.238009] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238029] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238030] print_req_error: I/O error, dev sda, sector 36
2024-10-31 13:38:11 localhost kernel: [ 146.238032] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238045] scsi 0:0:0:0: rejecting I/O to dead device
2024-10-31 13:38:11 localhost kernel: [ 146.238047] print_req_error: I/O error, dev sda, sector 6291480
2024-10-31 13:38:11 localhost kernel: [ 146.238062] Buffer I/O error on dev sda1, logical block 786431, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238168] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238170] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238175] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238176] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238184] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238185] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238199] Buffer I/O error on dev sda, logical block 40, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238201] Buffer I/O error on dev sda, logical block 41, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238205] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238206] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238210] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238211] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238215] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238217] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238220] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238221] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238224] Buffer I/O error on dev sda, logical block 8, async page read
2024-10-31 13:38:11 localhost kernel: [ 146.238226] Buffer I/O error on dev sda, logical block 9, async page read
2024-10-31 13:38:12 localhost kernel: [ 146.482007] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x4011
2024-10-31 13:38:12 localhost kernel: [ 146.494064] snd_hda_codec_realtek hdaudioC1D0: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
2024-10-31 13:38:15 localhost kernel: [ 150.065848] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x3
2024-10-31 13:38:15 localhost kernel: [ 150.065852] snd_hda_codec_realtek hdaudioC1D0: hda_codec_cleanup_stream: NID=0x2
2024-10-31 13:38:26 localhost kernel: [ 160.433037] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
2024-10-31 13:39:29 localhost kernel: [ 223.444589] start_addr=(0x20000), end_addr=(0x40000), buffer_size=(0x20000), smp_number_max=(16384)
Link: https://linux-hardware.org/?id=usb:17ef-4531
Link: https://lore.kernel.org/all/80ef917b-3680-4f85-93ba-c92d2b69ebaa@rowland.harvard.edu/
Link: https://lore.kernel.org/all/ad4bd008-8d0d-439b-879c-e9cf4c89ec56@acm.org/
Link: https://lore.kernel.org/all/4EB8ECD64F601331+e2f01a1f-8da5-4e7b-b909-d920a792756a@uniontech.com/
Reported-by: Xinwei Zhou <zhouxinwei@uniontech.com>
Co-developed-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Tested-by: Yujing Ming <mingyujing@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
drivers/scsi/scsi_lib.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f1cfe0bb89b2..96f3418c0cdd 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1565,6 +1565,7 @@ static void scsi_complete(struct request *rq)
static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
{
struct Scsi_Host *host = cmd->device->host;
+ struct scsi_device *sdev = cmd->device;
int rtn = 0;
atomic_inc(&cmd->device->iorequest_cnt);
@@ -1613,6 +1614,17 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
goto done;
}
+ /*
+ * Before we queue this command, check attribute use_192_bytes_for_3f.
+ * Because transmits data with a length of 0xff bytes via ioctl may
+ * cause some hard drives to hang and become unusable.
+ */
+ if (cmd->cmnd[0] == MODE_SENSE && sdev->use_192_bytes_for_3f &&
+ cmd->cmnd[2] == 0x3f && cmd->cmnd[4] != 192) {
+ cmd->result = DID_ABORT << 16;
+ goto done;
+ }
+
if (unlikely(host->shost_state == SHOST_DEL)) {
cmd->result = (DID_NO_CONNECT << 16);
goto done;
--
2.49.0
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-03-18 6:11 [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute WangYuli
@ 2025-03-21 1:08 ` Martin K. Petersen
2025-03-26 16:51 ` WangYuli
0 siblings, 1 reply; 8+ messages in thread
From: Martin K. Petersen @ 2025-03-21 1:08 UTC (permalink / raw)
To: WangYuli
Cc: James.Bottomley, martin.petersen, linux-scsi, linux-kernel, stern,
bvanassche, zhanjun, niecheng1, guanwentao, Xinwei Zhou, Xu Rao,
Yujing Ming
> However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
> transmits data with a length of 0xff bytes via ioctl, which can cause
> some hard drives to hang and become unusable.
I am really not a fan of using in-kernel workarounds to intercept
passthrough commands.
Why does does lshw perform a MODE SENSE in the first place? What
information is it looking for that isn't available in sysfs?
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute
2025-03-21 1:08 ` Martin K. Petersen
@ 2025-03-26 16:51 ` WangYuli
0 siblings, 0 replies; 8+ messages in thread
From: WangYuli @ 2025-03-26 16:51 UTC (permalink / raw)
To: Martin K. Petersen
Cc: James.Bottomley, linux-scsi, linux-kernel, stern, bvanassche,
zhanjun, niecheng1, guanwentao, Xinwei Zhou, Xu Rao, Yujing Ming
[-- Attachment #1.1.1: Type: text/plain, Size: 1870 bytes --]
Hi Martin K. Petersen,
On 2025/3/21 09:08, Martin K. Petersen wrote:
> I am really not a fan of using in-kernel workarounds to intercept
> passthrough commands.
>
> Why does does lshw perform a MODE SENSE in the first place? What
> information is it looking for that isn't available in sysfs?
I know this is a workaround to solve the problem at the application layer.
The problem is that the kernel does not know what operations the
application will do to the disk through ioctl.
Intercepting this illegal command in kernel mode will help improve the
stability of the system.
The following is the log of the exception I caught:
10:22:22 2024] queue cmd =====1a 00 3f 00 ff 00 10:22:22 2024] CPU: 7
PID: 6000 Comm: lshw Tainted: G O 4.19.0-arm64-desktoptest #197 10:22:22
2024] Hardware name: THTF ChaoXiang Series/THTF-FTD3000-ZX200-MF281C,
BIOS KL4.28.BXC.D.016.241025.R 10/25/2024 17:51:51 10:22:22 2024] Call
trace: 10:22:22 2024] dump_backtrace+0x0/0x1a0 10:22:22 2024]
show_stack+0x24/0x30 10:22:22 2024]dump_stack+0xa8/0xcc 10:22:22 2024]
queuecommand+0xbc/0x198 [usb_storage] 10:22:22 2024]
scsi_dispatch_cmd+0xa4/0x298 10:22:22 2024]scsi_request_fn+0x47c/0x7a8
10:22:22 2024] __blk_run_queue+0x50/0x88 10:22:22 2024]
blk_execute_rq_nowait+0xe0/0x160 10:22:22 2024]
sg_common_write.isra.11+0x254/0x6c0 10:22:22 2024]
sg_new_write.isra.12+0x178/0x308 10:22:22 2024] sg_ioctl+0xeb4/0x11d8
10:22:22 2024] do_vfs_ioctl+0xb0/0x868 10:22:22 2024]
ksys_ioctl+0x84/0xb8 10:22:22 2024] __arm64_sys_ioctl+0x28/0x38 10:22:22
2024] el0_svc_common+0xa0/0x190 10:22:22 2024] el0_svc_handler+0xac/0xb8
10:22:22 2024] el0_svc+0x8/0xc
I encountered this problem in multiple devices, causing the disk to be
unrecognizable. I think it is necessary to do this to make the system
more robust.
Thanks,
--
WangYuli
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-03-26 16:52 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-18 6:11 [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute WangYuli
2025-03-21 1:08 ` Martin K. Petersen
2025-03-26 16:51 ` WangYuli
-- strict thread matches above, loose matches on Subject: below --
2025-02-24 3:48 WangYuli
2025-02-24 18:11 ` Bart Van Assche
2025-02-25 13:11 ` WangYuli
2025-02-25 20:54 ` Bart Van Assche
2025-02-26 2:31 ` WangYuli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox