lkml.org 
[lkml]   [2019]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH AUTOSEL 4.20 104/117] scsi: smartpqi: correct lun reset issues
    Date
    From: Kevin Barnett <kevin.barnett@microsemi.com>

    [ Upstream commit 2ba55c9851d74eb015a554ef69ddf2ef061d5780 ]

    Problem:
    The Linux kernel takes a logical volume offline after a LUN reset. This is
    generally accompanied by this message in the dmesg output:

    Device offlined - not ready after error recovery

    Root Cause:
    The root cause is a "quirk" in the timeout handling in the Linux SCSI
    layer. The Linux kernel places a 30-second timeout on most media access
    commands (reads and writes) that it send to device drivers. When a media
    access command times out, the Linux kernel goes into error recovery mode
    for the LUN that was the target of the command that timed out. Every
    command that timed out is kept on a list inside of the Linux kernel to be
    retried later. The kernel attempts to recover the command(s) that timed out
    by issuing a LUN reset followed by a TEST UNIT READY. If the LUN reset and
    TEST UNIT READY commands are successful, the kernel retries the command(s)
    that timed out.

    Each SCSI command issued by the kernel has a result field associated with
    it. This field indicates the final result of the command (success or
    error). When a command times out, the kernel places a value in this result
    field indicating that the command timed out.

    The "quirk" is that after the LUN reset and TEST UNIT READY commands are
    completed, the kernel checks each command on the timed-out command list
    before retrying it. If the result field is still "timed out", the kernel
    treats that command as not having been successfully recovered for a
    retry. If the number of commands that are in this state are greater than
    two, the kernel takes the LUN offline.

    Fix:
    When our RAIDStack receives a LUN reset, it simply waits until all
    outstanding commands complete. Generally, all of these outstanding commands
    complete successfully. Therefore, the fix in the smartpqi driver is to
    always set the command result field to indicate success when a request
    completes successfully. This normally isn’t necessary because the result
    field is always initialized to success when the command is submitted to the
    driver. So when the command completes successfully, the result field is
    left untouched. But in this case, the kernel changes the result field
    behind the driver’s back and then expects the field to be changed by the
    driver as the commands that timed-out complete.

    Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
    Reviewed-by: Scott Teel <scott.teel@microsemi.com>
    Signed-off-by: Kevin Barnett <kevin.barnett@microsemi.com>
    Signed-off-by: Don Brace <don.brace@microsemi.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    drivers/scsi/smartpqi/smartpqi_init.c | 3 +++
    1 file changed, 3 insertions(+)

    diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
    index a25a07a0b7f0..c1efc182f5ea 100644
    --- a/drivers/scsi/smartpqi/smartpqi_init.c
    +++ b/drivers/scsi/smartpqi/smartpqi_init.c
    @@ -2704,6 +2704,9 @@ static unsigned int pqi_process_io_intr(struct pqi_ctrl_info *ctrl_info,
    switch (response->header.iu_type) {
    case PQI_RESPONSE_IU_RAID_PATH_IO_SUCCESS:
    case PQI_RESPONSE_IU_AIO_PATH_IO_SUCCESS:
    + if (io_request->scmd)
    + io_request->scmd->result = 0;
    + /* fall through */
    case PQI_RESPONSE_IU_GENERAL_MANAGEMENT:
    break;
    case PQI_RESPONSE_IU_TASK_MANAGEMENT:
    --
    2.19.1
    \
     
     \ /
      Last update: 2019-01-08 21:00    [W:3.915 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site