1. 10 Aug, 2017 15 commits
    • Steffen Maier's avatar
      scsi: zfcp: trace high part of "new" 64 bit SCSI LUN · 5d4a3d0a
      Steffen Maier authored
      Complements debugging aspects of the otherwise functionally complete
      v3.17 commit 9cb78c16 ("scsi: use 64-bit LUNs").
      
      While I don't have access to a target exporting 3 or 4 level LUNs,
      I did test it by explicitly attaching a non-existent fake 4 level LUN
      by means of zfcp sysfs attribute "unit_add".
      In order to see corresponding trace records of otherwise successful
      events, we had to increase the trace level of area SCSI and HBA to 6.
      
      $ echo 6 > /sys/kernel/debug/s390dbf/zfcp_0.0.1880_scsi/level
      $ echo 6 > /sys/kernel/debug/s390dbf/zfcp_0.0.1880_hba/level
      
      $ echo 0x4011402240334044 > \
        /sys/bus/ccw/drivers/zfcp/0.0.1880/0x50050763031bd327/unit_add
      
      Example output formatted by an updated zfcpdbf from the s390-tools
      package interspersed with kernel messages at scsi_logging_level=4605:
      
      Timestamp      : ...
      Area           : REC
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : scsla_1
      LUN            : 0x4011402240334044
      WWPN           : 0x50050763031bd327
      D_ID           : 0x00......
      Adapter status : 0x5400050b
      Port status    : 0x54000001
      LUN status     : 0x41000000
      Ready count    : 0x00000001
      Running count  : 0x00000000
      ERP want       : 0x01
      ERP need       : 0x01
      
      scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY pass 1 length 36
      scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY successful with code 0x0
      
      Timestamp      : ...
      Area           : HBA
      Subarea        : 00
      Level          : 6
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : fs_norm
      Request ID     : 0x<inquiry2-req-id>
      Request status : 0x00000010
      FSF cmnd       : 0x00000001
      FSF sequence no: 0x...
      FSF issued     : ...
      FSF stat       : 0x00000000
      FSF stat qual  : 00000000 00000000 00000000 00000000
      Prot stat      : 0x00000001
      Prot stat qual : ........ ........ 00000000 00000000
      Port handle    : 0x...
      LUN handle     : 0x...
      |
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 6
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : rsl_nor
      Request ID     : 0x<inquiry2-req-id>
      SCSI ID        : 0x00000000
      SCSI LUN       : 0x40224011
      SCSI LUN high  : 0x40444033 <=======================
      SCSI result    : 0x00000000
      SCSI retries   : 0x00
      SCSI allowed   : 0x03
      SCSI scribble  : 0x<inquiry2-req-id>
      SCSI opcode    : 12000000 a4000000 00000000 00000000
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000000 00000000
                       00000000 00000000
      
      scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY pass 2 length 164
      scsi 2:0:0:4630896905707208721: scsi scan: INQUIRY successful with code 0x0
      scsi 2:0:0:4630896905707208721: scsi scan: peripheral device type of 31, \
      no device added
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 9cb78c16 ("scsi: use 64-bit LUNs")
      Cc: <stable@vger.kernel.org> #3.17+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarJens Remus <jremus@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5d4a3d0a
    • Steffen Maier's avatar
      scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response · fdb7cee3
      Steffen Maier authored
      At the default trace level, we only trace unsuccessful events including
      FSF responses.
      
      zfcp_dbf_hba_fsf_response() only used protocol status and FSF status to
      decide on an unsuccessful response. However, this is only one of multiple
      possible sources determining a failed struct zfcp_fsf_req.
      
      An FSF request can also "fail" if its response runs into an ERP timeout
      or if it gets dismissed because a higher level recovery was triggered
      [trace tags "erscf_1" or "erscf_2" in zfcp_erp_strategy_check_fsfreq()].
      FSF requests with ERP timeout are:
      FSF_QTCB_EXCHANGE_CONFIG_DATA, FSF_QTCB_EXCHANGE_PORT_DATA,
      FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT or
      FSF_QTCB_CLOSE_PHYSICAL_PORT for target ports,
      FSF_QTCB_OPEN_LUN, FSF_QTCB_CLOSE_LUN.
      One example is slow queue processing which can cause follow-on errors,
      e.g. FSF_PORT_ALREADY_OPEN after FSF_QTCB_OPEN_PORT_WITH_DID timed out.
      In order to see the root cause, we need to see late responses even if the
      channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
      Example trace records formatted with zfcpdbf from the s390-tools package:
      
      Timestamp      : ...
      Area           : REC
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : ...
      Record ID      : 1
      Tag            : fcegpf1
      LUN            : 0xffffffffffffffff
      WWPN           : 0x<WWPN>
      D_ID           : 0x00<D_ID>
      Adapter status : 0x5400050b
      Port status    : 0x41200000
      LUN status     : 0x00000000
      Ready count    : 0x00000001
      Running count  : 0x...
      ERP want       : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
      ERP need       : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
      |
      Timestamp      : ...				30 seconds later
      Area           : REC
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : ...
      Record ID      : 2
      Tag            : erscf_2
      LUN            : 0xffffffffffffffff
      WWPN           : 0x<WWPN>
      D_ID           : 0x00<D_ID>
      Adapter status : 0x5400050b
      Port status    : 0x41200000
      LUN status     : 0x00000000
      Request ID     : 0x<request_ID>
      ERP status     : 0x10000000			ZFCP_STATUS_ERP_TIMEDOUT
      ERP step       : 0x0800				ZFCP_ERP_STEP_PORT_OPENING
      ERP action     : 0x02				ZFCP_ERP_ACTION_REOPEN_PORT
      ERP count      : 0x00
      |
      Timestamp      : ...				later than previous record
      Area           : HBA
      Subarea        : 00
      Level          : 5	> default level		=> 3	<= default level
      Exception      : -
      CPU ID         : 00
      Caller         : ...
      Record ID      : 1
      Tag            : fs_qtcb			=> fs_rerr
      Request ID     : 0x<request_ID>
      Request status : 0x00001010			ZFCP_STATUS_FSFREQ_DISMISSED
      						| ZFCP_STATUS_FSFREQ_CLEANUP
      FSF cmnd       : 0x00000005
      FSF sequence no: 0x...
      FSF issued     : ...				> 30 seconds ago
      FSF stat       : 0x00000000			FSF_GOOD
      FSF stat qual  : 00000000 00000000 00000000 00000000
      Prot stat      : 0x00000001			FSF_PROT_GOOD
      Prot stat qual : 00000000 00000000 00000000 00000000
      Port handle    : 0x...
      LUN handle     : 0x00000000
      QTCB log length: ...
      QTCB log info  : ...
      
      In case of problems detecting that new responses are waiting on the input
      queue, we sooner or later trigger adapter recovery due to an FSF request
      timeout (trace tag "fsrth_1").
      FSF requests with FSF request timeout are:
      typically FSF_QTCB_ABORT_FCP_CMND; but theoretically also
      FSF_QTCB_EXCHANGE_CONFIG_DATA or FSF_QTCB_EXCHANGE_PORT_DATA via sysfs,
      FSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT for WKA ports,
      FSF_QTCB_FCP_CMND for task management function (LUN / target reset).
      One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
      because the channel filled in the response via DMA into the request's QTCB.
      
      In a theroretical case, inject code can create an erroneous FSF request
      on purpose. If data router is enabled, it uses deferred error reporting.
      A READ SCSI command can succeed with FSF_PROT_GOOD, FSF_GOOD, and
      SAM_STAT_GOOD. But on writing the read data to host memory via DMA,
      it can still fail, e.g. if an intentionally wrong scatter list does not
      provide enough space. Rather than getting an unsuccessful response,
      we get a QDIO activate check which in turn triggers adapter recovery.
      One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
      because the channel filled in the response via DMA into the request's QTCB.
      Example trace records formatted with zfcpdbf from the s390-tools package:
      
      Timestamp      : ...
      Area           : HBA
      Subarea        : 00
      Level          : 6	> default level		=> 3	<= default level
      Exception      : -
      CPU ID         : ..
      Caller         : ...
      Record ID      : 1
      Tag            : fs_norm			=> fs_rerr
      Request ID     : 0x<request_ID2>
      Request status : 0x00001010			ZFCP_STATUS_FSFREQ_DISMISSED
      						| ZFCP_STATUS_FSFREQ_CLEANUP
      FSF cmnd       : 0x00000001
      FSF sequence no: 0x...
      FSF issued     : ...
      FSF stat       : 0x00000000			FSF_GOOD
      FSF stat qual  : 00000000 00000000 00000000 00000000
      Prot stat      : 0x00000001			FSF_PROT_GOOD
      Prot stat qual : ........ ........ 00000000 00000000
      Port handle    : 0x...
      LUN handle     : 0x...
      |
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 3
      Exception      : -
      CPU ID         : ..
      Caller         : ...
      Record ID      : 1
      Tag            : rsl_err
      Request ID     : 0x<request_ID2>
      SCSI ID        : 0x...
      SCSI LUN       : 0x...
      SCSI result    : 0x000e0000			DID_TRANSPORT_DISRUPTED
      SCSI retries   : 0x00
      SCSI allowed   : 0x05
      SCSI scribble  : 0x<request_ID2>
      SCSI opcode    : 28...				Read(10)
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000000 00000000
                                               ^^	SAM_STAT_GOOD
                       00000000 00000000
      
      Only with luck in both above cases, we could see a follow-on trace record
      of an unsuccesful event following a successful but late FSF response with
      FSF_PROT_GOOD and FSF_GOOD. Typically this was the case for I/O requests
      resulting in a SCSI trace record "rsl_err" with DID_TRANSPORT_DISRUPTED
      [On ZFCP_STATUS_FSFREQ_DISMISSED, zfcp_fsf_protstatus_eval() sets
      ZFCP_STATUS_FSFREQ_ERROR seen by the request handler functions as failure].
      However, the reason for this follow-on trace was invisible because the
      corresponding HBA trace record was missing at the default trace level
      (by default hidden records with tags "fs_norm", "fs_qtcb", or "fs_open").
      
      On adapter recovery, after we had shut down the QDIO queues, we perform
      unsuccessful pseudo completions with flag ZFCP_STATUS_FSFREQ_DISMISSED
      for each pending FSF request in zfcp_fsf_req_dismiss_all().
      In order to find the root cause, we need to see all pseudo responses even
      if the channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
      
      Therefore, check zfcp_fsf_req.status for ZFCP_STATUS_FSFREQ_DISMISSED
      or ZFCP_STATUS_FSFREQ_ERROR and trace with a new tag "fs_rerr".
      
      It does not matter that there are numerous places which set
      ZFCP_STATUS_FSFREQ_ERROR after the location where we trace an FSF response
      early. These cases are based on protocol status != FSF_PROT_GOOD or
      == FSF_PROT_FSF_STATUS_PRESENTED and are thus already traced by default
      as trace tag "fs_perr" or "fs_ferr" respectively.
      
      NB: The trace record with tag "fssrh_1" for status read buffers on dismiss
      all remains. zfcp_fsf_req_complete() handles this and returns early.
      All other FSF request types are handled separately and as described above.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 8a36e453 ("[SCSI] zfcp: enhancement of zfcp debug features")
      Fixes: 2e261af8 ("[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levels")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      fdb7cee3
    • Steffen Maier's avatar
      scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records · 12c3e575
      Steffen Maier authored
      If the FCP_RSP UI has optional parts (FCP_SNS_INFO or FCP_RSP_INFO) and
      thus does not fit into the fsp_rsp field built into a SCSI trace record,
      trace the full FCP_RSP UI with all optional parts as payload record
      instead of just FCP_SNS_INFO as payload and
      a 1 byte RSP_INFO_CODE part of FCP_RSP_INFO built into the SCSI record.
      
      That way we would also get the full FCP_SNS_INFO in case a
      target would ever send more than
      min(SCSI_SENSE_BUFFERSIZE==96, ZFCP_DBF_PAY_MAX_REC==256)==96.
      
      The mandatory part of FCP_RSP IU is only 24 bytes.
      PAYload costs at least one full PAY record of 256 bytes anyway.
      We cap to the hardware response size which is only FSF_FCP_RSP_SIZE==128.
      So we can just put the whole FCP_RSP IU with any optional parts into
      PAYload similarly as we do for SAN PAY since v4.9 commit aceeffbb
      ("zfcp: trace full payload of all SAN records (req,resp,iels)").
      This does not cause any additional trace records wasting memory.
      
      Decoded trace records were confusing because they showed a hard-coded
      sense data length of 96 even if the FCP_RSP_IU field FCP_SNS_LEN showed
      actually less.
      
      Since the same commit, we set pl_len for SAN traces to the full length of a
      request/response even if we cap the corresponding trace.
      In contrast, here for SCSI traces we set pl_len to the pre-computed
      length of FCP_RSP IU considering SNS_LEN or RSP_LEN if valid.
      Nonetheless we trace a hardcoded payload of length FSF_FCP_RSP_SIZE==128
      if there were optional parts.
      This makes it easier for the zfcpdbf tool to format only the relevant
      part of the long FCP_RSP UI buffer. And any trailing information is still
      available in the payload trace record just in case.
      
      Rename the payload record tag from "fcp_sns" to "fcp_riu" to make the new
      content explicit to zfcpdbf which can then pick a suitable field name such
      as "FCP rsp IU all:" instead of "Sense info :"
      Also, the same zfcpdbf can still be backwards compatible with "fcp_sns".
      
      Old example trace record before this fix, formatted with the tool zfcpdbf
      from s390-tools:
      
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 3
      Exception      : -
      CPU id         : ..
      Caller         : 0x...
      Record id      : 1
      Tag            : rsl_err
      Request id     : 0x<request_id>
      SCSI ID        : 0x...
      SCSI LUN       : 0x...
      SCSI result    : 0x00000002
      SCSI retries   : 0x00
      SCSI allowed   : 0x05
      SCSI scribble  : 0x<request_id>
      SCSI opcode    : 00000000 00000000 00000000 00000000
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000202 00000000
                                             ^^==FCP_SNS_LEN_VALID
                       00000020 00000000
                       ^^^^^^^^==FCP_SNS_LEN==32
      Sense len      : 96 <==min(SCSI_SENSE_BUFFERSIZE,ZFCP_DBF_PAY_MAX_REC)
      Sense info     : 70000600 00000018 00000000 29000000
                       00000400 00000000 00000000 00000000
                       00000000 00000000 00000000 00000000<==superfluous
                       00000000 00000000 00000000 00000000<==superfluous
                       00000000 00000000 00000000 00000000<==superfluous
                       00000000 00000000 00000000 00000000<==superfluous
      
      New example trace records with this fix:
      
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 3
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : rsl_err
      Request ID     : 0x<request_id>
      SCSI ID        : 0x...
      SCSI LUN       : 0x...
      SCSI result    : 0x00000002
      SCSI retries   : 0x00
      SCSI allowed   : 0x03
      SCSI scribble  : 0x<request_id>
      SCSI opcode    : a30c0112 00000000 02000000 00000000
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000a02 00000200
                       00000020 00000000
      FCP rsp IU len : 56
      FCP rsp IU all : 00000000 00000000 00000a02 00000200
                                             ^^=FCP_RESID_UNDER|FCP_SNS_LEN_VALID
                       00000020 00000000 70000500 00000018
                       ^^^^^^^^==FCP_SNS_LEN
                                         ^^^^^^^^^^^^^^^^^
                       00000000 240000cb 00011100 00000000
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                       00000000 00000000
                       ^^^^^^^^^^^^^^^^^==FCP_SNS_INFO
      
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : lr_okay
      Request ID     : 0x<request_id>
      SCSI ID        : 0x...
      SCSI LUN       : 0x...
      SCSI result    : 0x00000000
      SCSI retries   : 0x00
      SCSI allowed   : 0x05
      SCSI scribble  : 0x<request_id>
      SCSI opcode    : <CDB of unrelated SCSI command passed to eh handler>
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000100 00000000
                       00000000 00000008
      FCP rsp IU len : 32
      FCP rsp IU all : 00000000 00000000 00000100 00000000
                                             ^^==FCP_RSP_LEN_VALID
                       00000000 00000008 00000000 00000000
                                ^^^^^^^^==FCP_RSP_LEN
                                         ^^^^^^^^^^^^^^^^^==FCP_RSP_INFO
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 250a1352 ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      12c3e575
    • Steffen Maier's avatar
      scsi: zfcp: fix missing trace records for early returns in TMF eh handlers · 1a5d999e
      Steffen Maier authored
      For problem determination we need to see that we were in scsi_eh
      as well as whether and why we were successful or not.
      
      The following commits introduced new early returns without adding
      a trace record:
      
      v2.6.35 commit a1dbfddd
      ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
      on fc_block_scsi_eh() returning != 0 which is FAST_IO_FAIL,
      
      v2.6.30 commit 63caf367
      ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
      on not having gotten an FSF request after the maximum number of retry
      attempts and thus could not issue a TMF and has to return FAILED.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: a1dbfddd ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
      Fixes: 63caf367 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1a5d999e
    • Steffen Maier's avatar
      scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA · 9fe5d2b2
      Steffen Maier authored
      Without this fix we get SCSI trace records on task management functions
      which cannot be correlated to HBA trace records because all fields
      related to the FSF request are empty (zero).
      Also, the FCP_RSP_IU is missing as well as any sense data if available.
      
      This was caused by v2.6.14 commit 8a36e453 ("[SCSI] zfcp: enhancement
      of zfcp debug features") introducing trace records for TMFs but
      hard coding NULL for a possibly existing TMF FSF request.
      The scsi_cmnd scribble is also zero or unrelated for the TMF request
      so it also could not lookup a suitable FSF request from there.
      
      A broken example trace record formatted with zfcpdbf from the s390-tools
      package:
      
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : lr_fail
      Request ID     : 0x0000000000000000
                         ^^^^^^^^^^^^^^^^ no correlation to HBA record
      SCSI ID        : 0x<scsitarget>
      SCSI LUN       : 0x<scsilun>
      SCSI result    : 0x000e0000
      SCSI retries   : 0x00
      SCSI allowed   : 0x05
      SCSI scribble  : 0x0000000000000000
      SCSI opcode    : 2a000017 3bb80000 08000000 00000000
      FCP rsp inf cod: 0x00
                         ^^ no TMF response
      FCP rsp IU     : 00000000 00000000 00000000 00000000
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                       00000000 00000000
                       ^^^^^^^^^^^^^^^^^ no interesting FCP_RSP_IU
      Sense len      : ...
      ^^^^^^^^^^^^^^^^^^^^ no sense data length
      Sense info     : ...
      ^^^^^^^^^^^^^^^^^^^^ no sense data content, even if present
      
      There are some true cases where we really do not have an FSF request:
      "rsl_fai" from zfcp_dbf_scsi_fail_send() called for early
      returns / completions in zfcp_scsi_queuecommand(),
      "abrt_or", "abrt_bl", "abrt_ru", "abrt_ar" from
      zfcp_scsi_eh_abort_handler() where we did not get as far,
      "lr_nres", "tr_nres" from zfcp_task_mgmt_function() where we're
      successful and do not need to do anything because adapter stopped.
      For these cases it's correct to pass NULL for fsf_req to _zfcp_dbf_scsi().
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 8a36e453 ("[SCSI] zfcp: enhancement of zfcp debug features")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9fe5d2b2
    • Steffen Maier's avatar
      scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records · 975171b4
      Steffen Maier authored
      v4.9 commit aceeffbb ("zfcp: trace full payload of all SAN records
      (req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      necessary for problem determination, e.g. to see the
      currently active zone set during automatic port scan.
      
      While it already saves space by not dumping any empty residual entries
      of the large successful GPN_FT response (4 pages), there are seldom cases
      where the GPN_FT response is unsuccessful and likely does not have
      FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
      We typically see such case for an initiator WWPN, which is not in any zone.
      
      Cap unsuccessful responses to at least the actual basic CT_IU response
      plus whatever fits the SAN trace record built-in "payload" buffer
      just in case there's trailing information
      of which we would at least see the existence and its beginning.
      
      In order not to erroneously cap successful responses, we need to swap
      calling the trace function and setting the CT / ELS status to success (0).
      
      Example trace record pair formatted with zfcpdbf:
      
      Timestamp      : ...
      Area           : SAN
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : fssct_1
      Request ID     : 0x<request_id>
      Destination ID : 0x00fffffc
      SAN req short  : 01000000 fc020000 01720ffc 00000000
                       00000008
      SAN req length : 20
      |
      Timestamp      : ...
      Area           : SAN
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 2
      Tag            : fsscth2
      Request ID     : 0x<request_id>
      Destination ID : 0x00fffffc
      SAN resp short : 01000000 fc020000 80010000 00090700
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
      SAN resp length: 16384
      San resp info  : 01000000 fc020000 80010000 00090700
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
                       00000000 00000000 00000000 00000000 [trailing info]
      
      The fix saves all but one of the previously associated 64 PAYload trace
      record chunks of size 256 bytes each.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: aceeffbb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Cc: <stable@vger.kernel.org> #2.6.38+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      975171b4
    • Benjamin Block's avatar
      scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path · a099b7b1
      Benjamin Block authored
      Up until now zfcp would just ignore the FCP_RESID_OVER flag in the FCP
      response IU. When this flag is set, it is possible, in regards to the
      FCP standard, that the storage-server processes the command normally, up
      to the point where data is missing and simply ignores those.
      
      In this case no CHECK CONDITION would be set, and because we ignored the
      FCP_RESID_OVER flag we resulted in at least a data loss or even
      -corruption as a follow-up error, depending on how the
      applications/layers on top behave. To prevent this, we now set the
      host-byte of the corresponding scsi_cmnd to DID_ERROR.
      
      Other storage-behaviors, where the same condition results in a CHECK
      CONDITION set in the answer, don't need to be changed as they are
      handled in the mid-layer already.
      
      Following is an example trace record decoded with zfcpdbf from the
      s390-tools package. We forcefully injected a fc_dl which is one byte too
      small:
      
      Timestamp      : ...
      Area           : SCSI
      Subarea        : 00
      Level          : 3
      Exception      : -
      CPU ID         : ..
      Caller         : 0x...
      Record ID      : 1
      Tag            : rsl_err
      Request ID     : 0x...
      SCSI ID        : 0x...
      SCSI LUN       : 0x...
      SCSI result    : 0x00070000
                           ^^DID_ERROR
      SCSI retries   : 0x..
      SCSI allowed   : 0x..
      SCSI scribble  : 0x...
      SCSI opcode    : 2a000000 00000000 08000000 00000000
      FCP rsp inf cod: 0x00
      FCP rsp IU     : 00000000 00000000 00000400 00000001
                                             ^^fr_flags==FCP_RESID_OVER
                                               ^^fr_status==SAM_STAT_GOOD
                                                  ^^^^^^^^fr_resid
                       00000000 00000000
      
      As of now, we don't actively handle to possibility that a response IU
      has both flags - FCP_RESID_OVER and FCP_RESID_UNDER - set at once.
      Reported-by: default avatarLuke M. Hopkins <lmhopkin@us.ibm.com>
      Reviewed-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 553448f6 ("[SCSI] zfcp: Message cleanup")
      Fixes: ea127f97 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
      Cc: <stable@vger.kernel.org> #2.6.33+
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a099b7b1
    • Steffen Maier's avatar
      scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled · 71b8e45d
      Steffen Maier authored
      Since commit db007fc5 ("[SCSI] Command protection operation"),
      scsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to
      SCSI_PROT_NORMAL.
      Other FCP LLDDs such as qla2xxx and lpfc shield their queuecommand()
      to only access any of scsi_prot_sg...() if
      (scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).
      
      Do the same thing for zfcp, which introduced DIX support with
      commit ef3eb71d ("[SCSI] zfcp: Introduce experimental support for
      DIF/DIX").
      
      Otherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp,
      because the regular SCSI command with DIX protection data, that scsi_eh
      re-uses in scsi_send_eh_cmnd(), of course still has
      (scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the
      FCP channel hardware.
      
      This causes scsi_eh_test_devices() to have (finish_cmds == 0)
      [not SCSI device is online or not scsi_eh_tur() failed]
      so regular SCSI commands, that caused / were affected by scsi_eh,
      are moved to work_q and scsi_eh_test_devices() itself returns false.
      In turn, it unnecessarily escalates in our case in scsi_eh_ready_devs()
      beyond host reset to finally scsi_eh_offline_sdevs()
      which sets affected SCSI devices offline with the following kernel message:
      
      "kernel: sd H:0:T:L: Device offlined - not ready after error recovery"
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: ef3eb71d ("[SCSI] zfcp: Introduce experimental support for DIF/DIX")
      Cc: <stable@vger.kernel.org> #2.6.36+
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      71b8e45d
    • Benjamin Block's avatar
      scsi: zfcp: convert bool-definitions to use 'true' instead of '1' · 5156934b
      Benjamin Block authored
      Better form and cleans remaining warnings.
      
      Found with scripts/coccinelle/misc/boolinit.cocci.
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5156934b
    • Corentin Labbe's avatar
      scsi: zfcp: Remove unneeded linux/miscdevice.h include · 16d75e65
      Corentin Labbe authored
      drivers/s390/scsi/zfcp_aux.c does not contain any miscdevice so the
      inclusion of linux/miscdevice.h is unnecessary.
      
      [maier@linux.vnet.ibm.com: just for the records, this is in fact a
       minor missing code cleanup of the following older "feature"
       which also dropped the only former use of a misc device in zfcp:
       commit 663e0890 ("[SCSI] zfcp: remove access control tables
      				    interface")
       commit b5dc3c48 ("[SCSI] zfcp: remove access control tables
      				    interface (keep sysfs files)")
       commit 1b33ef23 ("zfcp: remove access control tables interface
      			     (port leftovers)")]
      Signed-off-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      16d75e65
    • Lukáš Korenčik's avatar
      scsi: zfcp: use setup_timer instead of init_timer · bc46427e
      Lukáš Korenčik authored
      Use initialization with setup_timer function instead of using
      init_timer function and data fields. It improves readability.
      Signed-off-by: default avatarLukáš Korenčik <xkorenc1@fi.muni.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      bc46427e
    • LABBE Corentin's avatar
      scsi: zfcp: replace zfcp_qdio_sbale_count by sg_nents · 7d91869c
      LABBE Corentin authored
      The zfcp_qdio_sbale_count function do the same work than sg_nents().
      So replace it by sg_nents() for removing duplicate code.
      Signed-off-by: default avatarLABBE Corentin <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7d91869c
    • Varun Prakash's avatar
      scsi: libcxgbi: use ndev->ifindex to find route · 4737c5a0
      Varun Prakash authored
      If cxgbi_ep_connect() is called with valid shost then find associated
      ndev and use ndev->ifindex to find route.
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4737c5a0
    • Christophe JAILLET's avatar
      scsi: mpt3sas: Fix memory allocation failure test in 'mpt3sas_base_attach()' · a5dd7efd
      Christophe JAILLET authored
      In the lines above this test, 8 'kzalloc' are performed, but only 7
      results are tested.
      
      Add the missing one (i.e. '!ioc->port_enable_cmds.reply').
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      a5dd7efd
    • Michał Mirosław's avatar
      scsi: aic7xxx: regenerate firmware files · 2ae203fa
      Michał Mirosław authored
      Regenerate firmware files to make cleaner base for following fix.
      This removes some unused definitions and reorders some #defines, but
      the code remains the same.
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      2ae203fa
  2. 08 Aug, 2017 2 commits
  3. 07 Aug, 2017 23 commits