1. 26 Jun, 2013 2 commits
  2. 25 Jun, 2013 11 commits
  3. 24 Jun, 2013 11 commits
  4. 04 Jun, 2013 11 commits
  5. 31 May, 2013 5 commits
    • Steffen Maier's avatar
      [SCSI] zfcp: status read buffers on first adapter open with link down · 9edf7d75
      Steffen Maier authored
      Commit 64deb6ef
      "[SCSI] zfcp: Use status_read_buf_num provided by FCP channel"
      started using a value returned by the channel but only evaluated the value
      if the fabric link is up.
      Commit 8d88cf3f
      "[SCSI] zfcp: Update status read mempool"
      introduced mempool resizings based on the above value.
      On setting an FCP device online for the very first time since boot, a new
      zeroed adapter object is allocated. If the link is down, the number of
      status read requests remains zero. Since just the config data exchange is
      incomplete, we proceed with adapter open recovery. However, we
      unconditionally call mempool_resize with adapter->stat_read_buf_num == 0 in
      this case.
      
      This causes a kernel message "kernel BUG at mm/mempool.c:131!" in process
      "zfcperp<FCP-device-bus-ID>" with last function mempool_resize in Krnl PSW
      and zfcp_erp_thread in the Call Trace.
      
      Don't evaluate channel values which are invalid on link down. The number of
      status read requests is always valid, evaluated, and set to a positive
      minimum greater than zero. The adapter open recovery can proceed and the
      channel has status read buffers to inform us on a future link up event.
      While we are not aware of any other code path that could result in mempool
      resize attempts of size zero, we still also initialize the number of status
      read buffers to be posted to a static minimum number on adapter object
      allocation.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org> #2.6.35+
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      9edf7d75
    • Martin Peschke's avatar
      [SCSI] zfcp: remove access control tables interface · 663e0890
      Martin Peschke authored
      This patch removes an interface that was used to manage access control
      tables within the HBA. The patch consequently removes the handling
      for conditions related to those access control tables, too.
      
      That initiator-based access control feature was only needed until the
      introduction of NPIV and was withdrawn with z10 years ago.
      It's time to cleanup the corresponding device driver code.
      Signed-off-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      663e0890
    • Steffen Maier's avatar
      [SCSI] zfcp: module parameter dbflevel for early debugging · bf3ea3ae
      Steffen Maier authored
      So far, we could only increase the s390dbf log level after an FCP
      device has been initially set online for it to create the dbf entries
      required to adjust the level.
      
      Introduce zfcp.dbflevel as counterpart to the already existing
      zfcp.dbfsize to enable debugging of e.g. setting an FCP device online.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      bf3ea3ae
    • Steffen Maier's avatar
      [SCSI] zfcp: block queue limits with data router · 5fea4291
      Steffen Maier authored
      Commit 86a9668a
      "[SCSI] zfcp: support for hardware data router"
      reduced the initial block queue limits in the scsi_host_template to the
      absolute minimum and adjusted them later on. However, the adjustment was
      too late for the BSG devices of Scsi_Host and fc_host.
      
      Therefore, ioctl(..., SG_IO, ...) with request or response size > 4kB to a
      BSG device of an fc_host or a Scsi_Host fails with EINVAL. As a result,
      users of such ioctl such as HBA_SendCTPassThru() in libzfcphbaapi return
      with error HBA_STATUS_ERROR.
      
      Initialize the block queue limits in zfcp_scsi_host_template to the
      greatest common denominator (GCD).
      
      While we cannot exploit the slightly enlarged maximum request size with
      data router, this should be neglectible. Doing so also avoids running into
      trouble after live guest relocation (LGR) / migration from a data router
      FCP device to an FCP device that does not support data router. In that
      case, zfcp would figure out the new limits on adapter recovery, but the
      fc_host and Scsi_Host (plus in fact all sdevs) still exist with the old and
      now too large queue limits.
      
      It should also OK, not to use half the size as in the DIX case, because
      fc_host and Scsi_Host do not transport FCP requests including SCSI commands
      using protection data.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Reviewed-by: default avatarMartin Peschke <mpeschke@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org> #3.2+
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      5fea4291
    • Daniel Hansel's avatar
      [SCSI] zfcp: fix adapter (re)open recovery while link to SAN is down · f76ccaac
      Daniel Hansel authored
      FCP device remains in status ERP_FAILED when device is switched online
      or adapter recovery is triggered  while link to SAN is down.
      
      When Exchange Configuration Data command returns the FSF status
      FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process.
      The only retries are done during the common error recovery procedure
      (i.e. max. 3 retries with 8sec sleep between) and remains in status
      ERP_FAILED with QDIO down.
      
      This commit reverts the commit 0df13847
      (zfcp: Fix adapter activation on link down).
      When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the
      adapter recovery will be finished without any retries. QDIO will be
      up now and status changes such as LINK UP will be received now.
      Signed-off-by: default avatarDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org> #2.6.37+
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      f76ccaac