1. 17 5月, 2017 8 次提交
  2. 09 5月, 2017 3 次提交
    • C
      scsi: lpfc: ensure els_wq is being checked before destroying it · 019c0d66
      Colin Ian King 提交于
      I believe there is a typo on the wq destroy of els_wq, currently the
      driver is checking if els_cq is not null and I think this should be a
      check on els_wq instead.
      
      Detected by CoverityScan, CID#1411629 ("Copy-paste error")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Acked-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      019c0d66
    • D
      scsi: lpfc: double lock typo in lpfc_ns_rsp() · 0d618cf4
      Dan Carpenter 提交于
      There is a double lock bug here so this will deadlock instead of
      unlocking.
      
      Fixes: 1c5b12f7 ("Fix implicit logo and RSCN handling for NVMET")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      0d618cf4
    • J
      scsi: lpfc: Fix panic on BFS configuration · 4492b739
      James Smart 提交于
      To select the appropriate shost template, the driver is issuing a
      mailbox command to retrieve the wwn. Turns out the sending of the
      command precedes the reset of the function.  On SLI-4 adapters, this is
      inconsequential as the mailbox command location is specified by dma via
      the BMBX register. However, on SLI-3 adapters, the location of the
      mailbox command submission area changes. When the function is first
      powered on or reset, the cmd is submitted via PCI bar memory. Later the
      driver changes the function config to use host memory and DMA. The
      request to start a mailbox command is the same, a simple doorbell write,
      regardless of submission area.  So.. if there has not been a boot driver
      run against the adapter, the mailbox command works as defaults are
      ok. But, if the boot driver has configured the card and, and if no
      platform pci function/slot reset occurs as the os starts, the mailbox
      command will fail. The SLI-3 device will use the stale boot driver dma
      location. This can cause PCI eeh errors.
      
      Fix is to reset the sli-3 function before sending the mailbox command,
      thus synchronizing the function/driver on mailbox location.
      
      Note: The fix uses routines that are typically invoked later in the call
      flow to reset the sli-3 device. The issue in using those routines is
      that the normal (non-fix) flow does additional initialization, namely
      the allocation of the pport structure. So, rather than significantly
      reworking the initialization flow so that the pport is alloc'd first,
      pointer checks are added to work around it. Checks are limited to the
      routines invoked by a sli-3 adapter (s3 routines) as this fix/early call
      is only invoked on a sli3 adapter. Nothing changes post the
      fix. Subsequent initialization, and another adapter reset, still occur -
      both on sli-3 and sli-4 adapters.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Fixes: 96418b5e ("scsi: lpfc: Fix eh_deadline setting for sli3 adapters.")
      Cc: stable@vger.kernel.org # v4.11+
      Reviewed-by: NEwan D. Milne <emilne@redhat.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      4492b739
  3. 26 4月, 2017 1 次提交
    • J
      lpfc: Fix memory corruption of the lpfc_ncmd->list pointers · bbe3012b
      James Smart 提交于
      lpfc was changing the private pointer that is set/maintained by
      the nvme_fc transport. This caused two issues: a) the transport, on
      teardown may erroneous attempt to free whatever address was set;
      and b) lfpc uses any value set in lpfc_nvme_fcp_abort() and
      assumes its a valid io request.
      
      Correct issue by properly defining a context structure for lpfc.
      Lpfc also updated to clear the private context structure on io
      completion.
      
      Since this bug caused scrutiny of the way lpfc moves local request
      structures between lists, also cleaned up list_del()'s to
      list_del_inits()'s.
      
      This is a nvme-specific bug. The patch was cut against the
      linux-block tree, for-4.12/block tree. It should be pulled in through
      that tree.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      bbe3012b
  4. 24 4月, 2017 22 次提交
    • J
      lpfc revison 11.2.0.12 · 51f39764
      James Smart 提交于
      Update lpfc version to reflect this set of changes.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      51f39764
    • J
      Fix Express lane queue creation. · 7e04e21a
      James Smart 提交于
      The older sli4 adapters only supported the 64 byte WQE entry size.
      The new adapter (fw) support both 64 and 128 byte WQE entry sizies.
      The Express lane WQ was not being created with the 128 byte WQE sizes
      when it was supported.
      
      Not having the right WQE size created for the express lane work queue
      caused the the firmware to overwrite the lun indentifier in the FCP header.
      
      This patch correctly creates the express lane work queue with the
      supported size.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      7e04e21a
    • J
      Update ABORT processing for NVMET. · 86c67379
      James Smart 提交于
      The driver with nvme had this routine stubbed.
      
      Right now XRI_ABORTED_CQE is not handled and the FC NVMET
      Transport has a new API for the driver.
      
      Missing code path, new NVME abort API
      Update ABORT processing for NVMET
      
      There are 3 new FC NVMET Transport API/ template routines for NVMET:
      
      lpfc_nvmet_xmt_fcp_release
      This NVMET template callback routine called to release context
      associated with an IO This routine is ALWAYS called last, even
      if the IO was aborted or completed in error.
      
      lpfc_nvmet_xmt_fcp_abort
      This NVMET template callback routine called to abort an exchange that
      has an IO in progress
      
      nvmet_fc_rcv_fcp_req
      When the lpfc driver receives an ABTS, this NVME FC transport layer
      callback routine is called. For this case there are 2 paths thru the
      driver: the driver either has an outstanding exchange / context for the
      XRI to be aborted or not.  If not, a BA_RJT is issued otherwise a BA_ACC
      
      NVMET Driver abort paths:
      
      There are 2 paths for aborting an IO. The first one is we receive an IO and
      decide not to process it because of lack of resources. An unsolicated ABTS
      is immediately sent back to the initiator as a response.
      lpfc_nvmet_unsol_fcp_buffer
                  lpfc_nvmet_unsol_issue_abort  (XMIT_SEQUENCE_WQE)
      
      The second one is we sent the IO up to the NVMET transport layer to
      process, and for some reason the NVME Transport layer decided to abort the
      IO before it completes all its phases. For this case there are 2 paths
      thru the driver:
      the driver either has an outstanding TSEND/TRECEIVE/TRSP WQE or no
      outstanding WQEs are present for the exchange / context.
      lpfc_nvmet_xmt_fcp_abort
          if (LPFC_NVMET_IO_INP)
              lpfc_nvmet_sol_fcp_issue_abort  (ABORT_WQE)
                      lpfc_nvmet_sol_fcp_abort_cmp
          else
              lpfc_nvmet_unsol_fcp_issue_abort
                      lpfc_nvmet_unsol_issue_abort  (XMIT_SEQUENCE_WQE)
                              lpfc_nvmet_unsol_fcp_abort_cmp
      
      Context flags:
      LPFC_NVMET_IOP - his flag signifies an IO is in progress on the exchange.
      LPFC_NVMET_XBUSY  - this flag indicates the IO completed but the firmware
      is still busy with the corresponding exchange. The exchange should not be
      reused until after a XRI_ABORTED_CQE is received for that exchange.
      LPFC_NVMET_ABORT_OP - this flag signifies an ABORT_WQE was issued on the
      exchange.
      LPFC_NVMET_CTX_RLS  - this flag signifies a context free was requested,
      but we are deferring it due to an XBUSY or ABORT in progress.
      
      A ctxlock is added to the context structure that is used whenever these
      flags are set/read  within the context of an IO.
      The LPFC_NVMET_CTX_RLS flag is only set in the defer_relase routine when
      the transport has resolved all IO associated with the buffer. The flag is
      cleared when the CTX is associated with a new IO.
      
      An exchange can has both an LPFC_NVMET_XBUSY and a LPFC_NVMET_ABORT_OP
      condition active simultaneously. Both conditions must complete before the
      exchange is freed.
      When the abort callback (lpfc_nvmet_xmt_fcp_abort) is envoked:
      If there is an outstanding IO, the driver will issue an ABORT_WQE. This
      should result in 3 completions for the exchange:
      1) IO cmpl with XB bit set
      2) Abort WQE cmpl
      3) XRI_ABORTED_CQE cmpl
      For this scenerio, after completion #1, the NVMET Transport IO rsp
      callback is called.  After completion #2, no action is taken with respect
      to the exchange / context.  After completion #3, the exchange context is
      free for re-use on another IO.
      
      If there is no outstanding activity on the exchange, the driver will send a
      ABTS to the Initiator. Upon completion of this WQE, the exchange / context
      is freed for re-use on another IO.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      86c67379
    • J
      Fix implicit logo and RSCN handling for NVMET · 1c5b12f7
      James Smart 提交于
      NVMET didn't have any RSCN handling at all and
      would not execute implicit LOGO when receiving a PLOGI
      from an rport that NVMET had in state UNMAPPED.
      
      Clean up the logic in lpfc_nlp_state_cleanup for
      initiators (FCP and NVME). NVMET should not respond to
      RSCN including allocating new ndlps so this code was
      conditionalized when nvmet_support is true.  The check
      for NLP_RCV_PLOGI in lpfc_setup_disc_node was moved
      below the check for nvmet_support to allow the NVMET
      to recover initiator nodes correctly.  The implicit
      logo was introduced with lpfc_rcv_plogi when NVMET gets
      a PLOGI on an ndlp in UNMAPPED state.  The RSCN handling
      was modified to not respond to an RSCN in NVMET.  Instead
      NVMET sends a GID_FT and determines if an NVMEP_INITIATOR
      it has is UNMAPPED but no longer in the zone membership.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      1c5b12f7
    • J
      Add Fabric assigned WWN support. · aeb3c817
      James Smart 提交于
      Adding support for Fabric assigned WWPN and WWNN.
      
      Firmware sends first FLOGI to fabric with vendor version changes.
      On link up driver gets updated service parameter with FAWWN assigned port
      name.  Driver sends 2nd FLOGI with updated fawwpn and modifies the
      vport->fc_portname in driver.
      
      Note:
      Soft wwpn will not be allowed when fawwpn is enabled.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      aeb3c817
    • J
      Fix max_sgl_segments settings for NVME / NVMET · 4d4c4a4a
      James Smart 提交于
      Cannot set NVME segment counts to a large number
      
      The existing module parameter lpfc_sg_seg_cnt is used for both
      SCSI and NVME.
      
      Limit the module parameter lpfc_sg_seg_cnt to 128 with the
      default being 64 for both NVME and NVMET, assuming NVME is enabled in the
      driver for that port. The driver will set max_sgl_segments in the
      NVME/NVMET template to lpfc_sg_seg_cnt + 1.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      4d4c4a4a
    • J
      Fix crash after issuing lip reset · 9d3d340d
      James Smart 提交于
      When RPI is not available, driver sends WQE with invalid RPI value and
      rejected by HBA.
      lpfc 0000:82:00.3: 1:3154 BLS ABORT RSP failed, data:  x3/xa0320008
      and
      lpfc :2753 PLOGI failure DID:FFFFFA Status:x3/xa0240008
      
      In this case, driver accesses rpi_ids array out of bounds.
      
      Fix:
      Check return value of lpfc_sli4_alloc_rpi(). Do not allocate
      lpfc_nodelist entry if RPI is not available.
      
      When RPI is not available, we will get discovery timeouts and
      command drops for some of the vports as seen below.
      
      lpfc :0273 Unexpected discovery timeout, vport State x0
      lpfc :0230 Unexpected timeout, hba link state x5
      lpfc :0111 Dropping received ELS cmd Data: x0 xc90c55 x0
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      9d3d340d
    • J
      Fix driver load issues when MRQ=8 · 2b7824d0
      James Smart 提交于
      The symptom is that the driver will fail to login to the fabric.
      The reason is because it is out of iocb resources.
      
      There is a one to one relationship between MRQs
      (receive buffers for NVMET-FC) and iocbs and the default number of
      IOCBs was not accounting for the number of MRQs that were being created.
      
      This fix aligns the number of MRQ resources with the total resources so
      that it can handle fabric events when needed.
      
      Also the initialization of ctxlock to be on FCP commands, NOT LS commands.
      And modified log messages so that the log output can be correlated with
      the analyzer trace.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      2b7824d0
    • J
      Remove hba lock from NVMET issue WQE. · 59c6e13e
      James Smart 提交于
      Unnecessary lock is taken. ring lock should be sufficient to protect the
      work queue submission.
      
      This was noticed when doing performance testing. The hbalock is not
      needed to issue io to the nvme work queue.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      59c6e13e
    • J
      Fix nvme initiator handling when not enabled. · 4410a67a
      James Smart 提交于
      Fix nvme initiator handline when CONFIG_LPFC_NVME_INITIATOR is not enabled.
      
      With update nvme upstream driver sources, loading
      the driver with nvme enabled resulting in this Oops.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
       IP: lpfc_nvme_update_localport+0x23/0xd0 [lpfc]
       PGD 0
       Oops: 0000 [#1] SMP
       CPU: 0 PID: 10256 Comm: lpfc_worker_0 Tainted
       Hardware name: ...
       task: ffff881028191c40 task.stack: ffff880ffdf00000
       RIP: 0010:lpfc_nvme_update_localport+0x23/0xd0 [lpfc]
       RSP: 0018:ffff880ffdf03c20 EFLAGS: 00010202
      
      Cause: As the initiator driver completes discovery at different stages,
      it call lpfc_nvme_update_localport to hint that the DID and role may have
      changed.  In the implementation of lpfc_nvme_update_localport, the driver
      was not validating the localport or the lport during the execution
      of the update_localport routine.  With the recent upstream additions to
      the driver, the create_localport routine didn't run and so the localport
      was NULL causing the page-fault Oops.
      
      Fix: Add the CONFIG_LPFC_NVME_INITIATOR preprocessor inclusions to
      lpfc_nvme_update_localport to turn off all routine processing when
      the running kernel does not have NVME configured.  Add NULL pointer
      checks on the localport and lport in lpfc_nvme_update_localport and
      dump messages if they are NULL and just exit.
      Also one alingment issue fixed.
      Repalces the ifdef with the IS_ENABLED macro.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      4410a67a
    • J
      Fix driver usage of 128B WQEs when WQ_CREATE is V1. · 3f247de7
      James Smart 提交于
      There are two versions of a structure for queue creation and setup that the
      driver shares with FW. The driver was only treating as version 0.
      
      Verify WQ_CREATE with 128B WQEs in V0 and V1.
      
      Code review of another bug showed the driver passing
      128B WQEs and 8 pages in WQ CREATE and V0.
      Code inspection/instrumentation showed that the driver
      uses V0 in WQ_CREATE and if the caller passes queue->entry_size
      128B, the driver sets the hdr_version to V1 so all is good.
      When I tested the V1 WQ_CREATE, the mailbox failed causing
      the driver to unload.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      3f247de7
    • J
      Fix driver unload/reload operation. · d1f525aa
      James Smart 提交于
      There are couple of different load/unload issues fixed with this patch.
      One of the issues was reported by Junichi Nomura, a patch was submitted
      by Johannes Thumsrhirn which did fix one of the problems but the fix in
      this patch separates the pring free from the queue free and does not set
      the parameter passed in to NULL.
      
      issues:
      (1) driver could not be unloaded and reloaded without some Oops or
       Panic occurring.
      (2) The driver was panicking because of a corruption in the Memory
      Manager when the iocb list was getting allocated.
      
      Root cause for the memory corruption was a double free of the Work Queue
      ring pointer memory - Freed once in the lpfc_sli4_queue_free when the CQ
      was destroyed and again in lpfc_sli4_queue_free when the WQ was destroyed.
      
      The pring free and the queue free were separated, the pring free was moved
      to the wq destroy routine because it a better fit logically to delete the
      ring with the wq.
      
      The checkpatch flagged several alignmenet issues that were also corrected
      with this patch.
      
      The mboxq was never initialed correctly before it was used by the driver
      this patch corrects that issue.
      Reported-by: NJunichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Tested-by: NJunichi Nomura <j-nomura@ce.jp.nec.com>
      d1f525aa
    • J
      Fix PRLI ACC rsp for NVME · c07f10cd
      James Smart 提交于
      PRLI ACC from target is FCP oriented.
      
      Word 0 was wrong. This was noticed by another nvmet-fc vendor that
      was testing the lpfc nvme-fc initiator with their target.
      
      Verified results with analyzer.
      
      PRLI
      BC B5 56 56  22 61 04 00  00 61 00 00  01 29 00 00  20 00 00 00
      00 10 FF FF  00 00 00 00  20 14 00 18  28 00 00 00  00 00 00 00
      00 00 00 00  00 00 00 20  00 00 00 00  9C D8 DA C9  BC 95 75 75
      
      ACC
      BC B5 56 56  23 61 00 00  00 61 04 00  01 98 00 00  30 00 00 00
      00 10 00 18  00 00 00 00  02 14 00 18  28 00 01 00  00 00 00 00
      00 00 00 00  00 00 00 18  00 00 00 00  B0 6B 07 57  BC B5 75 75
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      c07f10cd
    • J
      Fix extra line print in rqpair debug print. · afbb38fe
      James Smart 提交于
      An extra blank line was being added the the rqpair printing.
      
      Remove the extra line feed.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      afbb38fe
    • J
      Remove NULL ptr check before kfree. · eafe89f5
      James Smart 提交于
      The check for NULL ptr is not necessary, kfree will check it.
      
      Removing NULL ptr check.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      eafe89f5
    • J
      Remove unused defines for NVME PostBuf. · 06909bb9
      James Smart 提交于
      These defines for the posting of buffers for nvmet target were not used.
      
      Removing the unused defines.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      06909bb9
    • J
      Fix spelling in comments. · 0ef69968
      James Smart 提交于
      Comment should have said Repost.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      0ef69968
    • J
      Add debug messages for nvme/fcp resource allocation. · e8c0a779
      James Smart 提交于
      The xri resources are split into pools for NVME and FCP IO when NVME is
      enabled. There was not message in the log that identified this allocation.
      
      Added debug message to log XRI split.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      e8c0a779
    • J
      Fix log message in completion path. · c154e750
      James Smart 提交于
      In the lpfc_nvme_io_cmd_wqe_cmpl routine the driver was printing two
      pointers and the DID for the rport whenever an IO completed on a now
      that had transitioned to a non active state.
      
      There is no need to print the node pointer address for a node that
      is not active the DID should be enough to debug.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      c154e750
    • J
      Fix rejected nvme LS Req. · ba43c4d0
      James Smart 提交于
      In this case, the NVME initiator is sending an LS REQ command on an NDLP
      that is not MAPPED.  The FW rejects it.
      
      The lpfc_nvme_ls_req routine checks for a NULL ndlp pointer
      but does not check the NDLP state.  This allows the routine
      to send an LS IO when the ndlp is disconnected.
      
      Check the ndlp for NULL, actual node, Target and MAPPED
      or Initiator and UNMAPPED. This avoids Fabric nodes getting
      the Create Association or Create Connection commands.  Initiators
      are free to Reject either Create.
      Also some of the messages numbers in lpfc_nvme_ls_req were changed because
      they were already used in other log messages.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      ba43c4d0
    • J
      Fix nvme unregister port timeout. · 975ff31c
      James Smart 提交于
      During some link event testing it was observed that the
      wait_for_completion_timeout in the lpfc_nvme_unregister_port
      was timing out all the time.
      
      The initiator is claiming the nvme_fc_unregister_remoteport upcall is
      not completing the unregister in the time allotted.
      [ 2186.151317] lpfc 0000:07:00.0: 0:(0):6169 Unreg nvme wait failed 0
      
       The wait_for_completion_timeout returns 0 when the wait has
      been outstanding for the jiffies passed by the caller.  In this error
      message, the nvme initiator passed value 5 - meaning 5 jiffies -
      and this is just wrong.
      
      Calculate 5 seconds in Jiffies and pass that value
      from the current jiffies.
      
      Also the log message for the unregister timeout was reduced
      because timeout failure is the same as timeout.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      975ff31c
    • J
      Standardize nvme SGL segment count · a44e4e8b
      James Smart 提交于
      Standardize default SGL segment count for nvme target and initiator
      
      The driver needs to make them the same for clarity.
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      a44e4e8b
  5. 21 4月, 2017 3 次提交
    • J
      nvmet_fc: Rework target side abort handling · a97ec51b
      James Smart 提交于
      target transport:
      ----------------------
      There are cases when there is a need to abort in-progress target
      operations (writedata) so that controller termination or errors can
      clean up. That can't happen currently as the abort is another target
      op type, so it can't be used till the running one finishes (and it may
      not).  Solve by removing the abort op type and creating a separate
      downcall from the transport to the lldd to request an io to be aborted.
      
      The transport will abort ios on queue teardown or io errors. In general
      the transport tries to call the lldd abort only when the io state is
      idle. Meaning: ops that transmit data (readdata or rsp) will always
      finish their transmit (or the lldd will see a state on the
      link or initiator port that fails the transmit) and the done call for
      the operation will occur. The transport will wait for the op done
      upcall before calling the abort function, and as the io is idle, the
      io can be cleaned up immediately after the abort call; Similarly, ios
      that are not waiting for data or transmitting data must be in the nvmet
      layer being processed. The transport will wait for the nvmet layer
      completion before calling the abort function, and as the io is idle,
      the io can be cleaned up immediately after the abort call; As for ops
      that are waiting for data (writedata), they may be outstanding
      indefinitely if the lldd doesn't see a condition where the initiatior
      port or link is bad. In those cases, the transport will call the abort
      function and wait for the lldd's op done upcall for the operation, where
      it will then clean up the io.
      
      Additionally, if a lldd receives an ABTS and matches it to an outstanding
      request in the transport, A new new transport upcall was created to abort
      the outstanding request in the transport. The transport expects any
      outstanding op call (readdata or writedata) will completed by the lldd and
      the operation upcall made. The transport doesn't act on the reported
      abort (e.g. clean up the io) until an op done upcall occurs, a new op is
      attempted, or the nvmet layer completes the io processing.
      
      fcloop:
      ----------------------
      Updated to support the new target apis.
      On fcp io aborts from the initiator, the loopback context is updated to
      NULL out the half that has completed. The initiator side is immediately
      called after the abort request with an io completion (abort status).
      On fcp io aborts from the target, the io is stopped and the initiator side
      sees it as an aborted io. Target side ops, perhaps in progress while the
      initiator side is done, continue but noop the data movement as there's no
      structure on the initiator side to reference.
      
      patch also contains:
      ----------------------
      Revised lpfc to support the new abort api
      
      commonized rsp buffer syncing and nulling of private data based on
      calling paths.
      
      errors in op done calls don't take action on the fod. They're bad
      operations which implies the fod may be bad.
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      a97ec51b
    • J
      nvmet_fc: add req_release to lldd api · 19b58d94
      James Smart 提交于
      With the advent of the opdone calls changing context, the lldd can no
      longer assume that once the op->done call returns for RSP operations
      that the request struct is no longer being accessed.
      
      As such, revise the lldd api for a req_release callback that the
      transport will call when the job is complete. This will also be used
      with abort cases.
      
      Fixed text in api header for change in io complete semantics.
      
      Revised lpfc to support the new req_release api.
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      19b58d94
    • J
      nvmet_fc: add target feature flags for upcall isr contexts · 39498fae
      James Smart 提交于
      Two new feature flags were added to control whether upcalls to the
      transport result in context switches or stay in the calling context.
      
      NVMET_FCTGTFEAT_CMD_IN_ISR:
        By default, if the flag is not set, the transport assumes the
        lldd is in a non-isr context and in the cpu context it should be
        for the io queue. As such, the cmd handler is called directly in the
        calling context.
        If the flag is set, indicating the upcall is an isr context, the
        transport mandates a transition to a workqueue. The workqueue assigned
        to the queue is used for the context.
      NVMET_FCTGTFEAT_OPDONE_IN_ISR
        By default, if the flag is not set, the transport assumes the
        lldd is in a non-isr context and in the cpu context it should be
        for the io queue. As such, the fcp operation done callback is called
        directly in the calling context.
        If the flag is set, indicating the upcall is an isr context, the
        transport mandates a transition to a workqueue. The workqueue assigned
        to the queue is used for the context.
      
      Updated lpfc for flags
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      39498fae
  6. 19 4月, 2017 1 次提交
  7. 23 3月, 2017 2 次提交
    • A
      scsi: lpfc: fix building without debugfs support · 223b78ea
      Arnd Bergmann 提交于
      On a randconfig build without CONFIG_SCSI_LPFC_DEBUG_FS, I ran into
      multiple compile failures:
      
      drivers/scsi/lpfc/lpfc_debugfs.h: In function 'lpfc_debug_dump_wq':
      drivers/scsi/lpfc/lpfc_debugfs.h:405:15: error: 'DUMP_FCP' undeclared (first use in this function); did you mean 'DUMP_VAR'?
      drivers/scsi/lpfc/lpfc_debugfs.h:405:15: note: each undeclared identifier is reported only once for each function it appears in
      drivers/scsi/lpfc/lpfc_debugfs.h:408:22: error: 'DUMP_NVME' undeclared (first use in this function); did you mean 'DUMP_NONE'?
      drivers/scsi/lpfc/lpfc_nvmet.c: In function 'lpfc_nvmet_xmt_ls_rsp_cmp':
      drivers/scsi/lpfc/lpfc_nvmet.c:109:2: error: implicit declaration of function 'lpfc_nvmeio_data'; did you mean 'lpfc_mem_free'? [-Werror=implicit-function-declaration]
      drivers/scsi/lpfc/lpfc_nvmet.c: In function 'lpfc_nvmet_xmt_fcp_op':
      drivers/scsi/lpfc/lpfc_nvmet.c:523:10: error: unused variable 'id' [-Werror=unused-variable]
      
      They are all trivial to fix, so I'm doing it in a combined patch here.
      
      Fixes: 1d9d5a98 ("scsi: lpfc: refactor debugfs queue dump routines")
      Fixes: bd2cdd5e ("scsi: lpfc: NVME Initiator: Add debugfs support")
      Fixes: 2b65e182 ("scsi: lpfc: NVME Target: Add debugfs support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      223b78ea
    • D
      scsi: lpfc: Fix PT2PT PRLI reject · a71e3cdc
      Dick Kennedy 提交于
      lpfc cannot establish connection with targets that send PRLI in P2P
      configurations.
      
      If lpfc rejects a PRLI that is sent from a target the target will not
      resend and will reject the PRLI send from the initiator.
      
      [mkp: applied by hand]
      Signed-off-by: NDick Kennedy <dick.kennedy@broadcom.com>
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      a71e3cdc
新手
引导
客服 返回
顶部