Skip to content

L
linux
Switch branch/tag
  1. 26 Jun, 2013 1 commit
  3. 25 Jun, 2013 11 commits
  5. 24 Jun, 2013 11 commits
  7. 04 Jun, 2013 11 commits
  9. 31 May, 2013 6 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
    • Sebastian Ott's avatar
      [SCSI] zfcp: remove unused device_unregister wrapper · bd323866
      Sebastian Ott authored 
      Remove the now unused function zfcp_device_unregister since all
users have been converted to use device_unregister directly.
Reviewed-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      bd323866
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7