Re: [PATCH] scsi: core: Fix block I/O error of USB card reader during resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/17/2022 9:52 PM, Bart Van Assche wrote:
On 8/17/22 01:34, Michael Wu wrote:
When accessing storage device via an USB card reader, a block I/O error
occurs during resume:

PM: suspend exit
sd 0: 0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte
=0x08
sd 0: 0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
sd 0: 0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
sd 0: 0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 17 ce e1 00 00 f0 00
blk_update_request: I/O error, dev sda, sector 1560289 op 0x0:(READ) flags
0x84700 phys_seg 19 prio class 0
sd 0: 0:0:0: [sda] tag#0 device offline or changed

Fix it by changing the action in scsi_io_completion_action() from
ACTION_FAIL to ACTION_RETRY by adding the condition `cmd->device->
lockable`.

Signed-off-by: Michael Wu <michael@xxxxxxxxxxxxxxxxx>
---
  drivers/scsi/scsi_lib.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 4dbd29ab1dcc..4bc480721947 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -704,7 +704,8 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)
      } else if (sense_valid && sense_current) {
          switch (sshdr.sense_key) {
          case UNIT_ATTENTION:
-            if (cmd->device->removable) {
+            if (cmd->device->removable &&
+                cmd->device->lockable) {
                  /* Detected disc change.  Set a bit
                   * and quietly refuse further access.
                   */

To me the above doesn't look like a good way to address this. I don't see why a device being lockable should control whether or not a unit attention results in a retry? Shouldn't the decision taken by scsi_io_completion_action() depend on the ASC and ASCQ codes rather than on whether a device is removable and/or lockable?

Dear Bart,
Yes... My patch did seem suspicious. Here's the scene about the block I/O error: Some card reader does not respond the command 'MEDIUM REMOVAL PREVENT' correctly, as a result, the host does not send subsequent cmd 'MEDIUM REMOVAL ALLOW'/'MEDIUM REMOVAL PREVENT' before/after sleep, which leads to a enumeration failure after system resume. I wonder, without changing the behavior of the device, is there's a better way to solve this? -- Modifying the scsi core should not be a good idea though :(

BTW, the code modified by the above patch is old. This is what I found in the 2002 version of scsi_lib.c:

if ((SCpnt->sense_buffer[0] & 0x7f) == 0x70
     && (SCpnt->sense_buffer[2] & 0xf) == UNIT_ATTENTION) {
         if (SCpnt->device->removable) {
                 /* detected disc change.  set a bit and quietly refuse
                  * further access.
                  */
                 SCpnt->device->changed = 1;
                 SCpnt = scsi_end_request(SCpnt, 0, this_count);
                 return;
         } else {
                 /*
                  * Must have been a power glitch, or a
                  * bus reset.  Could not have been a
                  * media change, so we just retry the
                  * request and see what happens.
                  */
                 scsi_queue_next_request(q, SCpnt);
                 return;
}

Bart.

Thanks,
Thanks for your kindly notice. I looked around in the latest linux mainline repo, but could not find this code. Where can I get this 2002 version of scsi_lib.c? Thank you.

--
Regards,
Michael Wu



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux